Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
RFC 4774

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

(Jari Arkko) (was Discuss) Yes

(Lars Eggert) Yes

(Sam Hartman) (was Discuss) Yes

(Magnus Westerlund) Yes

(Ross Callon) (was Discuss) No Objection

(Brian Carpenter) No Objection

Comment (2006-08-28 for -)
No email
send info
Change to caption agreed by author after Gen-ART review:

OLD:
  Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN.

NEW:
  Figure 1: Alternate-ECN traffic, an old router, using RFC-3168 ECN,
  that is congested and ready to drop or mark the arriving packet.

(Lisa Dusseault) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2006-08-30 for -)
No email
send info
So, my reading of the BCP here is "Think about these issues before mucking with ECN alternate semantics".  I'm a shrug as to whether that is a BCP, but I can see the confusion.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

Comment (2006-08-30 for -)
No email
send info
I think this should be informational not BCP.

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) (was Discuss) No Objection

Comment (2006-08-31)
No email
send info
With statements like:

    This document
    doesn't comment on whether a mechanism would be required to ensure
    that the alternate-ECN semantics would not be let loose on the
    global Internet.  This document also doesn't comment on the chances
    that this scenario would be considered acceptable for
    standardization by the IETF community.

This document, at best, should be Informational or Experimental. I think statements like this are well in violation of principals in BCP 61 also. 

This is not part of my discuss only because Sam is holding a similar discuss for this.

Grammer nit: Section 4.1 s/don't/doesn't