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

[Robert Wilton <[e-mail]>]

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?

Rob


>
>
> /martin
> .
>