Re: [netconf] Adoption poll for draft-jgc-netconf-privcand-02

["maqiufang (A)" <[e-mail]>]

Hi, Kent, all

I have read the current version of the document and support the adoption of this work.

It is a useful work, the conflict detection and resolution look good to me, but I do have a couple of comments elsewhere, some of which might need more discussion:


1.       Private candidate solution for RESTCONF protocol

The current document states the private candidate used by RESTCONF exists only for the duration of the RESTCONF request, and any changes made to the private candidate datastore will be immediately committed to running. It is similar to 8040, but I think this doesn’t make much sense to introduce private candidate to RESTCONF. I don’t really understand what extra value private-candidate brings for RESTCONF protocol.

There seems to be a desire to allow some mechanisms in NC also work in RC, does this mean that it is desirable for RC to also hold the configuration in private candidate and commit to the running whenever it’s ready?


2.       Collectively supporting of both shared candidate and private candidate

The proposed solution requires the server to declare both the support for private candidate and the shared candidate capability to use the private candidate datastore, and the client also needs to send the private-candidate capability to enable the private candidate mode.

But it seems to me that if a server supports private-candidate, there is no need for it to maintain a shared candidate datastore any longer.  Any client can still use the “candidate” target in the edit-config/edit-data operation, but the configuration modification is actually made to the private candidate datastore by the server.

A client receiving the private candidate capability in server’s <hello> message, understands that the candidate datastore is now exclusive and a <lock> towards it is no longer needed, the legacy client if not understanding the private candidate capability can still simply behave the same way and lock the private candidate but this is no harm. Make sense?


3.       Missing YANG model

The document defines a new operation named <update> and augments the <compare> RPC operation defined in RFC 9144 to allow the client specify a historical private candidate, but I don’t see the related RPC definition and augmentation.


4.       Sec.4.6.2.2 <lock> and <unlock>

“Performing a <lock>/<unlock> on the private-candidate datastore is a valid operation. This will also lock/unlock the running configuration.”

Any consideration for the <lock>/<unlock> operation to perform on the both private-candidate and running datastores? This is inconsistent with 6241. NETCONF defines if the client specifies candidate datastore to be locked, then only candidate datastore is locked. I am not sure it is a good practice to change the lock behavior in this document.

It seems that there is no need for a client to lock the private candidate datastore, but it is okay. If that happens, a server could just do nothing.

Best Regards,
Qiufang

From: netconf [mailto:[e-mail]] On Behalf Of Kent Watsen
Sent: Tuesday, August 15, 2023 5:14 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [netconf] Adoption poll for draft-jgc-netconf-privcand-02


All,

This is start of a two week poll on making https://datatracker.ietf.org/doc/html/draft-jgc-netconf-privcand-02 a working group document.  Following up of the presentation and polls from the 117 session, please note that in-room poll indicated strong support for this work, though not many had read the current version of the draft.

Please send email to the list indicating "yes/support” or "no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

The poll ends August 28.

Kent and Mahesh (as co-chairs)