[ Top-post ]
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. > Hi there all, The RFC Editor is still working on some tooling issues in order to "officially" return to the document to the IETF/WG, but in the mean time they have assured me that they will not progress it ("I will work on the fix now — but rest assured we will not work on this document until it returns."). So, consider the document returned to the WG. If the authors can implement the (already discussed) removal of the ESNI dependency then we can do a (presumably compressed) WGLC on the changes, an IETF LC, IESG eval and hand it back to the RFC Editor. When doing the IETF LC I'll request that people restrict their comments to just the changes, and the IESG will (presumably) do the same. As this is a returning item, I'm asking the chairs to please prioritize the WGLC. W 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
