Top posting to assure everyone reads: I don’t think I could of come up with a better strategy to guarantee that IETF YANG models aren’t used if I tried. We’ll still specify them in IETF document and they’ll provide a useful reference model for other SDOs and vendor native models, but no one is going to implement and deploy them.
Thanks, Acee From: netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman <a...@yumaworks.com> Date: Friday, December 9, 2022 at 11:19 AM To: Kent Watsen <kent+i...@watsen.net> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen <kent+i...@watsen.net<mailto:kent%2bi...@watsen.net>> wrote: The idea to encode all relevant semantics of a type in a type's name has far-reaching consequences: - Are we going to deprecate counter32 and introduce non-zero-based-counter32 because we have also zero-based-counter32? - Do we introduce date-and-time-with-optional-zone-offset and deprecate date-and-time? I wish we had guiding principles for such naming decisions or, perhaps, it is a matter of the type's definition. The current date-and-time is not ambiguous because it asserts that either a 'Z' or an offset is present, making impossible for implementations to assume a zoneless form. Whereas the current ip-address is ambiguous because it silently accepts the "without" form, leading to surprise in some implementations when the expanded form is "unexpectedly" passed. Having well-defined guidance could prevent future missteps. The definition of ip-address (published in 2010) was the right thing to do since the optional zone index can disambiguate IP addresses in situations where this is needed. In 2013, we also provided the ip-address-no-zone definition to be used in situations where there is never a need to disambiguate IP addresses (e.g., when the zone is known from the context). Trying to focus just on this proposal, not extrapolate the trend... For 10 years we have had 2 typedefs for IP address: - ip-address - ip-address-no-zone This should be enough (even without reading the module!) to determine 1 form has a zone, and 1 does not. But nobody reads the YANG module so they didn't know about ip-address-no-zone. So how will they know about ip-address-zone either? Because tooling would flag "ip-address" as deprecated and the description statement would say to use the "with-zone" form? There is no reason to deprecate something to replace it with the exact same semantics, but a different name. The only reason to deprecate something is because it will be removed in the future, Deprecating and obsoleting such a critical data type would be highly disruptive. Many vendors and SDOs may refuse to do it. YANG Catalog search shows 1486 modules import the ip-address typedef. I suspect the number is about twice that. So we want to tell the world: "You have to stop using ip-address and use this new type instead". "Why? What's wrong with it?" "Nothing. We decided after 13 years we like this name better." A number of issues were raised (misconfigurations, OpenConfig, etc.). What are these operational problems that are caused because of the name ip-address? IMO it would be far worse to take away the most important typedef in YANG. We have never heard any issues at all from customers about problems implementing ip-address. As Martin pointed out, the server MUST check for values such as 0.0.0.0 that are accepted by the typedef pattern but not the leaf semantics. Checking for a zone index is no different. The ip-address typedef has been clarified in the draft update. That is sufficient. Kent // contributor Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
