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

[Ladislav Lhotka <[e-mail]>]

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