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

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2018 12:45:26 +0200

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.

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.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2018 12:58:13 +0200

> I think this is a serious omission.

We are not changing {+restconf}/data.
 
> represents combined configuration **from <staging>** and state data.

Perhaps people had the impression that your proposal changes
{+restconf}/data or that it should work with the NMDA solution.

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Sep 2018 13:04:00 +0200 (CEST)

> 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>.

> 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.

/martin

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2018 13:10:53 +0200

> We are not changing {+restconf}/data.

My point is that it is unclear what {+restconf}/data really is: "the combined
configuration and state data resources" is too vague given that several
configuration datastores may be present.

> {+restconf}/data or that it should work with the NMDA solution.

I am arguing that I did NOT change {+restconf}/data, I just made its definition
more precise.

If configuration resources under {+restconf}/data are expected to be identical
to those under {+restconf}/ds/ietf-datastores:running, then draft-ietf-netconf-
nmda-restconf should say so.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2018 13:25:04 +0200

> works as before.  See RFC 8040 section 1.4 for relationship to

Sec. 1.4 is about coexistence with NETCONF, whereas draft-lhotka-netconf-
restconf-transactions facilitates the use of RESTCONF *without* NETCONF.

> 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.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Sep 2018 13:32:42 +0200 (CEST)

> 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.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2018 14:02:19 +0200

> worse, doesn't work if the RESTCONF server is co-located with a

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Sep 2018 14:24:50 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> relationships need to be clarified.

Agreed.

> Specifically, I don't see any reason why

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.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2018 14:39:36 +0200

> 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

> > > > In fact, the use of the staging datastore makes sense only if <running>
> is
> > > not

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2018 14:43:27 +0200

> configuration datastores may be present.

Well, {+restconf}/data is whatever RFC 8040 says it is. We are not
changing it. If you want to interact with an NMDA datastore, then
there is a defined way to do so.

> I am arguing that I did NOT change {+restconf}/data, I just made its
> definition more precise.

Making something more precise may be seen by others as changes. Within
the NMDA work, we quickly discovered that the only backwards
compatible way to introduce NMDA to RESTCONF is to expose NMDA
datastores as new resources instead of trying to give an existing
resource a different meaning.
 
> If configuration resources under {+restconf}/data are expected to be
> identical to those under {+restconf}/ds/ietf-datastores:running,
> then draft-ietf-netconf- nmda-restconf should say so.

NMDA does not say what {+restconf}/data is because RFC 8040 defines
what {+restconf}/data is. Among other things, RFC 8040 says this:

      By default, RESTCONF
      methods access a unified view of the underlying datastore
      implementation on the server.

So {+restconf}/data is most likely not the same as
{+restconf}/ds/ietf-datastores:running.

/js

---

From: Qin Wu <[email-masked]>
Date: Thu, 27 Sep 2018 03:44:25 +0000

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

On Wed, 2018-09-26 at 14:24 +0200, Martin Bjorklund wrote:
> > > > > > draft-ietf-netconf-nmda-restconf is silent about the 
> > > > > > relationship between the {+restconf}/data and the <running> 
> > > > > > datastore, and it
> cannot
> > > > > 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-
> > > 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:
> > 

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
> > > > > > {+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.
> > > >