summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4148.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4148.txt')
-rw-r--r--doc/rfc/rfc4148.txt787
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]
+