Re: [Netconf] {+restconf}/data vs <running>

On Wed, 2018-09-26 at 13:32 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Wed, 2018-09-26 at 13:04 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > Hi,
> > > > 
> > > > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > > > between the {+restconf}/data and the <running> datastore, and it cannot
> > > > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > > > 
> > > >    This mandatory resource [{+restconf}/data] represents the combined
> > > >    configuration and state data resources that can be accessed by a
> > > >    client.
> > > > 
> > > > I think this is a serious omission.
> > > 
> > > draft-ietf-netconf-nmda-restconf doesn't change {+restconf}/data.  It
> > > works as before.  See RFC 8040 section 1.4 for relationship to
> > > <running>.
> > 
> > Sec. 1.4 is about coexistence with NETCONF, whereas draft-lhotka-netconf-
> > restconf-transactions facilitates the use of RESTCONF *without* NETCONF.
> 
> As I wrote in my reply to the adoption poll, I think that a staging
> datastore would be useful also for NETCONF.  As such, I think it would
> be unfortunate to do a solution that is just for RESTCONF, and even
> worse, doesn't work if the RESTCONF server is co-located with a
> NETCONF server.

Section 1.4 assumes only two options for client's edits: either to <running>
(with :writable-running) or to <candidate>. The staging datastore adds a new
option that is essentially incompatible with those two.

I support adding the staging datastore to NETCONF as well but the datastore
relationships need to be clarified. Specifically, I don't see any reason why
sec. 1.4 of RFC 8040 cannot be updated to say:

   Otherwise, if the device supports :staging, all edits to
   configuration nodes in {+restconf}/data are performed in the
   staging configuration datastore.

Lada

> 
> > > > Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> > > > lot of criticism for changing the semantics of
> > > > {+restconf}/data. However, I don't think it was the case: according to
> > > > the above definition, it seems perfectly OK if {+restconf}/data
> > > > represents combined configuration **from <staging>** and state data.
> > > 
> > > This would violate section 1.4 of RFC 8040, at least if the RESTCONF
> > > server is co-located with a NETCONF server.
> > 
> > In fact, the use of the staging datastore makes sense only if <running> is
> not
> > writable and <candidate> not supported (or not used, at least). Moreover,
> > NETCONF server needn't be present at all.
> 
> 
> /martin
> 
> 
> > 
> > Lada 
> > 
> > > 
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > > 
> > > > Lada
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67