Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Andy Bierman <andy@yumaworks.com> Fri, 23 November 2018 17:23 UTC
Return-Path: <andy@yumaworks.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 7E88312DD85 for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 09:23:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 e3-MJfPkhTz2 for <netmod@ietfa.amsl.com>; Fri, 23 Nov 2018 09:23:15 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3BE12D84D for <netmod@ietf.org>; Fri, 23 Nov 2018 09:23:14 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id u6-v6so11261077ljd.1 for <netmod@ietf.org>; Fri, 23 Nov 2018 09:23:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ngT9sg0eCM751eW79XZRlamtutRH8xZK8MY0bxt7NTU=; b=t3S7P39sEPLR+KT6bJK1PmnZ84U3+nYrV6nDOwAppne/sriEt6TTTQrYzo7VkHOk/y oc14MrgonewcpKJo5vrYwk+90mKgmVSX0MdDcNrU7ELCjgMInsEFwgmKfhbvTpn/BXRi VlHWGLQDi7WOA9ItESlFf9uljwJRuSCKlX2fG1SvziPJ6wG9kotnZWsyCaCYAvZwDxkt gFiBo9pYWnrJ8E1ZhIRy8VTMCPGAnjib9aW5VG1BVoRvH+tWojKBKA5DS1XSgP2Vy1ni UkFrBeouIxTaXKFdqMaGbnnvv0FiIwmYpH2eL2oJEGaoYnYVDnWQrfdtuCRro+D2fEul yKJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ngT9sg0eCM751eW79XZRlamtutRH8xZK8MY0bxt7NTU=; b=E5Iu7HcU+GUbedzs3apgLRUswNLoWvsVNgON/+TiO/JTMG75gFqH5dx8i+g+W5Xyvz SJ1Xq/tsxz3iVvpyMXAAri+Gzo45tUsvwi1KHDr4wwiGVNiVzsJy0nNDoY7QAJVx07hJ WTT6SHkn4875xzmecWXDvWXnnyJZ0ZOEuUZGxjYB/nYYw0Hms2LlBO8AUi0++/zfgiFF e+s/LfdwQC61vLlNGP7De5SCodZj7GnNRW63HdK4pkEkwIA2QDylyBF1HryY+uqg/beF CkkVbcrFslpMt0O31XCGAv+mT5YzDrUClQ1nF/0pFBG198JUkBj3jMSbXLuxarxXQ9bv lK2w==
X-Gm-Message-State: AA+aEWZumCecHo6lJ1m1Wn9tOHZ2f15KFseba9nT+alN/CpjDbEhKUE5 /3geKHi2wTJ2qBUmZB81CCE9f1f7V9r/RlDikd46Zw==
X-Google-Smtp-Source: AFSGD/X3toHS/AAM0iAFmxpwJW3JzSr1X8kStV/k3f5D5+4RSiKkR1DiHVfhCvtiixAhIrGNIqQOxsCJ7PlIn6awQqI=
X-Received: by 2002:a2e:841:: with SMTP id g1-v6mr11350569ljd.21.1542993792817; Fri, 23 Nov 2018 09:23:12 -0800 (PST)
MIME-Version: 1.0
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de> <d4e91369c2fe948fe6e2a884ee8dc889f6ce12c6.camel@nic.cz> <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz> <0467b647-1b3b-6b79-e568-8cb9526d1af3@cisco.com>
In-Reply-To: <0467b647-1b3b-6b79-e568-8cb9526d1af3@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 23 Nov 2018 09:23:01 -0800
Message-ID: <CABCOCHRN5-SSau2u_ADnRLk6AhStaUJfZeNuVURLafud=TMHBQ@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e979e5057b583cfb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/n2bTt9d26cFqHlHk0NwZJljB3KI>
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 17:23:17 -0000
On Fri, Nov 23, 2018 at 5:37 AM Robert Wilton <rwilton@cisco.com> wrote: > > On 23/11/2018 13:29, Ladislav Lhotka 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? > > I might be being picky, but it isn't absolutely clear from the text > which node "schema tree node" refers to. > > Hence I wonder whether it might be better to say "...identify the > referenced leaf or leaflist ..." and "value space of the referenced > schema tree node". > > IMO the RFC has a lot of room for improvement in this area: - the term "data node" is never defined but used 47 times - the term "data node identifier" is not defined or used - the term "schema node identifier" is defined and used 14 times (defined in sec. 3 Terminology and again in sec. 6.5) - every statement that uses some sort of path identifier (e.g. 9.9.2) needs to clearly specify whether the syntax is based on schema-node identifier or data-node identifier > Thanks, > Rob > > Andy > > > > >> > >>>> 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. > > > >>>> 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. > > > > 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 > >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- [netmod] Adding a pre-existing leaf into a new 'c… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Adding a pre-existing leaf into a ne… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Adding a pre-existing leaf into a ne… Andy Bierman
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- Re: [netmod] Adding a pre-existing leaf into a ne… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- Re: [netmod] Adding a pre-existing leaf into a ne… Andy Bierman
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Per Hedeland
- Re: [netmod] Adding a pre-existing leaf into a ne… Andy Bierman
- Re: [netmod] Adding a pre-existing leaf into a ne… Juergen Schoenwaelder
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Juergen Schoenwaelder
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Juergen Schoenwaelder
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Juergen Schoenwaelder
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Robert Wilton
- Re: [netmod] Adding a pre-existing leaf into a ne… Martin Bjorklund
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka
- Re: [netmod] Adding a pre-existing leaf into a ne… Juergen Schoenwaelder
- Re: [netmod] Adding a pre-existing leaf into a ne… Andy Bierman
- Re: [netmod] Adding a pre-existing leaf into a ne… Juergen Schoenwaelder
- Re: [netmod] Adding a pre-existing leaf into a ne… Andy Bierman
- Re: [netmod] Adding a pre-existing leaf into a ne… Ladislav Lhotka