I support this plan, and am eager to see the logjam unblocked! The mechanism for how we reintroduce the ECH option for SVCB can be debated separately. I like the idea of a separate small document, but can also see it being in the TLS draft or a bis of the SVCB document. Mainly that’s a question of who will spend the time to do the work, and where it will be easiest to get done.
Tommy > On Feb 24, 2023, at 6:33 AM, Ralf Weber <d...@fl1ger.de> wrote: > > Moin! > >> On 23 Feb 2023, at 18:39, Warren Kumari wrote: >> Instead of just having all of these document stuck indefinitely, I'm >> proposing that we: >> 1: Ask the RFC Editor to return the document to the IESG & IETF[1]. >> 2: I return it to the WG. >> 3: The authors remove the bits that rely on ESNI >> 4: The document progresses "normally" - it gets another WGLC, IETF LC, IESG >> Eval, etc. Hopefully this can be expedited - it's already gone though all >> of these steps once, and the updated document would be very similar to the >> original. >> >> 5: If / when tls-esni is published, the svcb-https authors submit a -bis >> (while will likely just be 'git checkout <current_version>'), and we >> progress this just like any other WG document. >> >> I've discussed this with the authors of the documents, the DNSOP and TLS >> chairs, the relevant ADs and the full IESG. >> >> However, before doing all this, I'd like to confirm that the WG doesn't >> object to the plan…. > > I agree with this plan and as SVCB is already widely deployed and we need an > RFC to point to and not a draft to get people not doing stupid things with it. > > So long > -Ralf > ——- > Ralf Weber > > _______________________________________________ > 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
