Re: [netmod] js review of draft-ietf-netmod-schema-mount-09

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 11 April 2018 06:20 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 0C7EB126B6E for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 23:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs7D5eGKyqhS for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 23:20:24 -0700 (PDT)
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 E5D5E1241FC for <netmod@ietf.org>; Tue, 10 Apr 2018 23:20:23 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B6288EA9; Wed, 11 Apr 2018 08:20:22 +0200 (CEST)
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 rApSET1mftFi; Wed, 11 Apr 2018 08:20:22 +0200 (CEST)
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; Wed, 11 Apr 2018 08:20:22 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F4E720035; Wed, 11 Apr 2018 08:20:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7c18PhgkgP5a; Wed, 11 Apr 2018 08:20:21 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F48620031; Wed, 11 Apr 2018 08:20:21 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 621F942AF3E0; Wed, 11 Apr 2018 08:20:21 +0200 (CEST)
Date: Wed, 11 Apr 2018 08:20:21 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
Message-ID: <20180411062021.i6h2c3z3kf4otae7@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
References: <20180410124643.mnywxuxrnyaahttv@elstar.local> <20180410.161546.1818555188781690245.mbj@tail-f.com> <20180410143416.4y5wofkhr67wxxo4@elstar.local> <20180410.225800.2211357338649569621.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180410.225800.2211357338649569621.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wwh4x3bSEkd6ijhuiOemibxBQmk>
Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09
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: Wed, 11 Apr 2018 06:20:27 -0000

On Tue, Apr 10, 2018 at 10:58:00PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote:
> > > > 
> > > > Yes, the checksum (which I think is actually a version identifier).
> > > > Anyway, the question is whether a client can draw any conclusions from
> > > > seeing YANG library instances with the same checksum and whether a
> > > > client must simpy treat this as a clash. If multiple mounted schemas
> > > > have the same YANG library, then reading one of them would be
> > > > sufficient. The question is whether the checksum is a tool for
> > > > deciding whether a YANG library is similar to an already known one or
> > > > whether a client must not make this assumption, i.e., a checksum is
> > > > always scoped to the YANG library instance and you have to read them
> > > > all.
> > > 
> > > Options:
> > > 
> > > 1.  Be silent about the YL checksum in this document.
> > > 
> > > 2.  State that the server MUST ensure that if two mounted YL
> > >     instances have the same checksum, then the YL contents MUST be
> > >     the same.
> > > 
> > > 3.  State that just b/c the YL checksum is the same in two mounted
> > >     instances, it does not mean that the YL contents is the same.
> > > 
> > > 4.  State that for use-schema, the YL contents and YL checksum MUST be
> > >     the samem but for inline, equal YL checksum is no guarantee for
> > >     equal YL contents.
> > > 
> > > From a client perspective, 2 is preferrable.  It is probably not
> > > difficult to implement on a server either; except in the peer mount
> > > case where the data is just read from some device.
> > 
> > The more I think about it, it seems option 4. is the right thing to
> > do.
> 
> Ok.  How about adding two sentences at the end of the last paragraph
> in section 3.3, giving: 
> 
>   The mounted schema is determined at run time: every instance of the
>   mount point that exists in the operational state MUST contain a copy
>   of YANG library data that defines the mounted schema exactly as for
>   a top-level schema. A client is expected to retrieve this data from
>   the instance tree, possibly after creating the mount point.  In the
>   "inline" case, instances of the same mount point MAY use different
>   mounted schemas, whereas in the "shared-schema" case, all instances
>   MUST use the same mounted schema.  In the "inline" case, if two
>   instances have the same YANG library checksum it is not guaranteed
>   that the YANG library contents are equal for these instances.

This text says "A client is expected to retrieve this data from the
instance tree, possibly after creating the mount point.", which seems
a bit odd. How does a client create a mount point? First, a mount
point is created by defining it in a YANG module, so this is
specification time not runtime. Perhaps you mean 'instantiated' rather
than 'created' but even then it is somewhat unclear how a client does
that in general. Perhaps simple drop ', possibly after creating the
mount point'.

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