Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-quic-manageability-14

[Lars Eggert <[e-mail]>]

Elwyn, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On 2022-2-8, at 3:29, Elwyn Davies via Datatracker <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art