Re: [Netconf] {+restconf}/data

On Thu, Jul 19, 2018 at 1:53 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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.

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

> >
> > /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
> >> Netconf@ietf.org
> >> 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/>
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>