Skip to main content

Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)
draft-ietf-pcn-3-in-1-encoding-11

Yes

(David Harrington)
(Martin Stiemerling)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

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

David Harrington Former IESG member
Yes
Yes ()

                            
Martin Stiemerling Former IESG member
Yes
Yes (for -10)

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2012-03-19 for -09)
Thanks for the work to address my Discuss and Comments.

---

The change at the end of 4.2 does seem to address my concern in 4.3,
but leaves the text in 4.3 looking rather strange: every node MUST be
configured although 4.2 says that if that doesn't happen it will not
be the end of the world.

---

The substantial change to 5.1 addresses my Discuss, thanks. There seems
to be a lot of new material here, including 2119 language. Is the WG
on board with the new text?

---

I would have liked to see more discssion in a single place about
interactions with management. There are several places where alarms or
notifications are discussed and quite a number of things that are
configurable.

There is also the question of how a PCN system may be diagnosed.

Your AD may be able to point you at an RFC that provides guidance :-)
Dan Romascanu Former IESG member
No Objection
No Objection (for -08)

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -09)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -09)

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-03-11 for -09)
"emphatically NOT RECOMMENDED" looks kinda like a cool new 2119 term, but it's not defined there and probably shouldn't be used. (I note that it isn't capitalized in Appendix B.) Maybe better would be "Implementation SHOULD NOT engage in this behavior except in the most extreme circumstances because..."

"This appendix is informative, not normative." I find this sentence to be an increasingly used verbal tic in documents. I think it's useless and should be removed. In the case of Appendix A, you already say at the end that "operators are ultimately free to" use PCN or not. In Appendix B, you remind the reader that in the event of a conflict between the appendix and the rest of the document, implementations should follow the guidelines in the rest of the document. This "informative vs. normative" distinction is just jargon that isn't necessary.
Peter Saint-Andre Former IESG member
No Objection
No Objection (for -08)

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -09)

                            
Robert Sparks Former IESG member
(was Discuss, No Objection) No Objection
No Objection (for -09)

                            
Ron Bonica Former IESG member
(was Discuss, No Objection) No Objection
No Objection (for -09)

                            
Russ Housley Former IESG member
No Objection
No Objection (for -08)

                            
Sean Turner Former IESG member
No Objection
No Objection (for -09)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-02-28 for -08)
The acronym PHB is used but not defined.
Stewart Bryant Former IESG member
No Objection
No Objection (for -08)

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -08)