Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04

[Andy Bierman <[e-mail]>]

On Mon, Feb 12, 2018 at 6:37 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
>
> > > > **** Sec. 1 - YANG library stability
> > > >
> > > >      The text basically says that the YANG library information can
> > > >      change at any time. This has been recently discussed but I
> > > >      haven't seen any conclusion yet. I understand it is difficult to
> > > >      enumerate all the situations when this information can change,
> > > >      but it should also be emphasized that YL info is not just
> another
> > > >      subtree of state data and that it should not change haphazardly.
> > >
> > > I agree, but I think that YANG library's job is to report what the
> > > server implements.  If the server dynamically changes its set of
> > > loaded modules, then YL should adapt.
> > >
> > > I welcome more discussion on this topic, but I don't think it has to
> > > be documented in this draft.
> >
> > What about this?
> >
> > OLD
> >    The YANG library information can be different on every server and it
> >    can change at runtime or across a server reboot.  If a server
> >    implements multiple network management protocols to access the
> >    server's datastores, then each such protocol may have its own
> >    conceptual instantiation of the YANG library.
> >
> > NEW
> >    The YANG library information represents a management API for a given
> server,
> >    and should therefore be as stable as possible. The circumstances
> under which
> >    this information can change are outside the scope of this document
> but it is
> >    advisable to consider potential impact on clients.
>
> I like the old text because it tells the client clearly that this data
> can change. And the statement has been in RFC 7895 in the exact same
> wording. If you want to add a statement that servers should not change
> the YANG library without reason I could live with that but any attempt
> to write text that makes the server somewhat guilty when a client is
> not prepared to handle a YANG library change is IMHO a fundamental
> change from what RFC 7895 said.
>
>
I strongly oppose changing this text.
Any server that can load or unload modules at run-time can change
the YANG library at run-time.


Andy


> > > >      It is like with database schemas, REST APIs and the like. Of
> > > >      course, these can change as well, but everybody has to
> understand
> > > >      that doing so means transition problems, broken clients etc.
> > > >
> > > >      For this reason, it might be useful to set YL and schema mount
> > > >      data aside and call them metadata or schema information - even
> if
> > > >      we continue modelling them with YANG.
> > >
> > > Do you have some concrete proposal for where to introduce this term?
> >
> > In RESTCONF it could be a separate well-known resource outside all
> datastores.
>
> Putting the data into a different place does not change the impact of
> the data changing. So I do not understand which problem introducing
> yet another datastore solves.
>
> > > > **** Sec. 4 - checksum
> > > >
> > > >      I think it would be very useful (even if not immediately) to
> > > >      standardize the procedure for computing the checksum. What I
> > > >      envision are systems that construct and process YANG schemas
> > > >      (such as the YANG Catalog). They could benefit from having a
> > > >      universal hash string as a characteristic of any particular
> > > >      schema. Just consider how useful the universal hashes are e.g.
> in
> > > >      git.
> > >
> > > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > > not needed immediately for this document.
> >
> > Checksums are mandatory, so every implementation has to invent some
> scheme.
> >
> > Actually, it might be useful to have checksums also on module-sets,
> schemas and
> > datastores so that the client can easily localize the changes and
> retrieve again
> > only necessary data.
>
> With RESTCONF, you can use etags and conditional requests. NETCONF
> lacks a similar generic mechanism to support caching. Instead of
> adding checksum everywhere into our data models, it seems a better
> solution would be to add something like etags to NETCONF. Hence, we
> reduced this to a single checksum which is needed as it is carried in
> the hello message.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>