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

Martin Bjorklund <mbj@tail-f.com> Mon, 12 February 2018 12:02 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD83C12778E for <netmod@ietfa.amsl.com>; Mon, 12 Feb 2018 04:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-iHBggTVGYg for <netmod@ietfa.amsl.com>; Mon, 12 Feb 2018 04:02:15 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC2F81276AF for <netmod@ietf.org>; Mon, 12 Feb 2018 04:02:14 -0800 (PST)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (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: <20180212.130212.2080346646041413993.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <87fu6axobc.fsf@nic.cz>
References: <87fu6axobc.fsf@nic.cz>
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: <https://mailarchive.ietf.org/arch/msg/netmod/broRR8kpvykEZR4F6mGY2CYSAoI>
Subject: Re: [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: Mon, 12 Feb 2018 12:02:17 -0000

Hi,

Thank you for this review.  Comments inline.

Ladislav Lhotka <lhotka@nic.cz> 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/

Fixed.


/martin


> 
> Lada
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
>