RSVP Extensions for Admission Priority
RFC 6401
Yes
(Magnus Westerlund)
No Objection
Lars Eggert
(Cullen Jennings)
(Jari Arkko)
(Pasi Eronen)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Abstain
Note: This ballot was opened for revision 15 and is now closed.
Lars Eggert
No Objection
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-01-01)
Unknown
AFAICS the only mention of "emergency services" in this I-D is in the file name (and that will disappear when it becomes an RFC). I have no objection to this feature for admission control priority policy becoming an RFC.
Alexey Melnikov Former IESG member
No Objection
No Objection
(2009-12-31)
Unknown
4.1.1. Admission Priority Merging Rules This section discusses alternatives for dealing with RSVP admission priority in case of merging of reservations. As merging applies to multicast, this section also applies to multicast sessions. The rules for merging Admission Priority Policy Elements are defined by the value encoded inside the Merge Strategy field in accordance with the corresponding IANA registry. The merge strategies (and associated values) defined by the present document are the same as those defined in [RFC3181] for merging Preemption Priority Policy Elements (see "IANA Considerations" section). This begs the question: is a separate registry needed? 6. IANA Considerations In section 3.1, the present document defines a Merge Strategy field This should be section 4.1. inside the Admission Priority policy element. IANA needs to create a registry for this field and allocate the following values: In section 3.1, the present document defines an Error Code field This should point to section 4.1 again. inside the Admission Priority policy element. IANA needs to create a registry for this field and allocate the following values: Similar issues with references to the section 3.2 (should be 4.2). 8.2. Informative References [I-D.ietf-nsis-qspec] Bader, A., Ash, G., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-22 (work in progress), November 2009. It looks like this should be Normative (due to the text in Section 4.1 in the paragraph talking about 8 bit Admission Priority field.
Cullen Jennings Former IESG member
(was Discuss, Abstain, No Record, Discuss)
No Objection
No Objection
(2010-01-07)
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2009-02-16)
Unknown
I had a DISCUSS concerning the fact that this document is not fully in line with the IETF requirements for an ETS as specified in RFC 3689 and RFC 3690. I am aware that the architecture issues and possible update or 3689/3690 to synchronize with the current thinking of ETS in the IETF and in the industry are out of scope for this document. It would have helped however to add informational references of other documents that may describe requirements and architecture (like GETS that came up during the discussions).
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
(was Discuss, Abstain)
No Objection
No Objection
(2008-06-05)
Unknown
I support the discuss comments about the use of router alert options.
Pasi Eronen Former IESG member
(was Abstain, Discuss)
No Objection
No Objection
(2010-01-07)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
(was Abstain, Discuss)
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss, No Objection)
No Objection
No Objection
(2010-01-05)
Unknown
Chris Newman Former IESG member
Abstain
Abstain
(2008-10-30)
Unknown
After the IESG discussion on this, I believe the following 3 changes would make me comfortable with standards track publication. For informational status, I believe the first and second items need to be addressed. 1. Having RAO rate limiting as merely a recommendation is not acceptable. I believe RAO rate limiting has to be mandatory-to-implement part of this proposal to prevent harm to the Internet from this proposal. Assuming this deploys, it's likely additional RAO defense mechanisms will be developed by the industry and be helpful, but a mandatory baseline is important. 2. It is my understanding there is no way to protect this mechanism from denial of service. A skilled attacker can generate a flood of RAO packets in this format that will almost certainly prevent valid RAO packets from being processed. The document needs to make this very clear to avoid false expectations. 3. I believe BCP 61 (RFC 3365) applies to this specification, and the current specification does not adequately meet that BCP. I am open to debate as this is not my area of primary expertise.
David Ward Former IESG member
Abstain
Abstain
(2008-06-04)
Unknown
Similar to my abstain on GIST docs, I am abstaining for reasons that Ross and Ron outlined.
Lisa Dusseault Former IESG member
(was No Record, Abstain)
Abstain
Abstain
(2008-10-22)
Unknown
I have read this document, but I'm still confused by the architecture and by the discussions about the architecture. The security model is "walled garden" as far as I can tell, but the authors have argued that this work is within the IETF's remit as traffic will go on the open Internet. I also don't understand the inclusion of multicast merging rules.