Skip to main content

Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
draft-ietf-tsvwg-ecn-alternates-02

Yes

(Jari Arkko)
(Lars Eggert)
(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.

Jari Arkko Former IESG member
(was Discuss) Yes
Yes (2006-08-31) Unknown

                            
Lars Eggert Former IESG member
Yes
Yes () Unknown

                            
Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Sam Hartman Former IESG member
(was Discuss) Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2006-08-28) Unknown
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 IESG member
No Objection
No Objection (2006-08-30) Unknown
I think this should be informational not BCP.
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
(was Discuss) No Objection
No Objection (2006-08-31) Unknown
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 IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2006-08-30) Unknown
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.