<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.11 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-irtf-panrg-path-properties-08" submissionType="IRTF" category="info" consensus="true" docName="draft-irtf-panrg-path-properties-08" number="9473" obsoletes="" updates="" submissionType="IETF"
xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.10.0 -->

  <front>
    <title abbrev="Path Properties">A Vocabulary of Path Properties</title>
    <seriesInfo name="Internet-Draft" value="draft-irtf-panrg-path-properties-08"/> name="RFC" value="9473"/>
    <author initials="R." surname="Enghardt" fullname="Reese Enghardt">
      <organization>Netflix</organization>
      <address>
        <email>ietf@tenghardt.net</email>
      </address>
    </author>
    <author initials="C." surname="Krähenbühl" fullname="Cyrill Krähenbühl">
      <organization>ETH Zürich</organization>
      <address>
        <email>cyrill.kraehenbuehl@inf.ethz.ch</email>
      </address>
    </author>
    <date year="2023" month="March" day="06"/>
    <area>IRTF</area>
    <workgroup>PANRG</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document is a product of the Path month="September"/>
    <workgroup>Path Aware Networking Research Group (PANRG).
Path Networking</workgroup>

<keyword>PAN</keyword>
<keyword>path-aware network</keyword>
<keyword>path property</keyword>
<keyword>path selection</keyword>

    <abstract>
      <t>Path properties express information about paths across a
      network and the services provided via such paths.  In a path-aware
      network, path properties may be fully or partially available to entities
      such as endpoints.  This document defines and categorizes path
      properties.  Furthermore, the document identifies several path
      properties which that might be useful to endpoints or other entities, e.g.,
      for selecting between paths or for invoking some of the provided services.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this
      services.  This document takes place on is a product of the
      "Path-Aware 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/listinfo/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> Group (PANRG).</t>
    </abstract>

  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The current Internet architecture does not explicitly support
      endpoint discovery of forwarding paths through the network nor the
      discovery of properties and services associated with these paths.
      Path-aware networking, as defined in Section 1.1 of <xref target="RFC9217" format="default"/>,
      sectionFormat="of" section="1.1"/>, describes "endpoint discovery of the
      properties of paths they use for communication across an internetwork,
      and endpoint reaction to these properties that affects routing and/or
      data transfer".  This document provides a generic definition of path
      properties, addressing the first of the questions in path-aware
      networking <xref target="RFC9217" format="default"/>.</t>
      <t>As terms related to paths have been used with different meanings in
      different areas of networking, first, this document provides a common
      terminology to define paths, path elements, and flows. Based on these
      terms, the document defines path properties.  Then, this document
      provides some examples of use cases for path properties.  Finally, the
      document lists several path properties that may be useful for the
      mentioned use cases. This list is intended to be neither exhaustive nor
      definitive.</t>
      <t>Note that this document does not assume that any of the listed path
      properties are actually available to any entity. The question of how
      entities can discover and distribute path properties in a trustworthy
      way is out of scope for this document.</t>
      <t>This document represents the consensus of the Path Aware Networking Research Group (PANRG).</t>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <dl>
        <dt>
Entity:  </dt>
      <dl spacing="normal" newline="false">
        <dt>Entity:</dt>
        <dd>
          <t>A physical or virtual device or function, or a collection of
          devices or functions, which that plays a role related to path-aware
          networking for particular paths and flows.  An entity can be on-path
          or off-path: off-path. On the path, an entity may participate in forwarding
          the flow, i.e., what may be called data "data plane functionality. functionality".  On or
          off the path, an entity may influence aspects of how the flow is
          forwarded, i.e., what may be called control "control plane functionality, functionality",
          such as Path Selection path selection or Service Invocation. service invocation.  An entity influencing
          forwarding aspects is usually aware of path properties, e.g., by
          observing or measuring them or by learning them from another
          entity.</t>
        </dd>
        <dt>
Node:  </dt>
        <dt>Node:</dt>
        <dd>
          <t>An on-path entity which that processes packets, e.g., sends, receives,
          forwards, or modifies them. A node may be physical or virtual, e.g.,
          a physical device, a service function provided as a virtual element,
          or even a single queue within a switch. A node may also be an entity which
          that consists of a collection of devices or functions, e.g., an
          entire Autonomous System (AS).</t>
        </dd>
        <dt>
Link:  </dt>
        <dt>Link:</dt>
        <dd>
          <t>A medium or communication facility that connects two or more
          nodes with each other. A link enables a node to send packets to
          other nodes.  Links can be physical, e.g., a Wi-Fi network which that
          connects an Access Point to stations, or virtual, e.g., a virtual
          switch which that connects two virtual machines hosted on the same
          physical machine. A link is unidirectional. As such, bidirectional
          communication can be modeled as two links between the same nodes in
          opposite directions.</t>
        </dd>
        <dt>
Path element:  </dt>
        <dt>Path element:</dt>
        <dd>
          <t>Either a node or a link. For example, a path element can be an
          Abstract Network Element (ANE) as defined in <xref target="I-D.ietf-alto-path-vector" target="RFC9275"
          format="default"/>.</t>
        </dd>
        <dt>
Path:  </dt>
        <dt>Path:</dt>
        <dd>
          <t>A sequence of adjacent path elements over which a packet can be
          transmitted, starting and ending with a node.
</t> node.</t>
          <t>Paths are unidirectional and time-dependent, time dependent, i.e., there can be a
          variety of paths from one node to another, and the path over which
          packets are transmitted may change.  A path definition can be strict
          (i.e., the exact sequence of path elements remains the same) or
          loose (i.e., the start and end node remain the same, but the path
          elements between them may vary over time).</t>
          <t>The representation of a path and its properties may depend on the
          entity considering the path.  On the one hand, the representation
          may differ due to entities having partial visibility of path
          elements comprising a path or their visibility changing over time.
          On the other hand, the representation may differ due to treating
          path elements at different levels of abstraction.  For example, a
          path may be given as a sequence of physical nodes and the links
          connecting these nodes, be given as a sequence of logical nodes such
          as a sequence of ASes or an Explicit Route Object (ERO), or only
          consist of a specific source and destination which that is known to be
          reachable from that source.</t>
          <t>A multicast or broadcast setting, setting where a packet is sent by one
          node and received by multiple nodes, nodes is described by multiple paths
          over which the packet is sent, one path for each combination of
          sending and receiving node; these paths do not have to be disjoint
          as defined by the Disjointness disjointness path property, see <xref
          target="examples" format="default"/>.</t>
        </dd>
        <dt>
Endpoint:  </dt>
        <dt>Endpoint:</dt>
        <dd>
          <t>The endpoints of a path are the start and end node of the
          path. For example, an endpoint can be a host as defined in <xref
          target="RFC1122" format="default"/>, which can be a client (e.g., a
          node running a web browser) or a server (e.g., a node running a web
          server).</t>
        </dd>
        <dt>
Reverse Path:  </dt>
        <dt>Reverse Path:</dt>
        <dd>
          <t>The path that is used by a remote node in the context of
          bidirectional communication.</t>
        </dd>
        <dt>
Subpath:  </dt>
        <dt>Subpath:</dt>
        <dd>
          <t>Given a path, a subpath is a sequence of adjacent path elements
          of this path.</t>
        </dd>
        <dt>
Flow:  </dt>
        <dt>Flow:</dt>
        <dd>
          <t>One or multiple packets to which the traits of a path or set of
          subpaths may be applied in a functional sense. For example, a flow
          can consist of all packets sent within a TCP session with the same
          five-tuple between two hosts, or it can consist of all packets sent
          on the same physical link.</t>
        </dd>
        <dt>
Property:  </dt>
        <dt>Property:</dt>
        <dd>
          <t>A trait of one or a sequence of path elements, or a trait of a
          flow with respect to one or a sequence of path elements. An example
          of a link property is the maximum data rate that can be sent over
          the link. An example of a node property is the administrative domain
          that the node belongs to. An example of a property of a flow with
          respect to a subpath is the aggregated one-way delay of the flow
          being sent from one node to another node over this subpath.  A
          property is thus described by a tuple containing the path
          element(s), the flow or an empty set if no packets are relevant for
          the property, the name of the property (e.g., maximum data rate),
          and the value of the property (e.g., 1Gbps).</t> 1 Gbps).</t>
        </dd>
        <dt>
Aggregated property:  </dt>
        <dt>Aggregated property:</dt>
        <dd>
          <t>A collection of multiple values of a property into a single
          value, according to a function. A property can be aggregated over multiple
          over:</t>
	  <ul spacing="normal">
	    <li>multiple path elements (i.e., a subpath), e.g., for example, the MTU
	    of a path as the minimum MTU of all links on the path, over multiple path,</li>
	    <li>multiple packets (i.e., a flow), e.g., for example, the median
	    one-way latency of all packets between two nodes, or over both, e.g., nodes,</li>
	    <li>or both path elements and packets, for example, the mean of
	    the queueing delays of a flow on all nodes along a path.
The path.</li>
	    </ul>
	    <t>The aggregation function can be numerical, e.g., numerical (e.g., median, sum, minimum, it can be logical, e.g.,
	    minimum) or logical (e.g., "true if all are true", "true if at
	    least 50% of values are true", true"), or it can be an arbitrary function which
	    that maps multiple input values to an output value.</t>
        </dd>
        <dt>
Observed property:  </dt>
        <dt>Observed property:</dt>
        <dd>
          <t>A property that is observed for a specific path element, subpath,
          or path, e.g., path. A property may be observed using measurements. For measurements, for example,
          the one-way delay of a specific packet transmitted from one node to another node can be measured.</t>
          node.</t>
        </dd>
        <dt>
Assessed property:  </dt>
        <dt>Assessed property:</dt>
        <dd>
          <t>An approximate calculation or assessment of the value of a
          property. An assessed property includes the reliability of the
          calculation or assessment. The notion of reliability depends on the
          property.  For example, a path property based on an approximate
          calculation may describe the expected median one-way latency of
          packets sent on a path within the next second, including the
          confidence level and interval. A non-numerical assessment may
          instead include the likelihood that the property holds.</t>
        </dd>
        <dt>
Target property:  </dt>
        <dt>Target property:</dt>
        <dd>
          <t>An objective that is set for a property over a path element,
          subpath, or path.  Note that a target property can be set for
          observed properties, such as one-way delay, but and also for properties
          that cannot be observed by the entity setting the target, such as
          inclusion of certain nodes on a path.</t>
        </dd>
      </dl>

      <section anchor="terminology-usage-for-specific-technologies" numbered="true" toc="default">
        <name>Terminology usage Usage for specific technologies</name> Specific Technologies</name>
        <t>The terminology defined in this document is intended to be general
        and applicable to existing and future path-aware technologies.  Using
        this terminology, a path-aware technology can define and consider
        specific path elements and path properties on a specific level of
        abstraction.  For instance, a technology may define path elements as
        IP routers, e.g., in source routing (<xref <xref target="RFC1940" format="default"/>).
        format="default"/>. Alternatively, it may consider path elements on a
        different layer of the Internet Architecture (<xref architecture <xref target="RFC1122" format="default"/>)
        format="default"/> or as a collection of entities not tied to a
        specific layer, such as an AS or an ERO.  Even within a single path-aware
        technology, specific definitions might differ depending on the context
        in which they are used.  For example, the endpoints might be the
        communicating hosts in the context of the transport layer, ASes that
        contain the hosts in the context of routing, or specific applications
        in the context of the application layer.</t>
      </section>
    </section>
    <section anchor="use-cases" numbered="true" toc="default">
      <name>Use Cases for Path Properties</name>
      <t>When a path-aware network exposes path properties to endpoints or
      other entities, these entities may use this information to achieve
      different goals.  This section lists several use cases for path
      properties.</t>
      <t>Note that this is not an exhaustive list, list; as with every new
      technology and protocol, novel use cases may emerge, and new path
      properties may become relevant.  Moreover, for any particular
      technology, entities may have visibility of and control over different
      path elements and path properties, properties and consider them on different levels
      of abstraction.  Therefore, a new technology may implement an existing
      use case related to different path elements or on a different level of
      abstraction.</t>
      <section anchor="path-selection" numbered="true" toc="default">
        <name>Path Selection</name>
        <t>Nodes may be able to send flows via one (or a subset) out of
        multiple possible paths, and an entity may be able to influence the
        decision about which path(s) to use.  Path Selection selection may be feasible
        if there are several paths to the same destination (e.g., in case of a
        mobile device with two wireless interfaces, both providing a path), path) or
        if there are several destinations, and thus several paths, providing
        the same service (e.g., Application-Layer Traffic Optimization (ALTO)
        <xref target="RFC5693" format="default"/>, an application layer
        peer-to-peer protocol allowing endpoints a better-than-random peer
        selection).  Entities can express their intent to achieve a specific
        goal by specifying target properties for their paths, e.g., related to
        performance or security.  Then, paths can be selected which that best meet
        the target properties, e.g., the entity can select these paths from
        all available paths or express the target properties to the network
        and rely on the network to select appropriate paths.</t>
        <t>Target properties relating to network performance typically refer
        to observed properties, such as One-Way Delay, One-Way Packet Loss, one-way delay, one-way packet loss,
        and Link Capacity. link capacity.  Entities then select paths based on their target
        property and the assessed property of the available paths that best
        match the application requirements.  For such performance-related
        target properties, the observed property is similar to a service level indicator (SLI) Service Level
        Indicator (SLI), and the assessed property is similar to a service level objective Service
        Level Objective (SLO) for IETF network slices Network Slices <xref
        target="I-D.ietf-teas-ietf-network-slices" format="default"/>.  As an
        example path selection path-selection strategy, for sending a small delay-sensitive query, an entity may select a path with a
        short One-Way Delay, while one-way delay for retrieving sending a large file, small delay-sensitive query, while
        it may select a path with high Link Capacities link capacities on all links.</t> links for
        retrieving a large file.</t>
        <t>It is also possible for an entity to set target properties which that it
        cannot (directly) observe, similar to service level expectations Service Level Expectations
        (SLEs) for IETF network slices Network Slices <xref
        target="I-D.ietf-teas-ietf-network-slices" format="default"/>.
For example, this can  This
        may apply to security-related target properties (e.g., to mandate that
        all enterprise traffic goes through a specific firewall) and path selection, such as
        selection (e.g., to enforce traffic policies by allowing or disallowing
        sending flows over paths that involve specific networks or nodes to enforce traffic policies or mandating that all enterprise traffic goes through a specific firewall.</t> nodes).</t>
        <t>Care needs to be taken when selecting paths based on observed path
        properties, as path properties that were previously measured may not
        be helpful in predicting current or future path properties properties, and such
        path selection may lead to unintended feedback loops. Also, there may
        be trade-offs between path properties (e.g., One-Way Delay one-way delay and Link Capacity), link
        capacity), and entities may influence these trade-offs with their
        choices.  Finally, path selection may impact fairness.  For example,
        if multiple entities concurrently attempt to meet their target
        properties using the same network resources, one entity's choices may
        influence the conditions on the path as experienced by flows of
        another entity.</t>

        <t>As a baseline, a path selection path-selection algorithm should aim to do a better
        job at of meeting the target properties, and consequently accommodating
        the user's requirements, than the default case of not selecting a path
        most of the time.</t>
        <t>Path selection can be done either by the communicating node(s) or
        by other entities within the network: network.  A network (e.g., an AS) can
        adjust its path selection for internal or external routing based on
        path properties.  In BGP, the Multi Exit Multi-Exit Discriminator (MED) attribute
        is used in the decision-making process to select which path to choose
        among those having the same AS PATH 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 link capacity
        or Link Usage 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 anchor="protocol-selection" numbered="true" toc="default">
        <name>Protocol Selection</name>
        <t>Before sending data over a specific path, an entity may select an
        appropriate protocol or configure protocol parameters depending on
        path properties.  For example, an endpoint may cache state on whether if
        a path allows the use of QUIC <xref target="RFC9000" format="default"/> and
        format="default"/>; if so, it may first attempt to connect using QUIC
        before falling back to another protocol when connecting over this path
        again. A video streaming video-streaming application may choose an (initial) video
        quality based on the achievable data rate or the monetary cost of
        sending data (e.g., volume-base volume-based or flat-rate cost model).</t>
      </section>
      <section anchor="service-invocation" numbered="true" toc="default">
        <name>Service Invocation</name>
        <t>In addition to path or protocol selection, an entity may choose to
        invoke additional functions in the context of Service Function
        Chaining <xref target="RFC7665" format="default"/>, which may
        influence what which nodes are on the path.  For example, a 0-RTT Transport
        Converter <xref target="RFC8803" format="default"/> will be involved
        in a path only when invoked by an endpoint; such invocation will lead
        to the use of MPTCP Multipath TCP (MPTCP) <xref target="RFC8684"
        format="default"/> or TCPinc <xref target="RFC8547" format="default"/> tcpcrypt <xref target="RFC8548"
        format="default"/> capabilities capabilities, while such use is not supported via
        the default forwarding path.  Another example is a connection which that is
        composed of multiple streams where each stream has specific service
        requirements. An endpoint may decide to invoke a given service
        function (e.g., transcoding) only for some streams while others are
        not processed by that service function.</t>
      </section>
    </section>
    <section anchor="examples" numbered="true" toc="default">
      <name>Examples of Path Properties</name>
      <t>This Section section gives some examples of path properties which that may be
      useful, e.g., for the use cases described in <xref target="use-cases"
      format="default"/>.</t>
      <t>Within the context of any particular technology, available path
      properties may differ as entities have insight into and are able to
      influence different path elements and path properties.  For example, an
      endpoint may have some visibility into path elements that are close and on a low
      level of abstraction and close, e.g., (e.g., individual nodes within the first
      few hops, hops), or it may have visibility into path elements that are far away
      and/or on a higher level of abstraction, e.g., abstraction (e.g., the list of ASes traversed.
      traversed).  This visibility may depend on factors such as the physical
      or network distance or the existence of trust or contractual
      relationships between the endpoint and the path element(s).  A path
      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 two endpoints and a single virtual link connecting
      them.</t>
      <t>Path properties may be relatively dynamic, e.g., the one-way delay of
      a packet sent over a specific path, or non-dynamic, e.g., the MTU of an
      Ethernet link which that only changes infrequently.  Usefulness over time
      differs depending on how dynamic a property is:
The the merit of a
      momentarily observed dynamic path propety property may diminish greatly as time
      goes on, e.g., it is possible for the observed values of One-Way Delay one-way delay
      to change on timescales which that are shorter than the One-Way Delay one-way delay between
      the measurement point and an entity making a decision such as Path Selection, path
      selection, which may cause the measurement to be outdated when it
      reaches the decision-making entity. Therefore, consumers of dynamic path
      properties need to apply caution when using them, e.g., by aggregating
      them appropriately or applying a dampening function to their changes to avoiding
      avoid oscillation.  In contrast, the observed value of a less dynamic
      path property might stay relevant for a longer period of time, e.g. e.g., a
      NAT typically stays on a particular path during the lifetime of a
      connection involving packets sent over this path.</t>
      <dl>
        <dt>
Access Technology:  </dt>
      <dl spacing="normal" newline="false">
        <dt>Access Technology:</dt>
        <dd>
          <t>The physical physical- or link layer link-layer technology used for transmitting or
          receiving a flow on one or multiple path elements. If known, the Access Technology
          access technology may be given as an abstract link type, e.g., as
          Wi-Fi, Wired wired Ethernet, or Cellular. cellular. It may also be given as a
          specific technology used on a link, e.g., 3GPP cellular, cellular or 802.11 WiFi.
          Wireless Local Area Network (WLAN). Other path elements relevant to
          the access technology may include nodes related to processing
          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>
        <dt>
Monetary Cost:  </dt>
        <dt>Monetary Cost:</dt>
        <dd>
          <t>The price to be paid to transmit or receive a specific flow
          across a network to which one or multiple path elements belong.</t>
        </dd>
        <dt>
Service function:  </dt>
        <dt>Service Function:</dt>
        <dd>
          <t>A service function that a path element applies to a flow, see
          <xref target="RFC7665" format="default"/>. Examples of abstract
          service functions include firewalls, Network Address Translation
          (NAT), and TCP Performance Enhancing Proxies. Some stateful service
          functions, such as NAT, need to observe the same flow in both
          directions, e.g., by being an element of both the path and the
          reverse path.</t>
        </dd>
        <dt>
Transparency:  </dt>
        <dt>Transparency:</dt>
        <dd>

          <t>When a node performs an action A on a flow F, the node is
          transparent to F with respect to some (meta-)information M if the
          node performs A independently of M.  M can can, for example example, be the
          existence of a protocol (header) in a packet or the content of a
          protocol header, payload, or both.  For example, A can be blocking
          packets or reading and modifying (other protocol) headers or
          payloads.  Transparency can be modeled using a function f, which
          takes as input F and M and outputs the action taken by the node.  If
          a taint analysis shows that the output of f is not tainted
          (impacted) by M M, or if the output of f is constant for arbitrary
          values of M, then the node is considered to be transparent.  An IP
          router could be transparent to transport protocol headers such as
          TCP/UDP but not transparent to IP headers since its forwarding
          behavior depends on the IP headers.  A firewall that only allows
          outgoing TCP connections by blocking all incoming TCP SYN packets
          regardless of their IP address is transparent to IP but not to TCP
          headers.  Finally, a NAT that actively modifies IP and TCP/UDP
          headers based on their content is not transparent to either IP or
          TCP/UDP headers. Note that according to this definition, a node that
          modifies packets in accordance with the endpoints, such as a
          transparent HTTP proxy, as defined in <xref target="RFC2616" target="RFC9110"
          format="default"/>, and a node listening and reacting to implicit or
          explicit signals, see <xref target="RFC8558" format="default"/>, are
          not considered transparent.
</t> transparent.</t>
          <t>Transparency only applies to nodes and not to links, as a link
          cannot modify or perform any other actions on the packets by
          itself. For example, if the content of a packet is altered when
          forwarded over a Generic Routing Encapsulation (GRE) tunnel <xref
          target="RFC2784" format="default"/><xref format="default"/> <xref target="RFC7676"
          format="default"/>, per this document considers as nodes the software instances that
          terminate the tunnel are considered nodes over which the actions are
          performed; thus, the transparency definition applies to these
          nodes.</t>
        </dd>
        <dt>
Administrative Domain:  </dt>
        <dt>Administrative Domain:</dt>
        <dd>
          <t>The identity of an individual or an organization that controls
          access to a path element (or several path elements).  Examples of
          administrative domains are an IGP area, an AS, or a service provider
          network.</t>
        </dd>
        <dt>
Routing
        <dt>Routing Domain Identifier:  </dt> Identifier:</dt>
        <dd>
          <t>An identifier indicating the routing domain of a path element.
          Path elements in the same routing domain are in the same
          administrative domain and use a common routing protocol to
          communicate with each other.  An example of a routing domain
          identifier is the globally unique autonomous system number Autonomous System Number (ASN) as
          defined in <xref target="RFC1930" format="default"/>.</t>
        </dd>
        <dt>
Disjointness:  </dt>
        <dt>Disjointness:</dt>
        <dd>
          <t>For a set of two paths or subpaths, the number of shared path
          elements can be a measure of intersection (e.g., Jaccard
          coefficient, which is the number of shared elements divided by the
          total number of elements). Conversely, the number of non-shared path
          elements can be a measure of disjointness (e.g., 1 - Jaccard
          coefficient). A multipath protocol might use disjointness as a
          metric to reduce the number of single points of failure. As paths
          can be defined at different levels of abstraction, two paths may be
          disjoint at one level of abstraction, abstraction but not on another.</t>
        </dd>
        <dt>
Symmetric Path:  </dt>
        <dt>Symmetric Path:</dt>
        <dd>
          <t>Two paths are symmetric if the path and its reverse path consist
          of the same path elements on the same level of abstraction, but in
          reverse order.  For example, a path which that consists of layer 3
          switches and links between them and a reverse path with the same
          path elements but in reverse order are considered "routing"
          symmetric, as the same path elements on the same level of
          abstraction (IP forwarding) are traversed in the opposite direction.
          Symmetry can depend on the level of abstraction on which the path is
          defined or modeled: modeled. If there are two parallel physical links between
          two nodes, modeling them as separate links may result in a flow
          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>
        <dt>
Path MTU:  </dt>
        <dt>Path MTU:</dt>
        <dd>
          <t>The maximum size, in octets, of a packet or frame that can be
          transmitted without fragmentation.</t>
        </dd>
        <dt>
Transport
        <dt>Transport Protocols available:  </dt> available:</dt>
        <dd>
          <t>Whether a specific transport protocol can be used to establish a
          connection over a path or subpath, e.g., whether the path is
          QUIC-capable or MPTCP-capable, based on input such as policy, cached
          knowledge, or probing results.</t>
        </dd>
        <dt>
Protocol
        <dt>Protocol Features available:  </dt> available:</dt>
        <dd>
          <t>Whether a specific protocol feature is available over a path or
          subpath, e.g., Explicit Congestion Notification (ECN), (ECN) or TCP Fast
          Open.</t>
        </dd>
      </dl>

      <t>Some path properties express the performance of the transmission of a
      packet or flow over a link or subpath.  Such transmission performance
      properties can be observed or assessed, e.g., by endpoints or by path
      elements on the path, or they may be available as cost metrics, see
      <xref target="I-D.ietf-alto-performance-metrics" target="RFC9439" format="default"/>.  Transmission performance
      properties may be made available in an aggregated form, such as averages
      or minimums.  Properties related to a path element which that constitutes a
      single layer 2 domain are abstracted from the used physical physical- and link layer link-layer technology, similar to <xref target="RFC8175"
      format="default"/>.</t>
      <dl>
        <dt>
Link Capacity:  </dt>

      <dl spacing="normal" newline="false">
        <dt>Link Capacity:</dt>
        <dd>
          <t>The link capacity is the maximum data rate at which data that was
          sent over a link can correctly be received at the node adjacent to
          the link.  This property is analogous to the link capacity defined
          in <xref target="RFC5136" format="default"/> and <xref
          target="RFC9097" format="default"/> but is not restricted to IP-layer
          traffic.</t>
        </dd>
        <dt>
Link Usage:  </dt>
        <dt>Link Usage:</dt>
        <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.  This property is analogous to the link usage defined in <xref
          target="RFC5136" format="default"/> and <xref target="RFC9097"
          format="default"/> but is not restricted to IP-layer traffic.</t>
        </dd>
        <dt>
One-Way Delay:  </dt>
        <dt>One-Way Delay:</dt>
        <dd>
          <t>The one-way delay is the delay between a node sending a packet
          and another node on the same path receiving the packet.  This
          property is analogous to the one-way delay defined in <xref
          target="RFC7679" format="default"/> but is not restricted to IP-layer
          traffic.</t>
        </dd>
        <dt>
One-Way
        <dt>One-Way Delay Variation:  </dt> Variation:</dt>
        <dd>
          <t>The variation of the one-way delays within a flow.  This property
          is similar to the one-way delay variation defined in <xref
          target="RFC3393" format="default"/> format="default"/>, but it is not restricted to IP-layer
          traffic and it is defined for packets on the same flow instead of packets
          sent between a source and destination IP address.</t>
        </dd>
        <dt>
One-Way
        <dt>One-Way Packet Loss:  </dt> Loss:</dt>
        <dd>
          <t>Packets sent by a node but not received by another node on the
          same path after a certain time interval are considered lost.  This
          property is analogous to the one-way loss defined in <xref
          target="RFC7680" format="default"/> but is not restricted to IP-layer
          traffic.  Metrics such as loss patterns <xref target="RFC3357"
          format="default"/> and loss episodes <xref target="RFC6534"
          format="default"/> can be expressed as aggregated properties.</t>
        </dd>
      </dl>

    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>If entities are basing policy or path selection path-selection decisions on path
      properties, they need to rely on the accuracy of path properties that
      other devices communicate to them.  In order to be able to trust such
      path properties, entities may need to establish a trust relationship or
      be able to independently verify the authenticity, integrity, and
      correctness of path properties received from another entity.</t>
      <t>Entities that reveal their target path properties to the network can
      negatively impact their own privacy, e.g., if the target property leaks
      personal information about a user, such as their identity or which (type
      of) application is used.  Such information could then allow network
      operators to block or re-prioritize reprioritize traffic for certain users and/or application.
      applications.  Conversely, if privacy enhancing privacy-enhancing technologies, e.g.,
      MASQUE proxies <xref target="RFC9298" format="default"/>, are used on a
      path, the path may only be partially visible to any single entity.  This
      may diminish the usefulness of path-aware technologies over this
      path.</t>
      <t>The need for, and potential definition of, security security- and privacy related privacy-related path properties, such as confidentiality and integrity
      protection of payloads, are the subject of ongoing discussion and
      research, e.g., for example, see <xref target="RFC9049" format="default"/> and <xref
      target="RFC9217" format="default"/>. As the discussion of such
      properties is not mature enough, they are out of scope for this
      document.  One aspect discussed in this context is that security related security-related
      properties are difficult to characterize since they are only meaningful
      with respect to a threat model which that depends on the use case,
      application, environment, and other factors.  Likewise, properties for
      trust relations between entities cannot be meaningfully defined without
      a concrete threat model, and defining a threat model is out of scope for
      this document.  Properties related to confidentiality, integrity, and
      trust seem to be orthogonal to the path terminology and path properties
      defined in this document, since they are tied to the communicating nodes
      and the protocols they use (e.g., client and server using HTTPS, or
      client and remote network node using a VPN service) as well as
      additional context, such as keying material and who has access to such a
      context. In contrast, the path as defined in this document is typically
      oblivious to these aspects.  Intuitively, the path describes what
      function the network applies to packets, while confidentiality,
      integrity, and trust describe what function the communicating parties
      apply to packets.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-idr-performance-routing" to="PERFORMANCE-ROUTING"/>
<displayreference target="I-D.ietf-teas-ietf-network-slices" to="NETWORK-SLICES"/>

    <references>
      <name>Informative References</name>

<reference anchor="I-D.ietf-idr-performance-routing"> anchor="I-D.ietf-idr-performance-routing" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-performance-routing-03">
<front>
<title>Performance-based BGP Routing Mechanism</title>
<author fullname="Xiaohu Xu" initials="X." surname="Xu"> surname="Xu" fullname="Xiaohu Xu">
<organization>Alibaba, Inc</organization>
</author>
<author fullname="Shraddha Hegde" initials="S." surname="Hegde"> surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper</organization>
</author>
<author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar"> surname="Talaulikar" fullname="Ketan Talaulikar">
<organization>Cisco</organization>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> surname="Boucadair" fullname="Mohamed Boucadair">
<organization>France Telecom</organization>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet"> surname="Jacquenet" fullname="Christian Jacquenet">
<organization>France Telecom</organization>
</author>
<date day="22" month="December" day="21" 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>
          </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-performance-routing-03"/>
</reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9275.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9439.xml"/>

<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="Randriamasy">
            <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 Traffic 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 abstract information regarding the paths.  This is useful for applications whose performance 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 bottlenecks by avoiding such paths.  This extension introduces a new abstraction called the "Abstract Network Element" (ANE) to represent these components and encodes 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 traffic 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="Randriamasy">
            <organization>Nokia Bell Labs</organization>
          </author>
          <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras">
            <organization>Telefonica</organization>
          </author>
          <date day="21" month="March" year="2022"/>
          <abstract>
            <t>   The cost metric is a basic concept in Application-Layer Traffic
   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
   provide a variety of network performance metrics, including network
   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
   service-level agreement) to derive a performance metric.  This
   document introduces an additional "cost-context" field to the ALTO
   "cost-type" field to convey the source of a performance metric.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-alto-performance-metrics-28"/>
      </reference>
      <reference anchor="I-D.ietf-teas-ietf-network-slices"> anchor="I-D.ietf-teas-ietf-network-slices"
target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-22">
<front>
<title>A Framework for IETF Network Slices</title>
<author initials="A." surname="Farrel" fullname="Adrian Farrel" initials="A." surname="Farrel"> role="editor">
<organization>Old Dog Consulting</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake" initials="J." surname="Drake"> role="editor">
<organization>Juniper Networks</organization>
</author>
<author fullname="Reza Rokui" initials="R." surname="Rokui"> surname="Rokui" fullname="Reza Rokui">
<organization>Ciena</organization>
</author>
<author fullname="Shunsuke Homma" initials="S." surname="Homma"> surname="Homma" fullname="Shunsuke Homma">
<organization>NTT</organization>
</author>
<author fullname="Kiran Makhijani" initials="K." surname="Makhijani"> surname="Makhijani" fullname="Kiran Makhijani">
<organization>Futurewei</organization>
</author>
<author fullname="Luis M. Contreras" initials="L. M." surname="Contreras"> surname="Contreras" fullname="Luis M. Contreras">
<organization>Telefonica</organization>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
            <organization>Microsoft Inc.</organization> surname="Tantsura" fullname="Jeff Tantsura">
<organization>Nvidia</organization>
</author>
<date day="21" month="January" month="August" year="2023"/>
          <abstract>
            <t>   This document describes network slicing in the context of networks
   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
   operating IETF Network Slices, the characteristics of an IETF Network
   Slice, the necessary system components and interfaces, and how
   abstract requests can be mapped to more specific technologies.  The
   document also discusses related considerations with monitoring and
   security.

   This document also provides definitions of related terms to enable
   consistent usage in other IETF documents that describe or use aspects
   of IETF Network Slices.

            </t>
          </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slices-19"/>
      </reference>
      <reference anchor="RFC1930">
        <front>
          <title>Guidelines for creation, selection, and registration of an Autonomous 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 utilize an Autonomous System (AS), and lists criteria for such.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion 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 initiative 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 (IPPM)</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="Rekhter">
            <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 network reachability information with other BGP systems.  This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing 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 can be quite complex.  In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs.  This document provides definitions for 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 provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques.  This memo provides information for the Internet 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 communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources.  Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology.  Some 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 guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.</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. However, 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 distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets).  This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which 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="Halpern">
            <organization/>
          </author>
          <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro">
            <organization/>
          </author>
          <date month="October" year="2015"/>
          <abstract>
            <t>This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network.  It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF.  This document does not propose solutions, protocols, 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="Morton">
            <organization/>
          </author>
          <date month="January" year="2016"/>
          <abstract>
            <t>This memo defines a metric for one-way delay of packets across Internet paths.  It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar 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="Morton">
            <organization/>
          </author>
          <date month="January" year="2016"/>
          <abstract>
            <t>This memo defines a metric for one-way loss of packets across Internet paths.  It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar 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 configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, 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 traffic on the Internet remains unencrypted.  The persistence of unencrypted traffic 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 for encryption, thus making incremental deployment impossible.  Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer.  The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation 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 designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO).  Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header.  The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted.  However, the extra latency can be avoided between two hosts that have 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="Hardie">
            <organization/>
          </author>
          <date month="April" year="2019"/>
          <abstract>
            <t>This document discusses the nature of signals seen by on-path elements 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 path between the two nodes setting up the transport connection, they are often used as signals by those network elements.  In transports that do not exchange these 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 confidential channels.  Where the endpoints desire that network elements along the path receive 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 improved 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 components necessary to establish and use multiple TCP flows across potentially disjoint paths.</t>
            <t>This document specifies v1 of Multipath TCP, obsoleting v0 as specified 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="Boucadair">
            <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 Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport 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 (Convert).</t>
            <t>This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (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="Iyengar">
            <organization/>
          </author>
          <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
            <organization/>
          </author>
          <date month="May" year="2021"/>
          <abstract>
            <t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration 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 Capacity Metric definition catering to measurement and outlines the corresponding Methods 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 internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.</t>
            <t>This document poses questions in path-aware networking, open as of 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 current 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 document defines a protocol that allows an HTTP client to create a tunnel for UDP communications 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="Braden">
            <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 protocol 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 Specification (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 routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any 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 arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-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 network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol.  However, GRE procedures are not specified for IPv6.</t>
            <t>This document specifies GRE procedures for IPv6, used as either the 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 Roads Not Taken)</title>
          <author fullname="S. Dawkins" initials="S." role="editor" surname="Dawkins">
            <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, most of which were unsuccessful or at most partially successful, in order to extract 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"/> value="draft-ietf-teas-ietf-network-slices-22"/>
</reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1930.xml"/>
<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"/>

    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to the Path-Aware Path Aware Networking Research Group for the discussion
      and feedback. Specifically, thanks to Mohamed Boucadair <contact fullname="Mohamed
      Boucadair"/> for the detailed review, various text suggestions, and shepherding,
      shepherding; thanks to Brian Trammell <contact fullname="Brian Trammell"/> for
      suggesting the flow definition, definition; and thanks to Luis <contact fullname="Luis
      M. Contreras, Spencer Dawkins, Paul Hoffman, Jake Holland, Colin Perkins, Adrian Perrig, Contreras"/>, <contact fullname="Spencer Dawkins"/>, <contact
      fullname="Paul Hoffman"/>, <contact fullname="Jake Holland"/>, <contact
      fullname="Colin Perkins"/>, <contact fullname="Adrian Perrig"/>, and Matthias Rost
      <contact fullname="Matthias Rost"/> for the reviews, comments, and
      suggestions. Many thanks to Dave Oran <contact fullname="Dave Oran"/> for his
      careful IRSG review.</t>
    </section>
  </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>