Re: [Netconf] {+restconf}/data

[Ladislav Lhotka <[e-mail]>]

On Thu, 2018-07-19 at 13:58 -0700, Andy Bierman wrote:
> 
> 
> On Thu, Jul 19, 2018 at 1:53 PM, Ladislav Lhotka <[e-mail]> wrote:
> > Juergen Schoenwaelder <[e-mail]> writes:
> > 
> > > 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.
> > 
> > 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).
> > 
> > > 
> > > 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).
> > 
> > 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.
> > 
> 
> 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.

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.

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

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

Lada

> 
> 
>  
> > Lada
> > 
> 
> Andy
>  
> > > 
> > > /js
> > > 
> > > On Wed, Jul 18, 2018 at 03:45:10PM -0400, Ladislav Lhotka wrote:
> > > > 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
> > > > 
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > 
> > > -- 
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67