draft-ietf-taps-minset-09.txt		draft-ietf-taps-minset-10.txt
	TAPS M. Welzl		TAPS M. Welzl
	Internet-Draft S. Gjessing		Internet-Draft S. Gjessing
	Intended status: Informational University of Oslo		Intended status: Informational University of Oslo
	Expires: March 17, 2019 September 13, 2018		Expires: March 22, 2019 September 18, 2018
	A Minimal Set of Transport Services for End Systems		A Minimal Set of Transport Services for End Systems
	draft-ietf-taps-minset-09		draft-ietf-taps-minset-10
	Abstract		Abstract
	This draft recommends a minimal set of Transport Services offered by		This draft recommends a minimal set of Transport Services offered by
	end systems, and gives guidance on choosing among the available		end systems, and gives guidance on choosing among the available
	mechanisms and protocols. It is based on the set of transport		mechanisms and protocols. It is based on the set of transport
	features in RFC 8303.		features in RFC 8303.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 March 17, 2019.		This Internet-Draft will expire on March 22, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . 22		10.1. Normative References . . . . . . . . . . . . . . . . . . 22
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		10.2. Informative References . . . . . . . . . . . . . . . . . 22
	Appendix A. The Superset of Transport Features . . . . . . . . . 24		Appendix A. The Superset of Transport Features . . . . . . . . . 24
	A.1. CONNECTION Related Transport Features . . . . . . . . . . 25		A.1. CONNECTION Related Transport Features . . . . . . . . . . 25
	A.2. DATA Transfer Related Transport Features . . . . . . . . 41		A.2. DATA Transfer Related Transport Features . . . . . . . . 41
	A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 41		A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 41
	A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 45		A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 45
	A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 46		A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 46
	Appendix B. Revision information . . . . . . . . . . . . . . . . 47		Appendix B. Revision information . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	Currently, the set of transport services that most applications use		Currently, the set of transport services that most applications use
	is based on TCP and UDP (and protocols that are layered on top of		is based on TCP and UDP (and protocols that are layered on top of
	them); this limits the ability for the network stack to make use of		them); this limits the ability for the network stack to make use of
	features of other transport protocols. For example, if a protocol		features of other transport protocols. For example, if a protocol
	supports out-of-order message delivery but applications always assume		supports out-of-order message delivery but applications always assume
	that the network provides an ordered bytestream, then the network		that the network provides an ordered bytestream, then the network
	stack can not immediately deliver a message that arrives out-of-		stack can not immediately deliver a message that arrives out-of-
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	an implementation over UDP is possible, and "T,U:" if an		an implementation over UDP is possible, and "T,U:" if an
	implementation over either TCP or UDP is possible.		implementation over either TCP or UDP is possible.
	4.1. CONNECTION Related Transport Features		4.1. CONNECTION Related Transport Features
	ESTABLISHMENT:		ESTABLISHMENT:
	o T,U: Connect		o T,U: Connect
	o T,U: Specify number of attempts and/or timeout for the first		o T,U: Specify number of attempts and/or timeout for the first
	establishment message		establishment message
			o T,U: Disable MPTCP
	o T: Configure authentication		o T: Configure authentication
	o T: Hand over a message to reliably transfer (possibly multiple		o T: Hand over a message to reliably transfer (possibly multiple
	times) before connection establishment		times) before connection establishment
	o T: Hand over a message to reliably transfer during connection		o T: Hand over a message to reliably transfer during connection
	establishment		establishment
	AVAILABILITY:		AVAILABILITY:
	o T,U: Listen		o T,U: Listen
			o T,U: Disable MPTCP
	o T: Configure authentication		o T: Configure authentication
	MAINTENANCE:		MAINTENANCE:
	o T: Change timeout for aborting connection (using retransmit limit		o T: Change timeout for aborting connection (using retransmit limit
	or time value)		or time value)
	o T: Suggest timeout to the peer		o T: Suggest timeout to the peer
	o T,U: Disable Nagle algorithm		o T,U: Disable Nagle algorithm
	o T,U: Notification of Excessive Retransmissions (early warning		o T,U: Notification of Excessive Retransmissions (early warning
	below abortion threshold)		below abortion threshold)
	o T,U: Specify DSCP field		o T,U: Specify DSCP field
	o T,U: Notification of ICMP error message arrival		o T,U: Notification of ICMP error message arrival
	o T: Change authentication parameters		o T: Change authentication parameters
	o T: Obtain authentication information		o T: Obtain authentication information
	o T,U: Set Cookie life value		o T,U: Set Cookie life value
	o T,U: Choose a scheduler to operate between streams of an		o T,U: Choose a scheduler to operate between streams of an
	skipping to change at page 13, line 32 ¶		skipping to change at page 13, line 35 ¶
	always be authenticated -- if this is exposed as such, it creates an		always be authenticated -- if this is exposed as such, it creates an
	undesirable dependency on the transport protocol. For compatibility		undesirable dependency on the transport protocol. For compatibility
	with TCP, a transport system should only allow to configure complete		with TCP, a transport system should only allow to configure complete
	transport layer packets, including headers, IP pseudo-header (if any)		transport layer packets, including headers, IP pseudo-header (if any)
	and payload.		and payload.
	Security is discussed in a separate document		Security is discussed in a separate document
	[I-D.ietf-taps-transport-security]. The minimal set presented in the		[I-D.ietf-taps-transport-security]. The minimal set presented in the
	present document excludes all security related transport features		present document excludes all security related transport features
	from Appendix A: "Configure authentication", "Change authentication		from Appendix A: "Configure authentication", "Change authentication
	parameters", "Obtain authentication information" and and "Set Cookie		parameters", "Obtain authentication information" and "Set Cookie life
	life value" as well as "Specifying a key id to be used to		value" as well as "Specifying a key id to be used to authenticate a
	authenticate a message".		message". It also excludes security transport features not listed in
			Appendix A, including content privacy to in-path devices.
	5.7. Packet Size		5.7. Packet Size
	UDP(-Lite) has a transport feature called "Specify DF field". This		UDP(-Lite) has a transport feature called "Specify DF field". This
	yields an error message in case of sending a message that exceeds the		yields an error message in case of sending a message that exceeds the
	Path MTU, which is necessary for a UDP-based application to be able		Path MTU, which is necessary for a UDP-based application to be able
	to implement Path MTU Discovery (a function that UDP-based		to implement Path MTU Discovery (a function that UDP-based
	applications must do by themselves). The "Get max. transport-message		applications must do by themselves). The "Get max. transport-message
	size that may be sent using a non-fragmented IP packet from the		size that may be sent using a non-fragmented IP packet from the
	configured interface" transport feature yields an upper limit for the		configured interface" transport feature yields an upper limit for the
	skipping to change at page 14, line 39 ¶		skipping to change at page 14, line 39 ¶
	(Sending Data, Receiving Data, Errors). Here, the focus is on		(Sending Data, Receiving Data, Errors). Here, the focus is on
	connections that the transport system offers as an abstraction to the		connections that the transport system offers as an abstraction to the
	application, as opposed to connections of transport protocols that		application, as opposed to connections of transport protocols that
	the transport system uses.		the transport system uses.
	6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION		6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION
	A connection must first be "created" to allow for some initial		A connection must first be "created" to allow for some initial
	configuration to be carried out before the transport system can		configuration to be carried out before the transport system can
	actively or passively establish communication with a remote end		actively or passively establish communication with a remote end
	system. All configuration parameters in Section 6.2 can be used		system. As a configuration of the newly created connection, an
	initially, although some of them may only take effect when a		application can choose to disallow usage of MPTCP. Furthermore, all
	connection has been established with a chosen transport protocol.		configuration parameters in Section 6.2 can be used initially,
	Configuring a connection early helps a transport system make the		although some of them may only take effect when a connection has been
	right decisions. For example, grouping information can influence the		established with a chosen transport protocol. Configuring a
	transport system to implement a connection as a stream of a multi-		connection early helps a transport system make the right decisions.
	streaming protocol's existing association or not.		For example, grouping information can influence the transport system
			to implement a connection as a stream of a multi-streaming protocol's
			existing association or not.
	For ungrouped connections, early configuration is necessary because		For ungrouped connections, early configuration is necessary because
	it allows the transport system to know which protocols it should try		it allows the transport system to know which protocols it should try
	to use. In particular, a transport system that only makes a one-time		to use. In particular, a transport system that only makes a one-time
	choice for a particular protocol must know early about strict		choice for a particular protocol must know early about strict
	requirements that must be kept, or it can end up in a deadlock		requirements that must be kept, or it can end up in a deadlock
	situation (e.g., having chosen UDP and later be asked to support		situation (e.g., having chosen UDP and later be asked to support
	reliable transfer). As an example description of how to correctly		reliable transfer). As an example description of how to correctly
	handle these cases, we provide the following decision tree (this is		handle these cases, we provide the following decision tree (this is
	derived from Section 4.1 excluding authentication, as explained in		derived from Section 4.1 excluding authentication, as explained in
	skipping to change at page 23, line 24 ¶		skipping to change at page 23, line 24 ¶
	2007, <https://www.rfc-editor.org/info/rfc4895>.		2007, <https://www.rfc-editor.org/info/rfc4895>.
	[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common		[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
	Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,		Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
	<https://www.rfc-editor.org/info/rfc4987>.		<https://www.rfc-editor.org/info/rfc4987>.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,		Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <https://www.rfc-editor.org/info/rfc5925>.		June 2010, <https://www.rfc-editor.org/info/rfc5925>.
			[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
			Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
			March 2013, <https://www.rfc-editor.org/info/rfc6897>.
	[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet		[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
	Technology Adoption and Transition (ITAT)", RFC 7305,		Technology Adoption and Transition (ITAT)", RFC 7305,
	DOI 10.17487/RFC7305, July 2014,		DOI 10.17487/RFC7305, July 2014,
	<https://www.rfc-editor.org/info/rfc7305>.		<https://www.rfc-editor.org/info/rfc7305>.
	[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP		[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
	Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,		Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
	<https://www.rfc-editor.org/info/rfc7413>.		<https://www.rfc-editor.org/info/rfc7413>.
	[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,		[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
	skipping to change at page 24, line 51 ¶		skipping to change at page 25, line 7 ¶
	is exhibited to an application could be implemented by using a		is exhibited to an application could be implemented by using a
	single stream of an SCTP association instead of mapping it to a		single stream of an SCTP association instead of mapping it to a
	complete SCTP association or TCP connection. This could be		complete SCTP association or TCP connection. This could be
	achieved by using more than one stream when an SCTP association is		achieved by using more than one stream when an SCTP association is
	first established (CONNECT.SCTP parameter "outbound stream		first established (CONNECT.SCTP parameter "outbound stream
	count"), maintaining an internal stream number, and using this		count"), maintaining an internal stream number, and using this
	stream number when sending data (SEND.SCTP parameter "stream		stream number when sending data (SEND.SCTP parameter "stream
	number"). Closing or aborting a connection could then simply free		number"). Closing or aborting a connection could then simply free
	the stream number for future use. This is discussed further in		the stream number for future use. This is discussed further in
	Section 5.2.		Section 5.2.
	o All transport features that are related to using multiple paths or		o With the exception of "Disable MPTCP", all transport features that
	the choice of the network interface were designated as		are related to using multiple paths or the choice of the network
	"automatable". Choosing a path or an interface does not depend on		interface were designated as "automatable". For example, "Listen"
	application-specific knowledge. For example, "Listen" could		could always listen on all available interfaces and "Connect"
	always listen on all available interfaces and "Connect" could use		could use the default interface for the destination IP address.
	the default interface for the destination IP address.
	Finally, in three cases, transport features are aggregated and/or		Finally, in three cases, transport features are aggregated and/or
	slightly changed from [RFC8303] in the description below. These		slightly changed from [RFC8303] in the description below. These
	transport features are marked as "CHANGED FROM RFC8303". These do		transport features are marked as "CHANGED FROM RFC8303". These do
	not add any new functionality but just represent a simple refactoring		not add any new functionality but just represent a simple refactoring
	step that helps to streamline the derivation process (e.g., by		step that helps to streamline the derivation process (e.g., by
	removing a choice of a parameter for the sake of applications that		removing a choice of a parameter for the sake of applications that
	may not care about this choice). The corresponding transport		may not care about this choice). The corresponding transport
	features are automatable, and they are listed immediately below the		features are automatable, and they are listed immediately below the
	"CHANGED FROM RFC8303" transport feature.		"CHANGED FROM RFC8303" transport feature.
	skipping to change at page 26, line 21 ¶		skipping to change at page 26, line 25 ¶
	Protocols: TCP, SCTP		Protocols: TCP, SCTP
	Functional because this is closely related to potentially assumed		Functional because this is closely related to potentially assumed
	reliable data delivery for data that is sent before or during		reliable data delivery for data that is sent before or during
	connection establishment.		connection establishment.
	Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP.		Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP.
	Implementation over UDP: Do nothing (this is irrelevant in case of		Implementation over UDP: Do nothing (this is irrelevant in case of
	UDP because there, reliable data delivery is not assumed).		UDP because there, reliable data delivery is not assumed).
	o Obtain multiple sockets		o Obtain multiple sockets
	Protocols: SCTP		Protocols: SCTP
	Automatable because the usage of multiple paths to communicate to		Automatable because the non-parallel usage of multiple paths to
	the same end host relates to knowledge about the network, not the		communicate between the same end hosts relates to knowledge about
	application.		the network, not the application.
	o Disable MPTCP		o Disable MPTCP
	Protocols: MPTCP		Protocols: MPTCP
	Automatable because the usage of multiple paths to communicate to		Optimizing because the parallel usage of multiple paths to
	the same end host relates to knowledge about the network, not the		communicate between the same end hosts can improve performance.
	application.		Whether to use this feature depends on knowledge about the network
			as well as application-specific knowledge (see Section 3.1 of
			[RFC6897]).
	Implementation: via a boolean parameter in CONNECT.MPTCP.		Implementation: via a boolean parameter in CONNECT.MPTCP.
			Implementation over TCP: Do nothing.
			Implementation over UDP: Do nothing.
	o Configure authentication		o Configure authentication
	Protocols: TCP, SCTP		Protocols: TCP, SCTP
	Functional because this has a direct influence on security.		Functional because this has a direct influence on security.
	Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP.		Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP.
	With TCP, this allows to configure Master Key Tuples (MKTs) to		With TCP, this allows to configure Master Key Tuples (MKTs) to
	authenticate complete segments (including the TCP IPv4		authenticate complete segments (including the TCP IPv4
	pseudoheader, TCP header, and TCP data). With SCTP, this allows		pseudoheader, TCP header, and TCP data). With SCTP, this allows
	to specify which chunk types must always be authenticated.		to specify which chunk types must always be authenticated.
	Authenticating only certain chunk types creates a reduced level of		Authenticating only certain chunk types creates a reduced level of
	skipping to change at page 29, line 15 ¶		skipping to change at page 29, line 21 ¶
	knowledge about the network and the Operating System, not the		knowledge about the network and the Operating System, not the
	application.		application.
	o Specify which IP Options must always be used		o Specify which IP Options must always be used
	Protocols: TCP, UDP(-Lite)		Protocols: TCP, UDP(-Lite)
	Automatable because IP Options relate to knowledge about the		Automatable because IP Options relate to knowledge about the
	network, not the application.		network, not the application.
	o Disable MPTCP		o Disable MPTCP
	Protocols: MPTCP		Protocols: MPTCP
	Automatable because the usage of multiple paths to communicate to		Optimizing because the parallel usage of multiple paths to
	the same end host relates to knowledge about the network, not the		communicate between the same end hosts can improve performance.
	application.		Whether to use this feature depends on knowledge about the network
			as well as application-specific knowledge (see Section 3.1 of
			[RFC6897]).
			Implementation: via a boolean parameter in LISTEN.MPTCP.
			Implementation over TCP: Do nothing.
			Implementation over UDP: Do nothing.
	o Configure authentication		o Configure authentication
	Protocols: TCP, SCTP		Protocols: TCP, SCTP
	Functional because this has a direct influence on security.		Functional because this has a direct influence on security.
	Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP.		Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP.
	Implementation over TCP: With TCP, this allows to configure Master		Implementation over TCP: With TCP, this allows to configure Master
	Key Tuples (MKTs) to authenticate complete segments (including the		Key Tuples (MKTs) to authenticate complete segments (including the
	TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this		TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this
	allows to specify which chunk types must always be authenticated.		allows to specify which chunk types must always be authenticated.
	Authenticating only certain chunk types creates a reduced level of		Authenticating only certain chunk types creates a reduced level of
	skipping to change at page 31, line 31 ¶		skipping to change at page 31, line 39 ¶
	informing it of an impending functional event.		informing it of an impending functional event.
	Implementation: via ERROR.TCP.		Implementation: via ERROR.TCP.
	Implementation over UDP: do nothing (there is no abortion		Implementation over UDP: do nothing (there is no abortion
	threshold).		threshold).
	o Add path		o Add path
	Protocols: MPTCP, SCTP		Protocols: MPTCP, SCTP
	MPTCP Parameters: source-IP; source-Port; destination-IP;		MPTCP Parameters: source-IP; source-Port; destination-IP;
	destination-Port		destination-Port
	SCTP Parameters: local IP address		SCTP Parameters: local IP address
	Automatable because the usage of multiple paths to communicate to		Automatable because the choice of paths to communicate between the
	the same end host relates to knowledge about the network, not the		same end hosts relates to knowledge about the network, not the
	application.		application.
	o Remove path		o Remove path
	Protocols: MPTCP, SCTP		Protocols: MPTCP, SCTP
	MPTCP Parameters: source-IP; source-Port; destination-IP;		MPTCP Parameters: source-IP; source-Port; destination-IP;
	destination-Port		destination-Port
	SCTP Parameters: local IP address		SCTP Parameters: local IP address
	Automatable because the usage of multiple paths to communicate to		Automatable because the choice of paths to communicate between the
	the same end host relates to knowledge about the network, not the		same end host relates to knowledge about the network, not the
	application.		application.
	o Set primary path		o Set primary path
	Protocols: SCTP		Protocols: SCTP
	Automatable because the usage of multiple paths to communicate to		Automatable because the choice of paths to communicate between the
	the same end host relates to knowledge about the network, not the		same end hosts relates to knowledge about the network, not the
	application.		application.
	o Suggest primary path to the peer		o Suggest primary path to the peer
	Protocols: SCTP		Protocols: SCTP
	Automatable because the usage of multiple paths to communicate to		Automatable because the choice of paths to communicate between the
	the same end host relates to knowledge about the network, not the		same end hosts relates to knowledge about the network, not the
	application.		application.
	o Configure Path Switchover		o Configure Path Switchover
	Protocols: SCTP		Protocols: SCTP
	Automatable because the usage of multiple paths to communicate to		Automatable because the choice of paths to communicate between the
	the same end host relates to knowledge about the network, not the		same end hosts relates to knowledge about the network, not the
	application.		application.
	o Obtain status (query or notification)		o Obtain status (query or notification)
	Protocols: SCTP, MPTCP		Protocols: SCTP, MPTCP
	SCTP parameters: association connection state; destination		SCTP parameters: association connection state; destination
	transport address list; destination transport address reachability		transport address list; destination transport address reachability
	states; current local and peer receiver window size; current local		states; current local and peer receiver window size; current local
	congestion window sizes; number of unacknowledged DATA chunks;		congestion window sizes; number of unacknowledged DATA chunks;
	number of DATA chunks pending receipt; primary path; most recent		number of DATA chunks pending receipt; primary path; most recent
	SRTT on primary path; RTO on primary path; SRTT and RTO on other		SRTT on primary path; RTO on primary path; SRTT and RTO on other
	skipping to change at page 48, line 45 ¶		skipping to change at page 49, line 10 ¶
	WG -06: Fixed nits.		WG -06: Fixed nits.
	WG -07: Addressed Genart comments from Robert Sparks.		WG -07: Addressed Genart comments from Robert Sparks.
	WG -08: Addressed one more Genart comment from Robert Sparks.		WG -08: Addressed one more Genart comment from Robert Sparks.
	WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben		WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben
	Campbell, Benjamin Kaduk and Eric Rescorla.		Campbell, Benjamin Kaduk and Eric Rescorla.
			WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla.
	Authors' Addresses		Authors' Addresses
	Michael Welzl		Michael Welzl
	University of Oslo		University of Oslo
	PO Box 1080 Blindern		PO Box 1080 Blindern
	Oslo N-0316		Oslo N-0316
	Norway		Norway
	Phone: +47 22 85 24 20		Phone: +47 22 85 24 20
	Email: michawe@ifi.uio.no		Email: michawe@ifi.uio.no
	Stein Gjessing		Stein Gjessing
End of changes. 22 change blocks.
	40 lines changed or deleted		59 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/