Subject: [Netconf] {+restconf}/data

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Jul 2018 15:45:10 -0400

Hi,

it seems that using RESTCONF with the updated NMDA-compatible modules
leads to the (IMO undesirable) result where under the "legacy" root
"{+restconf}/data" state data are mixed with configuration. For example,
with ietf-interfaces@2018-02-20

GET {+restconf}/data/ietf-interfaces:interfaces

yields configuration, state data and statistics, whereas with the old
revision ietf-interfaces@2014-05-08 GET on the same URL yields only
configuration. I think this defeats the purpose of NMDA.

On the other hand, the short datastore-less URLs are too handy to be
simply deprecated. I would therefore propose that {+restconf}/data be
essentially an alias for the configuration datastore that the user can
directly edit. This means:

- with writable <running> it will be an alias to running

- if the implementation uses <candidate>, it will be an alias to
  <candidate>.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jul 2018 10:41:56 +0200

Lada,

there is no point in changing the definition of {+restconf}/data since
this would lead to interoperability issues and hence {+restconf}/data
remains what it is.

Yes, the new datastore names are longer but we did not want to require
globally unique datastore names (which would require some form of a
registry and that everybody uses the registry).

/js

On Wed, Jul 18, 2018 at 03:45:10PM -0400, Ladislav Lhotka wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Jul 2018 16:53:01 -0400

> this would lead to interoperability issues and hence {+restconf}/data

Clients can have interoperability issues already now, e.g. if the server
upgrades to the new "ietf-interfaces" module:

- it can receive loads of unexpected state data and statistics

- no data may be available under "interfaces-state" (because of the
  ambiguity of the deprecated status).

> registry and that everybody uses the registry).

Most of the text in RFC 8040 deals with the {+restconf}/data resource
and its descendants, so effectively deprecating it in another document
seems pretty confusing. I think that {+restconf}/data should remain the
main entry point to configuration for an average client.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jul 2018 13:58:38 -0700

> main entry point to configuration for an average client.
I agree with Juergen.
You cannot change the usage of /restconf/data.
Old clients will expect the old behavior and break if a new server did this.

There is no reason to deprecate or change this URI.
Pick a new URI for new functionality.
This is much less confusing and it does not break old clients.

> Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Jul 2018 17:27:53 -0400

> Old clients will expect the old behavior and break if a new server did this.

What is "the old behavior" and how would it change with my proposal? The old
resources and their URIs continue to exist, clients can use the same methods as
before, only the returned data may be different. As my example with "ietf-
interfaces" demonstrates, this happens already when this module is upgraded to
the NMDA-compatible revision.

As a matter of fact, with my proposal the returned data would be exactly the
same as with the old version of "ietf-interfaces" - only configuration.

> This is much less confusing and it does not break old clients.

But {+restconf}/data is essentially equivalent to <get> output in NETCONF, and
this is what we wanted to get rid of.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jul 2018 15:33:47 -0700

Hi,

I think people should use the new NMDA URIs if they want different behavior
than RFC 8040.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Jul 2018 01:31:28 +0200

On Thu, Jul 19, 2018 at 05:27:53PM -0400, Ladislav Lhotka wrote:
> 
> What is "the old behavior" and how would it change with my proposal?
> The old resources and their URIs continue to exist, clients can use
> the same methods as before, only the returned data may be
> different. As my example with "ietf-interfaces" demonstrates, this
> happens already when this module is upgraded to the NMDA-compatible
> revision.

The ietf-interfaces module got updated and more nodes were added into
the tree. This is a rather normal procedure. (There never was a
requirement that config/state trees had to be split - this was just
the best thing we could do originally for ietf-interfaces.)

Clients only interested in config nodes can use the "content" query
parameter with the value "config" (RFC 8040 section 4.8.1). If clients
use the default "all", well then they get all.

/js