Telephony Routing over IP (TRIP) Attribute for Resource Priority
draft-carlberg-trip-attribute-rp-04
Yes
(Cullen Jennings)
(Jari Arkko)
No Objection
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 04 and is now closed.
Cullen Jennings Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
(2007-08-23)
Unknown
This document uses ABNF without a reference to the ABNF specification. In addition, the definition of the "alphanum" ABNF rule is in the SIP base spec which is not directly referenced.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2007-08-22)
Unknown
Section 3., paragraph 0: > 3. SIP Resource-Priority Effort WG history is inappropriate for an RFC. Rephrase or remove subsection. Document has a *ton* of obvious idnits. The sponsoring AD should have made the authors fix these before the documen hit the IESG.
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2007-08-17)
Unknown
From the Gen-ART Review by Pasi Eronen: The acronym "TRIP" should be expanded in document title and abstract. The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. Some of the references have been obsoleted by newer documents: -- RFC 1771 -> RFC 4271 -- ANSI T1.631 -> ATIS 1000631 (probably) -- H.460.4 (11/02) -> H.460.4 (01/07) (the title changed too) From the SecDir Review by Marcus Leech: I will note that TRIP suffers from the same problems as many routing protocols, in that securing the *transport* of that protocol isn't necessarily enough to determine the *authorization* of routing-control utterances issued by any of the participating parties. It would perhaps be good to review some of these protocols once BGP security has been nailed down to a point where it can be used as a model of other protocols that are "routing like" and based loosely on a BGP model (as in TRIP).
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown