Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt

Martin Bjorklund <mbj@tail-f.com> Tue, 10 October 2017 11:49 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 F1E341344FF for <netmod@ietfa.amsl.com>; Tue, 10 Oct 2017 04:49:52 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 bA-qS74CNiP2 for <netmod@ietfa.amsl.com>; Tue, 10 Oct 2017 04:49:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D3F43134D57 for <netmod@ietf.org>; Tue, 10 Oct 2017 04:49:23 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id C0F3C1AE02A7; Tue, 10 Oct 2017 13:49:22 +0200 (CEST)
Date: Tue, 10 Oct 2017 13:47:54 +0200 (CEST)
Message-Id: <20171010.134754.960517858051378663.mbj@tail-f.com>
To: ietfc@btconnect.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
References: <20170927.125558.606437323539289377.mbj@tail-f.com> <877ew9zrhs.fsf@nic.cz> <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
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/l0dS1ZyEDJjcoaUYkCYh5ESR2CE>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
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: Tue, 10 Oct 2017 11:49:53 -0000

"t.petch" <ietfc@btconnect.com> wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" <lhotka@nic.cz>
> Sent: Thursday, October 05, 2017 1:52 PM
> > Martin Bjorklund <mbj@tail-f.com> writes:
> >
> > > This version fixes the XPath context for parent-reference.
> > >
> > > However, there is one more thing to discuss, which is the term
> "mount
> > > point".
> > >
> > > The current text says:
> > >
> > >    - mount point: container or list node whose definition contains
> > >      the "mount-point" extension statement. The argument of the
> > >      "mount-point" statement defines the name of the mount point.
> > >
> > > So if we have:
> > >
> > >   container top {
> > >     container root {
> > >       yangmnt:mount-point ni;
> > >     }
> > >   }
> > >
> > > There is one mount point, the node /top/root, with the name "ni".
> > >
> > > Pretty confusing...   Does anyone have any comments around this?
> >
> > What about this?
> >
> > OLD
> >
> >     - mount point: container or list node whose definition contains
> >       the "mount-point" extension statement. The argument of the
> >       "mount-point" statement defines the name of the mount point.
> >
> > NEW
> >
> >     - mount point: container or list node whose definition contains
> >       the "mount-point" extension statement. The argument of the
> >       "mount-point" statement defines a label that is used for
> >       referencing the mount point.
> 
> Lada
> 
> Trouble is 'label' is not a defined term in RFC7950 which leaves me (and
> others) wondering what is this undefined concept.  I know plenty of
> languages that have the concept of a label but YANG is not one of them.

As Lada explained, currently we have two meanings of the term "mount
point name" - it means both the name of the container/list node, and
the argument to the extension.  So the idea is to have a different
term for the latter.

> I looked to see what the ABNF says for inspiration but there isn't
> any:-)  I think that there should be.
> 
> I looked for a worked example for inspiration, nope, none of them
> either!   What I mean is that in e.g. A.3  mount point with name root
> appears, but that is the only instance of 'root'.  The whole point is
> that root should appear more than once, once for where the mount will
> be, and then once or more times for the part that will be mounted, so an
> example where name appears once is not an example IMHO!

I don't understand this.  Can you elaborate?


/martin


> 
> Tom Petch
> 
> > Lada
> >
> > >
> > >
> > >
> > > /martin
> > >
>