Subject: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

From: Joel Jaeggli <[email-masked]>
Date: Mon, 17 Feb 2020 11:42:01 -0800

Greetings,

This was supposed to get processed shortly after IETF 106, however I lost track of it. We are therefore running a 2 week WGLC on draft-ietf-netmod-nmda-diff-03.

https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/

the 02 - 03 diff is available here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-nmda-diff-02&url2=draft-ietf-netmod-nmda-diff-03

Please send email to the list indicating your support or concerns.

This WGLC will conclude Monday March 2nd.

Thank you,
NETMOD WG Chairs

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 19 Feb 2020 16:57:28 +0000

Hi,

this is a good document that deserves to go forward. Some comments...

- In the introduction, you may want to mention that applied config
  often differs from config because applied config includes stuff that
  was learned or generated by the system (e.g., IP addresses obtained
  via DHCP or generated by the kernel itself). This applies to systems
  that otherwise implement NC or RC in a synchronous update manner,
  i.e., a difference between <intended> and <applied> is for many
  operational systems likely the normal situation and not an
  exceptional one.

- I do not understand this:

      [...]  (The filter dow not contain expressions that
      would match values data nodes, as this is not required by most use
      cases and would complicate the scheme, from implementation to
      dealing with race conditions.)

  Despite the wording nits, I fail to understand the race condition
  argument. It seems the filters are the same as we have them in other
  places and this is good and a strong argument by itself. Reusing
  concepts is a good thing. Just state that and remove potentially
  hand-waving arguments about race conditions created by filtering on
  values. (And subtree filters can filter out certain interfaces by
  matching the <name/> element.)

- I think you should import the term 'schema node' (and if necessary
  also other terms) from RFC 7950. Perhaps merge section 2+3 into a
  section Terminology that has the RFC2119 blurb and states that this
  specification uses the terminology defined in RFC 7950 and RFC 8342.

- Given that the applied configuration includes learned and system
  provided data, it may make a lot of sense to filter on origin so
  that learned or system generated config is not part of the
  comparison. I think this is really missing. Of course, one can
  filter the result to get rid of all 'learned' items but the whole
  point of the compare RPC is to avoid long responses that are not
  needed. The get-data operation defined in RFC 8526 has an origin
  filter that may be reused. (Perhaps it makes sense to align the
  parameters with RFC 8526 get-data even further.)

- Why do we need the 'no-matches' leaf? Why not simply return an empty
  'differences' container?

- Nit

  OLD

   RPC request to compare <operational< (source of the comparison) with
   <intended>(target of the comparison):

  NEW

   RPC request to compare <operational> (source of the comparison) with
   <intended> (target of the comparison):

- I have not validated the examples.

- Section 7 talks about rejecting frequent requests. It may be useful
  to specify which error response is returned in this case so that
  coders implement the same behavior.

- Perhaps the document should spell out how compare interacts with
  NACM. I kind of assume that NACM rules are applied before the
  content is compared, i.e., data that is not accessible won't get
  compared. Well, whatever the correct behavior is, I think this
  deserves to be spelled out.

- I would probably have picked in ietf-interfaces example to avoid a
  reference to a work in progress but this does not really matter
  much.

/js

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Feb 2020 17:58:34 +0100 (CET)

Hi,

> Please send email to the list indicating your support or concerns.

I have reviewed draft-ietf-netmod-nmda-diff-03 and have some comments.

o  Section 4

      (The filter dow not contain expressions that
      would match values data nodes, as this is not required by most use
      cases and would complicate the scheme, from implementation to
      dealing with race conditions.)

  I don't think it is a good idea to reject filters that match
  values.  For example, suppose I want to compare the config for a
  specific interface.  I could do /interfaces/interfac[name='eth0'],
  or a subtree filter.  Why should this not be possible?

  Besides, the mechanism of rejecting such filters is not defined.
  The only text we have is this sentence within parentheses.

o  leaf all in the YANG module

   s/Specifically, if one/For example, if one/

o  leaf xpath-filter

  The description needs to specify the XPath context, see RFC 6991.

o  container differences

  It is not clear what the YANG patch records reflect.  Is it the
  patches that are required to go from "source" to "target"?  Or the
  other way around?

o  anydata source-value

  This description needs work.  The current text isn't correct
  ('value' is not present when the operation is 'move').

  The description should explain what this is supposed to contain.

o  Section 6

  The example is confusing.  It seems the diff is the patches required
  to go from target to source.  And the source-value contains the
  origin present in the target, is that correct?  And the value
  contains an origin that isn't present in neither the source nor the
  target.

/martin

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 26 Feb 2020 01:33:08 +0000

Hi Juergen,

thank you for your comments!  Please find replies inline, <ALEX>

--- Alex

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Schönwälder, Jürgen
> Sent: Wednesday, February 19, 2020 8:57 AM
> To: Joel Jaeggli <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-
> netmod-nmda-diff-03
> 
> Hi,
> 

<ALEX>  
Agreed.  Adding the following text in the Introduction to bring this out clearer: " Likewise, during the course of operation, some data values may be learned or updated by the system itself over time, causing datastores to diverge. "
</ALEX>

>   matching the <name/> element.)

<ALEX>  What this meant to explain is that the filter simply defines which nodes are in and out of scope, independent of their actual value.  In other words, you would not be able to specify something like "have this be in scope, but only if its value is between 5 and 10".  This is to keep things simple; the race condition concerns if there are different speeds at which values propagate.  
In order to simplify this, I suggest we simply remove the text in parantheses (which was meant to provide clarification, but seems to add confusion, hence best to simply strike.)  
</ALEX>

>   specification uses the terminology defined in RFC 7950 and RFC 8342.

<ALEX>
OK, we are merging 2+3 (both are very short anyway).  Putting the following sentence in lieu of the acronyms: This specification uses the terminology defined in [RFC7950] and [RFC8342].  For definitions of terms such as "datastore", "schema node", "<intended>",  or "origin", please refer to those RFCs.  
</ALEX>

>   parameters with RFC 8526 get-data even further.)

<ALEX>Hmm, what are you exactly suggesting here?  We could add a parameter to include (or exclude) data of a certain origin.  However, that would raise the possibility that some differences are not found whose cause is precisely that they have a different origin than anticipated (e.g., for which it was not clear that they could be learned, or that they would be preconfigured).  Hence not making changes just yet; could you explain your requirement/suggestion a little more?  
</ALEX>
> - Why do we need the 'no-matches' leaf? Why not simply return an empty
<ALEX>
I guess this is a design choice.  I guess we could return an empty container as well; the "no-matches" makes it more "explicit", and in terms of response size it does not make a difference.  Unless there is a strong preference, we would like to prefer to keep it.  (Or perhaps Andy wants to jump in?)
</ALEX>

>    <intended> (target of the comparison):

<ALEX> fixed the spacing 
</ALEX>

>   coders implement the same behavior.
<ALEX> We could add that.  Which one would be appropriate to return / what should be returned?  
Should we simply return error-type "rpc", with error-tag "resource-denied"?   
If we do that, should we also include error-info, specifying a time interval after which it would be "safe" to issue the next diff request?  
</ALEX>

>   deserves to be spelled out.

<ALEX> Per RFC 8341, the same access control rules apply to all datastores subjected to NACM - presumably also to all datastores that can be subjected to nmda-diff.  From that perspective we didn't think it necessary to spell it out, but perhaps it should be.  
How about adding the following at the end of the first paragraph of Section 4:
"Any access control rules as configured by NACM [RFC 8341] are applied by the server before the comparison is performed, that is, only datastore schema nodes for which the client has read access are included in the comparison."  
</ALEX>

>   reference to a work in progress but this does not really matter

<ALEX> That would have been possible as well.  We prefer sticking with this example (it's just an example, so non-normative) if acceptable since it generates less work, however, if there is insistence that we update, we will be happy to do so. 

Thanks (end of my replies here)
--- Alex
</ALEX>

> > This was supposed to get processed shortly after IETF 106, however I lost
> track of it. We are therefore running a 2 week WGLC on draft-ietf-netmod-
> nmda-diff-03.
> >
> >
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-nmda-
> diff%2F&amp;data=02%7C01%7Calex%40futurewei.com%7C27cc7820468c4c5f
> 7bb208d7b55cd5c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
> 7177282659984332&amp;sdata=hMaCe8q44NEdcaPy74s29tAkLIJbEBQhjnRp5Y
> mtkB0%3D&amp;reserved=0
> >
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-netmod-nmda-diff-
> 02%26url2%3Ddraft-ietf-netmod-nmda-diff-
> 03&amp;data=02%7C01%7Calex%40futurewei.com%7C27cc7820468c4c5f7bb2
> 08d7b55cd5c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637177
> 282659984332&amp;sdata=jm03o26D0LMjaUfERALelo3RtNG4%2BliglxPWR3Ls
> 99c%3D&amp;reserved=0
> >
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;data=02%7C01%7Calex%40fu
> turewei.com%7C27cc7820468c4c5f7bb208d7b55cd5c9%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637177282659984332&amp;sdata=kMP6EgO
> qJ6N3FkPnCCt%2F25Xt9v4p9XAUGvpCv2Go47Y%3D&amp;reserved=0
> 
> 
> --
> Fax:   +49 421 200 3103
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .jacobs-
> university.de%2F&amp;data=02%7C01%7Calex%40futurewei.com%7C27cc782
> 0468c4c5f7bb208d7b55cd5c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> 7C0%7C637177282659984332&amp;sdata=BlWciwRclsZnEzcugWnkxr7vAWvsS
> E%2BKGodwzUMRS9Q%3D&amp;reserved=0>
> 
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;data=02%7C01%7Calex%40fu
> turewei.com%7C27cc7820468c4c5f7bb208d7b55cd5c9%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637177282659984332&amp;sdata=kMP6EgO
> qJ6N3FkPnCCt%2F25Xt9v4p9XAUGvpCv2Go47Y%3D&amp;reserved=0

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 26 Feb 2020 02:48:05 +0000

Hi Martin,

thank you for your comments!  Please see replies inline, <ALEX>

--- Alex

> From: netmod <[email-masked]> On Behalf Of Martin Bjorklund
> Sent: Thursday, February 20, 2020 8:59 AM
> To: [email-masked]
> diff%2F&amp;data=02%7C01%7Calex%40futurewei.com%7C2a7d8572a82d4d
> c6fb8208d7b6263e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37178147700288369&amp;sdata=z8dXlaWjYttnG2vFn8YWLzld3i2TpQoMkHXks
> I9xm%2Bc%3D&amp;reserved=0
> >
> 03&amp;data=02%7C01%7Calex%40futurewei.com%7C2a7d8572a82d4dc6fb8
> 208d7b6263e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63717
> 8147700298323&amp;sdata=1uye5dZqb7dhIJ5DZaGb4yChrLD6BUCg8R%2BwK
> Pvnlm4%3D&amp;reserved=0
> >

<ALEX> In my response to Juergen, I suggested to simply remove the text in the parantheses as it is apparently confusing.  
Our intent was to keep it simple and simply use the filter to "scope" the operation.  If we want to include matching values, things get a bit more complex with no clear benefit (when you would even want to specify such filter), but admittedly we were thinking of e.g. rapidly changing operational data.  For example, what if the value matches in the source but not the target, or vice versa - do we need to specify which one we mean (source, target, or any)?  There are also the mentioned "race conditions" if snap shots are taken at different times - although I guess those would be implementation limitations.  

That said, we can of course add it in if you do feel we should have that option (and we don't get objections).  You are correct that we should specify an error for rejecting the filter.  
</ALEX>

>    s/Specifically, if one/For example, if one/

<ALEX> Changed </ALEX>
>   The description needs to specify the XPath context, see RFC 6991.

<ALEX> Not sure what we need to be done here; the leaf uses the type definition from RFC 6991 (i.t. type yang:xpath1.0); is there anything else - please advise
</ALEX> 

>   patches that are required to go from "source" to "target"?  Or the

<ALEX> It is from source to target.  This is stated e.g. here: "The YANG-Patch data model is augmented to indicate the value of source datastore nodes in addition to the patch itself that would need to be applied to the source to produce the target."
I updated the description in the container "differences" as follows:
"            "The list of differences, encoded per RFC8072, 
             indicating the patches that need to be applied to 
             the source in order to arrive at the target, 
             with an augmentation to include source values where 
             applicable.";"
</ALEX>

>   The description should explain what this is supposed to contain.

<ALEX> When the operation is 'move', we want to be able to indicate the order prior to the move.  What would you call it?  
</ALEX>

>   contains an origin that isn't present in neither the source nor the

<ALEX> We will review the example to ensure it's correct; will get back to you on that tomorrow.  The diff contains the patches to go from source to target, ie the patches that, when applied to source, give you the target.  

Thanks again for your review!
</ALEX>

> turewei.com%7C2a7d8572a82d4dc6fb8208d7b6263e8c%7C0fee8ff2a3b24018
> 9c753a1d5591fedc%7C1%7C0%7C637178147700298323&amp;sdata=W1xgXQS
> lSzklkBAE1m324pwfJHnS%2B88OschqnJDdEBw%3D&amp;reserved=0

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 26 Feb 2020 08:54:53 +0000

> Agreed.  Adding the following text in the Introduction to bring this out clearer: " Likewise, during the course of operation, some data values may be learned or updated by the system itself over ti…

OK

> In order to simplify this, I suggest we simply remove the text in parantheses (which was meant to provide clarification, but seems to add confusion, hence best to simply strike.)  

If the filters work exactly the same way as they do elsewhere, then I
am happy and yes removing the text in parenthesis is good.

> OK, we are merging 2+3 (both are very short anyway).  Putting the following sentence in lieu of the acronyms: This specification uses the terminology defined in [RFC7950] and [RFC8342].  For defini…

This works for me.

> <ALEX>Hmm, what are you exactly suggesting here?  We could add a parameter to include (or exclude) data of a certain origin.  However, that would raise the possibility that some differences are not…

I believe that there will be quite large differences between say
<running> and <operational> due to learned applied config (think of
address mapping tables or forwarding table entries originating from
control plane protocols) and if I am not interested in this learned
state, I like to have a filter that allows me to express that I like
to have some of the learned data ignored. Similarly, I having a filter
to express that I like to have all config false leafs ignored seems
useful if I compare a configuration datastore with <operational>.
There are several useful filters in the definition of get-data [RFC
8526] and I feel we are missing several of them here.

Yes, there may be cases where I do not want to use some of the filters
but that does not justify that other use cases like comparing
<running> against <operational> are not well supported.

> I guess this is a design choice.  I guess we could return an empty container as well; the "no-matches" makes it more "explicit", and in terms of response size it does not make a difference.  Unless…

$ diff rfc7950.txt rfc7950.txt
$ echo $?
0

Good old tools tend to return an empty diff and not a special value if
there is no difference hence I found the design a bit surprising.
Perhaps there is a reason behind the design but then it is not obvious
to me.

> >    <intended> (target of the comparison):

OK
 
> If we do that, should we also include error-info, specifying a time interval after which it would be "safe" to issue the next diff request?  

I don't have the answer but obviously it makes sense to clearly spell
out the error behavior. ;-)

> "Any access control rules as configured by NACM [RFC 8341] are applied by the server before the comparison is performed, that is, only datastore schema nodes for which the client has read access ar…

OK
 
> <ALEX> That would have been possible as well.  We prefer sticking with this example (it's just an example, so non-normative) if acceptable since it generates less work, however, if there is insiste…

As I said, this does not really matter much to me. (I would have
picked ietf-interfaces because it is stable and most likely widely
understood by pretty much everybody and it nicely can be used to
explain why <running> and <operational> differ in many different ways,
i.e., loopback addresses configured by the system, IP privacy
addresses created by the system, IP addresses obtained by DHCP, IP
addresses not in <operational> due to hardware not present.)

/js