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

[Warren Kumari]

[ Top-post ]


On Thu, Feb 23, 2023 at 12:39 PM, Warren Kumari  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"
>  .  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 '), 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=draft-ietf-dnsop-svcb-https-11=--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

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

[Tommy Pauly]

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  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 '), 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

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

[Ralf Weber]

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 '), 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

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

[Martin Thomson]

On Fri, Feb 24, 2023, at 05:03, Christopher Wood wrote:
> +1 to this plan. Once the ECH content is removed from this draft, the 
> authors of draft-ietf-tls-esni will work to incorporate it there as 
> necessary. 

Warren's proposed plan is good.

I'm less sure about the various options for documenting the intersection of ECH 
and SVCB (three so far have been suggested, all of which have drawbacks). This 
could be treated as a question of paper shuffling where document editors can be 
given some freedom, so I am happy to await the first proposed draft on the 
subject rather than try to litigate it here.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Benjamin Schwartz]

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  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"
>  .  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 '), 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=draft-ietf-dnsop-svcb-https-11=--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

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

[Christopher Wood]

+1 to this plan. Once the ECH content is removed from this draft, the authors 
of draft-ietf-tls-esni will work to incorporate it there as necessary. 

Best,
Chris

> On Feb 23, 2023, at 12:57 PM, Tim Wicinski  wrote:
> 
> Thanks Warren for chasing all this process. 
> 
> Tim
> 
> 
> On Thu, Feb 23, 2023 at 12:54 PM Joe Abley  wrote:
> 
> On Thu, Feb 23, 2023 at 12: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 '), 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….
> 
> This sounds like a good plan to me. 
> 
> 
> Joe
> ___
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

Thanks Warren for chasing all this process.

Tim


On Thu, Feb 23, 2023 at 12:54 PM Joe Abley  wrote:

>
> On Thu, Feb 23, 2023 at 12: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 '), 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….
>
>
> This sounds like a good plan to me.
>
>
> Joe
>
> ___
> 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

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

[Joe Abley]

On Thu, Feb 23, 2023 at 12: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 '), 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….

This sounds like a good plan to me.

Joe

>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

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"
 .  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 '), 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=draft-ietf-dnsop-svcb-https-11=--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