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

["Jan Lindblad (jlindbla)" <[e-mail]>]

Hi James, Rob, WG,

Thanks for the updated version! I had an initial read through. Indeed as you say, I think this resolves the important points we’ve been discussing. Very good!

The new version makes the “in conflict” concept a central part of the mechanism. I think this is great, and the rules for when an “in conflict” situation arises are quite clear. What is not so clear to me is what operation(s) that a client may perform that clears  the “in conflict” state of a node in the private candidate. Maybe that is something you could elaborate a bit on? This is just a detailed comment, and I don’t expect this to be a contentious point.

Best Regards,
/jan

From: James Cumming (Nokia) <james.cumming=[e-mail]>
Date: Thursday, 30 May 2024 at 21:37
To: [e-mail] <[e-mail]>
Subject: [netconf] Private candidates -03 and points for discussion
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:

1.      Added Andy Bierman as a contributor
2.      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.
3.      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.
4.      Updated the RFC list that this draft updates
5.      Section 4.6.1: Made the ‘what constitutes a conflict’ section explicit with a minimum set of requirements
6.      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.
7.      Section 4.7.2.9: Identified the delete-config operation needed updating as well so provided a solution for this
8.      Section 4.7.1.1: Added a statement calling out that the update operation is atomic and provided a definition
9.      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)
10.  Added an updated NMDA diagram to visually explain how the solution fits into NMDA
11.  Various grammatical enhancements

We look forward to further discussion.

James and Rob