Lars Eggert's No Objection on draft-ietf-quic-manageability-16: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

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://github.com/quicwg/base-drafts/wiki/QUIC-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://github.com/larseggert/ietf-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).