doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc2436.txt b/doc/rfc/rfc2436.txt
new file mode 100644
index 0000000..b7b2077
--- /dev/null
+++ b/doc/rfc/rfc2436.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          R. Brett
+Request for Comments: 2436                              Nortel Networks
+Category: Informational                                      S. Bradner
+                                                     Harvard University
+                                                             G. Parsons
+                                                        Nortel Networks
+                                                           October 1998
+
+
+               Collaboration between ISOC/IETF and ITU-T
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Overview
+
+   This document describes the collaboration process between the ITU-T
+   and ISOC/IETF. The process was documented by ITU-T at its TSAG
+   (Telecommunication Standardization Advisory Group) meeting in
+   September 1998.  All participants of this meeting (including Study
+   Group chairmen and the ISOC Vice President for Standards) assisted in
+   the creation of this document.  Subsequently, it was sent to all
+   ITU-T Study Groups and ISOC/IETF to ensure that everyone was aware of
+   the process. Feedback is requested by the next meeting of TSAG in
+   April 1999.  This document is identical to the document produced by
+   TSAG.
+
+   Please send any comments on this document to ISOC at poised@tis.com
+   and for information to the ITU-T TSAG group at tsagco-op@itu.int
+
+ISOC/IETF and ITU-T Collaboration
+
+1 Scope
+
+   This Liaison is sent to all ITU-T Study Groups to encourage and aid
+   in the understanding of collaboration on standards development
+   between the ITU-T and the Internet Society (ISOC) / Internet
+   Engineering Task Force (IETF).  Feedback to TSAG is encouraged before
+   its next meeting in April 1999.
+
+
+
+
+
+Brett, et. al.               Informational                      [Page 1]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+2 Introduction
+
+   The telecommunication industry is faced with an explosion in growth
+   of the Internet and other IP (Internet Protocol) based networks.
+   Operators, manufacturers and software/application providers alike are
+   reconsidering their business directions and Standards Development
+   Organizations and Forums and Consortia are facing an immense
+   challenge to address this situation.  These challenges were
+   considered by TSAG at its meeting in Geneva, 7-11 September 1998,
+   where it recognized that although the ITU-T and ISOC/IETF are already
+   collaborating in a number of areas, this collaboration must be
+   strengthened within the context of changes in work emphasis and
+   direction within the ITU-T on studies related to IP based networks.
+
+   For example, many Study Groups (e.g., 7, 8 & 16) already address
+   several the aspects of IP based networks.  Further, new IP related
+   work activities are starting in other Study Groups (e.g., 4, 11 &
+   13).  There are many potential areas of interest to ITU-T Study
+   Groups in the IP area that should be investigated (e.g., signaling,
+   routing, security, numbering & addressing, integrated management,
+   performance, IP - telecom interworking, access).  Since many of these
+   areas are also being investigated by the IETF, there is a requirement
+   for close collaboration.
+
+   Recommendations A.4, A.5 and A.6 already document the process for
+   working with other organizations and their documents.  Since there
+   are no specific guidelines on the process of collaboration with the
+   IETF, this liaison is meant to provide that information.  The current
+   level of cooperation between the ITU-T and the IETF should be built
+   upon to ensure that the competence and experience of each
+   organization is brought to bear in the most effective manner and in
+   collaboration with the other.
+
+3 Guidance on Collaboration
+
+   TSAG has been made aware of several instances of existing successful
+   collaboration between the ITU-T and ISOC/IETF.  This section builds
+   on this existing process and details some of the more important
+   guidance points that Study Groups should be aware of in their
+   collaboration with ISOC/IETF.
+
+3.1  How to interact on ITU-T or IETF work items.
+
+   Study Groups that have identified work topics that are Internet
+   related should evaluate the relationship with topics defined in the
+   IETF.  Current IETF Working Groups and their charters (IETF
+   definition of the scope of work) are listed in the IETF archives (see
+
+
+
+
+Brett, et. al.               Informational                      [Page 2]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   section 3.5).  A Study Group may decide that development of a
+   Recommendation on a particular topic may benefit from collaboration
+   with the IETF.
+
+   The Study Group should identify this collaboration in its work plan
+   (specifically in that of each Question involved), describing the goal
+   of the collaboration and its expected outcome.  It is anticipated
+   that an IETF Working Group would also evaluate and identify areas of
+   relationship with the ITU-T and document the collaboration with the
+   ITU-T Study Group in its charter.
+
+   The following sections outline a process that can be used to enable
+   each group to learn about the others new work items.
+
+3.1.1  How the ITU-T learns about existing IETF work items
+
+   The responsibility is on individual Study Groups to review the
+   current IETF Working Groups to determine if there are any topics of
+   mutual interest.  Should a Study Group believe that there is an
+   opportunity for collaboration on a topic of mutual interest it should
+   contact both the IETF Working Group Chair and the Area Director
+   responsible.
+
+3.1.2  How the ITU-T learns about proposed new IETF work items
+
+   The IETF maintains a mailing list for the distribution and discussion
+   of proposed new Working Group charters amongst the management team.
+   To add or change a subscription to this list, send a message to
+   iesg-secretary@ietf.org indicating who you are and that you would
+   like to subscribe to the New Work mailing list.  Details on the list
+   process will be emailed to each subscriber.
+
+   It is recommended that each Study Group chairman (or a delegate)
+   subscribe to this list and monitor the new work items for possible
+   overlap or interest to their Study Group.  It is expected that this
+   mailing list will see one or two messages per month. Chairmen should
+   identify their comments on these charters by responding to the IESG
+   mailing list at iesg@ietf.org clearly indicating their ITU-T position
+   and the nature of their concern.  It should be noted that the IETF
+   turnaround time for new Working Group charters is one week.  As a
+   result, the mailing list should be consistently monitored.
+
+3.1.3  How the IETF learns about ITU-T work items
+
+   An initial list of Internet related topics in ITU-T Study Groups
+   based on the situation as of 11 September is being provided to the
+   Vice President of Standards for ISOC for distribution to the
+   appropriate IETF interested individuals and will be copied to all
+
+
+
+Brett, et. al.               Informational                      [Page 3]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   ITU-T Study Group Chairmen.  The intention is for Study Groups to
+   forward updates to the Vice President of Standards for ISOC as they
+   occur.
+
+   It is expected that any IETF Working Group interest with the topics
+   being covered by the ITU-T will be forwarded to individual Study
+   Group Chairmen (or the lead Study Group Chairman) by the Vice
+   President of Standards for ISOC.
+
+3.2  Representation
+
+   ISOC, including its standards body IETF, have been admitted by the
+   ITU Council to participate in the work of the ITU-T.   As a result,
+   ISOC delegates are therefore afforded equivalent rights to those of
+   other ITU-T Study Group participants (see 3.2.1).  Conversely, ITU-T
+   delegates may participate in the work of the IETF as individuals or
+   be recognized as ITU-T delegates (see 3.2.2).  To promote
+   collaboration it is useful to facilitate communication between the
+   organizations as further described below.
+
+3.2.1  IETF Recognition at ITU-T
+
+   Participants from the IETF may participate in ITU-T meetings as ISOC
+   delegates if the appropriate IETF Working Group (or area) has
+   approved their attendance.  This approval will be communicated to the
+   TSB in the form of a registration for a particular ITU-T meeting by
+   the Vice President of Standards for ISOC.
+
+3.2.2  ITU-T Recognition at ISOC/IETF
+
+   ITU-T Study Group Chairmen can authorize one or more members to
+   attend an IETF meeting as an official ITU-T delegate speaking on
+   behalf of the Study Group (or a particular Rapporteur Group).  The
+   Study Group Chairman communicates the ITU-T list of delegates by
+   email to the Vice President of Standards for ISOC and also to the
+   Study Group.  The email address of the Vice President of Standards
+   for ISOC is vp-standards@isoc.org.
+
+3.2.3 Communication contacts
+
+   To foster ongoing communication between the ITU-T and ISOC/IETF, it
+   is important to identify and establish contact points within ITU-T
+   Study Groups for specific IETF topics of mutual interest. It is
+   beneficial to identify these contact points early and in some cases
+   the contact point identified by each organization may be the same
+   individual.  It is responsibility of a Study Group to establish the
+   contact points with the IETF and maintain the list on its web page.
+
+
+
+
+Brett, et. al.               Informational                      [Page 4]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   An example of communication contacts that is suggested to Study
+   Groups has both a high level and a working level:
+
+   1. ITU-T Study Group Chairman and IETF Area Director
+
+      An IETF Area Director is the individual responsible for overseeing
+      a major focus of activity with a scope similar to that of an ITU-T
+      Study Group Chairman. These positions are both relatively long-
+      term (of several years) and offer the stability of contact points
+      between the two organizations for a given topic.
+
+   2. ITU-T Rapporteur and IETF Working Group Chair
+
+      An IETF Working Group Chair is an individual who is assigned to
+      lead the work on a specific task within one particular area with a
+      scope similar to that of an ITU-T Rapporteur.  These positions are
+      working positions (of a year or more) that typically end when the
+      work on a specific topic ends.  Collaboration here is very
+      beneficial to ensure the actual work gets done. Note that the
+      current IETF Area Directors and Working Group chairs can be found
+      in the IETF Working Group charters.  The current ITU-T Study Group
+      chairmen and Rapporteurs are listed on the ITU-T web page.
+
+   Both the ITU-T and IETF may assign their contact point function(s) to
+   other individuals than those suggested as it deems appropriate.
+
+3.2.4  Communication
+
+   Informal communication between contact points and experts of both
+   organizations is encouraged.  However, note that formal communication
+   from an ITU-T Study Group, Working Party or Rapporteur to an
+   associated IETF contact point must be explicitly approved and
+   identified as coming from the Study Group, Working Party or
+   Rapporteur Group, respectively.  Conversely, formal communication
+   from an IETF Working Group or Area Director must also be explicitly
+   approved and identified before forwarding to any ITU-T contact.
+   Formal communication is intended to allow the sharing of positions
+   between the IETF and the ITU-T outside of actual documents (as
+   described in 3.3).  This would cover such things as comments on
+   documents and requests for input.  The approved communication is
+   simply emailed from one body contact to another (the appropriate
+   mailing lists, as described in 3.2.5 may be copied).
+
+3.2.5  Mailing Lists
+
+   All IETF Working Groups and all ITU-T Study Group Questions have
+   associated mailing lists.
+
+
+
+
+Brett, et. al.               Informational                      [Page 5]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   In the IETF, the mailing list is the primary vehicle for discussion
+   and decision making.  It is recommended the ITU-T experts interested
+   in particular IETF working group topics subscribe to and participate
+   in these lists. The IETF Working Group mailing list subscription and
+   archive information are noted in each Working Group's charter. In the
+   ITU-T, the TSB has set up formal mailing lists for Questions, Working
+   Parties and other topics within Study Groups (more detail can be
+   found on the ITU website.).  These mailing lists are typically used
+   for discussion of ITU-T contributions.  Note that individual
+   subscribers to this list must be affiliated with an ITU-T member (at
+   this time, there is no blanket inclusion of all IETF participants as
+   members, however, as a member ISOC may designate representatives to
+   subscribe).  Alternatively, ITU-T members operate personal mailing
+   lists on various topics with no restrictions on membership (e.g.,
+   IETF participants are welcome).
+
+3.3     Document Sharing
+
+   During the course of ITU-T and IETF collaboration it is important to
+   share working drafts and documents among the technical working
+   groups.  Initial proposed concepts and specifications typically can
+   be circulated by email (often just repeating the concept and not
+   including the details of the specification) on both the IETF and
+   ITU-T mailing lists.  In addition, working texts (or URLs) of draft
+   Recommendations or RFCs (Internet Drafts) may also be sent between
+   the organizations as described below.
+
+3.3.1  IETF to ITU-T
+
+   IETF documents (e.g., Internet Drafts) can be submitted to a Study
+   Group as a Contribution from ISOC.  In order to ensure that the IETF
+   has properly authorized this,  the IETF Working Group must agree that
+   the specific drafts are of mutual interest and that there is a
+   benefit in forwarding them to the ITU-T for review, comment and
+   potential use.  Once agreed, the Vice President Standards for ISOC
+   would review the Working Group request and give approval.  The
+   contributions would then be forwarded (with the noted approval) to
+   the TSB for circulation as a Study Group Contribution.
+
+3.3.2  ITU-T to IETF
+
+   A Study Group may send texts of draft new Recommendations to the IETF
+   as contributions in the form of Internet Drafts.  Internet Drafts are
+   IETF temporary documents that expire six months after being
+   published.  The Study Group must decide that there is a benefit in
+   forwarding them to the IETF for review, comment and potential use.
+   Terms of reference for Rapporteur Group meetings may authorize
+   Rapporteur Groups to send working documents, in the form of Internet
+
+
+
+Brett, et. al.               Informational                      [Page 6]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   Drafts, to the IETF.  In both cases, the document editor would be
+   instructed to prepare the contribution in Internet Draft format (in
+   ASCII and optionally postscript format as per RFC 2223) and submit it
+   to the Internet Draft editor (email: internet-drafts@ietf.org).
+   Alternatively, the Study Group or Rapporteur Group could agree to
+   post the document on a web site and merely document its existence
+   with a short Internet Draft that contains a summary and the document
+   URL.
+
+   Both the Rapporteur and the Document Editor should be identified as
+   contacts in the contribution.  The contribution must also clearly
+   indicate that the Internet Draft is a working document of a
+   particular ITU-T Study Group.
+
+3.3.3  ITU-T & IETF
+
+   It is envisaged that the processes of 3.3.1 & 3.3.2 will often be
+   used simultaneously by both an IETF Working Group and an ITU-T Study
+   Group to collaborate on a topic of mutual interest.  It is also
+   envisaged that the outcome of the collaboration will be the
+   documentation in full by one body and its referencing by the other
+   (see section 3.4 for details).  That is, common or joint text is
+   discouraged because of the current differences in approval, revision
+   and stability of approved documents for publication by each body.
+
+3.4  Simple cross referencing
+
+   ITU-T Recommendation A.5, specifically its Annex A and the
+   application guidelines attached, describes the process for
+   referencing IETF RFCs in ITU-T Recommendations.  IETF RFC 2026,
+   specifically section 7.1.1, describes the process for referencing
+   other open standards (like ITU-T Recommendations) in IETF RFCs.
+
+3.5  Additional items
+
+   Several URLs to IETF procedures are provided here for information:
+
+   RFC2223  - Instructions to RFC Authors, October 1997
+      ftp://ftp.isi.edu/in-notes/rfc2223.txt
+   RFC2026  - The Internet Standards Process Revision 3, October 1996
+      ftp://ftp.isi.edu/in-notes/rfc2026.txt
+   RFC2418 - IETF Working Group Guidelines and Procedures, September
+      1998 ftp://ftp.isi.edu/in-notes/rfc2418.txt
+   Current list and status of all IETF RFCs ftp://ftp.isi.edu/in-
+      notes/rfc-index.txt
+   Current list and description of all IETF Internet Drafts:
+      ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt
+
+
+
+
+Brett, et. al.               Informational                      [Page 7]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   Current list of IETF Working Groups and their Charters: (includes
+      Area Directors and Chair contacts, Mailing list information, etc.)
+      http://www.ietf.org/html.charters/wg-dir.html
+   Current ITU-T information can be found on the ITU website: (includes
+      contacts, organization, Recommendations for purchase, mailing list
+      info, etc.) http://www.itu.int
+
+4.  Acknowledgments
+
+   The process was documented by ITU-T at its TSAG (Telecommunication
+   Standardization Advisory Group) meeting in September 1998.  All
+   participants of this meeting (including Study Group chairmen and the
+   ISOC Vice President for Standards) assisted in the creation of this
+   document.  Subsequently, it was sent to all ITU-T Study Groups and
+   ISOC/IETF to ensure that everyone was aware of the process. Feedback
+   is requested by the next meeting of TSAG in April 1999.
+
+5. Security Considerations
+
+   This type of non-protocol document does not directly effect the
+   security of the Internet.
+
+6. Authors' Addresses
+
+   ITU-T Contact:
+   R. F. Brett
+   Nortel Networks
+   P.O. Box 3511, Station C
+   Ottawa, ON  K1Y 4H7
+   Canada
+
+   Phone: +1-613-828-0902
+   Fax:   +1-613-828-9408
+   EMail: rfbrett@nortel.ca
+
+
+   ISOC Contact:
+   Scott O. Bradner
+   Harvard University
+   Holyoke Center, Room 876
+   1350 Mass. Ave.
+   Cambridge, MA  02138
+   USA
+
+   Phone: +1 617 495 3864
+   EMail: sob@harvard.edu
+
+
+
+
+
+Brett, et. al.               Informational                      [Page 8]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   Editor:
+   Glenn W. Parsons
+   Nortel Networks
+   P.O. Box 3511, Station C
+   Ottawa, ON  K1Y 4H7
+   Canada
+
+   Phone: +1-613-763-7582
+   Fax:   +1-613-763-4461
+   EMail: Glenn.Parsons@Nortel.ca
+
+7. References
+
+   [A.4]     ITU-T Recommendation A.4 - Communication process between
+             ITU-T and forums and consortia, October 1996.
+
+   [A.5]     ITU-T Recommendation A.5 - Generic procedures for including
+             references to documents to other organizations in ITU-T
+             Recommendations, January 1998.
+
+   [A.6]     ITU-T Recommendation A.6 - Cooperation and exchange of
+             information between ITU-T and national and regional
+             standards development organizations, September 1998.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3",
+             BCP 9, RFC 2026, October 1996.
+
+   [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
+             RFC 2223, October 1997.
+
+   [RFC2418] Bradner, S., "IETF Working Group Guidelines and
+             Procedures", BCP 25, RFC 2418, September 1998.
+
+8.  Full ITU Copyright Statement
+
+   Copyright (C) ITU (1998).  All Rights Reserved.
+
+   No part of this publication may be reproduced or utilized in any form
+   or by any means, electronic or mechanical, including photocopying and
+   microfilm, without permission in writing from the ITU.
+
+
+
+
+
+
+
+
+
+
+
+Brett, et. al.               Informational                      [Page 9]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+9.  Annex A
+
+   APPLICATION GUIDELINES ON REFERENCING DOCUMENTS FROM OTHER
+   ORGANIZATIONS
+
+PART I - Developed by TSAG at its January 1998 Meeting
+
+   The following guidelines should be used in conjunction with the
+   relevant provisions of Recommendations A.3, A.4, A.5 and A.23.
+
+   1. Ownership/Change Control
+      - When considering using material from other organizations it is
+         preferable to only include references to other standards,
+         rather than incorporate text from a standard in the body of a
+         Recommendation. Exceptionally, full text incorporation is
+         necessary rather than a reference where Recommendations having
+         regulatory connotations are concerned.
+
+      - Reference should be made to the particular issue of a standard.
+         In this way the ITU-T is in control of what is actually
+         referenced even if the source organization updates the
+         standard.
+      - References to standards from other organizations should only be
+         made where those organizations continue to provide public
+         access to the version referenced even when updated versions are
+         issued.
+      - When a draft Recommendation is being prepared and the intention
+         is to reference a standard from another organization, that
+         organization should be advised by the TSB of the ITU-T's
+         intention and should be requested to notify the ITU-T of any
+         impending changes to the standard and of any reissues of the
+         standard. (This request may be part of the correspondence
+         described in Recommendation A.5, section 2.4.) It is however
+         the responsibility of the Study Group to regularly review its
+         Recommendations and check if the references are correct and if
+         necessary to reissue the Recommendation with revised references
+         (and where necessary make changes in the body of the
+         Recommendation where the reference is made.).
+      - Should an organization intend to remove completely an earlier
+         version of a standard the ITU-T should be advised so that it
+         can either incorporate the text in the Recommendation or change
+         the reference to a later version.
+
+   2. Access
+      - The objective is to have referenced standards freely available
+         via the Web so that people purchasing a Recommendation may get
+         access to the references.  A warning should be given to
+         purchasers of ITU-T Recommendations that they may have to
+
+
+
+Brett, et. al.               Informational                     [Page 10]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+         additionally purchase the referenced standards. This could be
+         done by including a note to such effect in the introduction to
+         Recommendations where references are included.
+      - When developing a Recommendation where consideration is being
+         given to using references to other standards the Study Group
+         should investigate with the TSB whether the referenced text
+         will be available free of charge or if a payment will be
+         required. This should be taken into account by the Study Group
+         as it may influence the decision to use the reference.
+
+   3. IPR
+      - In principle, if the IPR policy of the organization owning a
+         referenced standard is more stringent than that of the ITU-T
+         then there should not be any IPR problems with including the
+         reference. However, this may not be the case with all
+         organizations. Further guidelines are being prepared by the
+         Director of the TSB.
+
+   4. Approval
+      - The approval procedures in Resolution 1 have to be followed for
+         Recommendations containing references (wholly or in part) to
+         standards from other bodies even in the case where the
+         Recommendation is just a reference to another standard.
+
+PART II - Developed by TSAG at its September 1998 Meeting
+
+   The following guidelines should be used in conjunction with
+   Recommendation A.5.
+
+   1. Nested References
+      Issue: RFCs often contain references to related RFCs and ITU-T
+      Recommendations which, in turn, may contain references to other
+      RFCs and Recommendations. It is unclear how to handle these nested
+      references in the context of A.5.
+
+      Guideline: Each time an RFC is referenced within an ITU-T
+      Recommendation, all references within that RFC should be listed in
+      the report documenting the decision of the Study Group. No further
+      treatment is necessary, although the Study Group may wish to
+      investigate those references further on a case-by-case basis. The
+      same guidelines apply when referencing the documents of other
+      organizations.
+
+   2. Subsequent Referencing of the Same Document
+      Issue: It is possible that the same RFC may be considered for
+      referencing in multiple Recommendations. It is unclear what
+      evaluation is required in subsequent references.
+
+
+
+
+Brett, et. al.               Informational                     [Page 11]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+      Guideline: The justification for referencing the same document in
+      different Recommendations is likely to be different. Consequently,
+      it is important that separate evaluations be made each time the
+      document is referenced.  However, only items 1 - 8 in Appendix I
+      (and Annex A) of Recommendation A.5 need to be completed if the
+      referenced organization has already been qualified per Section 3
+      of A.5. Since items 9 and 10 are dependent on the organization and
+      not on the document, they need to be completed only the first time
+      a document from that organization is being considered for
+      referencing and only if such information has not been documented
+      already.
+
+   3. Availability of Referenced Document
+      Issue: Paragraph 2.2.10 of A.5 requires that the contributing
+      Study Group member provide a full copy of the existing document.
+      It is unclear whether paper copies are mandatory or whether
+      electronic availability, for example, on a Web site, is
+      sufficient.
+
+      Guideline: The objective is to have referenced documents available
+      via the Web at no cost so that the Study Group members may proceed
+      with their evaluation. Accordingly, if a referenced document is
+      available in this manner, it is sufficient for the contributing
+      member to provide its exact location on the Web. On the other
+      hand, if the document is not available in this manner, a full copy
+      must be provided (in electronic format if permissible by the
+      referenced organization, otherwise in paper format).
+
+   4. Referencing of IETF Documents
+      Issue: It is unclear whether or not it is appropriate to reference
+      RFCs that are not on the standards track (the "Informational" and
+      "Experimental" RFCs) or those that are at the first level of
+      standardization (the "Proposed Standard" RFCs).
+
+      Guideline: Some outputs of organizations may not be appropriate
+      for normative referencing, others may not be appropriate for any
+      referencing, normative or informative. In the case of the IETF, it
+      is not appropriate to make any references to "Internet Drafts" or
+      to "Historic" RFCs as noted in A.5. In addition, it is not
+      appropriate to make normative references to RFCs that are
+      considered "Informational" or "Experimental". References to RFCs
+      that have the status of "Proposed Standards" should be made with
+      caution and should be evaluated on a case-by-case basis because
+      such standards are considered immature in the sense that they may
+      change if problems are found in real implementations or if better
+      solutions are identified.
+
+
+
+
+
+Brett, et. al.               Informational                     [Page 12]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+   5. IETF Address Changes
+      The electronic address of the IETF archives has changed.
+      Accordingly the addresses in items 4 and 9.8 of Annex A should be
+      changed, respectively to:
+         http://www.ietf.org/ipr.html - for the IPR archive
+         http://www.rfc-editor.org/rfc.html - for the RFC archive
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brett, et. al.               Informational                     [Page 13]
+
+RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brett, et. al.               Informational                     [Page 14]
+