1. Introduction

   This memo specifies procedures for modifying the Resource reSerVation
   Protocol (RSVP) [RSVP], including (but not limited to) adding,
   updating, extending or obsoleting: messages, message formats and
   procedures, object classes and class types, object formats and
   procedures; header formats, error codes and subcodes and semantics,
   and procedures for sending, receiving, and addressing RSVP messages.

   IANA recognizes the following RSVP name spaces: Message Types, Class
   Names, Class Numbers, Class Types and Sub-objects, Virtual
   Destination Ports, and Error Codes and (Subcode) Values (all of these
   will collectively be referred to as RSVP entities in this document).
   This memo specifies ranges for each name space and assignment
   policies for each range.  New RSVP name spaces must be defined in a
   Standards Track RFC which include guidelines for IANA assignments
   within the new name spaces.

   The assignment policies used in this document are: Standards Action
   (as defined in [IANA]), Expert Review, and Organization/Vendor
   Private (more simply, "Vendor Private"); the last two are defined in
   this document.  The intent of these assignment policies is to ensure

   that extensions to RSVP receive adequate review before code-points
   are assigned, without being overly rigid.  Thus, if an extension is
   widely accepted and its ramifications are well understood, it may
   receive an assignment from the Standards Action space; however, if an
   extension is experimental in nature, it receives an assignment from
   the Expert Review space, and may, with maturity, move to Standards
   Track.  Assignments from the Vendor Private space are not reviewed,
   but there are mechanisms in place to ensure that these codepoints can
   co-exist in a network without harm.

   A standards body other than the IETF that wishes to obtain an
   assignment for an RSVP entity must decide from which type of
   name/number space they desire their assignment be made from, and then
   submit the appropriate documentation.  For example, if the assignment
   is to be made from a number space designated as Standards Action, a
   Standards Track RFC MUST be submitted in support of the request for
   assignment.

   This memo updates the IANA Considerations section (section 7) of
   [RSVP-TE], replacing the assignment policies stated there.

   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [KEYWORDS].