Jürgen and netmod WG, +IESG, It is not just the IETF models that are using the inet:ip-address for the standard IPv4/IPv6 addresses without zones. Every vendor’s native models and the OpenConfig models use the base types and expect the standard IP address notation. If we don’t fix this, it is something that people can point to as another example of the IETF being out of touch with reality.
I thought about more, and it might make the backward compatibility easier if we just leave the existing ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone types and add *-zone types for the remote possibility that someone actually wants to include the zone. In the existing RFC 6991 BIS document, we could merely remove the zone from the ip-address, ipv4-address, and ipv6-address types and classify this as we would any other bug fix. While including the zone was the original intent of the base types, this is what those of us who work on software products would classify as a requirements bug. Thanks, Acee From: Andy Bierman <a...@yumaworks.com> Date: Tuesday, April 5, 2022 at 3:21 PM To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>, Andy Bierman <a...@yumaworks.com>, Acee Lindem <a...@cisco.com>, "l...@ietf.org" <l...@ietf.org>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>> wrote: On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote: > > > > The best outcome would be to fix ip-address to not include the zone, > > introduce ip-address-zone, and deprecate ip-address-no-zone. My take all > > the is that all the existing usages do not require zone and this would be a > > fix as opposed to a change. > > > > > I don't think this will harm our implementations. > The type is still string. The pattern will change but that is handled by a > library. > Whatever pattern is used will get handled the same way. Either a zone is allowed to be present or it is not, this does make a difference, its not a cosmetic change. True. The code will probably accept the pattern then fail trying to use the string. If the client sends the form with a zone. > The same problem exists for 'date' and 'date-no-zone' types, > but they are not used very much. Perhaps we should call types a, b, c, and so on - this may force people to read the descriptions. ;-) For some reason, the smarter the person, the less likely they are to read any of the documentation before using some software. I call it the "it should work the way I would design it" phenomenon :-) You have to admit that Acee's suggestion is more intuitive than the current definitions. Clearly an NBC change. IMO it is more useful to put some YANG extension magic in these specific typedefs than just bumping a major revision number. This is a great use-case for the version DT. There probably is no solution path where nobody has to change any YANG or any code and everything still works. /js Andy -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
