idnits 2.17.1 draft-ietf-pwe3-iana-allocation-12.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 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 269. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 66: '... and MUST not be used....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Unless otherwise noted in this document, the value of 0 is reserved, and MUST not be used. -- 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 (September 2005) is 6796 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: 'Note1' is mentioned on line 92, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft 4 Expiration Date: March 2006 Cisco Systems Inc. 6 September 2005 8 IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) 10 draft-ietf-pwe3-iana-allocation-12.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 other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document pre-allocates the fixed Pseudo-wire identifier , and 37 other fixed protocol values for protocols defined primarily in the 38 pseudo wire edge to edge working group. ( PWE3 ) Detailed IANA 39 allocation instructions are also included in this document. 41 Table of Contents 43 1 Specification of Requirements .......................... 2 44 2 IANA Considerations .................................... 2 45 2.1 Pseudowire Type ........................................ 2 46 2.2 Interface Parameters Sub-TLV type ...................... 3 47 2.3 Attachment Identifiers ................................. 4 48 2.3.1 Attachment Individual Identifier Type .................. 4 49 2.3.2 Attachment Group Identifier (AGI) Type ................. 5 50 2.4 Pseudo Wire Status ..................................... 5 51 3 Security Considerations ................................ 6 52 4 Full Copyright Statement ............................... 6 53 5 Intellectual Property Statement ........................ 6 54 6 Normative References ................................... 7 55 7 Author Information ..................................... 7 57 1. Specification of Requirements 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 63 2. IANA Considerations 65 Unless otherwise noted in this document, the value of 0 is reserved, 66 and MUST not be used. 68 2.1. Pseudowire Type 70 IANA needs to set up a registry of "Pseudowire Type". These are 15- 71 bit values. PW Type values 1 through 30 are specified in this 72 document, PW Type values 31 through 1024 are to be assigned by IANA, 73 using the "Expert Review" policy defined in [RFC2434]. PW Type values 74 1025 through 4096, and 32768 are reserved for future use, and are not 75 to be allocated by IANA. PW Type values 4097 through 32767 are 76 reserved for vendor proprietary extensions and are to be assigned by 77 IANA, using the "First Come First Served" policy defined in RFC2434. 78 A Pseudowire Type description of up to 65 characters is required for 79 any assignment from this registry. 81 Initial Pseudowire type value allocations are specified below: 83 PW type Description 85 0x0001 Frame Relay DLCI ( Martini Mode ) 86 0x0002 ATM AAL5 SDU VCC transport 87 0x0003 ATM transparent cell transport 88 0x0004 Ethernet Tagged Mode 89 0x0005 Ethernet 90 0x0006 HDLC 91 0x0007 PPP 92 0x0008 SONET/SDH Circuit Emulation Service Over MPLS(CEM) [Note1] 93 0x0009 ATM n-to-one VCC cell transport 94 0x000A ATM n-to-one VPC cell transport 95 0x000B IP Layer2 Transport 96 0x000C ATM one-to-one VCC Cell Mode 97 0x000D ATM one-to-one VPC Cell Mode 98 0x000E ATM AAL5 PDU VCC transport 99 0x000F Frame-Relay Port mode 100 0x0010 SONET/SDH Circuit Emulation over Packet (CEP) 101 0x0011 Structure-agnostic E1 over Packet (SAToP) 102 0x0012 Structure-agnostic T1 (DS1) over Packet (SAToP) 103 0x0013 Structure-agnostic E3 over Packet (SAToP) 104 0x0014 Structure-agnostic T3 (DS3) over Packet (SAToP) 105 0x0015 CESoPSN basic mode 106 0x0016 TDMoIP AAL1 Mode 107 0x0017 CESoPSN TDM with CAS 108 0x0018 TDMoIP AAL2 Mode 109 0x0019 Frame Relay DLCI 110 0x001A cTCP (RFC1144) Transport Header-compressed Packets 111 0x001B IPHC (RFC2507) Transport Header-compressed Packets 112 0x001C cRTP (RFC2508) Transport Header-compressed Packets 113 0x001D ROHC (RFC3095) Transport Header-compressed Packets 114 0x001E eCRTP (RFC3545) Transport Header-compressed Packets 116 Note 1: This PW type is grandfathered for a historical protocol. The 117 recommended standards-track protocol to use is CEP (PW type 0x0010). 119 2.2. Interface Parameters Sub-TLV type 121 IANA needs to set up a registry of "Pseudowire Interface Parameter 122 Sub-TLV types". These are 8 bit values. Sub-TLV types 1 through 12 123 are specified in this document. Sub-TLV types 13 through 64 are to be 124 assigned by IANA, using the "Expert Review" policy defined in 125 RFC2434. Sub-TLV types 65 through 127, and 255 are reserved for 126 future use, and are not to be allocated by IANA. Sub-TLV types 127 values 128 through 254 are reserved for vendor proprietary extensions 128 and are to be assigned by IANA, using the "First Come First Served" 129 policy defined in RFC2434. 131 Any assignments requested from this registry require a description up 132 to 54 characters. Furthermore a length specified as follows: 133 - A decimal integer 134 - Text as follows:"up to X", where X is a decimal integer 135 - Up to 3 different decimal integers. 137 is also required for assignment from this registry. 139 Initial Pseudowire Interface Parameter Sub-TLV type allocations are 140 specified below: 141 Parameter ID Length Description 143 0x01 4 Interface MTU in octets 144 0x02 4 Maximum Number of concatenated ATM cells 145 0x03 up to 82 Optional Interface Description string 146 0x04 4 CEP/TDM Payload Bytes 147 0x05 4 CEP options 148 0x06 4 Requested VLAN ID 149 0x07 6 CEP/TDM bit-rate 150 0x08 4 Frame-Relay DLCI Length 151 0x09 4 Fragmentation indicator 152 0x0A 4 FCS retention indicator 153 0x0B 4/8/12 TDM options 154 0x0C 4 VCCV parameter 156 Note that the Length field is defined as the length of the Sub-TLV 157 including the Sub-TLV type and length field itself. 159 2.3. Attachment Identifiers 161 2.3.1. Attachment Individual Identifier Type 163 IANA needs to set up a registry of "Attachment Individual Identifier 164 (AII) Type". These are 8-bit values. AII Type value 1 is defined in 165 this document. AII Type values 2 through 64 are to be assigned by 166 IANA using the "Expert Review" policy defined in RFC2434. AII Type 167 values 65 through 127, and 255 are reserved for future use, and are 168 not to be allocated by IANA. AII types values 128 through 254 are 169 reserved for vendor proprietary extensions and are to be assigned by 170 IANA, using the "First Come First Served" policy defined in RFC2434. 172 Any assignments requested from this registry require a description up 173 to 54 characters. Furthermore a length specified as follows: 175 - A decimal integer 176 - Text as follows:"up to X", where X is a decimal integer 177 - the word "Variable" 178 Initial Attachment Individual Identifier (AII) Type allocations are 179 specified below: 180 AII Type Length Description 181 0x014 A 32 bit unsigned number local identifier. 183 2.3.2. Attachment Group Identifier (AGI) Type 185 IANA needs to set up a registry of "Attachment Group Identifier (AGI) 186 Type". These are 8-bit values. AGI Type value 1 is defined in this 187 document. AGI Type values 2 through 64 are to be assigned by IANA 188 using the "Expert Review" policy defined in RFC2434. AGI Type values 189 65 through 127, and 255 are reserved for future use, and are not to 190 be allocated by IANA. AGI types values 128 through 254 are reserved 191 for vendor proprietary extensions and are to be assigned by IANA, 192 using the "First Come First Served" policy defined in RFC2434. 194 Any assignments requested from this registry require a description up 195 to 54 characters. Furthermore a length specified as follows: 196 - A decimal integer 197 - Text as follows:"up to X", where X is a decimal integer 198 - the word "Variable" 199 Initial Attachment Group Identifier (AGI) Type allocations are 200 specified below: 201 AGI Type Length Description 202 0x018 A route distinguisher (RD) as defined in rfc2547 204 2.4. Pseudo Wire Status 206 IANA needs to set up a registry of "Pseudowire Status Codes". These 207 are bitstrings of length 32. Status bits 0 to 4 are defined in this 208 document. Status bits 5 to 31 are to be assigned by IANA using the 209 "Expert Review" policy defined in RFC2434. 211 Any requests for allocation from this registry must include a 212 description up to 65 characters. 214 Initial Pseudowire Status Codes value allocations are as follows: 216 Bit MaskDescription 217 0x00000000 - Pseudo Wire forwarding ( clear all failures ) 218 0x00000001 - Pseudo Wire Not Forwarding 219 0x00000002 - Local Attachment Circuit ( ingress ) Receive Fault 220 0x00000004 - Local Attachment Circuit ( egress ) Transmit Fault 221 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault 222 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault 224 3. Security Considerations 226 This document specifies only fixed identifiers, and not the protocols 227 used to carry the encapsulated packets across the network. Each such 228 protocol may have its own set of security issues, but those issues 229 are not affected by the identifiers specified herein. 231 4. Full Copyright Statement 233 Copyright (C) The Internet Society (2005). 235 This document is subject to the rights, licenses and restrictions 236 contained in BCP 78, and except as set forth therein, the authors 237 retain all their rights. 239 This document and the information contained herein are provided on an 240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 242 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 243 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 244 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 247 5. Intellectual Property Statement 249 The IETF takes no position regarding the validity or scope of any 250 Intellectual Property Rights or other rights that might be claimed to 251 pertain to the implementation or use of the technology described in 252 this document or the extent to which any license under such rights 253 might or might not be available; nor does it represent that it has 254 made any independent effort to identify any such rights. Information 255 on the procedures with respect to rights in RFC documents can be 256 found in BCP 78 and BCP 79. 258 Copies of IPR disclosures made to the IETF Secretariat and any 259 assurances of licenses to be made available, or the result of an 260 attempt made to obtain a general license or permission for the use of 261 such proprietary rights by implementers or users of this 262 specification can be obtained from the IETF on-line IPR repository at 263 http://www.ietf.org/ipr. 265 The IETF invites any interested party to bring to its attention any 266 copyrights, patents or patent applications, or other proprietary 267 rights that may cover technology that may be required to implement 268 this standard. Please address the information to the IETF at ietf- 269 ipr@ietf.org. 271 6. Normative References 273 [RFC2434] " Guidelines for Writing an IANA Considerations Section 274 in RFCs", BCP26, October 1998. 276 7. Author Information 278 Luca Martini 279 Cisco Systems, Inc. 280 9155 East Nichols Avenue, Suite 400 281 Englewood, CO, 80112 282 e-mail: lmartini@cisco.com