We had a similar issue with DHCP and wrote an RFC talking about what the process should be for adding new options. It was fairly explicit about sub options, although didn’t come to quite the same conclusion that is being suggested here. https://datatracker.ietf.org/doc/bcp187/
FWIW I agree that sub option registries for dns seem like a bad idea in general. On Sun, Oct 19, 2025, at 3:31 PM, Shumon Huque wrote: > On Sun, Oct 19, 2025 at 6:01 AM Jim Reid <[email protected]> wrote: >> >> > On 19 Oct 2025, at 04:39, Viktor Dukhovni <[email protected]> wrote: >> > >> > My message to the WG is in essence to be sparing in defining RRTYPEs >> > with extensible field subtypes. >> >> I thought this WG decided a long time ago that subtyping was bad. It didn't >> get written up as an RFC though. > > The only IETF document I'm aware of that discusses this is RFC 3445, which > talks about the harms of subtyping, in the context of re-using the KEY RR for > DNSSEC (which later lead to the DNSKEY RR being defined). > > This is a bit different than the use of an extensible rdata type (service > param keys) in HTTPS. Though some of the 3445 arguments may apply to the more > general purpose SVCB record. > > I certainly agree with Viktor that extensible rdata formats pose significant > challenges for API design, and that we should be very cautious about defining > them. > > Shumon. > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
