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

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

Dne 6.9.2017 v 10:49 Martin Bjorklund napsal(a):
> Radek Krejčí <[e-mail]> wrote:
>> 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.
> I'm just saying that also "uses" can, and should be in this case,
> marked as deprecated.
>
>>>> 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?
> mandatory or not doesn't matter; mandatory doesn't mean "must
> implement", but "must exist if the parent exists".
>

that's not true in case of non-presence containers:

container x {
  status deprecated;
  leaf foo {
    type string;
    mandatory true;
  }
}

or with groupings:

grouping g {
  leaf foo {
    type string;
    mandatory true;
  }
}

container x {
  status deprecated;
  uses pre:g;
}
   
Radek