doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc4148.txt b/doc/rfc/rfc4148.txt
new file mode 100644
index 0000000..854ff6d
--- /dev/null
+++ b/doc/rfc/rfc4148.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         E. Stephan
+Request for Comments: 4148                            France Telecom R&D
+BCP: 108                                                     August 2005
+Category: Best Current Practice
+
+
+             IP Performance Metrics (IPPM) Metrics Registry
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This memo defines a registry for IP Performance Metrics (IPPM).  It
+   assigns and registers an initial set of OBJECT IDENTITIES to
+   currently defined metrics in the IETF.
+
+   This memo also defines the rules for adding IP Performance Metrics
+   that are defined in the future and for encouraging all IP performance
+   metrics to be registered here.
+
+   IANA has been assigned to administer this new registry.
+
+Table of Contents
+
+   1. The Internet-Standard Management Framework ......................2
+   2. Overview ........................................................2
+   3. IP Performance Metrics Registry Framework .......................2
+   4. Initial IPPM Metrics Registry Creation ..........................3
+   5. IANA Considerations .............................................4
+      5.1. Management Rules ...........................................4
+      5.2. Registration Template ......................................4
+   6. Initial IPPM Registry Definition ................................4
+   7. Security Considerations ........................................11
+   8. References .....................................................12
+      8.1. Normative References ......................................12
+      8.2. Informative References ....................................12
+
+
+
+
+
+
+
+Stephan                  Best Current Practice                  [Page 1]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+1.  The Internet-Standard Management Framework
+
+   For a detailed overview of the documents that describe the current
+   Internet-Standard Management Framework, please refer to section 7 of
+   RFC 3410 [RFC3410].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  MIB objects are generally
+   accessed through the Simple Network Management Protocol (SNMP).
+   Objects in the MIB are defined using the mechanisms defined in the
+   Structure of Management Information (SMI).  This memo specifies a MIB
+   module that is compliant to the SMIv2, which is described in STD 58,
+   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+   [RFC2580].
+
+2.  Overview
+
+   This memo defines a registry of the current metrics and a framework
+   for the integration of future metrics for the following reasons:
+
+   o  to permit metrics to be clearly referenced by MIB modules or other
+      data models;
+
+   o  to provide metrics identifiers for measurement interoperability;
+
+   o  to take special care with the integration of future standardized
+      metrics because it is a continuous process;
+
+   o  to provide room where other standards bodies can register their
+      metrics in order to encourage IP performance metrics to have
+      OBJECT IDENTITIES rooted at a common point because the intent of
+      the IPPM WG is to cooperate with other appropriate standards
+      bodies (or fora) to promote consistent metrics;
+
+   o  and, similarly, to provide room for enterprises to register
+      metrics.
+
+3.  IP Performance Metrics Registry Framework
+
+   MIB modules need to be able to reference IPPM Metrics precisely.  The
+   registry associates an OBJECT-IDENTITY with each metric.  For
+   example, Type-P-One-way-Delay and Type-P-One-way-Delay-Poisson-Stream
+   have different OBJECT IDENTITIES.
+
+   The registry has one branch.  Metrics are identified in the
+   'ianaIppmMetrics' subtree.
+
+
+
+
+
+Stephan                  Best Current Practice                  [Page 2]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+   This document defines an initial registry of the existing metrics
+   defined in the IPPM WG and the rules to manage the registry.
+
+   Documents defining metrics in the future will include in the IANA
+   section the registration information to identify these metrics
+   unambiguously.
+
+4.  Initial IPPM Metrics Registry Creation
+
+   The initial registry identifies the metrics currently defined in the
+   RFCs produced in the IPPM WG.  To date, the IPPM WG defined 33
+   metrics related to the following 7 topics:
+
+   1.  IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]
+
+   2.  One-way Delay Metrics, RFC 2679 [RFC2679]
+
+   3.  One-way Packet Loss Metrics, RFC 2680 [RFC2680]
+
+   4.  Round-trip Delay Metrics, RFC 2681 [RFC2681]
+
+   5.  One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]
+
+   6.  IP Packet Delay Variation Metric, RFC 3393 [RFC3393]
+
+   7.  IPPM Metrics for periodic streams, RFC 3432 [RFC3432]
+
+   These are sequentially registered in the node ianaIppmMetrics.
+
+   The naming conventions used for the existing metrics, and encouraged
+   for new IPPM metrics, are:
+
+   o  Metrics names conform SMIv2 rules for descriptors defined in
+      section 3.1 of [RFC2578];
+
+   o  The name starts with the prefix 'ietf';
+
+   o  'Type-P' prefix is removed;
+
+   o  '-' are removed;
+
+   o  The letter following a '-' is changed to uppercase.
+
+
+
+
+
+
+
+
+
+Stephan                  Best Current Practice                  [Page 3]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+5.  IANA Considerations
+
+   This section describes the rules for the management of the registry
+   by IANA.
+
+5.1.  Management Rules
+
+   Registrations are done sequentially by IANA in the ianaIppmMetrics
+   subtree on the basis of 'Specification Required', as defined in
+   [RFC2434].
+
+   The reference of the specification must point to a stable document
+   including a title, a revision, and a date.
+
+   The name always starts with the name of the organization and must
+   respect the SMIv2 rules for descriptors defined in section 3.1 of
+   [RFC2578].
+
+   A document that creates new metrics would have an "IANA
+   Considerations" section in which it would describe new metrics to be
+   registered.
+
+   An OBJECT IDENTITY assigned to a metric is definitive and cannot be
+   reused.  If a new version of a metric is produced, then it is
+   assigned with a new name and a new identifier.
+
+5.2.  Registration Template
+
+   The following is a proposed template to insert in the IANA
+   considerations section.  For each metric, that section would
+   instantiate the following statement:
+
+      IANA has registed the following metric in the IANA-IPPM-METRICS-
+      REGISTRY-MIB:
+
+       aNewMetricName OBJECT-IDENTITY
+       STATUS       current
+       DESCRIPTION
+          "The identifier for a new metric."
+       REFERENCE
+          "Reference R, section n."
+          ::= { ianaIppmMetrics nn }     -- IANA assigns nn
+
+6.  Initial IPPM Registry Definition
+
+   IANA-IPPM-METRICS-REGISTRY-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+
+
+
+Stephan                  Best Current Practice                  [Page 4]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+       OBJECT-IDENTITY, MODULE-IDENTITY, mib-2
+           FROM SNMPv2-SMI;
+
+   ianaIppmMetricsRegistry MODULE-IDENTITY
+   LAST-UPDATED "200507280000Z"    -- July 28, 2005
+   ORGANIZATION "IANA"
+   CONTACT-INFO "Internet Assigned Numbers Authority
+
+            Postal: ICANN
+                4676 Admiralty Way, Suite 330
+                Marina del Rey, CA 90292
+
+            Tel:    +1 310 823 9358
+            E-Mail: iana@iana.org"
+
+   DESCRIPTION
+      "This module defines a registry for IP Performance Metrics.
+
+      Registrations are done sequentially by IANA in the ianaIppmMetrics
+      subtree on the basis of 'Specification Required', as defined in
+      [RFC2434].
+
+      The reference of the specification must point to a stable document
+      including a title, a revision, and a date.
+
+      The name always starts with the name of the organization and must
+      respect the SMIv2 rules for descriptors defined in section 3.1 of
+      [RFC2578].
+
+      A document that creates new metrics would have an IANA
+      considerations section in which it would describe new metrics to
+      be registered.
+
+      An OBJECT IDENTITY assigned to a metric is definitive and cannot
+      be reused.  If a new version of a metric is produced, then it is
+      assigned with a new name and a new identifier.
+
+      Copyright (C) The Internet Society (2005).  The initial version of
+      this MIB module was published in RFC 4148; for full legal notices
+      see the RFC itself or
+      http://www.ietf.org/copyrights/ianamib.html."
+
+   REVISION      "200507280000Z"    -- July 28, 2005
+   DESCRIPTION
+       "Initial version of the IPPM metrics registry module.
+        This version published as RFC 4148."
+   ::= { mib-2 128 }
+
+
+
+
+Stephan                  Best Current Practice                  [Page 5]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+   ianaIppmMetrics OBJECT-IDENTITY
+       STATUS       current
+       DESCRIPTION
+           "Registration point for IP Performance Metrics."
+       ::= { ianaIppmMetricsRegistry 1 }
+
+   --
+   -- Registry of the metrics of the IPPM WG RFCs
+   --
+
+   --
+   -- RFC 2678 "IPPM Metrics for Measuring Connectivity"
+   --
+
+   ietfInstantUnidirConnectivity OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Instantaneous-Unidirectional-Connectivity"
+       REFERENCE "RFC2678, section 2."
+       ::= { ianaIppmMetrics 1}
+
+   ietfInstantBidirConnectivity OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Instantaneous-Bidirectional-Connectivity"
+       REFERENCE "RFC2678, section 3."
+       ::= { ianaIppmMetrics 2}
+
+   ietfIntervalUnidirConnectivity OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Interval-Unidirectional-Connectivity"
+       REFERENCE "RFC2678, section 4."
+       ::= { ianaIppmMetrics 3 }
+
+   ietfIntervalBidirConnectivity OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "Type-P-Interval-Bidirectional-Connectivity"
+       REFERENCE "RFC2678, section 5."
+       ::= { ianaIppmMetrics 4 }
+
+   ietfIntervalTemporalConnectivity OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P1-P2-Interval-Temporal-Connectivity"
+       REFERENCE "RFC2678, section 6."
+       ::= { ianaIppmMetrics 5 }
+
+
+
+Stephan                  Best Current Practice                  [Page 6]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+   --
+   -- RFC 2679 "A One-way Delay Metric for IPPM"
+   --
+
+   ietfOneWayDelay OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Delay"
+       REFERENCE "RFC2679, section 3."
+       ::= { ianaIppmMetrics 6 }
+
+   ietfOneWayDelayPoissonStream OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Delay-Poisson-Stream"
+       REFERENCE "RFC2679, section 4."
+       ::= { ianaIppmMetrics 7 }
+
+   ietfOneWayDelayPercentile OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Delay-Percentile"
+       REFERENCE "RFC2679, section 5.1."
+       ::= { ianaIppmMetrics 8 }
+
+   ietfOneWayDelayMedian OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Delay-Median"
+       REFERENCE "RFC2679, section 5.2."
+       ::= { ianaIppmMetrics 9 }
+
+   ietfOneWayDelayMinimum OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Delay-Minimum"
+       REFERENCE "RFC2679, section 5.3."
+       ::= { ianaIppmMetrics 10 }
+
+   ietfOneWayDelayInversePercentile OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Delay-Inverse-Percentile"
+       REFERENCE "RFC2679, section 5.4."
+       ::= { ianaIppmMetrics 11 }
+
+
+
+
+
+
+Stephan                  Best Current Practice                  [Page 7]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+   --
+   -- RFC 2680 "One-way Packet Loss Metric for IPPM"
+   --
+
+   ietfOneWayPktLoss OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Packet-Loss"
+       REFERENCE "RFC2680, section 2."
+       ::= { ianaIppmMetrics 12 }
+
+   ietfOneWayPktLossPoissonStream OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Packet-Loss-Poisson-Stream"
+       REFERENCE "RFC2680, section 3."
+       ::= { ianaIppmMetrics 13 }
+
+   ietfOneWayPktLossAverage OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Packet-Loss-Average"
+       REFERENCE "RFC2680, section 4."
+       ::= { ianaIppmMetrics 14 }
+
+   --
+   -- RFC 2681 "A Round-trip Delay Metric for IPPM"
+   --
+
+   ietfRoundTripDelay OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Round-trip-Delay"
+       REFERENCE " section 2 of the rfc2681."
+       ::= { ianaIppmMetrics 15 }
+
+   ietfRoundTripDelayPoissonStream OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Round-trip-Delay-Poisson-Stream"
+       REFERENCE "RFC2681, section 4."
+       ::= { ianaIppmMetrics 16 }
+
+   ietfRoundTripDelayPercentile OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Round-trip-Delay-Percentile"
+       REFERENCE "RFC2681, section 4.1."
+
+
+
+Stephan                  Best Current Practice                  [Page 8]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+       ::= { ianaIppmMetrics 17 }
+
+   ietfRoundTripDelayMedian OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Round-trip-Delay-Median"
+       REFERENCE "RFC2681, section 4.2."
+       ::= { ianaIppmMetrics 18 }
+
+   ietfRoundTripDelayMinimum OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Round-trip-Delay-Minimum"
+       REFERENCE "RFC2681, section 4.3."
+       ::= { ianaIppmMetrics 19 }
+
+   ietfRoundTripDelayInvPercentile OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-Round-trip-Inverse-Percentile"
+       REFERENCE "RFC2681, section 4.4."
+       ::= { ianaIppmMetrics 20 }
+
+   --
+   -- RFC 3357: "One-way Loss Pattern Sample Metrics"
+   --
+
+   ietfOneWayLossDistanceStream OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-Way-Loss-Distance-Stream"
+       REFERENCE " RFC3357, section 5.4.1."
+       ::={ ianaIppmMetrics 21}
+
+   ietfOneWayLossPeriodStream OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-Way-Loss-Period-Stream"
+       REFERENCE " RFC3357, section 5.4.2."
+       ::={ ianaIppmMetrics 22}
+
+   ietfOneWayLossNoticeableRate OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-Way-Loss-Noticeable-Rate"
+       REFERENCE " RFC3357, section 6.1."
+       ::= { ianaIppmMetrics 23 }
+
+
+
+
+Stephan                  Best Current Practice                  [Page 9]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+   ietfOneWayLossPeriodTotal OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-Way-Loss-Period-Total"
+       REFERENCE " RFC3357, section 6.2."
+       ::= { ianaIppmMetrics 24 }
+
+   ietfOneWayLossPeriodLengths OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-Way-Loss-Period-Lengths"
+       REFERENCE " RFC3357, section 6.3."
+       ::= { ianaIppmMetrics 25 }
+
+   ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-Way-Inter-Loss-Period-Lengths"
+       REFERENCE " RFC3357, section 6.4."
+       ::= { ianaIppmMetrics 26 }
+
+   --
+   -- RFC 3393: "IP Packet Delay Variation Metric
+   --           for IP Performance Metrics (IPPM)"
+
+   ietfOneWayIpdv OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-ipdv"
+       REFERENCE " RFC3393, section 2."
+       ::= { ianaIppmMetrics 27 }
+
+   ietfOneWayIpdvPoissonStream OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-ipdv-Poisson-stream"
+       REFERENCE " RFC3393, section 3."
+       ::= { ianaIppmMetrics 28 }
+
+   ietfOneWayIpdvPercentile OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+         "Type-P-One-way-ipdv-percentile"
+       REFERENCE " RFC3393, section 4.3."
+       ::= { ianaIppmMetrics 29 }
+
+   ietfOneWayIpdvInversePercentile OBJECT-IDENTITY
+       STATUS     current
+
+
+
+Stephan                  Best Current Practice                 [Page 10]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+       DESCRIPTION
+           "Type-P-One-way-ipdv-inverse-percentile"
+       REFERENCE " RFC3393, section 4.4."
+       ::= { ianaIppmMetrics 30 }
+
+   ietfOneWayIpdvJitter OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-ipdv-jitter"
+       REFERENCE " RFC3393, section 4.5."
+       ::= { ianaIppmMetrics 31 }
+
+   ietfOneWayPeakToPeakIpdv OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-peak-to-peak-ipdv"
+       REFERENCE " RFC3393, section 4.6."
+       ::= { ianaIppmMetrics 32 }
+
+   --
+   -- RFC 3432: "Network performance measurement with periodic streams"
+   --
+
+   ietfOneWayDelayPeriodicStream OBJECT-IDENTITY
+       STATUS     current
+       DESCRIPTION
+           "Type-P-One-way-Delay-Periodic-Stream"
+       REFERENCE " RFC3432, section 4."
+       ::= { ianaIppmMetrics 33 }
+
+   END
+
+7.  Security Considerations
+
+   This module does not define any management objects.  Instead, it
+   assigns a set of OBJECT-IDENTITIES which may be used by other MIB
+   modules to identify specific IP Performance Metrics.
+
+   Meaningful security considerations can only be written in the MIB
+   modules that define management objects.  This document has therefore
+   no impact on the security of the Internet.
+
+
+
+
+
+
+
+
+
+
+Stephan                  Best Current Practice                 [Page 11]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2578]  McCloghrie, K., Perkins, D., and J.  Schoenwaelder,
+              "Structure of Management Information Version 2 (SMIv2)",
+              STD 58, RFC 2578, April 1999.
+
+   [RFC2678]  Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
+              Connectivity", RFC 2678, September 1999.
+
+   [RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+              Delay Metric for IPPM", RFC 2679, September 1999.
+
+   [RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+              Packet Loss Metric for IPPM", RFC 2680, September 1999.
+
+   [RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
+              Delay Metric for IPPM", RFC 2681, September 1999.
+
+   [RFC3357]  Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
+              Metrics", RFC 3357, August 2002.
+
+   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
+              Metric for IP Performance Metrics (IPPM)", RFC 3393,
+              November 2002.
+
+   [RFC3432]  Raisanen, V., Grotefeld, G., and A. Morton, "Network
+              performance measurement with periodic streams", RFC 3432,
+              November 2002.
+
+8.2.  Informative References
+
+   [RFC2579]  McCloghrie, K., Perkins, D., and J.  Schoenwaelder,
+              "Textual Conventions for SMIv2", STD 58, RFC 2579,
+              April 1999.
+
+   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+              "Conformance Statements for SMIv2", STD 58, RFC 2580,
+              April 1999.
+
+   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
+              "Introduction and Applicability Statements for Internet-
+              Standard Management Framework", RFC 3410, December 2002.
+
+
+
+Stephan                  Best Current Practice                 [Page 12]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+Author's Address
+
+   Stephan Emile
+   France Telecom R & D
+   2 avenue Pierre Marzin
+   Lannion  F-22307
+   France
+
+   Fax:   +33 2 96 05 18 52
+   EMail: emile.stephan@francetelecom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stephan                  Best Current Practice                 [Page 13]
+
+RFC 4148            IP Performance Metrics Registry          August 2005
+
+
+Full 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.
+
+   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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Stephan                  Best Current Practice                 [Page 14]
+