rfc9620xml2.original.xml   rfc9620.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc rfcedstyle="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc toc="yes"?> -irtf-hrpc-guidelines-21" number="9620" category="info" updates="8280" obsoletes
<?rfc tocindent="yes"?> ="" submissionType="IRTF" xml:lang="en" consensus="true" tocInclude="true" sortR
<?rfc sortrefs="yes"?> efs="true" symRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<rfc ipr="trust200902" docName="draft-irtf-hrpc-guidelines-21" category="info" u pdates="8280">
<front> <front>
<title abbrev="Guidelines for HRPC">Guidelines for Human Rights Protocol and <title abbrev="Guidelines for HRPC">Guidelines for Human Rights Protocol
Architecture Considerations</title> and Architecture Considerations</title>
<seriesInfo name="RFC" value="9620"/>
<author initials="G." surname="Grover" fullname="Gurshabad Grover"> <author initials="G." surname="Grover" fullname="Gurshabad Grover">
<organization></organization> <organization/>
<address> <address>
<email>gurshabad@cis-india.org</email> <email>gurshabad@cis-india.org</email>
</address> </address>
</author> </author>
<author initials="N." surname="ten Oever" fullname="Niels ten Oever"> <author initials="N." surname="ten Oever" fullname="Niels ten Oever">
<organization>University of Amsterdam</organization> <organization>University of Amsterdam</organization>
<address> <address>
<email>mail@nielstenoever.net</email> <email>mail@nielstenoever.net</email>
</address> </address>
</author> </author>
<date year="2024" month="September"/>
<date year="2024" month="February" day="12"/>
<area>IRTF</area> <area>IRTF</area>
<workgroup>Human Rights Protocol Considerations Research Group</workgroup> <workgroup>Human Rights Protocol Considerations</workgroup>
<keyword>Internet-Draft</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"/>. This is an updat
ed version of the guidelines for human rights considerations in <xref target="RF
C8280"/>.</t>
<t>This document is not an Internet Standards Track specification; it is publish
ed for informational purposes.</t>
<t>This informational document has consensus for publication from the Internet R <keyword>International human rights</keyword>
esearch Task Force (IRTF) Human Right Protocol Considerations Research (HRPC) Gr <keyword>Protocol design</keyword>
oup. It has been reviewed, tried, and tested by both by the research group as we
ll as by researchers and practitioners from outside the research group. The rese
arch group acknowledges that the understanding of the impact of Internet protoco
ls and architecture on society is a developing practice and is a body of researc
h that is still in development.</t>
<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 (RFC
6973). This is an updated version of the guidelines for human rights
considerations in RFC 8280.</t>
<t>This document is a product of the Human Right Protocol Considerations (
HRPC) Research Group in the IRTF.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>This document outlines a set of human rights protocol considerations fo
<t>This document outlines a set of human rights protocol considerations for prot r protocol developers. It provides questions that engineers should ask themselve
ocol developers. It provides questions engineers should ask themselves when deve s when developing or improving protocols if they want to understand how their de
loping or improving protocols if they want to understand how their decisions can cisions can potentially influence the exercise of human rights on the Internet.
potentially influence the exercise of human rights on the Internet. It should b It should be noted that the impact of a protocol cannot solely be deduced from i
e noted that the impact of a protocol cannot solely be deduced from its design, ts design, but its usage and implementation should also be studied to form a ful
but its usage and implementation should also be studied to form a full protocol l human rights impact assessment.</t>
human rights impact assessment.</t> <t>The questions are based on the research performed by the Human Rights P
rotocol Considerations (HRPC) Research Group, which has been documented before t
<t>The questions are based on the research performed by the Human Rights Protoco hese considerations. The research establishes that human rights relate to standa
l Considerations (HRPC) research group which has been documented before these co rds and protocols and offers a common vocabulary of technical concepts that infl
nsiderations. The research establishes that human rights relate to standards and uence human rights and how these technical concepts can be combined to ensure th
protocols, and offers a common vocabulary of technical concepts that influence at the Internet remains an enabling environment for human rights. With this, the
human rights and how these technical concepts can be combined to ensure that the contours of a model for developing human rights protocol considerations has tak
Internet remains an enabling environment for human rights. With this, the conto en shape.</t>
urs of a model for developing human rights protocol considerations has taken sha <t>This document is an iteration of the guidelines that can be found in <x
pe.</t> ref target="RFC8280" format="default"/>. The methods for conducting human rights
reviews (<xref target="analyzing-drafts-based-on-their-perceived-or-speculated-
<t>This document is an iteration of the guidelines that can be found in <xref ta impact" format="default"/>) and the guidelines for human rights considerations (
rget="RFC8280"/>. The methods for conducting human rights reviews (Section 3.2), <xref target="expert-interviews" format="default"/>) in this document are being
and guidelines for human rights considerations (Section 3.3) in this document a tested for relevance, accuracy, and validity <xref target="HR-RT" format="defaul
re being tested for relevance, accuracy, and validity. <xref target="HR-RT"/> Th t"/>. The understanding of what human rights are is based on the "Universal Decl
e understanding of what human rights are is based on the Universal Declaration o aration of Human Rights" <xref target="UDHR" format="default"/> and subsequent t
f Human Rights <xref target="UDHR"/> and subsequent treaties that jointly form t reaties that jointly form the body of international human rights law <xref targe
he body of international human rights law <xref target="UNHR"/>.</t> t="UNHR" format="default"/>.</t>
<t>This document does not provide a detailed taxonomy of the nature of (po
<t>This document does not provide a detailed taxonomy of the nature of (potentia tential) human rights violations, whether direct or indirect / long-term or shor
l) human rights violations, whether direct or indirect, long-term or short-term, t-term, that certain protocol choices might present. In part, it is because this
certain protocol choices might present. In part because this is highly context- is highly context-dependent and also because this document aims to provide a pr
dependent, and in part, because this document aims to provide a practical set of actical set of guidelines. However, further research in this field would definit
guidelines. However, further research in this field would definitely benefit de ely benefit developers and implementers.</t>
velopers and implementers.</t> <t>
This informational document has consensus for publication from the Intern
<t>This document is not an Internet Standards Track specification; it is publish et Research Task Force (IRTF) Human Right Protocol Considerations (HRPC) Researc
ed for informational purposes.</t> h Group. It has been reviewed, tried, and tested by both the research group as w
ell as researchers and practitioners from outside the research group. The resear
<t>This informational document has consensus for publication from the Internet R ch group acknowledges that the understanding of the impact of Internet protocols
esearch Task Force (IRTF) Human Right Protocol Considerations Research Group. It and architecture on society is a developing practice and is a body of research
has been reviewed, tried, and tested by both by the research group as well as b that is still ongoing. This document is not an IETF product and is not a standar
y researchers and practitioners from outside the research group. The HRPC resear d.
ch group acknowledges that the understanding of the impact of Internet protocols </t>
and architecture on society is a developing practice and is a body of research </section>
that is still in development.</t> <section anchor="human-rights-threats" numbered="true" toc="default">
<name>Human Rights Threats</name>
</section> <t>Threats to the exercise of human rights on the Internet come in many fo
<section anchor="human-rights-threats" title="Human rights threats"> rms. Protocols and standards may harm or enable the right to freedom of expressi
on; right to freedom of information; right to non-discrimination; right to equal
<t>Threats to the exercise of human rights on the Internet come in many forms. P protection; right to participate in cultural life, arts, and science; right to
rotocols and standards may harm or enable the right to freedom of expression, ri freedom of assembly and association; right to privacy; and right to security. An
ght to freedom of information, right to non-discrimination, right to equal prote end user who is denied access to certain services or content may be unable to d
ction, right to participate in cultural life, arts and science, right to freedom isclose vital information about the malpractices of a government or other author
of assembly and association, right to privacy, and the right to security. An en ity. A person whose communications are monitored may be prevented or dissuaded f
d-user who is denied access to certain services or content may be unable to disc rom exercising their right to freedom of association or participate in political
lose vital information about the malpractices of a government or other authority processes <xref target="Penney" format="default"/>. In a worst-case scenario, p
. A person whose communications are monitored may be prevented or dissuaded from rotocols that leak information can lead to physical danger. A realistic example
exercising their right to freedom of association or participate in political pr to consider is when individuals perceived as threats to the state are subjected
ocesses <xref target="Penney"/>. In a worst-case scenario, protocols that leak i to torture, extra-judicial killing, or detention on the basis of information gat
nformation can lead to physical danger. A realistic example to consider is when hered by state agencies through the monitoring of network traffic.</t>
individuals perceived as threats to the state are subjected to torture, extra-ju <t>This document presents several examples of how threats to human rights
dicial killing or detention on the basis of information gathered by state agenci materialize on the Internet. This threat modeling is inspired by "<xref target="
es through the monitoring of network traffic.</t> RFC6973" format="title"/>" <xref target="RFC6973" format="default"/>, which is b
ased on security threat analysis. This method is a work in progress and by no me
<t>This document presents several examples of how threats to human rights materi ans a perfect solution for assessing human rights risks in Internet protocols an
alize on the Internet. This threat modeling is inspired by <xref target="RFC6973 d systems. Certain specific human rights threats are indirectly considered in In
"/> Privacy Considerations for Internet Protocols, which is based on security th ternet protocols as part of the security considerations <xref target="RFC3552" f
reat analysis. This method is a work in progress and by no means a perfect solut ormat="default"/>; however, privacy considerations <xref target="RFC6973" format
ion for assessing human rights risks in Internet protocols and systems. Certain ="default"/> or reviews, let alone human rights impact assessments of protocols,
specific human rights threats are indirectly considered in Internet protocols as are neither standardized nor implemented.</t>
part of the security considerations <xref target="BCP72"/>, but privacy conside <t>Many threats, enablers, and risks are linked to different rights. This
rations <xref target="RFC6973"/> or reviews, let alone human rights impact asses is not surprising if one takes into account that human rights are interrelated,
sments of protocols, are neither standardized nor implemented.</t> interdependent, and indivisible. However, here we're not discussing all human ri
ghts because not all human rights are relevant to Information and Communication
<t>Many threats, enablers, and risks are linked to different rights. This is not Technologies (ICTs) in general and to protocols and standards in particular <xre
surprising if one takes into account that human rights are interrelated, interd f target="Orwat" format="default"/>:</t>
ependent, and indivisible. Here, however, we’re not discussing all human rights <blockquote>The main source of the values of human rights is the
because not all human rights are relevant to information and communication techn <em>International Bill of Human Rights</em> that is composed of the <em>Universa
ologies (ICTs) in general and protocols and standards in particular <xref target l Declaration of Human Rights</em> (UDHR) <xref target="UDHR" format="default"/>
="Bless"/>: “The main source of the values of human rights is the International along with the <em>International Covenant on Civil and Political Rights</em> (I
Bill of Human Rights that is composed of the Universal Declaration of Human Righ CCPR) <xref target="ICCPR" format="default"/> and the <em>International Covenant
ts <xref target="UDHR"/> along with the International Covenant on Civil and Poli on Economic, Social and Cultural Rights</em> (ICESCR) <xref target="ICESCR" for
tical Rights <xref target="ICCPR"/> and the International Covenant on Economic, mat="default"/>. In the light of several cases of Internet censorship, the UN Hu
Social and Cultural Rights <xref target="ICESCR"/>. In the light of several case man Rights Council Resolution 20/8 was adopted in 2012, affirming that "...the s
s of Internet censorship, the UN Human Rights Council Resolution 20/8 was adopte ame rights that people have offline must also be protected online..." <xref targ
d in 2012, affirming that “the same rights that people have offline must also be et="UNHRC2016" format="default"/>. In 2015, the <em>Charter of Human Rights and
protected online.” <xref target="UNHRC2016"/> In 2015, the Charter of Human Rig Principles for the Internet</em> <xref target="IRP" format="default"/> was devel
hts and Principles for the Internet <xref target="IRP"/> was developed and relea oped and released <xref target="Jorgensen" format="default"/>. According to thes
sed. According to these documents, some examples of human rights relevant for IC e documents, some examples of human rights relevant for ICT systems are <em>huma
T systems are human dignity (Art. 1 UDHR), non-discrimination (Art. 2), rights t n dignity</em> (Art. 1 UDHR), <em>non-discrimination</em> (Art. 2), <em>rights t
o life, liberty and security (Art. 3), freedom of opinion and expression (Art. 1 o life, liberty and security</em> (Art. 3), <em>freedom of opinion and expressio
9), freedom of assembly and association (Art. 20), rights to equal protection, l n</em> (Art. 19), <em>freedom of assembly and association</em> (Art. 20), <em>ri
egal remedy, fair trial, due process, presumed innocent (Art. 7–11), appropriate ghts to equal protection, legal remedy, fair trial, due process, presumed innoce
social and international order (Art. 28), participation in public affairs (Art. nt</em> (Art. 7-11), <em>appropriate social and international order</em> (Art. 2
21), participation in cultural life, protection of the moral and material inter 8), <em>participation in public affairs</em> (Art. 21), <em>participation in cul
ests resulting from any scientific, literary or artistic production of which [th tural life, protection of intellectual property</em> (Art. 27), and <em>privacy<
ey are] the author (Art. 27), and privacy (Art. 12).” A partial catalog of human /em> (Art. 12).</blockquote>
rights related to Information and Communications Technologies, including econom <t>A partial catalog of human rights related to ICTs, including economic r
ic rights, can be found in <xref target="Hill2014"/>.</t> ights, can be found in <xref target="Hill" format="default"/>.</t>
<t>This is by no means an attempt to exclude specific rights or prioritize
<t>This is by no means an attempt to exclude specific rights or prioritize some some rights over others.</t>
rights over others.</t> </section>
<section anchor="conducting-human-rights-reviews" numbered="true" toc="defau
</section> lt">
<section anchor="conducting-human-rights-reviews" title="Conducting human rights <name>Conducting Human Rights Reviews</name>
reviews"> <t>Ideally, protocol developers and collaborators should incorporate human
rights considerations into the design process itself (see <xref target="analyzi
<t>Ideally, protocol developers and collaborators should incorporate human right ng-drafts-based-on-guidelines-for-human-rights-considerations-model"/> ("Analyzi
s considerations into the design process itself (see Guidelines for human rights ng Internet-Drafts Based on Guidelines for Human Rights Considerations Model")).
considerations). This section provides guidance on how to conduct a human right This section provides guidance on how to conduct a human rights review, i.e., ga
s review, i.e., gauge the impact or potential impact of a protocol or standard o uge the impact or potential impact of a protocol or standard on human rights.</t
n human rights.</t> >
<t>Human rights reviews can be done by any participant and can take place
<t>Human rights reviews can be done by any participant, and can take place at di at different stages of the development process of an Internet-Draft. Generally s
fferent stages of the development process of an Internet-Draft. Generally speaki peaking, it is easier to influence the development of a technology at earlier st
ng, it is easier to influence the development of a technology at earlier stages ages than at later stages. This does not mean that reviews at Last Call are not
than at later stages. This does not mean that reviews at last-call are not relev relevant, but they are less likely to result in significant changes in the revie
ant, but they are less likely to result in significant changes in the reviewed d wed document.</t>
ocument.</t> <t>Human rights reviews can be done by document authors, document shepherd
s, members of review teams, advocates, or impacted communities to influence the
<t>Human rights review can be done by document authors, document shepherds, memb standards development process. IETF documents can benefit from people with diffe
ers of review teams, advocates, or impacted communities to influence the standar rent knowledge, perspectives, and backgrounds, especially since their implementa
d development process. IETF documents can benefit from people with different kno tions can impact many different communities as well.</t>
wledges, perspectives, and backgrounds, especially since their implementation ca <t>Methods for analyzing technology for specific human rights impacts are
n impact many different communities as well.</t> still quite nascent. Currently, five methods have been explored by the human rig
hts review team, often in conjunction with each other.</t>
<t>Methods for analyzing technology for specific human rights impacts are still <section anchor="analyzing-drafts-based-on-guidelines-for-human-rights-con
quite nascent. Currently, five methods have been explored by the human rights re siderations-model" numbered="true" toc="default">
view team, often in conjunction with each other:</t> <name>Analyzing Internet-Drafts Based on Guidelines for Human Rights Con
siderations Model</name>
<section anchor="analyzing-drafts-based-on-guidelines-for-human-rights-considera <t>This analysis of Internet-Drafts uses the model as described in <xref
tions-model" title="Analyzing drafts based on guidelines for human rights consid target="guidelines-for-human-rights-considerations" format="default"/>. The out
erations model"> lined categories and questions can be used to review an Internet-Draft. The adva
<t>This analysis of Internet-Drafts uses the model as described in section 4. Th ntage of this is that it provides a known overview, and document authors can go
e outlined categories and questions can be used to review an Internet-Draft. The back to this document as well as <xref target="RFC8280" format="default"/> to un
advantage of this is that it provides a known overview, and document authors ca derstand the background and the context.</t>
n go back to this document as well as <xref target="RFC8280"/> to understand the </section>
background and the context.</t> <section anchor="analyzing-drafts-based-on-their-perceived-or-speculated-i
mpact" numbered="true" toc="default">
</section> <name>Analyzing Internet-Drafts Based on Their Perceived or Speculated I
<section anchor="analyzing-drafts-based-on-their-perceived-or-speculated-impact" mpact</name>
title="Analyzing drafts based on their perceived or speculated impact"> <t>When reviewing an Internet-Draft, specific human rights impacts can b
<t>When reviewing an Internet-Draft, specific human rights impacts can become ap ecome apparent by doing a close reading of the draft and seeking to understand h
parent by doing a close reading of the draft and seeking to understand how it mi ow it might affect networks or society. While less structured than the straight
ght affect networks or society. While less structured than the straight use of t use of the human rights considerations model, this analysis may lead to new spec
he human rights considerations model, this analysis may lead to new speculative ulative understandings of links between human rights and protocols.</t>
understandings of links between human rights and protocols.</t> </section>
<section anchor="expert-interviews" numbered="true" toc="default">
</section> <name>Expert Interviews</name>
<section anchor="expert-interviews" title="Expert interviews"> <t>Interviews with document authors, active members of the working group
<t>Interviews with document authors, active members of the Working Group, or exp , or experts in the field can help explore the characteristics of the protocol a
erts in the field can help explore the characteristics of the protocol and its e nd its effects.
ffects. There are two main advantages to this approach: one the one hand, it all There are two main advantages to this approach:</t>
ows the reviewer to gain a deeper understanding of the (intended) workings of th <ol spacing="normal">
e protocol; on the other hand, it also allows for the reviewer to start a discus <li>It allows the reviewer to gain a deeper understanding of the (intended)
sion with experts or even document authors, which can help the review gain tract workings of the protocol.</li>
ion when it is published.</t> <li>It allows for the reviewer to start a discussion with experts or even d
ocument authors, which can help the review gain traction when it is published.</
</section> li>
<section anchor="interviews-with-impacted-persons-and-communities" title="Interv </ol>
iews with impacted persons and communities"> </section>
<t>Protocols impact users of the Internet. Interviews can help the reviewer unde <section anchor="interviews-with-impacted-persons-and-communities" numbere
rstand how protocols affect the people that use the protocols. Since human right d="true" toc="default">
s are best understood from the perspective of the rights-holder, this approach w <name>Interviews with Impacted Persons and Communities</name>
ill improve the understanding of the real world effects of the technology. At th <t>Protocols impact users of the Internet. Interviews can help the revie
e same time, it can be hard to attribute specific changes to a particular protoc wer understand how protocols affect the people that use the protocols. Since hum
ol, this is of course even harder when a protocol has not been (widely) deployed an rights are best understood from the perspective of the rights-holder, this ap
.</t> proach will improve the understanding of the real-world effects of the technolog
y. At the same time, it can be hard to attribute specific changes to a particula
</section> r protocol; this is of course even harder when a protocol has not been widely de
<section anchor="tracing-impacts-of-implementations" title="Tracing impacts of i ployed.</t>
mplementations"> </section>
<t>The reality of deployed protocols can be at odds with the expectations during <section anchor="tracing-impacts-of-implementations" numbered="true" toc="
the protocol design and development phase <xref target="RFC8980"/>. When a spec default">
ification already has associated running code, the code can be analyzed either i <name>Tracing Impacts of Implementations</name>
n an experimental setting or on the Internet where its impact can be observed. I <t>The reality of deployed protocols can be at odds with the expectation
n contrast to reviewing the draft text, this approach can allow the reviewer to s during the protocol design and development phase <xref target="RFC8980" format
understand how the specifications works in practice, and potentially what unknow ="default"/>. When a specification already has associated running code, the code
n or unexpected effects the technology has.</t> 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 c
</section> an allow the reviewer to understand how the specifications work in practice and
</section> potentially what unknown or unexpected effects the technology has.</t>
<section anchor="guidelines-for-human-rights-considerations" title="Guidelines f </section>
or human rights considerations"> </section>
<section anchor="guidelines-for-human-rights-considerations" numbered="true"
<t>This section provides guidance for document authors in the form of a question toc="default">
naire about protocols and how technical decisions can shape the exercise of huma <name>Guidelines for Human Rights Considerations</name>
n rights. The questionnaire may be useful at any point in the design process, pa <t>This section provides guidance for document authors in the form of a qu
rticularly after the document authors have developed a high-level protocol model estionnaire about protocols and how technical decisions can shape the exercise o
as described in <xref target="RFC4101"/>. These guidelines do not seek to repla f human rights. The questionnaire may be useful at any point in the design proce
ce any existing referenced specifications, but rather contribute to them and loo ss, particularly after the document authors have developed a high-level protocol
k at the design process from a human rights perspective.</t> model as described in <xref target="RFC4101" format="default"/>. These guidelin
es do not seek to replace any existing referenced specifications but, rather, co
<t>Protocols and Internet Standards might benefit from a documented discussion o ntribute to them and look at the design process from a human rights perspective.
f potential human rights risks arising from potential misapplications of the pro </t>
tocol or technology described in the Request For Comments (RFC). This might be c <t>Protocols and Internet Standards might benefit from a documented discus
oupled with an Applicability Statement for that RFC.</t> sion of potential human rights risks arising from potential misapplications of t
he protocol or technology described in the Request for Comments (RFC). This migh
<t>Note that the guidance provided in this section does not recommend specific p t be coupled with an Applicability Statement for that RFC.</t>
ractices. The range of protocols developed in the IETF is too broad to make reco <t>Note that the guidance provided in this section does not recommend spec
mmendations about particular uses of data or how human rights might be balanced ific practices. The range of protocols developed in the IETF is too broad to mak
against other design goals. However, by carefully considering the answers to th e recommendations about particular uses of data or how human rights might be bal
e following questions, document authors should be able to produce a comprehensiv anced against other design goals. However, by carefully considering the answers
e analysis that can serve as the basis for discussion on whether the protocol ad to the following questions, document authors should be able to produce a compre
equately takes specific human rights threats into account. This guidance is mean hensive analysis that can serve as the basis for discussion on whether the proto
t to help the thought process of a human rights analysis; it does not provide sp col adequately takes specific human rights threats into account. This guidance i
ecific directions for how to write a human rights considerations section (follow s meant to help the thought process of a human rights analysis; it does not prov
ing the example set in <xref target="RFC6973"/>).</t> ide specific directions for how to write a human rights considerations section (
following the example set in <xref target="RFC6973" format="default"/>).</t>
<t>In considering these questions, authors will need to be aware of the potentia <t>In considering these questions, authors will need to be aware of the po
l of technical advances or the passage of time to undermine protections. In gene tential of technical advances or the passage of time to undermine protections. I
ral, considerations of rights are likely to be more effective if they are consid n general, considerations of rights are likely to be more effective if they have
ered given a purpose and specific use cases, rather than as abstract absolute go a purpose and specific use cases rather than abstract, absolute goals.</t>
als.</t> <t>Also note that while the section uses the word "protocol", the principl
es identified in these questions may be applicable to other types of solutions (
<t>Also note that while the section uses the word, ‘protocol’, the principles id extensions to existing protocols, architecture for solutions to specific problem
entified in these questions may be applicable to other types of solutions (exten s, etc.).</t>
sions to existing protocols, architecture for solutions to specific problems, et <section anchor="intermediaries" numbered="true" toc="default">
c.).</t> <name>Intermediaries</name>
<t>Question(s):
<section anchor="intermediaries" title="Intermediaries">
<t>Question(s):
Does your protocol depend on or allow for protocol-specific functions at interme diary nodes?</t> Does your protocol depend on or allow for protocol-specific functions at interme diary nodes?</t>
<t>Explanation:
<t>Explanation: The end-to-end principle <xref target="Saltzer" format="default"/> holds
The end-to-end principle <xref target="Saltzer"/> holds that certain functions c that certain functions can and should be performed at "ends" of the network. <xr
an and should be performed at ‘ends’ of the network. <xref target="RFC1958"/> st ef target="RFC1958" format="default"/> states that "in very general terms, the c
ates “that in very general terms, the community believes that the goal is connec ommunity believes that the goal is connectivity ... and the intelligence is end
tivity […] and the intelligence is end to end rather than hidden in the network. to end rather than hidden in the network". There are new opportunities for failu
” When a protocol exchange includes both endpoints and an intermediary, there ar re when a protocol exchange includes both endpoints and an intermediary, especia
e new opportunities for failure, especially when the intermediary is not under c lly when the intermediary is not under control of either endpoint, or is even la
ontrol of either endpoint, or even largely invisible to it, as, for instance, in rgely invisible to it, for instance, as with intercepting HTTPS proxies <xref ta
intercepting HTTPS proxies <xref target="https-interception"/>. This pattern al rget="HTTPS-interception" format="default"/>. This pattern also contributes to o
so contributes to ossification, because the intermediaries may impose protocol r ssification because the intermediaries may impose protocol restrictions -- somet
estrictions – sometimes in violation of the specification – that prevent the end imes in violation of the specification -- that prevent the endpoints from using
points from using more modern protocols, as described in Section 9.3 of <xref ta more modern protocols, as described in <xref target="RFC8446" sectionFormat="of"
rget="RFC8446"/>.</t> section="9.3"/>.</t>
<t>Note that intermediaries are distinct from services. In the former ca
<t>Note that intermediaries are distinct from services: in the former case the t se, the third-party element is part of the protocol exchange; whereas in the lat
hird party element is part of the protocol exchange, whereas in the latter the e ter, the endpoints communicate explicitly with the service. The client/server pa
ndpoints communicate explicitly with the service. The client/server pattern prov ttern provides clearer separation of responsibilities between elements than havi
ides clearer separation of responsibilities between elements than having an inte ng an intermediary. However, even in client/server systems, it is often good pra
rmediary. However, even in client/server systems, it is often good practice to p ctice to provide for end-to-end encryption between endpoints for protocol elemen
rovide for end-to-end encryption between endpoints for protocol elements which a ts that are outside of the scope of the service, as in the design of Messaging L
re outside of the scope of the service, as in the design of MLS <xref target="I- ayer Security (MLS) <xref target="RFC9420" format="default"/>.</t>
D.ietf-mls-protocol"/>.</t> <t>Example:
Encryption between the endpoints can be used to protect the protocol from interf
<t>Example: erence by intermediaries. The encryption of transport layer information in QUIC
Encryption between the endpoints can be used to protect the protocol from interf <xref target="RFC9000" format="default"/> and of the TLS Server Name Indication
erence by intermediaries. The encryption of transport layer information in QUIC (SNI) field <xref target="I-D.ietf-tls-esni" format="default"/> are examples of
<xref target="RFC9000"/> and of the TLS Server Name Indication field <xref targe this practice. One consequence of this is to limit the extent to which network o
t="I-D.ietf-tls-esni"/> are examples of this practice. One consequence of this i perators can inspect traffic, requiring them to have control of the endpoints in
s to limit the extent to which network operators can inspect traffic, requiring order to monitor their behavior.</t>
them to have control of the endpoints in order to monitor their behavior.</t> <t>Impacts:</t>
<ul spacing="normal">
<t>Impacts:</t> <li>Right to freedom of expression</li>
<li>Right to freedom of assembly and association</li>
<t><list style="symbols"> </ul>
<t>Right to freedom of expression</t> </section>
<t>Right to freedom of assembly and association</t> <section anchor="connectivity" numbered="true" toc="default">
</list></t> <name>Connectivity</name>
<t>Questions(s):
</section> Is your protocol optimized for low-bandwidth and high-latency connections? Could
<section anchor="connectivity" title="Connectivity"> your protocol also be developed in a stateless manner?</t>
<t>Questions(s): <t>Considering the fact that network quality and conditions vary across
Is your protocol optimized for low bandwidth and high latency connections? Could geography and time, it is also important to design protocols such that they are
your protocol also be developed in a stateless manner?</t> reliable even on low-bandwidth and high-latency connections.</t>
<t>Impacts:</t>
<t>Also considering the fact that network quality and conditions vary across geo <ul spacing="normal">
graphy and time, it is also important to design protocols such that they are rel <li>Right to freedom of expression</li>
iable even on low bandwidth and high latency connections.</t> <li>Right to freedom of assembly and association</li>
</ul>
<t>Impacts:</t> </section>
<section anchor="reliability" numbered="true" toc="default">
<t><list style="symbols"> <name>Reliability</name>
<t>Right to freedom of expression</t> <t>Question(s):
<t>Right to freedom of assembly and association</t>
</list></t>
</section>
<section anchor="reliability" title="Reliability">
<t>Question(s):
Is your protocol fault tolerant? Does it downgrade gracefully, i.e., with mechan isms for fallback and/or notice? Can your protocol resist malicious degradation attempts? Do you have a documented way to announce degradation? Do you have meas ures in place for recovery or partial healing from failure? Can your protocol ma intain dependability and performance in the face of unanticipated changes or cir cumstances?</t> Is your protocol fault tolerant? Does it downgrade gracefully, i.e., with mechan isms for fallback and/or notice? Can your protocol resist malicious degradation attempts? Do you have a documented way to announce degradation? Do you have meas ures in place for recovery or partial healing from failure? Can your protocol ma intain dependability and performance in the face of unanticipated changes or cir cumstances?</t>
<t>Explanation:
Reliability and resiliency ensures that a protocol will execute its function con
sistently and resistant to error, as described, and will function without unexpe
cted results. Measures for reliability in protocols assure users that their inte
nded communication was successfully executed.</t>
<t>A system that is reliable degrades gracefully and will have a documen
ted way to announce degradation. It will also have mechanisms to recover from fa
ilure 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 e
xample, exploited TLS' ability to gracefully downgrade to non-secure cipher suit
es <xref target="FREAK" format="default"/> <xref target="Logjam" format="default
"/>; from a functional perspective, this is useful, but from a security perspect
ive, 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 de
livery, the protocol needs to safeguard timeliness.</t>
<t>Example:
In the modern IP stack structure, a reliable transport layer requires an indicat
ion that transport processing has successfully completed, such as given by TCP's
ACK message <xref target="RFC9293" format="default"/>. Similarly, an applicatio
n-layer protocol may require an application-specific acknowledgement that contai
ns, among other things, a status code indicating the disposition of the request
(see <xref target="RFC3724" format="default"/>).</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to freedom of expression</li>
<li>Right to security</li>
</ul>
</section>
<section anchor="content-signals" numbered="true" toc="default">
<name>Content Signals</name>
<t>Question(s):
Does your protocol include explicit or implicit plaintext elements, in either t
he payload or the headers, that can be used for differential treatment? Is there
a way to minimize leaking such data to network intermediaries? If not, is there
a way for deployments of the protocol to make the differential treatment (inclu
ding 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 pac
ket is carrying, then they can use that information to discriminate in favor of
one type of content and against another. This impacts users' ability to send and
receive the content of their choice.</t>
<t>As recommended in <xref target="RFC8558" format="default"/>, protocol
designers should avoid the construction of implicit signals of their content. I
n general, protocol designers should avoid adding explicit signals for intermedi
aries. In certain cases, it may be necessary to add such explicit signals, but d
esigners should only do so when they provide clear benefit to end users (see <xr
ef target="RFC8890" format="default"/> for more on the priority of constituencie
s). In these cases, the implications of those signals for human rights should be
documented.</t>
<t>Note that many protocols provide signals that are intended for endpoi
nts that can be used as implicit signals by intermediaries for traffic discrimin
ation, based on either the content (e.g., TCP port numbers) or the sender/receiv
er (IP addresses). Where possible, these should be protected from intermediaries
by encryption. In many cases (e.g., IP addresses), these signals are difficult
to remove; but in other cases, such as TLS Application Layer Protocol Negotiatio
n <xref target="RFC7301" format="default"/>, there are active efforts to protect
this data <xref target="I-D.ietf-tls-esni" format="default"/>.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to freedom of expression</li>
<li>Right to non-discrimination</li>
<li>Right to equal protection</li>
</ul>
</section>
<section anchor="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 specifica
tion allow Unicode? If so, do you accept texts in one character set (which must
be UTF-8) or several (which is dangerous for interoperability)? If charsets or e
ncodings 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" format="de
fault"/>?</t>
<t>Explanation:
Internationalization refers to the practice of making protocols, standards, and
implementations usable in different languages and scripts (see <xref target="loc
alization"/> ("Localization")). In the IETF, internationalization means to add o
r improve the handling of non-ASCII text in a protocol <xref target="RFC6365" fo
rmat="default"/>. A different perspective, more appropriate to protocols that ar
e designed for global use from the beginning, is the definition used by the Worl
d Wide Web Consortium (W3C) <xref target="W3Ci18nDef"/>:</t>
<t>Explanation: <blockquote>Internationalization is the design and development of a product, app
Reliability and resiliency ensures that a protocol will execute its function con lication or document content that enables easy localization for target audiences
sistently and error resistant as described, and function without unexpected resu that vary in culture, region, or language.</blockquote>
lt. Measures for reliability in protocols assure users that their intended commu
nication 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 gr
acefully, and if applicable, will allow for partial healing.</t>
<t>It is important here to draw a distinction between random degradation and mal
icious degradation. Some attacks against previous versions of TLS, for example,
exploited TLS’ ability to gracefully downgrade to non-secure cipher suites <xref
target="FREAK"/><xref target="Logjam"/>– from a functional perspective, this is
useful; 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 indicat
ion that transport processing has successfully completed, such as given by TCP’s
ACK message <xref target="RFC0793"/>. Similarly, an application layer protocol
may require an application-specific acknowledgment that contains, among other th
ings, a status code indicating the disposition of the request (See <xref target=
"RFC3724"/>).</t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to freedom of expression</t>
<t>Right to security</t>
</list></t>
</section>
<section anchor="content-signals" title="Content signals">
<t>Question(s):
Does your protocol include explicit or implicit plaintext elements, either in t
he payload or headers, that can be used for differential treatment? Is there a w
ay minimise leaking of such data to network intermediaries? If not, is there a w
ay for deployments of the protocol to make the differential treatment (including
prioritisation of certain traffic), if any, auditable for negative impacts on n
et neutrality?</t>
<t>Example:
When network intermediaries are able to determine the type of content that a pac
ket is carrying then they can use that information to discriminate in favor of o
ne type of content and against another. This impacts users ability to send and r
eceive the content of their choice.</t>
<t>As recommended in <xref target="RFC8558"/> protocol designers should avoid th
e construction of implicit signals of their content. In general, protocol design
ers should avoid adding explicit signals for intermediaries. In certain cases, i
t 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"/> for
more on the priority of constituencies). In these cases, the implications of tho
se signal 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, e
ither based on content (e.g., TCP port numbers) or sender/receiver (IP addresses
). Where possible, these should be protected from intermediaries by encryption.
In many cases – e.g., IP address – these signals are difficult to remove, but in
other cases, such as TLS Application Layer Protocol Negotiation <xref target="R
FC7301"/>, there are active efforts to protect this data <xref target="I-D.ietf-
tls-esni"/>.</t>
<t><list style="symbols">
<t>Right to freedom of expression</t>
<t>Right to non-discrimination</t>
<t>Right to equal protection</t>
</list></t>
</section>
<section anchor="internationalization" title="Internationalization">
<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 specifica
tion allow Unicode? If so, do you accept texts in one charset (which must be UTF
-8), or several (which is dangerous for interoperability)? If character sets 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>
<t>Explanation:
Internationalization refers to the practice of making protocols, standards, and
implementations usable in different languages and scripts (see Localization). In
the IETF, internationalization means to add or improve the handling of non-ASCI
I text in a protocol. <xref target="RFC6365"/> A different perspective, more app
ropriate to protocols that are designed for global use from the beginning, is th
e definition used by the World Wide Web Consortium (W3C):</t>
<figure><artwork><![CDATA[
"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>
<t>Many protocols that handle text only handle one charset (US-ASCII), or leave
the question of what coded character set and encoding are used up to local guess
work (which leads, of course, to interoperability problems). If multiple charset
s are permitted, they must be explicitly identified <xref target="RFC2277"/>. A
dding non-ASCII text to a protocol allows the protocol to handle more scripts, h
opefully representing users across the world. In today’s world, that is normall
y best accomplished by allowing Unicode encoded in UTF-8 only.</t>
<t>In current IETF practice <xref target="RFC2277"/>, internationalization is ai
med at user-facing strings, not protocol elements, such as the verbs used by som
e text-based protocols. (Do note that some strings are both content and protocol
elements, such as identifiers.) Although this is reasonable practice for non-u
ser visible elements, given the IETF’s mission to make the Internet a global net
work of networks, <xref target="RFC3935"/> developers should provide full and eq
ual support for all scripts and character sets in the user-facing features of pr
otocols and for any content they carry.</t>
<t>Example:
See localization</t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to freedom of expression</t>
<t>Right to political participation</t>
<t>Right to participate in cultural life, arts and science</t>
</list></t>
</section>
<section anchor="localization" title="Localization">
<t>Question(s): <t>Many protocols that handle text only handle one charset (US-ASCII) or
leave the question of what coded charset and encoding are used up to local gues
swork (which leads, of course, to interoperability problems). If multiple charse
ts are permitted, they must be explicitly identified <xref target="RFC2277" form
at="default"/>. Adding non-ASCII text to a protocol allows the protocol to hand
le more scripts, hopefully representing users across the world. In today's worl
d, that is normally best accomplished by allowing only Unicode encoded in UTF-8.
</t>
<t>In current IETF practice <xref target="RFC2277" format="default"/>, i
nternationalization 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 reaso
nable practice for non-user visible elements, developers should provide full and
equal support for all scripts and charsets in the user-facing features of proto
cols and for any content they carry.</t>
<t>Example:
See <xref target="localization"/> ("Localization").</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to freedom of expression</li>
<li>Right to political participation</li>
<li>Right to participate in cultural life, arts, and science</li>
</ul>
</section>
<section anchor="localization" numbered="true" toc="default">
<name>Localization</name>
<t>Question(s):
Does your protocol uphold the standards of internationalization? Have you made a ny concrete steps towards localizing your protocol for relevant audiences?</t> Does your protocol uphold the standards of internationalization? Have you made a ny concrete steps towards localizing your protocol for relevant audiences?</t>
<t>Explanation: "Localization refers to the adaptation of a product, app
<t>Explanation: lication or document content to meet the language, cultural and other requiremen
Localization refers to the adaptation of a product, application or document cont ts of a specific target market (a 'locale')" <xref target="W3Ci18nDef" format="d
ent to meet the language, cultural and other requirements of a specific target m efault"/>. For our purposes, it can be described as the practice of translating
arket (a locale) <xref target="W3Ci18nDef"/>. For our purposes, it can be descri an implementation to make it functional in a specific language or for users in a
bed as the practice of translating an implementation to make it functional in a specific locale (see <xref target="internationalization"/> ("Internationalizati
specific language or for users in a specific locale (see Internationalization). on")). Internationalization is related to localization, but they are not the sam
Internationalization is related to localization, but they are not the same. Inte e. Internationalization is a necessary precondition for localization.</t>
rnationalization is a necessary precondition for localization.</t> <t>Example:
The Internet is a global medium, but many of its protocols and products are deve
<t>Example: loped with certain audiences in mind that often share particular characteristics
The Internet is a global medium, but many of its protocols and products are deve like knowing how to read and write in American Standard Code for Information In
loped with a certain audience in mind, that often share particular characteristi terchange (ASCII) and knowing English. This limits the ability of a large part o
cs like knowing how to read and write in American Standard Code for Information f the world's online population from using the Internet in a way that is cultura
Interchange (ASCII) and knowing English. This limits the ability of a large part lly and linguistically accessible. An example of a standard that has taken into
of the world’s online population from using the Internet in a way that is cultu account the view that individuals like to have access to data in their preferred
rally and linguistically accessible. An example of a standard that has taken int language can be found in <xref target="RFC5646" format="default"/>. The documen
o account the view that individuals like to have access to data in their native t describes a way to label information with an identifier for the language in wh
language can be found in <xref target="RFC5646"/>. The document describes a way ich it is written. And this allows information to be presented and accessed in m
to label information with an identifier for the language in which it is written. ore than one language.</t>
And this allows information to be presented and accessed in more than one langu <t>Impacts:</t>
age.</t> <ul spacing="normal">
<li>Right to non-discrimination</li>
<t>Impacts:</t> <li>Right to participate in cultural life, arts, and science</li>
<li>Right to freedom of expression</li>
<t><list style="symbols"> </ul>
<t>Right to non-discrimination</t> </section>
<t>Right to participate in cultural life, arts and science</t> <section anchor="open-standards" numbered="true" toc="default">
<t>Right to freedom of expression</t> <name>Open Standards</name>
</list></t> <t>Question(s):
Is your protocol fully documented in a way that it could be easily implemented,
</section> improved, built upon, and/or further developed? Do you depend on proprietary cod
<section anchor="open-standards" title="Open Standards"> e for the implementation, running, or further development of your protocol? Does
your protocol favor a particular proprietary specification over technically equ
<t>Question(s): ivalent competing specification(s), for instance, by making any incorporated ven
Is your protocol fully documented in a way that it could be easily implemented, dor specification "required" or "recommended" <xref target="RFC2026" format="de
improved, built upon and/or further developed? Do you depend on proprietary code fault"/>? Do you normatively reference another standard that is behind a paywall
for the implementation, running or further development of your protocol? Does y (and could you do without it)? Are you aware of any patents that would prevent
our protocol favor a particular proprietary specification over technically-equiv your standard from being fully implemented <xref target="RFC8179" format="defaul
alent competing specification(s), for instance by making any incorporated vendor t"/> <xref target="RFC6701" format="default"/>?</t>
specification “required” or “recommended” <xref target="RFC2026"/>? Do you nor <t>Explanation:
matively reference another standard that is not available without cost (and coul The Internet was able to be developed into the global network of networks becaus
d you do without it)? Are you aware of any patents that would prevent your stand e of the existence of open, non-proprietary standards <xref target="Zittrain" fo
ard from being fully implemented <xref target="RFC8179"/> <xref target="RFC6701" rmat="default"/>. They are crucial for enabling interoperability. Yet, open stan
/>?</t> dards are not explicitly defined within the IETF. On the subject, <xref target="
RFC2026" format="default"/> states:</t>
<t>Explanation: <blockquote>Various national and international standards bodies, such as ANSI, I
The Internet was able to be developed into the global network of networks becaus SO, IEEE, and ITU-T, develop a variety of protocol and service specifications th
e of the existence of open, non-proprietary standards <xref target="Zittrain"/>. at are similar to Technical Specifications defined here [at the IETF]. National
They are crucial for enabling interoperability. Yet, open standards are not exp and international groups also publish "implementors' agreements" that are analog
licitly defined within the IETF. On the subject, <xref target="RFC2026"/> states ous to Applicability Statements, capturing a body of implementation-specific det
: “Various national and international standards bodies, such as ANSI, ISO, IEEE, ail concerned with the practical application of their standards. All of these ar
and ITU-T, develop a variety of protocol and service specifications that are si e considered to be "open external standards" for the purposes of the Internet St
milar to Technical Specifications defined at the IETF. National and internationa andards Process.</blockquote>
l groups also publish “implementors’ agreements” that are analogous to Applicabi <t>Similarly, <xref target="RFC3935" format="default"/> does not define open sta
lity Statements, capturing a body of implementation-specific detail concerned wi ndards but does emphasize the importance of an "open process", i.e.:</t>
th the practical application of their standards. All of these are considered to <blockquote>... any interested person can participate in the work, know what is
be “open external standards” for the purposes of the Internet Standards Process being decided, and make [their] voice heard on the issue.</blockquote>
.” Similarly, <xref target="RFC3935"/> does not define open standards but does e <t>Open standards (and open source software) allow users to glean inform
mphasize the importance of an “open process”, i.e., “any interested person can p ation about how the tools they are using work, including the tools' security and
articipate in the work, know what is being decided, and make [their] voice heard privacy properties. They additionally allow for permissionless innovation, whic
on the issue.”</t> h is important to maintain the freedom and ability to freely create and deploy n
ew protocols on top of the communications constructs that currently exist. It is
<t>Open standards (and open source software) allow users to glean information ab at the heart of the Internet as we know it, and to maintain its fundamentally o
out how the tools they are using work, including the tools’ security and privacy pen nature, we need to be mindful of the need for developing open standards.</t>
properties. They additionally allow for permissionless innovation, which is imp <t>All standards that need to be normatively implemented should be freel
ortant to maintain the freedom and ability to freely create and deploy new proto y available and with reasonable protection for patent infringement claims so tha
cols on top of the communications constructs that currently exist. It is at the t they can also be implemented in open source or free software. Patents have oft
heart of the Internet as we know it, and to maintain its fundamentally open natu en held back open standardization or been used against those deploying open stan
re, we need to be mindful of the need for developing open standards.</t> dards, particularly in the domain of cryptography <xref target="Newegg" format="
default"/>. An exemption of this is sometimes made when a standardized protocol
<t>All standards that need to be normatively implemented should be freely availa normatively relies on specifications produced by others Standards Development Or
ble and with reasonable protection for patent infringement claims, so it can als ganizations (SDOs) that are not freely available. Patents in open standards or i
o be implemented in open source or free software. Patents have often held back o n normative references to other standards should have a patent disclosure <xref
pen standardization or been used against those deploying open standards, particu target="Note-well" format="default"/>, royalty-free licensing <xref target="Pate
larly in the domain of cryptography <xref target="newegg"/>. An exemption of thi nt-policy" format="default"/>, or some other form of fair, reasonable, and non-d
s is sometimes made when a protocol is standardized that normatively relies on s iscriminatory terms.</t>
pecifications produced by others standards development organizations (SDOs) that <t>Example:
are not freely available. Patents in open standards or in normative references <xref target="RFC6108" format="default"/> describes a system for providing criti
to other standards should have a patent disclosure <xref target="notewell"/>, ro cal end-user notifications to web browsers, which has been deployed by Comcast,
yalty-free licensing <xref target="patentpolicy"/>, or some other form of fair, an Internet Service Provider (ISP). Such a notification system is being used to
reasonable and non-discriminatory terms.</t> provide near-immediate notifications to customers, such as to warn them that the
ir traffic exhibits patterns that are indicative of malware or virus infection.
<t>Example: There are other proprietary systems that can perform such notifications, but tho
<xref target="RFC6108"/> describes a system for providing critical end-user noti se systems utilize Deep Packet Inspection (DPI) technology. In contrast, that do
fications to web browsers, which has been deployed by Comcast, an Internet Servi cument describes a system that does not rely upon DPI and is instead based on op
ce Provider (ISP). Such a notification system is being used to provide near-imme en IETF standards and open source applications.</t>
diate notifications to customers, such as to warn them that their traffic exhibi <t>Impacts:</t>
ts patterns that are indicative of malware or virus infection. There are other p <ul spacing="normal">
roprietary systems that can perform such notifications, but those systems utiliz <li>Right to freedom of expression</li>
e Deep Packet Inspection (DPI) technology. In contrast, that document describes <li>Right to participate in cultural life, arts, and science</li>
a system that does not rely upon DPI, and is instead based on open IETF standard </ul>
s and open source applications.</t> </section>
<section anchor="heterogeneity-support" numbered="true" toc="default">
<t>Impacts:</t> <name>Heterogeneity Support</name>
<t>Question(s):
<t><list style="symbols">
<t>Right to freedom of expression</t>
<t>Right to participate in cultural life, arts and science</t>
</list></t>
</section>
<section anchor="heterogeneity-support" title="Heterogeneity Support">
<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 appl ication protocols? Is your protocol liberal in what it receives and handles? Wil l it remain usable and open if the context changes?</t> Does your protocol support heterogeneity by design? Does your protocol allow for multiple types of hardware? Does your protocol allow for multiple types of appl ication protocols? Is your protocol liberal in what it receives and handles? Wil l it remain usable and open if the context changes?</t>
<t>Explanation:
<t>Explanation: The Internet is characterized by heterogeneity on many levels: devices, nodes, r
The Internet is characterized by heterogeneity on many levels: devices and nodes outer scheduling algorithms, queue management mechanisms, routing protocols, lev
, router scheduling algorithms and queue management mechanisms, routing protocol els of multiplexing, protocol versions and implementations, and underlying link
s, levels of multiplexing, protocol versions and implementations, underlying lin layers (e.g., point-to-point, multi-access links, wireless, Fiber Distributed Da
k layers (e.g., point-to-point, multi-access links, wireless, FDDI, etc.), in th ta Interface (FDDI), etc.) in the traffic mix and in the levels of congestion at
e traffic mix and in the levels of congestion at different times and places. Mor different times and places. Moreover, as the Internet is composed of autonomous
eover, as the Internet is composed of autonomous organizations and ISPs, each wi organizations and ISPs, each with their own separate policy concerns, there is
th their own separate policy concerns, there is a large heterogeneity of adminis a large heterogeneity of administrative domains and pricing structures. As a res
trative domains and pricing structures. As a result, the heterogeneity principle ult, the heterogeneity principle proposed in <xref target="RFC1958" format="defa
proposed in <xref target="RFC1958"/> needs to be supported by design <xref targ ult"/> needs to be supported by design <xref target="FIArch" format="default"/>.
et="FIArch"/>.</t> </t>
<t>Heterogeneity support in protocols can, thus, enable a wide range of
<t>Heterogeneity support in protocols can thus enable a wide range of devices an devices and (by extension) users to participate on the network.</t>
d (by extension) users to participate on the network.</t>
<t>Example:
Heterogeneity significantly contributed to the success of the internet architect
ure <xref target="Zittrain"/>. Niels Bohr famously said: “Prediction is very dif
ficult, especially if it’s about the future”, this also holds true for future us
es of the internet architecture and infrastructure. Therefore, as a rule of thum
b it is important to - as far as possible - design your protocol for different d
evices 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 to freedom of expression</t>
<t>Right to political participation</t>
</list></t>
</section>
<section anchor="adaptability" title="Adaptability">
<t>Question(s):
Question: Is your protocol written in a modular fashion and does it facilitate o
r hamper extensibility? In this sense, does your protocol impact permissionless
innovation? (See Open Standards)</t>
<t>Explanation:
Adaptability is closely interrelated with permissionless innovation: both mainta
in the freedom and ability to freely create and deploy new protocols on top of t
he communications constructs that currently exist. It is at the heart of the Int
ernet as we know it, and to maintain its fundamentally open nature, we need to b
e mindful of the impact of protocols on maintaining or reducing permissionless i
nnovation to ensure the Internet can continue to develop.</t>
<t>Adaptability and permissionless innovation can be used to shape information n
etworks as preferenced by groups of users. Furthermore, a precondition of adapta
bility 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 innovat
ion 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 the right
to freedom of expression. Since it allows the users of the network to determine
how to assemble, collaborate, and express themselves.</t>
<t>Example: <t>Example:
WebRTC generates audio and/or video data. WebRTC can be used in different locati Heterogeneity significantly contributed to the success of the Internet architect
ons by different parties; WebRTC’s standard application programming interfaces ( ure <xref target="Zittrain" format="default"/>. There is a famous quote often at
APIs) are developed to support applications from different voice service provide tributed to Niels Bohr: "Prediction is very difficult, especially if it's about
rs. Multiple parties will have similar capabilities, in order to ensure that all the future." This also holds true for future uses of the Internet architecture a
parties can build upon existing standards these need to be adaptable, and allow nd infrastructure. Therefore, as a rule of thumb, it is important to -- as far a
for permissionless innovation.</t> s 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 r
<t>Impacts:</t> elevant to document the reasoning for that.</t>
<t>Impacts:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Right to education</t> <li>Right to freedom of expression</li>
<t>Right to science</t> <li>Right to political participation</li>
<t>Right to freedom of expression</t> </ul>
<t>Right to freedom of assembly and association</t> </section>
</list></t> <section anchor="adaptability" numbered="true" toc="default">
<name>Adaptability</name>
</section> <t>Question(s):
<section anchor="integrity" title="Integrity"> Is your protocol written in a modular fashion, and does it facilitate or hamper
extensibility? In this sense, does your protocol impact permissionless innovatio
<t>Question(s): n? (See <xref target="open-standards"/> ("Open Standards").)</t>
Does your protocol maintain, assure and/or verify the accuracy of payload data? <t>Explanation:
Does your protocol maintain and assure the consistency of data? Does your protoc Adaptability is closely interrelated with permissionless innovation: both mainta
ol in any way allow for the data to be (intentionally or unintentionally) altere in the freedom and ability to create and deploy new protocols on top of the comm
d?</t> unications constructs that currently exist. It is at the heart of the Internet a
s we know it, and to maintain its fundamentally open nature, we need to be mindf
<t>Explanation: ul of the impact of protocols on maintaining or reducing permissionless innovati
on to ensure that the Internet can continue to develop.</t>
<t>Adaptability and permissionless innovation can be used to shape infor
mation networks as groups of users prefer. Furthermore, a precondition of adapta
bility 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 innovat
ion are inherently connected to the right to education and the right to science
as well as the right to freedom of assembly and association and the right to fre
edom of 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 locati
ons by different parties; WebRTC's standard Application Programming Interfaces (
APIs) are developed to support applications from different voice service provide
rs. Multiple parties will have similar capabilities. In order to ensure that all
parties can build upon existing standards, these need to be adaptable and allow
for permissionless innovation.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to education</li>
<li>Right to science</li>
<li>Right to freedom of expression</li>
<li>Right to freedom of assembly and association</li>
</ul>
</section>
<section anchor="integrity" numbered="true" toc="default">
<name>Integrity</name>
<t>Question(s):
Does your protocol maintain, assure, and/or verify the accuracy of payload data?
Does your protocol maintain and assure the consistency of data? Does your proto
col in any way allow for the data to be (intentionally or unintentionally) alter
ed?</t>
<t>Explanation:
Integrity refers to the maintenance and assurance of the accuracy and consistenc y of data to ensure it has not been (intentionally or unintentionally) altered.< /t> Integrity refers to the maintenance and assurance of the accuracy and consistenc y of data to ensure it has not been (intentionally or unintentionally) altered.< /t>
<t>Example:
<t>Example: Integrity verification of data is important to prevent vulnerabilities and attac
Integrity verification of data is important to prevent vulnerabilities and attac ks from on-path attackers. These attacks happen when a third party (often for ma
ks from on-path attackers. These attacks happen when a third party (often for ma licious reasons) intercepts a communication between two parties, inserting thems
licious reasons) intercepts a communication between two parties, inserting thems elves in the middle and changing the content of the data. In practice, this look
elves in the middle changing the content of the data. In practice this looks as s as follows:</t>
follows:</t> <t>Alice wants to communicate with Bob.
<t>Alice wants to communicate with Bob.
Alice sends a message to Bob, which Corinne intercepts and modifies. Alice sends a message to Bob, which Corinne intercepts and modifies.
Bob cannot see that the data from Alice was altered by Corinne. 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 intercepts and alters the communication as it is sent between Alice and Bob.
Corinne is able to control the communication content.</t> Corinne is able to control the communication content.</t>
<t>Impacts:</t>
<t>Impacts:</t> <ul spacing="normal">
<li>Right to freedom of expression</li>
<t><list style="symbols"> <li>Right to security</li>
<t>Right to freedom of expression</t> </ul>
<t>Right to security</t> </section>
</list></t> <section anchor="authenticity" numbered="true" toc="default">
<name>Authenticity</name>
</section> <t>Question(s):
<section anchor="authenticity" title="Authenticity"> 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 <xre
<t>Question(s): f target="security"/> ("Security"))? If relevant, have you implemented IPsec, DN
Do you have sufficient measures to confirm the truth of an attribute of a single S Security (DNSSEC), HTTPS, and other standard security best practices?</t>
piece of data or entity? Can the attributes get garbled along the way (see secu <t>Explanation:
rity)? If relevant, have you implemented IPsec, DNS Security (DNSSEC), HTTPS and
other Standard Security Best Practices?</t>
<t>Explanation:
Authenticity ensures that data does indeed come from the source it claims to com e from. This is important to prevent certain attacks or unauthorized access and use of data.</t> Authenticity ensures that data does indeed come from the source it claims to com e 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 preve
<t>At the same time, authentication should not be used as a way to prevent heter nt heterogeneity support, as is often done for vendor lock-in or digital rights
ogeneity support, as is often done for vendor lock-in or digital rights manageme management.</t>
nt.</t> <t>Example:
Authentication of data is important to prevent vulnerabilities and attacks from
<t>Example: on-path attackers. These attacks happen when a third party (often for malicious
Authentication of data is important to prevent vulnerabilities, and attacks from reasons) intercepts a communication between two parties, inserting themselves in
on-path attackers. These attacks happen when a third party (often for malicious the middle and posing as both parties. In practice, this looks as follows:</t>
reasons) intercepts a communication between two parties, inserting themselves i <t>Alice wants to communicate with Bob.
n the middle and posing as both parties. In practice this looks as follows:</t>
<t>Alice wants to communicate with Bob.
Alice sends data to Bob. Alice sends data to Bob.
Corinne intercepts the data sent to Bob. Corinne intercepts the data sent to Bob.
Corinne reads (and potentially alters) the message 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> 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>With proper authentication, the scenario would be as follows:</t>
<t>Alice wants to communicate with Bob.
<t>Alice wants to communicate with Bob.
Alice sends data to Bob. Alice sends data to Bob.
Corinne intercepts the data sent to Bob. Corinne intercepts the data sent to Bob.
Corinne reads and alters the message to Bob. Corinne reads and alters the message to Bob.
Bob is unable to verify whether that the data came from Alice.</t> Bob is unable to verify whether that the data came from Alice.</t>
<t>Impacts:</t>
<t>Impacts:</t> <ul spacing="normal">
<li>Right to privacy</li>
<t><list style="symbols"> <li>Right to freedom of expression</li>
<t>Right to privacy</t> <li>Right to security</li>
<t>Right to freedom of expression</t> </ul>
<t>Right to security</t> </section>
</list></t> <section anchor="confidentiality" numbered="true" toc="default">
<name>Confidentiality</name>
</section> <t>Question(s):
<section anchor="confidentiality" title="Confidentiality"> Does the protocol expose the transmitted data over the wire? Does the protocol e
xpose information related to identifiers or data? If so, what does it reveal to
<t>Question(s): each protocol entity (i.e., recipients, intermediaries, and enablers) <xref targ
Does the protocol expose the transmitted data over the wire? Does the protocol e et="RFC6973" format="default"/>? What options exist for protocol implementers to
xpose information related to identifiers or data? If so, what does it reveal to choose to limit the information shared with each entity? What operational contr
each protocol entity (i.e., recipients, intermediaries, and enablers) <xref targ ols are available to limit the information shared with each entity?</t>
et="RFC6973"/>? What options exist for protocol implementers to choose to limit <t>What controls or consent mechanisms does the protocol define or requi
the information shared with each entity? What operational controls are available re before personal data or identifiers are shared or exposed via the protocol? I
to limit the information shared with each entity?</t> f no such mechanisms or controls are specified, is it expected that control and
consent will be handled outside of the protocol?</t>
<t>What controls or consent mechanisms does the protocol define or require befor <t>Does the protocol provide ways for initiators to share different piec
e personal data or identifiers are shared or exposed via the protocol? If no suc es of information with different recipients? If not, are there mechanisms that e
h mechanisms or controls are specified, is it expected that control and consent xist outside of the protocol to provide initiators with such control?</t>
will be handled outside of the protocol?</t> <t>Does the protocol provide ways for initiators to limit the sharing or
expressing of individuals' preferences to recipients or intermediaries with reg
<t>Does the protocol provide ways for initiators to share different pieces of in ard to the collection, use, or disclosure of their personal data? If not, are th
formation with different recipients? If not, are there mechanisms that exist out ere mechanisms that exist outside of the protocol to provide users with such con
side of the protocol to provide initiators with such control?</t> trol? Is it expected that users will have relationships that govern the use of t
he information (contractual or otherwise) with those who operate these intermedi
<t>Does the protocol provide ways for initiators to limit the sharing or express aries? Does the protocol prefer encryption over cleartext operation?</t>
individuals’ preferences to recipients or intermediaries with regard to the col <t>Explanation:
lection, use, or disclosure of their personal data? If not, are there mechanisms Confidentiality refers to keeping your data secret from unintended listeners <xr
that exist outside of the protocol to provide users with such control? Is it ex ef target="RFC3552" format="default"/>. The growth of the Internet depends on us
pected that users will have relationships that govern the use of the information ers having confidence that the network protects their personal data <xref target
(contractual or otherwise) with those who operate these intermediaries? Does th ="RFC1984" format="default"/>. The possibility of pervasive monitoring and surve
e protocol prefer encryption over clear text operation?</t> illance undermines users' trust and can be mitigated by ensuring confidentiality
, i.e., passive attackers should gain little or no information from observation
<t>Explanation: or inference of protocol activity <xref target="RFC7258" format="default"/> <xre
Confidentiality refers to keeping your data secret from unintended listeners <xr f target="RFC7624" format="default"/>.</t>
ef target="BCP72"/>. The growth of the Internet depends on users having confiden <t>Example:
ce that the network protects their personal data <xref target="RFC1984"/>. The p Protocols that do not encrypt their payload make the entire content of the commu
ossibility of pervasive monitoring and surveillance undermines users’ trust, and nication available to the idealized attacker along their path. Following the adv
can be mitigated by ensuring confidentiality, i.e., passive attackers should ga ice in <xref target="RFC3365" format="default"/>, most such protocols have a sec
in little or no information from observation or inference of protocol activity. ure variant that encrypts the payload for confidentiality, and these secure vari
<xref target="RFC7258"/><xref target="RFC7624"/>.</t> ants are seeing ever-wider deployment. A noteworthy exception is DNS <xref targe
t="RFC1035" format="default"/>, as DNSSEC <xref target="RFC4033" format="default
<t>Example: "/> does not have confidentiality as a requirement. This implies that, in the ab
Protocols that do not encrypt their payload make the entire content of the commu sence of the use of more recent standards like DNS over TLS <xref target="RFC785
nication available to the idealized attacker along their path. Following the adv 8" format="default"/> or DNS over HTTPS <xref target="RFC8484" format="default"/
ice in <xref target="RFC3365"/>, most such protocols have a secure variant that >, all DNS queries and answers generated by the activities of any protocol are a
encrypts the payload for confidentiality, and these secure variants are seeing e vailable to the attacker. When store-and-forward protocols are used (e.g., SMTP
ver-wider deployment. A noteworthy exception is DNS <xref target="RFC1035"/>, as <xref target="RFC5321" format="default"/>), intermediaries leave this data subje
DNSSEC <xref target="RFC4033"/> does not have confidentiality as a requirement. ct to observation by an attacker that has compromised these intermediaries, unle
This implies that, in the absence of the use of more recent standards like DNS ss the data is encrypted end-to-end by the application-layer protocol or the imp
over TLS <xref target="RFC7858"/> or DNS over HTTPS <xref target="RFC8484"/>, al lementation uses an encrypted store for this data <xref target="RFC7624" format=
l DNS queries and answers generated by the activities of any protocol are availa "default"/>.</t>
ble to the attacker. When store-and-forward protocols are used (e.g., SMTP <xref <t>Impacts:</t>
target="RFC5321"/>), intermediaries leave this data subject to observation by a <ul spacing="normal">
n attacker that has compromised these intermediaries, unless the data is encrypt <li>Right to privacy</li>
ed end-to-end by the application-layer protocol or the implementation uses an en <li>Right to security</li>
crypted store for this data <xref target="RFC7624"/>.</t> </ul>
</section>
<t>Impacts:</t> <section anchor="security" numbered="true" toc="default">
<name>Security</name>
<t><list style="symbols"> <t>Question(s):
<t>Right to privacy</t> Did you have a look at <xref target="RFC3552" format="default"> "Guidelines for
<t>Right to security</t> Writing RFC Text on Security Considerations"</xref>? Have you found any attacks
</list></t> that are somewhat related to your protocol/specification yet considered out of s
cope of your document? Would these attacks be pertinent to the human-rights-enab
</section> ling features of the Internet (as described throughout this document)?</t>
<section anchor="security" title="Security"> <t>Explanation:
Security is not a single monolithic property of a protocol or system but rather
<t>Question(s): a series of related yet somewhat independent properties. Not all of these proper
Did you have a look at Guidelines for Writing RFC Text on Security Consideration ties are required for every application. Since communications are carried out by
s <xref target="BCP72"/>? Have you found any attacks that are somewhat related t systems and access to systems is through communications channels, security goal
o your protocol/specification, yet considered out of scope of your document? Wou s obviously interlock, but they can also be independently provided <xref target=
ld these attacks be pertinent to the human rights enabling features of the Inter "RFC3552" format="default"/>.</t>
net (as described throughout this document)?</t> <t>Typically, any protocol operating on the Internet can be the target o
f passive attacks (when the attacker can access and read packets on the network)
<t>Explanation: and active attacks (when an attacker is capable of writing information to the n
Security is not a single monolithic property of a protocol or system, but rather etwork packets) <xref target="RFC3552" format="default"/>.</t>
a series of related but somewhat independent properties. Not all of these prope <t>Example:
rties are required for every application. Since communications are carried out b See <xref target="RFC3552" format="default"/>.</t>
y systems and access to systems is through communications channels, security goa <t>Impacts:</t>
ls obviously interlock, but they can also be independently provided. <xref targe <ul spacing="normal">
t="BCP72"/>.</t> <li>Right to freedom of expression</li>
<li>Right to freedom of assembly and association</li>
<t>Typically, any protocol operating on the Internet can be the target of passiv <li>Right to non-discrimination</li>
e attacks (when the attacker can access and read packets on the network); active <li>Right to security</li>
attacks (when an attacker is capable of writing information to the network pack </ul>
ets). <xref target="BCP72"/></t> </section>
<section anchor="privacy" numbered="true" toc="default">
<t>Example: <name>Privacy</name>
See <xref target="BCP72"/>.</t> <t>Question(s):
Did you have a look at the guidelines described in Section <xref target="RFC6973
<t>Impacts:</t> " sectionFormat="bare" section="7"/> of "Privacy Considerations for Internet Pro
tocols" <xref target="RFC6973"/>? Does your protocol maintain the confidentialit
<t><list style="symbols"> y of metadata? Could your protocol counter traffic analysis? Does your protocol
<t>Right to freedom of expression</t> adhere to data minimization principles? Does your document identify potentially
<t>Right to freedom of assembly and association</t> sensitive data logged by your protocol and/or for how long that needs to be ret
<t>Right to non-discrimination</t> ained for technical reasons?</t>
<t>Right to security</t> <t>Explanation:
</list></t> Privacy refers to the right of an entity (normally a person), acting on i
ts own behalf, to determine the degree to which it will interact with its enviro
</section> nment, including the degree to which the entity is willing to share its personal
<section anchor="privacy" title="Privacy"> information with others <xref target="RFC4949" format="default"/>. If a protoco
l provides insufficient privacy protection, it may have a negative impact on fre
<t>Question(s): edom of expression as users self-censor for fear of surveillance or find that th
Did you have a look at the Guidelines in the Privacy Considerations for Internet ey are unable to express themselves freely.</t>
Protocols <xref target="RFC6973"/> section 7? Does your protocol maintain the c <t>Example:
onfidentiality of metadata? Could your protocol counter traffic analysis? Does y See <xref target="RFC6973" format="default"/>.</t>
our protocol adhere to data minimization principles? Does your document identif <t>Impacts:</t>
y potentially sensitive data logged by your protocol and/or for how long that ne <ul spacing="normal">
eds to be retained for technical reasons?</t> <li>Right to freedom of expression</li>
<li>Right to privacy</li>
<t>Explanation: <li>Right to non-discrimination</li>
Privacy refers to the right of an entity (normally a person), acting on its own </ul>
behalf, to determine the degree to which it will interact with its environment, </section>
including the degree to which the entity is willing to share its personal inform <section anchor="anonymity-and-pseudonymity" numbered="true" toc="default"
ation with others. <xref target="RFC4949"/>. If a protocol provides insufficient >
privacy protection it may have a negative impact on freedom of expression as us <name>Anonymity and Pseudonymity</name>
ers self-censor for fear of surveillance, or find themselves unable to express t <t>Question(s): Does your protocol make use of identifiers? Are these
hemselves freely.</t>
<t>Example:
See <xref target="RFC6973"/></t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to freedom of expression</t>
<t>Right to privacy</t>
<t>Right to non-discrimination</t>
</list></t>
</section>
<section anchor="anonymity-and-pseudonymity" title="Anonymity and Pseudonymity">
<t>Question(s): Does your protocol make use of identifiers? Are these
identifiers persistent? Are they used across multiple contexts? Is it identifiers persistent? Are they used across multiple contexts? Is it
possible for the user to reset or rotate them without negatively possible for the user to reset or rotate them without negatively
impacting the operation fo the protocol? Are they visible to others impacting the operation of the protocol? Are they visible to others
besides the protocol endpoints? Are they tied to real-world besides the protocol endpoints? Are they tied to real-world
identities? Have you considered the Privacy Considerations for identities? Have you considered "<xref target="RFC6973" format="title"/>" <xref
Internet Protocols <xref target="RFC6973"/>, especially section 6.1.2?</t> target="RFC6973" format="default"/>, especially Section <xref target="RFC6973" s
ectionFormat="bare" section="6.1.2"/>?</t>
<t>Explanation: <t>Explanation:
Most protocols depend on the use of some kind of identifier in order to correlat e Most protocols depend on the use of some kind of identifier in order to correlat e
activity over time and space. For instance:</t> activity over time and space. For instance:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>IP addresses are used as an identity for the source and
<t>IP addresses are used as an identity for the source and destination for destination for IP datagrams.</li>
IP datagrams.</t> <li>QUIC connection identifiers are used to correlate packets
<t>QUIC connection identifiers are used to correlate packets belonging to belonging to the same connection.</li>
the same connection.</t> <li>HTTP uses cookies to correlate multiple HTTP requests from the
<t>HTTP uses cookies to correlate multiple HTTP requests from the same same client.</li>
client.</t> <li>Email uses email addresses of the form example@example.com to
<t>Email uses email addresses of the form <eref target="mailto:example@example identify senders and receivers.</li>
.com">example@example.com</eref> to identify </ul>
senders and receivers.</t> <t>In general, these identifiers serve a necessary function for protocol
</list></t> operations
<t>In general, these identifiers serve a necessary function for protocol operati
ons,
by allowing them to maintain continuity. However, they can also create privacy by allowing them to maintain continuity. However, they can also create privacy
risks. There are two major ways in which those risks manifest:</t> risks. There are two major ways in which those risks manifest:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The identifier may itself reveal the user's identity in some way
<t>The identifier may itself reveal the user’s identity in some way or be or be tied to an identifier that does, as is the case when E.164
tied to an identifier which does, as is the case when E.164 (telephone) (telephone) numbers are used as identifiers for instant messaging
numbers are used as identifiers for instant messaging systems.</t> systems.</li>
<t>While the identifier may not reveal the user’s identity, it may make <li>While the identifier may not reveal the user's identity, it may
it possible to link enough of a user’s behavior to threaten their make it possible to link enough of a user's behavior to threaten
privacy, as is the case with HTTP cookies.</t> their privacy, as is the case with HTTP cookies.</li>
</list></t> </ul>
<t>Because identifiers are necessary for protocol operation, true anonym
<t>Because identifiers are necessary for protocol operation, true anonymity ity
is very difficult to achieve, but there are practices which promote is very difficult to achieve, but there are practices that promote
user privacy even when identifiers are used.</t> user privacy even when identifiers are used.</t>
<t>Impacts:</t>
<t>Impacts:</t> <ul spacing="normal">
<li>Right to non-discrimination</li>
<t><list style="symbols"> <li>Right to freedom of expression</li>
<t>Right to non-discrimination</t> <li>Right to political participation</li>
<t>Right to freedom of expression</t> <li>Right to freedom of assembly and association</li>
<t>Right to political participation</t> </ul>
<t>Right to freedom of assembly and association</t> <section anchor="pseudonymity" numbered="true" toc="default">
</list></t> <name>Pseudonymity</name>
<t>In general, user privacy is better preserved when identifiers are
<section anchor="pseudonymity" title="Pseudonymity"> pseudonymous (not tied to a user's real-world identity).</t>
<t>Example: In the development of the IPv6 protocol, it was discussed
<t>In general, user privacy is better preserved when identifiers are to
pseudonymous (not tied to a 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 embed a Media Access Control (MAC) address into unique IP
addresses. This would make it possible for eavesdroppers and other addresses. This would make it possible for eavesdroppers and other
information collectors to identify when different addresses used in information collectors to identify when different addresses used in
different transactions actually correspond to the same node. This is different transactions actually correspond to the same node. This is
why standardization efforts like Privacy Extensions for Stateless why standardization efforts like "<xref target="RFC8981" format="title"/>" <xref
Address Autoconfiguration in IPv6 <xref target="RFC4941"/> and MAC address target="RFC8981" format="default"/> and MAC address
randomization <xref target="draft-zuniga-mac-address-randomization"/> have been randomization <xref target="I-D.ietf-madinas-mac-address-randomization" format="
default"/> have been
pursued.</t> pursued.</t>
<t>Note that it is often attractive to try to create a pseudonym from
<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 a persistent identifier. This can be very difficult to do correctly
in a way that does not allow for recovering the persistent identifiers.</t> in a way that does not allow for recovering the persistent identifiers.</t>
<t>Example: A common practice in web tracking is to "encrypt" email
<t>Example: A common practice in Web tracking is to “encrypt” email
addresses by hashing them, thus allegedly making them addresses by hashing them, thus allegedly making them
“non-personally identifying”. However, because hash functions "non-personally identifying". However, because hash functions
are public operations, it is possible to dictionary search candidate are public operations, it is possible to do a dictionary search for candidate
email addresses and recover the original address <xref target="email-hashing"/>. email addresses and recover the original address <xref target="Email-hashing" fo
</t> rmat="default"/>.</t>
</section>
</section> <section anchor="unlinkability" numbered="true" toc="default">
<section anchor="unlinkability" title="Unlinkability"> <name>Unlinkability</name>
<t>Even true pseudonymous identifiers can present a privacy risk if th
<t>Even true pseudonymous identifiers can present a privacy risk if they ey are used across a wide enough scope. User privacy is better preserved
are used across a wide enough scope. User privacy is better preserved
if identifiers have limited scope both in time and space.</t> if identifiers have limited scope both in time and space.</t>
<t>Example: An example is the Dynamic Host Configuration Protocol (DHCP) wher
<t>Example: An example is Dynamic Host Configuration Protocol (DHCP) e sending a persistent identifier as the client name was not mandatory but, in p
where sending a persistent identifier as the client name was not ractice, done by many implementations before DHCP <xref target="RFC7844" format=
mandatory but, in practice, done by many implementations, before "default"/>.</t>
<xref target="RFC7844"/>.</t> <t>Example: Third-party cookies in HTTP allow trackers to correlate
<t>Example: Third party cookies in HTTP allow trackers to correlate
HTTP traffic across sites. This is the foundation of a whole HTTP traffic across sites. This is the foundation of a whole
ecosystem of Web tracking. Increasingly, Web browsers are restricting ecosystem of web tracking. Increasingly, web browsers are restricting
the use of third party cookies in order to protect user privacy.</t> the use of third-party cookies in order to protect user privacy.</t>
</section>
</section> </section>
</section> <section anchor="censorship-resistance" numbered="true" toc="default">
<section anchor="censorship-resistance" title="Censorship resistance"> <name>Censorship Resistance</name>
<t>Question(s):
<t>Question(s): Does your protocol architecture facilitate censorship? Does it include "choke po
Does your protocol architecture facilitate censorship? Does it include “choke po ints" that are easy to use for censorship? Does it expose identifiers that can b
ints” which are easy to use for censorship? Does it expose identifiers which can e used to selectively block certain kinds of traffic? Could it be designed to be
be used to selectively block certain kinds of trafic? Could it be designed to b more censorship resistant? Does your protocol make it apparent or transparent w
e more censorship resistant? Does your protocol make it apparent or transparent hen access to a resource is restricted and why it is restricted?</t>
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 with
out the knowledge of end users <xref target="RFC7754" format="default"/>. For a
<t>Explanation: survey of censorship techniques employed across the world, see <xref target="RFC
Governments and service providers block or filter content or traffic, often with 9505" format="default"/>, which lays out protocol properties that have been expl
out the knowledge of end-users. <xref target="RFC7754"/> See <xref target="draft oited to censor access to information. Censorship resistance refers to the metho
-irtf-pearg-censorship"/> for a survey of censorship techniques employed across ds and measures to prevent Internet censorship.</t>
the world, which lays out protocol properties that have been exploited to censor <t>Example:
access to information. Censorship resistance refers to the methods and measures The current design of the Web has a number of architectural choke points where i
to prevent Internet censorship.</t> t is possible for censors to intervene. These include obtaining the control of t
he domain name itself, DNS blocking either at the protocol layer or at the resol
<t>Example: ver, IP address blocking, and blocking at the web server. There has been extensi
The current design of the Web has a number of architectural choke points where i ve work on content distribution systems, which are intended to be more censorshi
t is possible for censors to intervene. These include obtaining the control of t p resistant; and some, such as BitTorrent, are in wide use. However, these syste
he domain name itself, DNS blocking at either the protocol layer or at the resol ms may have inferior reliability and performance compared to the Web (e.g., they
ver, IP address blocking, and blocking at the Web server. There has been extensi do not support active content on the server).</t>
ve work on content distribution systems which are intended to be more censorship <t>Example:
resistant, and some, such as BitTorrent, are in wide use, but these systems may Identifiers of content exposed within a protocol might be used to facilitate cen
have inferior reliability and performance compared to the Web (e.g., they do no sorship by allowing the censor to determine which traffic to block. DNS queries,
t support active content on the server).</t> the "host" request header in an HTTP request, and the Server Name Indication (S
NI) in a Transport Layer Security (TLS) ClientHello are all examples of protocol
<t>Example: elements that can travel in plaintext and be used by censors to identify what c
Identifiers of content exposed within a protocol might be used to facilitate cen ontent a user is trying to access <xref target="RFC9505" format="default"/>. Pro
sorship by allowing the censor to determine which traffic to block. DNS queries, tocol mechanisms such as Encrypted ClientHello <xref target="I-D.ietf-tls-esni"
the “host” request header in an HTTP request, the Server Name Indication (SNI) format="default"/> or DNS over HTTPS <xref target="RFC8484" format="default"/> t
in a Transport Layer Security (TLS) ClientHello are all examples of protocol ele hat encrypt metadata provide some level of resistance to this type of protocol i
ments that can travel in plaintext and be used by censors to identify what conte nspection. Full traffic encryption systems, such as Tor <eref target="https://to
nt a user is trying to access. <xref target="draft-irtf-pearg-censorship"/>. Pro rproject.org" brackets="angle"/>, can also be used by people to access otherwise
tocol mechanisms such as Encrypted Client Hello <xref target="I-D.ietf-tls-esni" censored resources.</t>
/> or DNS over HTTPS <xref target="RFC8484"/> that encrypt metadata provide some <t>Example: As noted above, one way to censor web traffic is to require
level of resistance to this type of protocol inspection. Full traffic encryptio the server to block it or require ISPs to block requests to the server. In HTTP,
n systems such as Tor [https://torproject.org] can also be used by people access denial or restriction of access can be made apparent by the use of status code
otherwise censored resources.</t> 451, which allows server operators and intermediaries to operate with greater tr
ansparency in circumstances where issues of law or public policy affect their op
<t>Example: As noted above, one way to censor Web traffic is to require the serv eration <xref target="RFC7725" format="default"/>. If a protocol potentially ena
er to block it or require internet service providers to block requests to the se bles censorship, protocol designers should strive towards creating error codes t
rver. In HTTP, denial or restriction of access can be made apparent by the use o hat capture different scenarios (e.g., blocked due to administrative policy, una
f status code 451, which allows server operators and intermediaries to operate w vailable because of legal requirements, etc.) to minimize ambiguity for end user
ith greater transparency in circumstances where issues of law or public policy a s.</t>
ffect their operation <xref target="RFC7725"/>. If a protocol potentially enable <t>Impacts:</t>
s censorship, protocol designers should strive towards creating error codes that <ul spacing="normal">
capture different scenarios (blocked due to administrative policy, unavailable <li>Right to freedom of expression</li>
because of legal requirements, etc.) to minimize ambiguity for end-users.</t> <li>Right to political participation</li>
<li>Right to participate in cultural life, arts, and science</li>
<t>Impacts:</t> <li>Right to freedom of assembly and association</li>
</ul>
<t><list style="symbols"> </section>
<t>Right to freedom of expression</t> <section anchor="outcome-transparency" numbered="true" toc="default">
<t>Right to political participation</t> <name>Outcome Transparency</name>
<t>Right to participate in cultural life, arts, and science</t> <t>Question(s): Are the intended and foreseen effects of your protocol d
<t>Right to freedom of assembly and association</t> ocumented and easily comprehensible? Have you described the central use case(s)
</list></t> for your protocol with a clear description of expected behavior and how it may,
or may not, impact other protocols, implementations, user expectations, or behav
</section> ior? Have you reviewed other protocols that solve similar problems, or made use
<section anchor="outcome-transparency" title="Outcome Transparency"> of similar mechanisms, to see if there are lessons that can be learned from thei
r use and misuse?</t>
<t>Question(s): Are the intended and forseen effects of your protocol documented <t>Explanation: Certain technical choices may have unintended consequenc
and easily comprehensible?</t> es.</t>
<t>Example: Lack of authenticity may lead to lack of integrity and negat
<t>Explanation: Certain technical choices may have unintended consequences. Have ive externalities; of which, spam is an example. Lack of data that could be used
you described the central use case(s) for your protocol with a clear descriptio for billing and accounting can lead to so-called "free" arrangements that obscu
n of expected behavior and how it may, or may not, impact other protocols, imple re the actual costs and distribution of the costs, for example, the barter arran
mentations, user expectations, or behavior? Have you reviewed other protocols th gements that are commonly used for Internet interconnection, and the commercial
at solve similar problems, or make use of similar mechanisms, to see if there ar exploitation of personal data for targeted advertising, which is the most common
e lessons that can be learnt from their use and misuse?</t> funding model for the so-called "free" services such as search engines and soci
al networks. Unexpected outcomes might not be technical but rather architectural
<t>Example: Lack of authenticity may lead to lack of integrity and negative exte , social, or economic. Therefore, it is of importance to document the intended o
rnalities, of which spam is an example. Lack of data that could be used for bill utcomes and other possible outcomes that have been considered.</t>
ing and accounting can lead to so-called “free” arrangements which obscure the a <t>Impacts:</t>
ctual costs and distribution of the costs, for example the barter arrangements t <ul spacing="normal">
hat are commonly used for Internet interconnection; and the commercial exploitat <li>Right to freedom of expression</li>
ion of personal data for targeted advertising which is the most common funding m <li>Right to privacy</li>
odel for the so-called “free” services such as search engines and social network <li>Right to freedom of assembly and association</li>
s. Unexpected outcomes might not be technical, but rather architectural, social <li>Right to access to information</li>
or economic. Therefore it is of importance to document the intended outcomes and </ul>
other possible outcomes that have been considered.</t> </section>
<section anchor="accessibility" numbered="true" toc="default">
<t>Impacts:</t> <name>Accessibility</name>
<t>Question(s):
<t><list style="symbols"> Is your protocol designed to provide an enabling environment for all? Have you l
<t>Right to freedom of expression</t> ooked at the W3C Web Accessibility Initiative for examples and guidance <xref ta
<t>Right to privacy</t> rget="W3CAccessibility" format="default"/>?</t>
<t>Right to freedom of assembly and association</t> <t>Explanation:
<t>Right to access to information</t> Sometimes in the design of protocols, websites, web technologies, or web tools,
</list></t> 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
</section> , culture, location, or physical or mental ability. When the Internet technologi
<section anchor="accessibility" title="Accessibility"> es meet this goal, it will be accessible to people with a diverse range of heari
ng, movement, sight, and cognitive ability <xref target="W3CAccessibility" forma
<t>Question(s): t="default"/>.</t>
Is your protocol designed to provide an enabling environment for all? Have you l <t>Example:
ooked at the W3C Web Accessibility Initiative for examples and guidance?</t> The HTML protocol as defined in <xref target="HTML" format="default"/> specifica
lly requires that every image must have an alt attribute (with a few exceptions)
<t>Explanation: to ensure images are accessible for people who cannot themselves decipher non-t
Sometimes in the design of protocols, websites, web technologies, or web tools, ext content in web pages.</t>
barriers are created that exclude people from using the Web. The Internet should <t>Another example is the work done in the AVT and AVTCORE Working Group
be designed to work for all people, whatever their hardware, software, language s in the IETF that enables text conversation in multimedia, text telephony, wire
, culture, location, or physical or mental ability. When the Internet technologi less multimedia, and video communications for sign language and lipreading (i.e.
es meet this goal, it will be accessible to people with a diverse range of heari , <xref target="RFC9071" format="default"/>).</t>
ng, movement, sight, and cognitive ability. <xref target="W3CAccessibility"/></t <t>Impacts:</t>
> <ul spacing="normal">
<li>Right to non-discrimination</li>
<t>Example: <li>Right to freedom of assembly and association</li>
The HTML protocol as defined in <xref target="HTML5"/> specifically requires tha <li>Right to education</li>
t every image must have an alt attribute (with a few exceptions) to ensure image <li>Right to political participation</li>
s are accessible for people that cannot themselves decipher non-text content in </ul>
web pages.</t> </section>
<section anchor="decentralization" numbered="true" toc="default">
<t>Another example is the work done in the AVT and AVTCORE working groups in the <name>Decentralization</name>
IETF that enables text conversation in multimedia, text telephony, wireless mul <t>Question(s):
timedia and video communications for sign language and lip-reading (i.e., <xref
target="RFC9071"/>).</t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to non-discrimination</t>
<t>Right to freedom of assembly and association</t>
<t>Right to education</t>
<t>Right to political participation</t>
</list></t>
</section>
<section anchor="decentralization" title="Decentralization">
<t>Question(s):
Can your protocol be implemented without a single point of control? If applicabl e, can your protocol be deployed in a federated manner? Does your protocol creat e additional centralized points of control?</t> Can your protocol be implemented without a single point of control? If applicabl e, can your protocol be deployed in a federated manner? Does your protocol creat e additional centralized points of control?</t>
<t>Explanation:
Decentralization is one of the central technical concepts of the architecture of
the Internet and is embraced as such by the IETF <xref target="RFC3935" format=
"default"/>. It refers to the absence or minimization of centralized points of c
ontrol, a feature that is assumed to make it easy for new users to join and new
uses to unfold <xref target="Ziewitz" format="default"/>. It also reduces issues
surrounding single points of failure and distributes the network such that it c
ontinues to function even if one or several nodes are disabled. With the commerc
ialization of the Internet in the early 1990s, there has been a slow move away f
rom decentralization, to the detriment of the technical benefits of having a dec
entralized Internet. For a more detailed discussion of this topic, please see <x
ref target="I-D.arkko-iab-internet-consolidation" format="default"/>.</t>
<t>Example:
The bits traveling the Internet are increasingly susceptible to monitoring and c
ensorship from both governments and ISPs as well as third (malicious) parties. T
he ability to monitor and censor is further enabled by the increased centralizat
ion 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-I
P protocols using peer-to-peer technology in combination with Distributed Hash T
able (DHT) for scalability are examples of how protocols can preserve decentrali
zation <xref target="I-D.pouwelse-censorfree-scenarios" format="default"/>.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to freedom of expression</li>
<li>Right to freedom of assembly and association</li>
</ul>
</section>
<section anchor="remedy" numbered="true" toc="default">
<name>Remedy</name>
<t>Question(s): Can your protocol facilitate a negatively impacted party
's right to remedy without disproportionately impacting other parties' human rig
hts, 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" format="default"/>. Access to remedy may help victims of human rights viol
ations in seeking justice or allow law enforcement agencies to identify a possib
le violator. However, current mechanisms in protocols that try to enable "attrib
ution" 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" format="default"/>
. Considering the potential adverse impact of attribution on the right to privac
y 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 a
s a means to enable the human right to remedy might help in identifying a violat
or of human rights and provide access to remedy, but this would disproportionate
ly affect all users right to privacy, anonymous expression, and association.
Furthermore, there are some recent advances in enabling abuse detection in end-t
o-end encrypted messaging systems, which also carry some risk to users' privacy
<xref target="Messenger-franking" format="default"/> <xref target="Hecate" forma
t="default"/>.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to remedy</li>
<li>Right to security</li>
<li>Right to privacy</li>
</ul>
</section>
<section anchor="misc-considerations" numbered="true" toc="default">
<name>Miscellaneous Considerations</name>
<t>Question(s): Have you considered potential negative consequences (ind
ividual or societal) that your protocol or document might have?</t>
<t>Explanation: Publication of a particular RFC under a certain status h
as consequences. Publication as an Internet Standard as part of the Standards Tr
ack may signal to implementers that the specification has a certain level of mat
urity, operational experience, and consensus. Similarly, publication of a speci
fication as an experimental document not part of the Standards Track would signa
l to the community that the document "may not be intended to be an Internet Stan
dard, or it may be intended for eventual standardization but not yet ready" for
wide deployment <xref target="RFC2026" format="default"/>. The extent of the dep
loyment, and consequently its overall impact on end users, may depend on the doc
ument status presented in the RFC. See <xref target="RFC2026" format="default"/>
and updates to it for a fuller explanation.</t>
</section>
</section>
<section anchor="document-status" numbered="true" toc="default">
<name>Document Status</name>
<t>This research group document lays out best practices and guidelines for
human rights reviews of network protocols, architectures, and other Internet-Dr
afts and RFCs.</t>
</section>
<t>Explanation: <section anchor="security-considerations" numbered="true" toc="default">
Decentralization is one of the central technical concepts of the architecture of <name>Security Considerations</name>
the Internet, and is embraced as such by the IETF <xref target="RFC3935"/>. It <t>Article three of the "Universal Declaration of Human Rights" reads: "Ev
refers to the absence or minimization of centralized points of control, a featur eryone has the right to life, liberty and security of person" <xref target="UDHR
e that is assumed to make it easy for new users to join and new uses to unfold < " format="default"/>. This article underlines the importance of security and its
xref target="Brown"/>. It also reduces issues surrounding single points of failu interrelation with human life and liberty; but since human rights are indivisib
re, and distributes the network such that it continues to function even if one o le, interrelated, and interdependent, security is also closely linked to other h
r several nodes are disabled. With the commercialization of the Internet in the uman rights and freedoms. This document seeks to strengthen human rights, freedo
early 1990s, there has been a slow move away from decentralization, to the detri ms, and security by relating and translating these concepts to concepts and prac
ment of the technical benefits of having a decentralized Internet. For a more de tices as they are used in Internet protocol and architecture development. The ai
tailed discussion of this topic, please see <xref target="arkkoetal"/>.</t> m of this is to secure human rights and thereby improve the sustainability, usab
ility, and effectiveness of the network. The document seeks to achieve this by p
<t>Example: roviding guidelines as done in <xref target="conducting-human-rights-reviews" fo
The bits traveling the Internet are increasingly susceptible to monitoring and c rmat="default"/> of this document.</t>
ensorship, from both governments and ISPs, as well as third (malicious) parties. </section>
The ability to monitor and censor is further enabled by the increased centraliz <section anchor="iana-considerations" numbered="true" toc="default">
ation of the network that creates central infrastructure points that can be tapp <name>IANA Considerations</name>
ed into. The creation of peer-to-peer networks and the development of voice-over <t>This document has no IANA actions.</t>
-IP protocols using peer-to-peer technology in combination with distributed hash </section>
table (DHT) for scalability are examples of how protocols can preserve decentra <section anchor="research-group-information" numbered="true" toc="default">
lization <xref target="Pouwelse"/>.</t> <name>Research Group Information</name>
<t>The discussion list for the IRTF Human Rights Protocol Considerations
<t>Impacts:</t> Research Group is located at the e-mail address: <eref
target="mailto:hrpc@ietf.org" brackets="angle"/>.</t>
<t><list style="symbols"> <t>Information on the group and information on how to subscribe to the
<t>Right to freedom of expression</t> list is at: <eref target="https://www.irtf.org/mailman/listinfo/hrpc"
<t>Right to freedom of assembly and association</t> brackets="angle"/>.</t>
</list></t> <t>Archives of the list can be found at: <eref
target="https://mailarchive.ietf.org/arch/browse/hrpc/"
</section> brackets="angle"/>.</t>
<section anchor="remedy" title="Remedy"> </section>
<t>Question(s): Can your protocol facilitate a negatively impacted party’s right
to remedy without disproportionately impacting other parties’ human rights, esp
ecially 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"/>.
Access to remedy may help victims of human rights violations in seeking justice
, or allow law enforcement agencies to identify a possible violator. However, cu
rrent mechanisms in protocols that try to enable ‘attribution’ to individuals im
pede 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 free
dom of expression <xref target="Kaye"/>. Considering the potential adverse impac
t of attribution on the right to privacy and freedom of expression, enabling att
ribution on an individual level is most likely not consistent with human rights.
</t>
<t>Example: Adding personally identifiable information to data streams as a mean
s to enable the human right to remedy might help in identifying a violator of hu
man rights and provide access to remedy, but this would disproportionally affect
all users right to privacy, anonymous expression, and association.
Furthermore, there are some recent advances in enabling abuse detection in end-t
o-end encrypted messaging systems, which also carry some risk to users’ privacy
<xref target="messenger-franking"/><xref target="hecate"/>.</t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to remedy</t>
<t>Right to security</t>
<t>Right to privacy</t>
</list></t>
</section>
<section anchor="misc-considerations" title="Misc. considerations">
<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 conse
quences. Publication as an Internet Standard as part of the Standards Track may
signal to implementers that the specification has a certain level of maturity, o
perational experience, and consensus. Similarly, publication of a specification
an experimental document as part of the non-standards track would signal to the
community that the document “may be intended for eventual standardization but [m
ay] not yet [be] ready” for wide deployment. The extent of the deployment, and c
onsequently its overall impact on end-users, may depend on the document status p
resented in the RFC. See <xref target="BCP9"/> and updates to it for a fuller ex
planation.</t>
</section>
</section>
<section anchor="document-status" title="Document Status">
<t>This RG document lays out best practices and guidelines for human rights revi
ews of network protocols, 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, Far
zaneh Badii, Sandra Braman, Colin Perkins, John Curran, Eliot Lear, Mallory Knod
el, 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">
<t>Article three of the Universal Declaration of Human Rights reads: “Everyone h
as the right to life, liberty and security of person.”. This article underlines
the importance of security and its interrelation with human life and liberty, bu
t since human rights are indivisible, interrelated and interdependent, security
is also closely linked to other human rights and freedoms. This document seeks t
o strengthen human rights, freedoms, and security by relating and translating th
ese 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 do
cument seeks to achieve this by providing guidelines as done in section three of
this document.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section anchor="research-group-information" title="Research Group Information">
<t>The discussion list for the IRTF Human Rights Protocol Considerations Researc
h Group is located at the e-mail address <eref target="mailto:hrpc@ietf.org">hrp
c@ietf.org</eref>. Information on the group and information on how to subscribe
to the list is at
<eref target="https://www.irtf.org/mailman/listinfo/hrpc">https://www.irtf.org/m
ailman/listinfo/hrpc</eref></t>
<t>Archives of the list can be found at:
<eref target="https://www.irtf.org/mail-archive/web/hrpc/current/index.html">htt
ps://www.irtf.org/mail-archive/web/hrpc/current/index.html</eref></t>
</section>
</middle> </middle>
<back> <back>
<references title='Informative References'> <displayreference target="I-D.pouwelse-censorfree-scenarios" to="Pouwelse"/>
<displayreference target="I-D.ietf-madinas-mac-address-randomization" to="MA
<reference anchor='RFC0793' target='https://www.rfc-editor.org/info/rfc793'> C-ADDRESS-RANDOMIZATION"/>
<front> <displayreference target="I-D.arkko-iab-internet-consolidation" to="Arkko"/>
<title>Transmission Control Protocol</title> <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
<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 i
n 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='Carpent
er'/>
<date month='June' year='1996'/>
<abstract>
<t>The Internet and its architecture have grown in evolutionary fashion fr
om modest beginnings, rather than from a Grand Plan. While this process of evolu
tion is one of the main reasons for the technology's success, it nevertheless se
ems useful to record a snapshot of the current principles of the Internet archit
ecture. 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 in
formation for the Internet community. This memo does not specify an Internet sta
ndard 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</organizat
ion>
</author>
<date month='August' year='1996'/>
<abstract>
<t>The Internet Architecture Board (IAB) and the Internet Engineering Stee
ring Group (IESG), the bodies which oversee architecture and standards for the I
nternet, are concerned by the need for increased protection of international com
mercial transactions on the Internet, and by the need to offer all Internet user
s 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 standa
rdization process, the requirements for moving a document between stages and the
types of documents used during this process. This document specifies an Interne
t 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 Eng
ineering Steering Group (IESG) towards the standardization efforts in the Intern
et Engineering Task Force (IETF) in order to help Internet protocols fulfill the
se 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 Stan
dard 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'> <references>
<front> <name>Informative References</name>
<title>The Rise of the Middle and the Future of End-to-End: Reflections on t
he 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 Int
ernet. In this document, we briefly examine the development of the end-to-end pr
inciple as it has been applied to the Internet architecture over the years. We d
iscuss 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 su
pports, 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'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.929
<front> 3.xml"/>
<title>A Mission Statement for the IETF</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103
<author fullname='H. Alvestrand' initials='H.' surname='Alvestrand'/> 5.xml"/>
<date month='October' year='2004'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.195
<abstract> 8.xml"/>
<t>This memo gives a mission statement for the IETF, tries to define the t <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.198
erms used in the statement sufficiently to make the mission statement understand 4.xml"/>
able and useful, argues why the IETF needs a mission statement, and tries to cap <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.202
ture some of the debate that led to this point. This document specifies an Inter 6.xml"/>
net Best Current Practices for the Internet Community, and requests discussion a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.227
nd suggestions for improvements.</t> 7.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.336
</front> 5.xml"/>
<seriesInfo name='BCP' value='95'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.355
<seriesInfo name='RFC' value='3935'/> 2.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC3935'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.372
</reference> 4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.393
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.403
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.410
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.898
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.494
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.532
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.564
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.610
8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.636
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.670
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.697
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.725
8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.762
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.772
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.784
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.785
8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.828
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.844
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.848
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.898
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.775
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.900
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.907
1.xml"/>
<reference anchor='RFC8179' target='https://www.rfc-editor.org/info/rfc8179'> <reference anchor="UDHR" target="https://www.un.org/en/about-us/universal-
<front> declaration-of-human-rights">
<title>Intellectual Property Rights in IETF Technology</title> <front>
<author fullname='S. Bradner' initials='S.' surname='Bradner'/> <title>Universal Declaration of Human Rights</title>
<author fullname='J. Contreras' initials='J.' surname='Contreras'/> <author>
<date month='May' year='2017'/> <organization>United Nations General Assembly</organization>
<abstract> </author>
<t>The IETF policies about Intellectual Property Rights (IPR), such as pat <date month="December" year="1948"/>
ent rights, relative to technologies developed in the IETF are designed to ensur </front>
e that IETF working groups and participants have as much information as possible </reference>
about any IPR constraints on a technical proposal as early as possible in the d
evelopment 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 wo
rked 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 Se
ction 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'> <reference anchor="Orwat">
<front> <front>
<title>DNS Security Introduction and Requirements</title> <title>Values and Networks: Steps Toward Exploring their Relationships
<author fullname='R. Arends' initials='R.' surname='Arends'/> </title>
<author fullname='R. Austein' initials='R.' surname='Austein'/> <author initials="C." surname="Orwat">
<author fullname='M. Larson' initials='M.' surname='Larson'/> <organization/>
<author fullname='D. Massey' initials='D.' surname='Massey'/> </author>
<author fullname='S. Rose' initials='S.' surname='Rose'/> <author initials="R." surname="Bless">
<date month='March' year='2005'/> <organization/>
<abstract> </author>
<t>The Domain Name System Security Extensions (DNSSEC) add data origin aut <date month="May" year="2016"/>
hentication and data integrity to the Domain Name System. This document introduc </front>
es these extensions and describes their capabilities and limitations. This docum <refcontent>ACM SIGCOMM Computer Communication Review, vol. 46, no. 2, p
ent also discusses the services that the DNS security extensions do and do not p p 25-31</refcontent>
rovide. Last, this document describes the interrelationships between the documen <seriesInfo name="DOI" value="10.1145/2935634.2935640"/>
ts that collectively describe DNSSEC. [STANDARDS-TRACK]</t> </reference>
</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'> <reference anchor="Ziewitz">
<front> <front>
<title>Writing Protocol Models</title> <title>A Prehistory of Internet Governance</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'/> <author initials="M." surname="Ziewitz">
<author> <organization/>
<organization abbrev='IAB'>Internet Architecture Board</organization> </author>
</author> <author initials="I." surname="Brown">
<date month='June' year='2005'/> <organization/>
<abstract> </author>
<t>The IETF process depends on peer review. However, IETF documents are ge <date month="April" year="2013"/>
nerally written to be useful for implementors, not reviewers. In particular, whi </front>
le great care is generally taken to provide a complete description of the state <refcontent>Research Handbook on Governance of the Internet, edited by I
machines and bits on the wire, this level of detail tends to get in the way of i an Brown. Cheltenham: Edward Elgar Publishing</refcontent>
nitial understanding. This document describes an approach for providing protocol <seriesInfo name="DOI" value="10.4337/9781849805025.00008"/>
"models" that allow reviewers to quickly grasp the essence of a system. This me </reference>
mo 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'> <reference anchor="Note-well" target="https://www.ietf.org/about/note-well
<front> /">
<title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</t <front>
itle> <title>Note Well</title>
<author fullname='T. Narten' initials='T.' surname='Narten'/> <author>
<author fullname='R. Draves' initials='R.' surname='Draves'/> <organization>IETF</organization>
<author fullname='S. Krishnan' initials='S.' surname='Krishnan'/> </author>
<date month='September' year='2007'/> </front>
<abstract> </reference>
<t>Nodes use IPv6 stateless address autoconfiguration to generate addresse
s using a combination of locally available information and information advertise
d by routers. Addresses are formed by combining network prefixes with an interfa
ce identifier. On an interface that contains an embedded IEEE Identifier, the in
terface identifier is typically derived from it. On other interface types, the i
nterface identifier is generated through other means, for example, via random nu
mber generation. This document describes an extension to IPv6 stateless address
autoconfiguration for interfaces whose interface identifier is derived from an I
EEE identifier. Use of the extension causes nodes to generate global scope addre
sses from interface identifiers that change over time, even in cases where the i
nterface contains an embedded IEEE identifier. Changing the interface identifier
(and the global scope addresses generated from it) over time makes it more diff
icult for eavesdroppers and other information collectors to identify when differ
ent addresses used in different transactions actually correspond to the same nod
e. [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'> <reference anchor="IRP" target="https://internetrightsandprinciples.org/campa
<front> ign/">
<title>Internet Security Glossary, Version 2</title> <front>
<author fullname='R. Shirey' initials='R.' surname='Shirey'/> <title>10 Internet Rights &amp; Principles</title>
<date month='August' year='2007'/> <author>
<abstract> <organization>Internet Rights and Principles Dynamic Coalition</orga
<t>This Glossary provides definitions, abbreviations, and explanations of nization>
terminology for information system security. The 334 pages of entries offer reco </author>
mmendations to improve the comprehensibility of written material that is generat </front>
ed in the Internet Standards Process (RFC 2026). The recommendations follow the </reference>
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 sens
e; (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 technol
ogy 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'> <reference anchor="ICCPR" target="https://www.ohchr.org/en/instruments-mec
<front> hanisms/instruments/international-covenant-civil-and-political-rights">
<title>Simple Mail Transfer Protocol</title> <front>
<author fullname='J. Klensin' initials='J.' surname='Klensin'/> <title>International Covenant on Civil and Political Rights</title>
<date month='October' year='2008'/> <author>
<abstract> <organization>United Nations General Assembly</organization>
<t>This document is a specification of the basic protocol for Internet ele </author>
ctronic mail transport. It consolidates, updates, and clarifies several previous <date month="December" year="1966"/>
documents, making all or parts of most of them obsolete. It covers the SMTP ext </front>
ension mechanisms and best practices for the contemporary Internet, but does not </reference>
provide details about particular extensions. Although SMTP was designed as a ma
il transport and delivery protocol, this specification also contains information
that is important to its use as a "mail submission" protocol for "split-UA" (Us
er 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'> <reference anchor="Saltzer">
<front> <front>
<title>Tags for Identifying Languages</title> <title>End-to-end arguments in system design</title>
<author fullname='A. Phillips' initials='A.' role='editor' surname='Phillips <author initials="J. H." surname="Saltzer">
'/> <organization/>
<author fullname='M. Davis' initials='M.' role='editor' surname='Davis'/> </author>
<date month='September' year='2009'/> <author initials="D. P." surname="Reed">
<abstract> <organization/>
<t>This document describes the structure, content, construction, and seman </author>
tics of language tags for use in cases where it is desirable to indicate the lan <author initials="D. D." surname="Clark">
guage used in an information object. It also describes how to register values fo <organization/>
r use in language tags and the creation of user-defined extensions for private i </author>
nterchange. This document specifies an Internet Best Current Practices for the I <date month="November" year="1984"/>
nternet Community, and requests discussion and suggestions for improvements.</t> </front>
</abstract> <refcontent>ACM Transactions on Computer Systems, vol. 2, no. 4, pp 277-
</front> 288</refcontent>
<seriesInfo name='BCP' value='47'/> <seriesInfo name="DOI" value="10.1145/357401.357402"/>
<seriesInfo name='RFC' value='5646'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC5646'/>
</reference>
<reference anchor='RFC6108' target='https://www.rfc-editor.org/info/rfc6108'> <reference anchor="ICESCR" target="https://www.ohchr.org/en/instruments-me
<front> chanisms/instruments/international-covenant-economic-social-and-cultural-rights"
<title>Comcast's Web Notification System Design</title> >
<author fullname='C. Chung' initials='C.' surname='Chung'/> <front>
<author fullname='A. Kasyanov' initials='A.' surname='Kasyanov'/> <title>International Covenant on Economic, Social and Cultural Rights<
<author fullname='J. Livingood' initials='J.' surname='Livingood'/> /title>
<author fullname='N. Mody' initials='N.' surname='Mody'/> <author>
<author fullname='B. Van Lieu' initials='B.' surname='Van Lieu'/> <organization>United Nations General Assembly</organization>
<date month='February' year='2011'/> </author>
<abstract> <date month="December" year="1966"/>
<t>The objective of this document is to describe a method of providing cri </front>
tical end-user notifications to web browsers, which has been deployed by Comcast </reference>
, an Internet Service Provider (ISP). Such a notification system is being used t
o provide near-immediate notifications to customers, such as to warn them that t
heir traffic exhibits patterns that are indicative of malware or virus infection
. There are other proprietary systems that can perform such notifications, but t
hose 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 b
ased in open IETF standards and open source applications. This document is not a
n Internet Standards Track specification; it is published for informational purp
oses.</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'> <reference anchor="Penney" target="https://papers.ssrn.com/sol3/papers.cfm?abstr
<front> act_id=2769645">
<title>IP Flow Anonymization Support</title> <front>
<author fullname='E. Boschi' initials='E.' surname='Boschi'/> <title>Chilling Effects: Online Surveillance and Wikipedia Use</title>
<author fullname='B. Trammell' initials='B.' surname='Trammell'/> <author initials="J." surname="Penney">
<date month='May' year='2011'/> <organization/>
<abstract> </author>
<t>This document describes anonymization techniques for IP flow data and t <date month="September" year="2016"/>
he export of anonymized data using the IP Flow Information Export (IPFIX) protoc </front>
ol. It categorizes common anonymization schemes and defines the parameters neede <refcontent>Berkeley Technology Law Journal, vol. 31, no. 1, pp 117-182</
d to describe them. It provides guidelines for the implementation of anonymized refcontent>
data export and storage over IPFIX, and describes an information model and Optio <seriesInfo name="DOI" value="10.15779/Z38SS13"/>
ns- based method for anonymization metadata export within the IPFIX protocol or </reference>
storage in IPFIX Files. This document defines an Experimental Protocol for the I
nternet 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'> <reference anchor="UNHRC2016" target="https://digitallibrary.un.org/record
<front> /845728?ln=en">
<title>Terminology Used in Internationalization in the IETF</title> <front>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/> <title>The promotion, protection and enjoyment of human rights on the
<author fullname='J. Klensin' initials='J.' surname='Klensin'/> Internet</title>
<date month='September' year='2011'/> <author>
<abstract> <organization>United Nations Human Rights Council</organization>
<t>This document provides a list of terms used in the IETF when discussing </author>
internationalization. The purpose is to help frame discussions of international <date month="June" year="2016"/>
ization in the various areas of the IETF and to help introduce the main concepts </front>
to IETF participants. This memo documents an Internet Best Current Practice.</t <refcontent>A/HRC/32/L.20</refcontent>
> </reference>
</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'> <reference anchor="W3Ci18nDef" target="https://www.w3.org/International/qu
<front> estions/qa-i18n.en">
<title>Sanctions Available for Application to Violators of IETF IPR Policy</ <front>
title> <title>Localization vs. Internationalization</title>
<author fullname='A. Farrel' initials='A.' surname='Farrel'/> <author initials="R" surname="Ishida">
<author fullname='P. Resnick' initials='P.' surname='Resnick'/> <organization>W3C</organization>
<date month='August' year='2012'/> </author>
<abstract> <author initials="S" surname="Miller">
<t>The IETF has developed and documented policies that govern the behavior <organization>Boeing</organization>
of all IETF participants with respect to Intellectual Property Rights (IPR) abo </author>
ut which they might reasonably be aware.</t> <date month="December" year="2005"/>
<t>The IETF takes conformance to these IPR policies very seriously. Howeve </front>
r, there has been some ambiguity as to what the appropriate sanctions are for th </reference>
e violation of these policies, and how and by whom those sanctions are to be app
lied.</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'> <reference anchor="Patent-policy" target="https://www.w3.org/Consortium/Pa
<front> tent-Policy-20040205/">
<title>Privacy Considerations for Internet Protocols</title> <front>
<author fullname='A. Cooper' initials='A.' surname='Cooper'/> <title>W3C Patent Policy</title>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/> <author initials="D" surname="Weitzner">
<author fullname='B. Aboba' initials='B.' surname='Aboba'/> <organization>W3C</organization>
<author fullname='J. Peterson' initials='J.' surname='Peterson'/> </author>
<author fullname='J. Morris' initials='J.' surname='Morris'/> <date month="February" year="2004"/>
<author fullname='M. Hansen' initials='M.' surname='Hansen'/> </front>
<author fullname='R. Smith' initials='R.' surname='Smith'/> <refcontent>W3C Recommendation</refcontent>
<date month='July' year='2013'/> </reference>
<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 sugg
ests 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'> <!-- [I-D.pouwelse-censorfree-scenarios] IESG state: Expired Long way used to in
<front> clude editor role-->
<title>Pervasive Monitoring Is an Attack</title> <reference anchor="I-D.pouwelse-censorfree-scenarios" target="https://datatracke
<author fullname='S. Farrell' initials='S.' surname='Farrell'/> r.ietf.org/doc/html/draft-pouwelse-censorfree-scenarios-02">
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/> <front>
<date month='May' year='2014'/> <title>Media without censorship (CensorFree) scenarios</title>
<abstract> <author initials="J." surname="Pouwelse" fullname="Johan Pouwelse" role="editor"
<t>Pervasive monitoring is a technical attack that should be mitigated in >
the design of IETF protocols, where possible.</t> <organization>Delft University of Technology</organization>
</abstract> </author>
</front> <date month="October" day="22" year="2012"/>
<seriesInfo name='BCP' value='188'/> </front>
<seriesInfo name='RFC' value='7258'/> <seriesInfo name="Internet-Draft" value="draft-pouwelse-censorfree-scenarios-02"
<seriesInfo name='DOI' value='10.17487/RFC7258'/> />
</reference> </reference>
<reference anchor='RFC7624' target='https://www.rfc-editor.org/info/rfc7624'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9505.xml"
<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, severa
l classes of attacks on Internet communications have been discovered. In this do
cument, we develop a threat model that describes these attacks on Internet confi
dentiality. We assume an attacker that is interested in undetected, indiscrimina
te 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'> <!-- [I-D.ietf-madinas-mac-address-randomization] IESG state: RFC Ed Queue Long
<front> way used to include editor role-->
<title>An HTTP Status Code to Report Legal Obstacles</title> <reference anchor="I-D.ietf-madinas-mac-address-randomization" target="https://d
<author fullname='T. Bray' initials='T.' surname='Bray'/> atatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-15">
<date month='February' year='2016'/> <front>
<abstract> <title>Randomized and Changing MAC Address State of Affairs</title>
<t>This document specifies a Hypertext Transfer Protocol (HTTP) status cod <author initials="J. C." surname="Zúñiga" fullname="Juan-Carlos Zúñiga">
e for use when resource access is denied as a consequence of legal demands.</t> <organization>CISCO</organization>
</abstract> </author>
</front> <author initials="C. J." surname="Bernardos" fullname="Carlos J. Bernardos" role
<seriesInfo name='RFC' value='7725'/> ="editor">
<seriesInfo name='DOI' value='10.17487/RFC7725'/> <organization>Universidad Carlos III de Madrid</organization>
</author>
<author initials="A." surname="Andersdotter" fullname="Amelia Andersdotter">
<organization>Safespring AB</organization>
</author>
<date month="July" day="15" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-madinas-mac-address-randomiz
ation-15"/>
</reference> </reference>
<reference anchor='RFC7844' target='https://www.rfc-editor.org/info/rfc7844'> <reference anchor="HTML" target="https://html.spec.whatwg.org/multipage/">
<front> <front>
<title>Anonymity Profiles for DHCP Clients</title> <title>HTML Living Standard</title>
<author fullname='C. Huitema' initials='C.' surname='Huitema'/> <author>
<author fullname='T. Mrugalski' initials='T.' surname='Mrugalski'/> <organization>WHATWG</organization>
<author fullname='S. Krishnan' initials='S.' surname='Krishnan'/> </author>
<date month='May' year='2016'/> <date month="August" year="2024"/>
<abstract> </front>
<t>Some DHCP options carry unique identifiers. These identifiers can enabl </reference>
e device tracking even if the device administrator takes care of randomizing oth
er potential identifications like link-layer addresses or IPv6 addresses. The an
onymity profiles are designed for clients that wish to remain anonymous to the v
isited network. The profiles provide guidelines on the composition of DHCP or DH
CPv6 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'> <reference anchor="Zittrain" target="https://dash.harvard.edu/handle/1/445
<front> 5262">
<title>Specification for DNS over Transport Layer Security (TLS)</title> <front>
<author fullname='Z. Hu' initials='Z.' surname='Hu'/> <title>The Future of the Internet and How to Stop It</title>
<author fullname='L. Zhu' initials='L.' surname='Zhu'/> <author initials="J." surname="Zittrain">
<author fullname='J. Heidemann' initials='J.' surname='Heidemann'/> <organization/>
<author fullname='A. Mankin' initials='A.' surname='Mankin'/> </author>
<author fullname='D. Wessels' initials='D.' surname='Wessels'/> <date year="2008"/>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/> </front>
<date month='May' year='2016'/> <refcontent>Yale University Press</refcontent>
<abstract> </reference>
<t>This document describes the use of Transport Layer Security (TLS) to pr
ovide privacy for DNS. Encryption provided by TLS eliminates opportunities for e
avesdropping and on-path tampering with DNS queries in the network, such as disc
ussed in RFC 7626. In addition, this document specifies two usage profiles for D
NS over TLS and provides advice on performance considerations to minimize overhe
ad 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'> <reference anchor="FIArch" target="https://link.springer.com/chapter/10.10
<front> 07/978-3-642-30241-1_6">
<title>Research into Human Rights Protocol Considerations</title> <front>
<author fullname='N. ten Oever' initials='N.' surname='ten Oever'/> <title>Design Principles for the Future Internet Architecture</title>
<author fullname='C. Cath' initials='C.' surname='Cath'/> <author surname="Papadimitriou" initials="D."/>
<date month='October' year='2017'/> <author surname="Zahariadis" initials="T."/>
<abstract> <author surname="Martinez-Julia" initials="P."/>
<t>This document aims to propose guidelines for human rights consideration <author surname="Papafili" initials="I."/>
s, similar to the work done on the guidelines for privacy considerations (RFC 69 <author surname="Morreale" initials="V."/>
73). The other parts of this document explain the background of the guidelines a <author surname="Torelli" initials="F."/>
nd how they were developed.</t> <author surname="Sales" initials="B."/>
<t>This document is the first milestone in a longer-term research effort. <author surname="Demeester" initials="P.">
It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research </author>
Group and also by individuals from outside the research group.</t> <date year="2012" month="January"/>
</abstract> </front>
</front> <refcontent>The Future Internet, pp. 55-67</refcontent>
<seriesInfo name='RFC' value='8280'/> <seriesInfo name="DOI" value="10.1007/978-3-642-30241-1_6"/>
<seriesInfo name='DOI' value='10.17487/RFC8280'/> </reference>
</reference>
<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'> <reference anchor="W3CAccessibility" target="https://www.w3.org/standards/
<front> webdesign/accessibility">
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <front>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'/> <title>Accessibility</title>
<date month='August' year='2018'/> <author>
<abstract> <organization>W3C</organization>
<t>This document specifies version 1.3 of the Transport Layer Security (TL </author>
S) protocol. TLS allows client/server applications to communicate over the Inter </front>
net in a way that is designed to prevent eavesdropping, tampering, and message f </reference>
orgery.</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 implementa
tions.</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'> <reference anchor="Newegg" target="https://arstechnica.com/tech-policy/201
<front> 3/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/">
<title>DNS Queries over HTTPS (DoH)</title> <front>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/> <title>Newegg on trial: Mystery company TQP rewrites the history of en
<author fullname='P. McManus' initials='P.' surname='McManus'/> cryption</title>
<date month='October' year='2018'/> <author initials="J." surname="Mullin">
<abstract> <organization/>
<t>This document defines a protocol for sending DNS queries and getting DN </author>
S responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exch <date month="November" year="2013"/>
ange.</t> </front>
</abstract> <refcontent>Ars Technica</refcontent>
</front> </reference>
<seriesInfo name='RFC' value='8484'/>
<seriesInfo name='DOI' value='10.17487/RFC8484'/>
</reference>
<reference anchor='RFC8980' target='https://www.rfc-editor.org/info/rfc8980'> <reference anchor="Hill" target="http://www.apig.ch/UNIGE%20Catalog.pdf">
<front> <front>
<title>Report from the IAB Workshop on Design Expectations vs. Deployment Re <title>Partial Catalog of Human Rights Related to ICT Activities</titl
ality in Protocol Development</title> e>
<author fullname='J. Arkko' initials='J.' surname='Arkko'/> <author initials="R." surname="Hill">
<author fullname='T. Hardie' initials='T.' surname='Hardie'/> <organization>Association for Proper Internet Governance (APIG)</org
<date month='February' year='2021'/> anization>
<abstract> </author>
<t>The Design Expectations vs. Deployment Reality in Protocol Development <date month="May" year="2014"/>
Workshop was convened by the Internet Architecture Board (IAB) in June 2019. Thi </front>
s report summarizes the workshop's significant points of discussion and identifi </reference>
es 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 par
ticipants 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'> <reference anchor="Kaye" target="https://digitallibrary.un.org/record/7987
<front> 09?v=pdf">
<title>Technical Considerations for Internet Service Blocking and Filtering< <front>
/title> <title>Report of the Special Rapporteur on the Promotion and Protectio
<author fullname='R. Barnes' initials='R.' surname='Barnes'/> n of the Right to Freedom of Opinion and Expression, David Kaye</title>
<author fullname='A. Cooper' initials='A.' surname='Cooper'/> <author initials="D." surname="Kaye">
<author fullname='O. Kolkman' initials='O.' surname='Kolkman'/> <organization/>
<author fullname='D. Thaler' initials='D.' surname='Thaler'/> </author>
<author fullname='E. Nordmark' initials='E.' surname='Nordmark'/> <date month="May" year="2015"/>
<date month='March' year='2016'/> </front>
<abstract> <refcontent>A/HRC/29/32</refcontent>
<t>The Internet is structured to be an open communications medium. This op </reference>
enness is one of the key underpinnings of Internet innovation, but it can also a
llow 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 communicat
ions. This document examines several technical approaches to Internet blocking a
nd 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 mo
st coherent with the Internet architecture is to inform endpoints about potentia
lly 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 t
he 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'> <reference anchor="UNGP" target="https://www.ohchr.org/en/publications/ref
<front> erence-publications/guiding-principles-business-and-human-rights">
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <front>
<author fullname='J. Iyengar' initials='J.' role='editor' surname='Iyengar'/ <title>Guiding Principles on Business and Human Rights: Implementing t
> he United Nations 'Protect, Respect and Remedy' Framework</title>
<author fullname='M. Thomson' initials='M.' role='editor' surname='Thomson'/ <author>
> <organization>United Nations</organization>
<date month='May' year='2021'/> </author>
<abstract> <date year="2012" month="January"/>
<t>This document defines the core of the QUIC transport protocol. QUIC pro </front>
vides applications with flow-controlled streams for structured communication, lo </reference>
w-latency connection establishment, and network path migration. QUIC includes se
curity measures that ensure confidentiality, integrity, and availability in a ra
nge 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'> <reference anchor="UNHR" target="https://www.ohchr.org/en/core-internation
<front> al-human-rights-instruments-and-their-monitoring-bodies">
<title>RTP-Mixer Formatting of Multiparty Real-Time Text</title> <front>
<author fullname='G. Hellström' initials='G.' surname='Hellström'/> <title>The Core International Human Rights Instruments and their monit
<date month='July' year='2021'/> oring bodies</title>
<abstract> <author>
<t>This document provides enhancements of real-time text (as specified in <organization>United Nations</organization>
RFC 4103) suitable for mixing in a centralized conference model, enabling source </author>
identification and rapidly interleaved transmission of text from different sour </front>
ces. The intended use is for real-time text mixers and participant endpoints cap </reference>
able of providing an efficient presentation or other treatment of a multiparty r
eal-time text session. The specified mechanism builds on the standard use of the
Contributing Source (CSRC) list in the Real-time Transport Protocol (RTP) packe
t for source identification. The method makes use of the same "text/t140" and "t
ext/red" formats as for two-party sessions.</t>
<t>Solutions using multiple RTP streams in the same RTP session are briefl
y 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 doc
ument 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 mi
xer and a participant can handle the multiparty-coded real-time text stream usin
g the RTP-mixer method. The capability is indicated by the use of a Session Desc
ription 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 e
ndpoint is not multiparty aware is also provided.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='9071'/>
<seriesInfo name='DOI' value='10.17487/RFC9071'/>
</reference>
<reference anchor="UDHR" target="http://www.un.org/en/documents/udhr/"> <reference anchor="HR-RT" target="https://github.com/IRTF-HRPC/reviews">
<front> <front>
<title>The Universal Declaration of Human Rights</title> <title>IRTF-HRPC / reviews</title>
<author > <author>
<organization>United Nations General Assembly</organization> <organization/>
</author> </author>
<date year="1948"/> <date month="December" year="2020"/>
</front> </front>
</reference> <refcontent>commit 3f5fbff</refcontent>
<reference anchor="Bless" > </reference>
<front>
<title>Values and Networks</title>
<author initials="R." surname="Bless">
<organization></organization>
</author>
<author initials="C." surname="Orwat">
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="Brown" >
<front>
<title>A Prehistory of Internet Governance</title>
<author initials="I." surname="Brown">
<organization></organization>
</author>
<author initials="M." surname="Ziewitz">
<organization></organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="Research Handbook on Governance of the Internet. Cheltenham,
Edward Elgar" value=""/>
</reference>
<reference anchor="notewell" target="https://www.ietf.org/about/note-well.html">
<front>
<title>Note Well</title>
<author >
<organization>IETF</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="IRP" target="http://internetrightsandprinciples.org/site/wp-c
ontent/uploads/2014/06/IRPC_10RightsandPrinciples_28May2014-11.pdf">
<front>
<title>10 Internet Rights &amp; Principles</title>
<author >
<organization>Internet Rights and Principles Dynamic Coalition</organizati
on>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="ICCPR" target="http://www.ohchr.org/EN/ProfessionalInterest/P
ages/CCPR.aspx">
<front>
<title>International Covenant on Civil and Political Rights</title>
<author >
<organization>United Nations General Assembly</organization>
</author>
<date year="1976"/>
</front>
</reference>
<reference anchor="Saltzer" >
<front>
<title>End-to-End Arguments in System Design</title>
<author initials="J.H." surname="Saltzer">
<organization></organization>
</author>
<author initials="D.P." surname="Reed">
<organization></organization>
</author>
<author initials="D.D." surname="Clark">
<organization></organization>
</author>
<date year="1984"/>
</front>
<seriesInfo name="ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288." value
=""/>
</reference>
<reference anchor="ICESCR" target="http://www.ohchr.org/EN/ProfessionalInterest/
Pages/CESCR.aspx">
<front>
<title>International Covenant on Economic, Social and Cultural Rights</title
>
<author >
<organization>United Nations General Assembly</organization>
</author>
<date year="1966"/>
</front>
</reference>
<reference anchor="Penney" target="http://papers.ssrn.com/sol3/papers.cfm?abstra
ct_id=2769645">
<front>
<title>Chilling Effects: Online Surveillance and Wikipedia Use</title>
<author initials="J." surname="Penney">
<organization></organization>
</author>
<date year="2016"/>
</front>
</reference>
<reference anchor="UNHRC2016" target="https://documents-dds-ny.un.org/doc/UNDOC/
LTD/G16/131/89/PDF/G1613189.pdf?OpenElement">
<front>
<title>UN Human Rights Council Resolution "The promotion, protection and enj
oyment of human rights on the Internet" (A/HRC/32/L.20)</title>
<author >
<organization>United Nations Human Rights Council</organization>
</author>
<date year="2016"/>
</front>
</reference>
<reference anchor="geekfeminism" target="http://geekfeminism.wikia.com/wiki/Pseu
donymity">
<front>
<title>Pseudonymity</title>
<author >
<organization>Geek Feminism Wiki</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="W3Ci18nDef" target="http://www.w3.org/International/questions
/qa-i18n.en">
<front>
<title>Localization vs. Internationalization</title>
<author >
<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>
</author>
<date year="1996"/>
</front>
</reference>
<reference anchor="patentpolicy" target="https://www.w3.org/Consortium/Patent-Po
licy-20040205/">
<front>
<title>W3C Patent Policy</title>
<author >
<organization>W3C</organization>
</author>
<date year="2004"/>
</front>
</reference>
<reference anchor="Pouwelse" target="https://tools.ietf.org/html/draft-pouwelse-
censorfree-scenarios">
<front>
<title>Media without censorship</title>
<author initials="J." surname="Pouwelse, Ed">
<organization></organization>
</author>
<date year="2012"/>
</front>
</reference>
<reference anchor="draft-irtf-pearg-censorship" target="https://tools.ietf.org/h
tml/draft-irtf-pearg-censorship">
<front>
<title>A Survey 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/d
oc/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>
<author initials="C.J." surname="Bernardos">
<organization></organization>
</author>
<author initials="A." surname="Andersdotter">
<organization></organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="HTML5" target="https://www.w3.org/TR/html5/">
<front>
<title>HTML5</title>
<author >
<organization>W3C</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="Zittrain" target="https://dash.harvard.edu/bitstream/handle/1
/4455262/Zittrain_Future%20of%20the%20Internet.pdf?sequence=1">
<front>
<title>The Future of the Internet - And How to Stop It</title>
<author initials="J." surname="Zittrain">
<organization></organization>
</author>
<date year="2008"/>
</front>
<seriesInfo name="Yale University Press" value=""/>
</reference>
<reference anchor="FIArch" target="http://www.future-internet.eu/uploads/media/F
IArch_Design_Principles_V1.0.pdf">
<front>
<title>Future Internet Design Principles</title>
<author >
<organization></organization>
</author>
<date year="2012" month="January"/>
</front>
</reference>
<reference anchor="W3CAccessibility" target="https://www.w3.org/standards/webdes
ign/accessibility">
<front>
<title>Accessibility</title>
<author >
<organization>W3C</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="newegg" target="http://arstechnica.com/tech-policy/2013/11/ne
wegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/">
<front>
<title>Newegg on trial: Mystery company TQP rewrites the history of encrypti
on</title>
<author initials="J." surname="Mullin">
<organization></organization>
</author>
<date year="2013"/>
</front>
</reference>
<reference anchor="Hill2014" 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>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="Kaye" target="https://www.ohchr.org/EN/HRbodies/HRC/RegularSe
ssions/Session29/Documents/A.HRC.29.32_AEV.doc">
<front>
<title>The use of encryption and anonymity in digital communications</title>
<author initials="D." surname="Kaye">
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="UNGP" target="https://www.ohchr.org/documents/publications/gu
idingprinciplesbusinesshr_en.pdf">
<front>
<title>United Nations Guiding Principles on Business and Human Rights</title
>
<author >
<organization>United Nations</organization>
</author>
<date year="2011"/>
</front>
</reference>
<reference anchor="UNHR" target="https://www.ohchr.org/en/professionalinterest/p
ages/coreinstruments.aspx">
<front>
<title>The Core International Human Rights Instruments and their monitoring
bodies</title>
<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/draf
t-arkko-iab-internet-consolidation-02">
<front>
<title>Considerations on Internet Consolidation and the Internet Architectur
e</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>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="FREAK" target="https://web.archive.org/web/20150304002021/htt
ps://freakattack.com/">
<front>
<title>Tracking the FREAK Attack</title>
<author >
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="Logjam" target="https://weakdh.org/imperfect-forward-secrecy-
ccs15.pdf">
<front>
<title>Imperfect Forward Secrecy, How Diffie-Hellman Fails in Practice</titl
e>
<author initials="D." surname="Adrian">
<organization></organization>
</author>
<author initials="K." surname="Bhargavan">
<organization></organization>
</author>
<author initials="." surname="et al">
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="hecate" target="https://eprint.iacr.org/2021/1686">
<front>
<title>Hecate, Abuse Reporting in Secure Messengers with Sealed Sender</titl
e>
<author initials="R." surname="Issa">
<organization></organization>
</author>
<author initials="N." surname="Alhaddad">
<organization></organization>
</author>
<author initials="M." surname="Varia">
<organization></organization>
</author>
<date year="2022"/>
</front>
</reference>
<reference 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>
</author>
<author initials="J." surname="Lu">
<organization></organization>
</author>
<author initials="T." surname="Ristenpart">
<organization></organization>
</author>
<date year="2017"/>
</front>
</reference>
<reference 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>
</author>
<author initials="S." surname="Englehardt">
<organization></organization>
</author>
<author initials="A." surname="Narayanan">
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="https-interception" >
<front>
<title>The Security Impact of HTTPS Interception</title>
<author initials="Z." surname="Durumeric">
<organization></organization>
</author>
<author initials="Z." surname="Ma">
<organization></organization>
</author>
<author initials="D." surname="Springall">
<organization></organization>
</author>
<author initials="R." surname="Barnes">
<organization></organization>
</author>
<author initials="N." surname="Sullivan">
<organization></organization>
</author>
<author initials="E." surname="Bursztein">
<organization></organization>
</author>
<author initials="M." surname="Bailey">
<organization></organization>
</author>
<author initials="J." surname="Halderman">
<organization></organization>
</author>
<author initials="V." surname="Paxson">
<organization></organization>
</author>
<date year="2017"/>
</front>
</reference>
<reference anchor="I-D.ietf-mls-protocol" target="https://datatracker.ietf.org/d
oc/draft-ietf-mls-protocol/">
<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>
<author initials="K." surname="Cohn-Gordon">
<organization></organization>
</author>
<date year="2023"/>
</front>
</reference>
<reference anchor='RFC8558' target='https://www.rfc-editor.org/info/rfc8558'> <!-- [I-D.arkko-iab-internet-consolidation] IESG state: Expired -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-arkko-iab
<title>Transport Protocol Path Signals</title> -internet-consolidation.xml"/>
<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 ex
ample, TCP's state machine uses a series of well-known messages that are exchang
ed in the clear. Because these are visible to network elements on the path betwe
en the two nodes setting up the transport connection, they are often used as sig
nals by those network elements. In transports that do not exchange these message
s 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 channe
ls. Where the endpoints desire that network elements along the path receive thes
e 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'> <reference anchor="FREAK" target="https://web.archive.org/web/201503040020
<front> 21/https://freakattack.com/">
<title>The Internet is for End Users</title> <front>
<author fullname='M. Nottingham' initials='M.' surname='Nottingham'/> <title>Tracking the FREAK Attack</title>
<date month='August' year='2020'/> <author>
<abstract> <organization>University of Michigan</organization>
<t>This document explains why the IAB believes that, when there is a confl </author>
ict between the interests of end users of the Internet and other parties, IETF d <date month="March" year="2015"/>
ecisions should favor end users. It also explores how the IETF can more effectiv </front>
ely achieve this.</t> <refcontent>Wayback Machine archive</refcontent>
</abstract> </reference>
</front>
<seriesInfo name='RFC' value='8890'/>
<seriesInfo name='DOI' value='10.17487/RFC8890'/>
</reference>
<reference anchor='RFC7301' target='https://www.rfc-editor.org/info/rfc7301'> <reference anchor="Logjam">
<front> <front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation <title>Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
Extension</title> </title>
<author fullname='S. Friedl' initials='S.' surname='Friedl'/> <author initials="D." surname="Adrian">
<author fullname='A. Popov' initials='A.' surname='Popov'/> <organization/>
<author fullname='A. Langley' initials='A.' surname='Langley'/> </author>
<author fullname='E. Stephan' initials='E.' surname='Stephan'/> <author initials="K." surname="Bhargavan">
<date month='July' year='2014'/> <organization/>
<abstract> </author>
<t>This document describes a Transport Layer Security (TLS) extension for <author initials="Z." surname="Durumeric">
application-layer protocol negotiation within the TLS handshake. For instances i <organization/>
n which multiple application protocols are supported on the same TCP or UDP port </author>
, this extension allows the application layer to negotiate which protocol will b <author initials="P." surname="Gaudry">
e used within the TLS connection.</t> <organization/>
</abstract> </author>
</front> <author initials="M." surname="Green">
<seriesInfo name='RFC' value='7301'/> <organization/>
<seriesInfo name='DOI' value='10.17487/RFC7301'/> </author>
</reference> <author 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 Co
mputer and Communications Security, pp 5-17</refcontent>
<seriesInfo name="DOI" value="10.1145/2810103.2813707"/>
</reference>
<reference anchor='I-D.ietf-tls-esni' target='https://datatracker.ietf.org/doc/h <reference anchor="Hecate" target="https://www.usenix.org/conference/useni
tml/draft-ietf-tls-esni-17'> xsecurity22/presentation/issa">
<front> <front>
<title>TLS Encrypted Client Hello</title> <title>Hecate, Abuse Reporting in Secure Messengers with Sealed Sender
<author fullname='Eric Rescorla' initials='E.' surname='Rescorla'> </title>
<organization>RTFM, Inc.</organization> <author initials="R." surname="Issa">
</author> <organization/>
<author fullname='Kazuho Oku' initials='K.' surname='Oku'> </author>
<organization>Fastly</organization> <author initials="N." surname="Alhaddad">
</author> <organization/>
<author fullname='Nick Sullivan' initials='N.' surname='Sullivan'> </author>
<organization>Cloudflare</organization> <author initials="M." surname="Varia">
</author> <organization/>
<author fullname='Christopher A. Wood' initials='C. A.' surname='Wood'> </author>
<organization>Cloudflare</organization> <date year="2022" month="August"/>
</author> </front>
<date day='9' month='October' year='2023'/> <refcontent>31st USENIX Security Symposium (USENIX Security 22), pp 2335-
<abstract> 2352</refcontent>
<t> This document describes a mechanism in Transport Layer Security (T </reference>
LS)
for encrypting a ClientHello message under a server public key.
Discussion Venues <reference anchor="Messenger-franking" target="https://eprint.iacr.org/201
7/664">
<front>
<title>Message Franking via Committing Authenticated Encryption</title
>
<author initials="P." surname="Grubbs">
<organization/>
</author>
<author initials="J." surname="Lu">
<organization/>
</author>
<author initials="T." surname="Ristenpart">
<organization/>
</author>
<date year="2017" month="July"/>
</front>
<refcontent>Cryptology ePrint Archive, Paper 2017/664</refcontent>
</reference>
This note is to be removed before publishing as an RFC. <reference anchor="Email-hashing" target="https://freedom-to-tinker.com/20
18/04/09/four-cents-to-deanonymize-companies-reverse-hashed-email-addresses/">
<front>
<title>Four cents to deanonymize: Companies reverse hashed email addre
sses</title>
<author initials="G." surname="Acar">
<organization/>
</author>
<author initials="S." surname="Englehardt">
<organization/>
</author>
<author initials="A." surname="Narayanan">
<organization/>
</author>
<date month="April" year="2018"/>
</front>
</reference>
Source for this draft and an issue tracker can be found at <reference anchor="HTTPS-interception">
https://github.com/tlswg/draft-ietf-tls-esni <front>
(https://github.com/tlswg/draft-ietf-tls-esni). <title>The Security Impact of HTTPS Interception</title>
<author initials="Z." surname="Durumeric">
<organization/>
</author>
<author initials="Z." surname="Ma">
<organization/>
</author>
<author initials="D." surname="Springall">
<organization/>
</author>
<author initials="R." surname="Barnes">
<organization/>
</author>
<author initials="N." surname="Sullivan">
<organization/>
</author>
<author initials="E." surname="Bursztein">
<organization/>
</author>
<author initials="M." surname="Bailey">
<organization/>
</author>
<author initials="J." surname="Halderman">
<organization/>
</author>
<author initials="V." surname="Paxson">
<organization/>
</author>
<date month="February" year="2017"/>
</front>
<refcontent>NDSS Symposium 2017</refcontent>
<seriesInfo name="DOI" value="10.14722/ndss.2017.23456"/>
</reference>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.942
</abstract> 0.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.855
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-esni-17'/> 8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.889
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.730
1.xml"/>
</reference> <!-- [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="Jorgensen">
<front>
<title>An internet bill of rights</title>
<author initials="R. F." surname="Jørgensen">
<organization/>
</author>
<date month="April" year="2013"/>
</front>
<refcontent>Research Handbook on Governance of the Internet, edited by I
an Brown. Cheltenham: Edward Elgar Publishing</refcontent>
<seriesInfo name="DOI" value="10.4337/9781849805025.00022"/>
</reference>
</references> </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 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 hrpc list for
reviews and suggestions.</t></li>
<li><t>Individuals who conducted human rights reviews for their work
and 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> </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> </rfc>
 End of changes. 79 change blocks. 
2920 lines changed or deleted 1606 lines changed or added

This html diff was produced by rfcdiff 1.48.