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

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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-iab-privacy-partitioning-05" number="9614" category="info" submissionType="IAB" consensus="true" tocInclude="true" updates="" obsoletes="" sortRefs="true" symRefs="true" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.19.0 -->

  <front>
    <title abbrev="Partitioning for Privacy">Partitioning as an Architecture for Privacy</title>
    <seriesInfo name="Internet-Draft" value="draft-iab-privacy-partitioning-05"/> name="RFC" value="9614"/>
    <author fullname="Mirja Kühlewind"> Kühlewind" initials="M." surname="Kühlewind">
      <organization>Ericsson Research</organization>
      <address>
        <email>mirja.kuehlewind@ericsson.com</email>
      </address>
    </author>
    <author fullname="Tommy Pauly"> Pauly" initials="T." surname="Pauly">
      <organization>Apple</organization>
      <address>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author fullname="Christopher A. Wood"> Wood" initials="C. A." surname="Wood">
      <organization>Cloudflare</organization>
      <address>
        <email>caw@heapingbits.net</email>
      </address>
    </author>

    <date year="2024" month="January" day="11"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 33?>

<t>This month="July"/>

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

<keyword>example</keyword>

    <abstract><t>This document describes the principle of privacy
    partitioning, which selectively spreads data and communication across
    multiple parties as a means to improve privacy by separating user identity
    from user data.  This document describes emerging patterns in protocols to
    partition what data and metadata is revealed through protocol
    interactions, provides common terminology, and discusses how to analyze
    such models.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Internet Architecture Board Internet Engineering Task Force mailing list (iab@iab.org),
    which is archived at <eref target=""/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/intarchboard/draft-obliviousness"/>.</t>
    </note>

  </front>
  <middle>
    <?line 41?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Protocols such as TLS and IPsec provide a secure (authenticated and
      encrypted) channel between two endpoints over which endpoints transfer
      information. Encryption and authentication of data in transit are
      necessary to protect information from being seen or modified by parties
      other than the intended protocol participants. As such, this kind of
      security is necessary for ensuring that information transferred over
      these channels remains private.</t>
      <t>However, a secure channel between two endpoints is insufficient for
      the privacy of the endpoints themselves. In recent years, privacy
      requirements have expanded beyond the need to protect data in transit
      between two endpoints. Some examples of this expansion include:</t>
      <ul spacing="normal">
        <li>
          <t>A
        <li>A user accessing a service on a website might not consent to
        reveal their location, but if that service is able to observe the
        client's IP address, it can learn something about the user's
        location. This is problematic for privacy since the service can link
        user data to the user's location.</t>
        </li>
        <li>
          <t>A location.</li>
<!-- [rfced] The use of "this" to start the second sentence seems to imply that the problem is a user not wanting their info to be recorded.  In addition, "needing to have which specific articles" is difficult to parse.  Please review.

Original:
   *  A user might want to be able to access content for which they are
      authorized, such as a news article, without needing to have which
      specific articles they read on their account being recorded.  This
      is problematic for privacy since the service can link user
      activity to the user's account.</t>
        </li>
        <li>
          <t>A account.

Perhaps:
   *  A user might want to be able to access content for which they are
      authorized, such as a news article, without having the
      specific articles they read on their account being recorded.
      Linking user activity to the user's account is problematic for
      privacy.
-->

        <li>A user might want to be able to access content for which they are
        authorized, such as a news article, without needing to have which
        specific articles they read on their account being recorded. This is
        problematic for privacy since the service can link user activity to
        the user's account.</li>
<!-- [rfced] Similar to above - "this" seems to indicate that the problem is the desire not to have contributions attributed to the specific user.  Please review.

Original:
   *  A client device that needs to upload metrics to an aggregation
      service might want to be able to contribute data to the system
      without having their specific contributions attributed to them.
      This is problematic for privacy since the service can link client
      contributions to the specific client.</t>
        </li> client.

Perhaps:
   *  A client device that needs to upload metrics to an aggregation
      service might want to contribute data to the system
      without having their specific contributions attributed to them.
      Linking client contributions to the specific client is problematic
      for privacy.

-->

        <li>A client device that needs to upload metrics to an aggregation
        service might want to be able to contribute data to the system without
        having their specific contributions attributed to them. This is
        problematic for privacy since the service can link client
        contributions to the specific client.</li>
      </ul>
      <t>The commonality in these examples is that clients want to interact with or use a service
without exposing too much user-specific or identifying information to that service. In particular,
separating the user-specific identity information from user-specific data is necessary for
privacy. Thus, in order to protect user privacy, it is important to keep identity (who) and data
(what) separate.</t>
      <t>This document defines "privacy partitioning," sometimes also referred to as the "decoupling principle"
<xref target="DECOUPLING"/>, as the general technique used to separate the data
and metadata visible to various parties in network communication, with the aim of improving
user privacy. Although privacy partitioning cannot guarantee there is no link between user-specific
identity and user-specific data, when applied properly it helps ensure that user privacy violations
become more technically difficult to achieve over time.</t>
<!-- [rfced] We initially thought "reasoning" meant "rationale".  May we change "reasoning" to "thinking"?

Original:
   This document summarizes work in those
   groups and describes a framework for reasoning about the resulting
   privacy posture of different endpoints in practice.
-->
      <t>Several IETF working groups are working on protocols or systems that adhere to the principle
of privacy partitioning, including Oblivious HTTP Application Intermediation (OHAI), Multiplexed
Application Substrate over QUIC Encryption (MASQUE), Privacy Pass, and Privacy Preserving Measurement (PPM). This document summarizes
work in those groups and describes a framework for reasoning about the resulting privacy posture of different
endpoints in practice.</t>
      <t>Privacy partitioning is particularly relevant as a tool for data
      minimization, which is described in <xref section="6.1"
      sectionFormat="of" target="RFC6973"/>. <xref target="RFC6973"/> provides
      guidance for privacy considerations in Internet protocols, along with a
      set of questions on how to evaluate the data minimization of a protocol
      in <xref section="7.1" sectionFormat="of" target="RFC6973"/>. Protocols
      that employ privacy partitioning ought to consider the questions in that
      section when evaluating their design, particularly with regard to how
      identifiers and data can be correlated by protocol participants and
      observers in each context that has been partitioned. Privacy
      partitioning can also be used as a way to separate identity providers
      from relying parties (see <xref section="6.1.4" sectionFormat="of"
      target="RFC6973"/>), as in the case of Privacy Pass (see Section <xref
      target="privacypass"/>).</t>
      <t>Privacy partitioning is not a panacea; applying it well requires
      holistic analysis of the system in question to determine whether or not
      partitioning as a tool, and as implemented, offers meaningful privacy
      improvements. See <xref target="limits"/> for more information.</t>
    </section>
    <section anchor="privacy-partitioning">
      <name>Privacy Partitioning</name>
      <t>For the purposes of user privacy, this document focuses on
      user-specific information. This might include any identifying
      information that is specific to a user, such as their email address or
      IP address, or any data about the user, such as their date of
      birth. Informally, the goal of privacy partitioning is to ensure that
      each party in a system beyond the user themselves only have has access to
      one type of user-specific information.</t>
      <t>This is a simple application of the principle of least privilege, wherein every party in
a system only has access to the minimum amount of information needed to fulfill their
function. Privacy partitioning advocates for this minimization by ensuring that protocols,
applications, and systems only reveal user-specific information to parties that need access
to the information for their intended purpose.</t>
      <t>Put simply, privacy partitioning aims to separate <em>who</em> someone is from <em>what</em> they do. In the
rest of this section, we describe how privacy partitioning can be used to achieve this goal.</t>
      <section anchor="privacy-contexts">
        <name>Privacy Contexts</name>
        <t>Each piece of user-specific information exists within some context, where a context
is abstractly defined as a set of data, metadata, and the entities that share access
to that information. In order to prevent the correlation of user-specific information across
contexts, partitions need to ensure that any single entity (other than the client itself)
does not participate in more than one context where the information is visible.</t>
        <t><xref target="RFC6973"/> discusses the importance of identifiers in reducing correlation as a way
of improving privacy:</t>
        <blockquote>
          <t>Correlation is the combination of various pieces of information
          related to an individual or that obtain that characteristic when combined... Correlation
          combined....</t>
	  <t>Correlation is closely related to identification.
          Internet protocols can facilitate correlation by allowing
          individuals' activities to be tracked and combined over time.</t> time....</t>
          <t>Pseudonymity is strengthened when less personal data can be
          linked to the pseudonym; when the same pseudonym is used less often
          and across fewer contexts; and when independently chosen pseudonyms
          are more frequently used for new actions (making them, from an
          observer's or attacker's perspective, unlinkable).</t>
        </blockquote>
        <t>Context separation is foundational to privacy partitioning and
        reducing correlation.  As an example, consider an unencrypted HTTP
        session over TCP, wherein the context includes both the content of the
        transaction as well as any metadata from the transport and IP headers;
        and the participants include the client, routers, other network
        middleboxes, intermediaries, and the server.
Middlboxes  Middleboxes or intermediaries
        might simply forward traffic, traffic or might terminate the traffic at any
        layer (such as terminating the TCP connection from the client and
        creating another TCP connection to the server). Regardless of how the
        middlebox interacts with the traffic, for the purposes of privacy
        partitioning, it is able to observe all of the data in the
        context.</t>
        <figure anchor="diagram-middlebox">
          <name>Diagram of a basic unencrypted client-to-server connection Basic Unencrypted Client-to-Server Connection with middleboxes</name> Middleboxes</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="176" width="560" viewBox="0 0 560 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,160" fill="none" stroke="black"/>
                <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
                <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
                <path d="M 240,64 L 240,128" fill="none" stroke="black"/>
                <path d="M 336,64 L 336,128" fill="none" stroke="black"/>
                <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
                <path d="M 528,64 L 528,128" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,160" fill="none" stroke="black"/>
                <path d="M 8,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 240,64 L 336,64" fill="none" stroke="black"/>
                <path d="M 456,64 L 528,64" fill="none" stroke="black"/>
                <path d="M 104,80 L 152,80" fill="none" stroke="black"/>
                <path d="M 192,80 L 240,80" fill="none" stroke="black"/>
                <path d="M 336,80 L 456,80" fill="none" stroke="black"/>
                <path d="M 104,112 L 152,112" fill="none" stroke="black"/>
                <path d="M 184,112 L 240,112" fill="none" stroke="black"/>
                <path d="M 336,112 L 456,112" fill="none" stroke="black"/>
                <path d="M 32,128 L 104,128" fill="none" stroke="black"/>
                <path d="M 240,128 L 336,128" fill="none" stroke="black"/>
                <path d="M 456,128 L 528,128" fill="none" stroke="black"/>
                <path d="M 8,160 L 552,160" fill="none" stroke="black"/>
                <g class="text">
                  <text x="48" y="52">Context</text>
                  <text x="88" y="52">A</text>
                  <text x="172" y="84">HTTP</text>
                  <text x="68" y="100">Client</text>
                  <text x="288" y="100">Middlebox</text>
                  <text x="492" y="100">Server</text>
                  <text x="168" y="116">TCP</text>
                  <text x="172" y="132">flow</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------------+
| Context A                                                         |
|  +--------+                +-----------+              +--------+  |
|  |        +------HTTP------+           +--------------+        |  |
|  | Client |                | Middlebox |              | Server |  |
|  |        +------TCP-------+           +--------------+        |  |
|  +--------+      flow      +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
]]></artwork>
          </artset>
        </figure>

        <t>Adding TLS encryption to the HTTP session is a simple partitioning
        technique that splits the previous context into two separate contexts: the contexts.
        The content of the transaction is now only visible to the client,
        TLS-terminating intermediaries, and server; server, while the metadata in
        transport and IP headers remain in the original context. In this
        scenario, without any further partitioning, the entities that
        participate in both contexts can allow the data in both contexts to be
        correlated.</t>
        <figure anchor="diagram-https">
          <name>Diagram of how adding encryption splits How Adding Encryption Splits the context Context into two</name> Two</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
                <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
                <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
                <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
                <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
                <path d="M 240,192 L 240,256" fill="none" stroke="black"/>
                <path d="M 336,192 L 336,256" fill="none" stroke="black"/>
                <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
                <path d="M 456,192 L 456,256" fill="none" stroke="black"/>
                <path d="M 528,64 L 528,128" fill="none" stroke="black"/>
                <path d="M 528,192 L 528,256" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,288" fill="none" stroke="black"/>
                <path d="M 8,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 456,64 L 528,64" fill="none" stroke="black"/>
                <path d="M 104,96 L 256,96" fill="none" stroke="black"/>
                <path d="M 304,96 L 456,96" fill="none" stroke="black"/>
                <path d="M 32,128 L 104,128" fill="none" stroke="black"/>
                <path d="M 456,128 L 528,128" fill="none" stroke="black"/>
                <path d="M 8,160 L 552,160" fill="none" stroke="black"/>
                <path d="M 32,192 L 104,192" fill="none" stroke="black"/>
                <path d="M 240,192 L 336,192" fill="none" stroke="black"/>
                <path d="M 456,192 L 528,192" fill="none" stroke="black"/>
                <path d="M 104,224 L 160,224" fill="none" stroke="black"/>
                <path d="M 192,224 L 240,224" fill="none" stroke="black"/>
                <path d="M 336,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 32,256 L 104,256" fill="none" stroke="black"/>
                <path d="M 240,256 L 336,256" fill="none" stroke="black"/>
                <path d="M 456,256 L 528,256" fill="none" stroke="black"/>
                <path d="M 8,288 L 552,288" fill="none" stroke="black"/>
                <g class="text">
                  <text x="48" y="52">Context</text>
                  <text x="88" y="52">A</text>
                  <text x="68" y="100">Client</text>
                  <text x="280" y="100">HTTPS</text>
                  <text x="492" y="100">Server</text>
                  <text x="48" y="180">Context</text>
                  <text x="88" y="180">B</text>
                  <text x="68" y="228">Client</text>
                  <text x="176" y="228">TCP</text>
                  <text x="288" y="228">Middlebox</text>
                  <text x="492" y="228">Server</text>
                  <text x="180" y="244">flow</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------------+
| Context A                                                         |
|  +--------+                                           +--------+  |
|  |        |                                           |        |  |
|  | Client +-------------------HTTPS-------------------+ Server |  |
|  |        |                                           |        |  |
|  +--------+                                           +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Context B                                                         |
|  +--------+                +-----------+              +--------+  |
|  |        |                |           |              |        |  |
|  | Client +-------TCP------+ Middlebox +--------------+ Server |  |
|  |        |       flow     |           |              |        |  |
|  +--------+                +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
]]></artwork>
          </artset>
        </figure>
        <t>Another way to create a partition is to simply use separate
        connections. For example, to split two separate HTTP requests from one
        another, a client could issue the requests on separate TCP
        connections, each on a different network, network and at different times; times, and
        avoid including obvious identifiers like HTTP cookies across the
        requests.</t>
        <figure anchor="diagram-dualconnect">
          <name>Diagram of making separate connections Making Separate Connections to generate separate contexts</name> Generate Separate Contexts</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
                <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
                <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
                <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
                <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
                <path d="M 240,64 L 240,128" fill="none" stroke="black"/>
                <path d="M 240,192 L 240,256" fill="none" stroke="black"/>
                <path d="M 336,64 L 336,128" fill="none" stroke="black"/>
                <path d="M 336,192 L 336,256" fill="none" stroke="black"/>
                <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
                <path d="M 456,192 L 456,256" fill="none" stroke="black"/>
                <path d="M 528,64 L 528,128" fill="none" stroke="black"/>
                <path d="M 528,192 L 528,256" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,288" fill="none" stroke="black"/>
                <path d="M 8,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 240,64 L 336,64" fill="none" stroke="black"/>
                <path d="M 456,64 L 528,64" fill="none" stroke="black"/>
                <path d="M 104,96 L 160,96" fill="none" stroke="black"/>
                <path d="M 192,96 L 240,96" fill="none" stroke="black"/>
                <path d="M 336,96 L 456,96" fill="none" stroke="black"/>
                <path d="M 32,128 L 104,128" fill="none" stroke="black"/>
                <path d="M 240,128 L 336,128" fill="none" stroke="black"/>
                <path d="M 456,128 L 528,128" fill="none" stroke="black"/>
                <path d="M 8,160 L 552,160" fill="none" stroke="black"/>
                <path d="M 32,192 L 104,192" fill="none" stroke="black"/>
                <path d="M 240,192 L 336,192" fill="none" stroke="black"/>
                <path d="M 456,192 L 528,192" fill="none" stroke="black"/>
                <path d="M 104,224 L 160,224" fill="none" stroke="black"/>
                <path d="M 192,224 L 240,224" fill="none" stroke="black"/>
                <path d="M 336,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 32,256 L 104,256" fill="none" stroke="black"/>
                <path d="M 240,256 L 336,256" fill="none" stroke="black"/>
                <path d="M 456,256 L 528,256" fill="none" stroke="black"/>
                <path d="M 8,288 L 552,288" fill="none" stroke="black"/>
                <g class="text">
                  <text x="48" y="52">Context</text>
                  <text x="88" y="52">A</text>
                  <text x="124" y="84">IP</text>
                  <text x="144" y="84">A</text>
                  <text x="68" y="100">Client</text>
                  <text x="176" y="100">TCP</text>
                  <text x="288" y="100">Middlebox</text>
                  <text x="492" y="100">Server</text>
                  <text x="172" y="116">flow</text>
                  <text x="200" y="116">A</text>
                  <text x="288" y="116">A</text>
                  <text x="48" y="180">Context</text>
                  <text x="88" y="180">B</text>
                  <text x="124" y="212">IP</text>
                  <text x="144" y="212">B</text>
                  <text x="68" y="228">Client</text>
                  <text x="176" y="228">TCP</text>
                  <text x="288" y="228">Middlebox</text>
                  <text x="492" y="228">Server</text>
                  <text x="172" y="244">flow</text>
                  <text x="200" y="244">B</text>
                  <text x="288" y="244">B</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------------+
| Context A                                                         |
|  +--------+                +-----------+              +--------+  |
|  |        | IP A           |           |              |        |  |
|  | Client +-------TCP------+ Middlebox +--------------+ Server |  |
|  |        |      flow A    |     A     |              |        |  |
|  +--------+                +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Context B                                                         |
|  +--------+                +-----------+              +--------+  |
|  |        | IP B           |           |              |        |  |
|  | Client +-------TCP------+ Middlebox +--------------+ Server |  |
|  |        |      flow B    |     B     |              |        |  |
|  +--------+                +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
]]></artwork>
          </artset>
        </figure>
        <t>Using separate connections to create separate contexts can reduce or eliminate
the ability of specific parties to correlate activity across contexts. However,
any identifier at any layer that is common across different contexts can be
used as a way to correlate activity. Beyond IP addresses, many other factors
can be used together to create a fingerprint of a specific device (such as
MAC
Media Access Control (MAC) addresses, device properties, software properties and behavior, application state, etc).</t> etc.).</t>
      </section>
      <section anchor="context-separation">
        <name>Context Separation</name>
        <t>In order to define and analyze how various partitioning techniques work, the boundaries of what is
being partitioned need to be established. This is the role of context separation. In particular,
in order to prevent the correlation of user-specific information across contexts, partitions need
to ensure that any single entity (other than the client itself) does not participate in contexts
where both identifiers are visible.</t>
        <t>Context separation can be achieved in different ways, for example, over time, across network paths, based
on (en)coding, etc. The privacy-oriented protocols described in this document generally involve
more complex partitioning, but the techniques to partition communication contexts still employ the
same techniques:</t>
        <ol spacing="normal" type="1"><li>
            <t>Cryptographic
        <ul spacing="normal">
	  <li>Cryptographic protection, such as the use of encryption to
	  specific parties, allows partitioning of contexts between different
	  parties (those with the ability to remove cryptographic protections,
	  and those without).</t>
          </li>
          <li>
            <t>Connection without).</li>
          <li>Connection separation across time or space to allow
          partitioning of contexts for different application transactions over
          the network.</t>
          </li>
        </ol> network.</li>
        </ul>
        <t>These techniques are frequently used in conjunction for context separation. For example,
encrypting an HTTP exchange using TLS between the client and TLS-terminating server might prevent
a network middlebox that sees a client IP address from seeing the user account identifier,
but it doesn't prevent the TLS-terminating server from observing both identifiers and correlating
them. As such, preventing correlation requires separating contexts, such as by using proxying to
conceal a client's IP address that would otherwise be used as an identifier.</t>
      </section>
      <section anchor="approaches-to-partitioning">
        <name>Approaches to Partitioning</name>
        <t>While all of the partitioning protocols described in this document
        create separate contexts using cryptographic protection and/or
        connection separation, each one has a unique approach that results in
        different sets of contexts. Since many of these protocols are new, it
        is yet to be seen how each approach will be used at scale across the Internet,
        Internet and what new models will emerge in the future.</t>
        <t>There are multiple factors that lead to a diversity in approaches
        to partitioning, including:</t>
        <ul spacing="normal">
          <li>
            <t>Adding
          <li>Adding privacy partitioning to existing protocol ecosystems
          places requirements and constraints on how contexts are
          constructed. CONNECT-style proxying is intended to work with servers
          that are unaware of privacy contexts, requiring more intermediaries
          to provide strong separation guarantees.
Oblivious HTTP, on  On the other hand,
          Oblivious HTTP assumes servers that cooperate with context
separation, and thus
          separation and, thus, reduces the overall number of elements in the solution.</t>
          </li>
          <li>
            <t>Whether
          solution.</li>
          <li>Whether or not information exchange needs to happen
          bidirectionally in an interactive fashion determines how contexts
          can be separated. Some use cases, like metrics collection for PPM,
          can occur with whereby information flowing only flows from clients to servers, servers and
          can function even when clients are no longer connected.  Privacy
          Pass is an example of a case that can be either interactive or not,
          depending on whether tokens can be cached and reused. CONNECT-style
          proxying and Oblivious HTTP often requires require bidirectional and
          interactive communication.</t>
          </li>
          <li>
            <t>The communication.</li>
          <li>The degree to which contexts need to be partitioned depends in
          part on the client's threat models and level of trust in various
          protocol participants. For example, in Oblivious HTTP, clients allow
          relays to learn that clients are accessing a particular
          application-specific gateway. If clients do not trust relays with
          this information, they can instead use a multi-hop CONNECT-style
          proxy approach wherein no single party learns whether specific
          clients are accessing a specific application. This is the default
          trust model for systems like Tor, where multiple hops are used to
          drive down the probability of privacy violations due to collusion or
          related attacks.</t>
          </li> attacks.</li>
        </ul>
      </section>
    </section>

    <section anchor="a-survey-of-protocols-using-partitioning">
      <name>A Survey of Protocols using Using Partitioning</name>
      <t>The following section discusses current on-going work in the IETF
      that is applying privacy partitioning.</t>
      <section anchor="masque">
        <name>CONNECT Proxying and MASQUE</name>
        <t>HTTP forward proxies, when
        <t>When using encryption on the connection between the client and the
        proxy, HTTP forward proxies provide privacy partitioning by separating
        a connection into multiple segments.  When connections to targets via
        the proxy themselves are encrypted, the proxy cannot see the
        end-to-end content. HTTP has historically supported forward proxying
        for TCP-like streams via the CONNECT method. More recently, the
        Multiplexed Application Substrate over QUIC Encryption (MASQUE) working group
        Working Group has developed protocols to similarly proxy UDP <xref target="CONNECT-UDP"/>
        target="RFC9297"/> and IP packets <xref target="CONNECT-IP"/> target="RFC9484"/> based on
        tunneling.</t>
        <t>In a single-proxy setup, there is a tunnel connection between the
        client and proxy and an end-to-end connection that is tunnelled tunneled between
        the client and target. This setup, as shown in the figure below, <xref
        target="diagram-1hop"/>, partitions communication into:</t>
        <ul spacing="normal">
          <li>
            <t>a
          <li>a Client-to-Target encrypted context, which contains the
          end-to-end content within the TLS session to the target, such as
          HTTP content;</t>
          </li>
          <li>
            <t>a content;</li>
<!-- [rfced] Is the end-to-end data perhaps carried or transported to the target?

Original:
   *  a Client-to-Target proxied context, which is the end-to-end data
      to the target that is also visible to the proxy, such as a TLS session;</t>
          </li>
          <li>
            <t>a
      session;

Perhaps:
   *  a Client-to-Target proxied context, which is the end-to-end data
      transported to the target that is also visible to the proxy, such as a TLS
      session;
-->

          <li>a Client-to-Target proxied context, which is the end-to-end data
          to the target that is also visible to the proxy, such as a TLS
          session;</li>
          <li>a Client-to-Proxy context, which contains the transport metadata
          between the client and the target, and the request to the proxy to
          open a connection to the target;</t> target; and </li>
          <li>
            <t>and a
	  <li>a Proxy-to-Target context, which for TCP and UDP proxying
	  contains any packet header information that is added or modified by
	  the proxy, e.g., the IP and TCP/UDP headers.</t>
          </li> headers.</li>
        </ul>
        <figure anchor="diagram-1hop">
          <name>Diagram of one-hop proxy contexts</name> One-Hop Proxy Contexts</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="560" width="560" viewBox="0 0 560 560" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,544" fill="none" stroke="black"/>
                <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
                <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
                <path d="M 32,320 L 32,384" fill="none" stroke="black"/>
                <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
                <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
                <path d="M 104,320 L 104,384" fill="none" stroke="black"/>
                <path d="M 240,192 L 240,256" fill="none" stroke="black"/>
                <path d="M 240,320 L 240,384" fill="none" stroke="black"/>
                <path d="M 240,448 L 240,512" fill="none" stroke="black"/>
                <path d="M 336,192 L 336,256" fill="none" stroke="black"/>
                <path d="M 336,320 L 336,384" fill="none" stroke="black"/>
                <path d="M 336,448 L 336,512" fill="none" stroke="black"/>
                <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
                <path d="M 456,192 L 456,256" fill="none" stroke="black"/>
                <path d="M 456,448 L 456,512" fill="none" stroke="black"/>
                <path d="M 528,64 L 528,128" fill="none" stroke="black"/>
                <path d="M 528,192 L 528,256" fill="none" stroke="black"/>
                <path d="M 528,448 L 528,512" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,544" fill="none" stroke="black"/>
                <path d="M 8,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 456,64 L 528,64" fill="none" stroke="black"/>
                <path d="M 104,96 L 248,96" fill="none" stroke="black"/>
                <path d="M 296,96 L 456,96" fill="none" stroke="black"/>
                <path d="M 32,128 L 104,128" fill="none" stroke="black"/>
                <path d="M 456,128 L 528,128" fill="none" stroke="black"/>
                <path d="M 8,160 L 552,160" fill="none" stroke="black"/>
                <path d="M 32,192 L 104,192" fill="none" stroke="black"/>
                <path d="M 240,192 L 336,192" fill="none" stroke="black"/>
                <path d="M 456,192 L 528,192" fill="none" stroke="black"/>
                <path d="M 104,224 L 136,224" fill="none" stroke="black"/>
                <path d="M 200,224 L 240,224" fill="none" stroke="black"/>
                <path d="M 336,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 32,256 L 104,256" fill="none" stroke="black"/>
                <path d="M 240,256 L 336,256" fill="none" stroke="black"/>
                <path d="M 456,256 L 528,256" fill="none" stroke="black"/>
                <path d="M 8,288 L 552,288" fill="none" stroke="black"/>
                <path d="M 32,320 L 104,320" fill="none" stroke="black"/>
                <path d="M 240,320 L 336,320" fill="none" stroke="black"/>
                <path d="M 104,352 L 128,352" fill="none" stroke="black"/>
                <path d="M 208,352 L 240,352" fill="none" stroke="black"/>
                <path d="M 32,384 L 104,384" fill="none" stroke="black"/>
                <path d="M 240,384 L 336,384" fill="none" stroke="black"/>
                <path d="M 8,416 L 552,416" fill="none" stroke="black"/>
                <path d="M 240,448 L 336,448" fill="none" stroke="black"/>
                <path d="M 456,448 L 528,448" fill="none" stroke="black"/>
                <path d="M 336,480 L 352,480" fill="none" stroke="black"/>
                <path d="M 432,480 L 456,480" fill="none" stroke="black"/>
                <path d="M 240,512 L 336,512" fill="none" stroke="black"/>
                <path d="M 456,512 L 528,512" fill="none" stroke="black"/>
                <path d="M 8,544 L 552,544" fill="none" stroke="black"/>
                <g class="text">
                  <text x="84" y="52">Client-to-Target</text>
                  <text x="192" y="52">Encrypted</text>
                  <text x="264" y="52">Context</text>
                  <text x="68" y="100">Client</text>
                  <text x="272" y="100">HTTPS</text>
                  <text x="492" y="100">Target</text>
                  <text x="272" y="116">content</text>
                  <text x="84" y="180">Client-to-Target</text>
                  <text x="184" y="180">Proxied</text>
                  <text x="248" y="180">Context</text>
                  <text x="68" y="228">Client</text>
                  <text x="168" y="228">Proxied</text>
                  <text x="288" y="228">Proxy</text>
                  <text x="492" y="228">Target</text>
                  <text x="152" y="244">TLS</text>
                  <text x="188" y="244">flow</text>
                  <text x="80" y="308">Client-to-Proxy</text>
                  <text x="176" y="308">Context</text>
                  <text x="68" y="356">Client</text>
                  <text x="168" y="356">Transport</text>
                  <text x="288" y="356">Proxy</text>
                  <text x="164" y="372">flow</text>
                  <text x="80" y="436">Proxy-to-Target</text>
                  <text x="176" y="436">Context</text>
                  <text x="288" y="484">Proxy</text>
                  <text x="392" y="484">Transport</text>
                  <text x="492" y="484">Target</text>
                  <text x="388" y="500">flow</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------------+
| Client-to-Target Encrypted Context                                |
|  +--------+                                           +--------+  |
|  |        |                                           |        |  |
|  | Client +------------------HTTPS--------------------+ Target |  |
|  |        |                 content                   |        |  |
|  +--------+                                           +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Target Proxied Context                                  |
|  +--------+                +-----------+              +--------+  |
|  |        |                |           |              |        |  |
|  | Client +----Proxied-----+   Proxy   +--------------+ Target |  |
|  |        |    TLS flow    |           |              |        |  |
|  +--------+                +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Proxy Context                                           |
|  +--------+                +-----------+                          |
|  |        |                |           |                          |
|  | Client +---Transport----+   Proxy   |                          |
|  |        |     flow       |           |                          |
|  +--------+                +-----------+                          |
|                                                                   |
+-------------------------------------------------------------------+
| Proxy-to-Target Context                                           |
|                            +-----------+              +--------+  |
|                            |           |              |        |  |
|                            |   Proxy   +--Transport---+ Target |  |
|                            |           |    flow      |        |  |
|                            +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
]]></artwork>
          </artset>
        </figure>
        <t>Using two (or more) proxies provides better privacy
        partitioning. In particular, with two proxies, each proxy sees the
        Client metadata, but not the Target; the Target, but not the Client
        metadata; or neither.</t>
        <t>In addition to the contexts described above for the single proxy
        case, the two-hop proxy case shown in the figure below <xref target="diagram-2hop"/>
        changes the contexts in several ways:</t>
        <ul spacing="normal">
          <li>
            <t>the
          <li>the Client-to-Target proxied context only includes the second
          proxy (referred to here as "Proxy B");</t>
          </li>
          <li>
            <t>a B");</li>
          <li>a new Client-to-Proxy B context is added, which is the TLS
          session from the client to Proxy B that is also visible to the first
          proxy (referred to here as "Proxy A");</t>
          </li>
          <li>
            <t>the A");</li>
          <li>the contexts that see transport data only (TCP or UDP over IP)
          are separated out into three separate contexts, a Client-to-Proxy A
          context, a Proxy A-to-Proxy B context, and a Proxy B-to-Target context.</t>
          </li>
          context.</li>
         </ul>
        <figure anchor="diagram-2hop">
          <name>Diagram of two-hop proxy contexts</name> Two-Hop Proxy Contexts</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="816" width="560" viewBox="0 0 560 816" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,800" fill="none" stroke="black"/>
                <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
                <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
                <path d="M 32,320 L 32,384" fill="none" stroke="black"/>
                <path d="M 32,448 L 32,512" fill="none" stroke="black"/>
                <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
                <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
                <path d="M 104,320 L 104,384" fill="none" stroke="black"/>
                <path d="M 104,448 L 104,512" fill="none" stroke="black"/>
                <path d="M 184,320 L 184,384" fill="none" stroke="black"/>
                <path d="M 184,448 L 184,512" fill="none" stroke="black"/>
                <path d="M 184,576 L 184,640" fill="none" stroke="black"/>
                <path d="M 248,320 L 248,384" fill="none" stroke="black"/>
                <path d="M 248,448 L 248,512" fill="none" stroke="black"/>
                <path d="M 248,576 L 248,640" fill="none" stroke="black"/>
                <path d="M 328,192 L 328,256" fill="none" stroke="black"/>
                <path d="M 328,320 L 328,384" fill="none" stroke="black"/>
                <path d="M 328,576 L 328,640" fill="none" stroke="black"/>
                <path d="M 328,704 L 328,768" fill="none" stroke="black"/>
                <path d="M 392,192 L 392,256" fill="none" stroke="black"/>
                <path d="M 392,320 L 392,384" fill="none" stroke="black"/>
                <path d="M 392,576 L 392,640" fill="none" stroke="black"/>
                <path d="M 392,704 L 392,768" fill="none" stroke="black"/>
                <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
                <path d="M 456,192 L 456,256" fill="none" stroke="black"/>
                <path d="M 456,704 L 456,768" fill="none" stroke="black"/>
                <path d="M 528,64 L 528,128" fill="none" stroke="black"/>
                <path d="M 528,192 L 528,256" fill="none" stroke="black"/>
                <path d="M 528,704 L 528,768" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,800" fill="none" stroke="black"/>
                <path d="M 8,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 456,64 L 528,64" fill="none" stroke="black"/>
                <path d="M 104,96 L 248,96" fill="none" stroke="black"/>
                <path d="M 296,96 L 456,96" fill="none" stroke="black"/>
                <path d="M 32,128 L 104,128" fill="none" stroke="black"/>
                <path d="M 456,128 L 528,128" fill="none" stroke="black"/>
                <path d="M 8,160 L 552,160" fill="none" stroke="black"/>
                <path d="M 32,192 L 104,192" fill="none" stroke="black"/>
                <path d="M 328,192 L 392,192" fill="none" stroke="black"/>
                <path d="M 456,192 L 528,192" fill="none" stroke="black"/>
                <path d="M 104,224 L 184,224" fill="none" stroke="black"/>
                <path d="M 248,224 L 328,224" fill="none" stroke="black"/>
                <path d="M 392,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 32,256 L 104,256" fill="none" stroke="black"/>
                <path d="M 328,256 L 392,256" fill="none" stroke="black"/>
                <path d="M 456,256 L 528,256" fill="none" stroke="black"/>
                <path d="M 8,288 L 552,288" fill="none" stroke="black"/>
                <path d="M 32,320 L 104,320" fill="none" stroke="black"/>
                <path d="M 184,320 L 248,320" fill="none" stroke="black"/>
                <path d="M 328,320 L 392,320" fill="none" stroke="black"/>
                <path d="M 104,352 L 184,352" fill="none" stroke="black"/>
                <path d="M 248,352 L 328,352" fill="none" stroke="black"/>
                <path d="M 32,384 L 104,384" fill="none" stroke="black"/>
                <path d="M 184,384 L 248,384" fill="none" stroke="black"/>
                <path d="M 328,384 L 392,384" fill="none" stroke="black"/>
                <path d="M 8,416 L 552,416" fill="none" stroke="black"/>
                <path d="M 32,448 L 104,448" fill="none" stroke="black"/>
                <path d="M 184,448 L 248,448" fill="none" stroke="black"/>
                <path d="M 104,480 L 184,480" fill="none" stroke="black"/>
                <path d="M 32,512 L 104,512" fill="none" stroke="black"/>
                <path d="M 184,512 L 248,512" fill="none" stroke="black"/>
                <path d="M 8,544 L 552,544" fill="none" stroke="black"/>
                <path d="M 184,576 L 248,576" fill="none" stroke="black"/>
                <path d="M 328,576 L 392,576" fill="none" stroke="black"/>
                <path d="M 248,608 L 328,608" fill="none" stroke="black"/>
                <path d="M 184,640 L 248,640" fill="none" stroke="black"/>
                <path d="M 328,640 L 392,640" fill="none" stroke="black"/>
                <path d="M 8,672 L 552,672" fill="none" stroke="black"/>
                <path d="M 328,704 L 392,704" fill="none" stroke="black"/>
                <path d="M 456,704 L 528,704" fill="none" stroke="black"/>
                <path d="M 392,736 L 456,736" fill="none" stroke="black"/>
                <path d="M 328,768 L 392,768" fill="none" stroke="black"/>
                <path d="M 456,768 L 528,768" fill="none" stroke="black"/>
                <path d="M 8,800 L 552,800" fill="none" stroke="black"/>
                <g class="text">
                  <text x="84" y="52">Client-to-Target</text>
                  <text x="192" y="52">Encrypted</text>
                  <text x="264" y="52">Context</text>
                  <text x="68" y="100">Client</text>
                  <text x="272" y="100">HTTPS</text>
                  <text x="492" y="100">Target</text>
                  <text x="272" y="116">content</text>
                  <text x="84" y="180">Client-to-Target</text>
                  <text x="184" y="180">Proxied</text>
                  <text x="248" y="180">Context</text>
                  <text x="68" y="228">Client</text>
                  <text x="216" y="228">Proxied</text>
                  <text x="360" y="228">Proxy</text>
                  <text x="492" y="228">Target</text>
                  <text x="200" y="244">TLS</text>
                  <text x="236" y="244">flow</text>
                  <text x="360" y="244">B</text>
                  <text x="80" y="308">Client-to-Proxy</text>
                  <text x="152" y="308">B</text>
                  <text x="192" y="308">Context</text>
                  <text x="68" y="356">Client</text>
                  <text x="216" y="356">Proxy</text>
                  <text x="360" y="356">Proxy</text>
                  <text x="216" y="372">A</text>
                  <text x="360" y="372">B</text>
                  <text x="80" y="436">Client-to-Proxy</text>
                  <text x="152" y="436">A</text>
                  <text x="192" y="436">Context</text>
                  <text x="68" y="484">Client</text>
                  <text x="216" y="484">Proxy</text>
                  <text x="216" y="500">A</text>
                  <text x="40" y="564">Proxy</text>
                  <text x="108" y="564">A-to-Proxy</text>
                  <text x="160" y="564">B</text>
                  <text x="200" y="564">Context</text>
                  <text x="216" y="612">Proxy</text>
                  <text x="360" y="612">Proxy</text>
                  <text x="216" y="628">A</text>
                  <text x="360" y="628">B</text>
                  <text x="40" y="692">Proxy</text>
                  <text x="112" y="692">B-to-Target</text>
                  <text x="192" y="692">Context</text>
                  <text x="360" y="740">Proxy</text>
                  <text x="492" y="740">Target</text>
                  <text x="360" y="756">B</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------------+
| Client-to-Target Encrypted Context                                |
|  +--------+                                           +--------+  |
|  |        |                                           |        |  |
|  | Client +------------------HTTPS--------------------+ Target |  |
|  |        |                 content                   |        |  |
|  +--------+                                           +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Target Proxied Context                                  |
|  +--------+                           +-------+       +--------+  |
|  |        |                           |       |       |        |  |
|  | Client +----------Proxied----------+ Proxy +-------+ Target |  |
|  |        |          TLS flow         |   B   |       |        |  |
|  +--------+                           +-------+       +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Proxy B Context                                         |
|  +--------+         +-------+         +-------+                   |
|  |        |         |       |         |       |                   |
|  | Client +---------+ Proxy +---------+ Proxy |                   |
|  |        |         |   A   |         |   B   |                   |
|  +--------+         +-------+         +-------+                   |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Proxy A Context                                         |
|  +--------+         +-------+                                     |
|  |        |         |       |                                     |
|  | Client +---------+ Proxy |                                     |
|  |        |         |   A   |                                     |
|  +--------+         +-------+                                     |
|                                                                   |
+-------------------------------------------------------------------+
| Proxy A-to-Proxy B Context                                        |
|                     +-------+         +-------+                   |
|                     |       |         |       |                   |
|                     | Proxy +---------+ Proxy |                   |
|                     |   A   |         |   B   |                   |
|                     +-------+         +-------+                   |
|                                                                   |
+-------------------------------------------------------------------+
| Proxy B-to-Target Context                                         |
|                                       +-------+       +--------+  |
|                                       |       |       |        |  |
|                                       | Proxy +-------+ Target |  |
|                                       |   B   |       |        |  |
|                                       +-------+       +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
]]></artwork>
          </artset>
        </figure>
<!-- [rfced] Are the protocols developed in MASQUE using forward proxying (as opposed to being forward proxying)?

Original:
   Forward proxying, such as the protocols developed in MASQUE, uses
   both encryption (via TLS) and separation of connections (via proxy
   hops that see only the next hop) to achieve privacy partitioning.

Perhaps:
   Forward proxying, which is used by protocols such as those developed
   in MASQUE, uses both encryption (via TLS) and separation of
   connections (via proxy hops that see only the next hop) to achieve
   privacy partitioning.
-->

        <t>Forward proxying, such as the protocols developed in MASQUE, uses both encryption (via TLS) and
separation of connections (via proxy hops that see only the next hop) to achieve privacy partitioning.</t>
      </section>
      <section anchor="oblivious-http-and-dns">
        <name>Oblivious HTTP and DNS</name>
        <t>Oblivious HTTP <xref target="OHTTP"/>, target="RFC9458"/>, developed in the Oblivious
        HTTP Application Intermediation (OHAI) working group, Working Group, adds per-message
        encryption to HTTP exchanges through a relay system. Clients send
        requests through an Oblivious Relay, which cannot read message
        contents, to an Oblivious Gateway, which can decrypt the messages but
        cannot communicate directly with the client or observe client metadata
        like an IP address.  Oblivious HTTP relies on Hybrid Public Key
        Encryption <xref target="HPKE"/> target="RFC9180"/> to perform encryption.</t>
        <t>Oblivious HTTP uses both encryption and separation of connections
        to achieve privacy partitioning.</t>
        <ul spacing="normal">
          <li>
            <t>End-to-end
          <li>End-to-end messages are encrypted between the Client and
          Gateway. The content of these inner messages are visible to the
          Client, Gateway, and Target. This is the Client-to-Target context.</t>
          </li>
          <li>
            <t>The
          context.</li>
          <li>The encrypted messages exchanged between the Client and Gateway
          are visible to the Relay, but the Relay cannot decrypt the messages.
          This is the Client-to-Gateway context.</t>
          </li>
          <li>
            <t>The context.</li>
          <li>The transport (such as TCP and TLS) connections between the
          Client, Relay, and Gateway form two separate contexts: a
          Client-to-Relay context and a Relay-to-Gateway context. It is
          important to note that the Relay-to-Gateway connection can be a
          single connection, even if the Relay has many separate Clients. This
          provides better anonymity by making the pseudonym presented by the
          Relay to be shared across many Clients.</t>
          </li> Clients.</li>
        </ul>
        <figure anchor="diagram-ohttp">
          <name>Diagram of Oblivious HTTP contexts</name> Contexts</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="560" width="560" viewBox="0 0 560 560" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,544" fill="none" stroke="black"/>
                <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
                <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
                <path d="M 32,320 L 32,384" fill="none" stroke="black"/>
                <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
                <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
                <path d="M 104,320 L 104,384" fill="none" stroke="black"/>
                <path d="M 184,192 L 184,256" fill="none" stroke="black"/>
                <path d="M 184,320 L 184,384" fill="none" stroke="black"/>
                <path d="M 184,448 L 184,512" fill="none" stroke="black"/>
                <path d="M 248,192 L 248,256" fill="none" stroke="black"/>
                <path d="M 248,320 L 248,384" fill="none" stroke="black"/>
                <path d="M 248,448 L 248,512" fill="none" stroke="black"/>
                <path d="M 328,64 L 328,128" fill="none" stroke="black"/>
                <path d="M 328,192 L 328,256" fill="none" stroke="black"/>
                <path d="M 328,448 L 328,512" fill="none" stroke="black"/>
                <path d="M 408,64 L 408,128" fill="none" stroke="black"/>
                <path d="M 408,192 L 408,256" fill="none" stroke="black"/>
                <path d="M 408,448 L 408,512" fill="none" stroke="black"/>
                <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
                <path d="M 528,64 L 528,128" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,544" fill="none" stroke="black"/>
                <path d="M 8,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 328,64 L 408,64" fill="none" stroke="black"/>
                <path d="M 456,64 L 528,64" fill="none" stroke="black"/>
                <path d="M 104,96 L 328,96" fill="none" stroke="black"/>
                <path d="M 408,96 L 456,96" fill="none" stroke="black"/>
                <path d="M 32,128 L 104,128" fill="none" stroke="black"/>
                <path d="M 328,128 L 408,128" fill="none" stroke="black"/>
                <path d="M 456,128 L 528,128" fill="none" stroke="black"/>
                <path d="M 8,160 L 552,160" fill="none" stroke="black"/>
                <path d="M 32,192 L 104,192" fill="none" stroke="black"/>
                <path d="M 184,192 L 248,192" fill="none" stroke="black"/>
                <path d="M 328,192 L 408,192" fill="none" stroke="black"/>
                <path d="M 104,224 L 184,224" fill="none" stroke="black"/>
                <path d="M 248,224 L 328,224" fill="none" stroke="black"/>
                <path d="M 32,256 L 104,256" fill="none" stroke="black"/>
                <path d="M 184,256 L 248,256" fill="none" stroke="black"/>
                <path d="M 328,256 L 408,256" fill="none" stroke="black"/>
                <path d="M 8,288 L 552,288" fill="none" stroke="black"/>
                <path d="M 32,320 L 104,320" fill="none" stroke="black"/>
                <path d="M 184,320 L 248,320" fill="none" stroke="black"/>
                <path d="M 104,352 L 184,352" fill="none" stroke="black"/>
                <path d="M 32,384 L 104,384" fill="none" stroke="black"/>
                <path d="M 184,384 L 248,384" fill="none" stroke="black"/>
                <path d="M 8,416 L 552,416" fill="none" stroke="black"/>
                <path d="M 184,448 L 248,448" fill="none" stroke="black"/>
                <path d="M 328,448 L 408,448" fill="none" stroke="black"/>
                <path d="M 248,480 L 328,480" fill="none" stroke="black"/>
                <path d="M 184,512 L 248,512" fill="none" stroke="black"/>
                <path d="M 328,512 L 408,512" fill="none" stroke="black"/>
                <path d="M 8,544 L 552,544" fill="none" stroke="black"/>
                <g class="text">
                  <text x="84" y="52">Client-to-Target</text>
                  <text x="184" y="52">Context</text>
                  <text x="68" y="100">Client</text>
                  <text x="368" y="100">Gateway</text>
                  <text x="492" y="100">Target</text>
                  <text x="88" y="180">Client-to-Gateway</text>
                  <text x="192" y="180">Context</text>
                  <text x="68" y="228">Client</text>
                  <text x="216" y="228">Relay</text>
                  <text x="368" y="228">Gateway</text>
                  <text x="80" y="308">Client-to-Relay</text>
                  <text x="176" y="308">Context</text>
                  <text x="68" y="356">Client</text>
                  <text x="216" y="356">Relay</text>
                  <text x="84" y="436">Relay-to-Gateway</text>
                  <text x="184" y="436">Context</text>
                  <text x="216" y="484">Relay</text>
                  <text x="368" y="484">Gateway</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------------+
| Client-to-Target Context                                          |
|  +--------+                           +---------+     +--------+  |
|  |        |                           |         |     |        |  |
|  | Client +---------------------------+ Gateway +-----+ Target |  |
|  |        |                           |         |     |        |  |
|  +--------+                           +---------+     +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Gateway Context                                         |
|  +--------+         +-------+         +---------+                 |
|  |        |         |       |         |         |                 |
|  | Client +---------+ Relay +---------+ Gateway |                 |
|  |        |         |       |         |         |                 |
|  +--------+         +-------+         +---------+                 |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Relay Context                                           |
|  +--------+         +-------+                                     |
|  |        |         |       |                                     |
|  | Client +---------+ Relay |                                     |
|  |        |         |       |                                     |
|  +--------+         +-------+                                     |
|                                                                   |
+-------------------------------------------------------------------+
| Relay-to-Gateway Context                                          |
|                     +-------+         +---------+                 |
|                     |       |         |         |                 |
|                     + Relay +---------+ Gateway |                 |
|                     |       |         |         |                 |
|                     +-------+         +---------+                 |
|                                                                   |
+-------------------------------------------------------------------+
]]></artwork>
          </artset>
        </figure>
        <t>Oblivious DNS over HTTPS (ODoH) <xref target="ODOH"/> target="RFC9230"/> applies the same
        principle as Oblivious HTTP, HTTP but operates on DNS messages only. As a
        precursor to the more generalized Oblivious HTTP, it relies on the
        same HPKE cryptographic primitives, primitives and can be analyzed in the same
        way.</t>
      </section>
      <section anchor="privacypass">
        <name>Privacy Pass</name>
        <t>Privacy Pass is an architecture <xref target="PRIVACYPASS"/>
        target="I-D.ietf-privacypass-architecture"/> and a set of protocols
        being developed in the Privacy Pass working group Working Group that allows clients
        to present proof of verification in an anonymous and unlinkable fashion,
        fashion via tokens. These tokens originally were originally designed as a way to
        prove that a client had solved a CAPTCHA, but they can be applied to other
        types of user or device attestation checks as well. In Privacy Pass,
        clients interact with an attester and issuer for the purposes of
        issuing a token, and clients then interact with an origin server to
        redeem said token.</t>
        <t>In Privacy Pass, privacy partitioning is achieved with cryptographic protection (in the form of blind
signature protocols or similar) and separation of connections across two contexts:
a "redemption context" between clients and origins (servers that request and receive tokens), and an
"issuance context" between clients, attestation servers, and token issuance servers. The cryptographic
protection ensures that information revealed during the issuance context is separated from information
revealed during the redemption context.</t>
        <figure anchor="diagram-privacypass">
          <name>Diagram of contexts Contexts in Privacy Pass</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
                <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
                <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
                <path d="M 184,64 L 184,128" fill="none" stroke="black"/>
                <path d="M 184,192 L 184,256" fill="none" stroke="black"/>
                <path d="M 256,64 L 256,128" fill="none" stroke="black"/>
                <path d="M 256,192 L 256,256" fill="none" stroke="black"/>
                <path d="M 312,192 L 312,256" fill="none" stroke="black"/>
                <path d="M 400,192 L 400,256" fill="none" stroke="black"/>
                <path d="M 456,192 L 456,256" fill="none" stroke="black"/>
                <path d="M 528,192 L 528,256" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,288" fill="none" stroke="black"/>
                <path d="M 8,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 184,64 L 256,64" fill="none" stroke="black"/>
                <path d="M 104,96 L 184,96" fill="none" stroke="black"/>
                <path d="M 32,128 L 104,128" fill="none" stroke="black"/>
                <path d="M 184,128 L 256,128" fill="none" stroke="black"/>
                <path d="M 8,160 L 552,160" fill="none" stroke="black"/>
                <path d="M 184,192 L 256,192" fill="none" stroke="black"/>
                <path d="M 312,192 L 400,192" fill="none" stroke="black"/>
                <path d="M 456,192 L 528,192" fill="none" stroke="black"/>
                <path d="M 256,224 L 312,224" fill="none" stroke="black"/>
                <path d="M 400,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 184,256 L 256,256" fill="none" stroke="black"/>
                <path d="M 312,256 L 400,256" fill="none" stroke="black"/>
                <path d="M 456,256 L 528,256" fill="none" stroke="black"/>
                <path d="M 8,288 L 552,288" fill="none" stroke="black"/>
                <g class="text">
                  <text x="60" y="52">Redemption</text>
                  <text x="136" y="52">Context</text>
                  <text x="68" y="100">Origin</text>
                  <text x="220" y="100">Client</text>
                  <text x="52" y="180">Issuance</text>
                  <text x="120" y="180">Context</text>
                  <text x="220" y="228">Client</text>
                  <text x="356" y="228">Attester</text>
                  <text x="492" y="228">Issuer</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------------+
| Redemption Context                                                |
|  +--------+         +--------+                                    |
|  |        |         |        |                                    |
|  | Origin +---------+ Client |                                    |
|  |        |         |        |                                    |
|  +--------+         +--------+                                    |
|                                                                   |
+-------------------------------------------------------------------+
| Issuance Context                                                  |
|                     +--------+      +----------+      +--------+  |
|                     |        |      |          |      |        |  |
|                     | Client +------+ Attester +------+ Issuer |  |
|                     |        |      |          |      |        |  |
|                     +--------+      +----------+      +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
]]></artwork>
          </artset>
        </figure>
<!-- [rfced] May we update the text as follows for clarity?

Original:
   Clients can fetch tokens through the issuance context early, and
   cache the tokens to later use in redemption contexts.

Perhaps:
   Clients can fetch tokens through the issuance context early and
   cache the tokens for later use in redemption contexts.
-->

        <t>Since the redemption context and issuance context are separate
        connections that involve separate entities, they can also be further
        decoupled by running those parts of the protocols at different
        times. Clients can fetch tokens through the issuance context early, early and
        cache the tokens to later use in redemption contexts. This can aid in
        partitioning identifiers and data.</t>
        <t><xref target="PRIVACYPASS"/> target="I-D.ietf-privacypass-architecture"/> describes
        different deployment models for which entities operate origins,
        attesters, and issuers; in some models, they are all separate
        entities, but and in others, others they can be operated by the same entity. The
        model impacts the effectiveness of partitioning, and some models (such
        as when all three are operated by the same entity) only provide
        effective partitioning when the timing of connections on the two
        contexts are not correlated, correlated and when the client uses different
        identifiers (such as different IP addresses) on each context.</t>
      </section>

      <section anchor="privacy-preserving-measurement">
        <name>Privacy Preserving Measurement</name>
        <t>The Privacy Preserving Measurement (PPM) working group Working Group is chartered
        to develop protocols and systems that help a data aggregation or
        collection server (or multiple, multiple non-colluding servers) compute
        aggregate values without learning the value of any one client's
        individual measurement. The Distributed Aggregation Protocol (DAP) is the
        primary working item of the group.</t>
        <t>At a high level, DAP uses a combination of cryptographic protection
        (in the form of secret sharing amongst non-colluding servers) to
        establish two contexts: an contexts:</t>
	<ul spacing="normal">

	  <li>an "upload context" between clients and non-colluding
	  aggregation servers (in which the servers are separated into
	  "Helper" and "Leader" roles) wherein aggregation servers possibly
	  learn client identity but nothing about their individual measurement reports, and
a
	  reports; and</li>
	  <li>a "collect context" wherein a collector learns
	  aggregate measurement results and nothing about individual client data.</t>
	  data.</li>
	</ul>
        <figure anchor="pa-topology">
          <name>Diagram of contexts Contexts in DAP</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="224" width="488" viewBox="0 0 488 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,208" fill="none" stroke="black"/>
                <path d="M 24,96 L 24,160" fill="none" stroke="black"/>
                <path d="M 96,96 L 96,160" fill="none" stroke="black"/>
                <path d="M 128,80 L 128,112" fill="none" stroke="black"/>
                <path d="M 128,144 L 128,176" fill="none" stroke="black"/>
                <path d="M 184,64 L 184,96" fill="none" stroke="black"/>
                <path d="M 184,160 L 184,192" fill="none" stroke="black"/>
                <path d="M 240,104 L 240,152" fill="none" stroke="black"/>
                <path d="M 288,64 L 288,96" fill="none" stroke="black"/>
                <path d="M 288,160 L 288,192" fill="none" stroke="black"/>
                <path d="M 312,32 L 312,168" fill="none" stroke="black"/>
                <path d="M 312,184 L 312,208" fill="none" stroke="black"/>
                <path d="M 344,112 L 344,144" fill="none" stroke="black"/>
                <path d="M 392,144 L 392,176" fill="none" stroke="black"/>
                <path d="M 440,112 L 440,144" fill="none" stroke="black"/>
                <path d="M 480,32 L 480,208" fill="none" stroke="black"/>
                <path d="M 8,32 L 480,32" fill="none" stroke="black"/>
                <path d="M 184,64 L 288,64" fill="none" stroke="black"/>
                <path d="M 128,80 L 176,80" fill="none" stroke="black"/>
                <path d="M 24,96 L 96,96" fill="none" stroke="black"/>
                <path d="M 184,96 L 288,96" fill="none" stroke="black"/>
                <path d="M 96,112 L 128,112" fill="none" stroke="black"/>
                <path d="M 344,112 L 440,112" fill="none" stroke="black"/>
                <path d="M 96,144 L 128,144" fill="none" stroke="black"/>
                <path d="M 344,144 L 440,144" fill="none" stroke="black"/>
                <path d="M 24,160 L 96,160" fill="none" stroke="black"/>
                <path d="M 184,160 L 288,160" fill="none" stroke="black"/>
                <path d="M 128,176 L 176,176" fill="none" stroke="black"/>
                <path d="M 296,176 L 392,176" fill="none" stroke="black"/>
                <path d="M 184,192 L 288,192" fill="none" stroke="black"/>
                <path d="M 8,208 L 480,208" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="304,176 292,170.4 292,181.6" fill="black" transform="rotate(180,296,176)"/>
                <polygon class="arrowhead" points="248,152 236,146.4 236,157.6" fill="black" transform="rotate(90,240,152)"/>
                <polygon class="arrowhead" points="248,104 236,98.4 236,109.6" fill="black" transform="rotate(270,240,104)"/>
                <polygon class="arrowhead" points="184,176 172,170.4 172,181.6" fill="black" transform="rotate(0,176,176)"/>
                <polygon class="arrowhead" points="184,80 172,74.4 172,85.6" fill="black" transform="rotate(0,176,80)"/>
                <g class="text">
                  <text x="44" y="52">Upload</text>
                  <text x="104" y="52">Context</text>
                  <text x="352" y="52">Collect</text>
                  <text x="416" y="52">Context</text>
                  <text x="236" y="84">Helper</text>
                  <text x="60" y="132">Client</text>
                  <text x="392" y="132">Collector</text>
                  <text x="236" y="180">Leader</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
+-------------------------------------+--------------------+
| Upload Context                      | Collect Context    |
|                     +------------+  |                    |
|              +----->|   Helper   |  |                    |
| +--------+   |      +------------+  |                    |
| |        +---+             ^        |   +-----------+    |
| | Client |                 |        |   | Collector |    |
| |        +---+             v        |   +-----+-----+    |
| +--------+   |      +------------+  |         |          |
|              +----->|   Leader   |<-----------+          |
|                     +------------+  |                    |
+-------------------------------------+--------------------+
]]></artwork>
          </artset>
        </figure>
      </section>
    </section>
    <section anchor="applying-privacy-partitioning">
      <name>Applying Privacy Partitioning</name>
      <t>Applying privacy partitioning to an existing or new system or
      protocol requires the following steps:</t>
      <ol spacing="normal" type="1"><li>
          <t>Identify type="1">
	<li>Identify the types of information used or exposed in a system or
	protocol, some of which can be used to identify a user or correlate to
	other contexts.</t>
        </li>
        <li>
          <t>Partition contexts.</li>
        <li>Partition data to minimize the amount of user-identifying or
        correlatable information in any given context to only include what is
        necessary for that
context, context and prevent the sharing of data across
        contexts wherever possible.</t>
        </li> possible.</li>
      </ol>
      <t>The most impactful types of information to partition are (a)
      user-identifying information, such as user identifiers (including
      account names or IP addresses) that can be linked and (b)
      non-user-identifying information (including content a user generates or
      accesses), which can be often sensitive when combined with a user
      identifier.</t>
      <t>In this section, we discuss considerations for partitioning these types of information.</t>
      <section anchor="user-identifying-information">
        <name>User-Identifying Information</name>
<!-- [rfced] We believe "but" is the wrong conjunction here.  Please consider the suggested update below.

Original:
   Collusion across contexts could reverse this
   partitioning, but can also promote non-user-identifying information
   to user-identifying.

Perhaps:
   Collusion across contexts could reverse this
   partitioning and cause non-user-identifying information to become
   user-identifying information.
-->
        <t>User data can itself be user-identifying, in which case it should
        be treated as an identifier.  For example, Oblivious DoH and Oblivious
        HTTP partition the client IP address and client request data into
        separate contexts, thereby ensuring that no entity beyond the client
        can observe both. Collusion across contexts could reverse this partitioning,
        partitioning but can also promote non-user-identifying information to
        user-identifying.  For example, in CONNECT proxy systems that use
        QUIC, the QUIC connection ID is inherently non-user-identifying since
        it is generated randomly (<xref section="5.1" sectionFormat="comma" target="QUIC"/>). sectionFormat="of"
        target="RFC9000"/>). However, if combined with another context that
        has user-identifying information such as the client IP address, the
        QUIC connection ID can become user-identifying information.</t>

<!-- [rfced] Is the information innate to A) user-agents or B) user-agents and
the network location?

Original:
   Some information is innate to client user-agents, including details
   of implementation of protocols in hardware and software, and network
   location.

Perhaps:
   Some information is innate to client user-agents, including details
   of the network location and implementation of protocols in hardware
   and software.
-->

<!-- [rfced] "promote" is unclear here.  May we update the text as follows?

Original:
   As a result, fingerprinting information, when combined with non-user-
   identifying user data, could promote user data to user-identifying
   information.

Perhaps:
   As a result, fingerprinting information, when combined with non-user-
   identifying user data, could become user-identifying information.
-->
        <t>Some information is innate to client user-agents, including details
        of implementation of protocols in hardware and software, and network
        location. This information can be used to construct user-identifying
        information, which is a process sometimes referred to as fingerprinting.
        "fingerprinting".  Depending on the application and system
        constraints, users may not be able to prevent fingerprinting in
        privacy contexts. As a result, fingerprinting information, when
        combined with non-user-identifying user data, could promote user data
        to user-identifying information.</t>
      </section>
      <section anchor="selecting-client-identifiers">
        <name>Selecting Client Identifiers</name>
        <t>The selection of client identifiers used in the contexts used for
        privacy partitioning has a large impact on the effectiveness of
        partitioning. Identifier selection can either undermine or improve the
        value of partitioning. Generally, each context involves some form of
        client identifier, which might be directly associated with a client identity,
        identity but can also be a pseudonym or a random one-time
        identifier.</t>
        <t>Using the same client identifier across multiple contexts can
        partly or wholly undermine the effectiveness of partitioning, partitioning by
        allowing the various contexts to be linked back to the same client.
        For example, if a client uses proxies as described in <xref
        target="masque"/> to separate connections, connections but uses the same email
        address to authenticate to two servers in different contexts, those
        actions can be linked back to the same client. While this does not
        undermine all of the partitioning achieved through proxying (the
        contexts along the network path still cannot correlate the client
        identity and what servers are being accessed), the overall effect of
        partitioning is diminished.</t>
        <t>When possible, using per-context unique client identifiers provides better partitioning properties.
For example, a client can use a unique email address as an account identifier with each different
server it needs to log into. The same approach can apply across many layers, as seen with
per-network MAC address randomization <xref target="I-D.ietf-madinas-mac-address-randomization"/>, use of
multiple temporary IP addresses across connections and over time <xref target="RFC8981"/>, and use of
unique per-subscription identifiers for HTTP Web Push <xref target="RFC8030"/>.</t>
      </section>
      <section anchor="incorrect-or-incomplete-partitioning">
        <name>Incorrect or Incomplete Partitioning</name>
        <t>Privacy partitioning can be applied incorrectly or
        incompletely. Contexts may contain more user-identifying information
        than desired, or some information in a context may be more
        user-identifying than intended. Moreover, splitting user-identifying
        information over multiple contexts has to be done with care, as
        creating more contexts can increase the number of entities that need
        to be trusted to not collude.  Nevertheless, partitions can help
        improve the client's privacy posture when applied carefully.</t>
        <t>Evaluating and qualifying the resulting privacy of a system or
        protocol that applies privacy partitioning depends on the contexts
        that exist and the types of user-identifying information in each
        context. Such evaluation is helpful for identifying ways in which
        systems or protocols can improve their privacy posture. For example,
        consider DNS-over-HTTPS DNS over HTTPS <xref target="DOH"/>, target="RFC8484"/>, which produces a
        single context which that contains both the client IP address and client
        query. One application of privacy partitioning results in ODoH, which
        produces two contexts, one with the client IP address and the other
        with the client query.</t>
      </section>
      <section anchor="selecting-information-within-a-context">
        <name>Selecting Information Within within a Context</name>
        <t>Recognizing potential applications of privacy partitioning requires
        identifying the contexts in use, the information exposed in a context,
        and the intent of information exposed in a context. Unfortunately,
        determining what information to include in a given context is a
        non-trivial task. In principle, the information contained in a context
        should be fit for purpose. As such, new systems or protocols developed
        should aim to ensure that all information exposed in a context serves
        as few purposes as possible. Designing with this principle from the
        start helps mitigate issues that arise if users of the system or
        protocol inadvertently ossify on the information available in
        contexts. Legacy systems that have ossified on information available
        in contexts may be difficult to change in practice. As an example,
        many existing anti-abuse systems depend on some client identifier identifier,
        such as the client IP address, coupled with client data, data to provide
        value. Partitioning contexts in these systems such that they no longer
        determine the client identity requires new solutions to the anti-abuse
        problem.</t>
      </section>
    </section>
    <section anchor="limits">
      <name>Limits of Privacy Partitioning</name>
      <t>Privacy partitioning aims to increase user privacy, though though, as
      stated, it is merely one of possibly many architectural tools that help
      manage privacy risks. Understanding the limits of its benefits requires
      a more comprehensive analysis of the system in question.  Such analysis
      also helps determine whether or not the tool has been applied
      correctly. In particular, the value of privacy partitioning depends on
      numerous factors, including, though not limited to:</t>
      <ul spacing="normal">
        <li>
          <t>Non-collusion to, the following: </t>
<ul><li>non-collusion
      across contexts; and</t>
        </li>
        <li>
          <t>The contexts and</li> <li>the type of information exposed in each context.</t>
        </li>
      </ul>
      context.</li></ul>
      <t>We elaborate on each below.</t> in the following sections.</t>
      <section anchor="violations-by-collusion">
        <name>Violations by Collusion</name>
        <t>Privacy partitions ensure that only the client, i.e., the entity which
        that is responsible for partitioning, can independently link all
        user-specific information. No other entity individually knows how to
        link all the user-specific information as long as they do not collude
        with each other across contexts. Thus, non-collusion is a fundamental
        requirement for privacy partitioning to offer meaningful privacy for end-users.
        end users. In particular, the trust relationships that users have with
        different parties affect the resulting impact on the user's
        privacy.</t>
        <t>As an example, consider OHTTP, Oblivious HTTP (OHTTP), wherein the Oblivious Relay knows
        the client identity but not the client data, and the Oblivious Gateway
        knows the client data but not the client identity.  If the Oblivious
        Relay and Gateway collude, they can link client identity and data
        together for each request and response transaction by simply observing
        requests in transit.</t>
        <t>It is not currently possible to guarantee with technical protocol
        measures that two entities are not colluding. Even if two entities do
        not collude directly, if both entities reveal information to other
        parties, it will not be possible to guarantee that the information
        won't be combined. However, there are some mitigations that can be
        applied to reduce the risk of collusion happening in practice:</t>
        <ul spacing="normal">
          <li>
            <t>Policy
          <li>Policy and contractual agreements between entities involved in
          partitioning to disallow logging or sharing of data, along with
          auditing to validate that the policies are being followed.  For
          cases where logging is required (such as for service operation),
          such logged data should be minimized and anonymized to prevent it
          from being useful for collusion.</t>
          </li>
          <li>
            <t>Protocol collusion.</li>
          <li>Protocol requirements to make collusion or data sharing more difficult.</t>
          </li>
          <li>
            <t>Adding
          difficult.</li>
          <li>Adding more partitions and contexts, contexts to make it increasingly
          difficult to collude with enough parties to recover identities.</t>
          </li> identities.</li>
        </ul>
      </section>
      <section anchor="violations-by-insufficient-or-incorrect-partitioning">
        <name>Violations by Insufficient or Incorrect Partitioning</name>
        <t>Insufficient or incorrect application of privacy partitioning can
        lessen or negate benefits to users.  In particular, it is possible to
        apply partitioning in a way that is either insufficient or incorrect
        for meaningful privacy. For example, partitioning at one layer in the
        stack can fail to account for linkable information at different layers
        in the stack. Privacy violations can stem from partitioning failures
        in a multitude of ways, some of which are described below.</t> in the following
        sections.</t>
        <section anchor="violations-from-application-information">
          <name>Violations from Application Information</name>
          <t>Partitioning at the network layer can be insufficient when the
          application layer fails to properly partition. As an example,
          consider OHTTP used for the purposes of hiding client-identifying
          information for a browser telemetry system. It is entirely possible
          for reports in such a telemetry system to contain both
          client-specific telemetry data, such as information about their
          specific browser instance, as well as client-identifying
          information, such as the client's email address, location, or IP
          address. Even though OHTTP separates the client IP address from the
          server via a relay, the server can still learn this directly from
          the client's telemetry report.</t>
        </section>
        <section anchor="violations-from-network-information">
          <name>Violations from Network Information</name>
          <t>It is also possible to inadequately partition at the network
          layer. As an example, consider both TLS Encrypted Client Hello (ECH)
          <xref target="I-D.ietf-tls-esni"/> and VPNs. ECH uses cryptographic
          protection (encryption) to hide information from unauthorized
          parties, but both clients and servers (two entities) can link
          user-specific data to a user-specific identifier (IP address).
          Similarly, while VPNs hide identifiers from end servers, the VPN
          server can still see the identifiers of both the client and
          server. Applying privacy partitioning would advocate for at least
          two additional entities to avoid revealing both identity (who) and
          user actions (what) from each involved party.</t>
        </section>
        <section anchor="violations-from-side-channels">
          <name>Violations from Side Channels</name>
          <t>Beyond the information that is intentionally revealed by applying
          privacy partitioning, it is also possible for the information to be
          unintentionally revealed through side channels. For example, in the
          two-hop proxy arrangement described in <xref target="masque"/>,
          Proxy A sees and proxies TLS data between the client and Proxy
          B. While it does not directly learn information that Proxy B sees,
          it does learn information through metadata, such as the timing and
          size of encrypted data being proxied. Traffic analysis could be
          exploited to learn more information from such metadata, including,
          in some cases, application data that Proxy A was never meant to
          see. Although privacy partitioning does not obviate such attacks, it
          does increase the cost necessary to carry them out in practice. See
          <xref target="security-considerations"/> for more discussion on this
          topic.</t>
        </section>
        <section anchor="identifying-partitions">
          <name>Identifying Partitions</name>
          <t>While straightforward violations of user privacy that stem from
          insufficient partitioning may seem straightforward to mitigate, it
          remains an open problem to rigorously determine what information
          needs to be partitioned for meaningful
privacy, privacy and to implement it
          in a way that achieves the desired properties. In essence, it is
          difficult to determine whether a certain set of information reveals
          "too much" about a specific user, and it is similarly challenging to
          determine whether or not an implementation of partitioning works as
          intended. There is ample evidence of data being assumed "private" or
          "anonymous" but, in hindsight, winds up revealing too much
          information such that it allows one to link back to individual
          clients; see <xref target="DataSetReconstruction"/> and <xref
          target="CensusReconstruction"/> for more examples of this in the
          real world.</t>
        </section>
      </section>
    </section>
    <section anchor="partitioning-impacts">
      <name>Partitioning Impacts</name>
      <t>Applying privacy partitioning to communication protocols leads to a
      substantial change in communication patterns.  For example, instead of
      sending traffic directly to a service, essentially all user traffic is
      routed through a set of intermediaries, possibly adding more end-to-end
      round trips in the process (depending on the system and protocol). This
      has a number of practical implications, described below.</t>
      <ol spacing="normal" type="1"><li>
          <t>Service spacing="normal">
<!-- [rfced] We are having trouble parsing some of this text.  Are "security procedures" an example?  In the last sentence, is "but" necessary?  Perhaps use "commonly" or "usually" instead of "traditionally" because "traditional" is ambiguous since it is not the same for everyone?

Original:
   1.  Service operational or management challenges.  Information that
       is traditionally passively observed in the network or metadata
       that has been unintentionally revealed to the service provider
       cannot be used anymore for e.g., existing security procedures
       such as application rate limiting or DDoS mitigation.  However,
       network management techniques deployed at present often rely on
       information that is exposed by most traffic but without any
       guarantees that the information is accurate.  </t>
          <t>

Perhaps A:
   1. Service operational or management challenges. Information that
      is traditionally passively observed in the network or metadata
      that has been unintentionally revealed to the service provider
      can no longer be used (e.g., existing security procedures
      such as application rate limiting or DDoS mitigation).  However,
      presently deployed network-management techniques often rely on
      information that is exposed by most traffic without any
      guarantee that the information is accurate.

Perhaps B:
   1.  Service operational or management challenges:  Information that
       is traditionally passively observed in the network or metadata
       that has been unintentionally revealed to the service provider
       cannot no longer be used for existing security procedures
       such as application rate limiting or DDoS mitigation.  However,
       presently deployed network-management techniques often rely on
       information that is exposed by most traffic without any
       guarantee that the information is accurate.
-->

	<li><t>Service operational or management challenges:
	Information that is traditionally passively observed in the
	network or metadata that has been unintentionally revealed to the
	service provider can no longer be used for, for example, existing security
	procedures such as application rate limiting or DDoS mitigation.
	However, presently deployed network-management techniques often rely
	on information that is exposed by most traffic but without any
	guarantees that the information is accurate.</t>
<!-- [rfced] Is there a word missing after "rather than relying on the assumption that"?  Perhaps "relying on the assumption that data is derived"?  Also, we wonder whether the "cannot be guaranteed to be present and may disappear at any time in future" could be simplified as "cannot be guaranteed to be and remain present at any future time."

Original:
       Privacy partitioning provides an opportunity for improvements in
       these management techniques by enabling active exchange of
       information with each entity in a privacy-preserving way and
       requesting exactly the information needed for a specific task or
       function rather than relying on the assumption that are derived
       from a limited set of unintentionally revealed information which
       cannot be guaranteed to be present and may disappear at any time
       in future.
-->

        <t>Privacy partitioning provides an opportunity for improvements in
        these management techniques by enabling active exchange of information
        with each entity in a privacy-preserving way and requesting exactly
        the information needed for a specific task or function rather than
        relying on the assumption that is derived from a limited set of
        unintentionally revealed information that cannot be guaranteed to be
        present and may disappear at any time in future.</t>
        </li>
        <li>
          <t>Varying

        <li><t>Varying performance effects and costs. costs:
	Depending on how context separation is done, privacy
	partitioning may affect application performance. As an example,
	Privacy Pass introduces an entire end-to-end round trip to issue a
	token before it can be redeemed, thereby decreasing performance. In
	contrast, while systems like CONNECT proxying may seem like they would
<!-- [rfced] Is "regress performance" a commonly understood phrase?  Otherwise, perhaps this can be changed to "diminish performance"?

Original:
       In contrast, while systems like
       CONNECT proxying may seem like they would regress performance,
       oftentimes the highly optimized nature of proxy-to-proxy paths
       leads to improved performance.  </t>
          <t>
-->

	regress performance, oftentimes the highly optimized nature of
	proxy-to-proxy paths leads to improved performance.</t>
<!-- [rfced] As performance itself cannot push back on something, we wonder if the lower performance may be used as a rationale against using privacy partitioning?

Original:
       Performance may also push back against the desire to apply
       privacy partitioning.

Perhaps:
       Lower performance may also be a consideration against
       privacy partitioning.

Later in the paragraph, perhaps "at the cost of less performance" should be "at the cost of performance" or "but it typically causes lower performance"?

Original:
       Performance may also push back against the desire to apply
       privacy partitioning. ...
       Applying privacy partitioning would prevent this, while typically
       at the cost of less performance.

Perhaps:
       Lower performance may also be a consideration against
       privacy partitioning. ...
       Applying privacy partitioning would prevent this, but typically
       at the cost of performance.
-->

        <t>Performance may also push back against the desire to apply privacy
        partitioning. For example, HTTPS connection reuse <xref (<xref
        section="9.1.1" sectionFormat="comma" target="HTTP2"/> sectionFormat="of" target="RFC9113"/>) allows
        clients to use an existing HTTPS session created for one origin to
        interact with different origins (provided that the original origin is
        authoritative for these alternative origins). Reusing connections
        saves the cost of connection establishment, establishment but means that the server
        can now link the client's activity with these two or more origins
        together. Applying privacy partitioning would prevent this, while but
        typically at the cost of less performance.  </t>
          <t>
In performance.</t>
        <t>In general, while performance and privacy tradeoffs trade-offs are often cast
        as a zero-sum game, in practice this is often not the case. The
        relationship between privacy and performance varies depending on a
        number of related factors, such as application characteristics,
        network path properties, and so on.</t>
        </li>
        <li>
          <t>Increased
        <li><t>Increased attack surface. surface:
	Even in the event that information is adequately partitioned
	across non-colluding parties, the resulting effects on the end-user end user
	may not always be positive. For example, using OHTTP as a basis for
	illustration, consider a hypothetical scenario where the Oblivious
	Gateway has an implementation flaw that causes all of its decrypt
	requests to be inappropriately logged to in a public or otherwise
	compromised location. Moreover, assume that the Target Resource for
	which these requests are destined does not have such an implementation
	flaw. Applications which that use OHTTP with this flawed Oblivious Gateway
	to interact with the Target Resource risk their user request
	information being made public, albeit in a way that is decoupled from
	user identifying information, whereas applications that do not use
	OHTTP to interact with the Target Resource do not risk this type of disclosure.</t>
        </li>
        <li>
          <t>Centralization.
	disclosure.</t></li>
        <li><t>Centralization: Depending on the protocol and system, as well
        as the desired privacy properties, the use of partitioning may
        inherently force centralization to a selected set of trusted
        participants.  As an example, the impact of OHTTP on end-user privacy
        generally increases proportionally to the number of users that exist
        behind a given Oblivious Relay. That is, the probability of an
        Oblivious Gateway determining the client associated with a request
        forwarded through an Oblivious Relay decreases as the number of
        possible clients behind the Oblivious Relay increases. This tradeoff trade-off
        encourages the centralization of the Oblivious Relays.</t>
        </li> Relays.</t></li>
      </ol>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t><xref target="limits"/> discusses some of the limitations of privacy
      partitioning in practice, practice and advocates for holistic analysis to
      understand the extent to which privacy partitioning offers meaningful
      privacy improvements.  Applied correctly, partitioning helps improve an
      end-user's privacy posture, thereby making violations harder to do via
      technical, social, or policy means. For example, side channels such as
      traffic analysis <xref target="I-D.irtf-pearg-website-fingerprinting"/>
      or timing analysis are still possible and can allow an unauthorized
      entity to learn information about a context they are not a participant
      of.  Proposed mitigations for these types of attacks, e.g., padding
      application traffic or generating fake traffic, can be very expensive
      and are therefore not typically applied in practice.  Nevertheless,
      privacy partitioning moves the threat vector from one that has direct
      access to user-specific information to one which that requires more effort,
      e.g., computational resources, to violate end-user privacy.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>

  <back>

    <displayreference target="RFC9297" to="CONNECT-UDP"/>
    <displayreference target="RFC9484" to="CONNECT-IP"/>
    <displayreference target="RFC9458" to="OHTTP"/>
    <displayreference target="RFC9180" to="HPKE"/>
    <displayreference target="RFC9230" to="ODOH"/>
    <displayreference target="RFC9000" to="QUIC"/>
    <displayreference target="I-D.ietf-madinas-mac-address-randomization" to="RANDOM-MAC"/>
    <displayreference target="RFC8484" to="DOH"/>
    <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
    <displayreference target="RFC9113" to="HTTP2"/>
    <displayreference target="I-D.irtf-pearg-website-fingerprinting" to="FINGERPINT"/>
    <displayreference target="I-D.ietf-privacypass-architecture" to="PRIVACYPASS"/>

    <references anchor="sec-informative-references">
      <name>Informative References</name>

      <reference anchor="CensusReconstruction" target="https://www.census.gov/data/academy/webinars/2021/disclosure-avoidance-series/simulated-reconstruction-abetted-re-identification-attack-on-the-2010-census.html">
        <front>
          <title>The Census Bureau's Simulated Reconstruction-Abetted
          Re-identification Attack on the 2010 Census</title>
          <author>
            <organization/>
            <organization>United States Consensus Bureau</organization>
          </author>
          <date>n.d.</date>
          <date month="May" year="2021"/>
        </front>
      </reference>

      <reference anchor="DECOUPLING">
        <front>
          <title>The decoupling principle: a practical privacy framework</title>
          <author fullname="Paul Schmitt" initials="P." surname="Schmitt">
            <organization>University of Hawai'i</organization>
          </author>
          <author fullname="Jana Iyengar" initials="J." surname="Iyengar">
            <organization>Fastly</organization>
          </author>
          <author fullname="Christopher Wood" initials="C." surname="Wood">
            <organization>Cloudflare</organization>
          </author>
          <author fullname="Barath Raghavan" initials="B." surname="Raghavan">
            <organization>USC</organization>
          </author>
          <date month="November" year="2022"/>
        </front>
        <seriesInfo name="Proceedings
        <refcontent>Proceedings of the 21st ACM Workshop on Hot Topics in" value="Networks"/>
        <seriesInfo name="DOI" value="10.1145/3563766.3564112"/>
        <refcontent>ACM</refcontent>
      </reference>
      <reference anchor="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"/> Networks</refcontent>
        <seriesInfo name="DOI" value="10.17487/RFC6973"/>
      </reference>
      <reference anchor="CONNECT-UDP">
        <front>
          <title>HTTP Datagrams and the Capsule Protocol</title>
          <author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
          <author fullname="L. Pardue" initials="L." surname="Pardue"/>
          <date month="August" year="2022"/>
          <abstract>
            <t>This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection.</t>
            <t>In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections.</t>
            <t>HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9297"/>
        <seriesInfo name="DOI" value="10.17487/RFC9297"/> value="10.1145/3563766.3564112"/>
      </reference>
      <reference anchor="CONNECT-IP">
        <front>
          <title>Proxying IP in HTTP</title>
          <author fullname="Tommy Pauly" initials="T." surname="Pauly">
            <organization>Apple Inc.</organization>
          </author>
          <author fullname="David Schinazi" initials="D." surname="Schinazi">
            <organization>Google LLC</organization>
          </author>
          <author fullname="Alex Chernyakhovsky" initials="A." surname="Chernyakhovsky">
            <organization>Google LLC</organization>
          </author>
          <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
            <organization>Ericsson</organization>
          </author>
          <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
            <organization>Ericsson</organization>
          </author>
          <date day="28" month="April" year="2023"/>
          <abstract>
            <t>This document describes how to proxy IP packets in HTTP.  This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy.  This document updates

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

     <!-- [I-D.ietf-privacypass-architecture] [PRIVACYPASS] IESG state: RFC 9298.
            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-masque-connect-ip-13"/>
      </reference>
      <reference anchor="OHTTP">
        <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="25" month="August" year="2023"/>
          <abstract>
            <t>   This document describes Oblivious HTTP, a protocol for forwarding
   encrypted HTTP messages.  Oblivious HTTP allows a client to make
   multiple requests to an origin server without that server being able
   to link those requests to the client or to identify the requests as
   having come from the same client, while placing only limited trust in
   the nodes used ED Queue 03/28/24-->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-privacypass-architecture.xml"/>

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

      <!-- [I-D.ietf-madinas-mac-address-randomization] [QUIC] IESG state: I-D
           Exists 01/31/24; updated to forward the messages.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-10"/>
      </reference>
      <reference anchor="HPKE">
        <front>
          <title>Hybrid Public Key Encryption</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes"/>
          <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
          <author fullname="B. Lipp" initials="B." surname="Lipp"/>
          <author fullname="C. Wood" initials="C." surname="Wood"/>
          <date month="February" year="2022"/>
          <abstract>
            <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), long version because missing editor
           role and SHA2.</t>
            <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9180"/>
        <seriesInfo name="DOI" value="10.17487/RFC9180"/>
      </reference>
      <reference anchor="ODOH">
        <front>
          <title>Oblivious DNS over HTTPS</title>
          <author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
          <author fullname="P. McManus" initials="P." surname="McManus"/>
          <author fullname="T. Pauly" initials="T." surname="Pauly"/>
          <author fullname="T. Verma" initials="T." surname="Verma"/>
          <author fullname="C.A. Wood" initials="C.A." surname="Wood"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.</t>
            <t>This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9230"/>
        <seriesInfo name="DOI" value="10.17487/RFC9230"/>
      </reference>
      <reference anchor="PRIVACYPASS">
        <front>
          <title>The Privacy Pass Architecture</title>
          <author fullname="Alex Davidson" initials="A." surname="Davidson">
            <organization>LIP</organization>
          </author>
          <author fullname="Jana Iyengar" initials="J." surname="Iyengar">
            <organization>Fastly</organization>
          </author>
          <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
            <organization>Cloudflare</organization>
          </author>
          <date day="25" month="September" year="2023"/>
          <abstract>
            <t>   This document specifies the Privacy Pass architecture and
   requirements for its constituent protocols used for authorization
   based on privacy-preserving authentication mechanisms.  It describes
   the conceptual model of Privacy Pass and its protocols, its security
   and privacy goals, practical deployment models, and recommendations
   for each deployment model that helps ensure the desired security and
   privacy goals are fulfilled.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-architecture-16"/>
      </reference>
      <reference anchor="QUIC">
        <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>
            <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9000"/>
        <seriesInfo name="DOI" value="10.17487/RFC9000"/>
      </reference> showing initials correctly -->
      <reference anchor="I-D.ietf-madinas-mac-address-randomization"> anchor="I-D.ietf-madinas-mac-address-randomization" target="https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-12">
	<front>
	  <title>Randomized and Changing MAC Address state of affairs</title>
	  <author initials="JC." surname="Zuniga" fullname="Juan-Carlos Zúñiga" initials="J. C." surname="Zúñiga"> Zuniga">
	    <organization>CISCO</organization>
	  </author>
	  <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardos" initials="C. J." surname="Bernardos"> role="editor">
	    <organization>Universidad Carlos III de Madrid</organization>
	  </author>
	  <author fullname="Amelia Andersdotter" initials="A." surname="Andersdotter"> surname="Andersdotter" fullname="Amelia Andersdotter">
	    <organization>Safespring AB</organization>
	  </author>
	  <date day="11" month="January" year="2024"/>
          <abstract>
            <t>   Internet privacy has become a major concern over the past few years.
   Users are becoming more aware that their online activity leaves a
   vast digital footprint, that communications are not always properly
   secured, and that their location and actions can be easily tracked.
   One of the main factors for the location tracking issue is the wide
   use of long-lasting identifiers, such as MAC addresses.

   There have been several initiatives at the IETF and the IEEE 802
   standards committees to overcome some of these privacy issues.  This
   document provides an overview of these activities, with the intention
   to inform the technical community about them, and help coordinate
   between present and future standardization activities.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-madinas-mac-address-randomization-10"/>
      </reference>
      <reference anchor="RFC8981">
        <front>
          <title>Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6</title>
          <author fullname="F. Gont" initials="F." surname="Gont"/>
          <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
          <author fullname="T. Narten" initials="T." surname="Narten"/>
          <author fullname="R. Draves" initials="R." surname="Draves"/>
          <date month="February" year="2021"/>
          <abstract>
            <t>This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8981"/>
        <seriesInfo name="DOI" value="10.17487/RFC8981"/>
      </reference>
      <reference anchor="RFC8030">
        <front>
          <title>Generic Event Delivery Using HTTP Push</title>
          <author fullname="M. Thomson" initials="M." surname="Thomson"/>
          <author fullname="E. Damaggio" initials="E." surname="Damaggio"/>
          <author fullname="B. Raymor" initials="B." role="editor" surname="Raymor"/>
          <date month="December" year="2016"/>
          <abstract>
            <t>This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8030"/>
        <seriesInfo name="DOI" value="10.17487/RFC8030"/>
      </reference>
      <reference anchor="DOH">
        <front>
          <title>DNS Queries over HTTPS (DoH)</title>
          <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
          <author fullname="P. McManus" initials="P." surname="McManus"/>
          <date month="October" year="2018"/>
          <abstract>
            <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8484"/>
        <seriesInfo name="DOI" value="10.17487/RFC8484"/>
      </reference>
      <reference anchor="I-D.ietf-tls-esni">
        <front>
          <title>TLS Encrypted Client Hello</title>
          <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
            <organization>RTFM, Inc.</organization>
          </author>
          <author fullname="Kazuho Oku" initials="K." surname="Oku">
            <organization>Fastly</organization>
          </author>
          <author fullname="Nick Sullivan" initials="N." surname="Sullivan">
            <organization>Cloudflare</organization>
          </author>
          <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
            <organization>Cloudflare</organization>
          </author>
          <date day="9" month="October" year="2023"/>
          <abstract>
            <t>   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

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/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

            </t>
          </abstract> day="28" year="2024"/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-17"/> value="draft-ietf-madinas-mac-address-randomization-12"/>
      </reference>

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

      <!-- [I-D.ietf-tls-esni] IESG state: I-D Exists 03/28/2024 -->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-tls-esni.xml"/>

      <reference anchor="DataSetReconstruction">
        <front>
          <title>Robust De-anonymization of Large Sparse Datasets</title>
          <author fullname="Arvind Narayanan" initials="A." surname="Narayanan">
            <organization/>
          </author>
          <author fullname="Vitaly Shmatikov" initials="V." surname="Shmatikov">
            <organization/>
          </author>
          <date month="May" year="2008"/>
        </front>
        <seriesInfo name="2008 IEEE
        <refcontent>IEEE Symposium on Security and Privacy (sp" value="2008)"/> Privacy</refcontent>
        <seriesInfo name="DOI" value="10.1109/sp.2008.33"/>
        <refcontent>IEEE</refcontent>
      </reference>
      <reference anchor="HTTP2">
        <front>
          <title>HTTP/2</title>
          <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
          <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on

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

      <!-- [I-D.irtf-pearg-website-fingerprinting] IESG state: Expired 03/28/24-->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-irtf-pearg-website-fingerprinting.xml"/>

    </references>
<section numbered="false" anchor="iab-members">
      <name>IAB Members at the same connection.</t>
            <t>This document obsoletes RFCs 7540 and 8740.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9113"/>
        <seriesInfo name="DOI" value="10.17487/RFC9113"/>
      </reference>
      <reference anchor="I-D.irtf-pearg-website-fingerprinting">
        <front>
          <title>Network-Based Website Fingerprinting</title>
          <author fullname="Ian Goldberg" initials="I." surname="Goldberg">
            <organization>University of Waterloo</organization>
          </author>
          <author fullname="Tao Wang" initials="T." surname="Wang">
            <organization>HK University Time of Science and Technology</organization>
          </author>
          <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
            <organization>Cloudflare</organization>
          </author>
          <date day="8" month="September" year="2020"/>
          <abstract>
            <t>   The IETF is well on its way to protecting connection metadata with
   protocols such as DNS-over-TLS and DNS-over-HTTPS, and work-in-
   progress towards encrypting the TLS SNI.  However, more work is
   needed to protect traffic metadata, especially in Approval</name>
<t>Internet Architecture Board members at the context of web
   traffic.  In time this document, we survey Website Fingerprinting attacks,
   which are a class of attacks that use machine learning techniques to
   attack web privacy, and highlight metadata leaks used by said
   attacks.  We also survey proposed mitigations for such leakage and
   discuss their applicability to IETF protocols such as TLS, QUIC, and
   HTTP.  We endeavor to show that Website Fingerprinting attacks are a
   serious problem that affect all Internet users, and we pose open
   problems and directions document was
   approved for future research in this area.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-pearg-website-fingerprinting-01"/>
      </reference>
    </references>
    <?line 834?> publication were:</t>
      <ul empty="true" spacing="compact" bare="false" indent="3">
        <li>
          <t><contact fullname="Dhruv Dhody"/></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="Suresh Krishnan"/></t>
        </li>
        <li>
          <t><contact fullname="Mirja Kühlewind"/></t>
        </li>
        <li>
          <t><contact fullname="Tommy Pauly"/></t>
        </li>
        <li>
          <t><contact fullname="Alvaro Retana"/></t>
        </li>
        <li>
          <t><contact fullname="David Schinazi"/></t>
        </li>
        <li>
          <t><contact fullname="Christopher Wood"/></t>
        </li>
        <li>
          <t><contact fullname="Qin Wu"/></t>
        </li>
        <li>
          <t><contact fullname="Jiankang Yao"/></t>
        </li>
      </ul>
</section>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank Martin Thomson, Eliot Lear, Mark Nottingham, Niels <contact fullname="Martin Thomson"/>, <contact
      fullname="Eliot Lear"/>, <contact fullname="Mark Nottingham"/>, <contact
      fullname="Niels ten Oever, Vittorio Bertola,
Antoine Fressancourt, Cullen Jennings, and Dhruv Dhody Oever"/>, <contact fullname="Vittorio Bertola"/>,
      <contact fullname="Antoine Fressancourt"/>, <contact fullname="Cullen
      Jennings"/>, and <contact fullname="Dhruv Dhody"/> for their reviews and
      feedback.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+1923bbRrbge30FlvohUpuk7aQviTPpbll22ppOYp3I6ax5
mbVAokjiGATYKFAKY7u/bN7mx2Zf6wKAshTLM52ew4fEIoG67Nq175fpdGq6
sqvsk+zoIm/hn2VTl/Uqy12W19lpu1iXnV10u9Zmy6bNLtryKl/sj0w+n7f2
qv9W8sgi7+yqafdPsrJeNsZ1rc03T7Lz06fGFM2izjcwa9Hmy25a5vPplt+b
bqMBp49+b2CSz8xru79u2gLerjvb1rabPsMXjcl33bppn5hsajL4LHdVxQN/
W7b/mWd/+9//a13Z67Iu6OemXeV1+XOOwz/Jnrflwrmmzr63zuawVXrGbvKy
epJt8P3Z652V9/9i5enZotkMp3vVbDb77CLfVfuRmU6328rGo3dbfPIvOX4/
PuDZui1d12zXts1OZ9mPTTO2hbOq2RXLKm+T0Rf59V/WNt8CBOdl52YAL2Pq
pt3AW1f2iTF4IP6vLDuztdu57+2iqeGUdgsamwYU3Hi1tvJQ9hRQId994rLL
crOr4IiLLH1xejq3HX89LQtbd+WyXNBys9OuyxevM/hXBwN++ujxIxmV58rb
le2eZOuu27onDx9eX1/PFvTzbNVcPSzyLn+YL/LCbvYPr+28rPPWPfz00aeP
HxalW1SNg5VN86umLPJ6YacODsy6h06XOW3TZea8TPi6t8xpTsucwr9gmVNc
5lTWse42lTFmOp1m+RyGyhcA2Ffr0mWA0LsNjJIV1i3acm4d7RGQul6UcMhZ
s8wEw7MYwyfZ9bpcrDNnK7hmcB7VPnNbAHEBY8KO4RYWGSDIZlcrFPNF2zhn
YFsdjUzDwXx4ZbONzWuYusnKzbZtrqyfdA7jWngUxoCLugPoZLztbp8t22bD
X+GUs4M7shvbrvD1LYAIrqGDmw0TNF2zaCqa1W8NtpV3YQcb2+X0R+kM0A2b
V4Ag3bptdqu1HwFGg1FzOh43wa+vYImOto84Y9tNWTdVs9pPaFA89p1z8MS6
uTYwe17n1f5nm7kdQHTTFLZyMz6tTVkUcAPNb5CAtE3BOGDMhV88vQMgfPXN
JQ1+fuHsQtcAgIW/kAgeI8FBsC0I9fFJWy/a/Rb+OskW67yubWUAta6thSVf
N/BzsW1gZy6D42jluMOXgES1W+Jp6J0EEpM95zHpuGGKaFJcNuASA7Pm18su
AwqQ1XZhncvbPZ0E7AwwKh6Wz3lu8QQdLg+oNUAJEB92Mt8rIpmmQ6LTwV4I
h/FU6gIe8edEDwJa57CBWXbKwJvAw4A2r4FWIrITvBC54LuwMGQQeJVaXAPM
0Jl4fQqLFiYjYMH0zipUXdYifQOsI5zuLJzti+YasKmdhAOSh7PxIygRZd1u
CXe9RNzG9cg9pVsCC8c//QsG/trA3byysNHzGlawwNf2wC4IQ/mt1v5jV8Li
LE6xzuHW2Z8AOAizud03dUGD1hZxPpxM7wjHkWaWXTYbHC/fwF13vEDYBU3g
EGhAYKpdgVR9mp3yLc4XCG9i4wCW9qpcWCS6eQZkE2aycB1W6y6rmy5Dkog7
gnXxvcSllm1WNYxrEzPfARIt6bD8YLCAfA6kB95q5vilpR0uKgQq8Ibziywv
ihYWMckAOReASRWArM4cbAbWX69AgGhgYHwLlwzv6IyzjMhPicfcwCSIGws6
KAU37GzBE+p6aIKyfm08EcOljQ0eQYmBcJ3z7ufWb4nBh6DpFEf41sKAe7pp
LHWUP9tiYpRw5HDA1/A/vBqVBbpewjOwRTx2wvaGUUPo/dYukOPo88Qu9gYJ
v/DHks6x2cEK+Moi/2oBp34BgIwCSPEDOA3ezRRIMp3AiA8TqD9BmI4ft0Jk
fretmpyoOgpFBDNAr9WqtSu+yXowfRgbhTECF5jKDpAxPi63d53deNgBwJhQ
IDQ8yPy7yCcMsCIeqJBBNh+CQbJtk8zhV+dXQA/NkPdbYU95RcSuFprlL2zp
GHb8ivOwUF5He0VKDIcQrqtRCMA9bxyjT5NtENXwsKZ+JY2y8eUen0qoaZNc
WqJfTLlBIGoBcYM4oEgQxvWywYB/pM8JU09JvBE440HskAQgqymQngfqR4go
zxGRwBPbbJu2EwC9tnYblnF8vW5OmOvDjOYYxYsTlWjsbCiFLcsaoH80KnMd
MR0qNyg1VQ5Jn3AdxGSW3I4KuG6A5yTuqBR3ZN68+fOz52cvf7j45vy7v371
7OX57PGj2ePHv/v9w89+/4fP/viHP8zg/797/PjTd+8mOtTK1nDUQFntYl2X
/9gRrGkuXT89RhtLhKWr0pVyX67ytmxA/FZhD0AKUj3oRK9T6ZDpDo2Xlxtk
FywIIsmNQQ5su0IMI/FrCCK8D8geVjtYH2AqrbAlwl83fFGUXSX4YPyB4UaG
qILiLryDek/JEsXWtiDywvmvbbV1LBwIuYnXC7Boqpxv/BxOBnjipsEHCaaL
vIJBQJJZInJ3TMTXJTA0kSPgqAFHLlFWgIM4f/7q6wxhhztdgRC6dUTW9asm
lmrhhjFVkoucFwQJIQkeNcxBAZ8ZNI77cl4B3cVjfPHq1QVphSrUk167AU7B
fx6/fHF6fjLJvhUh/ydbmPjxyx2pH53s7z9+OD+LZcbjb08v/+OH5zCAaOOg
mSIvxkPx3wB7RsoA6/rW5gh1ujnHFxffnggF9dfJ7TabHPmdM4RyROYaIFgK
PLyXXk3IgVCADktPItUFpubEquCZPkyOW+PLxUBrHJkZULiFgwQYAxmOJDc8
E2RcCzzJizGcLV1E3yoUyyp7hdSEuDMQ0IqWQ1cLNIlyI2q06mC4Y9lEAXJp
9ubNpSU9IfvD7DGu68/ff332hy/++Nm7dzP40f8RNJXVjpXPhNmgiAW/toy9
sBGjRoyAZXA0VQNboMuLXKDD+YBUOH4J1gA6DiId7KjaxSQj2QpiYR4rVNEm
/jjcRFB/CLUtsKxmP4rGBklFJ5ybtkMLCCsklCBusxD9D+65LDbwcABSuQKA
x+dEvC5D0aEloogbVY3cts4TfeLRc+S3QKrZ8oBKy5hSgu8YkUxbWpsFesAS
3U8dL3QNWDFHAua3iaLVKGLhxMQnQIAh0k0IdZ3vExruSZ+gA0xMDBMWu2el
mdWrY9C9Utya/Q4Pxp/LCXEOFiVgbkd3Ir7IPIQO8OaNHNgWfoK3b7geSNIB
PUBPXtj8SyLDLDaAGGKrShUZVKir0qHURCq1K51qRkwK8Xbo0SMMCsvKOUq3
lrRHwH+cbNu3KdI1ZEKUE8OviOyAIA0zwKV3Bi0Y8PRyV3lEFFsG6VegEBH4
KsD5DrZLV41YQaxAo6YfIBahsflaNb5dCxSHNapUFukS0reEf9BjdV9CivV1
JJeGhV3Rx2CL+8OiGSIgzOIHQ4ZF40+8IYIvDFn0jChTCNVYtVJilupS/SEK
YhPLbF623RqlQFoHMMyJIemkAY54gHmR9NokTJkuEj5Dwm6uEnuk5+IaIr0Z
IAe0mFQfUaxQawRU6fZbq9AfB6tIdahtgsiOuMKSgzBBQcnExgZqputoL2Vl
V5bkjdYiAQBKsPcLN37hsjoXLQ4HJaK622T5hjQwlKOi80NFiCU4QNNlWYnW
bJa7esEIMXoD8+IK9VCACdsdYGMx8UZylhhHIv5goo0LI1ephHYgyvtBWHrj
nHVBl5M9G9lzIurzNSnbyPzDNwbJC2Abncd+Mo42IHq6hDb+FsT335LUjSdf
CmX8LUrxv2W1umhIQYF/gxLsOm/oEH4CB2k9dyYWcUhsRRah8rUKgTQSIjoS
hkAZzpgfOGOeE1aXdnEzRoI6BmTREZsu2ZqhTEUwDTBVvjBkJGEjMQqnpJEI
6xD+zhKxivt8qmx+wh3pSbk1mRyio8q7lPqcJ/oVbLhmaqCcUi7L4W2JSVlW
7iYBqM6brWIigLQNtdJK1gr6Wc9oKNYDING2Wp6YorEuMATk0sgwa5Hh8SXE
C+XPDMk+SgI8RSGCUwQ9LMhfwRBM74gWyWcZSxIlGvCK3YIwJYKNsnMTq0uK
YE9gsif/2IHW+s78CVAmvFY6gfIGnREKZa+pITa5PuVQyYVNJmVdAKEqdnkF
Q9ONA+A28y5XaWoBZw/4Y1vmxiRU8XwgrMxm/eWgF8Sy5CuzwLipd2OWZUPx
k+7NMl+UVdnhycTAAaIEzKK5Zh6m63WfwMhiRyJMJQsaIvtrMYvrMmMN7E/w
0oWzu6Kp9xsxDqNfsF6hfRuepQ1WSIdBL3RoVUlEP1Q8vZ0n2+pIX9J7MDZJ
KKB6hJ9wBqIGNGiz7KxY1Anjs6W9hsUp3n9JP9EaYKd2i3SvhssLIy9Q3anD
uKwwEvouUWqi53gmJJ21vc7EkZEdb/LXIgFvJkz4EN9FOv0EuTrCkpxO9Ddu
fcveoEm2q3HTaDZDwU4olnfl8LEvgUcV9BdaGZoDNBm2Nob9M3NKvl6xWE2C
gA9f7mrv3WCd1aFhGREdD/XV2UVgsHwVeHkiA4GA3bAxwqgxVXg22bwZQHj7
SPgkl/M+WD8IUv5hvNPimMnWNkfx+kslmCaR/VUAC2RokoGaCjiPIhORKTWd
sFto3vxkyUqlKjg6DoXH0hnNzLf4ID1HFrfkSTFyMkPE078mRabN0RpBQho/
wCKyqG5Gfs+Emlb5HtZ17CU3eVaNcwBpBG4tIr8HjZBZum+gZnd80LRJ03tH
bZi0I9DwvyeFS64Fa5ck9whEvIHSBYuS7sksR4ToA8aPbsxZAARFMcF7QQL6
AJ7/85//zPLcXa3Mg+mHfx6Yt8rrs9Psl37ewiiZX86D/s/xQh8c+OmBjPK2
9wtereGbva37n976Uc74+N9mvc/b7Ft/jm/7P10SBkSjpNMB2ozs4n1r6cNl
CRzj7nD54M/be8IXwD/g+tlv4Iqv2nwzDdeCIiK+OnrGP2Rkb5nnDm5yTCv5
Xk67Zsr3Lb6IdJ0iynP0zpjTggyE6Hy2wYwnVzYhvLEylND3YF1mqRHUhc4x
dQSRkESSQJ5x5OtIPlcO+CTcw3FiTUaEa9Y5RBpT9UFpLWxiGtOvw3QV+XZZ
MaUOEQJ1SvBNIPjiAFZy0bTlqkSWp3SDFQiUKRa2RjEseOGQxi53LVH/hEKZ
ocDdk1GJhymAxBZUCbnUFafPsDAU7FS/ToJ2w+cwQbvLJY5fSgnaGIzwFlyO
weIgQfugtdwPXD74c18ELeDL0w9Yy/0zwBHWNf7v7Db44nnXg4gBDljX+/DF
8667rOV+4PLBn4/FACkob4T5odyYM/OKGFdgPgOeQ9yOJVS1oJPkaskwrdFj
bHcUkRo94zGnEkbqZhkac73eAsouzZtyNmKepKGh4YYEZzQ1iJCMgUMiQy+a
XVXAxG5nxUMl7zS18aOlMjUwMzKHUmyNd1qpdiFW7i76hVzOrLZQoKIJvsFm
zjw6tldU5WvZwKJpXlOMH6ut8fp+nczlFxILkAXiJf2/JxZEK07DF6e3Wsu/
GbH412UugC/xkv5F8OVp+OLprdbyb4YvfeaCBkWhqiMsRsxnYxwAmQRH13R2
qMwgq/nB3fSucJ7BmyTlk7EMtYzMorMRLTekLOTzkmK9MMhVjenetdIEsT+E
2QnV1tFnmYatmshJWKLFLTYGqZNQwp9lkMBMksWOeaaHK5llT9lPF7yIqJFt
cFJmyUt4tGmdSR0pK3bqxrx6CXC1LfreOlaCQ5wPRwyqLct8e3oWTyY/c+hP
Rxqha5bdNdpTw5fEI+cWAwAb5NKR28+hiRo4b7c4YXeOEp9LbxQ1JnaJsOuF
ua5EiKPYkoRUDbRolzEPxxOfk32VbH2w1Ws+F8NRmVH0gHeVAOCAM+fzqnTr
OF6T2HbDjsrFwJI7CNAr78et4xFl4NYxH+jWyQ65dXRGw54c0o6TkA74Mvhy
Rozagn7ivytwzID4gN6wl2Us+3kfw0Q3rSZeWNIanp7ngMkGQ6NsfbJoCjJO
AgrNKLdFc4+atqRghMgz4iOC2OoQhwZIXB+Gr9VXTXVlDfkD4L5ixFbPEDoX
D32EYEm+RJrj4e+269C7LIE5aMwh90YY5Ikxj2fZGQreDRDM7bpcaIgleU2j
UACSowFfUgNTn4RN2LpBKTnJzQg463zsXzgTJYDHHBcWghCFWFJ8+QaOCcdd
HFiuUxeoDtHsOrjjuMFgPouwRKVhOHcK09vmCw7gJvvMwdVTEJgPMYP1xNQl
MnY5n4Sg2MQRvy45xXzEBcRX4D8lGoAmHLvvsfpi9FjIgs9Sv/0JsxlWeHJq
HVTIR4b/vr1NLI7sdBC6YfKhz0PjtShiT8YLfIFVJfg1jg/2EenhMkuCQEe0
oP6kSyjVgaWxFjbX8MMheSD3oRC5emU4qNvnmcgMfS+uD16KApsD6dOLMN8L
NAHtftpzZDV6pxYYPpGPpTAwnK5JPSRyeF0CBihz5ETJsHpmSadbGB6oF9/y
NALpR7J5Ri6QBFFvRXmYC5uh3MJbO3S/ELAPm8QYHdDR67KWw2HMjq3JuWyF
wcBxmy4lyM52Lr5hs+ySAuxZrlgaDokPO+NkpWv1Du2tZmBQVhLyZlqKn/ka
aaCXcGC+RY4QDLqwerQn4sCl+JZrSQHj1yl3zYrp2Cx3GGvK1xmDK9CXq/l0
IgLxfitMyKDorKLEWEIJ8s/j8zUH4n05JYeNI6MuWWS/GFASn3tmF41G9mwr
IGiYMBelF/HdwDzGnJPKGGAeA3LiQJLniMLH2cvvvnt+9mrqun2FvgDBesqE
ksgeWAeRBqLaGjTJEgGMtqtzEs4iH5+/VrI2HFBi8BLPKMf7UwYdLKgJkjii
no8tdzOTRkZPNEWUpQ+ggQWGRLrdhm53tL5FgwIjXgFau4bexFjNHGXnRJ5n
hGkoELzK6t1mjtGKwBUrAbA4F1xT7XzG0I9pVGMaESQ02ifHrAE5AI3nZQGH
tmCvfMVYUxuf4niFiObWOISPnnTpUYoQpLe8kFwwZOMYFQrQJwORZuEA8lQ2
MJyLi28nNESzWOxahk8S4SUxHeTKQYpsNEWFArcIyAw9Cg5RXoakV+JQ5HG6
zU2G8cvB0YVOjzhklfxWPsiANQYKbeVj5J3akqAcw4ghPjEcjSHB+Rpk2jWv
QXz1ccF4HwuJc0BS0cP9QPHRq9SLxefIEM9CksOjIeNFJbIaIQgKkYVdtZbk
Dw4n9+cYqQWxtsBb4sh2+No0sYj9CeIpUnklYriGCoDPXKPdOUTDoMOMp2Ym
AgY83r9m/ghJYEJOuqfj52S9JG8pxKBxXmFQVOLQxKCHrABjQVAHpWbpxyga
uj68eplNJEUiRx45JxwTuKALA7QwLyQ9ioj0dN1sx442YhgSk1I3qs9w4Cft
i7QSwp9ePtdwkyFLL2wxVedAt8wp44T2RGdF0RFKwumGvkIVllUhz2VgDzyf
xioWLaJW0VzXEtXazCNLg1BeE9JgsmInmXRVteOYnNYHfnE0kaM46NPscge3
ec9R5MqDWVJIJRPE4mWjwV4ayR+i64COEL+Hc141+EhIBrGUVGPUZuEjy8f4
nmjtfIC4JH8rM85byd78ZpM7ED7eGUO3U4Nq8JhJRyECxFuI1JnGh5GoeONz
atNYGfaKw7w+y3ycQadJ83k8Mvkz/Gk6u+LodJDuKEQvMTNxZQMMX8z1bH8i
bU5DpBEPfPAAu6T5GUnDcpyAhWnBGFNgWQZAH/2MyRdKbGusF9FKLpTbbdGB
zuFoHnYIZ0JPtGUSanJVjrA0PRVM022Agn6LXJ2znqs9W0OinKQ4hcncMicp
TbyilRdI14CRFyYpJuDKTcmZPAyMH55dZG/e/FlvPvz51fdfn33x6Rd/fPdO
Q8O2GETXORM9d37x1fn02ay03XLKaDWV85mWW3iTTAOEOzvMHGcEPafYdqId
U54dhNzddhLy4HJ5/hboJtQJuA6ywOQMfXSWXBwes6LM8XHUJVwSIsRrMgBC
t0bCIVdxWa7QpjMHoF4nRp/UyIAoTDJqLqZuXNcrGj+LQllCfLNyNUrCH8dH
I6HRov35sBWJEeHVB21MnFv06pcHlsKXfrCQcrCEOJGYJ1KwGsreidIp/Q0L
S8nj9Q7WcsHX8QZYhKAVH8oyPEKjId4KCP1bvHnJ2ihiDkXJhPAkG+R1omGT
6WgEtt5a5dbTw3iRPDnwm0Blja+PxNuMpqyAUoy3Ja0cEcBp7Gw1YzpxzpPB
pA9xQonh+Tjuyj7OPPfoq8bF97o2fkWxMIdCYWAJsv9bxMJokNct1vLvFwvT
x5cLoTG3xJZ/+VgY2Y+fn8nXSBjnjfiCBFGDYf4/joV5O+ADt0aTaC2/FC6D
UX4RvoyMEuHLK+VdfXx5/yjJdCHq905ruR+4fPDn/vClz4t/Ib4c/tzPPbrL
nb55lIi+xLg0oC93WEvApTus5VdJX/rhEI/RvjGMg2hqS5aPbSyKUpCDRDlg
3NuxZEOfqK4cihNQvbt2XCPvuZ7FKnPdeI3bcN6vaEJiRRUKEhIY0RVEFh6U
/llAjf6d/s4vG335SzL1sQVQ9K+iKGOJ19vTgmMkn2OJO81GUVOPaM7OsiYN
24jhhkbHg9pSxsbcJHTRoeXMSekQ9D2TzhS2cFhVYduqT4bi9JtFoxqhOY7r
zrAjwmVHfJeeHp2IEoKejD4DehriKkUk76lFkS5j+tlC6JGSUbxUP6IfLcvW
dbdY6amsNDkj9S1GahGpRASRY1RE4NBQLSBbwfnFiUEbiDd1ZxizzyGjazSq
DjxdkxHt7NR4nUfUoex0BGSTWGHKng5Vpv9SUcbnj/7xXyrK+OdXpKKMwOFB
7++74cvbA/+/EV9iRUWm5HsZ1nQLfIkVFf/b05vWcj9w+eDPx1NRnt5Z6DwE
lz4Uxr7pjTJyRoOTGPlmMMoAX/rYEb65YZTRmU8H3zzNbljL/cDlgz8fD19O
PyK+vHeUW+HLLUY5iC93GmV0LSm+vHeU+4HLB3/uWaVN5ak7IsyhHd3PPfoF
9GV0lDvTlwNruSN9Gfn8uunLULr+RfTlVp/74dPvlV9uOcp75Jdbr+VG+eVW
n1+P/NI3gXw6bgLpqfKRCeTrnpc7jXyOgyrF1YzaP3ukJxkVeKMo1CiY4Bhd
4iBYUtXZKKJMAh29f5+e4wVRTIfXfEnV5eBhwHr47SQuSXU4MKIXmYTK6rPv
Lk0/YunNmz+/xH8E53azzkv4T9dtsfhsslNcxuHqo2a0+mjqqJ+gmYFq00w3
WOl3ZU0aSJ5ELFP0ElWXzTnQRwJiZsKi0XVNcVqSY+mfjmOUvscXJ0Z8rRwJ
QQWyZQGqH7qJlFMKr/6Vo4+8ozbHKDtarRQboAEcGqSMjBx84zbj4C84Ph/H
LqaTpvU1TBap8YsjfULUcD+mEcFQch3BF/t5WxbZxQ4eWGR/s/s4TAKO9cXF
355TZMPjzx+9e0dBlLZFT2yEnrMBPowiMddaOIS670fHKSzN+9c91JJwlcTL
fRYCFf6qAWCvBuV/HAaK1hijHo/YMz+dSTkJf5R4DV/F0Q+lG7fCBTMOB+aF
pfr5FE/ft3ozsjBGS5/QQX8qeo4h2cyMr1amGCw3WMx8OSB13BM5ik9wuPqJ
kfVFu8gIeQ4U/IjtaPSqWtHETEbfja03O0+LdmM2EcBAQjo9aHqvahiDZvio
1Tb8NDEUY1ouI/BilBBFk/sNCB0RVOgbufNaKoyZ+T4L9beiumBbLH9cdyF+
gSeSOHQsueeLhNHEOt//Fdvgnf1Fd7dp6FMfZuvRf93JNhitQBHjgfx9e9vg
HdZyP3D54M/H0N0Vfh/f1jMGvbvbesZO8rDuzlcy/kb3e3CU+1jL/cDlgz8f
A18YovcXvvCvZevh3X24reeOa/m3s/UM+PYv40cjn/u5R7/gTo+t5e705eOt
5V7gcrfPx9LdSQMdUd57+kqsvYefQNNllzA5EEnJffbyBcd5f4baELcOEWc6
lXr15b9BRuwnuKCQLhliVMgHh/dKACrolFaK+jt2D3NN6+t/Y9y7JHhjn6fB
yGUXaXS6GIOq2yD9EivVl1c2yqZCwZcrEXjtnPaC+lJSoZpSp978Ji7wb8by
qvK4UScA7eL787+fnv2Pi9PLy2AfiEaZxi9I9LwvS+2tJVLiYGBJSBaQhvNz
1iBlkPusGi5fQG3GYGiMZFlmcMShLyTWY69FZkcIU+8YX/dW8+QmnKRAOV+k
VWL2GGeAaSVA1NgxOIHbTPTKYVAPAc5Q8fnO67zATD8sMQB60OnFq7MXp4w1
ekzSqQZDsTnnbL+NmgZgJjnXs8COiFiZgnSbtV28dkYK21JwTdqHRSGTNoFC
GNAopMBILao2Gyu2ij9xSgpBYEJx5R7eXMC4NzTDSFOwKR+/sHYDiFcWPAqH
3aQrPdQVwFdm4LzLQwnHxxpjgwoo9iCosBUrHk5OqJq22eF8j5P3WC007/e6
CVqsybMj3M9mG5dPOOqlyzNmMSAcaNdxJqkG4HP64MJiMhZj14kEjNTmCMFO
hcUPTTBJ8CDJoqTBMj+C/Mb1JxL4mQh+XJ1DlpjWEZcmmoW2C7BZf3VUXdtH
1FAUUDSEGRtiCMOPovB+H6a5uywaWOANgtftJK/3CYG3kwJllJd8wWLGfag+
70dey/3A5YM/9yeQnitm/0Jseb/gpXCJVtz/5gZDQP+M3g5+uo0Dp6/TPMCG
ycwO/DfnzBNuHOU+1nI/cLnb52MJpJHcMyKW+pDFMuV9KJde+j6RQ8LoWXRC
cuMoxphrSWYs1wkKT2jh4ZDwrI2mfLVi6UNIhkrT7mquHEElcpAp+85MUXmN
QcnJ4HbBlOql7bCcB4tO6nkZZSAWsy9VbF2sGRT8Ilp7MdeYG1dyZ40ehNQ4
S7sqC010D2JEKPlitMkXtfaIpFfs7uEby4VdFRYLIlEtFMmPD11afTFnEfyN
MPyJl66EI7N85b7MtJULDyVnQbngVeXPyoSzooo3NQuE8dHBqcmc3qpMYj0X
02JPCM2BRnMqrU8ZjLApqitQSy3+tJwICUNhdcY7BbiTIvUewhBZKtFxePYT
9keKodz4SdMjoTHpkLHi3aoveomqA6KX7xUj5R+6qNy1VmFJk1fJPxXKLsX1
fvyWwgHHBepw6UkDt56ONNrIkLPZb9PssKfBIMKuASZWop1F+4nvV2i+xNca
W1dihRjqxRV1waVSO74oh0jeFKEvKdQTgFw9pQz+ItRHcidUQwx74+po1mAn
Pet8PXOqZKBSG/1GNTWw3k4d1ZAIDVuwM7zue5Y9K53vmnsaVuz7oWfHz04v
TtRnhSostnZVQJXUOIvJDgENDuQUtap1CZSEqlRMMhiAzzzvd8i5tbbg7KK1
3ACJlJ1NU69cZw7ADKvpaNW9VDtA9edIehbfqBokI5t+Q2NC1bIOzaD9t2ns
OsWtH70ApLDtEY179A0lvx5R9T9YqtaniGYwOhboeOhulGIVvuKeNheUFIp1
0k6T2nSNnTRQZfTOMcFDJUnwMYDBL0VRFdCTy2QE5OuNyBWgGF5xM+9oCdo8
min6XRWI0adQDvyBz/BGKRCL0fIeo8feK+aoIDMul7wde+tP+C2fcsay1KGX
E2Hq7R1n9j88mPal9/8Z9jyS+sQvH1RBEjnRA61p+Yf3zHw1nPlBOvPd9hwL
qTdAm68RPvTf+rs98HIyxnuh/UHoqWLnNp92zbapmtX+PeImkEiUMqlcHJdL
Ge9ZeXpTNRWJffGFxKT7lLY3bENtIF/dqEvrvHR2K3Ukz6VfJXN5tXTFdgeq
VkNVhdAWVSQ9IKO5JiSyGKqWqgE4UV8+7YspTS+ZUWqxWm9q82IkLi2AxNd5
kN6JLJWGRo1UDzXuvBmNjvZEkzSVq4lprlD88mIvNagMmVta8TVtck42mSjj
iLK6QulDZVrS5q9fi5XpLsoDQu+lGB1IeVjZicRDbIE6eghJ4VDkPcf5yXDb
cT0loxIWgTuRvUIJei3uWOcb2+s1ikwrqtRlpBEbbvp4fkJ886b541k0FIiP
3mj5ZpqQay9ZNLkleMPVuRyoHWRJT/vgadPk3tbYmjnsIcnVjHyXMymmRA2b
k1vF9uUR8LP0+QNu9zza7nlkWjP4a+hcx+Vy5QIkQMJqgX6rqEehtEOVJqmb
nuViToMSk0nfg8h50rygI+l5WgKuROJ4VN8y2I69FVT62mBLhWHmHZXAGfQq
rRstGhz1gtXeCqHhHYWozYjdcNWq3sUw3IeB7oaTzp3DSrpeUQaCs8GYo/di
INyZ/u89OMJJaPUjyXON276jlosljbi2CRU3iqKZzp9xQcU1aS9AOsbWYxyZ
E7jopeI9bBXg32wwLfLNmz/jwOTtevTo0cS3eP797DE2dvZ1wzE4qof+dUIz
M9/ierCIGChxjOwALw7ulC/lQmoRHgQ53BOqV9jr4VnWtVD5oBi203zF5vNA
Jwrb5WXFl0/bRKsKEdWJglMDSltQhUpWlbmWOFNkLXpbNWnxtmhJPdbka2ea
GwlqyLal4F9qHYwsj8wtWZwtC+CNaqUT2j2LixkS84oKEAftMq7zSUHKLcai
7UnbRteUxCQq10lnwaTlfrlOcXayBD/pvdDf3oDCjqL0TgndRBqo6IX0P4zd
vCE5vbSkJsNPIrCeR8YhYozOqiLdLFOtiBmZFl5O0pB9Q85RyYnq3GYVxpwZ
Zrl6IDfaZGbR4qJlISJJBctdXUg/dOwWuVHPY6Spp+P9VSuJT9JG9WIvZNTy
avFg8xojzSWf51H8cu5csyiJzAiX7OmTPXJKEZk+SNIgSxb6ROUHqNJ2wmKl
8oDamgZL8zGUWikvqW6KUIBVkumuQe9tAByW6HuPZSzuTMvAbeM2d9qHTWSV
eb547ZtghrX2mcAywIisF1pGIe8VZH7zRkoUvksaXS/i5kAIWhzEBFsctnMP
haWBOuzQW9tx2LnvyseWgKTGcsx+0farJcqTzrjm0CazH6XRHlWRlqL9AdiH
ilF7L69YiUP54OPkmuVY/FVyHULZfSle7+PrvYC/tgOzBponrjlzIphUOPxA
hMLihBmSlu5l5OhjBVLkAm2X3HrBcD1GlbEnWvsbyJHeMSlzPUJRBpUzenW6
pVVFD4PyWOjhqqUyRXr4LNUNC6rzRSUyEKylYjssu1BmGPRLktDYg0yH7euf
0n1GpTEJYaa2ImgKclxoGycyCAo9tKhTh9x67UwPkklUQxFYV+7g/4upPD1N
nsbsE+41YPy1B3a2bVpUnWKlIhL+gnu/jlpGZ9zn+/MvPn+Mo1JgCI8sMMXl
u90cLyb7HuIDRMJPEvCPdp5d7Nxah3uEoUTMeM5rQswF5XbgH3iKgKSpBn5x
Q7N5DREpdSSmaKUfC6OMzvSqbCSCHrg6t4u4WWpdU+aKA3peUCthN5Co6tBy
ngafS/DSgFXTWFrzmyt7NiRMUtc04r03roUOZUjHkYkyoQWeYQ3Hg7AA5kJT
YumMEdF+gA/86JgcRHW4k1acUelkqrDLfzE5QTMtaM3foUQMY1QkssbFLmES
sswLA47oDjbZ1hMFfRsjUdibIkeJ6wftu8JoLPMcmba2Vi6yf+zySqDDjkEU
pmLjDHfDGZpfOPJIwtdG5RGpCO0rQSfFVMjA4+tFJmFIB4+s7PlNsksU+K1s
iORxgyBCSwNelngcrHQTtFPVhaINyTEG4JZtH6q9CtSqc2OU3xTRaeqj/CTI
7/Pfff47vOg8KYzMJdvjLBFC9F79TW0zHpQYM6LcAr1o4Sq+rFOB+0Dv6rjV
wUvQrAeLil0ME4Nul362WE/H7nxF+/6DvLKeIBwZFLIfuapqrnTEmO9BAVvV
5c+EeQ1aVEqsVB72dbApd7ADxsedIFxJnIv5bRwylFj9EtMXP6k5XmmB/OE7
s+wHfKLboSqIUq+WwGcfZN6ZnuquljgaJDXWkQqGukkHe0UYdLl7zQWtNDJ0
sBHFHIsdGCP6GWwvS2C1pDdw0F3UfSQYV3u3IYRJyjB5ucHuEEmHJRBc3gcc
FoFIQFjCXD7sL3fBVpg9owhHApcWUDchEtZXfHIdHDxRQWxT35XkzSG/t2/w
gM1MyqWolyIEjlAvYPkFEloybxhcx3Kv2lLSc+oKhBxSTcs4EOAbu0I8TEwq
6xwL/ONIJRdgHh3HROMog0PBCEuVkalW+i+QvotS8YJPK3QbkAZn3kKeA9JP
8zm1FRU3LlNeXAMx2KEao5aSESuJhmcw5wuOr0nU/oLdt7NEqkiuG5sbFTw0
m6bR7aPuCr5VxKgQ7S824KjRBhZO9YFo21hcvrIbKg//DYYnOy4OP3Q+ZG9+
U9ED7w4IQYDkTm4os3NS/IXukLJCeb2O27YV2vNlA3Jtxc5qJFPq88SDMlFs
Ml7nhsqBez87PIK5v0rZAH9fO6QnWFy4y8msQvpW5fdVUseq2i7xHx5Geea7
dbV2jablK4nKdmX/IsABkV2UzBXEQ/2DpDbzBQuHc532C+GoGbhEKCvNbSxo
qMQ4aP6WWgtukBYQaUF8si2qvtK7JrKj+SPAhRBMSIaiGnbfqbt7zBBLbWo1
JRWkjRvoei8240dQdeDqNlwLXn6m8nrM4v4eehjM98ESPIJgLmlP5xPqtdN8
ObNSa1ougDfKwQFvUdig8PGm3/KdxU+GH5trUX0m4nywmd4MoCXcWyYL7m4g
iK9rjHjH9i2omulouLQb2vM5utZigN1rewyRbCM9kKY1gy6Sr9Y7F0WQODGw
5tispcjJXuqdfuS6P2QIw1iuBlVNdPTjFygP6oPUZ68uyPTnBoUiCbV9Pw86
s3W5DTbz1hGZZ7Vg2C4uZyU+FaRTUxwOEuR1jDRJabsXKl9yYoYGNKQlDzjV
h09pjHRKWIWJfmMarsLNoLbAcDCu+R6VuOxNMjPny9FlxanacvpRVBlh04i9
RK2r3JyT2joQtqSR7HQPbNzWjrpacGft0IPNV2IopQVeiTeZM7wJKbn1R7X3
Mgj1XtUWTiKFUFe8RV4FsUEiRwQhMHDMK3ghcEwCbmbZc038vm6CIti7Fmrb
JFud1DuQJzmivS878qX17Q3LjhuCiRV9fDs+hT0e67qpP+nM3Hq7eOSQ6Xwf
MY7VY1mL2W/U4UjovuH0i50GlwIP49gAvcbcQ4rVOS/WEM2+aEDA32sbsA5/
woCbHHsPcQMrDWzyYBEr8jAAE6PbSkc2VFM1q5U4y3uu64mY99iAvMOirPwu
sKeyyOOE/y0uTs+WrXccZ4CmOFQFqW+VtMLRGUvPlIsQCUg9dBA3FxrVCGs+
kaou+KYV/GdZG09FwwEKSdegCgA/s8VAfSQo1aNszGsD0qKarwf9DGHci5hg
uGLEQf7apg13ZA15aIHmZdNZ6P5GP0RcTU9PDLoyMEpGLEWhsrvvSbkRV4A7
RCw96joMd4LsM0IgyCw55LXnwE1xTK1lEoxfqbmr/5w3bd1KcSaihfa9moNR
SOnwApi4g2B9PVbCgmF8H9mEmZp3a03okpgM3zPswIqJLg7ZWmqZ6Im0Hcml
3IVZ0/OwnxJ3QkMjLlVOYcstjG98qlrC3uMwbLa9JqPNvMAdNXXCGUjkJDRN
mDROTKSUYECGuA4xAoNsqCMuUR4fcpNzHpx4LIL4leAEzRJVAkqjGC56UIkN
/AwdIWsJ9H3gb4wr/PiSPLqsFsGlBrnJ73Cgs6V8PXjy+qlw65JEfmaQBy1h
S3JlzVtg2Whapm5/XRvKEjGnw3dJL/FYuKSmWhRDSWWgiTwN3hfHMZoUmCXJ
arzYF15giqpkLjauxNGc/kVdMbZBw9B8sqpiVmFQRg/7qIfu/U+cSbwQE+8Z
n6QBP8KLRXfgI1An14F4AW91UG8FpmtK+adJFC4rOI48WPvMkdNGTOe9atXY
CM8Dj0/iABp/J5iZoPB5KG8dUxa0ZgBtJ+tTHEs1guOHEZNOGkvPRqWcGSgv
4ICa7Pj52YuTxHXSVW5qXV2+e0cJD3+/+A4BffaCXY2H46JDRScKc16XRUpq
aP+7Gp2JTUs8T8Ud6s4boaREr2s0cyxonQRpM9VZEi9+0GSCceQ4IMEJ6Mfa
tosspgBv3KasOXbO4JptWAyjCDw7RBNtfxa/3iy91ddE7bH43Vl2c8gkN/PN
i6uG/K5EHCim3pGM6kvPg2AV/BHw9VVTFpI3WaaNi7FX+vW6OVEXVesdtMdo
zzyR7aJ87sUx6kl4AJkvEVxn6xy7gTljnoaQqrGmTGx5LaXTqE/snO9vbsSn
PDe5HkaJbE+MxhiZ+sBEmkSE94LscbjqHostfe4IlvAz0hOtbdF4R9rpAff6
REuPSqvq2rcBpLt3oNEWGS+kBqV6v6VJNUn+ntwwCRoAVWuc4pwT/+bYw+wY
Dz0QYqIrWTSEmBioGrqvq/jKgqj0DQCVvs2X1G9SzUsLNUjbn7ZVg8Yb4/tz
SsfdHhmg+cNyIkOQpjlx89iEPfMVDxs/BZHCmZoCVFF46jjIAS2rlfCEcZuU
wreZX2HYiUCDu1EGOCa+v0WDOR0+tBZZKaAF90eUPgCRZffSolPYYbkGuHTT
NIzz3Tu6yyKHU6BnqX0hMZel2ZYLuXBx6KaXc5x256awq9W60+aJkYSmqf+6
f6736EW2RBRKYIO2a0cZ9+nghkKZ2TYvdSU20pCN27+JtZbE/HLVoKEPtYPI
2thLDvcxAr2Os6kobLyRltPTQ5gdayKxoC2BINrzlPzRcQgEmoVI4l9YJSqJ
9uIX63uv5tkC3s2pIsHAZ8SExWVHXYNNNhfrI8l1iVqy4iFIHh9nuvtukUCA
qsrWK1VxB3OLWZa9l2lkYZ9PtK8dy2nqNn/l+z9SI2OL1n2M6tQ4b4lZoWbV
RXZEMO7sEYZSHfkKF0doJqILuS7rwiEyYM8VtObutllgMLr9BDjBOVD6Uhuo
r6jhUWOAgn1SOzt/SZwUva2w0kvboQ9Roh1h4K+evTyfPX40e/z40RcPLy9m
nz569Pnss8+kOsibN2doi3XpOyDI+AsnlF5s56VXduCmVwjJqiB/Q6JUnHMe
5C1SHNLWlcHrhg3amTlnGAeChQjRCRicQr0XMQe0rftBO9plmJLOODSzE1Ls
OQXPwTaJCWM7TlXtveHYv4MmjYaS65Q/5AHN4w7pk+D6yCNTQdTUEl7H29mi
UbX0rYEp3vS46MeRsjZihEcShE4k5JVjHUOchVDUnHJRvc94MqIyPkai27PE
wGt47OSKIYqhd45pwVBCAcioSEUSt0N3i7dA+shNk2Ve+iZiJcVVfTgzeU8O
yyGN1zNwueJ8azUETcN8c7yFLU1GVlNqWendg8pbGM4Fqdy+SWjEM8m9QR4V
sZs9e9ZcRpa/GY7vDYS6qwhmbC5Fu6vkM1PjZl8rR1uSk5tsVOxTF8x8j1NR
5ohiIIr9mitKCS5q2lRL7HoQmJ1jn3jYExx5lmWjzj4fEUesaUsefITUMoS5
sq3MezTHt8sLtjUma1KEH2V1aFHWPjcIjhDveaGoa1rgdBtSe6/Fli7GbDQL
4DQ/5Xx/e1tGLilMMWIrGD2Ah+kb3gNIqO4PRk/hYcRh20jlt/5IcDK2umAr
b6m4knunmxCAg8ibbDmueQxo649PoqFwKsUT3DHKFmjK3W5BMkQkwjPnaF0Q
C3cUi0M3+e8gYkkEJM2GrIsjKdUq6dC1lESoo1crxCb4sjwUSlrbAzWCYEUE
D3bwxPcmmnqgW6elrerOBwDVYpsZkEacBKkjcTwMbNCaSAClJQnI3vjOBY/Q
B60ZLFiul82t6arOazGuu06UWJwm6emepIok4h39TN6ba0llWZF5JJphwpeb
kwUQkzBxuiKANdtOrNhSIokLcnE7QVaaMLY2Ynxy8YpkC3yHo0PG5bGeh3GQ
JCPkKxQzu0imi4yuo13iEp5JsVs4TZQd0loML8Aa1vDjp1zE+vFnIZHli9lj
TGUZqRBGkbJRGiNHhmn76AWnQinFprABLrdDgk5c6irYXH2hJyFbEoEltcJ0
AKR8bDdBIZDbyRFSEf3KKxQX+AcZDzjq95bjiOO4VZerfIx3KK2cEBLTN+S4
RuqMgrjzdKNnHqvhypEwlxjCiE6Sn1vixxzp05lKYLph9QkOzSBEN4aWkJC4
WDq12nT7rfSSF3ah26p6yMy4BldGyuXpADGJYYlEFCYQBWyzXLKXiLncAi0v
JKH8bNtmCmQ1W+Ubthqo7sdBTjAVhWfgW97PmmOE1iuSNYMT2lsFdGJaRLSo
KxLBskSKUhGJruIyk4oWIa5iTBDAchHwO1B9QN2Fm6RB8EFL0loeGSW9YLqt
qMGFaMgwegszWXWESi6KHE1PyaPGf0Mbpi9bTaJUUinBu0BTd7uSf019EV+/
TzXKKwoFZV8p5V/2wjphIr4ObCamY5znaL0guQC9ZV0rRmZvPM2z9X6LrlkW
Qt0CpIG2bMQ3mHjJcQJ1j68lGTLV25ZVfq1+Vq45wQkNJXWL5JLsodeAMlCg
AhgwD+jBMBS3Isn5Wy7Oj7QGb9I1RslRqFCzKfHAQkJZiKNmpY9vcx43wQR6
4Zpdu7BRlRq+vX5R4q3pKN3KW1EoQo5RrqYVD7c9i903TgZHYsqH4aMD6eGk
jqWCtGsYGDERHVs7eanZPUH4oXEGMVKy9rsBxBQIEnbkFXzfNymULiptxAbs
KIF3LOHO4mVJQlw9rCVGIOx7wBbGdiRvycZQS5E4J7QdVY3zUhOovh0VApUz
HyTw+XiHkL2XeGpSs4mw1ogwiOrDuQ1Ds1GUWAoQwQJNyYJUNcXI4SBoasA8
+1jLbU7l62GWnsxFcrGE3CwFfFR6UOiArnelSWrefEcpMqgFqCzL+hdRHq9o
chBQFMI+t2j08HG8vWAYpOOEHRMF7DyflxVyPSpwM04W4vjh2Ag8SH9TpBXb
W2S7HrYeUfHQ0lRyipEGrf4klWJkY2MRPh5ioo0rD0RzMOAilqNVKaB3tM1o
yBB591GqYk31LLGCYgktCdp8p2ZQzSGU4ejn94SJR6xXKmCKv4Tp+rqpiN8Z
b6tGKc6HYTIv+YkiwrvGx86PzEORZ24s9CxWKWdkIkpiJntuew7C1HyEPGDw
MNsjaADSGyKy72I2MRVINUXDFWc1qgk97IBNFblKtxyHQ1JcTzBOvCDBH9Az
7Rt1DLZYmhfUttX02s6BwdppmpgLh9i0wZWgcacYakTeMY+HWl2YA3ow+yz2
CIru7L0HSaiCGFdD9rgUQCP+H1MQOK0Z+lXY8BCHOYnbKC6a4O3+bGHZiokr
lp0UKvCyZMRzqMNrqz9NVH0DHotB3FsfqlvQEukkSdMjcTBIrT4tK3gP+slC
o4pro3I81lUDUnTFZXGIRZGdVW1RbBmU/EREmMOhnlRRxMot8CHIbOtbYiaE
wogLf6mNrRVO5SboJGAktQPKTLTg/PS70wEdeMX5nosdGWBwzXXDT4p3EvOb
ptMp6YNUiGaBUY3AkVd06cybJ0zvbPHV0RLUR4v1an60ojawptuQbeR19i1C
sQb61mwcMuznVQkH8o3F2B747XX2XUNZZusceON3Jd4NFOJfsn3s72UHUAYB
8CkcEOxzYk7rrkH3xteoPedEJwFMZzu0M2b/3VIhRJGpn63b3RX8tym0NAtK
KaDUlPaa7RpLawvc5Mz8HytzxXjzzgAA [rfced] Please note that this document does not conform with the guidance
the IAB provided in https://www.rfc-editor.org/materials/iab-format.txt.

- Each author's name SHOULD be listed without an organization.
Please let us know if any updates are needed.

- IAB consensus documents include a list of IAB members that were
  part of the IAB when the document was approved, in a section entitled
  "IAB Members at the Time of Approval".
We added this section.  Please verify that the list is correct.
-->

<!-- [rfced] The SVG has the width and height specified, which makes the
artwork not scale. We suggest that scaling be enabled. Scaling will allow
the figure to be resized when it is viewed on a mobile device; however,
there may be aesthetic trade-offs (e.g., a given image may appear too large on a
desktop screen, or different figures may scale differently based on their
relative sizes).

Please review Figures 1, 2, 3, 4, 5, 6, 7, and 8 in the HTML and PDF files and
let us know if they may be updated.
-->

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

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>