My preference would be the change in 289. Maximizes keeping things open for future protocols rather than attempting to predict the needs of the protocols.
On Fri, Jan 15, 2021 at 2:02 PM Ben Schwartz <bemasc= [email protected]> wrote: > 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
