Dne 6.9.2017 v 10:49 Martin Bjorklund napsal(a):
> Radek Krejčí <[email protected]> wrote:
>> Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a):
>>> Andy Bierman <[email protected]> wrote:
>>>> On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen <[email protected]> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
