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

[Andy Bierman <[e-mail]>]

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

> On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav Lhotka wrote:
> > On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder 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
> >
> > My problem with the current text is that it seems to make no difference
> between
> > YANG library and any other state data.
>
> The sentence starts with 'The YANG library information' and what
> follows is all scoped to 'YANG library information'.
>
> > > 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 guilty but careful. There is no requirement that clients check YANG
> library
> > between every two operations, and notifications are optional.
>
>
> So let me try to make an alternate proposal. (I only added the second
> sentence.)
>
> NEW:
>
>    The YANG library information can be different on every server and
>    it can change at runtime or across a server reboot. Servers may
>    schedule YANG library changes in way that minimizes the impact on
>    active clients. 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.
>
> > > not prepared to handle a YANG library change is IMHO a fundamental
> > > change from what RFC 7895 said.
> > >
> > > > > >      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.
> >
> > Nothing except emphasizing the difference between data and metadata,
> which is
> > IMO an important one.
>
> So its a different topic - one that we closed before I thought.
>
> > > > > > **** 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.
> >
> > Etags work, but my point here is to have the checksum as a globally
> unique
> > identifier of a given data model, schema or module set. For example, it
> would
> > allow for checking that multiple servers use the same data model.
>
> I was commenting on your proposal to have multiple checksums.
>
> Concering your other proposal, namely to specify a detailed algorithm
> how to calculate these checksums, I have reservations as well but for
> other reasons. First, RFC 7895 does not specify this. Second, for the
> usage in the NC hello exchange, it is not necessary that there is a
> common way to calculate the checksum. Third, the current definition in
> RFC 7895 (which has not been changed by the update) allows efficient
> implementations since the number is essentially a version number.
> Fourth, I have not seen a proposal for a robust algorithm that easily
> produces the exact same checksum across a number of equivalent
> configurations (the root problem is that the notion YANG library
> equivalence is nowhere really defined - you can't simply serialize
> YANG library data and checksum the result since there are only limited
> serialization ordering requirements).
>
>
I agree that the YANG library should not mandate a checksum algorithm.
I do not even like calling this field checksum (or having multiple fields).


> /js
>
>
Andy


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