RSVP Extensions for Admission Priority
draft-ietf-tsvwg-emergency-rsvp-15

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.

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.

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).

I support the discuss comments about the use of router alert options.