On 2017-12-01 18:49, Andy Bierman wrote:


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.


Andy

BALAZS: Yes, IMHO it should be generalized.
-- 
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

Reply via email to