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

[Schönwälder, Jürgen <[e-mail]>]

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

On Mon, Feb 17, 2020 at 11:42:01AM -0800, Joel Jaeggli wrote:
> 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
> 


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


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>