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

[Andy Bierman <[e-mail]>]

On Thu, Dec 22, 2016 at 3:24 AM, Robert Wilton <[e-mail]> wrote:

>
>
> 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?
>
>
I think the current text is pretty bad.
The term "references" is not very useful and it is not defined anywhere.
IMO a child node implicitly references its parent.  Any child node
could be refactered as an augment:

   container X {
      status obsolete;
      leaf Y {}
   }

equivalent to:


  augment /X {
     leaf Y {}
  }

  container X {
     status obsolete;
  }


Does the augment reference X?  I would say yes.

Even more distressing to me is that the definition of 'obsolete'
says SHOULD NOT implement.  There is no guidence on when
it is OK to ignore the SHOULD NOT.

Also, a deviation-stmt is not allowed to alter the status-stmt.
This seems wrong.  There is no discovery mechanism for a client
to reliably determine what the server implements.

I would prefer that the server advertise a deviation stating explicity
that the server is ignoring the status-stmt

  deviation /X {
     deviate replace {
        status deprecated;
     }
  }

But this is not even permitted by the YANG language.





> Rob
>

Andy


>
>
>>
>> /martin
>> .
>>
>>
>