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.
/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
