Kent,
On 4/7/22, 4:39 AM, "Kent Watsen" <k...@watsen.net> 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.
We already a large number of models that use the existing inet:ip-address types
whose implementations don't support the zone. Why should we start using this
esoteric "no-zone" types in new models? Note you have RFC 9127 BIS going to
through IESG right now... Better to fix it in one place (actually three, since
there is ipv4-address, ipv6-address, and ip-address) then in who knows how many
since many vendors import ietf-inet-types in their native models.
Thanks,
Acee
> 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.
> 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.
Kent (hatless)
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
