> On 21 Dec 2016, at 10:32, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>> Martin Bjorklund <[email protected]> writes:
>>
>>> Robert Wilton <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> The definition of "status" in RFC 7950 in section 7.21.2 (full text
>>>> below), states:
>>>>
>>>> If no status is specified, the default is "current".
>>>>
>>>> From my interpretation of the text in the draft, this implies that the
>>>> status of the "new" child leaf in the following example is "current",
>>>> and that this example is allowed!
>>>>
>>>> My questions are:
>>>> - Is my interpretation of the current text correct?
>>>
>>> Yes.
>>>
>>>> - Is this actually the best behaviour, or should it inherit like the
>>>> config statement?
>>>
>>> I think the idea was that if the status != current, it is better for
>>> the reader if it is explicitly stated.
>>>
>>>> Should I raise an errata for this?
>>>
>>> No.
>>>
>>> However, we could have said that a current node under a deprecated
>>> node (etc) in the same module is an error, in order to force people
>>> (through the useage of YANG validators) to detect and fix this.
>>
>> Since "current" is the default, correctly deprecating a subtree would
>> mean to explicitly add the "status" statement to every single node in
>> the subtree.
>
> Yes.
>
>> I think that "obsolete" should apply to the whole subtree, no matter
>> what status descendants have, and "deprecated" should apply to the whole
>> subtree except for parts that are obsolete.
>
> Maybe, but this is not how it works in YANG 1 and 1.1. For the
> reasoning behind this, see above. Maybe this is not perfect, and
> something that we should look into if we update YANG. But I don't
> think this is a problem.
I think it is a problem. We can see a lot of these things before long because
of the update rules. For example, it may apply to all the *-state trees, and
tagging every single node therein with "deprecated" or "obsolete" is a useless
exercise.
Lada
>
>
> /martin
>
>
>
>>
>> Lada
>>
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>>
>>>> container old {
>>>> status deprecated;
>>>> leaf new {
>>>> description "what status do I have?";
>>>> }
>>>> }
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> Full 7.21.2 text from 7950:
>>>>
>>>> 7.21.2. The "status" Statement
>>>>
>>>> The "status" statement takes as an argument one of the strings
>>>> "current", "deprecated", or "obsolete".
>>>>
>>>> o "current" means that the definition is current and valid.
>>>>
>>>> o "deprecated" indicates an obsolete definition, but it permits
>>>> new/continued implementation in order to foster interoperability
>>>> with older/existing implementations.
>>>>
>>>> o "obsolete" means that the definition is obsolete and SHOULD NOT be
>>>> implemented and/or can be removed from implementations.
>>>>
>>>> If no status is specified, the default is "current".
>>>>
>>>> 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
>>>> }
>>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
