I agree with the "ecb-in-svcb" document over a -bis, as the (soon to exist) registry states only expert review.
The one thing we have not discussed is Warren's comment [0] Possibly modulo the annoyingly painful "AliasMode clarification" change: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-10&url2=draft-ietf-dnsop-svcb-https-11&difftype=--html On Thu, Feb 23, 2023 at 4:25 PM Benjamin Schwartz <i...@bemasc.net> wrote: > On Thu, Feb 23, 2023 at 1:41 PM David Schinazi <dschinazi.i...@gmail.com> > wrote: > >> Moving the ECH/ESNI bits from draft-ietf-dnsop-svcb-https >> to draft-ietf-tls-esni seems to be the simplest option by far here. I >> strongly support that. >> David >> > > Currently, draft-ietf-tls-esni runs to 40 pages excluding the references > and appendices. I think we would do well to avoid making it even longer. > Also, the integration requirements touch on very different subject matter > from the ECH draft. In addition to defining and registering a SvcParamKey, > the text in question also discusses how enabling ECH via SVCB alters the > SVCB client retry logic and HTTP Alt-Svc processing, along with several > examples. > > More broadly, I think it's logical for ECH, like TLS itself, to be > specified without reference to DNS. We have a very nice abstraction > boundary here, and we might as well use it. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
