Andy Bierman writes:
>The reason the status-stmt is broken is because status=obsolete is not
>inherited from the parent. The status obsolete means it is gone from the
>server.
No: '"obsolete" means that the definition is obsolete and SHOULD NOT be
implemented and/or can be removed from implementations.' It's not
gone, just that it _can_ be removed.
>Since YANG data is hierarchical, any descendants of the obsolete node
>are no longer accessible in any way.
This is not true. "deprecated" and "obsolete" nodes can continue
to exist for decades. They are accessible by normal mechanisms.
The "status" affects expectations, not implementations, which
tend to not remove features that might affect paying customers.
In any case, my main contention is that the rule:
If a definition is "current", it MUST NOT reference a "deprecated" or
"obsolete" definition within the same module
is not workable, since nodes may need to reference deprecated and
obsolete nodes to block the interactions between new and old nodes,
as depicted in my example.
Thanks,
Phil
>On Wed, Jan 18, 2017 at 1:32 PM, Phil Shafer <[email protected]> wrote:
>> Martin Bjorklund writes:
>> >But marking definition as obsolete in one module cannot automatically
>> >make definitions in *other* modules obsolete.
>> >
>> >(*) _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.
>>
>> That's a massively deforming interpretation of "references".
>>
>> I'm not even sure this is a good rule at all. Consider:
>>
>> leaf old-stuff {
>> status deprecated;
>> must not(../new-stuff);
>> }
>> leaf new-stuff {
>> must not(../old-stuff);
>> }
>>
>> My new-stuff definitely references old-stuff which is deprecated,
>> but this is a _good_ data model and should not be "MUST NOT"d out
>> of existence.
>>
>> Thanks,
>> Phil
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
