idnits 2.17.1 draft-ietf-idr-rfc1863-historic-00.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 142. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 132. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 148), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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 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, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 4 longer pages, the longest (page 2) being 72 lines == 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 (June 4, 2004) is 7259 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 1863 (ref. '1') (Obsoleted by RFC 4223) -- Obsolete informational reference (is this intentional?): RFC 2796 (ref. '2') (Obsoleted by RFC 4456) -- Obsolete informational reference (is this intentional?): RFC 3065 (ref. '3') (Obsoleted by RFC 5065) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Inter-Domain Routing P. Savola 2 Internet-Draft CSC/FUNET 3 Obsoletes: 1863 (if approved) June 4, 2004 4 Expires: December 3, 2004 6 Reclassification of RFC 1863 to Historic 7 draft-ietf-idr-rfc1863-historic-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 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 This Internet-Draft will expire on December 3, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative 41 to a full mesh routing, to Historic status. This memo also Obsoletes 42 RFC 1863. 44 1. Reclassification of RFC 1863 to Historic 46 RFC 1863 [1] describes the use of route servers as an alternative to 47 BGP/IDRP full mesh routing. 49 In the context of this document the term "RFC 1863 route server" is 50 used to refer to a route server as specified in RFC1863. Other uses 51 of the term "route server" are outside the scope of this document. 53 Implementations of RFC 1863 route servers do not exist, and are not 54 used as an alternative to full mesh routing. Therefore the RFC 1863 55 is reclassified to Historic status. 57 Current techniques that serve as an alternative to full mesh routing 58 include BGP Route Reflectors [2], BGP Confederedations [3] and the 59 use of private AS numbers. IDRP for IP has never been standardized 60 by the IETF and can be considered obsolete. 62 Other uses of (non-RFC1863) route servers, rather than as an 63 alternative to full mesh routing as described by RFC 1863, are 64 expected to continue be used for multiple purposes, but are out of 65 the scope of this memo. 67 2. Acknowledgements 69 Jeffrey Haas, John Scudder, Paul Jakma, and Yakov Rekhter provided 70 useful background information for the creation of this memo. Scott 71 Bradner, Jeffrey Haas and Yakov Rekhter provided substantial feedback 72 during the WG last call. 74 3. IANA Considerations 76 This memo includes no request to IANA. 78 [[Note to the RFC-Editor: this section should be removed prior to 79 publication.]] 81 4. Security Considerations 83 Reclassifying RFC 1863 has no security considerations. 85 5. References 87 5.1 Normative References 89 [1] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh 90 routing", RFC 1863, October 1995. 92 5.2 Informative References 94 [2] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An 95 Alternative to Full Mesh IBGP", RFC 2796, April 2000. 97 [3] Traina, P., McPherson, D. and J. Scudder, "Autonomous System 98 Confederations for BGP", RFC 3065, February 2001. 100 Author's Address 102 Pekka Savola 103 CSC/FUNET 105 Espoo 106 Finland 108 EMail: psavola@funet.fi 110 Intellectual Property Statement 112 The IETF takes no position regarding the validity or scope of any 113 Intellectual Property Rights or other rights that might be claimed to 114 pertain to the implementation or use of the technology described in 115 this document or the extent to which any license under such rights 116 might or might not be available; nor does it represent that it has 117 made any independent effort to identify any such rights. Information 118 on the procedures with respect to rights in RFC documents can be 119 found in BCP 78 and BCP 79. 121 Copies of IPR disclosures made to the IETF Secretariat and any 122 assurances of licenses to be made available, or the result of an 123 attempt made to obtain a general license or permission for the use of 124 such proprietary rights by implementers or users of this 125 specification can be obtained from the IETF on-line IPR repository at 126 http://www.ietf.org/ipr. 128 The IETF invites any interested party to bring to its attention any 129 copyrights, patents or patent applications, or other proprietary 130 rights that may cover technology that may be required to implement 131 this standard. Please address the information to the IETF at 132 ietf-ipr@ietf.org. 134 Disclaimer of Validity 136 This document and the information contained herein are provided on an 137 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 138 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 139 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 140 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 141 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 142 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 144 Copyright Statement 146 Copyright (C) The Internet Society (2004). This document is subject 147 to the rights, licenses and restrictions contained in BCP 78, and 148 except as set forth therein, the authors retain all their rights. 150 Acknowledgment 152 Funding for the RFC Editor function is currently provided by the 153 Internet Society.