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

Martin Bjorklund <> Mon, 12 February 2018 12:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD83C12778E for <>; Mon, 12 Feb 2018 04:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D-iHBggTVGYg for <>; Mon, 12 Feb 2018 04:02:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CC2F81276AF for <>; Mon, 12 Feb 2018 04:02:14 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 877EE1AE0339; Mon, 12 Feb 2018 13:02:13 +0100 (CET)
Date: Mon, 12 Feb 2018 13:02:12 +0100 (CET)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Feb 2018 12:02:17 -0000


Thank you for this review.  Comments inline.

Ladislav Lhotka <> wrote:
> 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.

The text says:

  The recommended approach to populate /modules-state is to
  report the schema for YANG modules that are configurable via
  conventional datastores and for which config false data nodes are
  returned via a NETCONF <get> operation, or equivalent.

Do you think that more guidance is needed?

My opinion is that a server that wasnt to be backwards compatible
probably advertise exactly what it used to advertise (in
/modules-state), even if new NMDA-compatible models are added and
advertised in /yang-library for new clients.

In general it is of course not possible to advertise everything that
is availabile in /yang-library also in /modules-state - if this was
possible we wouldn't have done YLbis.

I don't think this document should provide recommendations on whether
to implement pre-NMDA versions or not; this will be up to each server
implementor to decide.

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

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

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

When revision is used as a list key, we can't have a choice.

And when it is not a key, it is an optional leaf, so adding a 'semver'
optional leaf in the future is also ok.

The proposal I have seen adds semver as an addition to revision, so
using a choice would not be correct in this case.

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

> **** Nits
>      - sec 1. paragraph 2: s/informaton/information/



> Lada
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> _______________________________________________
> netmod mailing list