Re: [Netconf] {+restconf}/data

[Andy Bierman <[e-mail]>]

Hi,

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

Andy


On Thu, Jul 19, 2018 at 2:27 PM, Ladislav Lhotka <[e-mail]> wrote:

> 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
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>