< draft-ietf-ippm-twamp-02.txt		draft-ietf-ippm-twamp-03.txt >
	K. Hedayat		K. Hedayat
	Internet Draft Brix Networks		Internet Draft Brix Networks
	Expires: April 2007 R. Krzanowski		Expires: September 2007 R. Krzanowski
	Verizon		Verizon
	K. Yum		K. Yum
	Juniper Networks		Juniper Networks
	A. Morton		A. Morton
	AT&T Labs		AT&T Labs
	J. Babiarz		J. Babiarz
	Nortel Networks		Nortel Networks
	November 2006		March 2007
	A Two-way Active Measurement Protocol (TWAMP)		A Two-way Active Measurement Protocol (TWAMP)
	draft-ietf-ippm-twamp-02		draft-ietf-ippm-twamp-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://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.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP)		The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP)
	provides a common protocol for measuring one-way metrics between		provides a common protocol for measuring one-way metrics between
	network devices. OWAMP can be used bi-directionally to measure		network devices. OWAMP can be used bi-directionally to measure
	one-way metrics in both directions between two network elements.		one-way metrics in both directions between two network elements.
	However, it does not accommodate round-trip or two-way		However, it does not accommodate round-trip or two-way
	measurements. This memo specifies a Two-way Active Measurement		measurements. This memo specifies a Two-way Active Measurement
	Protocol (TWAMP), based on the OWAMP, that adds two-way or		Protocol (TWAMP), based on the OWAMP, that adds two-way or
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	3.3 Value of the Accept Fields................................6		3.3 Value of the Accept Fields................................6
	3.4 TWAMP Control Commands....................................6		3.4 TWAMP Control Commands....................................6
	3.5 Creating Test Sessions....................................6		3.5 Creating Test Sessions....................................6
	3.6 Send Schedules............................................8		3.6 Send Schedules............................................8
	3.7 Starting Test Sessions....................................8		3.7 Starting Test Sessions....................................8
	3.8 Stop-Sessions.............................................8		3.8 Stop-Sessions.............................................8
	3.9 Fetch-Session.............................................8		3.9 Fetch-Session.............................................8
	4. TWAMP Test....................................................8		4. TWAMP Test....................................................8
	4.1 Sender Behavior...........................................9		4.1 Sender Behavior...........................................9
	4.2 Reflector Behavior........................................9		4.2 Reflector Behavior........................................9
	5. Implementers Guide...........................................14		5. Implementers Guide...........................................15
	5.1 Complete TWAMP...........................................14		5.1 Complete TWAMP...........................................15
	5.2 TWAMP Light..............................................14		5.2 TWAMP Light..............................................16
	6. Security Considerations......................................15		6. Security Considerations......................................17
	7. Acknowledgements.............................................15		7. Acknowledgements.............................................17
	8. IANA Considerations..........................................15		8. IANA Considerations..........................................17
	9. Internationalization Considerations..........................16		9. Internationalization Considerations..........................17
	10. References..................................................16		10. References..................................................18
	10.1 Normative References....................................16		10.1 Normative References....................................18
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group has completed		The IETF IP Performance Metrics (IPPM) working group has completed
	a draft standard for the round-trip delay [RFC2681] metric. IPPM		a draft standard for the round-trip delay [RFC2681] metric. IPPM
	has also completed a protocol for the control and collection of		has also completed a protocol for the control and collection of
	one-way measurements, the One-way Active Measurement Protocol		one-way measurements, the One-way Active Measurement Protocol
	(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip		(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip
	or two-way measurements.		or two-way measurements.
	skipping to change at page 7, line 45 ¶		skipping to change at page 7, line 45 ¶
	timeout interval following the reception of the Stop-Sessions		timeout interval following the reception of the Stop-Sessions
	message. The Session-Reflector MUST NOT reflect packets that are		message. The Session-Reflector MUST NOT reflect packets that are
	received beyond the timeout.		received beyond the timeout.
	Type-P descriptor is as defined in OWAMP [RFC4656]. The only		Type-P descriptor is as defined in OWAMP [RFC4656]. The only
	capability of this field is to set the Differentiated Services Code		capability of this field is to set the Differentiated Services Code
	Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST		Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST
	be used in test packets reflected by the Session-Reflector.		be used in test packets reflected by the Session-Reflector.
	Since there are no Schedule Slot Descriptions, the Request-Session		Since there are no Schedule Slot Descriptions, the Request-Session
	Message is followed by HMAC. This completes one logical message,		Message is completed by MBZ and HMAC fields. This completes one
	referred to as the Request-Session Command.		logical message, referred to as the Request-Session Command.
	The Session-Reflector MUST respond to each Request-Session Command		The Session-Reflector MUST respond to each Request-Session Command
	with an Accept-Message as defined in OWAMP [RFC4656]. The Port is		with an Accept-Message as defined in OWAMP [RFC4656]. The Port is
	the port to which TWAMP test packets are sent by the Session-Sender		the port to which TWAMP test packets are sent by the Session-Sender
	toward the Session-Reflector. In other words, the Port field		toward the Session-Reflector. In other words, the Port field
	indicates the port number where the Session-Reflector expects to		indicates the port number where the Session-Reflector expects to
	receive packets from the Session-Sender.		receive packets from the Session-Sender.
	3.6 Send Schedules		3.6 Send Schedules
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For authenticated and encrypted modes:		For authenticated and encrypted modes:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IZP (12 octets) |		| MBZ (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Error Estimate | |		| Error Estimate | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| IZP (6 octets) |		| MBZ (6 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Receive Timestamp |		| Receive Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IZP (8 octets) |		| MBZ (8 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| Sender Sequence Number |		| Sender Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IZP (12 octets) |		| MBZ (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Timestamp |		| Sender Timestamp |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Error Estimate | |		| Sender Error Estimate | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| IZP (6 octets) |		| MBZ (6 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| HMAC (16 octets) |
			| |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| |		| |
	. .		. .
	. Packet Padding .		. Packet Padding .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Sequence Number is the sequence number of the test packet according		Sequence Number is the sequence number of the test packet according
	to its arrival at the Session-Reflector. It starts with zero and		to its arrival at the Session-Reflector. It starts with zero and
	is incremented by one for each subsequent packet. The Sequence		is incremented by one for each subsequent packet. The Sequence
	Number generated by the Session-Reflector is independent from the		Number generated by the Session-Reflector is independent from the
	sequence number of the arriving packets.		sequence number of the arriving packets.
	Timestamp and Error Estimate are the Session-Reflector's transmit		Timestamp and Error Estimate are the Session-Reflector's transmit
	timestamp and error estimate for the reflected test packet,		timestamp and error estimate for the reflected test packet,
	respectively. The format of all timestamp and error estimate		respectively. The format of all timestamp and error estimate
	fields follow the definition and formats defined by OWAMP[RFC4656].		fields follow the definition and formats defined by OWAMP[RFC4656].
	skipping to change at page 13, line 50 ¶		skipping to change at page 14, line 7 ¶
	maximum data integrity protection while in authenticated mode the		maximum data integrity protection while in authenticated mode the
	sequence numbers are encrypted and the timestamps are sent in clear		sequence numbers are encrypted and the timestamps are sent in clear
	text. Sending the timestamp in clear text in authenticated mode		text. Sending the timestamp in clear text in authenticated mode
	allows one to reduce the time between when a timestamp is obtained		allows one to reduce the time between when a timestamp is obtained
	by a reflector and when the packet is reflected out. In encrypted		by a reflector and when the packet is reflected out. In encrypted
	mode, both the sender and reflector have to fetch the timestamp,		mode, both the sender and reflector have to fetch the timestamp,
	encrypt it, and send it; in authenticated mode, the middle step is		encrypt it, and send it; in authenticated mode, the middle step is
	removed, potentially improving accuracy (the sequence number can be		removed, potentially improving accuracy (the sequence number can be
	encrypted before the timestamp is fetched).		encrypted before the timestamp is fetched).
	In authenticated mode, the first block (32 octets) of each packet		In authenticated mode, the first block (16 octets) of each packet
	is encrypted using AES Electronic Cookbook (ECB) mode.		is encrypted using AES Electronic Cookbook (ECB) mode.
	Obtaining the key, encryption method, and packet padding is as		Obtaining the key, encryption method, and packet padding follows
	defined in section 4.1.2 of OWAMP [RFC4656]. In unauthenticated		the same procedure as OWAMP as described below.
	mode, no encryption is applied.		Similarly to each TWAMP-Control session, each TWAMP-Test session
			has two keys: an AES Session-key and an HMAC Session-key. However,
			there is a difference in how the keys are obtained: in the case of
			TWAMP-Control, the keys are generated by the client and
			communicated (as part of the Token) during connection setup as part
			of Set-Up-Response message; in the case of TWAMP-Test, described
			here, the keys are derived from the TWAMP-Control keys and the SID.
			The TWAMP-Test AES Session-key is obtained as follows: the
			TWAMP-Control AES Session-key (the same AES Session-key as is used
			for the corresponding TWAMP-Control session, where it is used in a
			different chaining mode) is encrypted, using AES, with the 16-octet
			session identifier (SID) as the key; this is a single-block ECB
			encryption; its result is the TWAMP-Test AES Session-key to use in
			encrypting (and decrypting) the packets of the particular
			TWAMP-Test session. Note that all of TWAMP-Test AES Session-key,
			TWAMP-Control AES Session-key, and the SID are comprised of 16
			octets.
			The TWAMP-Test HMAC Session-key is obtained as follows: the
			TWAMP-Control HMAC Session-key (the same HMAC Session-key as is
			used for the corresponding TWAMP-Control session) is encrypted,
			using AES, with the 16-octet session identifier (SID) as the key;
			this is a two-block CBC encryption, always performed with IV=0; its
			result is the TWAMP-Test HMAC Session-key to use in authenticating
			the packets of the particular TWAMP-Test session. Note that all of
			TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are
			comprised of 32 octets, while the SID is 16 octets.
			ECB mode used for encrypting the first block of TWAMP-Test packets
			in authenticated mode does not involve any actual chaining; this
			way, lost, duplicated, or reordered packets do not cause problems
			with deciphering any packet in an TWAMP-Test session.
			In encrypted mode, the first two blocks (32 octets) are encrypted
			using AES CBC mode. The AES Session-key to use is obtained in the
			same way as the key for authenticated mode. Each TWAMP-Test packet
			is encrypted as a separate stream, with just one chaining
			operation; chaining does not span multiple packets so that lost,
			duplicated, or reordered packets do not cause problems. The
			initialization vector for the CBC encryption is a value with all
			bits equal to zero.
			Implementation note: Naturally, the key schedule for each
			TWAMP-Test session MAY be set up only once per session, not once
			per packet.
			HMAC in TWAMP-Test only covers the part of the packet that is also
			encrypted. So, in authenticated mode, HMAC covers the first block
			(16 octets); in encrypted mode, HMAC covers two first blocks (32
			octets). In TWAMP-Test HMAC is not encrypted (note that this is
			different from TWAMP-Control, where encryption in stream mode is
			used, so everything including the HMAC blocks ends up being
			encrypted).
			In unauthenticated mode, no encryption or authentication is
			applied.
			Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
			generated independently of any other pseudo-random numbers
			mentioned in this document). However, implementations MUST provide
			a configuration parameter, an option, or a different means of
			making Packet Padding consist of all zeros.
	5. Implementers Guide		5. Implementers Guide
	This section serves as guidance to implementers of TWAMP. Two		This section serves as guidance to implementers of TWAMP. Two
	architectures are presented in this section for implementations		architectures are presented in this section for implementations
	where two hosts play the subsystem roles of TWAMP. Although only		where two hosts play the subsystem roles of TWAMP. Although only
	two architectures are presented here the protocol does not require		two architectures are presented here the protocol does not require
	their use. Similar to OWAMP [RFC4656] TWAMP is designed with		their use. Similar to OWAMP [RFC4656] TWAMP is designed with
	complete flexibility to allow different architectures that suite		complete flexibility to allow different architectures that suite
	multiple system requirements.		multiple system requirements.
	skipping to change at page 15, line 35 ¶		skipping to change at page 17, line 9 ¶
	This example eliminates the need for the TWAMP-Control protocol and		This example eliminates the need for the TWAMP-Control protocol and
	assumes that the Session-Reflector is configured and communicates		assumes that the Session-Reflector is configured and communicates
	its configuration with the Server through non-standard means. The		its configuration with the Server through non-standard means. The
	Session-Reflector simply reflects the incoming packets back to the		Session-Reflector simply reflects the incoming packets back to the
	controller while copying the necessary information and generating		controller while copying the necessary information and generating
	sequence number and timestamp values per section 5.2.1.		sequence number and timestamp values per section 5.2.1.
	6. Security Considerations		6. Security Considerations
	The security considerations of OWAMP [RFC4656] apply.		Fundamentally TWAMP and OWAMP use the same protocol for
			establishment of Control and Test procedures. The main difference
			between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
			vs. the Session-Receiver behavior in OWAMP. This difference in
			behavior does not introduce any known security vulnerabilities that
			are not already addressed by the security features of OWAMP. The
			entire security considerations of OWAMP [RFC4656] applies to TWAMP.
	7. Acknowledgements		7. Acknowledgements
	We would like to thank Nagarjuna Venn, Sharee McNab, Nick Kinraid,		We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
	and Stanislav Shalunov for their comments, suggestions, reviews,		and Stanislav Shalunov for their comments, suggestions, reviews,
	helpful discussion and proof-reading.		helpful discussion and proof-reading.
	8. IANA Considerations		8. IANA Considerations
	IANA has allocated a well-known TCP port number (861) for the		IANA has allocated a well-known TCP port number (861) for the
	OWAMP-Control part of the OWAMP [RFC4656] protocol which also		OWAMP-Control part of the OWAMP [RFC4656] protocol which also
	applies to the TWAMP-Control part of the TWAMP protocol.		applies to the TWAMP-Control part of the TWAMP protocol.
	9. Internationalization Considerations		9. Internationalization Considerations
	The protocol does not carry any information in a natural language,		The protocol does not carry any information in a natural language,
	with the possible exception of the KeyID in TWAMP-Control, which is		with the possible exception of the KeyID in TWAMP-Control, which is
	encoded in UTF-8.		encoded in UTF-8.
	skipping to change at page 17, line 49 ¶		skipping to change at page 19, line 35 ¶
	Nortel Networks		Nortel Networks
	3500 Carling Avenue		3500 Carling Avenue
	Ottawa, Ont K2H 8E9		Ottawa, Ont K2H 8E9
	Canada		Canada
	Email: babiarz@nortel.com		Email: babiarz@nortel.com
	URI: http://www.nortel.com/		URI: http://www.nortel.com/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	PARTICULAR PURPOSE.		FOR A PARTICULAR PURPOSE.
	Intellectual Property		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		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described		to pertain to the implementation or use of the technology described
	in this document or the extent to which any license under such		in this document or the extent to which any license under such
	rights might or might not be available; nor does it represent that		rights might or might not be available; nor does it represent that
	it has made any independent effort to identify any such rights.		it has made any independent effort to identify any such rights.
	Information on the procedures with respect to rights in RFC		Information on the procedures with respect to rights in RFC
End of changes. 20 change blocks.
	34 lines changed or deleted		107 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/