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

[Ladislav Lhotka <[e-mail]>]

On Wed, 2018-09-26 at 14:24 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka <[e-mail]> wrote:
> > On Wed, 2018-09-26 at 13:32 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka <[e-mail]> wrote:
> > > > On Wed, 2018-09-26 at 13:04 +0200, Martin Bjorklund wrote:
> > > > > Ladislav Lhotka <[e-mail]> 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.
> 
> Agreed.
> 
> > 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.
> 
> But your draft also requires the client to send an additional "commit"
> rpc, which means that an old client that communicates with a server
> that happens to implement staging won't work as expected.

This is true. One way to work around this (Rob's suggestion) is to require the
user to explicitly start the "staging mode" with an operation (such as "clone"
or "checkout"). Until then, all edits would be as specified in Sec. 1.4.

Lada

> 
> 
> 
> /martin
> 
> 
> 
> > 
> > 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
> > > > > > [e-mail]
> > > > > > 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
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67