Subject: [hrpc] Review of draft-irtf-hrpc-research-07

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 Jan 2017 12:45:04 -0500

Below is a review of draft-irtf-hrpc-research-07. I have not been involved in the RG so these comments are for what they're worth and I apologize if some of this ground has been trod before. This was an interesting read and most of my comments are provided with an eye towards making the document more useful/actionable in the IETF eventually, which I realize may not be a shared goal necessarily.

Substantive comments:

= Section 3.2.3 and 3.2.3.1 =

If the point of the IPv4 example is to demonstrate the human rights impacts -- both positive and negative -- of various protocol designs, I find the section to be narrow, slanted, and incomplete. It seems focused almost exclusively on the potential harms, which, for a protocol as fundamental to the operation of the Internet as IPv4, is not justified and renders this section somewhat useless IMO.

IPv4 is the basis for packet-switching on the Internet. What would the human rights impacts be if packet-switching was never invented? It seems to me that any evaluation of the human rights impacts of IPv4 needs to take this more wholistic view into account. IPv4 completely revolutionized networking and allowed for the amazing innovation that the purposes for which people were connecting could be disassociated from the providers of the physical circuits. Had that not happened, how would the capacity for human freedom of expression in the world be different from what it is today? I don't think an assessment of the human rights impacts of IPv4 can ignore this and still be credible.

The above is just one example of a fundamental aspect of the protocol that is overlooked in the existing analysis. Section 3.2.3.1.1 bemoans the visibility of source and destination addresses, while overlooking the fact that such addresses can actually provide a great deal of anonymity protection compared to other identifiers that could have been chosen to be made part of the protocol. Having decried address visibility, Section 3.2.3.1.2 then makes no mention of the fact that NAT can actually provide protection from such visibility.

For this section to add value, it either needs to provide a wholistic analysis of both the positive and negative impacts of the protocol that takes into consideration the space of alternative designs and outcomes, or it needs to state up front that it is cherry-picking a few harms identified as being linked to the protocol design just for demonstration purposes.

I think the same goes for the other examples in Section 3.2.3. The existing set of design and deployment decisions seem to be taken as givens rather than as a set of inflection points where things could have turned out much worse for human rights. What if the DNS hadn't been designed in a distributed fashion? What if we hadn't managed to make HTTP performant such that it could support rich media and applications as it does today? What if instead of the near-ubiquitous ability for stacks to deploy TLS we were all relying on IPSec as our underlying security protocol? All of those were real possibilities. Not acknowledging them makes the section read like a litany of criticisms rather than a balanced assessment of the positive and negative rights impacts of the protocols.

I was also surprised to see P2P, VPNs, a specific HTTP status code, and DDoS attacks in this section which is purportedly about protocols. This seems like a good bit of mixing apples and oranges; I think the section would be more effective if it focused on specific protocols since that is the unit of design most familiar to and most actionable for IETF engineers. Analyzing protocol-level design decisions is particularly important because what can be controlled within a protocol design space is different from what can be controlled within a particular implementation or deployment.

= Section 3.2.3.5.2 =

"Peer-to-Peer traffic (and BitTorrent in particular) represents a high
 percentage of global Internet traffic"

Is there a citation for this? My understanding is that by most measurements the share of p2p traffic is pretty low these days.

= Section 4.1.1.1 =

Two overall comments about this section: 

(1) The questionnaire seems like it took the kitchen sink approach. Many of the considerations covered here are already covered in other existing IETF documents. In a number of cases this document took specific items from those existing documents and broke them out into their own separate subsections with many detailed questions (e.g., privacy, anonymity, pseudonymity, confidentiality, integrity, reliability, authenticity). I think most protocol designers will find the sheer volume of questions here daunting and will find the redundancy both within the section and together with existing guidance documents reason enough to skip a human rights analysis altogether. I would recommend really trying to streamline this section down to the essence of the questions that protocol designers are not already asking themselves but should be. If you want to include a comprehensive mapping between the technical concepts and specific human rights, put that mapping in a different section and focus this section on the most important and actionable questions.

(2) I think it would be a lot clearer if the various subsections were explicit about where the recommendations here are different than recommendations in existing IETF documents and policies. For privacy, security, internationalization, and extensibility, the document mixes in references to existing guidance/policies with its own text and suggestions. If the suggestion is to just go read the other documents, a simple reference would do; otherwise, I think the document could be a lot clearer about where it is asking protocol designers to depart from or go beyond what the existing guidance requires. Other than drawing explicit links between the concepts and human rights affected, I think 4.1.1.1.2, .4, .9, .10, .14, .15, .16, and .17 could all be removed or replaced with simple pointers to existing documents (possibly also true for .5 and .12 but it’s not my area of expertise).

= Section 4.1.1.1.1 =

The example doesn't seem to be responsive to the question. The question is about requiring functionality at intermediaries whereas the example is about a design decision to prevent intermediaries from carrying out such functionality.

= Section 4.1.1.1.3 =

"Question(s): If your protocol impacts packet handling, does it look
 at the packet payload?  Is it making decisions based on the payload
 of the packet?  Does your protocol prioritize certain content or
 services over others in the routing process ? Is the protocol
 transparent about the priotization that is made (if any)?"

I think this set of questions could benefit from some refinement, in particular in terms of the actor(s) being targeted. I don't quite understand the notion of a protocol itself "looking" at a payload or making a decision. I'm guessing this one is actually targeted at network intermediaries, as in 4.1.1.1.1, since the whole point of many protocols is for endpoints to take some action based on packet payloads.

I also think the example in this section (and all the subsections of 4.1.1.1, actually) would be more useful if it cited a specific protocol that has the effect that the section raises concerns about, because it's hard to understand what is being implied here. That is, I'm not sure what the implications would be of the answers to these questions if applied to, say RFC 2474 and RFC 2475, because the implications all depend on the deployment context.

= Section 4.1.1.1.6 =

"Question(s): Does this protocol introduce new identifiers or reuse
 existing identifiers (e.g.  MAC addresses) that might be associated
 with persons or content?  ...

 Example: Identifiers of content exposed within a protocol might be
 used to facilitate censorship, as in the case of IP based censorship,
 which affects protocols like HTTP."

I'm not sure how much mileage there is to be had out of this question and example, because most protocols use identifiers. I don't think this is a bad thing, it's just really hard to design a way to communicate between two endpoints about something without using identifiers of some sort. The question is phrased broadly enough that I think the answer will almost always be "yes" but I'm not sure to what end.

= Section 4.1.1.1.7 =

This section is concerning because it seems to be trying to re-interpret or change existing IETF policies, which seems inappropriate even for an informational IRTF document. For example, this bit in particular caught my eye:

"All standards that need to be normatively implemented should be
 freely available and with reasonable protection for patent
 infringement claims, so it can also be implemented in open source or
 free software."

As nice as it would be if this were always true, it's not, and it's not likely going to be any time in the foreseeable future for the 8000+ specifications the IETF has produced. Many of the reasons for that are outside the control of IETF participants. So I find it unhelpful to suggest these as requirements. I also don't think BCP 78 and 79 and the note well should be further elaborated in a document such as this one; even as informational people can get confused.

I would suggest deleting this section as there is a high potential for confusion and I'm not sure that it provides much countervailing benefit.

Also, I don't understand how the example relates to the rest of the section or why the emphasis on DPI is there.

= Section 4.1.1.1.10 =

The example doesn't seem to relate to pseudonymity and I'm not sure what is meant by a "feature." Again here giving a specific protocol example would be more helpful I think.

= Section 4.1.1.1.11 =

I think combining access for those with disabilities and access for those with poor connectivity under a single heading is confusing. These imply some rather disparate design decisions, not all of which will apply to all protocols nor in the same ways. 

= Section 4.1.1.1.16 =

I think it would be better not to mix integrity with authentication (via the example reference) since you can have one without the other.

Nits:

= Section 1 =

"the privacy ... of the network" doesn't seem like the concept actually being described here. Usually we're focused on privacy of individuals, and confidentiality of corporations (e.g., network operators).

= Section 2 =

There are two different definitions offered for "Connectivity."

= Section 3.2.2 =

Accessibility is listed twice for "Right to political participation."

= Section 3.2.3 =

"For instance, relying on an external server can be bad for freedom of speech" -- without any further context provided, it's hard to understand what is meant by an "external" server.

= Section 4.1.1.1.2 =

"If a protocol provides insufficient privacy it may stifle speech" -- I don't think it's the protocol that would be doing the stifling.

= Section 4.1.1.1.6 =

Given that censorship is much more narrowly defined than filtering (presumably, although neither term is explicitly defined in the document), I think it would be better to use the term censorship rather than filtering. In some protocol contexts, filtering is an explicit goal and it has nothing to do with censorship.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Jan 2017 15:17:22 +0100

On Thu, Jan 05, 2017 at 12:45:04PM -0500,
 Alissa Cooper <[email-masked]> wrote 
 a message of 201 lines which said:

> If the point of the IPv4 example is to demonstrate the human rights
> impacts -- both positive and negative -- of various protocol
> designs, I find the section to be narrow, slanted, and
> incomplete. It seems focused almost exclusively on the potential
> harms, which, for a protocol as fundamental to the operation of the
> Internet as IPv4, is not justified and renders this section somewhat
> useless IMO.

You raise an interesting question (which, I believe, was not
explicitely discussed in the RG before): should the "human rights"
review of the protocols just an example (of the consequences of
technical decisions for HR) or should it be a comprehensive and
detailed review, with no stone left unturned?

I believe the implicit choice was to just give examples. They are
necessary because, in the IETF, many people believe that technology is
more or less neutral, and do not think that a technical choice can
have political consequences. Therefore, it is useful to have concrete
examples. But, to quote the draft, "It is important to note that the
assessment here is not a general judgment on these protocols.  When
they were conceived, there were many criteria to take into
account. [...] So, when we say 'protocol X has feature Y, which may
endanger the freedom of speech', it does not mean that protocol X is
bad and even less that its authors were evil.  The goal here is to
show, with actual examples, that the design of protocols have
practical consequences for some human rights and these consequences
have to be considered at design time."

So, I think I disagree with your review. The goal was not to give a
complete assessment of the Internet protocols (a different, and
certainly interesting work).

> IPv4 is the basis for packet-switching on the Internet. What would
> the human rights impacts be if packet-switching was never invented?

I don't think that IPv4 needs to be defended, its successes speak for
its importance and usefulness :-) 

> It seems to me that any evaluation of the human rights impacts of
> IPv4 needs to take this more wholistic view into account.

As I said, I think it is a different work. For instance, section 8 of
RFC 6973 does not make a "wholistic" analysis of the presence service,
and does not try to explain that it is useful.

By the way, the original versions of the draft were much more critical
of TCP/IP protocols, sometimes on the verge of paranoia.

> The above is just one example of a fundamental aspect of the
> protocol that is overlooked in the existing analysis. Section
> 3.2.3.1.1 bemoans the visibility of source and destination
> addresses, while overlooking the fact that such addresses can
> actually provide a great deal of anonymity protection compared to
> other identifiers that could have been chosen to be made part of the
> protocol.

The fact that there were worst choices do not seem to me a sufficient
reason to limit the critical analysis.

> Section 3.2.3.1.2 then makes no mention of the fact that NAT can
> actually provide protection from such visibility.

"Home" NAT, the one currently the most common for fixed-line access
does not protect at all since the public IP address identifies a
home. It could be said that CGN protects a bit, but this is not the
case for all usages of NAT.

> it needs to state up front that it is cherry-picking a few harms
> identified as being linked to the protocol design just for
> demonstration purposes.

In my opinion, this is stated in section 3.2.3.

> = Section 3.2.3 =
> 
> "For instance, relying on an external server can be bad for freedom
> of speech" -- without any further context provided, it's hard to
> understand what is meant by an "external" server.

How about "a server which is not under the direct control of one (or
both) of the parties which are communicating"?

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 6 Jan 2017 12:00:08 -0500

Hi Stephane,

> On Jan 6, 2017, at 9:17 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> have to be considered at design time.”

Is the goal to give the impression that those consequences are almost exclusively negative for human rights? Because almost every example given in 3.2.3 is used to emphasize how a protocol design choice has had a negative impact on human rights. I don’t think the examples in this section need to provide a comprehensive analysis of each protocol. But at a minimum they should demonstrate both the positive and negative consequences of design choices for human rights, assuming people think that both positive and negative implications exist.

> its importance and usefulness :-) 

I really disagree. I think there are many people at this point who take the underlying design of the internet as a given, perhaps more so for the potential audience for this document than for a typical IETF protocol spec. For that reason in particular I think it’s important to reflect both the upsides and downsides when describing the protocol design decisions.

> of TCP/IP protocols, sometimes on the verge of paranoia.

Well, as a first-time reader, the draft came off as excessively negative. As noted above, I’m willing to concede that it need not be wholistic, but it would be better if it were more balanced.

> reason to limit the critical analysis.

I’m not asking to take out the criticism, I’m asking to add in acknowledgment of where the design decision arrived on the spectrum of possible choices. I just think it’s too easy to say retrospectively that the choice could have been better without accounting for the fact that the choice actually was better than many other possible choices.

> home.

But not an individual user.

> It could be said that CGN protects a bit, but this is not the

Section 3.2.3 doesn’t say anything about the fact that it is focusing specifically on harms or negative consequences.

> both) of the parties which are communicating”?

Sure, that works.

Thanks,
Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Jan 2017 17:06:29 +0000

On 06/01/17 17:00, Alissa Cooper wrote:
> I think there are many people at this point who take the underlying
> design of the internet as a given, perhaps more so for the potential
> audience for this document than for a typical IETF protocol spec. For
> that reason in particular I think it’s important to reflect both the
> upsides and downsides when describing the protocol design decisions.

I think the above is a good point and well worth handling in the
document. I'm not sure if a general statement along the above lines
would be sufficient but it'd certainly be useful to add a paragraph
or two ack'ing the HR benefits of current Internet protocols and
saying that other text needs to be read with that in mind.

Cheers,
S.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Jan 2017 18:16:32 +0100

On Fri, Jan 06, 2017 at 05:06:29PM +0000,
 Stephen Farrell <[email-masked]> wrote 
 a message of 105 lines which said:

> it'd certainly be useful to add a paragraph or two ack'ing the HR
> benefits of current Internet protocols

<lazy>Any specific example in mind? It has to be specific, just
saying "IP enables people to communicate, which is good", is not,
IMHO, sufficient.</lazy>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Jan 2017 17:18:03 +0000

> saying "IP enables people to communicate, which is good", is not,

<even-more-lazy>Maybe Alissa has ideas for text?</even-more-lazy>

:-)

S.

> 
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Jan 2017 18:26:58 +0100

On Fri, Jan 06, 2017 at 05:18:03PM +0000,
 Stephen Farrell <[email-masked]> wrote 

> <even-more-lazy>Maybe Alissa has ideas for text?</even-more-lazy>

I suspect that most "positive benefits for HR" will be "negative
features" such as "SMTP does NOT require that the user sending an
email has a client certificate, which is good for anonymity"

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Jan 2017 12:29:04 -0500

folks, please be careful not to give redundant answers or repeat yourself.  this discussion has officially reached the too-fast stage, where nobody but the four of you can realistically be expected to actually follow it.

---

From: Niels ten Oever <[email-masked]>
Date: Sat, 7 Jan 2017 18:21:44 +0100

I added some sentences to the third para in the introduction:

Open, secure and reliable connectivity is necessary (although not
sufficient) to excercise human rights such as freedom of expression and
freedom of association {{FOC}}, as defined in the Universal Declaration
of Human Rights {{UDHR}}. The purpose of the Internet to be a global
network of networks that provides unfettered connectivity to all users
and for any content {{RFC1958}}. This objective of stimulating global
connectivity contributes to the Internet's role as an enabler of human
rights. The Internet has given people a platform to exchange opinions,
gather information, enabled people of different background and genders
to participate in the public debate whereas this might have been hard
for them to do so before, and it has allowed people to congregate and
organize. Next to that, the strong commitment to security {{RFC1984}}
{{RFC3365}} and privacy {{RFC6973}} {{RFC7258}} in the Internet's
architectural design contribute to the strengthening of the Internet as
a human rights enabling environment. One could even argue that the
Internet is not only an enabler of human rights, but that human rights
lie at the basis of, and are ingrained in, the architecture of the
networks that make up the Internet. Internet connectivity increases the
capacity for individuals to exercise their rights, the core of the
Internet, its architectural design is therefore closely intertwined with
the human rights framework {{CathFloridi}}. The quintessential link
between the Internet's infrastructure and human rights has been argued
by many. {{Bless}} for instance argues that, 'to a certain extent, the
Internet and its protocols have already facilitated the realization of
human rights, e.g., the freedom of assembly and expression. In contrast,
measures of censorship and pervasive surveillance violate fundamental
human rights.' {{Denardis15}} argues that 'Since the first hints of
Internet commercialization and internationalization, the IETF has
supported strong security in protocol design and has sometimes served as
a force resisting protocol-enabled surveillance features.' By doing so,
the IETF enabled the manifestation of the right to privacy, through the
Internet's infrastructure. Additionally, access to information gives
people access to knowledge that enables them to help satisfy other human
rights, as such the Internet  increasingly becoming a pre-condition for
human rights rather than a supplement.

Curious to hear what you all think of this.

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3

---

From: [email-masked]
Date: Sat, 7 Jan 2017 16:59:51 -0500

Perhaps a tangent but one early motivation for the establishment of
public libraries was so any citizen could access a copy of the laws.

How else could they?

And isn't access to the law a particularly fundamental right?

Much grows out of that one observation.

With paper libraries in decline the evolution of thought seems to me
obvious:

We mustn't decide that online access to the law is a sufficient
replacement while not also ensuring careful guarantees of easy,
reliable, and accurate access. And the privacy and security of that
access.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 9 Jan 2017 17:55:36 +0100

Hi Alissa,

Thank you very much for this very thorough review. I made quite a few
changes based on this. All changes can be found here:

https://github.com/nllz/IRTF-HRPC/commit/cb0a9788f9efd2050b7a1912fda8e823e4019ace

Please find my response and some questions inline (and sorry for the
delay in response):

On 01/05/2017 06:45 PM, Alissa Cooper wrote:
> Below is a review of draft-irtf-hrpc-research-07. I have not been
> involved in the RG so these comments are for what they're worth and I
> apologize if some of this ground has been trod before. This was an
> interesting read and most of my comments are provided with an eye
> towards making the document more useful/actionable in the IETF
> eventually, which I realize may not be a shared goal necessarily.
> 
> Substantive comments:
> 
> impacts -- both positive and negative -- of various protocol designs,
> I find the section to be narrow, slanted, and incomplete. It seems
> focused almost exclusively on the potential harms, which, for a
> protocol as fundamental to the operation of the Internet as IPv4, is
> not justified and renders this section somewhat useless IMO.
> 
> IPv4 needs to take this more wholistic view into account. IPv4
> completely revolutionized networking and allowed for the amazing
> innovation that the purposes for which people were connecting could
> be disassociated from the providers of the physical circuits. Had
> that not happened, how would the capacity for human freedom of
> expression in the world be different from what it is today? I don't
> think an assessment of the human rights impacts of IPv4 can ignore
> this and still be credible.
> 
> The above is just one example of a fundamental aspect of the protocol
> that is overlooked in the existing analysis. Section 3.2.3.1.1
> bemoans the visibility of source and destination addresses, while
> overlooking the fact that such addresses can actually provide a great
> deal of anonymity protection compared to other identifiers that could
> have been chosen to be made part of the protocol. Having decried
> address visibility, Section 3.2.3.1.2 then makes no mention of the
> fact that NAT can actually provide protection from such visibility.
> 
> For this section to add value, it either needs to provide a wholistic
> analysis of both the positive and negative impacts of the protocol
> that takes into consideration the space of alternative designs and
> outcomes, or it needs to state up front that it is cherry-picking a
> few harms identified as being linked to the protocol design just for
> demonstration purposes.
> 
> I think the same goes for the other examples in Section 3.2.3. The
> existing set of design and deployment decisions seem to be taken as
> givens rather than as a set of inflection points where things could
> have turned out much worse for human rights. What if the DNS hadn't
> been designed in a distributed fashion? What if we hadn't managed to
> make HTTP performant such that it could support rich media and
> applications as it does today? What if instead of the near-ubiquitous
> ability for stacks to deploy TLS we were all relying on IPSec as our
> underlying security protocol? All of those were real possibilities.
> Not acknowledging them makes the section read like a litany of
> criticisms rather than a balanced assessment of the positive and
> negative rights impacts of the protocols.
> 
> I was also surprised to see P2P, VPNs, a specific HTTP status code,
> and DDoS attacks in this section which is purportedly about
> protocols. This seems like a good bit of mixing apples and oranges; I
> think the section would be more effective if it focused on specific
> protocols since that is the unit of design most familiar to and most
> actionable for IETF engineers. Analyzing protocol-level design
> decisions is particularly important because what can be controlled
> within a protocol design space is different from what can be
> controlled within a particular implementation or deployment.
> 

As outlined in a subthread by Stephane and Stephen, this part did not
aim to do an in-depth Human Rights Impact Analsysis of a single protocol
but merely establish that there is a relationship between human rights
and protocols based on case studies.

I do hope one of the following hrpc drafts indeed can be the development
of a model for a Human Rights Impact Assessment of protocols, and maybe
even for of combinations of protocols (because that of course brings in
different vectors). This will needs more research and experimentation
though.

I do agree that the cases are a mix of things (even though all have
related RFCs)  but we exactly aimed at a mix of things so see what
different relations between protocols, standards and human rights could
look like.

I'm sorry to hear that you found the overall tone quite negative.
Therefore I added some extra positive text here:

https://github.com/nllz/IRTF-HRPC/commit/76375bdbf93c1c63661824fbcb7c89b17ecdb609

> = Section 3.2.3.5.2 =
> 
> "Peer-to-Peer traffic (and BitTorrent in particular) represents a
> high percentage of global Internet traffic"
> 
> Is there a citation for this? My understanding is that by most
> measurements the share of p2p traffic is pretty low these days.
> 

This is the most recent stat I could find on this:

http://mashable.com/2014/05/14/file-sharing-decline/#FG_t.2P3Uaqf

https://www.rt.com/news/162744-p2p-file-sharing-increase/

Which indeed indicated it flattened out. So that's why I propose

s/high/significant

> (1) The questionnaire seems like it took the kitchen sink approach.
> Many of the considerations covered here are already covered in other
> existing IETF documents. In a number of cases this document took
> specific items from those existing documents and broke them out into
> their own separate subsections with many detailed questions (e.g.,
> privacy, anonymity, pseudonymity, confidentiality, integrity,
> reliability, authenticity). I think most protocol designers will find
> the sheer volume of questions here daunting and will find the
> redundancy both within the section and together with existing
> guidance documents reason enough to skip a human rights analysis
> altogether. I would recommend really trying to streamline this
> section down to the essence of the questions that protocol designers
> are not already asking themselves but should be. If you want to
> include a comprehensive mapping between the technical concepts and
> specific human rights, put that mapping in a different section and
> focus this section on the most important and actionable questions.
> 

Thanks for this suggestion. I do agree that there are double parts, and
the parts that are doulbe, are also clearly referenced as such. What we
tried to do is create a clear human rights lens to specific problems,
that's why I  do not think the current parts are redundant.

Also: I think that providing a reason for people to look at those
documents increases that chance that they actually will, instead of just
saying: have a look at this.

> (2) I think it would be a lot clearer if the various subsections were
> explicit about where the recommendations here are different than
> recommendations in existing IETF documents and policies. For privacy,
> security, internationalization, and extensibility, the document mixes
> in references to existing guidance/policies with its own text and
> suggestions. If the suggestion is to just go read the other
> documents, a simple reference would do; otherwise, I think the
> document could be a lot clearer about where it is asking protocol
> designers to depart from or go beyond what the existing guidance
> requires. Other than drawing explicit links between the concepts and
> human rights affected, I think 4.1.1.1.2, .4, .9, .10, .14, .15, .16,
> and .17 could all be removed or replaced with simple pointers to
> existing documents (possibly also true for .5 and .12 but it’s not my
> area of expertise).

The paragraphs that you outline above are already pointing to the other
documents. The guidelines are not means to replace BCP72 or RFC6973, but
provide another perspective for looking at protocols from a human rights
perspective, and providing extra motivation for people to look at the
these standards, because many of them (Internationalization, etc) are
not as commonly use as we might like.

> 
> = Section 4.1.1.1.1 =
> 
> The example doesn't seem to be responsive to the question. The
> question is about requiring functionality at intermediaries whereas
> the example is about a design decision to prevent intermediaries from
> carrying out such functionality.
> 

The example shows that one can implement message encryption in different
ways, right? But maybe I am misunderstanding your question.

> I think this set of questions could benefit from some refinement, in
> particular in terms of the actor(s) being targeted. I don't quite
> understand the notion of a protocol itself "looking" at a payload or
> making a decision. 

s/looking at packet payload/use data from the packet payload

> I'm guessing this one is actually targeted at
> network intermediaries, as in 4.1.1.1.1, since the whole point of
> many protocols is for endpoints to take some action based on packet
> payloads.
> 

As well as protocols that might make use from packet payload data
instead of only using data from the header.

> I also think the example in this section (and all the subsections of
> 4.1.1.1, actually) would be more useful if it cited a specific
> protocol that has the effect that the section raises concerns about,
> because it's hard to understand what is being implied here. That is,
> I'm not sure what the implications would be of the answers to these
> questions if applied to, say RFC 2474 and RFC 2475, because the
> implications all depend on the deployment context.
> 

I would be hesitant to target this at specific protocols, because that
might exclude other protocols for which this could be relevant as well.
I think the first sentence already is kind of a pre-selection, right?

> used to facilitate censorship, as in the case of IP based
> censorship, which affects protocols like HTTP."
> 
> I'm not sure how much mileage there is to be had out of this question
> and example, because most protocols use identifiers. I don't think
> this is a bad thing, it's just really hard to design a way to
> communicate between two endpoints about something without using
> identifiers of some sort. The question is phrased broadly enough that
> I think the answer will almost always be "yes" but I'm not sure to
> what end.
> 

Re-using identifiers might be a bad thing for de-anonymization, and if
something can be implemented stateless, it might also be better for
privacy, right?

I think the last two questions in this para are key for providing
perspective:

Can your protocol contribute to filtering in a way it could be
implemented to censor data or services? Could this be designed to ensure
this doesn't happen?

I also think the example provides quite some framing which also shows
the boundaries of this question.

> = Section 4.1.1.1.7 =
> 
> This section is concerning because it seems to be trying to
> re-interpret or change existing IETF policies, which seems
> inappropriate even for an informational IRTF document. For example,
> this bit in particular caught my eye:
> 
> As nice as it would be if this were always true, it's not, and it's
> not likely going to be any time in the foreseeable future for the
> 8000+ specifications the IETF has produced. 

How is this not in-line with BCP78 ? I think this is exactly what BCP78
says, the standards are available freely by the IETF.

> Many of the reasons for
> that are outside the control of IETF participants. So I find it
> unhelpful to suggest these as requirements. I also don't think BCP 78
> and 79 and the note well should be further elaborated in a document
> such as this one; even as informational people can get confused.
> 
> I would suggest deleting this section as there is a high potential
> for confusion and I'm not sure that it provides much countervailing
> benefit.
> 
> Also, I don't understand how the example relates to the rest of the
> section or why the emphasis on DPI is there.
> 
> = Section 4.1.1.1.10 =
> 
> The example doesn't seem to relate to pseudonymity and I'm not sure
> what is meant by a "feature." Again here giving a specific protocol
> example would be more helpful I think.

Changed into:

Example:

Designing a standard that exposes private information, it is important
to consider ways to mitigate the obvious impacts. Pseudonymity means
using a pseudonym instead of one's "real" name. There are many reasons
for users to use pseudoyms, for instance to: hide their gender, protect
themselves against harassment, protect their families' privacy, frankly
discuss sexuality, or develop a artistic or journalistic persona without
retribution from an employer, (potential) customers, or social
surrounding. {{geekfeminism}} The difference between anonymity and
pseudonymity is that a pseudonym often is persistent. "Pseudonymity is
strengthened when less personal data can be linked to the pseudonym;
when the same pseudonym is used less often and across fewer contexts;
and when independently chosen pseudonyms are more frequently used for
new actions (making them, from an observer's or attacker's perspective,
unlinkable)." {{RFC6973}}

> 
> = Section 4.1.1.1.11 =
> 
> I think combining access for those with disabilities and access for
> those with poor connectivity under a single heading is confusing.
> These imply some rather disparate design decisions, not all of which
> will apply to all protocols nor in the same ways.
>

I agree, I guess the problem lies in the word 'accessibility'. That is
why we're offering different definitions for that in the glossary as
well. Any suggestion on how we might improve this?

> = Section 4.1.1.1.16 =
> 
> I think it would be better not to mix integrity with authentication
> (via the example reference) since you can have one without the
> other.
> 

I separated the two and created a different example.

> 
> 
> Nits:
> 
> = Section 1 =
> 
> "the privacy ... of the network" doesn't seem like the concept
> actually being described here. Usually we're focused on privacy of
> individuals, and confidentiality of corporations (e.g., network
> operators).
> 

Thanks, fixed!

> There are two different definitions offered for "Connectivity."

You mean this?

: The extent to which a device or network is able to reach other devices
or networks to exchange data. The Internet is the tool for providing
global connectivity {{RFC1958}}.
Different types of connectivity are further specified in {{RFC4084}}.

The first one provides a definition and the second a subcategorization,
right?

> Accessibility is listed twice for "Right to political

Thanks! That should have been connectivity!

> understand what is meant by an "external" server.

s/external server/centralized service

> = Section 4.1.1.1.2 =
> 
> "If a protocol provides insufficient privacy it may stifle speech" --
> I don't think it's the protocol that would be doing the stifling.
> 

Thanks, changed into:

If a protocol provides insufficient privacy protection it may have a
negative impact on freedom of expression as users self-censor for fear
of surveillance, or find themselves unable to express themselves freely.

> = Section 4.1.1.1.6 =
> 
> Given that censorship is much more narrowly defined than filtering
> (presumably, although neither term is explicitly defined in the
> document), I think it would be better to use the term censorship
> rather than filtering. In some protocol contexts, filtering is an
> explicit goal and it has nothing to do with censorship.
> 

Thanks fixed!

All changes can be found here:

https://github.com/nllz/IRTF-HRPC/commit/cb0a9788f9efd2050b7a1912fda8e823e4019ace

> 
> _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 9 Jan 2017 16:46:53 -0500

Hi Niels,

Some comments inline.

> On Jan 9, 2017, at 11:55 AM, Niels ten Oever <[email-masked]> wrote:
> 
> Hi Alissa,
> 
>> ...

If the section is specifically designed to present cases that cut across protocols, implementations, and networking paradigms, it should say so up front. The title and introduction to 3.2.3 indicate that the section is about protocols.

> https://github.com/nllz/IRTF-HRPC/commit/76375bdbf93c1c63661824fbcb7c89b17ecdb609

I think this helps, but what would be better would be specific text in the intro to 3.2.3 that explains that the emphasis of the examples is on adverse impacts to human rights. Perhaps even better would be to remove the positive examples and just focus exclusively on the negative ones, so it’s clear that the thrust of the entire section is to provide negative examples.

> https://www.rt.com/news/162744-p2p-file-sharing-increase/

If you’re comfortable citing Sandvine’s numbers as the first article does then there are more recent ones to point to: 
https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-american-traffic-is-now-streaming-video-and-audio.html <https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-american-traffic-is-now-streaming-video-and-audio.html>
https://www.sandvine.com/trends/global-internet-phenomena/ <https://www.sandvine.com/trends/global-internet-phenomena/>

Both of these challenge even a claim of “significant” percentage, although no overall global number is given. In any event, there should be a cite in the document.

> saying: have a look at this.

I think we just disagree about this, which is fine.

> perspective,

Just to re-state the point: as someone who is quite familiar with the content of a number of the referenced specs, it’s not clear to me whether these sections are asking me to use a different set of considerations from those specs or not. I suspect other readers would be similarly confused.

> and providing extra motivation for people to look at the

An instant messaging protocol might be designed such that intermediaries can make use of application-specific functions. That same protocol might support end-to-end encryption, or protocol designers might later design enhancements to the protocol that facilitate end-to-end encryption (an analogous example for real-time media would be PERC). Whether a protocol allows for application-specific functions at intermediaries and whether it supports end-to-end encryption can be mutually exclusive design decisions. 

> instead of only using data from the header.

Is the implication supposed to be that protocols that require endpoints to take action based on payload data are somehow better for human rights than those where endpoints are expected to take action solely based on header data? I don’t understand why that would be. Also, the distinction between payloads and headers is not clear, since a header at one layer is a payload at the next layer.

> I think the first sentence already is kind of a pre-selection, right?

I guess the label “Example” caused me to expect, well, an example of how each consideration might apply to a specific protocol, so that as a protocol designer I could learn the logic of how it might apply to my protocol. But if the text under each “Example” label isn’t really meant to provide an example, perhaps it should be labeled some other way?

> something can be implemented stateless, it might also be better for

I don’t think it’s accurate to make those claims generically. My SDP implementation might re-use SSRCs with no impact one way or another on anonymity. And using identifiers doesn’t necessarily imply any state is being maintained. If you could add a few examples of protocols that exchange content without using identifiers, I think I would be more convinced that the generic question about content identifiers has utility.

> the boundaries of this question.

I don’t really understand the example TBH. It talks about filtering based on IP address but then cites HTTP 451, whose use might have nothing to do with IP-based filtering.

> says, the standards are available freely by the IETF.

If you can find the text in BCP 78 that says the above, please cite it. We standardize protocols that normatively rely on specifications produced by other SDOs that are not freely available, even though it’s not ideal. The most recent one I can remember the IESG approving is https://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-10 <https://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-10>
> well. Any suggestion on how we might improve this?

Split these into separate sections with separate considerations for each.

> Different types of connectivity are further specified in {{RFC4084}}.

That is one of the definitions given. The other definition is at the end of the section:

Connectivity  The combination of the end-to-end principle,
      interoperability, resilience, reliability and robustness are the
      enableing factors that result in connectivity to and on the
      Internet.

Thanks,
Alissa

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Jan 2017 22:44:34 +0100

On Sat, Jan 07, 2017 at 06:21:44PM +0100,
 Niels ten Oever <[email-masked]> wrote 
 a message of 120 lines which said:

> {{Bless}} for instance argues that, 'to a certain extent, the
> Internet and its protocols have already facilitated the realization
> of human rights, e.g., the freedom of assembly and expression.

You can quote A. J. Liebling
<https://en.wikiquote.org/wiki/A._J._Liebling> "Freedom of the press
is guaranteed only to those who own one" or Benjamin Bayart
<https://fr.wikiquote.org/wiki/Internet#Benjamin_Bayart> "L’imprimerie
a permis au peuple de lire, Internet va lui permettre d’écrire" ("the
printing press allowed the people to read, Internet will enable it to
write").

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Jan 2017 22:53:18 +0100

On Mon, Jan 09, 2017 at 04:46:53PM -0500,
 Alissa Cooper <[email-masked]> wrote 
 a message of 783 lines which said:

> what would be better would be specific text in the intro to 3.2.3
> that explains that the emphasis of the examples is on adverse
> impacts to human rights. Perhaps even better would be to remove the
> positive examples and just focus exclusively on the negative ones,
> so it’s clear that the thrust of the entire section is to provide
> negative examples.

I disagree. The goal of the section is certainly not to focus on
negative examples.

I personnally think it would be a welcome addition to add posituve
examples but I asked for some and nobody suggested anything (besides
the very general "IP is efficient, it works, and it allows a wonderful
thing, the Internet"). May be we should search harder?

> > implemented to censor data or services? Could this be designed to
> > ensure this doesn't happen?
> > 
> I don’t really understand the example TBH. It talks about filtering
> based on IP address but then cites HTTP 451, whose use might have
> nothing to do with IP-based filtering.

I think it is two different things. "Filtering can be made apparent by
the use of status code 451" is an answer to the question "Does your
protocol make it apparent or transparent when filtering happens?" and
"Identifiers of content exposed within a protocol might be used to
facilitate censorship" is an answer to the question "Does this
protocol introduce new identifiers or reuse existing identifiers (e.g.
MAC addresses) that might be associated with persons or content?"

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 18 Jan 2017 13:18:53 +0100

Hi Alissa,

Comments inline:

Niels ten Oever
Head of Digital

Article 19
www.article19.org

On 01/09/2017 10:46 PM, Alissa Cooper wrote:
> Hi Niels,
> 
> Some comments inline.
> 
>> On Jan 9, 2017, at 11:55 AM, Niels ten Oever <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Alissa,
>>
> If the section is specifically designed to present cases that cut across
> protocols, implementations, and networking paradigms, it should say so
> up front. The title and introduction to 3.2.3 indicate that the section
> is about protocols.
> 

Added:

### Map cases of protocols, implementations and networking paradigms
that adversely impact human rights or are enablers thereof

Given the information above, the following list of cases of protocols,
implenentations and networking paradigms that adversely impact or enable
human rights was formed.

> I think this helps, but what would be better would be specific text in
> the intro to 3.2.3 that explains that the emphasis of the examples is on
> adverse impacts to human rights. Perhaps even better would be to remove
> the positive examples and just focus exclusively on the negative ones,

Added some text:

It is important to note that the assessment here is not a general
judgment on these protocols, nor an exhaustive listing of all the
potential negative or positive impacts on human rights they might have.

> If you’re comfortable citing Sandvine’s numbers as the first article
> does then there are more recent ones to point to: 
> https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-american-traffic-is-now-streaming-video-and-audio.html
> https://www.sandvine.com/trends/global-internet-phenomena/
> 
> Both of these challenge even a claim of “significant” percentage,
> although no overall global number is given. In any event, there should
> be a cite in the document.
> 

Added

> Just to re-state the point: as someone who is quite familiar with the
> content of a number of the referenced specs, it’s not clear to me
> whether these sections are asking me to use a different set of
> considerations from those specs or not. I suspect other readers would be
> similarly confused.
> 

Am trying to understand this better. If a questions says:

Did you have a look at the Privacy Considerations for Internet Protocols
{{RFC6973}}, especially section 6.1.1 ?

or:

Did you have a look at Guidelines for Writing RFC Text on Security
Considerations {{BCP72}}? Have you found any attacks that are out of
scope for your protocol? Would these attacks be pertinent to the human
rights enabling features of the Internet (as described throughout this
document)?

I don't not necessarily understand how this could be confusing.

But to resolve this I would like to offer:

This section provides guidance for document authors in the form of a
questionnaire about protocols and their (potential) impact. The
questionnaire may be useful at any point in the design process,
particularly after document authors have developed a high-level protocol
model as described in {{RFC4101}}. These guidelines do not seek to
replace any existing referenced specifications, but rather contribute to
them and look at the design process from a human rights perspective.

> An instant messaging protocol might be designed such that intermediaries
> can make use of application-specific functions. That same protocol might
> support end-to-end encryption, or protocol designers might later design
> enhancements to the protocol that facilitate end-to-end encryption (an
> analogous example for real-time media would be PERC). Whether a protocol
> allows for application-specific functions at intermediaries and whether
> it supports end-to-end encryption can be mutually exclusive design
> decisions. 
> 

You're right, we replaced the end-to-end example to a middle-box example.

Thanks for this.

> Is the implication supposed to be that protocols that require endpoints
> to take action based on payload data are somehow better for human rights
> than those where endpoints are expected to take action solely based on
> header data? 

Exactly the other way around.

> I don’t understand why that would be. Also, the distinction
> between payloads and headers is not clear, since a header at one layer
> is a payload at the next layer.
> 

I never thought payload like that, not sure if that is very colloquial
use. What term could we use to describe the non-header part of a packet?
Data portion?

Would this work better:

If your protocol impacts packet handling, does it use user data (packet
data that is not included in the header)? Is it making decisions based
on the payload of the packet? Does your protocol prioritize certain
content or services over others in the routing process ? Is the protocol
transparent about the prioritization that is made (if any)?

> I guess the label “Example” caused me to expect, well, an example of how
> each consideration might apply to a specific protocol, so that as a
> protocol designer I could learn the logic of how it might apply to my
> protocol. But if the text under each “Example” label isn’t really meant
> to provide an example, perhaps it should be labeled some other way?
> 

It's more of an impact example than a specific protocol example.

> I don’t think it’s accurate to make those claims generically. My SDP
> implementation might re-use SSRCs with no impact one way or another on
> anonymity. And using identifiers doesn’t necessarily imply any state is
> being maintained. If you could add a few examples of protocols that
> exchange content without using identifiers, I think I would be more
> convinced that the generic question about content identifiers has utility.
> 

Using an identifier doesn't mean state is being kept, but no state can
be kept without using an identifier.

If state identifiers are used this can have a negative effect on
anonymity, especially if these are also re-used in other protocols, and
thereby creating a more persistent identifier.

This does not mean that every identifier will have that effect.

I think RFC4941 and RFC7217 could be a good example of this.

> nothing to do with IP-based filtering.

Added:

In the development of the IPv6 protocol it was discussed to embed a
Media Access Control (MAC) address into unique IP addresses. This would
make it possible for 'eavesdroppers and other information collectors to
identify when different addresses used in different transactions
actually correspond to the same node. {{RFC4941}} This is why Privacy
Extensions for Stateless Address Autoconfiguration in IPv6 have been
introduced. {{RFC4941}}

> If you can find the text in BCP 78 that says the above, please cite it.
> We standardize protocols that normatively rely on specifications
> produced by other SDOs that are not freely available, even though it’s
> not ideal. The most recent one I can remember the IESG approving
> is https://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-10
> 

I've added:

Do you normatively reference another standard that is not available
without cost (and could it possible be done without)?

[...]

All standards that need to be normatively implemented should be freely
available and with reasonable protection for patent infringement claims,
so it can also be implemented in open source or free software. Patents
have often held back open standardization or been used against those
deploying open standards, particularly in the domain of cryptography
{{newegg}}. An exemption of this is sometimes made when a protocol is
standardized that normatively relies  on speficiations produced by
others SDOs that are not freely available.

> Split these into separate sections with separate considerations for each.

I've added the 'Accessibility' in relation to connectivity to the header
'Connectivity', and kept 'Accessibility' in relation to the design of
protocols, services or implementation that provide an enabling
environment for people with disabilities.

>       enableing factors that result in connectivity to and on the

Fixed.

Thanks again!

Best,

Niels