< draft-morton-ippm-port-twamp-test-00.txt		draft-morton-ippm-port-twamp-test-01.txt >
	Network Working Group A. Morton		Network Working Group A. Morton, Ed.
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Updates: 4656 and 5357 (if approved) June 25, 2017		Updates: 4656 and 5357 (if approved) G. Mirsky, Ed.
	Intended status: Standards Track		Intended status: Standards Track ZTE Corp.
	Expires: December 27, 2017		Expires: January 22, 2018 July 21, 2017
	OWAMP and TWAMP Well-Known Port Assignments		OWAMP and TWAMP Well-Known Port Assignments
	draft-morton-ippm-port-twamp-test-00		draft-morton-ippm-port-twamp-test-01
	Abstract		Abstract
	This memo describes new well-known port assignments for the OWAMP and		This memo explains the motivation and describes the re-assignment of
	TWAMP protocols for control and measurement, and clarifies the		well-known ports for the OWAMP and TWAMP protocols for control and
	meaning and composition of these standards track protocol names for		measurement, and clarifies the meaning and composition of these
	the industry.		standards track protocol names for the industry.
	The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-		The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-
	known port assignments.		known port assignments.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on December 27, 2017.		This Internet-Draft will expire on January 22, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4		4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5.1. Impact on TWAMP-Control Protocol . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		5.2. Impact on OWAMP-Control Protocol . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		5.3. Impact on OWAMP/TWAMP-Test Protocols . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
			10.1. Normative References . . . . . . . . . . . . . . . . . . 7
			10.2. Informative References . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group first developed		The IETF IP Performance Metrics (IPPM) working group first developed
	the One-Way Active Measurement Protocol, OWAMP, specified in		the One-Way Active Measurement Protocol, OWAMP, specified in
	[RFC4656]. Further protocol development to support testing resulted		[RFC4656]. Further protocol development to support testing resulted
	in the Two-Way Active Measurement Protocol, TWAMP, specified in		in the Two-Way Active Measurement Protocol, TWAMP, specified in
	[RFC5357].		[RFC5357].
	Both OWAMP and TWAMP require the implementation of a control and mode		Both OWAMP and TWAMP require the implementation of a control and mode
	negotiation protocol (OWAMP-Control and TWAMP-Control) which employs		negotiation protocol (OWAMP-Control and TWAMP-Control) which employs
	the reliable transport services of TCP (including security		the reliable transport services of TCP (including security
	configuration and key derivation). The control protocols arrange for		configuration and key derivation). The control protocols arrange for
	the configuration and management of test sessions using the		the configuration and management of test sessions using the
	associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport.		associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport.
	This memo recognizes the value of assigning a well-known UDP port to		This memo recognizes the value of assigning a well-known UDP port to
	the *-Test protocols, and that this goal can easily be arranged		the *-Test protocols, and that this goal can easily be arranged
	through port re-assignments.		through port re-assignments.
	2. Scope		2. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
			as shown here.
			3. Scope
	The scope of this memo is to re-allocate well-known ports for the UDP		The scope of this memo is to re-allocate well-known ports for the UDP
	Test protocols that compose necessary parts of their respective		Test protocols that compose necessary parts of their respective
	standards track protocols, OWAMP and TWAMP (along with clarifications		standards track protocols, OWAMP and TWAMP, along with clarifications
	of the complete protocol composition).		of the complete protocol composition for the industry.
	The memo updates [RFC4656] and [RFC5357], in terms of the UDP well-		The memo updates [RFC4656] and [RFC5357], in terms of the UDP well-
	known port assignments.		known port assignments.
	3. Definitions		4. Definitions
	This section defines key terms and clarifies the required composition		This section defines key terms and clarifies the required composition
	of the OWAMP and TWAMP standards-track protocols.		of the OWAMP and TWAMP standards-track protocols.
	OWAMP-Control is the protocol defined in Section 3 of [RFC4656].		OWAMP-Control is the protocol defined in Section 3 of [RFC4656].
	OWAMP-Test is the protocol defined in Section 4 of [RFC4656].		OWAMP-Test is the protocol defined in Section 4 of [RFC4656].
	OWAMP is described in a direct quote from Section 1.1 of[RFC4656]:		OWAMP is described in a direct quote from Section 1.1 of[RFC4656]:
	"OWAMP actually consists of two inter-related protocols: OWAMP-		"OWAMP actually consists of two inter-related protocols: OWAMP-
	Control and OWAMP-Test." A similar sentence appears in Section 2 of		Control and OWAMP-Test." A similar sentence appears in Section 2 of
	[RFC4656]. Since the consensus of many dictionary definitions of		[RFC4656]. Since the consensus of many dictionary definitions of
	"consist" is "composed or made up of", implementation of both OWAMP-		"consist" is "composed or made up of", implementation of both OWAMP-
	Control and OWAMP-Test are REQUIRED for standards-track OWAMP for		Control and OWAMP-Test are REQUIRED for standards-track OWAMP
	standards-track OWAMP specified in [RFC4656].		specified in [RFC4656].
	TWAMP-Control is the protocol defined in Section 3 of [RFC5357].		TWAMP-Control is the protocol defined in Section 3 of [RFC5357].
	TWAMP-Test is the protocol defined in Section 4 of [RFC5357].		TWAMP-Test is the protocol defined in Section 4 of [RFC5357].
	TWAMP is described in a direct quote from Section 1.1 of [RFC5357]:		TWAMP is described in a direct quote from Section 1.1 of [RFC5357]:
	"Similar to OWAMP [RFC4656], TWAMP consists of two inter-related		"Similar to OWAMP [RFC4656], TWAMP consists of two inter-related
	protocols: TWAMP-Control and TWAMP-Test." Since the consensus of		protocols: TWAMP-Control and TWAMP-Test." Since the consensus of
	many dictionary definitions of "consist" is "composed or made up of",		many dictionary definitions of "consist" is "composed or made up of",
	implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for		implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for
	standards-track TWAMP specified in [RFC5357].		standards-track TWAMP specified in [RFC5357].
	TWAMP Light is an idea described in Informative Appendix I of		TWAMP Light is an idea described in Informative Appendix I of
	[RFC5357], and includes an un-specified control protocol (possibly		[RFC5357], and includes an un-specified control protocol (possibly
	communicating through non-standard means) combined with the TWAMP-		communicating through non-standard means) combined with the TWAMP-
	Test protocol. The TWAMP Light idea was relegated to the		Test protocol. The TWAMP Light idea was relegated to the
	Appendix because it failed to meet the requirements for IETF		Appendix because it failed to meet the requirements for IETF
	protocols (there are no specifications for negotiating this form of		protocols (there are no specifications for negotiating this form of
	operation, and no specifications for mandatory-to-implement security		operation, and no specifications for mandatory-to-implement security
	features), as decribed in the references below:		features), as described in the references below:
	o Lars Eggert's Area Director review [LarsAD], where he pointed out		o Lars Eggert's Area Director review [LarsAD], where he pointed out
	that having two variants of TWAMP, Light and Complete (called		that having two variants of TWAMP, Light and Complete (called
	standards track TWAMP here), required a protocol mechanism to		standards track TWAMP here), required a protocol mechanism to
	negotiate which variant will be used. See Lars' comment on Sec		negotiate which variant will be used. See Lars' comment on Sec
	5.2. The working group consensus was to place the TWAMP Light		5.2. The working group consensus was to place the TWAMP Light
	description in Appendix I, and to refer to the Appendix only as an		description in Appendix I, and to refer to the Appendix only as an
	"incremental path to adopting TWAMP, by implementing the TWAMP-		"incremental path to adopting TWAMP, by implementing the TWAMP-
	Test protocol first".		Test protocol first".
	o Tim Polk's DISCUSS Ballot, which points out that TWAMP Light was		o Tim Polk's DISCUSS Ballot, which points out that TWAMP Light was
	an incomplete specification because the key required for		an incomplete specification because the key required for
	authenticated and encrypted modes depended on the TWAMP-Control		authenticated and encrypted modes depended on the TWAMP-Control
	Session key. See Tim's DISCUSS on 2008-07-16 [TimDISCUSS].		Session key. See Tim's DISCUSS on 2008-07-16 [TimDISCUSS].
	Additional requirement statements were added in the Appendix to		Additional requirement statements were added in the Appendix to
	address Tim's DISCUSS Ballot (see the last three paragraphs of		address Tim's DISCUSS Ballot (see the last three paragraphs of
	Appendix I in [RFC5357]).		Appendix I in [RFC5357]).
	Since the idea of TWAMP Light clearly includes the TWAMP-Test		Since the idea of TWAMP Light clearly includes the TWAMP-Test
	component of TWAMP, it is considered reasonable for future systems to		component of TWAMP, it is considered reasonable for future systems to
	use the TWAMP-Test well-known UDP port (whose re-allocated purpose is		use the TWAMP-Test well-known UDP port (whose re-allocated assignment
	requested here). Clearly, the TWAMP Light idea envisions many		is requested here). Clearly, the TWAMP Light idea envisions many
	components and communication capabilities beyond TWAMP-Test		components and communication capabilities beyond TWAMP-Test
	(facilitating the security requirements, for example), otherwise the		(implementing the security requirements, for example), otherwise the
	Appendix would be one sentence long (equivocating TWAMP Light with		Appendix would be one sentence long (equivocating TWAMP Light with
	TWAMP-Test).		TWAMP-Test only).
	4. New Well-Known Ports		5. New Well-Known Ports
	Originally, both TCP and UDP well-known ports were assigned to the		Originally, both TCP and UDP well-known ports were assigned to the
	control protocols that are essential components of standards track		control protocols that are essential components of standards track
	OWAMP and TWAMP.		OWAMP and TWAMP.
	Since OWAMP-Control and TWAMP-Control require TCP transport, they		Since OWAMP-Control and TWAMP-Control require TCP transport, they
	cannot make use of the UDP ports which were originally assigned.		cannot make use of the UDP ports which were originally assigned.
	However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP		However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP
	transport. It may simplify some operations to have a well-known port		transport. It may simplify some operations to have a well-known port
	available for the Test protocols as a default port, and this memo		available for the Test protocols as a default port, and this memo
	requests re-assignment of the UDP well-known port from the Control		requests re-assignment of the UDP well-known port from the Control
	protocol to the Test protocol (see the IANA Considerations section).		protocol to the Test protocol (see the IANA Considerations
			Section 7).
	5. Security Considerations		5.1. Impact on TWAMP-Control Protocol
			Section 3.5 [RFC5357] describes the detailed process of negotiating
			the Receiver Port number, on which the TWAMP Session-Reflector will
			send and receive TWAMP-Test packets. The Control-Client, acting on
			behalf of the Session-Sender, proposes the Receiver port number from
			the Dynamic Port range [RFC6335]:
			"The Receiver Port is the desired UDP port to which TWAMP-Test
			packets will be sent by the Session-Sender (the port where the
			Session-Reflector is asked to receive test packets). The Receiver
			Port is also the UDP port from which TWAMP-Test packets will be
			sent by the Session-Reflector (the Session-Reflector will use the
			same UDP port to send and receive packets)."
			It is possible that the proposed Receiver Port may be not available,
			e.g., the port is in use by another test session or another
			application. In this case:
			"... the Server at the Session-Reflector MAY suggest an alternate
			and available port for this session in the Port field. The
			Control-Client either accepts the alternate port, or composes a
			new Session-Request message with suitable parameters. Otherwise,
			the Server uses the Accept field to convey other forms of session
			rejection or failure to the Control Client and MUST NOT suggest an
			alternate port; in this case, the Port field MUST be set to zero."
			A Control Client that supports use of the allocated TWAMP-Test
			Receiver Port Section 7 MAY request to use that port number in the
			Request-TW-Session Command. If the Server does not support the
			allocated TWAMP-Test Receiver Port, then it sends an alternate port
			number in the Accept-Session message with Accept field = 0. Thus the
			deployment of the allocated TWAMP Receiver Port number is backward
			compatible with existing TWAMP-Control solutions that are based on
			[RFC5357]. Of course, use of a UDP port number chosen from the
			Dynamic Port range [RFC6335] will help to avoid the situation when
			the Control-Client or Server finds the proposed port being already in
			use.
			5.2. Impact on OWAMP-Control Protocol
			As described above, an OWAMP Control Client that supports use of the
			allocated OWAMP-Test Receiver Port Section 7 MAY request to use that
			port number in the Request-Session Command. If the Server does not
			support the allocated OWAMP-Test Receiver Port (or does not have the
			port available), then it sends an alternate port number in the
			Accept-Session message with Accept field = 0. Further exchanges
			proceed as already specified.
			5.3. Impact on OWAMP/TWAMP-Test Protocols
			OWAMP/TWAMP-Test may be used to measure IP performance metrics in an
			Equal Cost Multipath (ECMP) environment. Though algorithms to
			balance IP flows among available paths have not been standardized,
			the most common is the five-tuple that uses destination IP address,
			source IP address, protocol type, destination port number, and source
			port number. When attempting to monitor different paths in ECMP
			network, it is sufficient to vary only one of five parameters, e.g.
			the source port number. Thus, there will be no negative impact on
			ability to arrange concurrent OWAMP/TWAMP test sessions between the
			same test points to monitor different paths in the ECMP network when
			using the re-allocated UDP port number as the Receiver Port, as use
			of the port is optional.
			6. Security Considerations
	The security considerations that apply to any active measurement of		The security considerations that apply to any active measurement of
	live paths are relevant here as well. See [RFC4656] and [RFC5357].		live paths are relevant here as well (see [RFC4656] and [RFC5357]).
	When considering privacy of those involved in measurement or those		When considering privacy of those involved in measurement or those
	whose traffic is measured, the sensitive information available to		whose traffic is measured, the sensitive information available to
	potential observers is greatly reduced when using active techniques		potential observers is greatly reduced when using active techniques
	which are within this scope of work. Passive observations of user		which are within this scope of work. Passive observations of user
	traffic for measurement purposes raise many privacy issues. We refer		traffic for measurement purposes raise many privacy issues. We refer
	the reader to the security and privacy considerations described in		the reader to the security and privacy considerations described in
	the Large Scale Measurement of Broadband Performance (LMAP) Framework		the Large Scale Measurement of Broadband Performance (LMAP) Framework
	[RFC7594], which covers both active and passive techniques.		[RFC7594], which covers both active and passive techniques.
	6. IANA Considerations		The registered UDP port as the Receiver Port for OWAMP/TWAMP-Test
			could become a target of denial-of-service (DoS) or used to aid man-
			in-the-middle (MITM) attacks. To improve protection from the DoS
			following methods are recommended:
	This memo requests that IANA re-allocate UDP ports 861 and 862 as		o filtering access to the OWAMP/TWAMP Receiver Port by access list;
	shown below, leaving the TCP port assignments as-is:
	Service Port Protocol Description		o using a non-globally routable IP address for the OWAMP/TWAMP
			Session-Reflector address.
	owamp-control 861 tcp OWAMP-Control [RFC4656]		A MITM attack may try to modify the content of the OWAMP/TWAMP-Test
			packets in order to alter the measurement results. However, an
			implementation can use authenticated mode to detect modification of
			data. In addition, use encrypted mode to prevent eavesdropping and
			un-detected modification of the OWAMP/TWAMP-Test packets.
	owamp-test 861 udp OWAMP-Test [RFCXXXX]		7. IANA Considerations
	twamp-control 862 tcp Two-way Active Measurement		This memo requests re-allocation of two UDP port numbers from the
	Protocol (TWAMP) Control [RFC5357]		System Ports range [RFC6335]. Specifically, this memo requests that
			IANA re-allocate UDP ports 861 and 862 as shown below, leaving the
			TCP port assignments as-is:
	twamp-test 862 udp Two-way Active Measurement		+------------+-------+---------+----------------------+-------------+
	Protocol (TWAMP) Test [RFCXXXX]		| Service | Port | Transpo | Description | Reference |
			| Name | Numbe | rt Prot | | |
			| | r | ocol | | |
			+------------+-------+---------+----------------------+-------------+
			| owamp- | 861 | tcp | OWAMP-Control | [RFC4656] |
			| control | | | | |
			| owamp-test | 861 | udp | OWAMP-Test | [RFCXXXX] |
			| | | | | |
			| twamp- | 861 | tcp | TWAMP-Control | [RFC5357] |
			| control | | | | |
			| twamp-test | 862 | udp | TWAMP-Test Receiver | [RFCXXXX] |
			| | | | Port | |
			+------------+-------+---------+----------------------+-------------+
			Table 1 Re-allocated OWAMP and TWAMP Ports
	where RFCXXXX is this memo when published.		where RFCXXXX is this memo when published.
	7. Acknowledgements		8. Contributors
	The author thanks ...		Richard Foote and Luis M. Contreras made notable contributions on
			this topic.
	8. References		9. Acknowledgements
	8.1. Normative References		The authors thank the IPPM working group for their rapid review; also
			Muthu Arul Mozhi Perumal and Luay Jalil for their participation and
			suggestions.
			10. References
			10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
	Zekauskas, "A One-way Active Measurement Protocol		Zekauskas, "A One-way Active Measurement Protocol
	(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,		(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
	<http://www.rfc-editor.org/info/rfc4656>.		<http://www.rfc-editor.org/info/rfc4656>.
	[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.		[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
	Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",		Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
	RFC 5357, DOI 10.17487/RFC5357, October 2008,		RFC 5357, DOI 10.17487/RFC5357, October 2008,
	<http://www.rfc-editor.org/info/rfc5357>.		<http://www.rfc-editor.org/info/rfc5357>.
			[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
			Cheshire, "Internet Assigned Numbers Authority (IANA)
			Procedures for the Management of the Service Name and
			Transport Protocol Port Number Registry", BCP 165,
			RFC 6335, DOI 10.17487/RFC6335, August 2011,
			<http://www.rfc-editor.org/info/rfc6335>.
	[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,		[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
	Aitken, P., and A. Akhter, "A Framework for Large-Scale		Aitken, P., and A. Akhter, "A Framework for Large-Scale
	Measurement of Broadband Performance (LMAP)", RFC 7594,		Measurement of Broadband Performance (LMAP)", RFC 7594,
	DOI 10.17487/RFC7594, September 2015,		DOI 10.17487/RFC7594, September 2015,
	<http://www.rfc-editor.org/info/rfc7594>.		<http://www.rfc-editor.org/info/rfc7594>.
	8.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <http://www.rfc-editor.org/info/rfc8174>.
			10.2. Informative References
	[LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/		[LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/
	LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008.		LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008.
	[TimDISCUSS]		[TimDISCUSS]
	"https://datatracker.ietf.org/doc/rfc5357/history/", July		"https://datatracker.ietf.org/doc/rfc5357/history/", July
	2008.		2008.
	Author's Address		Authors' Addresses
	Al Morton		Al Morton (editor)
	AT&T Labs		AT&T Labs
	200 Laurel Avenue South		200 Laurel Avenue South
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Phone: +1 732 420 1571		Phone: +1 732 420 1571
	Fax: +1 732 368 1192		Fax: +1 732 368 1192
	Email: acmorton@att.com		Email: acmorton@att.com
	URI: http://home.comcast.net/~acmacm/		Greg Mirsky (editor)
			ZTE Corp.
			Email: gregimirsky@gmail.com
End of changes. 35 change blocks.
	58 lines changed or deleted		172 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/