draft-ietf-ippm-metrics-registry-05.txt		draft-ietf-ippm-metrics-registry-06.txt
	Network Working Group E. Stephan		Network Working Group E. Stephan
	Internet Draft France Telecom R&D		Internet-Draft France Telecom R&D
	Document: draft-ietf-ippm-metrics-registry-05.txt January 2004		Category: Best Current Practice May 19, 2004
	Category: Standards Track		Expires: November 17, 2004
	IPPM metrics registry		IPPM metrics registry
			draft-ietf-ippm-metrics-registry-06.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026 [RFC2026].		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at http://
	http://www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
			This Internet-Draft will expire on November 17, 2004.
			Copyright Notice
			Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This memo defines a registry of the IPPM working group metrics. It		This memo defines a registry for IP Performance Metrics (IPPM). It
	assigns an OBJECT IDENTIFIER to each metric currently standardized by		assigns and registers an initial set of OBJECT IDENTITIES to
	the IPPM WG. It defines the rules for the identification of the		currently defined metrics in the IETF.
	metrics standardized in the future.
			This memo also defines the rules for adding new IP Performance
			Metrics in the future, both those standardized inside and outside the
			IETF.
			IANA has been assigned to administer this new registry.
	Table of Contents		Table of Contents
	1. The Internet-Standard Management Framework...................2		1. The Internet-Standard Management Framework . . . . . . . . . . 3
	2. Terms........................................................2		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview.....................................................2		3. The IPPM Framework . . . . . . . . . . . . . . . . . . . . . . 3
	4. The IPPM Framework...........................................2		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Overview.....................................................3		5. IPPM metrics Registry framework . . . . . . . . . . . . . . . 4
	6. IPPM metrics Registry framework..............................3		6. Initial IPPM metrics registry creation . . . . . . . . . . . . 4
	6.1. Metrics registry template....................................4		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
	6.2. Initial IPPM metrics registry creation.......................5		7.1 Management rules . . . . . . . . . . . . . . . . . . . . . 5
	6.3. Future IPPM metrics registration.............................6		7.1.1 Naming Conventions . . . . . . . . . . . . . . . . . . 5
	6.4. Metric defined in cooperation with other bodies..............6		7.1.2 Metrics defined by IETF . . . . . . . . . . . . . . . 5
	7. Initial IPPM registry definition.............................6		7.1.3 Metrics defined in cooperation with other bodies . . . 5
	8. Intellectual Property.......................................13		7.1.4 Private Metrics registration . . . . . . . . . . . . . 6
	9. Acknowledgments.............................................13		7.2 Registration templates . . . . . . . . . . . . . . . . . . 6
	10. Normative References........................................13		7.2.1 IETF RFCs . . . . . . . . . . . . . . . . . . . . . . 6
	11. Informative References......................................14		7.2.2 Other Organizations . . . . . . . . . . . . . . . . . 7
	12. Security Considerations.....................................14		7.2.3 Enterprises . . . . . . . . . . . . . . . . . . . . . 7
	13. Author's Addresses..........................................15		8. Initial IPPM registry definition . . . . . . . . . . . . . . . 7
	14. Full Copyright Statement....................................15		9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
			10.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
			10.2 Informative References . . . . . . . . . . . . . . . . . . . 16
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . 18
	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]. Managed objects are accessed via a virtual
	information store, termed the Management Information Base or MIB.		information store, termed the Management Information Base or MIB. MIB
	MIB objects are generally accessed through the Simple Network		objects are generally accessed through the Simple Network Management
	Management Protocol (SNMP). Objects in the MIB are defined using the		Protocol (SNMP). Objects in the MIB are defined using the mechanisms
	mechanisms defined in the Structure of Management Information (SMI).		defined in the Structure of Management Information (SMI). This memo
	This memo specifies a MIB module that is compliant to the SMIv2,		specifies a MIB module that is compliant to the SMIv2, which is
	which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579		described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579]
	[RFC2579] and STD 58, RFC 2580 [RFC2580].		and STD 58, RFC 2580 [RFC2580].
	2. Terms		2. Terms
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in BCP 14, RFC 2119		document are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119].		[RFC2119].
	3. Overview		3. The IPPM Framework
	This memo defines a registry of the IPPM working group metrics. It
	assigns an OBJECT IDENTIFIER to each metric currently standardized by
	the IPPM WG. It defines the rules for the identification of the
	metrics standardized in the future.
	4. The IPPM Framework
	The IPPM Framework consists in four major components:		The IPPM Framework consists in four major components:
	+ A general framework for defining performance metrics		o A general framework for defining performance metrics described in
	described in the Framework for IP Performance Metrics RFC2330		the Framework for IP Performance Metrics RFC2330 [RFC2330];
	[RFC 2330];
	+ A set of standardized metrics, which conform to this		o A set of standardized metrics, which conform to this framework.
	framework.
	+ Emerging metrics which are being specified in respect of this		o Emerging metrics which are being specified in respect of this
	framework;		framework;
	+ The IPPM-REPORTING-MIB for reporting the results of the
	measures and for interfacing heterogeneous measurement systems
	with management entities.
	5. Overview		o The IPPM-REPORTING-MIB for reporting the results of the measures
			and for interfacing heterogeneous measurement systems with
			management entities.
			4. 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:
	+ to permit metrics to be clearly referenced by MIBs or other data		o to permit metrics to be clearly referenced by MIB modules or other
	models;		data models;
	+ Metrics identifiers are needed to allow measurement
	interoperability;
	+ As specification of new metrics is a continuous process, special		o Metrics identifiers are needed to allow measurement
	care must be taken for the integration of future standardized		interoperability; As specification of new metrics is a continuous
	metrics;		process, special care must be taken for the integration of future
			standardized metrics;
	+ As the intent of the IPPM WG is to cooperate with other		o As the intent of the IPPM WG is to cooperate with other
	appropriate standards bodies and other areas of IETF to promote		appropriate standards bodies and other areas of IETF to promote
	consistent metrics, there is a need to permit registration of		consistent metrics, there is a need to permit registration of such
	such metrics.		metrics.
	6. IPPM metrics Registry framework		5. IPPM metrics Registry framework
	MIBs need OBJECT INDENTIFIERs to refer precisely to the standardized		MIB modules need to be able to precisely reference IPPM Metrics. The
	metrics. The registry associates an OBJECT IDENTIFIER with each		registry associates an OBJECT-IDENTITY with each metric. As an
	metric. As an example oneWayDelay and oneWayDelayPoissonStream have		example Type-P-One-way-Delay and Type-P-One-way-Delay-Poisson-Stream
	different identifiers.		have different OBJECT IDENTITIES.
	The registry has 2 root branches. The category of the document		The registry has 3 main branches. The origin of the document
	determines the node which branch the metric is identified in:		determines the node which branch the metric is identified in:
	+ Metrics defined in a RFC are identified in the 'rfc' tree;		o Metrics defined by IETF are identified in the 'ietf' tree;
	+ Metrics defined in cooperation with other bodies may be
	identified in the 'otherBodies' tree.		o Metrics defined in cooperation with other organizations may be
			identified in the 'otherOrganizations' tree.
			o Vendors may register private metrics in the 'enterprises' tree.
			This document defines an initial registry of the existing metrics and
			the rules to manage the registry.
			Documents defining metrics in the future will include in the IANA
			section the registration information to unambiguously identify these
			metrics.
			6. Initial IPPM metrics registry creation
			The initial registry identifies the metrics currently defined in the
			RFCs produced in the IPPM WG. By now, the IPPM WG defined 33 metrics
			related to 7 topics:
			o IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678];
			o One-way Delay Metrics, RFC 2679 [RFC2679];
			o One-way Packet Loss Metrics, RFC 2680 [RFC2680];
			o Round-trip Delay Metrics, RFC 2681 [RFC2681];
			o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357];
			o IP Packet Delay Variation Metric, RFC 3393 [RFC3393];
			o IPPM Metrics for periodic streams, RFC 3432 [RFC3432];
			7. IANA considerations
			This section describes the rules for the management of the registry
			by IANA.
			7.1 Management rules
			7.1.1 Naming Conventions
	The name of the metric in the registry must respect the SMIv2 rules		The name of the metric in the registry must respect the SMIv2 rules
	for descriptors ([RFC2578], section 3.1) and should be easily		for descriptors ([RFC2578], section 3.1) and should be easily
	readable. Consequently the following is applied to adapt the name		readable. Consequently the following is applied to adapt the name
	used in the metric definition:		used in the metric definition:
	+ The first letter is forced to lower case;		o The name always starts with the prefix of the organization.
	+ '-' are removed;
	+ The letter following a '-' is forced to upper case;
	+ 'Type-P' prefix is removed.
	This document defines an initial registry of the existing metrics.
	Documents defining metrics in the future will include a registry
	section to clearly identify these metrics.
	6.1. Metrics registry template
	Each memo includes a registry which identifies the metrics. The		o 'Type-P' prefix is removed.
	registry is defined using a MODULE-IDENTITY macro. The name of the
	module must be unique. Each metric is identified in the registry
	using an OBJECT-IDENTITY macro defining the metric name, status,
	reference and OBJECT IDENTIFIER.
	The registry is defined in a dedicated section of the memo.		o '-' are removed;
	As an example, consider an improbable IPPM WG draft that defines 4		o The letter following a '-' is changed to upper case;
	metrics in the sections 4, 4.1, 4.2 and 4.3, respectively:
	+ Type-P-Packet-Speed metric;		o A node assigned to a metric is definitive and cannot be reused.
	+ Type-P-Average-Packet-Speed metric;
	+ Type-P-Minimum-Packet-Speed metric;
	+ Type-P-Maximum-Packet-Speed metric.
	Following is the registry that may be included in the document:		o If a new version of a metric is produced then it is assigned with
			a new name and a new identifier.
	+ The name of the section is 'IPPM Packet Speed metrics registry';		7.1.2 Metrics defined by IETF
	+ The name of the module is ippmPacketSpeedMetricsRegistry;
	+ 'N' is the node assigned by IANA to the registry module;
	+ The next free node of the sub tree ippmMetricsRegistry.rfc(1) is
	'34'.
	IPPM-PACKET-SPEED-METRICS-REGISTRY DEFINITIONS ::= BEGIN		Such metrics are registered in the node ietf(1) after approval of the
			document by the IESG.
	IMPORTS		The name always starts with the prefix 'ietf'. They are registered in
	OBJECT-IDENTITY, MODULE-IDENTITY, mib-2		the node ietf(1). They are numbered using the metrics definitions
	FROM SNMPv2-SMI		order in each memo.
	rfc
	FROM IPPM-METRICS-REGISTRY;
	ippmPacketSpeedMetricsRegistry MODULE-IDENTITY		7.1.3 Metrics defined in cooperation with other bodies
	LAST-UPDATED "YYYYMMDD0000Z"
	ORGANIZATION "IETF IPPM working Group"
	CONTACT-INFO "
	Tel:		After approval of the document by the IESG, IANA will assign the
	E-mail:		organization with a subtree under the branch otherOrganizations(2).
	Postal:
	Send comments to <ippm@ietf.org>		The organization registers metrics under the branch
	Mailing list subscription info:		otherOrganizations(2), in the corresponding subtree. The name of the
	https://www1.ietf.org/mailman/listinfo/ippm "		metric always starts with the prefix of the organization. The prefix
	DESCRIPTION		is the name of the subtree assigned to the organization.
	" This memo defines the registry for IPPM Packet Speed metrics.
	Copyright (C) The Internet Society (2003).		Nothing prevents these bodies from registering metrics in their own
			OBJECT INDENTIFIER trees.
	This version of this MIB module is part of RFC yyyy; see the		7.1.4 Private Metrics registration
	RFC itself for full legal notices."
	REVISION "YYYYMMDD0000Z"
	DESCRIPTION
	"Initial version of the module of the registry for IPPM Packet
	Speed metrics.
	This version published as RFC yyyy."
	::= { mib-2 N }
	ippmPacketSpeedMetric OBJECT-IDENTITY		IANA already assigns enterprises with unambiguous identifiers named
	STATUS current		enterprise numbers or vendorID. See http://www.iana.org/numbers.html.
	DESCRIPTION
	"The identifier for the Type-P-Packet-Speed metric."
	REFERENCE "RFCyyyy, section 4."
	::= { rfc 34 }
	ippmAvgPacketSpeedmetric OBJECT-IDENTITY		After approval of the document by the IESG, an enterprise may
	STATUS current		register private metrics under the branch enterprises(3), in the
	DESCRIPTION		subtree corresponding to its enterprise number. The name of the
	"The identifier for the Type-P-Average-Packet-Speed metric."		metric always starts with the prefix of the company.
	REFERENCE "RFCyyyy, section 4.1."
	::= { rfc 35 }
	ippmMinPacketSpeedmetric OBJECT-IDENTITY		The enterprise is responsible for the assignment of the number if its
	STATUS current		subtree.
	DESCRIPTION
	"The identifier for the Type-P-Minimum-Packet-Speed metric."
	REFERENCE "RFCyyyy, section 4.2."
	::= { rfc 36 }
	ippmMaxPacketSpeedmetric OBJECT-IDENTITY		Example: The enterprise Acme,which enterprise number is 100000, will
	STATUS current		register its metrics in the subtree
	DESCRIPTION		ippmMetricsRegistry(x).enterprises(3).100000.
	"The identifier for the Type-P-Maximum-Packet-Speed metric."
	REFERENCE "RFCyyyy, section 4.3."
	::= { rfc 37 }
	END		7.2 Registration templates
	6.2. Initial IPPM metrics registry creation		A document that creates new Metrics would have an IANA considerations
	The initial registry identifies the metrics currently defined in the		section in which it would describe new metrics to register.
	RFCs produced in the IPPM WG.
	By now, the IPPM WG defined 33 metrics related to 7 topics:		7.2.1 IETF RFCs
	+ IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678];		For each metric, that section would have a statement aka:
	+ One-way Delay Metrics, RFC 2679 [RFC2679];
	+ One-way Packet Loss Metrics, RFC 2680 [RFC2680];
	+ Round-trip Delay Metrics, RFC 2681 [RFC2681];
	+ One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357];
	+ IP Packet Delay Variation Metric, RFC 3393 [RFC3393];
	+ IPPM Metrics for periodic streams, RFC 3432 [RFC3432];
	They are registered in the node rfc(1). They are numbered using the RFC		IANA has registed the following Metric in the IANA-IPPM-METRICS-MIB:
	order and the metrics definitions order in each memo. The node assigned
	to a metric is definitive and cannot be reused.
	6.3. Future IPPM metrics registration		ietfSomeNewMetricName OBJECT-IDENTITY
			STATUS current
			DESCRIPTION "The identifier for the Type-P-Some-New_Metric-Name
			metric."
			REFERENCE "RFCxxxx, section n." -- RFC-Editor fills in xxxx
			::= { ietf nn } -- IANA assigns nn
	When the IPPM WG draft is considered mature enough:		7.2.2 Other Organizations
	+ The chair of the IPPM WG, or someone proposed by the directors		For each metric, that section would have a statement aka:
	of the Transport Area, assigns to each metric a sub node chosen
	in the tree rfc(1) of the IPPM-METRICS-REGISTRY;
	+ Authors insert a registry template in their document. Then they		IANA has registed the following Metric in the IANA-IPPM-METRICS-MIB:
	create an OBJECT-IDENTITY instance per metric and complete the
	instance with the assigned sub nodes.
	That helps to prepare the final version of the draft. Moreover it		orgSomeNewMetricName OBJECT-IDENTITY
	facilitates software integration and interoperability measurement		STATUS current
	during the specification process.		DESCRIPTION "The identifier for the Some-New_Metric-Name
			metric."
			REFERENCE "URL, section n." -- link to the org document.
			::= { org nn } -- org assigns nn
	6.4. Metric defined in cooperation with other bodies		7.2.3 Enterprises
	Such metrics may be registered in the node otherBodies(2).		For each metric, that section would have a statement aka:
	Nothing prevents these bodies from registering metrics in their own		Vendor has registed the following Metric:
	object identifier trees.
	7. Initial IPPM registry definition		vendorSomeNewMetricName OBJECT-IDENTITY
			STATUS current
			DESCRIPTION "The identifier for the Some-New_Metric-Name
			metric."
			REFERENCE "URL, section n." -- link to the vendor document.
			::= { vendorID nn } -- vendor assigns nn
	IPPM-METRICS-REGISTRY DEFINITIONS ::= BEGIN		8. Initial IPPM registry definition
			IANA-IPPM-METRICS-REGISTRY DEFINITIONS ::= BEGIN
	IMPORTS		IMPORTS
	OBJECT-IDENTITY, MODULE-IDENTITY, mib-2		OBJECT-IDENTITY, MODULE-IDENTITY, mib-2
	FROM SNMPv2-SMI;		FROM SNMPv2-SMI;
	ippmMetricsRegistry MODULE-IDENTITY		ippmMetricsRegistry MODULE-IDENTITY
	LAST-UPDATED "200304170000Z" -- April 17th, 2003		REVISION "200405190000Z" -- May 19th, 2004
	ORGANIZATION "IETF IPPM working Group"		ORGANIZATION "IETF IPPM working Group"
	CONTACT-INFO "		CONTACT-INFO "
	Emile STEPHAN		Emile STEPHAN
	France Telecom R&D		France Telecom R&D
	Tel: +1 33 2 96 05 36 10		Tel: +1 33 2 96 05 36 10
	E-mail: emile.stephan@francetelecom.com		E-mail: emile.stephan@francetelecom.com
	Postal: 2, avenue Pierre Marzin		Postal: 2, avenue Pierre Marzin
	Lannion, FRANCE 22307		Lannion, FRANCE 22307
	Send comments to <ippm@ietf.org>		Send comments to ippm@ietf.org
	Mailing list subscription info:		Mailing list subscription info:
	https://www1.ietf.org/mailman/listinfo/ippm "		https://www1.ietf.org/mailman/listinfo/ippm "
	DESCRIPTION		DESCRIPTION
	"This memo defines a registry of the IPPM working group		"This memo defines a registry of the IPPM working group
	metrics.		metrics.
			Copyright (C) The Internet Society (2004). This version of
	Copyright (C) The Internet Society (2003). This version of this		this MIB module is part of RFC yyyy; see the RFC itself for
	MIB module is part of RFC yyyy; see the RFC itself for full		full legal notices."
	legal notices."		REVISION "200405190000Z" -- May 19th, 2004
	REVISION "200304170000Z" -- April 17th, 2003
	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 yyyy."
	::= { mib-2 XXX } -- XXX to be assigned by IANA		::= { mib-2 XXX } -- XXX to be assigned by IANA
	rfc OBJECT IDENTIFIER ::= { ippmMetricsRegistry 1 }		ietf OBJECT IDENTIFIER ::= { ippmMetricsRegistry 1 }
	otherBodies OBJECT IDENTIFIER ::= { ippmMetricsRegistry 2 }		otherOrganizations OBJECT IDENTIFIER ::= { ippmMetricsRegistry 2 }
			enterprises OBJECT IDENTIFIER ::= { ippmMetricsRegistry 3 }
	--		--
	-- 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"
	--		--
	instantUnidirectionConnectivity OBJECT-IDENTITY		ietfInstantUnidirConnectivity OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Instantaneous-Unidirectional-		"The identifier for the Type-P-Instantaneous-Unidirectional-
	Connectivity metric."		Connectivity metric."
	REFERENCE "RFC2678, section 2."		REFERENCE "RFC2678, section 2."
	::={rfc 1}		::={rfc 1}
	instantBidirectionConnectivity OBJECT-IDENTITY		ietfInstantBidirConnectivity OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Instantaneous-Bidirectional-		"The identifier for the Type-P-Instantaneous-Bidirectional-
	Connectivity metric."		Connectivity metric."
	REFERENCE "RFC2678, section 3."		REFERENCE "RFC2678, section 3."
	::={rfc 2}		::={rfc 2}
	intervalUnidirectionConnectivity OBJECT-IDENTITY		ietfIntervalUnidirConnectivity OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Interval-Unidirectional-		"The identifier for the Type-P-Interval-Unidirectional-
	Connectivity metric."		Connectivity metric."
	REFERENCE "RFC2678, section 4."		REFERENCE "RFC2678, section 4."
	::= { rfc 3 }		::= { rfc 3 }
	intervalBidirectionConnectivity OBJECT-IDENTITY		ietfIntervalBidirConnectivity OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Interval-Bidirectional-		"The identifier for the Type-P-Interval-Bidirectional-
	Connectivity metric."		Connectivity metric."
	REFERENCE "RFC2678, section 5."		REFERENCE "RFC2678, section 5."
	::= { rfc 4 }		::= { rfc 4 }
	intervalTemporalConnectivity OBJECT-IDENTITY		ietfIntervalTemporalConnectivity OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P1-P2-Interval-Temporal-		"The identifier for the Type-P1-P2-Interval-Temporal-
	Connectivity metric."		Connectivity metric."
	REFERENCE "RFC2678, section 6."		REFERENCE "RFC2678, section 6."
	::= { rfc 5 }		::= { rfc 5 }
	--		--
	-- RFC 2679 "A One-way Delay Metric for IPPM"		-- RFC 2679 "A One-way Delay Metric for IPPM"
	--		--
	oneWayDelay OBJECT-IDENTITY		ietfOneWayDelay OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Delay metric."		"The identifier for the Type-P-One-way-Delay metric."
	REFERENCE "RFC2679, section 3."		REFERENCE "RFC2679, section 3."
	::= { rfc 6 }		::= { rfc 6 }
	oneWayDelayPoissonStream OBJECT-IDENTITY		ietfOneWayDelayPoissonStream OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Delay-Poisson-Stream		"The identifier for the Type-P-One-way-Delay-Poisson-Stream
	metric."		metric."
	REFERENCE "RFC2679, section 4."		REFERENCE "RFC2679, section 4."
	::= { rfc 7 }		::= { rfc 7 }
	oneWayDelayPercentile OBJECT-IDENTITY		ietfOneWayDelayPercentile OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Delay-Percentile		"The identifier for the Type-P-One-way-Delay-Percentile
	metric."		metric."
	REFERENCE "RFC2679, section 5.1."		REFERENCE "RFC2679, section 5.1."
	::= { rfc 8 }		::= { rfc 8 }
	oneWayDelayMedian OBJECT-IDENTITY		ietfOneWayDelayMedian OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Delay-Median metric."		"The identifier for the Type-P-One-way-Delay-Median metric."
	REFERENCE "RFC2679, section 5.2."		REFERENCE "RFC2679, section 5.2."
	::= { rfc 9 }		::= { rfc 9 }
	oneWayDelayMinimum OBJECT-IDENTITY		ietfOneWayDelayMinimum OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Delay-Minimum metric."		"The identifier for the Type-P-One-way-Delay-Minimum metric."
	REFERENCE "RFC2679, section 5.3."		REFERENCE "RFC2679, section 5.3."
	::= { rfc 10 }		::= { rfc 10 }
	oneWayDelayInversePercentile OBJECT-IDENTITY		ietfOneWayDelayInversePercentile OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Delay-Inverse-Percentile		"The identifier for the Type-P-One-way-Delay-Inverse-
	metric. "		Percentile metric. "
	REFERENCE "RFC2679, section 5.4."		REFERENCE "RFC2679, section 5.4."
	::= { rfc 11 }		::= { rfc 11 }
	--		--
	-- RFC 2680 "One Way Packet Loss Metric for IPPM"		-- RFC 2680 "One Way Packet Loss Metric for IPPM"
	--		--
	oneWayPacketLoss OBJECT-IDENTITY		ietfOneWayPktLoss OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Packet-Loss metric."		"The identifier for the Type-P-One-way-Packet-Loss metric."
	REFERENCE "RFC2680, section 2."		REFERENCE "RFC2680, section 2."
	::= { rfc 12 }		::= { rfc 12 }
	oneWayPacketLossPoissonStream OBJECT-IDENTITY		ietfOneWayPktLossPoissonStream OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Packet-Loss-Poisson-		"The identifier for the Type-P-One-way-Packet-Loss-Poisson-
	Stream metric."		Stream metric."
	REFERENCE "RFC2680, section 3."		REFERENCE "RFC2680, section 3."
	::= { rfc 13 }		::= { rfc 13 }
	oneWayPacketLossAverage OBJECT-IDENTITY		ietfOneWayPktLossAverage OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Packet-Loss-Average		"The identifier for the Type-P-One-way-Packet-Loss-Average
	metric."		metric."
	REFERENCE "RFC2680, section 4."		REFERENCE "RFC2680, section 4."
	::= { rfc 14 }		::= { rfc 14 }
			-- TODO remnae as V5 in v5 dir
	-- RFC2681 "A Round-trip Delay Metric for IPPM"		-- RFC2681 "A Round-trip Delay Metric for IPPM"
	--		--
	roundtripDelay OBJECT-IDENTITY		ietfRoundTripDelay OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Round-trip-Delay metric."		"The identifier for the Type-P-Round-trip-Delay metric."
	REFERENCE " section 2 of the rfc2681."		REFERENCE " section 2 of the rfc2681."
	::= { rfc 15 }		::= { rfc 15 }
	roundtripDelayPoissonStream OBJECT-IDENTITY		ietfRoundTripDelayPoissonStream OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Round-trip-Delay-Poisson-Stream		"The identifier for the Type-P-Round-trip-Delay-Poisson
	metric."		-Stream metric."
	REFERENCE "RFC2681, section 4."		REFERENCE "RFC2681, section 4."
	::= { rfc 16 }		::= { rfc 16 }
			ietfRoundTripDelayPercentile OBJECT-IDENTITY
	roundtripDelayPercentile OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Round-trip-Delay-Percentile		"The identifier for the Type-P-Round-trip-Delay-Percentile
	metric."		metric."
	REFERENCE "RFC2681, section 4.1."		REFERENCE "RFC2681, section 4.1."
	::= { rfc 17 }		::= { rfc 17 }
	roundtripDelayMedian OBJECT-IDENTITY		ietfRoundTripDelayMedian OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Round-trip-Delay-Median metric."		"The identifier for the Type-P-Round-trip-Delay-Median
			metric."
	REFERENCE "RFC2681, section 4.2."		REFERENCE "RFC2681, section 4.2."
	::= { rfc 18 }		::= { rfc 18 }
	roundtripDelayMinimum OBJECT-IDENTITY		ietfRoundTripDelayMinimum OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Round-trip-Delay-Minimum		"The identifier for the Type-P-Round-trip-Delay-Minimum
	metric."		metric."
	REFERENCE "RFC2681, section 4.3."		REFERENCE "RFC2681, section 4.3."
	::= { rfc 19 }		::= { rfc 19 }
	roundtripDelayInversePercentile OBJECT-IDENTITY		ietfRoundTripDelayInversePercentile OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-Round-trip-Inverse-Percentile		"The identifier for the Type-P-Round-trip-Inverse-Percentile
	metric."		metric."
	REFERENCE "RFC2681, section 4.4."		REFERENCE "RFC2681, section 4.4."
	::= { rfc 20 }		::= { rfc 20 }
	--		--
	-- RFC3357: "One-way Loss Pattern Sample Metrics"		-- RFC3357: "One-way Loss Pattern Sample Metrics"
	--		--
	oneWayLossDistanceStream OBJECT-IDENTITY		ietfOneWayLossDistanceStream OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-Way-Loss-Distance-Stream		"The identifier for the Type-P-One-Way-Loss-Distance-Stream
	metric."		metric."
	REFERENCE " RFC3357, section 5.4.1."		REFERENCE " RFC3357, section 5.4.1."
	::={ rfc 21}		::={ rfc 21}
	oneWayLossPeriodStream OBJECT-IDENTITY		ietfOneWayLossPeriodStream OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-Way-Loss-Period-Stream		"The identifier for the Type-P-One-Way-Loss-Period-Stream
	metric."		metric."
	REFERENCE " RFC3357, section 5.4.2."		REFERENCE " RFC3357, section 5.4.2."
	::={ rfc 22}		::={ rfc 22}
	oneWayLossNoticeableRate OBJECT-IDENTITY		ietfOneWayLossNoticeableRate OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-Way-Loss-Noticeable-Rate		"The identifier for the Type-P-One-Way-Loss-Noticeable-Rate
	metric."		metric."
	REFERENCE " RFC3357, section 6.1."		REFERENCE " RFC3357, section 6.1."
	::= { rfc 23 }		::= { rfc 23 }
	oneWayLossPeriodTotal OBJECT-IDENTITY		ietfOneWayLossPeriodTotal OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-Way-Loss-Period-Total		"The identifier for the Type-P-One-Way-Loss-Period-Total
	metric."		metric."
	REFERENCE " RFC3357, section 6.2."		REFERENCE " RFC3357, section 6.2."
	::= { rfc 24 }		::= { rfc 24 }
	oneWayLossPeriodLengths OBJECT-IDENTITY		ietfOneWayLossPeriodLengths OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-Way-Loss-Period-Lengths		"The identifier for the Type-P-One-Way-Loss-Period-Lengths
	metric."		metric."
	REFERENCE " RFC3357, section 6.3."		REFERENCE " RFC3357, section 6.3."
	::= { rfc 25 }		::= { rfc 25 }
	oneWayInterLossPeriodLengths OBJECT-IDENTITY		ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-Way-Inter-Loss-Period-		"The identifier for the Type-P-One-Way-Inter-Loss-Period-
	Lengths metric."		Lengths metric."
	REFERENCE " RFC3357, section 6.4."		REFERENCE " RFC3357, section 6.4."
	::= { rfc 26 }		::= { rfc 26 }
	--		--
	-- RFC3393:		-- RFC3393:
			-- IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)
	oneWayIpdv OBJECT-IDENTITY		ietfOneWayIpdv OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-ipdv metric."		"The identifier for the Type-P-One-way-ipdv metric."
	REFERENCE " RFC3393, section 2."		REFERENCE " RFC3393, section 2."
	::= { rfc 27 }		::= { rfc 27 }
	oneWayIpdvPoissonStream OBJECT-IDENTITY		ietfOneWayIpdvPoissonStream OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-ipdv-Poisson-stream		"The identifier for the Type-P-One-way-ipdv-Poisson-stream
	metric."		metric."
	REFERENCE " RFC3393, section 3."		REFERENCE " RFC3393, section 3."
	::= { rfc 28 }		::= { rfc 28 }
	oneWayIpdvPercentile OBJECT-IDENTITY		ietfOneWayIpdvPercentile OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-ipdv-percentile metric."		"The identifier for the Type-P-One-way-ipdv-percentile metric."
	REFERENCE " RFC3393, section 4.3."		REFERENCE " RFC3393, section 4.3."
	::= { rfc 29 }		::= { rfc 29 }
	oneWayIpdvInversePercentile OBJECT-IDENTITY		ietfOneWayIpdvInversePercentile OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-ipdv-inverse-percentile		"The identifier for the Type-P-One-way-ipdv-inverse
	metric."		-percentile metric."
	REFERENCE " RFC3393, section 4.4."		REFERENCE " RFC3393, section 4.4."
	::= { rfc 30 }		::= { rfc 30 }
	oneWayIpdvJitter OBJECT-IDENTITY		ietfOneWayIpdvJitter OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-ipdv-jitter metric."		"The identifier for the Type-P-One-way-ipdv-jitter metric."
	REFERENCE " RFC3393, section 4.5."		REFERENCE " RFC3393, section 4.5."
	::= { rfc 31 }		::= { rfc 31 }
	oneWayPeakToPeakIpdv OBJECT-IDENTITY		ietfOneWayPeakToPeakIpdv OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-peak-to-peak-ipdv		"The identifier for the Type-P-One-way-peak-to-peak-ipdv
	metric."		metric."
	REFERENCE " RFC3393, section 4.6."		REFERENCE " RFC3393, section 4.6."
	::= { rfc 32 }		::= { rfc 32 }
	--		--
	-- RFC3432: "Network performance measurement with periodic streams"		-- RFC3432: "Network performance measurement with periodic streams"
	--		--
	oneWayDelayPeriodicStream OBJECT-IDENTITY		ietfOneWayDelayPeriodicStream OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The identifier for the Type-P-One-way-Delay-Periodic-Stream		"The identifier for the Type-P-One-way-Delay-Periodic-Stream
	metric."		metric."
	REFERENCE " RFC3432, section 4."		REFERENCE " RFC3432, section 4."
	::= { rfc 33 }		::= { rfc 33 }
	END		END
	8. Intellectual Property		9. Security Considerations
	The IETF takes no position regarding the validity or scope of any		This module does not define any management objects. Instead, it
	intellectual property or other rights that might be claimed to		assigns a set of OBJECT-IDENTITIES which may be used by other MIB
	pertain to the implementation or use of the technology described in		modules to identify specific IP Performance Metrics.
	this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication 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 implementors or users of this specification can
	be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		Meaningful security considerations can only be written in the MIB
	copyrights, patents or patent applications, or other proprietary		modules that define management objects. This document has therefore
	rights which may cover technology that may be required to practice		no impact on the security of the Internet.
	this standard. Please address the information to the IETF Executive
	Director.
	9. Acknowledgments		10. References
	The author gratefully acknowledges Andy Bierman and Randy Presuhn for		10.1 Normative References
	their guidance and comments.
	10. Normative References		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	Rose, M. and S. Waldbusser, "Structure of Management Information		(IPv6) Specification", RFC 2460, December 1998.
	Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
	[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,		[RFC2463] Conta, A. and S. Deering, "Internet Control Message
	Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD		Protocol (ICMPv6) for the Internet Protocol Version 6
	58, RFC 2579, April 1999.		(IPv6) Specification", RFC 2463, December 1998.
	[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2",		IPv6 Specification", RFC 2473, December 1998.
	STD 58, RFC 2580, April 1999.
	11. Informative References		[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
			McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of
			Management Information Version 2 (SMIv2)", STD 58, RFC
			2578, April 1999.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
	3", BCP 9, RFC 2026, October 1996.		McCloghrie, K., Rose, M. and S. Waldbusser, "Textual
			Conventions for SMIv2", STD 58, RFC 2579, April 1999.
	[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,		[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
	"Framework for IP Performance Metrics", RFC 2330, May 1998.		"Conformance Statements for SMIv2", STD 58, RFC 2580,
			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 Ravikanth, R., "One-way Loss Pattern Sample		[RFC2895] Bierman, A., Bucci, C. and R. Iddon, "Remote Network
			Monitoring MIB Protocol Identifier Reference", RFC 2895,
			August 2000.
			[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
			Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
			Encoding", RFC 3032, January 2001.
			[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, November		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	2002.		November 2002.
	[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
	"Introduction and Applicability Statements for Internet Standard
	Management Framework", RFC 3410, December 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, November		performance measurement with periodic streams", RFC 3432,
	2002.		November 2002.
	12. Security Considerations		10.2 Informative References
	All the items specified in this MIB module are defined using the		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	macro OBJECT-IDENTITY. This macro does not have a MAX-ACCESS clause.		3", BCP 9, RFC 2026, October 1996.
	There are no management objects defined in this MIB module that have		[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
	a MAX-ACCESS clause of read-write and/or read-create. So, if this		"Framework for IP Performance Metrics", RFC 2330, May
	MIB module is implemented correctly, then there is no risk that an		1998.
	intruder can alter or create any management objects of this MIB
	module via direct SNMP SET operations.
	It is RECOMMENDED that implementers consider the security features as		[RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote Network
	provided by the SNMPv3 framework (see [RFC3410], section 8),		Monitoring MIB Protocol Identifier Macros", RFC 2896,
	including full support for the SNMPv3 cryptographic mechanisms (for		August 2000.
	authentication and privacy).
	Further, deployment of SNMP versions prior to SNMPv3 is NOT		[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
	RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to		"Introduction and Applicability Statements for
	enable cryptographic security. It is then a customer/operator		Internet-Standard Management Framework", RFC 3410,
	responsibility to ensure that the SNMP entity giving access to an		December 2002.
	instance of this MIB module is properly configured to give access to
	the objects only to those principals (users) that have legitimate
	rights to indeed GET or SET (change/create/delete) them.
	13. Author's Address		Author's Address
	Emile STEPHAN		Stephan Emile
	France Telecom R&D		France Telecom R&D
	2, avenue Pierre Marzin		2 avenue Pierre Marzin
	F-22307 Lannion cedex		Lannion, F-22307
	Phone: + 33 2 96 05 36 10
	Email: emile.stephan@francetelecom.com
	14. Full Copyright Statement		Fax: +33 2 96 05 18 52
			EMail: emile.stephan@francetelecom.com
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			intellectual property 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; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication 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 implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
			Full Copyright Statement
			Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist its implementation may be prepared, copied, published and		or assist in its implementation may be prepared, copied, published
	distributed, in whole or in part, without restriction of any kind,		and distributed, in whole or in part, without restriction of any
	provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgment
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/