Skip to main content

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

Yes

(Zaheduzzaman Sarker)

No Objection

Gunter Van de Velde
Jim Guichard
(Francesca Palombini)
(John Scudder)

Note: This ballot was opened for revision 32 and is now closed.

Deb Cooley
No Objection
Comment (2025-02-15 for -32) Not sent
Thanks to Scott Kelly for both secdir reviews.
Éric Vyncke
No Objection
Comment (2025-02-20 for -32) Sent
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).
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Roman Danyliw
No Objection
Comment (2025-02-17 for -32) Not sent
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:
Zaheduzzaman Sarker Former IESG member
Yes
Yes (for -32) Unknown

                            
Erik Kline Former IESG member
No Objection
No Objection (2025-02-16 for -32) Sent
# 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"
Francesca Palombini Former IESG member
No Objection
No Objection (for -32) Not sent

                            
John Scudder Former IESG member
No Objection
No Objection (for -32) Not sent

                            
Warren Kumari Former IESG member
No Objection
No Objection (2025-02-18 for -32) Not sent
Nice to see this finally moving ahead.
Also nice to see the (linked) implementations...