Subject: Re: [netmod] draft-schoenw-netmod-revised-datastores-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Jun 2016 14:53:29 +0200

On Fri, Jun 10, 2016 at 12:45:17PM +0100, Jonathan Hansford wrote:
> Juergen,
> 
> Page 6
> s/have proprietary mechanism/have proprietary mechanisms
> 
> Page 9
> s/in a configuration datastores/in a configuration datastore
> s/An example are/An example is

Thanks.
 
> Section 6.2
> I have not been following developments with RESTCONF, but could the “content” query parameter also be used to allow writes to datastores other than running?

Perhaps it could be extended in this way but I am not sure this is
what the designers had in mind.

> This is not central to the purpose of the document, but on page 5
> you state “the <startup> datastore can only be modified by copying
> <running> to <startup> in NETCONF”. If you wanted to startup
> datastore to differ from the running datastore (e.g. you needed to
> make changes to the running datastore but didn’t want those changes
> to persist beyond a restart or you wanted to make changes that would
> only apply after a restart) couldn’t you copy the startup datastore
> to the candidate datastore, make the changes then copy the candidate
> back to the startup?

The regular <commit> copies the content of the candidate datastore to
the <running> datastore. Note that validation happens during the
commit. So the standardized commit model is really <candidate> to
<running>. That said, in principle <copy-config> could be used to copy
<candidate> to <startup> but then this is not clearly defined (e.g.,
it is not spelled out that validation should happen in this case much
as in the commit case; I think a silent assumption is that
<copy-config> assumes to copy valid datastore content - and the
content of <candidate> may be invalid. Similarly, the
<discard-changes> operation really is at a semantic level a copy of
<running> to <candidate> (of course an implementation may not do a
full copy). So yes, an implementation may support other editing models
but given the way the RFC is written, I think you can't rely on other
editing models to be supported and to work in an interoperable way.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>