Reviewer: Elwyn Davies
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<
https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-quic-manageability-14
Reviewer: Elwyn Davies
Review Date: 2022-02-07
IETF LC End Date: 2022-02-07
IESG Telechat date: Not scheduled for a telechat
Summary:
Ready with various nits. The text is extremely dense and I am not sufficiently
close to tis work to determine whether the advice offered is entirely
appropriate or accurate. Most of the nits are trivially correctable, but some
thought needs to go into making the text in s3.1 fture prooof.
Major issues:
None
Minor issues:
None
Nits/editorial comments:
Nits:
General: s/e.g. /e.g., / (6 places)
s1: A note about the origin of terminology (e.g., Connection ID) is needed.
Primarily RFC 9000, I take it.
s1, para 3: s/This is achieved through integrity protection of the wire
image/This is enforced through integrity protection of the wire image/
Figures 1 and 6: The terms 0-RTT and 1-RTT are shown as 0RTT and 1RTT in the
figures. Please make consistent.
s1, para 4: s/an QUIC/a QUIC/
s2.1, para 6: s/QUIC version 1 uses version/QUIC version 1 uses version
number/; s/All deployed versions/Details of all deployed versions/
s2.3, para 1: In the last sentence s/the use of Alt-Svc/ the of the HTTP
Alternative Services mechanism [RFC7838]/
s2.3, para 2 (and 4 other places): The abbreviation or term 5-tuple is not in
the RFC Edito'r's list of abbreviations and is not used in RFC 9000. I think
this term needs to be expanded (probably in the list of terms - see comment on
s1).
s2.4 and elsewhere: The term 'flights [of datagrams]' is not defined. I
notice that the term was not defined in RFC 9000 where it is introduced
originally.
s2.4, para : s/detailed Figure 2/detailed in Figure 2/
s2.4, para 8: s/Figure4/(Figure 4)/, s/Figure 5/(Figure 5)/
s2.4, para 11: s/than in the Client/that is sent in the Client/
s2.4, para 13: "When the client uses 0-RTT connection resumption, the Client
Initial flight can also include one or more 0-RTT packets, as shown in Figure
6." Where is this connection resumption defined? It isn't in RFC 9000
AFAICS.
Maybe
https://datatracker.ietf.org/doc/html/draft-kuhn-quic-0rtt-bdp-08? Please supply a suitable explanation/reference.
s2.6, para 1 and s3.5, para 4: Be consistent between 5-tuple and five-tuple
please.
s3.1, para 2: I think the 'DNS' protocol deserves its full title DNS over
Dedicated QUIC Connections.
s3.1, para 2: The second sentence regarding implementations at the time of
writing is not future proof. This needs to be rewritten to express that there
is an expectation of multiple applications without tying it to somewhat
hypothetical implementations that might or might not exist by the time this
document is published as an RFC.s3.5, paa 4:
s3.2, para 2: "Connection establishment can therefore be detected using
heuristics similar to those used to detect TLS over TCP." Where would a reader
find out what are hese heuritics?
s3.4, last para: s/E.g./For example/
s3.8.2, para 8: s/i.e. /i.e., /
s4.2, para 4: s/well- defined/well-defined/
s4.2, para 6: s/unnecessary/unnecessarily/
s4.2, para 10: s/Specially/In particular/
