Hi there all, I was really hoping that it wouldn't come to this, but…
We approved draft-ietf-dnsop-svcb-https on 2022-05-22, and has been stuck in MISREF state ever since[0], waiting on draft-ietf-tls-esni - "TLS Encrypted Client Hello" <https://datatracker.ietf.org/doc/draft-ietf-tls-esni/> . This is basically as long as it takes to make a whole person… There are multiple documents in the RFC Editor queue waiting on the svcb-https document: https://www.rfc-editor.org/cluster_info.php?cid=C461. Unfortunately it now seems that tls-esni is not likely to be published anytime soon because they want deployment experience before advancing it, and that's not going to happen for some months. This means that the svcb-https document, and, by extension, the other documents in the cluster will be stuck for an indeterminate amount of time. The part of svcb-https that "needs" tls-esni is sort of an optional feature, and none of the other documents in this cluster seem to rely on it. 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…. W [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 [1]: While we prefer not do to this sort of thing, we have done it before - as an example: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/history/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
