> 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? > 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.). Kent // contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
