draft-ietf-taps-minset-06.txt		draft-ietf-taps-minset-07.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: February 23, 2019 August 22, 2018		Expires: March 4, 2019 August 31, 2018
	A Minimal Set of Transport Services for End Systems		A Minimal Set of Transport Services for End Systems
	draft-ietf-taps-minset-06		draft-ietf-taps-minset-07
	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 February 23, 2019.		This Internet-Draft will expire on March 4, 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 17 ¶		skipping to change at page 2, line 17 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. The Minimal Set of Transport Features . . . . . . . . . . . . 5		3. The Minimal Set of Transport Features . . . . . . . . . . . . 5
	3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5		3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5
	3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8		3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8
	3.2.2. Individual connections . . . . . . . . . . . . . . . 10		3.2.2. Individual connections . . . . . . . . . . . . . . . 10
	3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10		3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10
	3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10		3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10
	3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11		3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11
	4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 14
	Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15
	A.1. Step 1: Categorization -- The Superset of Transport		A.1. Step 1: Categorization -- The Superset of Transport
	Features . . . . . . . . . . . . . . . . . . . . . . . . 15		Features . . . . . . . . . . . . . . . . . . . . . . . . 15
	A.1.1. CONNECTION Related Transport Features . . . . . . . . 17		A.1.1. CONNECTION Related Transport Features . . . . . . . . 17
	A.1.2. DATA Transfer Related Transport Features . . . . . . 33		A.1.2. DATA Transfer Related Transport Features . . . . . . 33
	A.2. Step 2: Reduction -- The Reduced Set of Transport		A.2. Step 2: Reduction -- The Reduced Set of Transport
	Features . . . . . . . . . . . . . . . . . . . . . . . . 39		Features . . . . . . . . . . . . . . . . . . . . . . . . 38
	A.2.1. CONNECTION Related Transport Features . . . . . . . . 40		A.2.1. CONNECTION Related Transport Features . . . . . . . . 39
	A.2.2. DATA Transfer Related Transport Features . . . . . . 41		A.2.2. DATA Transfer Related Transport Features . . . . . . 40
	A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41		A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41
	A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42		A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 41
	A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43		A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 42
	A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44		A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 43
	A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44		A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44
	A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 45		A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 44
	A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45		A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45
	A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46		A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 45
	Appendix B. Revision information . . . . . . . . . . . . . . . . 46		Appendix B. Revision information . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Introduction		1. Introduction
	The task of a transport system is to offer transport services to its		Currently, the set of transport services that most applications use
	applications, i.e. the applications running on top of the transport		is based on TCP and UDP (and protocols that are layered on top of
	system. Ideally, it does so without statically binding applications		them); this limits the ability for the network stack to make use of
	to particular transport protocols. Currently, the set of transport		features of other transport protocols. For example, if a protocol
	services that most applications use is based on TCP and UDP (and		supports out-of-order message delivery but applications always assume
	protocols that are layered on top of them); this limits the ability		that the network provides an ordered bytestream, then the network
	for the network stack to make use of features of other transport		stack can not immediately deliver a message that arrives out-of-
	protocols. For example, if a protocol supports out-of-order message		order: doing so would break a fundamental assumption of the
	delivery but applications always assume that the network provides an		application. The net result is unnecessary head-of-line blocking
	ordered bytestream, then the network stack can not immediately		delay.
	deliver a message that arrives out-of-order: doing so would break a
	fundamental assumption of the application. The net result is
	unnecessary head-of-line blocking delay.
	By exposing the transport services of multiple transport protocols, a		By exposing the transport services of multiple transport protocols, a
	transport system can make it possible to use these services without		transport system can make it possible for applications to use these
	having to statically bind an application to a specific transport		services without being statically bound to a specific transport
	protocol. The first step towards the design of such a system was		protocol. The first step towards the design of such a system was
	taken by [RFC8095], which surveys a large number of transports, and		taken by [RFC8095], which surveys a large number of transports, and
	[RFC8303] as well as [RFC8304], which identify the specific transport		[RFC8303] as well as [RFC8304], which identify the specific transport
	features that are exposed to applications by the protocols TCP,		features that are exposed to applications by the protocols TCP,
	MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control		MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control
	mechanism. This memo is based on these documents and follows the		mechanism. This memo is based on these documents and follows the
	same terminology (also listed below). Because the considered		same terminology (also listed below). Because the considered
	transport protocols conjointly cover a wide range of transport		transport protocols conjointly cover a wide range of transport
	features, there is reason to hope that the resulting set (and the		features, there is reason to hope that the resulting set (and the
	reasoning that led to it) will also apply to many aspects of other		reasoning that led to it) will also apply to many aspects of other
	transport protocols that may be in use today, or may be designed in		transport protocols that may be in use today, or may be designed in
	the future.		the future.
	The number of transport features of current IETF transports is large,		By decoupling applications from transport protocols, a transport
	and exposing all of them has a number of disadvantages: generally,		system provides a different abstraction level than the Berkeley
	the more functionality is exposed, the less freedom a transport		sockets interface. As with high- vs. low-level programming
	system has to automate usage of the various functions of its		languages, a higher abstraction level allows more freedom for
	available set of transport protocols. Some functions only exist in		automation below the interface, yet it takes some control away from
	one particular protocol, and if an application used them, this would		the application programmer. This is the design trade-off that a
	statically tie the application to this protocol, limiting the		transport system developer is facing, and this document provides
	flexibility of the transport system. Also, if the number of exposed		guidance on the design of this abstraction level. Some transport
	features is exceedingly large, a transport system might become very		features are currently rarely offered by APIs, yet they must be
	difficult to use for an application programmer. Taking [RFC8303] as		offered or they can never be used. Other transport features are
	a basis, this document therefore develops a minimal set of transport		offered by the APIs of the protocols covered here, but not exposing
	features, removing the ones that could get in the way of transport		them in an API would allow for more freedom to automate protocol
	flexibility but keeping the ones that must be retained for		usage in a transport system. The minimal set presented in this
	applications to benefit from useful transport functionality.		document is an effort to find a middle ground that can be recommended
			for transport systems to implement, on the basis of the transport
			features discussed in [RFC8303].
	Applications use a wide variety of APIs today. The transport		Applications use a wide variety of APIs today. The transport
	features in the minimal set in this document must be reflected in		features in the minimal set in this document must be reflected in
	*all* network APIs in order for the underlying functionality to		*all* network APIs in order for the underlying functionality to
	become usable everywhere. For example, it does not help an		become usable everywhere. For example, it does not help an
	application that talks to a library which offers its own		application that talks to a library which offers its own
	communication interface if the underlying Berkeley Sockets API is		communication interface if the underlying Berkeley Sockets API is
	extended to offer "unordered message delivery", but the library only		extended to offer "unordered message delivery", but the library only
	exposes an ordered bytestream. Both the Berkeley Sockets API and the		exposes an ordered bytestream. Both the Berkeley Sockets API and the
	library would have to expose the "unordered message delivery"		library would have to expose the "unordered message delivery"
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 6 ¶
	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 Appendix A.2.1 excluding authentication, as explained in		derived from Appendix A.2.1 excluding authentication, as explained in
	Section 7):		Section 6):
	- Will it ever be necessary to offer any of the following?		- Will it ever be necessary to offer any of the following?
	* Reliably transfer data		* Reliably transfer data
	* Notify the peer of closing/aborting		* Notify the peer of closing/aborting
	* Preserve data ordering		* Preserve data ordering
	Yes: SCTP or TCP can be used.		Yes: SCTP or TCP can be used.
	- Is any of the following useful to the application?		- Is any of the following useful to the application?
	* Choosing a scheduler to operate between connections		* Choosing a scheduler to operate between connections
	in a group, with the possibility to configure a priority		in a group, with the possibility to configure a priority
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 10 ¶
	implemented to directly use TCP).		implemented to directly use TCP).
	Different from TCP's semantics, if the sending application has		Different from TCP's semantics, if the sending application has
	allowed that messages are not fully reliably transferred, or		allowed that messages are not fully reliably transferred, or
	delivered out of order, then such re-ordering or unreliability may be		delivered out of order, then such re-ordering or unreliability may be
	reflected per message in the arriving data. Messages will always		reflected per message in the arriving data. Messages will always
	stay intact - i.e. if an incomplete message is contained at the end		stay intact - i.e. if an incomplete message is contained at the end
	of the arriving data block, this message is guaranteed to continue in		of the arriving data block, this message is guaranteed to continue in
	the next arriving data block.		the next arriving data block.
	4. Conclusion		4. Acknowledgements
	By decoupling applications from transport protocols, a transport
	system provides a different abstraction level than the Berkeley
	sockets interface. As with high- vs. low-level programming
	languages, a higher abstraction level allows more freedom for
	automation below the interface, yet it takes some control away from
	the application programmer. This is the design trade-off that a
	transport system developer is facing, and this document provides
	guidance on the design of this abstraction level. Some transport
	features are currently rarely offered by APIs, yet they must be
	offered or they can never be used ("functional" transport features).
	Other transport features are offered by the APIs of the protocols
	covered here, but not exposing them in an API would allow for more
	freedom to automate protocol usage in a transport system. The
	minimal set presented in this document is an effort to find a middle
	ground that can be recommended for transport systems to implement, on
	the basis of the transport features discussed in [RFC8303].
	5. Acknowledgements
	The authors would like to thank all the participants of the TAPS		The authors would like to thank all the participants of the TAPS
	Working Group and the NEAT and MAMI research projects for valuable		Working Group and the NEAT and MAMI research projects for valuable
	input to this document. We especially thank Michael Tuexen for help		input to this document. We especially thank Michael Tuexen for help
	with connection connection establishment/teardown and Gorry Fairhurst		with connection connection establishment/teardown, Gorry Fairhurst
	for his suggestions regarding fragmentation and packet sizes, and		for his suggestions regarding fragmentation and packet sizes, and
	Spencer Dawkins for his extremely detailed and constructive review.		Spencer Dawkins for his extremely detailed and constructive review.
	This work has received funding from the European Union's Horizon 2020		This work has received funding from the European Union's Horizon 2020
	research and innovation programme under grant agreement No. 644334		research and innovation programme under grant agreement No. 644334
	(NEAT).		(NEAT).
	6. IANA Considerations		5. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	7. Security Considerations		6. Security Considerations
	Authentication, confidentiality protection, and integrity protection		Authentication, confidentiality protection, and integrity protection
	are identified as transport features by [RFC8095]. As currently		are identified as transport features by [RFC8095]. As currently
	deployed in the Internet, these features are generally provided by a		deployed in the Internet, these features are generally provided by a
	protocol or layer on top of the transport protocol; no current full-		protocol or layer on top of the transport protocol; no current full-
	featured standards-track transport protocol provides all of these		featured standards-track transport protocol provides all of these
	transport features on its own. Therefore, these transport features		transport features on its own. Therefore, these transport features
	are not considered in this document, with the exception of native		are not considered in this document, with the exception of native
	authentication capabilities of TCP and SCTP for which the security		authentication capabilities of TCP and SCTP for which the security
	considerations in [RFC5925] and [RFC4895] apply. The minimum		considerations in [RFC5925] and [RFC4895] apply. The minimum
	requirements for a secure transport system are discussed in a		requirements for a secure transport system are discussed in a
	separate document (Section 5 on Security Features and Transport		separate document (Section 5 on Security Features and Transport
	Dependencies of [I-D.ietf-taps-transport-security]).		Dependencies of [I-D.ietf-taps-transport-security]).
	8. References		7. References
	8.1. Normative References		7.1. Normative References
			[I-D.ietf-taps-transport-security]
			Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
			of Transport Security Protocols", draft-ietf-taps-
			transport-security-02 (work in progress), June 2018.
			[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
			Ed., "Services Provided by IETF Transport Protocols and
			Congestion Control Mechanisms", RFC 8095,
			DOI 10.17487/RFC8095, March 2017,
			<https://www.rfc-editor.org/info/rfc8095>.
	[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of		[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
	Transport Features Provided by IETF Transport Protocols",		Transport Features Provided by IETF Transport Protocols",
	RFC 8303, DOI 10.17487/RFC8303, February 2018,		RFC 8303, DOI 10.17487/RFC8303, February 2018,
	<https://www.rfc-editor.org/info/rfc8303>.		<https://www.rfc-editor.org/info/rfc8303>.
	8.2. Informative References		7.2. Informative References
	[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte		[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte
	Stuffing", September 1997,		Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No.
	<http://stuartcheshire.org/papers/COBSforToN.pdf>.		2, April 1999.
	[I-D.ietf-taps-transport-security]
	Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
	of Transport Security Protocols", draft-ietf-taps-
	transport-security-01 (work in progress), May 2018.
	[I-D.ietf-tsvwg-rtcweb-qos]		[I-D.ietf-tsvwg-rtcweb-qos]
	Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP		Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
	Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-		Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
	qos-18 (work in progress), August 2016.		qos-18 (work in progress), August 2016.
	[LBE-draft]		[LBE-draft]
	Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",		Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
	Internet-draft draft-tsvwg-le-phb-03, February 2018.		Internet-draft draft-tsvwg-le-phb-03, February 2018.
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 20 ¶
	[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,
	"Additional Policies for the Partially Reliable Stream		"Additional Policies for the Partially Reliable Stream
	Control Transmission Protocol Extension", RFC 7496,		Control Transmission Protocol Extension", RFC 7496,
	DOI 10.17487/RFC7496, April 2015,		DOI 10.17487/RFC7496, April 2015,
	<https://www.rfc-editor.org/info/rfc7496>.		<https://www.rfc-editor.org/info/rfc7496>.
	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
	Ed., "Services Provided by IETF Transport Protocols and
	Congestion Control Mechanisms", RFC 8095,
	DOI 10.17487/RFC8095, March 2017,
	<https://www.rfc-editor.org/info/rfc8095>.
	[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,		[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
	"Stream Schedulers and User Message Interleaving for the		"Stream Schedulers and User Message Interleaving for the
	Stream Control Transmission Protocol", RFC 8260,		Stream Control Transmission Protocol", RFC 8260,
	DOI 10.17487/RFC8260, November 2017,		DOI 10.17487/RFC8260, November 2017,
	<https://www.rfc-editor.org/info/rfc8260>.		<https://www.rfc-editor.org/info/rfc8260>.
	[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the		[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
	User Datagram Protocol (UDP) and Lightweight UDP (UDP-		User Datagram Protocol (UDP) and Lightweight UDP (UDP-
	Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,		Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
	<https://www.rfc-editor.org/info/rfc8304>.		<https://www.rfc-editor.org/info/rfc8304>.
	skipping to change at page 47, line 46 ¶		skipping to change at page 47, line 28 ¶
	that referred to it.		that referred to it.
	WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As		WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As
	part of that, removed "TAPS" as a term everywhere (abstract, intro,		part of that, removed "TAPS" as a term everywhere (abstract, intro,
	..).		..).
	WG -05: addressed comments from Spencer Dawkins.		WG -05: addressed comments from Spencer Dawkins.
	WG -06: Fixed nits.		WG -06: Fixed nits.
			WG -07: Addressed Genart comments from Robert Sparks.
	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. 23 change blocks.
	88 lines changed or deleted		70 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/