[tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-ecn-experimentation-06: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive:

General:

 I agree with Ekr's comment specifying RFC updates as text"patches" is
 confusing and unfriendly to the reader. While I don't necessarily agree that
 we should do bis drafts instead, I hope people will remember that we never
 actually render an "updated" RFC with the patches applied. I think this sort
 of thing would be easier to understand if we just spoke of the changes at a
 conceptual level and avoid getting wrapped around changing specific words to
 other specific words.  I don't expect that to change with this particular
 draft, but I think the IESG should consider some guidance here. (And I fully
 recognize that a lot of update drafts in ART do the same thing.)

-1, first paragraph: "An Experimental RFC MUST be published for any protocol
   or mechanism that takes advantage of any of these enabling updates."

This seems like an odd use of 2119 language, at least for something other than
a BCP.  Furthermore, I don't think this paragraph is the real authority on the
matter, since there is much more precise text scattered through the draft about
this particular requirement. Therefore, I suggest removing the 2119 language
and stating this descriptively. (e.g. "Mechanisms that take advantage of these
updates are to be specified in experimental RFCs.")

Speaking of which, there are several references to requiring experimental RFCs.
Are those expected to be IETF stream RFCs?

-5, first "patch":
Are there existing implementations that would become noncompliant with the new
text?

-9, 1st paragraph: "As a process memo that only removes limitations on proposed
   experiments, there are no protocol security considerations."
I am skeptical that removing limitations from experiments can be assumed to be
security neutral on its face. Please consider documenting the thought process
that led to that conclusion.

Editorial:
-1, 2nd paragraph: " There is no need to make changes for protocols ...
I'm a bit confused--those hypothetical standards track RFCs will need to make
the sort of changes that this paragraph says are not needed. Is the point that
_this_ document does not need to make those changes?

-2, Congestion Response Difference: "As discussed further in
      Section 4.1, an ECN congestion indication communicates a higher
      likelihood that a shorter queue exists at the network bottleneck
      node by comparison to a packet drop that indicates congestion
      [I-D.ietf-tcpm-alternativebackoff-ecn]."

I'm not sure what is being compared here. Is it a high chance of shorter queue,
or higher chance of a short queue?

-- (same paragraph): "(next bullet)"
There are no bullets.

-2, Congestion Marking Difference:
The first sentence is hard to parse. Please consider breaking it into simpler
sentences.

-3, first paragraph: "As specified in RFC 3168, ... [stuff]... , as specified
in experimental
   RFC 3540 [RFC3540].
This is hard to parse. In particular, I have trouble deciphering which part is
supposed to be specified in 3168 vs 3540.

-- 2nd paragraph: "but might equally have been due to re-
   marking of the ECN field by an erroneous middlebox or router."
I think "erroneous" modified "re-marking" rather than "middlebox or router".

-4.2, 1st paragraph: "... prevent the aggressive low latency traffic starving
conventional
   traffic ...  "
Is there a missing "from" between "traffic" and "starving"  Or maybe an "of"
after "starving"?