Subject: Re: [hrpc] Review of draft-irtf-hrpc-political-01

From: Niels ten Oever <[email-masked]>
Date: Fri, 17 May 2019 17:38:54 +0200

Hi Joe,

Thanks a lot for this review, I have accepted and integrated almost everything, which has led to a far more modest research question and conclusion. I have just a few nits:

On 3/28/19 8:43 AM, Joseph Lorenzo Hall wrote:
>             This provides a useful list of past IETF RFCs that had to struggle with non-engineering factors in standards setting, but then says, "Recently there has been an increased discussion on the relation between Internet protocols and human rights [RFC8280]", pointing to the HRPC IRTF RFC... I think this needs to qualify that this discussion had happened in the IRTF and not ubiquitously across the IETF.

It has also been the topic of a tech plenary talk [0], so I think one can say it has been discussed, no?

[0] https://www.youtube.com/watch?v=qvgIX3-pAZE

>           +
>             Would be great to find a more plain language way of saying "affordances". I'm not convinced the definition in the terminology section is comprehensible to engineers. ("The possibilities that are provided to an actors through the ordering of an environment by a technology.") 

Personally I think affordances are quite an essential term, exactly because it bridges technological determinism and social constructivism, but I tried to add more explanation to the glossary.

>       o
>         Section 4:
>       o
>           +
>             This needs to be clear this discussion has happened at IRTF, not IETF or needs to cite more evidence: "Nonetheless there has been a recent uptick in discussions around the impact of Internet protocols on human rights [RFC8280] in the IETF and more general about the impact of technology on society in the public debate."

I think this debate has both taken place at the plenary, as well as at ietf@ietf, and has not been limited to hrpc. 

>           +
>             This section is unclear in terms of if these are all academic or IETF-external views... the intro to this section seems to overclaim about what the reader should expect. E.g., 4.2 and 4.3 have no references; are any of these themes from community interviews or solely from the literature?

'This document aims to provide an overview of the spectrum of different positions that have been observed in the IETF and IRTF community.'

But I have added: , and have been observed during interviews, mailinglist exchanges, and during research group sessions. 

>           +
>               #
>                 This doesn't seem to reference interviews at all, so maybe clarify this is from academic and other literature? 
>           +
>             Would be great to find a more simple term than "conurbation".

Taken straight from the self-description by Andrew Sullivan!
>           +
>             4.3: this is perhaps a minor point, but even horse-powered vehicle culture at scale would require these things, so it's not self-evident this claim is true: "But even if that did not happen, widespread automobile use requires paved roads, and parking lots and structures.  These are pressures that come from the automotive technology itself, and would not arise without that technology." (I don't think this undermines the point being made here, but it's distracting.)

Again, same as above. I did not want to impinge on self-description of different positions.
>           +
>             4.5: the entire paragraph about the numbered Postman arguments is pretty opaque and needs the authors to unpack that or is not relevant to engineers. I think you can delete this graph without much effect.

I propose I make this a numbered list, to increase readability. But I do think it adds something because it makes an important point on different kind of biases.

As said, all other points I have integrated and sought to address, and I made the conclusion a lot less forward leaning.

Greatly looking forward to hear what you think!

Best,

Niels

-- 
Niels ten Oever
Researcher and PhD Candidate
DATACTIVE Research Group
University of Amsterdam

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