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

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


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

netmod mailing list

Reply via email to