Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement
draft-ietf-ccamp-rsvp-node-id-based-hello-03
Yes
(Alex Zinin)
No Objection
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)
(Ted Hardie)
Note: This ballot was opened for revision 03 and is now closed.
Alex Zinin Former IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2006-02-14)
Unknown
From Gen-ART review by Spencer Dawkins, in case the document is updated for any other reason: There was one point that I wish was explained better - there are five different places in the draft where a statement like "use of Node-ID based Hello session is optimal for detecting signaling adjacency failure" is made , but "optimal" is never explained or put in context. I can guess what I think it means, but I'm guessing, and a sentence or two of explanation might make the document clearer for many readers.
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
(2006-02-16)
Unknown
Abstract still refers to this document as a BCP, though it seems it is now going for PS. > Use of Node-ID based RSVP Hello messages is implied in a number of > cases, e.g., when data and control plan are separated, when TE links > are unnumbered. Furthermore, when link level failure detection is s/data and control plan/the data and control plane RSVP is expanded in the Abstract after it is used.
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
(2006-02-15)
Unknown
This really seems more like a proposed standard than a BCP. It seems like there is implementable and testable behavior and that this specification could advance along the standards track. I'd like the authors and possibly WG to consider this. However I do not think it appropriate to hold a discuss on this issue for this document.
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown