draft-ietf-taps-minset-07.txt   draft-ietf-taps-minset-08.txt 
TAPS M. Welzl TAPS M. Welzl
Internet-Draft S. Gjessing Internet-Draft S. Gjessing
Intended status: Informational University of Oslo Intended status: Informational University of Oslo
Expires: March 4, 2019 August 31, 2018 Expires: March 9, 2019 September 5, 2018
A Minimal Set of Transport Services for End Systems A Minimal Set of Transport Services for End Systems
draft-ietf-taps-minset-07 draft-ietf-taps-minset-08
Abstract Abstract
This draft recommends a minimal set of Transport Services offered by This draft recommends a minimal set of Transport Services offered by
end systems, and gives guidance on choosing among the available end systems, and gives guidance on choosing among the available
mechanisms and protocols. It is based on the set of transport mechanisms and protocols. It is based on the set of transport
features in RFC 8303. features in RFC 8303.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 4, 2019. This Internet-Draft will expire on March 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 16, line 10 skipping to change at page 16, line 10
efficiently if the application is in control of this optimizing efficiently if the application is in control of this optimizing
transport feature. These transport features require application- transport feature. These transport features require application-
specific knowledge (e.g., about delay/bandwidth requirements or the specific knowledge (e.g., about delay/bandwidth requirements or the
length of future data blocks that are to be transmitted). length of future data blocks that are to be transmitted).
The transport features of IETF transport protocols that do not The transport features of IETF transport protocols that do not
require application-specific knowledge and could therefore be require application-specific knowledge and could therefore be
utilized by a transport system on its own without involving the utilized by a transport system on its own without involving the
application are called "Automatable". application are called "Automatable".
Finally, some transport features are aggregated and/or slightly Finally, in three cases, transport features are aggregated and/or
changed from [RFC8303] in the description below. These transport slightly changed from [RFC8303] in the description below. These
features are marked as "ADDED". The corresponding transport features transport features are marked as "ADDED". These do not add any new
are automatable, and they are listed immediately below the "ADDED" functionality but just represent a simple refactoring step that helps
transport feature. to streamline the derivation process (e.g., by removing a choice of a
parameter for the sake of applications that may not care about this
choice). The corresponding transport features are automatable, and
they are listed immediately below the "ADDED" transport feature.
In this description, transport services are presented following the In this description, transport services are presented following the
nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL",
equivalent to "pass 2" in [RFC8303]. We also sketch how functional equivalent to "pass 2" in [RFC8303]. We also sketch how functional
or optimizing transport features can be implemented by a transport or optimizing transport features can be implemented by a transport
system. The "minimal set" derived in this document is meant to be system. The "minimal set" derived in this document is meant to be
implementable "one-sided" over TCP, and, with limitations, UDP. implementable "one-sided" over TCP, and, with limitations, UDP.
Hence, for all transport features that are categorized as Hence, for all transport features that are categorized as
"functional" or "optimizing", and for which no matching TCP and/or "functional" or "optimizing", and for which no matching TCP and/or
UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on
skipping to change at page 47, line 30 skipping to change at page 47, line 30
WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As
part of that, removed "TAPS" as a term everywhere (abstract, intro, part of that, removed "TAPS" as a term everywhere (abstract, intro,
..). ..).
WG -05: addressed comments from Spencer Dawkins. WG -05: addressed comments from Spencer Dawkins.
WG -06: Fixed nits. WG -06: Fixed nits.
WG -07: Addressed Genart comments from Robert Sparks. WG -07: Addressed Genart comments from Robert Sparks.
WG -08: Addressed one more Genart comment from Robert Sparks.
Authors' Addresses Authors' Addresses
Michael Welzl Michael Welzl
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
Oslo N-0316 Oslo N-0316
Norway Norway
Phone: +47 22 85 24 20 Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
 End of changes. 5 change blocks. 
8 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/