<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version="1.0" encoding="UTF-8"?>

<!-- draft submitted in xml v3 -->

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>

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

<!-- xml2rfc v2v3 conversion 2.45.2 -->

  <front>
    <title abbrev="What Not To to Do">Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)</title> (A&nbsp;Bestiary&nbsp;of&nbsp;Roads&nbsp;Not&nbsp;Taken)</title>
    <seriesInfo name="Internet-Draft" value="draft-irtf-panrg-what-not-to-do-19"/> name="RFC" value="9049"/>
    <author initials="S." surname="Dawkins" fullname="Spencer Dawkins" role="editor">
      <organization>Tencent America</organization>
      <address>
       <postal>
        <country>United States of America</country>
       </postal>
        <email>spencerdawkins.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="April" day="15"/> month="June"/>
    <area>IRTF</area>
    <workgroup>PANRG</workgroup>
    <workgroup>Path Aware Networking</workgroup>
    <keyword>PAN</keyword>
    <abstract>
      <t>At the first meeting
      <t>This document is a product of the Path Aware Networking Research Group, Group (PANRG).  At the research group 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 Path Aware networking researchers.</t>
      <t>This document contains that catalog and analysis.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">

      <name>Introduction</name>
      <t>This document describes the lessons that IETF participants have learned (and learned the hard way) about Path Aware Networking networking over a period of several decades, and decades. It also provides an analysis of reasons why various Path Aware Networking techniques have seen limited or no deployment.</t>
<t>This document represents the consensus of the Path Aware Networking Research Group (PANRG).</t>
      <section anchor="PANdef" numbered="true" toc="default">
        <name>What Do "Path" and "Path Awareness" Mean in this This Document?</name>
        <t>One of the first questions reviewers of this document have asked is "what's "What's the definition of a path, Path, and what's the definition of path awareness?" Path Awareness?" That is not an easy question to answer for this document.</t>
        <t>These terms have definitions in other PANRG documents <xref target="PANRG" format="default"/> documents, and are still the subject of some discussion in the research group, Research Group, as of the date of this document. But because this document reflects work performed over several decades, the technologies described in <xref target="Contributions" format="default"/> significantly predate the current definitions of "path" "Path" and "path aware" "Path Aware" in use in the Path Aware Networking Research Group, and it is unlikely that all the contributors to <xref target="Contributions" format="default"/> would have had the same understanding of these terms. Those technologies were considered "path aware" "Path Aware" in early PANRG discussions, discussions and so are included in this retrospective document.</t>
        <t>It is worth noting that the definitions of "path" "Path" and "path aware" "Path Aware" in <xref target="I-D.irtf-panrg-path-properties" format="default"/> would apply to path aware networking Path Aware techniques at a number of levels of the Internet protocol architecture (<xref target="RFC1122" format="default"/>, plus several decades of refinements), but the contributions received for this document tended to target the Transport Layer, transport layer and to treat a "path" "Path" constructed by routers as a "black box". opaque. It would be useful to consider how applicable the Lessons Learned cataloged in this document are, at other layers, and that would be a fine topic for follow-on research.</t>
        <t>The current definition of "Path" in the Path Aware Networking Research Group appears in Section 2 ("Terminology") in <xref target="I-D.irtf-panrg-path-properties" format="default"/>. That definition is included here as a convenience to the reader.</t>
<!-- DNE -->
        <blockquote>
   Path:  A sequence of adjacent path elements over which a packet can
      be transmitted, starting and ending with a node.  A path is
      unidirectional.  Paths are time-dependent, i.e., the sequence of
      path elements over which packets are sent from one node to another
      may change.  A path is defined between two nodes.  For multicast
      or broadcast, a packet may be sent by one node and received by
      multiple nodes.  In this case, the packet is sent over multiple
      paths at once, one path for each combination of sending and
      receiving node; these paths do not have to be disjoint.  Note that
      an entity may have only partial visibility of the path elements
      that comprise a path and visibility may change over time.
      Different entities may have different visibility of a path and/or
      treat path elements at different levels of abstraction.

</blockquote>
        <t>The current definition of "Path Awareness", Path Awareness, used by the Path Aware Networking Research Group, appears in Section 1.1 ("Definition") in <xref target="I-D.irtf-panrg-questions" format="default"/>.
That definition is included here as a convenience to the reader.</t>

<!-- DNE; fixed.  Updates reviewed and OKed by author -->
        <blockquote>
   For
   <t>For purposes of this document, "path aware networking" describes
   endpoint discovery of the properties of paths they use for
   communication,
   communication across an internetwork, and endpoint reaction to these
   properties that affects routing and/or transmission; note data transfer.  Note that this
   can and already does happen to some extent in the current Internet architecture.
   Expanding
   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 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, regardless of the specific design of the protocol features
   which enable this discovery and selection. selection.</t>
</blockquote>
      </section>
    </section>
    <section anchor="perspective" numbered="true" toc="default">
      <name>A Perspective On on This Document</name>
      <t>At the first meeting of the Path Aware Networking Research Group <xref target="PANRG" format="default"/>, at IETF 99 <xref target="PANRG-99" format="default"/>, Olivier Bonaventure led a discussion of "A Decade of Path Awareness" <xref target="PATH-Decade" format="default"/>, on attempts, which were mostly unsuccessful for a variety of reasons, to exploit Path Aware techniques and achieve a variety of goals over the past decade. At the end of that discussion, two things were abundantly clear.</t>
      <ul spacing="normal">
        <li>The Internet community has accumulated considerable experience with many Path Aware techniques over a long period of time, and</li>
        <li>Although some path aware Path Aware techniques have been deployed (for example, Differentiated Services, or DiffServ Diffserv <xref target="RFC2475" format="default"/>), most of these techniques haven't seen widespread adoption and deplyment. deployment. Even "successful" techniques like DiffServ Diffserv can face obstacles that prevents prevent wider usage. The reasons for non-adoption and limited adoption and deployment are many, many and are worthy of study.</li>
      </ul>
      <t>The meta-lessons from that experience were</t> were as follows:</t>
      <ul spacing="normal">
        <li>Path aware Aware networking has been more Research than Engineering, so establishing an IRTF Research Group for Path Aware Networking is networking was the right thing to do <xref target="RFC7418" format="default"/>.</li> format="default"/>.
</li>
        <li>Analyzing a catalog of past experience to learn the reasons for non-adoption would be a great first step for the Research Group.</li>
      </ul>
      <t>Allison Mankin, as IRTF Chair, officially chartered the Path Aware Networking Research Group in July, July 2018.</t>
      <t>This document contains the analysis performed by that research group Research Group (<xref target="LessonsLearned" format="default"/>), based on that catalog (<xref target="Contributions" format="default"/>).</t>
      <t>This document represents the consensus of the Path Aware Networking Research Group.</t>
      <section anchor="notes-for-the-reader" numbered="true" toc="default">
        <name>Notes for the Reader</name>
        <t>This Informational document discusses Path Aware protocol mechanisms considered, and in some cases standardized, by the Internet Engineering Task Force (IETF), and it considers Lessons Learned from those mechanisms. The intention is to inform the work of protocol designers, whether in the IRTF, the IETF, or elsewhere in the Internet ecosystem.</t>
        <t>As an Informational document published in the IRTF stream, Stream, this document has no authority beyond the quality of the analysis it contains.</t>
      </section>
      <section anchor="a-note-about-path-aware-techniques-included-in-this-document" numbered="true" toc="default">
        <name>A Note About Path-Aware about Path Aware Techniques Included In in This Document</name>
        <t>This document does not catalog every proposed path aware networking Path Aware technique that was not adopted and deployed. Instead, we limited our focus to technologies that passed through the IETF community, community and still identified enough techniques to provide background for the lessons included in <xref target="LessonsLearned" format="default"/> to inform researchers and protocol engineers in their work.</t>
        <t>No shame is intended for the techniques included in this document. As shown in <xref target="LessonsLearned" format="default"/>, the quality of specific techniques had little to do with whether they were deployed or not. Based on the techniques cataloged in this document, it is likely that when these techniques were put forward, the proponents were trying to engineer something that could not be engineered without first carrying out research. Actual shame would be failing to learn from experience, experience and failing to share that experience with other networking researchers and engineers.</t>
      </section>
      <section anchor="venue-for-discussion-of-this-document" numbered="true" toc="default">
        <name>Venue for Discussion of this Document</name>
        <t>(RFC Editor: please remove this section before publication)</t>
        <t>Discussion of specific contributed experiences and this document in general should take place on the PANRG mailing list.</t>
      </section>
      <section anchor="architectural-guidance" numbered="true" toc="default">
        <name>Architectural Guidance</name>
        <t>As background for understanding the Lessons Learned contained in this document, the reader is encouraged to become familiar with the Internet Architecture Board's documents on "What Makes for a Successful Protocol?" "<xref target="RFC5218" format="title"/>" <xref target="RFC5218" format="default"/>
and "Planning for Protocol Adoption and Subsequent Transitions" "<xref target="RFC8170" format="title"/>" <xref target="RFC8170" format="default"/>.</t>
        <t>Although these two documents do not specifically target path-aware Path Aware networking protocols, they are helpful resources for readers seeking to improve their understanding of considerations for successful adoption and deployment of any protocol. For example, the Basic Success Factors basic success factors described in Setion 2.1 of <xref target="RFC5218" format="default"/> sectionFormat="of" section="2.1"/> are helpful for readers of this document.</t>
        <t>Because there is an economic aspect to decisions about deployment, the IAB Workshop on Internet Technology Adoption and Transition <xref target="ITAT" format="default"/> report <xref target="RFC7305" format="default"/> also provides food for thought.</t>
        <t>Several of the Lessons Learned in <xref target="LessonsLearned" format="default"/> reflect considerations described in <xref target="RFC5218" format="default"/>, <xref target="RFC7305" format="default"/>, and <xref target="RFC8170" format="default"/>.</t>
      </section>
      <section anchor="terminology-used-in-this-document" numbered="true" toc="default">
        <name>Terminology Used in this This Document</name>
        <t>The terms Node "node" and Element "element" in this document have the meaning defined in <xref target="I-D.irtf-panrg-path-properties" format="default"/>.</t> format="default"/>.
</t>
      </section>
      <section anchor="TemplateContributions" numbered="true" toc="default">
        <name>Methodology for Contributions</name>
        <t>This document grew out of contributions by various IETF participants with experience with one or more Path Aware Networking techniques.</t>
        <t>There are many things that could be said about the Path Aware networking techniques that have been developed. For the purposes of this document, contributors were requested to provide</t>
        <ul spacing="normal">
          <li>the name of a technique, including an abbreviation if one was used</li> used.</li>
          <li>if available, a long-term pointer to the best reference describing the technique</li> technique.</li>
          <li>a short description of the problem the technique was intended to solve</li> solve.</li>
          <li>a short description of the reasons why the technique wasn't adopted</li> adopted.</li>
          <li>a short statement of the lessons that researchers can learn from our experience with this technique.</li>
        </ul>
      </section>
    </section>

    <section anchor="applying" numbered="true" toc="default">
      <name>Applying the Lessons We've Learned</name>
      <t>The initial scope for this document was roughly "what "What mistakes have we made in the decade prior to <xref target="PANRG-99" format="default"/>, that we shouldn't make again". again?" Some of the contributions in <xref target="Contributions" format="default"/> predate the initial scope. The earliest Path-Aware Networking Path Aware technique referred to in <xref target="Contributions" format="default"/> is <xref target="ST2" format="default"/>, target="IEN-119"/>, which was published in the late 1970s. 1970s; see <xref target="ST2" format="default"/>. Given that the networking ecosystem has evolved continuously, it seems reasonable to consider how to apply these lessons.</t>
      <t>The PANRG Research Group reviewed the Lessons Learned (<xref target="LessonsLearned" format="default"/>) contained in the May 23, 2019 draft version of this document at IETF 105 <xref target="PANRG-105-Min" format="default"/>, format="default"/> and carried out additional discussion at IETF 106 <xref target="PANRG-106-Min" format="default"/>. <xref target="thefuture" format="default"/> provides the "sense of the room" about each lesson after those discussions. The intention was to capture whether a specific lesson seems to be</t>
      <ul spacing="normal">
        <li>"Invariant" - well-understood and is likely to be applicable for any proposed Path Aware Networking networking solution.</li>
        <li>"Variable" - has impeded deployment in the past, past but might not be applicable in a specific technique. Engineering analysis to understand whether the lesson is applicable is prudent.</li>
        <li>"Not Now" - this a characteristic that tends to turn up a minefield full of dragons, and prudent dragons. Prudent network engineers will wish to avoid gambling on a technique that relies on this, until something significant changes</li> changes.</li>
      </ul>

      <t><xref target="ecn" format="default"/> on ECN Explicit Congestion Notification (ECN) was added during the review and approval process, based on a question from Martin Duke. That section, along with its Lessons Learned and place in the "Invariant"/"Variable"/"Not Now" taxonomy, <xref target="ecn" format="default"/>, as contained in the March 8, 2021 draft version of this document, was discussed at <xref target="PANRG-110" format="default"/>.</t> format="default"/> and is summarized in <xref target="OneChance"/>, describing a new Lesson Learned.
</t>

      <table anchor="thefuture" align="center">
        <thead>
          <tr>
            <th align="left">Lesson</th>
            <th align="left">Category</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Justifying Deployment (<xref target="JustifyingDeployment" format="default"/>)</td>
            <td align="left">Invariant</td>
          </tr>
          <tr>
            <td align="left">Providing Benefits for Early Adopters (<xref target="EarlyAdopters" format="default"/>)</td>
            <td align="left">Invariant</td>
          </tr>
          <tr>
            <td align="left">Providing Benefits during Partial Deployment (<xref target="PartialDeployment" format="default"/>)</td>
            <td align="left">Invariant</td>
          </tr>
          <tr>
            <td align="left">Outperforming End-to-end End-to-End Protocol Mechanisms (<xref target="Outperforming" format="default"/>)</td>
            <td align="left">Variable</td>
          </tr>
          <tr>
            <td align="left">Paying for Path Aware Techniques (<xref target="Paying" format="default"/>)</td>
            <td align="left">Invariant</td>
          </tr>
          <tr>
            <td align="left">Impact on Operational Practices (<xref target="OperationalImpact" format="default"/>)</td>
            <td align="left">Invariant</td>
          </tr>
          <tr>
            <td align="left">Per-connection align="left">Per-Connection State (<xref target="Per-connectionState" format="default"/>)</td>
            <td align="left">Variable</td>
          </tr>
          <tr>
            <td align="left">Keeping Traffic on Fast-paths Fast Paths (<xref target="Fast-paths" format="default"/>)</td>
            <td align="left">Variable</td>
          </tr>
          <tr>
            <td align="left">Endpoints Trusting Intermediate Nodes (<xref target="EndpointsTrustingIDs" format="default"/>)</td>
            <td align="left">Not Now</td>
          </tr>
          <tr>
            <td align="left">Intermediate Nodes Trusting Endpoints (<xref target="IDsTrustingEndpoints" format="default"/>)</td>
            <td align="left">Not Now</td>
          </tr>
          <tr>
            <td align="left">Reacting to Distant Signals (<xref target="ReactionTimes" format="default"/>)</td>
            <td align="left">Variable</td>
          </tr>
          <tr>
            <td align="left">Support in Endpoint Protocol Stacks (<xref target="ProtocolStackSupport" format="default"/>)</td>
            <td align="left">Variable</td>
          </tr>
          <tr>
            <td align="left">Planning for Failure (<xref target="OneChance" format="default"/>)</td>
            <td align="left">Invariant</td>
          </tr>
        </tbody>
      </table>

      <t>"Justifying Deployment", "Providing Benefits for Early Adopters", "Paying for Path Aware Techniques", "Impact on Operational Practice", Practices", and "Planning for Failure" were considered to be invariant - Invariant -- the sense of the room was that these would always be considerations for any proposed Path Aware Technique.</t> technique.</t>
      <t>"Providing Benefits During during Partial Deployment" was added after IETF 105, during research group last call, Research Group Last Call, and is also considered to be invariant.</t> Invariant.</t>
      <t>For "Outperforming End-to-end End-to-End Protocol Mechanisms", there is a trade-off between improved performance from Path Aware Techniques techniques and additional complexity required by some Path Aware Techniques.</t> techniques.</t>
      <ul spacing="normal">
        <li>For example, if you can obtain the same understanding of path characteristics from measurements obtained over a few more round trips, endpoint implementers are unlikely to be eager to add complexity, and many attributes can be measured from an endpoint, without assistance from intermediate nodes.</li>
      </ul>
      <t>For "Per-connection "Per-Connection State", the key questions discussed in the research group Research Group were "how much state" and "where state is maintained".</t>
      <ul spacing="normal">
        <li>IntServ
        <li>Integrated Services (IntServ) (<xref target="IntServ" format="default"/>) required state at every participating intermediate node for every connection between two endpoints. As the Internet ecosystem has evolved, carrying many connections in a tunnel that appears to intermediate nodes as a single connection has become more common, so that additional end-to-end connections don't add additional state to intermediate nodes between tunnel endpoints. If these tunnels are encrypted, intermediate nodes between tunnel endpoints can't distinguish between connections, even if that were desirable.</li>
      </ul>
      <t>For "Keeping Traffic on Fast-paths", Fast Paths", we noted that this was true for many platforms, but not for all.</t>
      <ul spacing="normal">
        <li>For backbone routers, this is likely an invariant, Invariant, but for platforms that rely more on general-purpose computers to make forwarding decisions, this may not be a fatal flaw for Path Aware Networking techniques.</li>
      </ul>
      <t>For "Endpoints Trusting Intermediate Nodes" and "Intermediate Nodes Trusting Endpoints", these lessons point to the broader need to revisit the Internet Threat Model.</t>
      <ul spacing="normal">
        <li>We noted with relief that discussions about this were already underway in the IETF community at IETF 105 (see the Security Area Open Meeting minutes <xref target="SAAG-105-Min" format="default"/> for discussion of <xref target="I-D.arkko-arch-internet-threat-model" format="default"/> and <xref target="I-D.farrell-etm" format="default"/>), and the Internet Architecture Board has created a mailing list for continued discussions (<xref <xref target="model-t" format="default"/>), format="default"/>, but we recognize that there are Path Aware Networking networking aspects of this effort, requiring research.</li>
      </ul>
      <t>For "Reacting to Distant Signals", we noted that not all attributes are equal.</t>
      <ul spacing="normal">
        <li>If an attribute is stable over an extended period of time, is difficult to observe via end-to-end mechanisms, and is valuable, Path Aware Techniques techniques that rely on that attribute to provide a significant benefit become more attractive.</li>
        <li>Analysis to help identify attributes that are useful enough to justify deployment of Path Aware techniques that make use of those attributes would be helpful.</li>
      </ul>
      <t>For "Support in Endpoint Protocol Stacks", we noted that Path Aware applications must be able to identify and communicate requirements about path characteristics.</t>
      <ul spacing="normal">
        <li>The de-facto de facto sockets API has no way of signaling application expectations for the network path to the protocol stack.</li>
      </ul>
    </section>
    <section anchor="LessonsLearned" numbered="true" toc="default">
      <name>Summary of Lessons Learned</name>
      <t>This section summarizes the Lessons Learned from the contributed subsections in <xref target="Contributions" format="default"/>.</t>
      <t>Each Lesson Learned is tagged with one or more contributions that encountered this obstacle as a significant impediment to deployment. Other contributed techniques may have also encountered this obstacle, but this obstacle may not have been the biggest impediment to deployment for those techniques.</t>
      <t>It is useful to notice that sometimes an obstacle might impede deployment, while at other times, the same obstacle might prevent adoption and deployment entirely.
The research group Research Group discussed distinguishing between obstacles that impede and obstacles that prevent, but it appears that the boundary between "impede" and
"prevent" can shift over time - -- some of the Lessons Learned are based on both a) Path Aware techniques that were not deployed, deployed and b) Path Aware techniques that were deployed, deployed but were not deployed widely or quickly. See <xref Sections&nbsp;<xref target="Shim6" format="default"/> format="counter"/> and <xref target="Addendum-MP-TCP" format="default"/> as one example format="counter"/> for examples of this shifting boundary.</t>
      <section anchor="JustifyingDeployment" numbered="true" toc="default">
        <name>Justifying Deployment</name>
        <t>The benefit of Path Awareness must be great enough to justify making changes in an operational network. The colloquial U.S. American U.S.&nbsp;American English expression, "If it ain't broke, don't fix it" is a "best current practice" on today's Internet. (See <xref Sections&nbsp;<xref target="Quick-Start" format="default"/>, format="counter"/>, <xref target="Source-Quench" format="default"/>, format="counter"/>, <xref target="TRIGTRAN" format="default"/>, format="counter"/>, and <xref target="ecn" format="default"/>, format="counter"/>, in addition to <xref target="RFC5218" format="default"/>).</t> format="default"/>.)</t>
      </section>
      <section anchor="EarlyAdopters" numbered="true" toc="default">
        <name>Providing Benefits for Early Adopters</name>
        <t>Providing benefits for early adopters can be key - -- if everyone must deploy a technique in order for the technique to provide benefits, or even to work at all, the technique is unlikely to be adopted widely or quickly. (See <xref Sections&nbsp;<xref target="IntServ" format="default"/> format="counter"/> and <xref target="Quick-Start" format="default"/>, format="counter"/>, in addition to <xref target="RFC5218" format="default"/>).</t> format="default"/>.)</t>
      </section>
      <section anchor="PartialDeployment" numbered="true" toc="default">
        <name>Providing Benefits During during Partial Deployment</name>
        <t>Some proposals require that all path elements along the full length of the path must be upgraded to support a new technique, before any benefits can be seen. This is likely to require coordination between operators who control a subset of path elements, and between operators and end users if endpoint upgrades are required. If a technique provides benefits when only a part of the path has been upgraded, this is likely to encourage adoption and deployment. (See <xref Sections&nbsp;<xref target="IntServ" format="default"/>, format="counter"/>, <xref target="Quick-Start" format="default"/>, format="counter"/>, and <xref target="ecn" format="default"/>, format="counter"/>, in addition to <xref target="RFC5218" format="default"/>).</t> format="default"/>.)</t>
      </section>
      <section anchor="Outperforming" numbered="true" toc="default">
        <name>Outperforming End-to-end End-to-End Protocol Mechanisms</name>
        <t>Adaptive end-to-end protocol mechanisms may respond to feedback quickly enough that the additional realizable benefit from a new Path Aware mechanism that tries to manipulate nodes along a path, or observe the attributes of nodes along a path, may be much smaller than anticipated anticipated. (See <xref Sections&nbsp;<xref target="Quick-Start" format="default"/> format="counter"/> and <xref target="TRIGTRAN" format="default"/>).</t> format="counter"/>.)</t>
      </section>
      <section anchor="Paying" numbered="true" toc="default">
        <name>Paying for Path Aware Techniques</name>
        <t>"Follow the money." If operators can't charge for a Path Aware technique to recover the costs of deploying it, the benefits to the operator must be really significant. Corollary: If if operators charge for a Path Aware technique, the benefits to users of that Path Aware technique must be significant enough to justify the cost. (See <xref Sections&nbsp;<xref target="ST2" format="default"/>, format="counter"/>, <xref target="IntServ" format="default"/>, format="counter"/>, <xref target="TRIGTRAN" format="default"/>, format="counter"/>, and <xref target="ecn" format="default"/>).</t> format="counter"/>.)</t>
      </section>
      <section anchor="OperationalImpact" numbered="true" toc="default">
        <name>Impact on Operational Practices</name>
        <t>Impact
        <t>The impact of a Path Aware technique requiring changes to operational practices can affect how quickly or widely a promising technique is deployed. The impacts of these changes may make deployment more likely, but they often discourage deployment. (See <xref target="Shim6" format="default"/>, including <xref target="Addendum-MP-TCP" format="default"/>).</t> format="default"/>.)</t>
      </section>
      <section anchor="Per-connectionState" numbered="true" toc="default">
        <name>Per-connection
        <name>Per-Connection State</name>
        <t>Per-connection state in intermediate nodes has been an impediment to adoption and deployment in the past, because of added cost and complexity. Often, similar benefits can be achieved with much less finely-grained finely grained state. This is especially true as we move from the edge of the network, further into the routing core core. (See <xref Sections&nbsp;<xref target="ST2" format="default"/> format="counter"/> and <xref target="IntServ" format="default"/>).</t> format="counter"/>.)</t>
      </section>
      <section anchor="Fast-paths" numbered="true" toc="default">
        <name>Keeping Traffic on Fast-paths</name> Fast Paths</name>
        <t>Many modern platforms, especially high-end routers, have been designed with hardware that can make simple per-packet forwarding decisions ("fast-paths"), ("fast paths") but have not been designed to make heavy use of in-band mechanisms such as IPv4 and IPv6 Router Alert Options (RAO) (RAOs) that require more processing to make forwarding decisions. Packets carrying in-band mechanisms are diverted to other processors in the router with much lower packet processing packet-processing rates. Operators can be reluctant to deploy techniques that rely heavily on in-band mechanisms because they may significantly reduce packet throughput. (See <xref target="NSIS" format="default"/>).</t> format="default"/>.)</t>
      </section>
      <section anchor="EndpointsTrustingIDs" numbered="true" toc="default">
        <name>Endpoints Trusting Intermediate Nodes</name>
        <t>If intermediate nodes along the path can't be trusted, it's unlikely that endpoints will rely on signals from intermediate nodes to drive changes to endpoint behaviors. We note that "trust" is not binary - one, low, -- one low level of trust applies when a node issuing receiving a message can confirm that it the sender of the message has visibility of the packets on the path it is seeking to control <xref target="RFC8085" format="default"/> (e.g., an ICMP Destination Unreachable message included a quoted packet <xref target="RFC0792"/> that includes the Internet Header + 64 bits of Original Data Datagram payload from the source). A higher level of trust can arise when an endpoint has established a short term, short-term, or even long term, long-term, trust relationship with network nodes. (See <xref Sections&nbsp;<xref target="Source-Quench" format="default"/> format="counter"/> and <xref target="TRIGTRAN" format="default"/>).</t> format="counter"/>.)</t>
      </section>
      <section anchor="IDsTrustingEndpoints" numbered="true" toc="default">
        <name>Intermediate Nodes Trusting Endpoints</name>
        <t>If the endpoints do not have any trust relationship with the intermediate nodes along a path, operators have been reluctant to deploy techniques that rely on endpoints sending unauthenticated control signals to routers. (See <xref Sections&nbsp;<xref target="IntServ" format="default"/> format="counter"/> and <xref target="NSIS" format="default"/>). format="counter"/>.) (We also note that this still remains a factor hindering deployment of DiffServ).</t> Diffserv.)</t>
      </section>
      <section anchor="ReactionTimes" numbered="true" toc="default">
        <name>Reacting to Distant Signals</name>
        <t>Because the Internet is a distributed system, if the distance that information from distant path elements travels to a Path Aware host is sufficiently large, the information may no longer accurately represent the state and situation at the distant host or elements along the path when it is received locally. In this case, the benefit that a Path Aware technique provides will be inconsistent, inconsistent and may not always be beneficial. (See <xref target="Quick-Start" format="default"/>).</t> format="default"/>.)</t>
      </section>
      <section anchor="ProtocolStackSupport" numbered="true" toc="default">
        <name>Support in Endpoint Protocol Stacks</name>
        <t>Just because a protocol stack provides a new feature/signal does not mean that applications will use the feature/signal. Protocol stacks may not know how to effectively utilize Path-Aware Path Aware techniques, because the protocol stack may require information from applications to permit the technique to work effectively, but applications may not a-priori a&nbsp;priori know that information. Even if the application does know that information, the de-facto de facto sockets API has no way of signaling application expectations for the network path to the protocol stack. In order for applications to provide these expectations to protocol stacks, we need an API that signals more than the packets to be sent. (See <xref Sections&nbsp;<xref target="ST2" format="default"/> format="counter"/> and <xref target="IntServ" format="default"/>).</t> format="counter"/>.)</t>
      </section>
      <section anchor="OneChance" numbered="true" toc="default">
        <name>Planning For for Failure</name>
        <t>If early implementers discover severe problems with a new feature, that feature is likely to be disabled, and convincing implementers to re-enable that feature can be very difficult, difficult and can require years or decades. In addition to testing, partial deployment for a subset of users, implementing instrumentation that will detect degraded user experience, and even "failback" to a previous version or "failover" to an entirely different implementation are likely to be helpful. (See <xref target="ecn" format="default"/>).</t> format="default"/>.)</t>
      </section>
    </section>
    <section anchor="Futures" numbered="true" toc="default">
      <name>Future Work</name>
      <t>By its nature, this document has been retrospective. In addition to considering how the Lessons Learned to date apply to current and future Path Aware networking proposals, it's also worth considering whether there is deeper investigation left to do.</t>
      <ul spacing="normal">
        <li>We note that this work was based on contributions from experts on various Path Aware networking techniques, and all of the contributed techniques involved unicast protocols. We didn't consider how these lessons might apply to multicast, and, given anecdotal reports at the IETF 109 MOPS working group Media Operations (MOPS) Working Group meeting of IP multicast offerings within data centers at one or more cloud providers (<xref <xref target="MOPS-109-Min" format="default"/>), format="default"/>, it might be useful to think about path awareness Path Awareness in multicast, before we have a history of unsuccessful deployments to document.</li>
        <li>
          <t>The question of whether a mechanism supports admission control, based on either endpoints or applications, is associated with Path Awareness. One of the motivations of IntServ and a number of other architectures (e.g. (e.g., Deterministic Networking, Networking <xref target="RFC8655" format="default"/>) is the ability to "say no" to an application based on resource availability on a path, before the application tries to inject traffic onto that path and discovers the path does not have the capacity to sustain enough utility to meet the application's minimum needs. The question of whether admission control is needed comes up repeatedly, but we have learned a few useful lessons that, while covered implicitly in some of the lessons learned of the Lessons Learned provided in this document, might be explained explicitly:  </t> explicitly:</t>
          <ul spacing="normal">
            <li>We have gained a lot of experience with application-based adaptation since the days where applications just injected traffic in-elastically inelastically into the network. Such adaptations seem to work well enough that admission control is of less value to these applications</li> applications.</li>
            <li>There are end-to-end measurement techniques that can steer traffic at the application layer (Content Distribution Networks, Delivery Networks (CDNs), multi-CDNs like Conviva <xref target="Conviva" format="default"/>, etc.)</li> etc.).</li>
            <li>We noted in <xref target="ProtocolStackSupport" format="default"/> that applications often don't know how to utilize Path Aware techniques. This includes not knowing enough about their admission control threshold to be able to ask accurately for the resources they need, whether this is because the application itself doesn't know, know or because the application has no way to signal its expectations to the underlying protocol stack. To date, attempts to help them haven't gotten anywhere (e.g. (e.g., the multiple-TSPEC (Traffic Specification) additions to RSVP to attempt to mirror codec selection by applications <xref target="I-D.ietf-tsvwg-intserv-multiple-tspec" format="default"/> expired in 2013).</li>
          </ul>
        </li>
        <li>We note that this work took the then-current IP network architecture as given, at least at the time each technique was proposed. It might be useful to consider aspects of the now-current IP network architecture that ease, or impede, Path Aware networking techniques. For example, there is limited ability in IP to constrain bidirectional paths to be symmetric, and information-centric networking protocols such as Named Data Networking (NDN) and Content-Centric Networking (CCNx) (<xref <xref target="RFC8793" format="default"/>) format="default"/> must force bidirectional path symmetry using protocol-specific mechanisms.</li>
      </ul>
    </section>
    <section anchor="Contributions" numbered="true" toc="default">
      <name>Contributions</name>
      <t>Contributions on these Path Aware networking techniques were analyzed to arrive at the Lessons Learned captured in <xref target="LessonsLearned" format="default"/>.</t>
      <t>Our expectation is that most readers will not need to read through this section carefully, but we wanted to record these hard-fought lessons as a service to others who may revisit this document, so they'll have the details close at hand.</t>
      <section anchor="ST2" numbered="true" toc="default">
        <name>Stream Transport (ST, ST2, ST2+)</name>
        <t>The suggested references for Stream Transport are:</t>
        <ul spacing="normal">
          <li>ST - A Proposed Internet Stream Protocol
          <li>"<xref target="IEN-119" format="title"/>" <xref target="IEN-119" format="default"/></li>
          <li>Experimental Internet Stream Protocol, Version 2 (ST-II)
          <li>"<xref target="RFC1190" format="title"/>" <xref target="RFC1190" format="default"/></li>
          <li>Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
          <li>"<xref target="RFC1819" format="title"/>" <xref target="RFC1819" format="default"/></li>
        </ul>
        <t>The first version of Stream Transport, ST <xref target="IEN-119" format="default"/>, was published in the late 1970's 1970s and was implemented and deployed on the ARPANET at small scale. It was used throughout the 1980's 1980s for experimental transmission of voice, video, and distributed simulation.</t>
        <t>The second version of the ST specification (ST2) <xref target="RFC1190" format="default"/> <xref target="RFC1819" format="default"/> was an experimental connection-oriented internetworking protocol that operated at the same layer as connectionless IP. ST2 packets could be distinguished by their IP header version numbers (IP, at that time, used version number 4, while ST2 used version number 5).</t>
        <t>ST2 used a control plane layered over IP to select routes and reserve capacity for real-time streams across a network path, based on a flow specification communicated by a separate protocol. The flow specification could be associated with QoS state in routers, producing an experimental resource reservation protocol. This allowed ST2 routers along a path to offer end-to-end guarantees, primarily to satisfy the QoS requirements for realtime real-time services over the Internet.</t>
        <section anchor="reasons-for-non-deployment" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>Although implemented in a range of equipment, ST2 was not widely used after completion of the experiments.  It did not offer the scalability and fate-sharing properties that have come to be desired by the Internet community.</t>
          <t>The ST2 protocol is no longer in use.</t>
        </section>
        <section anchor="lessons-learned" numbered="true" toc="default">
          <name>Lessons Learned.</name> Learned</name>
          <t>As time passed, the trade-off between router processing and link capacity changed. Links became faster faster, and the cost of router processing became comparatively more expensive.</t>
          <t>The ST2 control protocol used "hard state" - -- once a route was established, and resources were reserved, routes and resources existing existed until they were explicitly released via signaling. A soft-state approach was thought superior to this hard-state approach, approach and led to development of the IntServ model described in <xref target="IntServ" format="default"/>.</t>
        </section>
      </section>
      <section anchor="IntServ" numbered="true" toc="default">
        <name>Integrated Services (IntServ)</name>
        <t>The suggested references for IntServ are:</t>
        <ul spacing="normal">
          <li>RFC 1633 Integrated Services in the Internet Architecture: an Overview
          <li>"<xref target="RFC1633" format="title"/>" <xref target="RFC1633" format="default"/></li>
          <li>RFC 2211 Specification of the Controlled-Load Network Element Service
          <li>"<xref target="RFC2211" format="title"/>" <xref target="RFC2211" format="default"/></li>
          <li>RFC 2212 Specification of Guaranteed Quality of Service
          <li>"<xref target="RFC2212" format="title"/>" <xref target="RFC2212" format="default"/></li>
          <li>RFC 2215 General Characterization Parameters for Integrated Service Network Elements
          <li>"<xref target="RFC2215" format="title"/>" <xref target="RFC2215" format="default"/></li>
          <li>RFC 2205 Resource ReSerVation Protocol (RSVP)
          <li>"<xref target="RFC2205" format="title"/>" <xref target="RFC2205" format="default"/></li>
        </ul>
        <t>In 1994, when the IntServ architecture document <xref target="RFC1633" format="default"/> was published, real-time traffic was first appearing on the Internet. At that time, bandwidth was still a scarce commodity. Internet Service Providers built networks over DS3 (45 Mbps) infrastructure, and sub-rate (&lt; 1 Mpbs) Mbps) access was common. Therefore, the IETF anticipated a need for a fine-grained QoS mechanism.</t>
        <t>In the IntServ architecture, some applications can require service guarantees. Therefore, those applications use the Resource Reservation Protocol (RSVP) RSVP <xref target="RFC2205" format="default"/> to signal QoS reservations across network paths.  Every router in the network that participates in IntServ maintains per-flow soft-state soft state to a) perform call admission control and b) deliver guaranteed service.</t>
        <t>Applications use Flow Specification Specifications (Flow Specs) Specs, or FLOWSPECs) <xref target="RFC2210" format="default"/> to describe the traffic that they emit. RSVP reserves capacity for traffic on a per Flow Spec per-Flow-Spec basis.</t>
        <section anchor="reasons-for-non-deployment-1" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>Although IntServ has been used in enterprise and government networks, IntServ was never widely deployed on the Internet because of its cost. The following factors contributed to operational cost:</t>
          <ul spacing="normal">
            <li>IntServ must be deployed on every router that is on a path where IntServ is to be used. Although it is possible to include a router that does not participate in IntServ along the path being controlled, if that router is likely to become a bottleneck, IntServ cannot be used to avoid that bottleneck along the path</li> path.</li>
            <li>IntServ maintained per flow state</li> per-flow state.</li>
          </ul>
          <t>As IntServ was being discussed, the following occurred:</t>
          <ul spacing="normal">
            <li>For many expected uses, it became more cost effective to solve the QoS problem by adding bandwidth. Between 1994 and 2000, Internet Service Providers upgraded their infrastructures from DS3 (45 Mbps) to OC-48 (2.4 Gbps). This meant that even if an endpoint was using IntServ in an IntServ-enabled network, its requests would rarely, if ever, be denied, so endpoints and Internet Service Providers had little reason to enable IntServ.</li>
            <li>DiffServ
            <li>Diffserv <xref target="RFC2475" format="default"/> offered a more cost-effective, albeit less fine-grained, solution to the QoS problem.</li>
          </ul>
        </section>
        <section anchor="lessons-learned-1" numbered="true" toc="default">
          <name>Lessons Learned.</name> Learned</name>
          <t>The following lessons were learned:</t>
          <ul spacing="normal">
            <li>Any mechanism that requires every participating onpath on-path router to maintain per-flow state is not likely to succeed, unless the additional cost for offering the feature can be recovered from the user.</li>
            <li>Any mechanism that requires an operator to upgrade all of its routers is not likely to succeed, unless the additional cost for offering the feature can be recovered from the user.</li>
          </ul>
          <t>In environments where IntServ has been deployed, trust relationships
 with endpoints are very different from trust relationships on the
 Internet itself, and there itself.  There are often clearly-defined clearly defined hierarchies in
 Service Level Agreements (SLAs), and (SLAs) governing well-defined transport flows
 operating with pre-determined predetermined capacity and latency requirements over
 paths where capacity or other attributes are constrained.</t>
          <t>IntServ was never widely deployed to manage capacity across the Internet. However, the technique that it produced was deployed for reasons other than bandwidth management. RSVP is widely deployed as an MPLS signaling mechanism. BGP reuses the RSVP concept of Filter Specs to distribute firewall filters, although they are called Flow "Flow Spec Component Types Types" in BGP <xref target="RFC5575" format="default"/>.</t>
        </section>
      </section>
      <section anchor="Quick-Start" numbered="true" toc="default">
        <name>Quick-Start TCP</name>
        <t>The suggested references for Quick-Start TCP are:</t>
        <ul spacing="normal">
          <li>Quick-Start for TCP and IP
          <li>"<xref target="RFC4782" format="title"/>" <xref target="RFC4782" format="default"/></li>
          <li>Determining
          <li>"Determining an appropriate initial sending rate over an underutilized network path path" <xref target="SAF07" format="default"/></li>
          <li>Fast
          <li>"Fast Startup Internet Congestion Control for Broadband Interactive Applications Applications" <xref target="Sch11" format="default"/></li>
          <li>Using
          <li>"Using Quick-Start to enhance TCP-friendly rate control performance in bidirectional satellite networks networks" <xref target="QS-SAT" format="default"/></li>
        </ul>
        <t>Quick-Start is defined in an Experimental RFC <xref target="RFC4782" format="default"/> and is an Experimental a TCP extension that leverages support from the routers on the path to determine an allowed initial sending rate for a path through the Internet, either at the start of data transfers or after idle periods. Without information about the path, a sender cannot easily determine an appropriate initial sending rate. The default TCP congestion control therefore uses the safe but time-consuming slow-start algorithm <xref target="RFC5681" format="default"/>. With Quick-Start, connections are allowed to use higher initial sending rates if there is significant unused bandwidth along the path, path and if the sender and all of the routers along the path approve the request.</t>
        <t>By examining the Time To Live (TTL) field in Quick-Start packets, a sender can determine if  routers on the path have approved the Quick-Start request. However, this method is unable to take into account the routers hidden by tunnels or other network nodes invisible at the IP layer.</t>
        <t>The protocol also includes a nonce that provides protection against cheating routers and receivers. If the Quick-Start request is explicitly approved by all routers along the path, the TCP host can send at up to the approved rate; otherwise otherwise, TCP would use the default congestion control. Quick-Start requires modifications in the involved end-systems end systems as well as in routers. Due to the resulting deployment challenges, Quick-Start was only proposed in <xref target="RFC4782" format="default"/> for controlled environments.</t>
        <t>The Quick-Start mechanism is a lightweight, coarse-grained, in-band, network-assisted fast startup mechanism. The benefits are studied by simulation in a research paper <xref target="SAF07" format="default"/> that complements the protocol specification. The study confirms that Quick-Start can significantly speed up mid-sized data transfers. That paper also presents router algorithms that do not require keeping per-flow state. Later studies <xref target="Sch11" format="default"/> comprehensively analyzes analyze Quick-Start with a full Linux implementation and with a router fast path fast-path prototype using a network processor. In both cases, Quick-Start could be implemented with limited additional complexity.</t>
        <section anchor="reasons-for-non-deployment-2" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>However, experiments with Quick-Start in <xref target="Sch11" format="default"/> revealed several challenges:</t>
          <ul spacing="normal">
            <li>Having information from the routers along the path can reduce the risk of congestion, congestion but cannot avoid it entirely. Determining whether there is unused capacity is not trivial in actual router and host implementations. Data about available capacity visible at the IP layer may be imprecise, and due to the propagation delay, information can already be outdated when it reaches a sender. There is a trade-off between the speedup of data transfers and the risk of congestion even with Quick-Start. This could be mitigated by only allowing Quick-Start to access a proportion of the unused capacity along a path.</li>
            <li>For scalable router fast path implementation, fast-path implementations, it is important to enable parallel processing of packets, as this is a widely used method e.g. method, e.g., in network processors. One challenge is synchronization of information between packets that are processed in parallel, which should be avoided as much as possible.</li>
            <li>Only some types of application traffic can benefit from Quick-Start. Capacity needs to be requested and discovered. The discovered capacity needs to be utilized by the flow, or it implicitly becomes available for other flows.  Failing to use the requested capacity may have already reduced the pool of Quick-Start capacity that was made available to other competing Quick-Start requests. The benefit is greatest when  senders use this only for bulk flows and avoid sending unnecessary Quick-Start requests, e.g. e.g., for flows that only send a small amount of data. Choosing an appropriate request size requires application-internal knowledge that is not commonly expressed by the transport API. How a sender can determine the rate for an initial Quick-Start request is still a largely unsolved problem.</li>
          </ul>
          <t>There is no known deployment of Quick-Start for TCP or other IETF transports.</t>
        </section>
        <section anchor="lessons-learned-2" numbered="true" toc="default">
          <name>Lessons Learned</name>
          <t>Some lessons can be learned from Quick-Start. Despite being a very light-weight lightweight protocol, Quick-Start suffers from poor incremental deployment properties, both properties regarding both a) the required modifications in network infrastructure as well as and b) its interactions with applications. Except for corner cases, congestion control can be quite efficiently performed end-to-end end to end in the Internet, and in modern stacks there is not much room for significant improvement by additional network support.</t>
          <t>After publication of the Quick-Start specification, there have been large-scale experiments with an initial window of up to 10 MSS segments <xref target="RFC6928" format="default"/>. This alternative "IW10" approach can also ramp-up ramp up data transfers faster than the standard congestion control, but it only requires sender-side modifications. As a result, this approach can be easier and incrementally deployed in the Internet. While theoretically Quick-Start can outperform "IW10", the improvement in completion time for data transfer times can, in many cases, be small. After publication of <xref target="RFC6928" format="default"/>, most modern TCP stacks have increased their default initial window.</t>
        </section>
      </section>
      <section anchor="Source-Quench" numbered="true" toc="default">
        <name>ICMP Source Quench</name>
        <t>The suggested references reference for ICMP Source Quench are:</t> is:</t>
        <ul spacing="normal">
          <li>INTERNET CONTROL MESSAGE PROTOCOL
          <li>"<xref target="RFC0792" format="title"/>" <xref target="RFC0792" format="default"/></li>
        </ul>
        <t>The ICMP Source Quench message <xref target="RFC0792" format="default"/> allowed an on-path router to request the source of a flow to reduce its sending rate. This method allowed a router to provide an early indication of impending congestion on a path to the sources that contribute to that congestion.</t>
        <section anchor="reasons-for-non-deployment-3" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>This method was deployed in Internet routers over a period of time, time; the reaction of endpoints to receiving this signal has varied. For low speed low-speed links, with low multiplexing of flows the method could be used to regulate (momentarily reduce) the transmission rate. However, the simple signal does not scale with link speed, speed or with the number of flows sharing a link.</t>
          <t>The approach was overtaken by the evolution of congestion control methods in TCP <xref target="RFC2001" format="default"/>, and later also by other IETF transports. Because these methods were based upon measurement of the end-to-end path and an algorithm in the endpoint, they were able to evolve and mature more rapidly than methods relying on interactions between operational routers and endpoint stacks.</t>
          <t>After ICMP Source Quench was specified, the IETF began to recommend that transports provide end-to-end congestion control <xref target="RFC2001" format="default"/>. The Source Quench method has been obsoleted by the IETF <xref target="RFC6633" format="default"/>, and both hosts and routers must now silently discard this message.</t>
        </section>
        <section anchor="lessons-learned-3" numbered="true" toc="default">
          <name>Lessons Learned</name>
          <t>This method had several problems:</t> problems.</t>
          <t>First, <xref target="RFC0792" format="default"/> did not sufficiently specify how the sender would react to the ICMP Source Quench signal from the path (e.g., <xref target="RFC1016" format="default"/>). There was ambiguity in how the sender should utilize this additional information. This could lead to unfairness in the way that receivers (or routers) responded to this message.</t>
          <t>Second, while the message did provide additional information, the Explicit Congestion Notification (ECN) mechanism <xref target="RFC3168" format="default"/> provided a more robust and informative signal for network nodes to provide early indication that a path has become congested.</t>
          <t>The mechanism originated at a time when the Internet trust model was very different. Most endpoint implementations did not attempt to verify that the message originated from an on-path node before they utilized the message. This made it vulnerable to denial of service Denial-of-Service (DoS) attacks.  In theory, routers might have chosen to use the quoted packet contained in the ICMP payload to validate that the message originated from an on-path node, but this would have increased per-packet processing overhead for each router along the path, path and would have required transport functionality in the router to verify whether the quoted packet header corresponded to a packet the router had sent. In addition, section 5.2 of <xref target="RFC4443" format="default"/> sectionFormat="of" section="5.2"/>
noted ICMPv6-based attacks on hosts that would also have threatened routers processing ICMPv6 Source Quench payloads. As time passed, it became increasingly obvious that the lack of validation of the messages exposed receivers to a security vulnerability where the messages could be forged to create a tangible denial of service DoS opportunity.</t>
        </section>
      </section>
      <section anchor="TRIGTRAN" numbered="true" toc="default">
        <name>Triggers for Transport (TRIGTRAN)</name>
        <t>The suggested references for TRIGTRAN are:</t>
        <ul spacing="normal">
          <li>TRIGTRAN BOF at IETF 55 <xref target="TRIGTRAN-55" format="default"/></li>
          <li>TRIGTRAN BOF at IETF 56 <xref target="TRIGTRAN-56" format="default"/></li>
        </ul>
        <t>TCP <xref target="RFC0793" format="default"/> has a well-known weakness - -- the end-to-end flow control mechanism has only a single signal, the loss of a segment,
detected when no acknowledgment for the lost segment is received at the sender.  There are multiple reasons why the sender might not have received an acknowledgment for the segment.  To name several, the segment could have been trapped in a routing loop, damaged in transmission and failed checksum verification at the
receiver, or lost because some intermediate device discarded the packet, or any of a variety of other things could have happened to the acknowledgment on the way back from the receiver to the sender. TCP implementations since the late 1980s have made the "safe" decision and have interpreted the loss of a segment as evidence
that the path between two endpoints may have become congested enough to exhaust buffers on intermediate hops, so that the TCP sender should "back off" - -- reduce its sending rate until it knows that its segments are now being delivered without loss
<xref target="RFC5681" format="default"/>. More modern TCP stacks have added a growing array of strategies about how to establish the sending rate <xref target="RFC5681" format="default"/>, but when a path is no longer operational, TCP would continue to retry transmissions, which would fail, again, and double their Retransmission Time Out (RTO) timers with each failed transmission, with the result that TCP would wait many seconds before retrying a segment, even if the path becomes operational while the sender is waiting for its next retry.</t>
	</t>
        <t>The thinking behind TRIGTRAN was that if a path completely stopped working because a link along the path was "down", somehow something along the path could signal TCP when that link returned to service, and the sending TCP could retry immediately, without waiting for a full retransmission timeout (RTO) period.</t>
        <section anchor="reasons-for-non-deployment-4" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>The early dreams for TRIGTRAN were dashed because of an assumption that TRIGTRAN triggers would be unauthenticated. This meant that any "safe" TRIGTRAN mechanism would have relied on a mechanism such as setting the IPv4 TTL or IPv6 Hop Count to 255 at a sender and testing that it was 254 upon receipt, so that a receiver could verify that a signal was generated by an adjacent sender known to be on the path being used, used and not some unknown sender which that might not even be on the path (e.g., "The Generalized TTL Security Mechanism (GTSM)"
"<xref target="RFC5082" format="title"/>" <xref target="RFC5082" format="default"/>). This situation is very similar to the case for ICMP Source Quench messages as described in <xref target="Source-Quench" format="default"/>, which were also unauthenticated, unauthenticated and could be sent by an off-path attacker, resulting in deprecation of ICMP Source Quench message processing <xref target="RFC6633" format="default"/>.</t>
          <t>TRIGTRAN's scope shrunk from "the path is down" to "the first-hop link is down".</t> down."</t>
          <t>But things got worse.</t>
          <t>Because TRIGTRAN triggers would only be provided when the first-hop link was "down", TRIGTRAN triggers couldn't replace normal TCP retransmission behavior if the path failed because some link further along the network path was "down". So TRIGTRAN triggers added complexity to an already complex already-complex TCP state machine, machine and did not allow any existing complexity to be removed.</t>
          <t>There was also an issue that the TRIGTRAN signal was not sent in response to a specific host that had been sending packets, packets and was instead a signal that stimulated a response by any sender on the link. This needs to scale when there are multiple flows trying to use the same resource, yet the sender of a trigger has no understanding of how many of the potential traffic sources will respond by sending packets - -- if recipients of the signal back-off "back off" their responses to a trigger to improve scaling, then that immediately mitigates the benefit of the signal.</t>
          <t>Finally, intermediate forwarding nodes required modification to provide TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN triggers, so there was no way to recover the cost of modifying, testing, and deploying updated intermediate nodes.</t>
          <t>Two TRIGTRAN BOFs were held, at IETF 55 <xref target="TRIGTRAN-55" format="default"/> and IETF 56 <xref target="TRIGTRAN-56" format="default"/>, but this work was not chartered, and there was no interest in deploying TRIGTRAN unless it was chartered and standardized in the IETF.</t>
        </section>
        <section anchor="lessons-learned-4" numbered="true" toc="default">
          <name>Lessons Learned.</name> Learned</name>
          <t>The reasons why this work was not chartered, much less deployed, provide several useful lessons for researchers.</t>
          <ul spacing="normal">
            <li>TRIGTRAN started with a plausible value proposition, but networking realities in the early 2000s forced reductions in scope that led directly to reductions in potential benefits, benefits but no corresponding reductions in costs and complexity.</li>
            <li>These reductions in scope were the direct result of an inability for hosts to trust or authenticate TRIGTRAN signals they received from the network.</li>
            <li>Operators did not believe they could charge for TRIGTRAN signaling, because first-hop links didn't fail frequently, frequently and TRIGTRAN provided no reduction in operating expenses, so there was little incentive to purchase and deploy TRIGTRAN-capable network equipment.</li>
          </ul>
          <t>It is also worth noting that the targeted environment for TRIGTRAN in the late 1990s contained links with a relatively small number of directly-connected directly connected hosts - -- for instance, cellular or satellite links. The transport community was well aware of the dangers of sender synchronization based on multiple senders receiving the same stimulus at the same time, but the working assumption for TRIGTRAN was that there wouldn't be enough senders for this to be a meaningful problem. In the 2010s, it is was  common for a single "link" to support many senders and receivers on a single link, receivers, likely requiring TRIGTRAN senders to wait some random amount of time before sending after receiving a TRIGTRAN signal, which would have reduced the benefits of TRIGTRAN even more.</t>
        </section>
      </section>
      <section anchor="Shim6" numbered="true" toc="default">
        <name>Shim6</name>
        <t>The suggested references reference for Shim6 are:</t> is:</t>
        <ul spacing="normal">
          <li>Shim6: Level 3 Multihoming Shim Protocol for IPv6
        <li>"<xref target="RFC5533" format="title"/>" <xref target="RFC5533" format="default"/></li>
        </ul>
        <t>The IPv6 routing architecture <xref target="RFC1887" format="default"/> assumed that most sites on the Internet would be identified by Provider Assigned IPv6 prefixes, so that Default-Free Zone routers only contained routes to other providers, resulting in a very small IPv6 global routing table.</t>
        <t>For a single-homed site, this could work well. A multihomed site with only one upstream provider could also work well, although BGP multihoming from a single upstream provider was often a premium service (costing more than twice as much as two single-homed sites), and if the single upstream provider went out of service, all of the multihomed paths could fail simultaneously.</t>
        <t>IPv4 sites often multihomed by obtaining Provider Independent prefixes, prefixes and advertising these prefixes through multiple upstream providers. With the assumption that any multihomed IPv4 site would also multihome in IPv6, it seemed likely that IPv6 routing would be subject to the same pressures to announce Provider Independent prefixes, resulting in a global an IPv6 global routing table that exhibited the same explosive growth as the global IPv4 global routing table. During the early 2000s, work began on a protocol that would provide multihoming for IPv6 sites without requiring sites to advertise Provider Independent prefixes into the IPv6 global routing table.</t>
        <t>This protocol, called Shim6, "Shim6", allowed two endpoints to exchange multiple addresses ("Locators") that all mapped to the same endpoint ("Identity"). After an endpoint learned multiple Locators for the other endpoint, it could send to any of those Locators with the expectation that those packets would all be delivered to the endpoint with the same Identity. Shim6 was an example of an "Identity/Locator Split" protocol.</t>
        <t>Shim6, as defined in <xref target="RFC5533" format="default"/> and related RFCs, provided a workable solution for IPv6 multihoming using Provider Assigned prefixes, including capability discovery and negotiation, and allowing end-to-end application communication to continue even in the face of path failure, because applications don't see Locator failures, failures and continue to communicate with the same Identity using a different Locator.</t>
        <section anchor="reasons-for-non-deployment-5" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>Note that the problem being addressed was "site multihoming", but Shim6 was providing "host multihoming". That meant that the decision about what path would be used was under host control, not under edge router control.</t>
          <t>Although more work could have been done to provide a better technical solution, the biggest impediments to Shim6 deployment were operational and business considerations. These impediments were discussed at multiple network operator group meetings, including <xref target="Shim6-35" format="default"/> at <xref target="NANOG-35" format="default"/>.</t>
          <t>The technical issues centered around concerns that Shim6 relied on the host to track all the connections, while also tracking Identity/Locator mappings in the kernel, kernel and tracking failures to recognize that an available path has failed.</t>
          <t>The operational issues centered around concerns that operators were performing traffic engineering on traffic aggregates. With Shim6, these operator traffic engineering policies must be pushed down to individual hosts.</t>
          <t>In addition, operators would have no visibility or control over the decision of hosts choosing to switch to another path. They expressed concerns that relying on hosts to steer traffic exposed operator networks to oscillation based on feedback loops, if hosts moved from path to path frequently. Given that Shim6 was intended to support multihoming across operators, operators providing only one of the paths would have even less visibility as traffic suddenly appeared and disappeared on their networks.</t>
          <t>In addition, firewalls that expected to find a TCP or UDP transport-level protocol header in the IP payload would see a Shim6 Identity header instead, and they would not perform transport-protocol-based firewalling functions because the firewall's normal processing logic would not look past the Identity header.</t> header.
The firewall would perform its default action, which would most likely be to drop packets that don't match any processing rule.</t>
          <t>The business issues centered on reducing or removing the ability to sell BGP multihoming service to their own customers, which is often more expensive than two single-homed connectivity services.</t>
        </section>
        <section anchor="lessons-learned-5" numbered="true" toc="default">
          <name>Lessons Learned</name>
          <t>It is extremely important to take operational concerns into account when a path-aware Path Aware protocol is making decisions about path selection that may conflict with existing operational practices and business considerations.</t>
        </section>
        <section anchor="Addendum-MP-TCP" numbered="true" toc="default">
          <name>Addendum on MultiPath Multipath TCP</name>
          <t>During discussions in the PANRG session at IETF 103 <xref target="PANRG-103-Min" format="default"/>, Lars Eggert, past Transport Area Director, pointed out that during charter discussions for the Multipath TCP working group Working Group <xref target="MP-TCP" format="default"/>, operators expressed concerns that customers could use Multipath TCP to loadshare load-share TCP connections across operators simultaneously and compare passive performance measurements across network paths in real time, changing the balance of power in those business relationships. Although the Multipath TCP working group Working Group was chartered, this concern could have acted as an obstacle to deployment.</t>
          <t>Operator objections to Shim6 were focused on technical concerns, but this concern could have also been an obstacle to Shim6 deployment if the technical concerns had been overcome.</t>
        </section>
      </section>
      <section anchor="NSIS" numbered="true" toc="default">
        <name>Next Steps in Signaling (NSIS)</name>
        <t>The suggested references for Next Steps in Signaling (NSIS) are:</t>
        <ul spacing="normal">
          <li>the concluded working group charter <xref target="NSIS-CHARTER-2001" format="default"/></li>
          <li>GIST: General Internet Signalling Transport
          <li>"<xref target="RFC5971" format="title"/>" <xref target="RFC5971" format="default"/></li>
          <li>NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
          <li>"<xref target="RFC5973" format="title"/>" <xref target="RFC5973" format="default"/></li>
          <li>NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
          <li>"<xref target="RFC5974" format="title"/>" <xref target="RFC5974" format="default"/></li>
          <li>Authorization for NSIS Signaling Layer Protocols
          <li>"<xref target="RFC5981" format="title"/>" <xref target="RFC5981" format="default"/></li>
        </ul>
        <t>The NSIS Working Group worked on signaling techniques for network layer network-layer resources (e.g., QoS resource reservations, Firewall and NAT traversal).</t>
        <t>When RSVP <xref target="RFC2205" format="default"/> was used in deployments, a number of questions came up about its perceived limitations and potential missing features. The issues noted in the NSIS Working Group charter <xref target="NSIS-CHARTER-2001" format="default"/> include interworking between domains with different QoS architectures, mobility and roaming for IP interfaces, and complexity. Later, the lack of security in RSVP was also recognized (<xref <xref target="RFC4094" format="default"/>).</t> format="default"/>.</t>
        <t>The NSIS Working Group was chartered to tackle those issues and initially focused on QoS signaling as its primary use case. However, over time a new approach evolved that introduced a modular architecture using two application-specific signaling protocols (the protocols: a) the NSIS Signaling Layer Protocol (NSLP)) (NSLP) on top of b) a generic
signaling transport protocol (the NSIS Transport Layer Protocol (NTLP)).</t>
        <t>The NTLP (NTLP)).

</t>
        <t>NTLP is defined in <xref target="RFC5971" format="default"/>. Two types of NSLPs are defined: the NSIS Signaling Layer Protocol (NSLP) an NSLP for Quality-of-Service Signaling QoS signaling <xref target="RFC5974" format="default"/> as well as the NAT/Firewall NSIS Signaling Layer Protocol (NSLP) and an NSLP for NATs/firewalls <xref target="RFC5973" format="default"/>.</t>
        <section anchor="reasons-for-non-deployment-6" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>The obstacles for deployment can be grouped into implementation-related aspects and operational aspects.</t>

        <ul spacing="normal">
            <li>Implementation-related aspects:</li>
          </ul>
         <li>
          <t>Implementation-related aspects:</t>
          <t>Although NSIS provides benefits
    with respect to flexibility, mobility, and security compared to
    other network signaling techniques, hardware vendors were reluctant
    to deploy this solution, because it would require additional
    implementation effort and would result in additional complexity for
    router implementations.</t>
          <t>The NTLP
          <t>NTLP mainly operates as a path-coupled signaling protocol, i.e, i.e.,
    its messages are processed at the intermediate node's control plane of each intermediate node that are is
    also forwarding the data flows. This requires a
    mechanism to intercept signaling packets while they are forwarded
    in the same manner (especially along the same path) as data
    packets. NSIS uses the
    IPv4 and IPv6 Router Alert Option (RAO) to allow for
    interception of those path-coupled signaling messages, and
    this technique requires router implementations to correctly
    understand and implement the handling of RAOs, e.g., to only
    process packet packets with RAOs of interest and to leave packets with
    irrelevant RAOs in the fast forwarding processing path (a
    comprehensive discussion of these issues can be found in
    <xref target="RFC6398" format="default"/>). The latter was an issue with some router
    implementations at the time of standardization.</t>
          <t>Another reason is
    that path-coupled signaling protocols that interact with routers
    and request manipulation of state at these routers (or any
    other network element in general) are under scrutiny: a packet (or
    sequence of packets) out of the mainly untrusted data path is
    requesting creation and manipulation of network state. This is
    seen as potentially dangerous (e.g., opens up a Denial of Service (DoS) DoS threat to a
    router's control plane) and difficult for an operator to control.
    Path-coupled signaling approaches were considered problematic (see also section 3 of <xref target="RFC6398" format="default"/>). sectionFormat="of" section="3"/>). There are
    recommendations on how to secure NSIS nodes and
    deployments (e.g., <xref target="RFC5981" format="default"/>).</t>
    </li>
  </ul>
  <ul spacing="normal">
            <li>Operational Aspects:</li>
          </ul>
    <li>
         <t>Operational Aspects:</t>
         <t>NSIS not only
    required trust between customers and their provider, but also among
    different providers. Especially, In particular, QoS signaling techniques would
    require some kind of dynamic service level agreement SLA support that
    would imply (potentially quite complex) bilateral negotiations
    between different Internet service providers. Service Providers. This complexity was
    not considered to be justified justified, and increasing the
    bandwidth (and thus avoiding bottlenecks) was
    cheaper than actively managing network resource bottlenecks by
    using path-coupled QoS signaling techniques. Furthermore, an
    end-to-end path typically involves several provider domains domains, and
    these providers need to closely cooperate in cases of failures.</t>
    </li>
  </ul>
        </section>
        <section anchor="lessons-learned-6" numbered="true" toc="default">
          <name>Lessons Learned</name>
          <t>One goal of NSIS was to decrease the complexity of the signaling
protocol, but a path-coupled signaling protocol comes with the
intrinsic complexity of IP-based networks, beyond the complexity of the
signaling protocol itself. Sources of intrinsic complexity include:</t>
          <ul spacing="normal">
            <li>the presence of asymmetric routes between endpoints and routers</li> routers.</li>
            <li>the lack of security and trust at large in the Internet infrastructure</li> infrastructure.</li>
            <li>the presence of different trust boundaries</li> boundaries.</li>
            <li>the effects of best-effort networks (e.g., robustness to packet loss)</li> loss).</li>
            <li>divergence from the fate sharing fate-sharing principle (e.g., state within the network).</li>
          </ul>
          <t>Any path-coupled signaling protocol has to deal with these realities.</t>
          <t>Operators view the use of IPv4 and IPv6 Router Alert Option (RAO) Options (RAOs) to signal routers along the path from end systems with suspicion, because these end systems are usually not authenticated and heavy use of RAOs can easily increase the CPU load on routers that are designed to process most packets using a hardware "fast path" and diverting packets containing RAO RAOs to a slower, more capable processor.</t>
        </section>
      </section>
      <section anchor="FL" numbered="true" toc="default">
        <name>IPv6 Flow Label</name> Labels</name>
        <t>The suggested references reference for IPv6 Flow Label are:</t> Labels is:</t>
        <ul spacing="normal">
          <li>IPv6 Flow Label Specification
        <li>"<xref target="RFC6437" format="title"/>" <xref target="RFC6437" format="default"/></li>
        </ul>
        <t>IPv6 specifies a 20-bit field Flow Label field <xref target="RFC6437" format="default"/>, included in the fixed part of the IPv6 header and hence present in every IPv6 packet. An endpoint sets the value  in this field to one of a set of pseudo-randomly pseudorandomly assigned values. If a packet is not part of any flow, the flow label value is set to zero <xref target="RFC3697" format="default"/>. A number of Standards Track and Best Current Practice RFCs (e.g., <xref target="RFC8085" format="default"/>, <xref target="RFC6437" format="default"/>, <xref target="RFC6438" format="default"/>) encourage IPv6 endpoints to set a non-zero value in this field. A multiplexing transport could choose to use multiple flow labels to allow the network to either independently forward its subflows, subflows or to use one common value for the traffic aggregate. The flow label is present in all fragments. IPsec was originally put forward as one important use-case use case for this mechanism and does encrypt the field <xref target="RFC6438" format="default"/>.</t>
        <t>Once set, the flow label can provide information that can help inform network nodes about subflows present at the transport layer, without needing to interpret the setting of upper layer upper-layer protocol fields <xref target="RFC6294" format="default"/>.  This information can also be used to coordinate how aggregates of transport subflows are grouped when queued in the network and to select appropriate per-flow forwarding when choosing between alternate paths <xref target="RFC6438" format="default"/> (e.g. (e.g., for Equal Cost Equal-Cost Multipath Routing (ECMP) routing and Link Aggregation (LAG)).</t> Groups (LAGs)).</t>
        <section anchor="reasons-for-non-deployment-7" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>Despite the field being present in every IPv6 packet, the mechanism did not receive as much use as originally envisioned.  One reason is that to be useful it requires engagement by two different  stakeholders:</t>
          <ul spacing="normal">
            <li>Endpoint Implementation:</li>
          </ul>
            <li>
            <t>Endpoint Implementation:</t>
          <t>For network nodes along a path to utilize the flow label label, there needs to be a non-zero value inserted in the field <xref target="RFC6437" format="default"/> at the sending endpoint.
There needs to be an incentive for an endpoint to set an appropriate non-zero value.
The value should appropriately reflect the level of aggregation the traffic expects to be provided by the network. However, this requires the stack  to know granularity at which flows should be identified (or conversely (or, conversely, which flows should receive aggregated treatment), i.e., which packets carry the same flow label. Therefore, setting a non-zero value may result in additional choices that need to be made by an application developer.</t>
          <t>Although the original flow label standard <xref target="RFC3697" format="default"/> forbids any encoding of meaning into the flow label value, the opportunity to use the flow label as a covert channel or to signal other meta-information may have raised concerns about setting a non-zero value <xref target="RFC6437" format="default"/>.</t>
          <t>Before methods are widely deployed to use this method, there could be no incentive for an endpoint to set the field.</t>
	    </li>
	  </ul>
          <ul spacing="normal">
            <li>Operational
            <li>
             <t>Operational support in network nodes:</li>
          </ul> nodes:</t>
          <t>A benefit can only be realized when a network node along the path also uses this information to inform its decisions. Network equipment (routers and/or middleboxes) need to include appropriate support so they can in order to utilize the field when making decisions about how to classify flows, flows or to inform forwarding choices. Use forward packets. The use of any optional feature in a network node also requires corresponding updates to operational procedures, procedures and therefore is normally only introduced when the cost can be justified.</t>
          <t>A benefit from utilizing the flow label is expected to be increased quality of experience for applications - -- but this comes at some operational cost to an operator, operator and requires endpoints to set the field.</t>
	    </li>
	  </ul>
        </section>
        <section anchor="lessons-learned-7" numbered="true" toc="default">
          <name>Lessons Learned</name>
          <t>The flow label is a general purpose general-purpose header field for use by the path. Multiple uses have been proposed. One candidate use was to reduce the  complexity of forwarding decisions. However,  modern routers can use a "fast path", often taking advantage of hardware to accelerate processing. The method can assist in more complex forwarding, such as ECMP routing and load balancing.</t>
          <t>Although <xref target="RFC6437" format="default"/> recommended that endpoints should by default choose uniformly-distributed uniformly distributed labels for their traffic, the specification permitted an endpoint to choose to set a zero value. This ability of endpoints to choose to set a flow label of zero has had consequences on deployability:</t>
          <ul spacing="normal">
            <li>Before wide-scale support by endpoints, it would be impossible to rely on a non-zero flow label being set. Network nodes therefore would need to also employ other techniques to realize equivalent functions. An example of a method is one assuming semantics of the source port field to provide entropy input to a network-layer hash. This use of a 5-tuple to classify a packet represents a layering violation <xref target="RFC6294" format="default"/>. When other methods have been deployed, they increase the cost of deploying standards-based methods, even though they may offer less control to  endpoints and result in potential interaction with other uses/interpretation of the field.</li>
            <li>Even though the flow label is specified as an end-to-end field, some network paths have been observed to not transparently forward the flow label. This could result from non-conformant equipment, equipment or could indicate that some operational networks have chosen to re-use reuse the protocol field for other (e.g. internal purposes). (e.g., internal) purposes. This results in lack of transparency, and a deployment hurdle to endpoints expecting that they can set a flow label that is utilized by the network.  The more recent practice of "greasing" <xref target="GREASE" target="I-D.iab-use-it-or-lose-it" format="default"/> would suggest that a different outcome could have been achieved if endpoints were always required to set a non-zero value.</li>
            <li>
              <xref target="RFC1809" format="default"/> noted that setting the choice of the flow label value can depend on the expectations of the traffic generated by an application, which suggests that an API should be presented to control the setting or policy that is used. However, many currently available APIs do not have this support.</li>
          </ul>
          <t>A growth in the use of encrypted transports, (e.g. transports (e.g., QUIC <xref target="QUIC-WG" format="default"/>) target="RFC9000"/>) seems likely to raise similar issues similar to those discussed above and could motivate renewed interest in utilizing the flow label.</t> label.
</t>
        </section>
      </section>
      <section anchor="ecn" numbered="true" toc="default">
        <name>Explicit Congestion Notification (ECN)</name>
        <t>The suggested references for Explicit Congestion Notification (ECN) are:</t>
        <ul spacing="normal">
          <li>Recommendations on Queue Management and Congestion Avoidance in the Internet
          <li>"<xref target="RFC2309" format="title"/>" <xref target="RFC2309" format="default"/></li>
          <li>A Proposal to add Explicit Congestion Notification (ECN) to IP
          <li>"<xref target="RFC2481" format="title"/>" <xref target="RFC2481" format="default"/></li>
          <li>The Addition of Explicit Congestion Notification (ECN) to IP
          <li>"<xref target="RFC3168" format="title"/>" <xref target="RFC3168" format="default"/></li>
          <li>Implementation
          <li>"Implementation Report on Experiences with Various TCP RFCs RFCs" <xref target="vista-impl" format="default"/>, slides 6 and 7</li>
          <li>Implementation
          <li>"Implementation and Deployment of ECN ECN" (at <xref target="SallyFloyd" format="default"/></li> format="default"/>)</li>
        </ul>
        <t>In the early 1990s, the large majority of Internet traffic used TCP as its transport protocol, but TCP had no way to detect path congestion before the path was so congested that packets were being dropped, and these dropped. These congestion events could affect all senders using a path, either by "lockout", where long-lived flows monopolized the queues along a path, or by "full queues", where queues remain full, or almost full, for a long period of time.</t>
        <t>In response to this situation, "Active Queue Management" (AQM) was deployed in the network. A number of AQM disciplines have been deployed, but one common approach was that routers dropped packets when a threshold buffer length was reached, so that transport protocols like TCP that were responsive to loss would detect this loss and reduce their sending rates. Random Early Detection (RED) was one such proposal in the IETF. As the name suggests, a router using RED as its AQM discipline that detected time-averaged queue lengths passing a threshold would choose incoming packets probabilistically to be dropped <xref target="RFC2309" format="default"/>.
In response to this situation, "Active Queue Management" (AQM) was deployed in the network. A number of AQM disciplines have been deployed, but one common approach was that routers dropped packets when a threshold buffer length was reached, so that transport protocols like TCP that were responsive to loss would detect this loss and reduce their sending rates. Random Early Detection (RED) was one such proposal in the IETF. As the name suggests, a router using RED as its AQM discipline that detected time-averaged queue lengths passing a threshold would choose incoming packets probabilistically to be dropped <xref target="RFC2309" format="default"/>.</t>
        <t>Researchers suggested that providing "explicit congestion notifications" format="default"/>.</t>
        <t>Researchers suggested providing "explicit congestion notifications" to senders when routers along the path detected that their queues were building, so that some
giving senders would an opportunity to "slow down" as if a loss had occurred, so that the giving path queues had time to drain, and while the path still had sufficient buffer capacity to accommodate bursty arrivals of packets from other senders. This was proposed as an Experiment experiment in <xref target="RFC2481" format="default"/>, format="default"/> and standardized in <xref target="RFC3168" format="default"/>.</t>
        <t>A key aspect of ECN was the use of IP header fields rather than IP options to carry explicit congestion notifications, since the proponents recognized that</t>
        <ul empty="true" spacing="normal">
          <li>Many
<!-- DNE (too short for blockquote) -->
        <t indent="3">
        Many routers process the "regular" headers in IP packets more
  efficiently than they process the header information in IP
  options.</li>
        </ul>
  options.</t>
        <t>Unlike most of the Path Aware technologies included in this document, the story of ECN continues to the present day, day and encountered a large number of Lessons Learned during that time. The early history of ECN (non-)deployment provides Lessons Learned that were not captured by other contributions in <xref target="Contributions" format="default"/>, so that is the emphasis in this section of the document.</t>
        <section anchor="reasons-for-non-deployment-8" numbered="true" toc="default">
          <name>Reasons for Non-deployment</name>
          <t>There are at least three sub-stories - ECN
          <t>ECN deployment relied on three factors -- support in clients, ECN deployment client implementations, support in routers, router implementations, and AQM deployment decisions in operational networks. All three sub-stories mattered.</t> networks.</t>
          <t>The proponents of ECN did so much right, anticipating many of the Lessons Learned now recognized in <xref target="LessonsLearned" format="default"/>. They recognized the need to support incremental deployment (<xref target="EarlyAdopters" format="default"/>). They considered the impact on router throughput (<xref target="Fast-paths" format="default"/>). They even considered trust issues between end nodes and the network, both for both non-compliant end nodes (<xref target="IDsTrustingEndpoints" format="default"/>) and non-compliant routers (<xref target="EndpointsTrustingIDs" format="default"/>).</t>
          <t>They were rewarded with ECN being implemented in major operating systems, both for both end nodes and for routers. A number of implementations are listed under "Implementation and Deployment of ECN" at <xref target="SallyFloyd" format="default"/>.</t>
          <t>What they did not anticipate, anticipate was routers that would crash, crash when they saw bits 6 and 7 in the IPv4 TOS Type of Service (TOS) octet <xref target="RFC0791" format="default"/>/IPv6 format="default"/> / IPv6 Traffic Class field <xref target="RFC2460" format="default"/>, which <xref target="RFC2481" format="default"/> redefined to be "currently unused", "Currently Unused", being set to a non-zero value.</t>
          <t>As described in <xref target="vista-impl" format="default"/>,</t>
          <ul empty="true" spacing="normal">
            <li>Intermediate format="default"/> ("IGD" stands for "Intermediate Gateway Device Device"),</t>
<!-- DNE -->
          <blockquote>
          IGD problem #1: one of the most popular versions from one of the most popular vendors.
When a data packet arrives with either ECT(0) or ECT(1) (indicating successful ECN capability negotiation) indicated, router crashed.
Cannot be recovered at TCP layer (sic)</li>
          </ul> [sic]
	  </blockquote>
          <t>This implementation, which would be run on a significant percentage of Internet end nodes, was shipped with ECN disabled, as was true for several of the other implementations listed under "Implementation and Deployment of ECN" at <xref target="SallyFloyd" format="default"/>. Even if subsequent router vendors fixed these implementations, ECN was still disabled on end nodes, and given the tradeoff trade-off between the benefits of enabling ECN (somewhat better behavior during congestion) and the risks of enabling ECN (possibly crashing a router somewhere along the path), ECN tended to stay disabled on implementations that supported ECN for decades afterwards.</t>
        </section>
        <section anchor="lessons-learned-8" numbered="true" toc="default">
          <name>Lessons Learned</name>
          <t>Of the contributions included in <xref target="Contributions" format="default"/>, ECN may be unique in providing these lessons:</t>
          <ul spacing="normal">
            <li>Even if you do everything right, you may trip over implementation bugs in devices you know nothing about, that will cause severe problems that prevent successful deployment of your path aware Path Aware technology.</li>
            <li>After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by default.</li>
          </ul>
          <t>These two lessons, taken together, could be summarized as "you get one chance to get it right".</t> right."</t>
          <t>During discussion of ECN at <xref target="PANRG-110" format="default"/>, we noted that "you get one chance to get it right" isn't quite correct today, because operating systems on so many host systems are frequently updated, and transport protocols like QUIC <xref target="I-D.ietf-quic-transport" target="RFC9000" format="default"/> are being implemented in user space, space and can be updated without touching installed operating systems. Neither of these factors were true in the early 2000s.</t>
          <t>We think that these restatements of the ECN Lessons Learned are more useful for current implementers:</t>
          <ul spacing="normal">
            <li>Even if you do everything right, you may trip over implementation bugs in devices you know nothing about, that will cause severe problems that prevent successful deployment of your path aware Path Aware technology. Testing before deployment isn't enough to ensure successful deployment. It is also necessary to "deploy gently", which often means deploying for a small subset of users to gain experience, experience and implementing feedback mechanisms to detect that user experience is being degraded.</li>
            <li>After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by default. This might be based on the difficulty of distributing implementations that enable it by default, but are it is just as likely to be based on the "bad taste in the mouth" that implementers have after an unsuccessful deployment attempt that degraded user experience.</li>
          </ul>
          <t>With these expansions, the two lessons, taken together, could be more helpfully summarized as "plan for failure" - -- anticipate what your next step will be, if initial deployment is unsuccessful.</t>
          <t>ECN deployment was also hindered by non-deployment of AQM in many devices, because of operator interest in QoS features provided in the network, rather than using the network to assist end systems in providing for themselves. But that's another story, and the AQM Lessons Learned are already covered in other contributions in <xref target="Contributions" format="default"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document describes Path Aware techniques that were not adopted and widely deployed on the Internet, so it doesn't affect the security of the Internet.</t>
      <t>If this document meets its goals, we may develop new techniques for Path Aware Networking networking that would affect the security of the Internet, but security considerations for those techniques will be described in the corresponding RFCs that specify them.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes has no requests of IANA.</t> IANA actions.</t>
    </section>
    <section anchor="acknowledgments" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>Initial material for <xref target="ST2" format="default"/> on ST2 was provided by Gorry Fairhurst.</t>
      <t>Initial material for <xref target="IntServ" format="default"/> on IntServ was provided
  </middle>
  <back>

<displayreference target="I-D.irtf-panrg-questions" to="PANRG-QUESTIONS"/>
<displayreference target="I-D.irtf-panrg-path-properties" to="PANRG-PATH-PROPERTIES"/>
<displayreference target="I-D.ietf-tsvwg-intserv-multiple-tspec" to="INTSERV-MULTIPLE-TSPEC"/>
<displayreference target="I-D.arkko-arch-internet-threat-model" to="INTERNET-THREAT-MODEL"/>
<displayreference target="I-D.farrell-etm" to="FARRELL-ETM"/>
<displayreference target="I-D.iab-use-it-or-lose-it" to="GREASE"/>

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

<!-- draft-irtf-panrg-questions (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-panrg-questions.xml"/>

<!-- draft-irtf-panrg-path-properties (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-panrg-path-properties.xml"/>

<!-- draft-ietf-tsvwg-intserv-multiple-tspec (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tsvwg-intserv-multiple-tspec.xml"/>

<!-- draft-arkko-arch-internet-threat-model (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.arkko-arch-internet-threat-model.xml"/>

<!-- draft-farrell-etm (Replaced by Ron Bonica.</t>
      <t>Initial material for <xref target="Quick-Start" format="default"/> on Quick-Start TCP was provided draft-arkko-farrell-arch-model-t) (Expired)
HOWEVER - draft-farrell-etm is cited by Michael Scharf, who also provided suggestions [SAAG-105-Min] (Section 3), so we
have to improve keep the old listing -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.farrell-etm.xml"/>

<!-- draft-ietf-quic-transport (RFC 9000 / Published May 2021) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1016.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1190.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1633.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1809.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1819.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1887.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2001.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2210.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2211.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2212.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2215.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2481.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3697.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4094.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4782.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5218.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5533.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5575.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5971.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5974.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5981.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6294.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6398.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6633.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7305.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7418.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8170.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8793.xml"/>

      <reference anchor="Colossal-Cave" target="https://en.wikipedia.org/wiki/Colossal_Cave_Adventure">
        <front>
          <title>Colossal Cave Adventure</title>
          <author><organization>Wikipedia</organization></author>
          <date year="2021" month="June"/>
        </front>
      </reference>

<!-- [Conviva] Keep space before colon; this section after is how it was edited.</t>
      <t>Initial material for <xref target="Source-Quench" format="default"/> on ICMP Source Quench was provided by Gorry Fairhurst.</t>
      <t>Initial material for <xref target="TRIGTRAN" format="default"/> on Triggers for Transport (TRIGTRAN) was provided by Spencer Dawkins.</t>
      <t><xref target="Shim6" format="default"/> on Shim6 builds appears on initial material describing obstacles provided by Erik Nordmark, with background added by Spencer Dawkins.</t>
      <t>Initial material for <xref target="NSIS" format="default"/> page -->
      <reference anchor="Conviva" target="https://www.conviva.com/datasheets/precision-delivery-intelligence/">
        <front>
          <title>Conviva Precision : Data Sheet</title>
          <author>
            <organization/>
          </author>
          <date year="2021" month="January"/>
        </front>
      </reference>

      <reference anchor="IEN-119" target="https://www.rfc-editor.org/ien/ien119.txt">
        <front>
          <title>ST - A Proposed Internet Stream Protocol</title>
          <author initials="J." surname="Forgie" fullname="James W. Forgie">
            <organization/>
          </author>
          <date year="1979" month="September"/>
        </front>
      </reference>

<!-- draft-iab-use-it-or-lose-it (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.iab-use-it-or-lose-it.xml"/>

      <reference anchor="ITAT" target="https://www.iab.org/activities/workshops/itat/">
        <front>
          <title>IAB Workshop on Next Steps In Signaling (NSIS) was provided by Roland Bless Internet Technology Adoption and Martin Stiemerling.</t>
      <t>Initial material for <xref target="FL" format="default"/> on IPv6 Flow Labels was provided by Gorry Fairhurst.</t>
      <t>Initial material for <xref target="ecn" format="default"/> on Explicit Congestion Notification was provided by Spencer Dawkins.</t>
      <t>Our thanks to Adrian Farrel, Bob Briscoe, C.M. Heard, David Black, Eric Kinnear, Erik Auerswald, Gorry Fairhurst, Jake Holland, Joe Touch, Joeri de Ruiter, Kireeti Kompella, Mohamed Boucadair, Roland Bless, Ruediger Geib, Theresa Enghardt, Transition (ITAT) 2013</title>
          <author>
            <organization/>
          </author>
          <date year="2013" month="December"/>
        </front>
      </reference>

      <reference anchor="MP-TCP" target="https://datatracker.ietf.org/wg/mptcp/">
        <front>
          <title>Multipath TCP Working Group Home Page</title>
          <author>
            <organization/>
          </author>
        </front>
      </reference>

      <reference anchor="MOPS-109-Min" target="https://datatracker.ietf.org/meeting/109/materials/minutes-109-mops-00">
        <front>
          <title>Media Operations Working Group - IETF 109 Minutes</title>
          <author>
            <organization/>
          </author>
          <date year="2020" month="November"/>
        </front>
      </reference>

      <reference anchor="model-t" target="https://www.iab.org/mailman/listinfo/model-t">
        <front>
          <title>Model-t -- Discussions of changes in Internet deployment patterns and Wes Eddy, who provided review comments their impact on this document as a "work in process".</t>
      <t>Mallory Knodel reviewed this document for the Internet Research Steering Group, and provided many helpful suggestions.</t>
      <t>David Oran also provided helpful comments and text suggestions on this document during Internet Research Steering Group balloting. In particular, <xref target="Futures" format="default"/> reflects his review.</t>
      <t>Benjamin Kaduk and Rob Wilton provided helpful comments during Internet Engineering Steering threat model</title>
          <author>
            <organization/>
          </author>
        </front>
        <refcontent>model-t mailing list</refcontent>
      </reference>

      <reference anchor="NANOG-35" target="https://archive.nanog.org/meetings/nanog35/agenda">
        <front>
          <title>NANOG 35 Agenda</title>
          <author>
            <organization/>
          </author>
          <date year="2005" month="October"/>
        </front>
        <refcontent>North American Network Operators' Group conflict review.</t>
      <t>Special thanks to Adrian Farrel for helping Spencer navigate the twisty little passages of Flow Specs and Filter Specs in IntServ, RSVP, MPLS, and BGP. They are all alike, except when they are different <xref target="Colossal-Cave" format="default"/>.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Informative References</name> (NANOG)</refcontent>
      </reference>

      <reference anchor="I-D.irtf-panrg-questions" target="http://www.ietf.org/internet-drafts/draft-irtf-panrg-questions-08.txt"> anchor="NSIS-CHARTER-2001" target="https://datatracker.ietf.org/doc/charter-ietf-nsis/">
        <front>
          <title>Current Open Questions in Path Aware Networking</title>
          <seriesInfo name="Internet-Draft" value="draft-irtf-panrg-questions-08"/>
          <author initials="B" surname="Trammell" fullname="Brian Trammell">
          <title>Next Steps In Signaling Working Group Charter</title>
          <author>
            <organization/>
          </author>
          <date month="December" day="23" year="2020"/>
          <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 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.  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 year="2011" month="March"/>
        </front>
      </reference>

      <reference anchor="PANRG-99" target="https://datatracker.ietf.org/meeting/99/session/panrg">
        <front>
          <title>Path Aware Networking proposed Research Group (PANRG), and has been published to snapshot current thinking in this space.</t>
          </abstract> - IETF 99</title>
          <author>
            <organization/>
          </author>
          <date year="2017" month="July"/>
        </front>
      </reference>

      <reference anchor="I-D.irtf-panrg-path-properties" target="http://www.ietf.org/internet-drafts/draft-irtf-panrg-path-properties-01.txt"> anchor="PANRG-103-Min" target="https://datatracker.ietf.org/doc/minutes-103-panrg/">
        <front>
          <title>A Vocabulary of Path Properties</title>
          <seriesInfo name="Internet-Draft" value="draft-irtf-panrg-path-properties-01"/>
          <author initials="T" surname="Enghardt" fullname="Theresa Enghardt">
            <organization/>
          </author>
          <author initials="C" surname="Krahenbuhl" fullname="Cyrill Krahenbuhl">
          <title>Path Aware Networking Research Group - IETF 103 Minutes</title>
          <author>
            <organization/>
          </author>
          <date month="September" day="7" year="2020"/>
          <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 hosts.  This document defines and categorizes path properties. Furthermore, the document specifies several path properties which might be useful to hosts or other entities, e.g., for selecting between paths or for invoking some of the provided services.</t>
          </abstract> year="2018" month="November"/>
        </front>
      </reference>

      <reference anchor="I-D.ietf-tsvwg-intserv-multiple-tspec" target="http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-02.txt"> anchor="PANRG-105-Min" target="https://datatracker.ietf.org/doc/minutes-105-panrg/">
        <front>
          <title>Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-intserv-multiple-tspec-02"/>
          <author initials="J" surname="Polk" fullname="James Polk">
          <title>Path Aware Networking Research Group - IETF 105 Minutes</title>
          <author>
            <organization/>
          </author>
          <author initials="S" surname="Dhesikan" fullname="Subha Dhesikan">
          <date year="2019" month="July"/>
        </front>
      </reference>

      <reference anchor="PANRG-106-Min" target="https://datatracker.ietf.org/doc/minutes-106-panrg/">
        <front>
          <title>Path Aware Networking Research Group - IETF 106 Minutes</title>
          <author>
            <organization/>
          </author>
          <date month="February" day="25" year="2013"/>
          <abstract>
            <t>This document defines extensions to Integrated Services (IntServ) allowing  multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip.</t>
          </abstract> year="2019" month="November"/>
        </front>
      </reference>

      <reference anchor="I-D.arkko-arch-internet-threat-model" target="http://www.ietf.org/internet-drafts/draft-arkko-arch-internet-threat-model-01.txt"> anchor="PANRG-110" target="https://datatracker.ietf.org/meeting/110/session/panrg">
        <front>
          <title>Changes in the Internet Threat Model</title>
          <seriesInfo name="Internet-Draft" value="draft-arkko-arch-internet-threat-model-01"/>
          <author initials="J" surname="Arkko" fullname="Jari Arkko">
          <title>Path Aware Networking Research Group - IETF 110</title>
          <author>
            <organization/>
          </author>
          <date month="July" day="8" year="2019"/>
          <abstract>
            <t>Communications security has been at the center year="2021" month="March"/>
        </front>
      </reference>

      <reference anchor="PATH-Decade" target="https://datatracker.ietf.org/doc/slides-99-panrg-a-decade-of-path-awareness/">
        <front>
          <title>A Decade of many security improvements in the Internet.  The goal has been to ensure that communications are protected against outside observers and attackers.  This memo suggests that the existing threat model, while important and still valid, is no longer alone sufficient Path Awareness</title>
          <author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure">
            <organization/>
          </author>
          <date year="2017" month="July"/>
        </front>
      </reference>

      <reference anchor="PANRG" target="https://irtf.org/panrg">
        <front>
          <title>Path Aware Networking Research Group Home Page</title>
          <author>
            <organization/>
          </author>
        </front>
      </reference>

      <reference anchor="QS-SAT" target="https://dl.acm.org/citation.cfm?id=3160304.3160305">
        <front>
          <title>Using Quick-Start to cater for the pressing security issues enhance TCP-friendly rate control performance in the Internet.  For instance, it is also necessary to protect systems against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of the users.  While such protection is difficult, there are some measures that can be taken.  It is particularly important to ensure that as we continue to develop Internet technology, non-communications security related threats are properly understood.  While the consideration of these issues is relatively new in the IETF, this memo provides some initial ideas about potential broader threat models to consider when designing protocols for the Internet or when trying to defend against pervasive monitoring.  Further down the road, updated threat models could result in changes in RFC 3552 (guidelines for writing security considerations) and RFC 7258 (pervasive monitoring), to include proper consideration of non-communications security threats.  It may also be necessary to have dedicated guidance on how systems design and architecture affects security.</t>
          </abstract> bidirectional satellite networks</title>
          <author initials="R." surname="Secchi" fullname="Raffaello Secchi">
            <organization/>
          </author>
          <author initials="A." surname="Sathiaseelan" fullname="Arjuna Sathiaseelan">
            <organization/>
          </author>
          <author initials="F." surname="Potortì" fullname="Francesco Potortì">
            <organization/>
          </author>
          <author initials="A." surname="Gotta" fullname="Alberto Gotta">
            <organization/>
          </author>
          <author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
            <organization/>
          </author>
          <date month="May" year="2009"/>
        </front>
      <seriesInfo name="DOI" value="10.1002/sat.929"/>
      </reference>

      <reference anchor="I-D.farrell-etm" target="http://www.ietf.org/internet-drafts/draft-farrell-etm-03.txt"> anchor="SAAG-105-Min" target="https://datatracker.ietf.org/meeting/105/materials/minutes-105-saag-00">
        <front>
          <title>We're gonna need a bigger threat model</title>
          <seriesInfo name="Internet-Draft" value="draft-farrell-etm-03"/>
          <author initials="S" surname="Farrell" fullname="Stephen Farrell">
          <title>Security Area Open Meeting - IETF 105 Minutes</title>
          <author>
            <organization/>
          </author>
          <date month="July" day="6" year="2019"/>
          <abstract>
            <t>We argue that an expanded threat model is needed for Internet protocol development as protocol endpoints can no longer be considered to be generally trustworthy for any general definition of "trustworthy."</t>
          </abstract> year="2019" month="July"/>
        </front>
      </reference>

      <reference anchor="I-D.ietf-quic-transport" target="http://www.ietf.org/internet-drafts/draft-ietf-quic-transport-34.txt"> anchor="SAF07" target="https://dl.acm.org/doi/10.1016/j.comnet.2006.11.006">
        <front>
          <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34"/>
          <title>Determining an appropriate sending rate over an underutilized network path</title>
          <author initials="J" surname="Iyengar" fullname="Jana Iyengar"> initials="P." surname="Sarolahti" fullname="Pasi Sarolahti">
            <organization/>
          </author>
          <author initials="M" surname="Thomson" fullname="Martin Thomson"> initials="M." surname="Allman" fullname="Mark Allman">
            <organization/>
          </author>
          <author initials="S." surname="Floyd" fullname="Sally Floyd">
            <organization/>
          </author>
          <date month="January" day="14" year="2021"/>
          <abstract>
            <t>This document defines the core year="2007" month="May"/>
        </front>
        <seriesInfo name="DOI" value="10.1016/j.comnet.2006.11.006"/>
        <refcontent>Computer Networks: The International Journal 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, Computer 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.  DO NOT DEPLOY THIS VERSION OF QUIC  DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC.  This version is still a work in progress.  For trial deployments, please use earlier versions.  Note to Readers  Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic  Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-transport.</t>
          </abstract>
        </front> Telecommunications Networking, Volume 51, Number 7</refcontent>
      </reference>

      <reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791"> anchor="SallyFloyd" target="https://www.icir.org/floyd/ecn.html">
        <front>
          <title>Internet Protocol</title>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="STD" value="5"/>
          <title>ECN (Explicit Congestion Notification) in TCP/IP</title>
          <author initials="J." surname="Postel" fullname="J. Postel"> initials="S." surname="Floyd" fullname="Sally Floyd">
            <organization/>
          </author>
          <date year="1981" month="September"/> month="June" year="2009"/>
        </front>
      </reference>

      <reference anchor="RFC0792" target="https://www.rfc-editor.org/info/rfc792"> anchor="Sch11">
        <front>
          <title>Internet
          <title>Fast Startup Internet Congestion Control Message Protocol</title>
          <seriesInfo name="DOI" value="10.17487/RFC0792"/>
          <seriesInfo name="RFC" value="792"/>
          <seriesInfo name="STD" value="5"/> for Broadband Interactive Applications</title>
          <author initials="J." surname="Postel" fullname="J. Postel"> initials="M." surname="Scharf" fullname="M. Scharf">
            <organization/>
          </author>
          <date year="1981" month="September"/> year="2011" month="April"/>
        </front>
       <refcontent>Ph.D. Thesis, University of Stuttgart</refcontent>
      </reference>

      <reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793"> anchor="Shim6-35" target="https://www.youtube.com/watch?v=ji6Y_rYHAQs">
        <front>
          <title>Transmission Control Protocol</title>
          <seriesInfo name="DOI" value="10.17487/RFC0793"/>
          <seriesInfo name="RFC" value="793"/>
          <seriesInfo name="STD" value="7"/>
          <title>IAB IPv6 Multihoming Panel at NANOG 35</title>
          <author initials="J." surname="Postel" fullname="J. Postel"> initials="D." surname="Meyer" fullname="David Meyer">
            <organization/>
          </author>
          <date year="1981" month="September"/>
        </front>
      </reference>
      <reference anchor="RFC1016" target="https://www.rfc-editor.org/info/rfc1016">
        <front>
          <title>Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)</title>
          <seriesInfo name="DOI" value="10.17487/RFC1016"/>
          <seriesInfo name="RFC" value="1016"/>
          <author initials="W." surname="Prue" fullname="W. Prue"> initials="G." surname="Huston" fullname="Geoff Huston">
            <organization/>
          </author>
          <author initials="J." surname="Postel" fullname="J. Postel"> surname="Schiller" fullname="Jason Schiller">
            <organization/>
          </author>
          <author initials="V." surname="Gill" fullname="Vijay Gill">
            <organization/>
          </author>
          <date year="1987" month="July"/>
          <abstract>
            <t>The memo is intended to explore the issue of what a host could do with a source quench.  The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host.  This is a "crazy idea paper" and discussion is essential.</t>
          </abstract> year="2005" month="October"/>
        </front>
        <refcontent>North American Network Operators' Group (NANOG)</refcontent>
      </reference>

      <reference anchor="RFC1122" target="https://www.rfc-editor.org/info/rfc1122"> anchor="TRIGTRAN-55" target="https://www.ietf.org/proceedings/55/239.htm">
        <front>
          <title>Requirements
          <title>Triggers for Internet Hosts - Communication Layers</title>
          <seriesInfo name="DOI" value="10.17487/RFC1122"/>
          <seriesInfo name="RFC" value="1122"/>
          <seriesInfo name="STD" value="3"/>
          <author initials="R." surname="Braden" fullname="R. Braden" role="editor"> Transport BOF at IETF 55</title>
          <author>
            <organization/>
          </author>
          <date year="1989" month="October"/>
          <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> year="2002" month="November"/>
        </front>
      </reference>

      <reference anchor="RFC1190" target="https://www.rfc-editor.org/info/rfc1190"> anchor="TRIGTRAN-56" target="https://www.ietf.org/proceedings/56/251.htm">
        <front>
          <title>Experimental Internet Stream Protocol: Version 2 (ST-II)</title>
          <seriesInfo name="DOI" value="10.17487/RFC1190"/>
          <seriesInfo name="RFC" value="1190"/>
          <author initials="C." surname="Topolcic" fullname="C. Topolcic">
          <title>Triggers for Transport BOF at IETF 56</title>
          <author>
            <organization/>
          </author>
          <date year="1990" month="October"/>
          <abstract>
            <t>This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements.  This is a Limited-Use Experimental Protocol.  Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.</t>
          </abstract> year="2003" month="March"/>
        </front>
      </reference>

      <reference anchor="RFC1633" target="https://www.rfc-editor.org/info/rfc1633"> anchor="vista-impl" target="https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld1.htm">
        <front>
          <title>Integrated Services in the Internet Architecture: an Overview</title>
          <seriesInfo name="DOI" value="10.17487/RFC1633"/>
          <seriesInfo name="RFC" value="1633"/>
          <title>Implementation Report on Experiences with Various TCP RFCs</title>
          <author initials="R." surname="Braden" fullname="R. Braden"> initials="M." surname="Sridharan" fullname="Murari Sridharan">
            <organization/>
          </author>
          <author initials="D." surname="Clark" fullname="D. Clark"> surname="Bansal" fullname="Deepak Bansal">
            <organization/>
          </author>
          <author initials="S." surname="Shenker" fullname="S. Shenker"> initials="D." surname="Thaler" fullname="Dave Thaler">
            <organization/>
          </author>
          <date year="1994" month="June"/>
          <abstract>
            <t>This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t>
          </abstract> year="2007" month="March"/>
        </front>
      </reference>
      <reference anchor="RFC1809" target="https://www.rfc-editor.org/info/rfc1809">
        <front>
          <title>Using the Flow Label Field in IPv6</title>
          <seriesInfo name="DOI" value="10.17487/RFC1809"/>
          <seriesInfo name="RFC" value="1809"/>
          <author initials="C." surname="Partridge" fullname="C. Partridge">
            <organization/>
          </author>
          <date year="1995" month="June"/>
          <abstract>
            <t>The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6.  This memo provides information
    </references>
    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Initial material for the Internet community.  This memo does not specify an Internet standard of any kind.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC1819" target="https://www.rfc-editor.org/info/rfc1819">
        <front>
          <title>Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+</title>
          <seriesInfo name="DOI" value="10.17487/RFC1819"/>
          <seriesInfo name="RFC" value="1819"/>
          <author initials="L." surname="Delgrossi" fullname="L. Delgrossi" role="editor">
            <organization/>
          </author>
          <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
            <organization/>
          </author>
          <date year="1995" month="August"/>
          <abstract>
            <t>This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2).  This memo defines an Experimental Protocol <xref target="ST2" format="default"/> on ST2 was provided by <contact fullname="Gorry Fairhurst"/>.</t>
      <t>Initial material for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC1887" target="https://www.rfc-editor.org/info/rfc1887">
        <front>
          <title>An Architecture <xref target="IntServ" format="default"/> on IntServ was provided by <contact fullname="Ron Bonica"/>.</t>
      <t>Initial material for IPv6 Unicast Address Allocation</title>
          <seriesInfo name="DOI" value="10.17487/RFC1887"/>
          <seriesInfo name="RFC" value="1887"/>
          <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
            <organization/>
          </author>
          <author initials="T." surname="Li" fullname="T. Li" role="editor">
            <organization/>
          </author>
          <date year="1995" month="December"/>
          <abstract>
            <t>This document provides an architecture <xref target="Quick-Start" format="default"/> on Quick-Start TCP was provided by <contact fullname="Michael Scharf"/>, who also provided suggestions to improve this section after it was edited.</t>
      <t>Initial material for <xref target="Source-Quench" format="default"/> on ICMP Source Quench was provided by <contact fullname="Gorry Fairhurst"/>.</t>
      <t>Initial material for <xref target="TRIGTRAN" format="default"/> on Triggers for Transport (TRIGTRAN) was provided by <contact fullname="Spencer Dawkins"/>.</t>
      <t><xref target="Shim6" format="default"/> on Shim6 builds on initial material describing obstacles, which was provided by <contact fullname="Erik Nordmark"/>, with background added by <contact fullname="Spencer Dawkins"/>.</t>
      <t>Initial material for <xref target="NSIS" format="default"/> on Next Steps in Signaling (NSIS) was provided by <contact fullname="Roland Bless"/> and <contact fullname="Martin Stiemerling"/>.</t>
      <t>Initial material for allocating <xref target="FL" format="default"/> on IPv6 [1] unicast addresses Flow Labels was provided by <contact fullname="Gorry Fairhurst"/>.</t>
      <t>Initial material for <xref target="ecn" format="default"/> on Explicit Congestion Notification was provided by <contact fullname="Spencer Dawkins"/>.</t>
      <t>Our thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="Bob Briscoe"/>, <contact fullname="C.M. Heard"/>, <contact fullname="David Black"/>, <contact fullname="Eric Kinnear"/>, <contact fullname="Erik Auerswald"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Jake Holland"/>, <contact fullname="
Joe Touch"/>, <contact fullname="Joeri de Ruiter"/>, <contact fullname="Kireeti Kompella"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Randy Presuhn"/>,
<contact fullname="Roland Bless"/>, <contact fullname="Ruediger Geib"/>, <contact fullname="Theresa Enghardt"/>, and <contact fullname="Wes Eddy"/>, who provided review comments on this document as a "work in the Internet.  This process".</t>
      <t><contact fullname="Mallory Knodel"/> reviewed this document provides information for the Internet community.  This memo does not specify an Research Steering Group and provided many helpful suggestions.</t>
      <t><contact fullname="David Oran"/> also provided helpful comments and text suggestions on this document during Internet standard of any kind.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2001" target="https://www.rfc-editor.org/info/rfc2001">
        <front>
          <title>TCP Slow Start, Congestion Avoidance, Fast Retransmit, Research Steering Group balloting. In particular, <xref target="Futures" format="default"/> reflects his review.</t>
      <t><contact fullname="Benjamin Kaduk"/>, <contact fullname="Martin Duke"/>,
 and Fast Recovery Algorithms</title>
          <seriesInfo name="DOI" value="10.17487/RFC2001"/>
          <seriesInfo name="RFC" value="2001"/>
          <author initials="W." surname="Stevens" fullname="W. Stevens">
            <organization/>
          </author>
          <date year="1997" month="January"/>
          <abstract>
            <t>Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as <contact fullname="Rob Wilton"/> provided helpful comments during Internet standards: slow start, congestion avoidance, fast retransmit, Engineering Steering Group conflict review.</t>
      <t>Special thanks to <contact fullname="Adrian Farrel"/> for helping <contact fullname="Spencer"/> navigate the twisty little passages of Flow Specs and fast recovery.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2205" target="https://www.rfc-editor.org/info/rfc2205">
        <front>
          <title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification</title>
          <seriesInfo name="DOI" value="10.17487/RFC2205"/>
          <seriesInfo name="RFC" value="2205"/>
          <author initials="R." surname="Braden" fullname="R. Braden" role="editor">
            <organization/>
          </author>
          <author initials="L." surname="Zhang" fullname="L. Zhang">
            <organization/>
          </author>
          <author initials="S." surname="Berson" fullname="S. Berson">
            <organization/>
          </author>
          <author initials="S." surname="Herzog" fullname="S. Herzog">
            <organization/>
          </author>
          <author initials="S." surname="Jamin" fullname="S. Jamin">
            <organization/>
          </author>
          <date year="1997" month="September"/>
          <abstract>
            <t>This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet.  RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2210" target="https://www.rfc-editor.org/info/rfc2210">
        <front>
          <title>The Use of RSVP with IETF Integrated Services</title>
          <seriesInfo name="DOI" value="10.17487/RFC2210"/>
          <seriesInfo name="RFC" value="2210"/>
          <author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
            <organization/>
          </author>
          <date year="1997" month="September"/>
          <abstract>
            <t>This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2211" target="https://www.rfc-editor.org/info/rfc2211">
        <front>
          <title>Specification of the Controlled-Load Network Element Service</title>
          <seriesInfo name="DOI" value="10.17487/RFC2211"/>
          <seriesInfo name="RFC" value="2211"/>
          <author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
            <organization/>
          </author>
          <date year="1997" month="September"/>
          <abstract>
            <t>This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2212" target="https://www.rfc-editor.org/info/rfc2212">
        <front>
          <title>Specification of Guaranteed Quality of Service</title>
          <seriesInfo name="DOI" value="10.17487/RFC2212"/>
          <seriesInfo name="RFC" value="2212"/>
          <author initials="S." surname="Shenker" fullname="S. Shenker">
            <organization/>
          </author>
          <author initials="C." surname="Partridge" fullname="C. Partridge">
            <organization/>
          </author>
          <author initials="R." surname="Guerin" fullname="R. Guerin">
            <organization/>
          </author>
          <date year="1997" month="September"/>
          <abstract>
            <t>This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2215" target="https://www.rfc-editor.org/info/rfc2215">
        <front>
          <title>General Characterization Parameters for Integrated Service Network Elements</title>
          <seriesInfo name="DOI" value="10.17487/RFC2215"/>
          <seriesInfo name="RFC" value="2215"/>
          <author initials="S." surname="Shenker" fullname="S. Shenker">
            <organization/>
          </author>
          <author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
            <organization/>
          </author>
          <date year="1997" month="September"/>
          <abstract>
            <t>This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2309" target="https://www.rfc-editor.org/info/rfc2309">
        <front>
          <title>Recommendations on Queue Management and Congestion Avoidance in the Internet</title>
          <seriesInfo name="DOI" value="10.17487/RFC2309"/>
          <seriesInfo name="RFC" value="2309"/>
          <author initials="B." surname="Braden" fullname="B. Braden">
            <organization/>
          </author>
          <author initials="D." surname="Clark" fullname="D. Clark">
            <organization/>
          </author>
          <author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
            <organization/>
          </author>
          <author initials="B." surname="Davie" fullname="B. Davie">
            <organization/>
          </author>
          <author initials="S." surname="Deering" fullname="S. Deering">
            <organization/>
          </author>
          <author initials="D." surname="Estrin" fullname="D. Estrin">
            <organization/>
          </author>
          <author initials="S." surname="Floyd" fullname="S. Floyd">
            <organization/>
          </author>
          <author initials="V." surname="Jacobson" fullname="V. Jacobson">
            <organization/>
          </author>
          <author initials="G." surname="Minshall" fullname="G. Minshall">
            <organization/>
          </author>
          <author initials="C." surname="Partridge" fullname="C. Partridge">
            <organization/>
          </author>
          <author initials="L." surname="Peterson" fullname="L. Peterson">
            <organization/>
          </author>
          <author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
            <organization/>
          </author>
          <author initials="S." surname="Shenker" fullname="S. Shenker">
            <organization/>
          </author>
          <author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
            <organization/>
          </author>
          <author initials="L." surname="Zhang" fullname="L. Zhang">
            <organization/>
          </author>
          <date year="1998" month="April"/>
          <abstract>
            <t>This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.  It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet.  It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2481" target="https://www.rfc-editor.org/info/rfc2481">
        <front>
          <title>A Proposal to add Explicit Congestion Notification (ECN) to IP</title>
          <seriesInfo name="DOI" value="10.17487/RFC2481"/>
          <seriesInfo name="RFC" value="2481"/>
          <author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
            <organization/>
          </author>
          <author initials="S." surname="Floyd" fullname="S. Floyd">
            <organization/>
          </author>
          <date year="1999" month="January"/>
          <abstract>
            <t>This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP.  This memo defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2460">
        <front>
          <title>Internet Protocol, Version 6 (IPv6) Specification</title>
          <seriesInfo name="DOI" value="10.17487/RFC2460"/>
          <seriesInfo name="RFC" value="2460"/>
          <author initials="S." surname="Deering" fullname="S. Deering">
            <organization/>
          </author>
          <author initials="R." surname="Hinden" fullname="R. Hinden">
            <organization/>
          </author>
          <date year="1998" month="December"/>
          <abstract>
            <t>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC2475" target="https://www.rfc-editor.org/info/rfc2475">
        <front>
          <title>An Architecture for Differentiated Services</title>
          <seriesInfo name="DOI" value="10.17487/RFC2475"/>
          <seriesInfo name="RFC" value="2475"/>
          <author initials="S." surname="Blake" fullname="S. Blake">
            <organization/>
          </author>
          <author initials="D." surname="Black" fullname="D. Black">
            <organization/>
          </author>
          <author initials="M." surname="Carlson" fullname="M. Carlson">
            <organization/>
          </author>
          <author initials="E." surname="Davies" fullname="E. Davies">
            <organization/>
          </author>
          <author initials="Z." surname="Wang" fullname="Z. Wang">
            <organization/>
          </author>
          <author initials="W." surname="Weiss" fullname="W. Weiss">
            <organization/>
          </author>
          <date year="1998" month="December"/>
          <abstract>
            <t>This document defines an architecture for implementing scalable service differentiation in the Internet.  This memo provides information for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168">
        <front>
          <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
          <seriesInfo name="DOI" value="10.17487/RFC3168"/>
          <seriesInfo name="RFC" value="3168"/>
          <author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
            <organization/>
          </author>
          <author initials="S." surname="Floyd" fullname="S. Floyd">
            <organization/>
          </author>
          <author initials="D." surname="Black" fullname="D. Black">
            <organization/>
          </author>
          <date year="2001" month="September"/>
          <abstract>
            <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC3697" target="https://www.rfc-editor.org/info/rfc3697">
        <front>
          <title>IPv6 Flow Label Specification</title>
          <seriesInfo name="DOI" value="10.17487/RFC3697"/>
          <seriesInfo name="RFC" value="3697"/>
          <author initials="J." surname="Rajahalme" fullname="J. Rajahalme">
            <organization/>
          </author>
          <author initials="A." surname="Conta" fullname="A. Conta">
            <organization/>
          </author>
          <author initials="B." surname="Carpenter" fullname="B. Carpenter">
            <organization/>
          </author>
          <author initials="S." surname="Deering" fullname="S. Deering">
            <organization/>
          </author>
          <date year="2004" month="March"/>
          <abstract>
            <t>This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.  Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.  The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC4094" target="https://www.rfc-editor.org/info/rfc4094">
        <front>
          <title>Analysis of Existing Quality-of-Service Signaling Protocols</title>
          <seriesInfo name="DOI" value="10.17487/RFC4094"/>
          <seriesInfo name="RFC" value="4094"/>
          <author initials="J." surname="Manner" fullname="J. Manner">
            <organization/>
          </author>
          <author initials="X." surname="Fu" fullname="X. Fu">
            <organization/>
          </author>
          <date year="2005" month="May"/>
          <abstract>
            <t>This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network.  The goal here is to learn from them and to avoid common misconceptions.  Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. This memo provides information for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC4443" target="https://www.rfc-editor.org/info/rfc4443">
        <front>
          <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
          <seriesInfo name="DOI" value="10.17487/RFC4443"/>
          <seriesInfo name="RFC" value="4443"/>
          <seriesInfo name="STD" value="89"/>
          <author initials="A." surname="Conta" fullname="A. Conta">
            <organization/>
          </author>
          <author initials="S." surname="Deering" fullname="S. Deering">
            <organization/>
          </author>
          <author initials="M." surname="Gupta" fullname="M. Gupta" role="editor">
            <organization/>
          </author>
          <date year="2006" month="March"/>
          <abstract>
            <t>This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol).  ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6).  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC4782" target="https://www.rfc-editor.org/info/rfc4782">
        <front>
          <title>Quick-Start for TCP and IP</title>
          <seriesInfo name="DOI" value="10.17487/RFC4782"/>
          <seriesInfo name="RFC" value="4782"/>
          <author initials="S." surname="Floyd" fullname="S. Floyd">
            <organization/>
          </author>
          <author initials="M." surname="Allman" fullname="M. Allman">
            <organization/>
          </author>
          <author initials="A." surname="Jain" fullname="A. Jain">
            <organization/>
          </author>
          <author initials="P." surname="Sarolahti" fullname="P. Sarolahti">
            <organization/>
          </author>
          <date year="2007" month="January"/>
          <abstract>
            <t>This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period).  While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP.  Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.</t>
            <t>This document describes many paths where Quick-Start Requests would not be approved.  These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start.  These paths also include paths with routers or middleboxes that drop packets containing IP options.  Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks.  This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path.  As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.  This memo defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5082" target="https://www.rfc-editor.org/info/rfc5082">
        <front>
          <title>The Generalized TTL Security Mechanism (GTSM)</title>
          <seriesInfo name="DOI" value="10.17487/RFC5082"/>
          <seriesInfo name="RFC" value="5082"/>
          <author initials="V." surname="Gill" fullname="V. Gill">
            <organization/>
          </author>
          <author initials="J." surname="Heasley" fullname="J. Heasley">
            <organization/>
          </author>
          <author initials="D." surname="Meyer" fullname="D. Meyer">
            <organization/>
          </author>
          <author initials="P." surname="Savola" fullname="P. Savola" role="editor">
            <organization/>
          </author>
          <author initials="C." surname="Pignataro" fullname="C. Pignataro">
            <organization/>
          </author>
          <date year="2007" month="October"/>
          <abstract>
            <t>The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols.  This document generalizes this technique.  This document obsoletes Experimental RFC 3682.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5218" target="https://www.rfc-editor.org/info/rfc5218">
        <front>
          <title>What Makes for a Successful Protocol?</title>
          <seriesInfo name="DOI" value="10.17487/RFC5218"/>
          <seriesInfo name="RFC" value="5218"/>
          <author initials="D." surname="Thaler" fullname="D. Thaler">
            <organization/>
          </author>
          <author initials="B." surname="Aboba" fullname="B. Aboba">
            <organization/>
          </author>
          <date year="2008" month="July"/>
          <abstract>
            <t>The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success.  It is hoped that these observations can serve as guidance for future protocol work.  This memo  provides information for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5533" target="https://www.rfc-editor.org/info/rfc5533">
        <front>
          <title>Shim6: Level 3 Multihoming Shim Protocol for IPv6</title>
          <seriesInfo name="DOI" value="10.17487/RFC5533"/>
          <seriesInfo name="RFC" value="5533"/>
          <author initials="E." surname="Nordmark" fullname="E. Nordmark">
            <organization/>
          </author>
          <author initials="M." surname="Bagnulo" fullname="M. Bagnulo">
            <organization/>
          </author>
          <date year="2009" month="June"/>
          <abstract>
            <t>This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table.  The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5575" target="https://www.rfc-editor.org/info/rfc5575">
        <front>
          <title>Dissemination of Flow Specification Rules</title>
          <seriesInfo name="DOI" value="10.17487/RFC5575"/>
          <seriesInfo name="RFC" value="5575"/>
          <author initials="P." surname="Marques" fullname="P. Marques">
            <organization/>
          </author>
          <author initials="N." surname="Sheth" fullname="N. Sheth">
            <organization/>
          </author>
          <author initials="R." surname="Raszuk" fullname="R. Raszuk">
            <organization/>
          </author>
          <author initials="B." surname="Greene" fullname="B. Greene">
            <organization/>
          </author>
          <author initials="J." surname="Mauch" fullname="J. Mauch">
            <organization/>
          </author>
          <author initials="D." surname="McPherson" fullname="D. McPherson">
            <organization/>
          </author>
          <date year="2009" month="August"/>
          <abstract>
            <t>This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications.  This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</t>
            <t>Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.</t>
            <t>The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc5681">
        <front>
          <title>TCP Congestion Control</title>
          <seriesInfo name="DOI" value="10.17487/RFC5681"/>
          <seriesInfo name="RFC" value="5681"/>
          <author initials="M." surname="Allman" fullname="M. Allman">
            <organization/>
          </author>
          <author initials="V." surname="Paxson" fullname="V. Paxson">
            <organization/>
          </author>
          <author initials="E." surname="Blanton" fullname="E. Blanton">
            <organization/>
          </author>
          <date year="2009" month="September"/>
          <abstract>
            <t>This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.  This document obsoletes RFC 2581.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5971" target="https://www.rfc-editor.org/info/rfc5971">
        <front>
          <title>GIST: General Internet Signalling Transport</title>
          <seriesInfo name="DOI" value="10.17487/RFC5971"/>
          <seriesInfo name="RFC" value="5971"/>
          <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
            <organization/>
          </author>
          <author initials="R." surname="Hancock" fullname="R. Hancock">
            <organization/>
          </author>
          <date year="2010" month="October"/>
          <abstract>
            <t>This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network.  The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications.  GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path.  The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework.   This document defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5973" target="https://www.rfc-editor.org/info/rfc5973">
        <front>
          <title>NAT/Firewall NSIS Signaling Layer Protocol (NSLP)</title>
          <seriesInfo name="DOI" value="10.17487/RFC5973"/>
          <seriesInfo name="RFC" value="5973"/>
          <author initials="M." surname="Stiemerling" fullname="M. Stiemerling">
            <organization/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
            <organization/>
          </author>
          <author initials="C." surname="Aoun" fullname="C. Aoun">
            <organization/>
          </author>
          <author initials="E." surname="Davies" fullname="E. Davies">
            <organization/>
          </author>
          <date year="2010" month="October"/>
          <abstract>
            <t>This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls.  This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows.  For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic.  The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group.  The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.  This document defines an Experimental  Protocol for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5974" target="https://www.rfc-editor.org/info/rfc5974">
        <front>
          <title>NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling</title>
          <seriesInfo name="DOI" value="10.17487/RFC5974"/>
          <seriesInfo name="RFC" value="5974"/>
          <author initials="J." surname="Manner" fullname="J. Manner">
            <organization/>
          </author>
          <author initials="G." surname="Karagiannis" fullname="G. Karagiannis">
            <organization/>
          </author>
          <author initials="A." surname="McDonald" fullname="A. McDonald">
            <organization/>
          </author>
          <date year="2010" month="October"/>
          <abstract>
            <t>This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS.  Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it.  The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models.  It is simplified by the elimination of support for multicast flows.  This specification explains the overall protocol approach, describes the design decisions made, and provides examples.  It specifies object, message formats, and processing rules.  This document defines an  Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5981" target="https://www.rfc-editor.org/info/rfc5981">
        <front>
          <title>Authorization for NSIS Signaling Layer Protocols</title>
          <seriesInfo name="DOI" value="10.17487/RFC5981"/>
          <seriesInfo name="RFC" value="5981"/>
          <author initials="J." surname="Manner" fullname="J. Manner">
            <organization/>
          </author>
          <author initials="M." surname="Stiemerling" fullname="M. Stiemerling">
            <organization/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
            <organization/>
          </author>
          <author initials="R." surname="Bless" fullname="R. Bless" role="editor">
            <organization/>
          </author>
          <date year="2011" month="February"/>
          <abstract>
            <t>Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization.  Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources.  This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols.  The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. This document defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC6294" target="https://www.rfc-editor.org/info/rfc6294">
        <front>
          <title>Survey of Proposed Use Cases for the IPv6 Flow Label</title>
          <seriesInfo name="DOI" value="10.17487/RFC6294"/>
          <seriesInfo name="RFC" value="6294"/>
          <author initials="Q." surname="Hu" fullname="Q. Hu">
            <organization/>
          </author>
          <author initials="B." surname="Carpenter" fullname="B. Carpenter">
            <organization/>
          </author>
          <date year="2011" month="June"/>
          <abstract>
            <t>The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice.  This paper describes the flow label standard and discusses the implementation issues that it raises.  It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard.  Methods to address this problem are briefly reviewed.  We also question whether the standard should be revised.  This document  is not an Internet Standards Track specification; it is published for informational purposes.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC6398" target="https://www.rfc-editor.org/info/rfc6398">
        <front>
          <title>IP Router Alert Considerations and Usage</title>
          <seriesInfo name="DOI" value="10.17487/RFC6398"/>
          <seriesInfo name="RFC" value="6398"/>
          <seriesInfo name="BCP" value="168"/>
          <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur" role="editor">
            <organization/>
          </author>
          <date year="2011" month="October"/>
          <abstract>
            <t>The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet.  The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option.  This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  It also provides recommendations about protection approaches for service providers.  Finally, it provides brief guidelines for Router Alert implementation on routers.  This memo documents an Internet  Best Current Practice.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC6437" target="https://www.rfc-editor.org/info/rfc6437">
        <front>
          <title>IPv6 Flow Label Specification</title>
          <seriesInfo name="DOI" value="10.17487/RFC6437"/>
          <seriesInfo name="RFC" value="6437"/>
          <author initials="S." surname="Amante" fullname="S. Amante">
            <organization/>
          </author>
          <author initials="B." surname="Carpenter" fullname="B. Carpenter">
            <organization/>
          </author>
          <author initials="S." surname="Jiang" fullname="S. Jiang">
            <organization/>
          </author>
          <author initials="J." surname="Rajahalme" fullname="J. Rajahalme">
            <organization/>
          </author>
          <date year="2011" month="November"/>
          <abstract>
            <t>This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.  Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.</t>
            <t>The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC6438" target="https://www.rfc-editor.org/info/rfc6438">
        <front>
          <title>Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels</title>
          <seriesInfo name="DOI" value="10.17487/RFC6438"/>
          <seriesInfo name="RFC" value="6438"/>
          <author initials="B." surname="Carpenter" fullname="B. Carpenter">
            <organization/>
          </author>
          <author initials="S." surname="Amante" fullname="S. Amante">
            <organization/>
          </author>
          <date year="2011" month="November"/>
          <abstract>
            <t>The IPv6 flow label has certain restrictions on its use.  This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic.   [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC6633" target="https://www.rfc-editor.org/info/rfc6633">
        <front>
          <title>Deprecation of ICMP Source Quench Messages</title>
          <seriesInfo name="DOI" value="10.17487/RFC6633"/>
          <seriesInfo name="RFC" value="6633"/>
          <author initials="F." surname="Gont" fullname="F. Gont">
            <organization/>
          </author>
          <date year="2012" month="May"/>
          <abstract>
            <t>This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc6928">
        <front>
          <title>Increasing TCP's Initial Window</title>
          <seriesInfo name="DOI" value="10.17487/RFC6928"/>
          <seriesInfo name="RFC" value="6928"/>
          <author initials="J." surname="Chu" fullname="J. Chu">
            <organization/>
          </author>
          <author initials="N." surname="Dukkipati" fullname="N. Dukkipati">
            <organization/>
          </author>
          <author initials="Y." surname="Cheng" fullname="Y. Cheng">
            <organization/>
          </author>
          <author initials="M." surname="Mathis" fullname="M. Mathis">
            <organization/>
          </author>
          <date year="2013" month="April"/>
          <abstract>
            <t>This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected.  It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse.  The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7305" target="https://www.rfc-editor.org/info/rfc7305">
        <front>
          <title>Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7305"/>
          <seriesInfo name="RFC" value="7305"/>
          <author initials="E." surname="Lear" fullname="E. Lear" role="editor">
            <organization/>
          </author>
          <date year="2014" month="July"/>
          <abstract>
            <t>This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT).  The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK.  The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack).  This report summarizes contributions and discussions.  As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.</t>
            <t>Note that this document is a report on the proceedings of the workshop.  The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7418" target="https://www.rfc-editor.org/info/rfc7418">
        <front>
          <title>An IRTF Primer for IETF Participants</title>
          <seriesInfo name="DOI" value="10.17487/RFC7418"/>
          <seriesInfo name="RFC" value="7418"/>
          <author initials="S." surname="Dawkins" fullname="S. Dawkins" role="editor">
            <organization/>
          </author>
          <date year="2014" month="December"/>
          <abstract>
            <t>This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF).  This document emphasizes differences in expectations between the two organizations.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085">
        <front>
          <title>UDP Usage Guidelines</title>
          <seriesInfo name="DOI" value="10.17487/RFC8085"/>
          <seriesInfo name="RFC" value="8085"/>
          <seriesInfo name="BCP" value="145"/>
          <author initials="L." surname="Eggert" fullname="L. Eggert">
            <organization/>
          </author>
          <author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
            <organization/>
          </author>
          <author initials="G." surname="Shepherd" fullname="G. Shepherd">
            <organization/>
          </author>
          <date year="2017" month="March"/>
          <abstract>
            <t>The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.  This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP.  Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
            <t>Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic.  They may also need to implement additional mechanisms, depending on how they use UDP.</t>
            <t>Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t>
            <t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8170" target="https://www.rfc-editor.org/info/rfc8170">
        <front>
          <title>Planning for Protocol Adoption and Subsequent Transitions</title>
          <seriesInfo name="DOI" value="10.17487/RFC8170"/>
          <seriesInfo name="RFC" value="8170"/>
          <author initials="D." surname="Thaler" fullname="D. Thaler" role="editor">
            <organization/>
          </author>
          <date year="2017" month="May"/>
          <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>
      </reference>
      <reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8655">
        <front>
          <title>Deterministic Networking Architecture</title>
          <seriesInfo name="DOI" value="10.17487/RFC8655"/>
          <seriesInfo name="RFC" value="8655"/>
          <author initials="N." surname="Finn" fullname="N. Finn">
            <organization/>
          </author>
          <author initials="P." surname="Thubert" fullname="P. Thubert">
            <organization/>
          </author>
          <author initials="B." surname="Varga" fullname="B. Varga">
            <organization/>
          </author>
          <author initials="J." surname="Farkas" fullname="J. Farkas">
            <organization/>
          </author>
          <date year="2019" month="October"/>
          <abstract>
            <t>This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain.  Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path.  DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8793" target="https://www.rfc-editor.org/info/rfc8793">
        <front>
          <title>Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology</title>
          <seriesInfo name="DOI" value="10.17487/RFC8793"/>
          <seriesInfo name="RFC" value="8793"/>
          <author initials="B." surname="Wissingh" fullname="B. Wissingh">
            <organization/>
          </author>
          <author initials="C." surname="Wood" fullname="C. Wood">
            <organization/>
          </author>
          <author initials="A." surname="Afanasyev" fullname="A. Afanasyev">
            <organization/>
          </author>
          <author initials="L." surname="Zhang" fullname="L. Zhang">
            <organization/>
          </author>
          <author initials="D." surname="Oran" fullname="D. Oran">
            <organization/>
          </author>
          <author initials="C." surname="Tschudin" fullname="C. Tschudin">
            <organization/>
          </author>
          <date year="2020" month="June"/>
          <abstract>
            <t>Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="Colossal-Cave" target="https://en.wikipedia.org/wiki/Colossal_Cave_Adventure">
        <front>
          <title>Wikipedia Page for Colossal Cave Adventure</title>
          <author>
            <organization/>
          </author>
          <date year="2019" month="January"/>
        </front>
      </reference>
      <reference anchor="Conviva" target="https://www.conviva.com/datasheets/precision-delivery-intelligence/">
        <front>
          <title>Conviva Precision : Data Sheet</title>
          <author>
            <organization/>
          </author>
          <date year="2020" month="December"/>
        </front>
      </reference>
      <reference anchor="IEN-119" target="https://www.rfc-editor.org/ien/ien119.txt">
        <front>
          <title>ST - A Proposed Internet Stream Protocol</title>
          <author initials="J." surname="Forgie" fullname="James W. Forgie">
            <organization/>
          </author>
          <date year="1979" month="September"/>
        </front>
      </reference>
      <reference anchor="GREASE" target="https://tools.ietf.org/html/draft-iab-use-it-or-lose-it-00">
        <front>
          <title>Long-term Viability of Protocol Extension Mechanisms</title>
          <author initials="M." surname="Thomson" fullname="Martin Thomson">
            <organization/>
          </author>
          <date year="2019" month="July"/>
        </front>
      </reference>
      <reference anchor="ITAT" target="https://www.iab.org/activities/workshops/itat/">
        <front>
          <title>IAB Workshop on Internet Technology Adoption and Transition (ITAT)</title>
          <author>
            <organization/>
          </author>
          <date year="2013" month="December"/>
        </front>
      </reference>
      <reference anchor="MP-TCP" target="https://datatracker.ietf.org/wg/mptcp/about/">
        <front>
          <title>Multipath TCP Working Group Home Page</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="MOPS-109-Min" target="https://datatracker.ietf.org/meeting/109/materials/minutes-109-mops-00">
        <front>
          <title>Media Operations Working Group - IETF-109 Minutes</title>
          <author>
            <organization/>
          </author>
          <date year="2020" month="November"/>
        </front>
      </reference>
      <reference anchor="model-t" target="https://www.iab.org/mailman/listinfo/model-t">
        <front>
          <title>Model-t -- Discussions of changes in Internet deployment patterns and their impact on the Internet threat model</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="NANOG-35" target="https://www.nanog.org/meetings/nanog35/agenda">
        <front>
          <title>North American Network Operators Group NANOG-35 Agenda</title>
          <author>
            <organization/>
          </author>
          <date year="2005" month="October"/>
        </front>
      </reference>
      <reference anchor="NSIS-CHARTER-2001" target="https://datatracker.ietf.org/doc/charter-ietf-nsis/">
        <front>
          <title>Next Steps In Signaling Working Group Charter</title>
          <author>
            <organization/>
          </author>
          <date year="2011" month="March"/>
        </front>
      </reference>
      <reference anchor="PANRG-99" target="https://datatracker.ietf.org/meeting/99/sessions/panrg">
        <front>
          <title>Path Aware Networking Research Group - IETF-99</title>
          <author>
            <organization/>
          </author>
          <date year="2017" month="July"/>
        </front>
      </reference>
      <reference anchor="PANRG-103-Min" target="https://datatracker.ietf.org/doc/minutes-103-panrg/">
        <front>
          <title>Path Aware Networking Research Group - IETF-103 Minutes</title>
          <author>
            <organization/>
          </author>
          <date year="2018" month="November"/>
        </front>
      </reference>
      <reference anchor="PANRG-105-Min" target="https://datatracker.ietf.org/doc/minutes-105-panrg/">
        <front>
          <title>Path Aware Networking Research Group - IETF-105 Minutes</title>
          <author>
            <organization/>
          </author>
          <date year="2019" month="July"/>
        </front>
      </reference>
      <reference anchor="PANRG-106-Min" target="https://datatracker.ietf.org/doc/minutes-106-panrg/">
        <front>
          <title>Path Aware Networking Research Group - IETF-106 Minutes</title>
          <author>
            <organization/>
          </author>
          <date year="2019" month="November"/>
        </front>
      </reference>
      <reference anchor="PANRG-110" target="https://datatracker.ietf.org/meeting/110/sessions/panrg">
        <front>
          <title>Path Aware Networking Research Group - IETF-110</title>
          <author>
            <organization/>
          </author>
          <date year="2017" month="July"/>
        </front>
      </reference>
      <reference anchor="PATH-Decade" target="https://datatracker.ietf.org/doc/slides-99-panrg-a-decade-of-path-awareness/">
        <front>
          <title>A Decade of Path Awareness</title>
          <author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure">
            <organization/>
          </author>
          <date year="2017" month="July"/>
        </front>
      </reference>
      <reference anchor="PANRG" target="https://irtf.org/panrg">
        <front>
          <title>Path Aware Networking Research Group (Home Page)</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="QS-SAT" target="https://dl.acm.org/citation.cfm?id=3160304.3160305">
        <front>
          <title>Using Quick-Start to enhance TCP-friendly rate control performance in bidirectional satellite networks</title>
          <author initials="R." surname="Secchi" fullname="Raffaello Secchi">
            <organization/>
          </author>
          <author initials="A." surname="Sathiaseelan" fullname="Arjuna Sathiaseelan">
            <organization/>
          </author>
          <author initials="F." surname="Potorti" fullname="Francesco Potorti">
            <organization/>
          </author>
          <author initials="A." surname="Gotta" fullname="Alberto Gotta">
            <organization/>
          </author>
          <author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
            <organization/>
          </author>
          <date year="2009"/>
        </front>
      </reference>
      <reference anchor="QUIC-WG" target="https://datatracker.ietf.org/wg/quic/about/">
        <front>
          <title>QUIC Working Group Home Page</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="SAAG-105-Min" target="https://datatracker.ietf.org/meeting/105/materials/minutes-105-saag-00">
        <front>
          <title>Security Area Open Meeting - IETF-105 Minutes</title>
          <author>
            <organization/>
          </author>
          <date year="2019" month="July"/>
        </front>
      </reference>
      <reference anchor="SAF07">
        <front>
          <title>Determining an appropriate sending rate over an underutilized network path</title>
          <seriesInfo name="Computer Networking" value="Volume 51, Number 7"/>
          <author initials="P." surname="Sarolahti" fullname="Pasi Sarolahti">
            <organization/>
          </author>
          <author initials="M." surname="Allman" fullname="Mark Allman">
            <organization/>
          </author>
          <author initials="S." surname="Floyd" fullname="Sally Floyd">
            <organization/>
          </author>
          <date year="2007" month="May"/>
        </front>
      </reference>
      <reference anchor="SallyFloyd" target="https://www.icir.org/floyd/ecn.html">
        <front>
          <title>ECN (Explicit Congestion Notification) Filter Specs in TCP/IP</title>
          <author initials="S." surname="Floyd" fullname="Sally Floyd">
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="Sch11">
        <front>
          <title>Fast Startup Internet Congestion Control for Broadband Interactive Applications</title>
          <seriesInfo name="Ph.D." value="Thesis, University of Stuttgart"/>
          <author initials="M." surname="Scharf" fullname="M. Scharf">
            <organization/>
          </author>
          <date year="2011" month="April"/>
        </front>
      </reference>
      <reference anchor="Shim6-35" target="https://www.youtube.com/watch?v=ji6Y_rYHAQs">
        <front>
          <title>IAB IPv6 Multihoming Panel at NANOG 35</title>
          <seriesInfo name="NANOG" value="North American Network Operator Group"/>
          <author initials="D." surname="Meyer" fullname="David Meyer">
            <organization/>
          </author>
          <author initials="G." surname="Huston" fullname="Geoff Huston">
            <organization/>
          </author>
          <author initials="J." surname="Schiller" fullname="Jason Schiller">
            <organization/>
          </author>
          <author initials="V." surname="Gill" fullname="Vijay Gill">
            <organization/>
          </author>
          <date year="2005" month="October"/>
        </front>
      </reference>
      <reference anchor="TRIGTRAN-55" target="https://www.ietf.org/proceedings/55/239.htm">
        <front>
          <title>Triggers for Transport BOF at IETF 55</title>
          <author>
            <organization/>
          </author>
          <date year="2003" month="July"/>
        </front>
      </reference>
      <reference anchor="TRIGTRAN-56" target="https://www.ietf.org/proceedings/56/251.htm">
        <front>
          <title>Triggers for Transport BOF at IETF 56</title>
          <author>
            <organization/>
          </author>
          <date year="2003" month="November"/>
        </front>
      </reference>
      <reference anchor="vista-impl" target="https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld1.htm">
        <front>
          <title>Implementation Report on Experiences with Various TCP RFCs</title>
          <author initials="M." surname="Sridharan" fullname="Murari Sridharan">
            <organization/>
          </author>
          <author initials="D." surname="Bansal" fullname="Deepak Bansal">
            <organization/>
          </author>
          <author initials="D." surname="Thaler" fullname="Dave Thaler">
            <organization/>
          </author>
          <date year="2003" month="November"/>
        </front>
      </reference>
    </references> IntServ, RSVP, MPLS, and BGP. They are all alike, except when they are different <xref target="Colossal-Cave" format="default"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAH9EeGAAA+29W3PbWLIm+l4R9R8QrIeS9pC0ZFu25T0zPbIku9RtyypJ
1RUzLztAEhRRAgE2AEpme9d/P/nlZV1ASHJ199lx4sQ8dLVFEgvrkivv+eVo
NPr+uzZvi+xtMrhI20VydJ/WWXKetfdVfZuXN2+Tz5OmTadF1iRtlZxkq6La
LLOyTXaOkndZ0+ZpvUmqeXJZpbMmOa/a5Dq9zcrdwfffpZNJnd29TX5dpK18
QwNU3383q6ZluqRXzup03o7yup2PVmlZ34zu6ZejsmpHbTWaVaP9Q/px2tIv
v/9uSv9/U9Wbt0lezmmQZj1Z5k2TV2W7WdEvzi6v33//3fff5av6bdLW66Z9
vrd3uPecplFnqX2PVd3U1Xr1Nrk4Or/88P13t9mGPpy9Td6nedEEf/s9CD7k
7Qn+xp6Ffx6dYw60YeXsP9KiKmlim4xGXeVYQ0JbONVPkqSp6rbO5o3/YLOM
/p5Wy1U6bcO/sfP2A1rZul1U9Vt8N8J/Etob+vZqnJyk9zTzRj6Uzb5aZeU0
q+OvqvomLfO/py3t49vkGr+goz1aZnU+TRP5TbaknXmbNPL8TB4f51k7/183
+GpM85Jf1hUIKZvlbVXzWdBJ1Usa/C57i7+T5Gx0Mg7O+29rUFBFk+79ekW7
O1rV1Sqr2zxreKHuZ/T+Udvc3d+MctqTrL4bLddFm6+KjD5eZdNgyLS+va1G
aT1d4LdZXWZEYQsii3a0rGZZEfx0ntZ1VhSjrF3iddHb/rbOp6O2TstmRUen
D12+P957fbgf/fXczVT+fhH+vb+3/8r/en//+fPwr8O96LevXsTPvtk7jP/e
7/z95rUfjS7Afvjt8+d7B0KG7oP9vfgH+50H9p93/j4Ihn/Bk7G/Xr7ZD/96
FY/88nXw5Iv9V2+Cv14dvg5/+3Lv8CWmaX++fBntwcvXb6JJHey9CXbw4Pn+
m+jbg3gHDw7CiRy8ehMt+ODw9b4du/z5Iv7zZfTn1sMvw79fPT+M/35xGKz6
1csX0arp72jirzpH/+rwefD06xd7B+G3r1/Gy36z9yb6/s3+671g6m9eHcRf
C43ir+OqqJomLUbHKd9a3Os2rW8y4kOLtl01b589y8rxfX6br+imp2NiIc/w
1zN78j/w5H8cze6IlazBLXkIFTK/2nPEOm+yhPiDe2OC5xL33EAeFP5/mbV1
nt1ls+TPabmGyHm+B+kgMy7v8rv0gbne398Tg+JfgFE9o/HSZpFlbfNsVWfT
HBJkRDyAeFS9YfZQFPkNWN2zeOb6muTCnkreEi9t0+QKoz0w25Nsmi0nxHWf
7z3fw3SZoZyej+imv03iF1xdJ6PkiMavVlVDz54pq0quSEykS3xB4qMqBsnD
K63n05HwXz6XPCvxP3rZuP3SymMqNHQQFRl/Hifv6YE8cx+L0Pgz/bdJfrVv
w0VeZatW1rZ/+FqP4sPl6dHVaXdhH6vyZkRrWSZ/zdNJXuQtawy2nuT0S5uV
vKOfsumC5FGzbB5aZFtVhQgfXuCiXRbPVI1IJ6N1k43ydlTVIyIp/ufe3iOr
/jROrhfVsqE3x8v+lJLAKe3LcNV/XhdGe/iQj/P66PoR4qN58VRJkud3OeTY
M+gVzaJaNc/yNm07dHZ29C75VX+Q0MwcGVzT5pR0V242dEmqFeRmQnpGcg2J
lPOfO5jLbkSLAQXuv5BT+nQxuj6+eGDKuB8k46a3We23+f7m2XLVTlfP0km1
7k74E4tdKI80Kk+ddKbkA7Ss5KdqmfFNHxi3+fT54mq0v3c4+pSXf2QKS7pk
NO4zevQZqRSkoKRF82yZl+s2a3jAJW2oO283OeY1n0mDYB2n6cxvRJfx+j0e
Tz7JUNHmnVd38fVNElYYRu03HDh0o2VaPity0nFIE3qmj3YmKB8mo1FykjfT
Nau0De4HrsIN3b48oIGZ179px/FhwzTQLrK8TnLWF0E09Ld/SFQdmflAVnF+
dP75w+jFwSPLKNOyugm3vnnGH704eEbnWc7SeB3npBItTHMsTXvWna/qRjfc
Xpwc8RjRbn+etpVs9t6BTvPq7Gp0/NPR5fXp5cipM99IMWRmPKM9rGkXRqy/
0S1pOrR7nn0Bf81WDW1XcpXflGkB6oip5FhGiSb7CeokLtW+TJXNidHh4T9C
04eHz5pMDv4Za77xJHsNMxIyTcZziCj58HDQx65eh5Pc33vxR28f9tLftRei
nz/7x6dJYzx14fbfJPGkD/65SR/8CyZ90DvpQCaE8331z8331b9gvq+e3OR4
zmoO/FGWvL/3L6NfGutxAr7+aUQiLZ09pJs+uLNNkc9oYw8P1bhMSevDOKNq
LoZmihmWtI7Olh8l8kLWWdxS8MNBpFvEKsRn0ihz2uN3VZlGmrDqHp/H2189
fGcfWCxsZV7gP7rrO05A76pk+PlqdPWgPjMrxul0yW+cQnWhEx9P58s/5bP/
QTbd3ou9l2P5/4N4Lr80ePfPZD/fjq5o0Ba+pKwkATfNoDWM5qQvlzNaNwmL
LCF9va1JMSTZwQ4E/Iqk4CSf5aR8461kLTQpq+r081KW1zkOp9KN3L/sbC7T
+TylhytSYqfTRe6/56O5HHc+3x7hqP5tXZLqT3ucp02WFWnZGeRoHH1r3z08
5Psa62ymVXJBejHpn50B34+7X/RMq6BrTVv7oWrbdHtC/PGjk/hQ1WRbvU/z
erGum7YzxIdx9yuhWHja/E+Zin45Ox79+hDZPqRjwsHSq2JiuCc1y6ujo39I
THjN8qBXszwYNWl6s6VZEomsa5gyR6RdQc+B+cIj/UF5cXX0fu+1kevTxHuR
NjmRFt2PdLFFJBfj7a+2hyDd5ZZoBdpp53myiOLPtx++Sgua/ntSQ2edh6/G
4ce2TycZTL+8xMbQPUhXcOjRHtPFbejO42O+9CSUavxgXc6yet2Smfh3MoL1
bkPbXegmNnRCWQON2rFcMs6XK9rnOmB1A3r3X6tiTWRysD9Mztcs8l53lDgc
xJ5yWl4Zr+DtI4y9Z/19q+8zDKa5mOVz/O5ZNi3HsF/j7To9Pk92Tr+sCvp1
C9/GjbhI4UDP56Rb449dsEPim8/OLpRtX00X+/tv+2lID32MH6X1vGMChx/a
JN6nDdRiYtR005wdEUzmWDk0/Dfv6iqdTWCF8C/Zzs2SoxWWIEbX9sG5uQ0u
FuOTMc7qekHfNcPklxKumEadBFftum1vaCLRuR0RARWqfMvdX+TLV96e6Rzc
NhGfpHf5jO7rJqs7RHwyjj/u4ZFZNZ8nP62btupeH2KQ8eej7sN/TuFtoD3P
i2Lr3X8eb32zNcBf89+IaD/QjzoP/3UcfBo6E84u7kgPhJG+qJa4bhdpmRUJ
YjIwxpIXB49cLP7J4Gn7TrjyI+bcQ5diQ9x+PcnYN3efttPFn+7+x2/5q//9
H/X//uno50bP9/ry7MP15dH56OAxk9WxdGIx0yybsdF6cPDs+YtD3LSOW+q6
zm9uiNKYiK/NrZ+8+/weewMOnhwc9DHuvRdbs3r1h2f16tnzg/1/cFavHlLn
99TDc5c3bTrKl6viWy/Ep3Wd1iRX6nxG7KBPLmx91XOrsmyV3ibvaNJplzzp
XsWfb1H2Cdy/14t0+16cjKPPv3mTX71Rrf9Z29whDDh6QR/MeNs794S2KoNb
hRkWacm86fQv4sS4FdDMkvucbsBfaZuqdcO+rsv3xw9aVkoko9EoSScNlI4W
Z3PUsm9mnpMKlajmAT6HD79FYx/yL2v7jGOZSXpT05KhUxPDTYvqhn1CKWnJ
m79nJDrpVdmc6KnlGO4su8uKasW/EX9S+OYWXsYcgblhsqzoSZrc/SKnd91n
9PW6bNZT2oxmvi4SolD2KzXwRpFiypLRfz+ElKpqEues7n/hTcCJ5jeLVvxW
Bf0S7i4QuzfCTOqzbqBLpSsxxgZeL/ImIXtuzU4wWAopjUi7QjPZWj0JFH4I
p7DMZ7OCDK0fIKbqarZmQ2J7SCKXaZ1PEO+mnbYJ8vh8+3il05wsLlrDAjRb
0ARL2v8dWZH8gYfpusyS+3Szm7BS+8ABi+IDYyevZtjuhg6oJgtH7FM6B4xL
dH0HUmYdSteGHxNV8wTvF5vkTmmz/z3+ZGXaZJiUSZEvyYSa4SjLKnAvjtn5
8sMPErw/qcSeHPBUBh0rmAQmTSqH15HmdKIb+afk6w9ku86y+e8Y6nOZGZ0L
8bvYLy2BLOV78Dz+QXgYPNG0uaUZ0scD5Af8KAdD45JOybeVnkqZemSnHvwR
+6idlf+nAZhKi3HLqsW20k5u3LRAssSvaFpMnNG0ZHOgsOC+1EvdUP82dtpW
NIM6+fqVDfjff3dP64HidOhNRcEzbdaT37Ip37YGls3M+YJlY7t3nsZobD9n
rD7Pu3N8RxQ3IRJaY5bRrtbZvKCXEdGwai1WNogAlLhFfXhFa7EHUhDcDZlh
al+/si6YT9a8cFonXe+SNdWyJXawqjOeH0Yhg6mWK+Y3iuY9WHnS8mc0wOiY
u67/27gjBsn5UNdlkd9mNAO+uqnu89QmC5c0HfH29O+rdTGTA12kco8bkk9i
l3Bmh2fZdv4cR2o628T8kt7X0LWlTdhaG82bZsfUERy3UkdTMYHk5bRYz2Sn
+QzrjHgX0htYyY4J8ozXfc+KGpE033msPb4JT23516+PZ2G4LSJLDrtbBfcq
ZNwBu8H+J6UYYPTyAgLIUa8zL1YWD8R5ElOawjGW7Hz9qmkSv/8+TFYFsbcO
hQoXpOWxAG92hwkdZnzYymamWY6g7NZ9prmWMxGgolvw0175+piSQSDngp9w
NCW1PcQJtzVJExpgskmIDFuwMrqe9JNJkU5vk0n1ZTBO6Hhk4yYZ6BoCFBJb
CSRZVPe8pXRxJoXcl48qfD6qTFH5FpCDWwFt/hD7LEynwISVkpgE3IvTBBtF
L17lU96IeVUU1f2I+IwxGBWzfdeVSUcEwR+4lVgW/clM8Ur8d8nzZGdwzX4B
jmgOdr+N9MbCs4MZ5Y2/JAvcON54RPyzkvU2PjLmn0QstdyU/z4pqunt39ZV
m/1P0Zh5IW+T5Iioi2gWz0GszH5LpxpsWySZqIiN8ElRiiB4prcZdA+nGNM2
c5YQSVYiiiFxeQ4ni16iLg/WJelSVLNsjLfyC/LGhliXoa9zLNNrmCW0+TIb
kaAGyZYt6VjjbCxMOpi5jfPgvGXWMmKDFc7rakkKb8ZTEuHHtGQjLcnqlIhk
OF85CVA+HT70CSIBHoFYInIGEs7JmqbelUifTeAwwGdDv30YfqJToVvkJoIt
cxd3snGz0VQv964zvRA0bCa7oQPnjQzKa7fHwu1h9lTRtg35rbwwXIwspW0i
q3SSl6nRvjmsaFY2hEwOH2Iq/65SQQaeVaxasCyhHZ2wWP+tysGw4c/J+HLa
SNBAyhZ+D2wGP1SVkKCiWsOoy332hCwxOF0bRjTharmq8yZTxYi3MXjeH6bs
C2hqbAOc5PN5xhefpwNR5iY0c9/Fs/GveVY5khFGGZMgLq8bwwsCM5EQUOAL
+qxzQ5/gR4E2OgRzZVb8B7SGbQa1P94nFnXiXvUAh3Ja7P9LvCmRa7Ra10gK
2taQh6H8DsTvwNsxPAgR7gqEx5oGztwTkWOvpiOz7rxh3Wuup4nUU+JJ4s8b
GiOTEWnyU9OYlfr9kKJ80YFPlUIhH/UKPYMcFkbJqs+/47ZkprPwZZYMl7TA
Bm1o0bqaBQ6MX8jKcoYEotZEkpGJUyxCfUKonKx60+NMkLpTG5po1z21jFFs
7ABHCi6RC7MXXtq/tzxEsBPRnjVZoXSmvFr23VFuTVtGAjr7IrfUkbMbADPL
1EtcCFts1itoK5A4dXZDpidsVztlqIxQykEWpJ8Hhy8615yuKm1PEy1LFRFs
j1sZK6c2+3HPTf0BOWykfZiO+hl5VIFdSGbhyn/9+7/CKeKNrKFzkh0e2qej
w0N80ROQJQZExBXaWuAnj8R7eUgXgcaoyMEiKb9cwawL/CRwihDvjtwlkCop
G+mZcE213YfiHiHTO2/7XTFyC4iKM5jD4RA3VVqoYBeJ0LSqF48T3VaiGdnM
tA2WOmRRTYdb3qipkk7IxBGjbQovhrCjUXIdKunKCFrIA5rWlM50XaTQfU2R
ZaLJnNtMNJ1lWj7gZTL3R1HRsXofCCTSUOQs5nBUtItqfbOQ+x7czq5TYwIl
RNwY8MiwIP+Swrs39IIt5wlfZfVdPoWFSz/Cd/ggYXMD6cq//77rPWBm60Uv
K39sxYlyD8fMCjyKNMYgMw/zUG/KKf08GXhiGISDwVD1MwDXm6dQ43zlBc6O
XnDHMvSe7YV1k0IXuxbx4bxoZVWOokmYh2drZppHhl3E8XivBFuQTF1Nu55t
nD2wzNp05Dx20Bd5XuFZZ0hlwIFd9NqEoBk+oWVFX7hLTMOUyWl5Q5okjVTe
DGH+klwlUsqbhQYOUcDRvfdYcD+DyMUBVMPVKFTOrs9Kzhfp0iSwlbbYT8pv
cR5E5t9NtDZ6nH17JrD7dzwwtG5Y/RGm1rTZSu3OrLMInsVRQStFAmxa0vTZ
ucPrPV6kOVmeFaSBuFc1o009jN/EHUkuInIx5KQq81094EXNvHPR+4Um6kTp
uJ3JNFcLVQ1UvjKTFEKM5Wrgkt3ZcrTs9s2kzlZ4CahcDXj6o1k3f0QaONcl
NOwm2HXoWO6VZ1abwskk3vsrDDKLnKhOSi5dfnLg2FGnUym8CQZIk7CfiEQw
YthDE96OiQaknlynzS1UPKKwHQiuXRnOhm+2nAB68eBu8tMRPgBVpTTNk+hV
6m/43ezpA1XbUkQPYC/B/SJjr4HqTyA8MaEwH+aOpKVn96zB5p3c0mxaNRui
7qXs+hH7px/Y29Wa77O5L+RNtFXIbh9uOX7hltW4FcTNJNtUkuia/G2dhlaQ
I9jcU7KjgSOxs46c/30kR3rtue+ZqehnHU2lJzZACiibdEbWGetEK0vZf8IT
pr6YVD3O4BlgzI4fZ7MxTYJ2MyWiuc+8c34NPw3RJavYoY9RBEPaNMwPahaR
dnJeVqtLkZ3NObwGpAlm0Ebl934r4MyTOANd4ylXypUzd4OM9YdOyW0WEBBe
ELuxGIYQX6YXoFFKyGsmUGaF56TUL+BwZetJPXM2hWCuW65R7wwlKmwW1X3Z
P8Fhl4icbhzJd0jOti0ylRusxthNYfuIlSanarAggNfds79oug/77obqsA7d
1fSiclvp4DeuiJBpO4jIZkNnwJFNwpoBftDWGxV3ts3MmVQIincAQgo0OMnc
j2hmWCPuicisaVrLSPjIOQeTI7KjkH7HZ+TE3TzNC32rSElmU158CgkGv6Ln
62xbgcAuiw+zPwaoZpSSz1hv+V+zci3FRCeRLt92r/MOCf/klAtk3iakFNJh
0ejL6k7tnEatskk2r3ivJ5bEsovH49Ed3Tg/My5VEDAW92vIQOjsb8iUqHkD
ee/alHS/VcH6nrpUOSKw1K1C9YAt88gbsjTAh3U+Q8qg8t3OhY3DFb3eZOGV
vRTpnRKgTFoNsaD0RlzkE+L5S5z4kmaY1nJmkVA4Ch347yqi1B/94DCgkwGH
FT/R2hs1i668nWSFQX8aiLaGmj7iKxJ6LNKSU8lY9TN+EtXDXK0n4gltg9KY
RsdCIZxqfs6m0Ht2XwVzVNedHTGrXhob6I9TG2+TgNmGFelFVqywIKJf2r+p
rlX2FbSW3eplyJdgu5mywq1IkzOtJJCBQQKz8iHFHm61cuMmxjVc3hjCgRGv
IurVnU/ep1OOikXhvatM3PXjfYwXHUewwHBZ24FIbPY7F4hkLYLVBKKjslrS
DFL2BkhugtTWNRox98tRjeSfKI76+hXVUTTzWrI7xBJ4sXeAxRRN5UPs86oy
kQMCkft3pVEn1Tq6t6lfFmqktXuCnQiq29RhOClhmV2qJTYQxE2SX5rg/saK
i8Wmz82PfipO2O3gkTio2cJL+XKZV/8bYzI6r08kY6qZzEsKO8Pw29cfrjMi
PTK9Y0NgW8siw+mehY6QfjDGxOc4bOdiMB/akiVIO6jF3nwqLcKF9eEMUavY
PCSB3ESYIs1nSqEdq6Q/AMpPh/4JzsCBuvdeFZtHHLxRyJolfJ2x21nYsVKt
2LIYCtlU4pN3MxiqtmQ5uAzMkEtYI5/zJkErhfsRo9BH6R3JH7hyhuqbkQJO
dj5KPg9eNaFZgMbhVZlmRtYmcNzrMWYKgVdbes2qdRKaFRh60TJ+hifk9D/2
9BZ3T40UJsNsjQZ3jerc4TDEaNvMGOZWyk+oesAxEyg30Mq75MZH5946Vn8o
AuVdKfxr9uNd5rjH1x9S/dHvdnnZHQ09YUqU0hOzxv6wwk+SiRNjkiWy/m7N
E3YPAp45i02cgrTXeVVL4kPoHBWlM1OlBDu1hF6S3pCCMBgnV9XSZe/EN7I3
AyTM+YiWIWYqEh9yUE5gj/VdSKGsWo6/90W0H1+/Xl1LakDXugSrQW3yXoPM
2Lus9NkQwS11BiybnNkdqEx0o7xcE6OB3yRnP9+yUfoSt3gndI+IqSREsDah
ROR8Z6LUdRwzmvg06xUofd6Vrs6WSQb7C3btHCacNx1ovj47QJ3iqEiwg9dK
CZMz0PZztjVxS2a5Ge9e4/WDvAoGeSWDjOkjms98DZ2PSUBlKSY5gBPHEVBd
VcuBck8OsspeJemcOQt7NoJ8mK5rA3TPmY4rVi/NJEu9Oq7jyZFJ3BXH8N+S
wVkJ8UHSYpCMiNyLYqS6FgQ+e3G8GcbPBQkZrKaWgbHfL06ITa01NEIvRLYo
nsb7QF+k6GXgZ4Gapge54ng4MleW7LNU6yyYAP0w7bFVx5E7yTlDaP5ejwwN
V9se6GDB4A0tbA3fgEwccD3n1T3mLaE4pP5OURzTtPz2cibeiDWxQ6R40LRL
0hoyEpCkEbKaNCOTwSU06eiuoMO7AO7hlrinq8t36K4i0XqTLieFhufSrv+k
zgoOVooWM6RltnkRmLhB/pnVUOP4v37NpkSonNR7fM5kRHSOs1jXxpzlQooj
HHUqd3QDOKG4aQLHZuqTBFkQKFrAyfo20xiwmpG0cg5rsGjI221fHm8M235K
BQGFPvPE88wfR5t+gdK8YRdxDzcAc3kDdvB8/0F2MOTFm6dzhovt7vO+6Zn/
qZNN/jM5Vuil5D/x8Z/XtPQ5y7MQDerrV/+F/xw86z8TtygZ4YJ5AwZ4l4Fm
WjFpTjkfjrV3kAWNyJ/YB986lB7nhWZNxHPUT5+Y4Od1q85vjHRazoBHhTCa
Mzg9UAVGjX4vI9rZ6TTTjbNZPdcIfJA8tY17ujOfM1fX74AMUpjJiLtP5eng
C/l1/3Zl9YiIplQvxxVUH3539Dl/3LeMv2TZin3WGp6mIVApNJLgNY3j/+p7
/FSD1w0NAFqhkdh+WwKjgSYCQ0XO3X5ovzs70QH1Hui2bD/sBvbvovHocfvC
fd4z3iUnMohFfgJdirZNIAF4lEvNc7jOl1nv+q4kAI/LaK/xFEObOr2Vg9aP
+BN9ppdoQlcH0Mk0HfJzmR1z5WzPEX99m/zgxTDu8aD3vg6GyeCbriH/8Anq
xW8eJ9HBsMd7o0sabCXKiujN3brErNnSIUQTUJWuMV9kWtynG0QZ+7wmD8nv
ay9Mec96tubkIbYyCESJqDCmag2NF3XiZkXK3tWiGJrOwe6Hh3dAZgVTcfBH
WNNgGLhbkFPCxe5zl6unXqdZVGfNEq2fSbFY9KohcsyK7Auc6DBI81oihY0U
5vYMIMv4t9gPRbbmplqzbVVNIM2ShzOuObwSayIaiF6SYk60pP7FiUpFTS2Y
k0hnB4B4R8mCWJE4d6k0udX+sHuZa1wiHTBLb8TipbUHi5bDYx9B2qr7V2zE
SWbz0WgdZ/bJ24bOyZ6SeovF2Z7nITfTtEZ37H2MW443uc02QS2Fl+q9ZQNy
1wYwWJZr+pCNX80DlwAffwKKWdIeyj4O7OCI4XKGAliq/BMsyB2+PAqHPkfF
thYkaZX8XbCWMHPUdqnhGE5/oDG004Y+SMEH4YdtRF1u1yVqHSULTZP82Jjs
7rWk5gGmoMjC2UnGAju8mYQQU4Ni11Q6qL8Pmb+M4TxmlTgeorsjW9U/E7ch
MvdgT85cIgp/JdSaldN6s+K0rz8wGAj1Rw53Q+KtoX3bT4PJD3Fc7CJSBwFH
vJqck3wC8nxUMRhwLBOpfbPE5/Yx8641asOHB98g2FAjZhAMIObZRREyDoQ5
JnBYaaK9Bo694calSMo4ZSQuLrPBnQ2xkQOtXERmpD44vuOSxE8HxH4QjbeJ
a1Q91PpipMaarZbMEeRL5kV6/0hqStfhyDv4TbqRXtRv0nuEO3hPhLjunOMO
KdgcZBNpA8Onydv4yl0LbhQjVNkR/GonyTYNm2JbqWWNc43mllqmCZzM0Uk+
uwSAKEwduSl2yHzn3zyCs6AYDfABBdgPZONh8+OsPnFjPwUEqlEm+XEABcqJ
LYqz9ViYi9nFFONxYmEYw+M5qVsJRmewW8ROFRpMEmjW7IqrieuQIft3lxBr
bul+qpIYivcfS8HnULlzqIUEVPeIxrt1azlloShCYcfsB4F0JyDm7F62X3Dy
fcsaraE7cKruTHSOKNWPk0zBPNYFU2k1AaZrltzlachZfcqLU57ISF+Lp7pf
bfEX3pKS/ASDhIc0chxMRO+LeD8eE3QDW+9R4G1BLMyyKyKVQF5Zu6IfS7uo
kt9ENe8E7frTJHkUZkZrU4PBq4L3uFi8RuXG7pi/wTDZOu5gFmkA5UBqQyPM
Tp2gfsUs9yxNPDO1QNP+mSH06W+2ldfsox7NEYQk6SrVKUcXZ5YJBK6BmLuD
aAtmxW74aRso+oGTV96qfM9loCCz8lb981fr5VJRrLsOmq8/dHywLlplmQIN
P0zXtOn14mq2VhblCDSIUE8fdqDzvE7hGlUfjAsy0kvSmxtjv2FwK3bLS14F
wvalJQsic10TSk3Z8eTOfslcauHiMuDP7DcMZx8QpasLYQPmwfdZRV44BZOb
PirGcgngB83D87GobJQXE1Y/+sI6VEBOlXmycxBme8Jmhk2BHa3iko0izfeL
vMh8NR0/OfR2SWcAzct9MA6P+wH2Y7m6kT7u9fVAFQN5mzbWSQLW2eIV/enB
std5oO5a0GMC6wd0bkMPZDArA5XnB2zC0Bzmra8NIhO8CUJAW27MOvPe0Qlt
2mM8jBUCnLylTgkjf+oJ/2uRj51BOCkaLL5OgCJ1i+2+Ig2CVANAwzjBfkR2
ejlbL0cCgorPpaJDDVInP3kH+CB021yYu98B+vWHXv+nxX9MnmzVFDiGKunC
28KBeD5eFaCBgoYDJ4vyOSGvKco5aQfo81/GV2MP2HJKlg20fGKVdaYVAAOS
16CUHKYAqYS3dFPFXJnnX+ibgXgOBhzmtbKalfl0WJxWs3TzY+N0onGyI7se
YL1JWsMVZ8CMfkaF4kI+MvgUn+rAHnqGjTBbSUKVLkFi13Igvs2H/PWH2IWM
h/2Tk/BJqcZO7Um142FcczyczVbQCR+XwmaEoQkHdbGVqhhlVeorJav2TmqY
WEpJjfqw82hUxy4RKc0a7aF33Xpnmuumdo7iH9vcB91fQHnYcqpzvgxXarCz
DQ5UVQcSV43fqQvkQAlXASF6VGTlDQRcUOdo92S9uoEnS3ICVLFJ6RLch+kO
mr8Hs9Kdsh4pKjbGkugbRftsgtOqgqWXRs6JysHY3i8qh0+YiiRvnW/KliP0
vP2w1oBBSiH3de6dULoq0anNo8IWf0hkLqrqFsWJolwmmnI2TLRlrtzC9mzL
WG4rn9z3kADbJqzhNlV98/01LvqHYixff4hDLJy+N0tXXGAWWAd9ifpQNIjj
rSqp3p+TxQsfgl0bx3FNTAZeGuLIRf531nSNf4s/j8ktkFjudTpMnWfqPCjz
FddHmZeJydzQSujympnDb/a6PJ1i3wNaJS2uu2UKoLCEi2dIh+M8KHCGPg6s
5+M5rj+IJ2NTuOAuM2XwnvECJFuM+OFmPACRehIXvxKUfIX3T3tFu9y4qStc
m1aNGK9Cd1zCozl/jtZVh7d3OY6AYwLwkNdnx8lxRRe0SNEvJp7eUxPbfqdc
Vqug612MzSRUqbclua3TXSjNXOncrAfEouPOT0UD6bJsBQNZQdbn5g8diXcV
mLIBOzx4x8q9gytzuaqXk1/sLlW1yaUUd3GZN3FCDxfaWqUDp3XwnKy8B743
fTMona3dQJFmO0cYl2iB1bxFNh1qU4WD9TAtVf/CDLgeLdCLvr4IKd2AngAp
KxPxz9V5XvZ5Yh0zTsuOefOQ4RBnhmgCLaNSzDhFqWnN6NaQBFlr2JEh0eEy
J+Lfkn1aQqrmI7MRLhJGtmexGZGQ4LgJL8PLyIyTTiQFGh7btOHkMiQsO/M2
m90480AV0iGJ8loLi6zOXYu/pzjJ8BKY281FFew8Hg85f/0hiDjjiU+Q+HCm
1WXoTw5WsCCbjWWF8x+HeZlcE6XbA/Sue1ekgB1kgmw4XgT/1UghJvq8w8nO
YO494OrV4zeJszh8m3mZF1l6tzH3Tl6OGFMzkGQNzguVgRd3L3nDGNnxkteR
HJEsaIkjiP2/c3n0edc8X6LX8O3RZBZ1+T3o2x4TgxAPjIuv9MwHezMDWKdm
ooq1rK+oXHGP7nRIcxVgtXT3gikBB5be/TkUJsLgi/WUnZPOGbBlJLKDDzuY
i6OvZ74eDCsTCIwYqYoUrvXU4YZoNdVq7VkJuhEEpPlt6QxkgvRlMzBDnvcG
opwmLO4ylqcMKbNuJMoDdLMY3cqHdTiZypydjSYvPBBf5N2soUIF/N5ppJOM
yDWnUxib01/eNeCJDAw3DfAoNYwkUgaGONmhwHowM8AvxVGXqaoqkDf0cLOW
itslnT1YN46aOOk8r1WJyqUIsA/1REizKv0u5Qr04ioqTEWX9Pm9N0jy38nG
N+MhFygef7pwb3aFZMjrYgeo3WtjblK9QSrTEbMPACzFS2RxyHgrskgf75Vo
pZUy80sk7RiH4a1AOXP+SEakIxR35iJfyc0xd6aGho17xmb1I3ret2XLfP2h
N1lGybUNIChieBtOlX9g5q3mb/YSutOF3aX3/Pib731VBtMykJ51iepReN+m
BlDAJGG3AhqoyIAHTWe78cnOr+rj1HvAgQ25akuunEbsD+UzRCCIcQk3Db36
Vt7v2Mdj2UZff4iTjToVND4Exf4ZeA6da5lj5EMJ2XIeraQYyJXydblC3DN9
b2yLt3XKuDxQTUJNcQGNAytfczl6xlyzgD491DP2w4t7l+kagZ/pdA3mzlxW
K7zlZknKAKpT83Ytjxpinc6N38o1yFuuAp423zi5/w4oqqi4YmvcAwtlhpz4
IfoVYWdmMzflTBxOzmladrBK3sdGI2KWbiQDQ8vod4K5g/+WNDHSOPuyxDDC
n8XWEGJIOxGNACaUbVSFdXkmNO/rl1Ho47IifHCH12tEFj879nNsZI62Bbcl
WQCaAp+xTUBnAOwTwXAPs/xDcNlAGncXISa7qC1bNBtNGK41VEO12y43yTL2
8xEVLI5l2SGOuCwil6V0r4qCd+iNCsNOvJ29zwit/ZfHs0Dv3gu5tVPqhBRL
K3qHfBser8QDM05S5nlLIEUZFCuT7HkIJbJ4KJvI/HpUu3f5gO+DFEeyX12G
o8odcc5GiVqGSCRokK6IqHHIep76tbxF/9rK8aeR4OKZOeCFO7rurPKG72N/
xchhIgXjqZLKeU0uhG1FFaUj5A1HY5CYILCVfFihm6zNWOgOHeBbJ+wVehvZ
JzH0MxQNHTiUHsRaYie40bMMWQr0f+o5xdNbtdmshwxQoQ332EC4P4JCXG7n
cslr+Q22Xn5TugBXgOyWx3jaqTPcdc8tRG1kEno4kvecvcp1nrDw+C+VgRtO
oy/dsXYhI1RtCDBSt7bZ0iwZj0Y9Wd2AFtQNFkwGcWrBDy5il+n1F/05h7fq
6aw0CCRr+OKgHqNWt0i2Ykv5DlRwI9tWZHNRfSrDYoo0ccmvwS4hmcoF4OJI
sK/DF5W5ByO6t2ZR4YAKV/D6QAiYZiwlUxz3bzyMq9gNs5yryeJSqSgvSYKo
bqcdYCRPYJjccOVWWmbTWdWyT3bFQOaqJWi+0CH3FUxsGRJbDZDEzi78wEDT
4VMQXkFiGG1hkqllgLZxXL2o1g59W8oSwhaGnLGTW9FOhOyKoW/DzAcHPQ3R
H6xTgxX3marSpEM2bSUJCRGAmGcIYrtFFdYC1OUqUxi23UqjvH9aIyZIWFbU
PdOLgwKXLOfnvErdESacrZPS8U0FSYtZbhzWJCveA34vK7qJqQMftjRSJrAA
F1j8ByFaXyM2W+J6yHDxkc960npptLNFJqqCPlmPUdqiQcMi3jhVKGPdaq06
32pe1dgsnWmi59OV/s7Ln5cM3d06F1WryaEOetOEVePVVqeKueLraUpyVOfd
kJKHXGh1IrMqJd+AqLtT+RG3qMyX6yVLbC2Z6yWF7qmzGZ9l4lBEggSXJa44
g810JiNMg7aXjGol9LBa1jIneK1IV1kaQKGDR+rU2NqQhmTuKpTcfQIunngl
PdyhtipOmB/y1G7kJyhVZvnYrcsNNmskB58ifCQH2eRiIQFJfcN+im7SEzz4
eszgfnrQeTnKkMuv8BDOy+kC8lfssHMvYgfF0ummqD+Mok+9h8N42Y1kuRle
aNOZntuOa5ckGKXMudz4LeuZcz1aQMTYotIt6hI06WQHSUoY48TMTXyndxHN
IsDQRscn54pnZ/2SObsJ/4ITPmun493w9CTjjJOg+utieqwUdftzokJofIQG
x1YqibmzxdnTOMuFa4DlEFxBf953UZAn2iyqwqozLAEO+F2BfWvausf8YHcj
7tgwEPviWQ9toHDHScnJijnzCFsk+4oe+n1gU4B5iLEHTamr5ONBTsKVgvSu
+XAtes/QYVq6xEZ6cOlAD2+qtmWhvJG7IkyaOb0CLI+ury5Oj53exeNcXv31
gjdMxmZmltc1p8WSThxgok428YErBgV6uLbN3f0NkncRNh2517VQ94hYaL1c
ikAEhX7Hu+NH1aa2qm7FcFxk5cjhxl44UytCoqc9ZmWEMUYBHdTaZeEUKS5l
juELrNSIsd97NASnFUXJu5jr/ZOzEb8vuzWqWtPChk9qddsgMGYQKUikSj/0
HL6wKbYIC3W6LypOsBh8m+USHc+nhoTnzOARlCr6ohcox8UzzlOADHIv9SCh
eef85HyXB1TGMzrWwcIfHR+ff9nVJgHoYg81gKOxc4bU2560zRaBlnA6I1dZ
HaLqiUHSBTLZBjCJf1EZdteTwCCSHS+NepixoAr/LjPC2m4AwEXvD6DNyHQ/
KyyFXntRiqxNj4H0sFkIFugLANIQQS5IcJ3S7JGT45WB+7Rs7alpVc90sYiX
jeYMmOPkuySaCtCqCxFJEo04eazsICpP5uKabPMjzdFpR2TDknbWQB/ntGf6
ppw55/YVgwgGLRt2rq6HydX1c/7Pf9ulQ4MnwrLxmjWnmWYzD14ifpatcWjx
b4WHXF2TxDqCF0zKB50PVp9x7jHiVqfno/39w99/x3PSQYpt4eLBh4bJX9XA
fo6pj87OdhNtfHG4J+M8+L7oyee7gS/RwKv4HEfuh9gRHf2NzFJ2RWDfgqrx
7m5gM8PlSSH5w8AbP0rG070AH6gvJQY8tCjO0eXF0fnpNQ6WE1uShpSqTJpm
KDKNkaeh7uwfvsEbBOI32OMQUhyruKty+Dhgv1VDU8e9wzxnAGP28znyADLV
LK6fz7D2JtpR2e7gmMJNlarQMp6aTxUYVVBPRffx+OKRTOZbK2ERKdJ3Ccii
kAkAgI7HOuIZ2n9eP3f+OIdXFOQWG5wrlBxi8QsBebOlijFGZtfZxVBeif9w
gQYfQfy75KVp/Hhr3w8ORAK7r1Pf27cgm15WYpWaInFEDZDQTKP9HyRHyhlI
CjdWjFjwCoAowKjrqhHHt3eURrANc2QuxWcYVCzwxoBbrVJuSOqB0/hy9D1r
WL8dU/jn6sqngrg8gxU3HVMIpogsnAUqK5XRw9dziTCi5jPeaddjJoigMXeF
YyNU/W/WaNhH+j2/PkehgnhZGnpHoylJmG1UrGHbK7urKNkeY9zn+grz5VCW
Q0M+J9oOHJcR0F7IBLg8s5YWFHNUEeUrYf5YoEGkajKRkA7XVkuyS4j55HeS
+4CgEE2wLWU3+NIQLzHNRmAo22wEAErz2IXNCljicNGPuodR7+huTQ8SusP4
4atnt5fD4xb/kk5WY9uvjlgfK4Ij77eAuWoe8FbJtqZSBDkTAvFd3vrboS0D
xslH+lhsDIZrbFouwZq5PDSGoN8aUH+PjcY9kFgOu8Kw06SwWvmTLdndaFs6
H9eAm99pffGIG6zgwPE6Pt4gJj60W64Gk2Kc8aVHM4OIE+hvsi/C0hT9pXWA
rN5LgNBwxpcfNWQu0IIofkMm5Ehjj8B5geouaAKivjRrLk9TnLO8Ed0mfkBm
Xai3WBDdQhgx83JxaV8X8c+FQsbcJVLD8zd1BExPXFh+BvXFnnhShXHeNae5
APN0/9WLF73v6AI6h0WNb8GpPt/hp9m9CjcaR/QRjPr8+f5+R83Q1WuDYNqe
0ceKVEvrF2sYhPp+hdunYaJBn28P+sFY2Sz52UP3dod5Hg1zkHxQsNVjV3T2
dxnxgv5eZq01Wt3eme6MG/eOg/AdewcA9RLufZnRs3/V8e0y7MDs3bWH9w5E
3TorSX05ZPGZlRG5REaei20Eex/rXMNAEJoLBz8QXU5qgBRIKebdR5FwR6oU
MdtWroGkNqTgm1gX17zPOL/QK6G6SxfOMT5Z54WDd1JxcXL1Itl5eZB8mqwa
9M+Z16n0SuPwDYf915MRS9ud/57sJ59WE/pdKnik96zgoNx+LI4teGE9MHmU
85yKISNhMmQzulxGSDdn0Y117x/a8KE4KWPvQxjEM1PGC9bO3Kqub87cNQGV
eBn/CJUEjhxeQ6gbOF0n1HQg/U45CKk8XW+2/UY90rVtGl99x6QU7IFR/0ei
63geCbt011BCGLmkxz/GFQ+7xOgKpAT6HZrZpomY6+7Ne7wrvu077rPGbQlw
qYTRCh81+cgEb7n7myRb5kTb7GlSAdLEaqN30kvLVf9+KIp5M/6jOo3toK+1
UPANDidpEy6oYrgQ5TKAQCOdzB5mfSfj7myi8XTNI3fvgjRgzuvldHLWTzkv
nzP5Fcc3CtjFidx4TIWDowBNYQ/fnIXk1GqzVBcYUUe5DZCbO2jNHi+v9PFT
ZDM3uZUMiw/W1AEd2gVEAhoNSbST9jPJJJHYxMzQoVQY+cdhftboUlQntgUJ
hemt33264IrgIGamodDxaP6BzgyizXNYKUxTcn9wdVSzC89ZJu7qPoWh+dOr
puz5m+nxvDd0DHHpSPCeg8umqGn1r/R41p5LBpfq9HuDWIWFM5PiN+P44+Sd
KpeQSEyrz/f29oaP8Xpfg8V2ZMzYNeYc836a0efj0cs3yc7z8cvkAz5Twwap
SCqLDGwkzJ8U61+Ta4XQSukxwX9pRsbMJ53jWihArtXE12nNCUBaxzcUOi9z
bs4YoM5IUvXDyw6aAggSqCTMciRA5wPVeNTbTUjsEcGFsCMbuSMDVCBRRuvz
8U2CDR2kpDnwgwN91KSI2YK55FhL1rjbW+uAs+mWMKnAa6zDhbuTokzwFbTb
Wzn6D6SHwQjhZvl7yMFsrGktHos2LrhiMgbHtRB9mIjms8EtvugSdJHQMn5q
JamvxONokdCwpTgw2ahd/V88bVZJsvIur6tSVM2YszrR4mugt1NtDf/a03Id
5CRJVo68uOfRrpSR+JODPNGYosTduDdYsRkZRvgipz2FDpVp/0S5NR85Q/oI
nellTTtXH48ahVFh6FUboHXOVlBOY4LKcDNXNdqdSvxfXOAizdn6IiIrp5vY
fcGap8QnZB/dIzghCYPHGCYuyJGpR/lpuSzFfZK4bhMSnSxWs3+q7oXldPIT
NcNdfEKZ+Ejd4OqA4euqEARItfNKurxacj9Y2cmbrRmK+/HTxcerIMnQa8LJ
uw/QkSBNRD/FMFOY6Ss2Yd+TNk8vZi2MFS/nM4Vtkd3j2sz5N0gVClopSOsD
KIk0Ca9dHVdL6VKSXG9WQiqYgdSGHoBBWlJgkDWbXB/TT34I82iftH+7j3s7
OPwGv+RvuYxGpvHy9Ru1H12+ieKlw+QnVU40EsWz1ixzNl4M3YZDqxqGnsUJ
m8Aoer/3WsZH1VLCE1mv/K07hrNIUjbUfOZpvgNW08SJJkGgSY7iAOnVdGE2
9C8sLcPFspTihEqseTSH63kGBwnm7tw3AQjgVrivQXCbRF/mDbyvX3++Gl2h
oQJ2N3xdsJna6SGKgWDbGQaocVmKBfdWQAWKVXQ7Hmk8Oaz2YDtAOQKfj/pG
e89GbEJ5LuyQpLs+tGyn1GWkSxU1J4Uxb5pnkrgpHsh8JtVfeYVEm18VzS9M
U/aNAcQDnfKE4LwURZNuds43NVzCEyQ2VoCceQp8JGzh1FOLT1FQSzRx17pJ
55mgr6BtNBjdmguuGzT9lrWmxQ1abC2WehlfvdlHLPFX9mT7Yx1GqHaMC6Tb
LjWyVhrTN/tGs6cl2BxWya5L6XnqWFusZGtEWXuYyi528hJjZ7ijEcFvzjQX
g9VB7USy4fi3XG58ixILZD58xLXaub7+uJsIjjXdgpCsNaoSn2dwijTLXmqV
pL6VYm2yAheM6uYWSArWitFLQ/AfLNOEWwVxllE6ZaSdaP2LHEWt7KZWdEAn
7qLSIWRs5mKLWQ7lhcRhnNLoPLmcvepSZlC75WpJXKEBfqyhYm4XgHKoRSYC
3J2N7+JdOxzDvm3gclPvwXW7BrsF1Ta9Zy3CFXeCa0U4pwnRjxSwCqY0u6FA
j/8uG3MP4xzPiZlgrhq7Zds3bLw1Z9Ys4R2bO2asfheXGIt4jJTlNFI6iy5s
pa89OnF5XfBZIKMlLh4iiV0ADwNmX/j6e0auKQJEW2smo7zXEOfEQI40THfU
4YBeceayogIJK/cZ/ou7n9ZNYJNoeeXQaGskcKZQXlLudymyLdA3rhdBWT23
nW/Xs1zO1gdhNS5kIEmrFPa0k52Ja27uapWiIojQjSRv5A6mVlioEZ5wzUws
URkoDQIrm+ae07mxII9FgWK8y9S0cZD2rFSLyHHUxlwbbE+YE/FWa5pjY2mc
fEzxsGxLINOlmXu2kNgLI1xyvkgTU4OUPTB6yse8XH/ZysEvZ/YjnSaflLWp
bquW9DI1tYMYqlXzch49Yztxh8uYFF0kNIzw8ct899ke3OBvjiA63hgE+zTU
GsyCyd82DWhWacHeR+nb5K/RW0Gc+ym9k7KJToHRI0JFXMFcJsy/yptbbVKk
jEJyZFTOixcpDxHAQsVyqwZAZaEzKNQMJbX7DgIVN0N67xmZ0YlKTV500mAp
IFhRQ1wjHz/uA+zf0EUAC41CcPXQzzx7AqNJtTaBjI0ULpVg97gKVpE+aRx6
+0xi4lqhh0bxi6xx8lNd5w/BU7PIx2Wku7itj1kgc/sMxI3UpQ71NjlKJbJE
mYXwHwHQMU9JR3XWcEQqfLYOo1zdEwsD8mOPWSvx5yLbvnjxyVknSPqU3qN1
r+pfQjCW6LcIQ7UMO2RKSeOyStMobq6aBKdoEgltXWxN1XfXgzW0TTklXbm0
aBnjEfiDthNydV+GcKmDiiiyGVtfdG14iHwJXAwxUZeaA2j+YYmHJv9GcyoU
S7xlexG4F1HyvfjxxbkSYPNER35sB8Np8eqf9t2zwtR8QyTxf/tjDZ921p3m
A8wLzc3N2zDfXRzOTXD95k4dYzfHOOGCNy0ANtXDz829PMBYlKslDEiof1VV
rAjHIs3qCKzbLPeB8jNxUA3gxFIi06OKNZHIBlUwQh2UNL7QeoktwpWrMoJl
TtbFrTpzWFlnPujLssmIQOl9vel97VBIFePIEJIHxeTAWp0miKVLVoGVM9BZ
L6qq6THYTbOEKA+cgUFBgGRgEV9FnnXBSCYW7OBevxyDLDYGnefP3nuuji7O
WIN/yDbgs3XWaOmMpAdUYAvAcnE1LnLZiC4Zun0d8ywrnnnZqTjvc3c4GuQI
qpt/85Af2QG5mfdYnZlFCG8aXbmTrFnBTyBhjlRckKxKjkSXdOparEKgqJyj
8RiRyBqG5FRcenEppM/XGYo+Umc3il9iN4jzdbaUcuN8cbTCqeRIUmyl5Vyd
Tq0eOq4doTtx+oU9ZKJb0x7Upg/12OO6WTQh2pAsKJr3rdWDZK1OJoZrK65w
Nlp13fpTb4V7ci8M7gkaA7rC3OEd06BPDBdpnhaJyrJnI+h2awIuOqFQu7bc
cQ/WwLQ64rTNbTUtIHkSsTO6KKhtY+Nsfy/5dHUlhsurw+dv4HvQjDe+luzt
Gpz9ur838Mk6omqQ6l2ny9UIOKqxdqDZTq5C2fqx95ySA0zlO+4YhFzjEfLz
Y1Li1gSpmmpqrUfz4pYRTa4KWkDFoXc27+Zj/Mp5lPRZVWdWUdQ1VCoHgqcb
orgLwVnnZZgix2khDIYebo8A2mJEhuqTzglCxMjmXzLifi9JBIc0lIRyJU7w
FiVQpgheddq4CKGZ1DEReGwS4LEIlEkiUCZI2I6gTZ7Oe9oew7t+z86vTy+R
X3z8+fz68vPH5NPp1dXRh9Pk4vLz9edj+oCXtvf68LnPh+4Z0TBjgl87NxgO
qBx1ImPG1JkIZSgGYGO7j79nayIPcEvM3ee9QO4NwcAOtry06nh62p8UCkJk
uIDifeheFXpfosRmdRnAottH+iypK99oq4UTj6IaedCu1/nJpENLFwxeGLlw
YU4PdVEtKTrI8jvh9+pNTAvBCkrRwlBqXDRdN5PsyGao5ig3PpGioS+qQpuW
kdmsnY1g6QAkYQTEcWdZ8VXmNFo5ul2vCVhGjBxgFPlR0LAuDIdwSzWUy1uZ
MGuTnLnjKmNlipaxmvKPnQsnymDEhsJPWJqOgk4pa9vHHhkla2YBycEWDljv
7e0b+mCRtubmgKHUqzwkATZNk7khOdIs6dfrFTBhgkLEyoEJOexOK5Zl1m4u
aeWTvn2Oz/Q0XVZ6wSgqC4t0afaTrvKZAGSVbkqwwjUdLhL0MVSrCMrQeenS
EYTJBUKzh0lwCp0IS8vv4B2bkKJSWtnMcpmV1g/F7aS71XEvme6ZBYckSnqX
STEZu7BxNSHtMWuDHGbMRng5pxQqXC2UqQXjcKYeH08Sg1Bl2ZCAYu0FJlJa
z8xRzRzxMQUy5AhIoTCPjEF2MI9+j4TFYcRYLZE7whuSjd046AZVtzXRAzzD
mFvPyej9c24epjmFBZMUy739Vwz4JMo113AsJ/nNWoviOm9Vk9YKT0UX8KpW
BCITuB8KLrZCg855mteGCIBxuYJTshbUW57sIBgsZ7FrQLbClqL9T6RHOQpX
rChDWJoILOylExm9MxRCPVXnexiMPK/aIDnv9Ph8N3AV87a92H/1xjd9dSku
dL5rBal0L7pzXBDyI45MBGJtS6YpXlOAa8wZXXo7gowXPzViITcAcpbqmVS0
oTDhVmSRJERImjYOPE6aGCefOLdqq1uYtXJXIg2qWmkAgXtVB5udQTAfawtm
CgOD4nmcgY13MwQDmFLAXZ3b5G5dILlZuSDymaQ7veWo0oyYVyWCgkWK5Wbo
bzWbYlLrgKTVMvRCxDB4W11G+WKt0k1RCRnfpUWu/Z7/2IqDvhByfzu6Y4Cx
GXq9aH9RtqSw7dOFd7vHUaFgTGcVBskm61Kj23q3vd83OMSwcW68LVo5RUZg
dClTDyDphhOmB1oKsGiGrsLyYPzcKdcvX75EjreUxWOj714ZYIEcJ0SXMGlx
72jTQxLPWirJThqclh11sHUyYIcp6klqz7WwBsUnGeqZoD0aKQETwQRyx10A
tAuVdkIIgf2ohMBBPQ5Reb7Ge9VYcycjZinSkbydaACnlNGp38hWS6MlXOy0
vGGP9vYlqNjI9XU6JKGuazQZ0cT/oGLUQBNRbeEAFJ80O+yXgbHhPnr3+b3r
aXVwEOAyjg60iKD/p6+in75Si8S0sz0uc2YmmEomlXh/7rP0lmXJqKtasbHh
FT7jjwsLILrGd8KZRRIUSGZiW6XJbpYO+A7T6PJAD6ChpZ9v9pwdyEnQWauc
bGvQhJv5oYnQNOAfmuHb0xjQu0O7AiAA3M6+LFJOZ1afUtUBZF5UaABpLfws
eBzL9MFEiHqO6qUHrDQtPsoFocE6tPCPbhSrkNuU3FvSr+TGa2wM0Rnejyjt
4lPFCmyvVa1NRgFvxIGKtK4VRa7FdG4QNpSoj8HxWZGVU1rc1IOXamG3wLNK
WCIsXgt04mEQLbdeZqLQoqA+NIIa8/rLjwEZNpT8AI0qVWsBUoN34DKL7CdO
yPhMU9q5vAaKMf1ZW3oj2D0GM1auzww90qg4ZuQs/GzvU4A0wdMhxb2NSVue
ulhVjs6zAO9PSVG8+aF54HUsJRxuapi3BqbPQGXZl1be4NQTRoWSOjtAhXoO
4LrZIgFaw43iyYEHuGmJk4FwtErYA0Cy4djFxKSxBjNiCgOpaFlwPYc1SO8G
NXmDVCnjHRMVCXlZGJvmvzZUNGWrvhme0ZRkJIkODlrIl3rZkHdt1B5uj4aq
6/jocdaVO3lxC3xLlNh2V9TGmRQER+xZmgilUgAdYKmXqN5dL1deyXSPtCYo
XGe1DqTsdgY7CGyAnKuBH8Yz3EghKXIrSw7RuSQa1mRtaw5tRvu+vv4IrwAD
fv9UrUg7X0t08DnJFVZug+QoBRI0dsTU8PzgpRjhLIBXbdDB1MlkPcBQfbW6
SR5D+mRaoTQ0md9SAHzYu0UMSZgsTIAS5rdurNKTbbqKG/zKI2bDMcMQzZTz
5HANO2OpsTbAYWtxH6vJ2CDXKdJ1Dkl2PlxffdodKLfbQ1qM1R14wNlcdX5D
zVf7ES7RhzyLTi1hB1dU2rnV6Ej5oPTBbKouERnspJJYYx576FBz0ZVF9YMv
yScI5RzuoaNz+tYj7spABQzMfi3jVTr9kbZkSgyOBGBNByMK+8BtPAN0EENh
VDUOfMJgH5EoFS5h32uSnej1wNi7QR13VWv5s3mKHrpkrI9MMm9KOnut876Q
xW0PxtsJqKKaWAQRKdETWZ/C3josx3DOI4avIsYYBVMrv9ZaGngeGmX5+lmN
6Sh6Jma9G1zrbAWm09iufmGSv0WfvCnto+VimLHJPVikLEjroOMhOcyNDg2z
IFTI3gxQIKIxxPQChctNNLjufE01piAmTpOp1m5QOZx9olXzM3E2mUDwiQmG
AFKSlpbOPEsRQNlWUr/Eu21vYfrfGF/Q+89OT7m7LiCvDlSlEa1TMAeveXZF
vgf2LYNoWC35MNmotWav455LcmCGrBW3Iuf22ZigIdJXwCfKBXuE0xJcKbtg
hEv3ocmmuzvSWwzZNqtcahc001V2CCoop8SImmTbo7aTTREVdRIB4u1gWMTW
ifBAELucF/F2By3p/DulaSjZ7Az4E2nNQaMIcdf0hlpDJ84W+WvbFt/fwa5p
0Jan5yHBA1IK9jhn3f5BWAlPZSN7YHi6Hm+G5dBKspJ6+q3zVbmvIqtM3diL
rJgNHzHmpJCg33qL3ByK1sqJBbRo7pYZFtroEnl2nA1QBnN3E9M6JBXubiAp
qdZYJ8vFoNGy16O6xWIOzsGKTu4Xm8fn61vH+JokO3Vz73YAIqWoRfI6kUXZ
sZU5YzRzKYrEtdeSpSbAh5LjmvscuwAxh9t0tbkHMxAtEFWMjeCAzcSCc6kA
Iui09ABsFZUO1gYu/KG/2b5znzQnDxw/MofwsanzosfJjozQ2GS9s7k3l4fM
xuwY0VHpQqprBNuo/p9KXZfQpgONosvMFYHQgeM777fDqcTEfNMVEzITqKh3
6o8U/aTvmrriIg/pHovqxkCAIVTp7YiIwpWv/gQbx0n8MjgEbqvo6sEEgCTr
cgQtyYQTorTy1xXx30WqtdfaOsJdSmRIgbRMdDv0mbCTbIDcjFaypk9ztA+7
0MYp1fGmxEhYh3tN4EWVPbFUXK7D47ReSWvyQT+jSmswlc304EdiX5bS2mGY
TLOiWENxRQ6IK9Th10h4yDs9fa/1e5f3ci+1fUJ7gI6RbmfmDumkAjo4JSdl
LQ8sjMuqjBXpvm4i9CpFnNASGd+/3Flhsd2WekcjztskBrIsxOFj7xfkTVeG
nrJdRkODCVnelLrCAQ6511i6pSR4Gca6eMIG2L6B1H5KRdLSaySdggax4vRB
PDe00lHfUc1fFx0BKLDwSbBqSeczg3vcpbSxG1Y9FKYzSPmR3+W0ewdjl4ua
mT5X0CXf0/juSbaxEKxx3SnQLw3ZF9w37WnAPP55gJKHv99q9eeL5BOIZFFx
yRG+8ogXczNntQJQYGU08QKfW6+wCBBFAdbevObGvUQxmcZQORmF5EO2Xczq
rHdtVa41B1bWnRw12oeLX0sm1Tz/kgX+wRPJXRm9r7Ms+T/ABvdVPsUmuNgK
VNQGnbCkcLxjt2lSnNx3fulNUU004sz3B9xJeNH7gCiJo2K9WKXmHQlXdmjC
gDZa6o7rD61RODfJQfNUQUtzc9MhjNnJOEFBJ2o0l8Ehav9LJfbt4TgHgeuE
uXnAMl8vnS9+B2KRq1B994h7jlT5PGA4e7dWa2XDVgf24Ms5s4AbAwaeKl8q
FuyN1AdPnXNSSlCIoWbVuim0MoFdL0pUvKZgACRDTHDwWJCjpTO63Ei8kURF
oyTOapghM0MbIrISYN8nVpboOOrWyrTQkBfRdVdxxzs/LzfnMDTkvhdg17tX
zPqARs3yyDcSi26euzjNeiII55Xn4pwKy2gPbMESKy4DrIQHNqJzDZTso5e2
vsFG9mWRT3ILHfBbURtWoQyGfeCtkAx96Ud62b1F2rm4oxcOhdolJUPyoiLc
RVm7qbTRDTDGJYRhvk3P6uVz7Ioe+RPb4oHDn+AFbPr67FktsWaOO/TFmFG0
hIMhAgjnySudzTiPGU0KP1ZT1voG2i0Qt2WZsqs5PG0X/t4ZnDEXbTeDXUsS
DOE6LDHYvcxe4ICxhTf6hJ7cyoc4u5uJSQ1rYCm5x51/P8S2VcUAPzSL2qi+
EJAPC7joYjysiA3Hy7M1jVWeOexO1xOe/nIrf6aTSq5WBZqke6RGzsHQ84Bp
NLeweSDkVHcQnwd92gzDvAlQJd8AB/rh6C0kQinT2hZh/qr5dqes7YrxYMUN
gp5QZjek2Gryh1bVGiC6ix2GRRceLDN3vVQkBiQRE3XUpZLk6BxpDKzlAhZh
3bpguBMfsnO23zeuGY+LMQVInQ+cnite84gXOuy3hhDOqzCLwYHmSCq73hrx
Zg2YxQZHMhCV1tPPyjVRH7CbLPytlhAGgQNWvrX9psbw7l0LCR9/sNezP0rL
XS2NGTabfM4lDJp74CpXI9QqlsDMAadeWRSMEagJYX4p4rCcE8HgFVNUditp
akO1nFXDoKctsx3ZiCA3lO3bMIDGOWc4MrgRDArdcqzFTg7HlACOwSbBonA8
xuw4B+8S9X9p4t6/PLHRC/bZAKvg/Oj88wf+28fo3FLZTdpobxi8lQYWupyS
cqmWiSzVR3SwK+IZhYWeMnJUoV4qV0FvSVosn/lXnKDRZTHgxexG18t1C522
UIeRPWWXxpxiN6Vko7F2EBT+uOQpcW+79Yan8k0r9h48PpWgkbs5QLPyhg42
c9iD1l3i5gblGtzmlTUa5ZaiEXl4np5RVhUS07LGIZWt1hzMm2nQCbliRLGo
j2Qz2ZBcgoSbYNqe6ssq6jHqbowHvHX3kpiaWOBTqzWCfUjMaLoQwaV6P6r/
QMFhyVC8gUEeqnPmxH04LGHG7YkD3oB90UzzougY5K6zfVFxfkNus+U4gBbW
aPK38GbnihknH7jNUkDO4rJvM8trcmZwIIUU8cZta7jDnv0546PyAZboBKQD
Kjc58QeRNt6ZvgaygcABkHrhC/fc33Lpcr9Jmq4enb7B1jSmXSqgGi1unnNh
mVZI/XJy4V0mI2n16rRDTfsyv6pPhLtXJQYsU7bQySX3DEdANCTCP2e8Oy3p
8K90PQnkbG3ifNU1ay3uHWK/+LGxQFcQ8SuqG4CCuvcV6HqBpuKygniS3hfs
WHOXI1RaA81nW0ucyTTsoPVSA+dS13wMWgHIgeHyEkdvqyXbyeLAyJ29FcEO
m8nYsRCNqd7hxQZX/aCz2zv4si8tktGlsaCvt2WUjRgsUW9uBL0RpMuMxIUW
Qj8v01tJ+LF24EEbMN/nRDwXqeATEHdTtdTF9MJZrDhXfapAyA/KTVu1dbjH
abEThltRCJySfTf6dDGiT9jtolaSytcQx+Li6PzyA01aoqUWAdnfe4GWPfhu
RP+WVmjD5CN6HJ4ibNMOhcZ8gt0RmbTJCTs1q5q+hR4OclqrCjSTKWiUIZqK
2Q68kpWtJO729vWrLuf3kA09xIAdzakChJsUj94iASqdoegiM8AdD3/T4Xwd
94Fz/TNdABrjLosAloJSiH4wVwm6IqLI3lI24eySkXnIg0DH5k7qfFIwghxZ
RPBuARjnU5sYRZOck4k3LtQUU2acYiRVE6SoWRKyqXvai8SEV8UOhFw7AamE
geowr6ZrlV9e67KjCgJnfZPgmpRM+m2Hs9hSPdVvtP0CH7aGsEeOlytJO0fq
1lWbrQTVziGo7aAnNFJEuTf0k/7RJ4bxjlNVD7UVeXwqdiWkIfXo+Kejy+vT
y5FUgODhD2dX128d2LVHsOTX8fv8NRRT9PC1Pnp+dP3svQG6Yfhgkh8ZFsKD
FJ9ffTSQYhpAccC/6RkBZuNU61E1HxlIoH/MBn0pgx6tiWAdWDdv5GOvsRzK
wzf73ovMT/yqG/lByJv+EmLzkHhBN56wIkEgMTzgvCYeSbOE7XYNRKtuF3H5
aVulj3bdpMWuqiO/QmYw0F4I9Oz6m+RhBTfjTPlgkDXzQ9kmMqdWKlHgz6dL
Zn2vgbZiENGoqXLhS852gf4goJQaGFLR7pqwtf3b9ij9OThfDln7/ERJ3p1V
0h+dBZu3y7GNUaNHlJMGHRrqKg2cbTI0/ArOL+CjqoyaoynLmofusspz3W6X
+eKso5n2jHq5d/iSc8KSx8gmirGzjjC9ZS8lmK5uolS5cHkrwyA4vsbdQHyb
Zykzl24cDNHBiWY0AVcwKIZHznjFaGPsCvwyRZTSbtOtgUei3GbGEcAoWKLu
kADpwCXu+Pn4dlw77vSfuM27zK2rlWTKcFZgNKQPNzqVyI/tGdHW2NcY2yug
+Fta43bcaMy7iIBJEcR8JMtaf/U2+dZV/CGeFKIE8Av+Ga75DRjjzjJXsSa/
CUHBpNCc5YMks1SdtPyR+RituRwINPK/yOeKU3P26MNvY/cRr9ghwFlgkbs6
yk1HZoRGDOa4qHK1/SVX8H+7p6oq4W7JIDFuXR+zHnJPjntBuS1nzhdBE19P
ocvLQE4pETXCu67MfMrN12/oXL46TkbowGhl8zn3BXMmnOZp5GU/xhUOTgYy
XPIOWFNE7mCWsJal6xOnl7KFQWrPisGstu4t2fnjbKhTbZsgMzXC41EX41bS
04+N+TtkCGnL5AB9mGkGiV+SI9CmhmHDIQkPqiJjBADMmsjEkBnB3M1Xbyn0
ghmr74GNxqspvYuXtGZAbewwWQmH9RmYEo+ibdplrztNT9cirxkLuQISU2nC
sqoF/PXuVXIpR3NUkN2SfJbg2s7l0WfGLZdkS3eMbkGuzEnCD72nZKfB9G5v
R4qCQwJ2m9dPHuL5riUTRAbwuYgic+wB8TvSR/xmmhktQNF0huw0Km0EJQur
VOMbix8LzpMmnqUSjSky6NruxHIA3/M21GivcwejmR91zn+BwjaCCfwQkr+t
ZxNh2gW2njqJvFhVRjdnL2ReytOSxPzi8I3V6iLTptXws8tu5XVJfgXvbd99
bqIenlxKY9lzaYB7cKSuPYV9zx0lqYv+kQvaOHHN5ebKHyWDQEaRgJDgRBCh
5yvDQpTptIbU1vjMgx2GEdr0McuscEggkrBfsJmhoYFmCnzicvPWFyruGGU3
7A604A0f+K6F0zl8LsxpXXLaWaa4iJodrjxOlsF2PKrzDHiwuyzH2VsPdmFj
NGzSNV55RUUH5yWh6FD18Ao+IVaDkxNX9GcifOekukI8EzPgGxwyYM/xhNnt
qjcRrkYwckVoCqHigxgKxrnoP3BT06yDlblmPGxTiu7lO+wiBF+1+s8XHlol
IGlJZrZtVcAA64BcWoUXi1BVeCQr1zGasFt8WOMuVtKuIq0Bai1QCo68vAfl
67htwDyCUlpxxIui7x0qmsua+wQYseMl9XxJXFvn56yBIM3h1DH4YUdxDrum
QvBGs5Frfgs3LjLnNiWZD1PnbRQXbmpY9M6XjYupSguLcrCGTbITEp5gN6k4
301Ie4G5wTBKLniqdOtMHrcuZ4jbRIKFKhyAUxPAuWQcwRxztCPZbOhALqlL
DlQotVwSfb2DUN6RE0DaHZDX2BxzXUzoSvtXAah3ZThJAiyONHGgy3Oat95S
Z/AGwyQTE0eOubs78dDBjZP3Uj6xrKT/k4zQBQFpNyvXUp0tniaEjJCIt9mV
gViVnBrr1WGNbblfLKdpqVLF+blAO2JgFY2cPQZfAXTEm0o4DN8HTkmEXil1
6uq6cScZ5dPnoHavq/E9eEpiJFJs6ILc338HW49WC7zD6D1nFxoi8C2FJtmm
cj3+unP6/ruet0mzh7GWDpkSsP0+tfMVPVUC5MC9VUgj1wXa8uDsPsTtVZzk
+7d+k10Cm2tprs2YYlst6mIAt77J+CuoTAraA8CB3Hul8QovdpJJIxZwBBdk
U4YpCBbsUuWoGQtMFO3uYqAZkktu+KUuqRq9JRPfW5I2jUPUOp6Ic5xs3J1L
2qSie8lTtLEw4mMULaEQzijXHPhx6HdFRC0TxBKtd/wDeq8WoTwAhcsLxpU1
aGvRttYN3d3IwJL5hb9kbaRZ8w3naqawHE5QbUnp3NiUWb2cMs4V4+YbPgTP
5fjiF3bTc1RKZ+qsF7TuvNHKVdN5OVHU1FlLGHGm5MBBsw5ULeAUrsBm0XRP
fEQT03oopF7VQ+3ro8nlAXKyoZxhy7kjxsd0QgLp6w/vP34DrlnnqQDUrPNN
3EVNFIqXL15rx0FOWVNUIiAHPN8bTQCaylD3wSjyQfC0pU94FyFSjGbcE8g1
u8ToGuaUAyyndiVZFZU2QpJhyzs5To6CtLEmUyxvqfaQF+WNToaNl8xwA/il
qyZbz6qRJE7DGrQMKB5AMOadhpv7xmKSy7VR2FZeDJZe8NLl5dz7nPXGv5PK
qQA3rw5fw+d0FLhkr9RSaODTQpIHrfsddPhjNPCiRV1oyI6zvCIV7M3emwNs
bLTL9gc0QNoZ4gFoiSF7FmX0YXaMxT/iCeqswx0jq+UoxjkLSwCkkqOqpJwP
tyyqmJPNaLzpG/ApTbSwHEbBe4WtJ7AH6wn7BQTBTIbGwWmCvUzUYnlbKSE0
6ev4PDjd0ZEQd5yhLdFWv2cXJDMk31hQZsBOVmtnfSaMbpEFwV2azsgV9Sp4
knkqBJMAQCXEXTarVuk8vApvrGL2M2i7ydot+gGTsrypEC9ZIo705SIrVvpN
B/pIvPm2gW7ZZpy60+OwhK+oh5ajeSgOakO0D60gZ5hNqHgSz3BihJemYZNX
z+ED5+2HGbaF6N24tn5iDFUw7QVH4z7I6GFe4CbqlgK2am5KDpqTJrj2vMS2
Qd0N2v07BPB1MPmBW4EHclk4pmkYYqjlmAQnJ9ePT/70b8gROoYc8KHQS023
3Tk9/nQhJiHaJydHujyWjB+PPuzufhMSIofUFQnXU5IkEj7GFYWkPFlaLZbW
mrhMec6kjCg/464eFZfzMaC3c1VogqEdIsph8rDBW3mjvaQYHu6+CrQn6Cu3
2aIqoFKr4ndqPDv2GL915Qodwu70KPdYadHVkeqeEGi7h8ORGdWGUqgjqFyV
kRbMGNPErb3eHr8MKsbU6HfyyLhsDCUdT0iH1dkpbEzwc67/mTM5s6bLRijE
T0BSISOUhCSbnssJVsw+V6wX94lxx8gLR1yKfd7AVaBbl5aICrFa3WpujUFJ
9hTF7EjyG2KWmHzP7x0Z2qWHrp6lLahglz3RY8vhcfpSWtcb76b1Rx41zjV2
tXXoyI7p97AvqtxBl5qxB1x/oKMpPkWQuqwNurXJTZQP4bCBA0kPgpjks0Zq
7EkWz5SZak2Zz9nvqg9ygwPYqbDwPPgxozdxMjYX1qJjj0pN1bvFq0cmVToK
WbLDP6rTPEprUQny0EYG90QhGqS6zJAxwaZ7mtw5cHf5ncE+O7gKLlV+4ha5
y6qhptDfZK6YAJ+b+YYGnFyROsMfKzYE2zp/N3GSRg9utYFixA3phtURbiwz
WRRDd3GpWsQ+z7t1oclOAAb6DGm5+WxWZJPqS9bsOupzfW0DlmHrk4LVDa8j
YoHMxHghD+SMqaNvWkDFnYvm6jQsXUAgGfVejJNfDOAG4STdbWtJmfdsW1N5
ZhLXNkvFvCSeRhlpZODMfLJ+67qP5ZaGWGhrjSBW7fA8ptarKfRujeNTZyNT
tsuiT7F6GCZxTkLowL/5HvECRi5WOgg0LEAYhRlG3K9BKzK73ZIVp8O8wkPn
tFcZ2lHPPck/loe4re6m5rNHATMSgM2oEjrB/NeCj2EUPlYlptCmbz6T39pC
aX8PYFcwSiMGUBdW0Mum4y0KKCq4GU72GEKZXQsma4ajCizooWZxtkLY6QzR
IoaFnHuLW1IqSetj35wPF0lYxxCZBaYpFzwEbZ8rSCl+okMHnwQdTsCL4RmQ
dDkMGbH+UHFw/nVLrvAHapJy49uCielEzB13D51QXWvMmdlOauTkLp9bYaAj
C32F5hCt+DwipumNMzH1Qp1DoPEtW70Djd19MCAu+ikPA/8Rst7gYdZ4D8cT
hOnrwKrqqYiAWFBgf2Nnk41/8dDH0KV7UNDqG3nuUl7nxFEwJ9GHGzgDzmMg
WMdKNG1ZOSxzqWzJ8XxtjOqjAvw6lgzMuGm/uCzfEqbF4RBUdAU99mAncl2l
zGeZwhvl0VjE+S2ooeaQ8EjNxNpWYHGwPdkdZC3RxOSiDV/osRnmWHIwauHg
i/i681bUmesnlorZhlnd5VUROnbUZuOUMqcqsCQPanl8v2DInshxZoApHlzE
9KBGfco6nsLhhQ1el4w6iE4CheYgS/vJKuk6e53m5jPRAtxtLU7m2YN5PXM2
bAQi6hgpGR/xVDrc04Fua2pqCIGZM4AL8/Y40dZvVzVBnEYoTRpvwZhN69jR
Eb82wnXW5bLUAr0jrZszfluvSgylxITDTYJurOkWW2LH+aI7KL11NjJ9Mjbn
gxZDO9ruSRvbqDBxPddlohy0Nwe8X+xUs3PSMN9osa5nCrfuTliEbx4gY2y0
+WKH91g3nW7vJGfTCK8XOMapRATVdUYzG9xorAswbh8uT4+uTpE1KeUW4jVV
l29guZJcUnjQuLwNaFoZzjgPWaeCs92nmwDV6AFP2xh0qDgEe4cOq1fOMMDt
E0XM0XDXyyj9geBHs5KxoLDVsR6zDbeg97wS49pryVYw4R9dnAUmnrITc9+4
XrHeSVRLddXGnxTrDU7cS4sQcWvC2eoqyuhFjbU3VPzhvIlby1iltlrtygPV
zZYFiMzEaYRsf/7l7Bjthen/Rr9+gDcUlepN0I+dbR+H16eZImyQQfwFRYKT
SjsDCB0sK7JTpClUmd0bCJTCLD2kZxoyxjdCo3/9IZuWT7v1v3E07+2/3M4B
+BmetOSTawbOKw3GO0L41xo6RyE0yT9+AfrldGukKxKHSAupW5996/To19Y9
+/nLN5pSjnUfqaWOs/7jYwmePMc44uy7y4ylcGUtpWU/WYz8Na0ZlRpFDexw
//r1jhQzsp5pCPjXm4KzFV/xLr3uGRyfn0QttGheqBiFIfOePp5pKCVEmWJ0
H0s/RrRymf5W1Raf9Rjzco/Zicp9xyUNeDtVVmLE3Mw2nQVgZ+glNm0NsdXt
o8eM9wCETRWgImuKkqZvcUcOwSKuGVDWmW5NFg4Lkd+aWEs5Vsr+d9/zLXde
PddBm1jToKimt8R7B0PF8IY1PioEd4o9ScuqrMBsDNuevcGxm5BFJAZjhFj5
gRtQf19niP8zhiz/PC04sCd/C5IPjxh3lhnr8YVwhm0EBjpMBkfSYL17uQbJ
ztHPn3a3etpEgiyMD9GvmRWRbYainF69jOHwfIQkauUihaJqYOlxBamT7PpA
jlMD/6xiXSdo4ahkIO02ZwHQ9RaxCU+VcidGvZAMWt4cBdJihGoRtkqCvGH8
sah4ZkKSsRP1/B4nlwJrdMoX5SSzNtE7l6cnu9q+OBOjbWXsJ8KrOxK3ZslQ
Uirehr4LkhAhDWa3Kd5xWZJMGsSGBuip9JmfCRnpbjVSosX05zf0PoyTkeos
BYy2/8joYmOpsWZd4oGwcwoY7Pj/ktz/Jbn/cpL7/rtLD7YYqCFB83bGprBu
6yH3LwPh3AgImvJ9poEHMkL8svlglFGLyFnnhbpoqsDacaMK4j7SKBRkGLs7
Zx7eiLuimrL6OYth+/m9+iL8ipN4ISxrBzTvfiY9NbkVh+snZCTsW6ZKgS/d
DHaVTdZ1g+BJXcOd0ASJsWLkibGly1DbSrE/pHpf7NBT1w7RFbGItjTsBewM
VCBVoW+RIS8VFaqV3GshikvriRyFDa7DwhL76EvxAIuPiAMyTx77MOjqwMsp
pcO5L6DiU8D8/idY1qbbb4SfHEjrtHqg02sEgMrtItt8SOALu2Na18ZNNJQr
ovcefB4LT+vyeLd+KZnBLNW/gUe59vlI3I3wF1UoiWfgpTCvhRGsp2sx0iUw
VNUb23CDomkMSsjCuLNU7WVO2TDUDFUGPWvuuH+t2llIGaoJq82iU9JUwlfv
wADdjVugSuVNd1DPUTmJNF3B2z/zjdtciz8r8P769Tj8iNXkylmBrOUuVwuy
vhu3R5a1bIiRumXfXtSkKM2MvSooBADWa9aTEVaNcxnxssMC3jKZFrlURW5/
pYQnp8AMOfq6z6eCkuii581LLiMIIXED2tfjQEyeMdXQeQhg9XgxsWQkEnDN
R4AM3T0ghGWDK8QnoL/Rn2hLt0180zLnAvUBs97uuDtfv7LsO5rRnaBNsWzy
TZRSvGA/LaoRXNpcoih08GLSIO/pZBh8PhiB/YDhMJxbqdZ3kO3pE9FDTUW7
9XKNLfvG0CybXWPuCXrv2UlzjWFpIy3RADPQvgHhY64UglZsv7RHaRSeth7i
xrQMKS8SexFHKaaQqwiRE2EDLkCd1bTFYP7xGue+QVusjW1VmsAeylkKSzHG
4FsM0IHAFIVG6FiKic3n5lDhjQqzoWhjYT6k6hZ12iyGLgi3SZr0PplAkVGz
2AOboOvE5ysSvK35C/ZeH5LMesbpKtdq0B7DfR2mYjx/+WrPdz0IZB3UNq3k
FL1l4B1K6xKGMSC0LCKgnvSu542E4VbDhdjKF4F0Fta5faD/wIo+ySwJn2G9
fth/G8LSSGJoteI6WuRACPIEi/kHf8WFh2Ot7E6tIIbd+Kw0mHNCLeTT4+ud
vV3Yq/jX/m6yYx3usOr1FMIO+TkscDxsW1BrsOu8xrOhg/iqua0JTeMYQIyt
xMiti722wZFgxE6TT3cdlmBMoDF8LMZYlwZt6xtLc7G5C+M5B4e7EkJ6wJ1Y
hTcNaD206zMGxmPlpdZcQEvt1w0WQdW9Ov+aayPhA1IsieVL8MvYiKshldTW
1tDHwkkMneIlqqQtCXsULB+zuVE0JXbgzjJA+LtuVosYiTcr0aGJjp8lPdRi
xn1T0DXXnMLAUZy2tuv4a503tz1DaRhuI+QhpoYuVt4iPu9Qhd+VJQagT226
ida5VZ3IuryIJPoFnpZC5WnK7BH4kGC6j+PxfJ5rSCrWTrxy1qOm4FWIQ3FX
Hq6kzMvArpETVOx59aDa6W+qNXzWnHwnHZFUjOMLjElvWkkVfqf4d7IWJLYZ
c5KGH+BUK5QH8hYjZWOoHBdEov1D8C7HeRozwtjLFt77WUTFNHqtWSyx7opu
UiMF39zuR8mnJQ/3Kb4bjtfyMoF0tKFjkHQSFu96ckMNFdyxDeAFZK1h1hHT
GldP+8i4k7fwctxXtvvDRBoSt9UN91IcBs1u1stlWrOOA0xFbOdNpu6JBTuu
6W34BAmLOCNtL7OFVmS6Gd95RSXaFzmUhQGab3kFaTRApbTKL669pR+xnu86
R3W1A8YUqUT3Y+y/sNjBA61Z9wkH4NfvHdEIyNnoZJxn7XxEc5mO3K+R6ej8
uB3lhSZH95tEkHaM0QQba3phecNttZ4uJI+taQVHdmtJCMqL2HI1ufN06lH/
mINvd1yQE/pVO505W51rVLj8ZRl2OsGhdZXk1Fo4a7YqOIrqChEpSo7Y/6/u
dXKt1bPq1w8tGabKoMlhCQSp/reMk6CHQZnhBwAboacGioZww+Q4MJmvcGtZ
WjZBRoAi4jNOOYtMnj5IjNkAuvkF2VXDuBxd0GYUktBlNDdBLIN3iwk2SNHK
G9cs8QaycybtKf4/yOyk9xt3K5tkHoaRjWKrJt5INZrmB0X3NZSgfS/QYsFa
suOSNIx/dt83mMD5RSabu5BLotfFQC35cEUCnWW4zeuyn0pdN2PxZ8pJdM9K
b7ovQqOviIBEV2Ll55uEAF91VEYgeLPpygTUaDMhaqkm2nF6Q0dAcvn4udci
7cBKLugkYwRMReSJL1K0bFlFx6vgAIPQozFTH0oZeTPM384WY7kx3hHIiLkv
Ig/jzKiONRgmn+Ydu/WHkQNvbZW+YRmO5sOFhXWRBqQpaMsmQwXtOHmnOHs/
Ng6olL1M3k2K1fTxYt+cTCyKvPxmd5J4hXxnvuMIrtAZIuZEcqZds3WbNccr
cnCl7OSQksFu7nKnCwT7teh+ocYHfFRjmpIFoZOzWjZ9RAFk57FrkFGFxfeP
ouCGNQwwGM0wZ8SmDqZYsJZz37Yo7N/89GyEHQSIOeFG6mFz7l9QJp8bCnpg
L4uiHab3crBcFHnOn+LcnKWe3NnR+dGTp7akq91I3x6Gf2Dpjid1kKMphCkp
GVK7JUFYuZdLlNPn2g2ezLXr56Td0NnRPwIUbbl/Hyp4rt+neb2AX94AfnsH
om0DGoQMpn9sDXhJ372rAAk4fmSon0n5uh1doT+VDBd8IBCKnWE/kURNUY8J
zLA5RKxmLrofaTjGXPLWvi3yrwqP1g5f2Sy3HvcP7VzcdpKXvd0Q8p/ZUtcT
mwd/uot2911XKwiNOjlJ74n+xVmvcNx65ozbyLEi7dncmYcSMqcsOWCs8BWn
dX6bnFf1jCTIrfYEhv5xIyDW0nzxgak8sGqGeeTpBVCOZz1QjtvEVXBFKKdI
4l+fUlQS0wg5CeO6sITkB977/qMeYlzk2/xTR4jMpN81e+bxlJynDk8KIdci
oASU+mhGbyppJkAGGtLFmiTvajQcIEl8PP40Tn4imUKWz0lKo9K+0LkMcWLT
5C95WdJ3Qzm/ozWR1X2KdM3O2obJn6HF/VQV2Fr6q8qSa1gy/M86JwJJLmG2
0VB/yWvAvyd/qZarjH4/TD5VixR4we/oiXRGYw6jM6K/1nTN0FHxQ5ZPhlKe
1KTJaXmDbHXtf/4rkdzpbLaRa+22iHR+VNpLilarTYhCHsn1PgMW3iKmoX4M
mAI+ocyW1vkXeJAKHYot1nAAq5t1LjeL74ImJUeY0Qplmm5iYpGKdhXyHTWk
+Sw+11bn6R6zJ9yCpLEwVKyAd22tUt1UT80ROfkFN1XjjlwozIa6DBIgyl+z
asQeYy6faxLJWcW2WO1S+RsAIpO/pLO11I5eErn9mhdtVT6yiO70TgN8+c4M
HSRz+N4rAad5iOilOR+9lMfTG1PSFt+kWgfa3ucIKGvHOuQAMFYbiUu+4hhf
tvp9jlpW/SB3ImzIeJZEyxcfr+Sg33240PCMqGoF/Y/shCH6vgB1zbv6GRHB
JchCVUN0PS1Gx2QSqKo2Go2YYX7/3f8DMtixzRtCAQA=

-->
</rfc>