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

[Andy Bierman <[e-mail]>]

On Fri, Jun 28, 2024 at 7:58 AM James Cumming (Nokia) <
[e-mail]> wrote:

> Hi Andy,
>
>
>
> The idea of an interim was floated but the chairs felt we needed more
> discussion on the list first.  I would be in favour of either an interim or
> a side meeting in Vancouver (I’m not sure which is the correct option of an
> adopted draft).
>
>
>
> I don’t appear to have access to create a repository on this specific
> GitHub account.  If someone would be able to give me access I would be more
> than happy to post it here (I think it would be beneficial to track issues).
>
>
>

IMO email is not a modern collaboration tool.
Use of an issue tracker is needed for complex drafts like this one.

Thanks
>
>
> James
>
>
>

Andy


>
>
>
>
> *From: *Andy Bierman <[e-mail]>
> *Date: *Wednesday, 26 June 2024 at 17:28
> *To: *James Cumming (Nokia) <[e-mail]>
> *Cc: *Kent Watsen <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: [netconf] Re: 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.
>
>
>
>
>
>
>
> On Wed, Jun 26, 2024 at 11:08 AM James Cumming (Nokia) <james.cumming=
> [e-mail]> wrote:
>
> Hi Kent,
>
>
>
> Thanks for taking the time to review and provide your feedback.  It’s much
> appreciated.  Please find some responses/comments/questions interleaved.
>
>
>
>
>
>
>
> This draft is not on the NETCONF WG github page:
>
> https://github.com/netconf-wg
>
>
>
> It would be helpful to start using the issue tracker for this important
> draft.
>
>
>
> Would it be possible to have a side meeting in Vancouver and maybe a
> virtual interim in August
>
> for people interested in understanding and implementing private candidates?
>
>
>
> The original NETCONF design team (pre-4741) came up with the
> "conventional" datastore model
>
> so the major stakeholders each had a reasonable implementation strategy
> for their software architecture.
>
>
>
>
>
> Thanks
>
>
>
> James
>
>
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
> 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.
>
>
>
> [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]
>
>
>
>    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?
>
>
>
> [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]
>
>