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

[Robert Wilton <[e-mail]>]

On 22/12/2016 10:49, Martin Bjorklund wrote:
> 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.
OK.  I assume that this statement applies to deprecated as well.  I 
don't feel particularly strongly on this point.  If you mark something 
as obsolete/deprecated, then explicitly having to find and mark all 
references/children doesn't seem like a bad thing because it makes the 
full impact obvious (if pyang is enhanced to check for this).

>
> But marking definition as obsolete in one module cannot automatically
> make definitions in *other* modules obsolete.
I'm not so sure.

It seems to me that in practice, they are directly equivalent as if they 
were marked as obsolete.  I.e. clients cannot rely on them being 
available because the obsolete parent may not be implemented.

If the augmenting module wants to keep those nodes, then their only 
choice seems to be to explicitly mark them as obsolete, and make a copy 
of the nodes augmenting somewhere else in the schema tree.


>
> (*) _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.
Would it not be better to add some sort of explicit statement as an 
errata to 7950 (once there is agreement on what it should say)?  Or is 
this beyond the scope of what an errata is allowed to do?

Rob

>
>
> /martin
> .
>