draft-ietf-ippm-metrics-registry-08.txt   rfc4148.txt 
Network Working Group E. Stephan Network Working Group E. Stephan
Internet-Draft France Telecom R&D Request for Comments: 4148 France Telecom R&D
Expires: May 31, 2005 November 30, 2004 BCP: 108 August 2005
Category: Best Current Practice
IP Performance Metrics (IPPM) metrics registry IP Performance Metrics (IPPM) Metrics Registry
draft-ietf-ippm-metrics-registry-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document specifies an Internet Best Current Practices for the
patent or other IPR claims of which I am aware have been disclosed, Internet Community, and requests discussion and suggestions for
and any of which I become aware will be disclosed, in accordance with improvements. Distribution of this memo is unlimited.
RFC 3668.
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 May 31, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo defines a registry for IP Performance Metrics (IPPM). It This memo defines a registry for IP Performance Metrics (IPPM). It
assigns and registers an initial set of OBJECT IDENTITIES to assigns and registers an initial set of OBJECT IDENTITIES to
currently defined metrics in the IETF. currently defined metrics in the IETF.
This memo also defines the rules for adding new IP Performance This memo also defines the rules for adding IP Performance Metrics
Metrics that are defined in the future and for encouraging all IP that are defined in the future and for encouraging all IP performance
performance metrics to be registered here. metrics to be registered here.
IANA has been assigned to administer this new registry. IANA has been assigned to administer this new registry.
Table of Contents Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . . 3 1. The Internet-Standard Management Framework ......................2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview ........................................................2
3. IP Performance Metrics Registry Framework . . . . . . . . . . 3 3. IP Performance Metrics Registry Framework .......................2
4. Initial IPPM Metrics Registry Creation . . . . . . . . . . . . 4 4. Initial IPPM Metrics Registry Creation ..........................3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations .............................................4
5.1 Management rules . . . . . . . . . . . . . . . . . . . . . 5 5.1. Management Rules ...........................................4
5.2 Registration template . . . . . . . . . . . . . . . . . . 5 5.2. Registration Template ......................................4
6. Initial IPPM registry definition . . . . . . . . . . . . . . . 6 6. Initial IPPM Registry Definition ................................4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations ........................................11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References .....................................................12
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References ......................................12
8.2 Informative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References ....................................12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
1. The Internet-Standard Management Framework 1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]. Managed objects are accessed via a virtual RFC 3410 [RFC3410].
information store, termed the Management Information Base or MIB.
MIB objects are generally accessed through the Simple Network Managed objects are accessed via a virtual information store, termed
Management Protocol (SNMP). Objects in the MIB are defined using the the Management Information Base or MIB. MIB objects are generally
mechanisms defined in the Structure of Management Information (SMI). accessed through the Simple Network Management Protocol (SNMP).
This memo specifies a MIB module that is compliant to the SMIv2, Objects in the MIB are defined using the mechanisms defined in the
which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 Structure of Management Information (SMI). This memo specifies a MIB
[RFC2579] and STD 58, RFC 2580 [RFC2580]. 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 2. Overview
This memo defines a registry of the current metrics and a framework This memo defines a registry of the current metrics and a framework
for the integration of future metrics for the following reasons: for the integration of future metrics for the following reasons:
o to permit metrics to be clearly referenced by MIB modules or other o to permit metrics to be clearly referenced by MIB modules or other
data models; data models;
o Metrics identifiers are needed to allow measurement o to provide metrics identifiers for measurement interoperability;
interoperability;
o As specification of new metrics is a continuous process, special o to take special care with the integration of future standardized
care must be taken for the integration of future standardized metrics because it is a continuous process;
metrics;
o Since the intent of the IPPM WG is to cooperate with other o to provide room where other standards bodies can register their
appropriate standards bodies (or fora) to promote consistent metrics in order to encourage IP performance metrics to have
metrics, room where other standards bodies can register their OBJECT IDENTITIES rooted at a common point because the intent of
metrics is provided to encourage IP performance metrics to have the IPPM WG is to cooperate with other appropriate standards
OBJECT IDENTITIES rooted at a common point; bodies (or fora) to promote consistent metrics;
o Similarly, room is provided for enterprises to register metrics. o and, similarly, to provide room for enterprises to register
metrics.
3. IP Performance Metrics Registry Framework 3. IP Performance Metrics Registry Framework
MIB modules need to be able to precisely reference IPPM Metrics. The MIB modules need to be able to reference IPPM Metrics precisely. The
registry associates an OBJECT-IDENTITY with each metric. As an registry associates an OBJECT-IDENTITY with each metric. For
example Type-P-One-way-Delay and Type-P-One-way-Delay-Poisson-Stream example, Type-P-One-way-Delay and Type-P-One-way-Delay-Poisson-Stream
have different OBJECT IDENTITIES. have different OBJECT IDENTITIES.
The registry has one branch. Metrics are identified in The registry has one branch. Metrics are identified in the
'ianaIppmMetrics' subtree. 'ianaIppmMetrics' subtree.
This document defines an initial registry of the existing metrics This document defines an initial registry of the existing metrics
defined in the IPPM WG and the rules to manage the registry. defined in the IPPM WG and the rules to manage the registry.
Documents defining metrics in the future will include in the IANA Documents defining metrics in the future will include in the IANA
section the registration information to unambiguously identify these section the registration information to identify these metrics
metrics. unambiguously.
4. Initial IPPM Metrics Registry Creation 4. Initial IPPM Metrics Registry Creation
The initial registry identifies the metrics currently defined in the The initial registry identifies the metrics currently defined in the
RFCs produced in the IPPM WG. To date, the IPPM WG defined 33 RFCs produced in the IPPM WG. To date, the IPPM WG defined 33
metrics related to 7 topics: metrics related to the following 7 topics:
o IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 1. IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]
o One-way Delay Metrics, RFC 2679 [RFC2679]; 2. One-way Delay Metrics, RFC 2679 [RFC2679]
o One-way Packet Loss Metrics, RFC 2680 [RFC2680]; 3. One-way Packet Loss Metrics, RFC 2680 [RFC2680]
o Round-trip Delay Metrics, RFC 2681 [RFC2681]; 4. Round-trip Delay Metrics, RFC 2681 [RFC2681]
o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 5. One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]
o IP Packet Delay Variation Metric, RFC 3393 [RFC3393]; 6. IP Packet Delay Variation Metric, RFC 3393 [RFC3393]
o IPPM Metrics for periodic streams, RFC 3432 [RFC3432]; 7. IPPM Metrics for periodic streams, RFC 3432 [RFC3432]
They are sequentially registered in the node ianaIppmMetrics. These are sequentially registered in the node ianaIppmMetrics.
The naming conventions used for the existing metrics, and encouraged The naming conventions used for the existing metrics, and encouraged
for new IPPM metrics, are : for new IPPM metrics, are :
o Metrics names comform SMIv2 rules for descriptors defined in the o Metrics names conform SMIv2 rules for descriptors defined in
section 3.1 of [RFC2578]; section 3.1 of [RFC2578];
o The name starts with the prefix 'ietf'; o The name starts with the prefix 'ietf';
o 'Type-P' prefix is removed; o 'Type-P' prefix is removed;
o '-' are removed; o '-' are removed;
o The letter following a '-' is changed to upper case. o The letter following a '-' is changed to upper case.
5. IANA Considerations 5. IANA Considerations
This section describes the rules for the management of the registry This section describes the rules for the management of the registry
by IANA. by IANA.
5.1 Management rules 5.1. Management Rules
Registrations are done sequentially by IANA in the ianaIppmMetrics Registrations are done sequentially by IANA in the ianaIppmMetrics
subtree on the bases of 'Specification Required' as defined in subtree on the basis of 'Specification Required', as defined in
[RFC2434]. [RFC2434].
The reference of the specification must point to a stable document The reference of the specification must point to a stable document
including a title, a revision and a date. including a title, a revision, and a date.
The name always starts with the name of the organization and must The name always starts with the name of the organization and must
respect the SMIv2 rules for descriptors defined in the section 3.1 of respect the SMIv2 rules for descriptors defined in section 3.1 of
[RFC2578]; [RFC2578].
A document that creates new metrics would have an IANA considerations A document that creates new metrics would have an "IANA
section in which it would describe new metrics to register. Considerations" section in which it would describe new metrics to be
registered.
An OBJECT IDENTITY assigned to a metric is definitive and cannot be 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 reused. If a new version of a metric is produced, then it is
with a new name and a new identifier. assigned with a new name and a new identifier.
5.2 Registration template 5.2. Registration Template
Following is a proposed template to insert in the IANA considerations The following is a proposed template to insert in the IANA
section. For each metric, that section would instanciate the considerations section. For each metric, that section would
following statement: instantiate the following statement:
IANA has registed the following metric in the IANA has registed the following metric in the IANA-IPPM-METRICS-
IANA-IPPM-METRICS-REGISTRY-MIB: REGISTRY-MIB:
aNewMetricName OBJECT-IDENTITY aNewMetricName OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The identifier for a new metric." "The identifier for a new metric."
REFERENCE REFERENCE
"Reference R, section n." "Reference R, section n."
::= { ianaIppmMetrics nn } -- IANA assigns nn ::= { ianaIppmMetrics nn } -- IANA assigns nn
6. Initial IPPM registry definition 6. Initial IPPM Registry Definition
IANA-IPPM-METRICS-REGISTRY-MIB DEFINITIONS ::= BEGIN IANA-IPPM-METRICS-REGISTRY-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 OBJECT-IDENTITY, MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI; FROM SNMPv2-SMI;
ianaIppmMetricsRegistry MODULE-IDENTITY ianaIppmMetricsRegistry MODULE-IDENTITY
LAST-UPDATED "200411300000Z" -- November 30th, 2004 LAST-UPDATED "200507280000Z" -- July 28, 2005
ORGANIZATION "IANA" ORGANIZATION "IANA"
CONTACT-INFO "Internet Assigned Numbers Authority CONTACT-INFO "Internet Assigned Numbers Authority
Postal: ICANN Postal: ICANN
4676 Admiralty Way, Suite 330 4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Tel: +1 310 823 9358 Tel: +1 310 823 9358
E-Mail: iana@iana.org" E-Mail: iana@iana.org"
skipping to change at page 6, line 26 skipping to change at page 5, line 20
CONTACT-INFO "Internet Assigned Numbers Authority CONTACT-INFO "Internet Assigned Numbers Authority
Postal: ICANN Postal: ICANN
4676 Admiralty Way, Suite 330 4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Tel: +1 310 823 9358 Tel: +1 310 823 9358
E-Mail: iana@iana.org" E-Mail: iana@iana.org"
DESCRIPTION DESCRIPTION
"This module defines a registry for IP Performance Metrics. "This module defines a registry for IP Performance Metrics.
Registrations are done sequentially by IANA in the ianaIppmMetrics Registrations are done sequentially by IANA in the ianaIppmMetrics
subtree on the bases of 'Specification Required' as defined in subtree on the basis of 'Specification Required', as defined in
[RFC2434]. [RFC2434].
The reference of the specification must point to a stable document The reference of the specification must point to a stable document
including a title, a revision and a date. including a title, a revision, and a date.
The name always starts with the name of the organization and must The name always starts with the name of the organization and must
respect the SMIv2 rules for descriptors defined in the section 3.1 respect the SMIv2 rules for descriptors defined in section 3.1 of
of [RFC2578]; [RFC2578].
A document that creates new metrics would have an IANA A document that creates new metrics would have an IANA
considerations section in which it would describe new metrics to considerations section in which it would describe new metrics to
register. be registered.
An OBJECT IDENTITY assigned to a metric is definitive and cannot 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 be reused. If a new version of a metric is produced, then it is
assigned with a new name and a new identifier. assigned with a new name and a new identifier.
Copyright (C) The Internet Society (2004). The initial version of Copyright (C) The Internet Society (2005). The initial version of
this MIB module was published in RFC yyyy; for full legal notices this MIB module was published in RFC 4148; for full legal notices
see the RFC itself or see: see the RFC itself or
http://www.ietf.org/copyrights/ianamib.html. " http://www.ietf.org/copyrights/ianamib.html. "
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
REVISION "200411300000Z" -- November 30th, 2004 REVISION "200507280000Z" -- July 28, 2005
DESCRIPTION DESCRIPTION
"Initial version of the IPPM metrics registry module. "Initial version of the IPPM metrics registry module.
This version published as RFC yyyy." This version published as RFC 4148."
::= { mib-2 XXX } -- XXX to be assigned by IANA ::= { mib-2 128 }
ianaIppmMetrics OBJECT-IDENTITY ianaIppmMetrics OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Registration point for IP Performance Metrics." "Registration point for IP Performance Metrics."
::= { ianaIppmMetricsRegistry 1 } ::= { ianaIppmMetricsRegistry 1 }
-- --
-- Registry of the metrics of the IPPM WG RFCs -- Registry of the metrics of the IPPM WG RFCs
-- --
-- --
-- RFC 2678 " IPPM Metrics for Measuring Connectivity" -- RFC 2678 " IPPM Metrics for Measuring Connectivity"
-- --
ietfInstantUnidirConnectivity OBJECT-IDENTITY ietfInstantUnidirConnectivity OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Instantaneous-Unidirectional-Connectivity" "Type-P-Instantaneous-Unidirectional-Connectivity"
REFERENCE "RFC2678, section 2." REFERENCE "RFC2678, section 2."
::= { ianaIppmMetrics 1} ::= { ianaIppmMetrics 1}
skipping to change at page 10, line 5 skipping to change at page 8, line 5
REFERENCE "RFC2679, section 5.3." REFERENCE "RFC2679, section 5.3."
::= { ianaIppmMetrics 10 } ::= { ianaIppmMetrics 10 }
ietfOneWayDelayInversePercentile OBJECT-IDENTITY ietfOneWayDelayInversePercentile OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-way-Delay-Inverse-Percentile" "Type-P-One-way-Delay-Inverse-Percentile"
REFERENCE "RFC2679, section 5.4." REFERENCE "RFC2679, section 5.4."
::= { ianaIppmMetrics 11 } ::= { ianaIppmMetrics 11 }
-- --
-- RFC 2680 "One Way Packet Loss Metric for IPPM" -- RFC 2680 "One-way Packet Loss Metric for IPPM"
-- --
ietfOneWayPktLoss OBJECT-IDENTITY ietfOneWayPktLoss OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-way-Packet-Loss" "Type-P-One-way-Packet-Loss"
REFERENCE "RFC2680, section 2." REFERENCE "RFC2680, section 2."
::= { ianaIppmMetrics 12 } ::= { ianaIppmMetrics 12 }
ietfOneWayPktLossPoissonStream OBJECT-IDENTITY ietfOneWayPktLossPoissonStream OBJECT-IDENTITY
skipping to change at page 12, line 32 skipping to change at page 10, line 26
::= { ianaIppmMetrics 25 } ::= { ianaIppmMetrics 25 }
ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-Way-Inter-Loss-Period-Lengths" "Type-P-One-Way-Inter-Loss-Period-Lengths"
REFERENCE " RFC3357, section 6.4." REFERENCE " RFC3357, section 6.4."
::= { ianaIppmMetrics 26 } ::= { ianaIppmMetrics 26 }
-- --
-- RFC3393: -- RFC 3393: "IP Packet Delay Variation Metric
-- IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) -- for IP Performance Metrics (IPPM)"
ietfOneWayIpdv OBJECT-IDENTITY ietfOneWayIpdv OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-way-ipdv" "Type-P-One-way-ipdv"
REFERENCE " RFC3393, section 2." REFERENCE " RFC3393, section 2."
::= { ianaIppmMetrics 27 } ::= { ianaIppmMetrics 27 }
ietfOneWayIpdvPoissonStream OBJECT-IDENTITY ietfOneWayIpdvPoissonStream OBJECT-IDENTITY
STATUS current STATUS current
skipping to change at page 14, line 17 skipping to change at page 12, line 7
This module does not define any management objects. Instead, it This module does not define any management objects. Instead, it
assigns a set of OBJECT-IDENTITIES which may be used by other MIB assigns a set of OBJECT-IDENTITIES which may be used by other MIB
modules to identify specific IP Performance Metrics. modules to identify specific IP Performance Metrics.
Meaningful security considerations can only be written in the MIB Meaningful security considerations can only be written in the MIB
modules that define management objects. This document has therefore modules that define management objects. This document has therefore
no impact on the security of the Internet. no impact on the security of the Internet.
8. References 8. References
8.1 Normative References 8.1. Normative References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of "Structure of Management Information Version 2 (SMIv2)",
Management Information Version 2 (SMIv2)", STD 58, RFC STD 58, RFC 2578, April 1999.
2578, April 1999.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999. Connectivity", RFC 2678, September 1999.
[RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, August 2002. Metrics", RFC 3357, August 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002. November 2002.
[RFC3432] Raisanen, V., Grotefeld, G. and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. November 2002.
8.2 Informative References 8.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
McCloghrie, K., Rose, M. and S. Waldbusser, "Textual "Textual Conventions for SMIv2", STD 58, RFC 2579,
Conventions for SMIv2", STD 58, RFC 2579, April 1999. April 1999.
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for "Introduction and Applicability Statements for Internet-
Internet-Standard Management Framework", RFC 3410, Standard Management Framework", RFC 3410, December 2002.
December 2002.
Author's Address Author's Address
Stephan Emile Stephan Emile
France Telecom R & D France Telecom R & D
2 avenue Pierre Marzin 2 avenue Pierre Marzin
Lannion, F-22307 Lannion F-22307
France
Fax: +33 2 96 05 18 52 Fax: +33 2 96 05 18 52
EMail: emile.stephan@francetelecom.com EMail: emile.stephan@francetelecom.com
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. 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 (2004). 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 Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/