Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F1AC1840F1 for ; Wed, 26 Jun 2024 14:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DG7QkwreGSg for ; Wed, 26 Jun 2024 14:28:11 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AFFC1840DE for ; Wed, 26 Jun 2024 14:28:06 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-656d8b346d2so5132573a12.2 for ; Wed, 26 Jun 2024 14:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1719437285; x=1720042085; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FjcxdR7N2UJC0I7eXx6JGhxWK7xZRNOS5YsUFTLCOCE=; b=eX9lfcjlaPKsQWjG29ilJRlOzHf/GoHogJWaZs2eVA5cPNftKdUuDEXsgvQghxcDOq gxUUR/eIGJAMj1peRA7rOBB17bfhExzD02MhuWTkHCtdNmWP60iGhG/vP1GxYruLU9YG bQXTThrHQk9hqCbxQilCx+Kc4VfWU0128ispJyiBqZusAHGVwy6FXt4lmRUuz2AbIMBM LLUNPM+MhR4aTKQ+SzzP0p2PJfFT97ElexNMCrU9UGINVg2/NASY1Ms3WkPlnWU0oVUR rl/iQV9p+a9PznZJXMjxxswfWO/AjqWOa5D789EIKLY2QPx4z3yI+vsX2FXZDTjsNMlF gkZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719437285; x=1720042085; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FjcxdR7N2UJC0I7eXx6JGhxWK7xZRNOS5YsUFTLCOCE=; b=F1sGUlCDL0nnCfaGA2f9szIPfGvtjrfh8ibS5CQ71J/nzXQx1AadqW5Vq6S7wiTAko BOGfsHVwoHkaD63BMToocayuq9z8qAYio/yVH/vAtcOZMYRQ5wwYjaOcEalSbsqD7fDD jkXmWk2TgatbnmSQ0ueGtEKW4FPIZ2eL5Uzs6fhf34XpZ2xuHb9jTKq2cfaVS9ZPNh+S 1WEitKx0yyBNe2PyEXPsPi0JGqv/m4ad0ibih2YDjNwGqyuDSI9BSf4VQEjD0uprHjit C9EkzIu/9koduAWozFxhIA//D3DW6uVjXVqncu+AwS8MpQdrNow+ck93AoVInGlDQMva lwqA== X-Forwarded-Encrypted: i=1; AJvYcCU6mcEx/kFNMWyvDOgY1m8+vj8JTYLskhLqAO7A1v3iA0Tzof/ykpdMx3GmOTIK25A07r6EK/OsWbnHN26SPVAq X-Gm-Message-State: AOJu0Yzbm7IwKRDNuJbdVCVK3iM6hV15T6sgWVJJI+hpuWFMTEL7lr+3 TpbeJCnkvL9Ixu/hLTM2Y7ZiZjsE6X+ce7diT42Z8GbISB6lzCQxbaRiSRSJt5YpL90tBItLXg0 g7b0IuO0l6MDua7CVSrVWHqYhwqlPl+cQrNkmfw== X-Google-Smtp-Source: AGHT+IGsgkwN3ZqeOsQqJ7R2zpI968t1wiBh27JZlRlkFS+qzawNFp42ghm3np/arqlqG5x5CCXLn6t7gvSTgESY720= X-Received: by 2002:a05:6a20:72a4:b0:1bd:1d6e:d448 with SMTP id adf61e73a8af0-1bd1d6ed4d2mr7310694637.27.1719437285238; Wed, 26 Jun 2024 14:28:05 -0700 (PDT) MIME-Version: 1.0 References: <0100019014b5327e-0f40b891-8923-4063-a02c-cce7f2ab7923-000000@email.amazonses.com> In-Reply-To: From: Andy Bierman Date: Wed, 26 Jun 2024 14:27:54 -0700 Message-ID: To: "James Cumming (Nokia)" Content-Type: multipart/alternative; boundary="00000000000099c991061bd1b0c5" Message-ID-Hash: 72EMOUTFTLOOHHHI3ZCWIRLFOADOPYKA X-Message-ID-Hash: 72EMOUTFTLOOHHHI3ZCWIRLFOADOPYKA X-MailFrom: andy@yumaworks.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "netconf@ietf.org" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnetconf=5D_Re=3A_Private_candidates_-03_and_points_for_discussi?= =?utf-8?q?on?= List-Id: NETCONF WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000099c991061bd1b0c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 26, 2024 at 11:08=E2=80=AFAM James Cumming (Nokia) wrote: > Hi Kent, > > > > Thanks for taking the time to review and provide your feedback. It=E2=80= =99s 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=E2=80=AFPM, James Cumming (Nokia) < > james.cumming=3D40nokia.com@dmarc.ietf.org> 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 t= o > deal with confirmed commits that expire their timer or are cancelled. = We > also considered whether alternate sessions should be able to cancel th= em. > 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 thi= s > draft updates the proceeding RFCs we hope is sufficient here. We did > discuss the option to do augmentation rather than updates but this fee= ls > fairly awkward for clients given the base operation and the additional > datastore identity. The approach we have in the draft (currently) als= o > follows the suggestion given to another draft last meeting that was al= so > looking to add new items to a base YANG model. This approach is certa= inly > common for drafts without embedded YANG models. > > > > I don=E2=80=99t understand the =E2=80=9Cawkward for clients=E2=80=9D comm= ent. I am surprised to > see "ietf-netconf=E2=80=9D, =E2=80=9Cietf-datastore=E2=80=9D, and "ietf-n= mda-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 becomes > rather > than xmlns=3D=E2=80=9Dnew_ns=E2=80=9D/>. The same diff= erence would be > created for identity datastores. This is probably something we would lik= e > to have a chair / AD ruling on and we will cover it in our slot in IETF12= 0 > in person as well.] > > > > Regarding ietf-netconf, RFC 6241=E2=80=99s only noteworthy =E2=80=9Cupdat= e=E2=80=9D is by RFC > 8526 (NMDA for NETCONF) which defines two new operations and =E2=80=9Caug= ments=E2=80=9D in > the =E2=80=9Cdatastore=E2=80=9D parameter into a number of existing RPCs. > > > > Regarding ietf-datastore, note that =E2=80=9Cidentity=E2=80=9D statements= were used in > part to enable new declarations to occur outside RFC 8342 (NMDA). For > example, this is what the =E2=80=9Csystem-config=E2=80=9D 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 =E2=80=9C8526" isn=E2= =80=99t found > anywhere else in the draft... > > > > When =E2=80=9Cupdating=E2=80=9D an RFC, it is customary to have a paragra= ph or section > (called =E2=80=9CUpdates to RFC XXXX=E2=80=9D) in the Introduction that p= rovides 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 =E2=80=9Cupdate" RFC 8342, for the same reaso= ns as the > system-config draft? > > > > [Thanks Kent. Rob is working on some text to cover this.] > > 4. > 5. Section 4.6.1: Made the =E2=80=98what constitutes a conflict=E2=80= =99 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 ex= ample > 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 ti= me. > > > > High-level comments: > > > > - I wonder if Section 3 is needed, or perhaps it could reduced to a > paragraph in the Introduction? Generally I don=E2=80=99t think specs s= hould > provide a lot of motivating justification... > > > > [I reviewed it again and this section is IMHO a reasonable size to explai= n > 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 messages. > > > > [Thanks, we missed detailing this and will add it] > > > > - Regarding Section 4.4.2, given the previous comment, I=E2=80=99m oppose= d 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 datastor= e) > 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 =E2=80=98how=E2=80=99 w= ould be out of > scope for the document) that is present for the lifetime of that choice= =E2=80=A6 > 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=E2=80=99t understand why there is a differen= ce. > Please make the solutions the same so that, e.g., an RC server can be bui= lt > 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 th= e > 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 rout= er > 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 (whi= ch > 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=E2=80=99m = 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 ov= er > time the probability of a private candidate being out of date is very hig= h, > therefore, any workflow would require a client to do an update immediatel= y > on starting the session in order to get the config back in sync. > > > > Does it matter? To answer this question in both contexts=E2=80=A6. Does = it matter > that there is a slightly different implementation for NETCONF and > RESTCONF? I don=E2=80=99t think so, they are functionally very similar i= n 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 > *Date: *Thursday, 13 June 2024 at 23:05 > *To: *James Cumming (Nokia) > *Cc: *netconf@ietf.org > *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=E2=80=AFPM, James Cumming (Nokia) 40nokia.com@dmarc.ietf.org> 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 t= o > deal with confirmed commits that expire their timer or are cancelled. = We > also considered whether alternate sessions should be able to cancel th= em. > 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 thi= s > draft updates the proceeding RFCs we hope is sufficient here. We did > discuss the option to do augmentation rather than updates but this fee= ls > fairly awkward for clients given the base operation and the additional > datastore identity. The approach we have in the draft (currently) als= o > follows the suggestion given to another draft last meeting that was al= so > looking to add new items to a base YANG model. This approach is certa= inly > common for drafts without embedded YANG models. > > > > I don=E2=80=99t understand the =E2=80=9Cawkward for clients=E2=80=9D comm= ent. I am surprised to > see "ietf-netconf=E2=80=9D, =E2=80=9Cietf-datastore=E2=80=9D, and "ietf-n= mda-compare" being > published by this I-D. It seems that augments would work fine. > > > > Regarding ietf-netconf, RFC 6241=E2=80=99s only noteworthy =E2=80=9Cupdat= e=E2=80=9D is by RFC > 8526 (NMDA for NETCONF) which defines two new operations and =E2=80=9Caug= ments=E2=80=9D in > the =E2=80=9Cdatastore=E2=80=9D parameter into a number of existing RPCs. > > > > Regarding ietf-datastore, note that =E2=80=9Cidentity=E2=80=9D statements= were used in > part to enable new declarations to occur outside RFC 8342 (NMDA). For > example, this is what the =E2=80=9Csystem-config=E2=80=9D 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 =E2=80=9C8526" isn=E2= =80=99t found > anywhere else in the draft... > > > > When =E2=80=9Cupdating=E2=80=9D an RFC, it is customary to have a paragra= ph or section > (called =E2=80=9CUpdates to RFC XXXX=E2=80=9D) in the Introduction that p= rovides 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 =E2=80=9Cupdate" RFC 8342, for the same reaso= ns as the > system-config draft? > > > > > > > 4. > 5. Section 4.6.1: Made the =E2=80=98what constitutes a conflict=E2=80= =99 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 ex= ample > 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 ti= me. > > > > High-level comments: > > > > - I wonder if Section 3 is needed, or perhaps it could reduced to a > paragraph in the Introduction? Generally I don=E2=80=99t think specs s= hould > 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 messages. > > > > - Regarding Section 4.4.2, given the previous comment, I=E2=80=99m oppose= d to a > client-sent capability having a significant role. > > > > Regarding Section 4.3, I don=E2=80=99t understand why there is a differen= ce. > Please make the solutions the same so that, e.g., an RC server can be bui= lt > 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 -- netconf@ietf.org > To unsubscribe send an email to netconf-leave@ietf.org > --00000000000099c991061bd1b0c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 26, 2024 at 11:08=E2=80= =AFAM James Cumming (Nokia) <james.cumming=3D40nokia.com@dmarc.ietf.org> wrote:

H= i Kent,

= =C2=A0

T= hanks for taking the time to review and provide your feedback.=C2=A0 It=E2= =80=99s much appreciated.=C2=A0 Please find some responses/comments/questio= ns=C2=A0interleaved.=

= =C2=A0



This draft is not on the NETCONF WG github page:
<= div>
It would be helpful to start using the issue tracker for= this important draft.

Would it be possible to hav= e a side meeting in Vancouver and maybe a virtual interim in August
for people interested in understanding and implementing private candidat= es?

The original NETCONF design team (pre-4741) ca= me up with the "conventional" datastore model
so the ma= jor stakeholders each had a reasonable implementation strategy for their so= ftware architecture.=C2=A0=C2=A0

=C2=A0

T= hanks

= =C2=A0

J= ames

= =C2=A0

= =C2=A0



Andy

=C2=A0

H= i James,=C2=A0

= =C2=A0

= =C2=A0

O= n May 30, 2024, at 3:36=E2=80=AFPM, James Cumming (Nokia) <james.cumming=3D40nokia.com@dmarc.ietf.org> wrote:

= =C2=A0

G= ood morning/evening everyone,

= =C2=A0

T= he authors/editors of the private candidates draft have just published a ne= w -03 version of the draft (https://datatracker.ietf.org/doc/draft-ietf-netconf-privcand/)=C2=A0which we believe address the comments from the last (couple of) IETF meetings.

= =C2=A0

W= e would like to invite everyone to review the draft and provide any feedbac= k.

= =C2=A0

W= hilst addressing the points raised, a few other issues were identified and = we have proposed solutions to these in the draft as well.

= =C2=A0

H= ere is a summary of the changes in no particular order:

= =C2=A0

  1. Added Andy Bierman as a contributor
  2. Section 4.7.2.11.1: Identified that commit-confirmed behaviour was un= clear so provided some detail on how this should work with private candidat= es (and confirming that it is supported).=C2=A0 We considered how to deal with confirmed comm= its that expire their timer or are cancelled.=C2=A0 We also considered whet= her alternate sessions should be able to cancel them.<= /li>
  3. Added the YANG models to the draft as requested.=C2=A0 This l= ed us to a procedural question.=C2=A0 This draft is meant to operate for NM= DA and non-NMDA capable servers.=C2=A0 It is also adding a new base operation (update) and has some additive chan= ges to other older YANG models.=C2=A0 The discussion here is what the proce= dure should be for this.=C2=A0 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.=C2= =A0 We did discuss the option to do augmentation rather than updates but th= is feels fairly awkward for clients given the base operation and the additi= onal datastore identity.=C2=A0 The approach we have in the draft (currently) also follows the suggestion given to anot= her draft last meeting that was also looking to add new items to a base YAN= G model.=C2=A0 This approach is certainly common for drafts without embedde= d YANG models.

=C2=A0

I= don=E2=80=99t understand the =E2=80=9Cawkward for clients=E2=80=9D comment= .=C2=A0 I am surprised to see "ietf-netconf=E2=80=9D, =E2=80=9Cietf-da= tastore=E2=80=9D, and "ietf-nmda-compare" being published by this= I-D. =C2=A0 It seems that augments would work fine.

= =C2=A0

[Augments do work for most of the changes.=C2=A0 The decis= ion to update was based around providing a consistent approach to all of th= e operations making private-candidates feel like part of the base specification.=C2=A0 For example <edit-config><t= arget><candidate/></target></edit-config> becomes <= edit-config><target><private-candidate/></target></= edit-config> rather than <edit-config><target><private-ca= ndidate xmlns=3D=E2=80=9Dnew_ns=E2=80=9D/></target></edit-confi= g>.=C2=A0 The same difference would be created for identity datastores.=C2=A0 This i= s probably something we would like to have a chair / AD ruling on and we wi= ll cover it in our slot in IETF120 in person as well.]

= =C2=A0

R= egarding=C2=A0ietf-netcon= f,=C2=A0RFC 6241= =E2=80=99s only noteworthy =E2=80=9Cupdate=E2=80=9D is by RFC 8526 (NMDA fo= r NETCONF) which defines two new operations and =E2=80=9Caugments=E2=80=9D in the =E2= =80=9Cdatastore=E2=80=9D parameter into a number of existing RPCs. =C2=A0

= =C2=A0

R= egarding ietf-datastore, note that =E2=80=9Cidentity=E2=80=9D statements we= re used in part to enable new declarations to occur outside RFC 8342 (NMDA)= .=C2=A0 For example, this is what the =E2=80=9Csystem-config=E2=80=9D draft= has:=C2=A0https://datatracker.ietf.org/doc= /html/draft-ietf-netmod-system-config-06#name-yang-module=

= =C2=A0

C= an you remind me, what was the=C2=A0other draft last meeting that was also = looking to add new items to a base YANG model?

= =C2=A0

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

=C2=A0

  1. =C2=A0
  2. Updated the RFC list th= at this draft updates

=C2=A0

O= ne of the RFCs listed is RFC 8526, but the string =E2=80=9C8526" isn= =E2=80=99t found anywhere else in the draft...

= =C2=A0

W= hen =E2=80=9Cupdating=E2=80=9D an RFC, it is customary to have a paragraph = or section (called =E2=80=9CUpdates to RFC XXXX=E2=80=9D) in the Introducti= on that provides details.=C2=A0 For instance,=C2=A0https= ://datatracker.ietf.org/doc/html/rfc8526=C2=A0uses paragraphs while=C2=A0https://datatracke= r.ietf.org/doc/html/draft-ietf-netmod-system-config-06#name-introduction=C2=A0uses sections.

= =C2=A0

B= TW, should this draft also =E2=80=9Cupdate" RFC 8342, for the same rea= sons as the system-config draft?

= =C2=A0

[Thanks Kent.=C2=A0 Rob is wo= rking on some text to cover this.]

  1. =C2=A0
  2. Section 4.6.1: Made the= =E2=80=98what constitutes a conflict=E2=80=99 section explicit with a mini= mum set of requirements
  3. Section 4.6.1: A= dded scope for servers to add additional requirements to conflict detection= mechanisms beyond the minimum set (which are mandatory).=C2=A0 Transaction ID is explicitly mentioned as one such example here.<= /li>
  4. Section 4.7.2.9<= /a>: Identified the delete-config operation needed updating as well so prov= ided a solution for this
  5. Section 4.7.1.1: Added a statement callin= g out that the update operation is atomic and provided a definition<= u>
  6. Section 4.6.1: Explained in more detail how eac= h node is marked as in conflict which covers the discussed use-case of serv= ers deciding to call update themselves (without client prompting)
  7. Added an upd= ated NMDA diagram to visually explain how the solution fits into NMDA
  8. <= span style=3D"font-size:11pt">Various grammatical enhancements

= =C2=A0

W= e look forward to further discussion.

=C2=A0

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

= =C2=A0

H= igh-level comments:

= =C2=A0

-= I wonder if Section 3 is needed, or perhaps it could reduced to a paragrap= h in the Introduction? =C2=A0 =C2=A0Generally I don=E2=80=99t think specs s= hould provide a lot of motivating justification...

= =C2=A0

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

= =C2=A0

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

=C2=A0

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

= =C2=A0

-= Regarding Section 4.4.2, given the previous comment, I=E2=80=99m opposed t= o a client-sent capability having a significant role.<= /p>

= =C2=A0

[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.=C2=A0 What=C2=A0the above=C2=A0comment boils down to is whether=C2=A0the WG feels=C2=A0<= /span>a client should be able to select between private-candidates and shar= ed-candidates on a session-by-session basis.=C2=A0 If we feel they should (= as they can in NMDA by targeting a specific datastore) then the current approach is probably the right one.=C2=A0 If we feel that a client should = not be able to select between private and shared candidates on a per-sessio= n basis, then the alternative is to allow a server to specifically select a= mode (perhaps in config but =E2=80=98how=E2=80=99 would be out of scope for the document) that is present for the lifetime of that= choice=E2=80=A6 i.e. if a server implements private candidates a non-NMDA = client will always get private-candidates and never be able to target the s= hared candidate.]

= =C2=A0

R= egarding Section 4.3, I don=E2=80=99t understand why there is a difference.= =C2=A0 Please make the solutions the same so that, e.g., an RC server can b= e built on top on an NC server, and vice versa.=C2=A0 BTW, why destroy the private candidate at all, can't each user have their o= wn perpetually?=C2=A0 Does it matter?

= =C2=A0

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

=C2=A0<= /u>

Why= is there a difference?=C2=A0 It is a natural approach in NETCONF to tie th= e candidate to the NETCONF session ID for a few reasons.=C2=A0 Firstly, thi= s is communicated clearly at the start of each session and a session on a router is tied to it (at l= east in the implementations I have seen).=C2=A0 The NETCONF spec delineates= nicely between the transport layer (e.g. SSH) where the authentication (an= d the ties to the user are handled) and the NETCONF protocol layer.=C2=A0 Blending these seemed unnatural.=C2=A0 O= ur 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 can= didate to,=C2=A0= therefore at the suggestion of the WG we selected the client identity (ie the RESTCO= NF username).=C2=A0 I note that you say RC can rely on NC.=C2=A0 I=E2=80=99= m not sure if this is implementation specific or spec described so any guid= ance is welcome.

=C2=A0<= /u>

Why destroy the private-candidate at all?=C2=A0 If the private-can= didate is tied to the NETCONF session ID then closing of this session would= destroy this candidate.=C2=A0 Leaving it in place would just bloat the memory usage in a node.=C2=A0 Thi= s is based of my answer for why we are attaching it to the session-id rathe= r than the username.=C2=A0 In RESTCONF we could choose not to destroy the p= rivate-candidate at all, but this would lead to significant memory overhead, for example 5000 users would have 5000 cop= ies of running (as according to the spec a candidate is a full copy, althou= gh implementations may not implement it this way).=C2=A0 Another issue is t= hat over time the probability of a private candidate being out of date is very high, therefore, any workflow would re= quire a client to do an update immediately on starting the session in order= to get the config back in sync.

=C2=A0

Does it matter?=C2=A0 To answer this question in both cont= exts=E2=80=A6. Does it matter that there is a slightly different implementa= tion for NETCONF and RESTCONF?=C2=A0 I don=E2=80=99t think so, they are functionally very similar in the key parts of the draft.=C2=A0 Does it= matter whether a candidate is destroyed at all?=C2=A0 Yes, in order to ens= ure optimal memory management of a node over a significant period of time (= that may have a significant number of users).]

=C2=A0

J= ames and Rob

<= br> Kent // contributor

= =C2=A0

[Thanks Kent! We hope to have a -04 for the WG to review p= rior to IETF120]<= u>

= =C2=A0

=C2=A0<= /span>

=C2=A0<= /span>

From: Kent Watsen <kent+ietf@watsen.net>
Date: Thursday, 13 June 2024 at 23:05
To: James Cumming (Nokia) <james.cumming@nokia.com>
Cc: netconf@ie= tf.org <netcon= f@ietf.org>
Subject: Re: [netconf] Private candidates -03 and points for discuss= ion

=C2=A0

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.

=C2=A0

Hi James,

=C2=A0

=C2=A0

On May 30, 2024, at 3:36=E2=80=AFPM, James Cumming (Nokia) <james.cummin= g=3D40nokia= .com@dmarc.ietf.org> wrote:

=C2=A0

G= ood morning/evening everyone,<= u>

= =C2=A0

T= he authors/editors of the private candidates draft have just published a ne= w -03 version of the draft (https://datatracker.ietf.org/doc/draft-ietf-netconf-privcand/)=C2=A0which we believe address the comments from the last (couple of) IETF meetings.

= =C2=A0

W= e would like to invite everyone to review the draft and provide any feedbac= k.

= =C2=A0

W= hilst addressing the points raised, a few other issues were identified and = we have proposed solutions to these in the draft as well.

= =C2=A0

H= ere is a summary of the changes in no particular order:

= =C2=A0

  1. Added Andy Bierman as a contributor
  2. Section 4.7.2.11.1: Identified that commit-confirmed behaviour was un= clear so provided some detail on how this should work with private candidat= es (and confirming that it is supported).=C2=A0 We considered how to deal with confirmed comm= its that expire their timer or are cancelled.=C2=A0 We also considered whet= her alternate sessions should be able to cancel them.<= /li>
  3. Added the YANG models to the draft as requested.=C2=A0 This l= ed us to a procedural question.=C2=A0 This draft is meant to operate for NM= DA and non-NMDA capable servers.=C2=A0 It is also adding a new base operation (update) and has some additive chan= ges to other older YANG models.=C2=A0 The discussion here is what the proce= dure should be for this.=C2=A0 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.=C2= =A0 We did discuss the option to do augmentation rather than updates but th= is feels fairly awkward for clients given the base operation and the additi= onal datastore identity.=C2=A0 The approach we have in the draft (currently) also follows the suggestion given to anot= her draft last meeting that was also looking to add new items to a base YAN= G model.=C2=A0 This approach is certainly common for drafts without embedde= d YANG models.

=C2=A0

I don=E2=80=99t understand the =E2=80=9Cawkward for = clients=E2=80=9D comment.=C2=A0 I am surprised to see "ietf-netconf=E2= =80=9D, =E2=80=9Cietf-datastore=E2=80=9D, and "ietf-nmda-compare"= being published by this I-D. =C2=A0 It seems that augments would work fine= .

=C2=A0

Regarding=C2=A0ietf-netc= onf, RFC 6241=E2=80=99s only noteworthy =E2=80=9Cupdate=E2=80=9D is = by RFC 8526 (NMDA for NETCONF) which defines two new operations and =E2=80= =9Caugments=E2=80=9D in the =E2=80=9Cdatastore=E2=80=9D parameter into a nu= mber of existing RPCs. =C2=A0

=C2=A0

Regarding ietf-datastore, note that =E2=80=9Cidentit= y=E2=80=9D statements were used in part to enable new declarations to occur= outside RFC 8342 (NMDA).=C2=A0 For example, this is what the =E2=80=9Csyst= em-config=E2=80=9D draft has:=C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-= 06#name-yang-module

=C2=A0

Can you remind me, what was the=C2=A0other draft las= t meeting that was also looking to add new items to a base YANG model?

=C2=A0



  1. =C2=A0
  2. Updated the RFC list th= at this draft updates

=C2=A0

One of the RFCs listed is RFC 8526, but the string = =E2=80=9C8526" isn=E2=80=99t found anywhere else in the draft...

=C2=A0

When =E2=80=9Cupdating=E2=80=9D an RFC, it is custom= ary to have a paragraph or section (called =E2=80=9CUpdates to RFC XXXX=E2= =80=9D) in the Introduction that provides details.=C2=A0 For instance,=C2= =A0https://datatracker.ietf.org/doc/html/rfc8526=C2=A0uses paragraphs while https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-06#na= me-introduction=C2=A0uses sections.

=C2=A0

BTW, should this draft also =E2=80=9Cupdate" RF= C 8342, for the same reasons as the system-config draft?

=C2=A0



  1. =C2=A0
  2. Section 4.6.1: Made the= =E2=80=98what constitutes a conflict=E2=80=99 section explicit with a mini= mum set of requirements
  3. Section 4.6.1: A= dded scope for servers to add additional requirements to conflict detection= mechanisms beyond the minimum set (which are mandatory).=C2=A0 Transaction ID is explicitly mentioned as one such example here.<= /li>
  4. Section 4.7.2.9<= /a>: Identified the delete-config operation needed updating as well so prov= ided a solution for this
  5. Section 4.7.1.1: Added a statement callin= g out that the update operation is atomic and provided a definition<= u>
  6. Section 4.6.1: Explained in more detail how eac= h node is marked as in conflict which covers the discussed use-case of serv= ers deciding to call update themselves (without client prompting)
  7. Added an upd= ated NMDA diagram to visually explain how the solution fits into NMDA
  8. <= span style=3D"font-size:11pt">Various grammatical enhancements

= =C2=A0

W= e look forward to further discussion.=

=C2=A0

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

=C2=A0

High-level comments:

=C2=A0

- I wonder if Section 3 is needed, or perhaps it cou= ld reduced to a paragraph in the Introduction? =C2=A0 =C2=A0Generally I don= =E2=80=99t think specs should provide a lot of motivating justification...<= u>

=C2=A0

- Regarding Section 4.4.1, the go-to solution these = days is to use YANG Library.=C2=A0 Capabilities are only maintained for leg= acy clients.=C2=A0 FWIW, I suspect that a NETCONF 2.0 would eliminate the &= lt;hello> messages. =C2=A0<= /u>

=C2=A0

- Regarding Section 4.4.2, given the previous commen= t, I=E2=80=99m opposed to a client-sent capability having a significant rol= e.

=C2=A0

Regarding Section 4.3, I don=E2=80=99t understand wh= y there is a difference.=C2=A0 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.=C2= =A0 BTW, why destroy the private candidate at all, can't each user have their own perpetually?=C2=A0 Does it matter?<= /p>

=C2=A0



J= ames and Rob


Kent // contributor

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
netconf mailing list -- netconf@ietf.org
To unsubscribe send an email to netconf-leave@ietf.org
--00000000000099c991061bd1b0c5--