<?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.24 -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-irtf-panrg-questions-12" category="info" number="9217" tocInclude="true" sortRefs="true" symRefs="true" obsoletes="" updates="" submissionType="IETF" submissionType="IRTF" category="info" consensus="true" xml:lang="en" version="3">

<!-- xml2rfc v2v3 conversion 3.12.0 [rfced] FYI: We've updated the term "path aware" when used in attributive position, including in the title of this document. Please let us know if this is not preferred.

Original:
   Current Open Questions in Path Aware Networking

Updated:
   Current Open Questions in Path-Aware Networking

Note: We did not hyphenate as part of "Path Aware Networking proposed Research Group" since it does not appear as part of the RG name.
-->

  <front>
    <title abbrev="PAN questions">Current Open Questions in Path Aware Path-Aware Networking</title>
    <seriesInfo name="Internet-Draft" value="draft-irtf-panrg-questions-12"/> name="RFC" value="9217"/>
    <author initials="B." surname="Trammell" fullname="Brian Trammell">
      <organization>Google Switzerland GmbH</organization>
      <address>
        <postal>
          <street>Gustav-Gull-Platz 1</street>
          <city>8004 Zurich</city>
          <city>Zurich</city>
          <code>8004</code>
          <country>Switzerland</country>
        </postal>
        <email>ietf@trammell.ch</email>
      </address>
    </author>
    <date year="2022" month="January" day="25"/> month="March"/>
    <workgroup>Path Aware Networking RG</workgroup>
    <keyword>Internet-Draft</keyword> Networking</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <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 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 proposed Research Group (PANRG), and has
      been published to snapshot current thinking in this space.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/panrg/questions"/>.</t>
    </note>
  </front>
  <middle>

<!-- [rfced] For ease of the reader, should a definition or reference for SD-WAN be added?  If yes, please provide the reference information.  Perhaps an informative reference to the definition in RFC 9061?

Original:
   (e.g., Path Computation Element (PCE) [RFC4655] and Software-Defined
   Wide Area Network (SD-WAN) approaches)
-->

    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction to Path-Aware Networking</name>
      <t>In the current Internet architecture, the network layer provides a
      best-effort service to the endpoints using it, without verifiability of
      the properties of the path between tne the endpoints. While there are network layer
      network-layer technologies that attempt better-than-best-effort
      delivery, the interfaces to these are generally administrative as
      opposed to endpoint-exposed (e.g. endpoint exposed (e.g., Path Computation Element (PCE) <xref
      target="RFC4655" format="default"/> and Software-Defined Wide Area
      Network (SD-WAN) approaches), and they are often restricted to single
      administrative domains. In this architecture, an application can assume
      that a packet with a given destination address will eventually be
      forwarded toward that destination, but little else.</t>
      <t>A transport layer transport-layer protocol such as TCP can provide reliability over
      this best-effort service, and a protocol above the network layer, such
      as Transport Layer Security (TLS) <xref target="RFC8446" format="default"/>
      format="default"/>, can authenticate the remote endpoint. However,
      little, if any, explicit information about the path is available to the
      endpoints, and any assumptions made about that path often do not hold.
      These sometimes have serious impacts on the application, as in the case
      with BGP hijacking attacks.</t>
      <t>By contrast, in a path-aware internetworking architecture, endpoints
      can select or influence the path(s) through the network used by any
      given packet or flow. The network and transport layers explicitly expose
      information about the path or paths available to the endpoints and to
      the applications running on them, so that they can make this
      selection. The Application Layer Application-Layer Traffic Optimization (ALTO) protocol
      <xref target="RFC7285" format="default"/> can be seen as an example of a
      path-awareness approach implemented in transport-layer terms on the
      present Internet protocol stack.</t>
      <t>Path selection provides explicit visibility and control of network treatment to
applications and users of the network. This selection is available to the
application, transport,
application-, transport-, and/or network layer network-layer entities at each endpoint. Path
control at the flow and subflow level enables the design of new transport
protocols that can leverage multipath connectivity across disjoint paths through
the Internet, even over a single physical interface.  When exposed to
applications, or to end-users end users through a system configuration interface, path
control allows the specification of constraints on the paths that traffic should
traverse, for instance to confound passive surveillance in the network core
<xref target="RFC7624" format="default"/>.</t>
      <t>We note that this property of "path awareness" already exists in many
      Internet-connected networks within single domains. Indeed, much of the
      practice of network engineering using encapsulation at layer 3 can be
      said to be "path
aware", aware" in that it explicitly assigns traffic at tunnel
      endpoints to a given path within the network. Path-aware internetworking
      seeks to extend this awareness across domain boundaries without
      resorting to overlays, except as a transition technology.</t>
      <t>This document presents a snapshot of open questions in this space that will need
to be answered in order to realize a path-aware internetworking architecture; it
is published to further frame discussions within and outside the Path Aware
Networking Research Group, and is published with the rough consensus of that
group.</t>
      <section anchor="definitions" numbered="true" toc="default">
        <name>Definitions</name>
        <t>For purposes of this document, "path aware "path-aware networking" 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. Note that this can and already does happen to some extent
in the current Internet architecture; this definition expands current techniques
of path discovery and manipulation to cross administrative domain boundaries and
up to the transport and application layers at the endpoints.</t>
        <t>Expanding on this definition, a "path aware "path-aware internetwork" is one in
        which endpoint discovery of path properties and endpoint selection of
        paths used by traffic exchanged by the endpoint are explicitly supported,
        supported regardless of the specific design of the protocol features which
        that enable this discovery and selection.</t>
        <t>A "path", for the purposes of these definitions, is abstractly
        defined as a sequence of adjacent path elements over which a packet
        can be transmitted, where the definition of "path element" is technology-dependent.
        technology dependent. As this document is intended to pose questions
        rather than answer them, it assumes that this definition will be
        refined as part of the answer to the first two questions it
poses, poses
        about the vocabulary of path properties and how they are
        disseminated.</t>
        <t>Research into path aware path-aware internetworking covers any and all aspects of
designing, building, and operating path aware path-aware internetworks or the networks
and endpoints attached to them. This document presents a collection of
research questions to address in order to make a path aware path-aware Internet a
reality.</t>
      </section>
    </section>
    <section anchor="questions" numbered="true" toc="default">
      <name>Questions</name>
      <t>Realizing path-aware networking requires answers to a set of open
      research questions. This document poses these questions, questions as a starting
      point for discussions about how to realize path awareness in the Internet,
      Internet and to direct future research efforts within the Path Aware
      Networking Research Group.</t>
      <section anchor="a-vocabulary-of-path-properties" numbered="true" toc="default">
        <name>A Vocabulary of Path Properties</name>
        <t>The first question: how are paths and path properties defined and represented?</t>
        <t>In order for information about paths to be exposed to an endpoint,
        and for the endpoint to make use of that information,
<!-- [rfced] Is it necessary to a) define a common vocabulary for paths and b) the properties of those paths, or to define a) a common vocablary for paths and b) properties of the paths?

Original:
   In order for information about paths to be exposed to an endpoint,
   and for the endpoint to make use of that information, it is necessary
   to define a common vocabulary for paths through an internetwork, and
   properties of those paths.
-->
it is necessary
        to define a common vocabulary for paths through an internetwork and
        properties of those paths. The elements of this vocabulary could
        include terminology for components of a path and properties defined
        for these components, for the entire path, path or for subpaths of a
        path. These properties may be relatively static, such as the presence
        of a given node or service function on the path; path, as well as relatively
        dynamic, such as the current values of metrics such as loss and
        latency.</t>
        <t>This vocabulary and its representation must be defined carefully,
        as its design will have impacts on the properties (e.g.,
        expressiveness, scalability, and security) of a given path-aware
        internetworking architecture. For example, a system that exposes
        node-level information for the topology through each network would
        maximize information about the individual components of the path at
        the endpoints, at the expense of making internal network topology
        universally public, which may be in conflict with the business goals
        of each network's operator. Furthermore, properties related to
        individual components of the path may change frequently and may
        quickly become outdated. However, aggregating the properties of
        individual components to distill end-to-end properties for the entire
        path is not trivial.</t>
      </section>
      <section anchor="discovery-distribution-and-trustworthiness-of-path-properties" numbered="true" toc="default">
        <name>Discovery, Distribution, and Trustworthiness of Path Properties</name>
        <t>The second question: how do endpoints and applications get access to accurate,
useful, and trustworthy path properties?</t>
        <t>Once endpoints and networks have a shared vocabulary for expressing
        path properties, the network must have some method for distributing
        those path properties to the endpoints. Regardless of how path
        property information is distributed, the endpoints require a method to
        authenticate the properties -- in order to determine that they originated
        from and pertain to the path that they purport to.</t>
        <t>Choices in distribution and authentication methods will have impacts on the
scalability of a path-aware architecture. Possible dimensions in the space of
distribution methods include in-band in band versus out-of-band, out of band, push versus pull
versus publish-subscribe, publish subscribe, and so on. There are temporal issues with path
property dissemination as well, especially with dynamic properties, since the
measurement or elicitation of dynamic properties may be outdated by the time
that information is available at the endpoints, and interactions between the
measurement and dissemination delay may exhibit pathological behavior for
unlucky points in the parameter space.</t>
      </section>
      <section anchor="supporting-path-selection" numbered="true" toc="default">
        <name>Supporting Path Selection</name>
        <t>The third question: how can endpoints select paths to use for
        traffic in a way that can be trusted by the network, the endpoints,
        and the applications using them?</t>
        <t>Access to trustworthy path properties is only half of the challenge
        in establishing a path-aware architecture. Endpoints must be able to
        use this information in order to select paths for specific traffic
        they send. As with the dissemination of path properties, choices made
        in path selection path-selection methods will also have an impact on the tradeoff trade-off
        between scalability and expressiveness of a path-aware
        architecture. One key choice here is between in-band and out-of-band
        control of path selection. Another is granularity of path selection
        (whether per packet, per flow, or per larger aggregate), which also
        has a large impact on the scalabilty/expressiveness tradeoff. scalability/expressiveness trade-off. Path
        selection must, like path property information, be trustworthy, such
        that the result of a path selection at an endpoint is
        predictable. Moreover, any path selection path-selection mechanism should aim to
        provide an outcome that is not worse than using a single path, path or
        selecting paths at random.</t>
        <t>Path selection may be exposed in terms of the properties of the path or the identity
of elements of the path. In the latter case, a path may be identified at any of
multiple layers (e.g. (e.g., routing domain identifier, network layer network-layer address, higher-layer
identifier or name, and so on). In this case, care must be taken to present
semantically useful information to those making decisions about which path(s)
to trust.</t>
      </section>
      <section anchor="interfaces-for-path-awareness" numbered="true" toc="default">
        <name>Interfaces for Path Awareness</name>
        <t>The fourth question: how can interfaces among the network,
        transport, and application layers support the use of path
        awareness?</t>
        <t>In order for applications to make effective use of a path-aware
        networking architecture, the control interfaces presented by the
        network and transport layers must also expose path properties to the
        application in a useful way, and provide a useful set of paths among
        which the application can select. Path selection must be possible
        based not only on the preferences and policies of the application
        developer, but of end-users end users as well. Also, the path selection path-selection
        interfaces presented to applications and end users will need to
        support multiple levels of granularity. Most applications'
        requirements can be satisfied with the expression of path selection path-selection
        policies in terms of properties of the paths, while some applications
        may need finer-grained, per-path control. These interfaces will need
        to support incremental development and deployment of applications, and
        provide sensible defaults, to avoid hindering their adoption.</t>
      </section>
      <section anchor="implications-of-path-awareness-for-the-transport-and-application-layers" numbered="true" toc="default">
        <name>Implications of Path Awareness for the Transport and Application Layers</name>
        <t>The fifth question: how should transport-layer and higher layer higher-layer
        protocols be redesigned to work most effectively over a path-aware
        networking layer?</t>
        <t>In the current Internet, the basic assumption that at a given time all
traffic for a given flow will receive the same network treatment and traverse
the same path or equivalend equivalent paths often holds. In a path aware path-aware network,
this assumption is more easily violated. The weakening of this assumption
has implications for the design of protocols above any path-aware network layer.</t>
        <t>For example, one advantage of multipath communication is that a given
end-to-end flow can be "sprayed" along multiple paths in order to confound
attempts to collect data or metadata from those flows for pervasive
surveillance purposes <xref target="RFC7624" format="default"/>. However, the benefits of this approach are
reduced if the upper-layer protocols use linkable identifiers on packets
belonging to the same flow across different paths. Clients may mitigate
linkability by opting to not re-use reuse cleartext connection identifiers, such as
TLS session IDs or tickets, on separate paths. The privacy-conscious
strategies required for effective privacy in a path-aware Internet are only
possible if higher-layer protocols such as TLS permit clients to obtain
unlinkable identifiers.</t>
      </section>
      <section anchor="what-is-an-endpoint" numbered="true" toc="default">
        <name>What is an Endpoint?</name>
        <t>The sixth question: how is path awareness (in terms of vocabulary and
interfaces) different when applied to tunnel and overlay endpoints?</t>
        <t>The vision of path-aware networking articulated so far makes an assumption
that path properties will be disseminated to endpoints on which applications
are running (terminals with user agents, servers, and so on). However,
incremental deployment may require that a path-aware network "core" be used to
interconnect islands of legacy protocol networks. In these cases, it is the
gateways, not the application endpoints, that receive path properties and make
path selections for that traffic. The interfaces provided by this gateway are
necessarily different than those a path-aware networking layer provides to its
transport and application layers, and the path property information the
gateway needs and makes available over those interfaces may also be different.</t>
      </section>
      <section anchor="operating-a-path-aware-network" numbered="true" toc="default">
        <name>Operating a Path Aware Path-Aware Network</name>
        <t>The seventh question: how can a path aware path-aware network in a path aware path-aware internetwork
be effectively operated, given control inputs from network administrators,
application designers, and end users?</t>
        <t>The network operations model in the current Internet architecture
        assumes that traffic flows are controlled by the decisions and
        policies made by network
operators, operators as expressed in interdomain and
        intradomain routing protocols. In a network providing path selection
        to the endpoints, however, this assumption no longer holds, as
        endpoints may react to path properties by selecting alternate
        paths. Competing control inputs from path-aware endpoints and the
        routing control plane may lead to more difficult traffic engineering
        or nonconvergent non-convergent forwarding, especially if the endpoints' and
        operators' notion of the "best" path for given traffic diverges
        significantly. The degree of difficulty may depend on the fidelity of
        information made available to path selection path-selection algorithms at the
        endpoints. Explicit path selection can also specify outbound paths,
        while BGP policies are expressed in terms of inbound traffic.</t>
        <t>A concept for path aware path-aware network operations will need to have clear
        methods for the resolution of apparent (if not actual) conflicts of
        intent between the network's operator and the path selection at an
        endpoint. It will also need a set of safety principles to ensure that
        increasing path control does not lead to decreasing connectivity; one
        such safety principle could be "the existence of at least one path
        between two endpoints guarantees the selection of at least one path
        between those endpoints."</t>
      </section>
      <section anchor="deploying-a-path-aware-network" numbered="true" toc="default">
        <name>Deploying a Path Aware Path-Aware Network</name>
        <t>The eighth question: how can the incentives of network operators and end-users end users
be aligned to realize the vision of path aware path-aware networking, and how can the
transition from current ("path-oblivious") to path-aware networking be managed?</t>
        <t>The vision presented in the introduction discusses path aware path-aware
        networking from the point of view of the benefits accruing at the
        endpoints, to designers of transport protocols and applications as
        well as to the end users of those applications. However, this vision
        requires action not only at the endpoints but also within the
        interconnected networks offering path aware path-aware connectivity. While the
        specific actions required are a matter of the design and
        implementation of a specific realization of a path aware path-aware protocol
        stack, it is clear than that any path
aware path-aware architecture will require
        network operators to give up some control of their networks over to
        endpoint-driven control inputs.</t>
        <t>Here
        <t>Here, the question of apparent versus actual conflicts of intent
        arises again: certain network operations operation requirements may appear essential,
        essential but are merely accidents of the interfaces provided by
        current routing and management protocols. For example, related (but
        adjacent) to path aware path-aware networking, the widespread use of the TCP wire
        image <xref target="RFC8546" format="default"/> in network monitoring
        for DDoS prevention appears in conflict with the deployment of
        encrypted transports, only because path signaling <xref
        target="RFC8558" format="default"/> has been implicit in the
        deployment of past transport protocols.</t>
        <t>Similarly, incentives for deployment must show how existing network operations
        operation requirements are met through new path selection and property
        dissemination mechanisms.</t>
        <t>The incentives for network operators and equipment vendors need to
        be made clear, in terms of a plan to transition <xref target="RFC8170"
        format="default"/> an internetwork to path-aware operation, one
        network and facility at a time. This plan to transition must also take
        into account that the dynamics of path aware path-aware networking early in this
        transition (when few endpoints and flows in the Internet use path
        selection) may be different than those later in the transition.</t>
        <t>Aspects of data security and information management in a network that explicitly
radiates more information about the network's deployment and configuration, and
implicitly radiates information about endpoint configuration and preference
through path selection, must also be addressed.</t>
      </section>
    </section>

<!-- [rfced] Please provide text for a Security Considerations section per the RFC Style Guide (see section 4.8.5 of RFC 7322 <https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.5>).

In addition, please consider whether an IANA Considerations section should be added.  While the section is not required in RFCs, IANA prefers that a section be included to clearly indicate that "this document has no IANA actions."
-->

  </middle>
  <back>
    <references>
      <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8546.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8558.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8170.xml"/>

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

Note that our scripts did not find any words of concern.
-->

    </references>
    <section anchor="acknowledgments" numbered="true" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kuehlewind, Olivier
Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood, Lee Howard, Mohamed
Boucadair, Thorben Krueger, Gorry Fairhurst, Spencer Dawkins, Reese Enghardt,
Laurent Ciavaglia, Stephen Farrell, and Richard Yang, <contact fullname="Adrian Perrig"/>, <contact
      fullname="Jean-Pierre Smith"/>, <contact fullname="Mirja Kühlewind"/>,
      <contact fullname="Olivier Bonaventure"/>, <contact fullname="Martin
      Thomson"/>, <contact fullname="Shwetha Bhandari"/>, <contact
      fullname="Chris Wood"/>, <contact fullname="Lee Howard"/>, <contact
      fullname="Mohamed Boucadair"/>, <contact fullname="Thorben Krüger"/>,
      <contact fullname="Gorry Fairhurst"/>, <contact fullname="Spencer
      Dawkins"/>, <contact fullname="Reese Enghardt"/>, <contact
      fullname="Laurent Ciavaglia"/>, <contact fullname="Stephen Farrell"/>,
      and <contact fullname="Richard Yang"/> for discussions leading to
      questions in this document, document and for feedback on the document itself.</t>
      <t>This work is partially supported by the European Commission under
      Horizon 2020 grant agreement no. 688421 Measurement and Architecture for
      a Middleboxed Internet (MAMI), (MAMI) and by the Swiss State Secretariat for
      Education, Research, and Innovation under contract no. 15.0268. This
      support does not imply endorsement.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Informative References</name>
      <reference anchor="RFC4655">
        <front>
          <title>A Path Computation Element (PCE)-Based Architecture</title>
          <author fullname="A. Farrel" initials="A." surname="Farrel">
            <organization/>
          </author>
          <author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur">
            <organization/>
          </author>
          <author fullname="J. Ash" initials="J." surname="Ash">
            <organization/>
          </author>
          <date month="August" year="2006"/>
          <abstract>
            <t>Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks.  Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t>
            <t>This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space.  This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.  This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4655"/>
        <seriesInfo name="DOI" value="10.17487/RFC4655"/>
      </reference>
      <reference anchor="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization/>
          </author>
          <date month="August" year="2018"/>
          <abstract>
            <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="RFC7285">
        <front>
          <title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
          <author fullname="R. Alimi" initials="R." role="editor" surname="Alimi">
            <organization/>
          </author>
          <author fullname="R. Penno" initials="R." role="editor" surname="Penno">
            <organization/>
          </author>
          <author fullname="Y. Yang" initials="Y." role="editor" surname="Yang">
            <organization/>
          </author>
          <author fullname="S. Kiesel" initials="S." surname="Kiesel">
            <organization/>
          </author>
          <author fullname="S. Previdi" initials="S." surname="Previdi">
            <organization/>
          </author>
          <author fullname="W. Roome" initials="W." surname="Roome">
            <organization/>
          </author>
          <author fullname="S. Shalunov" initials="S." surname="Shalunov">
            <organization/>
          </author>
          <author fullname="R. Woundy" initials="R." surname="Woundy">
            <organization/>
          </author>
          <date month="September" year="2014"/>
          <abstract>
            <t>Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks.  For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients.  What is missing is knowledge of the underlying network topologies from the point of view of ISPs.  In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.</t>
            <t>The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance.  The basic information of ALTO is based on abstract maps of a network.  These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them.  Additional services are built on top of the maps.</t>
            <t>This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services.  Applications that could use the ALTO services are those that have a choice to which end points to connect.  Examples of such applications are peer-to-peer (P2P) and content delivery networks.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7285"/>
        <seriesInfo name="DOI" value="10.17487/RFC7285"/>
      </reference>
      <reference anchor="RFC7624">
        <front>
          <title>Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes">
            <organization/>
          </author>
          <author fullname="B. Schneier" initials="B." surname="Schneier">
            <organization/>
          </author>
          <author fullname="C. Jennings" initials="C." surname="Jennings">
            <organization/>
          </author>
          <author fullname="T. Hardie" initials="T." surname="Hardie">
            <organization/>
          </author>
          <author fullname="B. Trammell" initials="B." surname="Trammell">
            <organization/>
          </author>
          <author fullname="C. Huitema" initials="C." surname="Huitema">
            <organization/>
          </author>
          <author fullname="D. Borkmann" initials="D." surname="Borkmann">
            <organization/>
          </author>
          <date month="August" year="2015"/>
          <abstract>
            <t>Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered.  In this document, we develop a threat model that describes these attacks on Internet confidentiality.  We assume an attacker that is interested in undetected, indiscriminate eavesdropping.  The threat model is based on published, verified attacks.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7624"/>
        <seriesInfo name="DOI" value="10.17487/RFC7624"/>
      </reference>
      <reference anchor="RFC8546">
        <front>
          <title>The Wire Image of a Network Protocol</title>
          <author fullname="B. Trammell" initials="B." surname="Trammell">
            <organization/>
          </author>
          <author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind">
            <organization/>
          </author>
          <date month="April" year="2019"/>
          <abstract>
            <t>This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol.  This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8546"/>
        <seriesInfo name="DOI" value="10.17487/RFC8546"/>
      </reference>
      <reference anchor="RFC8558">
        <front>
          <title>Transport Protocol Path Signals</title>
          <author fullname="T. Hardie" initials="T." role="editor" surname="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="RFC8170">
        <front>
          <title>Planning for Protocol Adoption and Subsequent Transitions</title>
          <author fullname="D. Thaler" initials="D." role="editor" surname="Thaler">
            <organization/>
          </author>
          <date month="May" year="2017"/>
          <abstract>
            <t>Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol.  Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult.  This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8170"/>
        <seriesInfo name="DOI" value="10.17487/RFC8170"/>
      </reference>
    </references>

  </back>
  <!-- ##markdown-source:
H4sIALUe8GEAA71c2ZIbR3Z9z6/IaD2oGQH0ULSkoVsPcpOiKM6IEq1mmGE7
HI5EVQLIYaEKqqVBaEL/7nOXXApAa+bJD5rpJlC53OXcc5fq5XJpxjA2/ta+
nPret6P9ee9b+++TH8bQtYMNrX3nxq29O7je25/8eOj6j6HdGLda9f7h1r67
+8n+Gr9u6q5q3Q7L1b1bj8vQj+vl3rX9Zpm+s/zimand6G9Nhf/ddP3xFrus
O2PCvr+1Yz8N47OnT//16TNDe236btrfXj6E/eW1+eiP+K2+tW/a0fetH5ff
0dbGDKNr6/91TdfiOEc/mH24tf89dtXCDl0/9n494Kfjjn74H2PcNG67/tZY
u8R/Fkcabu2LG/u+d7udbxr+R7nbiz64dv5B129u7euu2zTe3h/C+JvvG2xv
X+9WP/AX/M6FBhf14/rfRn3yptryZwMO40c8j5u7h+XrqWmW7xo3/ma/4M+r
MEJGz58+/dL+19QHfarqpnYk4RX7GdN2/c6N4QHiNSTV/NtyubRuhb1cBem8
abEAnnfDaMfOjltv970fyAKiIK3rq20YfTVOvV9YZ/fQwdKxDoJ+J1lD8VW7
dYPFJzbs9hC0w5L7vtv7fgweMg2j9Z/23eAH3TV+ZLu1cQ8Qk1tBiukUtOtA
Z/Rtve+wMdRGosWDD6HGY7hk/ow+Mm6/bwKsiy0YT06Dp72G2W7498E3OHLc
YQtL22z5UGlzrG3wD6GHXbr1OlQ39sM2NLRcGOJqR5zcXtEqlqXT+mG4sq7p
vauPuGwYRnaknWuPJpkpxN9id19bleNgocgtvjdAotii7mAzLd/IPgRnXb0L
bSAFkkYNq2DtKrkKnVrXsY07+p4UtoYlHR9TG2kBSw8iGYPjVH5PAqz6bhhk
Edlc/6UUzI0x70kC8PdpR0YjCv21xI1i32wptiN8caRs++zpsy8WWNaNZgfT
tyuP7YaD7yETPE/7Qb9h0y7w/w++6fa0lWi/9vumO/LWWClvZcorDjf2zWgP
tFsfNqF1JI5DH8YRZ4DQ1nBE7BGGahqGeGzaNqONKdCG1I1r1vYXCIws3r4m
cLLXwMBfXj+Rg5HxrzzW30+rJgxbfJ0srXX7YduNplKYJUXzorwjJDnsocob
cdNdqOvGG/MZybvv6qkiodI6dLDlGQz+/bNA3/ud3ZrOH3d5xJXPjCU7k7Nm
BR0u/RqmP8JD+odQ+Whh2c2mgQ8PbZDRdtNoH3wf1sGtQhPEI/CAmXm3+DuJ
doXNSUZjW6yZXQsWYAuzkTMaHH/bdk23Ye+F1VgHRe72ZDj4oV/i39plefra
N/CU/ig3njmMETygXTZw2J5NY+5hbKV70XgBP0tBr9pe+5vNjZiKednt9tPI
iGNfNZ7t8vrdy1dP7N///u0v37/88uuvvvr9dzaQ+249kgKX3/l1aLHOBwje
3gEsokqtub7/bvnh7qcnFkjWd67CWdW8cOwjnxqrQICA7BERYVQrY+AwJ9dQ
HIEvqKmd4HprC7y0Ff0+DPBqlbGBYX6ECZGeYR4bLNmSX47wJ37C1TWOQejV
NBZ+2o4TSxPuDC3gqjWfjn4QZy8eXtgVTAcWAw5ifTOQB9wR1rYDxY5snYjb
XWOHCU4Htbx/+Y4PqmYLMTTZ8qBxvuclQxYhuryiW+H7l9BTtzLv01l+5LPc
ezgX7XP9/sf7qN7nX375NdTLsgOPgAhInLJu73fd6E00nxv7Q3eAlLCFXHth
wxqngpHCsKAGxMcUuEm6K3Ku6DmG1Jdi5KlX6u3ao2hwL1C8c5BQXMZJuDNi
PnVn2260266pb6x9zy4xdDs/hh28ZOsgGggudNNAwRzEAR4hCFOYzMK4BJyV
wwpsKS9ev7Pb8DfYDgEFPBU/DdDui2MiHgt66o9oxYmlZvSBoI0GbwR/iKuZ
fFv5JKbr4cksnkfdTuS3qyOLiA05GjdWWTfd4YZkkL7N/jY3xSEpqTkqjSm1
ZebaomWFXDyuM9mlOxXqYPqpbTlgsmR3xFpFfwwBZGo791GJiMgCj8kF7gp/
ZqslKyb2AnYP1Ybf5KPrux/f//wk+4LY8p+fPf9KbXlF6pdwjd/8J7fbA14A
5KXSiO0knCIzEfjTGB7FtxRPhnp30YbMGeHMfk7WAmNhcE2Xy1EqecpDGIL6
PcmRLQvP44hRieDWbmQ8BujPiCE9AIPoU2jSR0iGpUztBZ8rV1rkW7ID/gla
n0dXwgOOgdCeJyllMKAbmnhsUS5bIp9umFb8c0PsBw/RAYaCF8k9D3l/EyWo
AZKUSA/3buPtbmrGwGap1DM8sNyE3YEF/Y2ONGfDpiR9C0Z3AVgXWep+exwg
iCaHVyDJB0CgjXHyRO4L8gqJp0sRf/RUrHkcENHpfOuwmXox07TwQqArSauB
bEQcw95XIB9q8pAKvkPxjx1MESvei4Ss3gBGNjW1wa+40oD114wmlDkK56GD
IM1CsgFApVg6TP2DR5zjLyjmRV1XHeii+tDXz778/XcY8AdPAOuj4/5/5QwU
62vv6wWUDnOL1ItSPwRBU7iHb8GLPTAeSCOcDkAKrjo1Gn5iDP6XhAguMGDh
Rz6/4fNfLUQc+L4keBEkSXAbSsNU5iQHIBvbc4RArOYSHkMieqeZT757PEoA
oz5KhvgJQa2W4F9gkxo4i8auSJ+uJ2+MzBUwBN+hlbAGWTduPFA4poSIwc+w
hwVh4ZGGHs+TIAE0YtGR8JPsOeWZpUaZ8YvImDpBDbDF7jQN6sCf2GFgGk34
zf/zEfMbqIIIwywTWU89EewLuY9KnYAHUhmIVz2eC81TICEes62YBDD/Yd8m
h/TtMCnYggVyYQci/Owzy0w4SNgz31PQnHpJKPnLhYgXpc8UaeUVIWLVhxUF
B7UrQ5cjdR6zA5TZSAQERFMqEJDvV91uN7URR9RwwDVKKctd4yaW1JLSs/Mi
A1Po9doTdcKFRy6WSIyo3egEute+v7E/zXGCuSSxOYWEumNGtt9L6kosTewd
Kv4nkr5vVI5J0in9Txkp2XUgMzUqHJsFSCcBFIV9xAUCR5HOpWSj9DIqyCBJ
VoqT+RRfriAqseAwzvkRLOQVnzRxodk1qMxRmkSpqSuyyK5loD5sqW6WtDYz
DX68UNpMv5kGJJNRFmkipAEokHluhFqWh+dErcDCYdrT1QmXe79BPtQQPmmq
HGNYEdvVZoUTrcFjoMhBrqJsQMVR6slkMki5FAvnSkIbrzdzLTLXLEyAHnEd
LRLiwLWmqIyBg/9VWDYRwBrM3itbQOLGlG8QaiDnI5Riaq1hgxW/o9JLvTAH
TvGFyCSDTAFRl2P1ZbRd1h62X3tiTXfDHBYI5UjzraSaXI0qEBe2ueWkkH2K
oFUpdRg11x2y55niSIzLK8rhkhz2rh+jbvJadh16qqQeuhLowcdI1IsiiXvo
KreCEz1ueVsQvpTlQ7OD31Gy7GuoM6EuLtvZR8yeHIXNYZBUkEEEdIkMbOQq
q1gYvkfpd2hq/olxHwdxHAkfWXuwakbxd1M6yyB5nkYaErFy6UsREjadPcv0
8WZZfMQKtLRQhkHOelx5wAx4hmPkSJH5s9zEILlR6Iz3Oi9K9jDt0LMCSKPK
SAafw3c8n0nnO7taLGmXprdg16F8RgiGwAJVlcvIK+bBis9hfs4NI9nMXFzz
xhrnrkaznrj0nsQoZY+hpFKPtFBmgVzi8Z39j5mZ8pPvkpkS7YkWH296y8en
tTXhZdI8t+6EJvis92oKvv6Wy5aiXyHgp9WP1AJY+SKr4JxULU/EoRiXYT6a
C8V35R3l8gwA0CE4NURMlyWB8inZQHc7pPSFx65TPp9Sltaec4PToieBET/G
2bnJaKnkptihooQES1bNRPQL2XIQ9Iv0ZI94ps+KD5iTHaOQVRbYOj+VowBl
pKorzsfIIpFtyuXS2jdaEiqW37mjAGLD8Z6CGpU9q1QwKzJ7DRVaMmw73Ahb
xZLyemrV+3N+9g0tcPCMVsUepj62bneySSIuD66ZRNQ7T8XQIX2rEfpWg1sg
NlSJsBcCZ95K3Czao9hd7EdEaVawbO6msEPTAxqlDYcIrpSdVMgKoXGlmOt7
hGYkDfwfLoO0WauW+EXrik9MIbN/kujfWCLNWp9Z5Dya7V2bbYbkv5RKQulh
0SLGbi+GFk2bCxUxTTywXe7cJ6oeeXO5QBlA0h5CPbnmxFJTPeyU3OGsI5cY
cEhkB2wvcFjpi9B9XZMLOfGAIOgU3LjGzPkG7EI4B4zTrJjuUeKOD8achqwo
uyUg3XSu4VOVF/x80NjXgYl/LynSDvn8ouxgsEEK9Pzjq5KjCC1EqsXMCYTK
CI8+AjZD9ZFr5BUReUiw5hCfi8NusyGOKGnpWZ/08v4cDgDHDSfXy7Fb+jk4
XHB/4J+hGjA85yG4RhOySCgX9CM+Wk1KtrHee+rQQ2gUWJS/XgwQsOgOX59H
iLo7KX3OSnIbCuIVgTHje1VRDQhKAH7D+zTmpe2PpxEGkeRnQp35Dom6sJfC
ObaOUusTXI/OqRyh0Pu8X8bIIJVx0hwgZ9sJ2tZJUqyyiPpm3nOeJzcIv2Ue
QBIq73ScuSpx07gH5RDzOrJyGFxQz0QSLJoR5sSKlkuJdhJkUuoJ4qnNUjL1
dd/tJKbhKUrstPzJh8xPcFLRU7yF/bzcdoGabPh2XRiPaDsfiGGWT6qtowsg
agqIzGFJEXGOgO+A9YEyojogus66uVJoId5bHifuHYNtaJcrbrUDW6hMMY3L
bs3/tMD9hm38AClwY9LPXO5YInRK9UFMdOisluK1kUltyq6nIimyDa08zYzj
WDB9lpWEQcQMTgulcU0PaSS0pXnCaKX3YXbeDZCGtMVh05x4pqLo+bMxnEf8
iQks9X/MKVua18EvQDmFUkJtqYcMuct7cjLu38+uWwNZj3wY/2kbVkEoH/d6
qbS88rCNoDRlapup+ni0avYhsgeqZ2Hz1EgHjN1Lvk3+yAh1HzNjASgAWH+K
T1VBKoeTAZEu1Yli5s/9qwOiTqq2c6YLiMiyTNTwgrhOmz5agqXMCVh2l5Dw
DzBPahwwj61r1jECIfAguaLYE1qD6zk2U6YNj3vQq3TtNI2hDQ+ZnwH8zKyh
yMlmciIBpWJGlBTDBPhVzcl7jMpmbgbnGfECVxE04S6mTpUURZkSQQwCe6co
3yqSRDaGc9S+W6+TUZbIwjnsjJwx2JhHRfUz8PIjdeH4cJb9PGSDj1BC1ZgC
R8r21PwaEApiMNUosMqmdy3FJcW8+TfN9WHr+Zt7+o9LLAv+mTpFzOXpFzy+
oS6Nkgj/JFIkFRElpfwdMxdTlMp4/NOJQKIAdeKh0MBEndwmfNSocCl0LZJf
iBErkY8BhNLWqRmLpCYvT/XT7JJcY0b0BrUj47yxb0HSOiFM7fHcOIiBhWFn
pNNjXdhxeUjHBrAw1MMMTMBu4HY4zsgGj4/FH3OzS/OleD4lC1y1hNbqbnfe
tFSIjXkr4ZU0QS/VpMvOMVPqmnuHR0oK5nmj1wxNJ34amoXpuf8eR/XizrLG
OlDmPbKYEAqlGdj4WHaVYRatUMcqbnoS4p13NLUws7DbsIExSnfX5O/T+WlY
soiHT/IAipyScqoENSPS9FZ0w2kYJLxzTBQo9An/mwUjJiLEsTRfqAE4ZTVF
zF2HAUzEUIkLb/IkEIFVLoyQpWt1o6Mk4EJwKKaI3K5Tcp4xftYJNhfq21oD
5se0LDGv9JyWQ06HGbmg4bmlQAV3XWOG648MZkoIiiBUXCSVYk5i1nwCwugN
WGWMIzoAcRqRzqcZJFCqFhEvRTrJDeMnWnBTl2LpihpPlyNFiIdpB30OR2RQ
+8gHV47cjvyaw2TKzv0aqN1WWnVFbgmulJxwpjkdPiQvoGklcsXUu1aiBgCH
QBbZfzNgX5QzcfPTWQSf5hFSO5BjqxpM9FjDOTwftIgUhISklmLRz2NKIKiR
2rdjGBgMUhCOSF9E4GLmIgqmBK7LoDVwkMEJOTOa3Y+giC9E5ZR+uaHWPKUw
WGUZRxLIKmPFKQvNXBQGGK/cC+ywmA29MBo6Hz0ozY76kZIx+LWDcCnRg1oe
ulAD1tpamuIjT/+6uttrS4XwY1dcLaa/CUBSlv1+1us6G8pJddT1GdBouDqd
nuH2AAPuyWAcUQ+DsMg1KZGUJKtkEwkrmmOc3bhcBec1v310iFSsG+5EXfw0
X6YtzjHVrCh3oIZDao8xiOmHPM7CGu195YOO3g3Uij4f2FH04dkMk74XwyPZ
9oNrvBaaB52IpFk2mXWc9QgiQhuZgMzHx29U6LHITwIEhDSjkUoM6ebgKSxx
51FrtflJQywqlJYQ9Z4beFk/MmcYOcpc9iL4G2l9pyoeNS5d/YAgSMM7VBgr
5nfKNnWIbWYdoShKPyxudfyrYd9jn5qmTAhZEwMQ6ZV0Po69GB2wHeQfuV8j
bWscFMzb8c9cI5BYvOaJnLWQ0AdH5NHMRmZS93E2J5OrXmxh8KJ1KOrjabiM
ZhBg5VNFPEpwB3gQ6UchbQqKTWg/cgKTWQmXFYQz03QoiUGnPpJ1yexVHIla
c4wYY/X+ZRMYSgnNdmEMxKyN7COJBMIn4YSsSSGn9xQnbNV414/+05hGr7qS
XQ3FuOmP9wAmAeM330m7LfCBySLwESW6Y9lPwLXhB9WRhoOGimY1DXfj/UZq
lhwCpEKVWYM+czaAWcwOeI6XJsVRCLwke4W001Quzr6nahKuqZKigZoVFY4o
bb+gEMHTD0q+YagxCf1Wa4jh0xk4Ugow741dl7FpXtwvwu+TQqEHGlDj0KC9
ShlJ4h6oDADlVF2P8hDKCHmOntThqyapEIMbrV3PVI1vVaBGGsEtg2jsM5ft
3tkrL6R7TeDKGVE6QpwTvZZCHhW3ObITlUACKH0farqwnZV0PHqdmUfTFD3J
zGNVURHmAnhd0dzbFZ1+0mk/FrkaOrTV8JgJ5NYgFYXNpYmG4i2NNvaqHPfL
pS1H3IRc7MDjWFykPuGBRTmFDxiDyqW+OinDzMlNhOw8EigeNaNsTBaUGVN2
LgdiLIp9Qwoc2bY4cRQ8/MNIm8dZqaEARPpHszG5ZvR4jbiQGZOmfPeyeKcz
8t2MabG+mdezJep1xEN/ToMB7kIfOdb7afb/Us50KRJn6LkwZkBdnBlt4e2J
MAqNyDnMfoJzcARKOUseSEIevzhh8kyQoigT41YXj0voGAQT167mhtk/nrCa
TZJk8sMRke6nZ25yllWkrGUGwpWu1TGexsTGlAwTKFmXSgLLTJN1Lb/2Tn+P
uXzCaXIz49IlxfrSrEdm/OdvFWxzeJ5ToLazFERhTEy75IC5jMj4QdWlOKxS
uOTqaFMRxbiGm305rtH7NH6USZZzVRdOdTJHL/OGvGZ8cA/88XwWBGFGVeZ7
ZOCE13kauByFpfJF12IJXJsg1OibLDwpU9TklYWkU3xejNFAY58TamnUoO9d
0SspV1LiIuhRxqwHqAPvhoBK0zk0zkw9Q4Gk2m96zzQwHVwK5jIVZTmyUDJB
7zxJ4bCEBXkHpBxiP1G6azYd8sjtbkgt2dykehXH7U8eYt8mwJBy75GKnSud
l87pIL8KkqxbR+KyDafAHVp5NkIxTa/pW4lp8uIEQwpHnaWJXANm0hULxCaS
cxr2baaoFICDY5e+hiYpwsBaJ9c8SQ1kPRnNWc76Ged94zk4P1bAlDcS6aws
OJ751bLH4NZ+pPCIcEzEXF96pbZJnFxBmHapRZlcg0dD6fBk4IabeumL5aj/
N5xTMFs73UsHTyhNkHY8AJSKIzyMwAsPIz89f33vUFKUzQRqCknpKwqzwUnY
1GNrcBTKxnalE8HEQv443niw0YvhRmYRaDwRDjWUL4Mkx4zwL1UcCjeuSalz
nMAaz1jf2dzxIo3s6cblpDhjVYwZ1zzbuOxWDXQBkn71JHrhOT1YEV614G71
nHvm+lGItyxeD9WJMj9cPiofR5rAXEknqhz8IUJTyrpcVfWTvLN1GgfYtDSC
UhE5E5Yi0T3t6RcTPTmylC/eQP+zF0Rm6SBN68jl84yeXDdV9E7PSUU6aQUV
w28lJy1fn+iI5pwMPJY+oy+lSvkhNrVigzMlV0767lKDV4FqFYDDcnwpKrW5
XB73FWvLn5Qnmb8QFXmxAJtOsx5tfgljzke0zCL8/dwDoIwNF5D3MsmQm1P6
xnuW0YPvy2xkWfcXWBjw+oc41Rt9cgax2jMXhL0IsGDSZL5uA/5yayodObgA
9rPCJtPW/Z5kQkEFXu8aqdRygwFnosGbquK0MxUsH+H40V0je9LBd/gizxkX
ZGpWrImjQde8rQ5HJw+/ABsEFQci/3sa788Dip7fbT2QysKOCj/6gulX/IJp
IY1d1wbokR0bJ/nuu+6exu6IgnPUYYEMl2eh5hVS4Hx/3HPGGf2Ziw0NDVNV
booVfjJnmCq9b65n+uo5zpReeJdaGL++emGXPdD/EmDAbO7DDrykp+G6ArZ5
pKZIRqmuPxDS0n8coOgo58ZhZsYhJjCmqTZ6Xe40QOcZqZMxDJMaiMONAPHJ
+R6JK9hfytHQRk3/GnkJA3vtDXvwYsZ+HBNVafanCKKC/uLPT/nl8fnfb0Cm
XYSPJACpHJYdHFi59rkphaf6rM4u645lzMrNHerIyZw5fIf+1khu1+ogyTAP
i6aINZ7Umd50Kta/5srLGlqYM3fJk8Ry0vtuNtte1NaT2NW8mG+TE/Zxlbwr
Uck0/S4FzDhuqWlTyZSjs0uGmqSts5T6LodBnhWwm1aPLw9EZpJYGLIOAuQX
HKUrEb0HYktLn6+a+uDzVyTFhGNHy0Rjn4tuUSiXCI+0cPm9gs/sXfWx7Q5I
TjfsN8a8pdBCopVX6+5q/qM373zfB8DXX7xrl+8CfvP2fheoK/429H9z9q+T
3zb+EGhq6meiOr43L7rW8Z8FoBbkW56Eh/11u4HOdL89gKE7+wJb0RtDC/ty
izBgP3QdlvgROc8P/KcD8GS3dTvQ5RfdVLnaBTgQVulBXOxf+8lviDC87vr+
aL/Hh9upp7mE+z1JBPjoDjBM4NovnupMr9rNFouOC/Ojm9iKXgakR5smODwz
+j1Z6fcO12t07PCXUNET9j8dwbfO+8UJfiK3tZZ9z1/0yy+vxSH1NfBghYge
u5HpJQIQMN+s45yy1EnknRPJN9MbRLGG8Goi5IJmkDHvgtSNJ+pdQWx9+A2/
PXv67KmhTiFUTzkk79N2N/br58+/fPaFfXsymXVXcgjp3bzlv0ey6j5B+sk3
r9/evX2jf5VCD3N/wAkgPkrk7ykHGaFQJ9nbK9BUNff4yoEY/pu27R7EjOXg
8ucBKjnkF1/dPH329fP4Tra2/1LGQ17DpVoa2dhxuer/AMaY1nTUSgAA

-->

</rfc>