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

Martin Bjorklund <mbj@tail-f.com> Wed, 11 April 2018 06:46 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 396E9126C3D for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 23:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 FMrcGfIAyN6Z for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 23:46:44 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F313126DEE for <netmod@ietf.org>; Tue, 10 Apr 2018 23:46:44 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DAFF1AE043F; Wed, 11 Apr 2018 08:46:42 +0200 (CEST)
Date: Wed, 11 Apr 2018 08:46:42 +0200 (CEST)
Message-Id: <20180411.084642.1344446330417036664.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20180411062021.i6h2c3z3kf4otae7@elstar.local>
References: <20180410143416.4y5wofkhr67wxxo4@elstar.local> <20180410.225800.2211357338649569621.mbj@tail-f.com> <20180411062021.i6h2c3z3kf4otae7@elstar.local>
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/JVe8vf8_rWvFiDKCAYH6rzSacMU>
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:46:47 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 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'.

Ok, I will do that.


/martin