Skip to main content

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

Yes

Lars Eggert
(Jari Arkko)
(Magnus Westerlund)
(Sam Hartman)

No Objection

(Bill Fenner)
(Dan Romascanu)
(David Kessens)
(Jon Peterson)
(Lisa Dusseault)
(Ross Callon)
(Russ Housley)

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

Lars Eggert Yes

(Jari Arkko; former steering group member) (was Discuss) Yes

Yes (2006-08-31)

                            

(Magnus Westerlund; former steering group member) Yes

Yes ()

                            

(Sam Hartman; former steering group member) (was Discuss) Yes

Yes ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2006-08-28)
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.

(Cullen Jennings; former steering group member) No Objection

No Objection (2006-08-30)
I think this should be informational not BCP.

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) (was Discuss) No Objection

No Objection (2006-08-31)
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

(Ross Callon; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2006-08-30)
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.