Robert Wilton <[email protected]> wrote: > > > On 22/12/2016 10:22, Martin Bjorklund wrote: > > Robert Wilton <[email protected]> wrote: > >> > >> On 22/12/2016 10:00, Andy Bierman wrote: > >>> > >>> On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> > >>> > On 22 Dec 2016, at 07:22, Randy Presuhn > >>> <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > > >>> > Hi - > >>> > > >>> > On 12/21/2016 3:55 PM, Andy Bierman wrote: > >>> >> > >>> >> > >>> >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder > >>> >> <[email protected] > >>> <mailto:[email protected]> > >>> >> <mailto:[email protected] > >>> <mailto:[email protected]>>> wrote: > >>> > ... > >>> >> Perhaps I am blinded by the way @deprecate or __attribute__ > >>> >> ((deprecated)) or [[deprecated]] work in various programming > >>> >> languages. All these annotations do not deprecate my code, > >>> they just > >>> >> cause the generation of warnings so that I get aware of the > >>> issue and > >>> >> can do my homework. > >>> >> > >>> >> > >>> >> There are no protocols that let you manage orphaned data nodes > >>> >> without any parent. No way to represent it in XML or JSON either. > >>> >> No way to specify a RESTCONF target resource that leaves out > >>> >> some intermediate data nodes. > >>> > > >>> > Deprecating (or obsoleting) a definition does not orphan data > >>> nodes. > >>> > Perhaps I'm blinded by the way SNMP works, but it seems to me that > >>> > a robust client will need to be able to process data corresponding > >>> > to deprecated (or obsolete) definitions. Likewise, developers > >>> > of server-side software may find themselves in situations where > >>> > supporting obsolete definitions is a commercial necessity. Things > >>> > certainly played out that way in the SNMP world. I agree with > >>> Juergen > >>> > that tool-generated warnings seem to be the correct way to go. > >>> > >>> I agree that making a node deprecated or obsolete doesn't mean > >>> that its descendants are orphaned, it just means they cannot be > >>> current, and then "current" shouldn't be the default status for > >>> them - also because the descendants may come from other modules > >>> (via groupings and augments) that cannot be changed. > >>> > >>> Even if the default status is inherited, tools can still generate > >>> warnings. A data modeller can decide whether and where it makes > >>> sense to have the "status" statement explicitly, but isn't forced > >>> to do it everywhere. > >>> > >>> > >>> > >>> NETCONF and RESTCONF have no mechanisms for accessing data other than > >>> top-down from the top-level YANG data node to the target node. > >>> Removing an ancestor node from the server implementation effectively > >>> removes > >>> the entire subtree from the implementation. (The value of the YANG > >>> status-stmt > >>> of the descendant nodes has nothing to do with it) > >> I agree that this certainly seems to be the case if a node is marked > >> as obsolete. It seems that it implicitly forces all child nodes to be > >> obsolete as well regardless of which module they were defined in. > > No I don't think this is correct. If module B augment X in module A, > > and X is obsolete, it does NOT mean that the augmented nodes in B are > > automatically obsolete. However, in an implementation that doesn't > > implement X, the augmented nodes from B are obviously also not > > implemented. > I can get where you are coming from, but if you had a GUI viewer that > was looking at the combined schema tree, I think that you would to see > those descendant children nodes marked in some way to indicate that > implementations may validly not return them. Reporting them as current > when one of their parent nodes was obsolete would seem to be > deceptive. > > Is it that you are trying to differentiate between being explicitly > obsolete vs 'implicitly obsolete' through parentage?
I think that within a module, if a parent is obsolete, then all its child should also be obsolete (*). But I do think that the status should be explicitly stated. But marking definition as obsolete in one module cannot automatically make definitions in *other* modules obsolete. (*) _maybe_ 7950 can be interpreted in this way when it says: If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module If you're in a good mood, you could argue that a child always "references" its parent. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
