draft-ietf-taps-arch-08.txt   draft-ietf-taps-arch-09.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: 14 January 2021 Google Switzerland GmbH Expires: 6 May 2021 Google Switzerland GmbH
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.A. Wood C.A. Wood
Cloudflare Cloudflare
13 July 2020 2 November 2020
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-08 draft-ietf-taps-arch-09
Abstract Abstract
This document describes an architecture for exposing transport This document describes an architecture for exposing transport
protocol features to applications for network communication, the protocol features to applications for network communication, the
Transport Services architecture. The Transport Services Application Transport Services architecture. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. It uses messages for representing data transfer interaction pattern. It uses messages for representing data transfer
to applications, and it describes how implementations can use to applications, and it describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and multiple IP addresses, multiple protocols, and multiple paths, and
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 14 January 2021. This Internet-Draft will expire on 6 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7
2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7
2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8
3. API and Implementation Requirements . . . . . . . . . . . . . 9 3. API and Implementation Requirements . . . . . . . . . . . . . 9
3.1. Provide Common APIs for Common Features . . . . . . . . . 9 3.1. Provide Common APIs for Common Features . . . . . . . . . 9
3.2. Allow Access to Specialized Features . . . . . . . . . . 10 3.2. Allow Access to Specialized Features . . . . . . . . . . 10
3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11
3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12
4. Transport Services Architecture and Concepts . . . . . . . . 12 4. Transport Services Architecture and Concepts . . . . . . . . 12
4.1. Transport Services API Concepts . . . . . . . . . . . . . 13 4.1. Transport Services API Concepts . . . . . . . . . . . . . 13
4.1.1. Connections and Related Objects . . . . . . . . . . . 15 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 15
4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 16 4.1.2. Connections and Related Objects . . . . . . . . . . . 15
4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 17 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 16
4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 18 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 17
4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 19 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 18
4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 20 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 19
4.1.7. Connection Groups . . . . . . . . . . . . . . . . . . 20 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 20
4.2. Transport Services Implementation Concepts . . . . . . . 20 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 20
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 21 4.2. Transport Services Implementation Concepts . . . . . . . 21
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 22
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22
4.2.3. Separating Connection Groups . . . . . . . . . . . . 22 4.2.3. Separating Connection Groups . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Many application programming interfaces (APIs) to perform transport Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and networking have been deployed, perhaps the most widely known and
imitated being the BSD Socket [POSIX] interface (Socket API). The imitated being the BSD Socket [POSIX] interface (Socket API). The
naming of objects and functions across these APIs is not consistent, naming of objects and functions across these APIs is not consistent,
and varies depending on the protocol being used. For example, and varies depending on the protocol being used. For example,
sending and receiving streams of data is conceptually the same for sending and receiving streams of data is conceptually the same for
both an unencrypted Transmission Control Protocol (TCP) stream and both an unencrypted Transmission Control Protocol (TCP) stream and
skipping to change at page 4, line 10 skipping to change at page 4, line 10
Services Architecture does not require that all APIs and Services Architecture does not require that all APIs and
implementations are identical, a common minimal set of features implementations are identical, a common minimal set of features
represented in a consistent fashion will enable applications to be represented in a consistent fashion will enable applications to be
easily ported from one system to another. easily ported from one system to another.
1.1. Background 1.1. 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]. These offered by transport protocols [RFC8923]. These documents identified
documents identified common features and patterns across all common features and patterns across all transport protocols developed
transport protocols developed thus far in the IETF. 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
transport protocols on the Internet, this architecture also considers transport protocols on the Internet, this architecture also considers
the impact of transport security protocols on the feature-set exposed the impact of transport security protocols on the feature-set exposed
by Transport Services [I-D.ietf-taps-transport-security]. by Transport Services [RFC8922].
One of the key insights to come from identifying the minimal set of One of the key insights to come from identifying the minimal set of
features provided by transport protocols [I-D.ietf-taps-minset] was features provided by transport protocols [RFC8923] was that features
that features either require application interaction and guidance either require application interaction and guidance (referred to in
(referred to in that document as Functional or Optimizing Features), that document as Functional or Optimizing Features), or else can be
or else can be handled automatically by a system implementing handled automatically by a system implementing Transport Services
Transport Services (referred to as Automatable Features). Among the (referred to as Automatable Features). Among the identified
Functional and Optimizing Features, some were common across all or Functional and Optimizing Features, some were common across all or
nearly all transport protocols, while others could be seen as nearly all transport protocols, while others could be seen as
features that, if specified, would only be useful with a subset of features that, if specified, would only be useful with a subset of
protocols, but would not harm the functionality of other protocols. protocols, but would not harm the functionality of other protocols.
For example, some protocols can deliver messages faster for For example, some protocols can deliver messages faster for
applications that do not require messages to arrive in the order in applications that do not require messages to arrive in the order in
which they were sent. However, this functionality needs to be which they were sent. However, this functionality needs to be
explicitly allowed by the application, since reordering messages explicitly allowed by the application, since reordering messages
would be undesirable in many cases. would be undesirable in many cases.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
Originally, sockets presented a blocking interface for establishing Originally, sockets presented a blocking interface for establishing
connections and transferring data. However, most modern applications connections and transferring data. However, most modern applications
interact with the network asynchronously. Emulation of an interact with the network asynchronously. Emulation of an
asynchronous interface using sockets generally uses a try-and-fail asynchronous interface using sockets generally uses a try-and-fail
model. If the application wants to read, but data has not yet been 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 received from the peer, the call to read will fail. The application
then waits and can try again later. then waits and can try again later.
In contrast to sockets, all interaction with a Transport Services In contrast to sockets, all interaction with a Transport Services
system is expected to be asynchronous, and use an event-driven model system is expected to be asynchronous, and use an event-driven model
(see Section 4.1.5). For example, if the application wants to read, (see Section 4.1.6). For example, if the application wants to read,
its call to read will not complete immediately, but will deliver an its call to read will not complete immediately, but will deliver an
event containing the received data once it is available. Error event containing the received data once it is available. Error
handling is also asynchronous; a failure to send results in an handling is also asynchronous; a failure to send results in an
asynchronous send error as an event. asynchronous send error as an event.
The Transport Services API also delivers events regarding the The Transport Services API also delivers events regarding the
lifetime of a connection and changes in the available network links, lifetime of a connection and changes in the available network links,
which were not previously made explicit in sockets. which were not previously made explicit in sockets.
Using asynchronous events allows for a more natural interaction model Using asynchronous events allows for a more natural interaction model
skipping to change at page 8, line 23 skipping to change at page 8, line 23
Transport Services system could decide to not deliver a message, Transport Services system could decide to not deliver a message,
either following packet loss or because it has missed a deadline. either following packet loss or because it has missed a deadline.
In particular, this can avoid (re-)sending data that relies on a In particular, this can avoid (re-)sending data that relies on a
previous transmission that was never received. previous transmission that was never received.
* the ability to automatically assign messages and connections to * the ability to automatically assign messages and connections to
underlying transport connections to utilize multi-streaming and underlying transport connections to utilize multi-streaming and
pooled connections. pooled connections.
Allowing applications to interact with messages is backwards- Allowing applications to interact with messages is backwards-
compatible with existings protocols and APIs, as it does not change compatible with existing protocols and APIs because it does not
the wire format of any protocol. Instead, it gives the protocol change the wire format of any protocol. Instead, it gives the
stack additional information to allow it to make better use of modern protocol stack additional information to allow it to make better use
transport services, while simplifying the application's role in of modern transport services, while simplifying the application's
parsing data. For protocols which natively use a streaming role in parsing data. For protocols which natively use a streaming
abstraction, framers (Section 4.1.4) bridge the gap between the two abstraction, framers (Section 4.1.5) bridge the gap between the two
abstractions. abstractions.
2.3. Flexibile Implementation 2.3. Flexibile Implementation
Sockets, for protocols like TCP, are generally limited to connecting Sockets, for protocols like TCP, are generally limited to connecting
to a single address over a single interface. They also present a to a single address over a single interface. They also present a
single stream to the application. Software layers built upon sockets single stream to the application. Software layers built upon sockets
often propagate this limitation of a single-address single-stream often propagate this limitation of a single-address single-stream
model. The Transport Services architecture is designed to handle model. The Transport Services architecture is designed to handle
multiple candidate endpoints, protocols, and paths; and support multiple candidate endpoints, protocols, and paths; and support
skipping to change at page 9, line 32 skipping to change at page 9, line 32
access to multiple sets of protocols and protocol features; it can access to multiple sets of protocols and protocol features; it can
use these protocols across multiple paths that could have different use these protocols across multiple paths that could have different
performance and functional characteristics; and it can communicate performance and functional characteristics; and it can communicate
with different remote systems to optimize performance, robustness to with different remote systems to optimize performance, robustness to
failure, or some other metric. Beyond these, if the API for the failure, or some other metric. Beyond these, if the API for the
system remains the same over time, new protocols and features can be system remains the same over time, new protocols and features can be
added to the system's implementation without requiring changes in added to the system's implementation without requiring changes in
applications for adoption. applications for adoption.
The normative requirements described here allow Transport Services The normative requirements described here allow Transport Services
APIs and Implementations to provide this functionlity without causing APIs and Implementations to provide this functionality without
incompatibility or introducing security vulnerabilities. The rest of causing incompatibility or introducing security vulnerabilities. The
this document describes the architecture non-normatively. rest of this document describes the architecture non-normatively.
3.1. Provide Common APIs for Common Features 3.1. Provide Common APIs for Common Features
Any functionality that is common across multiple transport protocols Any functionality that is common across multiple transport protocols
SHOULD be made accessible through a unified set of Transport Services SHOULD be made accessible through a unified set of Transport Services
API calls. As a baseline, any Transport Services API MUST allow API calls. As a baseline, any Transport Services API MUST allow
access to the minimal set of features offered by transport protocols access to the minimal set of features offered by transport protocols
[I-D.ietf-taps-minset]. [RFC8923].
An application can specify constraints and preferences for the An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via protocols, features, and network interfaces it will use via
Properties. A Transport Services API SHOULD offer Properties that Properties. A Transport Services API SHOULD offer Properties that
are common to multiple transport protocols, in order to enable the are common to multiple transport protocols, which enables the system
system to appropriately select between protocols that offer to appropriately select between protocols that offer equivalent
equivalent features. Similarly, a Transport Services API SHOULD features. Similarly, a Transport Services API SHOULD offer
offer Properties that are applicable to a variety of network layer Properties that are applicable to a variety of network layer
interfaces and paths, in order to permit racing of different network interfaces and paths, which permits racing of different network paths
paths without affecting the applications using the system. Each without affecting the applications using the system. Each Property
Property is expected to have a default value. is expected to have a default value.
The default values for Properties SHOULD be selected to ensure The default values for Properties SHOULD be selected to ensure
correctness for the widest set of applications, while providing the correctness for the widest set of applications, while providing the
widest set of options for selection. For example, since both widest set of options for selection. For example, since both
applications that require reliability and those that do not require applications that require reliability and those that do not require
reliability can function correctly when a protocol provides reliability can function correctly when a protocol provides
reliability, reliability ought to be enabled by default. As another reliability, reliability ought to be enabled by default. As another
example, the default value for a Property regarding the selection of example, the default value for a Property regarding the selection of
network interfaces ought to permit as many interfaces as possible. network interfaces ought to permit as many interfaces as possible.
skipping to change at page 11, line 48 skipping to change at page 11, line 48
The following example shows equivalent Protocol Stacks: The following example shows equivalent Protocol Stacks:
* If the application does not require reliable transmission of data, * If the application does not require reliable transmission of data,
then a Protocol Stack that adds reliability could be regarded as then a Protocol Stack that adds reliability could be regarded as
an equivalent Protocol Stack as long as providing this would not an equivalent Protocol Stack as long as providing this would not
conflict with any other application-requested properties. conflict with any other application-requested properties.
To ensure that security protocols are not incorrectly swapped, To ensure that security protocols are not incorrectly swapped,
Transport Services systems MUST only select Protocol Stacks that meet Transport Services systems MUST only select Protocol Stacks that meet
application requirements ([I-D.ietf-taps-transport-security]). application requirements ([RFC8922]). Systems SHOULD only race
Systems SHOULD only race Protocol Stacks where the transport security Protocol Stacks where the transport security protocols within the
protocols within the stacks are identical. Transport Services stacks are identical. Transport Services systems MUST NOT
systems MUST NOT automatically fall back from secure protocols to automatically fall back from secure protocols to insecure protocols,
insecure protocols, or to weaker versions of secure protocols. A or to weaker versions of secure protocols. A Transport Services
Transport Services system MAY allow applications to explicitly system MAY allow applications to explicitly specify that fallback to
specify that fallback to a specific other version of a protocol is a specific other version of a protocol is allowed, e.g., to allow
allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not fallback to TLS 1.2 if TLS 1.3 is not available.
available.
3.4. Maintain Interoperability 3.4. Maintain Interoperability
It is important to note that neither the Transport Services API It is important to note that neither the Transport Services API
[I-D.ietf-taps-interface] nor the Implementation document [I-D.ietf-taps-interface] nor the Implementation document
[I-D.ietf-taps-impl] define new protocols or protocol capabilities [I-D.ietf-taps-impl] define new protocols or protocol capabilities
that affect what is communicated across the network. Use of a that affect what is communicated across the network. Use of a
Transport Services system MUST NOT require that a peer on the other Transport Services system MUST NOT require that a peer on the other
side of a connection uses the same API or implementation. A side of a connection uses the same API or implementation. A
Transport Services system acting as a connection initiator is able to Transport Services system acting as a connection initiator is able to
skipping to change at page 13, line 46 skipping to change at page 13, line 43
+-------+--------+ +-------+--------+
V V
Network Layer Interface Network Layer Interface
Figure 3: Concepts and Relationships in the Transport Services Figure 3: Concepts and Relationships in the Transport Services
Architecture Architecture
4.1. Transport Services API Concepts 4.1. Transport Services API Concepts
Fundamentally, a Transport Services API needs to provide connection Fundamentally, a Transport Services API needs to provide connection
objects (Section 4.1.1) that allow applications to establish objects (Section 4.1.2) that allow applications to establish
communication, and then send and receive data. These could be communication, and then send and receive data. These could be
exposed as handles or referenced objects, depending on the language. exposed as handles or referenced objects, depending on the language.
Beyond the connection objects, there are several high-level groups of Beyond the connection objects, there are several high-level groups of
actions that any Transport Services API needs to provide: actions that any Transport Services API needs to provide:
* Pre-Establishment (Section 4.1.2) encompasses the properties that * Pre-Establishment (Section 4.1.3) encompasses the properties that
an application can pass to describe its intent, requirements, an application can pass to describe its intent, requirements,
prohibitions, and preferences for its networking operations. prohibitions, and preferences for its networking operations.
These properties apply to multiple transport protocols, unless These properties apply to multiple transport protocols, unless
otherwise specified. Properties specified during Pre- otherwise specified. Properties specified during Pre-
Establishment can have a large impact on the rest of the Establishment can have a large impact on the rest of the
interface: they modify how establishment occurs, they influence interface: they modify how establishment occurs, they influence
the expectations around data transfer, and they determine the set the expectations around data transfer, and they determine the set
of events that will be supported. of events that will be supported.
* Establishment (Section 4.1.3) focuses on the actions that an * Establishment (Section 4.1.4) focuses on the actions that an
application takes on the connection objects to prepare for data application takes on the connection objects to prepare for data
transfer. transfer.
* Data Transfer (Section 4.1.4) consists of how an application * Data Transfer (Section 4.1.5) consists of how an application
represents the data to be sent and received, the functions represents the data to be sent and received, the functions
required to send and receive that data, and how the application is required to send and receive that data, and how the application is
notified of the status of its data transfer. notified of the status of its data transfer.
* Event Handling (Section 4.1.5) defines categories of notifications * Event Handling (Section 4.1.6) defines categories of notifications
which an application can receive during the lifetime of transport which an application can receive during the lifetime of transport
objects. Events also provide opportunities for the application to objects. Events also provide opportunities for the application to
interact with the underlying transport by querying state or interact with the underlying transport by querying state or
updating maintenance options. updating maintenance options.
* Termination (Section 4.1.6) focuses on the methods by which data * Termination (Section 4.1.7) focuses on the methods by which data
transmission is stopped, and state is torn down in the transport. transmission is stopped, and state is torn down in the transport.
The diagram below provides a high-level view of the actions and The diagram below provides a high-level view of the actions and
events during the lifetime of a Connection object. Note that some events during the lifetime of a Connection object. Note that some
actions are alternatives (e.g., whether to initiate a connection or actions are alternatives (e.g., whether to initiate a connection or
to listen for incoming connections), while others are optional (e.g., to listen for incoming connections), while others are optional (e.g.,
setting Connection and Message Properties in Pre-Establishment) or setting Connection and Message Properties in Pre-Establishment) or
have been omitted for brevity and simplicity. have been omitted for brevity and simplicity.
Pre-Establishment : Established : Termination Pre-Establishment : Established : Termination
----------------- : ----------- : ----------- ----------------- : ----------- : -----------
: : : :
+-- Local Endpoint : Message : +-- Local Endpoint : Message :
+-- Remote Endpoint : Receive() | : +-- Remote Endpoint : Receive() | :
+-- Transport Properties : Send() | : +-- Transport Properties : Send() | :
+-- Security Parameters : | : +-- Security Parameters : | :
| : | : | : | :
| InitiateWithSend() | Close() : | InitiateWithSend() | Close() :
| +---------------+ Initiate() +-----+------+ Abort() : | +---------------+ Initiate() +-----+------+ Abort() :
+---+ Preconnection |------------->| Connection |-----------> Closed +---+ Preconnection |------------->| Connection |-----------> Closed
+---------------+ Rendezvous() +------------+ : +---------------+ Rendezvous() +------------+ :
Listen() | : | | : Listen() | : | | :
| : | v : | : | v :
v : | Connection : v : | Connection :
+----------+ : | Ready : +----------+ : | Ready :
| Listener |----------------------+ : | Listener |----------------------+ :
+----------+ Connection Received : +----------+ Connection Received :
: : : :
Figure 4: The lifetime of a Connection object Figure 4: The lifetime of a Connection object
4.1.1. Connections and Related Objects 4.1.1. Endpoint Objects
* Endpoint: An Endpoint represents an identifier for one side of a
transport connection. Endpoints can be Local Endpoints or Remote
Endpoints, and respectively represent an identity that the
application uses for the source or destination of a connection.
An Endpoint can be specified at various levels of abstraction, and
an Endpoint at a higher level of abstraction (such as a hostname)
can be resolved to more concrete identities (such as IP
addresses).
* Remote Endpoint: The Remote Endpoint represents the application's
identifier for a peer that can participate in a transport
connection; for example, the combination of a DNS name for the
peer and a service name/port.
* Local Endpoint: The Local Endpoint represents the application's
identifier for itself that it uses for transport connections; for
example, a local IP address and port.
4.1.2. Connections and Related Objects
* Preconnection: A Preconnection object is a representation of a * Preconnection: A Preconnection object is a representation of a
potential Connection. It has state that describes parameters of a potential Connection. It has state that describes parameters of a
Connection that might exist in the future: the Local Endpoint from Connection that might exist in the future: the Local Endpoint from
which that Connection will be established, the Remote Endpoint which that Connection will be established, the Remote Endpoint
(Section 4.1.2) to which it will connect, and Transport Properties (Section 4.1.3) to which it will connect, and Transport Properties
that influence the paths and protocols a Connection will use. A that influence the paths and protocols a Connection will use. A
Preconnection can be fully specified such that it represents a Preconnection can be fully specified such that it represents a
single possible Connection, or it can be partially specified such single possible Connection, or it can be partially specified such
that it represents a family of possible Connections. The Local that it represents a family of possible Connections. The Local
Endpoint (Section 4.1.2) is required if the Preconnection is used Endpoint (Section 4.1.3) is required if the Preconnection is used
to Listen for incoming Connections. The Local Endpoint is to Listen for incoming Connections. The Local Endpoint is
optional if it is used to Initiate Connections. The Remote optional if it is used to Initiate Connections. The Remote
Endpoint is required in the Preconnection that is used to Initiate Endpoint is required in the Preconnection that is used to Initiate
Connections. The Remote Endpoint is optional if it is used to Connections. The Remote Endpoint is optional if it is used to
Listen for incoming Connections. The Local Endpoint and the Listen for incoming Connections. The Local Endpoint and the
Remote Endpoint are both required if a peer-to-peer Rendezvous is Remote Endpoint are both required if a peer-to-peer Rendezvous is
to occur based on the Preconnection. to occur based on the Preconnection.
* Transport Properties: Transport Properties allow the application * Transport Properties: Transport Properties allow the application
to express their requirements, prohibitions, and preferences and to express their requirements, prohibitions, and preferences and
configure the Transport Services system. There are three kinds of configure the Transport Services system. There are three kinds of
Transport Properties: Transport Properties:
- Selection Properties (Section 4.1.2) that can only be specified - Selection Properties (Section 4.1.3) that can only be specified
on a Preconnection. on a Preconnection.
- Connection Properties (Section 4.1.2) that can be specified on - Connection Properties (Section 4.1.3) that can be specified on
a Preconnection and changed on the Connection. a Preconnection and changed on the Connection.
- Message Properties (Section 4.1.4) that can be specified as - Message Properties (Section 4.1.5) that can be specified as
defaults on a Preconnection or a Connection, and can also be defaults on a Preconnection or a Connection, and can also be
specified during data transfer to affect specific Messages. specified during data transfer to affect specific Messages.
* Connection: A Connection object represents one or more active * Connection: A Connection object represents one or more active
transport protocol instances that can send and/or receive Messages transport protocol instances that can send and/or receive Messages
between local and remote systems. It holds state pertaining to between local and remote systems. It holds state pertaining to
the underlying transport protocol instances and any ongoing data the underlying transport protocol instances and any ongoing data
transfers. This represents, for example, an active Connection in transfers. This represents, for example, an active Connection in
a connection-oriented protocol such as TCP, or a fully-specified a connection-oriented protocol such as TCP, or a fully-specified
5-tuple for a connectionless protocol such as UDP. It can also 5-tuple for a connectionless protocol such as UDP. It can also
represent a pool of transport protocol instances, e.g., a set of represent a pool of transport protocol instances, e.g., a set of
TCP and QUIC connections to equivalent endpoints, or a stream of a TCP and QUIC connections to equivalent endpoints, or a stream of a
multi-streaming transport protocol instance. Connections can be multi-streaming transport protocol instance. Connections can be
created from a Preconnection or by a Listener. created from a Preconnection or by a Listener.
* Listener: A Listener object accepts incoming transport protocol * Listener: A Listener object accepts incoming transport protocol
connections from remote systems and generates corresponding connections from remote systems and generates corresponding
Connection objects. It is created from a Preconnection object Connection objects. It is created from a Preconnection object
that specifies the type of incoming Connections it will accept. that specifies the type of incoming Connections it will accept.
4.1.2. Pre-Establishment 4.1.3. Pre-Establishment
* Endpoint: An Endpoint represents an identifier for one side of a
transport connection. Endpoints can be Local Endpoints or Remote
Endpoints, and respectively represent an identity that the
application uses for the source or destination of a connection.
An Endpoint can be specified at various levels of abstraction, and
an Endpoint at a higher level of abstraction (such as a hostname)
can be resolved to more concrete identities (such as IP
addresses).
* Remote Endpoint: The Remote Endpoint represents the application's
identifier for a peer that can participate in a transport
connection; for example, the combination of a DNS name for the
peer and a service name/port.
* Local Endpoint: The Local Endpoint represents the application's
identifier for itself that it uses for transport connections; for
example, a local IP address and port.
* Selection Properties: The Selection Properties consist of the * Selection Properties: The Selection Properties consist of the
options that an application can set to influence the selection of properties that an application can set to influence the selection
paths between the local and remote systems, to influence the of paths between the local and remote systems, to influence the
selection of transport protocols, or to configure the behavior of selection of transport protocols, or to configure the behavior of
generic transport protocol features. These options can take the generic transport protocol features. These properties can take
form of requirements, prohibitions, or preferences. Examples of the form of requirements, prohibitions, or preferences. Examples
options that influence path selection include the interface type of properties that influence path selection include the interface
(such as a Wi-Fi connection, or a Cellular LTE connection), type (such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the largest Message that can be sent, or requirements around the largest Message that can be sent, or
preferences for throughput and latency properties. Examples of preferences for throughput and latency. Examples of properties
options that influence protocol selection and configuration of that influence protocol selection and configuration of transport
transport protocol features include reliability, multipath protocol features include reliability, multipath support, and fast
support, and fast open support. open support.
* Connection Properties: The Connection Properties are used to * Connection Properties: The Connection Properties are used to
configure protocol-specific options and control per-connection configure protocol-specific options and control per-connection
behavior of the Transport Services system; for example, a behavior of the Transport Services system; for example, a
protocol-specific Connection Property can express that if TCP is protocol-specific Connection Property can express that if TCP is
used, the implementation ought to use the User Timeout Option. used, the implementation ought to use the User Timeout Option.
Note that the presence of such a property does not require that a Note that the presence of such a property does not require that a
specific protocol will be used. In general, these properties do specific protocol will be used. In general, these properties do
not explicitly determine the selection of paths or protocols, but not explicitly determine the selection of paths or protocols, but
can be used in this way by an implementation during connection can be used by an implementation during connection establishment.
establishment. Connection Properties are specified on a Connection Properties are specified on a Preconnection prior to
Preconnection prior to Connection establishment, and can be Connection establishment, and can be modified on the Connection
modified on the Connection later. Changes made to Connection later. Changes made to Connection Properties after Connection
Properties after Connection establishment take effect on a best- establishment take effect on a best-effort basis.
effort basis.
* Security Parameters: Security Parameters define an application's * Security Parameters: Security Parameters define an application's
requirements for authentication and encryption on a Connection. requirements for authentication and encryption on a Connection.
They are used by Transport Security protocols (such as those They are used by Transport Security protocols (such as those
described in [I-D.ietf-taps-transport-security]) to establish described in [RFC8922]) to establish secure Connections. Examples
secure Connections. Examples of parameters that can be set of parameters that can be set include local identities, private
include local identities, private keys, supported cryptographic keys, supported cryptographic algorithms, and requirements for
algorithms, and requirements for validating trust of remote validating trust of remote identities. Security Parameters are
identities. Security Parameters are primarily associated with a primarily associated with a Preconnection object, but properties
Preconnection object, but properties related to identities can be related to identities can be associated directly with Endpoints.
associated directly with Endpoints.
4.1.4. Establishment Actions
4.1.3. Establishment Actions
* Initiate: The primary action that an application can take to * Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required create a Connection to a Remote Endpoint, and prepare any required
local or remote state to enable the transmission of Messages. For local or remote state to enable the transmission of Messages. For
some protocols, this will initiate a client-to-server style some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local handshake; for other protocols, this will just establish local
state (e.g., with connectionless protocols such as UDP). The state (e.g., with connectionless protocols such as UDP). The
process of identifying options for connecting, such as resolution process of identifying options for connecting, such as resolution
of the Remote Endpoint, occurs in response to the Initiate call. of the Remote Endpoint, occurs in response to the Initiate call.
* Listen: Enables a listener to accept incoming Connections. The * Listen: Enables a listener to accept incoming Connections. The
Listener will then create Connection objects as incoming Listener will then create Connection objects as incoming
connections are accepted (Section 4.1.5). Listeners by default connections are accepted (Section 4.1.6). Listeners by default
register with multiple paths, protocols, and local endpoints, register with multiple paths, protocols, and local endpoints,
unless constrained by Selection Properties and/or the specified unless constrained by Selection Properties and/or the specified
Local Endpoint(s). Connections can be accepted on any of the Local Endpoint(s). Connections can be accepted on any of the
available paths or endpoints. available paths or endpoints.
* Rendezvous: The action of establishing a peer-to-peer connection * Rendezvous: The action of establishing a peer-to-peer connection
with a Remote Endpoint. It simultaneously attempts to initiate a with a Remote Endpoint. It simultaneously attempts to initiate a
connection to a Remote Endpoint while listening for an incoming connection to a Remote Endpoint while listening for an incoming
connection from that endpoint. The process of identifying options connection from that endpoint. The process of identifying options
for the connection, such as resolution of the Remote Endpoint, for the connection, such as resolution of the Remote Endpoint,
skipping to change at page 18, line 40 skipping to change at page 18, line 32
connection. The processes by which connections are initiated connection. The processes by which connections are initiated
during a Rendezvous action will depend on the set of Local and during a Rendezvous action will depend on the set of Local and
Remote Endpoints configured on the Preconnection. For example, if Remote Endpoints configured on the Preconnection. For example, if
the Local and Remote Endpoints are TCP host candidates, then a TCP the Local and Remote Endpoints are TCP host candidates, then a TCP
simultaneous open [RFC0793] will be performed. However, if the simultaneous open [RFC0793] will be performed. However, if the
set of Local Endpoints includes server reflexive candidates, such set of Local Endpoints includes server reflexive candidates, such
as those provided by STUN, a Rendezvous action will race as those provided by STUN, a Rendezvous action will race
candidates in the style of the ICE algorithm [RFC8445] to perform candidates in the style of the ICE algorithm [RFC8445] to perform
NAT binding discovery and initiate a peer-to-peer connection. NAT binding discovery and initiate a peer-to-peer connection.
4.1.4. Data Transfer Objects and Actions 4.1.5. Data Transfer Objects and Actions
* Message: A Message object is a unit of data that can be * Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two systems represented as bytes that can be transferred between two systems
over a transport connection. The bytes within a Message are over a transport connection. The bytes within a Message are
assumed to be ordered. If an application does not care about the assumed to be ordered. If an application does not care about the
order in which a peer receives two distinct spans of bytes, those order in which a peer receives two distinct spans of bytes, those
spans of bytes are considered independent Messages. spans of bytes are considered independent Messages.
* Message Properties: Message Properties are used to specify details * Message Properties: Message Properties are used to specify details
about Message transmission. They can be specified directly on about Message transmission. They can be specified directly on
skipping to change at page 19, line 19 skipping to change at page 19, line 23
information about the received Message, such as metadata generated information about the received Message, such as metadata generated
at the receiver and information signalled by the remote endpoint. at the receiver and information signalled by the remote endpoint.
For example, a Message can be marked with a Message Property For example, a Message can be marked with a Message Property
indicating that it is the final message on a connection if the indicating that it is the final message on a connection if the
peer sent a TCP FIN. peer sent a TCP FIN.
* Send: The action to transmit a Message over a Connection to the * Send: The action to transmit a Message over a Connection to the
remote system. The interface to Send can accept Message remote system. The interface to Send can accept Message
Properties specific to how the Message content is to be sent. The Properties specific to how the Message content is to be sent. The
status of the Send operation is delivered back to the sending status of the Send operation is delivered back to the sending
application in an event (Section 4.1.5). application in an event (Section 4.1.6).
* Receive: An action that indicates that the application is ready to * Receive: An action that indicates that the application is ready to
asynchronously accept a Message over a Connection from a remote asynchronously accept a Message over a Connection from a remote
system, while the Message content itself will be delivered in an system, while the Message content itself will be delivered in an
event (Section 4.1.5). The interface to Receive can include event (Section 4.1.6). The interface to Receive can include
Message Properties specific to the Message that is to be delivered Message Properties specific to the Message that is to be delivered
to the application. to the application.
* Framer: A Framer is a data translation layer that can be added to * Framer: A Framer is a data translation layer that can be added to
a Connection to define how application-layer Messages are a Connection to define how application-layer Messages are
transmitted over a transport protocol. This is particularly transmitted over a transport protocol. This is particularly
relevant for protocols that otherwise present unstructured relevant for protocols that otherwise present unstructured
streams, such as TCP. streams, such as TCP.
4.1.5. Event Handling 4.1.6. Event Handling
The following categories of events can be delivered to an The following categories of events can be delivered to an
application: application:
* Connection Ready: Signals to an application that a given * Connection Ready: Signals to an application that a given
Connection is ready to send and/or receive Messages. If the Connection is ready to send and/or receive Messages. If the
Connection relies on handshakes to establish state between peers, Connection relies on handshakes to establish state between peers,
then it is assumed that these steps have been taken. then it is assumed that these steps have been taken.
* Connection Closed: Signals to an application that a given * Connection Closed: Signals to an application that a given
skipping to change at page 20, line 19 skipping to change at page 20, line 22
* Message Sent: Notifies the application of the status of its Send * Message Sent: Notifies the application of the status of its Send
action. This might indicate a failure if the Message cannot be action. This might indicate a failure if the Message cannot be
sent, or an indication that the Message has been processed by the sent, or an indication that the Message has been processed by the
protocol stack. protocol stack.
* Path Properties Changed: Notifies the application that some * Path Properties Changed: Notifies the application that some
property of the Connection has changed that might influence how property of the Connection has changed that might influence how
and where data is sent and/or received. and where data is sent and/or received.
4.1.6. Termination Actions 4.1.7. Termination Actions
* Close: The action an application takes on a Connection to indicate * Close: The action an application takes on a Connection to indicate
that it no longer intends to send data, is no longer willing to that it no longer intends to send data, is no longer willing to
receive data, and that the protocol should signal this state to receive data, and that the protocol should signal this state to
the remote system if the transport protocol allows this. (Note the remote system if the transport protocol allows this. (Note
that this is distinct from the concept of "half-closing" a that this is distinct from the concept of "half-closing" a
bidirectional connection, such as when a FIN is sent in one bidirectional connection, such as when a FIN is sent in one
direction of a TCP connection. Indicating the end of a stream in direction of a TCP connection. Indicating the end of a stream in
the Transport Services architecture is possible using Message the Transport Services architecture is possible using Message
Properties when sending.) Properties when sending.)
* Abort: The action the application takes on a Connection to * Abort: The action the application takes on a Connection to
indicate a Close and also indicate that the Transport Services indicate a Close and also indicate that the Transport Services
system should not attempt to deliver any outstanding data. This system should not attempt to deliver any outstanding data. This
is intended for immediate termination of a connection, without is intended for immediate termination of a connection, without
cleaning up state. cleaning up state.
4.1.7. Connection Groups 4.1.8. Connection Groups
A Connection Group is a set of Connections that share properties and A Connection Group is a set of Connections that share properties and
caches. For multiplexing transport protocols, only Connections caches. For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed within the same Connection Group are allowed to be multiplexed
together. An application can explicitly define Connection Groups to together. An application can explicitly define Connection Groups to
control caching boundaries, as discussed in Section 4.2.3. control caching boundaries, as discussed in Section 4.2.3.
4.2. Transport Services Implementation Concepts 4.2. Transport Services Implementation Concepts
This section defines the set of objects used internally to a system This section defines the set of objects used internally to a system
skipping to change at page 23, line 45 skipping to change at page 24, line 14
6. Security Considerations 6. Security Considerations
The Transport Services architecture does not recommend use of The Transport Services architecture does not recommend use of
specific security protocols or algorithms. Its goal is to offer ease specific security protocols or algorithms. Its goal is to offer ease
of use for existing protocols by providing a generic security-related of use for existing protocols by providing a generic security-related
interface. Each provided interface translates to an existing interface. Each provided interface translates to an existing
protocol-specific interface provided by supported security protocols. protocol-specific interface provided by supported security protocols.
For example, trust verification callbacks are common parts of TLS For example, trust verification callbacks are common parts of TLS
APIs. Transport Services APIs will expose similar functionality APIs. Transport Services APIs will expose similar functionality
[I-D.ietf-taps-transport-security]. [RFC8922].
As described above in Section 3.3, if a Transport Services system As described above in Section 3.3, if a Transport Services system
races between two different Protocol Stacks, both need to use the races between two different Protocol Stacks, both need to use the
same security protocols and options. However, a Transport Services same security protocols and options. However, a Transport Services
system can race different security protocols, e.g., if the system can race different security protocols, e.g., if the
application explicitly specifies that it considers them equivalent. application explicitly specifies that it considers them equivalent.
Applications need to ensure that they use security APIs Applications need to ensure that they use security APIs
appropriately. In cases where applications use an interface to appropriately. In cases where applications use an interface to
provide sensitive keying material, e.g., access to private keys or provide sensitive keying material, e.g., access to private keys or
skipping to change at page 25, line 5 skipping to change at page 25, line 24
8. References 8. References
8.1. Normative References 8.1. Normative References
[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., Wood, C., and T. Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
Pauly, "An Abstract Application Layer Interface to Pauly, "An Abstract Application Layer Interface to
Transport Services", Work in Progress, Internet-Draft, Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-interface-06, 9 March 2020, draft-ietf-taps-interface-09, 27 July 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-taps- <http://www.ietf.org/internet-drafts/draft-ietf-taps-
interface-06.txt>. interface-09.txt>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. 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", Work in "Implementing Interfaces to Transport Services", Work in
Progress, Internet-Draft, draft-ietf-taps-impl-06, 9 March Progress, Internet-Draft, draft-ietf-taps-impl-07, 13 July
2020, <http://www.ietf.org/internet-drafts/draft-ietf- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-
taps-impl-06.txt>. taps-impl-07.txt>.
[I-D.ietf-taps-minset]
Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", Work in Progress, Internet-
Draft, draft-ietf-taps-minset-11, 27 September 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-taps-
minset-11.txt>.
[I-D.ietf-taps-transport-security]
Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction Between Security
Protocols and Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-transport-security-12, 23
April 2020, <http://www.ietf.org/internet-drafts/draft-
ietf-taps-transport-security-12.txt>.
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open -- Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7", group Technical Standard: Base Specifications, Issue 7",
2008. 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
skipping to change at page 26, line 44 skipping to change at page 26, line 48
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction between Security
Protocols and Transport Services", RFC 8922,
DOI 10.17487/RFC8922, October 2020,
<https://www.rfc-editor.org/info/rfc8922>.
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/info/rfc8923>.
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)
Google Switzerland GmbH Google Switzerland GmbH
Gustav-Gull-Platz 1 Gustav-Gull-Platz 1
CH- 8004 Zurich CH- 8004 Zurich
Switzerland Switzerland
Email: ietf@trammell.ch Email: ietf@trammell.ch
Anna Brunstrom Anna Brunstrom
Karlstad University Karlstad University
 End of changes. 54 change blocks. 
157 lines changed or deleted 154 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/