[netconf] Re: Private candidates -03 and points for discussion

[Kent Watsen <[e-mail]>]

Hi James,


> On May 30, 2024, at 3:36 PM, James Cumming (Nokia) <james.cumming=[e-mail]> wrote:
> 
> Good morning/evening everyone,
>  
> The authors/editors of the private candidates draft have just published a new -03 version of the draft (https://datatracker.ietf.org/doc/draft-ietf-netconf-privcand/) which we believe address the comments from the last (couple of) IETF meetings.
>  
> We would like to invite everyone to review the draft and provide any feedback.
>  
> Whilst addressing the points raised, a few other issues were identified and we have proposed solutions to these in the draft as well.
>  
> Here is a summary of the changes in no particular order:
>  
> Added Andy Bierman as a contributor
> Section 4.7.2.11.1: Identified that commit-confirmed behaviour was unclear so provided some detail on how this should work with private candidates (and confirming that it is supported).  We considered how to deal with confirmed commits that expire their timer or are cancelled.  We also considered whether alternate sessions should be able to cancel them.
> Added the YANG models to the draft as requested.  This led us to a procedural question.  This draft is meant to operate for NMDA and non-NMDA capable servers.  It is also adding a new base operation (update) and has some additive changes to other older YANG models.  The discussion here is what the procedure should be for this.  All changes are additive and therefore this fact, coupled with the RFC sections that state that this draft updates the proceeding RFCs we hope is sufficient here.  We did discuss the option to do augmentation rather than updates but this feels fairly awkward for clients given the base operation and the additional datastore identity.  The approach we have in the draft (currently) also follows the suggestion given to another draft last meeting that was also looking to add new items to a base YANG model.  This approach is certainly common for drafts without embedded YANG models.

I don’t understand the “awkward for clients” comment.  I am surprised to see "ietf-netconf”, “ietf-datastore”, and "ietf-nmda-compare" being published by this I-D.   It seems that augments would work fine.

Regarding ietf-netconf, RFC 6241’s only noteworthy “update” is by RFC 8526 (NMDA for NETCONF) which defines two new operations and “augments” in the “datastore” parameter into a number of existing RPCs.  

Regarding ietf-datastore, note that “identity” statements were used in part to enable new declarations to occur outside RFC 8342 (NMDA).  For example, this is what the “system-config” draft has: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-06#name-yang-module

Can you remind me, what was the other draft last meeting that was also looking to add new items to a base YANG model?


> Updated the RFC list that this draft updates

One of the RFCs listed is RFC 8526, but the string “8526" isn’t found anywhere else in the draft...

When “updating” an RFC, it is customary to have a paragraph or section (called “Updates to RFC XXXX”) in the Introduction that provides details.  For instance, https://datatracker.ietf.org/doc/html/rfc8526 uses paragraphs while https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-06#name-introduction uses sections.

BTW, should this draft also “update" RFC 8342, for the same reasons as the system-config draft?


> Section 4.6.1: Made the ‘what constitutes a conflict’ section explicit with a minimum set of requirements
> Section 4.6.1: Added scope for servers to add additional requirements to conflict detection mechanisms beyond the minimum set (which are mandatory).  Transaction ID is explicitly mentioned as one such example here.
> Section 4.7.2.9: Identified the delete-config operation needed updating as well so provided a solution for this
> Section 4.7.1.1: Added a statement calling out that the update operation is atomic and provided a definition
> Section 4.6.1: Explained in more detail how each node is marked as in conflict which covers the discussed use-case of servers deciding to call update themselves (without client prompting)
> Added an updated NMDA diagram to visually explain how the solution fits into NMDA
> Various grammatical enhancements
>  
> We look forward to further discussion.

While focusing on the above, I noticed a number of editorial issues.  It would be a significant effort for me to provide a review of at that level of detail.  Hopefully most of these will be addressed automatically in time.

High-level comments:

- I wonder if Section 3 is needed, or perhaps it could reduced to a paragraph in the Introduction?    Generally I don’t think specs should provide a lot of motivating justification...

- Regarding Section 4.4.1, the go-to solution these days is to use YANG Library.  Capabilities are only maintained for legacy clients.  FWIW, I suspect that a NETCONF 2.0 would eliminate the <hello> messages.  

- Regarding Section 4.4.2, given the previous comment, I’m opposed to a client-sent capability having a significant role.

Regarding Section 4.3, I don’t understand why there is a difference.  Please make the solutions the same so that, e.g., an RC server can be built on top on an NC server, and vice versa.  BTW, why destroy the private candidate at all, can't each user have their own perpetually?  Does it matter?


> James and Rob

Kent // contributor