FWIW, I think this is really an editorial question. The SVCB draft lays out how we expect SVCB to be used initially, but there are very few constraints on how some future protocol specification could make use of the RR type. That includes the various possible fallback behaviors.
I'm happy to adjust the text for clarity on this point. Here are two alternatives for how to clarify the text: 1. Specify the expected behavior of future SVCB-reliant protocols (which do not yet exist): https://github.com/MikeBishop/dns-alt-svc/pull/288 2. Clarify that this section's recommendations are only defaults, and future protocols can do whatever they want: https://github.com/MikeBishop/dns-alt-svc/pull/289 On Thu, Jan 14, 2021 at 6:43 PM Martin Thomson <m...@lowentropy.net> wrote: > As requested (I'm not engaged here enough to understand the terms of > engagement, so my apologies for using an interaction form I'm accustomed > to), moving discussion from > https://github.com/MikeBishop/dns-alt-svc/issues/287 to here: > > The SVCB draft basically mandates a fallback to A/AAAA. I think that this > is not universal and that this should instead be made an option. > > For HTTP, the fallback is necessary. For a new protocol, a fallback could > be undesirable. Especially if you want to deploy that protocol using a > service name on which you have already deployed HTTP. If you don't want > your HTTP servers getting connection attempts for the new protocol, the > fallback is more nuisance than useful. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
