Re: [netmod] Does the YANG "status" statement inherit from its parent node?

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> 
> 
> On 22/12/2016 10:22, Martin Bjorklund wrote:
> > Robert Wilton <[e-mail]> wrote:
> >>
> >> On 22/12/2016 10:00, Andy Bierman wrote:
> >>>
> >>> On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka <[e-mail]
> >>> <mailto:[e-mail]>> wrote:
> >>>
> >>>
> >>>      > On 22 Dec 2016, at 07:22, Randy Presuhn
> >>>      <[e-mail]
> >>>      <mailto:[e-mail]>> wrote:
> >>>      >
> >>>      > Hi -
> >>>      >
> >>>      > On 12/21/2016 3:55 PM, Andy Bierman wrote:
> >>>      >>
> >>>      >>
> >>>      >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder
> >>>      >> <[e-mail]
> >>>      <mailto:[e-mail]>
> >>>      >> <mailto:[e-mail]
> >>>      <mailto:[e-mail]>>> 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