Re: [netmod] 'status' statement needed on every node
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 06 September 2017 06:57 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 89C15132D66 for <netmod@ietfa.amsl.com>; Tue, 5 Sep 2017 23:57:29 -0700 (PDT)
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 C_IyXe3_ozWq for <netmod@ietfa.amsl.com>; Tue, 5 Sep 2017 23:57:28 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B2C1321A5 for <netmod@ietf.org>; Tue, 5 Sep 2017 23:57:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CE36F21; Wed, 6 Sep 2017 08:57:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id EAwMzgXEmjsA; Wed, 6 Sep 2017 08:57:25 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 6 Sep 2017 08:57:25 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADB5A200E2; Wed, 6 Sep 2017 08:57:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z_O83dOB1AMz; Wed, 6 Sep 2017 08:57:25 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27481200E0; Wed, 6 Sep 2017 08:57:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id ECEE64096E25; Wed, 6 Sep 2017 08:57:23 +0200 (CEST)
Date: Wed, 06 Sep 2017 08:57:23 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: heasley <heas@shrubbery.net>
Cc: netmod@ietf.org
Message-ID: <20170906065723.dnv4xl2mchszcvlo@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: heasley <heas@shrubbery.net>, netmod@ietf.org
References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906014757.GD31035@shrubbery.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170906014757.GD31035@shrubbery.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/bc1xqLMW_uYdFrOG4L2YmDMxtaI>
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 06:57:29 -0000
On Wed, Sep 06, 2017 at 01:47:57AM +0000, heasley wrote: > > Isn't this something that is fixed with display (human representation) > tools? > I often work with the original definitions. And if the original definitions depend on context, I have to do another lookup (whether this is inside the original definition or some tool generated human representation does not matter). With the old /foo and /foo-state approach this was really bad since you had often objects with the same name and it was often not at all clear whether I have been looking at the config true or the config false definition without an additional search operation. Perhaps I could program my favourite editor to generate explicit config statements and status statements on the fly but I think we would be better off if readers would not have to program editors or use special tools to easily understand what a definition really means. > > > 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. > > How is anything ever expunged if parsing tools do not refuse to load > a module that depends on a deprecated node that it is attempting to > augment? Expunged? Deprecating a definition does not expunge anything. Tools that refuse to load a module that depends on deprecated nodes are in my view broken. It was one of YANG's design goals to support augmentations such that definitions and be augmented by independent organizations. Hence, we must face reality that it is impossible to determine how many augmentations of a definition are out there and hence it is impossible to have them all updated at the same time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
- [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