draft-ietf-taps-arch-01.txt		draft-ietf-taps-arch-02.txt
	TAPS Working Group T. Pauly, Ed.		TAPS Working Group T. Pauly, Ed.
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Informational B. Trammell, Ed.		Intended status: Standards Track B. Trammell, Ed.
	Expires: January 2, 2019 ETH Zurich		Expires: April 25, 2019 ETH Zurich
	A. Brunstrom		A. Brunstrom
	Karlstad University		Karlstad University
	G. Fairhurst		G. Fairhurst
	University of Aberdeen		University of Aberdeen
	C. Perkins		C. Perkins
	University of Glasgow		University of Glasgow
	P. Tiesel		P. Tiesel
	TU Berlin		TU Berlin
	C. Wood		C. Wood
	Apple Inc.		Apple Inc.
	July 01, 2018		October 22, 2018
	An Architecture for Transport Services		An Architecture for Transport Services
	draft-ietf-taps-arch-01		draft-ietf-taps-arch-02
	Abstract		Abstract
	This document provides an overview of the architecture of Transport		This document provides an overview of the architecture of Transport
	Services, a system for exposing the features of transport protocols		Services, a system for exposing the features of transport protocols
	to applications. This architecture serves as a basis for Application		to applications. This architecture serves as a basis for Application
	Programming Interfaces (APIs) and implementations that provide		Programming Interfaces (APIs) and implementations that provide
	flexible transport networking services. It defines the common set of		flexible transport networking services. It defines the common set of
	terminology and concepts to be used in more detailed discussion of		terminology and concepts to be used in more detailed discussion of
	Transport Services.		Transport Services.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 January 2, 2019.		This Internet-Draft will expire on April 25, 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Event-Driven API . . . . . . . . . . . . . . . . . . . . 5
	3.1. Common APIs for Common Features . . . . . . . . . . . . . 4		1.3. Data Transfer Using Messages . . . . . . . . . . . . . . 5
	3.2. Access to Specialized Features . . . . . . . . . . . . . 4		1.4. Flexibile Implementation . . . . . . . . . . . . . . . . 6
	3.3. Scope for API and Implementation Definitions . . . . . . 5		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Transport Services Architecture and Concepts . . . . . . . . 6		3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Transport Services API Concepts . . . . . . . . . . . . . 7		3.1. Common APIs for Common Features . . . . . . . . . . . . . 7
	4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 9		3.2. Access to Specialized Features . . . . . . . . . . . . . 7
	4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 10		3.3. Scope for API and Implementation Definitions . . . . . . 8
	4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 11		4. Transport Services Architecture and Concepts . . . . . . . . 9
	4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 11		4.1. Transport Services API Concepts . . . . . . . . . . . . . 10
	4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 12		4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 12
	4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 13		4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 13
	4.2. Transport System Implementation Concepts . . . . . . . . 13		4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 14
	4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 14		4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 14
	4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 14		4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 15
	4.3. Protocol Stack Equivalence . . . . . . . . . . . . . . . 15		4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 16
	4.3.1. Transport Security Equivalence . . . . . . . . . . . 16		4.2. Transport System Implementation Concepts . . . . . . . . 16
	4.4. Message Framing, Parsing, and Serialization . . . . . . . 16		4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 17
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		4.3. Protocol Stack Equivalence . . . . . . . . . . . . . . . 18
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		4.3.1. Transport Security Equivalence . . . . . . . . . . . 19
	8. Informative References . . . . . . . . . . . . . . . . . . . 18		4.4. Message Framing, Parsing, and Serialization . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
			7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
			8. Informative References . . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Many APIs to perform transport networking have been deployed, perhaps		Many application programming interfaces (APIs) to perform transport
	the most widely known and imitated being the BSD socket() [POSIX]		networking have been deployed, perhaps the most widely known and
	interface. The names and functions between these APIs are not		imitated being the BSD socket() [POSIX] interface. The names and
	consistent, and vary depending on the protocol being used. For		functions between these APIs are not consistent, and vary depending
	example, sending and receiving on a stream of data is conceptually		on the protocol being used. For example, sending and receiving on a
	the same between operating on an unencrypted Transmission Control		stream of data is conceptually the same between operating on an
	Protocol (TCP) stream and operating on an encrypted Transport Layer		unencrypted Transmission Control Protocol (TCP) stream and operating
	Security (TLS) [I-D.ietf-tls-tls13] stream over TCP, but applications		on an encrypted Transport Layer Security (TLS) [I-D.ietf-tls-tls13]
	cannot use the same socket send() and recv() calls on top of both		stream over TCP, but applications cannot use the same socket send()
	kinds of connections. Similarly, terminology for the implementation		and recv() calls on top of both kinds of connections. Similarly,
	of protocols offering transport services vary based on the context of		terminology for the implementation of protocols offering transport
	the protocols themselves. This variety can lead to confusion when		services vary based on the context of the protocols themselves. This
	trying to understand the similarities and differences between		variety can lead to confusion when trying to understand the
	protocols, and how applications can use them effectively.		similarities and differences between protocols, and how applications
			can use them effectively.
	The goal of the Transport Services architecture is to provide a		The goal of the Transport Services architecture is to provide a
	common, flexible, and reusable interface for transport protocols. As		common, flexible, and reusable interface for transport protocols. As
	applications adopt this interface, they will benefit from a wide set		applications adopt this interface, they will benefit from a wide set
	of transport features that can evolve over time, and ensure that the		of transport features that can evolve over time, and ensure that the
	system providing the interface can optimize its behavior based on the		system providing the interface can optimize its behavior based on the
	application requirements and network conditions.		application requirements and network conditions.
	This document is developed in parallel with the specification of the		This document is developed in parallel with the specification of the
	Transport Services API [I-D.ietf-taps-interface] and Implementation		Transport Services API [I-D.ietf-taps-interface] and Implementation
	[I-D.ietf-taps-impl] documents.		[I-D.ietf-taps-impl] documents.
			1.1. Overview
			The model for using sockets for networking can be represented as
			follows: applications create connections and transfer data using the
			socket API, which provides the interface to the implementations of
			UDP and TCP (typically implemented in the system's kernel), which in
			turn send data over the available network layer interfaces.
			+-----------------------------------------------------+
			| Application |
			+-----------------------------------------------------+
			| |
			+---------------------+ +-----------------------+
			| Socket Stream API | | Socket Datagram API |
			+---------------------+ +-----------------------+
			| |
			+-----------------------------------------------------+
			| TCP UDP |
			| Kernel Protocol Implementation |
			+-----------------------------------------------------+
			|
			+-----------------------------------------------------+
			| Network Layer Interface |
			+-----------------------------------------------------+
			The Transport Services architecture maintains this general model of
			interaction, but aims to both modernize the API surface exposed for
			transport protocols and enrich the capabilities of the transport
			system implementation.
			+-----------------------------------------------------+
			| Application |
			+-----------------------------------------------------+
			|
			+-----------------------------------------------------+
			| Transport Services API |
			+-----------------------------------------------------+
			|
			+-----------------------------------------------------+
			| Transport System Implementation |
			| (UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) |
			+-----------------------------------------------------+
			|
			+-----------------------------------------------------+
			| Network Layer Interface |
			+-----------------------------------------------------+
			The Transport Services API [I-D.ietf-taps-interface] defines the
			mechanism for an application to create and monitor network
			connections, and transfer data. The Implementation
			[I-D.ietf-taps-impl] is responsible for mapping the API into the
			various available transport protocols and managing the available
			network interfaces and paths.
			There are a few key departures that Transport Services makes from the
			sockets API: it presents an asynchronous, event-driven API; it uses
			messages for respresenting data transfer to applications; and it
			assumes an implementation that can use multiple IP addresses,
			multiple protocols, multiple paths, and provide multiple application
			streams.
			1.2. Event-Driven API
			Originally, sockets presented a blocking interface for establishing
			connections and transferring data. However, most modern applications
			interact with the network asynchronously. When sockets are presented
			as an asynchronous interface, they generally use a try-and-fail
			model. If the application wants to read, but data has not yet been
			received from the peer, the call to read will fail. The application
			then waits for a notification that it should try again.
			All interaction with a Transport Services system is expected to be
			asynchronous, and use an event-driven model unlike sockets
			Section 4.1.5. For example, if the application wants to read, its
			call to read will not fail, but will deliver an event containing the
			received data once it is available.
			The Transport Services API also delivers events regarding the
			lifetime of a connection and changes to available network links,
			which were not previously made explicit in sockets.
			Using asynchronous events allows for a much simpler interaction model
			when establishing connections and transferring data. Events in time
			more closely reflect the nature of interactions over networks, as
			opposed to how sockets represent network resources as file system
			objects that may be temporarily unavailable.
			1.3. Data Transfer Using Messages
			Sockets provide a message interface for datagram protocols like UDP,
			but provide an unstructured stream abstraction for TCP. While TCP
			does indeed provide the ability to send and receive data as streams,
			most applications need to interpret structure within these streams.
			HTTP/1.1 uses character delimiters to segment messages over a stream;
			TLS record headers carry a version, content type, and length; and
			HTTP/2 uses frames to segment its headers and bodies.
			In order to more closely match the way applications use the network,
			the Transport Services API respresents data as messages. Messages
			seamlessly work with transport protocols that support datagrams or
			records, but can also be used over a stream by defining the
			application-layer framing being used Section 4.4.
			1.4. Flexibile Implementation
			Sockets, for protocols like TCP, are generally limited to connecting
			to a single address over a single interface. They also present a
			single stream to the application. Software layers built upon sockets
			often propagate this limitation of a single-address single-stream
			model. The Transport Services architecture is designed to handle
			multiple candidate endpoints, protocols, and paths; and support
			multipath and multistreaming protocols.
			Transport Services implementations are meant to be flexible at
			connection establishment time, considering many different options and
			trying to select the most optimal combinations (Section 4.2.1 and
			Section 4.2.2). This requires applications to provide higher-level
			endpoints than IP addresses, such as hostnames and URLs, which are
			used by a Transport Services implementation for resolution, path
			selection, and racing.
			Flexibility after connection establishment is also important.
			Transport protocols that can migrate between multiple network layer
			interfaces need to be able to process and react to interface changes.
			Protocols that support multiple application-layer streams need to
			support initiating and receiving new streams using existing
			connections.
	2. Background		2. Background
	The Transport Services architecture is based on the survey of		The Transport Services architecture is based on the survey of
	Services Provided by IETF Transport Protocols and Congestion Control		Services Provided by IETF Transport Protocols and Congestion Control
	Mechanisms [RFC8095], and the distilled minimal set of the features		Mechanisms [RFC8095], and the distilled minimal set of the features
	offered by transport protocols [I-D.ietf-taps-minset]. This work has		offered by transport protocols [I-D.ietf-taps-minset]. This work has
	identified common features and patterns across all transport		identified common features and patterns across all transport
	protocols developed thus far in the IETF.		protocols developed thus far in the IETF.
	Since transport security is an increasingly relevant aspect of using		Since transport security is an increasingly relevant aspect of using
	skipping to change at page 4, line 22 ¶		skipping to change at page 7, line 24 ¶
	interface between applications and transports in a way that allows		interface between applications and transports in a way that allows
	the transport layer to evolve and improve without fundamentally		the transport layer to evolve and improve without fundamentally
	changing the contract with the application. This requires a careful		changing the contract with the application. This requires a careful
	consideration of how to expose the capabilities of protocols.		consideration of how to expose the capabilities of protocols.
	There are several degrees in which a Transport Services system can		There are several degrees in which a Transport Services system can
	offer flexibility to an application: it can provide access to		offer flexibility to an application: it can provide access to
	multiple sets of protocols and protocol features, it can use these		multiple sets of protocols and protocol features, it can use these
	protocols across multiple paths that may have different performance		protocols across multiple paths that may have different performance
	and functional characteristics, and it can communicate with different		and functional characteristics, and it can communicate with different
	Remote Endpoints to optimize performance. Beyond these, if the API		Remote Endpoints to optimize performance, robustness to failure, or
	for the system remains the same over time, new protocols and features		some other metric. Beyond these, if the API for the system remains
	may be added to the system's implementation without requiring changes		the same over time, new protocols and features may be added to the
	in applications for adoption.		system's implementation without requiring changes in applications for
			adoption.
	The following considerations were used in the design of this		The following considerations were used in the design of this
	architecture.		architecture.
	3.1. Common APIs for Common Features		3.1. Common APIs for Common Features
	Functionality that is common across multiple transport protocols		Functionality that is common across multiple transport protocols
	should be accessible through a unified set of API calls. An		should be accessible through a unified set of API calls. An
	application should be able to implement logic for its basic use of		application should be able to implement logic for its basic use of
	transport networking (establishing the transport, and sending and		transport networking (establishing the transport, and sending and
	receiving data) once, and expect that implementation to continue to		receiving data) once, and expect that implementation to continue to
	function as the transports change.		function as the transports change.
	Any Transport Services API must allow access to the distilled minimal		Any Transport Services API must allow access to the distilled minimal
	set of features offered by transport protocols		set of features offered by transport protocols
	[I-D.ietf-taps-minset].		[I-D.ietf-taps-minset].
	3.2. Access to Specialized Features		3.2. Access to Specialized Features
	Since applications will often need to control fine-grained details of		There are applications that will need to control fine-grained details
	transport protocols to optimize their behavior and ensure		of transport protocols to optimize their behavior and ensure
	compatibility with remote peers, a Transport Services system also		compatibility with remote peers,. A Transport Services system will
	needs to allow more specialized protocol features to be used. The		therefore also needs to allow more specialized protocol features to
	interface for these specialized options should be exposed differently		be used. The interface for these specialized options should be
	from the common options to ensure flexibility.		exposed differently from the common options to ensure flexibility.
	A specialized feature may be required by an application only when		A specialized feature could be required by an application only when
	using a specific protocol, and not when using others. For example,		using a specific protocol, and not when using others. For example,
	if an application is using UDP, it may require control over the		if an application is using UDP, it could require control over the
	checksum or fragmentation behavior for UDP; if it used a protocol to		checksum or fragmentation behavior for UDP; if it used a protocol to
	frame its data over a byte stream like TCP, it would not need these		frame its data over a byte stream like TCP, it would not need these
	options. In such cases, the API should expose the features in such a		options. In such cases, the API should expose the features in such a
	way that they take effect when a particular protocol is selected, but		way that they take effect when a particular protocol is selected, but
	do not imply that only that protocol may be used if there are		do not imply that only that protocol could be used if there are
	equivalent options.		equivalent options.
	Other specialized features, however, may be strictly required by an		Other specialized features, however, may be strictly required by an
	application and thus constrain the set of protocols that can be used.		application and thus constrain the set of protocols that can be used.
	For example, if an application requires encryption of its transport		For example, if an application requires encryption of its transport
	data, only protocol stacks that include some transport security		data, only protocol stacks that include some transport security
	protocol are eligible to be used. A Transport Services API must		protocol are eligible to be used. A Transport Services API must
	allow applications to define such requirements and constrain the		allow applications to define such requirements and constrain the
	system's options. Since such options are not part of the core/common		system's options. Since such options are not part of the core/common
	features, it should be simple for an application to modify its set of		features, it should be simple for an application to modify its set of
	skipping to change at page 5, line 45 ¶		skipping to change at page 8, line 47 ¶
	[I-D.ietf-taps-impl] will vary due to system-specific support and the		[I-D.ietf-taps-impl] will vary due to system-specific support and the
	needs of the deployment scenario. It is expected that all		needs of the deployment scenario. It is expected that all
	implementations of Transport Services will offer the entire mandatory		implementations of Transport Services will offer the entire mandatory
	API, but that some features will not be functional in certain		API, but that some features will not be functional in certain
	implementations. All implementations must offer sufficient APIs to		implementations. All implementations must offer sufficient APIs to
	use the distilled minimal set of features offered by transport		use the distilled minimal set of features offered by transport
	protocols [I-D.ietf-taps-minset], including API support for TCP and		protocols [I-D.ietf-taps-minset], including API support for TCP and
	UDP transport, but it is possible that some very constrained devices		UDP transport, but it is possible that some very constrained devices
	might not have, for example, a full TCP implementation.		might not have, for example, a full TCP implementation.
	In order to preserve flexibility and compatibility with future		To preserve flexibility and compatibility with future protocols, top-
	protocols, top-level features in the Transport Services API should		level features in the Transport Services API should avoid referencing
	avoid referencing particular transport protocols. Mappings of these		particular transport protocols. The mappings of these API features
	API features in the Implementation document, on the other hand, must		to specific implementations of each feature is explained in the
	explain the ramifications of each feature on existing protocols. It		[TAPS-IMPL], which also explain the implications of the feature
	is expected that the Implementation document will be updated and		provided by existing protocols. It is expected that this document
	supplemented as new protocols and protocol features are developed.		will be updated and supplemented as new protocols and protocol
			features are developed.
	It is important to note that neither the Transport Services API nor		It is important to note that neither the Transport Services API nor
	the Implementation document defines new protocols that require any		the Implementation document defines new protocols that require any
	changes on remote hosts. The Transport Services system must be		changes to a remote host. The Transport Services system must be
	deployable on one side only, as a way to allow an application to make		deployable on one side only, as a way to allow an application to make
	better use of available capabilities on a system and protocol		better use of available capabilities on a system and protocol
	features that may be supported by peers across the network.		features that may be supported by peers across the network.
	4. Transport Services Architecture and Concepts		4. Transport Services Architecture and Concepts
	The concepts defined in this document are intended primarily for use		The concepts defined in this document are intended primarily for use
	in the documents and specifications that describe the Transport		in the documents and specifications that describe the Transport
	Services architecture and API. While the specific terminology may be		Services architecture and API. While the specific terminology may be
	used in some implementations, it is expected that there will remain a		used in some implementations, it is expected that there will remain a
	skipping to change at page 18, line 36 ¶		skipping to change at page 21, line 36 ¶
	Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric		Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric
	Kinnear for their implementation and design efforts, including Happy		Kinnear for their implementation and design efforts, including Happy
	Eyeballs, that heavily influenced this work.		Eyeballs, that heavily influenced this work.
	8. Informative References		8. Informative References
	[I-D.ietf-taps-impl]		[I-D.ietf-taps-impl]
	Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,		Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
	Jones, T., Tiesel, P., Perkins, C., and M. Welzl,		Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
	"Implementing Interfaces to Transport Services", draft-		"Implementing Interfaces to Transport Services", draft-
	ietf-taps-impl-00 (work in progress), May 2018.		ietf-taps-impl-01 (work in progress), July 2018.
	[I-D.ietf-taps-interface]		[I-D.ietf-taps-interface]
	Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,		Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
	Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An		Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
	Abstract Application Layer Interface to Transport		Abstract Application Layer Interface to Transport
	Services", draft-ietf-taps-interface-00 (work in		Services", draft-ietf-taps-interface-01 (work in
	progress), April 2018.		progress), July 2018.
	[I-D.ietf-taps-minset]		[I-D.ietf-taps-minset]
	Welzl, M. and S. Gjessing, "A Minimal Set of Transport		Welzl, M. and S. Gjessing, "A Minimal Set of Transport
	Services for End Systems", draft-ietf-taps-minset-04 (work		Services for End Systems", draft-ietf-taps-minset-11 (work
	in progress), June 2018.		in progress), September 2018.
	[I-D.ietf-taps-transport-security]		[I-D.ietf-taps-transport-security]
	Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey		Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
	of Transport Security Protocols", draft-ietf-taps-		of Transport Security Protocols", draft-ietf-taps-
	transport-security-02 (work in progress), June 2018.		transport-security-02 (work in progress), June 2018.
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),		Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
	March 2018.		March 2018.
	skipping to change at page 19, line 43 ¶		skipping to change at page 22, line 43 ¶
	[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>.
	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,		[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
	Ed., "Services Provided by IETF Transport Protocols and		Ed., "Services Provided by IETF Transport Protocols and
	Congestion Control Mechanisms", RFC 8095,		Congestion Control Mechanisms", RFC 8095,
	DOI 10.17487/RFC8095, March 2017,		DOI 10.17487/RFC8095, March 2017,
	<https://www.rfc-editor.org/info/rfc8095>.		<https://www.rfc-editor.org/info/rfc8095>.
			[TAPS-IMPL]
			Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
			Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
			"Implementing Interfaces to Transport Services", draft-
			ietf-taps-impl-01 (work in progress), July 2018.
	Authors' Addresses		Authors' Addresses
	Tommy Pauly (editor)		Tommy Pauly (editor)
	Apple Inc.		Apple Inc.
	One Apple Park Way		One Apple Park Way
	Cupertino, California 95014		Cupertino, California 95014
	United States of America		United States of America
	Email: tpauly@apple.com		Email: tpauly@apple.com
	Brian Trammell (editor)		Brian Trammell (editor)
	ETH Zurich		ETH Zurich
	Gloriastrasse 35		Gloriastrasse 35
	8092 Zurich		8092 Zurich
	Switzerland		Switzerland
	Email: ietf@trammell.ch		Email: ietf@trammell.ch
	Anna Brunstrom		Anna Brunstrom
	Karlstad University		Karlstad University
End of changes. 19 change blocks.
	70 lines changed or deleted		212 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/