Subject: Dealing with Design issues following Last Call

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 Dec 2020 19:22:33 +0000

Hi Folks

Following the IETF Last Call, we have been working through the issues
raised against the core QUIC specifications. There are some Design issues,
listed below, and we've received input from the WG (and others) that has
led to proposed resolution via PRs.

* Idempotency and replay - https://github.com/quicwg/base-drafts/issues/4393

* IANA review of -transport; question 3 -
https://github.com/quicwg/base-drafts/issues/4378

* IANA review of -tls - https://github.com/quicwg/base-drafts/issues/4369

* Error code for illegal field composition -
https://github.com/quicwg/base-drafts/issues/4336

* No IANA version registry -
https://github.com/quicwg/base-drafts/issues/4280

* Path Challenge Padding and Amplification Protection -
https://github.com/quicwg/base-drafts/issues/4257

We are preparing the QUIC documents and intend to cut a new set of drafts
for our Area Director, Magnus Westerlund, to take forward to the IESG.
Rather than issue a WG consensus call for the above design issues, we plan
to merge the associated PRs, mark the issues as "call-issued" and leave
them open until the IESG review period concludes.

Cheers
Lars & Lucas
QUIC WG Co-chairs

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 18 Dec 2020 15:11:31 -0500

Hi Lucas,

Could you please clear something up for me:

> them open until the IESG review period concludes.

And then what?  In other words, should I implement the changes associated
with 4257 or not?  The text is in transport-33, yet the issue is still
open.  I take it to mean that this change is not as solid as it could be
and it may be rolled back (otherwise, why leave the bug open?).  In this
case, implementing this may end up to be a waste of time.

  - Dmitri.

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 18 Dec 2020 20:39:58 +0000

Hey Dmitri,

> case, implementing this may end up to be a waste of time.

Draft-33 is effectively the proposed resolution to all issues opened during
the IETF Last Call. These are the documents that the IESG will review to
ensure we addressed last call comments. It's feasible, albeit hopefully
unlikely, that changes might be requested to the text that deals
specifically with those design issues. The IESG may also request other
changes as a result of their review, of course. The transport, tls,
recovery and invariants documents are on the agenda for the next IESG
telechat on 2021-01-07 [1].

I'd treat implementing draft 33 as trying to implement a PR before it was
merged, while the WG was running its late-stage process. There's a risk it
could change or be rolled back, it's upon implementers to decide if they
wish to bear that risk. I'll also highlight that draft 33 includes the note
"DO NOT DEPLOY THIS VERSION". That doesn't mean don't trial implement the
changes but it is a factor people should consider before investing effort
at this stage.

[1] https://datatracker.ietf.org/iesg/agenda/

Cheers
Lucas

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 18 Dec 2020 15:57:36 -0500

> [1] https://datatracker.ietf.org/iesg/agenda/

I see -- thank you for the explanation.  So if IESG requests changes,
there will be a -34?

> "DO NOT DEPLOY THIS VERSION".

Touche!  Although I merely want to *implement*, not deploy this version.

> That doesn't mean don't trial implement the changes but it is a factor
> people should consider before investing effort at this stage.

I am trying to prevent a situation where IESG approves -33 on one day and
the RFC is published two days later and we do not have the changes
implemented yet.  Then, we would really have to scramble!  Am I naive to
expect such speedy RFC turnaround?

  - Dmitri.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 18 Dec 2020 13:36:46 -0800

> expect such speedy RFC turnaround?

Typical delay between IESG approval and final publication is 3-4 months. 
Very rarely fewer than 2 months. Could be more if caught behind a big 
queue, or if authors and copy editors get in a long discussion.

-- Christian Huitema

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Dec 2020 13:50:36 -0800

On Fri, Dec 18, 2020 at 01:36:46PM -0800, Christian Huitema wrote:
> Very rarely fewer than 2 months. Could be more if caught behind a big queue,
> or if authors and copy editors get in a long discussion.

Indeed.

I think the fastest remotely plausible, with explicit requests to expedite things
and with authors very responsive during AUTH48, would be at least 3 weeks,
for a group of documents of this length.  (And I don't know of any desire to request
expedited processing anyway.)

-Ben

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 18 Dec 2020 16:55:37 -0500

Thank you, Christian, you've calmed my fears!

  - Dmitri.

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 18 Dec 2020 18:34:23 -0800

> the RFC is published two days later and we do not have the changes

https://media.giphy.com/media/H7ZafI4jatlyht8Tst/giphy.gif

---

From: Lars Eggert <[email-masked]>
Date: Sat, 19 Dec 2020 08:05:52 +0200

We were actually going to ask for expedited processing, but IIRC that needs to wait until after IESG approval.

-- 
Sent from a mobile device; please excuse typos.

> On Dec 18, 2020, at 23:51, Benjamin Kaduk <bkaduk=[email-masked]> wrote:
> 
> And I don't know of any desire to request
> expedited processing anyway.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 22 Dec 2020 10:17:01 -0500

> https://media.giphy.com/media/H7ZafI4jatlyht8Tst/giphy.gif

I don't believe I've seen this sitcom.

  - Dmitri.