Éric Vyncke has entered the following ballot position for draft-ietf-quic-manageability-16: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Matt Joras for the shepherd's write-up including the WG consensus and the intended status. I hope that this helps to improve the document, Regards, -éric Note for the shepherding AD: missing consensus boilerplate. Should there be a section on the usefulness of IPFIX with QUIC ? ## Section 2.1 "All deployed versions are maintained in an IANA registry" is it "deployed" or "specified" ? I.e., an operator could always deploy an experimental version not yet in the IANA registry. The text appears inconsistent to me: - "Short headers contain only an optional destination connection ID" - "source and destination connection ID: short and long headers carry a destination connection ID", i.e., is it optional or not ? Also some inconsistency about the spin bit, is it only in v1 or is it an invariant ? Security ADs will know more of course but for me "cryptographically protected" is unclear whether it is confidentiality or integrity or both... Suggest to use "is confidentiality/integrity protected with cryptography" (or a lighter sentence than this one). ## Section 3 "Here we assume a bidirectional observer", let's also state that there is no section about unidirectional observer ? ## Section 3.1 Could the first 1200-byte QUIC packet be used to suspect a QUIC connection establishment ? ## Section 3.7 Can the data rate in each direction always be used to detect which side is the client/initiator vs. server/responder ? Even for HTTP/3 a POST can be larger than the reply. Or did I misread this paragraph ? ## Section 4.1 Suggest to expand "CE markings" ## Section 4.2 Thank you for this section, this may be the most useful one :-) (together with section 4.9) BTW, should there be 2 different time-outs? One for the "connection establishment" and one, longer, for "normal traffic". ## Section 4.6 "DDoS" is used while 4.7 use "DDOS" and expand the acronym ;-) (reading the I-D as first task in the morning with 2 cups of coffee has some side effects on my eyes ;-) )
