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

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:

> 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.

OK, so what information is "current/deprecated/obsolete" supposed to
convey? If we interpret it as likelihood that the node is implemented,
then it is clear that no node is more likely to be implemented that any
of its ancestors.

If the target node of an augment isn't implemented because it is
obsolete, then the augment cannot be applied, no matter how we classify
its contents.

>
> (*) _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.

Whatever mood I am in, an augment certainly references its target node,
so according to the above rule it cannot be current unless the target
node is also current.

Lada

>
>
> /martin

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67