Early Review of draft-ietf-alto-new-transport-01
review-ietf-alto-new-transport-01-artart-early-dawkins-2022-07-15-00

Request Review of draft-ietf-alto-new-transport
Requested revision No specific revision (document currently at 22)
Type Early Review
Team ART Area Review Team (artart)
Deadline 2022-07-15
Requested 2022-06-22
Requested by Mohamed Boucadair
Authors Kai Gao , Roland Schott , Y. Richard Yang , Lauren Delwiche , Lachlan Keller
I-D last updated 2022-07-15
Completed reviews Httpdir Last Call review of -14 by Martin Thomson (diff)
Secdir Last Call review of -15 by Donald E. Eastlake 3rd (diff)
Genart Last Call review of -15 by Linda Dunbar (diff)
Iotdir Telechat review of -17 by Wesley Eddy (diff)
Intdir Telechat review of -16 by Bob Halley (diff)
Artart Early review of -01 by Spencer Dawkins (diff)
Secdir Early review of -07 by Donald E. Eastlake 3rd (diff)
Opsdir Early review of -07 by Sheng Jiang (diff)
Rtgdir Early review of -07 by Russ White (diff)
Tsvart Early review of -07 by Dr. Bernard D. Aboba (diff)
Artart Early review of -07 by Spencer Dawkins (diff)
Httpdir Early review of -07 by Martin Thomson (diff)
Comments 
We are seeking for this review so that issues/advice are taken into account early in the process.

We are particularly interested in comments about the handling of H3, especially with regards to the guidelines in RFC9250 about HTTP versioning.

The current version focuses on H2 with the intent to cover at least common H2/H3 functionalities.

Of course, comments related to other considerations in the draft are more than welcome.

Thank you
Assignment Reviewer Spencer Dawkins
State Completed
Request Early review on draft-ietf-alto-new-transport by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/kdQlNP06sqJDVcBFqHi-3dLLJj4
Reviewed revision 01 (document currently at 22)
Result Ready w/issues
Completed 2022-07-15
review-ietf-alto-new-transport-01-artart-early-dawkins-2022-07-15-00
My apologies for a late early review(!?!).

I might be confused about this, but I see that this specification uses these
HTTP2 settings

0x02     SETTINGS_ENABLE_PUSH (a BCP14 “MUST”), and
0x03     SETTINGS_MAX_CONCURRENT_STREAMS (a BCP14 “must”)

RFC 9114 reserves these in the parallel HTTP/3 registry
(https://www.rfc-editor.org/rfc/rfc9114.html#iana-setting-table), and says this
about these reserved values in
https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.1:

7.2.4.1. Defined SETTINGS Parameters

Setting identifiers that were defined in [HTTP/2] where there is no
corresponding HTTP/3 setting have also been reserved (Section 11.2.2). These
reserved settings MUST NOT be sent, and their receipt MUST be treated as a
connection error of type H3_SETTINGS_ERROR.

Is that going to be a problem?

I’m also wondering if you need in-order delivery of results across multiple
QUIC streams. If you do, could you please let me know?

I hope this is helpful.

p.s. I should also let someone know that the HTML version of this draft says
it's -00 in the heading, but the date matches the date for -01, so I THINK I
was looking at the right version, but I've never seen that before.