idnits 2.17.1 draft-arkko-pppext-bap-ianafix-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2125, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2125, updated by this document, for RFC5378 checks: 1996-01-05) -- 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 7, 2009) is 5317 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2153' is mentioned on line 180, but not defined == Missing Reference: 'RFC 2125' is mentioned on line 209, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2153 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Updates: 2125 (if approved) J. Carlson 5 Intended status: BCP Workingcode 6 Expires: March 11, 2010 A. Baber 7 ICANN 8 September 7, 2009 10 IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol 11 (BAP) 12 draft-arkko-pppext-bap-ianafix-02 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and 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 Internet- 22 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/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 11, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document specifies the IANA guidelines for allocating new values 51 in the PPP Bandwidth Allocation and Bandwidth Allocation Control 52 Protocols. 54 1. Introduction 56 This document specifies the IANA guidelines [RFC5226] for allocating 57 new values for various fields in the PPP Bandwidth Allocation 58 Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP) 59 [RFC2125]. BACP is the control protocol for BAP, and is used to 60 manage the dynamic bandwidth allocation of implementations supporting 61 the PPP multilink protocol [RFC1990]. 63 The IANA guidelines are given in Section 2. Previously, no IANA 64 guidance existed for such allocations either in [RFC2125] or 65 [RFC3818]. The purpose of this document is to allow IANA to manage 66 number assignments based on these guidelines in a consistent manner. 67 This document also points to [RFC2153] which allows the construction 68 of vendor-specific packets and options. These mechanisms may also be 69 used for temporary experimental extensions, alleviating the need to 70 allocate specific experimental values in this document. 72 2. IANA Considerations 74 The IANA is instructed to create the following registries. For all 75 the registries, new values can be allocated through RFC Required 76 [RFC5226]. 78 IANA is instructed to create a registry for the BACP option values. 79 The initial contents of the registry should be as follows: 81 Registry Name: PPP BACP Configuration Option Types 82 Reference: [RFC2125 and XXX THIS RFC] 83 Registration Procedures: RFC Required 85 Type Configuration Option Reference 86 ---- -------------------- --------- 87 0 Vendor-Specific [RFC2153] 88 1 Favored-Peer [RFC2125] 89 2-255 Unassigned 91 IANA is also instructed to create a registry for the BAP Type field. 92 The initial contents of the registry should be as follows: 94 Registry Name: PPP BAP Type 95 Reference: [RFC2125 and XXX THIS RFC] 96 Registration Procedures: RFC Required 98 Type Datagram Reference 99 ---- -------------------- --------- 100 0 Vendor-Specific [RFC 2153] 101 1 Call-Request [RFC 2125] 102 2 Call-Response [RFC 2125] 103 3 Callback-Request [RFC 2125] 104 4 Callback-Response [RFC 2125] 105 5 Link-Drop-Query-Request [RFC 2125] 106 6 Link-Drop-Query-Response [RFC 2125] 107 7 Call-Status-Indication [RFC 2125] 108 8 Call-Status-Response [RFC 2125] 109 9-255 Unassigned 111 IANA is also instructed to create a registry for the BAP Response 112 Code field. The initial contents of the registry should be as 113 follows: 115 Registry Name: PPP BAP Response Code 116 Reference: [RFC2125 and XXX THIS RFC] 117 Registration Procedures: RFC Required 119 Value Response Code Reference 120 ---- -------------------- --------- 121 0 Request-Ack [RFC 2125] 122 1 Request-Nak [RFC 2125] 123 2 Request-Rej [RFC 2125] 124 3 Request-Full-Nak [RFC 2125] 125 4-255 Unassigned 127 IANA is also instructed to create a registry for the BAP Datagram 128 Option Type field. The initial contents of the registry should be as 129 follows: 131 Registry Name: PPP BAP Datagram Option Type 132 Reference: [RFC2125 and XXX THIS RFC] 133 Registration Procedures: RFC Required 135 Type Datagram Option Reference 136 ---- -------------------- --------- 137 0 Vendor-Specific [RFC 2153] 138 1 Link-Type [RFC 2125] 139 2 Phone-Delta [RFC 2125] 140 3 No-Phone-Number-Needed [RFC 2125] 141 4 Reason [RFC 2125] 142 5 Link-Discriminator [RFC 2125] 143 6 Call-Status [RFC 2125] 144 7-255 Unassigned 146 IANA is also instructed to create a registry for the BAP Link Type 147 field. The initial contents of the registry should be as follows: 149 Registry Name: PPP BAP Link Type 150 Reference: [RFC2125 and XXX THIS RFC] 151 Registration Procedures: RFC Required 153 Bit Link Type Reference 154 ---- -------------------- --------- 155 0 ISDN [RFC 2125] 156 1 X.25 [RFC 2125] 157 2 analog [RFC 2125] 158 3 switched digital (non-ISDN) [RFC 2125] 159 4 ISDN data over voice [RFC 2125] 160 5-7 Unassigned 162 Note the order of bits in this field as specified in Section 6.1 of 163 [RFC2125]: bit 0 of the Link Type field corresponds to bit 39 of the 164 Link-Type BAP Option. Also note that bits 5-7 were originally marked 165 reserved [RFC2125], but this RFC makes them in principle available 166 for allocation. New allocations are discouraged, however, as it 167 would be difficult to assess the impacts new bits might have on 168 interoperability with existing implementations. 170 IANA is also instructed to create a registry for the BAP Phone-Delta 171 Sub-Option Type field. The initial contents of the registry should 172 be as follows: 174 Registry Name: PPP BAP Phone-Delta Sub-Option Type 175 Reference: [RFC2125 and XXX THIS RFC] 176 Registration Procedures: RFC Required 178 Type Sub-Option Reference 179 ---- -------------------- --------- 180 0 Vendor-Specific [RFC 2153] 181 1 Unique-Digits [RFC 2125] 182 2 Subscriber-Number [RFC 2125] 183 3 Phone-Number-Sub-Address [RFC 2125] 184 4-255 Unassigned 186 IANA is also instructed to create a registry for the BAP Call Status 187 field. The initial contents of the registry should be as follows: 189 Registry Name: PPP BAP Call Status 190 Reference: [RFC2125 and XXX THIS RFC] 191 Registration Procedures: RFC Required 193 Value Call Status Reference 194 ----- -------------------- --------- 195 0 Success [RFC 2125] 196 1-254 Q.931 values [RFC 2125] [ITU.Q931.1993] 197 255 Non-specific failure [RFC 2125] 199 IANA is also instructed to create a registry for the BAP Call Action 200 field. The initial contents of the registry should be as follows: 202 Registry Name: PPP BAP Call Action 203 Reference: [RFC2125 and XXX THIS RFC] 204 Registration Procedures: RFC Required 206 Value Action Reference 207 ----- -------------------- --------- 208 0 No retry [RFC 2125] 209 1 Retry [RFC 2125] 210 2-255 Unassigned 212 3. Security Considerations 214 This specification does not change the security properties of BAP or 215 BACP. 217 However, a few words are necessary about the use of vendor-specific 218 extensions. Obviously, the use of vendor-specific extensions affects 219 interoperability. General purpose extensions would be better defined 220 as standard extensions. Similarly, if vendor-specific extensions are 221 used to test temporary experimental designs, guidance given in 222 [RFC3692] should be followed to avoid potentially harmful side- 223 effects. 225 4. Acknowledgments 227 The lack of any registration procedures has come up in IANA's review 228 of existing registries and RFCs. 230 5. References 232 5.1. Normative References 234 [RFC2125] Richards, C. and K. Smith, "The PPP Bandwidth Allocation 235 Protocol (BAP) The PPP Bandwidth Allocation Control 236 Protocol (BACP)", RFC 2125, March 1997. 238 [RFC2153] Simpson, W. and K. Fox, "PPP Vendor Extensions", RFC 2153, 239 May 1997. 241 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 242 Considered Useful", BCP 82, RFC 3692, January 2004. 244 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 245 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 246 May 2008. 248 5.2. Informative References 250 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 251 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 252 August 1996. 254 [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point 255 Protocol (PPP)", BCP 88, RFC 3818, June 2004. 257 [ITU.Q931.1993] 258 International Telecommunications Union, "ISDN user-network 259 interface layer 3 specification for basic call control", 260 ITU-T Recommendation Q.931, May 1993. 262 Appendix A. Changes from the Original RFCs 264 This document specifies only the IANA rules associated with various 265 fields in BAP and BACP, and does not change the operation of the 266 protocols themselves. 268 Appendix B. Acknowledgments 270 The authors would like to thank Carlos Pignataro, Eswaran Srinivasan, 271 Ignacio Goyret, and Bill Simpson for feedback. 273 Authors' Addresses 275 Jari Arkko 276 Ericsson 277 Jorvas 02420 278 Finland 280 Email: jari.arkko@piuha.net 282 James D. Carlson 283 Workingcode 285 Email: carlsonj@workingcode.com 287 Amanda Baber 288 ICANN 290 Email: amanda.baber@icann.org