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

-----邮件原件-----
发件人: Netconf [mailto:netconf-bounces@ietf.org] 代表 Ladislav Lhotka
发送时间: 2018年9月26日 20:40
收件人: Martin Bjorklund
抄送: netconf@ietf.org
主题: Re: [Netconf] {+restconf}/data vs <running>

On Wed, 2018-09-26 at 14:24 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > 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.
> 
> 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

[Qin]: Clone operation is similar to HTTP GET, but requires downloading and create a local copy in the client side,
I am wondering why not create private area in the running datastore of the server side?
> 
> 
> 
> /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
> > > > > > 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
> > 
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf