Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Martin Thomson <[e-mail]>]

On Thu, May 20, 2021, at 11:32, Brian Dickson wrote:
> Is it one of those things that are "Well, we think we might need 
> something", or is it "We already know something we need"?

The former is definitely a factor.  Though you might reasonably say that defining another HTTPSv2 codepoint is feasible, that path doesn't scale particularly well.

For the latter, there is a fairly long list of things that don't have enough substance to be really defensible.

Off the cuff, we have discussed in TLS some options that would improve performance and reliability.  It's not clear whether those would fall into extension codepoints on the ECH configuration or the SVCB/HTTPS record.  In QUIC, we are discussing whether ALPN binds to QUIC versions and the implications of that.  Some versions of AltSvc designs relied on QUIC version indications there.  The outcome of that discussion might point toward needing more parameters on HTTPS for QUIC version negotiation.
 
I would have thought that the former would be sufficient in this case.  The fact that this space has been static an unmovable in the past has repressed a bunch of opportunities.  Locking this down now would return us to that state and would be exceedingly unwise (at least in my view).

Note that I say that as someone who generally tries to avoid creating extension points.  But I've been convinced that extensibility is perhaps the key feature that SVCB delivers.  I'm surprised to find that you think otherwise.