More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP
draft-ietf-tcpm-accurate-ecn-34

Thanks to Scott Kelly for both secdir reviews.

# Internet AD comments for draft-ietf-tcpm-accurate-ecn-32
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1.4

* "expirience" -> "experience"

* "Remote Direct Access Memory" -> "Remote Direct Memory Access"

Thank you to Elwyn B. Davies for the GENART review.  Please review the feedback as there a number of suggestions for improved clarity.

** Section 7.  Explicitly name the registries that are going to be updated

OLD
The flag will now be defined as:
NEW
The flag will now be defined as the following in the “TCP Header Flags” registry in the “Transmission Control Protocol (TCP) Parameters” registry group:

OLD
These values are defined as:
NEW
These values are defined as the following in the “TCP Option Kind Numbers” registry in the “Transmission Control Protocol (TCP) Parameters” registry group:

Thanks for the work in this document, I only briefly browsed through it as it is really outside of my expertise even if the text is clear (BTW, I hope that this complex specification and re-use of one flag have been heavily tested in real networks). 

Nevertheless some comments:

Should "AccECN" be part of the title and in the abstract ? This could help searches.

The term `middlebox` is often used without a proper definition or reference and it seems to cover a lot of different roles from TCP offload to TCP normalizers (cfr section 3.3)

Section 1, any chance to get some explanations without reading RFC 7560 about `DCTCP [RFC8257] or L4S [RFC9330] need to know when more than one marking is received` ?

In the same section `So its applicability is intended to include all public and private IP networks`, the use of public/private is unusual, but I hope that everyone understands the same concept.

Section 1.4, s/two bit field/two-bit field/

Section 7, I wonder why there is a note to remove the IANA request. It is also unclear who is instructed to remove the text (I guess RFC Editor).

Nice to see this finally moving ahead.
Also nice to see the (linked) implementations...