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" [ <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743
have been adhered to in this document.
-->
<!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="August"/>
<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>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<keyword>example</keyword>
<abstract> <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 not an Internet Standards Track specification; it is
published for informational purposes.</t>
<t>This informational document has consensus for publication from the
Internet Research Task Force (IRTF) Human Right Protocol Considerations
(HRPC) Research Group. It has been reviewed, tried, and tested by both
the research group as well as researchers and practitioners from outside
the research group.
<t>This document sets guidelines for human rights considerations for developers <!--[rfced] Abstract and Section 1 - To avoid the repetition of "developing" and
working on network protocols and architectures, similar to the work done on the "development" in the same sentence, may we update "in development" to "ongoing"?
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 Original:
ed for informational purposes.</t> The research group
acknowledges that the understanding of the impact of Internet
protocols and architecture on society is a developing practice and is
a body of research that is still in development.
<t>This informational document has consensus for publication from the Internet R Perhaps:
esearch Task Force (IRTF) Human Right Protocol Considerations Research (HRPC) Gr The research group
oup. It has been reviewed, tried, and tested by both by the research group as we acknowledges that the understanding of the impact of Internet
ll as by researchers and practitioners from outside the research group. The rese protocols and architecture on society is a developing practice and is
arch group acknowledges that the understanding of the impact of Internet protoco a body of research that is still ongoing.
ls and architecture on society is a developing practice and is a body of researc -->
h that is still in development.</t>
The research group acknowledges that the
understanding of the impact of Internet protocols and architecture on
society is a developing practice and is a body of research that is still
in development.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>This document outlines a set of human rights protocol considerations fo
r protocol developers. It provides questions that engineers should ask themselve
s when developing or improving protocols if they want to understand how their de
cisions can potentially influence the exercise of human rights on the Internet.
<section anchor="introduction" title="Introduction"> <!--[rfced] Section 1 - We are having some difficulty parsing the second instanc
e
<t>This document outlines a set of human rights protocol considerations for prot of "protocol" in the sentence below. May it be removed?
ocol developers. It provides questions engineers should ask themselves when deve
loping or improving protocols if they want to understand how their decisions can
potentially influence the exercise of human rights on the Internet. It should b
e noted that the impact of a protocol cannot solely be deduced from its design,
but its usage and implementation should also be studied to form a full protocol
human rights impact assessment.</t>
<t>The questions are based on the research performed by the Human Rights Protoco
l Considerations (HRPC) research group which has been documented before these co
nsiderations. The research establishes that human rights relate to standards and
protocols, and offers a common vocabulary of technical concepts that influence
human rights and how these technical concepts can be combined to ensure that the
Internet remains an enabling environment for human rights. With this, the conto
urs of a model for developing human rights protocol considerations has taken sha
pe.</t>
<t>This document is an iteration of the guidelines that can be found in <xref ta
rget="RFC8280"/>. The methods for conducting human rights reviews (Section 3.2),
and guidelines for human rights considerations (Section 3.3) in this document a
re being tested for relevance, accuracy, and validity. <xref target="HR-RT"/> Th
e understanding of what human rights are is based on the Universal Declaration o
f Human Rights <xref target="UDHR"/> and subsequent treaties that jointly form t
he body of international human rights law <xref target="UNHR"/>.</t>
<t>This document does not provide a detailed taxonomy of the nature of (potentia
l) human rights violations, whether direct or indirect, long-term or short-term,
certain protocol choices might present. In part because this is highly context-
dependent, and in part, because this document aims to provide a practical set of
guidelines. However, further research in this field would definitely benefit de
velopers and implementers.</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
esearch Task Force (IRTF) Human Right Protocol Considerations Research Group. It
has been reviewed, tried, and tested by both by the research group as well as b
y researchers and practitioners from outside the research group. The HRPC resear
ch group acknowledges that the understanding of the impact of Internet protocols
and architecture on society is a developing practice and is a body of research
that is still in development.</t>
</section>
<section anchor="human-rights-threats" title="Human rights threats">
<t>Threats to the exercise of human rights on the Internet come in many forms. P
rotocols and standards may harm or enable the right to freedom of expression, ri
ght to freedom of information, right to non-discrimination, right to equal prote
ction, right to participate in cultural life, arts and science, right to freedom
of assembly and association, right to privacy, and the right to security. An en
d-user who is denied access to certain services or content may be unable to disc
lose vital information about the malpractices of a government or other authority
. A person whose communications are monitored may be prevented or dissuaded from
exercising their right to freedom of association or participate in political pr
ocesses <xref target="Penney"/>. In a worst-case scenario, protocols that leak i
nformation can lead to physical danger. A realistic example to consider is when
individuals perceived as threats to the state are subjected to torture, extra-ju
dicial killing or detention on the basis of information gathered by state agenci
es through the monitoring of network traffic.</t>
<t>This document presents several examples of how threats to human rights materi
alize on the Internet. This threat modeling is inspired by <xref target="RFC6973
"/> Privacy Considerations for Internet Protocols, which is based on security th
reat analysis. This method is a work in progress and by no means a perfect solut
ion for assessing human rights risks in Internet protocols and systems. Certain
specific human rights threats are indirectly considered in Internet protocols as
part of the security considerations <xref target="BCP72"/>, but privacy conside
rations <xref target="RFC6973"/> or reviews, let alone human rights impact asses
sments of protocols, are neither standardized nor implemented.</t>
<t>Many threats, enablers, and risks are linked to different rights. This is not Original:
surprising if one takes into account that human rights are interrelated, interd It should be noted that the impact
ependent, and indivisible. Here, however, we’re not discussing all human rights of a protocol cannot solely be deduced from its design, but its usage
because not all human rights are relevant to information and communication techn and implementation should also be studied to form a full protocol
ologies (ICTs) in general and protocols and standards in particular <xref target human rights impact assessment.
="Bless"/>: “The main source of the values of human rights is the International
Bill of Human Rights that is composed of the Universal Declaration of Human Righ
ts <xref target="UDHR"/> along with the International Covenant on Civil and Poli
tical Rights <xref target="ICCPR"/> and the International Covenant on Economic,
Social and Cultural Rights <xref target="ICESCR"/>. In the light of several case
s of Internet censorship, the UN Human Rights Council Resolution 20/8 was adopte
d in 2012, affirming that “the same rights that people have offline must also be
protected online.” <xref target="UNHRC2016"/> In 2015, the Charter of Human Rig
hts and Principles for the Internet <xref target="IRP"/> was developed and relea
sed. According to these documents, some examples of human rights relevant for IC
T systems are human dignity (Art. 1 UDHR), non-discrimination (Art. 2), rights t
o life, liberty and security (Art. 3), freedom of opinion and expression (Art. 1
9), freedom of assembly and association (Art. 20), rights to equal protection, l
egal remedy, fair trial, due process, presumed innocent (Art. 7–11), appropriate
social and international order (Art. 28), participation in public affairs (Art.
21), participation in cultural life, protection of the moral and material inter
ests resulting from any scientific, literary or artistic production of which [th
ey are] the author (Art. 27), and privacy (Art. 12).” A partial catalog of human
rights related to Information and Communications Technologies, including econom
ic rights, can be found in <xref target="Hill2014"/>.</t>
<t>This is by no means an attempt to exclude specific rights or prioritize some Perhaps:
rights over others.</t> It should be noted that the impact
of a protocol cannot solely be deduced from its design, but its usage
and implementation should also be studied to form a full
human rights impact assessment.
-->
</section> It should be noted that the impact of a protocol cannot solely be deduced
<section anchor="conducting-human-rights-reviews" title="Conducting human rights from its design, but its usage and implementation should also be studied to form
reviews"> a full protocol 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
hese considerations. The research establishes that human rights relate to standa
rds and protocols and offers a common vocabulary of technical concepts that infl
uence human rights and how these technical concepts can be combined to ensure th
at the Internet remains an enabling environment for human rights. With this, the
contours of a model for developing human rights protocol considerations has tak
en shape.</t>
<t>This document is an iteration of the guidelines that can be found in <x
ref target="RFC8280" format="default"/>. The methods for conducting human rights
reviews (<xref target="analyzing-drafts-based-on-their-perceived-or-speculated-
impact" format="default"/>) and the guidelines for human rights considerations (
<xref target="expert-interviews" format="default"/>) in this document are being
tested for relevance, accuracy, and validity <xref target="HR-RT" format="defaul
t"/>. The understanding of what human rights are is based on the "Universal Decl
aration of Human Rights" <xref target="UDHR" format="default"/> and subsequent t
reaties that jointly form the body of international human rights law <xref targe
t="UNHR" format="default"/>.</t>
<t>This document does not provide a detailed taxonomy of the nature of (po
tential) human rights violations, whether direct or indirect / long-term or shor
t-term, that certain protocol choices might present. In part, it is because this
is highly context-dependent and also because this document aims to provide a pr
actical set of guidelines. However, further research in this field would definit
ely benefit developers and implementers.</t>
<t>This document is not an Internet Standards Track specification; it is p
ublished for informational purposes.</t>
<t>This informational document has consensus for publication from the Inte
rnet Research Task Force (IRTF) Human Right Protocol Considerations Research Gro
up. It has been reviewed, tried, and tested by both the research group as well a
s researchers and practitioners from outside the research group. The HRPC Resear
ch Group acknowledges that the understanding of the impact of Internet protocols
and architecture on society is a developing practice and is a body of research
that is still in development.</t>
</section>
<section anchor="human-rights-threats" numbered="true" toc="default">
<name>Human Rights Threats</name>
<t>Threats to the exercise of human rights on the Internet come in many fo
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
protection; right to participate in cultural life, arts, and science; right to
freedom of assembly and association; right to privacy; and right to security. An
end user who is denied access to certain services or content may be unable to d
isclose vital information about the malpractices of a government or other author
ity. A person whose communications are monitored may be prevented or dissuaded f
rom exercising their right to freedom of association or participate in political
processes <xref target="Penney" format="default"/>. In a worst-case scenario, p
rotocols that leak information can lead to physical danger. A realistic example
to consider is when individuals perceived as threats to the state are subjected
to torture, extra-judicial killing, or detention on the basis of information gat
hered by state agencies through the monitoring of network traffic.</t>
<t>This document presents several examples of how threats to human rights
materialize on the Internet. This threat modeling is inspired by "<xref target="
RFC6973" format="title"/>" <xref target="RFC6973" format="default"/>, which is b
ased on security threat analysis. This method is a work in progress and by no me
ans a perfect solution for assessing human rights risks in Internet protocols an
d systems. Certain specific human rights threats are indirectly considered in In
ternet protocols as part of the security considerations <xref target="BCP72" for
mat="default"/>; however, privacy considerations <xref target="RFC6973" format="
default"/> or reviews, let alone human rights impact assessments of protocols, a
re neither standardized nor implemented.</t>
<t>Ideally, protocol developers and collaborators should incorporate human right <!-- [rfced] Section 2 - FYI, we have updated the following quote to match the
s considerations into the design process itself (see Guidelines for human rights text found in [Orwat]. Additionally, the quoted text has been encapsulated
considerations). This section provides guidance on how to conduct a human right within the <blockquote> element. Please let us know if there is any objection.
s review, i.e., gauge the impact or potential impact of a protocol or standard o
n human rights.</t>
<t>Human rights reviews can be done by any participant, and can take place at di Original:
fferent stages of the development process of an Internet-Draft. Generally speaki Here, however,
ng, it is easier to influence the development of a technology at earlier stages we're not discussing all human rights because not all human rights
than at later stages. This does not mean that reviews at last-call are not relev are relevant to information and communication technologies (ICTs) in
ant, but they are less likely to result in significant changes in the reviewed d general and protocols and standards in particular [Bless]: "The main
ocument.</t> source of the values of human rights is the International Bill of
Human Rights that is composed of the Universal Declaration of Human
Rights [UDHR] along with the International Covenant on Civil and
Political Rights [ICCPR] and the International Covenant on Economic,
Social and Cultural Rights [ICESCR]. In the light of several cases
of Internet censorship, the UN Human Rights Council Resolution 20/8
was adopted in 2012, affirming that "the same rights that people have
offline must also be protected online." [UNHRC2016] In 2015, the
Charter of Human Rights and Principles for the Internet [IRP] was
developed and released. According to these documents, some examples
of human rights relevant for ICT systems are human dignity (Art. 1
UDHR), non-discrimination (Art. 2), rights to life, liberty and
security (Art. 3), freedom of opinion and expression (Art. 19),
freedom of assembly and association (Art. 20), rights to equal
protection, legal remedy, fair trial, due process, presumed innocent
(Art. 7-11), appropriate social and international order (Art. 28),
participation in public affairs (Art. 21), participation in cultural
life, protection of the moral and material interests resulting from
any scientific, literary or artistic production of which [they are]
the author (Art. 27), and privacy (Art. 12)."
<t>Human rights review can be done by document authors, document shepherds, memb Current:
ers of review teams, advocates, or impacted communities to influence the standar However, here
d development process. IETF documents can benefit from people with different kno we're not discussing all human rights because not all human rights
wledges, perspectives, and backgrounds, especially since their implementation ca are relevant to Information and Communication Technologies (ICTs) in
n impact many different communities as well.</t> general and to protocols and standards in particular [Orwat]:
<t>Methods for analyzing technology for specific human rights impacts are still | The main source of the values of human rights is the
quite nascent. Currently, five methods have been explored by the human rights re | _International Bill of Human Rights_ that is composed of the
view team, often in conjunction with each other:</t> | _Universal Declaration of Human Rights_ (UDHR) [UDHR] along with
| the _International Covenant on Civil and Political Rights_ (ICCPR)
| [ICCPR] and the _International Covenant on Economic, Social and
| Cultural Rights_ (ICESCR) [ICESCR]. In the light of several cases
| of Internet censorship, the UN Human Rights Council Resolution
| 20/8 was adopted in 2012, affirming that "...the same rights that
| people have offline must also be protected online..." [UNHRC2016].
| In 2015, the _Charter of Human Rights and Principles for the
| Internet_ [IRP] was developed and released [Jorgensen]. According
| to these documents, some examples of human rights relevant for ICT
| systems are _human dignity_ (Art. 1 UDHR), _non-discrimination_
| (Art. 2), _rights to life, liberty and security_ (Art. 3),
| _freedom of opinion and expression_ (Art. 19), _freedom of
| assembly and association_ (Art. 20), _rights to equal protection,
| legal remedy, fair trial, due process, presumed innocent_ (Art.
| 7-11), _appropriate social and international order_ (Art. 28),
| _participation in public affairs_ (Art. 21), _participation in
| cultural life, protection of intellectual property_ (Art. 27), and
| _privacy_ (Art. 12).
-->
<t>Many threats, enablers, and risks are linked to different rights. This
is not surprising if one takes into account that human rights are interrelated,
interdependent, and indivisible. However, here we're not discussing all human ri
ghts because not all human rights are relevant to Information and Communication
Technologies (ICTs) in general and to protocols and standards in particular <xre
f target="Orwat" format="default"/>:</t>
<blockquote>The main source of the values of human rights is the
<em>International Bill of Human Rights</em> that is composed of the <em>Universa
l Declaration of Human Rights</em> (UDHR) <xref target="UDHR" format="default"/>
along with the <em>International Covenant on Civil and Political Rights</em> (I
CCPR) <xref target="ICCPR" format="default"/> and the <em>International Covenant
on Economic, Social and Cultural Rights</em> (ICESCR) <xref target="ICESCR" for
mat="default"/>. In the light of several cases of Internet censorship, the UN Hu
man Rights Council Resolution 20/8 was adopted in 2012, affirming that "...the s
ame rights that people have offline must also be protected online..." <xref targ
et="UNHRC2016" format="default"/>. In 2015, the <em>Charter of Human Rights and
Principles for the Internet</em> <xref target="IRP" format="default"/> was devel
oped and released <xref target="Jorgensen" format="default"/>. According to thes
e documents, some examples of human rights relevant for ICT systems are <em>huma
n dignity</em> (Art. 1 UDHR), <em>non-discrimination</em> (Art. 2), <em>rights t
o life, liberty and security</em> (Art. 3), <em>freedom of opinion and expressio
n</em> (Art. 19), <em>freedom of assembly and association</em> (Art. 20), <em>ri
ghts to equal protection, legal remedy, fair trial, due process, presumed innoce
nt</em> (Art. 7-11), <em>appropriate social and international order</em> (Art. 2
8), <em>participation in public affairs</em> (Art. 21), <em>participation in cul
tural life, protection of intellectual property</em> (Art. 27), and <em>privacy<
/em> (Art. 12).</blockquote>
<t>A partial catalog of human rights related to ICTs, including economic r
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
some rights over others.</t>
</section>
<section anchor="conducting-human-rights-reviews" numbered="true" toc="defau
lt">
<name>Conducting Human Rights Reviews</name>
<t>Ideally, protocol developers and collaborators should incorporate human
rights considerations into the design process itself (see <xref target="analyzi
ng-drafts-based-on-guidelines-for-human-rights-considerations-model"/> ("Analyzi
ng Internet-Drafts Based on Guidelines for Human Rights Considerations Model")).
This section provides guidance on how to conduct a human rights review, i.e., ga
uge the impact or potential impact of a protocol or standard on human rights.</t
>
<t>Human rights reviews can be done by any participant and can take place
at different stages of the development process of an Internet-Draft. Generally s
peaking, it is easier to influence the development of a technology at earlier st
ages than at later stages. This does not mean that reviews at Last Call are not
relevant, but they are less likely to result in significant changes in the revie
wed document.</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
standards development process. IETF documents can benefit from people with diffe
rent knowledge, perspectives, and backgrounds, especially since their implementa
tions can impact many different communities as well.</t>
<t>Methods for analyzing technology for specific human rights impacts are
still quite nascent. Currently, five methods have been explored by the human rig
hts review team, often in conjunction with each other.</t>
<section anchor="analyzing-drafts-based-on-guidelines-for-human-rights-con
siderations-model" numbered="true" toc="default">
<name>Analyzing Internet-Drafts Based on Guidelines for Human Rights Con
siderations Model</name>
<t>This analysis of Internet-Drafts uses the model as described in <xref
target="guidelines-for-human-rights-considerations" format="default"/>. The out
lined categories and questions can be used to review an Internet-Draft. The adva
ntage of this is that it provides a known overview, and document authors can go
back to this document as well as <xref target="RFC8280" format="default"/> to un
derstand the background and the context.</t>
</section>
<section anchor="analyzing-drafts-based-on-their-perceived-or-speculated-i
mpact" numbered="true" toc="default">
<name>Analyzing Internet-Drafts Based on Their Perceived or Speculated I
mpact</name>
<t>When reviewing an Internet-Draft, specific human rights impacts can b
ecome apparent by doing a close reading of the draft and seeking to understand h
ow it might affect networks or society. While less structured than the straight
use of the human rights considerations model, this analysis may lead to new spec
ulative understandings of links between human rights and protocols.</t>
</section>
<section anchor="expert-interviews" numbered="true" toc="default">
<name>Expert Interviews</name>
<t>Interviews with document authors, active members of the working group
, or experts in the field can help explore the characteristics of the protocol a
nd its effects. There are two main advantages to this approach: on the one hand,
it allows the reviewer to gain a deeper understanding of the (intended) working
s of the protocol; on the other hand, it also allows for the reviewer to start a
discussion with experts or even document authors, which can help the review gai
n traction when it is published.</t>
<section anchor="analyzing-drafts-based-on-guidelines-for-human-rights-considera <!-- [rfced] Section 3.3 - May we format the "two main advantages" as a
tions-model" title="Analyzing drafts based on guidelines for human rights consid numbered list?
erations model">
<t>This analysis of Internet-Drafts uses the model as described in section 4. Th
e outlined categories and questions can be used to review an Internet-Draft. The
advantage of this is that it provides a known overview, and document authors ca
n go back to this document as well as <xref target="RFC8280"/> to understand the
background and the context.</t>
</section> Original:
<section anchor="analyzing-drafts-based-on-their-perceived-or-speculated-impact" There are two main advantages to
title="Analyzing drafts based on their perceived or speculated impact"> this approach: one the one hand, it allows the reviewer to gain a
<t>When reviewing an Internet-Draft, specific human rights impacts can become ap deeper understanding of the (intended) workings of the protocol; on
parent by doing a close reading of the draft and seeking to understand how it mi the other hand, it also allows for the reviewer to start a discussion
ght affect networks or society. While less structured than the straight use of t with experts or even document authors, which can help the review gain
he human rights considerations model, this analysis may lead to new speculative traction when it is published.
understandings of links between human rights and protocols.</t>
</section> Perhaps:
<section anchor="expert-interviews" title="Expert interviews"> There are two main advantages to this approach:
<t>Interviews with document authors, active members of the Working Group, or exp
erts in the field can help explore the characteristics of the protocol and its e
ffects. There are two main advantages to this approach: one the one hand, it all
ows the reviewer to gain a deeper understanding of the (intended) workings of th
e protocol; on the other hand, it also allows for the reviewer to start a discus
sion with experts or even document authors, which can help the review gain tract
ion when it is published.</t>
</section> 1. It allows the reviewer to gain a deeper understanding of the
<section anchor="interviews-with-impacted-persons-and-communities" title="Interv (intended) workings of the protocol.
iews with impacted persons and communities">
<t>Protocols impact users of the Internet. Interviews can help the reviewer unde
rstand how protocols affect the people that use the protocols. Since human right
s are best understood from the perspective of the rights-holder, this approach w
ill improve the understanding of the real world effects of the technology. At th
e same time, it can be hard to attribute specific changes to a particular protoc
ol, this is of course even harder when a protocol has not been (widely) deployed
.</t>
</section> 2. It allows for the reviewer to start a discussion with experts or
<section anchor="tracing-impacts-of-implementations" title="Tracing impacts of i even document authors, which can help the review gain traction
mplementations"> when it is published.
<t>The reality of deployed protocols can be at odds with the expectations during -->
the protocol design and development phase <xref target="RFC8980"/>. When a spec </section>
ification already has associated running code, the code can be analyzed either i <section anchor="interviews-with-impacted-persons-and-communities" numbere
n an experimental setting or on the Internet where its impact can be observed. I d="true" toc="default">
n contrast to reviewing the draft text, this approach can allow the reviewer to <name>Interviews with Impacted Persons and Communities</name>
understand how the specifications works in practice, and potentially what unknow <t>Protocols impact users of the Internet. Interviews can help the revie
n or unexpected effects the technology has.</t> wer understand how protocols affect the people that use the protocols. Since hum
an rights are best understood from the perspective of the rights-holder, this ap
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
r protocol; this is of course even harder when a protocol has not been widely de
ployed.</t>
</section>
<section anchor="tracing-impacts-of-implementations" numbered="true" toc="
default">
<name>Tracing Impacts of Implementations</name>
<t>The reality of deployed protocols can be at odds with the expectation
s during the protocol design and development phase <xref target="RFC8980" format
="default"/>. When a specification already has associated running code, the code
can be analyzed either in an experimental setting or on the Internet where its
impact can be observed. In contrast to reviewing the draft text, this approach c
an allow the reviewer to understand how the specifications work in practice and
potentially what unknown or unexpected effects the technology has.</t>
</section>
</section>
<section anchor="guidelines-for-human-rights-considerations" numbered="true"
toc="default">
<name>Guidelines for Human Rights Considerations</name>
<t>This section provides guidance for document authors in the form of a qu
estionnaire about protocols and how technical decisions can shape the exercise o
f human rights. The questionnaire may be useful at any point in the design proce
ss, particularly after the document authors have developed a high-level protocol
model as described in <xref target="RFC4101" format="default"/>. These guidelin
es do not seek to replace any existing referenced specifications but, rather, co
ntribute to them and look at the design process from a human rights perspective.
</t>
<t>Protocols and Internet Standards might benefit from a documented discus
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 be coupled with an Applicability Statement for that RFC.</t>
<t>Note that the guidance provided in this section does not recommend spec
ific practices. The range of protocols developed in the IETF is too broad to mak
e recommendations about particular uses of data or how human rights might be bal
anced against other design goals. However, by carefully considering the answers
to the following questions, document authors should be able to produce a compre
hensive analysis that can serve as the basis for discussion on whether the proto
col adequately takes specific human rights threats into account. This guidance i
s meant to help the thought process of a human rights analysis; it does not prov
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 po
tential of technical advances or the passage of time to undermine protections.
</section> <!--[rfced] Section 4 - We are having some difficulty parsing this sentence,
</section> specifically "are considered given a purpose and specific use cases". For
<section anchor="guidelines-for-human-rights-considerations" title="Guidelines f clarity, may we update this sentence as follows?
or human rights considerations">
<t>This section provides guidance for document authors in the form of a question Additionally, may we avoid the repetition of "considerations" and
naire about protocols and how technical decisions can shape the exercise of huma "considered"?
n rights. The questionnaire may be useful at any point in the design process, pa
rticularly after the document authors have developed a high-level protocol model
as described in <xref target="RFC4101"/>. These guidelines do not seek to repla
ce any existing referenced specifications, but rather contribute to them and loo
k at the design process from a human rights perspective.</t>
<t>Protocols and Internet Standards might benefit from a documented discussion o Original:
f potential human rights risks arising from potential misapplications of the pro In general, considerations of rights are likely to be
tocol or technology described in the Request For Comments (RFC). This might be c more effective if they are considered given a purpose and specific
oupled with an Applicability Statement for that RFC.</t> use cases, rather than as abstract absolute goals.
<t>Note that the guidance provided in this section does not recommend specific p Perhaps:
ractices. The range of protocols developed in the IETF is too broad to make reco In general, considerations of rights are likely to be
mmendations about particular uses of data or how human rights might be balanced more effective if they have a purpose and specific
against other design goals. However, by carefully considering the answers to th use cases rather than abstract, absolute goals.
e following questions, document authors should be able to produce a comprehensiv -->
e analysis that can serve as the basis for discussion on whether the protocol ad
equately takes specific human rights threats into account. This guidance is mean
t to help the thought process of a human rights analysis; it does not provide sp
ecific directions for how to write a human rights considerations section (follow
ing the example set in <xref target="RFC6973"/>).</t>
<t>In considering these questions, authors will need to be aware of the potentia In general, considerations of rights are likely to be more effective if th
l of technical advances or the passage of time to undermine protections. In gene ey are considered given a purpose and specific use cases, rather than as abstrac
ral, considerations of rights are likely to be more effective if they are consid t, absolute goals.</t>
ered given a purpose and specific use cases, rather than as abstract absolute go <t>Also note that while the section uses the word "protocol", the principl
als.</t> es identified in these questions may be applicable to other types of solutions (
extensions to existing protocols, architecture for solutions to specific problem
s, etc.).</t>
<t>Also note that while the section uses the word, ‘protocol’, the principles id <!--[rfced] In Sections 4.1-4.21, does each section need to have "Question(s)",
entified in these questions may be applicable to other types of solutions (exten "Explanation", "Example", and "Impacts" entries? We note that some of these
sions to existing protocols, architecture for solutions to specific problems, et entries are missing from the sections. Please let us know if entries should be
c.).</t> added.
-->
<section anchor="intermediaries" title="Intermediaries"> <section anchor="intermediaries" numbered="true" toc="default">
<t>Question(s): <name>Intermediaries</name>
<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:
The end-to-end principle <xref target="Saltzer" format="default"/> holds
that certain functions can and should be performed at "ends" of the network. <xr
ef target="RFC1958" format="default"/> states that "in very general terms, the c
ommunity believes that the goal is connectivity ... and the intelligence is end
to end rather than hidden in the network".
<t>Explanation: <!--[rfced] Section 4.1 - As the number of commas make this sentence difficult
The end-to-end principle <xref target="Saltzer"/> holds that certain functions c to parse, may we update it as follows?
an and should be performed at ‘ends’ of the network. <xref target="RFC1958"/> st
ates “that in very general terms, the community believes that the goal is connec
tivity […] and the intelligence is end to end rather than hidden in the network.
” When a protocol exchange includes both endpoints and an intermediary, there ar
e new opportunities for failure, especially when the intermediary is not under c
ontrol of either endpoint, or even largely invisible to it, as, for instance, in
intercepting HTTPS proxies <xref target="https-interception"/>. This pattern al
so contributes to ossification, because the intermediaries may impose protocol r
estrictions – sometimes in violation of the specification – that prevent the end
points from using more modern protocols, as described in Section 9.3 of <xref ta
rget="RFC8446"/>.</t>
<t>Note that intermediaries are distinct from services: in the former case the t
hird party element is part of the protocol exchange, whereas in the latter the e
ndpoints communicate explicitly with the service. The client/server pattern prov
ides clearer separation of responsibilities between elements than having an inte
rmediary. However, even in client/server systems, it is often good practice to p
rovide for end-to-end encryption between endpoints for protocol elements which a
re outside of the scope of the service, as in the design of MLS <xref target="I-
D.ietf-mls-protocol"/>.</t>
<t>Example:
Encryption between the endpoints can be used to protect the protocol from interf
erence by intermediaries. The encryption of transport layer information in QUIC
<xref target="RFC9000"/> and of the TLS Server Name Indication field <xref targe
t="I-D.ietf-tls-esni"/> are examples of this practice. One consequence of this i
s to limit the extent to which network operators can inspect traffic, requiring
them to have control of the endpoints in order to monitor their behavior.</t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to freedom of expression</t>
<t>Right to freedom of assembly and association</t>
</list></t>
</section>
<section anchor="connectivity" title="Connectivity">
<t>Questions(s):
Is your protocol optimized for low bandwidth and high latency connections? Could
your protocol also be developed in a stateless manner?</t>
<t>Also considering the fact that network quality and conditions vary across geo
graphy and time, it is also important to design protocols such that they are rel
iable even on low bandwidth and high latency connections.</t>
<t>Impacts:</t>
<t><list style="symbols"> Original:
<t>Right to freedom of expression</t> When a protocol exchange includes
<t>Right to freedom of assembly and association</t> both endpoints and an intermediary, there are new opportunities for
</list></t> failure, especially when the intermediary is not under control of
either endpoint, or even largely invisible to it, as, for instance,
in intercepting HTTPS proxies [https-interception].
</section> Perhaps:
<section anchor="reliability" title="Reliability"> There are new opportunities for failure when a protocol exchange includes
both endpoints and an intermediary, especially when the intermediary is
not under control of either endpoint, or is even largely invisible to it,
for instance, as with intercepting HTTPS proxies [HTTPS-interception].
-->
<t>Question(s): When a protocol exchange includes both endpoints and an intermediary, the
re are new opportunities for failure, especially when the intermediary is not un
der control of either endpoint, or even largely invisible to it, as in, for inst
ance, intercepting HTTPS proxies <xref target="HTTPS-interception" format="defau
lt"/>. This pattern also contributes to ossification because the intermediaries
may impose protocol restrictions -- sometimes in violation of the specification
-- that prevent the endpoints from using more modern protocols, as described in
<xref target="RFC8446" sectionFormat="of" section="9.3"/>.</t>
<t>Note that intermediaries are distinct from services. In the former ca
se, the third-party element is part of the protocol exchange; whereas in the lat
ter, the endpoints communicate explicitly with the service. The client/server pa
ttern provides clearer separation of responsibilities between elements than havi
ng an intermediary. However, even in client/server systems, it is often good pra
ctice to provide for end-to-end encryption between endpoints for protocol elemen
ts that are outside of the scope of the service, as in the design of Messaging L
ayer Security (MLS) <xref target="RFC9420" format="default"/>.</t>
<t>Example:
Encryption between the endpoints can be used to protect the protocol from interf
erence by intermediaries. The encryption of transport layer information in QUIC
<xref target="RFC9000" format="default"/> and of the TLS Server Name Indication
(SNI) field <xref target="I-D.ietf-tls-esni" format="default"/> are examples of
this practice. One consequence of this is to limit the extent to which network o
perators can inspect traffic, requiring them to have control of the endpoints in
order to monitor their behavior.</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="connectivity" numbered="true" toc="default">
<name>Connectivity</name>
<t>Questions(s):
Is your protocol optimized for low-bandwidth and high-latency connections? Could
your protocol also be developed in a stateless manner?</t>
<t>Considering the fact that network quality and conditions vary across
geography and time, it is also important to design protocols such that they are
reliable even on low-bandwidth and high-latency connections.</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="reliability" numbered="true" toc="default">
<name>Reliability</name>
<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 charset (which must be UTF
-8) or several (which is dangerous for interoperability)? If character sets 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: <t>Many protocols that handle text only handle one charset (US-ASCII) or
See localization</t> leave the question of what coded character set and encoding are used up to loca
l guesswork (which leads, of course, to interoperability problems). If multiple
charsets are permitted, they must be explicitly identified <xref target="RFC2277
" format="default"/>. Adding non-ASCII text to a protocol allows the protocol t
o handle more scripts, hopefully representing users across the world. In today'
s world, 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.)
<t>Impacts:</t> <!--[rfced] Section 4.5 - We question the accuracy of the sentence below,
particularly in regards to the IETF's mission. As making the Internet a
"global network of networks" is not stated in RFC 3935, should that
statement be removed from the sentence?
<t><list style="symbols"> Original:
<t>Right to freedom of expression</t> Although this
<t>Right to political participation</t> is reasonable practice for non-user visible elements, given the
<t>Right to participate in cultural life, arts and science</t> IETF's mission to make the Internet a global network of networks,
</list></t> [RFC3935] developers should provide full and equal support for all
scripts and character sets in the user-facing features of protocols
and for any content they carry.
</section> Perhaps:
<section anchor="localization" title="Localization"> Although this
is reasonable practice for non-user visible elements, developers should
provide full and equal support for all scripts and character sets in
the user-facing features of protocols and for any content they carry.
-->
<t>Question(s): Although this is reasonable practice for non-user-visible elements, given the IE
TF's mission to make the Internet a global network of networks <xref target="RFC
3935" format="default"/>, developers should provide full and equal support for a
ll scripts and character sets in the user-facing features of protocols and for a
ny 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
lication or document content to meet the language, cultural and other requiremen
ts of a specific target market (a 'locale')" <xref target="W3Ci18nDef" format="d
efault"/>. For our purposes, it can be described as the practice of translating
an implementation to make it functional in a specific language or for users in a
specific locale (see <xref target="internationalization"/> ("Internationalizati
on")). Internationalization is related to localization, but they are not the sam
e. Internationalization is a necessary precondition for localization.</t>
<t>Example:
The Internet is a global medium, but many of its protocols and products are deve
loped with certain audiences in mind that often share particular characteristics
like knowing how to read and write in American Standard Code for Information In
terchange (ASCII) and knowing English. This limits the ability of a large part o
f the world's online population from using the Internet in a way that is cultura
lly and linguistically accessible. An example of a standard that has taken into
account the view that individuals like to have access to data in their native la
nguage can be found in <xref target="RFC5646" format="default"/>. The document d
escribes a way to label information with an identifier for the language in which
it is written. And this allows information to be presented and accessed in more
than one language.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to non-discrimination</li>
<li>Right to participate in cultural life, arts, and science</li>
<li>Right to freedom of expression</li>
</ul>
</section>
<section anchor="open-standards" numbered="true" toc="default">
<name>Open Standards</name>
<t>Explanation: <!--[rfced] Section 4.7 - To improve readability by avoiding use of a double
Localization refers to the adaptation of a product, application or document cont negative (i.e., "not" and "without"), may we update this sentence as follows?
ent to meet the language, cultural and other requirements of a specific target m
arket (a locale) <xref target="W3Ci18nDef"/>. For our purposes, it can be descri
bed as the practice of translating an implementation to make it functional in a
specific language or for users in a specific locale (see Internationalization).
Internationalization is related to localization, but they are not the same. Inte
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
loped with a certain audience in mind, that often share particular characteristi
cs like knowing how to read and write in American Standard Code for Information
Interchange (ASCII) and knowing English. This limits the ability of a large part
of the world’s online population from using the Internet in a way that is cultu
rally and linguistically accessible. An example of a standard that has taken int
o account the view that individuals like to have access to data in their native
language can be found in <xref target="RFC5646"/>. The document describes a way
to label information with an identifier for the language in which it is written.
And this allows information to be presented and accessed in more than one langu
age.</t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to non-discrimination</t>
<t>Right to participate in cultural life, arts and science</t>
<t>Right to freedom of expression</t>
</list></t>
</section>
<section anchor="open-standards" title="Open Standards">
<t>Question(s):
Is your protocol fully documented in a way that it could be easily implemented,
improved, built upon and/or further developed? Do you depend on proprietary code
for the implementation, running or further development of your protocol? Does y
our protocol favor a particular proprietary specification over technically-equiv
alent competing specification(s), for instance by making any incorporated vendor
specification “required” or “recommended” <xref target="RFC2026"/>? Do you nor
matively reference another standard that is not available without cost (and coul
d you do without it)? Are you aware of any patents that would prevent your stand
ard from being fully implemented <xref target="RFC8179"/> <xref target="RFC6701"
/>?</t>
<t>Explanation:
The Internet was able to be developed into the global network of networks becaus
e of the existence of open, non-proprietary standards <xref target="Zittrain"/>.
They are crucial for enabling interoperability. Yet, open standards are not exp
licitly defined within the IETF. On the subject, <xref target="RFC2026"/> states
: “Various national and international standards bodies, such as ANSI, ISO, IEEE,
and ITU-T, develop a variety of protocol and service specifications that are si
milar to Technical Specifications defined at the IETF. National and internationa
l groups also publish “implementors’ agreements” that are analogous to Applicabi
lity Statements, capturing a body of implementation-specific detail concerned wi
th the practical application of their standards. All of these are considered to
be “open external standards” for the purposes of the Internet Standards Process
.” Similarly, <xref target="RFC3935"/> does not define open standards but does e
mphasize the importance of an “open process”, i.e., “any interested person can p
articipate in the work, know what is being decided, and make [their] voice heard
on the issue.”</t>
<t>Open standards (and open source software) allow users to glean information ab Original:
out how the tools they are using work, including the tools’ security and privacy Do you normatively reference another standard that is not available
properties. They additionally allow for permissionless innovation, which is imp without cost (and could you do without it)?
ortant to maintain the freedom and ability to freely create and deploy new proto
cols on top of the communications constructs that currently exist. It is at the
heart of the Internet as we know it, and to maintain its fundamentally open natu
re, we need to be mindful of the need for developing open standards.</t>
<t>All standards that need to be normatively implemented should be freely availa Perhaps:
ble and with reasonable protection for patent infringement claims, so it can als Do you normatively reference another standard that is behind a paywall
o be implemented in open source or free software. Patents have often held back o (and could you do without it)?
pen standardization or been used against those deploying open standards, particu -->
larly in the domain of cryptography <xref target="newegg"/>. An exemption of thi
s is sometimes made when a protocol is standardized that normatively relies on s
pecifications produced by others standards development organizations (SDOs) that
are not freely available. Patents in open standards or in normative references
to other standards should have a patent disclosure <xref target="notewell"/>, ro
yalty-free licensing <xref target="patentpolicy"/>, or some other form of fair,
reasonable and non-discriminatory terms.</t>
<t>Example: <t>Question(s):
<xref target="RFC6108"/> describes a system for providing critical end-user noti Is your protocol fully documented in a way that it could be easily implemented,
fications to web browsers, which has been deployed by Comcast, an Internet Servi improved, built upon, and/or further developed? Do you depend on proprietary cod
ce Provider (ISP). Such a notification system is being used to provide near-imme e for the implementation, running, or further development of your protocol? Does
diate notifications to customers, such as to warn them that their traffic exhibi your protocol favor a particular proprietary specification over technically equ
ts patterns that are indicative of malware or virus infection. There are other p ivalent competing specification(s), for instance, by making any incorporated ven
roprietary systems that can perform such notifications, but those systems utiliz dor specification "required" or "recommended" <xref target="RFC2026" format="de
e Deep Packet Inspection (DPI) technology. In contrast, that document describes fault"/>? Do you normatively reference another standard that is not available wi
a system that does not rely upon DPI, and is instead based on open IETF standard thout cost (and could you do without it)? Are you aware of any patents that woul
s and open source applications.</t> d prevent your standard from being fully implemented <xref target="RFC8179" form
at="default"/> <xref target="RFC6701" format="default"/>?</t>
<t>Explanation:
The Internet was able to be developed into the global network of networks becaus
e of the existence of open, non-proprietary standards <xref target="Zittrain" fo
rmat="default"/>. They are crucial for enabling interoperability. Yet, open stan
dards are not explicitly defined within the IETF. On the subject, <xref target="
RFC2026" format="default"/> states:</t>
<blockquote>Various national and international standards bodies, such as ANSI, I
SO, IEEE, and ITU-T, develop a variety of protocol and service specifications th
at are similar to Technical Specifications defined here [at the IETF]. National
and international groups also publish "implementors' agreements" that are analog
ous to Applicability Statements, capturing a body of implementation-specific det
ail concerned with the practical application of their standards. All of these ar
e considered to be "open external standards" for the purposes of the Internet St
andards Process.</blockquote>
<t>Similarly, <xref target="RFC3935" format="default"/> does not define open sta
ndards but does emphasize the importance of an "open process", i.e.:</t>
<blockquote>... any interested person can participate in the work, know what is
being decided, and make [their] voice heard on the issue.</blockquote>
<t>Open standards (and open source software) allow users to glean inform
ation about how the tools they are using work, including the tools' security and
privacy properties. They additionally allow for permissionless innovation, whic
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
at the heart of the Internet as we know it, and to maintain its fundamentally o
pen nature, we need to be mindful of the need for developing open standards.</t>
<t>All standards that need to be normatively implemented should be freel
y available and with reasonable protection for patent infringement claims so tha
t they can also be implemented in open source or free software. Patents have oft
en held back open standardization or been used against those deploying open stan
dards, particularly in the domain of cryptography <xref target="Newegg" format="
default"/>.
<t>Impacts:</t> <!--[rfced] Section 4.7 - To improve the readability of this sentence, may
we update "when a protocol is standardized that" to "when a standardized
protocol"?
<t><list style="symbols"> Original:
<t>Right to freedom of expression</t> An exemption of this is sometimes
<t>Right to participate in cultural life, arts and science</t> made when a protocol is standardized that normatively relies on
</list></t> specifications produced by others standards development organizations
(SDOs) that are not freely available.
</section> Perhaps:
<section anchor="heterogeneity-support" title="Heterogeneity Support"> An exemption of this is sometimes
made when a standardized protocol normatively relies on
specifications produced by others Standards Development Organizations
(SDOs) that are not freely available.
-->
<t>Question(s): An exemption of this is sometimes made when a protocol is standardized th
at normatively relies on specifications produced by others Standards Development
Organizations (SDOs) that are not freely available. Patents in open standards o
r in normative references to other standards should have a patent disclosure <xr
ef target="Note-well" format="default"/>, royalty-free licensing <xref target="P
atent-policy" format="default"/>, or some other form of fair, reasonable, and no
n-discriminatory terms.</t>
<t>Example:
<xref target="RFC6108" format="default"/> describes a system for providing criti
cal end-user notifications to web browsers, which has been deployed by Comcast,
an Internet Service Provider (ISP). Such a notification system is being used to
provide near-immediate notifications to customers, such as to warn them that the
ir traffic exhibits patterns that are indicative of malware or virus infection.
There are other proprietary systems that can perform such notifications, but tho
se systems utilize Deep Packet Inspection (DPI) technology. In contrast, that do
cument describes a system that does not rely upon DPI and is instead based on op
en IETF standards and open source applications.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to freedom of expression</li>
<li>Right to participate in cultural life, arts, and science</li>
</ul>
</section>
<section anchor="heterogeneity-support" numbered="true" toc="default">
<name>Heterogeneity Support</name>
<t>Question(s):
Does your protocol support heterogeneity by design? Does your protocol allow for multiple types of hardware? Does your protocol allow for multiple types of 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:
The Internet is characterized by heterogeneity on many levels: devices, nodes, r
outer scheduling algorithms, queue management mechanisms, routing protocols, lev
els of multiplexing, protocol versions and implementations, and underlying link
layers (e.g., point-to-point, multi-access links, wireless, Fiber Distributed Da
ta Interface (FDDI), etc.) in the traffic mix and in the levels of congestion at
different times and places. Moreover, as the Internet is composed of autonomous
organizations and ISPs, each with their own separate policy concerns, there is
a large heterogeneity of administrative domains and pricing structures. As a res
ult, the heterogeneity principle proposed in <xref target="RFC1958" format="defa
ult"/> needs to be supported by design <xref target="FIArch" format="default"/>.
</t>
<t>Heterogeneity support in protocols can, thus, enable a wide range of
devices and (by extension) users to participate on the network.</t>
<t>Explanation: <!-- [rfced] Section 4.8 - Please note that since it is not known who
The Internet is characterized by heterogeneity on many levels: devices and nodes originally said the following quote (for example, it has also been attributed
, router scheduling algorithms and queue management mechanisms, routing protocol to baseball player Yogi Berra), may we update the wording to avoid future
s, levels of multiplexing, protocol versions and implementations, underlying lin possible errata.
k layers (e.g., point-to-point, multi-access links, wireless, FDDI, etc.), in th
e traffic mix and in the levels of congestion at different times and places. Mor
eover, as the Internet is composed of autonomous organizations and ISPs, each wi
th their own separate policy concerns, there is a large heterogeneity of adminis
trative domains and pricing structures. As a result, the heterogeneity principle
proposed in <xref target="RFC1958"/> needs to be supported by design <xref targ
et="FIArch"/>.</t>
<t>Heterogeneity support in protocols can thus enable a wide range of devices an
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: Original:
Adaptability is closely interrelated with permissionless innovation: both mainta Niels Bohr famously said:
in the freedom and ability to freely create and deploy new protocols on top of t "Prediction is very difficult, especially if it's about the future",
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 Perhaps:
etworks as preferenced by groups of users. Furthermore, a precondition of adapta There is a famous quote often attributed to Niels Bohr:
bility is the ability of the people who can adapt the network to be able to know "Prediction is very difficult, especially if it's about the future."
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"/>. Niels Bohr famously said: "Predi
APIs) are developed to support applications from different voice service provide ction is very difficult, especially if it's about the future." This also holds t
rs. Multiple parties will have similar capabilities, in order to ensure that all rue for future uses of the Internet architecture and infrastructure. Therefore,
parties can build upon existing standards these need to be adaptable, and allow as a rule of thumb, it is important to -- as far as possible -- design your prot
for permissionless innovation.</t> ocol for different devices and uses, especially at lower layers of the stack. Ho
wever, if you choose not to do this, it could be relevant to document the reason
<t>Impacts:</t> ing 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>Alice wants to communicate with Bob.
Alice sends data to Bob.
Corinne intercepts the data sent to Bob.
Corinne reads and alters the message to Bob.
Bob is unable to verify whether that the data came from Alice.</t>
<t>Impacts:</t>
<t><list style="symbols">
<t>Right to privacy</t>
<t>Right to freedom of expression</t>
<t>Right to security</t>
</list></t>
</section> <!--[rfced] Section 4.11 - Should "With proper authentication" be updated to
<section anchor="confidentiality" title="Confidentiality"> "Without proper authentication"?
<t>Question(s): Original:
Does the protocol expose the transmitted data over the wire? Does the protocol e With proper authentication, the scenario would be as follows:
xpose information related to identifiers or data? If so, what does it reveal to
each protocol entity (i.e., recipients, intermediaries, and enablers) <xref targ
et="RFC6973"/>? What options exist for protocol implementers to choose to limit
the information shared with each entity? What operational controls are available
to limit the information shared with each entity?</t>
<t>What controls or consent mechanisms does the protocol define or require befor Alice wants to communicate with Bob. Alice sends data to Bob.
e personal data or identifiers are shared or exposed via the protocol? If no suc Corinne intercepts the data sent to Bob. Corinne reads and alters
h mechanisms or controls are specified, is it expected that control and consent the message to Bob. Bob is unable to verify whether that the data
will be handled outside of the protocol?</t> came from Alice.
<t>Does the protocol provide ways for initiators to share different pieces of in Perhaps:
formation with different recipients? If not, are there mechanisms that exist out Without proper authentication, the scenario would be as follows:
side of the protocol to provide initiators with such control?</t>
<t>Does the protocol provide ways for initiators to limit the sharing or express Alice wants to communicate with Bob. Alice sends data to Bob.
individuals’ preferences to recipients or intermediaries with regard to the col Corinne intercepts the data sent to Bob. Corinne reads and alters
lection, use, or disclosure of their personal data? If not, are there mechanisms the message to Bob. Bob is unable to verify whether that the data
that exist outside of the protocol to provide users with such control? Is it ex came from Alice.
pected that users will have relationships that govern the use of the information -->
(contractual or otherwise) with those who operate these intermediaries? Does th
e protocol prefer encryption over clear text operation?</t>
<t>Explanation: <t>With proper authentication, the scenario would be as follows:</t>
Confidentiality refers to keeping your data secret from unintended listeners <xr <t>Alice wants to communicate with Bob.
ef target="BCP72"/>. The growth of the Internet depends on users having confiden Alice sends data to Bob.
ce that the network protects their personal data <xref target="RFC1984"/>. The p Corinne intercepts the data sent to Bob.
ossibility of pervasive monitoring and surveillance undermines users’ trust, and Corinne reads and alters the message to Bob.
can be mitigated by ensuring confidentiality, i.e., passive attackers should ga Bob is unable to verify whether that the data came from Alice.</t>
in little or no information from observation or inference of protocol activity. <t>Impacts:</t>
<xref target="RFC7258"/><xref target="RFC7624"/>.</t> <ul spacing="normal">
<li>Right to privacy</li>
<li>Right to freedom of expression</li>
<li>Right to security</li>
</ul>
</section>
<section anchor="confidentiality" numbered="true" toc="default">
<name>Confidentiality</name>
<t>Question(s):
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
each protocol entity (i.e., recipients, intermediaries, and enablers) <xref targ
et="RFC6973" format="default"/>? What options exist for protocol implementers to
choose to limit the information shared with each entity? What operational contr
ols are available to limit the information shared with each entity?</t>
<t>What controls or consent mechanisms does the protocol define or requi
re before personal data or identifiers are shared or exposed via the protocol? I
f no such mechanisms or controls are specified, is it expected that control and
consent will be handled outside of the protocol?</t>
<t>Does the protocol provide ways for initiators to share different piec
es of information with different recipients? If not, are there mechanisms that e
xist outside of the protocol to provide initiators with such control?</t>
<t>Does the protocol provide ways for initiators to limit the sharing or
expressing of individuals' preferences to recipients or intermediaries with reg
ard to the collection, use, or disclosure of their personal data? If not, are th
ere mechanisms that exist outside of the protocol to provide users with such con
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
aries? Does the protocol prefer encryption over cleartext operation?</t>
<t>Explanation:
Confidentiality refers to keeping your data secret from unintended listeners <xr
ef target="BCP72" format="default"/>. The growth of the Internet depends on user
s having confidence that the network protects their personal data <xref target="
RFC1984" format="default"/>. The possibility of pervasive monitoring and surveil
lance undermines users' trust and can be mitigated by ensuring confidentiality,
i.e., passive attackers should gain little or no information from observation or
inference of protocol activity <xref target="RFC7258" format="default"/> <xref
target="RFC7624" format="default"/>.</t>
<t>Example:
Protocols that do not encrypt their payload make the entire content of the commu
nication available to the idealized attacker along their path. Following the adv
ice in <xref target="RFC3365" format="default"/>, most such protocols have a sec
ure variant that encrypts the payload for confidentiality, and these secure vari
ants are seeing ever-wider deployment. A noteworthy exception is DNS <xref targe
t="RFC1035" format="default"/>, as DNSSEC <xref target="RFC4033" format="default
"/> does not have confidentiality as a requirement. This implies that, in the ab
sence of the use of more recent standards like DNS over TLS <xref target="RFC785
8" format="default"/> or DNS over HTTPS <xref target="RFC8484" format="default"/
>, all DNS queries and answers generated by the activities of any protocol are a
vailable to the attacker. When store-and-forward protocols are used (e.g., SMTP
<xref target="RFC5321" format="default"/>), intermediaries leave this data subje
ct to observation by an attacker that has compromised these intermediaries, unle
ss the data is encrypted end-to-end by the application-layer protocol or the imp
lementation uses an encrypted store for this data <xref target="RFC7624" format=
"default"/>.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to privacy</li>
<li>Right to security</li>
</ul>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security</name>
<t>Question(s):
Did you have a look at <xref target="BCP72" format="default"> "Guidelines for Wr
iting RFC Text on Security Considerations"</xref>? Have you found any attacks th
at are somewhat related to your protocol/specification yet considered out of sco
pe of your document? Would these attacks be pertinent to the human-rights-enabli
ng features of the Internet (as described throughout this document)?</t>
<t>Explanation:
Security is not a single monolithic property of a protocol or system but rather
a series of related yet somewhat independent properties. Not all of these proper
ties are required for every application. Since communications are carried out by
systems and access to systems is through communications channels, security goal
s obviously interlock, but they can also be independently provided <xref target=
"BCP72" format="default"/>.</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)
and active attacks (when an attacker is capable of writing information to the n
etwork packets) <xref target="BCP72" format="default"/>.</t>
<t>Example:
See <xref target="BCP72" 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>
<li>Right to non-discrimination</li>
<li>Right to security</li>
</ul>
</section>
<section anchor="privacy" numbered="true" toc="default">
<name>Privacy</name>
<t>Question(s):
Did you have a look at the guidelines described in Section <xref target="RFC6973
" sectionFormat="bare" section="7"/> of "Privacy Considerations for Internet Pro
tocols" <xref target="RFC6973"/>? Does your protocol maintain the confidentialit
y of metadata? Could your protocol counter traffic analysis? Does your protocol
adhere to data minimization principles? Does your document identify potentially
sensitive data logged by your protocol and/or for how long that needs to be ret
ained for technical reasons?</t>
<t>Explanation:
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
nment, including the degree to which the entity is willing to share its personal
information with others <xref target="RFC4949" format="default"/>.
<t>Example: <!--[rfced] Section 4.12 - To avoid the repetition of "themselves", may we updat
Protocols that do not encrypt their payload make the entire content of the commu e
nication available to the idealized attacker along their path. Following the adv this sentence as follows?
ice in <xref target="RFC3365"/>, most such protocols have a secure variant that
encrypts the payload for confidentiality, and these secure variants are seeing e
ver-wider deployment. A noteworthy exception is DNS <xref target="RFC1035"/>, as
DNSSEC <xref target="RFC4033"/> does not have confidentiality as a requirement.
This implies that, in the absence of the use of more recent standards like DNS
over TLS <xref target="RFC7858"/> or DNS over HTTPS <xref target="RFC8484"/>, al
l DNS queries and answers generated by the activities of any protocol are availa
ble to the attacker. When store-and-forward protocols are used (e.g., SMTP <xref
target="RFC5321"/>), intermediaries leave this data subject to observation by a
n attacker that has compromised these intermediaries, unless the data is encrypt
ed end-to-end by the application-layer protocol or the implementation uses an en
crypted store for this data <xref target="RFC7624"/>.</t>
<t>Impacts:</t> Original:
If a protocol provides insufficient privacy protection it
may have a negative impact on freedom of expression as users self-
censor for fear of surveillance, or find themselves unable to express
themselves freely.
<t><list style="symbols"> Perhaps:
<t>Right to privacy</t> If a protocol provides insufficient privacy protection, it
<t>Right to security</t> may have a negative impact on freedom of expression as users self-
</list></t> censor for fear of surveillance or find that they are unable to express
themselves freely.
-->
</section> If a protocol provides insufficient privacy protection, it may have a neg
<section anchor="security" title="Security"> ative impact on freedom of expression as users self-censor for fear of surveilla
nce or find themselves unable to express themselves freely.</t>
<t>Example:
See <xref target="RFC6973" format="default"/>.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to freedom of expression</li>
<li>Right to privacy</li>
<li>Right to non-discrimination</li>
</ul>
</section>
<section anchor="anonymity-and-pseudonymity" numbered="true" toc="default"
>
<name>Anonymity and Pseudonymity</name>
<t>Question(s): Does your protocol make use of identifiers? Are these
identifiers persistent? Are they used across multiple contexts? Is it
possible for the user to reset or rotate them without negatively
impacting the operation of the protocol? Are they visible to others
besides the protocol endpoints? Are they tied to real-world
identities? Have you considered "<xref target="RFC6973" format="title"/>" <xref
target="RFC6973" format="default"/>, especially Section <xref target="RFC6973" s
ectionFormat="bare" section="6.1.2"/>?</t>
<t>Explanation:
Most protocols depend on the use of some kind of identifier in order to correlat
e
activity over time and space. For instance:</t>
<ul spacing="normal">
<li>IP addresses are used as an identity for the source and
destination for IP datagrams.</li>
<li>QUIC connection identifiers are used to correlate packets
belonging to the same connection.</li>
<li>HTTP uses cookies to correlate multiple HTTP requests from the
same client.</li>
<li>Email uses email addresses of the form example@example.com to
identify senders and receivers.</li>
</ul>
<t>In general, these identifiers serve a necessary function for protocol
operations
by allowing them to maintain continuity. However, they can also create privacy
risks. There are two major ways in which those risks manifest:</t>
<ul spacing="normal">
<li>The identifier may itself reveal the user's identity in some way
or be tied to an identifier that does, as is the case when E.164
(telephone) numbers are used as identifiers for instant messaging
systems.</li>
<li>While the identifier may not reveal the user's identity, it may
make it possible to link enough of a user's behavior to threaten
their privacy, as is the case with HTTP cookies.</li>
</ul>
<t>Because identifiers are necessary for protocol operation, true anonym
ity
is very difficult to achieve, but there are practices that promote
user privacy even when identifiers are used.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to non-discrimination</li>
<li>Right to freedom of expression</li>
<li>Right to political participation</li>
<li>Right to freedom of assembly and association</li>
</ul>
<section anchor="pseudonymity" numbered="true" toc="default">
<name>Pseudonymity</name>
<t>In general, user privacy is better preserved when identifiers are
pseudonymous (not tied to a user's real-world identity).</t>
<t>Example: In the development of the IPv6 protocol, it was discussed
to
embed a Media Access Control (MAC) address into unique IP
addresses. This would make it possible for eavesdroppers and other
information collectors to identify when different addresses used in
different transactions actually correspond to the same node. This is
why standardization efforts like "<xref target="RFC8981" format="title"/>" <xref
target="RFC8981" format="default"/> and MAC address
randomization <xref target="I-D.ietf-madinas-mac-address-randomization" format="
default"/> have been
pursued.</t>
<t>Note that it is often attractive to try to create a pseudonym from
a persistent identifier. This can be very difficult to do correctly
in a way that does not allow for recovering the persistent identifiers.</t>
<t>Example: A common practice in web tracking is to "encrypt" email
addresses by hashing them, thus allegedly making them
"non-personally identifying". However, because hash functions
are public operations, it is possible to do a dictionary search for candidate
email addresses and recover the original address <xref target="Email-hashing" fo
rmat="default"/>.</t>
</section>
<section anchor="unlinkability" numbered="true" toc="default">
<name>Unlinkability</name>
<t>Even true pseudonymous identifiers can present a privacy risk if th
ey
are used across a wide enough scope. User privacy is better preserved
if identifiers have limited scope both in time and space.</t>
<t>Question(s): <!-- [rfced] Section 4.15.2 - Does "before [RFC7844]" refer to A) before the
Did you have a look at Guidelines for Writing RFC Text on Security Consideration writing of RFC 7844 or B) before DHCP?
s <xref target="BCP72"/>? Have you found any attacks that are somewhat related t
o your protocol/specification, yet considered out of scope of your document? Wou
ld these attacks be pertinent to the human rights enabling features of the Inter
net (as described throughout this document)?</t>
<t>Explanation: Original:
Security is not a single monolithic property of a protocol or system, but rather Example: An example is Dynamic Host Configuration Protocol (DHCP)
a series of related but somewhat independent properties. Not all of these prope where sending a persistent identifier as the client name was not
rties are required for every application. Since communications are carried out b mandatory but, in practice, done by many implementations, before
y systems and access to systems is through communications channels, security goa [RFC7844].
ls obviously interlock, but they can also be independently provided. <xref targe
t="BCP72"/>.</t>
<t>Typically, any protocol operating on the Internet can be the target of passiv Perhaps A:
e attacks (when the attacker can access and read packets on the network); active Example: An example is the Dynamic Host Configuration Protocol (DHCP)
attacks (when an attacker is capable of writing information to the network pack where sending a persistent identifier as the client name was not
ets). <xref target="BCP72"/></t> mandatory but, in practice, done by many implementations before
the writing of [RFC7844].
<t>Example: Perhaps B:
See <xref target="BCP72"/>.</t> Example: An example is the Dynamic Host Configuration Protocol (DHCP)
where sending a persistent identifier as the client name was not
mandatory but, in practice, done by many implementations before
DHCP [RFC7844].
-->
<t>Impacts:</t> <t>Example: An example is the Dynamic Host Configuration Protocol (DHC
P)
where sending a persistent identifier as the client name was not
mandatory but, in practice, done by many implementations, before
<xref target="RFC7844" format="default"/>.</t>
<t>Example: Third-party cookies in HTTP allow trackers to correlate
HTTP traffic across sites. This is the foundation of a whole
ecosystem of web tracking. Increasingly, web browsers are restricting
the use of third-party cookies in order to protect user privacy.</t>
</section>
</section>
<section anchor="censorship-resistance" numbered="true" toc="default">
<name>Censorship Resistance</name>
<t>Question(s):
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
e used to selectively block certain kinds of traffic? Could it be designed to be
more censorship resistant? Does your protocol make it apparent or transparent w
hen access to a resource is restricted and 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
survey of censorship techniques employed across the world, see <xref target="RFC
9505" format="default"/>, which lays out protocol properties that have been expl
oited to censor access to information. Censorship resistance refers to the metho
ds and measures to prevent Internet censorship.</t>
<t>Example:
The current design of the Web has a number of architectural choke points where i
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
ver, IP address blocking, and blocking at the web server. There has been extensi
ve work on content distribution systems, which are intended to be more censorshi
p resistant; and some, such as BitTorrent, are in wide use. However, these syste
ms may have inferior reliability and performance compared to the Web (e.g., they
do not support active content on the server).</t>
<t>Example:
Identifiers of content exposed within a protocol might be used to facilitate cen
sorship by allowing the censor to determine which traffic to block. DNS queries,
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
elements that can travel in plaintext and be used by censors to identify what c
ontent a user is trying to access <xref target="RFC9505" format="default"/>. Pro
tocol mechanisms such as Encrypted ClientHello <xref target="I-D.ietf-tls-esni"
format="default"/> or DNS over HTTPS <xref target="RFC8484" format="default"/> t
hat encrypt metadata provide some level of resistance to this type of protocol i
nspection. Full traffic encryption systems, such as Tor <eref target="https://to
rproject.org" brackets="angle"/>, can also be used by people to access otherwise
censored resources.</t>
<t>Example: As noted above, one way to censor web traffic is to require
the server to block it or require ISPs to block requests to the server. In HTTP,
denial or restriction of access can be made apparent by the use of status code
451, which allows server operators and intermediaries to operate with greater tr
ansparency in circumstances where issues of law or public policy affect their op
eration <xref target="RFC7725" format="default"/>. If a protocol potentially ena
bles censorship, protocol designers should strive towards creating error codes t
hat capture different scenarios (e.g., blocked due to administrative policy, una
vailable because of legal requirements, etc.) to minimize ambiguity for end user
s.</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>
<li>Right to freedom of assembly and association</li>
</ul>
</section>
<section anchor="outcome-transparency" numbered="true" toc="default">
<name>Outcome Transparency</name>
<t>Question(s): Are the intended and foreseen effects of your protocol d
ocumented and easily comprehensible?</t>
<t><list style="symbols"> <!--[rfced] Section 4.17 - Should the questions in the Explanation be
<t>Right to freedom of expression</t> moved up to the Question(s) entry?
<t>Right to freedom of assembly and association</t>
<t>Right to non-discrimination</t>
<t>Right to security</t>
</list></t>
</section> Original:
<section anchor="privacy" title="Privacy"> Question(s): Are the intended and forseen effects of your protocol
documented and easily comprehensible?
<t>Question(s): Explanation: Certain technical choices may have unintended
Did you have a look at the Guidelines in the Privacy Considerations for Internet consequences. Have you described the central use case(s) for your
Protocols <xref target="RFC6973"/> section 7? Does your protocol maintain the c protocol with a clear description of expected behavior and how it
onfidentiality of metadata? Could your protocol counter traffic analysis? Does y may, or may not, impact other protocols, implementations, user
our protocol adhere to data minimization principles? Does your document identif expectations, or behavior? Have you reviewed other protocols that
y potentially sensitive data logged by your protocol and/or for how long that ne solve similar problems, or make use of similar mechanisms, to see if
eds to be retained for technical reasons?</t> there are lessons that can be learnt from their use and misuse?
-->
<t>Explanation: <t>Explanation: Certain technical choices may have unintended consequenc
Privacy refers to the right of an entity (normally a person), acting on its own es. Have you described the central use case(s) for your protocol with a clear de
behalf, to determine the degree to which it will interact with its environment, scription of expected behavior and how it may, or may not, impact other protocol
including the degree to which the entity is willing to share its personal inform s, implementations, user expectations, or behavior? Have you reviewed other prot
ation with others. <xref target="RFC4949"/>. If a protocol provides insufficient ocols that solve similar problems, or make use of similar mechanisms, to see if
privacy protection it may have a negative impact on freedom of expression as us there are lessons that can be learned from their use and misuse?</t>
ers self-censor for fear of surveillance, or find themselves unable to express t <t>Example: Lack of authenticity may lead to lack of integrity and negat
hemselves freely.</t> ive externalities; of which, spam is an example. Lack of data that could be used
for billing and accounting can lead to so-called "free" arrangements that obscu
re the actual costs and distribution of the costs, for example, the barter arran
gements that are commonly used for Internet interconnection, and the commercial
exploitation of personal data for targeted advertising, which is the most common
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
, social, or economic. Therefore, it is of importance to document the intended o
utcomes and other possible outcomes that have been considered.</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to freedom of expression</li>
<li>Right to privacy</li>
<li>Right to freedom of assembly and association</li>
<li>Right to access to information</li>
</ul>
</section>
<section anchor="accessibility" numbered="true" toc="default">
<name>Accessibility</name>
<t>Example: <!-- [rfced] Section 4.18 - Should there be a citation for "W3C Web
See <xref target="RFC6973"/></t> Accessibility Initiative" in the following question?
<t>Impacts:</t> Current:
Question(s): Is your protocol designed to provide an enabling
environment for all? Have you looked at the W3C Web Accessibility
Initiative for examples and guidance?
-->
<t><list style="symbols"> <t>Question(s):
<t>Right to freedom of expression</t> Is your protocol designed to provide an enabling environment for all? Have you l
<t>Right to privacy</t> ooked at the W3C Web Accessibility Initiative for examples and guidance?</t>
<t>Right to non-discrimination</t> <t>Explanation:
</list></t> Sometimes in the design of protocols, websites, web technologies, or web tools,
barriers are created that exclude people from using the Web. The Internet should
be designed to work for all people, whatever their hardware, software, language
, culture, location, or physical or mental ability. When the Internet technologi
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="default"/>.</t>
<t>Example:
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)
to ensure images are accessible for people who cannot themselves decipher non-t
ext content in web pages.</t>
<t>Another example is the work done in the AVT and AVTCORE Working Group
s in the IETF that enables text conversation in multimedia, text telephony, wire
less multimedia, and video communications for sign language and lipreading (i.e.
, <xref target="RFC9071" format="default"/>).</t>
<t>Impacts:</t>
<ul spacing="normal">
<li>Right to non-discrimination</li>
<li>Right to freedom of assembly and association</li>
<li>Right to education</li>
<li>Right to political participation</li>
</ul>
</section>
<section anchor="decentralization" numbered="true" toc="default">
<name>Decentralization</name>
<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>
<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>
</section> <!--[rfced] Section 4.21 - May we update the following quoted text to better
<section anchor="anonymity-and-pseudonymity" title="Anonymity and Pseudonymity"> match the text in Section 4.2 of RFC 2026?
<t>Question(s): Does your protocol make use of identifiers? Are these Original:
identifiers persistent? Are they used across multiple contexts? Is it Similarly, publication of a specification an experimental document as
possible for the user to reset or rotate them without negatively part of the non-standards track would signal to the community that
impacting the operation fo the protocol? Are they visible to others the document "may be intended for eventual standardization but [may]
besides the protocol endpoints? Are they tied to real-world not yet [be] ready" for wide deployment.
identities? Have you considered the Privacy Considerations for
Internet Protocols <xref target="RFC6973"/>, especially section 6.1.2?</t>
<t>Explanation: Perhaps:
Most protocols depend on the use of some kind of identifier in order to correlat Similarly, publication of a specification as an experimental document not
e part of the Standards Track would signal to the community that
activity over time and space. For instance:</t> the document "may not be intended to be an Internet Standard, or it may
be intended for eventual standardization but not yet ready" for wide
deployment [RFC2026].
-->
<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 specif
ication as an experimental document not part of the Standards Track would signal
to the community that the document "may be intended for eventual standardizatio
n but [may] not yet [be] ready" for wide deployment. The extent of the deploymen
t, and consequently its overall impact on end users, may depend on the document
status presented in the RFC. See <xref target="RFC2026" format="default"/> and u
pdates 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><list style="symbols"> <section anchor="security-considerations" numbered="true" toc="default">
<t>IP addresses are used as an identity for the source and destination for <name>Security Considerations</name>
IP datagrams.</t> <t>Article three of the "Universal Declaration of Human Rights" reads: "Ev
<t>QUIC connection identifiers are used to correlate packets belonging to eryone has the right to life, liberty and security of person" <xref target="UDHR
the same connection.</t> " format="default"/>. This article underlines the importance of security and its
<t>HTTP uses cookies to correlate multiple HTTP requests from the same interrelation with human life and liberty; but since human rights are indivisib
client.</t> le, interrelated, and interdependent, security is also closely linked to other h
<t>Email uses email addresses of the form <eref target="mailto:example@example uman rights and freedoms. This document seeks to strengthen human rights, freedo
.com">example@example.com</eref> to identify ms, and security by relating and translating these concepts to concepts and prac
senders and receivers.</t> tices as they are used in Internet protocol and architecture development. The ai
</list></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
roviding guidelines as done in <xref target="conducting-human-rights-reviews" fo
rmat="default"/> of this document.</t>
</section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="research-group-information" numbered="true" toc="default">
<name>Research Group Information</name>
<t>The discussion list for the IRTF Human Rights Protocol Considerations
Research Group is located at the e-mail address: <eref
target="mailto:hrpc@ietf.org" brackets="angle"/>.</t>
<t>Information on the group and information on how to subscribe to the
list is at: <eref target="https://www.irtf.org/mailman/listinfo/hrpc"
brackets="angle"/>.</t>
<t>Archives of the list can be found at: <eref
target="https://mailarchive.ietf.org/arch/browse/hrpc/"
brackets="angle"/>.</t>
</section>
</middle>
<back>
<t>In general, these identifiers serve a necessary function for protocol operati <displayreference target="I-D.pouwelse-censorfree-scenarios" to="Pouwelse"/>
ons, <displayreference target="I-D.ietf-madinas-mac-address-randomization" to="MA
by allowing them to maintain continuity. However, they can also create privacy C-ADDRESS-RANDOMIZATION"/>
risks. There are two major ways in which those risks manifest:</t>
<t><list style="symbols"> <displayreference target="I-D.arkko-iab-internet-consolidation" to="Arkko"/>
<t>The identifier may itself reveal the user’s identity in some way or be <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
tied to an identifier which does, as is the case when E.164 (telephone)
numbers are used as identifiers for instant messaging systems.</t>
<t>While the identifier may not reveal the user’s identity, it may make
it possible to link enough of a user’s behavior to threaten their
privacy, as is the case with HTTP cookies.</t>
</list></t>
<t>Because identifiers are necessary for protocol operation, true anonymity <!-- [rfced] General Reference Queries
is very difficult to achieve, but there are practices which promote
user privacy even when identifiers are used.</t>
<t>Impacts:</t> a) The following references are not cited in the text. Please let us know
where they should be cited or if these references should be deleted from
the Informative References section.
<t><list style="symbols"> [geekfeminism]
<t>Right to non-discrimination</t> [RFC6235]
<t>Right to freedom of expression</t> [RFC9458]
<t>Right to political participation</t>
<t>Right to freedom of assembly and association</t>
</list></t>
<section anchor="pseudonymity" title="Pseudonymity"> b) [Orwat] (was [Bless]) We located an editorial note submitted to
Computer Communication Review by Orwat and Bless in April 2016
<https://www.sigcomm.org/sites/default/files/ccr/papers/2016/April/0000000-00000
03.pdf>
that contains the direct quote in Section 2 and was published in May
2016. We have updated the reference accordingly. Please let us know if
any updates are necessary.
<t>In general, user privacy is better preserved when identifiers are Original:
pseudonymous (not tied to a user’s real-world identity).</t> [Bless] Bless, R. and C. Orwat, "Values and Networks", 2015.
<t>Example: In the development of the IPv6 protocol, it was discussed to Current:
embed a Media Access Control (MAC) address into unique IP [Orwat] Orwat, C. and R. Bless, "Values and Networks - Steps
addresses. This would make it possible for eavesdroppers and other Toward Exploring their Relationships", ACM SIGCOMM
information collectors to identify when different addresses used in Computer Communication Review, vol. 46, no. 2, pp 25-31,
different transactions actually correspond to the same node. This is DOI 10.1145/2935634.2935640, May 2016,
why standardization efforts like Privacy Extensions for Stateless <https://doi.org/10.1145/2935634.2935640>.
Address Autoconfiguration in IPv6 <xref target="RFC4941"/> and MAC address
randomization <xref target="draft-zuniga-mac-address-randomization"/> have been
pursued.</t>
<t>Note that it is often attractive to try to create a pseudonym from c) [HTML5] FYI, the HTML specification is now under the management
a persistent identifier. This can be very difficult to do correctly of the Web Hypertext Application Technology Working Group
in a way that does not allow for recovering the persistent identifiers.</t> (WHATWG). Please see:
<t>Example: A common practice in Web tracking is to “encrypt” email <https://www.w3.org/news/2019/w3c-and-the-whatwg-have-just-signed-an-agreement-t
addresses by hashing them, thus allegedly making them o-collaborate-on-the-development-of-a-single-version-of-the-html-and-dom-specifi
“non-personally identifying”. However, because hash functions cations/>
are public operations, it is possible to dictionary search candidate
email addresses and recover the original address <xref target="email-hashing"/>.
</t>
</section> Therefore, we have updated the reference as follows.
<section anchor="unlinkability" title="Unlinkability">
<t>Even true pseudonymous identifiers can present a privacy risk if they Original:
are used across a wide enough scope. User privacy is better preserved [HTML5] W3C, "HTML5", 2014, <https://www.w3.org/TR/html5/>.
if identifiers have limited scope both in time and space.</t>
<t>Example: An example is Dynamic Host Configuration Protocol (DHCP) Current:
where sending a persistent identifier as the client name was not [HTML] WHATWG, "HTML Living Standard", April 2024,
mandatory but, in practice, done by many implementations, before <https://html.spec.whatwg.org/multipage/>.
<xref target="RFC7844"/>.</t>
<t>Example: Third party cookies in HTTP allow trackers to correlate d) [Hecate] We have found the following published as a USENIX
HTTP traffic across sites. This is the foundation of a whole Security paper. Would you like to update the reference as follows?
ecosystem of Web tracking. Increasingly, Web browsers are restricting
the use of third party cookies in order to protect user privacy.</t>
</section> Original:
</section> [hecate] Issa, R., Alhaddad, N., and M. Varia, "Hecate, Abuse
<section anchor="censorship-resistance" title="Censorship resistance"> Reporting in Secure Messengers with Sealed Sender", 2022,
<https://eprint.iacr.org/2021/1686>.
<t>Question(s): Perhaps:
Does your protocol architecture facilitate censorship? Does it include “choke po [Hecate] Issa, R., Alhaddad, N., and M. Varia, "Hecate, Abuse
ints” which are easy to use for censorship? Does it expose identifiers which can Reporting in Secure Messengers with Sealed Sender", 31st
be used to selectively block certain kinds of trafic? Could it be designed to b USENIX Security Symposium (USENIX Security 22),
e more censorship resistant? Does your protocol make it apparent or transparent pp 2335-2352, August 2022,
when access to a resource is restricted and the reasons why it is restricted?</t <https://www.usenix.org/conference/usenixsecurity22/
> presentation/issa>.
<t>Explanation: e) [FIArch] Since the site "www.future-internet.eu" is not reachable, may
Governments and service providers block or filter content or traffic, often with we update the reference as follows?
out the knowledge of end-users. <xref target="RFC7754"/> See <xref target="draft
-irtf-pearg-censorship"/> for a survey of censorship techniques employed across
the world, which lays out protocol properties that have been exploited to censor
access to information. Censorship resistance refers to the methods and measures
to prevent Internet censorship.</t>
<t>Example: Original:
The current design of the Web has a number of architectural choke points where i [FIArch] "Future Internet Design Principles", January 2012,
t is possible for censors to intervene. These include obtaining the control of t <http://www.future-internet.eu/uploads/media/
he domain name itself, DNS blocking at either the protocol layer or at the resol FIArch_Design_Principles_V1.0.pdf>.
ver, IP address blocking, and blocking at the Web server. There has been extensi
ve work on content distribution systems which are intended to be more censorship
resistant, and some, such as BitTorrent, are in wide use, but these systems may
have inferior reliability and performance compared to the Web (e.g., they do no
t support active content on the server).</t>
<t>Example: Perhaps:
Identifiers of content exposed within a protocol might be used to facilitate cen [FIArch] Papadimitriou, D., Zahariadis, T., Martinez-Julia, P.,
sorship by allowing the censor to determine which traffic to block. DNS queries, Papafili, I., Morreale, V., Torelli, F., Sales, B., and P.
the “host” request header in an HTTP request, the Server Name Indication (SNI) Demeester, "Design Principles for the Future Internet
in a Transport Layer Security (TLS) ClientHello are all examples of protocol ele Architecture", The Future Internet, pp. 55-67, DOI
ments that can travel in plaintext and be used by censors to identify what conte 10.1007/978-3-642-30241-1_6, January 2012,
nt a user is trying to access. <xref target="draft-irtf-pearg-censorship"/>. Pro <https://link.springer.com/chapter/10.1007/978-3-642-30241-1_6>.
tocol mechanisms such as Encrypted Client Hello <xref target="I-D.ietf-tls-esni" -->
/> or DNS over HTTPS <xref target="RFC8484"/> that encrypt metadata provide some
level of resistance to this type of protocol inspection. Full traffic encryptio
n systems such as Tor [https://torproject.org] can also be used by people access
otherwise censored resources.</t>
<t>Example: As noted above, one way to censor Web traffic is to require the serv er to block it or require internet service providers to block requests to the se rver. In HTTP, denial or restriction of access can be made apparent by the use o f status code 451, which allows server operators and intermediaries to operate w ith greater transparency in circumstances where issues of law or public policy a ffect their operation <xref target="RFC7725"/>. If a protocol potentially enable s censorship, protocol designers should strive towards creating error codes that capture different scenarios (blocked due to administrative policy, unavailable because of legal requirements, etc.) to minimize ambiguity for end-users.</t> <!-- [rfced] Obsoleted References
<t>Impacts:</t> a) RFC 0793 has been obsoleted by RFC 9293. We have replaced RFC
0793 with RFC 9293. Please let us know any objections.
<t><list style="symbols"> Original:
<t>Right to freedom of expression</t> Example: In the modern IP stack structure, a reliable transport layer
<t>Right to political participation</t> requires an indication that transport processing has successfully
<t>Right to participate in cultural life, arts, and science</t> completed, such as given by TCP's ACK message [RFC0793].
<t>Right to freedom of assembly and association</t>
</list></t>
</section> Current:
<section anchor="outcome-transparency" title="Outcome Transparency"> Example: In the modern IP stack structure, a reliable transport layer
requires an indication that transport processing has successfully
completed, such as given by TCP's ACK message [RFC9293].
<t>Question(s): Are the intended and forseen effects of your protocol documented b) RFC 4941 has been obsoleted by RFC 8981. We have replaced RFC
and easily comprehensible?</t> 4941 with RFC 8981. Please let us know any objections.
<t>Explanation: Certain technical choices may have unintended consequences. Have Original:
you described the central use case(s) for your protocol with a clear descriptio This is why
n of expected behavior and how it may, or may not, impact other protocols, imple standardization efforts like Privacy Extensions for Stateless Address
mentations, user expectations, or behavior? Have you reviewed other protocols th Autoconfiguration in IPv6 [RFC4941] and MAC address randomization
at solve similar problems, or make use of similar mechanisms, to see if there ar [draft-zuniga-mac-address-randomization] have been pursued.
e lessons that can be learnt from their use and misuse?</t>
<t>Example: Lack of authenticity may lead to lack of integrity and negative exte Current:
rnalities, of which spam is an example. Lack of data that could be used for bill This is why
ing and accounting can lead to so-called “free” arrangements which obscure the a standardization efforts like "Temporary Address Extensions for
ctual costs and distribution of the costs, for example the barter arrangements t Stateless Address Autoconfiguration in IPv6" [RFC8981] and MAC
hat are commonly used for Internet interconnection; and the commercial exploitat address randomization [MAC-ADDRESS-RANDOMIZATION] have been pursued.
ion of personal data for targeted advertising which is the most common funding m
odel for the so-called “free” services such as search engines and social network
s. Unexpected outcomes might not be technical, but rather architectural, social
or economic. Therefore it is of importance to document the intended outcomes and
other possible outcomes that have been considered.</t>
<t>Impacts:</t> c) [Patent-policy] This reference has been deprecated by a 2020 version.
Please let us know if you want to point to the current policy.
<t><list style="symbols"> Current:
<t>Right to freedom of expression</t> [Patent-policy]
<t>Right to privacy</t> Weitzner, D., "W3C Patent Policy", W3C Recommendation,
<t>Right to freedom of assembly and association</t> February 2004,
<t>Right to access to information</t> <https://www.w3.org/Consortium/Patent-Policy-20040205/>.
</list></t> Latest version available at
<https://www.w3.org/policies/patent-policy/>.
-->
</section> <!-- [rfced] BCP References
<section anchor="accessibility" title="Accessibility">
<t>Question(s): a) [BCP72] Please note that BCP 72 contains the following
Is your protocol designed to provide an enabling environment for all? Have you l RFCs. Would you like to update the reference to cite only RFC 3552
ooked at the W3C Web Accessibility Initiative for examples and guidance?</t> instead?
<t>Explanation: Original:
Sometimes in the design of protocols, websites, web technologies, or web tools, [BCP72] IETF, "Guidelines for Writing RFC Text on Security
barriers are created that exclude people from using the Web. The Internet should Considerations", 2003,
be designed to work for all people, whatever their hardware, software, language <https://datatracker.ietf.org/doc/bcp72/>.
, culture, location, or physical or mental ability. When the Internet technologi
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"/></t
>
<t>Example: Current:
The HTML protocol as defined in <xref target="HTML5"/> specifically requires tha [BCP72] Best Current Practice 72,
t every image must have an alt attribute (with a few exceptions) to ensure image <https://www.rfc-editor.org/info/bcp72>.
s are accessible for people that cannot themselves decipher non-text content in At the time of writing, this BCP comprises the following:
web pages.</t>
<t>Another example is the work done in the AVT and AVTCORE working groups in the Rescorla, E. and B. Korver, "Guidelines for Writing RFC
IETF that enables text conversation in multimedia, text telephony, wireless mul Text on Security Considerations", BCP 72, RFC 3552,
timedia and video communications for sign language and lip-reading (i.e., <xref DOI 10.17487/RFC3552, July 2003,
target="RFC9071"/>).</t> <https://www.rfc-editor.org/info/rfc3552>.
<t>Impacts:</t> Gont, F. and I. Arce, "Security Considerations for
Transient Numeric Identifiers Employed in Network
Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, July
2023, <https://www.rfc-editor.org/info/rfc9416>.
<t><list style="symbols"> Perhaps:
<t>Right to non-discrimination</t> [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
<t>Right to freedom of assembly and association</t> Text on Security Considerations", BCP 72, RFC 3552,
<t>Right to education</t> DOI 10.17487/RFC3552, July 2003,
<t>Right to political participation</t> <https://www.rfc-editor.org/info/rfc3552>.
</list></t>
</section> b) FYI, because RFC 2026 is a member of BCP 9, we have combined the
<section anchor="decentralization" title="Decentralization"> references [BCP9] and [RFC2026] into just RFC 2026. Note that this
updates one in-text reference from [BCP9] to [RFC2026]. Please let us
know any objections.
<t>Question(s): Original:
Can your protocol be implemented without a single point of control? If applicabl [BCP9] Bradner, S. and IETF, "The Internet Standards Process -
e, can your protocol be deployed in a federated manner? Does your protocol creat Revision 3", 1996,
e additional centralized points of control?</t> <https://datatracker.ietf.org/doc/rfc2026/>.
<t>Explanation: [RFC2026] Bradner, S., "The Internet Standards Process - Revision
Decentralization is one of the central technical concepts of the architecture of 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
the Internet, and is embraced as such by the IETF <xref target="RFC3935"/>. It <https://www.rfc-editor.org/info/rfc2026>.
refers to the absence or minimization of centralized points of control, a featur
e that is assumed to make it easy for new users to join and new uses to unfold <
xref target="Brown"/>. It also reduces issues surrounding single points of failu
re, and distributes the network such that it continues to function even if one o
r several nodes are disabled. With the commercialization of the Internet in the
early 1990s, there has been a slow move away from decentralization, to the detri
ment of the technical benefits of having a decentralized Internet. For a more de
tailed discussion of this topic, please see <xref target="arkkoetal"/>.</t>
<t>Example: Current:
The bits traveling the Internet are increasingly susceptible to monitoring and c [RFC2026] Bradner, S., "The Internet Standards Process - Revision
ensorship, from both governments and ISPs, as well as third (malicious) parties. 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
The ability to monitor and censor is further enabled by the increased centraliz <https://www.rfc-editor.org/info/rfc2026>.
ation of the network that creates central infrastructure points that can be tapp -->
ed into. The creation of peer-to-peer networks and the development of voice-over
-IP protocols using peer-to-peer technology in combination with distributed hash
table (DHT) for scalability are examples of how protocols can preserve decentra
lization <xref target="Pouwelse"/>.</t>
<t>Impacts:</t> <!-- [rfced] Updated Reference URLs - Please review each updated reference
and let us know of any objections or if any further updates are necessary.
<t><list style="symbols"> a) [ICCPR] FYI, the original URL redirects. We have updated the
<t>Right to freedom of expression</t> reference accordingly, including the date to match when the
<t>Right to freedom of assembly and association</t> covenant was adopted.
</list></t>
</section> Original:
<section anchor="remedy" title="Remedy"> [ICCPR] United Nations General Assembly, "International Covenant
on Civil and Political Rights", 1976,
<http://www.ohchr.org/EN/ProfessionalInterest/Pages/
CCPR.aspx>.
<t>Question(s): Can your protocol facilitate a negatively impacted party’s right Current:
to remedy without disproportionately impacting other parties’ human rights, esp [ICCPR] United Nations General Assembly, "International Covenant
ecially their right to privacy?</t> on Civil and Political Rights", 1966,
<https://www.ohchr.org/en/instruments-
mechanisms/instruments/international-covenant-civil-and-
political-rights>.
<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> b) [IRP] The original URL returned a 404 error. We updated it as follows.
<t>Example: Adding personally identifiable information to data streams as a mean Original:
s to enable the human right to remedy might help in identifying a violator of hu [IRP] Internet Rights and Principles Dynamic Coalition, "10
man rights and provide access to remedy, but this would disproportionally affect Internet Rights & Principles", 2014,
all users right to privacy, anonymous expression, and association. <http://internetrightsandprinciples.org/site/wp-
Furthermore, there are some recent advances in enabling abuse detection in end-t content/uploads/2014/06/
o-end encrypted messaging systems, which also carry some risk to users’ privacy IRPC_10RightsandPrinciples_28May2014-11.pdf>.
<xref target="messenger-franking"/><xref target="hecate"/>.</t>
<t>Impacts:</t> Current:
[IRP] Internet Rights and Principles Dynamic Coalition, "10
Internet Rights & Principles",
<https://internetrightsandprinciples.org/campaign/>.
<t><list style="symbols"> c) [ICESCR] FYI, the original URL redirects. We have updated the
<t>Right to remedy</t> reference accordingly.
<t>Right to security</t>
<t>Right to privacy</t>
</list></t>
</section> Original:
<section anchor="misc-considerations" title="Misc. considerations"> [ICESCR] United Nations General Assembly, "International Covenant
on Economic, Social and Cultural Rights", 1966,
<http://www.ohchr.org/EN/ProfessionalInterest/Pages/
CESCR.aspx>.
<t>Question(s): Have you considered potential negative consequences (individual Current:
or societal) that your protocol or document might have?</t> [ICESCR] United Nations General Assembly, "International Covenant
on Economic, Social and Cultural Rights", December 1966,
<https://www.ohchr.org/en/instruments-
mechanisms/instruments/international-covenant-economic-
social-and-cultural-rights>.
<t>Explanation: Publication of a particular RFC under a certain status has conse d) [UDHR] FYI, the original URL redirects. We have updated the
quences. Publication as an Internet Standard as part of the Standards Track may reference accordingly.
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> Original:
</section> [UDHR] United Nations General Assembly, "The Universal
<section anchor="document-status" title="Document Status"> Declaration of Human Rights", 1948,
<http://www.un.org/en/documents/udhr/>.
<t>This RG document lays out best practices and guidelines for human rights revi Current:
ews of network protocols, architectures and other Internet-Drafts and RFCs.</t> [UDHR] United Nations General Assembly, "Universal Declaration of
Human Rights", December 1948, <https://www.un.org/en/
about-us/universal-declaration-of-human-rights>.
</section> e) [UNGP] For ease of the reader, we have updated the URL for this
<section anchor="acknowledgements" title="Acknowledgements"> reference to point to the landing page of this document and have updated
<t>Thanks to:</t> the title accordingly.
<t><list style="symbols"> Original:
<t>Corinne Cath-Speth for work on <xref target="RFC8280"/>.</t> [UNGP] United Nations, "United Nations Guiding Principles on
<t>Reese Enghardt, Joe Hall, Avri Doria, Joey Salazar, Corinne Cath-Speth, Far Business and Human Rights", 2011,
zaneh Badii, Sandra Braman, Colin Perkins, John Curran, Eliot Lear, Mallory Knod <https://www.ohchr.org/documents/publications/
el, Brian Trammell, Jane Coffin, Eric Rescorla, Sofía Celi and the hrpc list for guidingprinciplesbusinesshr_en.pdf>.
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> Current:
<section anchor="security-considerations" title="Security Considerations"> [UNGP] United Nations, "Guiding Principles on Business and Human
Rights: Implementing the United Nations 'Protect, Respect
and Remedy' Framework", January 2012,
<https://www.ohchr.org/en/publications/reference-
publications/guiding-principles-business-and-human-
rights>.
<t>Article three of the Universal Declaration of Human Rights reads: “Everyone h f) [UNHR] FYI, the original URL redirects. We have updated the
as the right to life, liberty and security of person.”. This article underlines reference accordingly.
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> Original:
<section anchor="iana-considerations" title="IANA Considerations"> [UNHR] United Nations, "The Core International Human Rights
<t>This document has no actions for IANA.</t> Instruments and their monitoring bodies", 2011,
<https://www.ohchr.org/en/professionalinterest/pages/
coreinstruments.aspx>.
</section> Current:
<section anchor="research-group-information" title="Research Group Information"> [UNHR] United Nations, "The Core International Human Rights
<t>The discussion list for the IRTF Human Rights Protocol Considerations Researc Instruments and their monitoring bodies",
h Group is located at the e-mail address <eref target="mailto:hrpc@ietf.org">hrp <https://www.ohchr.org/en/core-international-human-rights-
c@ietf.org</eref>. Information on the group and information on how to subscribe instruments-and-their-monitoring-bodies>.
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: g) [UNHRC2016] The original URL returned an error. We have updated
<eref target="https://www.irtf.org/mail-archive/web/hrpc/current/index.html">htt the reference as follows.
ps://www.irtf.org/mail-archive/web/hrpc/current/index.html</eref></t>
</section> Original:
[UNHRC2016]
United Nations Human Rights Council, "UN Human Rights
Council Resolution "The promotion, protection and
enjoyment of human rights on the Internet" (A/HRC/32/
L.20)", 2016, <https://documents-dds-
ny.un.org/doc/UNDOC/LTD/G16/131/89/PDF/
G1613189.pdf?OpenElement>.
</middle> Current:
[UNHRC2016]
United Nations Human Rights Council, "The promotion,
protection and enjoyment of human rights on the Internet",
A/HRC/32/L.20, June 2016,
<https://digitallibrary.un.org/record/845728?ln=en>.
<back> h) [Zittrain] FYI, we have updated the URL for this reference to point to the
document's landing page.
<references title='Informative References'> Original:
[Zittrain] Zittrain, J., "The Future of the Internet - And How to
Stop It", Yale University Press , 2008,
<https://dash.harvard.edu/bitstream/handle/1/4455262/
Zittrain_Future%20of%20the%20Internet.pdf?sequence=1>.
<reference anchor='RFC0793' target='https://www.rfc-editor.org/info/rfc793'> Current:
<front> [Zittrain] Zittrain, J., "The Future of the Internet and How to Stop
<title>Transmission Control Protocol</title> It", Yale University Press, 2008,
<author fullname='J. Postel' initials='J.' surname='Postel'/> <https://dash.harvard.edu/handle/1/4455262>.
<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'> <references>
<front> <name>Informative References</name>
<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'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.929
<front> 3.xml"/>
<title>Architectural Principles of the Internet</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103
<author fullname='B. Carpenter' initials='B.' role='editor' surname='Carpent 5.xml"/>
er'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.195
<date month='June' year='1996'/> 8.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.198
<t>The Internet and its architecture have grown in evolutionary fashion fr 4.xml"/>
om modest beginnings, rather than from a Grand Plan. While this process of evolu <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.202
tion is one of the main reasons for the technology's success, it nevertheless se 6.xml"/>
ems useful to record a snapshot of the current principles of the Internet archit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.227
ecture. This is intended for general guidance and general interest, and is in no 7.xml"/>
way intended to be a formal or invariant reference model. This memo provides in <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.336
formation for the Internet community. This memo does not specify an Internet sta 5.xml"/>
ndard of any kind.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.372
</abstract> 4.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.393
<seriesInfo name='RFC' value='1958'/> 5.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC1958'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
</reference> 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.623
5.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='RFC1984' target='https://www.rfc-editor.org/info/rfc1984'> <reference anchor="UDHR" target="https://www.un.org/en/about-us/universal-
<front> declaration-of-human-rights">
<title>IAB and IESG Statement on Cryptographic Technology and the Internet</ <front>
title> <title>Universal Declaration of Human Rights</title>
<author> <author>
<organization abbrev='IAB'>Internet Architecture Board</organization> <organization>United Nations General Assembly</organization>
</author> </author>
<author> <date month="December" year="1948"/>
<organization abbrev='IESG'>Internet Engineering Steering Group</organizat </front>
ion> </reference>
</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'> <reference anchor="Orwat">
<front> <front>
<title>The Internet Standards Process -- Revision 3</title> <title>Values and Networks: Steps Toward Exploring their Relationships
<author fullname='S. Bradner' initials='S.' surname='Bradner'/> </title>
<date month='October' year='1996'/> <author initials="C." surname="Orwat">
<abstract> <organization/>
<t>This memo documents the process used by the Internet community for the </author>
standardization of protocols and procedures. It defines the stages in the standa <author initials="R." surname="Bless">
rdization process, the requirements for moving a document between stages and the <organization/>
types of documents used during this process. This document specifies an Interne </author>
t Best Current Practices for the Internet Community, and requests discussion and <date month="May" year="2016"/>
suggestions for improvements.</t> </front>
</abstract> <refcontent>ACM SIGCOMM Computer Communication Review, vol. 46, no. 2, p
</front> p 25-31</refcontent>
<seriesInfo name='BCP' value='9'/> <seriesInfo name="DOI" value="10.1145/2935634.2935640"/>
<seriesInfo name='RFC' value='2026'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC2026'/>
</reference>
<reference anchor='RFC2277' target='https://www.rfc-editor.org/info/rfc2277'> <reference anchor="Ziewitz">
<front> <front>
<title>IETF Policy on Character Sets and Languages</title> <title>A Prehistory of Internet Governance</title>
<author fullname='H. Alvestrand' initials='H.' surname='Alvestrand'/> <author initials="M." surname="Ziewitz">
<date month='January' year='1998'/> <organization/>
<abstract> </author>
<t>This document is the current policies being applied by the Internet Eng <author initials="I." surname="Brown">
ineering Steering Group (IESG) towards the standardization efforts in the Intern <organization/>
et Engineering Task Force (IETF) in order to help Internet protocols fulfill the </author>
se requirements. This document specifies an Internet Best Current Practices for <date month="April" year="2013"/>
the Internet Community, and requests discussion and suggestions for improvements </front>
.</t> <refcontent>Research Handbook on Governance of the Internet, edited by I
</abstract> an Brown. Cheltenham: Edward Elgar Publishing</refcontent>
</front> <seriesInfo name="DOI" value="10.4337/9781849805025.00008"/>
<seriesInfo name='BCP' value='18'/> </reference>
<seriesInfo name='RFC' value='2277'/>
<seriesInfo name='DOI' value='10.17487/RFC2277'/>
</reference>
<reference anchor='RFC3365' target='https://www.rfc-editor.org/info/rfc3365'> <reference anchor="Note-well" target="https://www.ietf.org/about/note-well
<front> /">
<title>Strong Security Requirements for Internet Engineering Task Force Stan <front>
dard Protocols</title> <title>Note Well</title>
<author fullname='J. Schiller' initials='J.' surname='Schiller'/> <author>
<date month='August' year='2002'/> <organization>IETF</organization>
</front> </author>
<seriesInfo name='BCP' value='61'/> </front>
<seriesInfo name='RFC' value='3365'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC3365'/>
</reference>
<reference anchor='RFC3724' target='https://www.rfc-editor.org/info/rfc3724'> <reference anchor="IRP" target="https://internetrightsandprinciples.org/campa
<front> ign/">
<title>The Rise of the Middle and the Future of End-to-End: Reflections on t <front>
he Evolution of the Internet Architecture</title> <title>10 Internet Rights &amp; Principles</title>
<author fullname='J. Kempf' initials='J.' role='editor' surname='Kempf'/> <author>
<author fullname='R. Austein' initials='R.' role='editor' surname='Austein'/ <organization>Internet Rights and Principles Dynamic Coalition</orga
> nization>
<author> </author>
<organization abbrev='IAB'>Internet Architecture Board</organization> </front>
</author> </reference>
<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'> <reference anchor="ICCPR" target="https://www.ohchr.org/en/instruments-mec
<front> hanisms/instruments/international-covenant-civil-and-political-rights">
<title>A Mission Statement for the IETF</title> <front>
<author fullname='H. Alvestrand' initials='H.' surname='Alvestrand'/> <title>International Covenant on Civil and Political Rights</title>
<date month='October' year='2004'/> <author>
<abstract> <organization>United Nations General Assembly</organization>
<t>This memo gives a mission statement for the IETF, tries to define the t </author>
erms used in the statement sufficiently to make the mission statement understand <date month="December" year="1966"/>
able and useful, argues why the IETF needs a mission statement, and tries to cap </front>
ture some of the debate that led to this point. This document specifies an Inter </reference>
net Best Current Practices for the Internet Community, and requests discussion a
nd suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='95'/>
<seriesInfo name='RFC' value='3935'/>
<seriesInfo name='DOI' value='10.17487/RFC3935'/>
</reference>
<reference anchor='RFC8179' target='https://www.rfc-editor.org/info/rfc8179'> <reference anchor="Saltzer">
<front> <front>
<title>Intellectual Property Rights in IETF Technology</title> <title>End-to-end arguments in system design</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'/> <author initials="J. H." surname="Saltzer">
<author fullname='J. Contreras' initials='J.' surname='Contreras'/> <organization/>
<date month='May' year='2017'/> </author>
<abstract> <author initials="D. P." surname="Reed">
<t>The IETF policies about Intellectual Property Rights (IPR), such as pat <organization/>
ent rights, relative to technologies developed in the IETF are designed to ensur </author>
e that IETF working groups and participants have as much information as possible <author initials="D. D." surname="Clark">
about any IPR constraints on a technical proposal as early as possible in the d <organization/>
evelopment process. The policies are intended to benefit the Internet community </author>
and the public at large, while respecting the legitimate rights of IPR holders. <date month="November" year="1984"/>
This document sets out the IETF policies concerning IPR related to technology wo </front>
rked on within the IETF. It also describes the objectives that the policies are <refcontent>ACM Transactions on Computer Systems, vol. 2, no. 4, pp 277-
designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Se 288</refcontent>
ction 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.</t> <seriesInfo name="DOI" value="10.1145/357401.357402"/>
</abstract> </reference>
</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="ICESCR" target="https://www.ohchr.org/en/instruments-me
<front> chanisms/instruments/international-covenant-economic-social-and-cultural-rights"
<title>DNS Security Introduction and Requirements</title> >
<author fullname='R. Arends' initials='R.' surname='Arends'/> <front>
<author fullname='R. Austein' initials='R.' surname='Austein'/> <title>International Covenant on Economic, Social and Cultural Rights<
<author fullname='M. Larson' initials='M.' surname='Larson'/> /title>
<author fullname='D. Massey' initials='D.' surname='Massey'/> <author>
<author fullname='S. Rose' initials='S.' surname='Rose'/> <organization>United Nations General Assembly</organization>
<date month='March' year='2005'/> </author>
<abstract> <date month="December" year="1966"/>
<t>The Domain Name System Security Extensions (DNSSEC) add data origin aut </front>
hentication and data integrity to the Domain Name System. This document introduc </reference>
es these extensions and describes their capabilities and limitations. This docum
ent also discusses the services that the DNS security extensions do and do not p
rovide. Last, this document describes the interrelationships between the documen
ts that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4033'/>
<seriesInfo name='DOI' value='10.17487/RFC4033'/>
</reference>
<reference anchor='RFC4101' target='https://www.rfc-editor.org/info/rfc4101'> <reference anchor="Penney" target="https://papers.ssrn.com/sol3/papers.cfm?abstr
<front> act_id=2769645">
<title>Writing Protocol Models</title> <front>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'/> <title>Chilling Effects: Online Surveillance and Wikipedia Use</title>
<author> <author initials="J." surname="Penney">
<organization abbrev='IAB'>Internet Architecture Board</organization> <organization/>
</author> </author>
<date month='June' year='2005'/> <date month="September" year="2016"/>
<abstract> </front>
<t>The IETF process depends on peer review. However, IETF documents are ge <refcontent>Berkeley Technology Law Journal, vol. 31, no. 1, pp 117-182</
nerally written to be useful for implementors, not reviewers. In particular, whi refcontent>
le great care is generally taken to provide a complete description of the state <seriesInfo name="DOI" value="10.15779/Z38SS13"/>
machines and bits on the wire, this level of detail tends to get in the way of i </reference>
nitial understanding. This document describes an approach for providing protocol
"models" that allow reviewers to quickly grasp the essence of a system. This me
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="UNHRC2016" target="https://digitallibrary.un.org/record
<front> /845728?ln=en">
<title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</t <front>
itle> <title>The promotion, protection and enjoyment of human rights on the
<author fullname='T. Narten' initials='T.' surname='Narten'/> Internet</title>
<author fullname='R. Draves' initials='R.' surname='Draves'/> <author>
<author fullname='S. Krishnan' initials='S.' surname='Krishnan'/> <organization>United Nations Human Rights Council</organization>
<date month='September' year='2007'/> </author>
<abstract> <date month="June" year="2016"/>
<t>Nodes use IPv6 stateless address autoconfiguration to generate addresse </front>
s using a combination of locally available information and information advertise <refcontent>A/HRC/32/L.20</refcontent>
d by routers. Addresses are formed by combining network prefixes with an interfa </reference>
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="geekfeminism" target="https://geekfeminism.fandom.com/w
<front> iki/Pseudonymity?oldid=30906">
<title>Internet Security Glossary, Version 2</title> <front>
<author fullname='R. Shirey' initials='R.' surname='Shirey'/> <title>Pseudonymity</title>
<date month='August' year='2007'/> <author>
<abstract> <organization>Geek Feminism Wiki</organization>
<t>This Glossary provides definitions, abbreviations, and explanations of </author>
terminology for information system security. The 334 pages of entries offer reco <date month="June" year="2015"/>
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="W3Ci18nDef" target="https://www.w3.org/International/qu
<front> estions/qa-i18n.en">
<title>Simple Mail Transfer Protocol</title> <front>
<author fullname='J. Klensin' initials='J.' surname='Klensin'/> <title>Localization vs. Internationalization</title>
<date month='October' year='2008'/> <author initials="R" surname="Ishida">
<abstract> <organization>W3C</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 <author initials="S" surname="Miller">
documents, making all or parts of most of them obsolete. It covers the SMTP ext <organization>Boeing</organization>
ension mechanisms and best practices for the contemporary Internet, but does not </author>
provide details about particular extensions. Although SMTP was designed as a ma <date month="December" year="2005"/>
il transport and delivery protocol, this specification also contains information </front>
that is important to its use as a "mail submission" protocol for "split-UA" (Us </reference>
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'> <referencegroup anchor="BCP72" target="https://www.rfc-editor.org/info/bcp7
<front> 2">
<title>Tags for Identifying Languages</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.35
<author fullname='A. Phillips' initials='A.' role='editor' surname='Phillips 52.xml"/>
'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
<author fullname='M. Davis' initials='M.' role='editor' surname='Davis'/> 16.xml"/>
<date month='September' year='2009'/> </referencegroup>
<abstract>
<t>This document describes the structure, content, construction, and seman
tics of language tags for use in cases where it is desirable to indicate the lan
guage used in an information object. It also describes how to register values fo
r use in language tags and the creation of user-defined extensions for private i
nterchange. This document specifies an Internet Best Current Practices for the I
nternet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='47'/>
<seriesInfo name='RFC' value='5646'/>
<seriesInfo name='DOI' value='10.17487/RFC5646'/>
</reference>
<reference anchor='RFC6108' target='https://www.rfc-editor.org/info/rfc6108'> <reference anchor="Patent-policy" target="https://www.w3.org/Consortium/Pa
<front> tent-Policy-20040205/">
<title>Comcast's Web Notification System Design</title> <front>
<author fullname='C. Chung' initials='C.' surname='Chung'/> <title>W3C Patent Policy</title>
<author fullname='A. Kasyanov' initials='A.' surname='Kasyanov'/> <author initials="D" surname="Weitzner">
<author fullname='J. Livingood' initials='J.' surname='Livingood'/> <organization>W3C</organization>
<author fullname='N. Mody' initials='N.' surname='Mody'/> </author>
<author fullname='B. Van Lieu' initials='B.' surname='Van Lieu'/> <date month="February" year="2004"/>
<date month='February' year='2011'/> </front>
<abstract> <refcontent>W3C Recommendation</refcontent>
<t>The objective of this document is to describe a method of providing cri <annotation>Latest version available at <eref target="https://www.w3.org/
tical end-user notifications to web browsers, which has been deployed by Comcast policies/patent-policy/" brackets="angle"/>.</annotation>
, an Internet Service Provider (ISP). Such a notification system is being used t </reference>
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'> <!-- [I-D.pouwelse-censorfree-scenarios] IESG state: Expired
<front> Long way used to include editor role for J. Pouwelse -->
<title>IP Flow Anonymization Support</title> <reference anchor="I-D.pouwelse-censorfree-scenarios" target="https://datatracke
<author fullname='E. Boschi' initials='E.' surname='Boschi'/> r.ietf.org/doc/html/draft-pouwelse-censorfree-scenarios-02">
<author fullname='B. Trammell' initials='B.' surname='Trammell'/> <front>
<date month='May' year='2011'/> <title>Media without censorship (CensorFree) scenarios</title>
<abstract> <author initials="J." surname="Pouwelse" fullname="Johan Pouwelse" role="editor"
<t>This document describes anonymization techniques for IP flow data and t >
he export of anonymized data using the IP Flow Information Export (IPFIX) protoc <organization>Delft University of Technology</organization>
ol. It categorizes common anonymization schemes and defines the parameters neede </author>
d to describe them. It provides guidelines for the implementation of anonymized <date month="October" day="22" year="2012"/>
data export and storage over IPFIX, and describes an information model and Optio </front>
ns- based method for anonymization metadata export within the IPFIX protocol or <seriesInfo name="Internet-Draft" value="draft-pouwelse-censorfree-scenarios-02"
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>
<reference anchor='RFC6365' target='https://www.rfc-editor.org/info/rfc6365'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9505.xml"
<front> />
<title>Terminology Used in Internationalization in the IETF</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.945
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/> 8.xml"/>
<author fullname='J. Klensin' initials='J.' surname='Klensin'/>
<date month='September' year='2011'/>
<abstract>
<t>This document provides a list of terms used in the IETF when discussing
internationalization. The purpose is to help frame discussions of international
ization in the various areas of the IETF and to help introduce the main concepts
to IETF participants. This memo documents an Internet Best Current Practice.</t
>
</abstract>
</front>
<seriesInfo name='BCP' value='166'/>
<seriesInfo name='RFC' value='6365'/>
<seriesInfo name='DOI' value='10.17487/RFC6365'/>
</reference>
<reference anchor='RFC6701' target='https://www.rfc-editor.org/info/rfc6701'> <!-- [I-D.ietf-madinas-mac-address-randomization] IESG state: RFC Ed Queue
<front> Long way used to include editor role for CJ. Bernardos-->
<title>Sanctions Available for Application to Violators of IETF IPR Policy</ <reference anchor="I-D.ietf-madinas-mac-address-randomization" target="https://d
title> atatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-15">
<author fullname='A. Farrel' initials='A.' surname='Farrel'/> <front>
<author fullname='P. Resnick' initials='P.' surname='Resnick'/> <title>
<date month='August' year='2012'/> Randomized and Changing MAC Address State of Affairs
<abstract> </title>
<t>The IETF has developed and documented policies that govern the behavior <author initials="J. C." surname="Zúñiga" fullname="Juan-Carlos Zúñiga">
of all IETF participants with respect to Intellectual Property Rights (IPR) abo <organization>CISCO</organization>
ut which they might reasonably be aware.</t> </author>
<t>The IETF takes conformance to these IPR policies very seriously. Howeve <author initials="C. J." surname="Bernardos" fullname="Carlos J. Bernardos" role
r, there has been some ambiguity as to what the appropriate sanctions are for th ="editor">
e violation of these policies, and how and by whom those sanctions are to be app <organization>Universidad Carlos III de Madrid</organization>
lied.</t> </author>
<t>This document discusses these issues and provides a suite of potential <author initials="A." surname="Andersdotter" fullname="Amelia Andersdotter">
actions that can be taken within the IETF community in cases related to patents. <organization>Safespring AB</organization>
This document is not an Internet Standards Track specification; it is published </author>
for informational purposes.</t> <date month="July" day="15" year="2024"/>
</abstract> </front>
</front> <seriesInfo name="Internet-Draft" value="draft-ietf-madinas-mac-address-randomiz
<seriesInfo name='RFC' value='6701'/> ation-15"/>
<seriesInfo name='DOI' value='10.17487/RFC6701'/>
</reference> </reference>
<reference anchor='RFC6973' target='https://www.rfc-editor.org/info/rfc6973'> <reference anchor="HTML" target="https://html.spec.whatwg.org/multipage/">
<front> <front>
<title>Privacy Considerations for Internet Protocols</title> <title>HTML Living Standard</title>
<author fullname='A. Cooper' initials='A.' surname='Cooper'/> <author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/> <organization>WHATWG</organization>
<author fullname='B. Aboba' initials='B.' surname='Aboba'/> </author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'/> <date month="August" year="2024"/>
<author fullname='J. Morris' initials='J.' surname='Morris'/> </front>
<author fullname='M. Hansen' initials='M.' surname='Hansen'/> </reference>
<author fullname='R. Smith' initials='R.' surname='Smith'/>
<date month='July' year='2013'/>
<abstract>
<t>This document offers guidance for developing privacy considerations for
inclusion in protocol specifications. It aims to make designers, implementers,
and users of Internet protocols aware of privacy-related design choices. It 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'> <reference anchor="Zittrain" target="https://dash.harvard.edu/handle/1/445
<front> 5262">
<title>Pervasive Monitoring Is an Attack</title> <front>
<author fullname='S. Farrell' initials='S.' surname='Farrell'/> <title>The Future of the Internet and How to Stop It</title>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/> <author initials="J." surname="Zittrain">
<date month='May' year='2014'/> <organization/>
<abstract> </author>
<t>Pervasive monitoring is a technical attack that should be mitigated in <date year="2008"/>
the design of IETF protocols, where possible.</t> </front>
</abstract> <refcontent>Yale University Press</refcontent>
</front> </reference>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>
<reference anchor='RFC7624' target='https://www.rfc-editor.org/info/rfc7624'> <reference anchor="FIArch" target="http://www.future-internet.eu/uploads/m
<front> edia/FIArch_Design_Principles_V1.0.pdf">
<title>Confidentiality in the Face of Pervasive Surveillance: A Threat Model <front>
and Problem Statement</title> <title>Future Internet Design Principles</title>
<author fullname='R. Barnes' initials='R.' surname='Barnes'/> <author>
<author fullname='B. Schneier' initials='B.' surname='Schneier'/> <organization/>
<author fullname='C. Jennings' initials='C.' surname='Jennings'/> </author>
<author fullname='T. Hardie' initials='T.' surname='Hardie'/> <date year="2012" month="January"/>
<author fullname='B. Trammell' initials='B.' surname='Trammell'/> </front>
<author fullname='C. Huitema' initials='C.' surname='Huitema'/> </reference>
<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'> <reference anchor="W3CAccessibility" target="https://www.w3.org/standards/
<front> webdesign/accessibility">
<title>An HTTP Status Code to Report Legal Obstacles</title> <front>
<author fullname='T. Bray' initials='T.' surname='Bray'/> <title>Accessibility</title>
<date month='February' year='2016'/> <author>
<abstract> <organization>W3C</organization>
<t>This document specifies a Hypertext Transfer Protocol (HTTP) status cod </author>
e for use when resource access is denied as a consequence of legal demands.</t> </front>
</abstract> </reference>
</front>
<seriesInfo name='RFC' value='7725'/>
<seriesInfo name='DOI' value='10.17487/RFC7725'/>
</reference>
<reference anchor='RFC7844' target='https://www.rfc-editor.org/info/rfc7844'> <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>Anonymity Profiles for DHCP Clients</title> <front>
<author fullname='C. Huitema' initials='C.' surname='Huitema'/> <title>Newegg on trial: Mystery company TQP rewrites the history of en
<author fullname='T. Mrugalski' initials='T.' surname='Mrugalski'/> cryption</title>
<author fullname='S. Krishnan' initials='S.' surname='Krishnan'/> <author initials="J." surname="Mullin">
<date month='May' year='2016'/> <organization/>
<abstract> </author>
<t>Some DHCP options carry unique identifiers. These identifiers can enabl <date month="November" year="2013"/>
e device tracking even if the device administrator takes care of randomizing oth </front>
er potential identifications like link-layer addresses or IPv6 addresses. The an <refcontent>Ars Technica</refcontent>
onymity profiles are designed for clients that wish to remain anonymous to the v </reference>
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="Hill" target="http://www.apig.ch/UNIGE%20Catalog.pdf">
<front> <front>
<title>Specification for DNS over Transport Layer Security (TLS)</title> <title>Partial Catalog of Human Rights Related to ICT Activities</titl
<author fullname='Z. Hu' initials='Z.' surname='Hu'/> e>
<author fullname='L. Zhu' initials='L.' surname='Zhu'/> <author initials="R." surname="Hill">
<author fullname='J. Heidemann' initials='J.' surname='Heidemann'/> <organization>Association for Proper Internet Governance (APIG)</org
<author fullname='A. Mankin' initials='A.' surname='Mankin'/> anization>
<author fullname='D. Wessels' initials='D.' surname='Wessels'/> </author>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/> <date month="May" year="2014"/>
<date month='May' year='2016'/> </front>
<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="Kaye" target="https://digitallibrary.un.org/record/7987
<front> 09?v=pdf">
<title>Research into Human Rights Protocol Considerations</title> <front>
<author fullname='N. ten Oever' initials='N.' surname='ten Oever'/> <title>Report of the Special Rapporteur on the Promotion and Protectio
<author fullname='C. Cath' initials='C.' surname='Cath'/> n of the Right to Freedom of Opinion and Expression, David Kaye</title>
<date month='October' year='2017'/> <author initials="D." surname="Kaye">
<abstract> <organization/>
<t>This document aims to propose guidelines for human rights consideration </author>
s, similar to the work done on the guidelines for privacy considerations (RFC 69 <date month="May" year="2015"/>
73). The other parts of this document explain the background of the guidelines a </front>
nd how they were developed.</t> <refcontent>A/HRC/29/32</refcontent>
<t>This document is the first milestone in a longer-term research effort. </reference>
It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research
Group and also by individuals from outside the research group.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='8280'/>
<seriesInfo name='DOI' value='10.17487/RFC8280'/>
</reference>
<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'> <reference anchor="UNGP" target="https://www.ohchr.org/en/publications/ref
<front> erence-publications/guiding-principles-business-and-human-rights">
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <front>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'/> <title>Guiding Principles on Business and Human Rights: Implementing t
<date month='August' year='2018'/> he United Nations 'Protect, Respect and Remedy' Framework</title>
<abstract> <author>
<t>This document specifies version 1.3 of the Transport Layer Security (TL <organization>United Nations</organization>
S) protocol. TLS allows client/server applications to communicate over the Inter </author>
net in a way that is designed to prevent eavesdropping, tampering, and message f <date year="2012" month="January"/>
orgery.</t> </front>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246 </reference>
, 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="UNHR" target="https://www.ohchr.org/en/core-internation
<front> al-human-rights-instruments-and-their-monitoring-bodies">
<title>DNS Queries over HTTPS (DoH)</title> <front>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/> <title>The Core International Human Rights Instruments and their monit
<author fullname='P. McManus' initials='P.' surname='McManus'/> oring bodies</title>
<date month='October' year='2018'/> <author>
<abstract> <organization>United Nations</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 </front>
ange.</t> </reference>
</abstract>
</front>
<seriesInfo name='RFC' value='8484'/>
<seriesInfo name='DOI' value='10.17487/RFC8484'/>
</reference>
<reference anchor='RFC8980' target='https://www.rfc-editor.org/info/rfc8980'> <reference anchor="HR-RT" target="https://github.com/IRTF-HRPC/reviews">
<front> <front>
<title>Report from the IAB Workshop on Design Expectations vs. Deployment Re <title>IRTF-HRPC / reviews</title>
ality in Protocol Development</title> <author>
<author fullname='J. Arkko' initials='J.' surname='Arkko'/> <organization/>
<author fullname='T. Hardie' initials='T.' surname='Hardie'/> </author>
<date month='February' year='2021'/> <date month="December" year="2020"/>
<abstract> </front>
<t>The Design Expectations vs. Deployment Reality in Protocol Development <refcontent>commit 3f5fbff</refcontent>
Workshop was convened by the Internet Architecture Board (IAB) in June 2019. Thi </reference>
s report summarizes the workshop's significant points of discussion and identifi
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'> <!-- [I-D.arkko-iab-internet-consolidation] IESG state: Expired -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-arkko-iab
<title>Technical Considerations for Internet Service Blocking and Filtering< -internet-consolidation.xml"/>
/title>
<author fullname='R. Barnes' initials='R.' surname='Barnes'/>
<author fullname='A. Cooper' initials='A.' surname='Cooper'/>
<author fullname='O. Kolkman' initials='O.' surname='Kolkman'/>
<author fullname='D. Thaler' initials='D.' surname='Thaler'/>
<author fullname='E. Nordmark' initials='E.' surname='Nordmark'/>
<date month='March' year='2016'/>
<abstract>
<t>The Internet is structured to be an open communications medium. This op
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="FREAK" target="https://web.archive.org/web/201503040020
<front> 21/https://freakattack.com/">
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <front>
<author fullname='J. Iyengar' initials='J.' role='editor' surname='Iyengar'/ <title>Tracking the FREAK Attack</title>
> <author>
<author fullname='M. Thomson' initials='M.' role='editor' surname='Thomson'/ <organization>University of Michigan</organization>
> </author>
<date month='May' year='2021'/> <date month="March" year="2015"/>
<abstract> </front>
<t>This document defines the core of the QUIC transport protocol. QUIC pro <refcontent>Wayback Machine archive</refcontent>
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="Logjam">
<front> <front>
<title>RTP-Mixer Formatting of Multiparty Real-Time Text</title> <title>Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
<author fullname='G. Hellström' initials='G.' surname='Hellström'/> </title>
<date month='July' year='2021'/> <author initials="D." surname="Adrian">
<abstract> <organization/>
<t>This document provides enhancements of real-time text (as specified in </author>
RFC 4103) suitable for mixing in a centralized conference model, enabling source <author initials="K." surname="Bhargavan">
identification and rapidly interleaved transmission of text from different sour <organization/>
ces. The intended use is for real-time text mixers and participant endpoints cap </author>
able of providing an efficient presentation or other treatment of a multiparty r <author initials="Z." surname="Durumeric">
eal-time text session. The specified mechanism builds on the standard use of the <organization/>
Contributing Source (CSRC) list in the Real-time Transport Protocol (RTP) packe </author>
t for source identification. The method makes use of the same "text/t140" and "t <author initials="P." surname="Gaudry">
ext/red" formats as for two-party sessions.</t> <organization/>
<t>Solutions using multiple RTP streams in the same RTP session are briefl </author>
y mentioned, as they could have some benefits over the RTP-mixer model. The RTP- <author initials="M." surname="Green">
mixer model was selected to be used for the fully specified solution in this doc <organization/>
ument because it can be applied to a wide range of existing RTP implementations. </author>
</t> <author initials="J." surname="Halderman">
<t>A capability exchange is specified so that it can be verified that a mi <organization/>
xer and a participant can handle the multiparty-coded real-time text stream usin </author>
g the RTP-mixer method. The capability is indicated by the use of a Session Desc <author initials="N." surname="Heninger">
ription Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".</t> <organization/>
<t>This document updates RFC 4103 ("RTP Payload for Text Conversation").</ </author>
t> <author initials="D." surname="Springall">
<t>A specification for how a mixer can format text for the case when the e <organization/>
ndpoint is not multiparty aware is also provided.</t> </author>
</abstract> <author initials="E." surname="Thomé">
</front> <organization/>
<seriesInfo name='RFC' value='9071'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC9071'/> <author initials="L." surname="Valenta">
</reference> <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="UDHR" target="http://www.un.org/en/documents/udhr/"> <reference anchor="Hecate" target="https://eprint.iacr.org/2021/1686">
<front> <front>
<title>The Universal Declaration of Human Rights</title> <title>Hecate: Abuse Reporting in Secure Messengers with Sealed Sender
<author > </title>
<organization>United Nations General Assembly</organization> <author initials="R." surname="Issa">
</author> <organization/>
<date year="1948"/> </author>
</front> <author initials="N." surname="Alhaddad">
</reference> <organization/>
<reference anchor="Bless" > </author>
<front> <author initials="M." surname="Varia">
<title>Values and Networks</title> <organization/>
<author initials="R." surname="Bless"> </author>
<organization></organization> <date year="2022" month="August"/>
</author> </front>
<author initials="C." surname="Orwat"> <refcontent>Cryptology ePrint Archive, Paper 2021/1686</refcontent>
<organization></organization> </reference>
</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'> <reference anchor="Messenger-franking" target="https://eprint.iacr.org/201
<front> 7/664">
<title>Transport Protocol Path Signals</title> <front>
<author fullname='T. Hardie' initials='T.' role='editor' surname='Hardie'/> <title>Message Franking via Committing Authenticated Encryption</title
<date month='April' year='2019'/> >
<abstract> <author initials="P." surname="Grubbs">
<t>This document discusses the nature of signals seen by on-path elements <organization/>
examining transport protocols, contrasting implicit and explicit signals. For ex </author>
ample, TCP's state machine uses a series of well-known messages that are exchang <author initials="J." surname="Lu">
ed in the clear. Because these are visible to network elements on the path betwe <organization/>
en the two nodes setting up the transport connection, they are often used as sig </author>
nals by those network elements. In transports that do not exchange these message <author initials="T." surname="Ristenpart">
s in the clear, on-path network elements lack those signals. Often, the removal <organization/>
of those signals is intended by those moving the messages to confidential channe </author>
ls. Where the endpoints desire that network elements along the path receive thes <date year="2017" month="July"/>
e signals, this document recommends explicit signals be used.</t> </front>
</abstract> <refcontent>Cryptology ePrint Archive, Paper 2017/664</refcontent>
</front> </reference>
<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="Email-hashing" target="https://freedom-to-tinker.com/20
<front> 18/04/09/four-cents-to-deanonymize-companies-reverse-hashed-email-addresses/">
<title>The Internet is for End Users</title> <front>
<author fullname='M. Nottingham' initials='M.' surname='Nottingham'/> <title>Four cents to deanonymize: Companies reverse hashed email addre
<date month='August' year='2020'/> sses</title>
<abstract> <author initials="G." surname="Acar">
<t>This document explains why the IAB believes that, when there is a confl <organization/>
ict between the interests of end users of the Internet and other parties, IETF d </author>
ecisions should favor end users. It also explores how the IETF can more effectiv <author initials="S." surname="Englehardt">
ely achieve this.</t> <organization/>
</abstract> </author>
</front> <author initials="A." surname="Narayanan">
<seriesInfo name='RFC' value='8890'/> <organization/>
<seriesInfo name='DOI' value='10.17487/RFC8890'/> </author>
</reference> <date month="April" year="2018"/>
</front>
</reference>
<reference anchor='RFC7301' target='https://www.rfc-editor.org/info/rfc7301'> <reference anchor="HTTPS-interception">
<front> <front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation <title>The Security Impact of HTTPS Interception</title>
Extension</title> <author initials="Z." surname="Durumeric">
<author fullname='S. Friedl' initials='S.' surname='Friedl'/> <organization/>
<author fullname='A. Popov' initials='A.' surname='Popov'/> </author>
<author fullname='A. Langley' initials='A.' surname='Langley'/> <author initials="Z." surname="Ma">
<author fullname='E. Stephan' initials='E.' surname='Stephan'/> <organization/>
<date month='July' year='2014'/> </author>
<abstract> <author initials="D." surname="Springall">
<t>This document describes a Transport Layer Security (TLS) extension for <organization/>
application-layer protocol negotiation within the TLS handshake. For instances i </author>
n which multiple application protocols are supported on the same TCP or UDP port <author initials="R." surname="Barnes">
, this extension allows the application layer to negotiate which protocol will b <organization/>
e used within the TLS connection.</t> </author>
</abstract> <author initials="N." surname="Sullivan">
</front> <organization/>
<seriesInfo name='RFC' value='7301'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC7301'/> <author initials="E." surname="Bursztein">
</reference> <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>
<reference anchor='I-D.ietf-tls-esni' target='https://datatracker.ietf.org/doc/h <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.942
tml/draft-ietf-tls-esni-17'> 0.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.855
<title>TLS Encrypted Client Hello</title> 8.xml"/>
<author fullname='Eric Rescorla' initials='E.' surname='Rescorla'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.889
<organization>RTFM, Inc.</organization> 0.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.730
<author fullname='Kazuho Oku' initials='K.' surname='Oku'> 1.xml"/>
<organization>Fastly</organization>
</author>
<author fullname='Nick Sullivan' initials='N.' surname='Sullivan'>
<organization>Cloudflare</organization>
</author>
<author fullname='Christopher A. Wood' initials='C. A.' surname='Wood'>
<organization>Cloudflare</organization>
</author>
<date day='9' month='October' year='2023'/>
<abstract>
<t> This document describes a mechanism in Transport Layer Security (T
LS)
for encrypting a ClientHello message under a server public key.
Discussion Venues <!-- [I-D.ietf-tls-esni] IESG state: I-D Exists -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-tls-
esni.xml"/>
This note is to be removed before publishing as an RFC. <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>
Source for this draft and an issue tracker can be found at <section anchor="acknowledgements" numbered="false" toc="default">
https://github.com/tlswg/draft-ietf-tls-esni <name>Acknowledgements</name>
(https://github.com/tlswg/draft-ietf-tls-esni). <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>
</t> <!-- [rfced] We see instances of "charset" and "character set" throughout the
</abstract> document. Would you like to update to "character set" upon first usage
</front> and then "charset" thereafter for consistently?
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-esni-17'/> -->
</reference> <!-- [rfced] FYI - We have expanded the following abbreviation per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion
in the document carefully to ensure correctness.
</references> Fiber Distributed Data Interface (FDDI)
-->
</back> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
<!-- ##markdown-source: For example, please consider whether "native" should be updated:
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==
An example of a standard
that has taken into account the view that individuals like to have
access to data in their native language can be found in [RFC5646].
--> -->
</rfc> </rfc>
 End of changes. 202 change blocks. 
2791 lines changed or deleted 2183 lines changed or added

This html diff was produced by rfcdiff 1.48.