idnits 2.17.1 draft-fenner-zinin-rtg-standard-reqts-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 628. ** 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. RFC 2119 keyword, line 198: '... extension to it SHOULD NOT be put on ...' RFC 2119 keyword, line 201: '...Experimental RFC SHOULD be considered....' RFC 2119 keyword, line 240: '...munity, the IESG MAY decide to waive s...' RFC 2119 keyword, line 247: '...ast Call message SHALL include the exp...' 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 (October 23, 2005) is 6760 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: 'Huston' is mentioned on line 137, but not defined == Missing Reference: '2026' is mentioned on line 449, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 -- Obsolete informational reference (is this intentional?): RFC 1264 (Obsoleted by RFC 4794) -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 3768 (Obsoleted by RFC 5798) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Fenner 3 Internet-Draft AT&T Labs - Research 4 Expires: April 26, 2006 A. Zinin 5 Alcatel 6 October 23, 2005 8 Internet Routing Protocol Standardization Criteria 9 draft-fenner-zinin-rtg-standard-reqts-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document provides guidance for the advancement of the protocols 43 produced within the IETF Routing Area. It places implementation and 44 interoperability constraints on protocols earlier in the standards 45 process than RFC 2026, based on RFC 2026's provision that the IESG 46 may require implementation and/or operational experience prior to 47 granting Proposed Standard status to a specification that materially 48 affects the core Internet protocols or that specifies behavior that 49 may have significant operational impact on the Internet. 51 We also discuss the applicability of these rules to protocols and 52 their extensions. 54 Table of Contents 56 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Note on protocol extensions . . . . . . . . . . . . . . . 5 62 3.2. Variance procedure . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Appeal processes . . . . . . . . . . . . . . . . . . . . . 6 65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Requirements for Proposed Standard . . . . . . . . . . . . 6 67 4.2. Requirements for Draft Standard . . . . . . . . . . . . . 7 68 4.3. Requirements for Standard . . . . . . . . . . . . . . . . 7 69 4.4. Optional Protocol Analysis . . . . . . . . . . . . . . . . 8 71 5. Submitting . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.1. Submitting for Proposed Standard . . . . . . . . . . . . . 10 73 5.2. Submitting for Draft Standard or Standard . . . . . . . . 11 75 6. Changes from RFC 1264 . . . . . . . . . . . . . . . . . . . . 11 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 88 A.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 91 Intellectual Property and Copyright Statements . . . . . . . . . . 15 93 1. Problem Statement 95 The three-stage IETF standardization process is described in BCP 9, 96 RFC 2026 [RFC2026]. In brief, the three stages of Internet 97 standardization are Proposed (which requires a well written, openly 98 reviewed specification), Draft (which requires Proposed status, 99 multiple implementations and some operational experience), and full 100 Internet Standard (which requires Draft status and more extensive 101 operational experience). Historically, increased requirements, 102 originally documented in RFC 1264 [RFC1264], have been applied to 103 protocols produced within the Routing Area. 105 NOTE: There is also ongoing work in the NEWTRK Working Group [1] on 106 an updated IETF Standards Track. At this time the document uses 107 the current standards track specified in RFC 2026. It will be 108 modified to reflect changes in the IETF standards track as needed. 110 The purpose of this document is to provide more specific guidance for 111 the advancement of the protocols produced within the IETF Routing 112 Area, consistent with RFC 2026's guidance: 114 The IESG may require implementation and/or operational experience 115 prior to granting Proposed Standard status to a specification that 116 materially affects the core Internet protocols or that specifies 117 behavior that may have significant operational impact on the 118 Internet. 120 Different types of protocols and all levels of the standardization 121 process are covered. 123 2. Motivation 125 The reason for elevated requirements for routing-related technologies 126 is in the greater cost of a mistake compared to other technologies 127 used in the Internet, as well as in particular attention to the 128 scaling characteristics. Unlike other Internet technologies that 129 require cooperation of a limited set of devices (e.g., two stations 130 in case of a transport protocol, or a group of devices on the same 131 subnet in case of ARP), routing protocols and related technologies 132 normally implement some version of a distributed algorithm involving 133 a large number of nodes (routers) in the network. As an example, a 134 single OSPF domain [RFC2328] may consist of a thousand routers, and 135 the total number of Autonomous Systems participating in global 136 Internet routing via BGP [I-D.ietf-idr-bgp4] is currently around 137 20,000 [Huston]. 139 Routing protocols are complex, widely distributed, real-time 140 algorithms. They are difficult to implement and to test. Even 141 though a protocol may work in one environment with one 142 implementation, that does not ensure that it will work in a different 143 environment with multiple vendors. A routing protocol may work well 144 within a range of topologies and number of networks and routers, but 145 may fail when an unforeseen limit is reached. The result is that 146 even with considerable operational experience, it is hard to 147 guarantee that the protocol is mature enough for widespread 148 deployment. 150 Because of the distributed nature of routing, the effects of a 151 problem (resulting from, e.g., underspecification or ambiguities in 152 protocol documents leading to interpretation differences in 153 implementations) may easily propagate through the network, and result 154 in service degradation or complete loss of connectivity. 155 Scalability-related issues may have a similar effect -- a solution 156 with poor scaling characteristics may behave well in small 157 deployments, but collapse as the network grows further. 159 The goals intended to be achieved by elevating standardization 160 requirements for routing-related technologies can be summarized as 161 follows: 163 1. Ensure that the documentation is adequate for multiple 164 interoperable implementations of the technology to be developed 165 independently without the need to consult the original authors or 166 reverse-engineer an existing implementation. 168 2. Ensure that first-order problems in the technology have been 169 discovered and fixed, its basic scaling properties, limitations, 170 dynamics, and security aspects have been analysed before it is 171 put on the Internet standards track and gets widely deployed. 173 3. Ensure that a technology becomes a full Internet Standard only if 174 it has been independently implemented by multiple parties, has 175 received sufficient operational experience, and has shown 176 reasonable characteristics (e.g., scaling, convergence) in the 177 environments it has been already deployed and will be deployed in 178 the foreseeable future. 180 4. Ensure that it's possible to monitor (and optionally configure) 181 the system using an open, standard interface. 183 3. Applicability 185 The IETF Routing Area does not work exclusively on the routing 186 protocols. Its work scope includes encapsulation and forwarding 187 behavior (e.g., MPLS or multicast), MPLS label propagation and 188 signalling protocols (e.g. LDP, and RSVP-TE), first-hop redundancy 189 protocols (VRRP), router-internal protocols like FORCES, as well as 190 extensions to all of these. Not all requirements defined in this 191 document apply to every specification produced in the IETF Routing 192 Area. 194 All Routing Area submissions: In addition to the requirements 195 described in the Internet Standards Process [RFC2026], a 196 requirement that applies to all documents submitted to the IESG 197 for Internet Standards track publication within the Routing Area 198 is that a protocol or an extension to it SHOULD NOT be put on the 199 Standards Track if no implementation exists for it. If it is 200 desirable to encourage implementation of a specification, 201 publication as an Experimental RFC SHOULD be considered. 203 Protocols subject to further requirement elevation: Elevated 204 requirements described in Section 4 of this document are 205 applicable to protocols implementing a distributed algorithm whose 206 functional domain spans more than one network segment (link) or 207 otherwise affects the state of the distributed routing system or 208 per-hop forwarding behavior, and extensions to such protocols. 210 To give specific examples, routing protocols like OSPF [RFC2328], BGP 211 [I-D.ietf-idr-bgp4], or PIM [I-D.ietf-pim-sm-v2-new] would fall 212 within the category of algorithms spanning more than one segment, and 213 hence elevated requirements would apply to them. The same is true 214 for LDP [RFC3036] and RSVP-TE [RFC3209]. On the other hand, 215 protocols like VRRP [RFC3768] or FORCES [I-D.ietf-forces-framework] 216 run on a single segment or even inside the node, and hence would not 217 fall into this category. 219 3.1. Note on protocol extensions 221 As stated above, the procedures described in this document are 222 equally applicable to both base protocol specifications and 223 extensions to them. However, as explained in Section 5, the 224 documentation required for protocol extensions is generally lighter 225 than for the base protocol specifications. 227 Note that even if a specification developed within the Routing area 228 is an extensions to a protocol initially developed elsewhere (other 229 IETF area or outside the IETF), principles laid out in this document 230 still apply. For example, RSVP-TE [RFC3209], [RFC1195]. 232 Also note, that all extensions to protocols that fall within the 233 elevated requirements category are automatically subject to at least 234 the same level of requirements as the base protocol, regardless of 235 the envisioned application or where in the IETF the extension has 236 been developed. 238 3.2. Variance procedure 240 In consultation with the community, the IESG MAY decide to waive some 241 or all of the requirements specified in this document. A situation 242 where this might be needed is when factors not envisioned in this 243 document arise and applying elevated requirements does more harm than 244 good. 246 If the IESG decides to waive some or all of the requirements, the 247 IETF Last Call message SHALL include the explanation of reasoning for 248 the variance. This will allow IETF participants to challenge the 249 IESG decision. 251 3.3. Appeal processes 253 All procedures described in this document are subject to the appeal 254 process described in [RFC2026], including the variance procedure in 255 that document's section 9. 257 4. Requirements 259 4.1. Requirements for Proposed Standard 261 1. Documents specifying the Protocol and its Usage. The 262 specification for the routing protocol must be well written such 263 that independent, interoperable implementations can be developed 264 solely based on the specification. For example, it should be 265 possible to develop an interoperable implementation without 266 consulting the original developers of the routing protocol. 268 2. A Management Information Base (MIB) must be written for the 269 protocol. The MIB does not need to submitted for Proposed 270 Standard at the same time as the routing protocol, but must be at 271 least an Internet Draft. 273 3. The security architecture of the protocol must be set forth 274 explicitly. The security architecture must include mechanisms 275 for authenticating protocol messages and may include other forms 276 of protection. 278 4. Two or more independent interoperable implementations must exist. 280 5. There must be evidence that the major features of the protocol 281 have been tested. 283 6. No operational experience is required for the routing protocol at 284 this stage in the standardization process. 286 See Section 5.1 for submission guidelines for the required reports. 288 4.2. Requirements for Draft Standard 290 1. Revisions to the Protocol and Usage documents showing changes and 291 clarifications made based on experience gained in the time 292 between when the protocol was made a Proposed Standard and it 293 being submitted for Draft Standard. The revised documents should 294 include a section summarizing the changes made. 296 2. The Management Information Base (MIB) must be at the Proposed 297 Standard level of standardization. 299 3. The security architecture of the protocol must be set forth 300 explicitly. The security architecture must include mechanisms 301 for authenticating protocol messages and may include other forms 302 of protection. 304 4. Two or more interoperable implementations must exist. At least 305 two must be written independently. 307 5. There must be evidence that all features of the protocol have 308 been tested, running between at least two implementations. This 309 must include that all of the security features have been 310 demonstrated to operate, and that the mechanisms defined in the 311 protocol actually provide the intended protection. 313 6. There must be significant operational experience. This must 314 include running in a moderate number routers configured in a 315 moderately complex topology, and must be part of the operational 316 Internet. All significant features of the protocol must be 317 exercised. In the case of an Interior Gateway Protocol (IGP), 318 both interior and exterior routes must be carried (unless another 319 mechanism is provided for the exterior routes). In the case of a 320 Exterior Gateway Protocol (EGP), it must carry the full 321 complement of exterior routes. 323 See Section 5.2 for submission guidelines for the required reports. 325 4.3. Requirements for Standard 327 1. Revisions to the Protocol and Usage documents showing changes and 328 clarifications made based on experience gained in the time 329 between when the protocol was made a Draft Standard and it being 330 submitted for Standard. The changes should be to clarify the 331 protocol or provide guidance in its implementation. No 332 significant changes can be made to the protocol at this stage. 333 The revised documents should include a section summarizing the 334 changes made. 336 2. The Management Information Base (MIB) must be submitted for 337 Standard at the same time as the routing protocol. 339 3. The security architecture of the protocol must be set forth 340 explicitly. The security architecture must include mechanisms 341 for authenticating protocol messages and may include other forms 342 of protection. 344 4. Three or more interoperable implementations must exist. At least 345 two must be written independently. 347 5. There must be evidence that all features of the protocol have 348 been tested, running between at least two independently written 349 implementations. This must include that all of the security 350 features have been demonstrated to operate, and that the 351 mechanisms defined in the protocol actually provide the intended 352 protection. 354 6. There must be significant operational experience. This must 355 include running in a large number routers configured in a complex 356 topology, and must be part of the operational Internet. The 357 operational experience must include multi-vendor operation. All 358 significant features of the protocol must be exercised. In the 359 case of an Interior Gateway Protocol (IGP), both interior and 360 exterior routes must be carried (unless another mechanism is 361 provided for the exterior routes). In the case of a Exterior 362 Gateway Protocol (EGP), it must carry the full complement of 363 exterior routes. 365 See Section 5.2 for submission guidelines for the required reports. 367 4.4. Optional Protocol Analysis 369 When a protocol introduces previously unknown algorithms or 370 techniques, the Area Directors may require that the working group 371 produce a Protocol Analysis. This protocol analysis will be a 372 separately-chartered working group work item, and may be a 373 prerequisite for publication at Draft Standard or Standard. 375 The Protocol Analysis must summarize the key features of the protocol 376 and analyze how the protocol will perform and scale in the Internet. 377 The intent of this requirement is to understand the boundary 378 conditions of the routing protocol. The new routing protocol must be 379 compared with the existing routing protocols (e.g., OSPF, BGP, etc.) 380 as appropriate. The report should answer several questions: 382 o What are the key features and algorithms of the protocol? 384 o How much link bandwidth, router memory and router CPU cycles does 385 the protocol consume under normal conditions? 387 o For these metrics, how does the usage scale as the routing 388 environment grows? This should include topologies at least an 389 order of magnitude larger than the current environment. 391 o What are the limits of the protocol for these metrics? (I.e., 392 when will the routing protocol break?) 394 o For what environments is the protocol well suited, and for what is 395 it not suitable? 397 When submitting for Standard, this report should simply be a revision 398 of the report that was submitted for Draft Standard; it must describe 399 the additional knowledge and understanding gained in the time between 400 when the protocol was made a Draft standard and when it was submitted 401 for Standard. 403 5. Submitting 405 Before submitting a Technical Specification for publication, the WG 406 chairs must ensure that the following steps have been completed: 408 1. The documents have undergone a Last Call in the Working Group, 409 major technical issues have been resolved, and there's a clear 410 support for publication. 412 2. The documents being submitted have been reviewed by the Routing 413 Area Directorate and all identified issues have been discussed 414 and, if necessary resolved. It is recommended that a review 415 request to the Directorate is initiated during the Working Group 416 Last Call. 418 3. The implementation and interoperability report has been submitted 419 to the IETF secretariat, and is publicly available at the IETF 420 web site. This report should include: 422 * Implementation experience. 424 * List of implementations including origin of code. 426 * Interoperability report. 428 * Test scenarios and test results showing that the major 429 features of the protocols have been tested. 431 5.1. Submitting for Proposed Standard 433 When submitting a specification or a bundle of documents to the ADs 434 for publication as Proposed Standard, the WG chairs (or the document 435 authors in case of an individual submission) send an E-mail message 436 to the Routing ADs, with a copy (in the "Cc:" field) to the IETF 437 secretariat (iesg-secretary@ietf.org) with the following information: 439 1. The name of the Internet-Draft(s) that contain the Technical 440 Specification(s) being submitted, as well as the desired 441 publication level (Proposed Standard in this case). Note that if 442 more than one document is submitted, each document may have a 443 different target status. These documents will be grouped in a 444 bundle, and will be processed for the IETF Last Call and IESG 445 review as a group. 447 2. If an Applicability Statement is included in the submission, the 448 name of the I-D containing the AS, as well as the target 449 publication status for it. Note that per [2026] the publication 450 level of the AS cannot be higher than the publication level of 451 the Technical Specification (item 1 above). 453 3. A brief description (technical summary) of the protocol. This 454 information will be used during the IETF Last Call and the IESG 455 review processes. The summary should include information such 456 as: 458 * What are the key features and algorithms of the protocol? 460 * For what environments is the protocol well suited, and for 461 what is it not suitable? 463 4. A pointer (e.g. URL) to the implementation and interoperability 464 report previously submitted to the IETF secretariat. 466 5. A pointer to the corresponding MIB document with an explanation 467 of how the MIB maturity requirement has been satisfied, or an 468 explanation of why no MIB modifications are required to support 469 functionality described in the Technical Specification. 471 6. Summary of the Routing Directorate review results, major issues 472 that were identified, whether they were discussed and resolved. 474 7. Any other reports or pointers to the documents otherwise required 475 by the IETF process, such as the PROTO writeup described at 476 . 478 5.2. Submitting for Draft Standard or Standard 480 In addition to the requirements listed in Section 5.1, when 481 submitting for Draft Standard or Standard, the submission must 482 include an additional report: 484 Description of operational experience. This must include 485 topology, environment, time and duration, implementations 486 involved, and overall results and conclusions gained from the 487 operational experience. 489 For a protocol, this report must be a separate document; for an 490 extension to an existing protocol, it may be sent as part of the 491 submission email. 493 6. Changes from RFC 1264 495 o Update to require two interoperable implementations for Proposed 496 Standard. 498 o Add explicit descriptions of what does and doesn't need to be 499 treated under the extended rules. 501 o Require an implementation for any standards-track document. 503 o Add an escape mechanism (IETF Last Call) so that the community can 504 comment on the decision of whether or not to apply these rules. 506 o Clarify protocol submission guidelines. 508 o Clarify how the process applies to protocol extensions. 510 o Remove security description from reports; it's required in the 511 specification already. 513 7. IANA Considerations 515 This document makes no request of IANA. 517 Note to RFC Editor: this section may be removed on publication as an 518 RFC. 520 8. Security Considerations 522 9. Acknowledgments 524 Bob Hinden wrote the original version of this document (RFC 1264 525 [RFC1264]) when he was Routing Area Director and the IETF was a very 526 different place. Most of the original document remains. 528 10. References 530 10.1. Normative References 532 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 533 3", BCP 9, RFC 2026, October 1996. 535 10.2. Informative References 537 [I-D.ietf-forces-framework] 538 Yang, L., "Forwarding and Control Element Separation 539 (ForCES) Framework", draft-ietf-forces-framework-13 (work 540 in progress), January 2004. 542 [I-D.ietf-idr-bgp4] 543 Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", 544 draft-ietf-idr-bgp4-26 (work in progress), October 2004. 546 [I-D.ietf-pim-sm-v2-new] 547 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 548 "Protocol Independent Multicast - Sparse Mode PIM-SM): 549 Protocol Specification (Revised)", 550 draft-ietf-pim-sm-v2-new-11 (work in progress), 551 October 2004. 553 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 554 dual environments", RFC 1195, December 1990. 556 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 557 Routing Protocol Standardization Criteria", RFC 1264, 558 October 1991. 560 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 562 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 563 B. Thomas, "LDP Specification", RFC 3036, January 2001. 565 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 566 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 567 Tunnels", RFC 3209, December 2001. 569 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 570 RFC 3768, April 2004. 572 URIs 574 [1] 576 Appendix A. Change Log 578 A.1. Changes since -00 580 o Changed "SHALL NOT" to "SHOULD NOT" in the requirement of one 581 implementation for all standards-track Routing Area Documents. 583 o Added that the two implementations for PS must be independent 585 o Moved the Protocol Analysis out of the required set of documents 586 to Section 4.4. 588 Authors' Addresses 590 Bill Fenner 591 AT&T Labs - Research 592 75 Willow Rd 593 Menlo Park, CA 94025 594 USA 596 Phone: +1 650 330-7893 597 Email: fenner@research.att.com 599 Alex Zinin 600 Alcatel 601 701 E Middlefield Rd 602 Mountain View, California 94043 604 Email: zinin@psg.com 606 Intellectual Property Statement 608 The IETF takes no position regarding the validity or scope of any 609 Intellectual Property Rights or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; nor does it represent that it has 613 made any independent effort to identify any such rights. Information 614 on the procedures with respect to rights in RFC documents can be 615 found in BCP 78 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the use of 620 such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR repository at 622 http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights that may cover technology that may be required to implement 627 this standard. Please address the information to the IETF at 628 ietf-ipr@ietf.org. 630 Disclaimer of Validity 632 This document and the information contained herein are provided on an 633 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 634 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 635 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 636 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 637 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 640 Copyright Statement 642 Copyright (C) The Internet Society (2005). This document is subject 643 to the rights, licenses and restrictions contained in BCP 78, and 644 except as set forth therein, the authors retain all their rights. 646 Acknowledgment 648 Funding for the RFC Editor function is currently provided by the 649 Internet Society.