Hi Lars, thanks for your review. We create PRs for all your points!
Mirja On 19.04.22, 19:55, "Lars Eggert via Datatracker" <[email protected]> wrote: Lars Eggert 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: ---------------------------------------------------------------------- Section 2.1, paragraph 1, comment: > All deployed versions are maintained in an IANA > registry (see Section 22.2 of [QUIC-TRANSPORT]). I don't think it's correct to claim that "all deployed versions are maintained in an IANA registry" - many versions are being and have been deployed that are not in that IANA registry at all (see https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-8d09ac6db7ab62b2&q=1&e=6d2579f2-7ef2-4a77-ab06-d4bc01b1037a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fwiki%2FQUIC-Versions); there is a huge range for experimental versions. Section 3.1, paragraph 1, comment: > At the time of writing, two application bindings for QUIC have been > published or adopted by the IETF: HTTP/3 [QUIC-HTTP] and DNS over > Dedicated QUIC Connections [I-D.ietf-dprive-dnsoquic]. These are > both known at the time of writing to have active Internet > deployments, so an assumption that all QUIC traffic is HTTP/3 is not > valid. HTTP/3 uses UDP port 443 by convention but various methods > can be used to specify alternate port numbers. Simple assumptions > about whether a given flow is using QUIC based upon a UDP port number > may therefore not hold; see also Section 5 of [RFC7605]. AFAIK Microsoft's SMB-over-QUIC also uses 443. The datatracker state does not indicate whether the consensus boilerplate should be included in this document. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" * Term "invalid"; alternatives might be "not valid", "unenforceable", "not binding", "inoperative", "illegitimate", "incorrect", "improper", "unacceptable", "inapplicable", "revoked", "rescinded" Thanks to Elwyn Davies for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/5c_ZgBH4YmAn13j0IszsrYKTVmI). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-f8ce152d1f78d2c2&q=1&e=6d2579f2-7ef2-4a77-ab06-d4bc01b1037a&u=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1, paragraph 1, nit: - used to identify the connection associated with a QUIC packet, for + used by the endpoints to identify the connection associated with a QUIC packet, for + +++++++++++++++++ Section 2.1, paragraph 1, nit: - is implicit. + is only known to the endpoints. Section 2.1, paragraph 1, nit: - endpoints might use an extension that varies the bit. Therefore, + endpoints might use an extension that varies the bit [QUIC-GREASE]. Therefore, + ++++++++++++++ Section 2.1, paragraph 1, nit: - headers, while it is implicit (depending on destination connection - ^^^^^^ + headers, while it is known only to the endpoints (depending on destination connection + +++++++++++++++++++++++ ^ + Section 2.8, paragraph 1, nit: - ossification in the implementation on the selection mechanism. - ^ + ossification in the implementation of the selection mechanism. + ^ Section 2.8, paragraph 1, nit: - traffic recognition will therefore behave differently than with these - ^^^ ^ ^^^^^^^^^ + traffic recognition will therefore be more problematic than with these + ^^^^ ^^^^^^^^^ ^ Section 4.2, paragraph 1, nit: - forwarding decison is not viable as it will break connectivity, or at + forwarding decision is not viable as it will break connectivity, or at + + Section 4.8, paragraph 1, nit: - Note that the 5-tuple of a QUIC connnection can change due to - - Section 4.8, paragraph 1, nit: - maybe be treated differently, as congestion control is usualy reset + maybe be treated differently, as congestion control is usually reset + + Section 4.10, paragraph 1, nit: - DF bit set, because fragmention occurs below the IP layer. However, + DF bit set, because fragmentation occurs below the IP layer. However, + ++ Section 6, paragraph 1, nit: - However, some information is still observerable, as supporting - -- Section 8, paragraph 1, nit: - Special thanks to last call reviewers Elwyn Davies, Barry Lieba, Al - - + Special thanks to last call reviewers Elwyn Davies, Barry Leiba, Al + + Section 2.4, paragraph 1, nit: > delays that trigger a spurious Probe Timeout ({Section 6.2 of > RFC9002}). If QUIC packets get lost or reordered, packets belonging This looks like broken Markdown. Document references draft-ietf-quic-applicability-15, but -16 is the latest available revision. Document references draft-ietf-tsvwg-transport-encrypt, but that has been published as RFC9065. Paragraph 7659, nit: > TP/3 uses UDP port 443 by convention but various methods can be used to speci > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short).
