[netconf] draft-ietf-netconf-privcand private candidate | Implicit <update> before a <commit>

[[e-mail]]

Hello there. In June James C. one of the author on this draft invited me to
read it and contribute, so here I am.

 

I will send my questions and remarks one by one in different e-mails (I have
about 9 of them). I am pretty available this week and the next one.

 

When I first read the draft, I was puzzled by the source code management
(SCM) systems analogies, stating that the NETCONF <commit> was like a SCM
merge. Only later did I read that, in this draft the <commit> operation is
different from RFC6241: an implicit <update> is issued first. 

 

This major <commit/> change appears first in the 4.3 section. It also
appears in 4.7.2.11 and in a few other places. This is also briefly
mentionned in 1.2 that <commit> is augmented without details.

 

To me, this change is quite important, and should be mentionned sooner and
made clearer in the draft.

 

I propose one change, in section 2.3:

 

"Obtaining this private candidate over NETCONF or RESTCONF will display the
entire configuration, including all changes made to it. Performing a
<commit> operation will merge the changes from the private candidate into
the running configuration (the same as a merge in source code management
systems). A <discard-changes> operation will revert the private candidate to
the branch's initial state or it's state at the last <commit> (whichever is
most recent)."

 

could be augmented by (copying from 4.3):

 

"Obtaining this private candidate over NETCONF or RESTCONF will display the
entire configuration, including all changes made to it. A <discard-changes>
operation will revert the private candidate to the branch's initial state or
it's state at the last <commit> (whichever is most recent).

Performing a <commit> operation will merge the changes from the private
candidate into the running configuration (the same as a merge in source code
management systems). This merge is done in two steps : first an implicit
<update> operation is issued, resyncing changes from the running
configuration into the private candidate (more details on this later in this
document), and then the running configuration is replaced by this updated
private candidate. In that sense, the private candidate <commit> operation
as described in this document is different from the simpler <commit>
operation as defined in [RFC6241] (which is equivalent to a simple
copy-config operation)."

 

And shorter alternative would be to underline that the <commit> operation is
different from RFC6241 and point to 4.2.7.11.

 

What do you think?

 

Best regards,

Dylan Sadoun 

 

Orange Restricted