Early Review of draft-ietf-netconf-privcand-06
review-ietf-netconf-privcand-06-opsdir-early-wu-2025-04-24-00

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.