<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-iab-path-signals-collaboration-03" category="info"> number="9419" submissionType="IAB" category="info" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="Path Signals Collab">Considerations Collaboration">Considerations on Application - Network Collaboration Using Path Signals</title>
    <seriesInfo name="RFC" value="9419"/>
    <author initials="J." surname="Arkko" fullname="Jari Arkko">
      <organization>Ericsson</organization>
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <email>jari.arkko@ericsson.com</email>
      </address>
    </author>
    <author initials="T." surname="Hardie" fullname="Ted Hardie">
      <organization>Cisco</organization>
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <email>ted.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple</organization>
      <organization showOnFrontPage="true">Apple</organization>
      <address>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="M." surname="Kühlewind" surname="Kuehlewind" fullname="Mirja Kühlewind">
      <organization>Ericsson</organization> Kuehlewind">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <email>mirja.kuehlewind@ericsson.com</email>
      </address>
    </author>
    <date year="2023" month="February" day="23"/>

    <keyword>Internet-Draft</keyword> month="June"/>

    <abstract>
      <t>This document discusses principles for designing mechanisms that use
      or provide path signals, signals and calls for standards action in specific
      valuable cases.  RFC 8558 describes path signals as messages to or from
      on-path elements, elements and points out that visible information will be used
      whether or not it is intended as a signal or not. signal. The principles in this
      document are intended as guidance for the design of explicit path
      signals, which are encouraged to be authenticated and include a minimal
      set of parties to minimize information sharing. These principles can be
      achieved through mechanisms like encryption of information and
      establishing trust relationships between entities on a path.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC8558"/> target="RFC8558" format="default"/> defines the term “path signals” "path
      signals" as signals to or from on-path elements. Today Today, path signals are
      often implicit, e.g. implicit; for example, they are derived from cleartext end-to-end information by e.g. by,
      e.g., examining transport protocols. For instance, on-path elements use
      various fields of the TCP header <xref target="RFC0793"/> target="RFC9293"
      format="default"/> to derive information about end-to-end latency as
      well as congestion.  These techniques have evolved because the
      information was available and its use required no coordination with
      anyone. This made such techniques more easily deployable than
      alternative, potentially more explicit or cooperative, approaches.</t>
      <t>However, this also means that applications and networks have often
      evolved their interaction without comprehensive design for how this
      interaction should happen or which (minimal) information would be needed
      for a certain function.  This has led to a situation where simply
      information that happens to be easily available is used instead of the
      information that would be is actually needed.  As such such, that information may
      be incomplete, incorrect, or only indirectly representative of the
      information that is actually needed. In addition, dependencies on
      information and mechanisms that were designed for a different function
limits
      limit the evolvability of the protocols in question.</t>
      <t>In summary, such unplanned interactions end up having several
      negative effects:</t>

<t><list style="symbols">
  <t>Ossifying
      <ul spacing="normal">
        <li>Ossifying protocols by introducing dependencies to unintended
        parties that may not be updating, such as how middleboxes have limited
        the use of TCP options</t>
  <t>Creating options</li>
        <li>Creating systemic incentives against deploying more secure or
        otherwise updated versions of protocols</t>
  <t>Basing protocols</li>
        <li>Basing network behaviour behavior on information that may be incomplete or incorrect</t>
  <t>Creating
        incorrect</li>
        <li>Creating a model where network entities expect to be able to use
        rich information about sessions passing through</t>
</list></t> through</li>
      </ul>
      <t>For instance, features such as DNS resolution or TLS setup have been
      used beyond their original intent, such as in name-based
      filtering. MAC Media Access Control (MAC) addresses have been used for
      access control, captive portals have been used to take over cleartext
      HTTP sessions, and so on. (This document is not about whether those
      practices are good or bad, bad; it is simply stating a fact that the features
      were used beyond their original intent.)</t>

      <t>Many protocol mechanisms throughout the stack fall into one of two
      categories: authenticated and private communication that is only visible to a
         very limited set of parties, often one on each “end”; "end", and
	 unauthenticated public communication that is also visible to all
	 network elements on a path.</t>
      <t>Exposed information encourages pervasive monitoring, which is
      described in RFC 7258 <xref target="RFC7258"/>, and target="RFC7258" format="default"/>. It may also be
      used for commercial purposes, purposes or to form a basis for filtering that the
      applications or users do not desire.
But  However, a lack of all path signalling, signaling,
      on the other hand, may limit network management, debugging, or the
      ability for networks to optimize their services.  There are many cases
      where elements on the network path can provide beneficial services, but
      only if they can coordinate with the endpoints. It also affects the
      ability of service providers and others to observe why problems occur
      <xref target="RFC9075"/>.</t> target="RFC9075" format="default"/>.</t>
      <t>As such, this situation is sometimes cast as an adversarial tradeoff trade-off
      between privacy and the ability for the network path to provide intended
      functions. However, this is perhaps an unnecessarily polarized
      characterization as a zero-sum situation. Not all information passing
      implies loss of privacy. For instance, performance information or
      preferences do not require disclosing the content being accessed, the
      user identity, or the application in use. Similarly, network congestion
      status information does not have to reveal network topology or topology, the
      status of other users, and so on.</t>
      <t>Increased deployment of encryption is changing this situation.
      Encryption provides tools for controlling information access and
      protects against ossification by avoiding unintended dependencies and
      requiring active maintenance.  The increased deployment of encryption
      provides an opportunity to reconsider parts of Internet architecture
      that have used implicit derivation of input signals for on-path
      functions rather than explicit signalling, signaling, as recommended by RFC 8558 <xref target="RFC8558"/>.</t>
      target="RFC8558" format="default"/>.</t>

      <t>For instance, QUIC replaces TCP for various applications and ensures protects
      end-to-end signals so that they are only accessible by the endpoints, ensuring
      evolvability <xref target="RFC9000"/>. target="RFC9000" format="default"/>.  QUIC
      does expose information dedicated for on-path elements to consume by
      using explicit signals for specific use cases, such as the Spin bit Bit for
      latency measurements or connection ID that can be used by load balancers
      <xref target="I-D.ietf-quic-manageability"/>. target="RFC9312" format="default"/>. This information is
      accessible by all on-path devices devices, but information is limited to only
      those use cases. Each new use case requires additional action.  This
      points to one way to resolve the adversity: the careful design of what
      information is passed.</t>
      <t>Another extreme is to employ explicit trust and coordination between
      specific entities, endpoints as well as endpoints, and network path elements.  VPNs are
      a good example of a case where there is an explicit authentication and
      negotiation with a network path element that is used to gain access to
      specific resources. Authentication and trust must be considered in both
      directions: how endpoints trust and authenticate signals from network path elements,
	elements and how network path elements trust and authenticate signals from
	endpoints.</t>
      <t>The goal of improving privacy and trust on the Internet does not
      necessarily need to remove the ability for network elements to perform
      beneficial functions. We should instead improve the way that these
      functions are achieved and design new ways to support explicit
      collaboration where it is seen as beneficial. As such such, our goals should be:</t>

<t><list style="symbols">
  <t>To ensure
      be to:</t>
      <ul spacing="normal">
        <li>ensure that information is distributed intentionally, not accidentally;</t>
  <t>to understand
        accidentally;</li>
        <li>understand the privacy and other implications of any
        distributed information;</t>
  <t>to ensure information;</li>
        <li>ensure that the information distribution is limited to the
        intended parties; and</t>
  <t>to gate and</li>
        <li>gate the distribution of information on the participation of
        the relevant parties.</t>
</list></t> parties.</li>
      </ul>
      <t>These goals for exposure and distribution apply equally to senders, receivers,
and path elements.</t>
      <t>Going forward, new standards work in the IETF needs to focus on
addressing this gap by providing better alternatives and mechanisms
for building functions that require some collaboration between
endpoints and path elements.</t>
      <t>We can establish some basic questions that any new network functions function
should consider:</t>

<t><list style="symbols">
  <t>Which
      <ul spacing="normal">
        <li>Which entities must consent to the information exchange?</t>
  <t>What exchange?</li>
        <li>What is the minimum information each entity in this set needs?</t>
  <t>What needs?</li>
        <li>What is the effect that new signals should have?</t>
  <t>What have?</li>
        <li>What is the minimum set of entities that need to be involved?</t>
  <t>What is involved?</li>
        <li>What are the right mechanism and needed level of trust to convey
        this kind of information?</t>
</list></t> information?</li>
      </ul>
      <t>If we look at ways network functions are achieved today, we find that many
      many, if not most of them them, fall short of the standard set up by the questions
      above. Too often, they send unnecessary information or information, fail to limit the
      scope of distribution distribution, or providing fail to provide any negotiation or consent.</t>
      <t>Designing explicit signals between applications and network elements,
      and ensuring that all information is appropriately protected, enables
      information exchange in both directions that is important for improving
      the quality of experience and network management.  The clean separation
      provided by explicit signals is also more conducive to protocol evolvability.</t>
      <t>Beyond the recommendation in <xref target="RFC8558"/>, target="RFC8558"
      format="default"/>, the IAB has provided further guidance on protocol
      design.  Among other documents, <xref target="RFC5218"/> target="RFC5218"
      format="default"/> provides general advice on incremental deployability
      based on an analysis of successes and failures failures, and <xref target="RFC6709"/>
      target="RFC6709" format="default"/> discusses protocol
      extensibility. The Internet Technology Adoption and Transition (ITAT)
      workshop report <xref target="RFC7305"/> target="RFC7305" format="default"/> is also a
      recommended reading on this same general topic. <xref target="RFC9049"/>, target="RFC9049"
      format="default"/>, an IRTF document, provides a catalogue catalog of past
      issues to avoid and discusses incentives for adoption of path signals
      such as the need for outperforming end-to-end mechanisms or considering
      per-connection state.</t>
      <t>This draft document discusses different approaches for explicit collaboration
      and provides guidance on architectural principles to design new
      mechanisms. <xref target="principles"/> target="principles" format="default"/> discusses
      principles that good design can follow. This section also provides
some examples and explanation explores the consequences of situations that not following the these
      principles can lead to. in those examples. <xref target="research"/> target="research" format="default"/>
      points to topics
      that need more to be looked at more carefully before any guidance can be
      given.</t>
    </section>
    <section anchor="principles" title="Principles"> numbered="true" toc="default">
      <name>Principles</name>
      <t>This section provides architecture-level principles for protocol
      designers and recommends models to apply for network collaboration and signalling.</t>
      signaling.</t>
      <t>While RFC 8558 <xref target="RFC8558"/> focused target="RFC8558" format="default"/> focuses specifically
      on communication to “on-path elements”, "on-path elements", the principles described in this
      document apply potentially to</t>

<t><list style="symbols">
  <t>on-path signalling, in to:</t>
      <ul spacing="normal">
        <li>on-path signaling (in either direction</t>
  <t>signalling direction) and</li>
        <li>signaling with other elements in the network that are not
        directly on-path, on-path but still influence end-to-end connections.</t>
</list></t> connections.</li>
      </ul>
      <t>An example of on-path signalling signaling is communication between an endpoint
and a router on a network path. An example of signalling signaling with another
network element is communication between an endpoint and a network-assigned
DNS server, firewall controller, or captive portal API server.  Note that
these communications are conceptually independent of the base flow, even if
they share a packet; they are coming from and going to other parties, rather than
creating a multiparty communication.</t>
      <t>Taken together, these principles focus on the inherent privacy and security
concerns of sharing information between endpoints and network elements,
emphasizing that careful scrutiny and a high bar of consent and trust
need to be applied.  Given the known threat of pervasive monitoring, the
application of these principles is critical to ensuring that the use
of path signals does not create a disproportionate opportunity for observers
to extract new data from flows.</t>
      <section anchor="intent" title="Intentional Distribution">

<t>This numbered="true" toc="default">
        <name>Intentional Distribution</name>
        <t>The following guideline is best expressed in <xref target="RFC8558"/>:</t>

<t>“Fundamentally, target="RFC8558" format="default"/>:</t>
        <blockquote>Fundamentally, this document recommends that implicit
        signals should be avoided and that an implicit signal should be
        replaced with an explicit signal only when the signal’s signal's originator
        intends that it be used by the network elements on the path.  For many
        flows, this may result in the signal being absent but allows it to be
        present when needed.”</t>

<t>The needed.</blockquote>

<!-- [rfced] We would like to rephrase this information as follows for
clarity and to reduce redundancy. Please let us know if the
preferred text is agreeable or if you prefer otherwise.

Original:
   The goal is that any information should be provided knowingly, for a
   specific purpose, sent in signals designed for that purpose, and that
   any use of information should be done within that purpose.  And that
   an analysis of the security and privacy implications of the specific
   purpose and associated information is needed.

Perhaps:
   The goal is that any information should be provided knowingly for a
   specific purpose, sent in signals designed for that purpose, and used
   within that purpose. In addition, an analysis of the security and privacy
   implications of the specific purpose and associated information is needed.
-->

        <t>The goal is that any information should be provided knowingly, for
        a specific purpose, sent in signals designed for that purpose, and that any use of information should be done within that purpose.  In
        addition, an analysis of the security and privacy implications of the
        specific purpose and associated information is needed.</t>
        <t>This guideline applies in the network element to application
        direction as well: a network element should not unintentionally leak
        information. While this document makes recommendations that are
        applicable to many different situations, it is important to note that
        the above call for careful analysis is key. Different types of
        information,
different applications, and different directions of
        communication influence the
the analysis, analysis and can lead to very
        different conclusions about what information can be shared or and with
        whom. For instance, it is easy to find examples of information that
        applications should not share with network elements (e.g., content of
        communications) or that network elements should not share with
        applications (e.g., detailed user location in a wireless
        network). But, equally, information about other things things, such as the
        onset of congestion congestion, should be possible to share, share and can be beneficial
        information to all parties.</t>
        <t>Intentional distribution is a precondition for explicit
        collaboration enabling that enables each entity to have the highest posssible possible level
        of control about what information to share.</t>
      </section>
      <section anchor="control-distr" title="Control numbered="true" toc="default">
        <name>Control of the Distribution of Information"> Information</name>
        <t>Explicit signals are not enough. The entities also need to agree to
        exchange the information.  Trust and mutual agreement between the
        involved entities must determine the distribution of information, information in
        order to give adequate control to each entity adequate control over the collaboration
        or information sharing. This can be achieved as discussed
        below.</t>
        <t>The sender needs to decide that it is willing to send information
        to a specific entity or set of entities.  Any passing of information
        or request for an action needs to be explicit, explicit and use signalling signaling
        mechanisms that are designed for the purpose.  Merely sending a
        particular kind of packet to a destination should not be interpreted
        as an implicit agreement.</t>
        <t>At the same time, the recipient of information or the target of a
        request should have the option to agree or deny to receiving the
        information. It should not be burdened with extra processing if it
        does not have willingness or a need to do so. This happens naturally
        in most protocol designs, but it has been a problem for some cases where
“slow path”
        "slow path" packet processing is required or implied, and the
        recipient or router is not willing to handle this. it. Performance impacts
        like this are best avoided, however.</t>
        <t>In any case, all involved entities must be identified and
        potentially authenticated if trust is required as a prerequisite to
        share certain information.</t>
        <t>Many Internet communications are not performed on behalf of the applications,
        applications but are ultimately made on behalf of users. However, not
        all information that may be shared directly relates to user actions or
        other sensitive data. All information shared information must be evaluated
        carefully to identify potential privacy implications for
        users. Information that directly relates to the user should not be
        shared without the user’s user's consent. It should be noted that the
        interests of the user and other parties, such as the application
        developer, may not always coincide; some applications may wish to
        collect more information about the user than the user would like.  As
        discussed in <xref target="RFC8890"/>, target="RFC8890" format="default"/>, from an IETF
        point of view, the interests of the user should be prioritized over those
        of the application developer. The general issue of how to achieve a
        balance of control between the actual user and an application
        representing an user’s a user's interest is out of scope for this document.</t>
      </section>
      <section anchor="auth" title="Protecting numbered="true" toc="default">
        <name>Protecting Information and Authentication"> Authentication</name>
        <t>Some simple forms of information often exist in cleartext form, e.g, ECN
        e.g., Explicit Congestion Notification (ECN) bits from routers are
        generally not authenticated or integrity protected. This is possible
        when the information exchanges do not carry any significantly
        sensitive information from the parties. Often Often, these kind kinds of
        interactions are also advisory in their nature (see also section <xref target="impact"/>).</t>
        target="impact" format="default"/>).</t>
        <t>In other cases cases, it may be necessary to establish a secure
signalling
        signaling channel for communication with a specific other party,
        e.g., between a network element and an application. This channel may
        need to be authenticated, integrity protected protected, and confidential.  This
        is necessary, for instance, if the particular information or request
        needs to be shared in confidence only with a particular, trusted
        network element or endpoint, endpoint or there’s a if there is danger of an attack where
        someone else may forge messages that could endanger the
        communication.</t>
        <t>Authenticated integrity protections on signalled signaled data can help
        ensure that data received in a signal has not been modified by other
        parties. Still, both network elements and endpoints need to be careful
        in processing or responding to any signal. Whether through bugs or
        attacks, the content of path signals can lead to unexpected behaviors
        or security vulnerabilities if not properly handled. As a result, the
        advice in <xref target="impact"/> target="impact" format="default"/> still applies even
        in situations where there’s there's a secure channel for sending
        information.</t>
        <t>However, it is important to note that authentication does not equal
        trust.

	Whether a communication is with an application server or
        network element that can be shown to be associated with a particular
        domain name, it does not follow that information about the user can be
        safely sent to it.</t>
        <t>In some cases, the ability of a party to show that it is on the
        path can be beneficial. For instance, an ICMP error that refers to a
        valid flow may be more trustworthy than any ICMP error claiming to
        come from an address.</t>
        <t>Other cases may require more substantial assurances. For instance,
        a specific trust arrangement may be established between a particular
        network and application. Or technologies technologies, such as confidential
computing
        computing, can be applied to provide an assurance that information
        processed by a party is handled in an appropriate manner.</t>
      </section>
      <section anchor="minimize-info" title="Minimize Information"> numbered="true" toc="default">
        <name>Minimize Information</name>
        <t>Each party should provide only the information that is needed for
        the other parties to perform the task for which collaboration is desired,
        desired and no more. This applies to information sent by an
        application about itself, information sent about users, or information
        sent by the network. This also applies to any information related to
        flow identification.</t>
        <t>An architecture can follow the guideline from <xref target="RFC8558"/>
        target="RFC8558" format="default"/> in using explicit signals, signals but
        still fail to differentiate properly between information that should
        be kept private and information that should be shared. <xref target="RFC6973"/>
        target="RFC6973" format="default"/> also outlines this principle of
        data minimization as a mitigation technique to protect privacy and
        provides further guidance.</t>
        <t>In looking at what information can or cannot easily be easily passed, we
        need to consider both, both information from the network to the application
        and from the application to the network.</t>
        <t>For the application to the network application-to-network direction, user-identifying
        information can be problematic for privacy and tracking reasons.
        Similarly, application identity can be problematic, problematic if it might form
        the basis for prioritization or discrimination that the application
        provider may not wish to happen.</t>
        <t>On the other hand, as noted above, information about general
        classes of applications may be desirable to be given by application providers,
        providers if it enables prioritization that would improve service,
        e.g., differentiation between interactive and non-interactive
        services.</t>
        <t>For the network to application direction network-to-application direction, there is similarly
        sensitive information, such as the precise location of the user.  On
        the other hand, various generic network conditions, predictive
        bandwidth and latency capabilities, and so on might be attractive
        information that applications can use to determine, for instance,
        optimal strategies for changing codecs. However, information given by
        the network about load conditions and so on should not form a
        mechanism to provide a
side-channel side channel into what other users are
        doing.</t>
        <t>While information needs to be specific and provided on a per-need
        basis, it is often beneficial to provide declarative information that,
        for instance, expresses application needs than and then makes specific requests
        for action.</t>
      </section>
      <section anchor="impact" title="Limiting numbered="true" toc="default">
        <name>Limiting Impact of Information"> Information</name>
        <t>Information shared between a network element and an endpoint of a
        connection needs to have a limited impact on the behavior of both
        endpoints and network elements. Any action that an endpoint or network
        element takes based on a path signal needs to be considered
        appropriately based on the level of authentication and trust that has
        been established, and it needs to be scoped to a specific network path.</t>
        <t>For example, an ICMP signal from a network element to an endpoint
        can be used to influence future behavior on that particular network
        path (such as changing the effective packet size or closing a
        path-specific connection), connection) but should not be able to cause a multipath
        or migration-capable transport connection to close.</t>
        <t>In many cases, path signals can be considered to be advisory
        information, with the effect of optimizing or adjusting the behavior
        of connections on a specific path. In the case of a firewall blocking
        connectivity to a given host, endpoints should only interpret that as
        the host being unavailable on that particular path; this is in
        contrast to an end-to-end authenticated signal, such as a
        DNSSEC-authenticated denial of existence <xref target="RFC7129"/>.</t> target="RFC7129"
        format="default"/>.</t>
      </section>
      <section anchor="min-ents" title="Minimum numbered="true" toc="default">
        <name>Minimum Set of Entities"> Entities</name>
        <t>It is recommended that a design identifies the minimum number of
        entities needed to share a specific signal required for an identified
        function.</t>

<t>Often
        <t>Often, this will be a very limited set, such as when an application
        only needs to provide a signal to its peer at the other end of the
        connection or a host needs to contact a specific VPN gateway. In other cases
        cases, a broader set is needed, such as when explicit or implicit
        signals from a potentially unknown set of multiple routers along the
        path inform the endpoints about congestion.</t>
        <t>While it is tempting to consider removing these limitations in the
        context of closed, private networks, each interaction is still best
        considered separately, rather than simply allowing all information
        exchanges within the closed network.  Even in a closed network with
        carefully managed elements elements, there may be compromised components, as
        evidenced in the most extreme way by the Stuxnet worm that operated in
        an airgapped air-gapped network.  Most “closed” "closed" networks have at least some needs
        and means to access the rest of the Internet, Internet and should not be
        modeled as if they had an impenetrable security barrier.</t>
      </section>
      <section anchor="info-carry" title="Carrying Information"> numbered="true" toc="default">
        <name>Carrying Information</name>
        <t>There is a distinction between what information is sent and how it
is sent. The information that is actually sent information may be limited, while the
mechanisms for sending or requesting information can be capable of
sharing much more.</t>
        <t>There is a tradeoff trade-off here between flexibility and ensuring that
the
minimality of information is minimal in the future. The concern is that a fully
generic data sharing data-sharing approach between different layers and parties
could potentially be misused, e.g., by making the availability of some
information a requirement for passing through a network, such as
making it mandatory to identify specific applications or users. This is
undesirable.</t>
        <t>This document recommends that signalling signaling mechanisms that send
        information
are be built to specifically support sending the necessary,
        minimal set of information (see <xref target="minimize-info"/>) target="minimize-info"
        format="default"/>) and no more. As previously noted, flow-identifying
        information is a path signal in itself, and as such such, provisioning of
        flow identifiers also requires protocol specific protocol-specific analysis.</t>
        <t>Further, such mechanisms also need to have an the ability for establishing to
        establish an agreement (see <xref target="control-distr"/>) target="control-distr"
        format="default"/>) and to establish sufficient trust to pass the
        information (see <xref target="auth"/>).</t> target="auth" format="default"/>).</t>
      </section>
    </section>
    <section anchor="research" title="Further Work"> numbered="true" toc="default">
      <name>Further Work</name>
      <t>This is a developing field, and it is expected that our understanding
      of it will continue to grow. One recent change is much higher use of
      encryption at different protocol layers. This obviously impacts the
      field greatly, by removing the ability to use most implicit signals.
But
      However, it may also provide new tools for secure collaboration, collaboration and
      force a rethinking of how collaboration should be performed.</t>
      <t>While there are some examples of modern, well-designed collaboration
      mechanisms, the list of examples is not long. Clearly Clearly, more work is needed,
      needed if we wish to realize the potential benefits of collaboration in
      further cases.  This requires a mindset change, a migration away from
      using implicit signals. And of course, course we need to choose such cases where
      the collaboration
   can be performed safely, where it is not a privacy concern, and where the
   incentives of the relevant parties are aligned. It
      should also be noted that many complex cases would require significant
      developments in order to become feasible.</t>
      <t>Some of the most difficult areas are listed below. Research on<vspace /> on
these topics would be welcome. Note that the topics include
both those dealing directly with on-path network element collaboration,
as well as collaboration
      and some adjacent issues that would influence such collaboration.</t>

<t><list style="symbols">
  <t>Some

<!--[rfced] Some of the bullet points in this list begin with a
complete sentence and some begin with a fragmented sentence (see
#4, #5, and #6). Please let us know if/how we may make the list
parallel.

Original:
   *  Some forms of collaboration may depend on business arrangements,
      which may or may not be easy to put in place.

   *  Secure communications with path elements is needed as discussed in
      Section 2.3.

   *  The use of path signals for reducing the effects of denial-of-
      service attacks, e.g., perhaps modern forms of "source quench"
      designs could be developed.

   *  Ways of protecting information when held by network elements or
      servers, beyond communications security.

   *  Sharing information from networks to applications.

   *  Sharing information from applications to networks.

   *  Data privacy regimes generally deal with more issues than merely
      whether some information is shared with another party or not.

   *  The present work has focused on the technical aspects of making
      collaboration safe and mutually beneficial, but of course,
      deployments need to take into account various regulatory and other
      policy matters.
-->

      <ul spacing="normal">
        <li>Some forms of collaboration may depend on business arrangements,
        which may or may not be easy to put in place. For instance, some
        quality-of-service mechanisms involve an expectation of paying for a
        service.  This is possible and has been successful within individual
        domains, e.g., users can pay for higher data rates or data caps in
        their ISP networks. However, it is a business-wise
        proposition that is much harder
proposition for end-to-end connections across multiple administrative
        domains <xref target="Claffy2015"/> target="Claffy2015" format="default"/> <xref target="RFC9049"/>.</t>
  <t>Secure communications
        target="RFC9049" format="default"/>.</li>
        <li>Secure communication with path elements is needed as discussed
        in <xref target="auth"/>. target="auth" format="default"/>.
	Finding practical ways for
        this has been difficult, both from the mechanics and scalability point view. And also
        of view, partially because there is no easy way to find out which parties
        to trust or what trust roots would be appropriate. Some
        application-network element interaction designs have focused on
        information (such as ECN bits) that is distributed openly within a
        path, but there are limited examples of designs with secure
        information exchange with specific network elements or endpoints.</t>
  <t>The endpoints.</li>
        <li>The use of path signals for reducing to reduce the effects of
        denial-of-service attacks, e.g., perhaps modern forms of “source
quench” designs "source
        quench" designs, could be developed. The difficulty is finding a
        solution that would be both effective against attacks and would not
        enable third parties from slowing down or censoring someone else’s commmunication.</t>
  <t>Ways else's
        communication.</li>

<li>Work has begun on mechanisms that dissociate the information held by servers from knowledge of the user's network location and behavior. Among the solutions that exist for this but are not widely deployed are <xref target="Oblivious" format="default"/> <xref target="PDoT" format="default"/> <xref target="I-D.arkko-dns-confidential" format="default"/> <xref target="I-D.thomson-http-oblivious" format="default"/>. These solutions address specific parts of the issue, and more work remains to find ways to limit the spread of information about the user's actions.  Host applications currently share sensitive information about the user's action with a variety of infrastructure and path elements, starting from basic data, such as domain names, source and destination addresses, and protocol header information.  This can expand to detailed end-user identity and other information learned by the servers.  Work to protect all of this information is needed.</li>

<li>Work is needed to explore how to increase the deployment of mechanisms for sharing information from networks to applications. There are some working examples of this, e.g., ECN. A few other proposals have been made (see, e.g.,  <xref target="I-D.flinck-mobile-throughput-guidance" format="default"/>), but very few of those have seen deployment.</li>

<li>Additional work on sharing information from applications to networks would also be valuable. There are a few working examples of this (see Section 1). Numerous proposals have been made in this space, but most of them have not progressed through standards or been deployed for a variety of reasons <xref target="RFC9049" format="default"/>. However, several current or recent proposals exist, such as <xref target="I-D.yiakoumis-network-tokens" format="default"/>.</li>

<!--
        <li>Ways of protecting information when held by network elements or
        servers, beyond communications security. For instance, host
        applications commonly share sensitive information about the user’s user's
        actions with other parties, starting from basic data data, such as domain
        names learned by DNS infrastructure or source and destination
        addresses and protocol header information learned by all routers on
        the path, to detailed end user end-user identity and other information learned
        by the servers. Some solutions are starting to exist for this but are
        not widely deployed, at least not today <xref target="Oblivious"/> target="Oblivious"
        format="default"/> <xref target="PDoT"/> target="PDoT" format="default"/> <xref target="I-D.arkko-dns-confidential"/>
        target="I-D.arkko-dns-confidential" format="default"/> <xref target="I-D.thomson-http-oblivious"/>.
        target="I-D.thomson-http-oblivious" format="default"/>.  These
        solutions address also very specific parts of the issue, and more work remains.</t>
  <t>Sharing
        remains.</li>

        <li>Sharing information from networks to applications. There are some
        working examples of this, e.g., ECN. A few other proposals have been
        made (see, e.g., <xref target="I-D.flinck-mobile-throughput-guidance"/>), target="I-D.flinck-mobile-throughput-guidance"
        format="default"/>), but very few of those have seen deployment.</t>
  <t>Sharing deployment.</li>

        <li>Sharing information from applications to networks. There are a few more
        working examples of this (see <xref target="intro"/>). However, numerous target="intro"
        format="default"/>). Numerous proposals have been made in
        this space, but most of them have not progressed through standards or
        been deployed, deployed for a variety of reasons <xref target="RFC9049"/>. Several target="RFC9049"
        format="default"/>. However, several current or recent proposals exist,
 however,
        such as <xref target="I-D.yiakoumis-network-tokens"/>.</t>
  <t>Data target="I-D.yiakoumis-network-tokens"
        format="default"/>.</li>
-->
        <li>Data privacy regimes generally deal with more issues than merely multiple issues, not just
        whether or not some information is shared with another party or not. party. For
        instance, there may be rules regarding how long information can be
        stored or what purpose that information may be used for.  Similar
        issues may also be applicable to the kind of information sharing
        discussed in this document.</t>
  <t>The document.</li>
        <li>The present work has focused on the technical aspects of making collabration
        collaboration safe and mutually beneficial, but of course, deployments
        need to take into account various regulatory and other policy
        matters. These include privacy regulation, competitive issues &amp; issues, network
        neutrality aspects, and so on.</t>
</list></t> on.</li>
      </ul>
    </section>
     <section anchor="acknowledgments" title="Acknowledgments">

<t>The authors would like to thank everyone at the IETF, the IAB, and our
day jobs for interesting thoughts and proposals in this space.
Fragments of this document were also in
<xref target="I-D.per-app-networking-considerations"/> and
<xref target="I-D.arkko-path-signals-information"/> that were published earlier. We
would also like to acknowledge <xref target="I-D.trammell-stackevo-explicit-coop"/>
for presenting similar thoughts. Finally, the authors would like to
thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark
Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew
Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, David
Schinazi, Cullen Jennings, Mallory
Knodel, Zhenbin Li, Chris Box, and Jeffrey Haas for useful feedback on this topic
and this draft.</t>

</section>

  </middle>

  <back>

    <references title='Informative References'>

<reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793">
  <front>
    <title>Transmission Control Protocol</title>
    <author fullname="J. Postel" initials="J." surname="Postel"/>
    <date month="September" year="1981"/>
  </front>
  <seriesInfo name="RFC" value="793"/>
  <seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference>

<reference anchor="RFC5218" target="https://www.rfc-editor.org/info/rfc5218">
  <front>
    <title>What Makes for a Successful Protocol?</title>
    <author fullname="D. Thaler" initials="D." surname="Thaler"/>
    <author fullname="B. Aboba" initials="B." surname="Aboba"/>
    <date month="July" year="2008"/>
    <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>
  <seriesInfo name="RFC" value="5218"/>
  <seriesInfo name="DOI" value="10.17487/RFC5218"/>
</reference>

<reference anchor="RFC6709" target="https://www.rfc-editor.org/info/rfc6709">
  <front>
    <title>Design Considerations for Protocol Extensions</title>
    <author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
    <author fullname="B. Aboba" initials="B." role="editor" surname="Aboba"/>
    <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
    <date month="September" year="2012"/>
    <abstract> anchor="iana-considerations" numbered="true" toc="include">
      <name>IANA Considerations</name>
      <t>This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations.  It is intended to assist designers of both base protocols and extensions.  Case studies are included.  A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6709"/>
  <seriesInfo name="DOI" value="10.17487/RFC6709"/>
</reference>

<reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973">
  <front>
    <title>Privacy Considerations for Internet Protocols</title>
    <author fullname="A. Cooper" initials="A." surname="Cooper"/>
    <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
    <author fullname="B. Aboba" initials="B." surname="Aboba"/>
    <author fullname="J. Peterson" initials="J." surname="Peterson"/>
    <author fullname="J. Morris" initials="J." surname="Morris"/>
    <author fullname="M. Hansen" initials="M." surname="Hansen"/>
    <author fullname="R. Smith" initials="R." surname="Smith"/>
    <date month="July" year="2013"/>
    <abstract>
      <t>This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6973"/>
  <seriesInfo name="DOI" value="10.17487/RFC6973"/>
</reference>

<reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7258">
  <front>
    <title>Pervasive Monitoring Is an Attack</title>
    <author fullname="S. Farrell" initials="S." surname="Farrell"/>
    <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
    <date month="May" year="2014"/>
    <abstract>
      <t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="188"/>
  <seriesInfo name="RFC" value="7258"/>
  <seriesInfo name="DOI" value="10.17487/RFC7258"/>
</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>
    <author fullname="E. Lear" initials="E." role="editor" surname="Lear"/>
    <date month="July" year="2014"/>
    <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 has 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>
  <seriesInfo name="RFC" value="7305"/>
  <seriesInfo name="DOI" value="10.17487/RFC7305"/>
</reference>

<reference anchor="RFC8558" target="https://www.rfc-editor.org/info/rfc8558">
  <front>
    <title>Transport Protocol Path Signals</title>
    <author fullname="T. Hardie" initials="T." role="editor" surname="Hardie"/>
    <date month="April" year="2019"/>
    <abstract>
      <t>This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals.  For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear.  Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements.  In transports that do not exchange these messages in the clear, on-path network elements lack those signals.  Often, the removal of those signals is intended by those moving the messages to confidential channels.  Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8558"/>
  <seriesInfo name="DOI" value="10.17487/RFC8558"/>
</reference>

<reference anchor="RFC8890" target="https://www.rfc-editor.org/info/rfc8890">
  <front>
    <title>The Internet is for End Users</title>
    <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
    <date month="August" year="2020"/>
    <abstract>
      <t>This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users.  It also explores how the IETF can more effectively achieve this.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8890"/>
  <seriesInfo name="DOI" value="10.17487/RFC8890"/>
</reference>

<reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000">
  <front>
    <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
    <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
    <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
    <date month="May" year="2021"/>
    <abstract> IANA actions.</t>
     </section>
 <section anchor="security-considerations" numbered="true" toc="include">
      <name>Security Considerations</name>
      <t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration.  QUIC includes has no security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9000"/>
  <seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>

<reference anchor="RFC9049" target="https://www.rfc-editor.org/info/rfc9049">
  <front>
    <title>Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)</title>
    <author fullname="S. Dawkins" initials="S." role="editor" surname="Dawkins"/>
    <date month="June" year="2021"/>
    <abstract>
      <t>This document is a product of the Path Aware Networking Research Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers.</t>
      <t>This document contains that catalog and analysis.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9049"/>
  <seriesInfo name="DOI" value="10.17487/RFC9049"/>
</reference>

<reference anchor="RFC9075" target="https://www.rfc-editor.org/info/rfc9075">
  <front>
    <title>Report from the IAB COVID-19 Network Impacts Workshop 2020</title>
    <author fullname="J. Arkko" initials="J." surname="Arkko"/>
    <author fullname="S. Farrell" initials="S." surname="Farrell"/>
    <author fullname="M. Kühlewind" initials="M." surname="Kühlewind"/>
    <author fullname="C. Perkins" initials="C." surname="Perkins"/>
    <date month="July" year="2021"/>
    <abstract>
      <t>The Coronavirus disease (COVID-19) pandemic caused changes in Internet user behavior, particularly during the introduction of initial quarantine and work-from-home arrangements. These behavior changes drove changes in Internet traffic.</t>
      <t>The Internet Architecture Board (IAB) held a workshop to discuss network impacts of the pandemic on November 9-13, 2020. The workshop was held to convene interested researchers, network operators, network management experts, and Internet technologists considerations.</t>
     </section>
  </middle>
  <back>
<displayreference target="I-D.per-app-networking-considerations" to="PER-APP-NETWORKING"/>
<displayreference target="I-D.arkko-path-signals-information" to="PATH-SIGNALS-INFO"/>
<displayreference target="I-D.trammell-stackevo-explicit-coop" to="EXPLICIT-COOP"/>
<displayreference target="I-D.flinck-mobile-throughput-guidance" to="MOBILE-THROUGHPUT-GUIDANCE"/>
<displayreference target="I-D.arkko-dns-confidential" to="DNS-CONFIDENTIAL"/>
<displayreference target="I-D.thomson-http-oblivious" to="HTTP-OBLIVIOUS"/>
<displayreference target="I-D.yiakoumis-network-tokens" to="NETWORK-TOKENS"/>

    <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5218.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6709.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7305.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8558.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8890.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9049.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9075.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9312.xml"/>

<!-- [I-D.per-app-networking-considerations] IESG state	Expired -->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.per-app-networking-considerations.xml"/>

<!-- [I-D.arkko-path-signals-information] IESG state Expired -->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.arkko-path-signals-information.xml"/>

<!-- [I-D.trammell-stackevo-explicit-coop] IESG state Expired. Updated to share their experiences. The meeting was held online given the ongoing travel and contact restrictions at that time.</t>
      <t>Note that this document long version because output 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>
  <seriesInfo name="RFC" value="9075"/>
  <seriesInfo name="DOI" value="10.17487/RFC9075"/>
</reference>

<reference anchor="I-D.ietf-quic-manageability" target="https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-18">
  <front>
    <title>Manageability of the QUIC Transport Protocol</title>
    <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
      <organization>Ericsson</organization>
    </author>
    <author fullname="Brian Trammell" initials="B." surname="Trammell">
      <organization>Google Switzerland GmbH</organization>
    </author>
    <date day="15" month="July" year="2022"/>
    <abstract>
      <t>This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a "user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport-aware network functions.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-manageability-18"/>
</reference>

<reference anchor="I-D.per-app-networking-considerations" target="https://datatracker.ietf.org/doc/html/draft-per-app-networking-considerations-00">
  <front>
    <title>Per-Application Networking Considerations</title>
    <author fullname="Lorenzo Colitti" initials="L." surname="Colitti">
      <organization>Google</organization>
    </author>
    <author fullname="Tommy Pauly" initials="T." surname="Pauly">
      <organization>Apple Inc.</organization>
    </author>
    <date day="15" month="November" year="2020"/>
    <abstract>
      <t>This document describes considerations for and implications of using application identifiers as a method of differentiating traffic on networks. Specifically, it discusses privacy considerations, possible mitigations, and considerations for user experience and API design. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/per-app-networking-considerations.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-per-app-networking-considerations-00"/>
</reference>

<reference anchor="I-D.arkko-path-signals-information" target="https://datatracker.ietf.org/doc/html/draft-arkko-path-signals-information-00">
  <front>
    <title>Considerations on Information Passed between Networks and Applications</title>
    <author fullname="Jari Arkko" initials="J." surname="Arkko">
      <organization>Ericsson</organization>
    </author>
    <date day="22" month="February" year="2021"/>
    <abstract>
      <t>Path signals are messages seen by on-path elements examining transport protocols. Current preference for good protocol design indicates desire for constructing explict rather than implicit signals to carry information. For instance, the ability of various middleboxes to read TCP messaging was an implicit signal that lead to difficulties in evolving the TCP protocol without breaking connectivity through some of those middleboxes. This document discusses the types of information that could be passed in these path signals, and provides some advice on what types of information might be provided in a beneficial manner, and which information might be less likely to be revealed or used by applications or networks.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-arkko-path-signals-information-00"/>
</reference> showing editor role-->
<reference anchor="I-D.trammell-stackevo-explicit-coop" target="https://datatracker.ietf.org/doc/html/draft-trammell-stackevo-explicit-coop-00">
<front>
    <title>Architectural
<title>
Architectural Considerations for Transport Evolution with Explicit Path Cooperation</title> Cooperation
</title>
<author initials="B." surname="Trammell" fullname="Brian Trammell" initials="B." surname="Trammell"> role="editor">
<organization>ETH Zurich</organization>
</author>
<date day="23" month="September" day="23" year="2015"/>
    <abstract>
      <t>The IAB Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich in January 2015 and the follow-up Substrate Protocol for User Datagrams (SPUD) BoF session at the IETF 92 meeting in Dallas in March 2015 identified the potential need for a UDP-based encapsulation to allow explicit cooperation with middleboxes while using encryption at the transport layer and above to protect user payload and metadata from inspection and interference. This document proposes a set of architectural considerations for such approaches.</t>
    </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-trammell-stackevo-explicit-coop-00"/>
</reference>

<!-- [I-D.flinck-mobile-throughput-guidance] IESG state Expired. Updated to
long version because Yanai's name is showing as "R.B Yanai" instead of
"R. Bar Yanai".
-->
<reference anchor="I-D.flinck-mobile-throughput-guidance" target="https://datatracker.ietf.org/doc/html/draft-flinck-mobile-throughput-guidance-04">
<front>
    <title>Mobile
<title>
Mobile Throughput Guidance Inband Signaling Protocol</title> Protocol
</title>
<author fullname="Ankur Jain" initials="A." surname="Jain"> surname="Jain" fullname="Ankur Jain">
<organization>Google</organization>
</author>
<author fullname="Andreas Terzis" initials="A." surname="Terzis"> surname="Terzis" fullname="Andreas Terzis">
<organization>Google</organization>
</author>
<author fullname="Hannu Flinck" initials="H." surname="Flinck"> surname="Flinck" fullname="Hannu Flinck">
<organization>Nokia Networks</organization>
</author>
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher"> surname="Sprecher" fullname="Nurit Sprecher">
<organization>Nokia Networks</organization>
</author>
<author fullname="Swaminathan Arunachalam" initials="S." surname="Arunachalam"> surname="Arunachalam" fullname="Swaminathan Arunachalam">
<organization>Nokia Networks</organization>
</author>
<author fullname="Kevin Smith" initials="K." surname="Smith"> surname="Smith" fullname="Kevin Smith">
<organization>Vodafone</organization>
</author>
<author fullname="Vijay Devarapalli" initials="V." surname="Devarapalli"> surname="Devarapalli" fullname="Vijay Devarapalli">
<organization>Vasona Networks</organization>
</author>
<author initials="R." surname="Bar Yanai" fullname="Roni Bar Yanai" initials="R. B." surname="Yanai"> Yanai">
<organization>Vasona Networks</organization>
</author>
<date day="13" month="March" day="13" year="2017"/>
    <abstract>
      <t>The bandwidth available for end user devices in cellular networks can vary by an order of magnitude over a few seconds due to changes in the underlying radio channel conditions, as device mobility and changes in system load as other devices enter and leave the network. Furthermore, packets losses are not always signs of congestion. The Transmission Control Protocol (TCP) can have difficulties adapting to these rapidly varying conditions leading to inefficient use of a cellular network's resources and degraded application performance. Problem statement, requirements and the architecture for a solution is documented in [Req_Arch_MTG_Exposure]. This document proposes a mechanism and protocol elements that allow the cellular network to provide near real-time information on capacity available to the TCP server. This "Throughput Guidance" (TG) information would indicate the throughput estimated to be available at the radio downlink interface (between the Radio Access Network (RAN) and the mobile device (UE)). TCP server can use this TG information to ensure high network utilization and high service delivery performance. The document describes the applicability of the proposed mechanism for video delivery over cellular networks; it also presents test results from live operator's environment.</t>
    </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-flinck-mobile-throughput-guidance-04"/>
</reference>

<reference anchor="I-D.arkko-dns-confidential" target="https://datatracker.ietf.org/doc/html/draft-arkko-dns-confidential-02">
  <front>
    <title>Privacy Improvements for DNS Resolution with Confidential Computing</title>
    <author fullname="Jari Arkko" initials="J." surname="Arkko">
      <organization>Ericsson</organization>
    </author>
    <author fullname="Jiri Novotny" initials="J." surname="Novotny">
      <organization>Ericsson</organization>
    </author>
    <date day="2" month="July" year="2021"/>
    <abstract>
      <t>Data leaks are a serious privacy problem for Internet users. Data in flight and at rest can be protected with traditional communications security and data encryption. Protecting data in use is more difficult. In addition, failure to protect data in use can lead to disclosing session or encryption keys needed for protecting data in flight or at rest. This document discusses the use of Confidential Computing,

<!-- [I-D.arkko-dns-confidential] IESG state Expired -->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.arkko-dns-confidential.xml"/>

<!-- [I-D.thomson-http-oblivious] IESG state Expired -->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.thomson-http-oblivious.xml"/>

<!-- [I-D.yiakoumis-network-tokens] IESG state Expired. Updated to reduce the risk of leaks from data in use. Our example use case long version because date is in the context of DNS resolution services. The document looks at the operational implications of running services in a way that even the owner of the service or compute platform cannot access user-specific information produced by the resolution process.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-arkko-dns-confidential-02"/>
</reference>

<reference anchor="I-D.thomson-http-oblivious" target="https://datatracker.ietf.org/doc/html/draft-thomson-http-oblivious-02">
  <front>
    <title>Oblivious HTTP</title>
    <author fullname="Martin Thomson" initials="M." surname="Thomson">
      <organization>Mozilla</organization>
    </author>
    <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
      <organization>Cloudflare</organization>
    </author>
    <date day="24" month="August" year="2021"/>
    <abstract>
      <t>This document describes a system for the forwarding of encrypted HTTP messages. This allows a client to make multiple requests of a server without the server being able to link those requests to the client or to identify the requests showing as having come from the same client.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-thomson-http-oblivious-02"/>
</reference> "December 22" instead of "December 21" -->
<reference anchor="I-D.yiakoumis-network-tokens" target="https://datatracker.ietf.org/doc/html/draft-yiakoumis-network-tokens-02">
<front>
<title>Network Tokens</title>
<author fullname="Yiannis Yiakoumis" initials="Y." surname="Yiakoumis"> surname="Yiakoumis" fullname="Yiannis Yiakoumis">
<organization>Selfie Networks</organization>
</author>
<author fullname="Nick McKeown" initials="N." surname="McKeown"> surname="McKeown" fullname="Nick McKeown">
<organization>Stanford University</organization>
</author>
<author fullname="Frode Sorensen" initials="F." surname="Sorensen"> surname="Sorensen" fullname="Frode Sorensen">
<organization>Norwegian Communications Authority</organization>
</author>
<date day="22" month="December" day="21" year="2020"/>
    <abstract>
      <t>Network tokens is a method for endpoints to explicitly and securely coordinate with networks about how their traffic is treated. They are inserted by endpoints in existing protocols, interpreted by trusted networks, and may be signed or encrypted to meet security and privacy requirements. Network tokens provide a means for network operators to expose datapath services (such as a zero-rating service, a user-driven QoS service, or a firewall whitelist), and for end users and application providers to access such services. Network tokens are inspired and derived by existing security tokens (like JWT and CWT), and borrow several of their core ideas along with security and privacy properties.</t>
    </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-yiakoumis-network-tokens-02"/>
</reference>

      <reference anchor="Claffy2015" > target="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2587262">
        <front>
          <title>Adding Enhanced Services to the Internet: Lessons from History</title>
          <author initials="." surname="kc Claffy">
      <organization></organization> initials="kc" surname="claffy" fullname="kc claffy" >
            <organization/>
          </author>
          <author initials="D." surname="Clark">
      <organization></organization> surname="Clark" fullname="David Clark">
            <organization/>
          </author>
          <date year="2015" month="April"/> month="November"/>
        </front>
  <seriesInfo name="TPRC
        <refcontent>TPRC 43: The 43rd Research Conference on Communication,
        Information and Internet Policy Paper" value=""/> Paper</refcontent>
	<seriesInfo name="DOI" value="10.2139/ssrn.2587262"/>
      </reference>

      <reference anchor="Oblivious" > anchor="Oblivious">
        <front>
          <title>Oblivious DNS: Practical privacy Privacy for DNS queries</title> Queries</title>
          <author initials="P." surname="Schmitt">
      <organization></organization> surname="Schmitt" fullname="Paul Schmitt">
            <organization/>
          </author>
          <author initials="A." surname="Edmundson" fullname="Anne Edmundson">
            <organization/>
          </author>
          <author initials="A." surname="Mankin" fullname="Allison Mankin">
            <organization/>
          </author>
          <author initials="N." surname="Feamster" fullname="Nick Feamster">
            <organization/>
          </author>
          <date year="2019"/> year="2018" month="December"/>
        </front>
  <seriesInfo name="Proceedings
        <refcontent>Proceedings on Privacy Enhancing Technologies 2019.2: 228-244" value=""/> Technologies, Volume 2019, Issue 2, pp. 228-244</refcontent>
	<seriesInfo name="DOI" value="10.2478/popets-2019-0028"/>
      </reference>

      <reference anchor="PDoT" > anchor="PDoT">
        <front>
          <title>PDoT: Private DNS-over-TLS with TEE Support</title>
          <author initials="Y." surname="Nakatsuka">
      <organization></organization> surname="Nakatsuka" fullname="Yoshimichi Nakatsuka">
            <organization/>
          </author>
          <author initials="A." surname="Paverd">
      <organization></organization> surname="Paverd" fullname="Andrew Paverd">
            <organization/>
          </author>
          <author initials="G." surname="Tsudik">
      <organization></organization> surname="Tsudik" fullname="Gene Tsudik">
            <organization/>
          </author>
          <date year="2021" month="February"/>
        </front>
  <seriesInfo name="Digit. Threat.: Res. Pract., Vol.
        <refcontent>Digital Threats: Research and Practice, Volume 2, No. Issue 1,
        Article No. 3, https://dl.acm.org/doi/fullHtml/10.1145/3431171" value=""/> pp. 1-22</refcontent>
	<seriesInfo name="DOI" value="10.1145/3431171"/>
      </reference>

<reference anchor="RFC7129" target="https://www.rfc-editor.org/info/rfc7129">
  <front>
    <title>Authenticated Denial of Existence in

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

 <section anchor="iab-members-at-the-time-of-approval" numbered="false">
      <name>IAB Members at the DNS</title>
    <author fullname="R. Gieben" initials="R." surname="Gieben"/>
    <author fullname="W. Mekking" initials="W." surname="Mekking"/>
    <date month="February" year="2014"/>
    <abstract>
      <t>Authenticated denial Time of existence allows a resolver Approval</name>
      <t>Internet Architecture Board members at the time this document was
      approved for publication were:</t>
      <ul empty="true" spacing="compact" bare="false" indent="3">
        <li>
          <t><contact fullname="Jari Arkko"/></t>
        </li>
        <li>
          <t><contact fullname="Deborah Brungard"/></t>
	</li>
        <li>
          <t><contact fullname="Lars Eggert"/></t>
        </li>
        <li>
          <t><contact fullname="Wes Hardaker"/></t>
        </li>
        <li>
          <t><contact fullname="Cullen Jennings"/></t>
        </li>
        <li>
          <t><contact fullname="Mallory Knodel"/></t>
        </li>
        <li>
          <t><contact fullname="Mirja Kühlewind"/></t>
        </li>
        <li>
          <t><contact fullname="Zhenbin Li"/></t>
        </li>
        <li>
          <t><contact fullname="Tommy Pauly"/></t>
        </li>
        <li>
          <t><contact fullname="David Schinazi"/></t>
        </li>
        <li>
          <t><contact fullname="Russ White"/></t>
        </li>
        <li>
          <t><contact fullname="Qin Wu"/></t>
        </li>
        <li>
          <t><contact fullname="Jiankang Yao"/></t>
        </li>
      </ul>
    </section>

    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to validate that a certain domain name does not exist. It is thank everyone at the IETF, the IAB, and
      our day jobs for interesting thoughts and proposals in this space.
      Fragments of this document were also used in <xref
      target="I-D.per-app-networking-considerations" format="default"/> and
      <xref target="I-D.arkko-path-signals-information" format="default"/>.
      We would also like to signal acknowledge that a domain name exists but does not have similar thoughts are presented in <xref
      target="I-D.trammell-stackevo-explicit-coop" format="default"/>. Finally, the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up authors would like to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.</t>
      <t>This document provides additional background commentary and some context thank
      <contact fullname="Adrian Farrell"/>, <contact fullname="Toerless
      Eckert"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Mark
      Nottingham"/>, <contact fullname="Luis M. Contreras"/>, <contact
      fullname="Watson Ladd"/>, <contact fullname="Vittorio Bertola"/>,
      <contact fullname="Andrew Campling"/>, <contact fullname="Eliot Lear"/>,
      <contact fullname="Spencer Dawkins"/>, <contact fullname="Christian
      Huitema"/>, <contact fullname="David Schinazi"/>, <contact
      fullname="Cullen Jennings"/>, <contact fullname="Mallory Knodel"/>,
      <contact fullname="Zhenbin Li"/>, <contact fullname="Chris Box"/>, and
      <contact fullname="Jeffrey Haas"/> for the NSEC useful feedback on this topic and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7129"/>
  <seriesInfo name="DOI" value="10.17487/RFC7129"/>
</reference>

    </references>
      document.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAA1h92MAA419XZMbx7Hle/2KCjLiSnQAEElJV+LowaZIyqKvSPGac63Y
3djYaKALQGsa3XB/zBBizD+7b/vHNk9+VFU3QHodtmM406iuysrKPHkys7Bc
Lt1QDXW48i/apq/K0BVDRT/5tvHPj8e62vC//dK/DcNd293Qc3VdrFt5zv9X
XzU7/64Y9v59tWuKunfFet2F26vJL/VTrmw3TXGgt5VdsR2WVbFeHumxZS+P
LTf54MvHX7uyGMKVo0mEXdudrnzVbFvnqmN35Ydu7Ienjx8/e/zU3YQTTa68
8q+bIXRNGJYv8QLn+qFoyv9T1G1DLz2F3h2rK/+/hnaz8H3bDV3Y9vTT6YAf
/rdzxTjs2+7Keb+k/3l6XX/l/7byz7ubm5Z/I9P/W9FV2S/bbnflX3XVpu/b
hn8TDkVVX/nf6blVgef+EvTPq017cNMXXK/8z0VXViF7w3Uo81/yG15U/abN
hx9CuarCsP3LDv++PPK7YqxP+cDt4XDKfssjY6vDZOQjHvhLgd9fGPfNyv/H
//3vfR3uqqbMBn9Tdb8X8z99UjoHPL26GYM+PZORa9ruQJpwSxpAe047H//p
/d9/evH4u2df64/fPn3y/ZWXn//9u8fP9Nf//uw7e+K7p9/GJ777+vG39vP3
39Lv9cfvnz3WH589fpx+/OZZ/PE7+dzr5UuW+/KfY7VZHoqm2IViXdXVcLrS
Px9DtyTpLRs5NnRKSLnzE2YPsnZMT0FcatvYU0NXHA6hrpek0JubcNsuwwec
zmqgYdujPbatq2Zzszy0NJmwHPZdO+72x3FY7saqLJpNmL61bHDkmi3Nqhmq
oo5v27cH2oblfhiOy3ZdV7dVO8YZn6riph0PVW+LWw7tTZAVvaiL7fb09PGT
b694p71alwfPyxKW4lWzxzRK/z50t9Um9H5o/bAP8eBe+V8CVKD32649+J+r
fqCD/0AG60lBQg/x0IjX7/7+wn/zNWk0ffybr7vS/z30oeg2e9iybegCvQh2
7AVp/NioJVvQm6J0PRmH+Gb/riWB4mjQ3ukL2fzQ6eiq2mNR8ttkJeg/SzkR
Nxtd++S3L1f4bXdDv/w1F2MUS/ytf/n2PdnMrtgMNNPa0ytvC5oNzRV/8v8c
ee0PoH46LZrQMzebjr733cq/3+wP1TC4udjede0mBGwGG/l3+h7ZGGzRddjs
m7Zud/QZfsfqKb3r6ffLp998A7G8e9leT9bAv5CBhoDJLttb0v7rX977u4p8
wPWrV/79eDySvX3wifn+j5V/W9wUQz/eFPnvn8N+0WBl/su/rvx1P5bVTRLF
T2HdjUV3ovk+fXK25JfVrhroQ/suFMPqCnqyElGvFv4fbb3yTxf+bbvyTxZk
1En+dfBfLzy0v7/66quyXhWbw4rM2FdlW321Hev65+FQf/Xk8erJk2++/err
b75+8uS7J7w2t1wufbHuB4zu3PW+6j05vfFAB8yXZL/Hviex0u6SsMm29rzB
ZcDRh/APJPyiqfoDHYx9MfixJxXu6Pn2lg6pg5nwaiYWrL2kK7UMwq6OPEbv
oUO0tVXj+2PYVNtq42+LeizWtK5NQe9fObJmHqYPr9501Rpzysb2RU9T6Xuy
a3xCaXg+jmQT+LFQB6yoXzjM4dhW9LNvx0EmfVv1Fd6V2THShLr264AFlf5u
H+jMd74afNWTZR9CU9Kv6aWFzgBvbFretJBLi9Y0TGRadHhPHMCZoWORwLCI
bH279WYx/VSKd/uKTAbGIYPRjh2tucSaabKMB2AaAUBKljfNpB5pJwryXk11
oJn2ZDpo9GNBmiPS4r9Uf0wF0O8JCzQ7XlE/WdOmaBy9rNjsq3CLd4vZznWh
rm54et3pyIPR+6qpGXOB9p+MSb+HGjE28l2oxdfsq2NP6xnuQmg81sMzxQdZ
FivHanuoypJQgHsIk9i15Shq9PFhhX/ekw/++FE95v09yXVbNVgvyZgM6ME/
yMX6AJtpynSuQM4UiMTRlsVppny0F+2W9tRXB9myhQ8rEh05zwoSwlCOTimJ
PHwYaEUluaBl4O1JUlmf5FPhQ4EdYbEUTQ875OhAEQhsa5rATzQ3sisDtGZx
puF8Am9p62Cjt1Wo6XyR9GnV7vrFO78PBU3Ks2CAR0gwtFqZ53SL1jge2Uxp
a2hDT47kdEeOHfIiV0znDY+vvKrJAGNckfHv/Z4MoSfPX0MC67ApMDPMY3LM
cIZuCV3xYWeF1TV0gcBKRx9tWnoRgeWqsZNJ+1E0J4LIUE46XAdak+9HOhXZ
6w8tTkjRV/WJ1nes2xO/gg5844oaLpSx2YKswSBogh6UD9m5I0EDrDACwpOE
j7qW1B7m2Lmf2ztS/24hB5z0gA5SoP0Sm1KkYKTndSn2ULmIuph0SCpVx2ah
E1vosEhsAAHLYxfoTPfYILUNMBX79k5enH2Kzmw71qXb08tpdHpKbMWXevQf
TS0cnoXVaMi9Qknp+cJvQjcUZLW2Y8NjrsQn7GmfarEzMHnDqGOQVSTRQ+1P
k8FZBjKP3juxTroZaburXswrtJn0ko/m2SBxmrTGkTdJ5rtyz3vddDyWfc4d
6ICuMRSkV4eBtg4/d13Y0MmkZbYNT7es8Bv6sQsk5J60gDdaz4t3Z3Op+rNZ
kO3xBWFFwWqkaLDsZCnZXrmZ0Ttzl3cQn+xq3IGy2jIYHOIeuJrM8yCmi1VG
sbtNNBoHuBsov2yco6n14+FAOGMhkhqbY100DYs8ak2PU+7HIxQTRqeHVpOf
aMJOxBFoPpuBcKD7k/+176vtCY+ll64hSzHA+MNEBrTzBGXN36nPIeDBq8c+
kdNkN3skYESf1omStkHBxcKv2w9mTlgQcmAEamw9rFrLXqan+b0AZOJVnEin
DoQkaOdxvG9piGJXQNXUHDB8wXnvw2bsGLa08PJ3Va/zoReRKHrhF7ZpxfSe
HwsmEvRQ0wogPHLGnnHMTG3O9NGzCVeNzGdNXrotQ63nykaPHpAsE31Anb2Y
sxZyIIF2OOjnBpzAk8z/WPQ8Y3XWzk3dyJYmQELoo/iB4enfbT2KA+888DFh
B1GUQDMIjePjuw5ki82ItR2BVwAi3vQh7SepJmLu5ZoAXem2FUww44s3z1/g
BNHLettmjC2mgY/EhuIu9jakZPWC8McR++ngGOF+Zx9BgFYQ/ACo98np/nx9
/c6ZOASLksWG6/pyinrpZyilyM+QH1ljEvNRwp0gLn/XtiUEsy7KhUBDs4T9
YNu5LTYKMuH5opT53P9L4a0eOfeGPF3UvKn94I0UEBs8x9n0upo/jIWJHbtr
jY0iBbry5wDxqHHQJo86o7ljS6n42LHxJ6me4jmcYsmFujV+N3k3cpX+AZ38
Bz/wm8Zm8nZ3HAn/bT7xYvanBszx4rpO58GwTo4IX304tuJM0hmIAJn0n+L3
gp3ooW0qitHZ2Ih/JExvYQU+D+rEg38RmISf7u9FY3CSeWbr4KJ+YgGh21SI
gscOs+jZy2AeND9S+Eoinqj0SSMmMIEeoUE76CKrIBxDF1buR9rjggAYbTAJ
G5LI4GfNC2HJBTFgdCAa0kjMlffJ5OaE+DnwsSzDetzt5LMSeJhTwUwjWIEm
0Wnj6EB0tFciBMAAWoyTcICScqSmlivbIYexbed43hQ/WIBIcmwIl7PsbOCF
X9N6xUWzfztxxBExYJAonZ1hU0osR254kI0pxFlNVkRC08HtvV3PgSCLSxa5
xhM09J5PGykdHbF2Q45BlABU2v09qZmCDkV9CQnhH+0hkKg4QiIvA2QLbAAX
QnicVkhwvgztdusstDHSpBALMNmCM7HRLC2sjg7VEAIJYApHK9Z4AmA8iZF8
PmwoTaM+kd2s6Yc/6ONkTGDRSCf/UKeBiPaP0LVLAg5pdSv/FhaxrieAxlwK
Bz206rrt1U/yquaRCs2HP0v/mAzDdEFQ/ivqvsJ/5iBoYDk0gZ0AjPQ6sH1l
zxDKhVNAQO9janA4JbXOsgIVu4iVf08KTTKo6Sk7GymWYes99hNDUrZBvAL7
GtqJjmRdJIs0tEcwUKRqnVNrjCFIGHIi+VjnTgfgbENeHzZE4Aj7HkT9KWqm
TYS538nic3VbuVfpMdUK6HGr3Ir6ypq3JwcF4kqFBSGnwkfFYFELbGeiWgOo
txV4N5chuAm4wyiyT7IZjBYPBT+MbaYo6Zohva7UfXKlcQmkrC0zb/ROOggs
aeOh2c1AqC5SoGBPK6wCAE5jjlv1rBaLS3RbJB7iOA7OQvctRwMSQsfD5Cng
E6dP04nRYG5u6ZxgXmT3IRVHwooEVcY5rOYo6z//6/ULBBtkymmtQK54v0Xr
ZyEjxU6MFlIU7iaUA0yk7Ch7SZrFxCguZADszSRqUIP2+DHN0DueE+t3YA86
1ftQKlTIBRWt+4DQnN5xCBDByKd0Ji/l+ozXA2hnR5GAIeb8/khHc10NDg8r
04BoGutXR8JKTWaM5/X6pew2XImRdDQDV7cURq6LGuImw/7x42cyH1j9tUTQ
KXTkCC+XKLytrbsMkgKAf8qlVPUGiBwjr/okeDGtduVfAQw14S7+zixcH8NH
sidFHnMrTalg7q7Q49CDMxDTxr4FSRyxjaQU27HWeNKRrt/NImN2CwUsJjxZ
I7aJwDGEjL/R+OGAI5p2UZg5Zm5zEkY9mIsbazHKIumfz6iiiSeLZJr7x7u3
osuFoGlQXxQhMcwRKTGegE3teIb5gczQpMXXFLO2Q5V4IhrFDHz+5ogyLWCA
BTTjOLRpVZD22AHt+OfnbxPZHPB/a3ZNbKYYQ7p1C4VhgoGzZxzPJtEkseaY
2M6MY+7xoszEiWCwi3/+xMDJ3mHgBJscG+hdCwJ7C4sJO8zBfQZMeEQFmNHy
Ro+YIwtwIqKkh9Z09BxVTuyHooIMCLoM1PwWlNOKHJHMUcbmI6FImlQl2W/S
KBfpaaxBiTOcP/oQv7iXDE9Sp0kuX3EsWSS4XWC1os/mSOqgoTJifsivt4mu
AxMl162a7zN6CnpHqGagcGMclIpp5PwzIAHS2mwYx+A3P9BgzKIAtQ6GFPMN
kmMs7s4iCTo/BMmnr4kz0CHz+c2pt/jJqX2z7Oec0eEAT0bdQY85kZEPMUsA
qDbxpzfVMTpn/LIj9bgtmsHGFiXtg4oZisSeCnPnvc3fAx9K1uufwtFhmwML
bgF/HSrYS80BTQ2R+2sLvafB74quXLCmpAQVa22lJ+DV9U9M/rEWbdvNyFGO
MhgRqu2KI9yHABv8liwmHR2fUc/9jBJk57ceq5qfT9rMG2R4GEHGTFXNFmeG
98ICfwvsLWPaRUZCcLqJnKFx182JBWDnNU7FqY6bqWNN/41j6MhRsTnEA2xn
2zPNCh8Y04Y/e/6s2GE8xCQ1RR2Thwsb+hRTaeAcWP5/ng0gPKUsgfdPbZ5O
Gshw/hF7p/IYcRE6RkysVY0w9WeT7qrdfkh7qE6I+XTS4sBmVQyoYKXbcJJV
3FQ4uZNTQYO71+S0A0VS7Y0YqrMtEG8ZU29IRi3oI25bsWVgtrHhyBmG5ND2
g56rg5BDJIwuMkas3rz48ajw0SVdIA27RYqlbYXXWUgw3jNdHCPKKe8PlqOo
ajhR4R74TZv2yD59ahK67HSIyiXnLXAPOkSq+zKmm8/ApUXSn0q3zDK/ERCL
njNZNjHMnOIh40pGrD5ZiIQAkyKatSR0z1UZqjnz9xFhkFkGTdkItE0eFnKB
lVJ+AsxuV3EFSD77xNgw3cJ0JgWogUxjkQdOjH7PhBPTUmC5SZwg6G+ZxouE
Yh4YkKR/jGxkim9i6JxFNgsxhc9/5MRQnMR27OCLUlJbZiivEh+88v75gWJt
9VrGupKB5uFRGHV/n+LBHblcJCMI6hL0djyRjcQERR3zegIxmFlmThD/LeoT
eDdwP6PQBKIYUE9EVawP/E4UYCFBnFU7mHQ+DMi8qXg4tx8BUCw7ObnnpSQg
ePxr5GwZz/svX18/v37E3oOO3RGRHw6fsIpfP/6WXmpblEeTFCzzmWjN4BVk
qE0QQ3usNiuL4b55Jsykf/138komzEWUnwOKJkm1uzEIUdtDK/tRUjMc4ZsT
1cVn+RIm321tFHZPkt55+MaWkiPEcVBAx6c1ZY8z4rrtnPkPhpqhW2aRHZiT
sLJKFBRFZnNLqbGUijVAcAHEGc2hqpQpZcYbSO2S1TZwMtywokuzhsTTY7m2
uPzTOPQcyOgg8LhbmlJ7p7Fmr8vkTY+7xK5YYx8N/T8gUxdxUSR+zDWRbZdx
1Za4aX0GOR/kU1tMu9MqMxyrGFGyGuV+DjZC87TwPsDNgxoOCStr5LC2LYOu
UxKmRuA7UhiwWg9RV2UT+fgwE5luqQkgMT4ZhbMUnzmrNppZECNv45HpJWkm
Gs34Lw82pliJGbhI5AAW7SuKNy+xN4LtkOTQaJAhJY0xS1i0/sGcGHkghGS2
jkl+YVYRxFPOqxDIeaI260+ReMipJ/p8qMR2mreRh9NDEvpqdG+xlsJXC4e9
VDuyG0SqEekGS4fra4WIJzAgbrIe2T1lhzod2575hDx8P58605kT0UXn3cSQ
lHe28B0ZktBJfiePcynumrxlvuZCOA038/7/X6+WoNletwS5jay8QyaUkwPd
wm9JRHeADUaw4pfAKpKS9JKS9M/fvdaPkLt72w4SZDkJUycTETxHo23CUQsL
CMgpyWrQjT2b39JpX5DDRpnR1gkU2wt3ckSN7fCD4DP8isN8jhVb1YOYosu5
TbfJEs9jPVR46jSdIWxxcROg6DvOhS403J6cUomCFOzvxUbnMSrn2MmJOl5q
JyGqlphNi6Bi1VcezJyjuXA4EvSo/ohgztgvOmeEL5uTbueeADrJr8P7LCqJ
rIbLID4jSBR0+L/ClvFSbpr2Dj9BSuw+LyYRZ3k83bSphKCAtH4ulbXQO08E
chafHXTmYiPHwtsUuDakBz4lLQNfgEKCjCxnByx5rE6KbkDtIQGNaIhwXCF6
AUXCgX3IhXPGPfiXOTjnIjr6k5lt2PtA54xJuDVFCPBQnLIvZ9Dwim3Xg59G
Qo4H5TAWM5OXmW7ByYcpcuWK2H0s/AFKUSJH49P5J7KnlV7nCly1CXNkLBTt
3V53WX75RW/p96HtlODgicgMh5xnznNzeTJaOA2YKc59IRLDCCxwlQGysiQ3
OmxmkXVOmtFas4bC8BZw7z3ePHATxRoKxVVKMnUtQHqQcXhVFsBPazlNOhGq
Q7XphdgbKTtKpKcmsRee34WqXNPHvFCJXxQfjXuDyjwrzbk8hZLZbNqZqpkM
Atsug7gZgGcpqQFJNQtkWeacFz+oy3A6rNiBvm83VTHjwbjUQ4vJ5mou5mDu
NhOB3E4Si9EVG+d9BYnOP6QywInWlJrRfsBrN/nUVl6AyeTcuAMZ4n4WmfXJ
ieuMtGLiIAygIeYEIReumoameLoxL6WsLThWIB4OW822xk0BgREoInoZhx9O
x9DPNn3hJoA9btVCQw77WxY2s5XOHXUCHjCzPDedhNWTR7ArpSlpWLiaeuyN
y+BqnhkVq+jVsSPlYh42GXf79jBPX4vMQtEzrch0S0Ts02W78wLQbOfFZ/Nr
zkzIl6j/XcQk91wY/SN3iUW/PPjk/TpwGQaKfmmhnCqv2yhjihPvKhCvfaSc
Hq38jyMKmYVLXVwoLmsVSXBvRh4Pws+SKRCXG9PqyQi1fazr4RmnrVxPSkIm
lXStVr4YKZz7rjldXcBUgvGQQPzTIaJnXgdJ7pxqpHdJop/WAgABf4dJy6wj
sacg8BPK5Wx14mpf6MNqpl7O2PG8y+fjQx15yeu65+KmKbVjmD00KAITasLY
S8fBpUGbYtcFlnRkq2aM7Mpdx5zRYQQIlc8cpM5C4Jh8RsuVp1wvKVVAvC+n
8zOsP8cubYdMPvIEgFFFCfUaQhQl/WGyE1zEJ4Uf+a7xybzYq1Cd9ycUfYzW
oX4IxsVnSm4gkfllQNolOnwaCl0gDNMkkXCmkH6a/+T6jxmXvKLA6BRrZeZ5
kI6JfegXe+HGemHinNapHl0oTPjWLOyZVxQX84JixiTqYd0bsoy1ULiC+iUD
M9YEkI2RlmBCllfi7DYTD05a59aSAerokA3aB5NBsqg9CAqVAQaFhdqohXGL
1bFSEzeTB/dnFN1OpFg4k0/G4ouNOcZdYA3ntqTGSkZCFVnWiVd9PbjMXMLa
jKSQkBUbTQbMAEkbzeVUW2jCpPzHqVI0MJYMneyolaQlrSqh1b43BXNMHNcx
He9mdIbWu+05vxi4oFHqz6RwgtM9qbLOPehJfxlkPrCdyqfbp76JVnOCoTR4
Flwm+M6CbK13zVQd9YOKPVb+XSrb8o4GLFAyxP090vfQBYkHFKUvkJtGIZrU
n1th4ELJ9osWBOrEZVvbSmC+y9mQaclqZfmUfKmFWnz+BQGdEG1v7GeYGDyp
qo1U7oWIHBJRJlM4ZVR411uz3lM0w2id9gYR9EEyB9ySMvkYl4BlZXpNe5aA
cHm1uEKSrEcBdTG9Vnx33or3rWyd7A7zzmgToVCP0PQsu6EDmsQDt9hBpJHg
g9R0IzJC6jLa3lqx6mriuhi+X5pzLNCbHj+dlLW72FNf9M7SP6jsTNABMLXM
U9a0haR9Ef2LaEiDZqxHjk4mwB2+HC0+i9iNUNScedu0CN7L8IOwsxM4hUfv
kEPlpF5dI+3IXOkZRkqFiUy4xH9JVwuO0cqjpjQ5qBhNf//sMch9pXIk7yxE
1W0V7hafWX8UF1jhFrQDij3VlbZ9uKDFSRCCJSzdwLkCADnuN2rNqXJZcy1s
esJBOViQPpm4H+za0utc7LiR5J9uelwPl56P7AEkeSieLIuFBFS9kwQdBpm3
Sc/qdT4+hB0hKPUeu8l1+jzqYY7erTXrQ9Vz8Bs7CBAJHbixb+FfvXiLcjWt
pxFDqk0BIrhadWlS8K68wo7j2JhbtCq0PuHiSE3kxsHwWyyRpXPbndjCcnoU
DHUziHdXQ5B/nGcaiy5Q0fQrL1SoqpSOzvqCOKbkouryturb7uQkGq46cWvB
f9kHfcR4/Y8fxUfc3z8SDyAHUVxYFa1byh4DmcaahEKbcVyGcLDqhgC3ldqn
2FArvCIGS2f+JA2Yi1hpXZxF8OdKafBR3sddZDk/mG/l4tJGapVcup5A6/iY
ZdDlCtuSRZXbrBCGYdgUDkX4kwNCNZpQTn3bRqtBVSJpuIVjbxnOKFT4DeNY
rVa6C1/AkZbQsk5qiHwxcGOJNvrR2QF7E+o+sHxoqhRQpM5rJmLZ+ICe4GEE
vE8J5edTlz4XZaUXuqgSwAuCvER8uA/10eWFS/wXre1hkcSObCAq8TIByKsU
dLE+TV3Dyr9HgmMhCfyz2FqKBoyKVnUA/jVKpGpy/MV4vj+2Aq9hL/V0omTs
N+klctYvvR53AiBZxP3C5wXucy7YeA7HtWDSCMbhDDeedTxQ5MhuxxpWiPPW
TGJxNQiQJxl4UhMBeCVXsRVKRy6spBRtElV+kDUF5IwSkxREkyclRT2SCmlL
XX50nQUdUyQW8dBnOalZqWfE40xOiIpH+aJydEoh9ZEIzj2eEOU4Y2fkXlZa
TL70rjETkFjEs4PmyhaV79zjtpjEDJKnPS8DFNYgOm15n+uLrUZoLIJq0D7O
GAfoPqXWFpmFFLvt44u0eytS0u6MXZkTXMAYL96886HrjN7ltgzJq+JGhqp0
oLLNhjPiYdmT9Ib9SSAOI+s0zqYuqoMehg0Wwb3w3BjDBXO0vF8zDyH0uJS6
SXPmuMYEGYiS/CmWargcdzJ3lzkBLYDtOpgf3k6dbvQyfGzMLWQ7aGrAniF3
C7920lhul4wYmMxtvUNv58hIRCWtCaWsb4c10NZwphBO7YikGGxXOZTk08rG
rckrlEDxNhxpERR6Y5c4TJkku9uBL+kBkwRyRYZWmGiT07r1Cy3YkSY3QmFq
QvMyXone+xt+UrrrpsxN1WtbWyl0RiPlSep7zcRA8/PQhakoYJ1Jok1OEMGw
UG8X5x+QP2vrzZQxcjZixu3bFBjwpHnMcilOYhreVj4MFrkm59ZM21JSDQi/
LaUYGJHlBQfcnsRc5IzuyzPxWl6XeG7WhGjarRj0bBNTDHUTjkNs+yzmrNbk
WSXGtd4I11PRNFlCJNpa79OosvthuMoPLln1Tutw6GCTJ9rpK+ySBj0aENQk
WRxrQ7SeLFabiC1EfQqHDZ8g9Dlh0bB7kBsHQDlz1wNXShqmi21F8PxT9YlY
OfV3zQMmVt74XK6V+qxplfQAff6hlAFZsL4uLQqHMlzIVyhDRL/baIVMXq5P
YALiQc8VV2Zk3W6TZjjtlLsw6EJ5rwNXt+L1TssQKivJ0bgy0nYIYDtY+kyN
5olxa76MobbF0EKWwRWct7EKigO6Rk7qUhrCYlVyNVyQBZ84j9bXwop2lhyz
kiW2KhemiCQZi8DqPmcrzq6msI4EbTG1yCM/n3lhQ4ywbrXUs22W+e9Sf21U
nEwLLycdB2uP6W2rUxDoJgx8zoMgRYK7DmIeKOMQVt7ne+FkL6xTjSVOupdq
rDTT0qP0ED1jvJQ1feiuKhl6lc7aujbFMSLTrCVSlQ2OcxhMGHPLNO2X3ghx
INS9JiHmARZ3L6NAgMakMAPpEQ4kra9y05Zhk/Ny+SujiuS7ILwOd5qldWfr
yAgu7QBP5eE5FnCwPkuDyNy0z+Ys6xgVNr/NK9Xy6U1iQsM/mQEttUGeDAoe
dXx+DWkLzZEl27K5kUjqQm69OduChZsK2OpAJv2LNjUAQklaZy1VHNDKNli/
GwDML6gXZyaH447zpJjGI/ABZ6zmv4zzY5UXJxWygtMoRM4sFLHTpdJZyCmw
OAsfh79wn69PQi3DyXI5VrOSpnAh5GAhpQrmPPib7HPqMnPTWvX4WUw3pigv
9MhpOwJOU0w6ZNhYjuRaq/btxh/bvUkxnlgozYKnAEJnLcTlxcqJTBaarLNG
vJTu346MnpLgrVokUSWTDrgv1bS5rGXaekK4NE+SJT0gMscl0lQukl7GBSbN
eLRwjLomfLX5D7nNKlbNodyygwXTm2DZxuHJeIFXpnH4eM3pOKCZdHfC4jzi
n7YVahSqZNy00iLdiSBdMCjBlIsblJcoyt/HfjC55PqclXE61r1UCcS1TK9F
p7gdk+PNWAW5JtdxI1ZUhrhFiR9rjJjOfdsPeUeoClPvX9IMoh4QcUr4hNRC
ubFJV0Vd2H1M7gdvtx0IGUby7jMVs67paQpJBJx8YYHLbt6/erGcPkbwqJK+
SOaCoZTu48c/o3b/ydNn3N1tYdd48O8lX/nKElsceS1hC2CwNF0Va/x1yVYm
HrNf066kZjysmYhzMV+mcVhMb2WbpccuJsU0oZwyay7d6eWM+9UcN+vV2dUu
SURMSM8ofN7EaJqiW7N5MHmBWyjAyAwZrAvCNAMcZoeCE6m8+XFI7CdMcLbG
f7x7yw2Gd8UJeulycrnw667l2+2QgY8x62wR2eVubl52aCYrzz6OjRSBalZf
zjsppHL+Dlc17yLLomdSDmLyEGu5yi3elhedufSRhcNxiBSJBiXcQquntdeL
rxT2CAnvmCn8IFVCMCflIgZ1dn3LQhro8iviABIH2fF+cJlx0aaigDAhrxHW
K40KazaY5yxTWiLW9AWdUIqs/SvlDIvZn+Q2v9RiIA1PZdYizNBWITzfhtce
KgyAn9tGW6J7F26FBy+tYo9b36y3HZ3CCuPeD+MHJH3vZJ8AuPiGP2nbho5X
3Q7xSD79NxjsgUz9wewqPxqhDjA7zNGx9jpp7OTLANvYV86FD7EfL6afFQPn
bsZxQ4Mktu0OnH1RapUFQbZBAplI+K6LrquMCXqBvNA8JYaC3m275JwRF/Va
Qz1X7FRiGCKMunRxQCydBslojdGNXnkar8XTmtH0Sd06NSt85VItxXxZ6QqX
Oig/nGpi5rXh5hHVuZJdtAryA44480iTpdmFO55/ZYvb1mTQlT+dNQXSpOSq
ROVWJyIQvRJcIqvWYvZUd+slj27xETMhNkdrWYrzSJWKdXFitN+kK/Iki5Jb
IjCuVT/yQZdyvjXOy425dHWW6cojUsfpBYTmGxiHcRg/vRQuobVkNJ2+gVN3
KDltJWcX6wRS4HHpKquY3HRoYNcAHLdnXn+2IPwzBU7zOizHFShjVbPfn/Tq
WIu/aZZEcTETN7sQNxcV5zU/fpySp/ePpozlc7ACgW/DlnQvdgacYE7fnDWY
TpA9ClOEvpTGF+WW2ZmicFVLxiZEI2uK9AzqBSKxoigLAqVGFhBdODTd0Uya
qUpQzFgzuathcj0v/hZLAlU20xLF+0fWbhI/6Ppxi9CSQb+1QEPjzkhmHZET
9Jw2fuh11v43+IiPD2MPm4sp1cJKFrhZHhfdLvT+WK7TtQSZWPixyy5QALZk
0IMlVI3wkLsOPXq/NlycxtXD2trbi3HhMtDO2jSyq4uQg4wHOe6EnGjV/nZt
SqL1U8ym8ZzpvaEY4HPXp4nPj5sh9T7izuaARa6G06x63lLIHR/pOihLx+VM
vEiL/rrB5dAEw2mnb1TfYOGntH1WvGtVURHFDPEeuGkfI+AS+bGuWXBJ/DKW
JU6bNJNKSmqrrsRHxnG0QA1AC9fTB+a3ODkk9zIkpFdt3V2IrCJJttZ767Jq
JmE8Bi01n6Qmmkg4663jvHvpnh5YjBLWQnRjwb/ZWWchMAYDyDHdijbZq+cC
fHElIQri7kIsL9jsW5Tl8AnNr9E7L3zVcDmVpkm+cBFvrYxcsPqmWPuXN/bS
LNxw4aoNrfjgXcoLr/TKw7z6SsJWvs/0g82ZLx+OF1WkmhQ7qbERMRYBr4Pk
BEHUwzFoeY4iJNZ5HC5EfFxiV8gUoSKxljd9jQLJx2uTnfa3xsuDSQHxplXq
xpNUlTxml6RzDYCUSJVQHtxma7Vs0lOpXY1zUmN6svI7sqV4rPy92EgforRe
Z+xxJDxk9/OBVrhegwUSC5Wm2oBjL82CXGsIxQPSzJKf8b54PEohj88v3bVm
hiPfZ+W5b2qeFWYU4e2qgmW7XdpVipkr0bpObbUieUU++Vic9F4Vjy9K0M/y
deGzmidGlsZHacs+Ciw0qsBtzWTZkO73XnLtveEg4Ur5WkmpSTFrLcUhXILY
dlZEcsR8+QpiFDK9fv8u4vmcBZZLSKNMl3wrsHiCAtpLA3AnXp91GFzsjCVo
3OFiRIsc6YNFCWDBjDSXa8pqyAOmbyO5v6fnsiZ/UQUz45NyVVbM6SVQKWFb
nJUWipelba4EFB3tKzzohVz4GEvt4m7EI6hVMjHtpSqwUfqbBjGvlQoVpa0L
FsT5/Bp4wegEplgL9XYzbquRZopK89SahtVbqCB3Dk70GwPadshOecaIruTg
ZKDUvv2FRohtwVlgrNXYAoas9bttZkBFUfGrF2+xGnIjj2KKPL9siUJKK8eq
jM2VJG5ylnZlnJ94TJsG76r67Yt3jsgDc142dSOm8q6eled6H6/MntCMW463
9O7uRCDyPYteSbD82MdqJTl7dsuoePpkqB7IxWlsOsi87R/ElW1iI6CWnJYS
TEUt46KHbWUtCnYHtd0aHnebdTERvHaNpU6QVfIuBtWSx4Ni85ezmGaxKvdK
bZQgesANU0TIvb2TgrcvpId8Usj2J/8bjoxeDq6VqJNL9sE57QH01qdLm6Q2
kUsU9Cro2fG2GH9umMGVwZZMEmL0UablhBy8WAg6qzv6Aj2uVvCZ3RuQKqcH
/AQbDlHJfVES1+pZEPPl5Cu18C0BRddIDQs65+nN4GS7UYohuKUBimHXsll7
CZtFuwTcridlKK1fWZEvIXsH6Cirv1UdCXrcJC0oDW+hKaf3w+Y3p2XBpM/H
HvbBdkfNiemiwJAoGu6uqrSJB7YTxmFMNyvcoeTDvoYClS8+sUb4O1/jRLY5
frvS/T39C99TpH7g01+BxU9++juw4DnsuzmyyYuk9ZJtsL4Z5d+lanKGKzzb
pswQdxfYYYlPutDDn99eGG/lMCXlw57FCzDo8oVjEzsIKZqNIWtLXoRQ4p0p
J3veyd3vjGxKqUi2z4lg/uV3jFHMybaZhmBZ8Hu2igP5BXwBYLq89vMLn5xI
VDFGdJEWXvBL+M4V/+n1W2As32dDkXHWPTIeQodUPD5/QRwijHhlGkWdQfzP
5EYwfhyVoTLIThv6jQ5KF+DhYrokA+Y5mLBHQUBguglDaMXJBLcQaJGvkyAr
1lnjkUTYadp8eKBn1jyU+CfZw099hZsCo5ewRxb4dGHHl3CnSnxgebFt0qQR
QTiJiRviGFRI8Sjj9TnzmZpU7IYRLaGzb336iS15Ms4T1roba+7a3uHrEWmb
EV1z1uCc24Q7GFprRc6a4y9RqnYBPaFpLfHRpSnKt6ht2haOc33h8rlIU0a4
yAuaN114r1AiXkUAg0BIkf6SgSaOrbjMa8N1m0dFFMZXShhj3AKFsFwh4rX/
lMlOq0vQ6+BT3JzOYSzIli984BKKYkPPAXpKqQq+GSPsxlp4y2Tzj/LdebT2
QXmawELmODBXpbHWmM5ztBsGdaiiQ/8WfXoTRsLzwinLcqfXfT/0zzfIJJEz
2vHcpQVVvluuz/qBZI+K5gZ11h2+5cjSZ+gAihevyegkEgfX8Xu77rXwRRpo
BMzhFA/RnephmxiFlfupK3aKRrbT3ZZvqWAtIv8uB/Fffk0k6gNpK3OX9anv
isR3T8UvweEvg+DaXPA7yGX434K7S/SDyaaIYgzm+T7/XZPkQqVkLfYbaZVU
FBAHQ3ZPySf2xMmePC8pumj8TxRiB3QNXLeh4675V/TmjgKkNwwJSJ/YG/O/
b9zbdsCL98Vh4X8ZScRvVtIPTlIjPfmtGOhZ/wu55YX/RzXgYpnW/0jjtXWx
QPzUhTv3As6BL5x5VVcEGn4hQS38+yPIg45M4N0Nh8Qv9h0SOjTJn0eKLw40
wMuCImf3fkOxSPFHRY+MdU3G/G+hAcHcY5J1jfae/2iQd1r4/0modU2r+KXS
8fyP7QfRuL8R4O7Cyf9cFLEJEGH6lk7imr+hQtWLqRUn5JNd5bZy/w/wHLO+
wXcAAA==

-->
</rfc>