Adding Acknowledgement Congestion Control to TCP
RFC 5690

[Ballot comment]
You have some non-2119 language that may need attention. For example, in Section 2.2
  PT is the payload type expected in the RTP header.  A value of zero
  indicates that the receiver shall not check payload type to detect
  malformed packets.

[Ballot discuss]
In section 2.1
  1)Only the following values MUST be specified for structure-
    agnostic emulation (see [RFC4553]):
    a) Structure-agnostic E1 emulation  - 32
    b) Structure-agnostic T1 emulation:
        i) MUST be set to 24 for the basic mode 
        ii) MUST be set to 25 for the "Octet-aligned T1"
            mode
    c) Structure-agnostic E3 emulation  - 535
    d) Structure-agnostic T3 emulation  - 699

I cannot pare this. Does the "MUST" apply to future specifications? I.e., is it an instruction to IANA? Or are you trying to say...

  For structure-agnostic emulation, this parameter MUST
  be set to one of the following values.

[Ballot comment]
I don't think the use of the RFC 2119 boilerplate is appropriate.
AFAICS, the only use of such language is in instructions to the RFC Editor and the IANA. These instructions will be removed before publication and so the boilerplate is redundant and should be removed.

[Ballot discuss]
I can live with the IESG note as is, but after reading this draft, I think it might be more appropriate to change the IESG note to something along lines of:

      The content of this RFC was at one time considered by the IETF,
      and therefore it may resemble a current IETF work in progress or a
      published IETF work.  This RFC is not a candidate for any level of
      Internet Standard.  See RFC 3932 for more information.

This document was submitted to the RFC Editor to be published as an
Informational Independent Submission: draft-floyd-tcpm-ackcc-05.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.


Adding Acknowledgement Congestion Control to TCP

This document describes a possible congestion control mechanism for
acknowledgement traffic (ACKs) in TCP. The document specifies an
end-to-end acknowledgement congestion control mechanism for TCP
that uses participation from both TCP hosts, the TCP data sender
and the TCP data receiver. The TCP data sender detects lost or
ECN-marked

ACK packets, and tells the TCP data receiver the ACK Ratio R to use
to respond to the congestion on the reverse path from the data
receiver to the data sender. The TCP data receiver sends roughly
one ACK packet for every R data packets received. This mechanism
is based on the acknowledgement congestion control in DCCP's CCID
2. This acknowledgement congestion control mechanism is being
specified for further evaluation by the network community.


Four week timeout expires on 11 June 2009.