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

Ladislav Lhotka <lhotka@nic.cz> Tue, 27 November 2018 15:28 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 BEF9B130EB3 for <netmod@ietfa.amsl.com>; Tue, 27 Nov 2018 07:28:12 -0800 (PST)
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 uQQXgRV9nEiZ for <netmod@ietfa.amsl.com>; Tue, 27 Nov 2018 07:28:09 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 77729130E8B for <netmod@ietf.org>; Tue, 27 Nov 2018 07:28:09 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 767BE1820CC0; Tue, 27 Nov 2018 16:35:05 +0100 (CET)
Received: from localhost (084035065018.static.ipv4.infopact.nl [84.35.65.18]) by trail.lhotka.name (Postfix) with ESMTPSA id E318E1820CBA; Tue, 27 Nov 2018 16:35:02 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
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>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, j.schoenwaelder@jacobs-university.de, netmod@ietf.org
Date: Tue, 27 Nov 2018 16:28:04 +0100
Message-ID: <87h8g2v8u3.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1Hx62UMW7avukt-lUO1iYehLssE>
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: Tue, 27 Nov 2018 15:28:20 -0000

Martin Bjorklund <mbj@tail-f.com> writes:

> 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.
>
>> > > >    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?
>
>
>> > > > 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.

This actually indicates that the text "optionally further restricted" is
fundamentally wrong because it seems to suggest that "require-instance
true" is just an additional restriction of leafref's type. But it is
apparently not the case:

- #2 is always used for determining the "inherited" type that has to be
  satisfied in all data trees

- #1 adds a semantic constraint that only has to be satisfied in a valid
  tree.

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