[netconf] Re: WGLC for privcand-06

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

Hi, all,



I've spent some time reviewing this document, and I feel that this document needs further improvements through 1-2 additional revisions. Hopefully some comments below could help (sorry I didn’t check the comments for duplication with Rob’s review):



Some high-level moderate issues I see:

1.       The abstract states that the private candidate solution is applicable to both NETCONF and RESTCONF protocol. But the title is "NETCONF private Candidates", should the title be aligned?



  1.  The document requests to update 6241, 8342, 8526, 9144, but please remove 8342, I didn’t find any updates to NMDA throughout the document.


3.       I am unsure if section 3 (Limitations using the shared candidate configuration for multiple clients) is really needed, or would it make sense for this section to be moved inside introduction sec.?



4.       Please add a forward reference if any concept mentioned in the earlier part of the text will be explained in detail later, I would also expect an explicit section instead of the statement “more details on this later in this document”.



5.       I am not convinced that this draft has no security considerations.

Some security matters in my mind, e.g., access control management for private candidate to prevent unauthorized users access to private candidate. An attacker could attempts to exhaust server resources by establishing a large number of sessions with the server and creates private candidate datastores continuously.

You should also provide the security consideration for the YANG module following rfc8407bis guideline.



6.       Please register the YANG module in the "IETF XML" and "YANG Module Names" registry in IANA considerations. I like the way for the yang module to be defined in the normative sections, instead of appendix section. For compare RPC augmentation, I think you should add a when statement and states that this parameter is only available when the source or target is a candidate datastore.





There are also some parts in the draft that I feel lack clarity or not accurate enough:

1.       Sec.2.1 "A session specific datastore is a configuration datastore that,
   unlike the candidate and running configuration datastores which have
   only one per system, is bound to the specific NETCONF session."


                s/candidate/shared candidate/.  Or maybe startup?



2.       Sec2.3. " Any changes made to it, for example, through the use of operations such
   as <edit-config> and <edit-data>, are made in this private candidate
   configuration. "

I am unsure what this sentence tries to convey, as I though “it” already refers to private-candidate. I think maybe what you refer to is "any changes made to "candidate" target datastore, through the use of operations such as <edit-config> and <edit-data>, are made in this private candidate configuration datastore."


3.       Sec.2.3., "All changes made to this private candidate configuration are held
   separately from any other candidate configuration changes, whether
   made by other users to the shared candidate or any other private
   candidate, and are not visible to or accessible by anyone else."

Is it possible for the server to support private candidate and shared candidate simultaneously?
If the server supports private candidate, all configuration changes targeting "candidate" are made to private candidate, then how does it possible for a client to write something into shared candidate?


4.       Sec.4. "Additionally, the choice of using a shared candidate configuration

4.   datastore or a private candidate configuration datastore MUST be for

4.   the entire duration of the NETCONF session."


I am unsure how clients can make any choice between using a shared configuration datastore or a private candidate datastore. If the server supports private candidate, then it should use private candidate for the  client, otherwise just use the shared candidate.


5.       Is sec.4.4.1 also applicable to RESTCONF server? As I think the RESTCONF capability identifier usually starts with "urn:ietf:params:restconf".


6.       Sec.4.4.1   "As support for the shared candidate configuration datastore is a pre-

6.   requisite for the private candidate functionlity, a server MUST also

6.   advertise the :candidate capability as defined in [RFC6241]."



s/functionlity/functionality/

I am unsure I agree with the first half of this sentence, i.e., support for the shared candidate configuration datastore is a pre-requisite for the private candidate functionality. If an implementation supports private candidate already, then every session uses its own candidate, I don't think there is a need to also support a shared candidate, as no one would use it if they have their own private candidate. Could this be reworded?



7.       Sec.4.5.

“A <compare> [RFC9144] operation MAY be performed against:

     *  The initial creation point of the private candidate's branch

     *  Against the last update point of the private candidate's branch

     *  Against the running configuration”



I feel lost when I first read this. I guess you could either remove this part or make it clearer. The origin <compare> RPC must have both a source and a target datastore for the comparison, you should be clear how the RPC is augmented.



8.       Sec.4.6.1

“A conflict is when the intent of the client may have been different had it had a different starting point.”

This doesn’t feel like the right definition for a conflict.



“A server MAY choose to add additional checks over and above the above list.”

Remove "and above".



9.       Sec.4.7.2.1.1

"When a private candidate is committed using the <confirmed/> parameter and the commit operation disconnects the client's session,"



Note you also have Sec4.3 that states that "Issuing a <commit> operation will not close the private candidate but will issue an implicit <update> operation resyncing changes from the running configuration. "

Is this contradictory?



10.   Sec.4.7.2.1.1

I think the draft should also be clear:

·         what happens if client 1 has issued a confirmed <commit> and then another client has issued a follow-up confirmed <commit> operation before the time expires?

·         What if the <persist> is given in the confirmed commit, and another client gives a follow-up confirming commit?

Could these be clarified?

Best Regards,
Qiufang