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

[Alissa Cooper <[e-mail]>]

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.