Hi,
here is my review of the rfc7895bis document:
*** General comments
- This revision is a significant improvement necessary for
supporting NMDA. However, it is also flexible enough in that it
allows for implementing the NMDA rules in an effective way but
doesn't preclude the use of other datastores and datastore
architectures.
- Another benefit is that the new YANG library schema can be
easily integrated with schema mount information.
*** Specific comments
**** Sec. 1 - backward compatibility
Given that the old YANG library schema is carried over as a
deprecated subtree, how can a server implementor actually cater
for backward compatibility of e.g. RESTCONF clients supporting
only RFC 8040? Could the same YANG modules that comprise NMDA
datastore schemas be advertized also via the old YANG library? Or
is it necessary to also have pre-NMDA versions of all modules?
Some more explanation might be useful here.
**** 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.
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.
**** Sec. 3 - semantic versioning
Some placeholders for future inclusion of semantic versions in
YANG library information might be useful. To this end, I would
suggest to introduce a new choice node and make "revision" (or,
even better, "revision-date") its only case. This way, other
versioning schemes such as semver could be easily added via
augmentation.
**** 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.
**** Nits
- sec 1. paragraph 2: s/informaton/information/
Lada
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
