Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

Ladislav Lhotka <lhotka@nic.cz> Fri, 23 November 2018 15:24 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 08BE1130E34 for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 07:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8V_EZ9VXr7Du for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 07:24:49 -0800 (PST)
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 4E19F130E30 for <netmod@ietf.org>; Fri, 23 Nov 2018 07:24:48 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id DB3C363801; Fri, 23 Nov 2018 16:23:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542986601; bh=45S5ri9RXrkJU6hgwmzjuIXDmt9WGcF0wc7Zd0gSwYM=; h=From:To:Date; b=iAthGPO4zLbr1KZdLJfUwiIA6QzXVGMU/IkQdS5zZbCwBaoIoXMbWSShCVZibh8fD x03ehy1iwvTcoSWRroZGOF1TD765F/ku7z/zMQL1qA/KvZier9KRSIwrkGDVTkTSrB Sote/7cyp2eIkMD+EmyDEg+WOo5JCJIWboGmhvgU=
Message-ID: <c72bdb5e639428734a85468d6b507707cae79433.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
Date: Fri, 23 Nov 2018 16:23:21 +0100
In-Reply-To: <20181123.150923.932933854491492133.mbj@tail-f.com>
References: <d4e91369c2fe948fe6e2a884ee8dc889f6ce12c6.camel@nic.cz> <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz> <20181123.150923.932933854491492133.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/o2BD4z--SbGa6U8KyEkM-Y8SLqI>
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 23 Nov 2018 15:24:53 -0000

On Fri, 2018-11-23 at 15:09 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> > > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > > > Here is an attempt to rewrite things in a way according to how I
> > > > > understand things works. It should be possible to describe what we
> > > > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > > > only the last two sentences.)
> > > > > 
> > > > > OLD
> > > > > 
> > > > >    The leafref built-in type is restricted to the value space of some
> > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > >    "path" substatement (Section 9.9.2) is used to identify the
> referred
> > > > >    leaf or leaf-list node in the schema tree.  The value space of the
> > > > >    referring node is the value space of the referred node.
> > > > > 
> > > > > NEW
> > > > > 
> > > > >    The leafref built-in type is restricted to the value space of some
> > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > >    "path" substatement (Section 9.9.2) is used to identify a leaf or
> > > > >    leaf-list node in the data tree. The value space of the leafref
> > > > >    node is determined by the value space of the schema tree node
> > > > 
> > > > The term "value space of a schema tree node" is not defined.
> > > 
> > > OK. So we say 'the value space of the type of the schema tree node'.
> > 
> > Yes, this is better. But what if the schema tree node is made invalid due to
> a
> > failed "when" expression? Does it still apply?
> 
> Yes.  I'm sure the text around "when" can be improved, but the idea is
> that if the when expression is false, the schema node becomes
> "invalid"; but it still exists.

But then no referred-to leaf instance can exist, so does the leafref make sense
at all?

And what about if-feature: can I have an instance of a leafref pointing to a
leaf that depends on a feature, and the feature is not active?

> 
> > > > >    definining the referenced data tree node.
> > > > 
> > > > With require-instance=false there needn't be any referenced data tree
> node.
> > > 
> > > So we add "(irrespective whether the node exists or not).
> > 
> > If the data tree node doesn't exist, we cannot refer to the schema tree node
> > that defines it.
> 
> It's pretty clear what the intention is, right?  So what are the right
> words to explain it?

The right words have to avoid mentioning any data tree nodes because there may
be none. It is necessary to explain how the schema tree is traversed based on
the path expression. This basically means:

- ".." = ascend to the closest ancestor data node
- skip all predicates
- if there is an intervening choice in the schema, determine the right case and
descend to it

> 
> 
> > > > > This likely is not perfect yet but perhaps we manage to make it
> > > > > perfect. ;-) What is not yet clearly described I think is what
> > > > > 'further restricted by corresponding instance nodes in the data tree'
> > > > > means (and that I think depends on require-instance). Perhaps add
> > > > 
> > > > Right. In this case it is not "further restricted" but rather there is a
> > > > discrete set of possible values.
> > > 
> > > A discrete set of possible values is a restriction so I do not
> > > understand your comment. So here is the next iteration:
> > 
> > If required-instance is true, there is no need to care about all this tricky
> > stuff with schema tree nodes and their types. In other words:
> > 
> > 1. if required-instance = true, the permitted values are obtained from the
> data
> > tree.
> 
> Not true in the candidate.  See also the mail thread you quoted.

Hmm, so you are saying that in candidate require-instance is ignored but the
leafref's value must still be inside the value space defined by #2? This is IMO
not clear at all.

Lada

> 
> 
> /martin
> 
> 
> > 2. if required-instance = false, the corresponding schema node has to be
> > determined, and its type defines the permitted values of the leafref node.
> > 
> > It is an exclusive-or, #1 is not an "optional further restriction".
> > 
> > Lada
> > 
> > > 
> > > NEW:
> > > 
> > >     The leafref built-in type is restricted to the value space of some
> > >     leaf or leaf-list node in the schema tree and optionally further
> > >     restricted by corresponding instance nodes in the data tree (see
> > >     Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> > >     to identify a leaf or leaf-list node in the data tree. The value
> > >     space of the leafref node is determined by the value space of the
> > >     type of the schema tree node definining the referenced data tree
> > >     node (irrespective whether the referenced data tree node exists or
> > >     not).
> > > 
> > > /js
> > > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67