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 " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ]> | |||
<?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 & 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 & 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. |