Hi Éric, Thanks for the review. I've captured your comments as issues on the QUIC WG GItHub repository. Links to each are provided as in-line responses.
I apologize for spelling your name with a 'k' not a 'c'. I've realized this only at the end of the issue-making process. I was so focused on getting the accent correct I missed that part. I'll get this fixed up soon. On Tue, Jan 5, 2021 at 11:12 AM Éric Vyncke via Datatracker < [email protected]> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-quic-transport-33: No Objection > > 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 https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this long but easy to read document. It is > clearly a major change for the Internet. > > Special thanks to Bernie Volz for his internet directorate review. > > I support Erik Kline's comments about sections 9.6.3 (interaction of NAT64 > and > preferred address) and 14.1 (IPv6 extension headers). > > Please bear with some comments from a non-transport oriented person... I > have > yet to review QUIC-RECOVERY so I will assume for now that packet loss by > the > network (such as RED) will also reduce the "QUIC congestion window". > > NB: I still wonder why QUIC is in upper case if it is a name and not an > acronym > ;-) > > Please find below some non-blocking COMMENT points (but replies would be > appreciated), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > -- Section 1 -- > "QUIC packets are carried in UDP datagrams ([UDP]) to better facilitate > deployment in existing systems and networks.", this is an assumption > presented > as a fact without citing any reference... This does not seem too good to > me. > https://github.com/quicwg/base-drafts/issues/4524 > -- Section 2.2 -- > "an endpoint MAY treat receipt of different data at > the same offset within a stream as a connection error of type > PROTOCOL_VIOLATION." > > Should it be a SHOULD or even a MUST rather than a MAY ? Even if streams > are > protected, isn't it a security issue to allow overwrite of a stream ? Esp > when > the endpoints could deliver out-of-order to the application ? > https://github.com/quicwg/base-drafts/issues/4525 > -- Section 3.1 (and others) -- > It would have been nice to use the SVG alternate graphic format for such an > fundamental document ;-) > https://github.com/quicwg/base-drafts/issues/4526 > -- Section 4.2 and others -- > The specification is rather vague about the behavior (no default timer, no > default "window", nothing said about increasing the credit, ...) and > leaves a > lot to implantations. Is it an issue or is it described in QUIC-RECOVERY ? > https://github.com/quicwg/base-drafts/issues/4527 > -- Section 5.1 -- > It would be nice for the reader to explain the rationale for having > multiple > connection IDs for the same connection. > https://github.com/quicwg/base-drafts/issues/4528 > -- Section 7 -- > Please state before that QUIC version 0x00000001 is the version specified > by > the document or use "This version of QUIC" rather than "Version 0x00000001 > of > QUIC" > > https://github.com/quicwg/base-drafts/issues/4529 -- Section 8.1 -- > Out of curiosity, why selecting a UDP payload of at least 1200 octets? I > would > assume that 1232 would have worked as well (1280 IPv6 MTU - 40 IPv6 header > - 8 > UDP header). Of course, 1200 is a nicer number ;-) > https://github.com/quicwg/base-drafts/issues/4530 > -- Section 9 (and also 9.4 and possibly others) -- > Please also consider adding another reason for an endpoint to change its > IPv6 > address due to RFC 4941 ("privacy extensions for IPv6 addresses") and not > only > NAT ;-) > https://github.com/quicwg/base-drafts/issues/4531 > -- Section 9.1 -- > Can this mechanism also be used not only when changing of IP address but > also > of IP version ? > > Did the QUIC WG/authors consider using happy eyeball (RFC 8305) to probe > whether IPvfoo could become better than IPvbar regularly during a QUIC > connection (using the preferred addresses) ? > https://github.com/quicwg/base-drafts/issues/4532 > -- Section 9.7 -- > Why a SHOULD for the use of a hash, IMHO a good pseudo-random number would > also > work (as explained in RFC 6437). > https://github.com/quicwg/base-drafts/issues/4533 > -- Section 13 -- > Should the text provide a forward reference to section 14 (datagram size) ? > https://github.com/quicwg/base-drafts/issues/4534 > -- Section 14.1 -- > This padding on the initial packets is quite a smart technique ;-) > https://github.com/quicwg/base-drafts/issues/4535 > -- Section 17.2.1 -- > I find a little weird that the "unused" field have a SHOULD setting for the > MSB... Suggest to keep the F bit apart and use a 6-bit "unused" field. > https://github.com/quicwg/base-drafts/issues/4536 > -- Section 18.2 -- > I am not a transport expert, so, I can be wrong but usually, rather than > using > "::.0", "[::]:0" is used. > https://github.com/quicwg/base-drafts/issues/4537 > -- Section 19.2 -- > Suggest to also mention "keeping NAT binding states alive" as a use case > for > PING. > https://github.com/quicwg/base-drafts/issues/4538 > == NITS == > > -- Section 1 -- > In "QUIC authenticates all packets and encrypts as much as is practical." > it is > a little unclear to me whether the 'as much' applies only to 'encrypts' or > also > on 'authenticates'. Or is it clear for an English-native speaker (that I am > not). > https://github.com/quicwg/base-drafts/issues/4539 > -- Section 1.3 -- > Rather than using "described by ?" why not using the letter 'l' (as in > length) > rather than a '?'. It is confusing at first sight. > https://github.com/quicwg/base-drafts/issues/4540 > -- Section 4.5 -- > "the final size is the number of bytes sent" is slightly ambiguous as it > could > either be the number of bytes sent by the application or sent as UDP > payload. > The rest of the paragraph kind of answers the question though. > https://github.com/quicwg/base-drafts/issues/4541 > -- Section 5.2.2 -- > "If a server receives a packet that indicates an unsupported version but is > large enough to initiate a new connection" it is unclear what is the > subject of > "is"... > https://github.com/quicwg/base-drafts/issues/4542 > -- Section 6.3 -- > The use of "0x?a?a?a?a" with undefined syntax brings only question marks > in the > reader's mind => suggest to remove "0x?a?a?a?a" but keep the forward > pointer to > section 15. > https://github.com/quicwg/base-drafts/issues/4543 > -- Section 8.2 -- > Why using "two-tuple" rather than the simpler "pair" ? > https://github.com/quicwg/base-drafts/issues/4544 > -- Section 23.1 -- > Why using the anchor [IPv4] rather than [RFC791] ? Just curious... > https://github.com/quicwg/base-drafts/issues/4545 Cheers, Lucas On behalf of QUIC WG Chairs
