Subject: Working Group Last Call: QUIC protocol drafts -30/-17

From: Lars Eggert <[email-masked]>
Date: Thu, 17 Sep 2020 10:51:54 +0300

Hello,

this email announces a Working Group Last Call (WGLC) for the following QUIC documents:

* QUIC Transport
  https://tools.ietf.org/html/draft-ietf-quic-transport-30

* QUIC Loss Detection and Congestion Control
  https://tools.ietf.org/html/draft-ietf-quic-recovery-30

* Using TLS to Secure QUIC
  https://tools.ietf.org/html/draft-ietf-quic-tls-30

* Version-Independent Properties of QUIC
  https://tools.ietf.org/html/draft-ietf-quic-invariants-30

* HTTP/3
  https://tools.ietf.org/html/draft-ietf-quic-http-30

* QPACK Header Compression for HTTP/3
  https://tools.ietf.org/html/draft-ietf-quic-qpack-17

The WGLC will run for one week, ending on 24 September 2020.

Please review the documents above and open individual issues for each of your review comments in our repository at https://github.com/quicwg/base-drafts. You may also send comments to [email-masked], but we'd appreciate individual GitHub issues if at all possible.

As a reminder, we have been operating under the Late-Stage Process; see https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#late-stage-process. In theory, this means that the contents of the drafts above already have consensus. However, the Chairs would like to actively reaffirm that consensus and start the process of wider review through a formal WGLC. Issues raised during WGLC will be handled in accordance with the Late-Stage Process defined in the Contribution Guidelines (see link above). Please note that design issues that revisit a topic where there's already declared consensus (see https://github.com/quicwg/base-drafts/issues?q=is%3Aclosed+label%3Ahas-consensus) need to provide compelling reasons to warrant reopening the discussion.

As part of this WGLC, we seek consensus on the following remaining open design issues and their proposed resolutions:

* #4099: Should invalid TP result in FRAME_ENCODING_ERROR?
  https://github.com/quicwg/base-drafts/issues/4099
  Proposed resolution: https://github.com/quicwg/base-drafts/pull/4100

* #4087: Conflicting error codes
  https://github.com/quicwg/base-drafts/issues/4087
  Proposed resolution: https://github.com/quicwg/base-drafts/pull/4088

* #4076: IP restrictions on Tokens makes them of limited use for non-anycast DNS load balancing
  https://github.com/quicwg/base-drafts/issues/4076
  Proposed resolution: https://github.com/quicwg/base-drafts/pull/4089
  (Note that PR #4089 was already merged by mistake; if the WGLC determines there
  is no consensus, this will be rolled back.)

Cheers,
Lars, Lucas and Mark
QUIC WG Chairs

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 21 Sep 2020 18:53:16 +0100

>    https://tools.ietf.org/html/draft-ietf-quic-invariants-30

<snip>

I have read Version-Independent Properties of QUIC (-30) in the WGLC and 
think this is ready, I found 3 editorial comments that might need 
consideration after the WGLC:

(i) I suggest the introduction for this spec starts abruptly. Is it 
worth considering one sentence top explain what QUIC is, in case someone 
read this document first? - One possible solution could be to move the 
text in section 3 to section 1? (To me, the section 3 text does not need 
to come after the Section 2 definitions.)

(ii) Does this read better with /for/ moved within the sentence?
OLD:/At the endpoint, the connection ID is used to identify which QUIC 
connection the packet is intended for./
NEW:/At the  endpoint, the connection ID is used to identify the QUIC 
connection for which  the packet is intended./

(iii) I see the desire to emphasise the “NOT”, but I query if this is 
correct usage of a RFC2119 keyword in Appendix A?:
/The following statements are NOT guaranteed to be true for every QUIC
    version:/

Best wishes,

Gorry

---

From: Lars Eggert <[email-masked]>
Date: Tue, 22 Sep 2020 10:36:41 +0300

Hi,

I opened the following three issues to track the discussion/resolutions on these comments:

On 2020-9-21, at 20:53, Gorry Fairhurst <[email-masked]> wrote:
> (i) I suggest the introduction for this spec starts abruptly. Is it worth considering one sentence top explain what QUIC is, in case someone read this document first? - One possible solution could be to move the text in section 3 to section 1? (To me, the section 3 text does not need to come after the Section 2 definitions.)

https://github.com/quicwg/base-drafts/issues/4118

> OLD:/At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for./
> NEW:/At the  endpoint, the connection ID is used to identify the QUIC connection for which  the packet is intended./

https://github.com/quicwg/base-drafts/issues/4119

> (iii) I see the desire to emphasise the “NOT”, but I query if this is correct usage of a RFC2119 keyword in Appendix A?:

https://github.com/quicwg/base-drafts/issues/4120

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Sep 2020 12:06:47 +0300

Hi,

> The WGLC will run for one week, ending on 24 September 2020.

the WGLC has concluded, confirming consensus for the documents above (with -invariants being at version -10 and not -30; copy&paste error, sorry).

>  is no consensus, this will be rolled back.)

Thanks,
Lars (for the chairs)