[DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

[Warren Kumari <[e-mail]>]

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/