Barry Leiba's Yes on draft-ietf-quic-transport-33: (with COMMENT)

Barry Leiba via Datatracker <> Wed, 06 January 2021 00:02 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 5D59B3A0EE6; Tue, 5 Jan 2021 16:02:06 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <>
To: The IESG <>
Subject: Barry Leiba's Yes on draft-ietf-quic-transport-33: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <>
Message-ID: <>
Date: Tue, 05 Jan 2021 16:02:06 -0800
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2021 00:02:07 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-quic-transport-33: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks for the great work on this important protocol, and for a very well
written document!  Just some very minor editorial comments:

— Section 3.5 —
   An endpoint SHOULD copy the error code from the STOP_SENDING frame to
   the RESET_STREAM frame it sends, but MAY use any application error

— Section 9.6.2 —
   It SHOULD drop packets
   for this connection received on the old IP address, but MAY continue
   to process delayed packets.

Do as you think best with cases such as these, but for my part, I dislike the
“SHOULD... but MAY” formulation, as I find it contradictory when it’s read
strictly.  In general, I prefer to simply avoid the BCP 14 key word for the
second part (“SHOULD do x, but may make other choices”).  In both cases here,
I’d probably just leave off the second part, as it doesn’t seem to add
anything.  At the least, I encourage making it “may” (or “can”).  But again, as
you think best.

— Section 4 —

   It is necessary to limit the amount of data that a receiver could
   buffer, to prevent a fast sender from overwhelming a slow receiver,
   or to prevent a malicious sender from consuming a large amount of
   memory at a receiver.

You’re not talking about limiting the ability of the receiver (“could buffer”),
but limiting the potential buffering requirement on the client (“has to
buffer”), yes?

— Section 4.1 —

   Once a receiver advertises a limit for the connection or a stream, it
   MAY advertise a smaller limit, but this has no effect.

I don’t think this really fits the spirit of “MAY”.  I would say, “it is not an
error to advertise a smaller limit, but....”

— Section 7 —

   Once completed, endpoints are able to exchange
   application data.

The antecedent to “once completed” is dangling, and the previous sentence talks
about exchanging application data earlier.  I suggest, “Once the handshake is
completed, endpoints are able to exchange application data freely.”