Re: [netmod] 'status' statement needed on every node

[Radek Krejčí <[e-mail]>]

Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a):
> Andy Bierman <[e-mail]> wrote:
>> On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen <[e-mail]> wrote:
>>
>>>
>>>
>>>>> I still don't know what it means to define hierarchical data and say the
>>>>> parent is deprecated but not the descendant nodes.
>>>> It is odd but can happen anyway. A current augmentation of something
>>>> that got deprecated likely stays current. I would hope that tools warn
>>>> if they see this but that's it.
>>> This example seems to provide support for saying status should be
>>> inherited.  But, to be clear, you agree that if a parent is deprecated,
>>> than its decedents should be deprecated as well, right?
>>>
>>>
>>>
>> right -- the RFC says this has to be done manually.
>> A missing status-stmt means status=current.
>>
>>
>>
>>>>> This is rather non-intuitive, as is the idea that all descendant
>>>>> nodes need to be manually edited (status is not inherited).
>>>> Not a big deal. The benefit is that a reader like me knows clear that
>>>> the definition I am look at is deprecated, no need to search backwards
>>>> to find out.
>>> tree diagrams do this too, though I like Martin's approach of removing
>>> the deprecated -state trees from the tree diagram altogether.
>>>
>>>
>>>
>>>>> It also means the objects expanded from groupings cannot ever be
>>>>> changed (clearly a bug in YANG).
>>>> Yes, bug in YANG.
>>> Is this the same issue I raised?
>>>
>>>   import ietf-foo {
>>>     prefix f;
>>>   }
>>>
>>>   container bar {
>>>     uses f:foo;
>>>   }
>>>
>>>   container baz {
>>>     status deprecated;
>>>     uses f:foo;            <-- oops, descendants not deprecated!
>>>   }                           (not a problem if status inherited)
> As Andy explains below, this should be:
>
>    container baz {
>      status deprecated;
>      uses f:foo {
>        status deprecated;
>      }
>    }

despite I see this explanation of status in uses as useful, I don't see anything in RFC that would support this.

>> According to my interpretation of 7.21.2, this is a MUST NOT:
>>
>>    If a definition is "current", it MUST NOT reference a "deprecated" or
>>    "obsolete" definition within the same module.
>>
>>    If a definition is "deprecated", it MUST NOT reference an "obsolete"
>>    definition within the same module.
>>
>>    For example, the following is illegal:
>>
>>      typedef my-type {
>>        status deprecated;
>>        type int32;
>>      }
>>
>>      leaf my-leaf {
>>        status current;
>>        type my-type; // illegal, since my-type is deprecated
>>      }
>>
>> The term "reference" is not really defined above.
>> It should also clearly apply to "uses" (e.g., your example) and  leafref
>> path-stmt.
>>
>>    leaf foo {
>>      type string;
>>      status deprecated;
>>   }
>>
>>   leaf bar {
>>     type leafref { path /foo; }
>>   }
>>
>> If it apples to path-stmt, then why not all XPath?
> B/c in XPath it is even ok to refer to non-existing nodes.  And you
> might have things like /baz/*.
>
>> Why doesn't "reference" include descendant nodes?
>>
>> The text in 7950 is too strict and can cause a massive ripple-effect when
>> any status-stmt is changed.
>>  At the same time it is too vague to be useful to implementors.
> While I agree that it is not clear what it means to have a "current"
> child to a "deprecated" node, I don't think this is a big issue.  If a
> node is deprecated, it is ok for an implementation to not implement
> it.  Obviously this means that no child nodes to that node is
> implemented either, regardless of their status, if they are augmented
> in, or comes from a grouping.

what about the mandatory nodes inside a deprecated container? Formally, they are not deprecated (default status is current) so still mandatory, right?

Radek