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

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

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-irtf-hrpc-guidelines-21" number="9620" category="info" updates="8280"> updates="8280" obsoletes="" submissionType="IRTF" xml:lang="en" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="Guidelines for HRPC">Guidelines for Human Rights Protocol
    and Architecture Considerations</title>
    <seriesInfo name="RFC" value="9620"/>
    <author initials="G." surname="Grover" fullname="Gurshabad Grover">
      <organization></organization>
      <organization/>
      <address>
        <email>gurshabad@cis-india.org</email>
      </address>
    </author>
    <author initials="N." surname="ten Oever" fullname="Niels ten Oever">
      <organization>University of Amsterdam</organization>
      <address>
        <email>mail@nielstenoever.net</email>
      </address>
    </author>
    <date year="2024" month="February" day="12"/> month="September"/>

    <area>IRTF</area>
    <workgroup>Human Rights Protocol Considerations Research Group</workgroup>
    <keyword>Internet-Draft</keyword> Considerations</workgroup>

   <keyword>International human rights</keyword>
   <keyword>Protocol design</keyword>

    <abstract>
      <t>This document sets guidelines for human rights considerations for
      developers working on network protocols and architectures, similar to
      the work done on the guidelines for privacy considerations <xref target="RFC6973"/>. (RFC
      6973). This is an updated version of the guidelines for human rights
      considerations in <xref target="RFC8280"/>.</t> RFC 8280.</t>
      <t>This document is not an Internet Standards Track specification; it is published for informational purposes.</t>

<t>This informational document has consensus for publication from a product of the Internet Research Task Force (IRTF) Human Right Protocol Considerations Research (HRPC) Group. It has been reviewed, tried, and tested by both by the research group as well as by researchers and practitioners from outside the research group. The research group acknowledges that the understanding of the impact of Internet protocols and architecture on society is a developing practice and is a body of research that is still Research Group in development.</t> the IRTF.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document outlines a set of human rights protocol considerations for protocol developers. It provides questions that engineers should ask themselves when developing or improving protocols if they want to understand how their decisions can potentially influence the exercise of human rights on the Internet. It should be noted that the impact of a protocol cannot solely be deduced from its design, but its usage and implementation should also be studied to form a full protocol human rights impact assessment.</t>
      <t>The questions are based on the research performed by the Human Rights Protocol Considerations (HRPC) research group Research Group, which has been documented before these considerations. The research establishes that human rights relate to standards and protocols, protocols and offers a common vocabulary of technical concepts that influence human rights and how these technical concepts can be combined to ensure that the Internet remains an enabling environment for human rights. With this, the contours of a model for developing human rights protocol considerations has taken shape.</t>
      <t>This document is an iteration of the guidelines that can be found in <xref target="RFC8280"/>. target="RFC8280" format="default"/>. The methods for conducting human rights reviews (Section 3.2), (<xref target="analyzing-drafts-based-on-their-perceived-or-speculated-impact" format="default"/>) and the guidelines for human rights considerations (Section 3.3) (<xref target="expert-interviews" format="default"/>) in this document are being tested for relevance, accuracy, and validity. validity <xref target="HR-RT"/> target="HR-RT" format="default"/>. The understanding of what human rights are is based on the Universal "Universal Declaration of Human Rights Rights" <xref target="UDHR"/> target="UDHR" format="default"/> and subsequent treaties that jointly form the body of international human rights law <xref target="UNHR"/>.</t> target="UNHR" format="default"/>.</t>
      <t>This document does not provide a detailed taxonomy of the nature of (potential) human rights violations, whether direct or indirect, indirect / long-term or short-term, that certain protocol choices might present. In part part, it is because this is highly context-dependent, context-dependent and in part, also because this document aims to provide a practical set of guidelines. However, further research in this field would definitely benefit developers and implementers.</t>

<t>This document is not an Internet Standards Track specification; it is published for informational purposes.</t>

<t>This
      <t>
	This informational document has consensus for publication from the Internet Research Task Force (IRTF) Human Right Protocol Considerations (HRPC) Research Group. It has been reviewed, tried, and tested by both by the research group as well as by researchers and practitioners from outside the research group. The HRPC research group acknowledges that the understanding of the impact of Internet protocols and architecture on society is a developing practice and is a body of research that is still in development.</t> ongoing. This document is not an IETF product and is not a standard.
    </t>
    </section>
    <section anchor="human-rights-threats" title="Human rights threats"> numbered="true" toc="default">
      <name>Human Rights Threats</name>
      <t>Threats to the exercise of human rights on the Internet come in many forms. Protocols and standards may harm or enable the right to freedom of expression, expression; right to freedom of information, information; right to non-discrimination, non-discrimination; right to equal protection, protection; right to participate in cultural life, arts arts, and science, science; right to freedom of assembly and association, association; right to privacy, privacy; and the right to security. An end-user end user who is denied access to certain services or content may be unable to disclose vital information about the malpractices of a government or other authority. A person whose communications are monitored may be prevented or dissuaded from exercising their right to freedom of association or participate in political processes <xref target="Penney"/>. target="Penney" format="default"/>. In a worst-case scenario, protocols that leak information can lead to physical danger. A realistic example to consider is when individuals perceived as threats to the state are subjected to torture, extra-judicial killing killing, or detention on the basis of information gathered by state agencies through the monitoring of network traffic.</t>
      <t>This document presents several examples of how threats to human rights materialize on the Internet. This threat modeling is inspired by "<xref target="RFC6973" format="title"/>" <xref target="RFC6973"/> Privacy Considerations for Internet Protocols, target="RFC6973" format="default"/>, which is based on security threat analysis. This method is a work in progress and by no means a perfect solution for assessing human rights risks in Internet protocols and systems. Certain specific human rights threats are indirectly considered in Internet protocols as part of the security considerations <xref target="BCP72"/>, but target="RFC3552" format="default"/>; however, privacy considerations <xref target="RFC6973"/> target="RFC6973" format="default"/> or reviews, let alone human rights impact assessments of protocols, are neither standardized nor implemented.</t>
      <t>Many threats, enablers, and risks are linked to different rights. This is not surprising if one takes into account that human rights are interrelated, interdependent, and indivisible. Here, however, we’re However, here we're not discussing all human rights because not all human rights are relevant to information Information and communication technologies Communication Technologies (ICTs) in general and to protocols and standards in particular <xref target="Bless"/>: “The target="Orwat" format="default"/>:</t>
      <blockquote>The main source of the values of human rights is the International
<em>International Bill of Human Rights Rights</em> that is composed of the Universal <em>Universal Declaration of Human Rights Rights</em> (UDHR) <xref target="UDHR"/> target="UDHR" format="default"/> along with the International <em>International Covenant on Civil and Political Rights Rights</em> (ICCPR) <xref target="ICCPR"/> target="ICCPR" format="default"/> and the International <em>International Covenant on Economic, Social and Cultural Rights Rights</em> (ICESCR) <xref target="ICESCR"/>. target="ICESCR" format="default"/>. In the light of several cases of Internet censorship, the UN Human Rights Council Resolution 20/8 was adopted in 2012, affirming that “the "...the same rights that people have offline must also be protected online.” online..." <xref target="UNHRC2016"/> target="UNHRC2016" format="default"/>. In 2015, the Charter <em>Charter of Human Rights and Principles for the Internet Internet</em> <xref target="IRP"/> target="IRP" format="default"/> was developed and released. released <xref target="Jorgensen" format="default"/>. According to these documents, some examples of human rights relevant for ICT systems are human dignity <em>human dignity</em> (Art. 1 UDHR), non-discrimination <em>non-discrimination</em> (Art. 2), rights <em>rights to life, liberty and security security</em> (Art. 3), freedom <em>freedom of opinion and expression expression</em> (Art. 19), freedom <em>freedom of assembly and association association</em> (Art. 20), rights <em>rights to equal protection, legal remedy, fair trial, due process, presumed innocent innocent</em> (Art. 7–11), appropriate 7-11), <em>appropriate social and international order order</em> (Art. 28), participation <em>participation in public affairs affairs</em> (Art. 21), participation <em>participation in cultural life, protection of the moral and material interests resulting from any scientific, literary or artistic production of which [they are] the author intellectual property</em> (Art. 27), and privacy <em>privacy</em> (Art. 12).” A 12).</blockquote>
      <t>A partial catalog of human rights related to Information and Communications Technologies, ICTs, including economic rights, can be found in <xref target="Hill2014"/>.</t> target="Hill" format="default"/>.</t>
      <t>This is by no means an attempt to exclude specific rights or prioritize some rights over others.</t>
    </section>
    <section anchor="conducting-human-rights-reviews" title="Conducting human rights reviews"> numbered="true" toc="default">
      <name>Conducting Human Rights Reviews</name>
      <t>Ideally, protocol developers and collaborators should incorporate human rights considerations into the design process itself (see <xref target="analyzing-drafts-based-on-guidelines-for-human-rights-considerations-model"/> ("Analyzing Internet-Drafts Based on Guidelines for human rights considerations). Human Rights Considerations Model")).
This section provides guidance on how to conduct a human rights review, i.e., gauge the impact or potential impact of a protocol or standard on human rights.</t>
      <t>Human rights reviews can be done by any participant, participant and can take place at different stages of the development process of an Internet-Draft. Generally speaking, it is easier to influence the development of a technology at earlier stages than at later stages. This does not mean that reviews at last-call Last Call are not relevant, but they are less likely to result in significant changes in the reviewed document.</t>
      <t>Human rights review reviews can be done by document authors, document shepherds, members of review teams, advocates, or impacted communities to influence the standard standards development process. IETF documents can benefit from people with different knowledges, knowledge, perspectives, and backgrounds, especially since their implementation implementations can impact many different communities as well.</t>
      <t>Methods for analyzing technology for specific human rights impacts are still quite nascent. Currently, five methods have been explored by the human rights review team, often in conjunction with each other:</t> other.</t>
      <section anchor="analyzing-drafts-based-on-guidelines-for-human-rights-considerations-model" title="Analyzing drafts based numbered="true" toc="default">
        <name>Analyzing Internet-Drafts Based on guidelines Guidelines for human rights considerations model"> Human Rights Considerations Model</name>
        <t>This analysis of Internet-Drafts uses the model as described in section 4. <xref target="guidelines-for-human-rights-considerations" format="default"/>. The outlined categories and questions can be used to review an Internet-Draft. The advantage of this is that it provides a known overview, and document authors can go back to this document as well as <xref target="RFC8280"/> target="RFC8280" format="default"/> to understand the background and the context.</t>
      </section>
      <section anchor="analyzing-drafts-based-on-their-perceived-or-speculated-impact" title="Analyzing drafts based numbered="true" toc="default">
        <name>Analyzing Internet-Drafts Based on their perceived Their Perceived or speculated impact"> Speculated Impact</name>
        <t>When reviewing an Internet-Draft, specific human rights impacts can become apparent by doing a close reading of the draft and seeking to understand how it might affect networks or society. While less structured than the straight use of the human rights considerations model, this analysis may lead to new speculative understandings of links between human rights and protocols.</t>
      </section>
      <section anchor="expert-interviews" title="Expert interviews"> numbered="true" toc="default">
        <name>Expert Interviews</name>
        <t>Interviews with document authors, active members of the Working Group, working group, or experts in the field can help explore the characteristics of the protocol and its effects.
   There are two main advantages to this approach: one the one hand, it approach:</t>
   <ol spacing="normal">
     <li>It allows the reviewer to gain a deeper understanding of the (intended) workings of the protocol; on the other hand, it also protocol.</li>
     <li>It allows for the reviewer to start a discussion with experts or even document authors, which can help the review gain traction when it is published.</t> published.</li>
   </ol>
      </section>
      <section anchor="interviews-with-impacted-persons-and-communities" title="Interviews numbered="true" toc="default">
        <name>Interviews with impacted persons Impacted Persons and communities"> Communities</name>
        <t>Protocols impact users of the Internet. Interviews can help the reviewer understand how protocols affect the people that use the protocols. Since human rights are best understood from the perspective of the rights-holder, this approach will improve the understanding of the real world real-world effects of the technology. At the same time, it can be hard to attribute specific changes to a particular protocol, protocol; this is of course even harder when a protocol has not been (widely) widely deployed.</t>
      </section>
      <section anchor="tracing-impacts-of-implementations" title="Tracing impacts numbered="true" toc="default">
        <name>Tracing Impacts of implementations"> Implementations</name>
        <t>The reality of deployed protocols can be at odds with the expectations during the protocol design and development phase <xref target="RFC8980"/>. target="RFC8980" format="default"/>. When a specification already has associated running code, the code can be analyzed either in an experimental setting or on the Internet where its impact can be observed. In contrast to reviewing the draft text, this approach can allow the reviewer to understand how the specifications works work in practice, practice and potentially what unknown or unexpected effects the technology has.</t>
      </section>
    </section>
    <section anchor="guidelines-for-human-rights-considerations" title="Guidelines numbered="true" toc="default">
      <name>Guidelines for human rights considerations"> Human Rights Considerations</name>
      <t>This section provides guidance for document authors in the form of a questionnaire about protocols and how technical decisions can shape the exercise of human rights. The questionnaire may be useful at any point in the design process, particularly after the document authors have developed a high-level protocol model as described in <xref target="RFC4101"/>. target="RFC4101" format="default"/>. These guidelines do not seek to replace any existing referenced specifications, but rather specifications but, rather, contribute to them and look at the design process from a human rights perspective.</t>
      <t>Protocols and Internet Standards might benefit from a documented discussion of potential human rights risks arising from potential misapplications of the protocol or technology described in the Request For for Comments (RFC). This might be coupled with an Applicability Statement for that RFC.</t>
      <t>Note that the guidance provided in this section does not recommend specific practices. The range of protocols developed in the IETF is too broad to make recommendations about particular uses of data or how human rights might be balanced against other design goals.  However, by carefully considering the answers to the following questions, document authors should be able to produce a comprehensive analysis that can serve as the basis for discussion on whether the protocol adequately takes specific human rights threats into account. This guidance is meant to help the thought process of a human rights analysis; it does not provide specific directions for how to write a human rights considerations section (following the example set in <xref target="RFC6973"/>).</t> target="RFC6973" format="default"/>).</t>
      <t>In considering these questions, authors will need to be aware of the potential of technical advances or the passage of time to undermine protections. In general, considerations of rights are likely to be more effective if they are considered given have a purpose and specific use cases, cases rather than as abstract abstract, absolute goals.</t>
      <t>Also note that while the section uses the word, ‘protocol’, word "protocol", the principles identified in these questions may be applicable to other types of solutions (extensions to existing protocols, architecture for solutions to specific problems, etc.).</t>
      <section anchor="intermediaries" title="Intermediaries"> numbered="true" toc="default">
        <name>Intermediaries</name>
        <t>Question(s):
Does your protocol depend on or allow for protocol-specific functions at intermediary nodes?</t>
        <t>Explanation:
	The end-to-end principle <xref target="Saltzer"/> target="Saltzer" format="default"/> holds that certain functions can and should be performed at ‘ends’ "ends" of the network. <xref target="RFC1958"/> target="RFC1958" format="default"/> states “that in that "in very general terms, the community believes that the goal is connectivity […] ... and the intelligence is end to end rather than hidden in the network.” When network". There are new opportunities for failure when a protocol exchange includes both endpoints and an intermediary, there are new opportunities for failure, especially when the intermediary is not under control of either endpoint, or is even largely invisible to it, as, for instance, in as with intercepting HTTPS proxies <xref target="https-interception"/>. target="HTTPS-interception" format="default"/>. This pattern also contributes to ossification, ossification because the intermediaries may impose protocol restrictions – -- sometimes in violation of the specification – -- that prevent the endpoints from using more modern protocols, as described in Section 9.3 of <xref target="RFC8446"/>.</t> target="RFC8446" sectionFormat="of" section="9.3"/>.</t>
        <t>Note that intermediaries are distinct from services: in services. In the former case case, the third party third-party element is part of the protocol exchange, exchange; whereas in the latter latter, the endpoints communicate explicitly with the service. The client/server pattern provides clearer separation of responsibilities between elements than having an intermediary. However, even in client/server systems, it is often good practice to provide for end-to-end encryption between endpoints for protocol elements which that are outside of the scope of the service, as in the design of MLS Messaging Layer Security (MLS) <xref target="I-D.ietf-mls-protocol"/>.</t> target="RFC9420" format="default"/>.</t>
        <t>Example:
Encryption between the endpoints can be used to protect the protocol from interference by intermediaries. The encryption of transport layer information in QUIC <xref target="RFC9000"/> target="RFC9000" format="default"/> and of the TLS Server Name Indication (SNI) field <xref target="I-D.ietf-tls-esni"/> target="I-D.ietf-tls-esni" format="default"/> are examples of this practice. One consequence of this is to limit the extent to which network operators can inspect traffic, requiring them to have control of the endpoints in order to monitor their behavior.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to freedom of assembly and association</t>
</list></t> association</li>
        </ul>
      </section>
      <section anchor="connectivity" title="Connectivity"> numbered="true" toc="default">
        <name>Connectivity</name>
        <t>Questions(s):
Is your protocol optimized for low bandwidth low-bandwidth and high latency high-latency connections? Could your protocol also be developed in a stateless manner?</t>

<t>Also considering
        <t>Considering the fact that network quality and conditions vary across geography and time, it is also important to design protocols such that they are reliable even on low bandwidth low-bandwidth and high latency high-latency connections.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to freedom of assembly and association</t>
</list></t> association</li>
        </ul>
      </section>
      <section anchor="reliability" title="Reliability"> numbered="true" toc="default">
        <name>Reliability</name>
        <t>Question(s):
Is your protocol fault tolerant? Does it downgrade gracefully, i.e., with mechanisms for fallback and/or notice? Can your protocol resist malicious degradation attempts? Do you have a documented way to announce degradation? Do you have measures in place for recovery or partial healing from failure? Can your protocol maintain dependability and performance in the face of unanticipated changes or circumstances?</t>
        <t>Explanation:
Reliability and resiliency ensures that a protocol will execute its function consistently and error resistant to error, as described, and will function without unexpected result. results. Measures for reliability in protocols assure users that their intended communication was successfully executed.</t>
        <t>A system that is reliable degrades gracefully and will have a documented way to announce degradation. It will also have mechanisms to recover from failure gracefully, and gracefully and, if applicable, will allow for partial healing.</t>
        <t>It is important here to draw a distinction between random degradation and malicious degradation. Some attacks against previous versions of TLS, for example, exploited TLS’ TLS' ability to gracefully downgrade to non-secure cipher suites <xref target="FREAK"/><xref target="Logjam"/>– target="FREAK" format="default"/> <xref target="Logjam" format="default"/>; from a functional perspective, this is useful; useful, but from a security perspective, this can be disastrous.</t>
        <t>For reliability, it is necessary that services notify the users if a delivery fails. In the case of real-time systems, in addition to the reliable delivery, the protocol needs to safeguard timeliness.</t>
        <t>Example:
In the modern IP stack structure, a reliable transport layer requires an indication that transport processing has successfully completed, such as given by TCP’s TCP's ACK message <xref target="RFC0793"/>. target="RFC9293" format="default"/>. Similarly, an application layer application-layer protocol may require an application-specific acknowledgment acknowledgement that contains, among other things, a status code indicating the disposition of the request (See (see <xref target="RFC3724"/>).</t> target="RFC3724" format="default"/>).</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to security</t>
</list></t> security</li>
        </ul>
      </section>
      <section anchor="content-signals" title="Content signals"> numbered="true" toc="default">
        <name>Content Signals</name>
        <t>Question(s):
 Does your protocol include explicit or implicit plaintext elements, either in either the payload or the headers, that can be used for differential treatment? Is there a way minimise to minimize leaking of such data to network intermediaries? If not, is there a way for deployments of the protocol to make the differential treatment (including prioritisation prioritization of certain traffic), if any, auditable for negative impacts on net neutrality?</t>
        <t>Example:
When network intermediaries are able to determine the type of content that a packet is carrying carrying, then they can use that information to discriminate in favor of one type of content and against another. This impacts users users' ability to send and receive the content of their choice.</t>
        <t>As recommended in <xref target="RFC8558"/> target="RFC8558" format="default"/>, protocol designers should avoid the construction of implicit signals of their content. In general, protocol designers should avoid adding explicit signals for intermediaries. In certain cases, it may be necessary to add such explicit signals, but designers should only do so when they provide clear benefit to end users (see <xref target="RFC8890"/> target="RFC8890" format="default"/> for more on the priority of constituencies). In these cases, the implications of those signal signals for human rights should be documented.</t>
        <t>Note that many protocols provide signals that are intended for endpoints that can be used as implicit signals by intermediaries for traffic discrimination, either based on either the content (e.g., TCP port numbers) or the sender/receiver (IP addresses). Where possible, these should be protected from intermediaries by encryption. In many cases – e.g., (e.g., IP address – addresses), these signals are difficult to remove, remove; but in other cases, such as TLS Application Layer Protocol Negotiation <xref target="RFC7301"/>, target="RFC7301" format="default"/>, there are active efforts to protect this data <xref target="I-D.ietf-tls-esni"/>.</t>

<t><list style="symbols">
  <t>Right target="I-D.ietf-tls-esni" format="default"/>.</t>
	<t>Impacts:</t>
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to non-discrimination</t>
  <t>Right non-discrimination</li>
          <li>Right to equal protection</t>
</list></t> protection</li>
        </ul>
      </section>
      <section anchor="internationalization" title="Internationalization"> numbered="true" toc="default">
        <name>Internationalization</name>
        <t>Question(s):
Does your protocol or specification define text string elements, in the payload or headers, that have to be understood or entered by humans? Does your specification allow Unicode? If so, do you accept texts in one charset character set (which must be UTF-8), UTF-8) or several (which is dangerous for interoperability)? If character sets charsets or encodings other than UTF-8 are allowed, does your specification mandate a proper tagging of the charset? Did you have a look at <xref target="RFC6365"/>?</t> target="RFC6365" format="default"/>?</t>
        <t>Explanation:
Internationalization refers to the practice of making protocols, standards, and implementations usable in different languages and scripts (see Localization). <xref target="localization"/> ("Localization")). In the IETF, internationalization means to add or improve the handling of non-ASCII text in a protocol. protocol <xref target="RFC6365"/> target="RFC6365" format="default"/>. A different perspective, more appropriate to protocols that are designed for global use from the beginning, is the definition used by the World Wide Web Consortium (W3C):</t>

<figure><artwork><![CDATA[
     "Internationalization (W3C) <xref target="W3Ci18nDef"/>:</t>

<blockquote>Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language."  {{W3Ci18nDef}}
]]></artwork></figure> language.</blockquote>

        <t>Many protocols that handle text only handle one charset (US-ASCII), (US-ASCII) or leave the question of what coded character set charset and encoding are used up to local guesswork (which leads, of course, to interoperability problems). If multiple charsets are permitted, they must be explicitly identified <xref target="RFC2277"/>. target="RFC2277" format="default"/>.  Adding non-ASCII text to a protocol allows the protocol to handle more scripts, hopefully representing users across the world.  In today’s today's world, that is normally best accomplished by allowing only Unicode encoded in UTF-8 only.</t> UTF-8.</t>
        <t>In current IETF practice <xref target="RFC2277"/>, target="RFC2277" format="default"/>, internationalization is aimed at user-facing strings, not protocol elements, such as the verbs used by some text-based protocols. (Do note that some strings are both content and protocol elements, such as identifiers.) Although this is reasonable practice for non-user visible elements, given the IETF’s mission to make the Internet a global network of networks, <xref target="RFC3935"/> developers should provide full and equal support for all scripts and character sets charsets in the user-facing features of protocols and for any content they carry.</t>
        <t>Example:
See localization</t> <xref target="localization"/> ("Localization").</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to political participation</t>
  <t>Right participation</li>
          <li>Right to participate in cultural life, arts arts, and science</t>
</list></t> science</li>
        </ul>
      </section>
      <section anchor="localization" title="Localization"> numbered="true" toc="default">
        <name>Localization</name>
        <t>Question(s):
Does your protocol uphold the standards of internationalization? Have you made any concrete steps towards localizing your protocol for relevant audiences?</t>
        <t>Explanation:
Localization "Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale) 'locale')" <xref target="W3Ci18nDef"/>. target="W3Ci18nDef" format="default"/>. For our purposes, it can be described as the practice of translating an implementation to make it functional in a specific language or for users in a specific locale (see Internationalization). <xref target="internationalization"/> ("Internationalization")). Internationalization is related to localization, but they are not the same. Internationalization is a necessary precondition for localization.</t>
        <t>Example:
The Internet is a global medium, but many of its protocols and products are developed with a certain audience audiences in mind, mind that often share particular characteristics like knowing how to read and write in American Standard Code for Information Interchange (ASCII) and knowing English. This limits the ability of a large part of the world’s world's online population from using the Internet in a way that is culturally and linguistically accessible. An example of a standard that has taken into account the view that individuals like to have access to data in their native preferred language can be found in <xref target="RFC5646"/>. target="RFC5646" format="default"/>. The document describes a way to label information with an identifier for the language in which it is written. And this allows information to be presented and accessed in more than one language.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to non-discrimination</t>
  <t>Right non-discrimination</li>
          <li>Right to participate in cultural life, arts arts, and science</t>
  <t>Right science</li>
          <li>Right to freedom of expression</t>
</list></t> expression</li>
        </ul>
      </section>
      <section anchor="open-standards" title="Open Standards"> numbered="true" toc="default">
        <name>Open Standards</name>
        <t>Question(s):
Is your protocol fully documented in a way that it could be easily implemented, improved, built upon upon, and/or further developed? Do you depend on proprietary code for the implementation, running running, or further development of your protocol? Does your protocol favor a particular proprietary specification over technically-equivalent technically equivalent competing specification(s), for instance instance, by making any incorporated vendor specification  “required”  "required" or “recommended” "recommended" <xref target="RFC2026"/>? target="RFC2026" format="default"/>? Do you normatively reference another standard that is not available without cost behind a paywall (and could you do without it)? Are you aware of any patents that would prevent your standard from being fully implemented <xref target="RFC8179"/> target="RFC8179" format="default"/> <xref target="RFC6701"/>?</t> target="RFC6701" format="default"/>?</t>
        <t>Explanation:
The Internet was able to be developed into the global network of networks because of the existence of open, non-proprietary standards <xref target="Zittrain"/>. target="Zittrain" format="default"/>. They are crucial for enabling interoperability. Yet, open standards are not explicitly defined within the IETF. On the subject, <xref target="RFC2026"/> states: “Various target="RFC2026" format="default"/> states:</t>
<blockquote>Various national and international standards bodies, such as ANSI, ISO, IEEE, and ITU-T, develop a variety of protocol and service specifications that are similar to Technical Specifications defined at here [at the IETF. IETF]. National and international groups also publish “implementors’ agreements” "implementors' agreements" that are analogous to Applicability Statements, capturing a body of implementation-specific detail concerned with the practical application of their standards. All of these are considered to be “open "open external standards” standards" for the purposes of the Internet Standards Process.” Similarly, Process.</blockquote>
<t>Similarly, <xref target="RFC3935"/> target="RFC3935" format="default"/> does not define open standards but does emphasize the importance of an “open process”, i.e., “any "open process", i.e.:</t>
<blockquote>... any interested person can participate in the work, know what is being decided, and make [their] voice heard on the issue.”</t> issue.</blockquote>
        <t>Open standards (and open source software) allow users to glean information about how the tools they are using work, including the tools’ tools' security and privacy properties. They additionally allow for permissionless innovation, which is important to maintain the freedom and ability to freely create and deploy new protocols on top of the communications constructs that currently exist. It is at the heart of the Internet as we know it, and to maintain its fundamentally open nature, we need to be mindful of the need for developing open standards.</t>
        <t>All standards that need to be normatively implemented should be freely available and with reasonable protection for patent infringement claims, claims so it that they can also be implemented in open source or free software. Patents have often held back open standardization or been used against those deploying open standards, particularly in the domain of cryptography <xref target="newegg"/>. target="Newegg" format="default"/>. An exemption of this is sometimes made when a protocol is standardized that protocol normatively relies on specifications produced by others standards development organizations Standards Development Organizations (SDOs) that are not freely available. Patents in open standards or in normative references to other standards should have a patent disclosure <xref target="notewell"/>, target="Note-well" format="default"/>, royalty-free licensing <xref target="patentpolicy"/>, target="Patent-policy" format="default"/>, or some other form of fair, reasonable reasonable, and non-discriminatory terms.</t>
        <t>Example:
<xref target="RFC6108"/> target="RFC6108" format="default"/> describes a system for providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast, that document describes a system that does not rely upon DPI, DPI and is instead based on open IETF standards and open source applications.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to participate in cultural life, arts arts, and science</t>
</list></t> science</li>
        </ul>
      </section>
      <section anchor="heterogeneity-support" title="Heterogeneity Support"> numbered="true" toc="default">
        <name>Heterogeneity Support</name>
        <t>Question(s):
Does your protocol support heterogeneity by design? Does your protocol allow for multiple types of hardware? Does your protocol allow for multiple types of application protocols? Is your protocol liberal in what it receives and handles? Will it remain usable and open if the context changes?</t>
        <t>Explanation:
The Internet is characterized by heterogeneity on many levels: devices and devices, nodes, router scheduling algorithms and algorithms, queue management mechanisms, routing protocols, levels of multiplexing, protocol versions and implementations, and underlying link layers (e.g., point-to-point, multi-access links, wireless, FDDI, etc.), Fiber Distributed Data Interface (FDDI), etc.) in the traffic mix and in the levels of congestion at different times and places. Moreover, as the Internet is composed of autonomous organizations and ISPs, each with their own separate policy concerns, there is a large heterogeneity of administrative domains and pricing structures. As a result, the heterogeneity principle proposed in <xref target="RFC1958"/> target="RFC1958" format="default"/> needs to be supported by design <xref target="FIArch"/>.</t> target="FIArch" format="default"/>.</t>
        <t>Heterogeneity support in protocols can thus can, thus, enable a wide range of devices and (by extension) users to participate on the network.</t>
<t>Example:
Heterogeneity significantly contributed to the success of the internet Internet architecture <xref target="Zittrain"/>. target="Zittrain" format="default"/>. There is a famous quote often attributed to Niels Bohr famously said: “Prediction Bohr: "Prediction is very difficult, especially if it’s it's about the future”, this future." This also holds true for future uses of the internet Internet architecture and infrastructure. Therefore, as a rule of thumb thumb, it is important to - -- as far as possible - -- design your protocol for different devices and uses, especially at lower layers of the stack. However, if you choose not to do this, it could be relevant to document the reasoning for that.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to political participation</t>
</list></t> participation</li>
        </ul>
      </section>
      <section anchor="adaptability" title="Adaptability"> numbered="true" toc="default">
        <name>Adaptability</name>
        <t>Question(s):
Question:
Is your protocol written in a modular fashion fashion, and does it facilitate or hamper extensibility? In this sense, does your protocol impact permissionless innovation? (See Open Standards)</t> <xref target="open-standards"/> ("Open Standards").)</t>
        <t>Explanation:
Adaptability is closely interrelated with permissionless innovation: both maintain the freedom and ability to freely create and deploy new protocols on top of the communications constructs that currently exist. It is at the heart of the Internet as we know it, and to maintain its fundamentally open nature, we need to be mindful of the impact of protocols on maintaining or reducing permissionless innovation to ensure that the Internet can continue to develop.</t>
        <t>Adaptability and permissionless innovation can be used to shape information networks as preferenced by groups of users. users prefer. Furthermore, a precondition of adaptability is the ability of the people who can adapt the network to be able to know and understand the network. This is why adaptability and permissionless innovation are inherently connected to the right to education and the right to science as well as the right to freedom of assembly and association as well as and the right to freedom of expression. Since expression, since it allows the users of the network to determine how to assemble, collaborate, and express themselves.</t>
        <t>Example:
WebRTC generates audio and/or video data. WebRTC can be used in different locations by different parties; WebRTC’s WebRTC's standard application programming interfaces Application Programming Interfaces (APIs) are developed to support applications from different voice service providers. Multiple parties will have similar capabilities, in capabilities. In order to ensure that all parties can build upon existing standards standards, these need to be adaptable, adaptable and allow for permissionless innovation.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to education</t>
  <t>Right education</li>
          <li>Right to science</t>
  <t>Right science</li>
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to freedom of assembly and association</t>
</list></t> association</li>
        </ul>
      </section>
      <section anchor="integrity" title="Integrity"> numbered="true" toc="default">
        <name>Integrity</name>
        <t>Question(s):
Does your protocol maintain, assure assure, and/or verify the accuracy of payload data? Does your protocol maintain and assure the consistency of data? Does your protocol in any way allow for the data to be (intentionally or unintentionally) altered?</t>
        <t>Explanation:
Integrity refers to the maintenance and assurance of the accuracy and consistency of data to ensure it has not been (intentionally or unintentionally) altered.</t>
        <t>Example:
Integrity verification of data is important to prevent vulnerabilities and attacks from on-path attackers. These attacks happen when a third party (often for malicious reasons) intercepts a communication between two parties, inserting themselves in the middle and changing the content of the data. In practice practice, this looks as follows:</t>
        <t>Alice wants to communicate with Bob.
Alice sends a message to Bob, which Corinne intercepts and modifies.
Bob cannot see that the data from Alice was altered by Corinne.
Corinne intercepts and alters the communication as it is sent between Alice and Bob.
Corinne is able to control the communication content.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to security</t>
</list></t> security</li>
        </ul>
      </section>
      <section anchor="authenticity" title="Authenticity"> numbered="true" toc="default">
        <name>Authenticity</name>
        <t>Question(s):
Do you have sufficient measures to confirm the truth of an attribute of a single piece of data or entity? Can the attributes get garbled along the way (see security)? <xref target="security"/> ("Security"))? If relevant, have you implemented IPsec, DNS Security (DNSSEC), HTTPS HTTPS, and other Standard Security Best Practices?</t> standard security best practices?</t>
        <t>Explanation:
Authenticity ensures that data does indeed come from the source it claims to come from. This is important to prevent certain attacks or unauthorized access and use of data.</t>
        <t>At the same time, authentication should not be used as a way to prevent heterogeneity support, as is often done for vendor lock-in or digital rights management.</t>
        <t>Example:
Authentication of data is important to prevent vulnerabilities, vulnerabilities and attacks from on-path attackers. These attacks happen when a third party (often for malicious reasons) intercepts a communication between two parties, inserting themselves in the middle and posing as both parties. In practice practice, this looks as follows:</t>
        <t>Alice wants to communicate with Bob.
Alice sends data to Bob.
Corinne intercepts the data sent to Bob.
Corinne reads (and potentially alters) the message to Bob.
	Bob cannot see that the data did not come from Alice but from Corinne.</t>
        <t>With proper authentication, the scenario would be as follows:</t>
        <t>Alice wants to communicate with Bob.
Alice sends data to Bob.
Corinne intercepts the data sent to Bob.
Corinne reads and alters the message to Bob.
Bob is unable to verify whether that the data came from Alice.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to privacy</t>
  <t>Right privacy</li>
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to security</t>
</list></t> security</li>
        </ul>
      </section>
      <section anchor="confidentiality" title="Confidentiality"> numbered="true" toc="default">
        <name>Confidentiality</name>
        <t>Question(s):
Does the protocol expose the transmitted data over the wire? Does the protocol expose information related to identifiers or data? If so, what does it reveal to each protocol entity (i.e., recipients, intermediaries, and enablers) <xref target="RFC6973"/>? target="RFC6973" format="default"/>? What options exist for protocol implementers to choose to limit the information shared with each entity? What operational controls are available to limit the information shared with each entity?</t>
        <t>What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol? If no such mechanisms or controls are specified, is it expected that control and consent will be handled outside of the protocol?</t>
        <t>Does the protocol provide ways for initiators to share different pieces of information with different recipients? If not, are there mechanisms that exist outside of the protocol to provide initiators with such control?</t>
        <t>Does the protocol provide ways for initiators to limit the sharing or express individuals’ expressing of individuals' preferences to recipients or intermediaries with regard to the collection, use, or disclosure of their personal data? If not, are there mechanisms that exist outside of the protocol to provide users with such control? Is it expected that users will have relationships that govern the use of the information (contractual or otherwise) with those who operate these intermediaries? Does the protocol prefer encryption over clear text cleartext operation?</t>
        <t>Explanation:
Confidentiality refers to keeping your data secret from unintended listeners <xref target="BCP72"/>. target="RFC3552" format="default"/>. The growth of the Internet depends on users having confidence that the network protects their personal data <xref target="RFC1984"/>. target="RFC1984" format="default"/>. The possibility of pervasive monitoring and surveillance undermines users’ trust, users' trust and can be mitigated by ensuring confidentiality, i.e., passive attackers should gain little or no information from observation or inference of protocol activity. activity <xref target="RFC7258" format="default"/> <xref target="RFC7258"/><xref target="RFC7624"/>.</t> target="RFC7624" format="default"/>.</t>
        <t>Example:
Protocols that do not encrypt their payload make the entire content of the communication available to the idealized attacker along their path. Following the advice in <xref target="RFC3365"/>, target="RFC3365" format="default"/>, most such protocols have a secure variant that encrypts the payload for confidentiality, and these secure variants are seeing ever-wider deployment. A noteworthy exception is DNS <xref target="RFC1035"/>, target="RFC1035" format="default"/>, as DNSSEC <xref target="RFC4033"/> target="RFC4033" format="default"/> does not have confidentiality as a requirement. This implies that, in the absence of the use of more recent standards like DNS over TLS <xref target="RFC7858"/> target="RFC7858" format="default"/> or DNS over HTTPS <xref target="RFC8484"/>, target="RFC8484" format="default"/>, all DNS queries and answers generated by the activities of any protocol are available to the attacker. When store-and-forward protocols are used (e.g., SMTP <xref target="RFC5321"/>), target="RFC5321" format="default"/>), intermediaries leave this data subject to observation by an attacker that has compromised these intermediaries, unless the data is encrypted end-to-end by the application-layer protocol or the implementation uses an encrypted store for this data <xref target="RFC7624"/>.</t> target="RFC7624" format="default"/>.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to privacy</t>
  <t>Right privacy</li>
          <li>Right to security</t>
</list></t> security</li>
        </ul>
      </section>
      <section anchor="security" title="Security"> numbered="true" toc="default">
        <name>Security</name>
        <t>Question(s):
Did you have a look at Guidelines <xref target="RFC3552" format="default"> "Guidelines for Writing RFC Text on Security Considerations <xref target="BCP72"/>? Considerations"</xref>? Have you found any attacks that are somewhat related to your protocol/specification, protocol/specification yet considered out of scope of your document? Would these attacks be pertinent to the human rights enabling human-rights-enabling features of the Internet (as described throughout this document)?</t>
        <t>Explanation:
Security is not a single monolithic property of a protocol or system, system but rather a series of related but yet somewhat independent properties. Not all of these properties are required for every application. Since communications are carried out by systems and access to systems is through communications channels, security goals obviously interlock, but they can also be independently provided. provided <xref target="BCP72"/>.</t> target="RFC3552" format="default"/>.</t>
        <t>Typically, any protocol operating on the Internet can be the target of passive attacks (when the attacker can access and read packets on the network); network) and active attacks (when an attacker is capable of writing information to the network packets). packets) <xref target="BCP72"/></t> target="RFC3552" format="default"/>.</t>
        <t>Example:
See <xref target="BCP72"/>.</t> target="RFC3552" format="default"/>.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to freedom of assembly and association</t>
  <t>Right association</li>
          <li>Right to non-discrimination</t>
  <t>Right non-discrimination</li>
          <li>Right to security</t>
</list></t> security</li>
        </ul>
      </section>
      <section anchor="privacy" title="Privacy"> numbered="true" toc="default">
        <name>Privacy</name>
        <t>Question(s):
Did you have a look at the Guidelines guidelines described in the Privacy Section <xref target="RFC6973" sectionFormat="bare" section="7"/> of "Privacy Considerations for Internet Protocols Protocols" <xref target="RFC6973"/> section 7? target="RFC6973"/>? Does your protocol maintain the confidentiality of metadata? Could your protocol counter traffic analysis? Does your protocol adhere to data minimization principles?  Does your document identify potentially sensitive data logged by your protocol and/or for how long that needs to be retained for technical reasons?</t>
        <t>Explanation:
	Privacy refers to the right of an entity (normally a person), acting on its own behalf, to determine the degree to which it will interact with its environment, including the degree to which the entity is willing to share its personal information with others. others <xref target="RFC4949"/>. target="RFC4949" format="default"/>. If a protocol provides insufficient privacy protection protection, it may have a negative impact on freedom of expression as users self-censor for fear of surveillance, surveillance or find themselves that they are unable to express themselves freely.</t>
        <t>Example:
See <xref target="RFC6973"/></t> target="RFC6973" format="default"/>.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to privacy</t>
  <t>Right privacy</li>
          <li>Right to non-discrimination</t>
</list></t> non-discrimination</li>
        </ul>
      </section>
      <section anchor="anonymity-and-pseudonymity" title="Anonymity numbered="true" toc="default">
        <name>Anonymity and Pseudonymity"> Pseudonymity</name>
        <t>Question(s): Does your protocol make use of identifiers? Are these
identifiers persistent?  Are they used across multiple contexts? Is it
possible for the user to reset or rotate them without negatively
impacting the operation fo of the protocol? Are they visible to others
besides the protocol endpoints? Are they tied to real-world
identities? Have you considered the Privacy Considerations for
Internet Protocols "<xref target="RFC6973" format="title"/>" <xref target="RFC6973"/>, target="RFC6973" format="default"/>, especially section 6.1.2?</t> Section <xref target="RFC6973" sectionFormat="bare" section="6.1.2"/>?</t>
        <t>Explanation:
Most protocols depend on the use of some kind of identifier in order to correlate
activity over time and space. For instance:</t>

<t><list style="symbols">
  <t>IP
        <ul spacing="normal">
          <li>IP addresses are used as an identity for the source and
          destination for IP datagrams.</t>
  <t>QUIC datagrams.</li>
          <li>QUIC connection identifiers are used to correlate packets
          belonging to the same connection.</t>
  <t>HTTP connection.</li>
          <li>HTTP uses cookies to correlate multiple HTTP requests from the
          same
client.</t>
  <t>Email client.</li>
          <li>Email uses email addresses of the form <eref target="mailto:example@example.com">example@example.com</eref> example@example.com to
          identify senders and receivers.</t>
</list></t> receivers.</li>
        </ul>
        <t>In general, these identifiers serve a necessary function for protocol operations, operations
by allowing them to maintain continuity. However, they can also create privacy
risks. There are two major ways in which those risks manifest:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The identifier may itself reveal the user’s user's identity in some way
          or be tied to an identifier which that does, as is the case when E.164
          (telephone) numbers are used as identifiers for instant messaging systems.</t>
  <t>While
          systems.</li>
	  <li>While the identifier may not reveal the user’s user's identity, it may
	  make it possible to link enough of a user’s user's behavior to threaten
	  their privacy, as is the case with HTTP cookies.</t>
</list></t> cookies.</li>
        </ul>
        <t>Because identifiers are necessary for protocol operation, true anonymity
is very difficult to achieve, but there are practices which that promote
user privacy even when identifiers are used.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to non-discrimination</t>
  <t>Right non-discrimination</li>
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to political participation</t>
  <t>Right participation</li>
          <li>Right to freedom of assembly and association</t>
</list></t> association</li>
        </ul>
        <section anchor="pseudonymity" title="Pseudonymity"> numbered="true" toc="default">
          <name>Pseudonymity</name>
          <t>In general, user privacy is better preserved when identifiers are
pseudonymous (not tied to a user’s user's real-world identity).</t>
          <t>Example: In the development of the IPv6 protocol, it was discussed to
embed a Media Access Control (MAC) address into unique IP
addresses. This would make it possible for eavesdroppers and other
information collectors to identify when different addresses used in
different transactions actually correspond to the same node. This is
why standardization efforts like Privacy Extensions for Stateless
Address Autoconfiguration in IPv6 "<xref target="RFC8981" format="title"/>" <xref target="RFC4941"/> target="RFC8981" format="default"/> and MAC address
randomization <xref target="draft-zuniga-mac-address-randomization"/> target="I-D.ietf-madinas-mac-address-randomization" format="default"/> have been
pursued.</t>
          <t>Note that it is often attractive to try to create a pseudonym from
a persistent identifier. This can be very difficult to do correctly
in a way that does not allow for recovering the persistent identifiers.</t>
          <t>Example: A common practice in Web web tracking is to “encrypt” "encrypt" email
addresses by hashing them, thus allegedly making them
“non-personally identifying”.
"non-personally identifying". However, because hash functions
are public operations, it is possible to do a dictionary search for candidate
email addresses and recover the original address <xref target="email-hashing"/>.</t> target="Email-hashing" format="default"/>.</t>
        </section>
        <section anchor="unlinkability" title="Unlinkability"> numbered="true" toc="default">
          <name>Unlinkability</name>
          <t>Even true pseudonymous identifiers can present a privacy risk if they are used across a wide enough scope. User privacy is better preserved
if identifiers have limited scope both in time and space.</t>
   <t>Example: An example is the Dynamic Host Configuration Protocol (DHCP) where sending a persistent identifier as the client name was not mandatory but, in practice, done by many implementations, implementations before DHCP <xref target="RFC7844"/>.</t> target="RFC7844" format="default"/>.</t>
          <t>Example: Third party Third-party cookies in HTTP allow trackers to correlate
HTTP traffic across sites.  This is the foundation of a whole
ecosystem of Web web tracking. Increasingly, Web web browsers are restricting
the use of third party third-party cookies in order to protect user privacy.</t>
        </section>
      </section>
      <section anchor="censorship-resistance" title="Censorship resistance"> numbered="true" toc="default">
        <name>Censorship Resistance</name>
        <t>Question(s):
Does your protocol architecture facilitate censorship? Does it include “choke points” which "choke points" that are easy to use for censorship? Does it expose identifiers which that can be used to selectively block certain kinds of trafic? traffic? Could it be designed to be more censorship resistant? Does your protocol make it apparent or transparent when access to a resource is restricted and the reasons why it is restricted?</t>
        <t>Explanation:
Governments and service providers block or filter content or traffic, often without the knowledge of end-users. <xref target="RFC7754"/> See end users <xref target="draft-irtf-pearg-censorship"/> for target="RFC7754" format="default"/>. For a survey of censorship techniques employed across the world, see <xref target="RFC9505" format="default"/>, which lays out protocol properties that have been exploited to censor access to information. Censorship resistance refers to the methods and measures to prevent Internet censorship.</t>
        <t>Example:
The current design of the Web has a number of architectural choke points where it is possible for censors to intervene. These include obtaining the control of the domain name itself, DNS blocking at either at the protocol layer or at the resolver, IP address blocking, and blocking at the Web web server. There has been extensive work on content distribution systems systems, which are intended to be more censorship resistant, resistant; and some, such as BitTorrent, are in wide use, but use. However, these systems may have inferior reliability and performance compared to the Web (e.g., they do not support active content on the server).</t>
        <t>Example:
Identifiers of content exposed within a protocol might be used to facilitate censorship by allowing the censor to determine which traffic to block. DNS queries, the “host” "host" request header in an HTTP request, and the Server Name Indication (SNI) in a Transport Layer Security (TLS) ClientHello are all examples of protocol elements that can travel in plaintext and be used by censors to identify what content a user is trying to access. access <xref target="draft-irtf-pearg-censorship"/>. target="RFC9505" format="default"/>. Protocol mechanisms such as Encrypted Client Hello ClientHello <xref target="I-D.ietf-tls-esni"/> target="I-D.ietf-tls-esni" format="default"/> or DNS over HTTPS <xref target="RFC8484"/> target="RFC8484" format="default"/> that encrypt metadata provide some level of resistance to this type of protocol inspection. Full traffic encryption systems systems, such as Tor [https://torproject.org] <eref target="https://torproject.org" brackets="angle"/>, can also be used by people to access otherwise censored resources.</t>
        <t>Example: As noted above, one way to censor Web web traffic is to require the server to block it or require internet service providers ISPs to block requests to the server. In HTTP, denial or restriction of access can be made apparent by the use of status code 451, which allows server operators and intermediaries to operate with greater transparency in circumstances where issues of law or public policy affect their operation <xref target="RFC7725"/>. target="RFC7725" format="default"/>. If a protocol potentially enables censorship, protocol designers should strive towards creating error codes that capture different scenarios (blocked (e.g., blocked due to administrative policy, unavailable because of legal requirements, etc.) to minimize ambiguity for end-users.</t> end users.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to political participation</t>
  <t>Right participation</li>
          <li>Right to participate in cultural life, arts, and science</t>
  <t>Right science</li>
          <li>Right to freedom of assembly and association</t>
</list></t> association</li>
        </ul>
      </section>
      <section anchor="outcome-transparency" title="Outcome Transparency"> numbered="true" toc="default">
        <name>Outcome Transparency</name>
        <t>Question(s): Are the intended and forseen foreseen effects of your protocol documented and easily comprehensible?</t>

<t>Explanation: Certain technical choices may have unintended consequences. comprehensible? Have you described the central use case(s) for your protocol with a clear description of expected behavior and how it may, or may not, impact other protocols, implementations, user expectations, or behavior? Have you reviewed other protocols that solve similar problems, or make made use of similar mechanisms, to see if there are lessons that can be learnt learned from their use and misuse?</t>
        <t>Explanation: Certain technical choices may have unintended consequences.</t>
        <t>Example: Lack of authenticity may lead to lack of integrity and negative externalities, externalities; of which which, spam is an example. Lack of data that could be used for billing and accounting can lead to so-called “free” "free" arrangements which that obscure the actual costs and distribution of the costs, for example example, the barter arrangements that are commonly used for Internet interconnection; interconnection, and the commercial exploitation of personal data for targeted advertising advertising, which is the most common funding model for the so-called “free” "free" services such as search engines and social networks. Unexpected outcomes might not be technical, technical but rather architectural, social social, or economic. Therefore Therefore, it is of importance to document the intended outcomes and other possible outcomes that have been considered.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to privacy</t>
  <t>Right privacy</li>
          <li>Right to freedom of assembly and association</t>
  <t>Right association</li>
          <li>Right to access to information</t>
</list></t> information</li>
        </ul>
      </section>
      <section anchor="accessibility" title="Accessibility"> numbered="true" toc="default">
        <name>Accessibility</name>
        <t>Question(s):
Is your protocol designed to provide an enabling environment for all? Have you looked at the W3C Web Accessibility Initiative for examples and guidance?</t> guidance <xref target="W3CAccessibility" format="default"/>?</t>
        <t>Explanation:
Sometimes in the design of protocols, websites, web technologies, or web tools, barriers are created that exclude people from using the Web. The Internet should be designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Internet technologies meet this goal, it will be accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. ability <xref target="W3CAccessibility"/></t> target="W3CAccessibility" format="default"/>.</t>
        <t>Example:
The HTML protocol as defined in <xref target="HTML5"/> target="HTML" format="default"/> specifically requires that every image must have an alt attribute (with a few exceptions) to ensure images are accessible for people that who cannot themselves decipher non-text content in web pages.</t>
        <t>Another example is the work done in the AVT and AVTCORE working groups Working Groups in the IETF that enables text conversation in multimedia, text telephony, wireless multimedia multimedia, and video communications for sign language and lip-reading lipreading (i.e., <xref target="RFC9071"/>).</t> target="RFC9071" format="default"/>).</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to non-discrimination</t>
  <t>Right non-discrimination</li>
          <li>Right to freedom of assembly and association</t>
  <t>Right association</li>
          <li>Right to education</t>
  <t>Right education</li>
          <li>Right to political participation</t>
</list></t> participation</li>
        </ul>
      </section>
      <section anchor="decentralization" title="Decentralization"> numbered="true" toc="default">
        <name>Decentralization</name>
        <t>Question(s):
Can your protocol be implemented without a single point of control? If applicable, can your protocol be deployed in a federated manner? Does your protocol create additional centralized points of control?</t>
        <t>Explanation:
Decentralization is one of the central technical concepts of the architecture of the Internet, Internet and is embraced as such by the IETF <xref target="RFC3935"/>. target="RFC3935" format="default"/>. It refers to the absence or minimization of centralized points of control, a feature that is assumed to make it easy for new users to join and new uses to unfold <xref target="Brown"/>. target="Ziewitz" format="default"/>. It also reduces issues surrounding single points of failure, failure and distributes the network such that it continues to function even if one or several nodes are disabled. With the commercialization of the Internet in the early 1990s, there has been a slow move away from decentralization, to the detriment of the technical benefits of having a decentralized Internet. For a more detailed discussion of this topic, please see <xref target="arkkoetal"/>.</t> target="I-D.arkko-iab-internet-consolidation" format="default"/>.</t>
        <t>Example:
The bits traveling the Internet are increasingly susceptible to monitoring and censorship, censorship from both governments and ISPs, ISPs as well as third (malicious) parties. The ability to monitor and censor is further enabled by the increased centralization of the network that creates central infrastructure points that can be tapped into. The creation of peer-to-peer networks and the development of voice-over-IP protocols using peer-to-peer technology in combination with distributed hash table Distributed Hash Table (DHT) for scalability are examples of how protocols can preserve decentralization <xref target="Pouwelse"/>.</t> target="I-D.pouwelse-censorfree-scenarios" format="default"/>.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to freedom of expression</t>
  <t>Right expression</li>
          <li>Right to freedom of assembly and association</t>
</list></t> association</li>
        </ul>
      </section>
      <section anchor="remedy" title="Remedy"> numbered="true" toc="default">
        <name>Remedy</name>
        <t>Question(s): Can your protocol facilitate a negatively impacted party’s party's right to remedy without disproportionately impacting other parties’ parties' human rights, especially their right to privacy?</t>
        <t>Explanation: Providing access to remedy by states and corporations is a part of the UN Guiding Principles on Business and Human Rights <xref target="UNGP"/>. target="UNGP" format="default"/>. Access to remedy may help victims of human rights violations in seeking justice, justice or allow law enforcement agencies to identify a possible violator. However, current mechanisms in protocols that try to enable ‘attribution’ "attribution" to individuals impede the exercise of the right to privacy. The former UN Special Rapporteur for Freedom of Expression has also argued that anonymity is an inherent part of freedom of expression <xref target="Kaye"/>. target="Kaye" format="default"/>. Considering the potential adverse impact of attribution on the right to privacy and freedom of expression, enabling attribution on an individual level is most likely not consistent with human rights.</t>
        <t>Example: Adding personally identifiable information to data streams as a means to enable the human right to remedy might help in identifying a violator of human rights and provide access to remedy, but this would disproportionally disproportionately affect all users right to privacy, anonymous expression, and association.
Furthermore, there are some recent advances in enabling abuse detection in end-to-end encrypted messaging systems, which also carry some risk to users’ users' privacy <xref target="messenger-franking"/><xref target="hecate"/>.</t> target="Messenger-franking" format="default"/> <xref target="Hecate" format="default"/>.</t>
        <t>Impacts:</t>

<t><list style="symbols">
  <t>Right
        <ul spacing="normal">
          <li>Right to remedy</t>
  <t>Right remedy</li>
          <li>Right to security</t>
  <t>Right security</li>
          <li>Right to privacy</t>
</list></t> privacy</li>
        </ul>
      </section>
      <section anchor="misc-considerations" title="Misc. considerations"> numbered="true" toc="default">
        <name>Miscellaneous Considerations</name>
        <t>Question(s): Have you considered potential negative consequences (individual or societal) that your protocol or document might have?</t>
        <t>Explanation: Publication of a particular RFC under a certain status has consequences. Publication as an Internet Standard as part of the Standards Track may signal to implementers that the specification has a certain level of maturity, operational experience, and consensus.  Similarly, publication of a specification as an experimental document as not part of the non-standards track Standards Track would signal to the community that the document “may "may not be intended to be an Internet Standard, or it may be intended for eventual standardization but [may] not yet [be] ready” ready" for wide deployment. deployment <xref target="RFC2026" format="default"/>. The extent of the deployment, and consequently its overall impact on end-users, end users, may depend on the document status presented in the RFC. See <xref target="BCP9"/> target="RFC2026" format="default"/> and updates to it for a fuller explanation.</t>
      </section>
    </section>
    <section anchor="document-status" title="Document Status"> numbered="true" toc="default">
      <name>Document Status</name>
      <t>This RG research group document lays out best practices and guidelines for human rights reviews of network protocols, architectures architectures, and other Internet-Drafts and RFCs.</t>
    </section>

    <section anchor="acknowledgements" title="Acknowledgements">
<t>Thanks to:</t>

<t><list style="symbols">
  <t>Corinne Cath-Speth for work on <xref target="RFC8280"/>.</t>
  <t>Reese Enghardt, Joe Hall, Avri Doria, Joey Salazar, Corinne Cath-Speth, Farzaneh Badii, Sandra Braman, Colin Perkins, John Curran, Eliot Lear, Mallory Knodel, Brian Trammell, Jane Coffin, Eric Rescorla, Sofía Celi and the hrpc list for reviews and suggestions.</t>
  <t>Individuals who conducted human rights reviews for their work and feedback: Amelia Andersdotter, Shane Kerr, Beatrice Martini, Karan Saini, and Shivan Kaul Sahib.</t>
</list></t>

</section>
<section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Article three of the Universal "Universal Declaration of Human Rights Rights" reads: “Everyone "Everyone has the right to life, liberty and security of person.”. person" <xref target="UDHR" format="default"/>. This article underlines the importance of security and its interrelation with human life and liberty, liberty; but since human rights are indivisible, interrelated interrelated, and interdependent, security is also closely linked to other human rights and freedoms. This document seeks to strengthen human rights, freedoms, and security by relating and translating these concepts to concepts and practices as they are used in Internet protocol and architecture development. The aim of this is to secure human rights and thereby improve the sustainability, usability, and effectiveness of the network. The document seeks to achieve this by providing guidelines as done in section three <xref target="conducting-human-rights-reviews" format="default"/> of this document.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t> IANA actions.</t>
    </section>
    <section anchor="research-group-information" title="Research numbered="true" toc="default">
      <name>Research Group Information"> Information</name>
      <t>The discussion list for the IRTF Human Rights Protocol Considerations
      Research Group is located at the e-mail address address: <eref target="mailto:hrpc@ietf.org">hrpc@ietf.org</eref>. Information
      target="mailto:hrpc@ietf.org" brackets="angle"/>.</t>
      <t>Information on the group and information on how to subscribe to the
      list is at at: <eref target="https://www.irtf.org/mailman/listinfo/hrpc">https://www.irtf.org/mailman/listinfo/hrpc</eref></t> target="https://www.irtf.org/mailman/listinfo/hrpc"
      brackets="angle"/>.</t>
      <t>Archives of the list can be found at: <eref target="https://www.irtf.org/mail-archive/web/hrpc/current/index.html">https://www.irtf.org/mail-archive/web/hrpc/current/index.html</eref></t>
      target="https://mailarchive.ietf.org/arch/browse/hrpc/"
      brackets="angle"/>.</t>
    </section>
  </middle>
  <back>

    <references title='Informative References'>

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

<reference anchor='RFC1035' target='https://www.rfc-editor.org/info/rfc1035'>
  <front>
    <title>Domain names - implementation and specification</title>
    <author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'/>
    <date month='November' year='1987'/>
    <abstract>
      <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
    </abstract>
  </front>
  <seriesInfo name='STD' value='13'/>
  <seriesInfo name='RFC' value='1035'/>
  <seriesInfo name='DOI' value='10.17487/RFC1035'/>
</reference>

<reference anchor='RFC1958' target='https://www.rfc-editor.org/info/rfc1958'>
  <front>
    <title>Architectural Principles of the Internet</title>
    <author fullname='B. Carpenter' initials='B.' role='editor' surname='Carpenter'/>
    <date month='June' year='1996'/>
    <abstract>
      <t>The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='1958'/>
  <seriesInfo name='DOI' value='10.17487/RFC1958'/>
</reference>

<reference anchor='RFC1984' target='https://www.rfc-editor.org/info/rfc1984'>
  <front>
    <title>IAB and IESG Statement on Cryptographic Technology and the Internet</title>
    <author>
      <organization abbrev='IAB'>Internet Architecture Board</organization>
    </author>
    <author>
      <organization abbrev='IESG'>Internet Engineering Steering Group</organization>
    </author>
    <date month='August' year='1996'/>
    <abstract>
      <t>The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='200'/>
  <seriesInfo name='RFC' value='1984'/>
  <seriesInfo name='DOI' value='10.17487/RFC1984'/>
</reference>

<reference anchor='RFC2026' target='https://www.rfc-editor.org/info/rfc2026'>
  <front>
    <title>The Internet Standards Process -- Revision 3</title>
    <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
    <date month='October' year='1996'/>
    <abstract>
      <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='9'/>
  <seriesInfo name='RFC' value='2026'/>
  <seriesInfo name='DOI' value='10.17487/RFC2026'/>
</reference>

<reference anchor='RFC2277' target='https://www.rfc-editor.org/info/rfc2277'>
  <front>
    <title>IETF Policy on Character Sets and Languages</title>
    <author fullname='H. Alvestrand' initials='H.' surname='Alvestrand'/>
    <date month='January' year='1998'/>
    <abstract>
      <t>This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='18'/>
  <seriesInfo name='RFC' value='2277'/>
  <seriesInfo name='DOI' value='10.17487/RFC2277'/>
</reference>

<reference anchor='RFC3365' target='https://www.rfc-editor.org/info/rfc3365'>
  <front>
    <title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
    <author fullname='J. Schiller' initials='J.' surname='Schiller'/>
    <date month='August' year='2002'/>
  </front>
  <seriesInfo name='BCP' value='61'/>
  <seriesInfo name='RFC' value='3365'/>
  <seriesInfo name='DOI' value='10.17487/RFC3365'/>
</reference>

<reference anchor='RFC3724' target='https://www.rfc-editor.org/info/rfc3724'>
  <front>
    <title>The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture</title>
    <author fullname='J. Kempf' initials='J.' role='editor' surname='Kempf'/>
    <author fullname='R. Austein' initials='R.' role='editor' surname='Austein'/>
    <author>
      <organization abbrev='IAB'>Internet Architecture Board</organization>
    </author>
    <date month='March' year='2004'/>
    <abstract>
      <t>The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='3724'/>
  <seriesInfo name='DOI' value='10.17487/RFC3724'/>
</reference>

<reference anchor='RFC3935' target='https://www.rfc-editor.org/info/rfc3935'>
  <front>
    <title>A Mission Statement for the IETF</title>
    <author fullname='H. Alvestrand' initials='H.' surname='Alvestrand'/>
    <date month='October' year='2004'/>
    <abstract>
      <t>This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='95'/>
  <seriesInfo name='RFC' value='3935'/>
  <seriesInfo name='DOI' value='10.17487/RFC3935'/>
</reference>

<reference anchor='RFC8179' target='https://www.rfc-editor.org/info/rfc8179'>
  <front>
    <title>Intellectual Property Rights in IETF Technology</title>
    <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
    <author fullname='J. Contreras' initials='J.' surname='Contreras'/>
    <date month='May' year='2017'/>
    <abstract>
      <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='79'/>
  <seriesInfo name='RFC' value='8179'/>
  <seriesInfo name='DOI' value='10.17487/RFC8179'/>
</reference>

<reference anchor='RFC4033' target='https://www.rfc-editor.org/info/rfc4033'>
  <front>
    <title>DNS Security Introduction and Requirements</title>
    <author fullname='R. Arends' initials='R.' surname='Arends'/>
    <author fullname='R. Austein' initials='R.' surname='Austein'/>
    <author fullname='M. Larson' initials='M.' surname='Larson'/>
    <author fullname='D. Massey' initials='D.' surname='Massey'/>
    <author fullname='S. Rose' initials='S.' surname='Rose'/>
    <date month='March' year='2005'/>
    <abstract>
      <t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='4033'/>
  <seriesInfo name='DOI' value='10.17487/RFC4033'/>
</reference>

<reference anchor='RFC4101' target='https://www.rfc-editor.org/info/rfc4101'>
  <front>
    <title>Writing Protocol Models</title>
    <author fullname='E. Rescorla' initials='E.' surname='Rescorla'/>
    <author>
      <organization abbrev='IAB'>Internet Architecture Board</organization>
    </author>
    <date month='June' year='2005'/>
    <abstract>
      <t>The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='4101'/>
  <seriesInfo name='DOI' value='10.17487/RFC4101'/>
</reference>

<reference anchor='RFC4941' target='https://www.rfc-editor.org/info/rfc4941'>
  <front>
    <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
    <author fullname='T. Narten' initials='T.' surname='Narten'/>
    <author fullname='R. Draves' initials='R.' surname='Draves'/>
    <author fullname='S. Krishnan' initials='S.' surname='Krishnan'/>
    <date month='September' year='2007'/>
    <abstract>
      <t>Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='4941'/>
  <seriesInfo name='DOI' value='10.17487/RFC4941'/>
</reference>

<reference anchor='RFC4949' target='https://www.rfc-editor.org/info/rfc4949'>
  <front>
    <title>Internet Security Glossary, Version 2</title>
    <author fullname='R. Shirey' initials='R.' surname='Shirey'/>
    <date month='August' year='2007'/>
    <abstract>
      <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name='FYI' value='36'/>
  <seriesInfo name='RFC' value='4949'/>
  <seriesInfo name='DOI' value='10.17487/RFC4949'/>
</reference>

<reference anchor='RFC5321' target='https://www.rfc-editor.org/info/rfc5321'>
  <front>
    <title>Simple Mail Transfer Protocol</title>
    <author fullname='J. Klensin' initials='J.' surname='Klensin'/>
    <date month='October' year='2008'/>
    <abstract>
      <t>This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='5321'/>
  <seriesInfo name='DOI' value='10.17487/RFC5321'/>
</reference>

<reference anchor='RFC5646' target='https://www.rfc-editor.org/info/rfc5646'>
  <front>
    <title>Tags for Identifying Languages</title>
    <author fullname='A. Phillips' initials='A.' role='editor' surname='Phillips'/>
    <author fullname='M. Davis' initials='M.' role='editor' surname='Davis'/>
    <date month='September' year='2009'/>
    <abstract>
      <t>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='47'/>
  <seriesInfo name='RFC' value='5646'/>
  <seriesInfo name='DOI' value='10.17487/RFC5646'/>
</reference>

<reference anchor='RFC6108' target='https://www.rfc-editor.org/info/rfc6108'>
  <front>
    <title>Comcast's Web Notification System Design</title>
    <author fullname='C. Chung' initials='C.' surname='Chung'/>
    <author fullname='A. Kasyanov' initials='A.' surname='Kasyanov'/>
    <author fullname='J. Livingood' initials='J.' surname='Livingood'/>
    <author fullname='N. Mody' initials='N.' surname='Mody'/>
    <author fullname='B. Van Lieu' initials='B.' surname='Van Lieu'/>
    <date month='February' year='2011'/>
    <abstract>
      <t>The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6108'/>
  <seriesInfo name='DOI' value='10.17487/RFC6108'/>
</reference>

<reference anchor='RFC6235' target='https://www.rfc-editor.org/info/rfc6235'>
  <front>
    <title>IP Flow Anonymization Support</title>
    <author fullname='E. Boschi' initials='E.' surname='Boschi'/>
    <author fullname='B. Trammell' initials='B.' surname='Trammell'/>
    <date month='May' year='2011'/>
    <abstract>
      <t>This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6235'/>
  <seriesInfo name='DOI' value='10.17487/RFC6235'/>
</reference>

<reference anchor='RFC6365' target='https://www.rfc-editor.org/info/rfc6365'>
  <front>
    <title>Terminology Used in Internationalization in the IETF</title>
    <author fullname='P. Hoffman' initials='P.' surname='Hoffman'/>
    <author fullname='J. Klensin' initials='J.' surname='Klensin'/>
    <date month='September' year='2011'/>
    <abstract>
      <t>This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='166'/>
  <seriesInfo name='RFC' value='6365'/>
  <seriesInfo name='DOI' value='10.17487/RFC6365'/>
</reference>

<reference anchor='RFC6701' target='https://www.rfc-editor.org/info/rfc6701'>
  <front>
    <title>Sanctions Available for Application to Violators of IETF IPR Policy</title>
    <author fullname='A. Farrel' initials='A.' surname='Farrel'/>
    <author fullname='P. Resnick' initials='P.' surname='Resnick'/>
    <date month='August' year='2012'/>
    <abstract>
      <t>The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.</t>
      <t>The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.</t>
      <t>This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6701'/>
  <seriesInfo name='DOI' value='10.17487/RFC6701'/>
</reference>

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

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

<reference anchor='RFC7624' target='https://www.rfc-editor.org/info/rfc7624'>
  <front>
    <title>Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement</title>
    <author fullname='R. Barnes' initials='R.' surname='Barnes'/>
    <author fullname='B. Schneier' initials='B.' surname='Schneier'/>
    <author fullname='C. Jennings' initials='C.' surname='Jennings'/>
    <author fullname='T. Hardie' initials='T.' surname='Hardie'/>
    <author fullname='B. Trammell' initials='B.' surname='Trammell'/>
    <author fullname='C. Huitema' initials='C.' surname='Huitema'/>
    <author fullname='D. Borkmann' initials='D.' surname='Borkmann'/>
    <date month='August' year='2015'/>
    <abstract>
      <t>Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7624'/>
  <seriesInfo name='DOI' value='10.17487/RFC7624'/>
</reference>

<reference anchor='RFC7725' target='https://www.rfc-editor.org/info/rfc7725'>
  <front>
    <title>An HTTP Status Code to Report Legal Obstacles</title>
    <author fullname='T. Bray' initials='T.' surname='Bray'/>
    <date month='February' year='2016'/>
    <abstract>
      <t>This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7725'/>
  <seriesInfo name='DOI' value='10.17487/RFC7725'/>
</reference>

<reference anchor='RFC7844' target='https://www.rfc-editor.org/info/rfc7844'>
  <front>
    <title>Anonymity Profiles for DHCP Clients</title>
    <author fullname='C. Huitema' initials='C.' surname='Huitema'/>
    <author fullname='T. Mrugalski' initials='T.' surname='Mrugalski'/>
    <author fullname='S. Krishnan' initials='S.' surname='Krishnan'/>
    <date month='May' year='2016'/>
    <abstract>
      <t>Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7844'/>
  <seriesInfo name='DOI' value='10.17487/RFC7844'/>
</reference>

<reference anchor='RFC7858' target='https://www.rfc-editor.org/info/rfc7858'>
  <front>
    <title>Specification for DNS over Transport Layer Security (TLS)</title>
    <author fullname='Z. Hu' initials='Z.' surname='Hu'/>
    <author fullname='L. Zhu' initials='L.' surname='Zhu'/>
    <author fullname='J. Heidemann' initials='J.' surname='Heidemann'/>
    <author fullname='A. Mankin' initials='A.' surname='Mankin'/>
    <author fullname='D. Wessels' initials='D.' surname='Wessels'/>
    <author fullname='P. Hoffman' initials='P.' surname='Hoffman'/>
    <date month='May' year='2016'/>
    <abstract>
      <t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t>
      <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7858'/>
  <seriesInfo name='DOI' value='10.17487/RFC7858'/>
</reference>

<reference anchor='RFC8280' target='https://www.rfc-editor.org/info/rfc8280'>
  <front>
    <title>Research into Human Rights Protocol Considerations</title>
    <author fullname='N. ten Oever' initials='N.' surname='ten Oever'/>
    <author fullname='C. Cath' initials='C.' surname='Cath'/>
    <date month='October' year='2017'/>
    <abstract>
      <t>This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.</t>
      <t>This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8280'/>
  <seriesInfo name='DOI' value='10.17487/RFC8280'/>
</reference>

<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
    <author fullname='E. Rescorla' initials='E.' surname='Rescorla'/>
    <date month='August' year='2018'/>
    <abstract>
      <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
      <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8446'/>
  <seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>

<reference anchor='RFC8484' target='https://www.rfc-editor.org/info/rfc8484'>
  <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='RFC8980' target='https://www.rfc-editor.org/info/rfc8980'>
  <front>
    <title>Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development</title>
    <author fullname='J. Arkko' initials='J.' surname='Arkko'/>
    <author fullname='T. Hardie' initials='T.' surname='Hardie'/>
    <date month='February' year='2021'/>
    <abstract>
      <t>The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.</t>
      <t>Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8980'/>
  <seriesInfo name='DOI' value='10.17487/RFC8980'/>
</reference>

<reference anchor='RFC7754' target='https://www.rfc-editor.org/info/rfc7754'>
  <front>
    <title>Technical Considerations for Internet Service Blocking and Filtering</title>
    <author fullname='R. Barnes' initials='R.' surname='Barnes'/>
    <author fullname='A. Cooper' initials='A.' surname='Cooper'/>
    <author fullname='O. Kolkman' initials='O.' surname='Kolkman'/>
    <author fullname='D. Thaler' initials='D.' surname='Thaler'/>
    <author fullname='E. Nordmark' initials='E.' surname='Nordmark'/>
    <date month='March' year='2016'/>
    <abstract>
      <t>The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7754'/>
  <seriesInfo name='DOI' value='10.17487/RFC7754'/>
</reference>

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

<reference anchor='RFC9071' target='https://www.rfc-editor.org/info/rfc9071'>
  <front>
    <title>RTP-Mixer Formatting of Multiparty Real-Time Text</title>
    <author fullname='G. Hellström' initials='G.' surname='Hellström'/>
    <date month='July' year='2021'/>
    <abstract>
      <t>This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time Transport Protocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions.</t>
      <t>Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP-mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations.</t>
      <t>A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".</t>
      <t>This document updates RFC 4103 ("RTP Payload for Text Conversation").</t>
      <t>A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9071'/>
  <seriesInfo name='DOI' value='10.17487/RFC9071'/>
</reference>

    <displayreference target="I-D.pouwelse-censorfree-scenarios" to="Pouwelse"/>
    <displayreference target="I-D.ietf-madinas-mac-address-randomization" to="MAC-ADDRESS-RANDOMIZATION"/>
    <displayreference target="I-D.arkko-iab-internet-consolidation" to="Arkko"/>
    <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>

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

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1958.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1984.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2277.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3365.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3724.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3935.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8179.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4101.xml"/>
      <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.4949.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6108.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6365.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6701.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7725.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8280.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8980.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7754.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9071.xml"/>

      <reference anchor="UDHR" target="http://www.un.org/en/documents/udhr/"> target="https://www.un.org/en/about-us/universal-declaration-of-human-rights">
        <front>
    <title>The Universal
          <title>Universal Declaration of Human Rights</title>
    <author >
          <author>
            <organization>United Nations General Assembly</organization>
          </author>
          <date month="December" year="1948"/>
        </front>
      </reference>

      <reference anchor="Bless" > anchor="Orwat">
        <front>
          <title>Values and Networks</title>
    <author initials="R." surname="Bless">
      <organization></organization>
    </author> Networks: Steps Toward Exploring their Relationships</title>
          <author initials="C." surname="Orwat">
      <organization></organization>
            <organization/>
          </author>
          <author initials="R." surname="Bless">
            <organization/>
          </author>
          <date year="2015"/> month="May" year="2016"/>
        </front>
        <refcontent>ACM SIGCOMM Computer Communication Review, vol. 46, no. 2, pp 25-31</refcontent>
        <seriesInfo name="DOI" value="10.1145/2935634.2935640"/>
      </reference>

<reference anchor="Brown" > anchor="Ziewitz">
        <front>
          <title>A Prehistory of Internet Governance</title>
          <author initials="I." surname="Brown">
      <organization></organization>
    </author>
    <author initials="M." surname="Ziewitz">
      <organization></organization>
            <organization/>
          </author>
          <author initials="I." surname="Brown">
            <organization/>
          </author>
          <date month="April" year="2013"/>
        </front>
  <seriesInfo name="Research
        <refcontent>Research Handbook on Governance of the Internet. Cheltenham, Internet, edited by Ian Brown. Cheltenham: Edward Elgar" value=""/> Elgar Publishing</refcontent>
        <seriesInfo name="DOI" value="10.4337/9781849805025.00008"/>
      </reference>

      <reference anchor="notewell" target="https://www.ietf.org/about/note-well.html"> anchor="Note-well" target="https://www.ietf.org/about/note-well/">
        <front>
          <title>Note Well</title>
    <author >
          <author>
            <organization>IETF</organization>
          </author>
    <date year="2015"/>
        </front>
      </reference>

   <reference anchor="IRP" target="http://internetrightsandprinciples.org/site/wp-content/uploads/2014/06/IRPC_10RightsandPrinciples_28May2014-11.pdf"> target="https://internetrightsandprinciples.org/campaign/">
        <front>
          <title>10 Internet Rights &amp; Principles</title>
    <author >
          <author>
            <organization>Internet Rights and Principles Dynamic Coalition</organization>
          </author>
    <date year="2014"/>
        </front>
      </reference>

      <reference anchor="ICCPR" target="http://www.ohchr.org/EN/ProfessionalInterest/Pages/CCPR.aspx"> target="https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-civil-and-political-rights">
        <front>
          <title>International Covenant on Civil and Political Rights</title>
    <author >
          <author>
            <organization>United Nations General Assembly</organization>
          </author>
          <date year="1976"/> month="December" year="1966"/>
        </front>
      </reference>

      <reference anchor="Saltzer" > anchor="Saltzer">
        <front>
    <title>End-to-End Arguments
          <title>End-to-end arguments in System Design</title> system design</title>
          <author initials="J.H." initials="J. H." surname="Saltzer">
      <organization></organization>
            <organization/>
          </author>
          <author initials="D.P." initials="D. P." surname="Reed">
      <organization></organization>
            <organization/>
          </author>
          <author initials="D.D." initials="D. D." surname="Clark">
      <organization></organization>
            <organization/>
          </author>
          <date month="November" year="1984"/>
        </front>
  <seriesInfo name="ACM TOCS, Vol
        <refcontent>ACM Transactions on Computer Systems, vol. 2, Number no. 4, November 1984, pp 277-288." value=""/> 277-288</refcontent>
        <seriesInfo name="DOI" value="10.1145/357401.357402"/>
      </reference>

      <reference anchor="ICESCR" target="http://www.ohchr.org/EN/ProfessionalInterest/Pages/CESCR.aspx"> target="https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-economic-social-and-cultural-rights">
        <front>
          <title>International Covenant on Economic, Social and Cultural Rights</title>
    <author >
          <author>
            <organization>United Nations General Assembly</organization>
          </author>
          <date month="December" year="1966"/>
        </front>
      </reference>

<reference anchor="Penney" target="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2769645"> target="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2769645">
        <front>
          <title>Chilling Effects: Online Surveillance and Wikipedia Use</title>
          <author initials="J." surname="Penney">
      <organization></organization>
            <organization/>
          </author>
          <date month="September" year="2016"/>
        </front>
	<refcontent>Berkeley Technology Law Journal, vol. 31, no. 1, pp 117-182</refcontent>
        <seriesInfo name="DOI" value="10.15779/Z38SS13"/>
      </reference>

      <reference anchor="UNHRC2016" target="https://documents-dds-ny.un.org/doc/UNDOC/LTD/G16/131/89/PDF/G1613189.pdf?OpenElement"> target="https://digitallibrary.un.org/record/845728?ln=en">
        <front>
    <title>UN Human Rights Council Resolution "The
          <title>The promotion, protection and enjoyment of human rights on the Internet" (A/HRC/32/L.20)</title>
    <author > Internet</title>
          <author>
            <organization>United Nations Human Rights Council</organization>
          </author>
          <date month="June" year="2016"/>
        </front>
</reference>
<reference anchor="geekfeminism" target="http://geekfeminism.wikia.com/wiki/Pseudonymity">
  <front>
    <title>Pseudonymity</title>
    <author >
      <organization>Geek Feminism Wiki</organization>
    </author>
    <date year="2015"/>
  </front>
	<refcontent>A/HRC/32/L.20</refcontent>
      </reference>

      <reference anchor="W3Ci18nDef" target="http://www.w3.org/International/questions/qa-i18n.en"> target="https://www.w3.org/International/questions/qa-i18n.en">
        <front>
          <title>Localization vs. Internationalization</title>
          <author > initials="R" surname="Ishida">
            <organization>W3C</organization>
          </author>
    <date year="2010"/>
  </front>
</reference>
<reference anchor="BCP72" target="https://datatracker.ietf.org/doc/bcp72/">
  <front>
    <title>Guidelines for Writing RFC Text on Security Considerations</title>
    <author >
      <organization>IETF</organization>
    </author>
    <date year="2003"/>
  </front>
</reference>
<reference anchor="BCP9" target="https://datatracker.ietf.org/doc/rfc2026/">
  <front>
    <title>The Internet Standards Process -- Revision 3</title>
    <author initials="S." surname="Bradner">
      <organization></organization>
    </author>
	  <author >
      <organization>IETF</organization> initials="S" surname="Miller">
	    <organization>Boeing</organization>
	  </author>
          <date year="1996"/> month="December" year="2005"/>
        </front>
      </reference>

      <reference anchor="patentpolicy" anchor="Patent-policy" target="https://www.w3.org/Consortium/Patent-Policy-20040205/">
        <front>
          <title>W3C Patent Policy</title>
          <author > initials="D" surname="Weitzner">
            <organization>W3C</organization>
          </author>
          <date month="February" year="2004"/>
        </front>
	<refcontent>W3C Recommendation</refcontent>
      </reference>

<!-- [I-D.pouwelse-censorfree-scenarios] IESG state: Expired Long way used to include editor role-->
<reference anchor="Pouwelse" target="https://tools.ietf.org/html/draft-pouwelse-censorfree-scenarios"> anchor="I-D.pouwelse-censorfree-scenarios" target="https://datatracker.ietf.org/doc/html/draft-pouwelse-censorfree-scenarios-02">
<front>
<title>Media without censorship</title> censorship (CensorFree) scenarios</title>
<author initials="J." surname="Pouwelse, Ed">
      <organization></organization> surname="Pouwelse" fullname="Johan Pouwelse" role="editor">
<organization>Delft University of Technology</organization>
</author>
<date month="October" day="22" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-pouwelse-censorfree-scenarios-02"/>
</reference>

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

<!-- [I-D.ietf-madinas-mac-address-randomization] IESG state: RFC Ed Queue Long way used to include editor role-->
<reference anchor="draft-irtf-pearg-censorship" target="https://tools.ietf.org/html/draft-irtf-pearg-censorship"> anchor="I-D.ietf-madinas-mac-address-randomization" target="https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-15">
<front>
    <title>A Survey
<title>Randomized and Changing MAC Address State of Worldwide Censorship Techniques</title>
    <author initials="J." surname="Hall">
      <organization></organization>
    </author>
    <author initials="M." surname="Aaron">
      <organization></organization>
    </author>
    <author initials="S." surname="Adams">
      <organization></organization>
    </author>
    <author initials="B." surname="Jones">
      <organization></organization>
    </author>
    <author initials="N." surname="Feamster">
      <organization></organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="draft-ietf-ohai-ohttp" target="https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp">
  <front>
    <title>Oblivious DNS Over HTTPS</title>
    <author initials="M." surname="Thomson">
      <organization></organization>
    </author>
    <author initials="C.A." surname="Wood">
      <organization></organization>
    </author>
    <date year="2023"/>
  </front>
</reference>
<reference anchor="draft-zuniga-mac-address-randomization" target="https://tools.ietf.org/html/draft-ietf-madinas-mac-address-randomization">
  <front>
    <title>MAC address randomization</title>
    <author initials="J.C." surname="Zuniga">
      <organization></organization>
    </author> Affairs</title>
<author initials="C.J." surname="Bernardos">
      <organization></organization> initials="J. C." surname="Zúñiga" fullname="Juan-Carlos Zúñiga">
<organization>CISCO</organization>
</author>
<author initials="C. J." surname="Bernardos" fullname="Carlos J. Bernardos" role="editor">
<organization>Universidad Carlos III de Madrid</organization>
</author>
<author initials="A." surname="Andersdotter">
      <organization></organization> surname="Andersdotter" fullname="Amelia Andersdotter">
<organization>Safespring AB</organization>
</author>
<date year="2020"/> month="July" day="15" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-madinas-mac-address-randomization-15"/>
</reference>

      <reference anchor="HTML5" target="https://www.w3.org/TR/html5/"> anchor="HTML" target="https://html.spec.whatwg.org/multipage/">
        <front>
    <title>HTML5</title>
    <author >
      <organization>W3C</organization>
          <title>HTML Living Standard</title>
          <author>
            <organization>WHATWG</organization>
          </author>
          <date year="2014"/> month="August" year="2024"/>
        </front>
      </reference>

      <reference anchor="Zittrain" target="https://dash.harvard.edu/bitstream/handle/1/4455262/Zittrain_Future%20of%20the%20Internet.pdf?sequence=1"> target="https://dash.harvard.edu/handle/1/4455262">
        <front>
          <title>The Future of the Internet - And and How to Stop It</title>
          <author initials="J." surname="Zittrain">
      <organization></organization>
            <organization/>
          </author>
          <date year="2008"/>
        </front>
  <seriesInfo name="Yale
        <refcontent>Yale University Press" value=""/> Press</refcontent>
      </reference>

      <reference anchor="FIArch" target="http://www.future-internet.eu/uploads/media/FIArch_Design_Principles_V1.0.pdf"> target="https://link.springer.com/chapter/10.1007/978-3-642-30241-1_6">
        <front>
    <title>Future
          <title>Design Principles for the Future Internet Design Principles</title> Architecture</title>
          <author surname="Papadimitriou" initials="D."/>
          <author surname="Zahariadis" initials="T."/>
          <author surname="Martinez-Julia" initials="P."/>
          <author surname="Papafili" initials="I."/>
          <author surname="Morreale" initials="V."/>
          <author surname="Torelli" initials="F."/>
          <author >
      <organization></organization> surname="Sales" initials="B."/>
          <author surname="Demeester" initials="P.">
          </author>
          <date year="2012" month="January"/>
        </front>
	<refcontent>The Future Internet, pp. 55-67</refcontent>
	<seriesInfo name="DOI" value="10.1007/978-3-642-30241-1_6"/>
      </reference>

      <reference anchor="W3CAccessibility" target="https://www.w3.org/standards/webdesign/accessibility">
        <front>
          <title>Accessibility</title>
    <author >
          <author>
            <organization>W3C</organization>
          </author>
    <date year="2015"/>
        </front>
      </reference>

      <reference anchor="newegg" target="http://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/"> anchor="Newegg" target="https://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/">
        <front>
          <title>Newegg on trial: Mystery company TQP rewrites the history of encryption</title>
          <author initials="J." surname="Mullin">
      <organization></organization>
            <organization/>
          </author>
          <date month="November" year="2013"/>
        </front>
        <refcontent>Ars Technica</refcontent>
      </reference>

      <reference anchor="Hill2014" anchor="Hill" target="http://www.apig.ch/UNIGE%20Catalog.pdf">
        <front>
          <title>Partial Catalog of Human Rights Related to ICT Activities</title>
          <author initials="R." surname="Hill">
      <organization></organization>
            <organization>Association for Proper Internet Governance (APIG)</organization>
          </author>
          <date month="May" year="2014"/>
        </front>
      </reference>

      <reference anchor="Kaye" target="https://www.ohchr.org/EN/HRbodies/HRC/RegularSessions/Session29/Documents/A.HRC.29.32_AEV.doc"> target="https://digitallibrary.un.org/record/798709?v=pdf">
        <front>
    <title>The use
          <title>Report of encryption the Special Rapporteur on the Promotion and anonymity in digital communications</title> Protection of the Right to Freedom of Opinion and Expression, David Kaye</title>
          <author initials="D." surname="Kaye">
      <organization></organization>
            <organization/>
          </author>
          <date month="May" year="2015"/>
        </front>
        <refcontent>A/HRC/29/32</refcontent>
      </reference>

      <reference anchor="UNGP" target="https://www.ohchr.org/documents/publications/guidingprinciplesbusinesshr_en.pdf"> target="https://www.ohchr.org/en/publications/reference-publications/guiding-principles-business-and-human-rights">
        <front>
    <title>United Nations Guiding
          <title>Guiding Principles on Business and Human Rights</title>
    <author > Rights: Implementing the United Nations 'Protect, Respect and Remedy' Framework</title>
          <author>
            <organization>United Nations</organization>
          </author>
          <date year="2011"/> year="2012" month="January"/>
        </front>
      </reference>

      <reference anchor="UNHR" target="https://www.ohchr.org/en/professionalinterest/pages/coreinstruments.aspx"> target="https://www.ohchr.org/en/core-international-human-rights-instruments-and-their-monitoring-bodies">
        <front>
          <title>The Core International Human Rights Instruments and their monitoring bodies</title>
    <author >
          <author>
            <organization>United Nations</organization>
          </author>
    <date year="2011"/>
        </front>
      </reference>

      <reference anchor="HR-RT" target="https://github.com/IRTF-HRPC/reviews">
        <front>
    <title>Human Rights Reviews</title>
    <author >
      <organization></organization>
    </author>
    <date year="2022"/>
  </front>
</reference>
<reference anchor="arkkoetal" target="https://datatracker.ietf.org/doc/html/draft-arkko-iab-internet-consolidation-02">
  <front>
    <title>Considerations on Internet Consolidation and the Internet Architecture</title>
    <author initials="J." surname="Arkko">
      <organization></organization>
    </author>
    <author initials="B." surname="Trammell">
      <organization></organization>
    </author>
    <author initials="M." surname="Notthingham">
      <organization></organization>
    </author>
    <author initials="C." surname="Huitema">
      <organization></organization>
    </author>
    <author initials="M." surname="Thomson">
      <organization></organization>
    </author>
    <author initials="J." surname="Tantsure">
      <organization></organization>
    </author>
    <author initials="N." surname="ten Oever">
      <organization></organization>
          <title>IRTF-HRPC / reviews</title>
          <author>
            <organization/>
          </author>
          <date year="2019"/> month="December" year="2020"/>
        </front>
        <refcontent>commit 3f5fbff</refcontent>
      </reference>

<!-- [I-D.arkko-iab-internet-consolidation] IESG state: Expired -->
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-arkko-iab-internet-consolidation.xml"/>

      <reference anchor="FREAK" target="https://web.archive.org/web/20150304002021/https://freakattack.com/">
        <front>
          <title>Tracking the FREAK Attack</title>
    <author >
      <organization></organization>
          <author>
            <organization>University of Michigan</organization>
          </author>
          <date month="March" year="2015"/>
        </front>
      <refcontent>Wayback Machine archive</refcontent>
      </reference>

      <reference anchor="Logjam" target="https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf"> anchor="Logjam">
        <front>
          <title>Imperfect Forward Secrecy, Secrecy: How Diffie-Hellman Fails in Practice</title>
          <author initials="D." surname="Adrian">
      <organization></organization>
            <organization/>
          </author>
          <author initials="K." surname="Bhargavan">
      <organization></organization>
            <organization/>
          </author>
          <author initials="Z." surname="Durumeric">
            <organization/>
	  </author>
          <author initials="P." surname="Gaudry">
            <organization/>
	  </author>
          <author initials="M." surname="Green">
            <organization/>
	  </author>
          <author initials="." surname="et al">
      <organization></organization> initials="J." surname="Halderman">
            <organization/>
          </author>
          <author initials="N." surname="Heninger">
            <organization/>
          </author>
          <author initials="D." surname="Springall">
            <organization/>
          </author>
          <author initials="E." surname="Thomé">
            <organization/>
          </author>
          <author initials="L." surname="Valenta">
            <organization/>
          </author>
          <author initials="B." surname="VanderSloot">
            <organization/>
          </author>
          <author initials="E." surname="Wustrow">
            <organization/>
          </author>
          <author initials="S." surname="Zanella-Béguelin">
            <organization/>
          </author>
          <author initials="P." surname="Zimmerman">
            <organization/>
          </author>
          <date month="October" year="2015"/>
        </front>
        <refcontent>CCS '15: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp 5-17</refcontent>
        <seriesInfo name="DOI" value="10.1145/2810103.2813707"/>
      </reference>

      <reference anchor="hecate" target="https://eprint.iacr.org/2021/1686"> anchor="Hecate" target="https://www.usenix.org/conference/usenixsecurity22/presentation/issa">
        <front>
          <title>Hecate, Abuse Reporting in Secure Messengers with Sealed Sender</title>
          <author initials="R." surname="Issa">
      <organization></organization>
            <organization/>
          </author>
          <author initials="N." surname="Alhaddad">
      <organization></organization>
            <organization/>
          </author>
          <author initials="M." surname="Varia">
      <organization></organization>
            <organization/>
          </author>
          <date year="2022"/> year="2022" month="August"/>
        </front>
	<refcontent>31st USENIX Security Symposium (USENIX Security 22), pp 2335-2352</refcontent>
      </reference>

      <reference anchor="messenger-franking" anchor="Messenger-franking" target="https://eprint.iacr.org/2017/664">
        <front>
          <title>Message Franking via Committing Authenticated Encryption</title>
          <author initials="P." surname="Grubbs">
      <organization></organization>
            <organization/>
          </author>
          <author initials="J." surname="Lu">
      <organization></organization>
            <organization/>
          </author>
          <author initials="T." surname="Ristenpart">
      <organization></organization>
            <organization/>
          </author>
          <date year="2017"/> year="2017" month="July"/>
        </front>
	<refcontent>Cryptology ePrint Archive, Paper 2017/664</refcontent>
      </reference>

      <reference anchor="email-hashing" anchor="Email-hashing" target="https://freedom-to-tinker.com/2018/04/09/four-cents-to-deanonymize-companies-reverse-hashed-email-addresses/">
        <front>
          <title>Four cents to deanonymize: Companies reverse hashed email addresses</title>
          <author initials="G." surname="Acar">
      <organization></organization>
            <organization/>
          </author>
          <author initials="S." surname="Englehardt">
      <organization></organization>
            <organization/>
          </author>
          <author initials="A." surname="Narayanan">
      <organization></organization>
            <organization/>
          </author>
          <date year="n.d."/> month="April" year="2018"/>
        </front>
      </reference>

      <reference anchor="https-interception" > anchor="HTTPS-interception">
        <front>
          <title>The Security Impact of HTTPS Interception</title>
          <author initials="Z." surname="Durumeric">
      <organization></organization>
            <organization/>
          </author>
          <author initials="Z." surname="Ma">
      <organization></organization>
            <organization/>
          </author>
          <author initials="D." surname="Springall">
      <organization></organization>
            <organization/>
          </author>
          <author initials="R." surname="Barnes">
      <organization></organization>
            <organization/>
          </author>
          <author initials="N." surname="Sullivan">
      <organization></organization>
            <organization/>
          </author>
          <author initials="E." surname="Bursztein">
      <organization></organization>
            <organization/>
          </author>
          <author initials="M." surname="Bailey">
      <organization></organization>
            <organization/>
          </author>
          <author initials="J." surname="Halderman">
      <organization></organization>
            <organization/>
          </author>
          <author initials="V." surname="Paxson">
      <organization></organization>
            <organization/>
          </author>
          <date month="February" year="2017"/>
        </front>
</reference>
        <refcontent>NDSS Symposium 2017</refcontent>
        <seriesInfo name="DOI" value="10.14722/ndss.2017.23456"/>
      </reference>

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

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

      <reference anchor="I-D.ietf-mls-protocol" target="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/"> anchor="Jorgensen">
        <front>
    <title>The Messaging Layer Security (MLS) Protocol</title>
    <author initials="R." surname="Barnes">
      <organization></organization>
    </author>
    <author initials="B." surname="Beurdouche">
      <organization></organization>
    </author>
    <author initials="R." surname="Robert">
      <organization></organization>
    </author>
    <author initials="J." surname="Millican">
      <organization></organization>
    </author>
    <author initials="E." surname="Omara">
      <organization></organization>
    </author>
          <title>An internet bill of rights</title>
          <author initials="K." surname="Cohn-Gordon">
      <organization></organization> initials="R. F." surname="Jørgensen">
            <organization/>
          </author>
          <date year="2023"/> month="April" year="2013"/>
        </front>
</reference>

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

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

<reference anchor='RFC7301' target='https://www.rfc-editor.org/info/rfc7301'>
  <front>
    <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
    <author fullname='S. Friedl' initials='S.' surname='Friedl'/>
    <author fullname='A. Popov' initials='A.' surname='Popov'/>
    <author fullname='A. Langley' initials='A.' surname='Langley'/>
    <author fullname='E. Stephan' initials='E.' surname='Stephan'/>
    <date month='July' year='2014'/>
    <abstract>
      <t>This document describes a Transport Layer Security (TLS) extension
    </references>

    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to:</t>
      <ul spacing="normal">
        <li><t><contact fullname="Corinne Cath-Speth"/> for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported work on <xref
        target="RFC8280" format="default"/>.</t></li>
        <li><t><contact fullname="Reese Enghardt"/>, <contact fullname="Joe
        Hall"/>, <contact fullname="Avri Doria"/>, <contact fullname="Joey
        Salazar"/>, <contact fullname="Corinne Cath-Speth"/>, <contact
        fullname="Farzaneh Badii"/>, <contact fullname="Sandra Braman"/>,
        <contact fullname="Colin Perkins"/>, <contact fullname="John
        Curran"/>, <contact fullname="Eliot Lear"/>, <contact
        fullname="Mallory Knodel"/>, <contact fullname="Brian Trammell"/>,
        <contact fullname="Jane Coffin"/>, <contact fullname="Eric
        Rescorla"/>, <contact fullname="Sofía Celi"/>, and the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7301'/>
  <seriesInfo name='DOI' value='10.17487/RFC7301'/>
</reference>

<reference anchor='I-D.ietf-tls-esni' target='https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-17'>
   <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) hrpc list for encrypting a ClientHello message under a server public key.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source
        reviews and suggestions.</t></li>
        <li><t>Individuals who conducted human rights reviews for this draft their work
        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>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-tls-esni-17'/>

</reference>

    </references> feedback: <contact fullname="Amelia Andersdotter"/>, <contact
        fullname="Shane Kerr"/>, <contact fullname="Beatrice Martini"/>,
        <contact fullname="Karan Saini"/>, and <contact fullname="Shivan Kaul
        Sahib"/>.</t></li>
      </ul>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAJDpyWUAA+2963IbWZIm+B9PEca2XZG9AHjTvbpaTVFSilUpJVtklmy6
piztAHEARCoQgYoIkELKZFbvsL/WbOYR9in2TepJ1j93P7cAKCmzu3dn16Zt
JosCAifOxY9fP3cfjUaDruhK+zT7bl3ktiwq22azusler5emyt4V80XXZpdN
3dXTusxMlWdnzXRRdHbarRubnddVS79rTFfQXwMzmTT2Znuwd5fng7yeVmZJ
b8obM+tGRdPNRotmNR3N/cOjk+PB1HR2Xjebp1lRzerBepXTB+3T7PHJ46PB
oFg1T7OuWbfdydHRk6OTgWmseZpdvLt+Nbitmw/zpl6vnt4x+3Sy2TvbWkOL
yb7DjwYf7IZGyGmwqrNNZbvRC0x00Ha06p9MWVc0941tB6vi6SDLmtnU5m23
KfXTLKOXRH8WVW6rzn3Q1k3X2Fnr/71ZJv/smmLqH57WyyX91n9bVNgdP7b9
2I3Kou1GNMikLumxUf2P/9vArLtF3TwdjOgZ/r+ioq++G2N5N7Zxn8oZfLdu
2oWZmLz3rV2aonyazd3X/zIt2hEtpTDjupn3xn47pslU2Q92a/i3hS3b7S9p
CFMVv/D+P81+rAr6ri26TVbPsrNlS9uem2VvKvjvv1QYj4arMdqYzmYwqOpm
SQPd2KdEFUQp7l8Zfo///+7V+dGjJ6dP9e/jo9MH/u8nDx6Hvx/fd3+fHJ08
9H+fPHrk/j49feh/e/roxD9/+iSM+fj40RP39/2jU//e+8dHx/7vJ/fjv/3z
D05P/OcPHt73c3h4fOTn+fAkvOthNJ+Hj8L4D5888u99dBLW+OhhmPMj+sL/
/fh++PxxeB53zf99P8zn8f2wV4+fhGfifXj06IF/5snR0VH4+xHNE//48cXr
d0/llJX3XC+sowZTZi/stDRySUEY8V2WX4EjPM2On9x/LP92lK+Ek41AaExf
nc2zt3rdv7MVXf0yO2tbu5yUG52BaeaWbt6i61ZPDw9vb2/H6wq0fmirQ2JZ
a76Jh+t80Rzy7J+Xtm3du3T+fzLlmlgduONb24EP6Ux1qidHxw/0g+258lV6
N5aB+5+fj7MfmlvTyaub+rZKd+6MuJtdEDMgjonNcrwr+w63ujLV1A7SiZze
tWf8vouxvKX/+Ztx9m+FvS26X+Sb1jaFbXHvngY++po2YFLXHzI6uPB+TKuj
A3ZTG2fnC1vSZV6Y5TB7md+aJs9elnPT8CKrurO3tizlIvuFvqWPs/f0eW85
D75IAhcvSS5snXOrB13YbsZHbSb1ujvEm0d49XjRLUuezMW7y3S/946Pwh6r
fPlf6QyKalqs6AD3etO7/8XpbQ0FCgqDZS82xE6LKQkuUxag4p00W+ggDY9B
Q6z8CLw64rD28HY1mtb0YNUdrldlbfL2ENM7PHp4SIs8/+n46J37eZjATyeP
35gNnhsdH49X+Uw25fz8sneBZR180Qzk7I2lo+9AB+fFTSF6w2WNNUzp+113
+dHD3Tv177rJ9WK6aHgPXr49JDVgRjeMp8jztW13eGnmtj3EgsamXX3k9V2Z
svvFNukKX1b5qKtHL1kBmgtXoKuRXW1ILi2JZ7XFvPri1frDOHs9doP3v3wx
zi7HdJNsvuMb+n/nxBE/bF+9s/M32fUP51fD7E+k35wMs7fr5cQ22X36iw4B
f/vxIOiG2WqVkWAbnTx+PE4P4PF9PdyXV+fffLoviaZqotBhdkUaj5GDPl+X
pBvecc4P7zjnfyfP/uaTxurCUV/aqrKb3hU/XxQlKVzz7OVsRmouncEPrIBl
V+vmxtJ3zNWw0vfFh2JlSTnKfmxt/+rfuVBHDfLynUtamRXJwnHbNtWYtMHD
ti5P3YfT2fKZmZDGaKbdT0X++5NHD588vP9AROvb1+/O8e50ST++TTXi83pN
N7wE567LNQvaPcjgVVMva/xziD+h4+MrrNRWP9cbED24+YLHEnYDKoi5+162
f3ZIkzg8PTn8fnxydPCtu7Lr+HdNejc795J6lOftqNo4IU6fH/749sUP54ff
X784/O744eHx6fHh4yeHly9e4Z/0r8dPwNme/bCy1cvSYhDeyrm1H2Z2WVRF
u0x387K167yuNkvSXL8ojbL+8r6jMbNXOihTT7bz+ON3j2/pMcNUgL8Ok7fj
1+9Pz4vjx9ULO0un+X1NvFaV7eymHafXWL/ozf/oi6dDb7rzAt6e8n4n7zj8
K2lFfJKHfzUjTHJsK9Fkzi8fnaTT7ZmM7xsSFnQHSXPMrsniAZ1d2em6gbnQ
szqTNRydfvkM7lYJaASDW/WBTAyvGoCAJtPVo5NDN/En27qrF+NXsBVJn2Gj
c0o8KBuN6JbdFGBG2WnKCp88vHOmzCKuoIuZvEqkxW9dA5mrsG5kFSsDRWBF
AnnaY350xNklf8vyetoj8KMv6zM7CaRNKQRnR8ZwsV4eyotG8qIRRj86OXog
U7ys16SKtTad3htmtqSGLkhhy6YWQ7WLYtUj45Ovsl4dHfrnePeUu5pM67CH
UAkPxXOx0h+P5P2zxtpRS3+bpqhbnnzk4ViRajwfhZn21XeWKay6v6+bMr8l
ss7O/dNE+tNFVeAepUs8ufOmel3DOF05i7X4M9PUW9o9UdoZWd5b1sfzcfaH
urJbn5Ph/8oaNth/7ebt3JR40+g3o3phCvoPuEuyXT9MSlIn6zVpxm+vsh/I
wsheX19fXvX25ssmDm3C9aJettvbQMbW2ZjOoc5/5eWK15fOP1rZL+uqmJvR
0kxHJs9JJ2lHDXELUp/UIZJS+tl5po9lyWO/lg5oUf/Gb96xWvr6Odh1k9db
Z0w7cVYRj23zuvst54x9WJq8qEx795p5e15fv/n+Qbp6/uiLptQWX/8W3nP9
jqeoLObfio5Os3AbHzP0V2v2bvYsV3oVbUn2ur7Nupp4fb3KLrqeoX/0+MuG
/h/G/r3utVtU1i7GC9Pc0LGMbb4+nBQdaXt03w4XtHelPTw+vH//wYOThyeH
bqifZML/y8lRPaP/0KTpv97ghnrTWmIipLf+/lhfG5sR/8WUNnbHXeKkeI9e
XcDdmx6Obo7fFbF9Irs1Prg/mGptmk3ElXcoDzMeceQM2bFdeyN1CY5/KNP4
Sd70U2Sg/ul4fOQNUyKBsymkbjEpyNbsibbkq1/lRfgW0mqd5D+8tZOc53lo
kjdiiMre2vm8Z2+85Q9ZkW7IhqK7D5uS9ox0vpWpNtn1v15mjb0l1YeUIxBk
5PChM202K9ylvv1xtx7kCPHNGnbOzlMxDU0Bomcqqif+MRKFAX6D08Pj40NZ
zKiuRjzv0VKmPdJpj7q/rkZ0qjLvEc17pPMe1bNRmLdcxtdkV+GS9/bm0pCq
AKOTWG9Zz/v+QNKtSgOLge7jxfk1nXFHAqIrfoUjxrnfMIHd2jhO2ayK+Xi6
IFvi4ruXdLd0Pkx64m7+o9nYbc1w3dr0lNiaMpUq8PAg5MW8oMHY67/Ghu9Q
au8mUOcjwOvvJtLEPH79blLntEVspr2z83Vpmiuxl9tD/ePkyeEL7/w8G9OT
45Mn49OTn85e/mlMIk9eJSbndz0fWd+GJ8Uemnzk16JteL5uoeuLy+suFy8t
/PhX2Ivfsv7g0l2tSZvQ3T6cyySD52yi81s0P9nKcxjY19uHfF57duicJAmR
XlTEv9VlhOXSVSiabFnT5OsGWyPn8Z+8clsdriLHSOEcIyt2jExpDUWYp7hI
9Ihfvxu9u+4J6PQS3hT2tq+h7mD3mBQR+2I9YaaCqN0IscHDJh4B/zXNhw+1
pWuRvrYXwSM68lKI7YqyyI2/ZYnojqOWvY1+8jUV6gyT2aEbXzdmubQ71ey3
pDQt6GgXIZ4V6V2v1zSV5ZZGdrdmSpO4NnQsfvJZrIv34my/RW3l/R4VZuKF
MNzFYUNHRyeiD7x7efbH3g3A0KBi7Dd/n511HX22m4VtEamdjBE9IOWDJ0b/
hoR5cHRK5iDptyfHh+5RsrTMB8NjM/3wjL6v5z+bnofmYrmyDXx32au64fjC
lZ02droZsvL2opjNCjt6TUcHKn5lipJ9uZdwqRVbEZOv8t6znOTf1pn9kZRr
UuPm5mb7OyJIU95heN7SIvMF70Xh1jGayTpGraxjNJ22xw88W1pYRM17N5Q/
G2ZnE8igd3YFo5tOqVA/iiVjum1tNSedjy1q+pjUQGwV1P7dl/lu8XnRtlv0
TKR5Vi5I8TdbXm0i9T+RvWx2b4EFH+7GhZkK62IqOH74+CGvdunmPZqRMQHS
6zsJaC5zokX9NrspDLGHJQlc3oEzWgTxOPB+Wu5LL5p7x/7oi0u+RFx9PZls
2U10Vb9f9z+8HhOvRAB7RfrMDi1j96KPHx0+fChueQ6GjxZkGmwt996ret3A
F0KcmNSg3Kp28QvzS6hiJFtIf4RyT6ojDUGr5vGcgWnbe19c63d0jlOzFbO4
GtPmzUtLRJ53/S/JfHxrGrMxldmhYepttmQJIqpCxwLmhDtNq358eHT/8OjJ
4YzWNeJ14ZloXaph0rJGuqyRLGsk2+SXJRyCXyh8bWpX26Y2RLh3LRLrICbA
eiY8CyJA9GdfJJAtBfvfxtmLNcRpU0x3fPdm67oQJ7kCDcx3eG4QHzbNblfM
FdT4HUzmJf1m3bS/dLbYFc99Tlvlwg8J+b42JTGA5faAfxpnl+ZjLJ7wx8Xo
xVis/bIdrRRrs73Dcitx/74nVbUJO77/5vurAw/S6fGdL7ty7tyV53BsrJu8
Xk8XWxKTfvWunthmi2ZhEiH0M925lz8siZ53MPnzelGNvqvpZXcQ+p3yN/aU
RHtHVDsajTIX4xkMrsluypziSoY7XfR56i1PIjLTVEnC9zldk7JeMauvG2aK
pCRVglXI3ItFOzWRptQOs7ZYFmQggLVAwPMPaKnWBX56MyECvjHTTX8Snz4p
POXzZyg5tJ4Cb8sE3pVn7HkQvMeOQb+0PJJnPDgwKxi8v130d1V3eNcOLz3r
Llm7stNiprbA77KCf8TmAfNKzMAjjFi7X62bVU38ZawvS7/1ryamxLO1VbvW
3Qk2RzZr6mWqo3ogxbVpP0B1mdpsH0ryQaxvfx3Ptg+d+kBgbSSZZSITS1qi
6Nk2H8LVgP9hPZmsAFrmZEN2CKkB9L+YVeNGY0hdRiMAGoH/pQfclyAoDLFi
zQnTwCe8snrdYXI7xhozP+iPP/1Q1bekf8zZx2E6/uGaPZA4LiZZIY7Cs2i/
c3dTMMi0rad0yTZMcu4qYLyV6nv8I/6SDDH2qvjJ8Uzoq7aDewDWuvwc5zuW
e7os8ry0gwFNpqnzNcdMB7+P/q9PkbQzQtoGd3kroOrWsuse++/CheYDps9v
6NE28xG3jDQkegmOo13U65J2hWiKtm/Z2vKGnrwlHSjeDBD5ksfhnXH7WfCe
b7JbRPyJB4QTyRbwg7Ipm9P9YfdBRqwzW9UI6xQkxeDfmJXsd+STsx9Jlhbi
EvlSEJnXpNOeWIYE5YEowvmbaLNMhWtOFoul19KPcktngdsLYizoHeKUG2aT
dcf/XrOSyEe/XEngVy6m26+yrTFQ263JOmcXE245vXRGAje8OVmIzs1A+2iZ
SJgh2ehgDBHlxLQ0oq7aExuUfXqD3EV8800wVr3tvft0uyjob3/xHfFhbDuD
v4LGp4NIaax3M2nGRpigXslkqQ273rAt3vepvEBpR7hLPZsxl2D/FiLR9dRM
4HLii+acjEztULP0TYFukndGZEeT3/Fj0N8Ey1pOiPr50MB9eb1KPp5pNNAW
KxZDtsJCifBtdVM0dcX3tC95xtl7mElk19PSMBIAVaSjtkKKy5pEVixtMd43
3WycUmc+WJCeWdnxDhFGgxBHC6DInpDkxenaSW0GTffEIg52aUmLyoWT0BSY
V/XnqJ6YbP9K0R+n45MDOclfIZSjX58eYC5dsiC+ApZ9BiJ7MB7Rk70BtIbe
NiXd0MBcx3tvTFnkpCmOaUXsivr8WXyrfeFwu0WjeBG9OLlu3wQ0pVcBpkpv
wgza9UTiJ0RBjTXwL8uW/1yTWUH8hhkDBncCpEi8gcmcSnOL0d9i9K2jzmsr
+opydBZYHTR1omXzEWirjTt/Gl6DVPue5R6k77op6lKOZAiGT78i6iwaeEZY
qZG/h1lZV/MRzXiJj4n/NR3/a0hmZUNvryLSXdQkMVuSelBFVuAVYHIX9AhM
24mdGvgbOlXxFvRYydogw9Zzu7KMi5eTLeRXw/RngUyKJZu0YS9UYtOWquQM
NDmGawfW4JD4c8Mr9YzMEeCssMTYb5m953ZWwIfK0qKif3SxlpyIBUjZ/6lW
/g+uT0IK/v9DqRy8jq9wtwDHaRONMtYs+VtnnX2rggUBafHmJeKLoDK6P5fJ
eoNQX5oNnbjwBhaUeghMNdCKxJHDca6P4AgtIwh3fR9RdPRAVVejvGinDZma
Vf9L4rumjOCI0VfgHcW0AJoJa5k63GlZzCBEGlUYWjooFiu7ZmQUWSpn3OJU
+zNQk3bogwr+m1Z9GIBK0NbkI+JhDTHaGqdLbA5qowSB8bTjpfTMDfNQEcMM
tsIeT0Casr11hv0oiRkQC0dwMNq4jNHqPJGlKR25qRIyZ9i9mBlNVjMbFOeJ
TBM6Zktj0BxZ+4tDjiwtNSpFE9cpreBiY8URmk3RtmuTO7VayU2d/2QI3LHD
blMxRO/QVh4VvhLEnIXsFWgs9BYSLAZOh7YbTUmKZw5oNYyuJ9+n0poPyTZB
HaIPWQdcLTYtvyQ3cBxjI+jeIImqmNIqDDg9H5GyPpwfG0gQkSR7iARbbN3U
ku4AOnHX0l08ui20Hmwg6Qo/E6WK7kk7CX4xpHd0jRn9TJYEw6Q/KMKYlUUW
3dgcuaOkrBRt77Jkc4OjFK6q75oTUYsiQrxuvhCCCDFFGsD5d+jVM5JD274R
Fd/EiSA4aV66Ffx60bP9KhN2QrOyiPkXv9ht243fIb8UpZjDDhBn7arQNUT+
IASG2WV0vm3ven51GYwKsWxirc5dQ/dSQ+KSzrvVqYjaK7yY90P0mXnjws80
n6qmxwzuQOZCRx4ajYmIQbetLRftB3ZB3SE0Ws4OoImcu7uvOkE6jNtmVldV
KSuDD83md72iFa1LZZjfhy3nG+NtP38W4/frLrqM1XE2BEg35GAVPH5ftnSZ
aGLjjxZT2YJZkBMmRC857XUT6VY5yPINxJDuwlCFTKMGpOwxRisRJsiFO8Kq
BAk708z5FNkJQHpUI2ypmGWYOawrnBP9lPgxGUjdDoNWdp82WSxb0mb4X1s6
KzhCW9AMSeW0uNwLp3je2nsNuyuYfa+FYEzZMwCcssv6Y/9LTEItIWakCeOn
1ycsWyzguqznYAT7F+fXLVtbc02bSMzxnlRX3buYwhYHiSD97PPnp5IJsGRi
JeM25G/dSJJbX7Mo2uj6O131ORSbvknl1B5Eb2q+urPfZJDBWJGI5faLvy31
iAbjJCY17748zLfkuPCASC1RkYURS5aFtAzHXCG/2kTDDAhYcSh8Q57GydHh
4+yWLr7J61UnnAHYOiJO4vHNUmQxbfTf//bfmCeYpQ1shj5f2RrCbmFucLIz
TmxZrtvO+7tU1WLWim/Hf//bf1eDlVNLaNMu+J0PZNLnpBvSerYOrJfLBi6a
qKC0Ze8uaTAsxlleudx4on/wdoQdp3XDarrIWbo1HsAzJPpc2lRk9fxTcotY
kJxfO2bMV0yezIt5xSGos4bk1jFnph4Md+ij+gQ8IW4va1UzywKhJNEfPQOW
x0/p8UgRgn3g82m8ouxe/iR9+C691M3kKJnKtpJc2jl90hCPzUlznRlSzhil
N8zytXW61pA1gPWSyaiqEWvV8R/9/W//+/ExHD8repa4KVSONtB/6t+gMyIC
0Jk9pl8FJQ9TBqthCxU0SjNp3aPHux7tqfFRIpLyi2XteJtTQzIHZsKpt/R7
UAxrqJArrP93kLo4LXjR4HtsYCCIArjyfnvxIkG/+K9/Zrc30cp//Qu/VbRo
N/NH6hNzslQP8eRgvAclW1GL04Ba3OE6FdRij7+fpyr5dcTgIY+m5Zqvg1Wm
pCMOdzj/HKIyCooVbarr0Cs7uhIrMbQ+YnAbVBRnOnJQDwYEtD2+c+4bAPDZ
xmjxisH5l32KO03YxJq9yC2iBkG377tk6KOSzB8SEXUIbNCu1M0KH9qvRApV
WZdIgLsECAbYcpbtt9b2s5C+MNyB6hytEqcPwcAlJXnPlejQtXO2knK5Y1/o
WMd2PCQVfz23iS+iCaGU3UGPOmhW/LbYWd1zIzi/rtIJR3AnG74f/gY6FQfP
QGPKVqWBI6OL9C1631yYreykd1z47cQUg7YqRTTGLpOTGBrRl0EEeqgeMWL1
hW1U14mCRfHYvGyv7GwwJWuashDVUr07oOYMF8t9qCfkfaqgehGCbjf4B2xa
whWlupsTHKItOzaQQT8i/vEBHkOarDAaXDUQE/v5aKLTBQzMVjyO1vvHvNTC
PdlxLv1jCS5Q5jp0v0P4f2FXdONy+mzJCb6t+JZ4mA5ZOXSIOaIsHViG6NqG
5bnqjuK+7m+3J6QdZzrmjLMgenW64jVlPqtaBWtlgViC923IjocV7sqNVcV+
YqZcr6XCWiyzHSGQQudUNP3QHN6rN4E9V+FV8drUtzjOYFlEMQ+2C3+RsIMn
JXyx2yqTF4m+IK66vwK3mVUGTgjUMVg3eDcY1oyW5eMrrFuxf5TEfFk3IaC3
4/rzmdE5zTor4q+ufiatj5fL22kNiSPmsk9pPf/wD9mZXwYDSCJD+FdEaNgw
F6ngzOVYNZVriyCpphxIdItVNShGE9E8HfO7Lz5YjWyDg3ARn0KLYoTgp9L5
uhXpp1uwg19gOCJjulOI0jK7KdTYgBURhbwNk1nF0kj4KV7Zv0H85nnNRCfK
ZBJpCN7oKGrWi3eLc8bRrLccNLYx/trhCEEHJ5LS3VpUASG2wfuF96qz7djf
mOFXaFX2l727pLkZvhrMT3i0TFyKZGbHrm+eqOqv9oMq2704P224RHwM58Q7
1xJrB+oJH2fvF0WpfBJAcnaV58KZhcM0hsfQpIitC7GLRIdyUp5G4ZV0Xr2K
SMdtIe5f4thncobHAAZ3d4vbuBVK9raxHt7Lj3Q8nWiTorJc+D+Vt20xZsMs
LebFWNd7RVlxzIS5sOWxvWSQUBSOa2HLlWMUQlBkUIFhN6yd+iG91Gf9m0ay
Up6A70ojzkc6FDHd/dVpPbGzJk+85Kl4RHBd4dOh0VgSE+utb9tYarFMnvNo
dOstTX936GQf+0Vf5AcOXLY15985L6F4pKOXks2pb3YGYvx2elUDtcm5UzxP
1M3Evt5E8IZwLKLF+/0NA8uKGFnHw7GXNw3NKTX0z97LUfGhO43Uy51BCKCo
jEI4wO9FBG4JA++YYLLNfPkiF47cPt5akbjMDiV0amN6viq2wRMcdSdLX4ev
6zxECyPx7CYsPxstasBBhykR0Y6UpQKG7N1RNTjZQRRE6kqt7psggcnKlxWx
q6IrlpZJQyUFwMWgBDJUSOqsu8g+cboWvo19WW4Xhl5m0DunAGpYoRaMyXEa
W8XaNKKa0P9Ycu8jE7vcHBDl083ceKJAaJcdi8pw4adPdJR2cK0L18JmboDo
GHVtdHJ1nrfBlwWynuowZKc3LqsiMofYcmEBF6tpC4RGRHI9EbzHe1lcEoOm
mwbWv+GVOp8CTaxZVxVeNSWG65AtZAi6WbJEA2ZcfLngB5XcwIJXzcH4TsMZ
/UDjLfOmIjiMddR6gjAYtvWCdR66kG0XVAK3cpFNkK99AsQ4zDm2mMY2RC3d
BsHAigdUo2dqzEfANcaSrCtVLXAl5XBsoOSUjLGpoJFvtyC/Zg9vQwjvtjUZ
dtRXeZyoATiFLSinh1WmgMDgOGLqH+YN87CqFNfH4KQvhplFbUvf4iKbrZ2t
y4yjM2RyAjfj5pea48PoKsP9NYM9x4/1l8dqduQ5ZLDJqMQH4cbs1lv5qqAy
n0Kj2gRNldcSRkC1FqZItYNp4vYjhDIRZ2PZ8ADCMCUusRobjtcJYQvbEt/D
kne5RJE0RSP0nBHiterhxgJvJrM+DdPvQJ+IopaYZyYGAEbCFBEb72LYEdky
GkYRG88/uSxauoc+e3JLQ4EkDxcj2Xk8984yiQCKwv4uNin36UScT8WtAFx7
BegTc0ia3Jm8VTKqseTOeqgeS0IaBJeQq8V5wIe/JXpvcg8IchfKuwgaK8U3
w6l6HuHQkRA6SagrokFdIFvLsFVqMjiIXbEEW8Kj4sd3IXe5g0F4rTVGgKQB
7CMuZBp6dXszMVyIiggfGg1tp+hWSk/z2kANCKAosgKmpAEAuxpCf47Nmqq9
haqiDrJZDcaKL73lNty+fwGg60AL4ki1AvZcNZZkUAuFwmvvHqfIzF/i6C7i
PRN8gSfNyiPWUu03h7ObcVsS1ftySDWO+Sl1eXLg2LDG2bwShtIyAm0L7qy+
5SCrYUjXFmDPT0fCuD6Ura5Azobvj9gzfBxV7odzEK4rOAVA3xwPk3jtwRjw
8/6ptjY+PndqrLhVVuxvnN2tCZUuwhVPsLlsTShihR8zkmGHh4ql9UJ3iWBS
cNhzzSkXjBz2VwmvVVBMg2Ntwh5+q2IW5OMw6HguionPixtR4AQ2Jxas232o
xBxwGzpeLB7C1ufV4A9E1azelcHgDNZI5VnHLZuzGljnA/HeEBQKHmb3HFHe
GyqN+mhXkUvIwfOE+DCcTFQeqpdHrm+3WQkDcBE/4oyk/eAi4W/206sISmLt
ETiNPVr+17CiAiur6WXwENpuOgbVeDuH62zAYTP4V53mfnvwdPAC5L1BgmGk
gyIengmaRzSwODVh5N82UzcWu1mL8BJEIIhLPRsMyN4mHqbVb8BcrVRZtBJZ
kc0kQteiiZ8/ZzBGHBtRSEV4DauEIALPmAKinn5wj4Zt73n0rHgwxnKPUBGY
hmdoTZvtKQYdaUkbH03HAjzyW6w+HGNZ2JsYXghqkjB3VVmpR7HJ/jwej//i
XUbYjLIs5la5ENbLSPU8IdZFkefiFIwnjHDs+57pYj+KMaQRIpoOQy9pQNa0
FMFYJafAK1G/ATwp9Qopws6HiiOdmaIU9FJwzrLR5NbgD1SBF8wEROmpmYWo
yeDmMfQGe4kcOc4PUSwFO6QRf6AdFmQsNHho5oVOm5MwiewlL5OW/rFgrNh2
eqfPMVshvNVU4mYIuhhfiprEjFPaYgBysjK8AZe1YMRC2G/EGlGxm8luNOKo
GDgh69wedO1xOYkRRo9LIF6AdcLa/UGxprVmpYu5IPTXpkruek+XdVD7J+NT
vFCswPv3H0rcL2hCvWXh2HPmJFNVEh0u8WlsOOA8jW4MqUxkjENZIUVYTF72
m0QQpC2KHIoFaLw1UvKZ9FYdUC1sBBNXLACA8oaxTk00sGmJeO4hqxCNP2Nv
E01LS2sjFmhXEZaETmwF0cGqI9bvnIK6EI0gkU2hfteYviNsOVMv3PTJJBRa
4EJa4syfw8Hi4cARjn3GQFrP6aLiMH5SgR7irC8/V/FuseBWWLQjtSnpoQEP
xrvGJJPaWvTAm++vAMHYlbzLeQnEnFndeDp4uT2/3umlTn1VAFJ6kDQs7Kna
TVBIU5KU0412A8sgdbsFXyK62dgEMI8l/euPF+dC8Sg1rnAeXf01LfBKjuct
PEsXVe4x8ux8jVbf0eptWxUYoUkxJWwnuFMcZz9UooNoOa0kMgFIyLLQG/2R
cb3Q+PisHBYTsWyJXnMsq2LDziE0SVehcQunwC1ZMYWVG7HUdOuLSsEXMDAE
/KmBhokFLdcNjlKS2tung8FIwf53wbbveOAuNIooEOeRpPPqQ8v6w0Vfe6jp
aJcMAwRlQ3mY0Ji3Rc4GXs42PAdxK0EoVqpKPgMYig4tHc1hlhILzIgY5zgE
KdkkvJ+pbtc3e2ZmqkBAdzzA0RSK5kHUvhAWfwMhZ6YNCQ1SB+p5Y1YLecj7
K+GbwjsgKkgxkbMPxr2aiu3a4f+9RtuQBsE6ILMWos5v35T/B872Hc9OK5gl
quHW0c4MAuJdXRKFV92zjHVHNpFuK9oxYlL036lYoA70wBx+aSErinbp1I6y
5DAdTeiQ/k2aBV09IgC6MOkbaWEkwQCDJ4GBspC5xYvU2SnQlhYTwe/kJiWe
kFvDFgdSR9e4zNHP01+RmYgkQvEZsjNIMtamNWuIDtYOJwocv85jogrUrqkj
SsPqq6jTzqXBbkhRWsVErRyhMqtZA5So6PncO8CRR1A0tCpRmbY06+gMFV/X
FhBfREySHKnaa6RQspVoP9op7CN4b52WLXcIpUw6JRnbNLwX+NRILNXrJ+JX
ncXxbPg7ImeqwCjG2Ru3w5oK6CdcxNeHyBMWjsRV3DUCTEAjUD14LKCFdONg
x4vfQ1eUw9hToZ05WKq/h0IF8K56cuVl8J78KiLiZCn+GbMGJSVP7OxbZBJK
yCW5Jhzsm0Wm4tAN6A2vlPLgCuD1BEbEaj64UWNuJZjGWl8s0KUqZ3p/GGC3
42aNsyuOL3Mhpta7n6DP8qNay4GlJwlh0edVpA4l0sm1y+i7e5k7ZoQaw3YH
lqHpQa2ULCLKZzj5mkshfvrE5aY+f/70SapAff5MyrU6PB3RARcZ/KchJiQO
6d+5xz10c/thh80pWkNaP62QtvhVSqVOAhBjRpmTZiNU5TN9wMJmAgER2sWR
ZvA3M//AwbceOMz6NqusphyxfyWol4jsilByvrqIbGW0Yap4wdUjXgAzs/M1
h9NoTPZ0YyVezdO3q8FxcQkpiixGF8knWgwv6+tlordYSVQOipZcUf+s+tQY
INi/mvAYlpZh9ywk6Xtx8JCeeH1+ea/Nzs7/yLWf4HlinQ/tfWDlXEmJErku
WeSZ1slFTHfjZtp7MngtQs7g0ro0AahfIHIafwnwubpqUIsJn7G+sW4lauZW
7wJYBS29LWJzsFH39/6V1YWgp5B68X6TNHfE67QxVj2heRDbSaV2Nsh2uHTU
a+BNL0WNyd8kSApGuHjzYxiFAsUduEGxVnZXW5Nz5kackc6Ggbh3Fa4FfsWZ
1BjvWXbROl8Ec1MUvl8ivFQKUpDdYaAJdooz8KPTRJ7YfqBxZrhpQ81J8ONJ
Tj6isD5PJbkizjkv57VrisA4OOitA8O23rZ0nijV4g+GfL0rkCP9pOMLgzlU
di5AFR885ho89P/X9FPwEZLcmb+Q7OTZvVRWHH2qoO3U9cpG+kYMQJdZ6CQ7
6g9J+oVpmo2SZyVqKM5JvB9SesGbWJqIqEB4Vkdm5qZmsD+jSHovYxVS5YGp
+Jq41BxdsrC/iOu3tnKofwZGZR5TVTmvAgl4STuH2G5DDMXF8p7B4/GAHXi9
SHlc/uSmLjxgS5iaHp+ndL0x0VtlGqkb+2uvAIMGQvtjb1TxaqUGL5z2Sjzq
rC58LmgkS2oMKlegP6yEG7emUlcsRbO29h67jfc/sIfEBwjV8SgHwyBo3dHH
T2BRY9rsidLIvpL/Ro+dOEu3lkzEAyfBguu9EzRzL1IIV5pMfztEHny3QcUa
x24sxn0GjdCHXXSXhdw1k4tJRL0tajBv8SXTbhPAlmtCAoxyvbN+qrIyQw/0
c8S7b8dzMnFIeGUs/SruzdMeMGaOiyweKs032T7JW1+27oDhGw3CMS07R4e6
q5Fj2yfpBMdKmO1kE7lR+FR41yQBiVQkmVh4pfgkbRu2UbyDWK7YdMgkqaER
cfWcSiWgnrKT1/C4nEXSVwq9+boCb+2c1CD5Skjs0Ski8LEjWtF0dkYb3rWp
NwmATQiAnX4bopHsqyIzfmI7ySf5up9REyIl/Q4qXw2YRABjWTyXnrCMauHO
j+AWXrR+TaayESFhsgjHxTTeuQxhvlHts0jU93FAMB5+JDuJNBYWm22NAC8b
vEhYXwnmRvxLlUASEXbcF2cW54vRBH68fjVCug8TtCS57fv0XEm1rtcR52Pn
l7D+A36thzpKVTteBc1JIIQhEMLvEfrAzKEj5ncsbQkURCe1QvC6rDPzeYRI
05XQ3hR57BVwkAyJqp4+fPD587NBz47edfwCBPGRc+/updctRXmJXPc++3K4
o+4UV6SCSOea4A7XTm8npX1uXSmDpkCZI2bTcYMfz3sZezBM87PcVCXrR6WJ
r/clEpdbC7i8cboaZ1fnFxdCokUcahrHO5SdRTNNDCeWGHHumN7kKGGfWYzI
LWHS87KeEAVBEfGwxImlw6skW6RVDzbXbdFwrEfWc/eU7D1EwXs7yUKXmWz/
/ek5FF9fujHb23mQfvydEDs4ysIImjE2TIyNGIKVaF+Sz8yZLqHeJlFc1J+J
5QvXjWSd0XK0nX/MrkefFocqFrQlEDthJDhSlUzGexkdUGgJ9fmzJlf3Nl86
Scj5sq6gHySX/ccrIQO54aQ0KK24QLavuQQ2kqeXWbuGyWXms+bTWq/YTY6l
Z3MapmXlVpkGcN1IWXFozaFkqaSMwwexQfJ0yZDthyixzlpE1woKccfGJGs+
jmFFsaUoQs8UjX6vMCazM9HfepdAQKbB7+zB0rEVoZvIxK9XFdnhK/VqNFYL
LmB8VYTFp6yYgjIfZ3yP69xs7rXy0dB7qLjlbckFi6BfT9lklmJCSOVyWBHl
67L7oiMLA8VBIyYIrVNSVwSp5JlWtBF3sBB4uQuNp2MFo5nAYUWMtUMHhUnj
VUFFwEJJUExaf3k5oZCLQ4kCFWGY91/EcAx+UN8jWGaEuGPL4wvv9afdtOMD
OuNSYD7eG4QIZS3FV/xusMlGVMBFXVyYOgwt3gnHcu8BmSXIpdic9PA849ib
DwT5+hw0lngBnpyCp0Ypj6rv+bgh6g7yvWLlpF1zxF5Sm+gbJxw4dpEKVlUq
4hObWS4fllZtEHctp0ptIh7GJiJZjbG7CM6LhIX9VudFVAEmTgVOHvlVhX5Y
VYuF49dVtPUKwBIJmnocZb+Mm472LHsNRgjdYQkPpW7VtLEAp3d2BRF7yyPo
/mC7e6GSUO8uYvh9v33SwS/VM0xuVp13QJhfIZCQ/Gs7DcWL0BiGHeX4abcI
Hj3vMQlYcieolqaBS2HfyDrtQU/yjBngyevWwmYxsD9gGEy7pTqxy7AUL5qk
/MVZgO6CAd0avLxFjHf3a8MmYLfV7Zo+w9MWZWqXSnCwu2eiBgtcBnd8CXop
o2CGnWY23D2WiUz9FZwbGnbUCGkYPb5+1zFz4UGUv8AKXC9lImz1gYyj4pM+
8wn0ooaej54Kztb7JBxlcqWwonKiSOAN7YIlbYCu9vOWAOnj3Dz29wr8EfkH
EkxhHCSNe8YF0umQHYCZdDfFSMS58VKHXUBO+6KV8DhufFSiJ1Go3iaOwwtZ
ObWBSZhhRwlghUXsvVZrXRAzWq3LqJDe2hW3ija7Ureir2eil0fDRNCi17wF
8pE2gUK5GFQJUxCn3Ci3ZNXJXBnQXqEaFAFDoqh450JBKt5gBxEIdcbYSC5c
wmElLkd/H3ZWCUXTeVclNNSi1BvauvUSrZuJTYuROWR2ELA+kcu/sqhc0Sbe
Lxw9ERD3lxMBrOpUz/MoxcdaibKxZ5GXKBrNUrLljNinXv29QwjtMPZ/u3j5
qnCD/EE72YDJ/2roXKNePqjYIzLwb/X8IF2+3MQFlIbOkMtx64uSNLOVxO8Q
PXfFMP0l95HtAOQUM812hpuO6e1zvrvAeIc+U2h7XGckJet6tivYIA7kfsaW
f39qznNw1AORy80IUumGuLakfK8si4jkN7TDKYQQWqba4uCHUbkI1J2v8i3/
TLanwi/fw0r3IofznurIRyd0X/xOVkK2N5aVfAdwUgd475a7wqE3pihZ3/Td
TGvEhAR4okgXuGTc10V38Cw7a0Tx8KBtqd/QWe/avFWNUbCF4iBx72eOJnV3
heAiIlLc4PGjJ6SCion/CM65XSjdkNzFcOrS+aNiFI7qKXcrvR5y6TBNHxlV
IPKfBqmkDk9CGl41+/TJdT5UrqXg8GbNFWpmrlKlNLxJDchx9l8skKi4oFHl
ahXXkYUobjoRilFiBzBgItWl0t8wJglFED/N9tDeBs4vXyRnu2xOeLs0AAvm
ytnbq4thdnH1A/3n5cuX4i66uP5xdD10u0w36AbeXhFtSXKwhp37WW/e6xK1
dLj2GP+r9GG3eFc0mxf+9u61cMFVhUBpIm225+mrbtp7mZkTt2R9ci/MBckU
9RwbRbO5I72Hy9usOsmHDPVUU+YUIrhSMFlqgjfuAGMVEwuI1WQX7vHnAS9A
6dB2re0nHgi17zEFAefXJIe557mnU3v7GcDbbaLHe3EQO7EGXX6JOo17ZMvB
Hzxil0gCRYUe5duM/Zgqk9DJavx9z6Gv9oQfSu0kn9gsRfxTmaiq0ochK1zi
9UE1IWYmSBPMHdiHNfM/84b+JbtB1A4O7MaX30YFUTveGwx+SFfCnE9WJ2Xn
WlIzweYO1F2toJ+aeIpllEG/IqpL9uSmtEEJFxVOJh+iuP7BewH6ERd0Eu9x
52CpG4+7EKUuoG/gaWKxz3hDlNG6UWHpPeEJJNADvxjXpfoDazchJoqPAYlA
+NmqKxLha8bpB0We1aSV92ynlaN8lNPFvFyxEuG0DE0qWne/cUTdFp1yWQw5
8UJrA8UrUFxYbiQNmIbm85O65KiGGOcZwX5ABqhPv3CYgKgFRUIRnJATM0kF
avoRY6kbS7IQJdN9DLJWYFzEDRJ/jy8wJnAqtpOJvMBuBOQ+LVGKHAXnnAHr
gKfxexEriegXOhK939PxWBurt672HoyoBYDIDHZMFu+sw7qRbHSJVGpgXQKo
QhHb29bLn3W475rLQsC1irCgQ7B++iRNXCFF2TgBYtLzRHGNhdwGdnf0s+a5
jnVU3VNOKVGIykJ6fvbkkWYLshdQqohFh52olc3cVLol6C3w4of2IEgQMMf+
QYe99ocS3DqMW/EzDApbG7KwwtNKTBolUuLQ4sxApNEOEvmgeAx8pk29MWW3
GfHBk4BB2had0KdP8kNpoIsHOUVr6ephuAxtFMcbxrQJeu3ZLuj7y5lIsTdA
FLbjo8fsPwxmm0IcNYngRhqxThv1t/mK1QxPC3oCKZ12gsTV29aGWhqhl4gr
aDBBzd7l1LTMGyLxpvrHpfgtEd2+ujxAozJoN8nb3Ay9LImSCNjnWRFjGhVL
jm13dnum03Xb0UY2sY+Z5m8apvtlDBJ18Xv7cVFM2CUiqSMJaEDAWzcawCtF
z4b7t1mzgSqcIq65IkeY6KlaaNJjDRTRKzNMluAcRgyJ0J+tu4ILK7+wdkV0
zLidC0kUwI7tv7i8OEjqZ0QVFNRDs9OGj/GuUcIz3Ru2F2nYoStaDz4DT43H
NPAd4mBB2uwlZnhxSvhvhrL9Blfva+CfauBzWGsUr/jXfb7Ofb5Ifj7ZaARw
p+0a5L6PO/mETVQVAbn86h/GuqgX7gyKS8fgSqPi6LxVr4DiR7R2A0ef6Jfv
uTaLa3Djwsr+uAqnLwiqT1HkXzT04OXy3r1fFGSQ7FutGBMuv0D2D/FvRr4K
B8s5D5eUNPDW6cLm61JKI6NIWLdY+jJhaxSMqIzK3YCVll/3wunyLr6puqkf
OVLsd8wjkXdE24cCnyhZhKJOlIBFWwfbYbwQUrQ0c5FfMVIvG9eVAhK74TST
YfbqxYsLzar1EA7Hb5bFRzWYxC3mZ00nMNdIalJjUaQta6PINSAN9E3d2Jrz
z0ybqmi9espm3aEwKOypVGqyAXl1CeymlO8Rk4jYIgqcaK6czURCOdupddAc
djCL87R37PTKHHhN5FQz3xRNw3mZCxcdFAwxLeWsZRwxUP9DVT3jAUPaLzhq
3Ub1OjRH1wOa0ZtL7rAQpEbuP316dYFuz4wJSnmDu/JJTgFXu1ysW9fbwmQo
/RPqPMSUvA9klcvGPggmScy16jRdN5LSvcmEspHaIUeyU3PfU0Dg0U5jLrxW
Hid7p56QtwVI63m9QBYNqADlFE2RP832LslylYxVnCbDzj3AK8nwLRAv+Pvf
/o82ajQxW+Nle64GDyczSCZ2sxZvoTzhy1fcPWG5CTMIKyUKFaboSsb0TeSx
LtUvtF5O1GucGFEjPDczDVfAV5AcfagUsB1rC3crPs01h6SipaMcaI0qQsoK
XB4ld5wOOaAFuzmBSa21jDu87lJmbZg4a+NK7l4mCwYcOh574rR0yW+XmHfE
T6UcIccJd+ZvuX883ZY06qEXL/SStHR4i2ZoPqx5IbmmdiGWTEMz2aOsG/pV
uwsiL30muCSutVIB0pHvgJ9LZag7TelnApVPXeoHPXkVr5S5IkodlurecOE6
Znt3vuepQAr+p4XufEhacThZjxtbwwAN2iyyXL5rVwVgrD344hZERtTWolor
jJ0tPpj98VFqRtwdY/dSj6VEVewa8u5mcIqoaBMxcnVZIq2u5RLWrySksRRG
lMZiWdClFNaLLrLHT8vgLmrxEuAXsTRwNVfUZ87nxpworTLqa1O4qt23yDb9
9l0RU2ZhlZw0YzRIltBciQ4vZHslX6mGHZdGTb7/llr13/DbwNNczcK0FmVS
QjHaxZD0oJFlnQTADL5IuNZ103ewQSjdT7lceUi0sJN31+eK8EdiGeLetQug
wQyVoOo40ydjqkvRmrW73JO4ODEzZtv+Tn9/Lzg6+sr/vDHLpY9aIO0TxfIv
L9qDXqQeJ6TaTFKKi2M84c3igHUBATWqQetvnBmic4uyG114YGpWxpVLGCaZ
5nFLTSCP3Bi8L+uizMWi9JVqYh8e/Olx+SGh6lKP6hscq3cJSk/LSWbUt8Zs
f0tuNFjZvNmWrDvsP8c1hy6F1REX2VOaGOiaXjLHVfQ3qG6nPek5vE7McVef
nSvj3Pl7/uWGI8xhy9lRqClWE1fX1fu8uQhi8hE884w579uOfmN6qCWeNRqr
aHs8nrjxZRSiPdD8+/5aIuIrul7Bzm+ebZr06GbKJxGFhARF0dM7XVz1Zl1W
LqDoily7fFjpVliNSA1b6Id8464llKRPkaCCJFZvalxZZV88w+wr8Om3oi9y
dx+tc+Na6oZsZ1+c47Z2NxLXtkUYQwtKaO9n1W2kc7U4AFxMJM28UrZ3ESpl
ii4HtDyLVKlQhpt4Bncnt4kWv1xU0YW1ruf1ZKwPIfkF03fJnPQ4fev8jOfo
X1bZZKWIK9U54CVg3fSw7/dsozp/fGS8/W4yrTtz8VXywDTAHa/gZ9ttVY0B
pNKxketp6z7LS/BDrC0aNQTFXd2O7SF9atl/SM7n2ZrewJUBdjCjkObQrmHw
FeJa0Xx7mSVaB6nTgobSoGGouStoJaIRCIzCyoV1JQrxYij651rn2/8MtTK6
bG6aCWo4St8mDiQS12HQnVuDJIOEvgsLB7CMwysXl/T4MHvxFmVdXJ8d+tfV
y/ODoVaFCvBFjybzzz4HaPrSFXPss6x4B9OqCLxMMXhIS5MaA1GGgjo/Cxcl
UuKXJ4IGt5ONeJydMgVmWtqu8ZfQO1JtVbfn0JC3KiYbN391q0vYQrijT3Tz
OC43gcUu94jUC3JVjLglxYxFFUNlSMX5MCoEXFrMuTmlbwroHHcxhz1LJ/Yr
Oevw/9usldX0WtrAaU02/fl/HFPNEq7qpGSPJYWleUbZKhw4fRIATQ3Gx+WQ
hTUeyNoStv01fpwXQobh1sh0Effgfwa2PBhwg3VN3EopWnyFrvunwpwm9n+M
7eoJj50bhJITvrurqn2hwGm8Y1OT7NSdIkKhCv+uSgEzwW2aHf4h1hq7RVLT
javgqW+7aiXFRuXAjRZ1g09cVc5dP45t8whEHeVnMGdhvVXzEm99wIpjGjeo
KQ89EH7sMDwLIdICGdhClnuxKlxCZZwbqxahdpg8iKuoPsveM7p5JZYUWy9p
/bW4IzgTmHgAu7jwV7xAhkjnURsXJyr1RVoL1ZROUdDEfo9X+NUj0xVyBSt4
uLrRVuFxMEU2Mzkdhy7yuH+6W3DIKiSIO+eKtI9PisFkMhPpcMH++pvCJINr
XQaJfkazqJt02QoPYEArn7UvEtRFa/KmAdbERutEsxcxi7Qanp/BYAc1uwgz
iUSXologPbmWsxV4e2TDQ+3Z6svba3gU6C4UozBimjVp6R/OC2QKu2POcRA8
mhm/kHdS9+O3rC3QFFapnjznJYkQ5vcil5krV6Try7aqGThgzVw7NojOW5au
I+Ea3l+t8azgCY+8S6jsP3TrxH+0vWtwem+RmHvYeUKYQYEZLIqVvlgabDvX
VAh1BJLYl1j8tFtzZ0TRR2+L1h64qBt4BlyEwgCsOkX6xUx2nSoOI6mQCK4r
5RwkldOxlL5622P1kV3+wdqVT1BSSYdcJs1/qHwdhZJtcfzK9xOWhIF5U9+K
zZD4dwVezj5j2VetrTnVqUwjTcE59hSL1e4iCxcEfHzfvVgiP94BS0/fGK43
HrXBZrDAurmxdKjsafCFqrUWyT2YPG3U+Y494V0xNxpWZGMgnrjuoQNRohg2
Fzl3+qhTvrnRDD3ZlcxYiQMmdCLKLLfB8GAvAEwaB4IO4AGtrai5149OEAeV
Px+icFCsbofuAIrzEFSzkIzbVvUu+SxFrKnZsv17NnAslJjm0axRzBRdeTDx
+CXdAhlgcQVzk7Mb0gV0TzmJHMnibSe3M0QaFHCldb+AdDYhnZoXo5dD1zIT
aZIekDq1W9sbR+WNZcQRYnqjW8YphSJB6BDPwC6yUBYIyGhpYUgmWKBCi0en
PH/Dn5Edqn0ljk5PY+Suq+CZXECJc4Ycu1AmpyzU8vRAAkNEEjnJlO9wBgwA
INKVUR2snBOEGTJruP5ep/roMcfOaZP8d2Ixa7lgXKoh+3Lx/V/X1vduc60B
nHfcZ9wrVRYKYolyzLeVGHULMJVob5qWLqgd0RtGdHRIl4wz1Fy6uGIxrt5c
X2qi0unJ8efPB32tzienuxohis1nRF90xbjjZaBXn3bF7Qpq1JzKd3JjgEVK
DSF4+1XpEB1hQjFftzlRabFeEbKdqTUSOEdfHT8ob5D6ZUPpk/jSf7NZkGj9
V/4fqbq/ux5Gr53Ne2AH6dLQNLJrKR4QPCznd7SdjzJmZ9o6b+Ot9ZCVQAbi
rTTn9GZB4rQ+TPCjw2xjuxiVD6wCCoW5Csgi0DToTio38+Qu8RRIhXhakNp2
HGeNqxH5JJI4WzqRcvtJOe5u0SCtXGATUYPBg2dZTyD7TXP5QM69RrILAf2F
lOtfcW/peqvrK0P5klYz4JWNXka3g/jabyu8V9rJPkG3v9U29D7bIXyp9Wkl
F0qyahg4ElG3i9r1YtucMWGaptCDmQRUZMjkY9LUTzmeypu3FSZfoIYvl09x
e8YNG+hic71JF+OHYyrKv01Q2mHppS+DlY8jRWYwuN6sJMVsmPIyVamgI/da
W6mywOawZERz5CbWBlqUtrBVwv9kZsGzxymxUp6t7YGHDn7nCiKlw8U8jCu6
rZjRohyH3s9eKmWiY8mrDqLl99L6I/3uP7O+8DfnZwb2Bf51qfztm9gXFh6x
MBWoOkSfYUnOsZ5uUKQiF4HvBPLoy1E5jaQkEh8i23ZGLJxdxaw53dcGnLLr
M7MbUJr7qq4QDFIy8RcXR3Z9SJ5l0W89AElN+E3i4QM8pxAEHwYs6/lcZH3v
vZpVqh1tVOHTxAwHy2uQgeXK+oQ2Mupp3eKF7jjSYKGgBSQS4bw7vgKKUdvg
QBpwyu0E2gVoRpQ+L2fDFCbAktsiBY0B4i4fWfoYYt8BdpE+j8z4b4qmrrBd
/ayh/iBOgRZejvG0hap4EApt4KU1CnquA9c9XRTHJ/ef4NJdJOzeNzYoqih+
E+UpuewVLR2oN6BXbDJji2PHrYUmKvYZuqCPkLKg5zuDWcmlN4P5xBb8rBC9
2vm8g19zG2mhSKlxtsVj/KX6zcC3bUVnBx+Rprx1tVk63Mxla9e5ftCrjrrz
Tn/wKnfk+5JcXBaYg9glhqOW8th09/SRjQZgpNZPqFgkAOxWfREDD2R0sXjO
zWCvCwoqwTdXd+ovWPq8YHfO5WYgJ+3o1PsCaLyeP87PK2q+IpQ4mNiWiS31
3bryidFPu8K1cDbliKso6D507L3wGl+cN/lF1jv4MutNW4QryT8cH49P+r6O
N3UbtzUMae6R8cTJNx8K6RYR1S6IUS7TWnGDA2eAq5cbJZnZr0DbbaXKics1
JxL+xyyu5RhsGdOGOgndxh+yS55gCCHgMr4g2CDDSODGQAUhpeIfpeFF6ACw
5Y11QDg/d69ZTCx4tbAmGtmHD8Ng/AJYhWKMTEmEFi5A7EbzxMvPaSXjNoqG
0pA0unRH4QFfLpGMyyNa/jNsjerSnBrzT1oY41/0f8ekBf5zFBlA4TQpmum0
Jqmc2UrrM1+dVa23aFu01VxUZMXXo0+c+/6+tMNBXE6r00YcXrgraJEdMh4T
nOqcigt1HIqbKW73af6ZXs8eWl8gQ3yD0nuRzJBiRrvLJHW9iBclPYk6MGwf
EFF+ca8NJIYG7aBzBH05kxDnrtc2Ldkhb4fHwgV/WYMxreb7vRwfP7yf7aOp
xmpRV/aARtJypgmBx/seSjB0GhFjKJjo+0wa732Dtd7SJDHprnX5IrlgzTQR
1Kh2rJOd29UH4lhsSrDhpD93DVFEv+AD0hopg8yd1PbqIaSZ1vU60MSfa+GC
/t2LCGwnXQ0FLW+cMBps4fD5YKYLNBTzloxSjO9CqWcFdwVJ/gHLCKcMcAcR
6Wi9gy/8tuIo/xH1u74VUfcPPdkcX+xkoZwuyH2kuEIMGgnvXPdg5cZDpH+f
ofruAji6CALMU9hB5FF1dTV7dU7YEry8eejPmakSiCPtYclvGaArPFrTvoEn
KTsTq+9cI1n7b87OD3wNXq6ZQXYvsVQaeeDZpHoGJeLt6l4lugJ8X21OVvvK
cUcW5oNY29RIjAaAvAXAmxbiV4E3K7Z1EGUlIeRrXEc/Dm8wtriR1lohbQVS
BSlfHvwyAHy5n9rsSvyyw9JpBS9Dp0Ms7Mr18Rmc6SadrbHZZFjN16rcFJWc
g9Ogj7ULFO2tW85Aulu4N3/6xF2lR7/QZs/NaGmmI31wlDyIdoPQYgAvHKzW
TbvulaKOm30B9KS2OvZBqna79IDMkyFLyoGJ1MSIZHXD1K+wzRpylcTTDspe
UiHIO5sDmlNbi/ge4rveGCcRZ2fseakjWAq9A8VUsTIunyNNrvbUR7knAj1Q
KmcFIktEpSak4pqrO1myJUtfhQffDfa4uosaRqEeJ9Lx9iK56qrEYNzQ6nHA
LBFlRqax3NYTiaWB5jxxWq5FIhK2Ny9QI3jQ10dUr/BQhppM0ILLnSj1ffrE
PxnpIsUJC7b1I6qHffB5Ni+5MiSYfcJ/YubEacFS3YqNPbWASfK7dqeDIFjF
cNDENBVt7OccZz9+hS0OisRsEYrm+C9czOwrZVgSnBapXhtTRqhbhvjHpjJL
2vjX0LPPk8voa33vv3h9fnkwkO7v0NukdMtOInTpAaI0ZpVZCnSTyHkg5ZyR
807icJglLdsZmca1narNdnan4BcGGv24n4bJcNE8KswpujQ4S3rtKt9oNC+x
BPgB76CRc2nRjGaceaif6LRr7fEsOsjtoi6J4Ka1JmHTh/HNAhoMzIJ9wKSF
vI/y79UJqw0nq/kgiT3vXIY3YVzx9Fh4atfXczb0Edn2vZuQT/01IHvaaTak
f039cKHxl2srsjdd1B+sZNS2e1HzQhRExjS55DMCeDsGcbihiIZlgH7qjy2l
+DTq48IX7NGVMPNarSpJx+acb0WnZSilAnUXOg9Pt7emu8PfJ9LYrOgIpFKF
druRf4qz1vu6Oe9V4aKtP1Itbtf5rEBJ9ym69KG+lfsdAxGkPGdc9MnneOgu
sL8G2LQQ3m1Cv0ERXs6XgDm47jdMX65ChPNQPXr0gC5SJg4ckaJF082Ij5tm
Pgr7pn0jjPiOpFdE2FTxCMJ0RNkiqSXRL4Ts0OAl7CPukR75w1x4IhTE5xSA
0FoKd1YcWWH3I21ovJv6+9kKlnZF0X0xXNpBVUMgwA+WuLlgs7k6y6HvJkbG
9V5wBFiMKOYR4WIBDxbdGOmg2pdt0X2R1XXg95V1aFh3+eqJy9ZTp3TcSFLL
wjDLFXtSANZMOsyyO9feInEISUgT2+vSWdu6ZHkdNZVwg0gcPh7S7YF0T3WG
sS8wogmkN1JyKm6pgdZljC0vfOmQuBmqx6p85TLLjGAbh6ohz4vuuubDGupY
Im4ZtqS2WFSkw3taGbJR9JrWmV4bP8SXTRMS8LB4jW2z40BhGj6jSxRJf2G1
3hzv1kFCYxcxbjL04XFQPC1dF3mTl2yTRXxzJw/Peg4Qd5sSj7q6LFQYYstx
xOMYQSCo3b0FaQp7vu+V9LOQFKTEjyRP39Gzdf/q7cWBZCRf+4Zi0mEkpANc
f391kJ2zHvHa0vxdz4iko+tWmfDMF2qhxdxwgdOo6xUTr/X1yuM7F6woEyos
i2HJioD2WaqVC42/xjTHQYGKAG+OQl96aICsMJMlfvr0bFcf2y9CPRIgjQ9L
edAce424ToVEkz2D7CTJ3fd9ivLJXH0apNGWZSi2E8Bq7ur4djE0xT9z9+6n
h4ek49FgwGyM62b+lyR867Zes2uVpXtcnR6JNJNk8ZqaNaxJQsRMuIMNtEZN
g1CqVk2M51sozlFAsOHaefrOpD2ae8IXOdiWv/4X3k3qLGRlexdC/ijpWBUC
Fowai7NQkKU6WBqXG3e6xsT3E2SHdtSC7v6DYyc+NZNW1xCaD/sCjgFC0wVA
Inu95my8xgrNVBpRxK1GnWxCUT++XKW55XaoYptpORHaWm0IXTRRXEJVipMH
O4JeUWTStc8IN+VLTbiwf2yESwl2NsEZ5sVtSrE//r6vWIkNHg6XXdBm+3xw
wLZLbnqvxoksC6CggHKKypmSucvRzlBAXUvDsBtZIrV0kMsJGU4uFBA0rf9X
6+gPv6HS8ZeTYn9Yd5zqcR2RTS/KpjGkIK6NdB1oWfgzrbRbtYTj6sgM4Zc6
yIzcsgsuOFHanpJMap525vMxaGkkF8nvCOEa9fUmXu0jWDG8h5kNmvXxvYOL
mFbEB9iroKGF1BmaKwP4wnoec+w90ly9iUs4YF4cY1U3+NCHb7tFBCJrhzvK
GbVcewNju4/q0AY8isihT6u9tXl/zEzbbJRRDrhrtqJzCqFQ90BcoomtMKv+
C/Vbw3vni88qH8OmVJ0PGhVcnV/U7KKlP59F3Pt7ro04C9lAuDDYHDSLYXe/
PlD4TF4uOeWi364+q2aTASLDjJFIk6vOGe/aGPt3SVKQyHRNM/ItLCca31cU
EyAbjA2mcdyM2noEIBH9YA+3Zo/2gYsJia4hr68n7dTlbCtUHPWfhTEnWq4H
47a4nVErXf54QpcWHpT4DR5RJ+68chNmHxWxR4aTD/39zpugXOm64SrKak55
L0aKxg4di3Ah8xuYZFJp1ZU9ZRsKPiJ1K6IQCR5Ah9kyin/2dss3zXV6gvrt
LKKXrg9WzTN0xT3G2Y+ho3QtDKhVVVdTID0HSEFzsdE1dMNij6coo1VMo9pE
3t0bV9ftenV9PC/xswgpqd5089/17NcQKv/tQkA9gf8OLNZOiznTckLazOCb
+sHHrhWnWTKWRzGVEcbG9bCJuBQQXKH+9PvTc1bTkgkQOXNWC+55dDFkz0m0
5jiivt/kypczdaVRvWkecddbO2G3Hv8Vii0KD2nkw5qfnDDKUd104vDXbBL7
USxwVVt7/SRoNZLF4O9k1Poy2jk2gV2LHxlKUuKsuqmLxpceHPpis8Ot5i74
qHbQWWhoi03LEhGMHWKkzHyB9PcOs+jnFu+AayBDlwFAzKGHUU1s1O2CT13L
4YgwzDleH1VWQ0kj9g+gtaRArVpQoeZi1PNKAGl+XtxfJiGBBLuI3Xx9/eb7
yFsZCplz0gG+RVVtjySWtlzau1pOjeMuxRIJnNw2TPBUsEa6KCN+Xxc1s7ch
O6BlDc8VqFhK274m2RUpbVIL/xaRqF1iHGAK1bS5yzkCJFKhUS1LuCSI8FYY
F0ng2l8gcs2r++yD+MaVwM/+dM0bSv97/sO7l/wAqFDrH0Wl7Z1ZKPq2ezdO
zcfaGADCRsNQG6MpJmATyiFGD/GLpYJOD9aLjeCL59uEGG6eshoBEIv5aS4n
WwlPjh4df6FD9jeHsL+FAe4sJHNnlTXiii+sKoW7+02hLkLKGXuFo537NZRY
gN/P+XMazaBU0LWUONo1pK/Ly06Smc01X2MJ/HSz04HtApS+tnnmV4Jy8OJ+
jObR46X9hbN8rHyiilOVI+0bdSVXoQV3Ek3oQet9MVo6sMZMBWDCOoFavkyx
Ua18LpjWa5PlMmeaFCEr/ui7FzrkDWTIf+a6dqBYzdJqfTXx+3P8Qjp7R/Xp
f661Lo9+yh+uSZaW6LLxvKlvK50sOzi4ghrEkdjQxDuaWjWlmBxaLRBdMitP
1ESF6zmAN+9R6BsjFdZ4Eh74xECRQnp416F5Kxdq1d6/XDQ2J1ngmicEzTDa
xURIKCexXHj8+MmTI18/1Lt2icQRXAPDRxOTjdar6tHR0J1fbmmFMeQikJK2
r9bSuzcSX4wGQsUQnZhA9Iz4g6U7hM0dTsMvhD0/KwRF6GYazhlDlMM0Hz7U
9JsyzbODrOEi0uIy3OoSJS7kENOjU2lZSqho7KUoxr4NadOCoOy8F+ORAq5J
VTXE//Z9MYuDUF7iemHjgoX6vuhloGnXxEdYvs9e0onbPOvd734dNpZgzENa
f9vT4p7Zjr7bHQp0SJMYmac4aZyVYRsuu2shAn31PjVPeigcLm82wi6NLi4j
S1bUrGSoUDCbXR/1cuKglprD3fr6q4w14KJkiGNfi33fEtF59z5il5FHGbZ7
WlDWxd+3SJso6rJe0/m1lgnqPy+9ApLpHYmYvO9+2ZZHUQzARIBi9T1YjTAD
K+Um0PDAXnLR7nG53oalSBd+y8h8sX6EMO8lCVYJqFd02aZnyvRdOpe+jn0w
VHQ2k42231H9Ubo8sbbBBYzjvm8/vuW8EIxz6dMlEGl5DtpxuTmvea7vJBns
06cf3353ya0S+m9mb5ItV6Tq0JqXQhRxItlNUZduKii3bFkD+3ndCpRB1Hvk
UxhSJ2F2TaUCNulFNDebhhtMMCVl3LqJEDMu5BhFEJJ6x5J0LQAlLXl8z+m1
NMF7YvmFLnN0kKRKCGf/CAEQ0t77ZyW3GUYjHTjt8JWcbfbOSJnmtSQWvArU
+zLkIXBAFALRNPO1s6E8WFJ9Na6qpT/L3TkNnz790WxwwTzO3MOgnGNZfBZt
XOc02gUXc+uvUFyVu945DIZtbxyetttPDavQatg1AvRbudECOZXDxjBHiukn
iWdIf+Jt6FSh3cOTzC/Jhu2IwS5bSTr2XcD18Ls06TGmav4303VRxQAt9J5S
wtuidKn7rdZ+7564QKqHM6Z8gxN7JFQAY1cUqv4JDJUmAKiKd7/H/saDpJpr
cEhybEvTpokEJIpRRG4JM1lzexWfVlPF+b0hP3cL0xxiLkCAo1+uvgygLkG5
NFxSQyjp0yeMYMkWbkYkMasPjCj79GlhUbDobuEgW7kzP25HcgykwBvSdMbe
uyRsqCcTdqVrhKvivamxhxwVFz1Vcz+TKfpflNqaJZUwdZR+pmRFb9zi7Rw1
imBTUY9AZBxz7YaoP6kGvSSDO/bdxwNJ3sVW7y0uCBwJhNCT6xqgLGbpsE+l
2FBa+ceVrUjbBgqiw83Nh0+XMCMYth4X/IG7suEoi/N2oKINKYnjuBPYqr8h
6RvZeY1x1IHjt7i3NpjHUQ1WXp9cwLBCp+KTid5twhL9kH//23/DlkwiH6cm
BFfsvu7je3HT/0y/+AszN+Rq/3li/8LZrpu//+2/848ZYBEXXbheiMc+KkDp
v432CefMPdyh/rPpUkZpbj6UNuRDTPN//HqUdkKHUbVeiM7Gmc+CfaJo4vUq
Z8Wi4w5Qgm1CD0UJuTgKBrTuhXvBFb9g8Pv0/wYDhgm++y7MxEOcuK17APo7
L2aUfp9wWonjsK4R109RD2ZsWsdeaHcRRi+ARJBvaM0QMYOzqUd/sdHRn/zv
afLEqLANzJNcFbRz0y1GJOxJavGxKmpHAAcnj484k5iYkwWC5mU1h7+SzvMP
tSXGU5K1fXbTFNkLGs3wp5vsipTtXwxpM9uvGGavTPOLqewie27yohjSw1Xe
mOx5Y2h38BPasOzSwsvVYrxFlZ2vESEZZi/Lgqjxe4uh30DlIib9R5i9NInn
qA2C2092Lib1B4P31rMZyva+bIopLaAlrbKkSV7Vs//r/zTZOZ2Nt00WzWrK
VXIUfi2nIwVo5trog7Z5xKgWp11xqfC6QjNmWB67zlcjJYVuLGsgpICga9hT
tE8ukVnAmVF5DfAvzW6Bqf/RNvT3czKtGgAT3oCXVrRdfzQN2i0b/gdGu1qQ
rKjo83VJHy+KCdHCHUUdtijCk/UZODWrE8iOdVp2xT5fYg8v7LQ0jedkiWLN
RfSeZnsv4XqFS2LRLxguAWpugKMBPl8LwAemxnuKnzc6E+nvwnenW/R7IiZN
/wpuFOb6BHibUE4D71bfJL9elJiWqx6kmo82kNKkymHaesAjLnwpgqiggWuq
4ZoWAE0uria5tFsalqqgLjkkcDWyLKSuAql81Rwx057B5X45TLdxstFqV+qQ
iDuwC/LN++4YEF2FsrkRx0raLgpP9YI3aVGaOP4io179FsXS+2QEkKP1e7b2
gfW6ycZ1QBapTFYVEbca60Puf1SEgkACMCiAlQzNVaKK+3bHbmpSlsxo4kpI
sBM9MGgEG9Tt7vJTo8sQnRI0u7O3Z99wtQbp6UrB68wl4XBElwai8YgzSZT0
Ozj1487pd91YGd3GbjDPu9iT9e76VXpNPTatl7vbezdXMp0KzYsOYUdxokX2
T2CU/wK8GqBe/zxO+ryrmObYhN6Z5Eut9t+uJwLKcKoLz527ZQz+yWHKbm9v
x0Da4TWHmAIt5rDkmvSz+hCz+GfwLTrbm5CNygMlTdJN9/QLY46MDHB4ayc8
5qEa4IeoOvJxvOiWJb3m/wb0O5Zvav8AAA==

-->
</rfc>