draft-ietf-taps-interface-19.txt		draft-ietf-taps-interface-20.txt
	TAPS Working Group B. Trammell, Ed.		TAPS Working Group B. Trammell, Ed.
	Internet-Draft Google Switzerland GmbH		Internet-Draft Google Switzerland GmbH
	Intended status: Standards Track M. Welzl, Ed.		Intended status: Standards Track M. Welzl, Ed.
	Expires: 10 September 2023 University of Oslo		Expires: 30 September 2023 University of Oslo
	T. Enghardt		R. Enghardt
	Netflix		Netflix
	G. Fairhurst		G. Fairhurst
	University of Aberdeen		University of Aberdeen
	M. Kuehlewind		M. Kuehlewind
	Ericsson		Ericsson
	C. Perkins		C. Perkins
	University of Glasgow		University of Glasgow
	P. Tiesel		P. Tiesel
	SAP SE		SAP SE
	T. Pauly		T. Pauly
	Apple Inc.		Apple Inc.
	9 March 2023		29 March 2023
	An Abstract Application Layer Interface to Transport Services		An Abstract Application Layer Interface to Transport Services
	draft-ietf-taps-interface-19		draft-ietf-taps-interface-20
	Abstract		Abstract
	This document describes an abstract application programming		This document describes an abstract application programming
	interface, API, to the transport layer that enables the selection of		interface, API, to the transport layer that enables the selection of
	transport protocols and network paths dynamically at runtime. This		transport protocols and network paths dynamically at runtime. This
	API enables faster deployment of new protocols and protocol features		API enables faster deployment of new protocols and protocol features
	without requiring changes to the applications. The specified API		without requiring changes to the applications. The specified API
	follows the Transport Services architecture by providing		follows the Transport Services architecture by providing
	asynchronous, atomic transmission of messages. It is intended to		asynchronous, atomic transmission of messages. It is intended to
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 10 September 2023.		This Internet-Draft will expire on 30 September 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 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 18, line 40 ¶		skipping to change at page 18, line 40 ¶
	* Interface name (string), e.g., to qualify link-local or multicast		* Interface name (string), e.g., to qualify link-local or multicast
	addresses (see Section 6.1.2 for details):		addresses (see Section 6.1.2 for details):
	LocalSpecifier.WithInterface("en0")		LocalSpecifier.WithInterface("en0")
	Note that an IPv6 address specified with a scope (e.g.		Note that an IPv6 address specified with a scope (e.g.
	2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to		2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to
	WithIPv6Address with an unscoped address and WithInterface together.		WithIPv6Address with an unscoped address and WithInterface together.
	An Endpoint MUST NOT be configured with multiple identifiers of the		The design of the API MUST NOT permit an Endpoint to be configured
	same type. For example, an endpoint cannot have two IP addresses		with multiple identifiers of the same type. For example, an endpoint
	specified. Two separate IP addresses are represented as two Endpoint		cannot have two IP addresses specified. Two separate IP addresses
	Objects. If a Preconnection specifies a Remote Endpoint with a		are represented as two Endpoint Objects. If a Preconnection
	specific IP address set, it will only establish Connections to that		specifies a Remote Endpoint with a specific IP address set, it will
	IP address. If, on the other hand, the Remote Endpoint specifies a		only establish Connections to that IP address. If, on the other
	hostname but no addresses, the Connection can perform name resolution		hand, the Remote Endpoint specifies a hostname but no addresses, the
	and attempt using any address derived from the original hostname of		Connection can perform name resolution and attempt using any address
	the Remote Endpoint. Note that multiple Remote Endpoints can be		derived from the original hostname of the Remote Endpoint. Note that
	added to a Preconnection, as discussed in Section 7.5.		multiple Remote Endpoints can be added to a Preconnection, as
			discussed in Section 7.5.
	The Transport Services system resolves names internally, when the		The Transport Services system resolves names internally, when the
	Initiate(), Listen(), or Rendezvous() method is called to establish a		Initiate(), Listen(), or Rendezvous() method is called to establish a
	Connection. Privacy considerations for the timing of this resolution		Connection. Privacy considerations for the timing of this resolution
	are given in Section 13.		are given in Section 13.
	The Resolve() action on a Preconnection can be used by the		The Resolve() action on a Preconnection can be used by the
	application to force early binding when required, for example with		application to force early binding when required, for example with
	some Network Address Translator (NAT) traversal protocols (see		some Network Address Translator (NAT) traversal protocols (see
	Section 7.3).		Section 7.3).
	skipping to change at page 79, line 50 ¶		skipping to change at page 79, line 50 ¶
	good questions based on implementation experience and for		good questions based on implementation experience and for
	contributing text, e.g., on multicast.		contributing text, e.g., on multicast.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[I-D.ietf-taps-arch]		[I-D.ietf-taps-arch]
	Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and		Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and
	C. Perkins, "An Architecture for Transport Services", Work		C. Perkins, "An Architecture for Transport Services", Work
	in Progress, Internet-Draft, draft-ietf-taps-arch-16, 9		in Progress, Internet-Draft, draft-ietf-taps-arch-17, 29
	March 2023, <https://datatracker.ietf.org/doc/html/draft-		March 2023, <https://datatracker.ietf.org/doc/html/draft-
	ietf-taps-arch-16>.		ietf-taps-arch-17>.
	[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/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,		[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
	RFC 2914, DOI 10.17487/RFC2914, September 2000,		RFC 2914, DOI 10.17487/RFC2914, September 2000,
	<https://www.rfc-editor.org/rfc/rfc2914>.		<https://www.rfc-editor.org/rfc/rfc2914>.
	skipping to change at page 91, line 4 ¶		skipping to change at page 91, line 4 ¶
	CH- 8004 Zurich		CH- 8004 Zurich
	Switzerland		Switzerland
	Email: ietf@trammell.ch		Email: ietf@trammell.ch
	Michael Welzl (editor)		Michael Welzl (editor)
	University of Oslo		University of Oslo
	PO Box 1080 Blindern		PO Box 1080 Blindern
	0316 Oslo		0316 Oslo
	Norway		Norway
	Email: michawe@ifi.uio.no		Email: michawe@ifi.uio.no
	Theresa Enghardt		Reese Enghardt
	Netflix		Netflix
	121 Albright Way		121 Albright Way
	Los Gatos, CA 95032,		Los Gatos, CA 95032,
	United States of America		United States of America
	Email: ietf@tenghardt.net		Email: ietf@tenghardt.net
	Godred Fairhurst		Godred Fairhurst
	University of Aberdeen		University of Aberdeen
	Fraser Noble Building		Fraser Noble Building
	Aberdeen, AB24 3UE		Aberdeen, AB24 3UE
End of changes. 8 change blocks.
	18 lines changed or deleted		19 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/