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
> [email protected]
> 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/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
