On Fri, Dec 1, 2017 at 3:37 AM, Balazs Lengyel <[email protected]>
wrote:

> Hello,
>
> https://tools.ietf.org/html/rfc7950#section-7.21.2
>
>    o  "deprecated" indicates an obsolete definition, but it permits
>       new/continued implementation in order to foster interoperability
>       with older/existing implementations.
>
> This means that a node that is deprecated MAY or MAY NOT be implemented.
> YANG is considered an interface contract,  however "maybe implemented" is
> unusable in a contract.
>

I agree that the status-stmt is mostly worthless the way it is defined in
RFC 7950.
The good news is that the text in RFC 2578 (which it is based on) is much
worse,
so we are getting better over time.

The word "permits", rather than "requires" indicates this is a MAY, not
even a SHOULD,
and certain not a MUST.

YANG already has a statement defined for indicating such optional support:
> the feature statement.
> Deprecated works as if there would be an if-feature statement on each
> deprecated schema node
> where the server does not advertise whether the feature is supported of
> not. Why is it not advertised?
>
> I would like to propose to use a feature here. This would allow the
> client to understand if the container interfaces-state is implemented or
> not.
>
> module ietf-interfaces {
>    feature pre-nmda-support {
>        description "The feature indicates that
>           schema parts representing state information
>           are deprecated but are still implemented."
>    }
>
>    container interfaces {...}
>
>    container interfaces-state {
>       if-feature pre-nmda-support ;
>       status deprecated;
>       ...
>  }
> }
>
>

This proposal seems useful. Maybe it could be generalized,
because the issue is status=deprecated, not NMDA.



>  regards Balazs
>
>

Andy



> On 2017-11-28 20:29, Kent Watsen wrote:
>
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-rfc7223bis-00.
>
> Please recall that this update's intention is to
> modify the YANG module to be in line with the NMDA
> guidelines [1].  Reviewing the diff between the two
> drafts [2] should reveal just this.
>
> The working group last call ends on December 12.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
> [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt
>
> Thank you,
> Netmod Chairs
>
>
> _______________________________________________
> netmod mailing [email protected]https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: [email protected]
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to