Internet DRAFT - draft-fenner-zinin-rtg-standard-reqts

draft-fenner-zinin-rtg-standard-reqts






Network Working Group                                          B. Fenner
Internet-Draft                                      AT&T Labs - Research
Expires: April 26, 2006                                         A. Zinin
                                                                 Alcatel
                                                        October 23, 2005


           Internet Routing Protocol Standardization Criteria
                draft-fenner-zinin-rtg-standard-reqts-01

Status of this Memo

   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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides guidance for the advancement of the protocols
   produced within the IETF Routing Area.  It places implementation and
   interoperability constraints on protocols earlier in the standards
   process than RFC 2026, based on RFC 2026's provision that the IESG
   may require implementation and/or operational experience prior to
   granting Proposed Standard status to a specification that materially
   affects the core Internet protocols or that specifies behavior that



Fenner & Zinin           Expires April 26, 2006                 [Page 1]

Internet-Draft         Routing Standards Criteria           October 2005


   may have significant operational impact on the Internet.

   We also discuss the applicability of these rules to protocols and
   their extensions.


Table of Contents

   1.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Note on protocol extensions  . . . . . . . . . . . . . . .  5
     3.2.  Variance procedure . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Appeal processes . . . . . . . . . . . . . . . . . . . . .  6

   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Requirements for Proposed Standard . . . . . . . . . . . .  6
     4.2.  Requirements for Draft Standard  . . . . . . . . . . . . .  7
     4.3.  Requirements for Standard  . . . . . . . . . . . . . . . .  7
     4.4.  Optional Protocol Analysis . . . . . . . . . . . . . . . .  8

   5.  Submitting . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Submitting for Proposed Standard . . . . . . . . . . . . . 10
     5.2.  Submitting for Draft Standard or Standard  . . . . . . . . 11

   6.  Changes from RFC 1264  . . . . . . . . . . . . . . . . . . . . 11

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12

   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12

   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 13
     A.1.  Changes since -00  . . . . . . . . . . . . . . . . . . . . 13

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15







Fenner & Zinin           Expires April 26, 2006                 [Page 2]

Internet-Draft         Routing Standards Criteria           October 2005


1.  Problem Statement

   The three-stage IETF standardization process is described in BCP 9,
   RFC 2026 [RFC2026].  In brief, the three stages of Internet
   standardization are Proposed (which requires a well written, openly
   reviewed specification), Draft (which requires Proposed status,
   multiple implementations and some operational experience), and full
   Internet Standard (which requires Draft status and more extensive
   operational experience).  Historically, increased requirements,
   originally documented in RFC 1264 [RFC1264], have been applied to
   protocols produced within the Routing Area.

   NOTE: There is also ongoing work in the NEWTRK Working Group [1] on
      an updated IETF Standards Track.  At this time the document uses
      the current standards track specified in RFC 2026.  It will be
      modified to reflect changes in the IETF standards track as needed.

   The purpose of this document is to provide more specific guidance for
   the advancement of the protocols produced within the IETF Routing
   Area, consistent with RFC 2026's guidance:

      The IESG may require implementation and/or operational experience
      prior to granting Proposed Standard status to a specification that
      materially affects the core Internet protocols or that specifies
      behavior that may have significant operational impact on the
      Internet.

   Different types of protocols and all levels of the standardization
   process are covered.


2.  Motivation

   The reason for elevated requirements for routing-related technologies
   is in the greater cost of a mistake compared to other technologies
   used in the Internet, as well as in particular attention to the
   scaling characteristics.  Unlike other Internet technologies that
   require cooperation of a limited set of devices (e.g., two stations
   in case of a transport protocol, or a group of devices on the same
   subnet in case of ARP), routing protocols and related technologies
   normally implement some version of a distributed algorithm involving
   a large number of nodes (routers) in the network.  As an example, a
   single OSPF domain [RFC2328] may consist of a thousand routers, and
   the total number of Autonomous Systems participating in global
   Internet routing via BGP [I-D.ietf-idr-bgp4] is currently around
   20,000 [Huston].

   Routing protocols are complex, widely distributed, real-time



Fenner & Zinin           Expires April 26, 2006                 [Page 3]

Internet-Draft         Routing Standards Criteria           October 2005


   algorithms.  They are difficult to implement and to test.  Even
   though a protocol may work in one environment with one
   implementation, that does not ensure that it will work in a different
   environment with multiple vendors.  A routing protocol may work well
   within a range of topologies and number of networks and routers, but
   may fail when an unforeseen limit is reached.  The result is that
   even with considerable operational experience, it is hard to
   guarantee that the protocol is mature enough for widespread
   deployment.

   Because of the distributed nature of routing, the effects of a
   problem (resulting from, e.g., underspecification or ambiguities in
   protocol documents leading to interpretation differences in
   implementations) may easily propagate through the network, and result
   in service degradation or complete loss of connectivity.
   Scalability-related issues may have a similar effect -- a solution
   with poor scaling characteristics may behave well in small
   deployments, but collapse as the network grows further.

   The goals intended to be achieved by elevating standardization
   requirements for routing-related technologies can be summarized as
   follows:

   1.  Ensure that the documentation is adequate for multiple
       interoperable implementations of the technology to be developed
       independently without the need to consult the original authors or
       reverse-engineer an existing implementation.

   2.  Ensure that first-order problems in the technology have been
       discovered and fixed, its basic scaling properties, limitations,
       dynamics, and security aspects have been analysed before it is
       put on the Internet standards track and gets widely deployed.

   3.  Ensure that a technology becomes a full Internet Standard only if
       it has been independently implemented by multiple parties, has
       received sufficient operational experience, and has shown
       reasonable characteristics (e.g., scaling, convergence) in the
       environments it has been already deployed and will be deployed in
       the foreseeable future.

   4.  Ensure that it's possible to monitor (and optionally configure)
       the system using an open, standard interface.


3.  Applicability

   The IETF Routing Area does not work exclusively on the routing
   protocols.  Its work scope includes encapsulation and forwarding



Fenner & Zinin           Expires April 26, 2006                 [Page 4]

Internet-Draft         Routing Standards Criteria           October 2005


   behavior (e.g., MPLS or multicast), MPLS label propagation and
   signalling protocols (e.g.  LDP, and RSVP-TE), first-hop redundancy
   protocols (VRRP), router-internal protocols like FORCES, as well as
   extensions to all of these.  Not all requirements defined in this
   document apply to every specification produced in the IETF Routing
   Area.

   All Routing Area submissions: In addition to the requirements
      described in the Internet Standards Process [RFC2026], a
      requirement that applies to all documents submitted to the IESG
      for Internet Standards track publication within the Routing Area
      is that a protocol or an extension to it SHOULD NOT be put on the
      Standards Track if no implementation exists for it.  If it is
      desirable to encourage implementation of a specification,
      publication as an Experimental RFC SHOULD be considered.

   Protocols subject to further requirement elevation: Elevated
      requirements described in Section 4 of this document are
      applicable to protocols implementing a distributed algorithm whose
      functional domain spans more than one network segment (link) or
      otherwise affects the state of the distributed routing system or
      per-hop forwarding behavior, and extensions to such protocols.

   To give specific examples, routing protocols like OSPF [RFC2328], BGP
   [I-D.ietf-idr-bgp4], or PIM [I-D.ietf-pim-sm-v2-new] would fall
   within the category of algorithms spanning more than one segment, and
   hence elevated requirements would apply to them.  The same is true
   for LDP [RFC3036] and RSVP-TE [RFC3209].  On the other hand,
   protocols like VRRP [RFC3768] or FORCES [I-D.ietf-forces-framework]
   run on a single segment or even inside the node, and hence would not
   fall into this category.

3.1.  Note on protocol extensions

   As stated above, the procedures described in this document are
   equally applicable to both base protocol specifications and
   extensions to them.  However, as explained in Section 5, the
   documentation required for protocol extensions is generally lighter
   than for the base protocol specifications.

   Note that even if a specification developed within the Routing area
   is an extensions to a protocol initially developed elsewhere (other
   IETF area or outside the IETF), principles laid out in this document
   still apply.  For example, RSVP-TE [RFC3209], [RFC1195].

   Also note, that all extensions to protocols that fall within the
   elevated requirements category are automatically subject to at least
   the same level of requirements as the base protocol, regardless of



Fenner & Zinin           Expires April 26, 2006                 [Page 5]

Internet-Draft         Routing Standards Criteria           October 2005


   the envisioned application or where in the IETF the extension has
   been developed.

3.2.  Variance procedure

   In consultation with the community, the IESG MAY decide to waive some
   or all of the requirements specified in this document.  A situation
   where this might be needed is when factors not envisioned in this
   document arise and applying elevated requirements does more harm than
   good.

   If the IESG decides to waive some or all of the requirements, the
   IETF Last Call message SHALL include the explanation of reasoning for
   the variance.  This will allow IETF participants to challenge the
   IESG decision.

3.3.  Appeal processes

   All procedures described in this document are subject to the appeal
   process described in [RFC2026], including the variance procedure in
   that document's section 9.


4.  Requirements

4.1.  Requirements for Proposed Standard

   1.  Documents specifying the Protocol and its Usage.  The
       specification for the routing protocol must be well written such
       that independent, interoperable implementations can be developed
       solely based on the specification.  For example, it should be
       possible to develop an interoperable implementation without
       consulting the original developers of the routing protocol.

   2.  A Management Information Base (MIB) must be written for the
       protocol.  The MIB does not need to submitted for Proposed
       Standard at the same time as the routing protocol, but must be at
       least an Internet Draft.

   3.  The security architecture of the protocol must be set forth
       explicitly.  The security architecture must include mechanisms
       for authenticating protocol messages and may include other forms
       of protection.

   4.  Two or more independent interoperable implementations must exist.

   5.  There must be evidence that the major features of the protocol
       have been tested.



Fenner & Zinin           Expires April 26, 2006                 [Page 6]

Internet-Draft         Routing Standards Criteria           October 2005


   6.  No operational experience is required for the routing protocol at
       this stage in the standardization process.

   See Section 5.1 for submission guidelines for the required reports.

4.2.  Requirements for Draft Standard

   1.  Revisions to the Protocol and Usage documents showing changes and
       clarifications made based on experience gained in the time
       between when the protocol was made a Proposed Standard and it
       being submitted for Draft Standard.  The revised documents should
       include a section summarizing the changes made.

   2.  The Management Information Base (MIB) must be at the Proposed
       Standard level of standardization.

   3.  The security architecture of the protocol must be set forth
       explicitly.  The security architecture must include mechanisms
       for authenticating protocol messages and may include other forms
       of protection.

   4.  Two or more interoperable implementations must exist.  At least
       two must be written independently.

   5.  There must be evidence that all features of the protocol have
       been tested, running between at least two implementations.  This
       must include that all of the security features have been
       demonstrated to operate, and that the mechanisms defined in the
       protocol actually provide the intended protection.

   6.  There must be significant operational experience.  This must
       include running in a moderate number routers configured in a
       moderately complex topology, and must be part of the operational
       Internet.  All significant features of the protocol must be
       exercised.  In the case of an Interior Gateway Protocol (IGP),
       both interior and exterior routes must be carried (unless another
       mechanism is provided for the exterior routes).  In the case of a
       Exterior Gateway Protocol (EGP), it must carry the full
       complement of exterior routes.

   See Section 5.2 for submission guidelines for the required reports.

4.3.  Requirements for Standard

   1.  Revisions to the Protocol and Usage documents showing changes and
       clarifications made based on experience gained in the time
       between when the protocol was made a Draft Standard and it being
       submitted for Standard.  The changes should be to clarify the



Fenner & Zinin           Expires April 26, 2006                 [Page 7]

Internet-Draft         Routing Standards Criteria           October 2005


       protocol or provide guidance in its implementation.  No
       significant changes can be made to the protocol at this stage.
       The revised documents should include a section summarizing the
       changes made.

   2.  The Management Information Base (MIB) must be submitted for
       Standard at the same time as the routing protocol.

   3.  The security architecture of the protocol must be set forth
       explicitly.  The security architecture must include mechanisms
       for authenticating protocol messages and may include other forms
       of protection.

   4.  Three or more interoperable implementations must exist.  At least
       two must be written independently.

   5.  There must be evidence that all features of the protocol have
       been tested, running between at least two independently written
       implementations.  This must include that all of the security
       features have been demonstrated to operate, and that the
       mechanisms defined in the protocol actually provide the intended
       protection.

   6.  There must be significant operational experience.  This must
       include running in a large number routers configured in a complex
       topology, and must be part of the operational Internet.  The
       operational experience must include multi-vendor operation.  All
       significant features of the protocol must be exercised.  In the
       case of an Interior Gateway Protocol (IGP), both interior and
       exterior routes must be carried (unless another mechanism is
       provided for the exterior routes).  In the case of a Exterior
       Gateway Protocol (EGP), it must carry the full complement of
       exterior routes.

   See Section 5.2 for submission guidelines for the required reports.

4.4.  Optional Protocol Analysis

   When a protocol introduces previously unknown algorithms or
   techniques, the Area Directors may require that the working group
   produce a Protocol Analysis.  This protocol analysis will be a
   separately-chartered working group work item, and may be a
   prerequisite for publication at Draft Standard or Standard.

   The Protocol Analysis must summarize the key features of the protocol
   and analyze how the protocol will perform and scale in the Internet.
   The intent of this requirement is to understand the boundary
   conditions of the routing protocol.  The new routing protocol must be



Fenner & Zinin           Expires April 26, 2006                 [Page 8]

Internet-Draft         Routing Standards Criteria           October 2005


   compared with the existing routing protocols (e.g., OSPF, BGP, etc.)
   as appropriate.  The report should answer several questions:

   o  What are the key features and algorithms of the protocol?

   o  How much link bandwidth, router memory and router CPU cycles does
      the protocol consume under normal conditions?

   o  For these metrics, how does the usage scale as the routing
      environment grows?  This should include topologies at least an
      order of magnitude larger than the current environment.

   o  What are the limits of the protocol for these metrics?  (I.e.,
      when will the routing protocol break?)

   o  For what environments is the protocol well suited, and for what is
      it not suitable?

   When submitting for Standard, this report should simply be a revision
   of the report that was submitted for Draft Standard; it must describe
   the additional knowledge and understanding gained in the time between
   when the protocol was made a Draft standard and when it was submitted
   for Standard.


5.  Submitting

   Before submitting a Technical Specification for publication, the WG
   chairs must ensure that the following steps have been completed:

   1.  The documents have undergone a Last Call in the Working Group,
       major technical issues have been resolved, and there's a clear
       support for publication.

   2.  The documents being submitted have been reviewed by the Routing
       Area Directorate and all identified issues have been discussed
       and, if necessary resolved.  It is recommended that a review
       request to the Directorate is initiated during the Working Group
       Last Call.

   3.  The implementation and interoperability report has been submitted
       to the IETF secretariat, and is publicly available at the IETF
       web site.  This report should include:

       *  Implementation experience.

       *  List of implementations including origin of code.




Fenner & Zinin           Expires April 26, 2006                 [Page 9]

Internet-Draft         Routing Standards Criteria           October 2005


       *  Interoperability report.

       *  Test scenarios and test results showing that the major
          features of the protocols have been tested.

5.1.  Submitting for Proposed Standard

   When submitting a specification or a bundle of documents to the ADs
   for publication as Proposed Standard, the WG chairs (or the document
   authors in case of an individual submission) send an E-mail message
   to the Routing ADs, with a copy (in the "Cc:" field) to the IETF
   secretariat (iesg-secretary@ietf.org) with the following information:

   1.  The name of the Internet-Draft(s) that contain the Technical
       Specification(s) being submitted, as well as the desired
       publication level (Proposed Standard in this case).  Note that if
       more than one document is submitted, each document may have a
       different target status.  These documents will be grouped in a
       bundle, and will be processed for the IETF Last Call and IESG
       review as a group.

   2.  If an Applicability Statement is included in the submission, the
       name of the I-D containing the AS, as well as the target
       publication status for it.  Note that per [2026] the publication
       level of the AS cannot be higher than the publication level of
       the Technical Specification (item 1 above).

   3.  A brief description (technical summary) of the protocol.  This
       information will be used during the IETF Last Call and the IESG
       review processes.  The summary should include information such
       as:

       *  What are the key features and algorithms of the protocol?

       *  For what environments is the protocol well suited, and for
          what is it not suitable?

   4.  A pointer (e.g.  URL) to the implementation and interoperability
       report previously submitted to the IETF secretariat.

   5.  A pointer to the corresponding MIB document with an explanation
       of how the MIB maturity requirement has been satisfied, or an
       explanation of why no MIB modifications are required to support
       functionality described in the Technical Specification.

   6.  Summary of the Routing Directorate review results, major issues
       that were identified, whether they were discussed and resolved.




Fenner & Zinin           Expires April 26, 2006                [Page 10]

Internet-Draft         Routing Standards Criteria           October 2005


   7.  Any other reports or pointers to the documents otherwise required
       by the IETF process, such as the PROTO writeup described at
       <http://rtg.ietf.org/area/procedures/proto_wgchair_writeup>.

5.2.  Submitting for Draft Standard or Standard

   In addition to the requirements listed in Section 5.1, when
   submitting for Draft Standard or Standard, the submission must
   include an additional report:

      Description of operational experience.  This must include
      topology, environment, time and duration, implementations
      involved, and overall results and conclusions gained from the
      operational experience.

   For a protocol, this report must be a separate document; for an
   extension to an existing protocol, it may be sent as part of the
   submission email.


6.  Changes from RFC 1264

   o  Update to require two interoperable implementations for Proposed
      Standard.

   o  Add explicit descriptions of what does and doesn't need to be
      treated under the extended rules.

   o  Require an implementation for any standards-track document.

   o  Add an escape mechanism (IETF Last Call) so that the community can
      comment on the decision of whether or not to apply these rules.

   o  Clarify protocol submission guidelines.

   o  Clarify how the process applies to protocol extensions.

   o  Remove security description from reports; it's required in the
      specification already.


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.




Fenner & Zinin           Expires April 26, 2006                [Page 11]

Internet-Draft         Routing Standards Criteria           October 2005


8.  Security Considerations


9.  Acknowledgments

   Bob Hinden wrote the original version of this document (RFC 1264
   [RFC1264]) when he was Routing Area Director and the IETF was a very
   different place.  Most of the original document remains.


10.  References

10.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

10.2.  Informative References

   [I-D.ietf-forces-framework]
              Yang, L., "Forwarding and Control Element Separation
              (ForCES) Framework", draft-ietf-forces-framework-13 (work
              in progress), January 2004.

   [I-D.ietf-idr-bgp4]
              Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)",
              draft-ietf-idr-bgp4-26 (work in progress), October 2004.

   [I-D.ietf-pim-sm-v2-new]
              Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode PIM-SM):
              Protocol Specification  (Revised)",
              draft-ietf-pim-sm-v2-new-11 (work in progress),
              October 2004.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC1264]  Hinden, R., "Internet Engineering Task Force Internet
              Routing Protocol Standardization Criteria", RFC 1264,
              October 1991.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,



Fenner & Zinin           Expires April 26, 2006                [Page 12]

Internet-Draft         Routing Standards Criteria           October 2005


              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3768]  Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
              RFC 3768, April 2004.

URIs

   [1]  <http://www.ietf.org/html.charters/newtrk.html>


Appendix A.  Change Log

A.1.  Changes since -00

   o  Changed "SHALL NOT" to "SHOULD NOT" in the requirement of one
      implementation for all standards-track Routing Area Documents.

   o  Added that the two implementations for PS must be independent

   o  Moved the Protocol Analysis out of the required set of documents
      to Section 4.4.





























Fenner & Zinin           Expires April 26, 2006                [Page 13]

Internet-Draft         Routing Standards Criteria           October 2005


Authors' Addresses

   Bill Fenner
   AT&T Labs - Research
   75 Willow Rd
   Menlo Park, CA  94025
   USA

   Phone: +1 650 330-7893
   Email: fenner@research.att.com


   Alex Zinin
   Alcatel
   701 E Middlefield Rd
   Mountain View, California  94043

   Email: zinin@psg.com

































Fenner & Zinin           Expires April 26, 2006                [Page 14]

Internet-Draft         Routing Standards Criteria           October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Fenner & Zinin           Expires April 26, 2006                [Page 15]