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

["James Cumming (Nokia)" <[e-mail]>]

Hi Kent,

Thanks for taking the time to review and provide your feedback.  It’s much appreciated.  Please find some responses/comments/questions interleaved.

Thanks

James


Hi James,


On May 30, 2024, at 3:36 PM, James Cumming (Nokia) <james.cumming=[e-mail]<mailto: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:


  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.

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.

[Augments do work for most of the changes.  The decision to update was based around providing a consistent approach to all of the operations making private-candidates feel like part of the base specification.  For example <edit-config><target><candidate/></target></edit-config> becomes <edit-config><target><private-candidate/></target></edit-config> rather than <edit-config><target><private-candidate xmlns=”new_ns”/></target></edit-config>.  The same difference would be created for identity datastores.  This is probably something we would like to have a chair / AD ruling on and we will cover it in our slot in IETF120 in person as well.]

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?

[I was trying to find the details in the minutes but was unable to.  I recall that it may have been the system datastore update I do recall that it was Benoit who was discussing it]


  1.
  2.  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?

[Thanks Kent.  Rob is working on some text to cover this.]

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

[I reviewed it again and this section is IMHO a reasonable size to explain the problem statement.  I would welcome any additional views from the WG]

- 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.

[Thanks, we missed detailing this and will add it]

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

[The draft aims to keep an approach that works for NMDA and non-NMDA clients and servers, so that all clients can benefit from the new functionality if the server supports it.  What the above comment boils down to is whether the WG feels a client should be able to select between private-candidates and shared-candidates on a session-by-session basis.  If we feel they should (as they can in NMDA by targeting a specific datastore) then the current approach is probably the right one.  If we feel that a client should not be able to select between private and shared candidates on a per-session basis, then the alternative is to allow a server to specifically select a mode (perhaps in config but ‘how’ would be out of scope for the document) that is present for the lifetime of that choice… i.e. if a server implements private candidates a non-NMDA client will always get private-candidates and never be able to target the shared candidate.]

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?

[Let me try to address each part of this in turn:

Why is there a difference?  It is a natural approach in NETCONF to tie the candidate to the NETCONF session ID for a few reasons.  Firstly, this is communicated clearly at the start of each session and a session on a router is tied to it (at least in the implementations I have seen).  The NETCONF spec delineates nicely between the transport layer (e.g. SSH) where the authentication (and the ties to the user are handled) and the NETCONF protocol layer.  Blending these seemed unnatural.  Our understanding (which comes with a request for RESTCONF expert assistance) is that in RESTCONF there is no such session ID with which to tie the candidate to, therefore at the suggestion of the WG we selected the client identity (ie the RESTCONF username).  I note that you say RC can rely on NC.  I’m not sure if this is implementation specific or spec described so any guidance is welcome.

Why destroy the private-candidate at all?  If the private-candidate is tied to the NETCONF session ID then closing of this session would destroy this candidate.  Leaving it in place would just bloat the memory usage in a node.  This is based of my answer for why we are attaching it to the session-id rather than the username.  In RESTCONF we could choose not to destroy the private-candidate at all, but this would lead to significant memory overhead, for example 5000 users would have 5000 copies of running (as according to the spec a candidate is a full copy, although implementations may not implement it this way).  Another issue is that over time the probability of a private candidate being out of date is very high, therefore, any workflow would require a client to do an update immediately on starting the session in order to get the config back in sync.

Does it matter?  To answer this question in both contexts…. Does it matter that there is a slightly different implementation for NETCONF and RESTCONF?  I don’t think so, they are functionally very similar in the key parts of the draft.  Does it matter whether a candidate is destroyed at all?  Yes, in order to ensure optimal memory management of a node over a significant period of time (that may have a significant number of users).]

James and Rob

Kent // contributor

[Thanks Kent! We hope to have a -04 for the WG to review prior to IETF120]



From: Kent Watsen <[e-mail]>
Date: Thursday, 13 June 2024 at 23:05
To: James Cumming (Nokia) <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [netconf] Private candidates -03 and points for discussion

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


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:


  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.

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?




  1.
  2.  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?




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