Hi Elwyn, Many thanks for the review! We’ve incorporated editorial nit fixes into revision -15 of the draft (for details, see https://github.com/quicwg/ops-drafts/pull/455 <https://github.com/quicwg/ops-drafts/pull/455>).
Cheers, Brian > On 8 Feb 2022, at 02:29, Elwyn Davies via Datatracker <nore...@ietf.org> > wrote: > > 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/ > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
