idnits 2.17.1 draft-ietf-rsvp-iana-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RSVP97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 20, 1999) is 9136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RSVP97' on line 162 looks like a reference -- Missing reference section? 'Guide98' on line 153 looks like a reference -- Missing reference section? 'RFC2205' on line 69 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Braden 2 Expiration: October 1999 ISI 3 File: draft-ietf-rsvp-iana-00.txt L. Zhang 4 UCLA 6 IANA Considerations for RSVP Version 1 8 April 20, 1999 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are Working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 linebreak http://www.ietf.org/shadow.html. 29 Abstract 31 This document provides an IANA Considerations section that will be 32 included in a future revision of the RSVP (Resource Reservation 33 Protocol) specification, RFC 2205 [RSVP97]. Meanwhile, this document 34 should be used to perform protocol parameter assignment for the RSVP 35 protocol. 37 1. Introduction 39 The responsible Internet authority (presently called the IANA) should 40 assign values to RSVP protocol parameters using rules presented in 41 this document, which uses the terminology of BCP 26 [Guide98]. 43 The contents of this document will become the IANA Considerations 44 section in a future revision of the RSVP (Resource Reservation 45 Protocol) specification, RFC 2205 [RSVP97]. 47 2. IANA Considerations 49 2.1 Message Type (or Msg Type) 51 Message Type is an 8-bit number that identifies the function of 52 the RSVP message. Its values fall into the following ranges: 54 0 Illegal value 55 1-127 Assigned by IANA with IETF Consensus. 56 128-191 Assigned by IANA using First-Come-First-Served 57 192-255 Private usage. 59 2.2 Class Number (or Class Num) 61 Class Number is an 8-bit number that identifies a class of data 62 objects to be carried in an RSVP message. Within each such class, 63 an 8-bit Class Type number (below) further specifies the 64 particular object type. 66 The two high-order bits of the Class Number are used to encode the 67 desired behavior when an RSVP implementation receives a message 68 containing an object whose Class Number it does not understand 69 [RFC2205]. In the following table: bits "x" are to be assigned by 70 the IANA. The bit "r" is currently required to have the value 1. 72 Class 73 Number Behavior Meaning 74 Range 75 ________ ________ _____________________________________ 76 0xxxxxxx REJECT RSVP rejects the RSVP message and 77 sends an RSVP error message. 79 10rxxxxx IGNORE RSVP silently ignores the object and 80 does not forward it. 82 11xxxxxx FORWARD RSVP silently ignores the object but 83 forwards it. 85 The following table shows the behavior and IANA assignment rule 86 for each sub-range of the Class Number value: 88 0-80 REJECT; assigned by IANA with IETF Consensus. 89 81-127 REJECT; assigned by IANA using First-Come-First-Served 90 128-159 (Reserved) 91 160-191 IGNORE; assigned by IANA with IETF Consensus. 92 192-223 FORWARD; assigned by IANA with IETF Consensus. 93 224-255 FORWARD; assigned by IANA using First-Come-First-Served 95 2.3 Class Type 97 Class Type is an 8-bit number that is assigned distinctly for each 98 Class Number. 100 0 Illegal value 101 1-127 Assigned by IANA with IETF Consensus. 102 128-191 Assigned by IANA using First-Come-First-Served 103 192-255 Private usage. 105 2.4 Virtual Destination Port (vDstPort) 107 Virtual Destination Port is a 16-bit value number is used in 108 objects with the SESSION Class Number and the IPv4/GPI or IPv6/GPI 109 Class Type. Values of this quantity are assigned using the 110 following rules: 112 0 Illegal Value 113 1-10 Reserved. Contact authors of RFC 2207. 114 11-8191 Assigned by IANA using First-Come-First-Served. 115 8192-65535 Reserved for dynamic allocation. 117 For values assigned by IANA, the rules are those for UDP port 118 assignment: the requestor must provide (a) a Point of Contact, (b) 119 a brief description of the intended use, and (c) a short name to 120 be associated with the assignment. 122 2.5 Error Code 124 This 8-bit number indicates the basic type of error. New values 125 should be assigned using Expert Review. A document must be 126 submitted that defines the precise meaning of the error code and 127 the accompanying Error Value field. 129 2.6 Globally-Defined Error Value Sub-Code 131 These sub-codes form the low-order 12 bits of a 16-bit Error Value 132 of the form: 134 0000xxxxxxxxxxxx 136 New sub-code values of this form should be assigned using Expert 137 Review [Guide98], and a document must be submitted that defines 138 their precise meaning. Currently assigned Error Code values 139 include the following for which additional globally defined error 140 value sub-codes may be defined: 142 o Error Code = 01: Admission control failure. 144 o Error Code = 12: Service preemption. 146 o Error Code = 21: Traffic control error. 148 In addition, new error codes may be defined in the future that 149 expand this list; they must be fully and explicitly documented. 151 3. References 153 [Guide98] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 154 Considerations Section in an RFC", October 1998. 156 [RSVP97] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 157 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 158 Specification", RFC 2205, September 1997. 160 Security Considerations 162 The security considerations for RSVP are specified in [RSVP97]. 164 Authors' Addresses 166 Bob Braden 167 USC Information Sciences Institute 168 4676 Admiralty Way 169 Marina del Rey, CA 90292 171 Phone: (310) 822-1511 172 EMail: Braden@ISI.EDU 173 Lixia Zhang 174 Xerox Palo Alto Research Center 175 3333 Coyote Hill Road 176 Palo Alto, CA 94304 178 Phone: (415) 812-4415 179 EMail: Lixia@PARC.XEROX.COM