On Mon, Feb 12, 2018 at 9:29 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> 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: +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
