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

Ladislav Lhotka <lhotka@nic.cz> Fri, 09 February 2018 13:52 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 35F72120726 for <netmod@ietfa.amsl.com>; Fri, 9 Feb 2018 05:52:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id srYu6QsQ4A4Z for <netmod@ietfa.amsl.com>; Fri, 9 Feb 2018 05:52:43 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name []) by ietfa.amsl.com (Postfix) with ESMTP id 01080129BBF for <netmod@ietf.org>; Fri, 9 Feb 2018 05:52:42 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id A9E531820412; Fri, 9 Feb 2018 14:51:16 +0100 (CET)
Received: from localhost (nat-2.nic.cz []) by trail.lhotka.name (Postfix) with ESMTPSA id 39F5E18203DE for <netmod@ietf.org>; Fri, 9 Feb 2018 14:51:15 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Mail-Followup-To: netmod@ietf.org
Date: Fri, 09 Feb 2018 14:52:39 +0100
Message-ID: <87fu6axobc.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Mlcf0xPCMdUb9CxzSARTPz0hZIo>
Subject: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Feb 2018 13:52:54 -0000


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

    - 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

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

**** Nits

     - sec 1. paragraph 2: s/informaton/information/


Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67