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/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
