rfc9217.original.xml		rfc9217.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.24 -->		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		-irtf-panrg-questions-12" number="9217" tocInclude="true" sortRefs="true" symRef
	-irtf-panrg-questions-12" category="info" tocInclude="true" sortRefs="true" symR		s="true" obsoletes="" updates="" submissionType="IRTF" category="info" consensus
	efs="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="		="true" xml:lang="en" version="3">
	3">
	<!-- xml2rfc v2v3 conversion 3.12.0 -->		<!-- [rfced] FYI: We've updated the term "path aware" when used in attributive p
			osition, including in the title of this document. Please let us know if this is
			not preferred.
			Original:
			Current Open Questions in Path Aware Networking
			Updated:
			Current Open Questions in Path-Aware Networking
			Note: We did not hyphenate as part of "Path Aware Networking proposed Research G
			roup" since it does not appear as part of the RG name.
			-->
	<front>		<front>
	<title abbrev="PAN questions">Current Open Questions in Path Aware Networkin		<title abbrev="PAN questions">Current Open Questions in Path-Aware Networkin
	g</title>		g</title>
	<seriesInfo name="Internet-Draft" value="draft-irtf-panrg-questions-12"/>		<seriesInfo name="RFC" value="9217"/>
	<author initials="B." surname="Trammell" fullname="Brian Trammell">		<author initials="B." surname="Trammell" fullname="Brian Trammell">
	<organization>Google Switzerland GmbH</organization>		<organization>Google Switzerland GmbH</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Gustav-Gull-Platz 1</street>		<street>Gustav-Gull-Platz 1</street>
	<city>8004 Zurich</city>		<city>Zurich</city>
			<code>8004</code>
	<country>Switzerland</country>		<country>Switzerland</country>
	</postal>		</postal>
	<email>ietf@trammell.ch</email>		<email>ietf@trammell.ch</email>
	</address>		</address>
	</author>		</author>
	<date year="2022" month="January" day="25"/>		<date year="2022" month="March"/>
	<workgroup>Path Aware Networking RG</workgroup>		<workgroup>Path Aware Networking</workgroup>
	<keyword>Internet-Draft</keyword>
			<!-- [rfced] Please insert any keywords (beyond those that appear in the title)
			for use on https://www.rfc-editor.org/search. -->
			<keyword>example</keyword>
	<abstract>		<abstract>
	<t>In contrast to the present Internet architecture, a path-aware internet		<t>In contrast to the present Internet architecture, a path-aware
	working		internetworking architecture has two important properties: it exposes
	architecture has two important properties: it exposes the properties of		the properties of available Internet paths to endpoints, and it provides
	available Internet paths to endpoints, and provides for endpoints and		for endpoints and applications to use these properties to select paths
	applications to use these properties to select paths through the Internet for		through the Internet for their traffic. While this property of "path
	their traffic. While this property of "path awareness" already exists in many		awareness" already exists in many Internet-connected networks within
	Internet-connected networks within single domains and via administrative		single domains and via administrative interfaces to the network layer, a
	interfaces to the network layer, a fully path-aware internetwork expands these		fully path-aware internetwork expands these concepts across layers and
	concepts across layers and across the Internet.</t>		across the Internet.</t>
	<t>This document poses questions in path-aware networking open as of 2021,
	that		<t>This document poses questions in path-aware networking, open as of
	must be answered in the design, development, and deployment of path-aware		2021, that must be answered in the design, development, and deployment
	internetworks. It was originally written to frame discussions in the Path Aware		of path-aware internetworks. It was originally written to frame
	Networking proposed Research Group (PANRG), and has been published to snapshot		discussions in the Path Aware Networking Research Group (PANRG), and has
	current thinking in this space.</t>		been published to snapshot current thinking in this space.</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>Discussion Venues</name>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/panrg/questions"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
			<!-- [rfced] For ease of the reader, should a definition or reference for SD-WAN
			be added? If yes, please provide the reference information. Perhaps an inform
			ative reference to the definition in RFC 9061?
			Original:
			(e.g., Path Computation Element (PCE) [RFC4655] and Software-Defined
			Wide Area Network (SD-WAN) approaches)
			-->
	<section anchor="intro" numbered="true" toc="default">		<section anchor="intro" numbered="true" toc="default">
	<name>Introduction to Path-Aware Networking</name>		<name>Introduction to Path-Aware Networking</name>
	<t>In the current Internet architecture, the network layer provides a		<t>In the current Internet architecture, the network layer provides a
	best-effort service to the endpoints using it, without verifiability of the		best-effort service to the endpoints using it, without verifiability of
	properties of the path between tne endpoints. While there are network layer		the properties of the path between the endpoints. While there are
	technologies that attempt better-than-best-effort delivery, the interfaces to		network-layer technologies that attempt better-than-best-effort
	these are generally administrative as opposed to endpoint-exposed (e.g. Path		delivery, the interfaces to these are generally administrative as
	Computation Element (PCE) <xref target="RFC4655" format="default"/> and Software		opposed to endpoint exposed (e.g., Path Computation Element (PCE) <xref
	-Defined Wide Area Network		target="RFC4655" format="default"/> and Software-Defined Wide Area
	(SD-WAN) approaches), and they are often restricted to single		Network (SD-WAN) approaches), and they are often restricted to single
	administrative domains. In this architecture, an application can assume that a		administrative domains. In this architecture, an application can assume
	packet with a given destination address will eventually be forwarded toward that		that a packet with a given destination address will eventually be
	destination, but little else.</t>		forwarded toward that destination, but little else.</t>
	<t>A transport layer protocol such as TCP can provide reliability over thi		<t>A transport-layer protocol such as TCP can provide reliability over
	s		this best-effort service, and a protocol above the network layer, such
	best-effort service, and a protocol above the network layer, such as		as Transport Layer Security (TLS) <xref target="RFC8446"
	Transport Layer Security (TLS) <xref target="RFC8446" format="default"/> can aut		format="default"/>, can authenticate the remote endpoint. However,
	henticate the remote		little, if any, explicit information about the path is available to the
	endpoint. However, little, if any, explicit information about the path		endpoints, and any assumptions made about that path often do not hold.
	is available to the endpoints, and any assumptions made about that path		These sometimes have serious impacts on the application, as in the case
	often do not hold. These sometimes have serious impacts on the application,		with BGP hijacking attacks.</t>
	as in the case with BGP hijacking attacks.</t>		<t>By contrast, in a path-aware internetworking architecture, endpoints
	<t>By contrast, in a path-aware internetworking architecture, endpoints ca		can select or influence the path(s) through the network used by any
	n		given packet or flow. The network and transport layers explicitly expose
	select or influence the path(s) through the network used by any given		information about the path or paths available to the endpoints and to
	packet or flow. The network and transport layers explicitly expose information		the applications running on them, so that they can make this
	about the path or paths available to the endpoints and to the applications		selection. The Application-Layer Traffic Optimization (ALTO) protocol
	running on them, so that they can make this selection. The Application Layer		<xref target="RFC7285" format="default"/> can be seen as an example of a
	Traffic Optimization (ALTO) protocol <xref target="RFC7285" format="default"/> c		path-awareness approach implemented in transport-layer terms on the
	an be seen as an example		present Internet protocol stack.</t>
	of a path-awareness approach implemented in transport-layer terms on the
	present Internet protocol stack.</t>
	<t>Path selection provides explicit visibility and control of network trea tment to		<t>Path selection provides explicit visibility and control of network trea tment to
	applications and users of the network. This selection is available to the		applications and users of the network. This selection is available to the
	application, transport, and/or network layer entities at each endpoint. Path		application-, transport-, and/or network-layer entities at each endpoint. Path
	control at the flow and subflow level enables the design of new transport		control at the flow and subflow level enables the design of new transport
	protocols that can leverage multipath connectivity across disjoint paths through		protocols that can leverage multipath connectivity across disjoint paths through
	the Internet, even over a single physical interface. When exposed to		the Internet, even over a single physical interface. When exposed to
	applications, or to end-users through a system configuration interface, path		applications, or to end users through a system configuration interface, path
	control allows the specification of constraints on the paths that traffic should		control allows the specification of constraints on the paths that traffic should
	traverse, for instance to confound passive surveillance in the network core		traverse, for instance to confound passive surveillance in the network core
	<xref target="RFC7624" format="default"/>.</t>		<xref target="RFC7624" format="default"/>.</t>
	<t>We note that this property of "path awareness" already exists in many		<t>We note that this property of "path awareness" already exists in many
	Internet-connected networks within single domains. Indeed, much of the practice		Internet-connected networks within single domains. Indeed, much of the
	of network engineering using encapsulation at layer 3 can be said to be "path		practice of network engineering using encapsulation at layer 3 can be
	aware", in that it explicitly assigns traffic at tunnel endpoints to a given		said to be "path aware" in that it explicitly assigns traffic at tunnel
	path within the network. Path-aware internetworking seeks to extend this		endpoints to a given path within the network. Path-aware internetworking
	awareness across domain boundaries without resorting to overlays, except as a		seeks to extend this awareness across domain boundaries without
	transition technology.</t>		resorting to overlays, except as a transition technology.</t>
	<t>This document presents a snapshot of open questions in this space that will need		<t>This document presents a snapshot of open questions in this space that will need
	to be answered in order to realize a path-aware internetworking architecture; it		to be answered in order to realize a path-aware internetworking architecture; it
	is published to further frame discussions within and outside the Path Aware		is published to further frame discussions within and outside the Path Aware
	Networking Research Group, and is published with the rough consensus of that		Networking Research Group, and is published with the rough consensus of that
	group.</t>		group.</t>
	<section anchor="definitions" numbered="true" toc="default">		<section anchor="definitions" numbered="true" toc="default">
	<name>Definitions</name>		<name>Definitions</name>
	<t>For purposes of this document, "path aware networking" describes endp oint		<t>For purposes of this document, "path-aware networking" describes endp oint
	discovery of the properties of paths they use for communication across an		discovery of the properties of paths they use for communication across an
	internetwork, and endpoint reaction to these properties that affects routing		internetwork, and endpoint reaction to these properties that affects routing
	and/or data transfer. Note that this can and already does happen to some extent		and/or data transfer. Note that this can and already does happen to some extent
	in the current Internet architecture; this definition expands current techniques		in the current Internet architecture; this definition expands current techniques
	of path discovery and manipulation to cross administrative domain boundaries and		of path discovery and manipulation to cross administrative domain boundaries and
	up to the transport and application layers at the endpoints.</t>		up to the transport and application layers at the endpoints.</t>
	<t>Expanding on this definition, a "path aware internetwork" is one in w		<t>Expanding on this definition, a "path-aware internetwork" is one in
	hich		which endpoint discovery of path properties and endpoint selection of
	endpoint discovery of path properties and endpoint selection of paths used by		paths used by traffic exchanged by the endpoint are explicitly
	traffic exchanged by the endpoint are explicitly supported, regardless of the		supported regardless of the specific design of the protocol features
	specific design of the protocol features which enable this discovery and		that enable this discovery and selection.</t>
	selection.</t>		<t>A "path", for the purposes of these definitions, is abstractly
	<t>A "path", for the purposes of these definitions, is abstractly define		defined as a sequence of adjacent path elements over which a packet
	d as a		can be transmitted, where the definition of "path element" is
	sequence of adjacent path elements over which a packet can be transmitted,		technology dependent. As this document is intended to pose questions
	where the definition of "path element" is technology-dependent. As this document		rather than answer them, it assumes that this definition will be
	is intended to pose questions rather than answer them, it assumes that this		refined as part of the answer to the first two questions it poses
	definition will be refined as part of the answer the first two questions it		about the vocabulary of path properties and how they are
	poses, about the vocabulary of path properties and how they are disseminated.</t		disseminated.</t>
	>		<t>Research into path-aware internetworking covers any and all aspects o
	<t>Research into path aware internetworking covers any and all aspects o		f
	f		designing, building, and operating path-aware internetworks or the networks
	designing, building, and operating path aware internetworks or the networks
	and endpoints attached to them. This document presents a collection of		and endpoints attached to them. This document presents a collection of
	research questions to address in order to make a path aware Internet a		research questions to address in order to make a path-aware Internet a
	reality.</t>		reality.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="questions" numbered="true" toc="default">		<section anchor="questions" numbered="true" toc="default">
	<name>Questions</name>		<name>Questions</name>
	<t>Realizing path-aware networking requires answers to a set of open resea		<t>Realizing path-aware networking requires answers to a set of open
	rch		research questions. This document poses these questions as a starting
	questions. This document poses these questions, as a starting point for		point for discussions about how to realize path awareness in the
	discussions about how to realize path awareness in the Internet, and to direct		Internet and to direct future research efforts within the Path Aware
	future research efforts within the Path Aware Networking Research Group.</t>		Networking Research Group.</t>
	<section anchor="a-vocabulary-of-path-properties" numbered="true" toc="def ault">		<section anchor="a-vocabulary-of-path-properties" numbered="true" toc="def ault">
	<name>A Vocabulary of Path Properties</name>		<name>A Vocabulary of Path Properties</name>
	<t>The first question: how are paths and path properties defined and rep resented?</t>		<t>The first question: how are paths and path properties defined and rep resented?</t>
	<t>In order for information about paths to be exposed to an endpoint, an		<t>In order for information about paths to be exposed to an endpoint,
	d for the		and for the endpoint to make use of that information,
	endpoint to make use of that information, it is necessary to define a common		<!-- [rfced] Is it necessary to a) define a common vocabulary for paths and b) t
	vocabulary for paths through an internetwork, and properties of those paths. The		he properties of those paths, or to define a) a common vocablary for paths and b
	elements of this vocabulary could include terminology for components of a path		) properties of the paths?
	and properties defined for these components, for the entire path, or for
	subpaths of a path. These properties may be relatively static, such as the		Original:
	presence of a given node or service function on the path; as well as relatively		In order for information about paths to be exposed to an endpoint,
	dynamic, such as the current values of metrics such as loss and latency.</t>		and for the endpoint to make use of that information, it is necessary
	<t>This vocabulary and its representation must be defined carefully, as		to define a common vocabulary for paths through an internetwork, and
	its design		properties of those paths.
	will have impacts on the properties (e.g., expressiveness, scalability, security		-->
	)		it is necessary
	of a given path-aware internetworking architecture. For example, a system that e		to define a common vocabulary for paths through an internetwork and
	xposes		properties of those paths. The elements of this vocabulary could
	node-level information for the topology through each network would maximize		include terminology for components of a path and properties defined
	information about the individual components of the path at the endpoints, at		for these components, for the entire path or for subpaths of a
	the expense of making internal network topology universally public, which may		path. These properties may be relatively static, such as the presence
	be in conflict with the business goals of each network's operator. Furthermore,		of a given node or service function on the path, as well as relatively
	properties related to individual components of the path may change frequently		dynamic, such as the current values of metrics such as loss and
	and may quickly become outdated. However, aggregating the properties of		latency.</t>
	individual components to distill end-to-end properties for the entire path is		<t>This vocabulary and its representation must be defined carefully,
	not trivial.</t>		as its design will have impacts on the properties (e.g.,
			expressiveness, scalability, and security) of a given path-aware
			internetworking architecture. For example, a system that exposes
			node-level information for the topology through each network would
			maximize information about the individual components of the path at
			the endpoints, at the expense of making internal network topology
			universally public, which may be in conflict with the business goals
			of each network's operator. Furthermore, properties related to
			individual components of the path may change frequently and may
			quickly become outdated. However, aggregating the properties of
			individual components to distill end-to-end properties for the entire
			path is not trivial.</t>
	</section>		</section>
	<section anchor="discovery-distribution-and-trustworthiness-of-path-proper ties" numbered="true" toc="default">		<section anchor="discovery-distribution-and-trustworthiness-of-path-proper ties" numbered="true" toc="default">
	<name>Discovery, Distribution, and Trustworthiness of Path Properties</n ame>		<name>Discovery, Distribution, and Trustworthiness of Path Properties</n ame>
	<t>The second question: how do endpoints and applications get access to accurate,		<t>The second question: how do endpoints and applications get access to accurate,
	useful, and trustworthy path properties?</t>		useful, and trustworthy path properties?</t>
	<t>Once endpoints and networks have a shared vocabulary for expressing p		<t>Once endpoints and networks have a shared vocabulary for expressing
	ath		path properties, the network must have some method for distributing
	properties, the network must have some method for distributing those path		those path properties to the endpoints. Regardless of how path
	properties to the endpoints. Regardless of how path property information is		property information is distributed, the endpoints require a method to
	distributed, the endpoints require a method to authenticate		authenticate the properties in order to determine that they originated
	the properties -- to determine that they originated from and pertain to the		from and pertain to the path that they purport to.</t>
	path that they purport to.</t>
	<t>Choices in distribution and authentication methods will have impacts on the		<t>Choices in distribution and authentication methods will have impacts on the
	scalability of a path-aware architecture. Possible dimensions in the space of		scalability of a path-aware architecture. Possible dimensions in the space of
	distribution methods include in-band versus out-of-band, push versus pull		distribution methods include in band versus out of band, push versus pull
	versus publish-subscribe, and so on. There are temporal issues with path		versus publish subscribe, and so on. There are temporal issues with path
	property dissemination as well, especially with dynamic properties, since the		property dissemination as well, especially with dynamic properties, since the
	measurement or elicitation of dynamic properties may be outdated by the time		measurement or elicitation of dynamic properties may be outdated by the time
	that information is available at the endpoints, and interactions between the		that information is available at the endpoints, and interactions between the
	measurement and dissemination delay may exhibit pathological behavior for		measurement and dissemination delay may exhibit pathological behavior for
	unlucky points in the parameter space.</t>		unlucky points in the parameter space.</t>
	</section>		</section>
	<section anchor="supporting-path-selection" numbered="true" toc="default">		<section anchor="supporting-path-selection" numbered="true" toc="default">
	<name>Supporting Path Selection</name>		<name>Supporting Path Selection</name>
	<t>The third question: how can endpoints select paths to use for traffic		<t>The third question: how can endpoints select paths to use for
	in a way		traffic in a way that can be trusted by the network, the endpoints,
	that can be trusted by the network, the endpoints, and the applications using th		and the applications using them?</t>
	em?</t>		<t>Access to trustworthy path properties is only half of the challenge
	<t>Access to trustworthy path properties is only half of the challenge i		in establishing a path-aware architecture. Endpoints must be able to
	n		use this information in order to select paths for specific traffic
	establishing a path-aware architecture. Endpoints must be able to use this		they send. As with the dissemination of path properties, choices made
	information in order to select paths for specific traffic they send. As with the		in path-selection methods will also have an impact on the trade-off
	dissemination of path properties, choices made in path selection methods will		between scalability and expressiveness of a path-aware
	also have an impact on the tradeoff between scalability and expressiveness of a		architecture. One key choice here is between in-band and out-of-band
	path-aware architecture. One key choice here is between in-band and		control of path selection. Another is granularity of path selection
	out-of-band control of path selection. Another is granularity of path selection		(whether per packet, per flow, or per larger aggregate), which also
	(whether per packet, per flow, or per larger aggregate), which also has a large		has a large impact on the scalability/expressiveness trade-off. Path
	impact on the scalabilty/expressiveness tradeoff. Path selection must, like		selection must, like path property information, be trustworthy, such
	path property information, be trustworthy, such that the result of a path		that the result of a path selection at an endpoint is
	selection at an endpoint is predictable. Moreover, any path selection mechanism		predictable. Moreover, any path-selection mechanism should aim to
	should aim to provide an outcome that is not worse than using a single path, or		provide an outcome that is not worse than using a single path or
	selecting paths at random.</t>		selecting paths at random.</t>
	<t>Path selection may be exposed in terms of the properties of the path or the identity		<t>Path selection may be exposed in terms of the properties of the path or the identity
	of elements of the path. In the latter case, a path may be identified at any of		of elements of the path. In the latter case, a path may be identified at any of
	multiple layers (e.g. routing domain identifier, network layer address, higher-l ayer		multiple layers (e.g., routing domain identifier, network-layer address, higher- layer
	identifier or name, and so on). In this case, care must be taken to present		identifier or name, and so on). In this case, care must be taken to present
	semantically useful information to those making decisions about which path(s)		semantically useful information to those making decisions about which path(s)
	to trust.</t>		to trust.</t>
	</section>		</section>
	<section anchor="interfaces-for-path-awareness" numbered="true" toc="defau lt">		<section anchor="interfaces-for-path-awareness" numbered="true" toc="defau lt">
	<name>Interfaces for Path Awareness</name>		<name>Interfaces for Path Awareness</name>
	<t>The fourth question: how can interfaces among the network, transport,		<t>The fourth question: how can interfaces among the network,
	and		transport, and application layers support the use of path
	application layers support the use of path awareness?</t>		awareness?</t>
	<t>In order for applications to make effective use of a path-aware netwo		<t>In order for applications to make effective use of a path-aware
	rking		networking architecture, the control interfaces presented by the
	architecture, the control interfaces presented by the network and transport		network and transport layers must also expose path properties to the
	layers must also expose path properties to the application in a useful way, and		application in a useful way, and provide a useful set of paths among
	provide a useful set of paths among which the application can select. Path		which the application can select. Path selection must be possible
	selection must be possible based not only on the preferences and policies of the		based not only on the preferences and policies of the application
	application developer, but of end-users as well. Also, the path selection		developer, but of end users as well. Also, the path-selection
	interfaces presented to applications and end users will need to support multiple		interfaces presented to applications and end users will need to
	levels of granularity. Most applications' requirements can be satisfied with the		support multiple levels of granularity. Most applications'
	expression of path selection policies in terms of properties of the paths, while		requirements can be satisfied with the expression of path-selection
	some applications may need finer-grained, per-path control. These interfaces		policies in terms of properties of the paths, while some applications
	will need to support incremental development and deployment of applications, and		may need finer-grained, per-path control. These interfaces will need
	provide sensible defaults, to avoid hindering their adoption.</t>		to support incremental development and deployment of applications, and
			provide sensible defaults, to avoid hindering their adoption.</t>
	</section>		</section>
	<section anchor="implications-of-path-awareness-for-the-transport-and-appl ication-layers" numbered="true" toc="default">		<section anchor="implications-of-path-awareness-for-the-transport-and-appl ication-layers" numbered="true" toc="default">
	<name>Implications of Path Awareness for the Transport and Application L ayers</name>		<name>Implications of Path Awareness for the Transport and Application L ayers</name>
	<t>The fifth question: how should transport-layer and higher layer proto		<t>The fifth question: how should transport-layer and higher-layer
	cols be		protocols be redesigned to work most effectively over a path-aware
	redesigned to work most effectively over a path-aware networking layer?</t>		networking layer?</t>
	<t>In the current Internet, the basic assumption that at a given time al l		<t>In the current Internet, the basic assumption that at a given time al l
	traffic for a given flow will receive the same network treatment and traverse		traffic for a given flow will receive the same network treatment and traverse
	the same path or equivalend paths often holds. In a path aware network,		the same path or equivalent paths often holds. In a path-aware network,
	this assumption is more easily violated. The weakening of this assumption		this assumption is more easily violated. The weakening of this assumption
	has implications for the design of protocols above any path-aware network layer. </t>		has implications for the design of protocols above any path-aware network layer. </t>
	<t>For example, one advantage of multipath communication is that a given		<t>For example, one advantage of multipath communication is that a given
	end-to-end flow can be "sprayed" along multiple paths in order to confound		end-to-end flow can be "sprayed" along multiple paths in order to confound
	attempts to collect data or metadata from those flows for pervasive		attempts to collect data or metadata from those flows for pervasive
	surveillance purposes <xref target="RFC7624" format="default"/>. However, the be nefits of this approach are		surveillance purposes <xref target="RFC7624" format="default"/>. However, the be nefits of this approach are
	reduced if the upper-layer protocols use linkable identifiers on packets		reduced if the upper-layer protocols use linkable identifiers on packets
	belonging to the same flow across different paths. Clients may mitigate		belonging to the same flow across different paths. Clients may mitigate
	linkability by opting to not re-use cleartext connection identifiers, such as		linkability by opting to not reuse cleartext connection identifiers, such as
	TLS session IDs or tickets, on separate paths. The privacy-conscious		TLS session IDs or tickets, on separate paths. The privacy-conscious
	strategies required for effective privacy in a path-aware Internet are only		strategies required for effective privacy in a path-aware Internet are only
	possible if higher-layer protocols such as TLS permit clients to obtain		possible if higher-layer protocols such as TLS permit clients to obtain
	unlinkable identifiers.</t>		unlinkable identifiers.</t>
	</section>		</section>
	<section anchor="what-is-an-endpoint" numbered="true" toc="default">		<section anchor="what-is-an-endpoint" numbered="true" toc="default">
	<name>What is an Endpoint?</name>		<name>What is an Endpoint?</name>
	<t>The sixth question: how is path awareness (in terms of vocabulary and		<t>The sixth question: how is path awareness (in terms of vocabulary and
	interfaces) different when applied to tunnel and overlay endpoints?</t>		interfaces) different when applied to tunnel and overlay endpoints?</t>
	<t>The vision of path-aware networking articulated so far makes an assum ption		<t>The vision of path-aware networking articulated so far makes an assum ption
	skipping to change at line 254 ¶		skipping to change at line 301 ¶
	are running (terminals with user agents, servers, and so on). However,		are running (terminals with user agents, servers, and so on). However,
	incremental deployment may require that a path-aware network "core" be used to		incremental deployment may require that a path-aware network "core" be used to
	interconnect islands of legacy protocol networks. In these cases, it is the		interconnect islands of legacy protocol networks. In these cases, it is the
	gateways, not the application endpoints, that receive path properties and make		gateways, not the application endpoints, that receive path properties and make
	path selections for that traffic. The interfaces provided by this gateway are		path selections for that traffic. The interfaces provided by this gateway are
	necessarily different than those a path-aware networking layer provides to its		necessarily different than those a path-aware networking layer provides to its
	transport and application layers, and the path property information the		transport and application layers, and the path property information the
	gateway needs and makes available over those interfaces may also be different.</ t>		gateway needs and makes available over those interfaces may also be different.</ t>
	</section>		</section>
	<section anchor="operating-a-path-aware-network" numbered="true" toc="defa ult">		<section anchor="operating-a-path-aware-network" numbered="true" toc="defa ult">
	<name>Operating a Path Aware Network</name>		<name>Operating a Path-Aware Network</name>
	<t>The seventh question: how can a path aware network in a path aware in		<t>The seventh question: how can a path-aware network in a path-aware in
	ternetwork		ternetwork
	be effectively operated, given control inputs from network administrators,		be effectively operated, given control inputs from network administrators,
	application designers, and end users?</t>		application designers, and end users?</t>
	<t>The network operations model in the current Internet architecture ass		<t>The network operations model in the current Internet architecture
	umes that		assumes that traffic flows are controlled by the decisions and
	traffic flows are controlled by the decisions and policies made by network		policies made by network operators as expressed in interdomain and
	operators, as expressed in interdomain and intradomain routing protocols. In		intradomain routing protocols. In a network providing path selection
	a network providing path selection to the endpoints, however, this assumption		to the endpoints, however, this assumption no longer holds, as
	no longer holds, as endpoints may react to path properties by selecting		endpoints may react to path properties by selecting alternate
	alternate paths. Competing control inputs from path-aware endpoints and the rout		paths. Competing control inputs from path-aware endpoints and the
	ing		routing control plane may lead to more difficult traffic engineering
	control plane may lead to more difficult traffic engineering or nonconvergent		or non-convergent forwarding, especially if the endpoints' and
	forwarding, especially if the endpoints' and operators' notion of the "best" pat		operators' notion of the "best" path for given traffic diverges
	h		significantly. The degree of difficulty may depend on the fidelity of
	for given traffic diverges significantly. The degree of difficulty may depend on		information made available to path-selection algorithms at the
	the fidelity of information made available to path selection algorithms at		endpoints. Explicit path selection can also specify outbound paths,
	the endpoints. Explicit path selection can also specify		while BGP policies are expressed in terms of inbound traffic.</t>
	outbound paths, while BGP policies are expressed in terms of inbound traffic.</t		<t>A concept for path-aware network operations will need to have clear
	>		methods for the resolution of apparent (if not actual) conflicts of
	<t>A concept for path aware network operations will need to have clear m		intent between the network's operator and the path selection at an
	ethods		endpoint. It will also need a set of safety principles to ensure that
	for the resolution of apparent (if not actual) conflicts of intent between the		increasing path control does not lead to decreasing connectivity; one
	network's operator and the path selection at an endpoint. It will also need		such safety principle could be "the existence of at least one path
	set of safety principles to ensure that increasing path control does not lead		between two endpoints guarantees the selection of at least one path
	to decreasing connectivity; one such safety principle could be "the existence		between those endpoints."</t>
	of at least one path between two endpoints guarantees the selection of at
	least one path between those endpoints."</t>
	</section>		</section>
	<section anchor="deploying-a-path-aware-network" numbered="true" toc="defa ult">		<section anchor="deploying-a-path-aware-network" numbered="true" toc="defa ult">
	<name>Deploying a Path Aware Network</name>		<name>Deploying a Path-Aware Network</name>
	<t>The eighth question: how can the incentives of network operators and		<t>The eighth question: how can the incentives of network operators and
	end-users		end users
	be aligned to realize the vision of path aware networking, and how can the		be aligned to realize the vision of path-aware networking, and how can the
	transition from current ("path-oblivious") to path-aware networking be managed?< /t>		transition from current ("path-oblivious") to path-aware networking be managed?< /t>
	<t>The vision presented in the introduction discusses path aware network		<t>The vision presented in the introduction discusses path-aware
	ing from		networking from the point of view of the benefits accruing at the
	the point of view of the benefits accruing at the endpoints, to designers of		endpoints, to designers of transport protocols and applications as
	transport protocols and applications as well as to the end users of those		well as to the end users of those applications. However, this vision
	applications. However, this vision requires action not only at the endpoints but		requires action not only at the endpoints but also within the
	also within the interconnected networks offering path aware connectivity. While		interconnected networks offering path-aware connectivity. While the
	the specific actions required are a matter of the design and implementation of a		specific actions required are a matter of the design and
	specific realization of a path aware protocol stack, it is clear than any path		implementation of a specific realization of a path-aware protocol
	aware architecture will require network operators to give up some control of		stack, it is clear that any path-aware architecture will require
	their networks over to endpoint-driven control inputs.</t>		network operators to give up some control of their networks over to
	<t>Here the question of apparent versus actual conflicts of intent arise		endpoint-driven control inputs.</t>
	s again:		<t>Here, the question of apparent versus actual conflicts of intent
	certain network operations requirements may appear essential, but are merely		arises again: certain network operation requirements may appear
	accidents of the interfaces provided by current routing and management		essential but are merely accidents of the interfaces provided by
	protocols. For example, related (but adjacent) to path aware networking, the		current routing and management protocols. For example, related (but
	widespread use of the TCP wire image <xref target="RFC8546" format="default"/> i		adjacent) to path-aware networking, the widespread use of the TCP wire
	n network monitoring for DDoS		image <xref target="RFC8546" format="default"/> in network monitoring
	prevention appears in conflict with the deployment of encrypted transports, only		for DDoS prevention appears in conflict with the deployment of
	because path signaling <xref target="RFC8558" format="default"/> has been implic		encrypted transports, only because path signaling <xref
	it in the deployment of past		target="RFC8558" format="default"/> has been implicit in the
	transport protocols.</t>		deployment of past transport protocols.</t>
	<t>Similarly, incentives for deployment must show how existing network o		<t>Similarly, incentives for deployment must show how existing network
	perations		operation requirements are met through new path selection and property
	requirements are met through new path selection and property dissemination		dissemination mechanisms.</t>
	mechanisms.</t>		<t>The incentives for network operators and equipment vendors need to
	<t>The incentives for network operators and equipment vendors need to be		be made clear, in terms of a plan to transition <xref target="RFC8170"
	made		format="default"/> an internetwork to path-aware operation, one
	clear, in terms of a plan to transition <xref target="RFC8170" format="default"/		network and facility at a time. This plan to transition must also take
	> an internetwork to		into account that the dynamics of path-aware networking early in this
	path-aware operation, one network and facility at a time. This plan to		transition (when few endpoints and flows in the Internet use path
	transition must also take into account that the dynamics of path aware		selection) may be different than those later in the transition.</t>
	networking early in this transition (when few endpoints and flows in the
	Internet use path selection) may be different than those later in the
	transition.</t>
	<t>Aspects of data security and information management in a network that explicitly		<t>Aspects of data security and information management in a network that explicitly
	radiates more information about the network's deployment and configuration, and		radiates more information about the network's deployment and configuration, and
	implicitly radiates information about endpoint configuration and preference		implicitly radiates information about endpoint configuration and preference
	through path selection, must also be addressed.</t>		through path selection, must also be addressed.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="acknowledgments" numbered="true" toc="default">
	<name>Acknowledgments</name>		<!-- [rfced] Please provide text for a Security Considerations section per the R
	<t>Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kuehlewind, Oliv		FC Style Guide (see section 4.8.5 of RFC 7322 <https://www.rfc-editor.org/rfc/rf
	ier		c7322.html#section-4.8.5>).
	Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood, Lee Howard, Mohamed
	Boucadair, Thorben Krueger, Gorry Fairhurst, Spencer Dawkins, Reese Enghardt,		In addition, please consider whether an IANA Considerations section should be ad
	Laurent Ciavaglia, Stephen Farrell, and Richard Yang, for discussions		ded. While the section is not required in RFCs, IANA prefers that a section be
	leading to questions in this document, and for feedback on the document itself.<		included to clearly indicate that "this document has no IANA actions."
	/t>		-->
	<t>This work is partially supported by the European Commission under Horiz
	on 2020
	grant agreement no. 688421 Measurement and Architecture for a Middleboxed
	Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and
	Innovation under contract no. 15.0268. This support does not imply endorsement.<
	/t>
	</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC4655">
	<front>
	<title>A Path Computation Element (PCE)-Based Architecture</title>
	<author fullname="A. Farrel" initials="A." surname="Farrel">
	<organization/>
	</author>
	<author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur">
	<organization/>
	</author>
	<author fullname="J. Ash" initials="J." surname="Ash">
	<organization/>
	</author>
	<date month="August" year="2006"/>
	<abstract>
	<t>Constraint-based path computation is a fundamental building block
	for traffic engineering systems such as Multiprotocol Label Switching (MPLS) an
	d Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation
	in large, multi-domain, multi-region, or multi-layer networks is complex and may
	require special computational components and cooperation between the different
	network domains.</t>
	<t>This document specifies the architecture for a Path Computation E
	lement (PCE)-based model to address this problem space. This document does not
	attempt to provide a detailed description of all the architectural components, b
	ut rather it describes a set of building blocks for the PCE architecture from wh
	ich solutions may be constructed. This memo provides information for the Intern
	et community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4655"/>
	<seriesInfo name="DOI" value="10.17487/RFC4655"/>
	</reference>
	<reference anchor="RFC8446">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla">
	<organization/>
	</author>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Securi
	ty (TLS) protocol. TLS allows client/server applications to communicate over th
	e Internet in a way that is designed to prevent eavesdropping, tampering, and me
	ssage forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077
	, 5246, and 6961. This document also specifies new requirements for TLS 1.2 imp
	lementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>
	<reference anchor="RFC7285">
	<front>
	<title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
	<author fullname="R. Alimi" initials="R." role="editor" surname="Alimi
	">
	<organization/>
	</author>
	<author fullname="R. Penno" initials="R." role="editor" surname="Penno
	">
	<organization/>
	</author>
	<author fullname="Y. Yang" initials="Y." role="editor" surname="Yang">
	<organization/>
	</author>
	<author fullname="S. Kiesel" initials="S." surname="Kiesel">
	<organization/>
	</author>
	<author fullname="S. Previdi" initials="S." surname="Previdi">
	<organization/>
	</author>
	<author fullname="W. Roome" initials="W." surname="Roome">
	<organization/>
	</author>
	<author fullname="S. Shalunov" initials="S." surname="Shalunov">
	<organization/>
	</author>
	<author fullname="R. Woundy" initials="R." surname="Woundy">
	<organization/>
	</author>
	<date month="September" year="2014"/>
	<abstract>
	<t>Applications using the Internet already have access to some topol
	ogy information of Internet Service Provider (ISP) networks. For example, views
	to Internet routing tables at Looking Glass servers are available and can be pr
	actically downloaded to many network application clients. What is missing is kn
	owledge of the underlying network topologies from the point of view of ISPs. In
	other words, what an ISP prefers in terms of traffic optimization -- and a way
	to distribute it.</t>
	<t>The Application-Layer Traffic Optimization (ALTO) services define
	d in this document provide network information (e.g., basic network location str
	ucture and preferences of network paths) with the goal of modifying network reso
	urce consumption patterns while maintaining or improving application performance
	. The basic information of ALTO is based on abstract maps of a network. These
	maps provide a simplified view, yet enough information about a network for appli
	cations to effectively utilize them. Additional services are built on top of th
	e maps.</t>
	<t>This document describes a protocol implementing the ALTO services
	. Although the ALTO services would primarily be provided by ISPs, other entities
	, such as content service providers, could also provide ALTO services. Applicat
	ions that could use the ALTO services are those that have a choice to which end
	points to connect. Examples of such applications are peer-to-peer (P2P) and con
	tent delivery networks.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7285"/>
	<seriesInfo name="DOI" value="10.17487/RFC7285"/>
	</reference>
	<reference anchor="RFC7624">
	<front>
	<title>Confidentiality in the Face of Pervasive Surveillance: A Threat
	Model and Problem Statement</title>
	<author fullname="R. Barnes" initials="R." surname="Barnes">
	<organization/>
	</author>
	<author fullname="B. Schneier" initials="B." surname="Schneier">
	<organization/>
	</author>
	<author fullname="C. Jennings" initials="C." surname="Jennings">
	<organization/>
	</author>
	<author fullname="T. Hardie" initials="T." surname="Hardie">
	<organization/>
	</author>
	<author fullname="B. Trammell" initials="B." surname="Trammell">
	<organization/>
	</author>
	<author fullname="C. Huitema" initials="C." surname="Huitema">
	<organization/>
	</author>
	<author fullname="D. Borkmann" initials="D." surname="Borkmann">
	<organization/>
	</author>
	<date month="August" year="2015"/>
	<abstract>
	<t>Since the initial revelations of pervasive surveillance in 2013,
	several classes of attacks on Internet communications have been discovered. In
	this document, we develop a threat model that describes these attacks on Interne
	t confidentiality. We assume an attacker that is interested in undetected, indi
	scriminate eavesdropping. The threat model is based on published, verified atta
	cks.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7624"/>
	<seriesInfo name="DOI" value="10.17487/RFC7624"/>
	</reference>
	<reference anchor="RFC8546">
	<front>
	<title>The Wire Image of a Network Protocol</title>
	<author fullname="B. Trammell" initials="B." surname="Trammell">
	<organization/>
	</author>
	<author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind">
	<organization/>
	</author>
	<date month="April" year="2019"/>
	<abstract>
	<t>This document defines the wire image, an abstraction of the infor
	mation available to an on-path non-participant in a networking protocol. This a
	bstraction is intended to shed light on the implications that increased encrypti
	on has for network functions that use the wire image.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8546"/>
	<seriesInfo name="DOI" value="10.17487/RFC8546"/>
	</reference>
	<reference anchor="RFC8558">
	<front>
	<title>Transport Protocol Path Signals</title>
	<author fullname="T. Hardie" initials="T." role="editor" surname="Hard
	ie">
	<organization/>
	</author>
	<date month="April" year="2019"/>
	<abstract>
	<t>This document discusses the nature of signals seen by on-path ele
	ments examining transport protocols, contrasting implicit and explicit signals.
	For example, TCP's state machine uses a series of well-known messages that are
	exchanged in the clear. Because these are visible to network elements on the pa
	th between the two nodes setting up the transport connection, they are often use
	d as signals by those network elements. In transports that do not exchange thes
	e messages in the clear, on-path network elements lack those signals. Often, the
	removal of those signals is intended by those moving the messages to confidenti
	al channels. Where the endpoints desire that network elements along the path re
	ceive these signals, this document recommends explicit signals be used.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8558"/>
	<seriesInfo name="DOI" value="10.17487/RFC8558"/>
	</reference>
	<reference anchor="RFC8170">
	<front>
	<title>Planning for Protocol Adoption and Subsequent Transitions</titl
	e>
	<author fullname="D. Thaler" initials="D." role="editor" surname="Thal
	er">
	<organization/>
	</author>
	<date month="May" year="2017"/>
	<abstract>
	<t>Over the many years since the introduction of the Internet Protoc
	ol, we have seen a number of transitions throughout the protocol stack, such as
	deploying a new protocol, or updating or replacing an existing protocol. Many p
	rotocols and technologies were not designed to enable smooth transition to alter
	natives or to easily deploy extensions; thus, some transitions, such as the intr
	oduction of IPv6, have been difficult. This document attempts to summarize some
	basic principles to enable future transitions, and it also summarizes what make
	s for a good transition plan.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8170"/>
	<seriesInfo name="DOI" value="10.17487/RFC8170"/>
	</reference>
	</references>
	</back>
	<!-- ##markdown-source:
	H4sIALUe8GEAA71c2ZIbR3Z9z6/IaD2oGQH0ULSkoVsPcpOiKM6IEq1mmGE7
	HI5EVQLIYaEKqqVBaEL/7nOXXApAa+bJD5rpJlC53OXcc5fq5XJpxjA2/ta+
	nPret6P9ee9b+++TH8bQtYMNrX3nxq29O7je25/8eOj6j6HdGLda9f7h1r67
	+8n+Gr9u6q5q3Q7L1b1bj8vQj+vl3rX9Zpm+s/zimand6G9Nhf/ddP3xFrus
	O2PCvr+1Yz8N47OnT//16TNDe236btrfXj6E/eW1+eiP+K2+tW/a0fetH5ff
	0dbGDKNr6/91TdfiOEc/mH24tf89dtXCDl0/9n494Kfjjn74H2PcNG67/tZY
	u8R/Fkcabu2LG/u+d7udbxr+R7nbiz64dv5B129u7euu2zTe3h/C+JvvG2xv
	X+9WP/AX/M6FBhf14/rfRn3yptryZwMO40c8j5u7h+XrqWmW7xo3/ma/4M+r
	MEJGz58+/dL+19QHfarqpnYk4RX7GdN2/c6N4QHiNSTV/NtyubRuhb1cBem8
	abEAnnfDaMfOjltv970fyAKiIK3rq20YfTVOvV9YZ/fQwdKxDoJ+J1lD8VW7
	dYPFJzbs9hC0w5L7vtv7fgweMg2j9Z/23eAH3TV+ZLu1cQ8Qk1tBiukUtOtA
	Z/Rtve+wMdRGosWDD6HGY7hk/ow+Mm6/bwKsiy0YT06Dp72G2W7498E3OHLc
	YQtL22z5UGlzrG3wD6GHXbr1OlQ39sM2NLRcGOJqR5zcXtEqlqXT+mG4sq7p
	vauPuGwYRnaknWuPJpkpxN9id19bleNgocgtvjdAotii7mAzLd/IPgRnXb0L
	bSAFkkYNq2DtKrkKnVrXsY07+p4UtoYlHR9TG2kBSw8iGYPjVH5PAqz6bhhk
	Edlc/6UUzI0x70kC8PdpR0YjCv21xI1i32wptiN8caRs++zpsy8WWNaNZgfT
	tyuP7YaD7yETPE/7Qb9h0y7w/w++6fa0lWi/9vumO/LWWClvZcorDjf2zWgP
	tFsfNqF1JI5DH8YRZ4DQ1nBE7BGGahqGeGzaNqONKdCG1I1r1vYXCIws3r4m
	cLLXwMBfXj+Rg5HxrzzW30+rJgxbfJ0srXX7YduNplKYJUXzorwjJDnsocob
	cdNdqOvGG/MZybvv6qkiodI6dLDlGQz+/bNA3/ud3ZrOH3d5xJXPjCU7k7Nm
	BR0u/RqmP8JD+odQ+Whh2c2mgQ8PbZDRdtNoH3wf1sGtQhPEI/CAmXm3+DuJ
	doXNSUZjW6yZXQsWYAuzkTMaHH/bdk23Ye+F1VgHRe72ZDj4oV/i39plefra
	N/CU/ig3njmMETygXTZw2J5NY+5hbKV70XgBP0tBr9pe+5vNjZiKednt9tPI
	iGNfNZ7t8vrdy1dP7N///u0v37/88uuvvvr9dzaQ+249kgKX3/l1aLHOBwje
	3gEsokqtub7/bvnh7qcnFkjWd67CWdW8cOwjnxqrQICA7BERYVQrY+AwJ9dQ
	HIEvqKmd4HprC7y0Ff0+DPBqlbGBYX6ECZGeYR4bLNmSX47wJ37C1TWOQejV
	NBZ+2o4TSxPuDC3gqjWfjn4QZy8eXtgVTAcWAw5ifTOQB9wR1rYDxY5snYjb
	XWOHCU4Htbx/+Y4PqmYLMTTZ8qBxvuclQxYhuryiW+H7l9BTtzLv01l+5LPc
	ezgX7XP9/sf7qN7nX375NdTLsgOPgAhInLJu73fd6E00nxv7Q3eAlLCFXHth
	wxqngpHCsKAGxMcUuEm6K3Ku6DmG1Jdi5KlX6u3ao2hwL1C8c5BQXMZJuDNi
	PnVn2260266pb6x9zy4xdDs/hh28ZOsgGggudNNAwRzEAR4hCFOYzMK4BJyV
	wwpsKS9ev7Pb8DfYDgEFPBU/DdDui2MiHgt66o9oxYmlZvSBoI0GbwR/iKuZ
	fFv5JKbr4cksnkfdTuS3qyOLiA05GjdWWTfd4YZkkL7N/jY3xSEpqTkqjSm1
	ZebaomWFXDyuM9mlOxXqYPqpbTlgsmR3xFpFfwwBZGo791GJiMgCj8kF7gp/
	ZqslKyb2AnYP1Ybf5KPrux/f//wk+4LY8p+fPf9KbXlF6pdwjd/8J7fbA14A
	5KXSiO0knCIzEfjTGB7FtxRPhnp30YbMGeHMfk7WAmNhcE2Xy1EqecpDGIL6
	PcmRLQvP44hRieDWbmQ8BujPiCE9AIPoU2jSR0iGpUztBZ8rV1rkW7ID/gla
	n0dXwgOOgdCeJyllMKAbmnhsUS5bIp9umFb8c0PsBw/RAYaCF8k9D3l/EyWo
	AZKUSA/3buPtbmrGwGap1DM8sNyE3YEF/Y2ONGfDpiR9C0Z3AVgXWep+exwg
	iCaHVyDJB0CgjXHyRO4L8gqJp0sRf/RUrHkcENHpfOuwmXox07TwQqArSauB
	bEQcw95XIB9q8pAKvkPxjx1MESvei4Ss3gBGNjW1wa+40oD114wmlDkK56GD
	IM1CsgFApVg6TP2DR5zjLyjmRV1XHeii+tDXz778/XcY8AdPAOuj4/5/5QwU
	62vv6wWUDnOL1ItSPwRBU7iHb8GLPTAeSCOcDkAKrjo1Gn5iDP6XhAguMGDh
	Rz6/4fNfLUQc+L4keBEkSXAbSsNU5iQHIBvbc4RArOYSHkMieqeZT757PEoA
	oz5KhvgJQa2W4F9gkxo4i8auSJ+uJ2+MzBUwBN+hlbAGWTduPFA4poSIwc+w
	hwVh4ZGGHs+TIAE0YtGR8JPsOeWZpUaZ8YvImDpBDbDF7jQN6sCf2GFgGk34
	zf/zEfMbqIIIwywTWU89EewLuY9KnYAHUhmIVz2eC81TICEes62YBDD/Yd8m
	h/TtMCnYggVyYQci/Owzy0w4SNgz31PQnHpJKPnLhYgXpc8UaeUVIWLVhxUF
	B7UrQ5cjdR6zA5TZSAQERFMqEJDvV91uN7URR9RwwDVKKctd4yaW1JLSs/Mi
	A1Po9doTdcKFRy6WSIyo3egEute+v7E/zXGCuSSxOYWEumNGtt9L6kosTewd
	Kv4nkr5vVI5J0in9Txkp2XUgMzUqHJsFSCcBFIV9xAUCR5HOpWSj9DIqyCBJ
	VoqT+RRfriAqseAwzvkRLOQVnzRxodk1qMxRmkSpqSuyyK5loD5sqW6WtDYz
	DX68UNpMv5kGJJNRFmkipAEokHluhFqWh+dErcDCYdrT1QmXe79BPtQQPmmq
	HGNYEdvVZoUTrcFjoMhBrqJsQMVR6slkMki5FAvnSkIbrzdzLTLXLEyAHnEd
	LRLiwLWmqIyBg/9VWDYRwBrM3itbQOLGlG8QaiDnI5Riaq1hgxW/o9JLvTAH
	TvGFyCSDTAFRl2P1ZbRd1h62X3tiTXfDHBYI5UjzraSaXI0qEBe2ueWkkH2K
	oFUpdRg11x2y55niSIzLK8rhkhz2rh+jbvJadh16qqQeuhLowcdI1IsiiXvo
	KreCEz1ueVsQvpTlQ7OD31Gy7GuoM6EuLtvZR8yeHIXNYZBUkEEEdIkMbOQq
	q1gYvkfpd2hq/olxHwdxHAkfWXuwakbxd1M6yyB5nkYaErFy6UsREjadPcv0
	8WZZfMQKtLRQhkHOelx5wAx4hmPkSJH5s9zEILlR6Iz3Oi9K9jDt0LMCSKPK
	SAafw3c8n0nnO7taLGmXprdg16F8RgiGwAJVlcvIK+bBis9hfs4NI9nMXFzz
	xhrnrkaznrj0nsQoZY+hpFKPtFBmgVzi8Z39j5mZ8pPvkpkS7YkWH296y8en
	tTXhZdI8t+6EJvis92oKvv6Wy5aiXyHgp9WP1AJY+SKr4JxULU/EoRiXYT6a
	C8V35R3l8gwA0CE4NURMlyWB8inZQHc7pPSFx65TPp9Sltaec4PToieBET/G
	2bnJaKnkptihooQES1bNRPQL2XIQ9Iv0ZI94ps+KD5iTHaOQVRbYOj+VowBl
	pKorzsfIIpFtyuXS2jdaEiqW37mjAGLD8Z6CGpU9q1QwKzJ7DRVaMmw73Ahb
	xZLyemrV+3N+9g0tcPCMVsUepj62bneySSIuD66ZRNQ7T8XQIX2rEfpWg1sg
	NlSJsBcCZ95K3Czao9hd7EdEaVawbO6msEPTAxqlDYcIrpSdVMgKoXGlmOt7
	hGYkDfwfLoO0WauW+EXrik9MIbN/kujfWCLNWp9Z5Dya7V2bbYbkv5RKQulh
	0SLGbi+GFk2bCxUxTTywXe7cJ6oeeXO5QBlA0h5CPbnmxFJTPeyU3OGsI5cY
	cEhkB2wvcFjpi9B9XZMLOfGAIOgU3LjGzPkG7EI4B4zTrJjuUeKOD8achqwo
	uyUg3XSu4VOVF/x80NjXgYl/LynSDvn8ouxgsEEK9Pzjq5KjCC1EqsXMCYTK
	CI8+AjZD9ZFr5BUReUiw5hCfi8NusyGOKGnpWZ/08v4cDgDHDSfXy7Fb+jk4
	XHB/4J+hGjA85yG4RhOySCgX9CM+Wk1KtrHee+rQQ2gUWJS/XgwQsOgOX59H
	iLo7KX3OSnIbCuIVgTHje1VRDQhKAH7D+zTmpe2PpxEGkeRnQp35Dom6sJfC
	ObaOUusTXI/OqRyh0Pu8X8bIIJVx0hwgZ9sJ2tZJUqyyiPpm3nOeJzcIv2Ue
	QBIq73ScuSpx07gH5RDzOrJyGFxQz0QSLJoR5sSKlkuJdhJkUuoJ4qnNUjL1
	dd/tJKbhKUrstPzJh8xPcFLRU7yF/bzcdoGabPh2XRiPaDsfiGGWT6qtowsg
	agqIzGFJEXGOgO+A9YEyojogus66uVJoId5bHifuHYNtaJcrbrUDW6hMMY3L
	bs3/tMD9hm38AClwY9LPXO5YInRK9UFMdOisluK1kUltyq6nIimyDa08zYzj
	WDB9lpWEQcQMTgulcU0PaSS0pXnCaKX3YXbeDZCGtMVh05x4pqLo+bMxnEf8
	iQks9X/MKVua18EvQDmFUkJtqYcMuct7cjLu38+uWwNZj3wY/2kbVkEoH/d6
	qbS88rCNoDRlapup+ni0avYhsgeqZ2Hz1EgHjN1Lvk3+yAh1HzNjASgAWH+K
	T1VBKoeTAZEu1Yli5s/9qwOiTqq2c6YLiMiyTNTwgrhOmz5agqXMCVh2l5Dw
	DzBPahwwj61r1jECIfAguaLYE1qD6zk2U6YNj3vQq3TtNI2hDQ+ZnwH8zKyh
	yMlmciIBpWJGlBTDBPhVzcl7jMpmbgbnGfECVxE04S6mTpUURZkSQQwCe6co
	3yqSRDaGc9S+W6+TUZbIwjnsjJwx2JhHRfUz8PIjdeH4cJb9PGSDj1BC1ZgC
	R8r21PwaEApiMNUosMqmdy3FJcW8+TfN9WHr+Zt7+o9LLAv+mTpFzOXpFzy+
	oS6Nkgj/JFIkFRElpfwdMxdTlMp4/NOJQKIAdeKh0MBEndwmfNSocCl0LZJf
	iBErkY8BhNLWqRmLpCYvT/XT7JJcY0b0BrUj47yxb0HSOiFM7fHcOIiBhWFn
	pNNjXdhxeUjHBrAw1MMMTMBu4HY4zsgGj4/FH3OzS/OleD4lC1y1hNbqbnfe
	tFSIjXkr4ZU0QS/VpMvOMVPqmnuHR0oK5nmj1wxNJ34amoXpuf8eR/XizrLG
	OlDmPbKYEAqlGdj4WHaVYRatUMcqbnoS4p13NLUws7DbsIExSnfX5O/T+WlY
	soiHT/IAipyScqoENSPS9FZ0w2kYJLxzTBQo9An/mwUjJiLEsTRfqAE4ZTVF
	zF2HAUzEUIkLb/IkEIFVLoyQpWt1o6Mk4EJwKKaI3K5Tcp4xftYJNhfq21oD
	5se0LDGv9JyWQ06HGbmg4bmlQAV3XWOG648MZkoIiiBUXCSVYk5i1nwCwugN
	WGWMIzoAcRqRzqcZJFCqFhEvRTrJDeMnWnBTl2LpihpPlyNFiIdpB30OR2RQ
	+8gHV47cjvyaw2TKzv0aqN1WWnVFbgmulJxwpjkdPiQvoGklcsXUu1aiBgCH
	QBbZfzNgX5QzcfPTWQSf5hFSO5BjqxpM9FjDOTwftIgUhISklmLRz2NKIKiR
	2rdjGBgMUhCOSF9E4GLmIgqmBK7LoDVwkMEJOTOa3Y+giC9E5ZR+uaHWPKUw
	WGUZRxLIKmPFKQvNXBQGGK/cC+ywmA29MBo6Hz0ozY76kZIx+LWDcCnRg1oe
	ulAD1tpamuIjT/+6uttrS4XwY1dcLaa/CUBSlv1+1us6G8pJddT1GdBouDqd
	nuH2AAPuyWAcUQ+DsMg1KZGUJKtkEwkrmmOc3bhcBec1v310iFSsG+5EXfw0
	X6YtzjHVrCh3oIZDao8xiOmHPM7CGu195YOO3g3Uij4f2FH04dkMk74XwyPZ
	9oNrvBaaB52IpFk2mXWc9QgiQhuZgMzHx29U6LHITwIEhDSjkUoM6ebgKSxx
	51FrtflJQywqlJYQ9Z4beFk/MmcYOcpc9iL4G2l9pyoeNS5d/YAgSMM7VBgr
	5nfKNnWIbWYdoShKPyxudfyrYd9jn5qmTAhZEwMQ6ZV0Po69GB2wHeQfuV8j
	bWscFMzb8c9cI5BYvOaJnLWQ0AdH5NHMRmZS93E2J5OrXmxh8KJ1KOrjabiM
	ZhBg5VNFPEpwB3gQ6UchbQqKTWg/cgKTWQmXFYQz03QoiUGnPpJ1yexVHIla
	c4wYY/X+ZRMYSgnNdmEMxKyN7COJBMIn4YSsSSGn9xQnbNV414/+05hGr7qS
	XQ3FuOmP9wAmAeM330m7LfCBySLwESW6Y9lPwLXhB9WRhoOGimY1DXfj/UZq
	lhwCpEKVWYM+czaAWcwOeI6XJsVRCLwke4W001Quzr6nahKuqZKigZoVFY4o
	bb+gEMHTD0q+YagxCf1Wa4jh0xk4Ugow741dl7FpXtwvwu+TQqEHGlDj0KC9
	ShlJ4h6oDADlVF2P8hDKCHmOntThqyapEIMbrV3PVI1vVaBGGsEtg2jsM5ft
	3tkrL6R7TeDKGVE6QpwTvZZCHhW3ObITlUACKH0farqwnZV0PHqdmUfTFD3J
	zGNVURHmAnhd0dzbFZ1+0mk/FrkaOrTV8JgJ5NYgFYXNpYmG4i2NNvaqHPfL
	pS1H3IRc7MDjWFykPuGBRTmFDxiDyqW+OinDzMlNhOw8EigeNaNsTBaUGVN2
	LgdiLIp9Qwoc2bY4cRQ8/MNIm8dZqaEARPpHszG5ZvR4jbiQGZOmfPeyeKcz
	8t2MabG+mdezJep1xEN/ToMB7kIfOdb7afb/Us50KRJn6LkwZkBdnBlt4e2J
	MAqNyDnMfoJzcARKOUseSEIevzhh8kyQoigT41YXj0voGAQT167mhtk/nrCa
	TZJk8sMRke6nZ25yllWkrGUGwpWu1TGexsTGlAwTKFmXSgLLTJN1Lb/2Tn+P
	uXzCaXIz49IlxfrSrEdm/OdvFWxzeJ5ToLazFERhTEy75IC5jMj4QdWlOKxS
	uOTqaFMRxbiGm305rtH7NH6USZZzVRdOdTJHL/OGvGZ8cA/88XwWBGFGVeZ7
	ZOCE13kauByFpfJF12IJXJsg1OibLDwpU9TklYWkU3xejNFAY58TamnUoO9d
	0SspV1LiIuhRxqwHqAPvhoBK0zk0zkw9Q4Gk2m96zzQwHVwK5jIVZTmyUDJB
	7zxJ4bCEBXkHpBxiP1G6azYd8sjtbkgt2dykehXH7U8eYt8mwJBy75GKnSud
	l87pIL8KkqxbR+KyDafAHVp5NkIxTa/pW4lp8uIEQwpHnaWJXANm0hULxCaS
	cxr2baaoFICDY5e+hiYpwsBaJ9c8SQ1kPRnNWc76Ged94zk4P1bAlDcS6aws
	OJ751bLH4NZ+pPCIcEzEXF96pbZJnFxBmHapRZlcg0dD6fBk4IabeumL5aj/
	N5xTMFs73UsHTyhNkHY8AJSKIzyMwAsPIz89f33vUFKUzQRqCknpKwqzwUnY
	1GNrcBTKxnalE8HEQv443niw0YvhRmYRaDwRDjWUL4Mkx4zwL1UcCjeuSalz
	nMAaz1jf2dzxIo3s6cblpDhjVYwZ1zzbuOxWDXQBkn71JHrhOT1YEV614G71
	nHvm+lGItyxeD9WJMj9cPiofR5rAXEknqhz8IUJTyrpcVfWTvLN1GgfYtDSC
	UhE5E5Yi0T3t6RcTPTmylC/eQP+zF0Rm6SBN68jl84yeXDdV9E7PSUU6aQUV
	w28lJy1fn+iI5pwMPJY+oy+lSvkhNrVigzMlV0767lKDV4FqFYDDcnwpKrW5
	XB73FWvLn5Qnmb8QFXmxAJtOsx5tfgljzke0zCL8/dwDoIwNF5D3MsmQm1P6
	xnuW0YPvy2xkWfcXWBjw+oc41Rt9cgax2jMXhL0IsGDSZL5uA/5yayodObgA
	9rPCJtPW/Z5kQkEFXu8aqdRygwFnosGbquK0MxUsH+H40V0je9LBd/gizxkX
	ZGpWrImjQde8rQ5HJw+/ABsEFQci/3sa788Dip7fbT2QysKOCj/6gulX/IJp
	IY1d1wbokR0bJ/nuu+6exu6IgnPUYYEMl2eh5hVS4Hx/3HPGGf2Ziw0NDVNV
	booVfjJnmCq9b65n+uo5zpReeJdaGL++emGXPdD/EmDAbO7DDrykp+G6ArZ5
	pKZIRqmuPxDS0n8coOgo58ZhZsYhJjCmqTZ6Xe40QOcZqZMxDJMaiMONAPHJ
	+R6JK9hfytHQRk3/GnkJA3vtDXvwYsZ+HBNVafanCKKC/uLPT/nl8fnfb0Cm
	XYSPJACpHJYdHFi59rkphaf6rM4u645lzMrNHerIyZw5fIf+1khu1+ogyTAP
	i6aINZ7Umd50Kta/5srLGlqYM3fJk8Ry0vtuNtte1NaT2NW8mG+TE/Zxlbwr
	Uck0/S4FzDhuqWlTyZSjs0uGmqSts5T6LodBnhWwm1aPLw9EZpJYGLIOAuQX
	HKUrEb0HYktLn6+a+uDzVyTFhGNHy0Rjn4tuUSiXCI+0cPm9gs/sXfWx7Q5I
	TjfsN8a8pdBCopVX6+5q/qM373zfB8DXX7xrl+8CfvP2fheoK/429H9z9q+T
	3zb+EGhq6meiOr43L7rW8Z8FoBbkW56Eh/11u4HOdL89gKE7+wJb0RtDC/ty
	izBgP3QdlvgROc8P/KcD8GS3dTvQ5RfdVLnaBTgQVulBXOxf+8lviDC87vr+
	aL/Hh9upp7mE+z1JBPjoDjBM4NovnupMr9rNFouOC/Ojm9iKXgakR5smODwz
	+j1Z6fcO12t07PCXUNET9j8dwbfO+8UJfiK3tZZ9z1/0yy+vxSH1NfBghYge
	u5HpJQIQMN+s45yy1EnknRPJN9MbRLGG8Goi5IJmkDHvgtSNJ+pdQWx9+A2/
	PXv67KmhTiFUTzkk79N2N/br58+/fPaFfXsymXVXcgjp3bzlv0ey6j5B+sk3
	r9/evX2jf5VCD3N/wAkgPkrk7ykHGaFQJ9nbK9BUNff4yoEY/pu27R7EjOXg
	8ucBKjnkF1/dPH329fP4Tra2/1LGQ17DpVoa2dhxuer/AMaY1nTUSgAA
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7285.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7624.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8546.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8558.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8170.
			xml"/>
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed.
			Note that our scripts did not find any words of concern.
	-->		-->
			</references>
			<section anchor="acknowledgments" numbered="false" toc="default">
			<name>Acknowledgments</name>
			<t>Many thanks to <contact fullname="Adrian Perrig"/>, <contact
			fullname="Jean-Pierre Smith"/>, <contact fullname="Mirja Kühlewind"/>,
			<contact fullname="Olivier Bonaventure"/>, <contact fullname="Martin
			Thomson"/>, <contact fullname="Shwetha Bhandari"/>, <contact
			fullname="Chris Wood"/>, <contact fullname="Lee Howard"/>, <contact
			fullname="Mohamed Boucadair"/>, <contact fullname="Thorben Krüger"/>,
			<contact fullname="Gorry Fairhurst"/>, <contact fullname="Spencer
			Dawkins"/>, <contact fullname="Reese Enghardt"/>, <contact
			fullname="Laurent Ciavaglia"/>, <contact fullname="Stephen Farrell"/>,
			and <contact fullname="Richard Yang"/> for discussions leading to
			questions in this document and for feedback on the document itself.</t>
			<t>This work is partially supported by the European Commission under
			Horizon 2020 grant agreement no. 688421 Measurement and Architecture for
			a Middleboxed Internet (MAMI) and by the Swiss State Secretariat for
			Education, Research, and Innovation under contract no. 15.0268. This
			support does not imply endorsement.</t>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 33 change blocks.
	621 lines changed or deleted		314 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/