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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 12 February 2018 17:29 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 D609B12D870 for <netmod@ietfa.amsl.com>; Mon, 12 Feb 2018 09:29:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 y2UqQT2m9knx for <netmod@ietfa.amsl.com>; Mon, 12 Feb 2018 09:29:39 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D6612D864 for <netmod@ietf.org>; Mon, 12 Feb 2018 09:29:39 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 01DBE675; Mon, 12 Feb 2018 18:29:38 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id dbkmgLfHCV9Z; Mon, 12 Feb 2018 18:29:35 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Feb 2018 18:29:37 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B073A2014E; Mon, 12 Feb 2018 18:29:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e7OIg2qu2W66; Mon, 12 Feb 2018 18:29:36 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 970DF2014B; Mon, 12 Feb 2018 18:29:36 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7E1B54243CEA; Mon, 12 Feb 2018 18:29:36 +0100 (CET)
Date: Mon, 12 Feb 2018 18:29:36 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
Message-ID: <20180212172936.lt2stijpxgk6o3ug@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com> <1518445591.13433.81.camel@nic.cz> <20180212143749.vmjwgtx2lgxxgbcw@elstar.local> <1518448469.13433.104.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1518448469.13433.104.camel@nic.cz>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kcJ3t27zLfa03NGdznMkzMB5zsQ>
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 17:29:43 -0000

On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav Lhotka wrote:
> On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:
> > On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
> >  
> > > > > **** 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.
> > > 
> > > What about this?
> > > 
> > > OLD
> > >    The YANG library information can be different on every server and it
> > >    can change at runtime or across a server reboot.  If a server
> > >    implements multiple network management protocols to access the
> > >    server's datastores, then each such protocol may have its own
> > >    conceptual instantiation of the YANG library.
> > > 
> > > NEW
> > >    The YANG library information represents a management API for a given
> > > server, 
> > >    and should therefore be as stable as possible. The circumstances under
> > > which 
> > >    this information can change are outside the scope of this document but it
> > > is 
> > >    advisable to consider potential impact on clients.
> > 
> > I like the old text because it tells the client clearly that this data
> > can change. And the statement has been in RFC 7895 in the exact same
> 
> My problem with the current text is that it seems to make no difference between
> YANG library and any other state data.

The sentence starts with 'The YANG library information' and what
follows is all scoped to 'YANG library information'.
 
> > wording. If you want to add a statement that servers should not change
> > the YANG library without reason I could live with that but any attempt
> > to write text that makes the server somewhat guilty when a client is
> 
> Not guilty but careful. There is no requirement that clients check YANG library
> between every two operations, and notifications are optional.


So let me try to make an alternate proposal. (I only added the second
sentence.)

NEW:

   The YANG library information can be different on every server and
   it can change at runtime or across a server reboot. Servers may
   schedule YANG library changes in way that minimizes the impact on
   active clients. If a server implements multiple network management
   protocols to access the server's datastores, then each such
   protocol may have its own conceptual instantiation of the YANG
   library.
 
> > not prepared to handle a YANG library change is IMHO a fundamental
> > change from what RFC 7895 said.
> > 
> > > > >      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?
> > > 
> > > In RESTCONF it could be a separate well-known resource outside all
> > > datastores.
> > 
> > Putting the data into a different place does not change the impact of
> > the data changing. So I do not understand which problem introducing
> > yet another datastore solves.
> 
> Nothing except emphasizing the difference between data and metadata, which is
> IMO an important one.

So its a different topic - one that we closed before I thought.
 
> > > > > **** 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.
> > > 
> > > Checksums are mandatory, so every implementation has to invent some scheme.
> > > 
> > > Actually, it might be useful to have checksums also on module-sets, schemas
> > > and
> > > datastores so that the client can easily localize the changes and retrieve
> > > again
> > > only necessary data.
> > 
> > With RESTCONF, you can use etags and conditional requests. NETCONF
> > lacks a similar generic mechanism to support caching. Instead of
> > adding checksum everywhere into our data models, it seems a better
> > solution would be to add something like etags to NETCONF. Hence, we
> > reduced this to a single checksum which is needed as it is carried in
> > the hello message.
> 
> Etags work, but my point here is to have the checksum as a globally unique
> identifier of a given data model, schema or module set. For example, it would
> allow for checking that multiple servers use the same data model.

I was commenting on your proposal to have multiple checksums.

Concering your other proposal, namely to specify a detailed algorithm
how to calculate these checksums, I have reservations as well but for
other reasons. First, RFC 7895 does not specify this. Second, for the
usage in the NC hello exchange, it is not necessary that there is a
common way to calculate the checksum. Third, the current definition in
RFC 7895 (which has not been changed by the update) allows efficient
implementations since the number is essentially a version number.
Fourth, I have not seen a proposal for a robust algorithm that easily
produces the exact same checksum across a number of equivalent
configurations (the root problem is that the notion YANG library
equivalence is nowhere really defined - you can't simply serialize
YANG library data and checksum the result since there are only limited
serialization ordering requirements).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>