From: Andy Bierman <a...@yumaworks.com> Sent: 26 February 2021 14:57 To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>; Rob Wilton (rwilton) <rwil...@cisco.com>; netmod@ietf.org Subject: Re: [netmod] type equivalence
On Fri, Feb 26, 2021 at 3:45 AM Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>> wrote: On Fri, Feb 26, 2021 at 11:31:58AM +0000, Rob Wilton (rwilton) wrote: > > I also note that draft-ietf-netmod-yang-module-versioning-02 states: > > This document updates [RFC7950] section 11. Section 3 describes > modifications to YANG revision handling and update rules, and > Section 4 describes a YANG extension statement to do import by > derived revision. > > So, I'm still of the opinion that clarifying this behaviour in > draft-ietf-netmod-yang-module-versioning-02, if the proposed change cannot be > accepted as a verified errata, is a pragmatic solution. > This document has a long way to go. I am not sure everybody agrees with changing YANG 1.1 rules by an update (without changing YANG's version number, i.e., it becomes upclear which rules apply to a given YANG module). I do not think an update of any kind can brush aside MUST and MUST NOT details in the updated RFC. [RW] In the general case, I don’t believe this is correct. E.g., some bits in a protocol header that are reserved for future use and are specified as the sender MUST set to 0, and receiver MUST ignore. Then an extension comes along and wants to make use of those bits, updating, but not obsoleting, the base RFC. Or a more recent case, not directly related to RFC 2119 language, is changing an existing IANA registry from Vendor Private Use to FCFS. This was done by updating the base RFC. Specifically, the module-versioning draft is not trying to create a new version of YANG but fix issues and make it better for clients: E.g., in RFC 7950, a vendor is allowed to move from status current to obsolete immediately, at which point the server SHOULD NOT implement the node. This would have pretty much the same impact on clients as just deleting the node. I believe that draft-ietf-netmod-yang-module-versioning-02 improves on RFC 7950 by requiring this breaking change to be flagged in the module history as NBC, and gives serves the ability to advertise that they don’t implement obsolete nodes. In addition, servers can implement or not implement status deprecated nodes, and they do not need to flag to clients whether or not that node is implemented: E.g. leaf foo { type string; mandatory true; status deprecated; } leaf bar { type string; mandatory true; status deprecated; } Two RFC 7950 compliant servers: * The first implements foo but not bar. The second implements bar but not foo. Clients do not know which leaves are implemented by the server, and implementing neither/both doesn’t help since it will always fail on one server. draft-ietf-netmod-yang-module-versioning-02 aims on improving RFC 7950 by requiring that status deprecated nodes are always implemented or explicitly deprecated, so that API to the client is always well defined. It also attempts to ensure that this information about deprecated leaves being implemented is communicated to clients in a backwards compatible way via an augmentation to YANG library. Regards, Rob
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
