idnits 2.17.1 draft-carpenter-obsolete-1888-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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 159. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (September 2004) is 7163 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) ** Obsolete normative reference: RFC 1888 (Obsoleted by RFC 4048) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. 'NSAP' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft B. Carpenter 3 Document: draft-carpenter-obsolete-1888-01.txt IBM 4 Expires: March 2005 6 September 2004 8 RFC 1888 is obsolete 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document recommends that RFC 1888, on OSI NSAPs and IPv6, be 35 reclassified Historic as most of it has no further value, apart from 36 one section which is faulty. 38 Table of Contents 40 1. Introduction 2 41 2. Recommendation to reclassify RFC 1888 2 42 3. Security Considerations 2 43 4. IANA Considerations 3 44 5. Acknowledgements 3 45 6. Normative References 3 46 7. Author's Address 3 48 RFC 1888 is obsolete September 2004 50 1. Introduction 52 [RFC 1888] was published as an Experimental RFC in 1996, at an early 53 stage in the development of IPv6, when it appeared important to 54 consider usage of Open Systems Interconnection (OSI) addressing for 55 IPv6. In Sections 3 through 5, it defines mappings of certain OSI 56 Network Service Access Point (NSAP) addresses inside IPv6 addresses, 57 and how to carry arbitrary NSAP addresses as IPv6 destination 58 options. However, it also contains significant "health warnings" 59 about the difficulty of routing packets in the global Internet using 60 such addresses. As far as is known to the IETF, these address 61 mappings have never been seriously used and are not supported by IPv6 62 implementations. Furthermore, the deployment of OSI solutions is not 63 sufficiently widespread that any change in this situation can be 64 expected. 66 Additionally, Section 6 of [RFC 1888] specifies a mapping of IPv6 67 addresses inside OSI NSAP addresses. This mapping has recently 68 aroused some interest, for example to allow IP addresses to be 69 expressed in an Asynchronous Transfer Mode (ATM) context. 70 Unfortunately, Section 6 of [RFC 1888] contains two errors in its 71 usage of OSI Initial Domain Part (IDP) format: 73 * firstly by referring in the text to the Internet Code Point (ICP) 74 as a single octet, whereas it is correctly a 16-bit field; 76 * secondly by stating that "The first three octets are an IDP in 77 binary format", but [NSAP] states in section A.5.2.1 that "The 78 abstract syntax for the IDI is decimal digits" and specifies a 79 preferred binary encoding in section A.5.3 "using a semi-octet to 80 represent the value of each decimal digit ... , yielding a value in 81 the range 0000-1001". 83 2. Recommendation to reclassify RFC 1888 85 Due to the lack of use of one of the mappings, and the errors in the 86 documentation of the other one, this document recommends the IESG to 87 reclassify [RFC 1888] as Historic. 89 It is assumed that parties who wish to use a mapping of IPv6 90 addresses inside OSI NSAP addresses will correct, augment, and 91 resubmit Section 6 of [RFC 1888] as a separate document. 93 3. Security Considerations 95 This recommendation has no known impact on the security of the 96 Internet. 98 RFC 1888 is obsolete September 2004 100 4. IANA Considerations 102 IANA is requested to mark the IPv6 address prefix 0000 001, reserved 103 for NSAP Allocation in [RFC 3513], as simply Reserved. 105 IANA is requested to hold the registry for ICD codes implied by 106 Section 6 of [RFC 1888] in abeyance until a replacement for that 107 Section is approved for publication. 109 5. Acknowledgements 111 Scott Brim and Arun Pandey made useful comments on this document. 113 6. Normative References 115 [RFC 1888] J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. 116 Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. 118 [RFC 3513] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) 119 Addressing Architecture", RFC 3513, April 2003. 121 [NSAP] International Organization for Standardization, "Information 122 technology -- Open Systems Interconnection -- Network service 123 definition", ISO/IEC 8348:2002, 2002. 125 7. Author's Address 127 Brian E. Carpenter 128 IBM Zurich Research Laboratory 129 Saeumerstrasse 4 / Postfach 130 8803 Rueschlikon 131 Switzerland 132 Email: brc@zurich.ibm.com 134 Intellectual Property Statement 136 The IETF takes no position regarding the validity or scope of any 137 Intellectual Property Rights or other rights that might be claimed to 138 pertain to the implementation or use of the technology described in 139 this document or the extent to which any license under such rights 140 might or might not be available; nor does it represent that it has 141 made any independent effort to identify any such rights. Information 142 on the IETF's procedures with respect to rights in IETF Documents can 143 be found in BCP 78 and BCP 79. 145 Copies of IPR disclosures made to the IETF Secretariat and any 146 assurances of licenses to be made available, or the result of an 147 attempt made to obtain a general license or permission for the use of 149 RFC 1888 is obsolete September 2004 151 such proprietary rights by implementers or users of this 152 specification can be obtained from the IETF on-line IPR repository at 153 http://www.ietf.org/ipr. 155 The IETF invites any interested party to bring to its attention any 156 copyrights, patents or patent applications, or other proprietary 157 rights that may cover technology that may be required to implement 158 this standard. Please address the information to the IETF at 159 ietf-ipr@ietf.org. 161 Disclaimer of Validity 163 This document and the information contained herein are provided on an 164 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 165 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 166 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 167 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 168 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 169 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 171 Copyright Statement 173 Copyright (C) The Internet Society (2004). This document is subject 174 to the rights, licenses and restrictions contained in BCP 78, and 175 except as set forth therein, the authors retain all their rights. 177 Acknowledgment 179 Funding for the RFC Editor function is currently provided by the 180 Internet Society.