rfc9473.original.xml		rfc9473.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.11 -->		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
	<?rfc toc="yes"?>		="IRTF" category="info" consensus="true" docName="draft-irtf-panrg-path-properti
	<?rfc sortrefs="yes"?>		es-08" number="9473" obsoletes="" updates=""
	<?rfc symrefs="yes"?>		xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-irtf-panrg-path-properties-08" category="info" obsoletes="" updates="" submissi
	onType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" ver
	sion="3">
	<!-- xml2rfc v2v3 conversion 3.10.0 -->
	<front>		<front>
	<title abbrev="Path Properties">A Vocabulary of Path Properties</title>		<title abbrev="Path Properties">A Vocabulary of Path Properties</title>
	<seriesInfo name="Internet-Draft" value="draft-irtf-panrg-path-properties-08 "/>		<seriesInfo name="RFC" value="9473"/>
	<author initials="R." surname="Enghardt" fullname="Reese Enghardt">		<author initials="R." surname="Enghardt" fullname="Reese Enghardt">
	<organization>Netflix</organization>		<organization>Netflix</organization>
	<address>		<address>
	<email>ietf@tenghardt.net</email>		<email>ietf@tenghardt.net</email>
	</address>		</address>
	</author>		</author>
	<author initials="C." surname="Krähenbühl" fullname="Cyrill Krähenbühl">		<author initials="C." surname="Krähenbühl" fullname="Cyrill Krähenbühl">
	<organization>ETH Zürich</organization>		<organization>ETH Zürich</organization>
	<address>		<address>
	<email>cyrill.kraehenbuehl@inf.ethz.ch</email>		<email>cyrill.kraehenbuehl@inf.ethz.ch</email>
	</address>		</address>
	</author>		</author>
	<date year="2023" month="March" day="06"/>		<date year="2023" month="September"/>
	<area>IRTF</area>		<workgroup>Path Aware Networking</workgroup>
	<workgroup>PANRG</workgroup>
	<keyword>Internet-Draft</keyword>		<keyword>PAN</keyword>
			<keyword>path-aware network</keyword>
			<keyword>path property</keyword>
			<keyword>path selection</keyword>
	<abstract>		<abstract>
	<t>This document is a product of the Path Aware Networking Research Group		<t>Path properties express information about paths across a
	(PANRG).		network and the services provided via such paths. In a path-aware
	Path properties express information about paths across a network and the service		network, path properties may be fully or partially available to entities
	s provided via such paths.		such as endpoints. This document defines and categorizes path
	In a path-aware network, path properties may be fully or partially available to		properties. Furthermore, the document identifies several path
	entities such as endpoints.		properties that might be useful to endpoints or other entities, e.g.,
	This document defines and categorizes path properties.		for selecting between paths or for invoking some of the provided
	Furthermore, the document identifies several path properties which might be usef		services. This document is a product of the Path Aware Networking
	ul to endpoints or other entities,		Research Group (PANRG).</t>
	e.g., for selecting between paths or for invoking some of the provided services.
	</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>Discussion Venues</name>
	<t>Discussion of this document takes place on the
	"Path-Aware Networking Research Group" mailing list (PANRG),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
	panrg/"/>.
	Subscription information is at <eref target="https://www.ietf.org/mailman/li
	stinfo/panrg/"/>.</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/panrg/path-properties/"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>The current Internet architecture does not explicitly support endpoint		<t>The current Internet architecture does not explicitly support
	discovery of forwarding paths through the network nor the discovery of propertie		endpoint discovery of forwarding paths through the network nor the
	s and services associated with these paths.		discovery of properties and services associated with these paths.
	Path-aware networking, as defined in Section 1.1 of <xref target="RFC9217" forma		Path-aware networking, as defined in <xref target="RFC9217"
	t="default"/>, describes		sectionFormat="of" section="1.1"/>, describes "endpoint discovery of the
	"endpoint discovery of the properties of paths they use for communication across		properties of paths they use for communication across an internetwork,
	an internetwork, and endpoint reaction to these properties that affects routing		and endpoint reaction to these properties that affects routing and/or
	and/or data transfer".		data transfer". This document provides a generic definition of path
	This document provides a generic definition of path properties, addressing the f		properties, addressing the first of the questions in path-aware
	irst of the questions in path-aware networking <xref target="RFC9217" format="de		networking <xref target="RFC9217" format="default"/>.</t>
	fault"/>.</t>		<t>As terms related to paths have been used with different meanings in
	<t>As terms related to paths have been used with different meanings in dif		different areas of networking, first, this document provides a common
	ferent areas of networking, first, this document provides a common terminology t		terminology to define paths, path elements, and flows. Based on these
	o define paths, path elements, and flows. Based on these terms, the document def		terms, the document defines path properties. Then, this document
	ines path properties.		provides some examples of use cases for path properties. Finally, the
	Then, this document provides some examples of use cases for path properties.		document lists several path properties that may be useful for the
	Finally, the document lists several path properties that may be useful for the m		mentioned use cases. This list is intended to be neither exhaustive nor
	entioned use cases. This list is intended to be neither exhaustive nor definitiv		definitive.</t>
	e.</t>		<t>Note that this document does not assume that any of the listed path
	<t>Note that this document does not assume that any of the listed path pro		properties are actually available to any entity. The question of how
	perties are actually available to any entity. The question of how entities can d		entities can discover and distribute path properties in a trustworthy
	iscover and distribute path properties in a trustworthy way is out of scope for		way is out of scope for this document.</t>
	this document.</t>
	<t>This document represents the consensus of the Path Aware Networking Res earch Group (PANRG).</t>		<t>This document represents the consensus of the Path Aware Networking Res earch Group (PANRG).</t>
	</section>		</section>
	<section anchor="terminology" numbered="true" toc="default">		<section anchor="terminology" numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<dl>		<dl spacing="normal" newline="false">
	<dt>		<dt>Entity:</dt>
	Entity: </dt>
	<dd>		<dd>
	<t>A physical or virtual device or function, or a collection of device		<t>A physical or virtual device or function, or a collection of
	s or functions, which plays a role related to path-aware networking for particul		devices or functions, that plays a role related to path-aware
	ar paths and flows.		networking for particular paths and flows. An entity can be on-path
	An entity can be on-path or off-path: On the path, an entity may participate in		or off-path. On the path, an entity may participate in forwarding
	forwarding the flow, i.e., what may be called data plane functionality.		the flow, i.e., what may be called "data plane functionality". On or
	On or off the path, an entity may influence aspects of how the flow is forwarded		off the path, an entity may influence aspects of how the flow is
	, i.e., what may be called control plane functionality, such as Path Selection o		forwarded, i.e., what may be called "control plane functionality",
	r Service Invocation.		such as path selection or service invocation. An entity influencing
	An entity influencing forwarding aspects is usually aware of path properties, e.		forwarding aspects is usually aware of path properties, e.g., by
	g., by observing or measuring them or by learning them from another entity.</t>		observing or measuring them or by learning them from another
			entity.</t>
	</dd>		</dd>
	<dt>		<dt>Node:</dt>
	Node: </dt>
	<dd>		<dd>
	<t>An on-path entity which processes packets, e.g., sends, receives, f		<t>An on-path entity that processes packets, e.g., sends, receives,
	orwards, or modifies them. A node may be physical or virtual, e.g., a physical d		forwards, or modifies them. A node may be physical or virtual, e.g.,
	evice, a service function provided as a virtual element, or even a single queue		a physical device, a service function provided as a virtual element,
	within a switch. A node may also be an entity which consists of a collection of		or even a single queue within a switch. A node may also be an entity
	devices or functions, e.g., an entire Autonomous System (AS).</t>		that consists of a collection of devices or functions, e.g., an
			entire Autonomous System (AS).</t>
	</dd>		</dd>
	<dt>		<dt>Link:</dt>
	Link: </dt>
	<dd>		<dd>
	<t>A medium or communication facility that connects two or more nodes		<t>A medium or communication facility that connects two or more
	with each other. A link enables a node to send packets to other nodes.		nodes with each other. A link enables a node to send packets to
	Links can be physical, e.g., a Wi-Fi network which connects an Access Point to s		other nodes. Links can be physical, e.g., a Wi-Fi network that
	tations, or virtual, e.g., a virtual switch which connects two virtual machines		connects an Access Point to stations, or virtual, e.g., a virtual
	hosted on the same physical machine. A link is unidirectional. As such, bidirect		switch that connects two virtual machines hosted on the same
	ional communication can be modeled as two links between the same nodes in opposi		physical machine. A link is unidirectional. As such, bidirectional
	te directions.</t>		communication can be modeled as two links between the same nodes in
			opposite directions.</t>
	</dd>		</dd>
	<dt>		<dt>Path element:</dt>
	Path element: </dt>
	<dd>		<dd>
	<t>Either a node or a link. For example, a path element can be an Abst		<t>Either a node or a link. For example, a path element can be an
	ract Network Element (ANE) as defined in <xref target="I-D.ietf-alto-path-vector		Abstract Network Element (ANE) as defined in <xref target="RFC9275"
	" format="default"/>.</t>		format="default"/>.</t>
	</dd>		</dd>
	<dt>		<dt>Path:</dt>
	Path: </dt>
	<dd>		<dd>
	<t>A sequence of adjacent path elements over which a packet can be tra		<t>A sequence of adjacent path elements over which a packet can be
	nsmitted, starting and ending with a node.		transmitted, starting and ending with a node.</t>
	</t>		<t>Paths are unidirectional and time dependent, i.e., there can be a
	<t>Paths are unidirectional and time-dependent, i.e., there can be a v		variety of paths from one node to another, and the path over which
	ariety of paths from one node to another, and the path over which packets are tr		packets are transmitted may change. A path definition can be strict
	ansmitted may change.		(i.e., the exact sequence of path elements remains the same) or
	A path definition can be strict (i.e., the exact sequence of path elements remai		loose (i.e., the start and end node remain the same, but the path
	ns the same) or loose (i.e., the start and end node remain the same, but the pat		elements between them may vary over time).</t>
	h elements between them may vary over time).</t>		<t>The representation of a path and its properties may depend on the
	<t>The representation of a path and its properties may depend on the e		entity considering the path. On the one hand, the representation
	ntity considering the path.		may differ due to entities having partial visibility of path
	On the one hand, the representation may differ due to entities having partial vi		elements comprising a path or their visibility changing over time.
	sibility of path elements comprising a path or their visibility changing over ti		On the other hand, the representation may differ due to treating
	me.		path elements at different levels of abstraction. For example, a
	On the other hand, the representation may differ due to treating path elements a		path may be given as a sequence of physical nodes and the links
	t different levels of abstraction.		connecting these nodes, be given as a sequence of logical nodes such
	For example, a path may be given as a sequence of physical nodes and the links c		as a sequence of ASes or an Explicit Route Object (ERO), or only
	onnecting these nodes, a sequence of logical nodes such as a sequence of ASes or		consist of a specific source and destination that is known to be
	an Explicit Route Object (ERO), or only consist of a specific source and destin		reachable from that source.</t>
	ation which is known to be reachable from that source.</t>		<t>A multicast or broadcast setting where a packet is sent by one
	<t>A multicast or broadcast setting, where a packet is sent by one nod		node and received by multiple nodes is described by multiple paths
	e and received by multiple nodes, is described by multiple paths over which the		over which the packet is sent, one path for each combination of
	packet is sent, one path for each combination of sending and receiving node; the		sending and receiving node; these paths do not have to be disjoint
	se paths do not have to be disjoint as defined by the Disjointness path property		as defined by the disjointness path property, see <xref
	, see <xref target="examples" format="default"/>.</t>		target="examples" format="default"/>.</t>
	</dd>		</dd>
	<dt>		<dt>Endpoint:</dt>
	Endpoint: </dt>
	<dd>		<dd>
	<t>The endpoints of a path are the start and end node of the path. For		<t>The endpoints of a path are the start and end node of the
	example, an endpoint can be a host as defined in <xref target="RFC1122" format=		path. For example, an endpoint can be a host as defined in <xref
	"default"/>, which can be a client (e.g., a node running a web browser) or a ser		target="RFC1122" format="default"/>, which can be a client (e.g., a
	ver (e.g., a node running a web server).</t>		node running a web browser) or a server (e.g., a node running a web
			server).</t>
	</dd>		</dd>
	<dt>		<dt>Reverse Path:</dt>
	Reverse Path: </dt>
	<dd>		<dd>
	<t>The path that is used by a remote node in the context of bidirectio		<t>The path that is used by a remote node in the context of
	nal communication.</t>		bidirectional communication.</t>
	</dd>		</dd>
	<dt>		<dt>Subpath:</dt>
	Subpath: </dt>
	<dd>		<dd>
	<t>Given a path, a subpath is a sequence of adjacent path elements of		<t>Given a path, a subpath is a sequence of adjacent path elements
	this path.</t>		of this path.</t>
	</dd>		</dd>
	<dt>		<dt>Flow:</dt>
	Flow: </dt>
	<dd>		<dd>
	<t>One or multiple packets to which the traits of a path or set of sub		<t>One or multiple packets to which the traits of a path or set of
	paths may be applied in a functional sense. For example, a flow can consist of a		subpaths may be applied in a functional sense. For example, a flow
	ll packets sent within a TCP session with the same five-tuple between two hosts,		can consist of all packets sent within a TCP session with the same
	or it can consist of all packets sent on the same physical link.</t>		five-tuple between two hosts, or it can consist of all packets sent
			on the same physical link.</t>
	</dd>		</dd>
	<dt>		<dt>Property:</dt>
	Property: </dt>
	<dd>		<dd>
	<t>A trait of one or a sequence of path elements, or a trait of a flow		<t>A trait of one or a sequence of path elements, or a trait of a
	with respect to one or a sequence of path elements. An example of a link proper		flow with respect to one or a sequence of path elements. An example
	ty is the maximum data rate that can be sent over the link. An example of a node		of a link property is the maximum data rate that can be sent over
	property is the administrative domain that the node belongs to. An example of a		the link. An example of a node property is the administrative domain
	property of a flow with respect to a subpath is the aggregated one-way delay of		that the node belongs to. An example of a property of a flow with
	the flow being sent from one node to another node over this subpath.		respect to a subpath is the aggregated one-way delay of the flow
	A property is thus described by a tuple containing the path element(s), the flow		being sent from one node to another node over this subpath. A
	or an empty set if no packets are relevant for the property, the name of the pr		property is thus described by a tuple containing the path
	operty (e.g., maximum data rate), and the value of the property (e.g., 1Gbps).</		element(s), the flow or an empty set if no packets are relevant for
	t>		the property, the name of the property (e.g., maximum data rate),
			and the value of the property (e.g., 1 Gbps).</t>
	</dd>		</dd>
	<dt>		<dt>Aggregated property:</dt>
	Aggregated property: </dt>
	<dd>		<dd>
	<t>A collection of multiple values of a property into a single value,		<t>A collection of multiple values of a property into a single
	according to a function. A property can be aggregated over multiple path element		value, according to a function. A property can be aggregated
	s (i.e., a subpath), e.g., the MTU of a path as the minimum MTU of all links on		over:</t>
	the path, over multiple packets (i.e., a flow), e.g., the median one-way latency		<ul spacing="normal">
	of all packets between two nodes, or over both, e.g., the mean of the queueing		<li>multiple path elements (i.e., a subpath), for example, the MTU
	delays of a flow on all nodes along a path.		of a path as the minimum MTU of all links on the path,</li>
	The aggregation function can be numerical, e.g., median, sum, minimum, it can be		<li>multiple packets (i.e., a flow), for example, the median
	logical, e.g., "true if all are true", "true if at least 50% of values are true		one-way latency of all packets between two nodes,</li>
	", or an arbitrary function which maps multiple input values to an output value.		<li>or both path elements and packets, for example, the mean of
	</t>		the queueing delays of a flow on all nodes along a path.</li>
			</ul>
			<t>The aggregation function can be numerical (e.g., median, sum,
			minimum) or logical (e.g., "true if all are true", "true if at
			least 50% of values are true"), or it can be an arbitrary function
			that maps multiple input values to an output value.</t>
	</dd>		</dd>
	<dt>		<dt>Observed property:</dt>
	Observed property: </dt>
	<dd>		<dd>
	<t>A property that is observed for a specific path element, subpath, o		<t>A property that is observed for a specific path element, subpath,
	r path, e.g., using measurements. For example, the one-way delay of a specific p		or path. A property may be observed using measurements, for example,
	acket transmitted from one node to another node can be measured.</t>		the one-way delay of a specific packet transmitted from node to
			node.</t>
	</dd>		</dd>
	<dt>		<dt>Assessed property:</dt>
	Assessed property: </dt>
	<dd>		<dd>
	<t>An approximate calculation or assessment of the value of a property		<t>An approximate calculation or assessment of the value of a
	. An assessed property includes the reliability of the calculation or assessment		property. An assessed property includes the reliability of the
	. The notion of reliability depends on the property.		calculation or assessment. The notion of reliability depends on the
	For example, a path property based on an approximate calculation may describe th		property. For example, a path property based on an approximate
	e expected median one-way latency of packets sent on a path within the next seco		calculation may describe the expected median one-way latency of
	nd, including the confidence level and interval. A non-numerical assessment may		packets sent on a path within the next second, including the
	instead include the likelihood that the property holds.</t>		confidence level and interval. A non-numerical assessment may
			instead include the likelihood that the property holds.</t>
	</dd>		</dd>
	<dt>		<dt>Target property:</dt>
	Target property: </dt>
	<dd>		<dd>
	<t>An objective that is set for a property over a path element, subpat		<t>An objective that is set for a property over a path element,
	h, or path.		subpath, or path. Note that a target property can be set for
	Note that a target property can be set for observed properties, such as one-way		observed properties, such as one-way delay, and also for properties
	delay, but also for properties that cannot be observed by the entity setting the		that cannot be observed by the entity setting the target, such as
	target, such as inclusion of certain nodes on a path.</t>		inclusion of certain nodes on a path.</t>
	</dd>		</dd>
	</dl>		</dl>
	<section anchor="terminology-usage-for-specific-technologies" numbered="tr ue" toc="default">		<section anchor="terminology-usage-for-specific-technologies" numbered="tr ue" toc="default">
	<name>Terminology usage for specific technologies</name>		<name>Terminology Usage for Specific Technologies</name>
	<t>The terminology defined in this document is intended to be general an		<t>The terminology defined in this document is intended to be general
	d applicable to existing and future path-aware technologies.		and applicable to existing and future path-aware technologies. Using
	Using this terminology, a path-aware technology can define and consider specific		this terminology, a path-aware technology can define and consider
	path elements and path properties on a specific level of abstraction.		specific path elements and path properties on a specific level of
	For instance, a technology may define path elements as IP routers, e.g., in sour		abstraction. For instance, a technology may define path elements as
	ce routing (<xref target="RFC1940" format="default"/>). Alternatively, it may co		IP routers, e.g., in source routing <xref target="RFC1940"
	nsider path elements on a different layer of the Internet Architecture (<xref ta		format="default"/>. Alternatively, it may consider path elements on a
	rget="RFC1122" format="default"/>) or as a collection of entities not tied to a		different layer of the Internet architecture <xref target="RFC1122"
	specific layer, such as an AS or an ERO.		format="default"/> or as a collection of entities not tied to a
	Even within a single path-aware technology, specific definitions might differ de		specific layer, such as an AS or ERO. Even within a single path-aware
	pending on the context in which they are used.		technology, specific definitions might differ depending on the context
	For example, the endpoints might be the communicating hosts in the context of th		in which they are used. For example, the endpoints might be the
	e transport layer, ASes that contain the hosts in the context of routing, or spe		communicating hosts in the context of the transport layer, ASes that
	cific applications in the context of the application layer.</t>		contain the hosts in the context of routing, or specific applications
			in the context of the application layer.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="use-cases" numbered="true" toc="default">		<section anchor="use-cases" numbered="true" toc="default">
	<name>Use Cases for Path Properties</name>		<name>Use Cases for Path Properties</name>
	<t>When a path-aware network exposes path properties to endpoints or other		<t>When a path-aware network exposes path properties to endpoints or
	entities,		other entities, these entities may use this information to achieve
	these entities may use this information to achieve different goals.		different goals. This section lists several use cases for path
	This section lists several use cases for path properties.</t>		properties.</t>
	<t>Note that this is not an exhaustive list, as with every new technology		<t>Note that this is not an exhaustive list; as with every new
	and protocol, novel use cases may emerge, and new path properties may become rel		technology and protocol, novel use cases may emerge, and new path
	evant.		properties may become relevant. Moreover, for any particular
	Moreover, for any particular technology, entities may have visibility of and con		technology, entities may have visibility of and control over different
	trol over different path elements and path properties, and consider them on diff		path elements and path properties and consider them on different levels
	erent levels of abstraction.		of abstraction. Therefore, a new technology may implement an existing
	Therefore, a new technology may implement an existing use case related to differ		use case related to different path elements or on a different level of
	ent path elements or on a different level of abstraction.</t>		abstraction.</t>
	<section anchor="path-selection" numbered="true" toc="default">		<section anchor="path-selection" numbered="true" toc="default">
	<name>Path Selection</name>		<name>Path Selection</name>
	<t>Nodes may be able to send flows via one (or a subset) out of multiple		<t>Nodes may be able to send flows via one (or a subset) out of
	possible paths, and an entity may be able to influence the decision which path(		multiple possible paths, and an entity may be able to influence the
	s) to use.		decision about which path(s) to use. Path selection may be feasible
	Path Selection may be feasible if there are several paths to the same destinatio		if there are several paths to the same destination (e.g., in case of a
	n (e.g., in case of a mobile device with two wireless interfaces, both providing		mobile device with two wireless interfaces, both providing a path) or
	a path), or if there are several destinations, and thus several paths, providin		if there are several destinations, and thus several paths, providing
	g the same service (e.g., Application-Layer Traffic Optimization (ALTO) <xref ta		the same service (e.g., Application-Layer Traffic Optimization (ALTO)
	rget="RFC5693" format="default"/>, an application layer peer-to-peer protocol al		<xref target="RFC5693" format="default"/>, an application layer
	lowing endpoints a better-than-random peer selection).		peer-to-peer protocol allowing endpoints a better-than-random peer
	Entities can express their intent to achieve a specific goal by specifying targe		selection). Entities can express their intent to achieve a specific
	t properties for their paths, e.g., related to performance or security.		goal by specifying target properties for their paths, e.g., related to
	Then, paths can be selected which best meet the target properties, e.g., the ent		performance or security. Then, paths can be selected that best meet
	ity can select these paths from all available paths or express the target proper		the target properties, e.g., the entity can select these paths from
	ties to the network and rely on the network to select appropriate paths.</t>		all available paths or express the target properties to the network
	<t>Target properties relating to network performance typically refer to		and rely on the network to select appropriate paths.</t>
	observed properties, such as One-Way Delay, One-Way Packet Loss, and Link Capaci		<t>Target properties relating to network performance typically refer
	ty.		to observed properties, such as one-way delay, one-way packet loss,
	Entities then select paths based on their target property and the assessed prope		and link capacity. Entities then select paths based on their target
	rty of the available paths that best match the application requirements.		property and the assessed property of the available paths that best
	For such performance-related target properties, the observed property is similar		match the application requirements. For such performance-related
	to a service level indicator (SLI) and the assessed property is similar to a se		target properties, the observed property is similar to a Service Level
	rvice level objective (SLO) for IETF network slices <xref target="I-D.ietf-teas-		Indicator (SLI), and the assessed property is similar to a Service
	ietf-network-slices" format="default"/>.		Level Objective (SLO) for IETF Network Slices <xref
	As an example path selection strategy, for sending a small delay-sensitive query		target="I-D.ietf-teas-ietf-network-slices" format="default"/>. As an
	, an entity may select a path with a short One-Way Delay, while for retrieving a		example path-selection strategy, an entity may select a path with a
	large file, it may select a path with high Link Capacities on all links.</t>		short one-way delay for sending a small delay-sensitive query, while
	<t>It is also possible for an entity to set target properties which it c		it may select a path with high link capacities on all links for
	annot (directly) observe, similar to service level expectations (SLEs) for IETF		retrieving a large file.</t>
	network slices <xref target="I-D.ietf-teas-ietf-network-slices" format="default"		<t>It is also possible for an entity to set target properties that it
	/>.		cannot (directly) observe, similar to Service Level Expectations
	For example, this can apply to security-related target properties and path selec		(SLEs) for IETF Network Slices <xref
	tion, such as allowing or disallowing sending flows over paths that involve spec		target="I-D.ietf-teas-ietf-network-slices" format="default"/>. This
	ific networks or nodes to enforce traffic policies or mandating that all enterpr		may apply to security-related target properties (e.g., to mandate that
	ise traffic goes through a specific firewall.</t>		all enterprise traffic goes through a specific firewall) and path
	<t>Care needs to be taken when selecting paths based on observed path pr		selection (e.g., to enforce traffic policies by allowing or disallowing
	operties, as path properties that were previously measured may not be helpful in		sending flows over paths that involve specific networks or nodes).</t>
	predicting current or future path properties and such path selection may lead t		<t>Care needs to be taken when selecting paths based on observed path
	o unintended feedback loops. Also, there may be trade-offs between path properti		properties, as path properties that were previously measured may not
	es (e.g., One-Way Delay and Link Capacity), and entities may influence these tra		be helpful in predicting current or future path properties, and such
	de-offs with their choices.		path selection may lead to unintended feedback loops. Also, there may
	Finally, path selection may impact fairness.		be trade-offs between path properties (e.g., one-way delay and link
	For example, if multiple entities concurrently attempt to meet their target prop		capacity), and entities may influence these trade-offs with their
	erties using the same network resources, one entity's choices may influence the		choices. Finally, path selection may impact fairness. For example,
	conditions on the path as experienced by flows of another entity.</t>		if multiple entities concurrently attempt to meet their target
	<t>As a baseline, a path selection algorithm should aim to do a better j		properties using the same network resources, one entity's choices may
	ob at meeting the target properties, and consequently accommodating the user's r		influence the conditions on the path as experienced by flows of
	equirements, than the default case of not selecting a path most of the time.</t>		another entity.</t>
	<t>Path selection can be done either by the communicating node(s) or by
	other entities within the network:		<t>As a baseline, a path-selection algorithm should aim to do a better
	A network (e.g., an AS) can adjust its path selection for internal or external r		job of meeting the target properties, and consequently accommodating
	outing based on path properties.		the user's requirements, than the default case of not selecting a path
	In BGP, the Multi Exit Discriminator (MED) attribute is used in the decision-mak		most of the time.</t>
	ing process to select which path to choose among those having the same AS PATH l		<t>Path selection can be done either by the communicating node(s) or
	ength and origin <xref target="RFC4271" format="default"/>; in a path-aware netw		by other entities within the network. A network (e.g., an AS) can
	ork, instead of using this single MED value, other properties such as Link Capac		adjust its path selection for internal or external routing based on
	ity or Link Usage could additionally be used to improve load balancing or perfor		path properties. In BGP, the Multi-Exit Discriminator (MED) attribute
	mance <xref target="I-D.ietf-idr-performance-routing" format="default"/>.</t>		is used in the decision-making process to select which path to choose
			among those having the same AS path length and origin <xref
			target="RFC4271" format="default"/>; in a path-aware network, instead
			of using this single MED value, other properties such as link capacity
			or link usage could additionally be used to improve load balancing or
			performance <xref target="I-D.ietf-idr-performance-routing"
			format="default"/>.</t>
	</section>		</section>
	<section anchor="protocol-selection" numbered="true" toc="default">		<section anchor="protocol-selection" numbered="true" toc="default">
	<name>Protocol Selection</name>		<name>Protocol Selection</name>
	<t>Before sending data over a specific path, an entity may select an app		<t>Before sending data over a specific path, an entity may select an
	ropriate protocol or configure protocol parameters depending on path properties.		appropriate protocol or configure protocol parameters depending on
	For example, an endpoint may cache state on whether a path allows the use of QUI		path properties. For example, an endpoint may cache state if
	C <xref target="RFC9000" format="default"/> and if so, first attempt to connect		a path allows the use of QUIC <xref target="RFC9000"
	using QUIC before falling back to another protocol when connecting over this pat		format="default"/>; if so, it may first attempt to connect using QUIC
	h again.		before falling back to another protocol when connecting over this path
	A video streaming application may choose an (initial) video quality based on the		again. A video-streaming application may choose an (initial) video
	achievable data rate or the monetary cost of sending data (e.g., volume-base or		quality based on the achievable data rate or the monetary cost of
	flat-rate cost model).</t>		sending data (e.g., volume-based or flat-rate cost model).</t>
	</section>		</section>
	<section anchor="service-invocation" numbered="true" toc="default">		<section anchor="service-invocation" numbered="true" toc="default">
	<name>Service Invocation</name>		<name>Service Invocation</name>
	<t>In addition to path or protocol selection, an entity may choose to in		<t>In addition to path or protocol selection, an entity may choose to
	voke additional functions in the context of Service Function Chaining <xref targ		invoke additional functions in the context of Service Function
	et="RFC7665" format="default"/>, which may influence what nodes are on the path.		Chaining <xref target="RFC7665" format="default"/>, which may
	For example, a 0-RTT Transport Converter <xref target="RFC8803" format="default"		influence which nodes are on the path. For example, a 0-RTT Transport
	/> will be involved in a path only when invoked by an endpoint; such invocation		Converter <xref target="RFC8803" format="default"/> will be involved
	will lead to the use of MPTCP <xref target="RFC8684" format="default"/> or TCPin		in a path only when invoked by an endpoint; such invocation will lead
	c <xref target="RFC8547" format="default"/> <xref target="RFC8548" format="defau		to the use of Multipath TCP (MPTCP) <xref target="RFC8684"
	lt"/> capabilities while such use is not supported via the default forwarding pa		format="default"/> or tcpcrypt <xref target="RFC8548"
	th.		format="default"/> capabilities, while such use is not supported via
	Another example is a connection which is composed of multiple streams where each		the default forwarding path. Another example is a connection that is
	stream has specific service requirements. An endpoint may decide to invoke a gi		composed of multiple streams where each stream has specific service
	ven service function (e.g., transcoding) only for some streams while others are		requirements. An endpoint may decide to invoke a given service
	not processed by that service function.</t>		function (e.g., transcoding) only for some streams while others are
			not processed by that service function.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="examples" numbered="true" toc="default">		<section anchor="examples" numbered="true" toc="default">
	<name>Examples of Path Properties</name>		<name>Examples of Path Properties</name>
	<t>This Section gives some examples of path properties which may be useful		<t>This section gives some examples of path properties that may be
	, e.g., for the use cases described in <xref target="use-cases" format="default"		useful, e.g., for the use cases described in <xref target="use-cases"
	/>.</t>		format="default"/>.</t>
	<t>Within the context of any particular technology, available path propert		<t>Within the context of any particular technology, available path
	ies may differ		properties may differ as entities have insight into and are able to
	as entities have insight into and are able to influence different path elements		influence different path elements and path properties. For example, an
	and path properties.		endpoint may have some visibility into path elements that are close and on
	For example, an endpoint may have some visibility into path elements that are on		a low
	a low level of abstraction and close, e.g., individual nodes within the first f		level of abstraction (e.g., individual nodes within the first
	ew hops, or it may have visibility into path elements that are far away and/or o		few hops), or it may have visibility into path elements that are far away
	n a higher level of abstraction, e.g., the list of ASes traversed.		and/or on a higher level of abstraction (e.g., the list of ASes
	This visibility may depend on factors such as the physical or network distance o		traversed). This visibility may depend on factors such as the physical
	r the existence of trust or contractual relationships between the endpoint and t		or network distance or the existence of trust or contractual
	he path element(s).		relationships between the endpoint and the path element(s). A path
	A path property can be defined relative to individual path elements, a sequence		property can be defined relative to individual path elements, a sequence
	of path elements, or "end-to-end", i.e., relative to a path that comprises of tw		of path elements, or "end-to-end", i.e., relative to a path that
	o endpoints and a single virtual link connecting them.</t>		comprises of two endpoints and a single virtual link connecting
	<t>Path properties may be relatively dynamic, e.g., the one-way delay of a		them.</t>
	packet sent over a specific path, or non-dynamic, e.g., the MTU of an Ethernet		<t>Path properties may be relatively dynamic, e.g., the one-way delay of
	link which only changes infrequently.		a packet sent over a specific path, or non-dynamic, e.g., the MTU of an
	Usefulness over time differs depending on how dynamic a property is:		Ethernet link that only changes infrequently. Usefulness over time
	The merit of a momentarily observed dynamic path propety may diminish greatly as		differs depending on how dynamic a property is: the merit of a
	time goes on, e.g.,		momentarily observed dynamic path property may diminish greatly as time
	it is possible for the observed values of One-Way Delay to change on timescales		goes on, e.g., it is possible for the observed values of one-way delay
	which are shorter than the One-Way Delay between the measurement point and an en		to change on timescales that are shorter than the one-way delay between
	tity making a decision such as Path Selection, which may cause the measurement t		the measurement point and an entity making a decision such as path
	o be outdated when it reaches the decision-making entity. Therefore, consumers o		selection, which may cause the measurement to be outdated when it
	f dynamic path properties need to apply caution when using them, e.g., by aggreg		reaches the decision-making entity. Therefore, consumers of dynamic path
	ating them appropriately or applying a dampening function to their changes to av		properties need to apply caution when using them, e.g., by aggregating
	oiding oscillation.		them appropriately or applying a dampening function to their changes to
	In contrast, the observed value of a less dynamic path property might stay relev		avoid oscillation. In contrast, the observed value of a less dynamic
	ant for a longer period of time, e.g. a NAT typically stays on a particular path		path property might stay relevant for a longer period of time, e.g., a
	during the lifetime of a connection involving packets sent over this path.</t>		NAT typically stays on a particular path during the lifetime of a
	<dl>		connection involving packets sent over this path.</t>
	<dt>		<dl spacing="normal" newline="false">
	Access Technology: </dt>		<dt>Access Technology:</dt>
	<dd>		<dd>
	<t>The physical or link layer technology used for transmitting or rece		<t>The physical- or link-layer technology used for transmitting or
	iving a flow on one or multiple path elements. If known, the Access Technology m		receiving a flow on one or multiple path elements. If known, the
	ay be given as an abstract link type, e.g., as Wi-Fi, Wired Ethernet, or Cellula		access technology may be given as an abstract link type, e.g., as
	r. It may also be given as a specific technology used on a link, e.g., 3GPP cell		Wi-Fi, wired Ethernet, or cellular. It may also be given as a
	ular, or 802.11 WiFi. Other path elements relevant to the access technology may		specific technology used on a link, e.g., 3GPP cellular or 802.11
	include nodes related to processing packets on the physical or link layer, such		Wireless Local Area Network (WLAN). Other path elements relevant to
	as elements of a cellular core network. Note that there is no common registry of		the access technology may include nodes related to processing
	possible values for this property.</t>		packets on the physical or link layer, such as elements of a
			cellular core network. Note that there is no common registry of
			possible values for this property.</t>
	</dd>		</dd>
	<dt>		<dt>Monetary Cost:</dt>
	Monetary Cost: </dt>
	<dd>		<dd>
	<t>The price to be paid to transmit or receive a specific flow across		<t>The price to be paid to transmit or receive a specific flow
	a network to which one or multiple path elements belong.</t>		across a network to which one or multiple path elements belong.</t>
	</dd>		</dd>
	<dt>		<dt>Service Function:</dt>
	Service function: </dt>
	<dd>		<dd>
	<t>A service function that a path element applies to a flow, see <xref		<t>A service function that a path element applies to a flow, see
	target="RFC7665" format="default"/>. Examples of abstract service functions inc		<xref target="RFC7665" format="default"/>. Examples of abstract
	lude firewalls, Network Address Translation (NAT), and TCP Performance Enhancing		service functions include firewalls, Network Address Translation
	Proxies. Some stateful service functions, such as NAT, need to observe the same		(NAT), and TCP Performance Enhancing Proxies. Some stateful service
	flow in both directions, e.g., by being an element of both the path and the rev		functions, such as NAT, need to observe the same flow in both
	erse path.</t>		directions, e.g., by being an element of both the path and the
			reverse path.</t>
	</dd>		</dd>
	<dt>		<dt>Transparency:</dt>
	Transparency: </dt>
	<dd>		<dd>
	<t>When a node performs an action A on a flow F, the node is transpare
	nt to F with respect to some (meta-)information M if the node performs A indepen		<t>When a node performs an action A on a flow F, the node is
	dently of M.		transparent to F with respect to some (meta-)information M if the
	M can for example be the existence of a protocol (header) in a packet or the con		node performs A independently of M. M can, for example, be the
	tent of a protocol header, payload, or both.		existence of a protocol (header) in a packet or the content of a
	For example, A can be blocking packets or reading and modifying (other protocol)		protocol header, payload, or both. For example, A can be blocking
	headers or payloads.		packets or reading and modifying (other protocol) headers or
	Transparency can be modeled using a function f, which takes as input F and M and		payloads. Transparency can be modeled using a function f, which
	outputs the action taken by the node.		takes as input F and M and outputs the action taken by the node. If
	If a taint analysis shows that the output of f is not tainted (impacted) by M or		a taint analysis shows that the output of f is not tainted
	if the output of f is constant for arbitrary values of M, then the node is cons		(impacted) by M, or if the output of f is constant for arbitrary
	idered to be transparent.		values of M, then the node is considered to be transparent. An IP
	An IP router could be transparent to transport protocol headers such as TCP/UDP		router could be transparent to transport protocol headers such as
	but not transparent to IP headers since its forwarding behavior depends on the I		TCP/UDP but not transparent to IP headers since its forwarding
	P headers.		behavior depends on the IP headers. A firewall that only allows
	A firewall that only allows outgoing TCP connections by blocking all incoming TC		outgoing TCP connections by blocking all incoming TCP SYN packets
	P SYN packets regardless of their IP address is transparent to IP but not to TCP		regardless of their IP address is transparent to IP but not to TCP
	headers.		headers. Finally, a NAT that actively modifies IP and TCP/UDP
	Finally, a NAT that actively modifies IP and TCP/UDP headers based on their cont		headers based on their content is not transparent to either IP or
	ent is not transparent to either IP or TCP/UDP headers.		TCP/UDP headers. Note that according to this definition, a node that
	Note that according to this definition, a node that modifies packets in accordan		modifies packets in accordance with the endpoints, such as a
	ce with the endpoints, such as a transparent HTTP proxy, as defined in <xref tar		transparent HTTP proxy, as defined in <xref target="RFC9110"
	get="RFC2616" format="default"/>, and a node listening and reacting to implicit		format="default"/>, and a node listening and reacting to implicit or
	or explicit signals, see <xref target="RFC8558" format="default"/>, are not cons		explicit signals, see <xref target="RFC8558" format="default"/>, are
	idered transparent.		not considered transparent.</t>
	</t>		<t>Transparency only applies to nodes and not to links, as a link
	<t>Transparency only applies to nodes and not to links, as a link cann		cannot modify or perform any other actions on the packets by
	ot modify or perform any other actions on the packets by itself. For example, if		itself. For example, if the content of a packet is altered when
	the content of a packet is altered when forwarded over a Generic Routing Encaps		forwarded over a Generic Routing Encapsulation (GRE) tunnel <xref
	ulation (GRE) tunnel <xref target="RFC2784" format="default"/><xref target="RFC7		target="RFC2784" format="default"/> <xref target="RFC7676"
	676" format="default"/>, this document considers as nodes the software instances		format="default"/>, per this document the software instances that
	that terminate the tunnel over which the actions are performed; thus, the trans		terminate the tunnel are considered nodes over which the actions are
	parency definition applies to these nodes.</t>		performed; thus, the transparency definition applies to these
			nodes.</t>
	</dd>		</dd>
	<dt>		<dt>Administrative Domain:</dt>
	Administrative Domain: </dt>
	<dd>		<dd>
	<t>The identity of an individual or an organization that controls acce		<t>The identity of an individual or an organization that controls
	ss to a path element (or several path elements).		access to a path element (or several path elements). Examples of
	Examples of administrative domains are an IGP area, an AS, or a service provider		administrative domains are an IGP area, an AS, or a service provider
	network.</t>		network.</t>
	</dd>		</dd>
	<dt>		<dt>Routing Domain Identifier:</dt>
	Routing Domain Identifier: </dt>
	<dd>		<dd>
	<t>An identifier indicating the routing domain of a path element.		<t>An identifier indicating the routing domain of a path element.
	Path elements in the same routing domain are in the same administrative domain a		Path elements in the same routing domain are in the same
	nd use a common routing protocol to communicate with each other.		administrative domain and use a common routing protocol to
	An example of a routing domain identifier is the globally unique autonomous syst		communicate with each other. An example of a routing domain
	em number (ASN) as defined in <xref target="RFC1930" format="default"/>.</t>		identifier is the globally unique Autonomous System Number (ASN) as
			defined in <xref target="RFC1930" format="default"/>.</t>
	</dd>		</dd>
	<dt>		<dt>Disjointness:</dt>
	Disjointness: </dt>
	<dd>		<dd>
	<t>For a set of two paths or subpaths, the number of shared path eleme		<t>For a set of two paths or subpaths, the number of shared path
	nts can be a measure of intersection (e.g., Jaccard coefficient, which is the nu		elements can be a measure of intersection (e.g., Jaccard
	mber of shared elements divided by the total number of elements). Conversely, th		coefficient, which is the number of shared elements divided by the
	e number of non-shared path elements can be a measure of disjointness (e.g., 1 -		total number of elements). Conversely, the number of non-shared path
	Jaccard coefficient). A multipath protocol might use disjointness as a metric t		elements can be a measure of disjointness (e.g., 1 - Jaccard
	o reduce the number of single points of failure. As paths can be defined at diff		coefficient). A multipath protocol might use disjointness as a
	erent levels of abstraction, two paths may be disjoint at one level of abstracti		metric to reduce the number of single points of failure. As paths
	on, but not on another.</t>		can be defined at different levels of abstraction, two paths may be
			disjoint at one level of abstraction but not on another.</t>
	</dd>		</dd>
	<dt>		<dt>Symmetric Path:</dt>
	Symmetric Path: </dt>
	<dd>		<dd>
	<t>Two paths are symmetric if the path and its reverse path consist of		<t>Two paths are symmetric if the path and its reverse path consist
	the same path elements on the same level of abstraction, but in reverse order.		of the same path elements on the same level of abstraction, but in
	For example, a path which consists of layer 3 switches and links between them an		reverse order. For example, a path that consists of layer 3
	d a reverse path with the same path elements but in reverse order are considered		switches and links between them and a reverse path with the same
	"routing" symmetric, as the same path elements on the same level of abstraction		path elements but in reverse order are considered "routing"
	(IP forwarding) are traversed in the opposite direction.		symmetric, as the same path elements on the same level of
	Symmetry can depend on the level of abstraction on which the path is defined or		abstraction (IP forwarding) are traversed in the opposite direction.
	modeled: If there are two parallel physical links between two nodes, modeling th		Symmetry can depend on the level of abstraction on which the path is
	em as separate links may result in a flow using asymmetric paths, and modeling t		defined or modeled. If there are two parallel physical links between
	hem as a single virtual link may result in symmetric paths, e.g., if the differe		two nodes, modeling them as separate links may result in a flow
	nce between the two physical links is irrelevant in a particular context.</t>		using asymmetric paths, and modeling them as a single virtual link
			may result in symmetric paths, e.g., if the difference between the
			two physical links is irrelevant in a particular context.</t>
	</dd>		</dd>
	<dt>		<dt>Path MTU:</dt>
	Path MTU: </dt>
	<dd>		<dd>
	<t>The maximum size, in octets, of a packet or frame that can be trans		<t>The maximum size, in octets, of a packet or frame that can be
	mitted without fragmentation.</t>		transmitted without fragmentation.</t>
	</dd>		</dd>
	<dt>		<dt>Transport Protocols available:</dt>
	Transport Protocols available: </dt>
	<dd>		<dd>
	<t>Whether a specific transport protocol can be used to establish a co		<t>Whether a specific transport protocol can be used to establish a
	nnection over a path or subpath, e.g., whether the path is QUIC-capable or MPTCP		connection over a path or subpath, e.g., whether the path is
	-capable, based on input such as policy, cached knowledge, or probing results.</		QUIC-capable or MPTCP-capable, based on input such as policy, cached
	t>		knowledge, or probing results.</t>
	</dd>		</dd>
	<dt>		<dt>Protocol Features available:</dt>
	Protocol Features available: </dt>
	<dd>		<dd>
	<t>Whether a specific protocol feature is available over a path or sub		<t>Whether a specific protocol feature is available over a path or
	path, e.g., Explicit Congestion Notification (ECN), or TCP Fast Open.</t>		subpath, e.g., Explicit Congestion Notification (ECN) or TCP Fast
			Open.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Some path properties express the performance of the transmission of a p
	acket or flow over a link or subpath.		<t>Some path properties express the performance of the transmission of a
	Such transmission performance properties can be observed or assessed, e.g., by e		packet or flow over a link or subpath. Such transmission performance
	ndpoints or by path elements on the path, or they may be available as cost metri		properties can be observed or assessed, e.g., by endpoints or by path
	cs, see <xref target="I-D.ietf-alto-performance-metrics" format="default"/>.		elements on the path, or they may be available as cost metrics, see
	Transmission performance properties may be made available in an aggregated form,		<xref target="RFC9439" format="default"/>. Transmission performance
	such as averages or minimums.		properties may be made available in an aggregated form, such as averages
	Properties related to a path element which constitutes a single layer 2 domain a		or minimums. Properties related to a path element that constitutes a
	re abstracted from the used physical and link layer technology, similar to <xref		single layer 2 domain are abstracted from the used physical- and link-laye
	target="RFC8175" format="default"/>.</t>		r technology, similar to <xref target="RFC8175"
	<dl>		format="default"/>.</t>
	<dt>
	Link Capacity: </dt>		<dl spacing="normal" newline="false">
			<dt>Link Capacity:</dt>
	<dd>		<dd>
	<t>The link capacity is the maximum data rate at which data that was s		<t>The link capacity is the maximum data rate at which data that was
	ent over a link can correctly be received at the node adjacent to the link.		sent over a link can correctly be received at the node adjacent to
	This property is analogous to the link capacity defined in <xref target="RFC5136		the link. This property is analogous to the link capacity defined
	" format="default"/> and <xref target="RFC9097" format="default"/> but not restr		in <xref target="RFC5136" format="default"/> and <xref
	icted to IP-layer traffic.</t>		target="RFC9097" format="default"/> but is not restricted to IP-layer
			traffic.</t>
	</dd>		</dd>
	<dt>		<dt>Link Usage:</dt>
	Link Usage: </dt>
	<dd>		<dd>
	<t>The link usage is the actual data rate at which data that was sent
	over a link is correctly received at the node adjacent to the link.		<t>The link usage is the actual data rate at which data that was
	This property is analogous to the link usage defined in <xref target="RFC5136" f		sent over a link is correctly received at the node adjacent to the
	ormat="default"/> and <xref target="RFC9097" format="default"/> but not restrict		link. This property is analogous to the link usage defined in <xref
	ed to IP-layer traffic.</t>		target="RFC5136" format="default"/> and <xref target="RFC9097"
			format="default"/> but is not restricted to IP-layer traffic.</t>
	</dd>		</dd>
	<dt>		<dt>One-Way Delay:</dt>
	One-Way Delay: </dt>
	<dd>		<dd>
	<t>The one-way delay is the delay between a node sending a packet and		<t>The one-way delay is the delay between a node sending a packet
	another node on the same path receiving the packet.		and another node on the same path receiving the packet. This
	This property is analogous to the one-way delay defined in <xref target="RFC7679		property is analogous to the one-way delay defined in <xref
	" format="default"/> but not restricted to IP-layer traffic.</t>		target="RFC7679" format="default"/> but is not restricted to IP-layer
			traffic.</t>
	</dd>		</dd>
	<dt>		<dt>One-Way Delay Variation:</dt>
	One-Way Delay Variation: </dt>
	<dd>		<dd>
	<t>The variation of the one-way delays within a flow.		<t>The variation of the one-way delays within a flow. This property
	This property is similar to the one-way delay variation defined in <xref target=		is similar to the one-way delay variation defined in <xref
	"RFC3393" format="default"/> but not restricted to IP-layer traffic and defined		target="RFC3393" format="default"/>, but it is not restricted to IP-la
	for packets on the same flow instead of packets sent between a source and destin		yer
	ation IP address.</t>		traffic and it is defined for packets on the same flow instead of pack
			ets
			sent between a source and destination IP address.</t>
	</dd>		</dd>
	<dt>		<dt>One-Way Packet Loss:</dt>
	One-Way Packet Loss: </dt>
	<dd>		<dd>
	<t>Packets sent by a node but not received by another node on the same		<t>Packets sent by a node but not received by another node on the
	path after a certain time interval are considered lost.		same path after a certain time interval are considered lost. This
	This property is analogous to the one-way loss defined in <xref target="RFC7680"		property is analogous to the one-way loss defined in <xref
	format="default"/> but not restricted to IP-layer traffic.		target="RFC7680" format="default"/> but is not restricted to IP-layer
	Metrics such as loss patterns <xref target="RFC3357" format="default"/> and loss		traffic. Metrics such as loss patterns <xref target="RFC3357"
	episodes <xref target="RFC6534" format="default"/> can be expressed as aggregat		format="default"/> and loss episodes <xref target="RFC6534"
	ed properties.</t>		format="default"/> can be expressed as aggregated properties.</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="security-considerations" numbered="true" toc="default">		<section anchor="security-considerations" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>If entities are basing policy or path selection decisions on path prope		<t>If entities are basing policy or path-selection decisions on path
	rties, they need to rely on the accuracy of path properties that other devices c		properties, they need to rely on the accuracy of path properties that
	ommunicate to them.		other devices communicate to them. In order to be able to trust such
	In order to be able to trust such path properties, entities may need to establis		path properties, entities may need to establish a trust relationship or
	h a trust relationship or be able to independently verify the authenticity, inte		be able to independently verify the authenticity, integrity, and
	grity, and correctness of path properties received from another entity.</t>		correctness of path properties received from another entity.</t>
	<t>Entities that reveal their target path properties to the network can ne		<t>Entities that reveal their target path properties to the network can
	gatively impact their own privacy, e.g., if the target property leaks personal i		negatively impact their own privacy, e.g., if the target property leaks
	nformation about a user, such as their identity or which (type of) application i		personal information about a user, such as their identity or which (type
	s used.		of) application is used. Such information could then allow network
	Such information could then allow network operators to block or re-prioritize tr		operators to block or reprioritize traffic for certain users and/or
	affic for certain users and/or application.		applications. Conversely, if privacy-enhancing technologies, e.g.,
	Conversely, if privacy enhancing technologies, e.g., MASQUE proxies <xref target		MASQUE proxies <xref target="RFC9298" format="default"/>, are used on a
	="RFC9298" format="default"/>, are used on a path, the path may only be partiall		path, the path may only be partially visible to any single entity. This
	y visible to any single entity.		may diminish the usefulness of path-aware technologies over this
	This may diminish the usefulness of path-aware technologies over this path.</t>		path.</t>
	<t>The need for, and potential definition of, security and privacy related		<t>The need for, and potential definition of, security- and privacy-relate
	path properties, such as confidentiality and integrity protection of payloads,		d path properties, such as confidentiality and integrity
	are the subject of ongoing discussion and research, e.g., see <xref target="RFC9		protection of payloads, are the subject of ongoing discussion and
	049" format="default"/> and <xref target="RFC9217" format="default"/>. As the di		research, for example, see <xref target="RFC9049" format="default"/> and <
	scussion of such properties is not mature enough, they are out of scope for this		xref
	document.		target="RFC9217" format="default"/>. As the discussion of such
	One aspect discussed in this context is that security related properties are dif		properties is not mature enough, they are out of scope for this
	ficult to characterize since they are only meaningful with respect to a threat m		document. One aspect discussed in this context is that security-related
	odel which depends on the use case, application, environment, and other factors.		properties are difficult to characterize since they are only meaningful
	Likewise, properties for trust relations between entities cannot be meaningfully		with respect to a threat model that depends on the use case,
	defined without a concrete threat model, and defining a threat model is out of		application, environment, and other factors. Likewise, properties for
	scope for this document.		trust relations between entities cannot be meaningfully defined without
	Properties related to confidentiality, integrity, and trust seem to be orthogona		a concrete threat model, and defining a threat model is out of scope for
	l to the path terminology and path properties defined in this document, since th		this document. Properties related to confidentiality, integrity, and
	ey are tied to the communicating nodes and the protocols they use (e.g., client		trust seem to be orthogonal to the path terminology and path properties
	and server using HTTPS, or client and remote network node using a VPN service) a		defined in this document, since they are tied to the communicating nodes
	s well as additional context, such as keying material and who has access to such		and the protocols they use (e.g., client and server using HTTPS, or
	a context. In contrast, the path as defined in this document is typically obliv		client and remote network node using a VPN service) as well as
	ious to these aspects.		additional context, such as keying material and who has access to such a
	Intuitively, the path describes what function the network applies to packets, wh		context. In contrast, the path as defined in this document is typically
	ile confidentiality, integrity, and trust describe what function the communicati		oblivious to these aspects. Intuitively, the path describes what
	ng parties apply to packets.</t>		function the network applies to packets, while confidentiality,
			integrity, and trust describe what function the communicating parties
			apply to packets.</t>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document has no IANA actions.</t>		<t>This document has no IANA actions.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>
	<name>Informative References</name>
	<reference anchor="I-D.ietf-idr-performance-routing">
	<front>
	<title>Performance-based BGP Routing Mechanism</title>
	<author fullname="Xiaohu Xu" initials="X." surname="Xu">
	<organization>Alibaba, Inc</organization>
	</author>
	<author fullname="Shraddha Hegde" initials="S." surname="Hegde">
	<organization>Juniper</organization>
	</author>
	<author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar"
	>
	<organization>Cisco</organization>
	</author>
	<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"
	>
	<organization>France Telecom</organization>
	</author>
	<author fullname="Christian Jacquenet" initials="C." surname="Jacquene
	t">
	<organization>France Telecom</organization>
	</author>
	<date day="22" month="December" year="2020"/>
	<abstract>
	<t> The current BGP specification doesn't use network performance
	metrics
	(e.g., network latency) in the route selection decision process.
	This document describes a performance-based BGP routing mechanism in
	which network latency metric is taken as one of the route selection
	criteria. This routing mechanism is useful for those server
	providers with global reach to deliver low-latency network
	connectivity services to their customers.
	</t>		<displayreference target="I-D.ietf-idr-performance-routing" to="PERFORMANCE-ROUT
	</abstract>		ING"/>
	</front>		<displayreference target="I-D.ietf-teas-ietf-network-slices" to="NETWORK-SLICES"
	<seriesInfo name="Internet-Draft" value="draft-ietf-idr-performance-rout		/>
	ing-03"/>
	</reference>
	<reference anchor="I-D.ietf-alto-path-vector">
	<front>
	<title>An Extension for Application-Layer Traffic Optimization (ALTO):
	Path Vector</title>
	<author fullname="Kai Gao" initials="K." surname="Gao">
	<organization>Sichuan University</organization>
	</author>
	<author fullname="Young Lee" initials="Y." surname="Lee">
	<organization>Samsung</organization>
	</author>
	<author fullname="Sabine Randriamasy" initials="S." surname="Randriama
	sy">
	<organization>Nokia Bell Labs</organization>
	</author>
	<author fullname="Y. Richard Yang" initials="Y. R." surname="Yang">
	<organization>Yale University</organization>
	</author>
	<author fullname="Jingxuan Zhang" initials="J." surname="Zhang">
	<organization>Tongji University</organization>
	</author>
	<date day="20" month="March" year="2022"/>
	<abstract>
	<t>This document is an extension to the base Application-Layer Traff
	ic Optimization (ALTO) protocol. It extends the ALTO cost map and ALTO property
	map services so that an application can decide to which endpoint(s) to connect
	based not only on numerical/ordinal cost values but also on fine-grained abstrac
	t information regarding the paths. This is useful for applications whose perfor
	mance is impacted by specific components of a network on the end-to-end paths, e
	.g., they may infer that several paths share common links and prevent traffic bo
	ttlenecks by avoiding such paths. This extension introduces a new abstraction c
	alled the "Abstract Network Element" (ANE) to represent these components and enc
	odes a network path as a vector of ANEs. Thus, it provides a more complete but
	still abstract graph representation of the underlying network(s) for informed tr
	affic optimization among endpoints.
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-alto-path-vector-25"
	/>
	</reference>
	<reference anchor="I-D.ietf-alto-performance-metrics">
	<front>
	<title>ALTO Performance Cost Metrics</title>
	<author fullname="Qin Wu" initials="Q." surname="Wu">
	<organization>Huawei</organization>
	</author>
	<author fullname="Y. Richard Yang" initials="Y. R." surname="Yang">
	<organization>Yale University</organization>
	</author>
	<author fullname="Young Lee" initials="Y." surname="Lee">
	<organization>Samsung</organization>
	</author>
	<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
	<organization>Huawei</organization>
	</author>
	<author fullname="Sabine Randriamasy" initials="S." surname="Randriama
	sy">
	<organization>Nokia Bell Labs</organization>
	</author>
	<author fullname="Luis M. Contreras" initials="L. M." surname="Contrer
	as">
	<organization>Telefonica</organization>
	</author>
	<date day="21" month="March" year="2022"/>
	<abstract>
	<t> The cost metric is a basic concept in Application-Layer Traffi
	c
	Optimization (ALTO), and different applications may use different
	types of cost metrics. Since the ALTO base protocol (RFC 7285)
	defines only a single cost metric (namely, the generic "routingcost"
	metric), if an application wants to issue a cost map or an endpoint
	cost request in order to identify a resource provider that offers
	better performance metrics (e.g., lower delay or loss rate), the base
	protocol does not define the cost metric to be used.
	This document addresses this issue by extending the specification to		<references>
	provide a variety of network performance metrics, including network		<name>Informative References</name>
	delay, delay variation (a.k.a, jitter), packet loss rate, hop count,
	and bandwidth.
	There are multiple sources (e.g., estimation based on measurements or		<reference anchor="I-D.ietf-idr-performance-routing" target="https://datatracker
	service-level agreement) to derive a performance metric. This		.ietf.org/doc/html/draft-ietf-idr-performance-routing-03">
	document introduces an additional "cost-context" field to the ALTO		<front>
	"cost-type" field to convey the source of a performance metric.		<title>Performance-based BGP Routing Mechanism</title>
			<author initials="X." surname="Xu" fullname="Xiaohu Xu">
			<organization>Alibaba, Inc</organization>
			</author>
			<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
			<organization>Juniper</organization>
			</author>
			<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar">
			<organization>Cisco</organization>
			</author>
			<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
			<organization>France Telecom</organization>
			</author>
			<author initials="C." surname="Jacquenet" fullname="Christian Jacquenet">
			<organization>France Telecom</organization>
			</author>
			<date month="December" day="21" year="2020"/>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-idr-performance-routing-03"/
			>
			</reference>
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9275.xml"
	</abstract>		/>
	</front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9439.xml"
	<seriesInfo name="Internet-Draft" value="draft-ietf-alto-performance-met		/>
	rics-28"/>
	</reference>
	<reference anchor="I-D.ietf-teas-ietf-network-slices">
	<front>
	<title>A Framework for IETF Network Slices</title>
	<author fullname="Adrian Farrel" initials="A." surname="Farrel">
	<organization>Old Dog Consulting</organization>
	</author>
	<author fullname="John Drake" initials="J." surname="Drake">
	<organization>Juniper Networks</organization>
	</author>
	<author fullname="Reza Rokui" initials="R." surname="Rokui">
	<organization>Ciena</organization>
	</author>
	<author fullname="Shunsuke Homma" initials="S." surname="Homma">
	<organization>NTT</organization>
	</author>
	<author fullname="Kiran Makhijani" initials="K." surname="Makhijani">
	<organization>Futurewei</organization>
	</author>
	<author fullname="Luis M. Contreras" initials="L. M." surname="Contrer
	as">
	<organization>Telefonica</organization>
	</author>
	<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
	<organization>Microsoft Inc.</organization>
	</author>
	<date day="21" month="January" year="2023"/>
	<abstract>
	<t> This document describes network slicing in the context of netw
	orks
	built from IETF technologies. It defines the term "IETF Network
	Slice" and establishes the general principles of network slicing in
	the IETF context.
	The document discusses the general framework for requesting and		<reference anchor="I-D.ietf-teas-ietf-network-slices"
	operating IETF Network Slices, the characteristics of an IETF Network		target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice
	Slice, the necessary system components and interfaces, and how		s-22">
	abstract requests can be mapped to more specific technologies. The		<front>
	document also discusses related considerations with monitoring and		<title>A Framework for IETF Network Slices</title>
	security.		<author initials="A." surname="Farrel" fullname="Adrian Farrel" role="editor">
			<organization>Old Dog Consulting</organization>
			</author>
			<author initials="J." surname="Drake" fullname="John Drake" role="editor">
			<organization>Juniper Networks</organization>
			</author>
			<author initials="R." surname="Rokui" fullname="Reza Rokui">
			<organization>Ciena</organization>
			</author>
			<author initials="S." surname="Homma" fullname="Shunsuke Homma">
			<organization>NTT</organization>
			</author>
			<author initials="K." surname="Makhijani" fullname="Kiran Makhijani">
			<organization>Futurewei</organization>
			</author>
			<author initials="L. M." surname="Contreras" fullname="Luis M. Contreras">
			<organization>Telefonica</organization>
			</author>
			<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
			<organization>Nvidia</organization>
			</author>
			<date month="August" year="2023"/>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slices-22"
			/>
			</reference>
	This document also provides definitions of related terms to enable		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1930.xml"
	consistent usage in other IETF documents that describe or use aspects		/>
	of IETF Network Slices.		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3357.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5136.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5693.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6534.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8175.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8548.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8558.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8684.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8803.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9097.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9217.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9298.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1940.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7676.xml"
			/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9049.xml"
			/>
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-sl
	ices-19"/>
	</reference>
	<reference anchor="RFC1930">
	<front>
	<title>Guidelines for creation, selection, and registration of an Auto
	nomous System (AS)</title>
	<author fullname="J. Hawkinson" initials="J." surname="Hawkinson">
	<organization/>
	</author>
	<author fullname="T. Bates" initials="T." surname="Bates">
	<organization/>
	</author>
	<date month="March" year="1996"/>
	<abstract>
	<t>This memo discusses when it is appropriate to register and utiliz
	e an Autonomous System (AS), and lists criteria for such. This document specifi
	es an Internet Best Current Practices for the Internet Community, and requests d
	iscussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="6"/>
	<seriesInfo name="RFC" value="1930"/>
	<seriesInfo name="DOI" value="10.17487/RFC1930"/>
	</reference>
	<reference anchor="RFC2616">
	<front>
	<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
	<author fullname="R. Fielding" initials="R." surname="Fielding">
	<organization/>
	</author>
	<author fullname="J. Gettys" initials="J." surname="Gettys">
	<organization/>
	</author>
	<author fullname="J. Mogul" initials="J." surname="Mogul">
	<organization/>
	</author>
	<author fullname="H. Frystyk" initials="H." surname="Frystyk">
	<organization/>
	</author>
	<author fullname="L. Masinter" initials="L." surname="Masinter">
	<organization/>
	</author>
	<author fullname="P. Leach" initials="P." surname="Leach">
	<organization/>
	</author>
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
	<organization/>
	</author>
	<date month="June" year="1999"/>
	<abstract>
	<t>HTTP has been in use by the World-Wide Web global information ini
	tiative since 1990. This specification defines the protocol referred to as "HTTP
	/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="2616"/>
	<seriesInfo name="DOI" value="10.17487/RFC2616"/>
	</reference>
	<reference anchor="RFC3357">
	<front>
	<title>One-way Loss Pattern Sample Metrics</title>
	<author fullname="R. Koodli" initials="R." surname="Koodli">
	<organization/>
	</author>
	<author fullname="R. Ravikanth" initials="R." surname="Ravikanth">
	<organization/>
	</author>
	<date month="August" year="2002"/>
	</front>
	<seriesInfo name="RFC" value="3357"/>
	<seriesInfo name="DOI" value="10.17487/RFC3357"/>
	</reference>
	<reference anchor="RFC3393">
	<front>
	<title>IP Packet Delay Variation Metric for IP Performance Metrics (IP
	PM)</title>
	<author fullname="C. Demichelis" initials="C." surname="Demichelis">
	<organization/>
	</author>
	<author fullname="P. Chimento" initials="P." surname="Chimento">
	<organization/>
	</author>
	<date month="November" year="2002"/>
	</front>
	<seriesInfo name="RFC" value="3393"/>
	<seriesInfo name="DOI" value="10.17487/RFC3393"/>
	</reference>
	<reference anchor="RFC4271">
	<front>
	<title>A Border Gateway Protocol 4 (BGP-4)</title>
	<author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rek
	hter">
	<organization/>
	</author>
	<author fullname="T. Li" initials="T." role="editor" surname="Li">
	<organization/>
	</author>
	<author fullname="S. Hares" initials="S." role="editor" surname="Hares
	">
	<organization/>
	</author>
	<date month="January" year="2006"/>
	<abstract>
	<t>This document discusses the Border Gateway Protocol (BGP), which
	is an inter-Autonomous System routing protocol.</t>
	<t>The primary function of a BGP speaking system is to exchange netw
	ork reachability information with other BGP systems. This network reachability
	information includes information on the list of Autonomous Systems (ASes) that r
	eachability information traverses. This information is sufficient for constructi
	ng a graph of AS connectivity for this reachability from which routing loops may
	be pruned, and, at the AS level, some policy decisions may be enforced.</t>
	<t>BGP-4 provides a set of mechanisms for supporting Classless Inter
	-Domain Routing (CIDR). These mechanisms include support for advertising a set
	of destinations as an IP prefix, and eliminating the concept of network "class"
	within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes,
	including aggregation of AS paths.</t>
	<t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4271"/>
	<seriesInfo name="DOI" value="10.17487/RFC4271"/>
	</reference>
	<reference anchor="RFC5136">
	<front>
	<title>Defining Network Capacity</title>
	<author fullname="P. Chimento" initials="P." surname="Chimento">
	<organization/>
	</author>
	<author fullname="J. Ishac" initials="J." surname="Ishac">
	<organization/>
	</author>
	<date month="February" year="2008"/>
	<abstract>
	<t>Measuring capacity is a task that sounds simple, but in reality c
	an be quite complex. In addition, the lack of a unified nomenclature on this su
	bject makes it increasingly difficult to properly build, test, and use technique
	s and tools built around these constructs. This document provides definitions f
	or the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling
	between a source and destination in an IP network. By doing so, we hope to pro
	vide a common framework for the discussion and analysis of a diverse set of curr
	ent and future estimation techniques. This memo provides information for the In
	ternet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5136"/>
	<seriesInfo name="DOI" value="10.17487/RFC5136"/>
	</reference>
	<reference anchor="RFC5693">
	<front>
	<title>Application-Layer Traffic Optimization (ALTO) Problem Statement
	</title>
	<author fullname="J. Seedorf" initials="J." surname="Seedorf">
	<organization/>
	</author>
	<author fullname="E. Burger" initials="E." surname="Burger">
	<organization/>
	</author>
	<date month="October" year="2009"/>
	<abstract>
	<t>Distributed applications -- such as file sharing, real-time commu
	nication, and live and on-demand media streaming -- prevalent on the Internet us
	e a significant amount of network resources. Such applications often transfer l
	arge amounts of data through connections established between nodes distributed a
	cross the Internet with little knowledge of the underlying network topology. So
	me applications are so designed that they choose a random subset of peers from a
	larger set with which to exchange data. Absent any topology information guidin
	g such choices, or acting on suboptimal or local information obtained from measu
	rements and statistics, these applications often make less than desirable choice
	s.</t>
	<t>This document discusses issues related to an information-sharing
	service that enables applications to perform better-than-random peer selection.
	This memo provides information for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5693"/>
	<seriesInfo name="DOI" value="10.17487/RFC5693"/>
	</reference>
	<reference anchor="RFC6534">
	<front>
	<title>Loss Episode Metrics for IP Performance Metrics (IPPM)</title>
	<author fullname="N. Duffield" initials="N." surname="Duffield">
	<organization/>
	</author>
	<author fullname="A. Morton" initials="A." surname="Morton">
	<organization/>
	</author>
	<author fullname="J. Sommers" initials="J." surname="Sommers">
	<organization/>
	</author>
	<date month="May" year="2012"/>
	<abstract>
	<t>The IETF has developed a one-way packet loss metric that measures
	the loss rate on a Poisson and Periodic probe streams between two hosts. Howeve
	r, the impact of packet loss on applications is, in general, sensitive not just
	to the average loss rate but also to the way in which packet losses are distribu
	ted in loss episodes (i.e., maximal sets of consecutively lost probe packets).
	This document defines one-way packet loss episode metrics, specifically, the fre
	quency and average duration of loss episodes and a probing methodology under whi
	ch the loss episode metrics are to be measured. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6534"/>
	<seriesInfo name="DOI" value="10.17487/RFC6534"/>
	</reference>
	<reference anchor="RFC7665">
	<front>
	<title>Service Function Chaining (SFC) Architecture</title>
	<author fullname="J. Halpern" initials="J." role="editor" surname="Hal
	pern">
	<organization/>
	</author>
	<author fullname="C. Pignataro" initials="C." role="editor" surname="P
	ignataro">
	<organization/>
	</author>
	<date month="October" year="2015"/>
	<abstract>
	<t>This document describes an architecture for the specification, cr
	eation, and ongoing maintenance of Service Function Chains (SFCs) in a network.
	It includes architectural concepts, principles, and components used in the cons
	truction of composite services through deployment of SFCs, with a focus on those
	to be standardized in the IETF. This document does not propose solutions, prot
	ocols, or extensions to existing protocols.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7665"/>
	<seriesInfo name="DOI" value="10.17487/RFC7665"/>
	</reference>
	<reference anchor="RFC7679">
	<front>
	<title>A One-Way Delay Metric for IP Performance Metrics (IPPM)</title
	>
	<author fullname="G. Almes" initials="G." surname="Almes">
	<organization/>
	</author>
	<author fullname="S. Kalidindi" initials="S." surname="Kalidindi">
	<organization/>
	</author>
	<author fullname="M. Zekauskas" initials="M." surname="Zekauskas">
	<organization/>
	</author>
	<author fullname="A. Morton" initials="A." role="editor" surname="Mort
	on">
	<organization/>
	</author>
	<date month="January" year="2016"/>
	<abstract>
	<t>This memo defines a metric for one-way delay of packets across In
	ternet paths. It builds on notions introduced and discussed in the IP Performan
	ce Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be fami
	liar with that document. This memo makes RFC 2679 obsolete.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="81"/>
	<seriesInfo name="RFC" value="7679"/>
	<seriesInfo name="DOI" value="10.17487/RFC7679"/>
	</reference>
	<reference anchor="RFC7680">
	<front>
	<title>A One-Way Loss Metric for IP Performance Metrics (IPPM)</title>
	<author fullname="G. Almes" initials="G." surname="Almes">
	<organization/>
	</author>
	<author fullname="S. Kalidindi" initials="S." surname="Kalidindi">
	<organization/>
	</author>
	<author fullname="M. Zekauskas" initials="M." surname="Zekauskas">
	<organization/>
	</author>
	<author fullname="A. Morton" initials="A." role="editor" surname="Mort
	on">
	<organization/>
	</author>
	<date month="January" year="2016"/>
	<abstract>
	<t>This memo defines a metric for one-way loss of packets across Int
	ernet paths. It builds on notions introduced and discussed in the IP Performanc
	e Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be famil
	iar with that document. This memo makes RFC 2680 obsolete.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="82"/>
	<seriesInfo name="RFC" value="7680"/>
	<seriesInfo name="DOI" value="10.17487/RFC7680"/>
	</reference>
	<reference anchor="RFC8175">
	<front>
	<title>Dynamic Link Exchange Protocol (DLEP)</title>
	<author fullname="S. Ratliff" initials="S." surname="Ratliff">
	<organization/>
	</author>
	<author fullname="S. Jury" initials="S." surname="Jury">
	<organization/>
	</author>
	<author fullname="D. Satterwhite" initials="D." surname="Satterwhite">
	<organization/>
	</author>
	<author fullname="R. Taylor" initials="R." surname="Taylor">
	<organization/>
	</author>
	<author fullname="B. Berry" initials="B." surname="Berry">
	<organization/>
	</author>
	<date month="June" year="2017"/>
	<abstract>
	<t>When routing devices rely on modems to effect communications over
	wireless links, they need timely and accurate knowledge of the characteristics
	of the link (speed, state, etc.) in order to make routing decisions. In mobile
	or other environments where these characteristics change frequently, manual conf
	igurations or the inference of state through routing or transport protocols does
	not allow the router to make the best decisions. This document introduces a ne
	w protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bi
	directional, event-driven communication channel between the router and the modem
	to facilitate communication of changing link characteristics.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8175"/>
	<seriesInfo name="DOI" value="10.17487/RFC8175"/>
	</reference>
	<reference anchor="RFC8547">
	<front>
	<title>TCP-ENO: Encryption Negotiation Option</title>
	<author fullname="A. Bittau" initials="A." surname="Bittau">
	<organization/>
	</author>
	<author fullname="D. Giffin" initials="D." surname="Giffin">
	<organization/>
	</author>
	<author fullname="M. Handley" initials="M." surname="Handley">
	<organization/>
	</author>
	<author fullname="D. Mazieres" initials="D." surname="Mazieres">
	<organization/>
	</author>
	<author fullname="E. Smith" initials="E." surname="Smith">
	<organization/>
	</author>
	<date month="May" year="2019"/>
	<abstract>
	<t>Despite growing adoption of TLS, a significant fraction of TCP tr
	affic on the Internet remains unencrypted. The persistence of unencrypted traff
	ic can be attributed to at least two factors. First, some legacy protocols lack
	a signaling mechanism (such as a STARTTLS command) by which to convey support fo
	r encryption, thus making incremental deployment impossible. Second, legacy app
	lications themselves cannot always be upgraded and therefore require a way to im
	plement encryption transparently entirely within the transport layer. The TCP E
	ncryption Negotiation Option (TCP-ENO) addresses both of these problems through
	a new TCP option kind providing out-of-band, fully backward-compatible negotiati
	on of encryption.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8547"/>
	<seriesInfo name="DOI" value="10.17487/RFC8547"/>
	</reference>
	<reference anchor="RFC8548">
	<front>
	<title>Cryptographic Protection of TCP Streams (tcpcrypt)</title>
	<author fullname="A. Bittau" initials="A." surname="Bittau">
	<organization/>
	</author>
	<author fullname="D. Giffin" initials="D." surname="Giffin">
	<organization/>
	</author>
	<author fullname="M. Handley" initials="M." surname="Handley">
	<organization/>
	</author>
	<author fullname="D. Mazieres" initials="D." surname="Mazieres">
	<organization/>
	</author>
	<author fullname="Q. Slack" initials="Q." surname="Slack">
	<organization/>
	</author>
	<author fullname="E. Smith" initials="E." surname="Smith">
	<organization/>
	</author>
	<date month="May" year="2019"/>
	<abstract>
	<t>This document specifies "tcpcrypt", a TCP encryption protocol des
	igned for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO
	). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and o
	ther manipulations of the TCP header. The protocol is self-contained and specif
	ically tailored to TCP implementations, which often reside in kernels or other e
	nvironments in which large external software dependencies can be undesirable. Be
	cause the size of TCP options is limited, the protocol requires one additional o
	ne-way message latency to perform key exchange before application data can be tr
	ansmitted. However, the extra latency can be avoided between two hosts that hav
	e recently established a previous tcpcrypt connection.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8548"/>
	<seriesInfo name="DOI" value="10.17487/RFC8548"/>
	</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="RFC8684">
	<front>
	<title>TCP Extensions for Multipath Operation with Multiple Addresses<
	/title>
	<author fullname="A. Ford" initials="A." surname="Ford">
	<organization/>
	</author>
	<author fullname="C. Raiciu" initials="C." surname="Raiciu">
	<organization/>
	</author>
	<author fullname="M. Handley" initials="M." surname="Handley">
	<organization/>
	</author>
	<author fullname="O. Bonaventure" initials="O." surname="Bonaventure">
	<organization/>
	</author>
	<author fullname="C. Paasch" initials="C." surname="Paasch">
	<organization/>
	</author>
	<date month="March" year="2020"/>
	<abstract>
	<t>TCP/IP communication is currently restricted to a single path per
	connection, yet multiple paths often exist between peers. The simultaneous use
	of these multiple paths for a TCP/IP session would improve resource usage within
	the network and thus improve user experience through higher throughput and impr
	oved resilience to network failure.</t>
	<t>Multipath TCP provides the ability to simultaneously use multiple
	paths between peers. This document presents a set of extensions to traditional
	TCP to support multipath operation. The protocol offers the same type of service
	to applications as TCP (i.e., a reliable bytestream), and it provides the compo
	nents necessary to establish and use multiple TCP flows across potentially disjo
	int paths.</t>
	<t>This document specifies v1 of Multipath TCP, obsoleting v0 as spe
	cified in RFC 6824, through clarifications and modifications primarily driven by
	deployment experience.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8684"/>
	<seriesInfo name="DOI" value="10.17487/RFC8684"/>
	</reference>
	<reference anchor="RFC8803">
	<front>
	<title>0-RTT TCP Convert Protocol</title>
	<author fullname="O. Bonaventure" initials="O." role="editor" surname=
	"Bonaventure">
	<organization/>
	</author>
	<author fullname="M. Boucadair" initials="M." role="editor" surname="B
	oucadair">
	<organization/>
	</author>
	<author fullname="S. Gundavelli" initials="S." surname="Gundavelli">
	<organization/>
	</author>
	<author fullname="S. Seo" initials="S." surname="Seo">
	<organization/>
	</author>
	<author fullname="B. Hesmans" initials="B." surname="Hesmans">
	<organization/>
	</author>
	<date month="July" year="2020"/>
	<abstract>
	<t>This document specifies an application proxy, called Transport Co
	nverter, to assist the deployment of TCP extensions such as Multipath TCP. A Tra
	nsport Converter may provide conversion service for one or more TCP extensions.
	The conversion service is provided by means of the 0-RTT TCP Convert Protocol (C
	onvert).</t>
	<t>This protocol provides 0-RTT (Zero Round-Trip Time) conversion se
	rvice since no extra delay is induced by the protocol compared to connections th
	at are not proxied. Also, the Convert Protocol does not require any encapsulatio
	n (no tunnels whatsoever).</t>
	<t>This specification assumes an explicit model, where the Transport
	Converter is explicitly configured on hosts. As a sample applicability use case
	, this document specifies how the Convert Protocol applies for Multipath TCP.</t
	>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8803"/>
	<seriesInfo name="DOI" value="10.17487/RFC8803"/>
	</reference>
	<reference anchor="RFC9000">
	<front>
	<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
	<author fullname="J. Iyengar" initials="J." role="editor" surname="Iye
	ngar">
	<organization/>
	</author>
	<author fullname="M. Thomson" initials="M." role="editor" surname="Tho
	mson">
	<organization/>
	</author>
	<date month="May" year="2021"/>
	<abstract>
	<t>This document defines the core of the QUIC transport protocol. Q
	UIC provides applications with flow-controlled streams for structured communicat
	ion, low-latency connection establishment, and network path migration. QUIC incl
	udes security measures that ensure confidentiality, integrity, and availability
	in a range of deployment circumstances. Accompanying documents describe the int
	egration of TLS for key negotiation, loss detection, and an exemplary congestion
	control algorithm.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9000"/>
	<seriesInfo name="DOI" value="10.17487/RFC9000"/>
	</reference>
	<reference anchor="RFC9097">
	<front>
	<title>Metrics and Methods for One-Way IP Capacity</title>
	<author fullname="A. Morton" initials="A." surname="Morton">
	<organization/>
	</author>
	<author fullname="R. Geib" initials="R." surname="Geib">
	<organization/>
	</author>
	<author fullname="L. Ciavattone" initials="L." surname="Ciavattone">
	<organization/>
	</author>
	<date month="November" year="2021"/>
	<abstract>
	<t>This memo revisits the problem of Network Capacity Metrics first
	examined in RFC 5136. This memo specifies a more practical Maximum IP-Layer Capa
	city Metric definition catering to measurement and outlines the corresponding Me
	thods of Measurement.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9097"/>
	<seriesInfo name="DOI" value="10.17487/RFC9097"/>
	</reference>
	<reference anchor="RFC9217">
	<front>
	<title>Current Open Questions in Path-Aware Networking</title>
	<author fullname="B. Trammell" initials="B." surname="Trammell">
	<organization/>
	</author>
	<date month="March" year="2022"/>
	<abstract>
	<t>In contrast to the present Internet architecture, a path-aware in
	ternetworking architecture has two important properties: it exposes the properti
	es of available Internet paths to endpoints, and it provides for endpoints and a
	pplications to use these properties to select paths through the Internet for the
	ir traffic. While this property of "path awareness" already exists in many Inter
	net-connected networks within single domains and via administrative interfaces t
	o the network layer, a fully path-aware internetwork expands these concepts acro
	ss layers and across the Internet.</t>
	<t>This document poses questions in path-aware networking, open as o
	f 2021, that must be answered in the design, development, and deployment of path
	-aware internetworks. It was originally written to frame discussions in the Path
	Aware Networking Research Group (PANRG), and has been published to snapshot cur
	rent thinking in this space.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9217"/>
	<seriesInfo name="DOI" value="10.17487/RFC9217"/>
	</reference>
	<reference anchor="RFC9298">
	<front>
	<title>Proxying UDP in HTTP</title>
	<author fullname="D. Schinazi" initials="D." surname="Schinazi">
	<organization/>
	</author>
	<date month="August" year="2022"/>
	<abstract>
	<t>This document describes how to proxy UDP in HTTP, similar to how
	the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this doc
	ument defines a protocol that allows an HTTP client to create a tunnel for UDP c
	ommunications through an HTTP server that acts as a proxy.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9298"/>
	<seriesInfo name="DOI" value="10.17487/RFC9298"/>
	</reference>
	<reference anchor="RFC1122">
	<front>
	<title>Requirements for Internet Hosts - Communication Layers</title>
	<author fullname="R. Braden" initials="R." role="editor" surname="Brad
	en">
	<organization/>
	</author>
	<date month="October" year="1989"/>
	<abstract>
	<t>This RFC is an official specification for the Internet community.
	It incorporates by reference, amends, corrects, and supplements the primary pr
	otocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="3"/>
	<seriesInfo name="RFC" value="1122"/>
	<seriesInfo name="DOI" value="10.17487/RFC1122"/>
	</reference>
	<reference anchor="RFC1940">
	<front>
	<title>Source Demand Routing: Packet Format and Forwarding Specificati
	on (Version 1)</title>
	<author fullname="D. Estrin" initials="D." surname="Estrin">
	<organization/>
	</author>
	<author fullname="T. Li" initials="T." surname="Li">
	<organization/>
	</author>
	<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
	<organization/>
	</author>
	<author fullname="K. Varadhan" initials="K." surname="Varadhan">
	<organization/>
	</author>
	<author fullname="D. Zappala" initials="D." surname="Zappala">
	<organization/>
	</author>
	<date month="May" year="1996"/>
	<abstract>
	<t>The purpose of SDRP is to support source-initiated selection of r
	outes to complement the route selection provided by existing routing protocols f
	or both inter-domain and intra-domain routes. This memo provides information fo
	r the Internet community. This memo does not specify an Internet standard of an
	y kind.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="1940"/>
	<seriesInfo name="DOI" value="10.17487/RFC1940"/>
	</reference>
	<reference anchor="RFC2784">
	<front>
	<title>Generic Routing Encapsulation (GRE)</title>
	<author fullname="D. Farinacci" initials="D." surname="Farinacci">
	<organization/>
	</author>
	<author fullname="T. Li" initials="T." surname="Li">
	<organization/>
	</author>
	<author fullname="S. Hanks" initials="S." surname="Hanks">
	<organization/>
	</author>
	<author fullname="D. Meyer" initials="D." surname="Meyer">
	<organization/>
	</author>
	<author fullname="P. Traina" initials="P." surname="Traina">
	<organization/>
	</author>
	<date month="March" year="2000"/>
	<abstract>
	<t>This document specifies a protocol for encapsulation of an arbitr
	ary network layer protocol over another arbitrary network layer protocol. [STAND
	ARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="2784"/>
	<seriesInfo name="DOI" value="10.17487/RFC2784"/>
	</reference>
	<reference anchor="RFC7676">
	<front>
	<title>IPv6 Support for Generic Routing Encapsulation (GRE)</title>
	<author fullname="C. Pignataro" initials="C." surname="Pignataro">
	<organization/>
	</author>
	<author fullname="R. Bonica" initials="R." surname="Bonica">
	<organization/>
	</author>
	<author fullname="S. Krishnan" initials="S." surname="Krishnan">
	<organization/>
	</author>
	<date month="October" year="2015"/>
	<abstract>
	<t>Generic Routing Encapsulation (GRE) can be used to carry any netw
	ork- layer payload protocol over any network-layer delivery protocol. Currently,
	GRE procedures are specified for IPv4, used as either the payload or delivery p
	rotocol. However, GRE procedures are not specified for IPv6.</t>
	<t>This document specifies GRE procedures for IPv6, used as either t
	he payload or delivery protocol.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7676"/>
	<seriesInfo name="DOI" value="10.17487/RFC7676"/>
	</reference>
	<reference anchor="RFC9049">
	<front>
	<title>Path Aware Networking: Obstacles to Deployment (A Bestiary of R
	oads Not Taken)</title>
	<author fullname="S. Dawkins" initials="S." role="editor" surname="Daw
	kins">
	<organization/>
	</author>
	<date month="June" year="2021"/>
	<abstract>
	<t>This document is a product of the Path Aware Networking Research
	Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to
	catalog and analyze past efforts to develop and deploy Path Aware techniques, mo
	st of which were unsuccessful or at most partially successful, in order to extra
	ct insights and lessons for Path Aware networking researchers.</t>
	<t>This document contains that catalog and analysis.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9049"/>
	<seriesInfo name="DOI" value="10.17487/RFC9049"/>
	</reference>
	</references>		</references>
	<section numbered="false" anchor="acknowledgments" toc="default">		<section numbered="false" anchor="acknowledgments" toc="default">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>Thanks to the Path-Aware Networking Research Group for the discussion a		<t>Thanks to the Path Aware Networking Research Group for the discussion
	nd feedback. Specifically, thanks to Mohamed Boucadair for the detailed review,		and feedback. Specifically, thanks to <contact fullname="Mohamed
	various text suggestions, and shepherding, thanks to Brian Trammell for suggesti		Boucadair"/> for the detailed review, various text suggestions, and
	ng the flow definition, and thanks to Luis M. Contreras, Spencer Dawkins, Paul H		shepherding; thanks to <contact fullname="Brian Trammell"/> for
	offman, Jake Holland, Colin Perkins, Adrian Perrig, and Matthias Rost for the re		suggesting the flow definition; and thanks to <contact fullname="Luis
	views, comments, and suggestions. Many thanks to Dave Oran for his careful IRSG		M. Contreras"/>, <contact fullname="Spencer Dawkins"/>, <contact
	review.</t>		fullname="Paul Hoffman"/>, <contact fullname="Jake Holland"/>, <contact
			fullname="Colin Perkins"/>, <contact fullname="Adrian Perrig"/>, and
			<contact fullname="Matthias Rost"/> for the reviews, comments, and
			suggestions. Many thanks to <contact fullname="Dave Oran"/> for his
			careful IRSG review.</t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAKElBmQAA61963LbSJbmfz4FwhMbI0WQbNlVvnZszKhs2a2Zkq2xVN2x
	OzGxkSSSJMogwAJAyewKv808xvzrF5vznUtmAqDsqt6pHy7xgrycPPfzneRs
	Npt0RVf6V9l59ud66Rb70jWHrF5l167bZNdNvfNNV/h24haLxt+9Gr2f18vK
	bWmAvHGrblY03Wq2c1Wzpn+7zWwXvjk7ezHJXedfTZb077puDq+yolrVk0mx
	a15lXbNvuydnZy/Pnkxc492r7PLj7dvJfd18Wjf1fkczn7//+G7yyR/ovZw+
	rjrfVL6bvcHEk0nbuSr/f66sK1rMgVa2K15l/97Vy2nW1k3X+FVLfx22+OM/
	JhO37zZ182qSzSYZ/VdU7avs4zy7qNYb1+Qdvykb++h96/sf1M3aVcVfXVfU
	1avsve9WZfGZP/FbV5S0MXrrnzuvz8xpmb2JXs+zf23+9p8bXy3+9l+bMpns
	9aEpynL8aX/Gi9s/Zf/3b//VFMtNOuuSH55/apzHw3u/Kf+ZSDz33eavc/rq
	BPRutjTIHR0DP3k5ezPHYmdF3szopPjzaulnRPOuqNbDr7myq+Vk7/yyAwGP
	fZ6Ms/UdLbMdfq/zrp3xX0QbHPKsLYult+99fPv68cvvzuKrJ88eP4uvvvvu
	6fP01cvv4qvvnzx/HF89ffxd8tzTZ+k3nz397vv46vmzZ0/TV89fpq9eJGt5
	8fh58s0XT79/3nv1In31NH317EUy34sXZ8laXp6dnaWvXiZjvnzyuPfqJcac
	zWaZW7Rd45bE/Lebos1IFPdbX3UZ/e0ykrx8v+wgy93Gi9ye35NogV9BcTpd
	4u3Wu2a5yd5BxrITlrHT+YS/HWU38593jW/bLDBQXdHsxCIZeIGmWzZ1i1n1
	NDOSRZ629c0dzhWD3RW5z7O7wmXtnqbkJ+eTywqLBUc5Xp2OMOX30jVs3SFb
	+Gy1L0vSUA19Tu87vHB3xP5uUfqsqzMiQMHf50kcrb3Kd3VRdTRXn0y5XxUV
	fRFrVZ1U/BVL7U88n7zdN7SXZls3fsq7ipTOMd2Kp/N3vnHlaNn3G5LSbFus
	Nx2Wv2897UAWquvCZmpMENY+nfj5ej7NiNg0bkmShsNaEGW8r5Tk9BE+Lqq7
	mo+yrbfeDjsQ28g/F4bZFnle+snkH6A9hT/oJME+PlvumwZbMr2agS+Kjube
	N9gxbaWqO3ACCSrZjAMReLcjzRo2kuVFu6yJCmxAaHF0njmWJgvuNsRj6w0v
	0Nikoh0wQdMnE+LhaAILubatlwUdVJ7dFx0PRIpZ2eh6xEE08xTnL8ecE6Wy
	G88bzh7PH2OiX39V6fryZUpfa5dNsSDD8ej4hpSwtjQsVPflDzhWPo5lvd3u
	q2KpIqJiUdHkQlVhbWwrTELGTlZFPKFbirN0G0cnsVrRwttMdTIe/wPNRdbU
	kd10VbvyzaMhdysPQCjXvvKkhIUSBc+lq0+molXlOYQcM2Cvq6Jpg/r4Ze9b
	PAgVcERa8UxCTWK3c1o7iQwt2pd8ZLQ7odfG3XniZWJkIpoeZV7QFpn9tp7s
	XLXmeeK78AiY5OnZ8gIhkA9sG2cBstIyiqou6/UBixB2kLWokiEJw7OtHMyq
	rO/befaDw+rwPJ8Jb2Yg/aZARgqD5Kl6cGEsqP6z2+5KYSPwzpJma5mDxtqn
	qKDlBnOXRds9rHSYbVRhqsZZqajhaTpI2luYd54x62BI2A7wapXLkS1wxIUo
	p88bRz4a+Q4stsZMd55O+33deZm0v+mgNkh26R1l5yrIE6akiYbLB2eRUOzH
	2h3PspY8YNGRLzHgpr6P2n/pqiC+fKz0gjyRxb7zo+kKmCB2QIm3us0huyfK
	0TZg32hcGmTnlX7J5uZDs9t4GEkwEu9tSdLiq3bf/n0mmJT0beTcyeSCd/1q
	Ald9tzm0pGNKGIE7crmJUHQe0JJsFvYVK5QpXkAMylL1Hi1Evtam3yO2FiO1
	K90BgtPUROyB3I7lfWU2eImgwRyBIECT80pPis+CGKmu2HNkc7da8d+vsg+V
	KFZ6AfGzR8C7MnhBH3kcUWJQWD3RLNOsmPs5lh/ZnchS0rJZOdKGKh/26Uqw
	zYRmlBU8ODF5OeXek/dKbLtjzavcZfOCOXQ5Pv/KIogFyMyWx9YxDf4Js8WN
	D2fU0Au2eGSK72qxJCk1bXV6BkYTWyotbd+q5PCRHVP14l4sSA4XbF7peZqX
	dG+7b5TAW7xD3yiJO6vw3qqpt0StxF05sPjnnjmzCoesi1XGamriuZZV5fKT
	78IKSEByetH4pSdF0k5tQy3z7rbOxbfC1HPi+4rmMRIfkQEb1cUPhd3xlroR
	4RSik+TA8yZGagt4flKu0AywiCWrmr1nc8X6oqW/lpveqlzZssaM3CTbhyZg
	dU1H8dvkUfch49AZnu+7uqq3NSmTmwOpzG12cn4DJfFjUX0SnbD1ebHnQ+v7
	ICu3LMBwontpKRWzCYmxkBhCXcMusSEmX2Qjzih2VtLotAQoX3busVHSBzg1
	O0m8Fm7gUea8otZE3s4hnsxfitnbIvh/gT6yKHrofAlOya7ZNcJcnVOaHDtn
	OzU5jOFw2KN9Y0sbY2O9qdnkiGHPWoq6I7fol8LWIUtVkdMJqODSJxJYkPCk
	7w9orrsn/vWlMBiWUjJlzIsPswv1iadqcqdb8rizMDD89uvEQ8FJX4g11tNg
	DY+B59lbcKy4FVMNqew5WxDoqzGjmaDsQr9ycv7+4nTgL//664OBPzt5WJtw
	X+t/EY0JFs9/dkt2eVLnKmNLLCfklHtsXezEbouugzalE2/MzYWXjD+ZN2XL
	c0TC12JsiHf75yNxZ7H1s9zv4MRAkkU9g2o+ECK7cw3t6xDdeNZs5BcFLlct
	Nw2xrBivuAuTACwj2QGrguXGVWtaawZrjecS31vXAHeEzuEkLA+nR2+kpOxT
	sEGep2oD65zi+Mu6Jj8uGYXpZ8ST3ciD4Tli3n0XtxTGT1hzy7u442Qgdgya
	njLp4XUFT8eZGlN+w6xF1w7DdjkMkznzCqAVc2/2hgcAwdQjwFEQEXPZ1GBG
	HpSjgyzf98N+Ci8k5uTsAMl/WyxEAY7oSUK7awoOeHT94iMXTfoYHyVbSCNE
	ukoWxt+xzo4imc6C4rgU1yXRTkmGpxRrodLKLkB2VMTVHK4LNlYtW7qEgUy1
	iZYxVhZVpIpSD6BVVTQdDEHuZzKCeS3975zfiAkjzr7QBEH2sYav/WHxsweX
	X3z8cMo6vK7Kg1lE4Rw4LmTnlxQZ7Rs4XfDW4dZXQkSRNtLFn6r6vtKoBFHz
	hqMCFlw2bvI8cynZw31J3qPDJOTHNLXL+UXru46jx3vWB0ETFQimiPbwiUwJ
	YCHqmuT4gIck2hud4Pxr1qD/uWZooqoQ/k4nmvI0fIJwpNnuEj8ubNOIO1T5
	xWXgFeb+Y5r7oACEQyyOq4U4FOv8zAY0UeeLA6/ijX5UwcqmfiE8Uu9J5Vto
	yhr+QrMU0PK3LLshaRWFHvrvuOKpo5M9NFBVzIAEpQzbPDJB/4Rk8OMnT5Ck
	UQNv31+WBZsucwdE2e2rSkT63i9w8vfk+p2KpYQTSIfytQfkK9B1HxFctxK3
	2f55w8xs7GcLXR0ULCJgHk4VLXx//5lZ/CuuAk1zs1/sdIZ3IsQWlJCw8UeS
	0P0tJnYlIaqo0slbClUw7IeKHYWEPYPrFtmT9EzRO1bOPUoALMsIKVi3IxGX
	43FJVAOGbf3IEeGACUeWCn1ZhlWw2AW3+vb1Nb3Ttiz4muUTP2lFxJl1e2wg
	GCryqsAz4h0W3TenOer1sftEzozKgTg0TA6MUVfeeOcBu6xxdnhCt8yrJ2OA
	sIy95G8ONEcApZSTgdgLNQEFG3AGx30utuTqc4jbOMu8mFvB+2RTpYp+PCzz
	6XBYl2/JQ4G94RxPXqvP4MRV4GcWvqyRnOvq8aBhvIdJ0ONonnO9bvzaiUPu
	Z/fsK5Qu5Id4lIXn/Db29ZCTptpGdg0NK9NQ2DzY5n6gsunYmKMgrbTd1Bex
	YzlpT6dxMWLk/HZHI0I8ihXN3XMFG3ruzmGxmnGLCpbp6Hp5elmbKqTRyZ5G
	7/POUdT/0IOP3y12LXTWeSTorsfP/agzqAIetR0cIOnkOsa9/BVax3JZa/al
	TsQesVJ40BRzcqo4kp5djNpKfdbAFKcW12GHV7c/pSZGOZ9OCPSxD8tSPZk6
	zSIN55SjCbPhGHtTIXJ2VWBApL2q5WGoP1Kdo/Yf3gzmWtSYNh3QVUnifM/8
	y3zdJsKB+kAZHDPIle6W88eBiBzDW85CCVztt0jox0hYtoCc0nZqVJqaQqQH
	1Iezrz/qGuKlQjYo4cveP0rfhxMKd+np2f/CkpVNkq+KHLhmUZDCoCghLFHr
	XW7XxjMoqh0FHDoISy1yq+E94tsPnIcacW3gLDO5tX1vJarUXMeUs6bGUNNM
	8+m27z37+pLmMpXbs1YaePQVUW8a9uHSaO/rKskyATJlzoURmLfhTisY1aYm
	8Yc+p6NCUtXygY4f4ShduSoogyi1rJDdcHAi/bLc55JDg2oqXIyG2E15aCrJ
	r9NeVGWkz0o8F8XOljA5FqCEpSysouIe3q1Ei6KgNSaG8UBU/aCUDi28zqsu
	hZQbP8PzJyWPbC1TxDQ9vbdCFZfMMYddEsKiWnfH6R6iQDUL8pYehWSK2867
	3KisJvcTkWpT13k0noEGm7rMkdW5dc3ad0MeqDlYgvU1foeJEVaP5pUrGt/g
	+HlSkiEb158tugoyeD0QPk4RW6DXEwfJHHCek9P/g4oTjYtIBLl+G1LDDo35
	NfoSh5MXFSdiGrbKbUsaFu6HaMdwqCiL9OoiJNJuLcWZIKSdX274U+CTWJem
	JcAktuiGqIlB5YvrpppUYp93GUAGn4s25KhWey6RJ1WSdAXzyU9aUi3adCEm
	H8NH5HS0SsnQBM2THFd2EtMPK1pMsPB9YexhOuEtowcAm5IEebICkcJQJ03m
	arPLa65DU2RkWpUoqZG7FahPNGp7+f3Zly+nJEUlqt/sV6KQWYjwhI0Nghis
	PUmGuINvTFsFcMJ5Ck44SYNEifTaUaI9JIjAoV0hh5wSCfNEbkSq9MZSGh8/
	zCcXCM1i9l98o6MHOI2DxqxfqxAQywaxBuWsUj9cLKoYkx0kw9nCbozMVIzE
	A7ZExgnRJQ3OwdGRiFQDvqplAIdunZM4ViXoLGH40BB61qxxwn5VSgJS4Mi0
	yVdkYi51/kRx9utQAx+ADLNf/4GIMONa9ZfJ5C8bfxwzBGNRt+OC/DfRNpJN
	CRwC5kRxnEU2hTyBY4jvPMKjwKDrmvShoi9a5bd+df4bBf5h9bzQknmVltwx
	IsNZpEzDoJTK36dSy4qgqbuaGH9KQ0Do49TYFEkY6VyJKfDwcYjVEgAFi2Lm
	k6u68bA5AkdCAT6p+qZc36MfZ6P6yVdVZlwRZSMWafhNjTbtq0KpT1bfzpne
	Isu3YuCWG9KLDTgEitU/k1u1ulEtLYI/tFhOafY11lF1C8PVL/VK3TRmVdS2
	cHWNa+iMlYNreSLO7p6MandqsIQY4dQtkbkMmBY2V72CdjJ6rG0znITkto1e
	OwagcBffIxIoDDCWpg2BR84sz1estKoCGUyhKK1imSTRkuZyT4LJYPqyB7ut
	iUe8ARgk6UNB1n0BHmzFKjcrtwQXINTSym1M20ti+ehqkrlbi6X3fdwMUEBh
	wLBoKxfrgs+j1pr9yBbptnErqLwPu67YKjI3Ozn/8fbDqUChADZFzlK83b7O
	y3beNzOGyvomCC3Csfoey4jayiHw7PDljatmpLJzCjf4qdbOheL+ixT2YmBN
	qWSwT9OlqisxetBdcNHkjQNToOcrFqq0ZCwll5AkBYhEwK+kDZf7hpEBAoQS
	lghOZykOvbDcgg6IfHvfJT7hEahCWjeicWSQXhZckAmIZwNeKAAlE4oc2Z/y
	agpdpb0dzDLb+yyaPC0HL7sGUESDHw4cegzL9NF8iY2REqo77BBS0ESkoaDT
	6q874h/IEf8LSeAbccTt5bWEpD+SEhAGRwGebClFRXwEgTU6mE3dgVBmkUDc
	6HSHUYJlnsZBpZnyAaXZhMmBuk7TyinrN/6XfWGBN3s0AgROYefGVGNG4Nh8
	mCbgGInkj21RncA8RAkX5GPR5DTTyc2Pl6df2dLXx4mBGY1DAg6RuLy4fRsO
	VtDracH8IYQ7yirnrZgbyZ6yPQnSnHEG1sOgCvxXi0BZuwV3cxg2Q6adsXfI
	LzWHIYDJ+DQGwnh+A19vwEUkhKWETw2A+v5O5ipB/mxVwNlUb/3ImBtyPHvs
	ZqGH5eVILi4Fjo6IMdiplSZRZcEsV90RudS6XwgrT6SKUh5OjQ+m6Zn1T0zy
	BuqJ0qFdtP/fpzZwwQtRaWBw3YRovYd5ODo24bSTgMN0P7CVRRteGgOIR8B+
	UyJtgH+XxAZBo+uyWe1J8MzOL219yS4/26xdjRKtlGxJ7nLVU5wsoLPzMLio
	jMcn1rWPCO7EgKzoSO7pGTrp1+KJ+7zV8LlznxAyRbUTseBB80SBHvl7R9x4
	LPAeJp7U+V1R71uivKXWmEk1+7Dx5Q6YV2CV6aNCpjaEO0OtQsg+gptbb0Ii
	khi6RJ4HjlEVsgQr2uyC1C8wGDtUb4jLDWiivhLRL/ezerWKCeThpOph9ARz
	rMhPDTWe+Ng9X67tTWalM1Lry00tLQABSHxkd+QHA3uyckWDyvCA2YvE24wI
	27pSigJqSD7KdsduhhnzkUXBQ/u252WZIJJ15gxCK2Vx0Qz/2Nrax7vF7LkG
	1knyn/s9SPJJk9EXOfukcrMaoxbP2bsiTiRdFdOVkS6uREdIt9lCde5LcqqL
	LUcCdfDKsp/rBZLl2HM/r3U0duHCH5NryeD0IHgc5Tf/2PZMJFjJVeqnrxwd
	QHCawedRpgwJUke8vsBUxIGPO1IXLGcaC45M83P9tAEUB+IAQYD2o+V+XpWP
	79XkPJzkSYAunt+cioLMf94DWN61QwJL/wqnhkpx0/RvyyMFNTGKmS+r7Id3
	11oqAmtmF5/JUrwpkDrewuOHzb+6eHMK1lTct5XsCyOqBD+zrWNAs6JUE0cv
	RkV4k5gRUCu3rfnM8LeCjQI/n99k1+e3fyJlUa0VDkUstGYcg/amffnyRymc
	j/MX05BP5q6AkDXUZBPtxopxciSJXJkV6ekM0JTf+ImTpEth4lzkhj1PaQ9g
	vUYagKIglIpo/oUrnSCMkbBInNbEVD7QMciwEcS6FtQk8e4PHIoHk8ZlTk1n
	95KbD/kzVd/1thkY81qtijXrdHt35xo6EiQq+9m2cYPFQ7gUTlJS1MTQlg6V
	IVgzhV+KuilZu6gA49j+7afL19oKc3Z29uWL1BNWGSyDdNQkqlIBWHrW/OhC
	SLSikUUClp/SolLYHZvVBMAVa9+ysLUrgBrPAHEGirbxbsu6IvHHBagoTE2x
	K2cqXXmqz/yyZ6B6L0rQGJJ9/gg/sM4SUisdaoFLVUS9c1bFQO7KfutnC1Zk
	ZIjJVZrxIPwQI2ZPhYHGKPgJNwsq/1pjQlYnVEn8qj4H6TY5AXJXf/KJGETc
	9ZGMpS3irZU3X28UJsBnjKbRiEvqWynuB9DqbuNTKzWqk53NPt7eIqOgCdnX
	dUXHCfvCs6BVlDjpHp3BC28+Xx7ViIDqmCVke4JtiKz8R1EQRSClDGY+TcK/
	V9dA4Mi0z158T9PSUumtolrqu0+/f07v2t8v6O8l6RtO86nXTszB02FITWZq
	r6D2f6YmbdAniE4HNTgaHhWSyxdOT+GAgG/WzJuJeyKc3iq8j2F18hbp6jaB
	Guq59kJShrSkwg8Lkfe4RnGWo2YC5W7OqS9r7OZUDoVjOCRU48JAH96iMAbI
	Yw0SWi8DlnEwA2fJL5KusXGOPAD3tDHJuh2x5CNtZ0M/NPJwaBqz7IshWWI2
	OYJo2LbF9Dy0/1+ih5CI0lcyx/1Ewgg9zJnVCbfyRpAv5KDlyofAVZD0bI7l
	OX9HlvkbtoBnZTomiW2evT+yBFIi8xRL1/dHU8LiFZbEwbGQlheke/cBbJu4
	WmI7Vv4+21CsYXi3Y5n2ry1oRYR39xJf/MEy1wjjSd6OrTFNv5UKqpMyUeMY
	HJlr4SOZvw/4Xjl0C0QHhXVg0rpjfiPa8yx/KHV/tAYqSo5789TM89JAIsmv
	kdreFLt+W0U4tB5yP8K5GBbWgyaYY6y1YRn6ThkpHMoA9fctSCD6iJHjpf89
	si6EdGSXoEkVii6Siex3kgEGZwcwlrazMDCwj9/emr8/7pm3WUkf5YeKHIFl
	erBHAC+Kc4lYwpGDxumFanZkOANnVdkFlByqtbxa0S8C/+buCK6tNRYToU4O
	ncPA5AC1V+kduHDoxdOZe7i19hWX+wHW6Ky2gPNwTVEeYq7BHo08YGxbMARy
	k62B0kec1soqOP0RxGFScFKrl8/qZScjqq4f1XMQga2zN0ADtyQFQfVy3QJJ
	OvbkNPLrD5ByeQJjyiK7p27PJwkOQ5HneMdh6r0sndQ9+6NLOofc+1ya79nP
	kMb1jSKLhrFU0qNr9TcEwMDRMF3GRyAMi/wRywZn1Wg5avK5W9wYPelfDCg5
	a1BMAgS5JoJHUkKQXvfsvAW7Lc4PZ0mEJTH3XS3FoLpdkpekOO3LSrWP9JwP
	T1vxumDeY3s7aJWelNyhjxCFgaCZOcwqanZmwBmyR/r0/fltUirA8wEP0+u9
	zfLQuknytvLMt9pwGHwncR3F10pBU73gAakR6cK7DTY64N8T1c1SLeWspKrK
	8SRLhIHkNIyMLQwRAFmPkOk9OPTlSno+hOCjRY17X6pgvGR1RLhgXelzbj6c
	0v+QLzTtxLrstS9LkJLm7Hq9nGlfzQhgpLsVM0/z2VTfvbu+zpY6JI//4uzJ
	/PFjmvltMc8+SCg36O1SnlB33Mlmh+VqxZmJe5BW4MSBTE/WAo6jJxbzzmnz
	gAuLJqaJeYl5liIU4FezV28XLJAAAjYuWDzTiaoCQ9d8xAhOrixOfE0hX2Cs
	Bt6uaJqdKyQsUQ6K3NMrXjITjW6eCU0NX+UtRbKj/WLgaFs/48DBVyRdOoj2
	QbQKiOZ+dGmhCZHhvOeyB94cjt6Gg7V8OnkQ1qB5LtdySHioMMkT0gqaEUa4
	dp1kaC6qjaZuroGwxO0ONxJ/EK8gKT6aPPICjToNKlj1W0xuSed7JTX42KOa
	aGNB6sMEKYXQ/FJ3m+iEmUfWaG+N6hsJfckAVktWNQrxkT4F2ZxItxzGuYgc
	L+itwuq59aZVVJNr1G69HfUgsP9+siUOnJ2m2J4rBRAMJj2HA2i9pCXz+NV8
	csUe4yoGC1mAqyZuq4uJiZMNhdpoQ9KYnd0rdRs4Rqq6wRPyAJL1B6TkWIuA
	loMY5dx810VZLz/15B9C40IHGTfTsyE86aeSTnWqVrCjPBvwTMmRDBua99oz
	GaRjZU4Eaj6toDkB737LU19JIpQR39r3oULFFSJNQUtz7+WK8arizriSdFcL
	p+i+jWBahY7jjiFLL/ADtLATqWP4/BSjXkVYyPAhOCNdMMEBxR4dt6upFMxT
	3jL4UQCIJszGNzQEbKTmWvtfCSqNczyDg44REgn0H356c81IW95bfwSaIzxR
	gNGQWE+SKAuPpHTdDEHa8TmEP6ZnhKrslGsuk9a/rjEQFEt0HVqWb+MxPEmT
	11v74s3/eR8YDw5Zk7MrJNUIcq9odr1e6IiQXiabrXm4sNJQs1JHiLXwUmOZ
	cD8ERhdVyJQz+gzwDSZnxjP9RWg9hIaShFc6Ug9NnfbBCII4gDxDS6Hcv2PL
	M8JA9vlpVtShuy2EekkxuLe6P93eXoNfPh+GF1qxqcHdeAI0ym1+vlenis2j
	bmlIFADeuD1XYDHyd1usicxtYr5wcx2PqQmqlPVTpkdDeKoohJOiXYxtx3q6
	jAuYyh4liJXivqinpNwg1wRJsn05KPRpR84BvO/L1aCJQyW+r1ZD860DFtmi
	mHCJi0W57/SqrI9agbqolm7XWnfCybuPF6dZtyehKLUz9clzJEnl7+fPnvNB
	9HHlRjpWi1qSh0mtVx0XfwyDbRqOIeLS1edtrkErsREEjyu5fP5HhraJNezS
	M0muHkhOposd33D4+81/b7j5z3wzueXOQJxpRkSAHOnllFkAEDd12QY3th76
	TieMbUlurzLPDGi21Gc61pWoN0SRwn13zXeDacFxGrt84eHoDS8hyYSeXj1X
	2WB2aff3NdqBES70aww7ZDGV1SS1LzL2punC572bOkItgT2nwbNy6vHj452X
	EBpE4+EiMxslWI6uTuq2fnSBy2TYoTlYRrpX4cl1WS84zKQhf6GY1sVrZ1q5
	dqbabxdooD6/eT++LERv7eQccNpnDtq+1ZPpLMEVwHnWXax+nEyA6tHGNQYM
	iVc2WOu35ifwRS4hG/JaE/H/QoxHgk308cCvFNwkEyoHRycKczB3x9aVru6Q
	kA1fj4yqdZrW2+1s8UvIjf3mDeRpT751dGazY5tAM4WGNJpdEFaQ7ALYpTcY
	q1m5ghXcQsvZK34i2b62MoS2/pUrSloZ33XTg27aYX/7soppcsQapMc7CToO
	zY6nm80P4PS4svHk5rDVPYRW/DA6J83C50W8byDcRZKGGmlzeBC/UftJ+OTh
	NRZVGJfsOVZ5rPVtfP2TpEu+0wuL1DSOLgbaqi3vLb3fDT+IZo8siUmT2O1H
	Kv6PIr2mlpH/O+iQnZCrFP3OU7sGR8oCpt/GdxrN7Tit0Sm9GuboRHXVu0VD
	useNF+WaMEQlr5Au6gICXBiwwUVsZb/X/2gvLw8Ss4hIjOHpzu5K2XLerkXF
	sgixp8ZBkf8SBP5owOM5/P64o5G0MCTcakK39L1EMO+0v0F0kTQhpVQM0oVa
	lLN6wdXtT2bprQG9Lf7qGaVfUzDF5YxVL2xdAVqRpdcOpC2x4FQ0KdC31lu7
	CydE+Qh+DBzSxtKfhv2Kroi5tnHApDMacMWT+7QokbXvpTrTNsloZYyihuNI
	WQr4ixnXskvOHHEp3N6YxmhCQltz1RlLSfqfgSI55yuJGdFlI8CEBXhATriV
	WyZkF2+9Awbx2xQI+17JE+zEhoLp17cZLuN5jRyz3JRJoQzGVY/24vV7aZ9A
	2PUWLd8fSCBpoRPOGg3z8ymSvof6T3rKtkVrbZw9nuGcryyXWT8ul3QCqNl7
	Oh09WYDdJWnJ99CzjKvDQiKq1+21OBxXbaGQ1aHVzvpkAmVdq5gUucHcgqNv
	XnUO9+f2N+xEJ9y6PJ21kPboeIMCHk0CQ3jMa0XuSp8/Lj8edB1Yc2PP447G
	iHz5fecTjSRW6Unqn5oCtg53Lf/nUdOY5RqVAHqobIkmHz9/yl5hD55mSkfD
	QMWsPXjJibMtyL3HjAV2ba9GaQElstcCFZfqp17hlN5kEm7Q0Xy7XAJzm6aq
	WdAoLq7XcICT78XFDt1fXDevmC/FgL0EWMa8GhIdvvRNzufyeqakE5C10YfR
	ej3iSJNzEXJnfN/r7yYMZ7CMLv/zRJFF/k9TpFf/NKL0K9aFlSDTCqkmQmL7
	hCoiqZGml8ZUAw8o1qlisuG3EKG/qCEd8IMCf/e+sz87VDS1OgEK3Nkbpnl7
	s7exURla98jqEwkdrz0OPtwFfmrhN+9CL3KTEaTztVeZSosKAfbaq0vGw3zg
	ariYVkxIlnREgVzXvREPxhlxD/GCt68zhlt1LEx2NwFXWO2qiKG3XZLp+D1c
	U6KKNWaaF2e/g2muxAAFY8Fj7oA3barWDvDpcxVH/tTvipZTUvwpfhGD8Xxs
	Y9XW6w25o4uFpHd5AqCmNL7AyeDtCyxnglx+QGyBPORBcf6CPSa7qSLBgxuI
	oD0C052KlbbiVNqgR1HynkxVvOBx2DIih2o37aYpEzmELVf3JWiSxL6hyAR4
	FFtCeo2JaSuGrSt1RuXhFKbE3kiKUUsrS6SpkQHlHe1Re8Dl17g1Ciy2bvhP
	aSRgHV5pfn2448DPx69qTtoBXccBoys1P26NC+Pm+S5pgwRzVAy54By8No7I
	CLiecdcUdw4OcS90GfYWlt5RmEJ/twzBHf+uiOOOiGmKG0Mza8hEWjr0BCV+
	osNpD9msSH/1K9PRpTDDpR0ueIR9YWGOoWpgARQ6pII2ow2hDYQioqDY+Jce
	VAtgma3h6ZI1zCdpdqhYGWHoKKxAm14TYvS6Or/5t58uONsP4v+7/uLLf0zD
	XRDxNpRpDF/Ag5x75/K5/TAKo/Lixfnq7RkvsHLqwZ7UyQsorFXapJCudowY
	ud1I8xdoI3y6q5F+L7gJO/ndiWlolNMLC4Qq5reOxMwYwC7qwYj2cJAMDpLi
	XR9WxZzGuyn3cg8pX+gn9S38OsBePHQpksg9/PFqcq8p/pdn378MLsw/xR+5
	QH5MwvIwEF+WuOz/uIBUm7YSu/kKHXSqzBgi+o3fGMDdjXK1u82T3F0TLg1R
	cQ6UDdTs/6YCEgjIAXSKRGMHHz96o6XEuKpKOutQQgJmYHyRX7cBRE6yHOZ+
	9guOBhaeplIBtXlXNHUl1xZxXZgVlOJEcX/4J39f4LFhC3pfnQbnwCe979r/
	F1deRk/MshKcJVg2nisscRPT6K6Iw9jb4W/4NYjjQdiAbUfaXC2M91uD2TW0
	zDVrRdW8ghJNrjA6duPPQ9caTYdHa1ffdEe7vuIVwbuQounsB240Na23rtpv
	89DhSR4MZUopwSTfsJtRww/+5D7AB/58/d5qNVxMuPdo32/T3gzl8KgGPnnG
	MODisKbQKPR+UzO6Pxab5Nsh0ZWNwHvWLPi126Ai6q4mk879prFwpj+3AM+h
	2xd2s1EYOvyakLSBJDCi5KKBWIwLP4sg3QG/jWnCPWnjKfoHywYBR2utyjqd
	uG+X5+/PR65b/5dNNly5lG+6cDO9/KYUOpQwzPnSUl+cZJn8+kpKDD7/349W
	rmz9I+5LcEhPKvsh+zj71g+iGLh2oK6t93ae3WiizH4kx2a4qjfkuufZD/V+
	6XJXNHEoT5a7ZJz3XeHvpxzw8OnyPXH7tabKNJPbbvyOVFTOtx3F8X9ocB/d
	beO2W/AtN3roo8lPlPTRASxbNsCPe6LxFVeRuoZIT9PRXkhYm+yNuyda0BvX
	jrTvn+rVaovrHf/FffL0qiz5vvHX5EdXwH7JV89zXhC9boq1zHVFvv+moMP7
	iESWbV923U6ZS3z43aNk33N6sjokS32DHoMPjWKepPW9YTTZ5cebdzrifPLf
	JgQA1VByAAA=
	</rfc>		</rfc>
End of changes. 85 change blocks.
	1631 lines changed or deleted		644 lines changed or added
This html diff was produced by rfcdiff 1.48.