I'm OK with this, although personally I'm happy to just wait for ECH. I had hoped for a simpler solution (like marking SVCB's dependency on ECH as Informative), but I can understand if the IESG thinks there's no other way.
If we are chopping the ECH parts out of SVCB, I would prefer to publish them later as a separate document, rather than stuffing them into ECH or opening a SVCB-bis. I think that will be clearer for readers and will minimize further delays. On Thu, Feb 23, 2023 at 12:39 PM Warren Kumari <war...@kumari.net> wrote: > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
