Subject: Re: [netmod] Thoughts on draft-clemm-netmod-nmda-diff

From: Alexander Clemm <[email-masked]>
Date: Thu, 9 Aug 2018 00:15:50 +0000

Hello Qin,

quick responses inline, <ALEX>

--- Alex

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Friday, July 20, 2018 8:26 AM
> To: Joe Clarke <jclarke=[email-masked]>; [email-masked]
> Subject: Re: [netmod] Thoughts on draft-clemm-netmod-nmda-diff
> 
> Add two additional thoughts,
> (1) I hope NMDA datastore can be used to compare one datastore at two
> different timepoints, so I am not sure source and target defined in the
> model are enough to support this case.

<ALEX> This would require a "snapshotting" capability.  I think this would go beyond the scope of the draft.  However, if someone were to define such a capability, perhaps copy the datastore to the equivalent to a "candidate" (or "archive"), then the comparison operation should be applicable to having one of those as source target. 
</ALEX>

> (2) NMDA Base events defined in (https://tools.ietf.org/html/draft-wu-
> netconf-base-notification-nmda-01 can leverage NMDA diff to perform
> NMDA data validation, right now it is up to the server to detect validation
> event, but now we might rely on NMDA diff to decide which object is
> missing, what failed objects are. NMDA diff becomes a good tool.
> On the other hand, user might want to know when applied configuration
> start, when applied configuration complete, based on this to see when to
> perform NMDA diff. To address this, we might consider two or three new
> notifications In the draft-wu-netconf-base-notification-nmda-01 to help to
> decide when to use NDMA diff

<ALEX> Sure, I think looking at NMDA for scenarios deserving of notification is a worthwhile goal to address in your draft.  The nmda-diff draft addresses "on-demand" only.  As a side note, it is conceivable to have a difference also notified using a notification, i.e. define the equivalent of a subscription for a datastore compare (to make for a hybrid between YANG-Push and nmda-diff).  Personally, I think this would make a lot of sense, although I wouldn't want to go there until we have the existing subscription drafts finished.  
</ALEX>

> 
> -Qin
> -----邮件原件-----)
> 发件人: netmod [mailto:[email-masked]] 代表 Joe Clarke
> 发送时间: 2018年7月20日 21:52
> 收件人: [email-masked]
> 主题: [netmod] Thoughts on draft-clemm-netmod-nmda-diff
> 
> I just had a chance to finish reading this.  The in-person meeting group
> seems to strongly support this work, and I agree.
> 
> Coming from a serviceability standpoint, I find this might serve as a
> precursor to a VCS-like "blame log".  Would it be reasonable to include
> identifiers as to who (or what) made the change and when?  Sorry if this
> was raised at the mic today.  I came to the room a bit late.
> 
> Joe
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Qin Wu <[email-masked]>
Date: Thu, 9 Aug 2018 03:59:58 +0000

-----邮件原件-----
发件人: Alexander Clemm 
发送时间: 2018年8月9日 8:16
收件人: Qin Wu; Joe Clarke; [email-masked]
主题: RE: [netmod] Thoughts on draft-clemm-netmod-nmda-diff

Hello Qin,

--- Alex

> different timepoints, so I am not sure source and target defined in 
> the model are enough to support this case.

[Qin]: I think we can define mirror image datastore to record image at specific time point, in this case, we can use NMDA diff to compare their difference.

> NMDA data validation, right now it is up to the server to detect 
> validation event, but now we might rely on NMDA diff to decide which 
> object is missing, what failed objects are. NMDA diff becomes a good tool.
> start, when applied configuration complete, based on this to see when 
> to perform NMDA diff. To address this, we might consider two or three 
> new notifications In the draft-wu-netconf-base-notification-nmda-01 to 
> help to decide when to use NDMA diff

[Qin]: Yes,I think this is close to the event notification we proposed in draft-wu-netconf-base-notification-nmda-01, i.e., nmda-data-validate.
We can support NMDA diff to validate the data.
> I just had a chance to finish reading this.  The in-person meeting 
> group seems to strongly support this work, and I agree.
> 
> precursor to a VCS-like "blame log".  Would it be reasonable to 
> include identifiers as to who (or what) made the change and when?  
> Sorry if this was raised at the mic today.  I came to the room a bit late.
> 
> Joe
>