On Thu, Apr 07, 2022 at 08:39:01AM +0000, Kent Watsen wrote: > > Juergen et. al. , > > > What are our options? > > > > a) Do nothing and accept that types are called as they are. > > b) Change the types as suggested and accept that doing so breaks > > modules where zone indexes are meaningful. > > c) Deprecate the types and create a new module defining new types > > so that modules can opt-in to use better names. > > d) Deprecate the -no-zone types and move back to have a single > > type for IP addresses. > > What’s the value of (d)? Seems like keeping is better, if only to guide > readers towards knowing the base types include zones. And, besides, any > module-designer wishing to restrict zones would then have to create their own > “no-zone” types. >
I added d) for completeness. > > Any other options? > > e) define new types “*-with-zone” > and deprecate existing “ip*-address” types and recast the “*-no-zone” types > as derived from the *-with-zone types? This way it is always a conscious > decision. Yes, looks like a valid 5th option. My understanding is that we currently enumerate the options, not their pros and cons and whether we like them or not. > > How are we going to pick between them? > > I don’t think Errata works, since 6991 defining the *-no-zone types makes it > clear what intended. Yes, my understanding is that the type definitions are clear and unambiguous. The issue is that the names tend to mislead people. /js -- 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
