Subject: I-D Action: draft-ietf-quic-transport-33.txt

From: [email-masked]
Date: Sun, 13 Dec 2020 15:23:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC WG of the IETF.

        Title           : QUIC: A UDP-Based Multiplexed and Secure Transport
        Authors         : Jana Iyengar
                          Martin Thomson
	Filename        : draft-ietf-quic-transport-33.txt
	Pages           : 206
	Date            : 2020-12-13

Abstract:
   This document defines the core of the QUIC transport protocol.  QUIC
   provides applications with flow-controlled streams for structured
   communication, low-latency connection establishment, and network path
   migration.  QUIC includes security measures that ensure
   confidentiality, integrity, and availability in a range of deployment
   circumstances.  Accompanying documents describe the integration of
   TLS for key negotiation, loss detection, and an exemplary congestion
   control algorithm.

DO NOT DEPLOY THIS VERSION OF QUIC

   DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC.  This
   verion is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list ([email-masked] (mailto:[email-masked])), which is
   archived at https://mailarchive.ietf.org/arch/search/?email_list=quic

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-transport.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-quic-transport-33.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-33

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 14 Dec 2020 10:29:27 +1100

Just to keep everyone here in the loop, this is the version we're going to give to the IESG.

It is final in every way, except for the little bit I've quoted here:

>    verion is still a work in progress.  For trial deployments, please

(And yeah, I can see the typo *now*.)

In any case, please respect this request.  I doubt that the IESG will ask for disruptive changes (or that we'll tolerate them), but we want to reserve the option of doing so.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 14 Dec 2020 10:33:15 +1100

And I forgot the other thing.

The latest update only includes the base protocol.  Magnus is taking the documents in two phases and the first includes only -invariants, -transport, -tls, and -recovery.

There are a few changes to the http-core documents that we want to get the HTTP draft aligned with.  We've been promised an update to that this week and so we've delayed -http and -qpack for a couple of days.

On Mon, Dec 14, 2020, at 10:29, Martin Thomson wrote:
> In any case, please respect this request.  I doubt that the IESG will 
> ask for disruptive changes (or that we'll tolerate them), but we want 
> to reserve the option of doing so.
> 
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 13 Dec 2020 16:11:35 -0800

Just skimming through the doc (it has version 1 in it!)

Sec. 12.4 Frames and Frame Types

regarding rule of shortest encoding form of frame type:

"This rule applies to all current and future QUIC frame types. An endpoint
MAY treat the receipt of a frame type that uses a longer encoding than
necessary as a connection error of type PROTOCOL_VIOLATION.”

I do appreciate shortest encoding form here, but how can QUIC v1 decide how
future frames are encoded without placing that rule in invariants? Does it
refer to extensions, or to future QUIC versions?

Mikkel

On 14 December 2020 at 00.33.57, Martin Thomson ([email-masked]) wrote:

The latest update only includes the base protocol. Magnus is taking the
documents in two phases and the first includes only -invariants,
-transport, -tls, and -recovery.

There are a few changes to the http-core documents that we want to get the
HTTP draft aligned with. We've been promised an update to that this week
and so we've delayed -http and -qpack for a couple of days.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 14 Dec 2020 11:16:38 +1100

On Mon, Dec 14, 2020, at 11:11, Mikkel Fahnøe Jørgensen wrote:
> I do appreciate shortest encoding form here, but how can QUIC v1 decide 
> how future frames are encoded without placing that rule in invariants? 
> Does it refer to extensions, or to future QUIC versions?

The rules regarding frame encoding can only apply to this version of QUIC.  Another version might not even have frames.  This refers to frames that might - in the future - be defined as extensions to QUIC version 1.