I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

To support multiple clients making configuration changes concurrently, this document defines NETCONF private Candidate Datastore and corresponding NETCONF/RESTCONF protocol operations on Private Candidate Datastore, specially conflict detection and resolution have been specified.

This document is on the right track. However I have the following comments and suggestions which help improve:

Major issues:
None

Minor issues
1. Introduction section
The problem statement in the introduction section lacks clarity, also it is not clear how problem described in section 1 is related to section 3, suggestion consolidated section 3 with section 1 to have a better problem statement.

2. Introduction section said:
“
Many network devices support candidate configurations within the CLI interface, where a user (machine or otherwise) is able to edit a self-contained copy of a device's configuration without blocking other users from doing so.
”
Similar to the previous paragraph, is there any side effect to use CLI to operate on candidate configuration? Also in the following paragraph, it said:
“
This document specifies the extensions to the NETCONF protocol in order to support the use of private candidates. It also describes how the RESTCONF protocol can be used on a system that implements private candidates.¶
”
Why private candidates are needed? Is this becos the limitation of using shared candidate datastores, it looks it suddenly jumps into protocol definition for new datastore.

3. Section 1.3 and section 4.7.2.7
I feel <compare> operation on private candidate datastores is not part of this document, since compare operation on private candidate datastore is used to  compare the same datastore with two different time point, RFC9144 is not sufficient to support this operation, in addition, you also need to support checkpoint-based configuration backup and recovery at the datastore level. See YANG model snippet:
“
            default last-update;
            type enumeration {
                enum last-update;
                enum creation-point;
            }
”
Private candidate at last update time point or at the creation point time point might not exist without YANG data model for checkpoint-based configuration backup and recovery. I remember this has been discussed before in NETMOD mailing list.

4. Section 6 Security section
YANG security guideline defined in https://wiki.ietf.org/group/ops/yang-security-guidelines
Is not followed.

5. Section 2.3
Section 2.3 is defined what private candidate is about. Suggest to follow the guidelines for defining datastores in Appendix A of [RFC8342] and have a separate section, RFC8808 provides an example on factory datastore.

6. Section 2.1, Section 2.2, section 2.3
Suggestion to follow the style of section 1.1 of RFC8808, distinct existing term from new term and make a short definition for new term “private candidate datastore” as well.