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

Ladislav Lhotka <lhotka@nic.cz> Mon, 09 October 2017 08:43 UTC

Return-Path: <lhotka@nic.cz>
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 AEFB7134D62 for <netmod@ietfa.amsl.com>; Mon, 9 Oct 2017 01:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.101
X-Spam-Level:
X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 xnrbgFZyvMV6 for <netmod@ietfa.amsl.com>; Mon, 9 Oct 2017 01:43:48 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3117134D2E for <netmod@ietf.org>; Mon, 9 Oct 2017 01:43:47 -0700 (PDT)
Received: from birdie14 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 75E42608FA; Mon, 9 Oct 2017 10:43:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1507538624; bh=wiVfoHUwWz63n0VzrTUstT8D7+WflP2mdYb73pymulk=; h=From:To:Date; b=Inl6XH4Of4I3cH/62lMAaV2458aIuUfGgLtycGWK4CJrsyI2AkZhunDomejMELBuq 7qNi1EWJ7QjUvk1IKn0j29/SZohrV+t0Ja4uPFhoDgufa7CGV3y4ntNtH9aQ5k8lCh hnqleThMdTBHWxt5cbpSh66djqCEUC7bFl0tLsJ4=
Message-ID: <1507538675.15153.15.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: "t.petch" <ietfc@btconnect.com>, Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
Date: Mon, 09 Oct 2017 10:44:35 +0200
In-Reply-To: <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
References: <150650952130.25003.1792240611663747386@ietfa.amsl.com> <20170927.125558.606437323539289377.mbj@tail-f.com> <877ew9zrhs.fsf@nic.cz> <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/WurI6f-wonVDswilglCDFnTvZ8k>
Subject: [netmod] Odp.: 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: Mon, 09 Oct 2017 08:43:51 -0000

t.petch píše v Pá 06. 10. 2017 v 12:39 +0100:
> ----- 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.

The argument of the "schema-mount" extension is used exclusively for the
purposes of schema mount so it is fully appropriate that the term "label" is
unknown to RFC 7950. In fact, the problem that Martin pointed to is that data
nodes in RFC 7950 already have their name and now we are introducing the same
term with a different meaning.

Lada

> 
> 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!
> 
> Tom Petch
> 
> > Lada
> > 
> > > 
> > > 
> > > 
> > > /martin
> > > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67