Procedures for Modifying the Resource reSerVation Protocol (RSVP)
RFC 3936

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                        K. Kompella
Request for Comments: 3936                              Juniper Networks
Updates: 3209, 2205                                              J. Lang
BCP: 96                                                  Rincon Networks
Category: Best Current Practice                             October 2004

   Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This memo specifies procedures for modifying the Resource reSerVation
   Protocol (RSVP).  This memo also lays out new assignment guidelines
   for number spaces for RSVP messages, object classes, class-types, and
   sub-objects.

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

Kompella & Lang          Best Current Practice                  [Page 1]
RFC 3936             Procedures for Modifying RSVP          October 2004

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

2.  Assignment Policies for RSVP Entities

   For each of the RSVP name spaces identified by IANA, the space is
   divided into assignment ranges; the following terms are used in
   describing the procedures by which IANA assigns values: "Standards
   Action" (as defined in [IANA]), "Expert Review", and
   "Organization/Vendor Private", defined below.

   "Expert Review" ranges refer to values that are to be reviewed by an
   Expert designated by the IESG.  The code points from these ranges are
   typically used for experimental extensions; such assignments MUST be
   requested by Experimental RFCs that document their use and
   processing, and the actual assignments made during the IANA actions
   for the document.  Values from "Expert Review" ranges MUST be
   registered with IANA.

   "Organization/Vendor Private" ranges refer to values that are
   enterprise-specific; these MUST NOT be registered with IANA.  For
   Vendor Private values, the first 4-octet word of the data field MUST
   be an enterprise code [ENT] as registered with the IANA SMI Network

Kompella & Lang          Best Current Practice                  [Page 2]
RFC 3936             Procedures for Modifying RSVP          October 2004