idnits 2.17.1 draft-schryver-pppext-iana-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 233 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 2003) is 7554 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? '1' on line 46 looks like a reference -- Missing reference section? '2' on line 68 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Schryver 3 Internet Draft Rhyolite Software 4 August 2003 6 IANA Considerations for the Point-to-Point Protocol (PPP) 7 draft-schryver-pppext-iana-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute 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 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on January 15, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 The charter of the Point-to-Point Protocol Extensions (pppext) 38 working group includes the responsibility to "actively advance PPP's 39 most useful extensions to full standard, while defending against 40 further enhancements of questionable value." In support of that 41 charter, the allocation of PPP protocol and other assigned numbers 42 will no longer be "first come first served." 44 Introduction 46 The Point-to-Point protocol (PPP, RFC 1661 [1]) is a mature protocol 47 with a large number of subprotocols, encapsulations and other 48 extensions. The main protocol as well as its extensions involve many 49 name spaces in which values must be assigned. 50 Http://www.iana.org/assignments/ppp-numbers contains a list of the 51 address spaces and their current assignments. 53 Historically, initial values in new name spaces have often been 54 chosen in the RFCs creating the name spaces. The IANA made 55 subsequent assignments with a "First Come First Served" policy. This 56 memo changes that policy for some PPP address spaces. 58 Most of the PPP names spaces are quiescent, but some continue to 59 attract proposed extensions. Extensions of PPP have been defined in 60 RFCs that are "Informational" and so are not subject to review. 61 These extensions usually require values assigned in one or more of 62 the PPP name spaces. Making these allocations require "IETF 63 Consensus" will ensure that proposals are reviewed. 65 Terminology 67 The terms "name space", "assigned value", and "registration" are used 68 here with the meanings defined in BCP 26 [2]. The policies "First 69 Come First Served" and "IETF Consensus" used here also have the 70 meanings defined in BCP 26. 72 IANA Considerations for PPP 74 IETF Consensus, usually through the Point-to-Point Protocol 75 Extensions (pppext) working group, is required for assigning new 76 values in the following address spaces: 78 PPP DLL PROTOCOL NUMBERS 79 PPP LCP AND IPCP CODES 80 PPP LCP CONFIGURATION OPTION TYPES 81 PPP CCP CONFIGURATION OPTION TYPES 82 PPP CHAP AUTHENTICATION ALGORITHMS 83 PPP LCP FCS-ALTERNATIVES 84 PPP MULTILINK ENDPOINT DISCRIMINATOR CLASS 85 PPP LCP CALLBACK OPERATION FIELDS 86 PPP BRIDGING CONFIGURATION OPTION TYPES 87 PPP BRIDGING MAC TYPES 88 PPP BRIDGING SPANNING TREE 89 PPP IPCP CONFIGURATION OPTION TYPES 90 PPP IPV6CP CONFIGURATION OPTIONS 91 PPP IP-Compression-Protocol Types 93 4. Security Considerations 95 This memo deals with matters of process, not protocol. 97 Normative References 98 W. Simpson, Ed., "The Point-to-Point Protocol (PPP)", STD 51, 99 RFC 1661, July 1994. 100 Alvestrand, H. and T. Narten, "Guidelines for Writing an 101 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 102 October 1998. 104 Author's Address 106 Vernon Schryver 107 Rhyolite Software 108 2482 Lee Hill Drive 109 Boulder, Colorado 80302 111 EMail: vjs@rhyolite.com 113 Intellectual Property Statement 115 The IETF takes no position regarding the validity or scope of any 116 intellectual property or other rights that might be claimed to 117 pertain to the implementation or use of the technology described in 118 this document or the extent to which any license under such rights 119 might or might not be available; neither does it represent that it 120 has made any effort to identify any such rights. Information on the 121 IETF's procedures with respect to rights in standards-track and 122 standards-related documentation can be found in BCP-11. Copies of 123 claims of rights made available for publication and any assurances of 124 licenses to be made available, or the result of an attempt made to 125 obtain a general license or permission for the use of such 126 proprietary rights by implementors or users of this specification can 127 be obtained from the IETF Secretariat. 129 The IETF invites any interested party to bring to its attention any 130 copyrights, patents or patent applications, or other proprietary 131 rights which may cover technology that may be required to practice 132 this standard. Please address the information to the IETF Executive 133 Director. 135 Full Copyright Statement 137 Copyright (C) The Internet Society (2003). All Rights Reserved. 139 This document and translations of it may be copied and furnished to 140 others, and derivative works that comment on or otherwise explain it 141 or assist in its implementation may be prepared, copied, published 142 and distributed, in whole or in part, without restriction of any 143 kind, provided that the above copyright notice and this paragraph are 144 included on all such copies and derivative works. However, this 145 document itself may not be modified in any way, such as by removing 146 the copyright notice or references to the Internet Society or other 147 Internet organizations, except as needed for the purpose of 148 developing Internet standards in which case the procedures for 149 copyrights defined in the Internet Standards process must be 150 followed, or as required to translate it into languages other than 151 English. 153 The limited permissions granted above are perpetual and will not be 154 revoked by the Internet Society or its successors or assignees. 156 This document and the information contained herein is provided on an 157 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 158 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 159 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION