Subject: Re: [hrpc] Comment on draft-guidelines for RG Last Call

From: Vittorio Bertola <[email-masked]>
Date: Mon, 1 Feb 2021 11:03:48 +0100 (CET)

>     Il 30/01/2021 23:00 farzaneh badii <[email-masked]> ha scritto:
> 
>     4. Nice to see that you mention DoH. It's a great privacy preserving protocol. 
> 
I was only skimming through this list but my skimmer parsed the sequence "DoH", so here I am.

Indeed, DoH is a great example of a protocol that can advance or stifle human rights depending on how it is used - even more, it can advance some people's rights while stifling other people's. I wouldn't go into DoH specifically in this draft (the current reference however is ok, no problem with it) but it led me to think that the section on "censorship resistance" seems to miss the nuances completely.

For example, Article 20 of the ICCPR mandates censorship of war propaganda and hate speech, so a protocol exhibiting "censorship resistance" may negatively impact human rights if used to bypass that censorship. This should at least be recognized in the document; protocol designers that work on features that bypass censorship should consider both the good and the bad things that can then happen. (Same for the middlebox discussion in the "connectivity" section.) Indeed, much of the ex-post heat in the DoH discussion derived from the fact that the designers had thought of the good things, but had not realized or acknowledged the bad ones.

Another rights-sensitive topic that the DoH discussions brought up is child protection. There have been concerns about the disruption both of child sexual abuse filters and of parental controls (Article 18.4 of the ICCPR recognizes the right of families to educate their children "in conformity with their own convictions"). Possibly a section on this topic would make sense.

There also are other rights that have been often mentioned in connection with architectural Internet issues but do not appear here. For example, the right to free elections, with all the discussions about decentralized electoral propaganda via social media; or the broad right to safety and life. Even in the U.S., the last few years (weeks?) seem to have turned the tide a little, with people realizing that a bit of caution in the design of Internet communication protocols and applications is necessary to preserve democracy and public order. I know it's a hard discussion to have, and also that this is possibly more about the use of the protocols than of protocol design itself (but this can be said of many things that are already in the document). But it will be the Internet policy discussion of the decade.

So I think that a document encouraging engineers to consider the societal impacts of their new technologies more deeply, from more viewpoints, and with more nuances would be quite more useful than a document just promoting the traditional view that everything on the Internet should be free, decentralized and uncontrolled to the maximum.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: farzaneh badii <[email-masked]>
Date: Mon, 1 Feb 2021 08:24:35 -0500

> I was only skimming through this list but my skimmer parsed the sequence
Of course.

>
> Indeed, DoH is a great example of a protocol that can advance or stifle
> human rights depending on how it is used - even more, it can advance some
> people's rights while stifling other people's. I wouldn't go into DoH
> specifically in this draft (the current reference however is ok, no problem
> with it) but it led me to think that the section on "censorship resistance"
> seems to miss the nuances completely.
>
> For example, Article 20 of the ICCPR mandates censorship of war propaganda
> and hate speech, so a protocol exhibiting "censorship resistance" may
> negatively impact human rights if used to bypass that censorship. This
> should at least be recognized in the document; protocol designers that work
> on features that bypass censorship should consider both the good and the
> bad things that can then happen. (Same for the middlebox discussion in the
> "connectivity" section.) Indeed, much of the ex-post heat in the DoH
> discussion derived from the fact that the designers had thought of the good
> things, but had not realized or acknowledged the bad ones.
>

There is nothing good about censorship.

>
> Another rights-sensitive topic that the DoH discussions brought up is
> child protection. There have been concerns about the disruption both of
> child sexual abuse filters and of parental controls (Article 18.4 of the
> ICCPR recognizes the right of families to educate their children "in
> conformity with their own convictions"). Possibly a section on this topic
> would make sense.
>

Sexual abuse filter and parental “surveillance” have the potential for
censorship and in my opinion raising kids that think surveillance is a
necessary part of life is a terrible for the future of the society.
We can have encryption and fight with child sexual abuse (both in our
society and online, and not just take sexual abuse pictures down and think
we and the kids are all ok!). Encryption and child online protection are
not mutually exclusive.

I hope for kids not to be indoctrinated by their parents.

>
> There also are other rights that have been often mentioned in connection
> with architectural Internet issues but do not appear here. For example, the
> right to free elections, with all the discussions about decentralized
> electoral propaganda via social media; or the broad right to safety and
> life. Even in the U.S., the last few years (weeks?) seem to have turned the
> tide a little, with people realizing that a bit of caution in the design of
> Internet communication protocols and applications is necessary to preserve
> democracy and public order. I know it's a hard discussion to have, and also
> that this is possibly more about the use of the protocols than of protocol
> design itself (but this can be said of many things that are already in the
> document). But it will be the Internet policy discussion of the decade.
>

This has been the Internet policy discussion for a decade already. Again,
elections is a matter of sovereignty and the States.

And I totally agree that this is a matter of the implementation of the
protocol and not its design, something we have brought up before.

Where is the evidence that “decentralized” electoral propaganda was
effective? Studies that I have seen discuss the fact that centralization
and “echo chambers” can be far more effective.

>
> So I think that a document encouraging engineers to consider the societal
> impacts of their new technologies more deeply, from more viewpoints, and
> with more nuances would be quite more useful than a document just promoting
> the traditional view that everything on the Internet should be free,
> decentralized and uncontrolled to the maximum.
>

Free and decentralized does not mean uncontrolled.

This back and forth arguments about rights is a good cautionary sign that
we need to refrain from putting engineers in charge of balancing rights and
deciding what is better for people. They are not elected officials, they
are not here to control speech, and it is not their fault that the protocol
can potentially get abused during the implementation for reasons they could
not predict or control for! What we need is to understand if, where, how
and in what context protocols have affected people and if it is the
protocol or other factors involved as well.

I think this document could have mentioned that more elaborately with
concrete examples. I think our research group should have done that. But I
guess it’s too late now.

> [email-masked]
> Office @ Via Treviso 12, 10144 Torino, Italy <https://www.google.com/maps/search/Via+Treviso+12,+10144+Torino,+Italy?entry=gmail&source=g>
>
>

-- 
Farzaneh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 1 Feb 2021 18:23:46 +0100

On Mon, Feb 01, 2021 at 11:03:48AM +0100,
 Vittorio Bertola <vittorio.bertola=[email-masked]> wrote 
 a message of 119 lines which said:

> protocol designers that work on features that bypass censorship
> should consider both the good and the bad things that can then
> happen.

> So I think that a document encouraging engineers to consider the
> societal impacts of their new technologies more deeply, from more
> viewpoints, and with more nuances would be quite more useful than a
> document just promoting the traditional view that everything on the
> Internet should be free, decentralized and uncontrolled to the
> maximum.

[I think I agree with Farzaneh Badii here but I would like to make
another point.]

The problem is that the protocols are not deployed in an ideal
world. We know that, out there, there are strong, very strong forces,
both political and economical, working to use the Internet as a
surveillance tool, and to censor free speech. Whatever the IETF (and
the developers of programs like Tor, which is not an IETF outcome)
produces, whatever the protocols are, these forces will try to use the
Internet to increase surveillance, censorship and other bad things. As
in the well-known XKCD picture <https://xkcd.com/538/>, using Tor,
Signal and other technologies will limit the surveillance but
certainly not stop it, as more than one human rights activist
discovered :-(

So, the issue is not really about the proper balance between, say,
freedom of speech and censorship of nazi/racist/sectarian speech. It
is that we are a small force, developing techniques that fight against
the interests of giants. We should not refrain ourselves to develop
anti-censorship techniques because we (and the ordinary users) are
already at a disadvantage.

> people realizing that a bit of caution in the design of Internet
> communication protocols and applications is necessary to preserve
> democracy and public order.

I don't think this is a consensual opinion. I don't know about the USA
but in many countries, the call "we must tame the Internet since it
allows ordinary people to communicate and this can be dangerous" is
often heard from governemnts and traditional medias but does not
represent the viewpoint of the majority of "people".

But it seems close from the traditional discussion about
encryption. How could you change Internet protocols to resist
censorship when speech is used for good and to yield to censorship
when speech is used for bad? (Spoiler: you cannot.)

> Indeed, much of the ex-post heat in the DoH discussion derived from
> the fact that the designers had thought of the good things, but had
> not realized or acknowledged the bad ones.

I strongly disagree with this assessment. The people who worked in the
doh working group were well aware of the (very ancient and
traditional) discussions about good and bad sides of censorship, about
conflicts between different human rights, about balance, etc.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 1 Feb 2021 18:50:27 +0100

On Sat, Jan 30, 2021 at 05:00:00PM -0500,
 farzaneh badii <[email-masked]> wrote 
 a message of 380 lines which said:

> 1. One major issue that I see here and you might be able to easily
> solve it is that there is no distinction between user facing
> protocols and other protocols. For example, you ask for
> accessibility and consideration of culture etc.

Unlike the old telephone network, the Internet does not have a
clear-cut distinction between users and operators. Many protocols are
deployed by people who are not professional network operators. I tend
to think that there are no pure "developpers-only protocols". Error
messages, for instance, tend to leak and therefore their
internationalization is an issue.

Two examples:

* the tussle about IDN was fueled by the fact that some people claimed
that domain names were "purely technical identifiers" (not needing
internationalization) while others regarded them as a communication
tool between humans ("side of the bus").

* RFC 8203 was replaced by RFC 9003 just because of
internationalization issues in the messages. And this is for BGP,
hardly a "end user" protocol.

> Are you asking all the protocols to be provided in multiple
> languages, even those that only developers and implementers use and
> not the actual users? You might want to clarify that.

I'm confused here. I don't think that draft-irtf-hrpc-guidelines-05
asks for internationalization of the specifications themselves (for
instance by translating the RFC). Clarification is needed (and Niels
ten Oever's reply about Ramsey Nasr and Qalb confuses me even more;
are we talking about internationalization of protocols or
internationalization of specifications?)

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 1 Feb 2021 20:38:08 +0100

Hi Farzaneh,

On 31-01-2021 19:16, farzaneh badii wrote:
> Hello Niels.
> 
> 
> I don't know how we measure consensus here. But I remember weighing in back then as well(When Mr. Curran weighed in back in 2019). Here is the thread: https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution <https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution>
> 
> I can see that unfortunately I missed the discussion on this topic during the past year, and that's my fault, but I can bring reasons not to add "attribution and legal remedy" to this document at all. 
> 
> 1. Access to legal remedy is something that the States are supposedly in charge of bringing to their citizens.Which should (in theory) ensure that human rights are enforced. I don't think there was an intention to  provide  mechanisms for "enforcement" of human rights in various legal systems through Internet protocols. As mentioned in the beginning of your document: 
> "Human rights threats on the Internet come in a myriad of forms.* **P**rotocols and standards can harm or enable* the right to freedom of expression, right to non-discrimination, right to equal protection, right to participate in cultural life, arts and science, right to freedom of assembly and association, and the right to security." 
> 
> So we are not in the business of enforcing but providing an enabling environment. Because if we want to help law enforcement and the judicial authorities enforce human rights through Internet protocols we should bear in mind that that they are not always staunch advocates of human rights. So what I assume we are trying to do here is to help Internet protocol not to facilitate harm and "enable" human rights. 
> 

The text in the draft seeks to address this risk. I have sought to address all points made in that discussion, and I would not like to re-open that debate. If you feel the text is unbalanced, could you perhaps provide text suggestions? 

> 2. Attribution, section 3.3.20  of the Guideline, the authors assert that: "However, attribution to corporate entities, associations, and/or countries may not directly negatively impact human rights." I think this is not a very well backed up claim. Because in some cases some associations might be political or they might be human rights associations dealing with a dictatorship. Attribution to those associations certainly can impact their human rights negatively. Even when it comes to corporations, some CEOs of digital companies are put in jail because of the materials posted on their websites. I don't think we can argue that attribution to corporate entities might not adversely impact human rights.
> 

Again, the keyword in that sentence is 'may', so there is no strong claim made. 

> All in all I think section 3.3.20 does not help Internet Protocols enable human rights and it can be misinterpreted. 

I think the text in there is not strong and shows different perspectives and potential consequences. But again, happy to receive text suggestions. 

> 
> And in my previous email I talked about the problems with threat intelligence agencies and some of their conducts and the use of WHOIS for attribution (which was actually not designed to "identify" actors but unfortunately was used for that) so I will not reiterate here. 

From exactly that discussion we got the idea to remove individuals, and leave non-natural persons in. 

Best,

Niels

> 
> 
> 
> 
> 
> 
> 
> On Sun, Jan 31, 2021 at 5:52 AM Niels ten Oever <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Farzaneh,
> 
>     Thanks a lot for the review!
> 
>     On 30-01-2021 23:00, farzaneh badii wrote:
>     > Hello
>     >
>     > Adding my comments on this document: https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05> <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>>
>     >
>     > 1. One major issue that I see here and you might be able to easily solve it is that there is no distinction between user facing protocols and other protocols. For example, you ask for accessibility and consideration of culture etc. Are you asking all the protocols to be provided in multiple languages, even those that only developers and implementers use and not the actual users? You might want to clarify that. 
>     >
> 
>     We had a quite extensive discussion about this in relation to the presentation by Ramsey Nasr who create Qalb, an Arabic programming language. Programmers are the most frequent 'users' of protocols - if we continue using only latin characters and English documentation in protocols we are likely to reproduce the existing lack of diversity in protocol developers communities. But we can make the text on this clearer as well!
> 
>     > 2.section 3.3.1 on connectivity, you mention that "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 ...". Then in your example you say: Middleboxes (including NAT).... can create potential for abuse. NAT is a Network Address Translation protocol. I don't think it has anything to do with bandwidth. In this example you also mention CDNs. Are you suggesting that the developer should not consider "Middleboxes" protocols? I think you need to work on the example of section 3.3.1 some more to make it clearer. 
>     >
> 
>     Excellent point - we'll address this in a future version.
> 
>     > 3. section 3.3.20 remedy and attribution 
>     > This section worries me. As a  scholar I have worked on cyber attribution to some extent and believe in general when we have the right processes in place, attribution is very important and can hold cyber-attackers accountable. I am aware of some of the attribution processes and unfortunately some threat intelligence firms and open source intelligence organizations can violate the privacy of individuals by profiling them. Also, uncontrolled attribution mechanisms can lead to frivolous intellectual property claims. Both some threat intelligence firms and IP firms have used WHOIS extensively in their favor to attribute cybersecurity attacks and bring forward IP claims. WHOIS protocol did not have the intention to actually identify organizations and individuals, but to make them "contactable".and it was still used and mined for so many years and those who have abused WHOIS have not been held accountable.When you suggest they consider "attribution" when developing protocols it
>     > concerns me because it is not enough that you limit attribution to organizations and states. These kinds of attributions can be used against individuals and until we do not have the right preserving processes to put in place for those who want to be in the attribution business, rights of the individual can be at risk. there are very privacy conscious cybersecurity researchers out there but unfortunately that does not ensure a systematic practice of attribution in a fair manner. And you mention attribution to associations is fine and may not directly negatively impact human rights. Associations can themselves be at risk of frivolous attacks and frivolous attribution. I am concerned about this paragraph. I think we should have a conversation about it.
>     >
> 
>     In the proposed text I tried to capture the consensus that emerged from the extensive discussion that was had on this list. Do you have concrete suggestions on how to better capture that conensensus? I am afraid we would go back and repeat the same discussion.
> 
>     Thanks!
>     Niels
>     > On Sat, Jan 30, 2021 at 10:35 AM Corinne Cath <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hi all,
>     >
>     >     I trust this email finds you well. I did a review of the draft, from my perspective as an academic. Take it as you please. My main concern is that some of the language reads a bit deterministic (as, I know so does RFC 8280). It means that a lot of onus is put on the impact of a protocol, as opposed the role of the individuals that write them. 
>     >
>     >     I think through out the document, it would be interesting (especially in section 1 through 3.2.5) to see if you can rewrite such that you speak more directly to the protocol developers. I think that section 3.3 does that well, in terms of the tone it takes. As it clearly connects the actions of protocol developers to their potential outcomes. 
>     >
>     >     Hope this is helpful! 
>     >
>     >     Kind regards, 
>     >
>     >     Corinne
>     >
>     >     ---------------------------------
>     >
>     >     *1. Introduction*
>     >
>     >     "It provides questions engineers should ask
>     >
>     >        themselves when developing or improving protocols if they want to
>     >        understand their potential human rights impact."
>     >
>     >
>     >     >> maybe if they want to understand potential human rights concerns? Impact seems a little deterministic, as you also mention in the next sentence, I wonder if you can prove such direct impact between protocol development in the IETF and impact on human rights.
>     >
>     >     "The research establishes
>     >
>     >        that human rights relate to standards and protocols, and offers a
>     >        common vocabulary of technical concepts that impact human rights and
>     >        how these technical concepts can be combined to ensure that the
>     >        Internet remains an enabling environment for human rights."
>     >
>     >
>     >     >> same comment for the word impact, perhaps shape? influence? etc.
>     >
>     >
>     >           3.1 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>>. Human rights threats
>     >
>     >
>     >
>     >      "Protocols and standards can harm or enable the right to freedom of
>     >        expression, right to non-discrimination, right to equal protection,
>     >        right to participate in cultural life, arts and science, right to
>     >
>     >     freedom of assembly and association, and the right to security. "
>     >
>     >
>     >     >> again, deterministic language. Perhaps soften or add more concrete examples for context, that draw from current IETF discussions/standards.
>     >
>     >
>     >
>     >           3.3 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>>. Guidelines for human rights considerations
>     >
>     >
>     >
>     >     again, use of the word impact in the introduction.
>     >
>     >
>     >
>     >
>     >     --
>     >     Corinne Cath - Speth
>     >     Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute
>     >
>     >     Web: www.oii.ox.ac.uk/people/corinne-cath <http://www.oii.ox.ac.uk/people/corinne-cath> <http://www.oii.ox.ac.uk/people/corinne-cath <http://www.oii.ox.ac.uk/people/corinne-cath>>
>     >     Email: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> & [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     Twitter: @C_CS
>     >     _______________________________________________
>     >     hrpc mailing list
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc> <https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>>
>     >
>     >
>     > _______________________________________________
>     > hrpc mailing list
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>
>     >
> 
>     -- 
>     Niels ten Oever, PhD
>     Postdoctoral Researcher - Media Studies Department - University of Amsterdam
>     Postdoctoral Research Fellow - Communications Department - Texas A&M University
>     Research Fellow - Centre for Internet and Human Rights - European University Viadrina
>     Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
> 
>     W: https://nielstenoever.net <https://nielstenoever.net>
>     E: [email-masked] <mailto:[email-masked]>
>     T: @nielstenoever
>     P/S/WA: +31629051853
>     PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
> 
>     Read my dissertation 'Wired Norms' here: https://pure.uva.nl/ws/files/50781961/Thesis.pdf <https://pure.uva.nl/ws/files/50781961/Thesis.pdf>
>     _______________________________________________
>     hrpc mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>
> 

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Postdoctoral Research Fellow - Communications Department - Texas A&M University
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my dissertation 'Wired Norms' here: https://pure.uva.nl/ws/files/50781961/Thesis.pdf

---

From: farzaneh badii <[email-masked]>
Date: Mon, 1 Feb 2021 16:22:17 -0500

Here we go:

Question(s): Can your protocol facilitate a negatively impacted

   party's right to the appropriate  legal remedy without
disproportionately impacting

   other parties' human rights, especially their right to privacy?

   Explanation: Access to legal remedy is a human right that ensures

   that individuals whose rights have been violated can seek remedies

   through a judicial authority.  Attribution (i.e. mechanisms in

   protocols or architectures that are designed to make communications

   or artifacts attributable might help with seeking the appropriate remedy
.) to a certain computer or individual) can be

   a part of this, since it may allow law enforcement agencies to

   identify a possible violator.  However, attribution mechanisms may

   impede the exercise of the right to privacy.  The Special Rapporteur

   for Freedom of Expression has also argued that anonymity is an

   inherent part of freedom of expression.  [Kaye] Considering the

   adverse impact of attribution on the right to privacy and freedom of

   expression, attribution on an individual level may is not be consistent

   with human rights.  However, attribution to corporate entities,

   associations, and/or countries may not directly negatively impact

   human rights.

   Impacts:

   -  Right to legal remedy

   -  Right to security
Farzaneh

On Mon, Feb 1, 2021 at 2:38 PM Niels ten Oever <[email-masked]>
wrote:

> > I don't know how we measure consensus here. But I remember weighing in
> back then as well(When Mr. Curran weighed in back in 2019). Here is the
> thread: https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution <
> https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution>
> >
> > I can see that unfortunately I missed the discussion on this topic
> during the past year, and that's my fault, but I can bring reasons not to
> add "attribution and legal remedy" to this document at all.
> >
> > 1. Access to legal remedy is something that the States are supposedly in
> charge of bringing to their citizens.Which should (in theory) ensure that
> human rights are enforced. I don't think there was an intention to
> provide  mechanisms for "enforcement" of human rights in various legal
> systems through Internet protocols. As mentioned in the beginning of your
> document:
> > "Human rights threats on the Internet come in a myriad of
> forms.* **P**rotocols and standards can harm or enable* the right to
> freedom of expression, right to non-discrimination, right to equal
> protection, right to participate in cultural life, arts and science, right
> to freedom of assembly and association, and the right to security."
> >
> > So we are not in the business of enforcing but providing an enabling
> environment. Because if we want to help law enforcement and the judicial
> authorities enforce human rights through Internet protocols we should bear
> in mind that that they are not always staunch advocates of human rights. So
> what I assume we are trying to do here is to help Internet protocol not to
> facilitate harm and "enable" human rights.
> >
>
> The text in the draft seeks to address this risk. I have sought to address
> all points made in that discussion, and I would not like to re-open that
> debate. If you feel the text is unbalanced, could you perhaps provide text
> suggestions?
>
> > 2. Attribution, section 3.3.20  of the Guideline, the authors assert
> that: "However, attribution to corporate entities, associations, and/or
> countries may not directly negatively impact human rights." I think this is
> not a very well backed up claim. Because in some cases some associations
> might be political or they might be human rights associations dealing with
> a dictatorship. Attribution to those associations certainly can impact
> their human rights negatively. Even when it comes to corporations, some
> CEOs of digital companies are put in jail because of the materials posted
> on their websites. I don't think we can argue that attribution to corporate
> entities might not adversely impact human rights.
> >
>
> > All in all I think section 3.3.20 does not help Internet Protocols
> enable human rights and it can be misinterpreted.
>
> I think the text in there is not strong and shows different perspectives
> and potential consequences. But again, happy to receive text suggestions.
>
> >
> > And in my previous email I talked about the problems with threat
> intelligence agencies and some of their conducts and the use of WHOIS for
> attribution (which was actually not designed to "identify" actors but
> unfortunately was used for that) so I will not reiterate here.
>
> >     > Adding my comments on this document:
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05> <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>>
> >     >
> solve it is that there is no distinction between user facing protocols and
> other protocols. For example, you ask for accessibility and consideration
> of culture etc. Are you asking all the protocols to be provided in multiple
> languages, even those that only developers and implementers use and not the
> actual users? You might want to clarify that.
> >     >
> >
> >     We had a quite extensive discussion about this in relation to the
> presentation by Ramsey Nasr who create Qalb, an Arabic programming
> language. Programmers are the most frequent 'users' of protocols - if we
> continue using only latin characters and English documentation in protocols
> we are likely to reproduce the existing lack of diversity in protocol
> developers communities. But we can make the text on this clearer as well!
> >
> >     > 2.section 3.3.1 on connectivity, you mention that "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 ...". Then in your example you say: Middleboxes (including
> NAT).... can create potential for abuse. NAT is a Network Address
> Translation protocol. I don't think it has anything to do with bandwidth.
> In this example you also mention CDNs. Are you suggesting that the
> developer should not consider "Middleboxes" protocols? I think you need to
> work on the example of section 3.3.1 some more to make it clearer.
> >     >
> >
> >     > This section worries me. As a  scholar I have worked on cyber
> attribution to some extent and believe in general when we have the right
> processes in place, attribution is very important and can hold
> cyber-attackers accountable. I am aware of some of the attribution
> processes and unfortunately some threat intelligence firms and open source
> intelligence organizations can violate the privacy of individuals by
> profiling them. Also, uncontrolled attribution mechanisms can lead to
> frivolous intellectual property claims. Both some threat intelligence firms
> and IP firms have used WHOIS extensively in their favor to attribute
> cybersecurity attacks and bring forward IP claims. WHOIS protocol did not
> have the intention to actually identify organizations and individuals, but
> to make them "contactable".and it was still used and mined for so many
> years and those who have abused WHOIS have not been held accountable.When
> you suggest they consider "attribution" when developing protocols it
> >     > concerns me because it is not enough that you limit attribution to
> organizations and states. These kinds of attributions can be used against
> individuals and until we do not have the right preserving processes to put
> in place for those who want to be in the attribution business, rights of
> the individual can be at risk. there are very privacy
> conscious cybersecurity researchers out there but unfortunately that does
> not ensure a systematic practice of attribution in a fair manner. And you
> mention attribution to associations is fine and may not directly negatively
> impact human rights. Associations can themselves be at risk of
> frivolous attacks and frivolous attribution. I am concerned about this
> paragraph. I think we should have a conversation about it.
> >     >
> >
> >     In the proposed text I tried to capture the consensus that emerged
> from the extensive discussion that was had on this list. Do you have
> concrete suggestions on how to better capture that conensensus? I am afraid
> we would go back and repeat the same discussion.
> >
> >     > On Sat, Jan 30, 2021 at 10:35 AM Corinne Cath <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> wrote:
> >     >
> >     >     Hi all,
> >     >
> >     >     I trust this email finds you well. I did a review of the
> draft, from my perspective as an academic. Take it as you please. My main
> concern is that some of the language reads a bit deterministic (as, I know
> so does RFC 8280). It means that a lot of onus is put on the impact of a
> protocol, as opposed the role of the individuals that write them.
> >     >
> >     >     I think through out the document, it would be interesting
> (especially in section 1 through 3.2.5) to see if you can rewrite such that
> you speak more directly to the protocol developers. I think that section
> 3.3 does that well, in terms of the tone it takes. As it clearly connects
> the actions of protocol developers to their potential outcomes.
> >     >
> >     >     Hope this is helpful!
> >     >
> >     >     Kind regards,
> >     >
> >     >     Corinne
> >     >
> >     >     >> maybe if they want to understand potential human rights
> concerns? Impact seems a little deterministic, as you also mention in the
> next sentence, I wonder if you can prove such direct impact between
> protocol development in the IETF and impact on human rights.
> >     >
> >     >     >> same comment for the word impact, perhaps shape? influence?
> etc.
> >     >
> >     >
> >     >           3.1 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>>.
> Human rights threats
> >     >
> >     >
> >     >
> >     >     >> again, deterministic language. Perhaps soften or add more
> concrete examples for context, that draw from current IETF
> discussions/standards.
> >     >
> >     >
> >     >
> >     >           3.3 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>>.
> Guidelines for human rights considerations
> >     >
> >     >
> >     >
> >     >     Web: www.oii.ox.ac.uk/people/corinne-cath <
> http://www.oii.ox.ac.uk/people/corinne-cath> <
> http://www.oii.ox.ac.uk/people/corinne-cath <
> http://www.oii.ox.ac.uk/people/corinne-cath>>
> >     >     Email: [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>> & [email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>
> >     >     Twitter: @C_CS
> >     >     https://www.irtf.org/mailman/listinfo/hrpc <
> https://www.irtf.org/mailman/listinfo/hrpc> <
> https://www.irtf.org/mailman/listinfo/hrpc <
> https://www.irtf.org/mailman/listinfo/hrpc>>
> >     >
> >     >
> >     > https://www.irtf.org/mailman/listinfo/hrpc <
> https://www.irtf.org/mailman/listinfo/hrpc>
> >     >
> >
> >     --
> >     Niels ten Oever, PhD
> >     Read my dissertation 'Wired Norms' here:
> https://pure.uva.nl/ws/files/50781961/Thesis.pdf <
> https://pure.uva.nl/ws/files/50781961/Thesis.pdf>
> >     https://www.irtf.org/mailman/listinfo/hrpc <
> https://www.irtf.org/mailman/listinfo/hrpc>
> >
>
> --
> Niels ten Oever, PhD
> Read my dissertation 'Wired Norms' here:
> https://pure.uva.nl/ws/files/50781961/Thesis.pdf
>

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 01 Feb 2021 23:19:30 +0100

Dear Farzaneh,

Do your alterations reflect the content of the discussion, or mere your opinion?

I hope we're seeking to reach a consensus during last call, not reopening the discussion.

Best,

Niels

On Feb 1, 2021, 22:22, at 22:22, farzaneh badii <[email-masked]> wrote:
>> Again, the keyword in that sentence is 'may', so there is no strong
>claim
>> made.
>>
>> From exactly that discussion we got the idea to remove individuals,
>and
>> leave non-natural persons in.
>>
>> Best,
>>
>> Niels
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Sun, Jan 31, 2021 at 5:52 AM Niels ten Oever
><[email-masked]
>> <mailto:[email-masked]>> wrote:
>> >
>> >     Hi Farzaneh,
>> >
>protocols and
>not the
>> >     >        themselves when developing or improving protocols if
>they
>> want to
>> >     >        that human rights relate to standards and protocols,
>and
>> offers a
>> >     >        common vocabulary of technical concepts that impact
>human
>> rights and
>> >     >        how these technical concepts can be combined to ensure
>that
>> the
>> >     >        expression, right to non-discrimination, right to
>equal
>> protection,
>> >     >        right to participate in cultural life, arts and
>science,
>> right to
>> >     >
><mailto:[email-masked]
>> <mailto:[email-masked]>>
>> >     Postdoctoral Researcher - Media Studies Department - University
>of
>> Amsterdam
>> >     Postdoctoral Research Fellow - Communications Department -
>Texas A&M
>> University
>> >     Research Fellow - Centre for Internet and Human Rights -
>European
>> University Viadrina
>> >     Associated Scholar - Centro de Tecnologia e Sociedade -
>Fundação
>> Getúlio Vargas
>> >
>> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação
>Getúlio
>> Vargas
>>

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 2 Feb 2021 00:42:50 +0100

> On Feb 1, 2021, at 6:50 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

I am likewise confused.

I strongly believe that all protocols should be agnostic as to the character-sets carried as payload.

I also strongly believe that protocols themselves should not feature embedded text strings, in any language.  Any flags in the protocol itself should be binary labels, with meanings which can be documented in any language spoken by people developing things that use the protocol.

Is someone suggesting something other than those two cases?

                                -Bill

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 1 Feb 2021 19:51:01 -0500

Dear colleagues,

(ObDisclaimer: I work for the Internet Society, but this is only my
personal opinion and is no statement of ISOC's views.)

>internationalization is an issue.

I think this is true, but the entire discussion that arose as a result
of Ramsey Nasr's presentation was, in my opinion, rather unsatisfying
because in my opinion it conflated four different issues:

1.  The specification of protocols.  The IETF works in English and
always has.  IETF standards-track RFCs (and indeed, the entire series
AFAIK) have very generous republication terms in part to encourage
translation, but the official version of any standard published in the
RFC series is in English.  It is not hard to understand the arguments
about what problems that causes, but the experience with SDOs that try
to publish simultaneously in (for example) all the UN languages
suggests that too can create problems.  Technical translation is not a
trivial matter.  It doesn't seem to me that this piece of the puzzle
is considered in the current draft-irtf-hrpc-guidelines, and given the
contents of the I-D it probably shouldn't be in there.  But it seems
to be emerging in this discussion so I mention it for completeness.

2.  The protocols themselves.  I think Farzaneh's point upthread was
that this issue is more or less severe depending on the purpose of the
protocol.  What are the chances that a protocol element makes it into
a user context?  As Stephane notes, too, the definition of "user" on
the Internet is a little slippery, though it still seems to me that
(for example) identifiers from protocols that are clearly exposed in
an ordinary user's context (such as room names in XMPP or domain names
in URIs and URLs or email addresses) have more wide-ranging effects if
they are not internationalized than (say) possibly opaque strings that
are used in error codes or whatever.  The latter are rather more
easily dealt with via lookups and so on.  The draft as it stands seems
to treat this distinction without too much care, because it seems
pretty hard to imagine (for instance) tagging every error message in
every protocol with an RFC 5646 language-tag (even if that always
worked reliably, which it does not.  Domain names, for instance, are
often not words in any language).  There was a lot of work done by
the PRECIS working group on some of these matters:
https://tools.ietf.org/wg/precis/.

3.  The implementation of the protocols.  Many of the issues hinted at
in section 3.3.11 of the draft have as much to do with implementation
as they have to do with the protocols themselves.  (This actually
seems to me to be an overarching issue with the draft, which was a
concern I recall raising some time ago but that didn't seem to get any
traction, so I gave up.)  This is clearest in the bit, "The Internet
is a global medium, but many of its protocols and products are
developed with a certain audience in mind …."  There is rather a gap
between the protocols that undergird communications on the Internet
and the products that implement those protocols, and it is hard for me
to see how it helps protocol designers make the right trade-offs if we
can't be clear about which problem we're talking about.

4.  The tools used to work on all of the above.  One of the things I
found most vexing about the presentation the WG received was its
emphasis on the tools used to develop things (like, for instance, the
programming languages).  It is true that many programming languages
depend on ASCII and it is also true that there is a large quantity of
code that uses those programming languages.  I think that issue is
completely irrelevant to the matters above (if there were a Turing-complete
programming language that used Linear B for its writing system, I
presume such a system would still be able to implement protocols that
were specified in English), but the above-mentioned conflation of
protocols and products suggests that the issue of tools remains
somehow implicated in this passage.

The section in the draft is in any case actually about both localization and
internationalization, so the text is confusing in light of its heading
and the seeming cross-reference to internationalization (which I think
is actually a pointer to text in the referred-to W3C document).

I don't know how to fix any of this because I don't really know what
the text is trying to say, in part due to the conflation that I think
is there.  As I said, the last time I really engaged with this I
didn't feel like I made any headway.  But this is my feedback on
section 3.3.11, for whatever it's worth.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: farzaneh badii <[email-masked]>
Date: Mon, 1 Feb 2021 20:06:51 -0500

Niels,

I don't know how you come to consensus. I thought you as one of the
drafters need to make changes that capture the consensus. Seems like you
have had “many discussions” and all the points I have raised been resolved
satisfactorily in this group in my absence. Then the only thing I can do is
to record my objection to paragraph 3.3.20: Attribution.

I don't think the paragraph as is in that document is human rights enabling
and frankly it has the potential to do the opposite. It is a mistake to
bring court and law enforcement to the discussion when the scope of this
group is "enabling human rights". It is a mistake to make a distinction
between natural and legal persons in this case and assume that natural
persons may not be harmed in the process because the distinction “may”
protect them.

I brought reasons and they don't seem to be convincing to you or something
you want to work with and it seems to me it is too late now. So I get out
of your way and just record my objection to the paragraph.

Just to disclose: I have worked on cyber attack attribution processes
academically, and believe that attribution is one way to hold cyber
attackers accountable. I just don’t think we need the protocol developer
think about ways of attribution to make it easier to attribute cyber
attacks in court for legal remedy and include this in the guidelines for
human rights protection document as a “access to legal remedy”. Anonymity
makes attribution harder but still not impossible. Many John Doe’s have had
cases against them which provided the plaintiffs with the appropriate
remedies.

On Mon, Feb 1, 2021 at 5:19 PM Niels ten Oever <[email-masked]>
wrote:

> On Feb 1, 2021, at 22:22, farzaneh badii <[email-masked]> wrote:
>>
>> Here we go:
>>
>>
>>    or artifacts attributable might help with seeking the appropriate
>> remedy.)  to a certain computer or individual) can be
>>
>>    identify a possible violator .  However, attribution mechanisms may
>>
>> On Mon, Feb 1, 2021 at 2:38 PM Niels ten Oever < [email-masked]>
>> wrote:
>>
>>> Hi Farzaneh,
>>>
>>> > 1. Access to legal remedy is something that the States are supposedly
>>> in charge of bringing to their citizens.Which should (in theory) ensure
>>> that human rights are enforced. I don't think there was an intention to
>>> The text in the draft seeks to address this risk. I have sought to
>>> address all points made in that discussion, and I would not like to re-open
>>> that debate. If you feel the text is unbalanced, could you perhaps provide
>>> text suggestions?
>>>
>>> claim made.
>>> > On Sun, Jan 31, 2021 at 5:52 AM Niels ten Oever <
>>> [email-masked] <mailto: [email-masked]>> wrote:
>>> >
>>> >     Hi Farzaneh,
>>> >
>>> >     > 1. One major issue that I see here and you might be able to
>>> easily solve it is that there is no distinction between user facing
>>> protocols and other protocols. For example, you ask for accessibility and
>>> consideration of culture etc. Are you asking all the protocols to be
>>> provided in multiple languages, even those that only developers and
>>> implementers use and not the actual users? You might want to clarify that.
>>> >     >
>>> >
>>> >     > 2.section 3.3.1 on connectivity, you mention that "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 ...". Then in your example you say: Middleboxes (including
>>> >     > concerns me because it is not enough that you limit attribution
>>> to organizations and states. These kinds of attributions can be used
>>> against individuals and until we do not have the right preserving processes
>>> to put in place for those who want to be in the attribution business,
>>> rights of the individual can be at risk. there are very privacy
>>> [email-masked] <mailto: [email-masked]> <mailto:
>>> [email-masked] <mailto: [email-masked]>>> wrote:
>>> >     >
>>> >     >     Hi all,
>>> >     >
>>> that the
>>> >     >     >> same comment for the word impact, perhaps shape?
>>> influence? etc.
>>> >     >
>>> >     >
>>> >     >           3.1 < https://tools.ietf.org/html/
>>> draft-irtf-hrpc-guidelines-05#section-3.1 < https://tools.ietf.org/html/
>>> draft-irtf-hrpc-guidelines-05#section-3.1>>. Human rights threats
>>> >     >
>>> >     >
>>> >     >
>>> >     >           3.3 < https://tools.ietf.org/html/
>>> draft-irtf-hrpc-guidelines-05#section-3.3 < https://tools.ietf.org/html/
>>> draft-irtf-hrpc-guidelines-05#section-3.3>>. Guidelines for human
>>> rights considerations
>>> >     >
>>> >     >
>>> >     >
>>> http://www.oii.ox.ac.uk/people/corinne-cath> < http://www.oii.ox.ac.uk/
>>> people/corinne-cath < http://www.oii.ox.ac.uk/people/corinne-cath>>
>>> >     >     Email: [email-masked] <mailto: [email-masked]>
>>> <mailto: [email-masked] <mailto: [email-masked]>> &
>>> [email-masked] <mailto: [email-masked]> <mailto:
>>> [email-masked] <mailto: [email-masked]>>
>>> >     >     Twitter: @C_CS
>>> >     >      [email-masked] <mailto: [email-masked]> <mailto:
>>> [email-masked] <mailto: [email-masked]>>
>>> >     > [email-masked] <mailto: [email-masked]>
>>> >     W: https://nielstenoever.net < https://nielstenoever.net>
>>> >     E: [email-masked] <mailto: [email-masked]>
>>> >     T: @nielstenoever
>>> >     P/S/WA: +31629051853
>>> >      [email-masked] <mailto: [email-masked]>

-- 
Farzaneh

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 02 Feb 2021 08:57:40 +0100

Dear Farzaneh,

In the extensive discussion between you, John, Amelia, Pranesh and others you were the only one who said attribution has no role in this document whatsoever. You reiterate this position.  But that might mean that you are in the rough. 

Best,

Niels

On Feb 2, 2021, 02:06, at 02:06, farzaneh badii <[email-masked]> wrote:
>> Do your alterations reflect the content of the discussion, or mere
>your
>> opinion?
>>
>> I hope we're seeking to reach a consensus during last call, not
>reopening
>> the discussion.
>>
>> Best,
>>
>> Niels
>>
>>>> thread: 
>https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution <
>accessibility and
>>>> >     >      "Protocols and standards can harm or enable the right
>to
>>>> freedom of
>>>> >     >     Ph.D. Candidate, Oxford Internet Institute & Alan
>Turing
>>>> Institute
>>>> >     >
>http://www.oii.ox.ac.uk/
>>>> >     Postdoctoral Researcher - Media Studies Department -
>University of
>>>> Amsterdam
>Texas
>>>> A&M University
>>>> Postdoctoral Research Fellow - Communications Department - Texas
>A&M
>>>> University

---

From: Mark Perkins <[email-masked]>
Date: Tue, 2 Feb 2021 21:06:27 +1100

Not sure that Farzaneh is in the rough, I came out clearly against 
attribution a while ago (start of the discussion?).  Not sure how many 
others are also opposed, as not many have spoken - perhaps a straw poll 
is needed? My impression is that there is no consensus on this issue, 
more like a clear division.

Mark P.

Le 02/02/2021 à 18:57, Niels ten Oever a écrit :
> Dear Farzaneh,
>
> In the extensive discussion between you, John, Amelia, Pranesh and 
> others you were the only one who said attribution has no role in this 
> document whatsoever. You reiterate this position.  But that might mean 
> that you are in the rough.
>
> Best,
>
> Niels
> On Feb 2, 2021, at 02:06, farzaneh badii <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Niels,
>
>     I don't know how you come to consensus. I thought you as one of
>     the drafters need to make changes that capture the consensus.
>     Seems like you have had “many discussions” and all the points I
>     have raised been resolved satisfactorily in this group in my
>     absence. Then the only thing I can do is to record my objection to
>     paragraph 3.3.20: Attribution.
>
>     I don't think the paragraph as is in that document is human rights
>     enabling and frankly it has the potential to do the opposite. It
>     is a mistake to bring court and law enforcement to the discussion
>     when the scope of this group is "enabling human rights". It is a
>     mistake to make a distinction between natural and legal persons in
>     this case and assume that natural persons may not be harmed in the
>     process because the distinction “may” protect them.
>
>     I brought reasons and they don't seem to be convincing to you or
>     something you want to work with and it seems to me it is too late
>     now. So I get out of your way and just record my objection to the
>     paragraph.
>
>     Just to disclose: I have worked on cyber attack attribution
>     processes academically, and believe that attribution is one way to
>     hold cyber attackers accountable. I just don’t think we need the
>     protocol developer think about ways of attribution to make it
>     easier to attribute cyber attacks in court for legal remedy and
>     include this in the guidelines for human rights protection
>     document as a “access to legal remedy”. Anonymity makes
>     attribution harder but still not impossible. Many John Doe’s have
>     had cases against them which provided the plaintiffs with the
>     appropriate remedies.
>
>
>
>
>
>     On Mon, Feb 1, 2021 at 5:19 PM Niels ten Oever <
>     [email-masked] <mailto:[email-masked]>> wrote:
>
>         Dear Farzaneh,
>
>         On Feb 1, 2021, at 22:22, farzaneh badii <
>         [email-masked] <mailto:[email-masked]>>
>         wrote:
>
>             Here we go:
>
>
>             or artifacts attributable might help with seeking the
>             appropriate remedy.) to a certain computer or individual)
>             can be
>
>             identify a possible violator .However, attribution
>             mechanisms may
>
>             impede the exercise of the right to privacy.The Special
>             Rapporteur
>
>             inherent part of freedom of expression.[Kaye] Considering the
>
>             with human rights.However, attribution to corporate entities,
>
>             -Right to security
>             On Mon, Feb 1, 2021 at 2:38 PM Niels ten Oever <
>             [email-masked] <mailto:[email-masked]>>
>             wrote:
>
>                 Hi Farzaneh,
>
>                 > I don't know how we measure consensus here. But I
>                 remember weighing in back then as well(When Mr. Curran
>                 weighed in back in 2019). Here is the thread:
>                 https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution
>                 <https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution>
>                 <
>                 https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution
>                 <https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution>>
>
>                 >
>                 > I can see that unfortunately I missed the discussion
>                 on this topic during the past year, and that's my
>                 fault, but I can bring reasons not to add "attribution
>                 and legal remedy" to this document at all.
>                 >
>                 > 1. Access to legal remedy is something that the
>                 States are supposedly in charge of bringing to their
>                 citizens.Which should (in theory) ensure that human
>                 rights are enforced. I don't think there was an
>                 intention to provide  mechanisms for "enforcement" of
>                 human rights in various legal systems through Internet
>                 protocols. As mentioned in the beginning of your
>                 document:
>                 > "Human rights threats on the Internet come in a
>                 myriad of forms.* **P**rotocols and standards can harm
>                 or enable* the right to freedom of expression, right
>                 to non-discrimination, right to equal
>                 protection, right to participate in cultural life,
>                 arts and science, right to freedom of assembly and
>                 association, and the right to security."
>                 >
>                 > So we are not in the business of enforcing but
>                 providing an enabling environment. Because if we want
>                 to help law enforcement and the judicial authorities
>                 enforce human rights through Internet protocols we
>                 should bear in mind that that they are not always
>                 staunch advocates of human rights. So what I assume we
>                 are trying to do here is to help Internet protocol not
>                 to facilitate harm and "enable" human rights.
>                 >
>
>                 The text in the draft seeks to address this risk. I
>                 have sought to address all points made in that
>                 discussion, and I would not like to re-open that
>                 debate. If you feel the text is unbalanced, could you
>                 perhaps provide text suggestions?
>
>                 > 2. Attribution, section 3.3.20  of the Guideline,
>                 the authors assert that: "However, attribution to
>                 corporate entities, associations, and/or countries may
>                 not directly negatively impact human rights." I think
>                 this is not a very well backed up claim. Because in
>                 some cases some associations might be political or
>                 they might be human rights associations dealing with a
>                 dictatorship. Attribution to those associations
>                 certainly can impact their human rights negatively.
>                 Even when it comes to corporations, some CEOs of
>                 digital companies are put in jail because of the
>                 materials posted on their websites. I don't think we
>                 can argue that attribution to corporate entities might
>                 not adversely impact human rights.
>                 >
>
>                 > All in all I think section 3.3.20 does not help
>                 Internet Protocols enable human rights and it can be
>                 misinterpreted.
>
>                 I think the text in there is not strong and shows
>                 different perspectives and potential consequences. But
>                 again, happy to receive text suggestions.
>
>                 >
>                 > And in my previous email I talked about the problems
>                 with threat intelligence agencies and some of their
>                 conducts and the use of WHOIS for attribution (which
>                 was actually not designed to "identify" actors but
>                 From exactly that discussion we got the idea to remove
>                 individuals, and leave non-natural persons in.
>
>                 Best,
>
>                 Niels
>
>                 >
>                 >
>                 >
>                 >
>                 >
>                 >
>                 >
>                 [email-masked] <mailto:[email-masked]>
>                 <mailto: [email-masked]
>                 <mailto:[email-masked]>>> wrote:
>                 >
>                 >     Hi Farzaneh,
>                 >
>                 >     > Hello
>                 >     >
>                 >     > Adding my comments on this document:
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>
>                 <
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>>
>                 <
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>
>                 <
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>>
>                 >
>                 >     >
>                 >     > 1. One major issue that I see here and you
>                 might be able to easily solve it is that there is no
>                 distinction between user facing protocols and other
>                 protocols. For example, you ask for accessibility and
>                 consideration of culture etc. Are you asking all the
>                 protocols to be provided in multiple languages, even
>                 those that only developers and implementers use and
>                 >     >
>                 >     We had a quite extensive discussion about this
>                 in relation to the presentation by Ramsey Nasr who
>                 create Qalb, an Arabic programming language.
>                 Programmers are the most frequent 'users' of protocols
>                 - if we continue using only latin characters and
>                 English documentation in protocols we are likely to
>                 reproduce the existing lack of diversity in protocol
>                 >     > 2.section 3.3.1 on connectivity, you mention
>                 that "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 ...". Then in your
>                 example you say: Middleboxes (including NAT).... can
>                 create potential for abuse. NAT is a Network Address
>                 Translation protocol. I don't think it has anything to
>                 do with bandwidth. In this example you also mention
>                 CDNs. Are you suggesting that the developer should not
>                 consider "Middleboxes" protocols? I think you need to
>                 >     >
>                 >     > 3. section 3.3.20 remedy and attribution
>                 >     > This section worries me. As a scholar I have
>                 worked on cyber attribution to some extent and
>                 believe in general when we have the right processes in
>                 place, attribution is very important and can hold
>                 cyber-attackers accountable. I am aware of some of the
>                 attribution processes and unfortunately some threat
>                 intelligence firms and open source intelligence
>                 organizations can violate the privacy of individuals
>                 by profiling them. Also, uncontrolled attribution
>                 mechanisms can lead to frivolous intellectual property
>                 claims. Both some threat intelligence firms and IP
>                 firms have used WHOIS extensively in their favor to
>                 attribute cybersecurity attacks and bring forward IP
>                 claims. WHOIS protocol did not have the intention to
>                 actually identify organizations and individuals, but
>                 to make them "contactable".and it was still used and
>                 mined for so many years and those who have abused
>                 WHOIS have not been held accountable.When you suggest
>                 they consider "attribution" when developing protocols it
>                 >     > concerns me because it is not enough that you
>                 limit attribution to organizations and states. These
>                 kinds of attributions can be used against individuals
>                 and until we do not have the right preserving
>                 processes to put in place for those who want to be in
>                 the attribution business, rights of the individual can
>                 be at risk. there are very privacy
>                 conscious cybersecurity researchers out there but
>                 unfortunately that does not ensure a
>                 systematic practice of attribution in a fair manner.
>                 And you mention attribution to associations is fine
>                 and may not directly negatively impact human rights.
>                 Associations can themselves be at risk of
>                 frivolous attacks and frivolous attribution. I am
>                 concerned about this paragraph. I think we should have
>                 a conversation about it.
>                 >     >
>                 >
>                 >     In the proposed text I tried to capture the
>                 consensus that emerged from the extensive discussion
>                 that was had on this list. Do you have concrete
>                 suggestions on how to better capture that conensensus?
>                 I am afraid we would go back and repeat the same
>                 discussion.
>                 >
>                 >     > 4. Nice to see that you mention DoH. It's a
>                 great privacy preserving protocol.
>                 >     >
>                 >     >
>                 >
>                 >     Thanks!
>                 >
>                 >     Niels
>                 >
>                 >     >
>                 >     >
>                 >     >
>                 >     >
>                 >     >
>                 >     >
>                 >     >
>                 >     >
>                 >     > Farzaneh
>                 >     >
>                 >     >
>                 >     > On Sat, Jan 30, 2021 at 10:35 AM Corinne Cath
>                 < [email-masked] <mailto:[email-masked]>
>                 <mailto: [email-masked]
>                 <mailto:[email-masked]>> <mailto:
>                 [email-masked] <mailto:[email-masked]>
>                 <mailto: [email-masked]
>                 <mailto:[email-masked]>>>> wrote:
>                 >     >
>                 >     >     Hi all,
>                 >     >
>                 >     >     I trust this email finds you well. I did a
>                 review of the draft, from my perspective as an
>                 academic. Take it as you please. My main concern is
>                 that some of the language reads a bit deterministic
>                 (as, I know so does RFC 8280). It means that a lot of
>                 onus is put on the impact of a protocol, as opposed
>                 the role of the individuals that write them.
>                 >     >
>                 >     >     I think through out the document, it would
>                 be interesting (especially in section 1 through 3.2.5)
>                 to see if you can rewrite such that you speak more
>                 directly to the protocol developers. I think that
>                 section 3.3 does that well, in terms of the tone it
>                 takes. As it clearly connects the actions of protocol
>                 developers to their potential outcomes.
>                 >     >
>                 >     >     Hope this is helpful!
>                 >     >
>                 >     >     Kind regards,
>                 >     >
>                 >     >     Corinne
>                 >     >
>                 >     >  ----------------------------- ----
>                 >     >
>                 >     >     *1. Introduction*
>                 >     >
>                 >     >     "It provides questions engineers should ask
>                 >     >
>                 >     >        themselves when developing or improving
>                 protocols if they want to
>                 >     >        understand their potential human rights
>                 impact."
>                 >     >
>                 >     >
>                 >     >     >> maybe if they want to understand
>                 potential human rights concerns? Impact seems a little
>                 deterministic, as you also mention in the next
>                 sentence, I wonder if you can prove such direct impact
>                 between protocol development in the IETF and impact on
>                 human rights.
>                 >     >
>                 >     >     "The research establishes
>                 >     >
>                 >     >        that human rights relate to standards
>                 and protocols, and offers a
>                 >     >        common vocabulary of technical concepts
>                 that impact human rights and
>                 >     >        how these technical concepts can be
>                 combined to ensure that the
>                 >     >        Internet remains an enabling
>                 environment for human rights."
>                 >     >
>                 >     >
>                 >     >     >> same comment for the word impact,
>                 perhaps shape? influence? etc.
>                 >     >
>                 >     >
>                 >     >           3.1 <
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>
>                 <
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>>>.
>                 Human rights threats
>                 >     >
>                 >     >
>                 >     >
>                 >     >      "Protocols and standards can harm or
>                 enable the right to freedom of
>                 >     >        expression, right to
>                 non-discrimination, right to equal protection,
>                 >     >        right to participate in cultural life,
>                 arts and science, right to
>                 >     >
>                 >     >     freedom of assembly and association, and
>                 the right to security. "
>                 >     >
>                 >     >
>                 >     >     >> again, deterministic language. Perhaps
>                 soften or add more concrete examples for context, that
>                 draw from current IETF discussions/standards.
>                 >     >
>                 >     >
>                 >     >
>                 >     >           3.3 <
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>
>                 <
>                 https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3
>                 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>>>.
>                 >     >
>                 >     >
>                 >     >
>                 >     >     again, use of the word impact in the
>                 introduction.
>                 >     >
>                 >     >
>                 >     >
>                 >     >
>                 >     >     --
>                 >     >     Corinne Cath - Speth
>                 >     >     Ph.D. Candidate, Oxford Internet Institute
>                 & Alan Turing Institute
>                 >     >
>                 >     >     Web: www.oii.ox.ac.uk/people/corinne-cath
>                 <http://www.oii.ox.ac.uk/people/corinne-cath> <
>                 http://www.oii.ox.ac.uk/people/corinne-cath
>                 <http://www.oii.ox.ac.uk/people/corinne-cath>> <
>                 http://www.oii.ox.ac.uk/people/corinne-cath
>                 <http://www.oii.ox.ac.uk/people/corinne-cath> <
>                 http://www.oii.ox.ac.uk/people/corinne-cath
>                 <http://www.oii.ox.ac.uk/people/corinne-cath>>>
>                 >     >     Email: [email-masked]
>                 <mailto:[email-masked]> <mailto:
>                 [email-masked] <mailto:[email-masked]>>
>                 <mailto: [email-masked]
>                 <mailto:[email-masked]> <mailto:
>                 [email-masked] <mailto:[email-masked]>>> &
>                 [email-masked] <mailto:[email-masked]>
>                 <mailto: [email-masked]
>                 <mailto:[email-masked]>> <mailto:
>                 [email-masked] <mailto:[email-masked]>
>                 <mailto: [email-masked]
>                 <mailto:[email-masked]>>>
>                 >     >     Twitter: @C_CS
>                 >     >  _____________________________ __________________
>                 >     >     hrpc mailing list
>                 >     > [email-masked] <mailto:[email-masked]> <mailto:
>                 [email-masked] <mailto:[email-masked]>> <mailto:
>                 [email-masked] <mailto:[email-masked]> <mailto:
>                 [email-masked] <mailto:[email-masked]>>>
>                 >     > https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc> <
>                 https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc>> <
>                 https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc> <
>                 https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc>>>
>                 >     >
>                 >     >
>                 >     > ______________________________ _________________
>                 >     > hrpc mailing list
>                 >     > [email-masked] <mailto:[email-masked]> <mailto:
>                 [email-masked] <mailto:[email-masked]>>
>                 >     > https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc> <
>                 https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc>>
>                 >     >
>                 >
>                 >     --
>                 >     Niels ten Oever, PhD
>                 <https://nielstenoever.net> <
>                 https://nielstenoever.net <https://nielstenoever.net>>
>                 <mailto:[email-masked]> <mailto:
>                 [email-masked] <mailto:[email-masked]>>
>                 >     T: @nielstenoever
>                 >     P/S/WA: +31629051853
>                 <https://pure.uva.nl/ws/files/50781961/Thesis.pdf> <
>                 <https://pure.uva.nl/ws/files/50781961/Thesis.pdf>>
>                 >     _____________________________ __________________
>                 >     hrpc mailing list
>                 > https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc> <
>                 https://www.irtf.org/mailman/listinfo/hrpc
>                 <https://www.irtf.org/mailman/listinfo/hrpc>>
>                 >
>
>                 -- 
>                 Niels ten Oever, PhD
>                 University of Amsterdam
>                 <https://pure.uva.nl/ws/files/50781961/Thesis.pdf>
>
>
>
>     -- 
>     Farzaneh
>
>
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc

-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 2 Feb 2021 14:53:33 +0100 (CET)

> Il 01/02/2021 18:23 Stephane Bortzmeyer <[email-masked]> ha scritto:
> 

I don't want to have the whole discussion again - I stated my concerns on the current draft and that's it - but I do want to say something on this narrative.

The above was perhaps true 30 years ago. Today, the IETF is the standardization arm of one of the biggest global industries, led by the five most valuable listed companies of the world, which is under antitrust investigation in almost every corner of the planet and which is strong enough to censor the sitting U.S. President if so decides. There is at least the same potential for human rights violations in what the Internet does than in what others do to the Internet.

Basically, the Internet used to be the new kid on the block - radical, innovative, brilliant, out of control and disruptive. But then, there is now an expectation that the Internet turns into a boring, well behaved adult.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Feb 2021 09:06:58 -0500

> The above was perhaps true 30 years ago. Today, the IETF is the standardization arm of one of the biggest global industries, led by the five most valuable listed companies of the world, which is un…

This is a nice little lark, Vittorio, but in fact we were never powerful enough to censor the U.S. president. There are people who are that powerful, perhaps. Perhaps some of us work for those people, at some deep remove. But we are not they.

Instead, what we have actually seen is that the powerful organization some of us might have wished would censor the U.S. president did not. The one organization that did finally censor him while he was still president only did so after he had done something so egregious that it seemed like a safe move.

What I’ve seen of this effort is that the intention seems more aimed at preventing people from being silenced than it is at giving people the tools they need to avoid hearing people whose speech toward them is unwelcome (online harassment, of which Trump is simply the most formerly powerful example). If there is anything missing from this effort, it is that: that I can’t just say “no, I won’t accept email from strangers,” for example.

This is a hard problem, and one that we at the IETF are ill-equipped to address, since most unwelcome speech happens above the protocol level.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Feb 2021 14:07:03 +0000

Hiya,

On 02/02/2021 13:53, Vittorio Bertola wrote:
> Today, the IETF is the standardization arm of one of the biggest
> global industries,

Stephane will correct me if needed, but I thought it was
pretty clear that the "we" to whom Stephane referred did
not really include those IT behemoth companies (though I
think it probably does include some but not all of their
employees). FWIW, I agree with him.

I'm also sad that you seem to think that the IETF is only
the plaything of large companies, and I think you're wrong
there. There's more to it than that.

Cheers,
S.

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 2 Feb 2021 12:03:46 -0500

My suggestion to resolve the text is simply to minimise and make it 
netral. Perhaps something on attribution needs to be there as a 
reference to what is already in RFC 8280 and, even better, to serve as a 
pointer to future work that might deepen our collective understanding of 
attribution and protocols, even if that more thorough research uncovers 
restraint as a best practice.

-Mallory

On 2/1/21 8:06 PM, farzaneh badii wrote:
> Niels,�
> drafters need to make changes that capture the consensus. Seems like 
> you have had “many discussions” and all the points I have raised 
> been resolved satisfactorily in this group in my absence. Then the 
> only thing I can do is to record my objection to paragraph 3.3.20: 
> Attribution.�
>
> enabling and frankly it has the potential to do the opposite. It is a 
> mistake to bring court and law enforcement to the discussion when the 
> scope of this group is "enabling human rights". It is a mistake to 
> make a distinction between natural and legal persons in this case and 
> assume that natural persons may not be harmed in the process because 
> the distinction “may” protect them.�
>
> something you want to work with and it seems to me it is too late now. 
> So I get out of your way and just record my objection to the paragraph.�
>
> attackers accountable. I just don’t think we need the protocol 
> developer think about ways of attribution to make it easier to 
> attribute cyber attacks in court for legal remedy and include this in 
> the guidelines for human rights protection document as a “access to 
> legal remedy”. Anonymity makes attribution harder but still not 
> impossible. Many John Doe’s have had cases against them which 
> provided the plaintiffs with the appropriate remedies.�
>
>
>
>
>
> On Mon, Feb 1, 2021 at 5:19 PM Niels ten Oever <[email-masked] 
>     your opinion?
>     reopening the discussion.
>
>     Best,
>
>     Niels
>
>     On Feb 1, 2021, at 22:22, farzaneh badii <[email-masked]
>          � party's right to the appropriate  legal remedy without
>          � other parties' human rights, especially their right to
>         privacy?
>
>
>          � Explanation: Access to legal remedy is a human right that
>         ensures
>
>          � that individuals whose rights have been violated can seek
>         remedies
>
>
>
>
>          � through a judicial authority. � Attribution (i.e.
>         mechanisms in
>
>          � protocols or architectures that are designed to make
>         communications
>
>          � or artifacts attributable might help with seeking the
>         appropriate remedy.)� to a certain computer or individual) can be
>
>          � a part of this, since it may allow law enforcement
>         agencies to
>
>          � identify a possible violator .� However, attribution
>         mechanisms may
>
>          � impede the exercise of the right to privacy.� The Special
>         Rapporteur
>
>          � for Freedom of Expression has also argued that anonymity is an
>
>          � inherent part of freedom of expression.� [Kaye]
>         Considering the
>
>          � adverse impact of attribution on the right to privacy and
>         freedom of
>
>          � expression, attribution on an individual level may � is�
>         not be consistent
>
>          � with human rights.� However, attribution to corporate
>         entities,
>
>          � associations, and/or countries may not directly negatively
>         impact
>
>          � human rights.
>
>
>          � Impacts:
>
>
>          � - � Right to legal remedy
>
>
>          � -� Right to security
>
>         Farzaneh
>
>
>             weighed in back in 2019). Here is the thread:�
>             > I can see that unfortunately I missed the discussion on
>             this topic during the past year, and that's my fault, but
>             I can bring reasons not to add "attribution and legal
>             remedy" to this document at all.�
>             >
>             > 1. Access to legal remedy is something that the States
>             are supposedly in charge of bringing to their
>             citizens.Which should (in theory) ensure that human rights
>             are enforced. I don't think there was an intention to 
>             provide  mechanisms for "enforcement" of human rights in
>             various legal systems through Internet protocols. As
>             mentioned in the beginning of your document:�
>             > "Human rights threats on the Internet come in a myriad
>             of forms.* **P**rotocols and standards can harm or
>             enable* the right to freedom of expression, right to
>             non-discrimination, right to equal protection, right to
>             participate in cultural life, arts and science, right
>             to freedom of assembly and association, and the right to
>             security."�
>             >
>             providing an enabling environment. Because if we want to
>             help law enforcement and the judicial authorities enforce
>             human rights through Internet protocols we should bear
>             in mind that that they are not always staunch advocates of
>             human rights. So what I assume we are trying to do here is
>             to help Internet protocol not to facilitate harm and
>             "enable" human rights.�
>             >
>
>             The text in the draft seeks to address this risk. I have
>             sought to address all points made in that discussion, and
>             I would not like to re-open that debate. If you feel the
>             text is unbalanced, could you perhaps provide text
>             suggestions?
>
>             > 2. Attribution, section 3.3.20  of the Guideline, the
>             authors assert that: "However, attribution to corporate
>             entities, associations, and/or countries may not directly
>             negatively impact human rights." I think this is not a
>             very well backed up claim. Because in some cases some
>             associations might be political or they might be human
>             rights associations dealing with a dictatorship.
>             Attribution to those associations certainly can impact
>             their human rights negatively. Even when it comes to
>             corporations, some CEOs of digital companies are put in
>             jail because of the materials posted on their websites. I
>             don't think we can argue that attribution to corporate
>             > All in all I think section 3.3.20 does not help Internet
>             Protocols enable human rights and it can be misinterpreted.
>
>             conducts and the use of WHOIS for attribution (which was
>             actually not designed to "identify" actors but
>             >     > Adding my comments on this document:�
>             <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>>>
>             >     >
>             protocols to be provided in multiple languages, even those
>             that only developers and implementers use and not the
>             actual users? You might want to clarify that.�
>             >     >
>             >
>             >     We had a quite extensive discussion about this in
>             relation to the presentation by Ramsey Nasr who create
>             Qalb, an Arabic programming language. Programmers are the
>             most frequent 'users' of protocols - if we continue using
>             only latin characters and English documentation in
>             protocols we are likely to reproduce the existing lack of
>             diversity in protocol developers communities. But we can
>             make the text on this clearer as well!
>             >
>             important to design protocols such that they are reliable
>             even on low bandwidth ...". Then in your example you say:
>             Middleboxes (including NAT).... can create potential for
>             abuse. NAT is a Network Address Translation protocol. I
>             don't think it has anything to do with bandwidth. In this
>             example you also mention CDNs. Are you suggesting that the
>             developer should not consider "Middleboxes" protocols? I
>             think you need to work on the example of section 3.3.1
>             some more to make it clearer.�
>             >     >
>             >
>             >     > 3. section 3.3.20 remedy and attribution�
>             >     > This section worries me. As a� scholar I have
>             worked on cyber attribution to some extent and believe in
>             general when we have the right processes in
>             organizations can violate the privacy of individuals by
>             profiling them. Also, uncontrolled attribution mechanisms
>             can lead to frivolous intellectual property claims. Both
>             some threat intelligence firms and IP firms have used
>             WHOIS extensively in their favor to attribute
>             cybersecurity attacks and bring forward IP claims. WHOIS
>             protocol did not have the intention to actually identify
>             organizations and individuals, but to make them
>             "contactable".and it was still used and mined for so many
>             years and those who have abused WHOIS have not been held
>             accountable.When you suggest they consider "attribution"
>             when developing protocols it
>             limit attribution to organizations and states. These kinds
>             of attributions can be used against individuals and until
>             we do not have the right preserving processes to put in
>             place for those who want to be in the attribution
>             business, rights of the individual can be at risk. there
>             are very privacy conscious cybersecurity researchers out
>             there but unfortunately that does not ensure a
>             systematic practice of attribution in a fair manner. And
>             you mention attribution to associations is fine and may
>             not directly negatively impact human rights. Associations
>             can themselves be at risk of frivolous attacks and
>             frivolous attribution. I am concerned about this
>             consensus that emerged from the extensive discussion that
>             was had on this list. Do you have concrete suggestions on
>             how to better capture that conensensus? I am afraid we
>             would go back and repeat the same discussion.
>             >
>             great privacy preserving protocol.�
>             >     >
>             >     >
>             >
>             >     Thanks!
>             >
>             >     Niels
>             >
>             >     >
>             >     >
>             >     >
>             >     >
>             >     >
>             >     >
>             >     >
>             >     >
>             >     > Farzaneh
>             >     >
>             >     >
>             >     > On Sat, Jan 30, 2021 at 10:35 AM Corinne Cath <
>             >     >     I trust this email finds you well. I did
>             a review of the draft, from my perspective as an academic.
>             Take it as you please. My main concern is that some of the
>             language reads a bit deterministic (as, I know so does RFC
>             8280). It means that a lot of onus is put on the impact of
>             a protocol, as opposed the role of the individuals that
>             write them.�
>             >     >
>             >     >     I think through out the document, it
>             would be interesting (especially in section 1 through
>             3.2.5) to see if you can rewrite such that you speak more
>             directly to the protocol developers. I think that section
>             3.3 does that well, in terms of the tone it takes. As it
>             clearly connects the actions of protocol developers to
>             their potential outcomes.�
>             >     >
>             >     >     Hope this is helpful!�
>             >     >
>             >     >     Kind regards,�
>             >     >
>             >     >     Corinne
>             >     >
>             >     >     ---------------------------------
>             >     >
>             >     >     *1. Introduction*
>             >     >
>             >     >        themselves when developing or
>             improving protocols if they want to
>             >     >        understand their potential human
>             rights impact."
>             >     >
>             >     >
>             deterministic, as you also mention in the next sentence, I
>             wonder if you can prove such direct impact between
>             >     >        that human rights relate to
>             standards and protocols, and offers a
>             >     >        common vocabulary of technical
>             concepts that impact human rights and
>             >     >        right to participate in cultural
>             life, arts and science, right to
>             >     >
>             >     >     >> again, deterministic language.
>             Perhaps soften or add more concrete examples for context,
>             that draw from current IETF discussions/standards.
>             >     >
>             >     >
>             >     >
>             >     >           3.3 <
>             >     >     Ph.D. Candidate, Oxford Internet
>             Institute & Alan Turing Institute
>             >     >
>             >     >     Web:
>             <mailto:[email-masked]> <mailto: [email-masked]
>             <mailto:[email-masked]>> <mailto: [email-masked]
>             <mailto:[email-masked]> <mailto: [email-masked]
>             <mailto:[email-masked]>>> & [email-masked]
>             <mailto:[email-masked]> <mailto:
>             [email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked]> <mailto:
>             [email-masked] <mailto:[email-masked]>>>
>             >     >     Twitter: @C_CS
>             >     >   
>             >     >    � [email-masked] <mailto:[email-masked]>
>             <mailto: [email-masked] <mailto:[email-masked]>> <mailto:
>             >     >    �
>             >     > _______________________________________________
>             >     > hrpc mailing list
>             <https://nielstenoever.net> < https://nielstenoever.net
>             <https://nielstenoever.net>>
>             >    � [email-masked] <mailto:[email-masked]> <mailto:
>             >    � https://www.irtf.org/mailman/listinfo/hrpc
>             Texas A&M University
>             European University Viadrina
>             Fundação Getúlio Vargas

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Gurshabad Grover <[email-masked]>
Date: Tue, 23 Feb 2021 00:04:56 +0530

Dear Corinne,

Thank you very much for your comments! Please see below to track the
specific changes that were made in response to your feedback.

On 1/30/21 9:04 PM, Corinne Cath wrote:
> 
> I think through out the document, it would be interesting (especially in
> section 1 through 3.2.5) to see if you can rewrite such that you speak
> more directly to the protocol developers. I think that section 3.3 does
> that well, in terms of the tone it takes. As it clearly connects the
> actions of protocol developers to their potential outcomes. 
>  

Marked a tone review as a to-do for the next update.

>>> maybe if they want to understand potential human rights concerns? Impact seems a little deterministic, as you also mention in the next sentence, I wonder if you can prove such direct impact between protocol development in the IETF and impact on human rights. 
> 

Changed to something which I hope is less deterministic: "It provides
questions engineers should ask themselves when developing or improving
protocols if they want to understand how their decisions can potentially
influence the exercise of human rights on the Internet."

>>> same comment for the word impact, perhaps shape? influence? etc. 
> 

Changed.

> 
>       3.1
>       <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>.
>       Human rights threats
> 
> 
> 
>>> again, deterministic language. Perhaps soften or add more concrete examples for context, that draw from current IETF discussions/standards. 
> 
> 

Softened the language a bit.

> 
>       3.3
>       <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>.

Done.

Thanks again!
-Gurshabad

---

From: Gurshabad Grover <[email-masked]>
Date: Tue, 23 Feb 2021 00:09:00 +0530

Thanks so much for your review, Farzaneh!

Just two thoughts in-line.

On 1/31/21 3:30 AM, farzaneh badii wrote:
> Hello
>  
> 2.section 3.3.1 on connectivity, you mention that "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
> Translation protocol. I don't think it has anything to do with
> bandwidth. In this example you also mention CDNs. Are you suggesting
> that the developer should not consider "Middleboxes" protocols? I think
> you need to work on the example of section 3.3.1 some more to make it
> clearer. 
> 

Thanks, added an example that relates to bandwidth and connectivity. And
have marked as to-do to remove the unnecessary text from this section.

> processes and unfortunately some threat intelligence firms and open
> source intelligence organizations can violate the privacy of individuals
> by profiling them. Also, uncontrolled attribution mechanisms can lead to
> frivolous intellectual property claims. Both some threat intelligence
> firms and IP firms have used WHOIS extensively in their favor to
> attribute cybersecurity attacks and bring forward IP claims. WHOIS
> protocol did not have the intention to actually identify organizations
> and individuals, but to make them "contactable".and it was still used
> and mined for so many years and those who have abused WHOIS have not
> been held accountable.When you suggest they consider "attribution" when
> developing protocols it concerns me because it is not enough that you
> limit attribution to organizations and states. These kinds of
> attributions can be used against individuals and until we do not have
> the right preserving processes to put in place for those who want to be
> in the attribution business, rights of the individual can be at risk.
> there are very privacy conscious cybersecurity researchers out there but
> unfortunately that does not ensure a systematic practice of attribution
> in a fair manner. And you mention attribution to associations is fine
> and may not directly negatively impact human rights. Associations can
> themselves be at risk of frivolous attacks and frivolous attribution. I
> am concerned about this paragraph. I think we should have a conversation
> about it.
> 

For now, I have changed the text to (very close to) what you suggested
subsequently in this thread. What you suggested reflects my views as
well. I did not sense a strong pushback on it in the thread. However,
given the comments about whether the text in the section has rg
consensus, I've kept this the discussion as a to-do.

Hope that's alright, and thanks again!

-Gurshabad