Re: [netmod] 'status' statement needed on every node
Martin Bjorklund <mbj@tail-f.com> Wed, 06 September 2017 08:51 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 4F716132396 for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 01:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 aO3_9M1zueJU for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 01:51:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7161270AB for <netmod@ietf.org>; Wed, 6 Sep 2017 01:51:10 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D0C81AE0187; Wed, 6 Sep 2017 10:51:09 +0200 (CEST)
Date: Wed, 06 Sep 2017 10:49:36 +0200
Message-Id: <20170906.104936.1524498889327990684.mbj@tail-f.com>
To: rkrejci@cesnet.cz
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <a6630804-c6cd-edb0-a642-9743aa9c13f0@cesnet.cz>
References: <CABCOCHTycfsSi11Jfsrs=mFstzYg3257JtFGqgKGr-NpR8rxgQ@mail.gmail.com> <20170906.085222.355333494940576314.mbj@tail-f.com> <a6630804-c6cd-edb0-a642-9743aa9c13f0@cesnet.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/QaC4Q0x1PMgpiWaCa00NCncCiSQ>
Subject: Re: [netmod] 'status' statement needed on every node
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: Wed, 06 Sep 2017 08:51:12 -0000
Radek Krejčí <rkrejci@cesnet.cz> wrote: > Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a): > > Andy Bierman <andy@yumaworks.com> wrote: > >> On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen <kwatsen@juniper.net> wrote: > >> > >>> > >>> > >>>>> I still don't know what it means to define hierarchical data and say the > >>>>> parent is deprecated but not the descendant nodes. > >>>> It is odd but can happen anyway. A current augmentation of something > >>>> that got deprecated likely stays current. I would hope that tools warn > >>>> if they see this but that's it. > >>> This example seems to provide support for saying status should be > >>> inherited. But, to be clear, you agree that if a parent is deprecated, > >>> than its decedents should be deprecated as well, right? > >>> > >>> > >>> > >> right -- the RFC says this has to be done manually. > >> A missing status-stmt means status=current. > >> > >> > >> > >>>>> This is rather non-intuitive, as is the idea that all descendant > >>>>> nodes need to be manually edited (status is not inherited). > >>>> Not a big deal. The benefit is that a reader like me knows clear that > >>>> the definition I am look at is deprecated, no need to search backwards > >>>> to find out. > >>> tree diagrams do this too, though I like Martin's approach of removing > >>> the deprecated -state trees from the tree diagram altogether. > >>> > >>> > >>> > >>>>> It also means the objects expanded from groupings cannot ever be > >>>>> changed (clearly a bug in YANG). > >>>> Yes, bug in YANG. > >>> Is this the same issue I raised? > >>> > >>> import ietf-foo { > >>> prefix f; > >>> } > >>> > >>> container bar { > >>> uses f:foo; > >>> } > >>> > >>> container baz { > >>> status deprecated; > >>> uses f:foo; <-- oops, descendants not deprecated! > >>> } (not a problem if status inherited) > > As Andy explains below, this should be: > > > > container baz { > > status deprecated; > > uses f:foo { > > status deprecated; > > } > > } > > despite I see this explanation of status in uses as useful, I don't > see anything in RFC that would support this. I'm just saying that also "uses" can, and should be in this case, marked as deprecated. > >> According to my interpretation of 7.21.2, this is a MUST NOT: > >> > >> If a definition is "current", it MUST NOT reference a "deprecated" or > >> "obsolete" definition within the same module. > >> > >> If a definition is "deprecated", it MUST NOT reference an "obsolete" > >> definition within the same module. > >> > >> For example, the following is illegal: > >> > >> typedef my-type { > >> status deprecated; > >> type int32; > >> } > >> > >> leaf my-leaf { > >> status current; > >> type my-type; // illegal, since my-type is deprecated > >> } > >> > >> The term "reference" is not really defined above. > >> It should also clearly apply to "uses" (e.g., your example) and leafref > >> path-stmt. > >> > >> leaf foo { > >> type string; > >> status deprecated; > >> } > >> > >> leaf bar { > >> type leafref { path /foo; } > >> } > >> > >> If it apples to path-stmt, then why not all XPath? > > B/c in XPath it is even ok to refer to non-existing nodes. And you > > might have things like /baz/*. > > > >> Why doesn't "reference" include descendant nodes? > >> > >> The text in 7950 is too strict and can cause a massive ripple-effect when > >> any status-stmt is changed. > >> At the same time it is too vague to be useful to implementors. > > While I agree that it is not clear what it means to have a "current" > > child to a "deprecated" node, I don't think this is a big issue. If a > > node is deprecated, it is ok for an implementation to not implement > > it. Obviously this means that no child nodes to that node is > > implemented either, regardless of their status, if they are augmented > > in, or comes from a grouping. > > what about the mandatory nodes inside a deprecated container? > Formally, they are not deprecated (default status is current) so > still mandatory, right? mandatory or not doesn't matter; mandatory doesn't mean "must implement", but "must exist if the parent exists". /martin
- [netmod] 'status' statement needed on every node Kent Watsen
- Re: [netmod] 'status' statement needed on every n… Juergen Schoenwaelder
- Re: [netmod] 'status' statement needed on every n… Andy Bierman
- Re: [netmod] 'status' statement needed on every n… Juergen Schoenwaelder
- Re: [netmod] 'status' statement needed on every n… Andy Bierman
- Re: [netmod] 'status' statement needed on every n… Kent Watsen
- Re: [netmod] 'status' statement needed on every n… Andy Bierman
- Re: [netmod] 'status' statement needed on every n… heasley
- Re: [netmod] 'status' statement needed on every n… Juergen Schoenwaelder
- Re: [netmod] 'status' statement needed on every n… Martin Bjorklund
- Re: [netmod] 'status' statement needed on every n… Martin Bjorklund
- Re: [netmod] 'status' statement needed on every n… Juergen Schoenwaelder
- Re: [netmod] 'status' statement needed on every n… Juergen Schoenwaelder
- Re: [netmod] 'status' statement needed on every n… Radek Krejčí
- Re: [netmod] 'status' statement needed on every n… Martin Bjorklund
- Re: [netmod] 'status' statement needed on every n… Robert Wilton
- Re: [netmod] 'status' statement needed on every n… Ladislav Lhotka
- Re: [netmod] 'status' statement needed on every n… Radek Krejčí
- Re: [netmod] 'status' statement needed on every n… Ladislav Lhotka
- Re: [netmod] 'status' statement needed on every n… Juergen Schoenwaelder
- Re: [netmod] 'status' statement needed on every n… Robert Wilton
- Re: [netmod] 'status' statement needed on every n… Andy Bierman