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

[Andy Bierman <[e-mail]>]

On Thu, Jun 27, 2024 at 4:58 AM maqiufang (A) <maqiufang1=
[e-mail]> wrote:

> Hi, James,
>
>
>
> 1.      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.]
>
> My intuition is that it makes more sense to see “ietf-netconf” module
> being published by 6241bis, instead of this work; and same for
> “ietf-datastore” and “ietf-nmda-compare”. It's already the case that
> private-candidate is not covered in the base spec, I am not sure how we
> could make it feel like part of the base protocol. The augment way also
> seems good enough to me.
>
>
>


IMO the ietf-netconf module MUST NOT be republished unless the NETCONF
protocol is updated (e.g. base:1.2).
The new work augments the existing modules.  It will be optional to
implement so it does not replace the existing module in any way.


Andy






> 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]
>
> As a co-author of system-config document, I don't recall any discussion
> around this point;-) The use of  datastore identities in NMDA allows for
> future expansion, I am unsure there is a need to revise “ietf-datastores”
> module. System datastore definition follows the guidelines for defining
> datastores in appendix A of RFC8342, as well as definition of
> <factory-default> in RFC 8808 (see
> https://datatracker.ietf.org/doc/html/rfc8808#section-4) For NMDA
> servers to support private-candidate, I believe this draft should also
> follow the similar way.
>
> Best Regards,
>
> Qiufang
>
> 3.      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.]
>
> 4.
>
> 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.
>
>
>
> 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?
>
>
>
>
>
> 3.
>
> 4.      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?
>
>
>
>
>
> 4.
>
> 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.
>
>
>
> 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
>
>
>
>
>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>