RSVP Extensions for Admission Priority
RFC 6401

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

(Magnus Westerlund) Yes

(Jari Arkko) No Objection

(Ron Bonica) (was Abstain, Discuss) No Objection

(Ross Callon) (was Discuss) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) (was Abstain, Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2010-01-01 for -)
No email
send info
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.

(Russ Housley) No Objection

(Cullen Jennings) (was Discuss, Abstain, No Record, Discuss) No Objection

Alexey Melnikov No Objection

Comment (2009-12-31 for -)
No email
send info
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.

(Tim Polk) (was No Record, Discuss, No Objection) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2009-02-16)
No email
send info
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).

(Robert Sparks) No Objection

(Mark Townsley) (was Discuss, Abstain) No Objection

Comment (2008-06-05)
No email
send info
I support the discuss comments about the use of router alert options.

(Lisa Dusseault) (was No Record, Abstain) Abstain

Comment (2008-10-22 for -)
No email
send info
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.

(Chris Newman) Abstain

Comment (2008-10-30 for -)
No email
send info
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) Abstain

Comment (2008-06-04 for -)
No email
send info
Similar to my abstain on GIST docs, I am abstaining for reasons that Ross and Ron outlined.