On Thu, Dec 08, 2022 at 03:02:39AM +0000, Kent Watsen wrote: > > We are addressing the current/existing confusion, as discussed in the last 9 > months and in a virtual interim. Not doing anything would be truly unhelpful. > > The strategy is to gradually move towards having only explicit names. The > first step is to introduce a new explicit name, while deprecating the legacy > ambiguous name. This provides time for modules to slowly migrate to the new > name. The second step, to be done only after the "versioning" work lands, is > to remove the legacy deprecated name, while marking the module revision as > having an NBC change. >
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? - ... 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). And in 2023 we go and deprecate ip-address and introduce an identical ip-address-with-zone type and start a possible infinite conversion process? This all seems to be a bike-shed discussion. <https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality> /js -- Jürgen Schönwälder Constructor 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
