Roman Danyliw's Yes on draft-ietf-quic-http-33: (with COMMENT)

Roman Danyliw via Datatracker <> Tue, 19 January 2021 23:28 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3D24F3A1879; Tue, 19 Jan 2021 15:28:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <>
To: The IESG <>
Subject: Roman Danyliw's Yes on draft-ietf-quic-http-33: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <>
Message-ID: <>
Date: Tue, 19 Jan 2021 15:28:37 -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: Tue, 19 Jan 2021 23:28:37 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-quic-http-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:


The work on this document and its companions is greatly appreciated!

Thank you to Hilarie Orman for the SECDIR review.

** Section 3.1.  “The host must be listed either as the CN field …”, why not a
normative MUST just as there is in the next sentence around the required use of

** Section 3.3  Per “Once a connection exists to a server endpoint, this
connection MAY be reused for requests with multiple different URI authority
components”, it might be worth repeating here that in cases of https, changes
in the authority components still need to occur within the bounds of the
certificate validation practices noted in Section 3.1 and in Section 4.3.4 of