Hi Eric, thanks for your reply. I created a new github issue for section 3.1. and we will see if we can clarify things!
Mirja On 13.06.22, 18:44, "Eric Vyncke (evyncke)" <[email protected]> wrote: Mirja Thank you for your thank you ;) More seriously, please look below for EV> Regards -éric On 01/06/2022, 10:42, "Mirja Kuehlewind" <[email protected]> wrote: Hi Eric, Thanks for you nice review for this document as well. I filed some issue or directly created some PRs for some of your comments but I still have a few questions. Please see inline. Mirja On 20.04.22, 08:55, "Éric Vyncke via Datatracker" <[email protected]> wrote: É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 ? [MK] Yes, I think if you look at the first packet as a whole you can be reasonably sure that you look at a quic packet. I guess this is an assumption throughout the whole document, as section 2.4 says: "New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed." [MK] Do we need to say more? EV> hummm I guess not even if the text in 2.4 is rather generic while the point in 3.1 is really specific. Perhaps adding which handshake properties are 'distinguishable' already in section 2.4 ? ## 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 ? [MK] Not sure what the intention of this question is. I think this section only says by looking at the data rate you can learn something about symmetry (however, there could also be padding which could conceal the application layer symmetry). Any changes/clarifications needed here? EV> no need to change, it was more for my education. ## 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". [MK] The text was written with the assumption of one time-out as believe usually deployed today. I don't think we want to design anything beyond that in this document. EV> fair enough, thank you for the explanation. ## 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 ;-) )
