On Mon, Feb 12, 2018 at 6:37 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
