idnits 2.17.1 draft-ietf-mpls-iana-rsvp-session-flags-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 171. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 178. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 184. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 2007) is 6252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Adrian Farrel 3 Internet Draft Old Dog Consulting 4 Category: Informational 5 Expiration Date: August 2007 February 2007 7 Codepoint Registry for The Flags Field in the Resource Reservation 8 Protocol Traffic Engineering (RSVP-TE) Session Attribute Object 10 draft-ietf-mpls-iana-rsvp-session-flags-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document provides instructions to IANA for the creation of a new 38 codepoint registry for the flags field in the Session Attribute 39 object of the Resource Reservation Protocol Traffic Engineeging 40 (RSVP-TE) signaling messages used in Multiprotocol Label Switching 41 (MPLS) and Generalized MPLS (GMPLS) signaling. 43 1. Introduction 45 The Resource Reservation Protocol (RSVP) [RFC2205] has been extended 46 as Rsvp for Traffic Engineering (RSVP-TE) for use in Multiprotocol 47 Label Switching (MPLS) signaling [RFC3209] and Generalized MPLS 48 (GMPLS) [RFC3473]. 50 [RFC3209] introduced a new signaling object, the Session Attribute 51 object, that is carried on the RSVP Path message. The Session 52 Attribute object contains an eight-bit field of flags. 54 The original specification of RSVP-TE assigned uses to three of 55 these bit flags. Subsequent MPLS and GMPLS RFCs have assigned further 56 flags. 58 There is a need for a codepoint registry to track the use of the bit 59 flags in this field, to ensure that bits are not assigned more than 60 once, and to define the procedures by which such bits may be 61 assigned. 63 This document lists the current bit usage and provides information 64 for IANA to create a new registry. This document does not define the 65 uses of specific bits - definitive procedures for the use of the 66 bits can be found in the referenced RFCs. 68 2. Existing Usage 70 2.1. RFC 3209 72 [RFC3209] defines the use of three bits as follows: 74 0x01 Local protection desired 76 0x02 Label recording desired 78 0x04 SE Style desired 80 2.2. RFC 4090 82 [RFC4090] defines the use of two bits as follows: 84 0x08 Bandwidth protection desired 86 0x10 Node protection desired 88 2.3. RFC 4736 90 [RFC4736] defines the use of one bit as follows: 92 0x20 Path re-evaluation request 94 3. Security Considerations 96 This informational document exists purely to create an IANA registry. 97 Such registries help to protect the IETF process against Denial of 98 Service attacks. 100 Otherwise there are no security considerations for this document. 102 4. IANA Considerations 104 IANA is requested to create a new codepoint registry as follows. 106 The new registry should be placed under the "RSVP-TE Parameters" 107 branch of the tree. 109 The new registry should be termed "Session Attribute Object Flags." 111 Flags from this registry may only be assigned by IETF consensus 112 [RFC2434]. 114 The registry should reference the flags already defined as described 115 in section 2 of this document. 117 5. Acknowledgements 119 Thanks to JP Vasseur, Bill Fenner and Thomas Narten for reviewing 120 this document. 122 6. References 124 6.1 Normative References 126 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and 127 S. Jamin, "Resource ReSerVation Protocol (RSVP) -- 128 Version 1, Functional Specification", RFC 2205, 129 September 1997. 131 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 132 an IANA Considerations Section in RFCs", BCP 26, RFC 133 2434, October 1998. 135 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 136 V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 137 Tunnels", RFC 3209, December 2001. 139 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 140 Switching (GMPLS) Signaling - Resource ReserVation 141 Protocol-Traffic Engineering (RSVP-TE) Extensions", 142 RFC 3473, January 2003. 144 6.2 Informative References 146 [RFC4090] Pan, P., Swallow, G., and Atlas, A., "Fast Reroute 147 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 148 May 2005. 150 [RFC4736] Vasseur, JP., Ikejiri, Y., and Zhang, R., 151 "Reoptimization of Multiprotocol Label Switching (MPLS) 152 Traffic Engineering (TE) Loosely Routed Label Switched 153 Path (LSP)", RFC 4736, November 2006. 155 7. Author's Address 157 Adrian Farrel 158 Old Dog Consulting 160 Email: adrian@olddog.co.uk 162 8. Intellectual Property Consideration 164 The IETF takes no position regarding the validity or scope of any 165 Intellectual Property Rights or other rights that might be claimed to 166 pertain to the implementation or use of the technology described in 167 this document or the extent to which any license under such rights 168 might or might not be available; nor does it represent that it has 169 made any independent effort to identify any such rights. Information 170 on the procedures with respect to rights in RFC documents can be 171 found in BCP 78 and BCP 79. 173 Copies of IPR disclosures made to the IETF Secretariat and any 174 assurances of licenses to be made available, or the result of an 175 attempt made to obtain a general license or permission for the use of 176 such proprietary rights by implementers or users of this 177 specification can be obtained from the IETF on-line IPR repository at 178 http://www.ietf.org/ipr. 180 The IETF invites any interested party to bring to its attention any 181 copyrights, patents or patent applications, or other proprietary 182 rights that may cover technology that may be required to implement 183 this standard. Please address the information to the IETF at ietf- 184 ipr@ietf.org. 186 9. Full Copyright Statement 188 Copyright (C) The IETF Trust (2007). 190 This document is subject to the rights, licenses and restrictions 191 contained in BCP 78, and except as set forth therein, the authors 192 retain all their rights. 194 This document and the information contained herein are provided on an 195 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 196 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 197 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 198 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 199 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 200 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.