Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07

From: Niels ten Oever <[email-masked]>
Date: Thu, 5 Jan 2017 17:05:11 +0100

Hi Andrew,

Thanks a lot for this response, reply inline:
On 12/30/2016 03:20 AM, Andrew Sullivan wrote:
> Dear colleagues,
> 
> This is my much-overdue response to draft-irtf-hrpc-research.  I
> apologize for the dilatory notes.  I have failed to send these remarks
> on every previous occasion, partly because the authors are much better
> at turning around drafts than I am at completing my reviews.
> 
> I should say that in general I think this is a useful draft and even
> if the authors reject my suggestions I would have no objection to the
> RG publishing the draft.
> 
> Part of the reason that I have struggled with this draft is because,
> while I do not really disagree with many of its conclusions or
> recommendations, I have a number of concerns about how it gets to
> those conclusions.  I've made some oblique references to these points
> in various mic lines and list postings, but I haven't done a good job
> of laying out the concern, so this is an effort to do it more
> completely.
> 
> My concern is that the draft cannot decide whether it is a human
> rights ethics _for_ the Internet protocols, or a HR ethics _of_
> the Internet protocols.
> 

What we're trying to do is to propose a HR ethics for Internet
protocols, which finds it roots in the values that are currently a
partial (and quite obscure) ethic of Internet protocols.

I think the fact that we're talking for so long about what these could
be, makes it really clear that the ethics of Internet protocols are by
far not as clear as many who have worked on the early network would have
wanted them to be. This can also be seen in the film 'Net of Rights'.

> The trouble shows up early on.  For instance, section 1 says, "The
> purpose of the Internet to be a global network of networks that
> provides unfettered connectivity to all users and for any content
> [RFC1958]" In my reading, RFC 1958 does not actually offer a claim
> about the purpose of the Internet.  Perhaps of greater concern, RFC
> 1958 explicitly notes that its own purpose is not "to lay down dogma
> about how Internet protocols should be designed".  That is, while RFC
> 1958 is about "architecture", it strives not to be prescriptive.  It's
> therefore strange to see it cited as the source for "this objective"
> of the Internet.
> 

I think the sentence 'the community believe that the goals is
connectivity' is pretty clear here:

   2.1 Many members of the Internet community would argue that there is
   no architecture, but only a tradition, which was not written down for
   the first 25 years (or at least not by the IAB).  However, in very
   general terms, the community believes that the goal is connectivity,
   the tool is the Internet Protocol, and the intelligence is end to end
   rather than hidden in the network.

> Now, it is true that RFC 3935 says, "The Internet isn't value-neutral,
> and neither is the IETF."  But the rest of the text is in fact silent
> on _which_ values the Internet has, because the document is about the
> IETF, and not the Internet.  And while RFC 3935 continues to talk
> about the technologies that the IETF "choose[s] to create" as opposed
> to ones that are possible, it seems to me that it actually expresses
> implicitly a value of the Internet as such.  That value can found an
> ethic all of its own.

RFC3935 seems to have a bit thicker description here:

      The IETF community wants the Internet to succeed because we
      believe that the existence of the Internet, and its influence on
      economics, communication, and education, will help us to build a
      better human society.

Also the following description seems to negate your statement that there
is such a thing as an inherent network ethic:

 These concepts have little to do with the
   technology that's possible, and much to do with the technology that
   we choose to create.

According to RFC3935 it's about a conscious ethical choice we're making,
that we're not basing on what is possible, but on what we choose to create.

You're right that the documents are not very specific about what this
should be, and that is exactly the void that this document tries to fill.

> 
> If there is an ethic of the Internet, it is this: that more
> internetworking is better because that makes the Internet better
> connected.  This is a (more or less) pure engineering value that follows
> directly from the recognition of network effects.  Once you have
> network effects, a given network is more valuable from the connections
> it can make.  But that has special consequences for the Internet,
> because internetworking is not flat.  It is instead networking of
> networks, which means that any given connection to the Internet must
> always be treated as the connection of another network.  This requires
> a formal indifference to the nature of the network on the other
> side of that connection, an acknowledgement that the newly-connected
> network might be patchy or unreliable, and also an assumption that the
> network so connected is not itself the locus of intelligence.  We're
> not building the Catanet.
> 
> Now, it seems to me that there are two stances that the draft takes
> with respect to why human rights ought to matter for Internet
> protocols.  One of them is more troublesome for the draft's purpose
> than the other.  The first is that there are human rights, and that
> Internet protocols need to be built to support them.  

I think this is a misrepresentation of the draft. There is an explicit
difference between 'support human rights' (which would be an advocacy /
enforcement position) and 'respect human rights' (which simply ensures
that there is no adverse impact on human rights).

We might call
> this the "extrinsic value" position.  The second is that there are
> human rights, and the expression of them aligns nicely with the
> (above-outlined) positive engineering value of the Internet; we might
> call this the "concordant value" position[1].  We can see this tension in
> the following bit from section 1:
> 
>    Therefore, important human rights enabling characteristics
>    of the Internet might be degraded if they're not properly defined,
>    described and protected as such.  And, the other way around, not
>    protecting human right enabling characteristics could also result in
>    (partial) loss of functionality and connectivity, and other inherent
>    parts of the Internet's architecture of networks.[2]
> 
> The first sentence of these is a claim about extrinsic values and why
> Internet protocol designers ought to care about those.  The second is
> about how protecting human rights contributes to the values of the
> Internet.  My basic concern is that this dual motivation at once
> threatens both the goal (of 3935) and the effort.  The goal is
> threatened because the extrinsic motivation changes the meaning of
> "work better".  The effort is threatened because it obscures the
> engineering value of "the network for its own sake", and subsumes that
> value beneath externally-supplied values.
> 

I would not have a problem with a useable inherent network ethic, if
there was such a thing. How your concept of an inherent network ethic
help us with issues like internationalization, universal availability,
and accessibility? It completely leaves the human out of the equation,
whereas the Internet is about humans, not about the Internet itself. The
Internet is not an interesting science expiriment (anymore), it is
mediating central democratic processes, the public debate, and the
global economy. The Internet does not simply exist for the Internets sake.

Furthermore, there are many different ways in which inter-connectivity
is possible, but it gives very little guidance on the hard choices we
need to make and the impact they might have.

> For the draft, a consequence of all the above is that the motivation
> for the human rights considerations is not clearly stated in terms
> that a sceptic might endorse.  The comparison with the security and
> privacy considerations is instructive.  Those seem, to my eye, to be
> motivated by the value of security or privacy (as appropriate), but
> the failure to take them into consideration is framed mostly in terms
> of the harm _to the Internet_ that arises if the issue is not taken
> into account.  Perhaps in the case of the hrpc draft the extrinsic
> motivations are more reasonable, because this is not an IETF
> document.  But if one thinks that technologies are neutral, and that
> it is the _use_ of the technologies that can trample on rights, the
> focus on human rights might sound like an attempt to make the IETF
> into a political actor.

Technology is not neutral, neither is the Internet and neither is the
IETF. The IETF already is political and also already is a political
actor. There is are ample examples of that in the book by Laura DeNardis:

DeNardis, Laura. 2009. Protocol Politics: The Globalization of Internet
Governance. Cambridge, MA: MIT Press.

as well as:

DeNardis, Laura. 2014. The Global War for Internet Governance.

I am still waiting for relevant literature that argues that technology
is ethically neutral. We've cited quite a body of literature that argues
the exact opposite. Repeating that technology is neutral will not make
it more true, but I am more than happy to be convinced.

> 
> In order to make this clearer, it might help if the draft discussed
> more plainly three possible interactions: how considering rights
> might be good for the purposes of the Internet protocols (perhaps
> because it makes them more useful and therefore more likely to be
> adopted, or because it makes them more resilient to certain kinds of
> attacks, or whatever); how considering rights might be useful in
> extrinsic value terms (this seems mostly to be what section 3 does);
> and how considering rights might be good for the overall
> socio-political environment into which the Internet is deployed (some
> of section 1 and some of section 6 seems to be doing this).
> 
> Finally, in my view, that very section 6 continues to be troublesome.
> It argues that protocols _are_ politics despite outlining some views
> that do not seem to support such a view at all.  It says
> 
>    However, these protocols and standards do not
>    exist outside of their technical context nor outside of their
>    political, historical, economic, legal or cultural context.  This is
>    best exemplified by the way in which protocols have become part and
>    parcel of political processes and public policies
> 
> The first of these sentences is trivially true: _nothing_ exists
> outside if its context, so protocols and standards don't either.  But
> the best exemplification of that is not that people use protocols as
> part of their political arguments or public policies.  Indeed, if one
> believed that protocols are merely tools and that it is the use of the
> tool (not the tool as such) that determines its political
> consequences, one could argue that protocols need to be _protected_
> from being dragged into such discussions.  

So you are arguing here that things actually do exist outside of their
context until they are used? And that things do not order reality or
shape their usage? In that case it might be interesting to have a look
at UI/UX studies and how they are working on increasing the
understanding of the relationship between technolog and the user and how
specific design stimulated or inhibits specific behavior.

Adams, Anne, and Martina Angela Sasse. 1999. “Users Are Not the Enemy.”
Commun. ACM 42 (12): 40–46. doi:10.1145/322796.322806.

Gonzalez, Teofilo, Jorge Díaz-Herrera, and Heikki Topi, eds. 2014.
“Sociotechnical Approaches to the Study of Information Systems.” In
Computing Handbook, Third Edition. Boca Raton, FL: CRC Press.
https://www.crcpress.com/Computing-Handbook-Third-Edition-Two-Volume-Set/Tucker-Gonzalez-Topi-Diaz-Herrera/p/book/9781439898444.

If you would like a more high level architecture and infrastructure
approach to this point, you could have a look at:

Star, Susan Leigh. 1999. “The Ethnography of Infrastructure.” American
Behavioral Scientist 43 (3): 377–91. doi:10.1177/00027649921955326.

Bowker, Geoffrey C., and Susan Leigh Star. 2000. Sorting Things Out:
Classification and Its Consequences. The MIT Press.

> So there is a faint hint of
> circularity in section 6's reasoning about why rights are important
> for protocols.  This may be because the section never really takes
> seriously the position that a tool need not itself have a value
> charge, and that the value comes entirely in its use.  It's true that
> this view of technology fell out of fashion at least after the second
> War and arguably earlier.  But it's a position entirely in keeping
> with the Aristotelian tradition.  Moreover, it is rather far from
> obvious to me that some of the citations in the section actually agree
> with the positions in whose support they are being cited.
> 

I am afraid you're right that your position is a position in line with
Aristotelian ethics as they were current before the Second World War.
But scienctific literature and opinion has quite significantly changed
since then, partially because of the use of technology in the Second
World War. Also Artistotelian ethics have moved on. A quick search finds
two articles that argue the exact opposite:

Aristotle on Technology and Nature, Schummer, Joachim, Philosophia
Naturalis, 38 (2001), pp. 105-120
http://www.joachimschummer.net/jslit/aristot.htm

Being human in a global age of technology, Whelton, Beverly J. B.,
Nursing Philosophy, January 2016, Vol.17(1), pp.28-35

In the latter there is also a description of Heidegger and the concept
of equipment/tool/technology and mediation (or rather immediation).

I might have missed some literature, if so, I am happy to read some
books or articles per your suggestion.

> This leads to a problem for the following recommendation:
> 
>         At this point
>    is difficult to say whether hard-coding human rights into protocols
>    is wise or feasible.  It is however important to make conscious and
>    explicit design decisions that take into account the human rights
>    protocol considerations guidelines developed above.  This will ensure
>    that the impact protocols can have on human rights is clear and
>    explicit, both for developers and for users.  In addition, it ensures
>    that the impact of specific protocol on human rights is carefully
>    considered and that concrete design decisions are documented in the
>    protocol.
> 
> Why is it important to make the design decisions this way?  Why is it
> important that the impact on human rights is clear and explicit?  If a
> protocol designer thinks the protocol's _use_ is what makes for the
> consequences for others' rights, what is the motivation for that
> individual to think about the rights-effects?  (Motivating this all in
> terms of the consequences for the network might be effective in this
> case.)
> 
> I hope these remarks are useful to the authors.

I really hope we can either put the tech-neutrality argument to bed, or
continue the discussion based on literature.

> 
> Best regards,
> 
> A
> 
> 
> [1] As an aside, there's an "intrinsic value" position: that the
> Internet inherently is a mechanism for expressing human rights in its
> very nature, and so only human rights values are Internet protocol
> values.  I don't think the draft proposes this, though I note that
> there are people who feel strongly that the Internet _should_ work
> this way.  That's a political problem for the IETF, perhaps, but it's
> not an issue for this draft.

Eventhough article 19 of the UDHR can be read as a description of the
Internet, we quite quickly get into problem if we look at the detailed
implications of that statement. It's not easy to bridge the legal and
the technical, but this is something we have been trying to do in this
draft.

> 
> [2] It's worth noting that the opening of this paragraph contains
> historical claims that are in really deep need of citations, because I've
> read almost nothing about the early Internet that suggests "everyone"
> could join, much less contribute code.  The DoD near-end-of-ARPANET
> project certainly didn't let "everyone" join.  The NSFnet AUP was
> _entirely_ clear that not "everyone" could join or contribute code,
> even if the AUP was honoured more in the breach.  The late-1990s and
> early-2000s open source literature has obscured the difficulty for
> mere mortals of connecting to the Internet in earlier periods.  I was
> a motivated-to-connect undergraduate in Ontario, Canada in the late
> 1980s/early 1990s, and the best I could do was a commercial dial-up
> system that provided a kind of gateway to parts of the Internet
> (undergraduates didn't rate connection to ONet in those days).
> 

I _really_ like this point. But I feel hesitant to go deeper into this,
because I would be tempted to go into histories of the Radiatation Lab,
FIDONET and ARPAnet. Some of this has been excellently described here:

Flichy, Patrice. 2007. The internet imaginaire. Cambridge, Mass.: MIT Press.

and

Turner, Fred. 2006. From Counterculture to Cyberculture: Stewart Brand,
the Whole Earth Network, and the Rise of Digital Utopianism. Chicago:
University of Chicago Press.

What if I simply change the text into this?:

The open nature of the initial technical design (open standards, open
source, etc) fostered freedom of communication as a core value, the aim
was to create a network which would enable everyone to connect and to
exchange data, information and code.

All the best,

Niels

PS New version with changes:

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Jan 2017 16:35:09 +0000

Hiya,

Comments on two of your responses below, other text
elided...

> wanted them to be. This can also be seen in the film 'Net of Rights'.

I don't find the above argument convincing and perhaps for
a reason that's useful to elucidate: we do not know that
the "wanted them to be" above applies. In my own case, I do
have some opinions that you (Niels) would likely call some
relevant ethics. In the IETF context however, I have not
found it necessary that we reach consensus on those. And I
am not at all sure we ought try - I can't see a useful
subset of my or what I imagine are others' ethical opinions
on which it'd be good for the IETF to have reached consensus,
and I really doubt that the IETF would find any such subset
on which it could reach consensus.

> actor. There is are ample examples of that in the book by Laura DeNardis:

I'm sorry but I (and I think others) do not agree with you on
this point, no matter how oft asserted, and even though that
literature does exist.

> is ethically neutral. 

That is not what I claimed. Some technology is not ethically neutral.
But I do assert that IETF technology some is ethically neutral.
You seem to be asserting that no technology can ever be ethically
neutral and I disagree with that.

> We've cited quite a body of literature that argues
> the exact opposite. 

No, you did not provide exact opposites above. Yes, there is a body
of literature that argues as you do. It's fine that we do not all
share the exact same opinions, but would be better if the draft did
reflect that divergence.

> Repeating that technology is neutral will not make

That was not repeated because it was not stated, by me at least
and nor I think by Andrew. *Some* technology is neutral was my
assertion.

Cheers,
S.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Jan 2017 11:55:03 -0500

Hi,

Some further follow up.

On Thu, Jan 05, 2017 at 05:05:11PM +0100, Niels ten Oever wrote:
> > [RFC1958]"

> connectivity' is pretty clear here:
[…]
>    rather than hidden in the network.

I think there is a difference between "connectivity" and "unfettered
connectivity to all users and for any content".  Indeed, I bet there
are countries today who think they have a goal of connectivity without
having the latter more expansive goal.

I think this puts the finger on what's bothering me, though: in my
reading the draft is too keen to take the most expansive,
rights-supporting reading of any text even when alternative readings
are available.  A more conservative approach to the literature would,
I think, actually make the draft's conclusions stronger.

>       economics, communication, and education, will help us to build a

This is a claim about what the community that makes up the IETF
believes, not what "the IETF" considered in itself believes.  There
may or may not be a difference between those two things.

>    technology that's possible, and much to do with the technology that

Nope, it shows my point.  The "we" there are choosing to make
_internetworking_ technology, and that technology might itself have an
inherent ethic.  The IETF participants could choose to create
technologies that run against internetworking (arguably, sometimes
they do.  One could make the argument -- I've heard people do it --
that MPLS is not terribly internetty).  

> that there is no adverse impact on human rights).

Perhaps (though I confess this distinction is not always quite so
plain to me in the text).  But I don't think that this alters the
point I was making, which is that the difference between extrinsic and
concordant values might be important.

> whereas the Internet is about humans, not about the Internet itself.

I don't think so.  The argument, for instance, about why pervasive
monitoring is an attack _on the network_ and not on the users works
the same way.  It says (in part) that the attack is on the network
because the pervasive monitoring undermines the utility of and faith
in the network, which thereby reduces the incentives to use it, which
reduces the positive-feedback network effects of the network.  That is
_apart from_ the social costs and the attack on human users and so on.

> global economy. The Internet does not simply exist for the Internets sake.

The trouble here is that, if _that_ is the basis of internetworking,
then there is a strong position available to sceptics of this draft.
It is that engineers ought to inform but not decide policy debates.
This is the classic technocratic position: that the technocrats advise
policy makers, but themselves never make such policy decisions.  Of
course, the draft is arguing that this position is wishful thinking,
because protocols are in fact politics anyway.  But unless you deal
with the technocratic point of view head on -- and it just rejects the
postwar position about the combination of protocols and politics --
then the draft will remain subjecto attack from that technocratic
point of view.  (More on this below.)

What you claim above is that the values are in fact all extrinsic.  If
that's true, then the debate over which rights and which
interpretation (China's?  The US's?  NL's or CA's?) of the UDHR ought
to count is something that happens outside the IETF.  It remains only
for protocol designers to take these values "into account" somehow.

If, on the other hand, there is a concordant value that flows from
internetworking values themselves, then protocol engineers have a
positive duty when writing Internet protocols to consider those
internetworking values and promote them when possible.  I claim (but
it'd be a hard problem to show, I suppose) that these are a concordant
set of values that have the interesting property of supporting a
particular vision of human rights also.

> need to make and the impact they might have.

It is possible that we are not in alignment about the nature of the
project.  The Internet is not merely about inter-connectivity of
nodes.  It is about inter-connectivity of networks with a particular
style of inter-connectivity in which the edges have most of the
intelligence, the individual networks interconnect without necessarily
having pre-existing contractual or other such arrangements among them,
and where messages flow from one part of the internetwork to another
without a lot of molestation from intermediate nodes.  That's quite a
lot more than inter-connectivity.  I agree that inter-connectivity
could, for instance, be achieved by the Catanet approach that a
certain IETF gadfly often promotes, and probably by something like the
old telephone networks suitably updated for packet switching.  But
those wouldn't be _internets_, even if they'd be interconnectivity.

> shape their usage?

Well, of course, that is (roughly) a metaphysical position that
basically ruled Western philosophy from at least Plato through
Descartes.  So it seems a little surprising to wave it away with a
couple rhetorical questions, especially because it undergirds the
strict separation of roles that is implied in the technocratic stance.

> World War.

If your argument is at bottom that the old position is wrong because
it's old, then I fear we are far apart.  I am not arguing that old
position is true.  I am arguing that it needs to be taken seriously,
and that the draft doesn't do so, and therefore the draft is weaker
than it needs to be.

> exchange data, information and code.

I am always leery of claims about the aim of actors in the past (and
ironically, I get even more leery when many of those actors are still
around, because I know my own motivations for what I did in the past
are now quite fuzzy to me, and I tell stories to myself about how I
got to this place where I am).  So I'd suggest this instead:

    The open nature of the initial technical design and its open
    standards, as well as developments like open source, fostered
    freedom of communication.  What emerged was a network of networks
    that could enable everyone to connect and to exchange data,
    information and code.  For many, enabling such conections became a
    core value.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 10:56:09 +0100

Hiya Stephen,

Thanks for this, reply inline:
> on which it could reach consensus.

Andrew made the point: we already have an ethics (namely an inherent
network ethic).

You seem to make the point here: we don't need an ethics, which is
different.

> this point, no matter how oft asserted, and even though that

But it would be great if you (and maybe others) provide arguments for it
except for repeating the point.

We wrote a draft, cited literature, offered more literature, we had
several discussions about this at sessions, also at the last one, so at
this point I am not sure what I can do to address this.

Could you perhaps provide an argument why you think protocols are not
political?

> neutral and I disagree with that.

All technology has the characteristic of ordering and re-ordering the
world we live in. It stimulates certain behavior, and it inhibits
others. In this way it influences our public and private sphere and thus
is political.

It does so in major ways, such as where it directly touches upon civil
liberties such as privacy and freedom of expression. But it also does so
in more subtle ways, via (lack of) availability in local languages,
centralized vs distributed solutions, and reliability and performance on
high latency networks vs low latency networks.

And of course even the possibility of making specific things possible.

This is all inherently political.

> share the exact same opinions, but would be better if the draft did

I think your argument diverges from the one Andrew makes. If you think
we should capture your line of argumentation in the draft, let's have a
discussion about it. What kind of protocols do you think are not political?

> and nor I think by Andrew. *Some* technology is neutral was my

OK - let's work it out!

Thanks again!

Cheers,

Niels

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Jan 2017 11:20:35 +0000

Hiya,

> Andrew made the point: we already have an ethics (namely an inherent

I think the "we" above is ambiguous and that that is part of
the reason we're still discussing this.

> You seem to make the point here: we don't need an ethics, which is

That was not my point.

I said I don't believe the IETF needs to reach consensus on a
thing called ethics. I further said that I doubt that the IETF
could, in practice, reach rough consensus on such a thing.

That does not mean that IETF participants do ot do not "need
an ethics." I said nothing about that, except for my own case
where I do kinda know.

> except for repeating the point.

We both seem to be accusing one another of simply repeating
arguments. That usually means we're not really reading the
other's arguments;-)

> Could you perhaps provide an argument why you think protocols are not

It is below but once more: I assert that some IETF technology
is political but some is not political.

Here's an example. [1] While there were a bunch of "corporate"
politics around DTN, (not human rights related, but down to who
wanted to promote which technology where and when) [1] was not
at all involved in that.

You seem to be asserting that even [1] is political. Please
explain to me how that is true for that RFC as I just don't see
that.

If you assert that [1] is political because everything in the
entire universe is political then that seems to me to mean that
there is no need for the "protocols are politics" statements in
the draft - one tautology less would surely improve things if
you are correct. (And one incorrect statement less certainly
would from my POV:-)

If you can't say why [1] is political, then it seems to me you
have to accept that not all IETF technology is political. (Unless
you are asserting that "all IETF technology is political even
though it is not possible to say why for some RFCs," which'd be
quite odd;-)

Cheers,
S.

[1] https://tools.ietf.org/html/rfc6256

---

From: Jeanette Hofmann <[email-masked]>
Date: Fri, 6 Jan 2017 13:43:47 +0100

Hi all,

I am not sure if it helps if another person gets involved but I give it 
a try.

I want to comment on two things, the question of ethics and the question 
of politics.

re: ethics

> could, in practice, reach rough consensus on such a thing.

This point can probably be generalised: There is nearly never consensus 
on ethics. No group ever agrees on more than single ethical statement. 
The IETF is no different in this respect from any other collective. 
Another question would be if the IETF as a group would find it helpful 
or desirable to regard its technical work within an ethical framework. 
This could be addressed in the draft document as an open issue requiring 
further debate.

Re political:

As a political scientist I'd like to remind you that there are many 
different understandings of 'the political'.

Political can refer to:
1.  how a standard (or any other object) is produced
2. how a standard is put to use
3. how it affects its environment
4. who selects or decides over a standard

There are probably more definitions around I am not aware of. From my 
understanding, the IETF used to distinguish technical from political 
design criteria. In other words, a choice becomes political when 
non-technical criteria play a role in or dominate protocol development. 
This definition would refer to 1 and perhaps 4.

While I was doing research on the IETF, I was always interested in how 
and where its participants draw the line between a technical and a 
political decision. An easy line to draw was that between the IETF 
(driven by technical criteria) and the ITU (organised around political 
motives). Yet, when it comes to contested design issues such as IPv6 
(which I studied at that time), the distinction between the technical 
and the political seems to blur. What is technical from one point of 
view, may appear political from another. I recall the length of IP 
addresses to be such a case in point.

It is certainly an important professional cornerstone to have a common 
understanding of the distinction between what is technical and what is 
political, this does not imply that outsiders would draw the line in the 
same way.

I do agree that to declare everything as political does not help in this 
context. Yet, I am not sure political/non-political is an inherent 
quality of a technical standard. It might be something that is rather 
ascribed to it, depending either on one's definition of the political or 
on one's position in the development work of the standard.

Best, Jeanette

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 14:08:03 +0100

Hi Andrew,

Happy new year!

Reply inline:

> that MPLS is not terribly internetty).  

I think this para refutes your interpretation:

   The Internet: A large, heterogeneous collection of interconnected
      systems that can be used for communication of many different types
      between any interested parties connected to it.  The term includes
      both the "core Internet" (ISP networks) and "edge Internet"
      (corporate and private networks, often connected via firewalls,
      NAT boxes, application layer gateways and similar devices).  The
      Internet is a truly global network, reaching into just about every
      country in the world.
      The IETF community wants the Internet to succeed because we
      believe that the existence of the Internet, and its influence on
      economics, communication, and education, will help us to build a
      better human society.

In the first paragraph the technical aspect is explained (from which you
could potentially derive a networking ethic), but the second parapgraph
clearly explains a (primitive) external ethic.

So If you then continue to explain that this quote:

We embrace technical concepts such as
   decentralized control, edge-user empowerment and sharing of
   resources, because those concepts resonate with the core values of
   the IETF community.  These concepts have little to do with the
   technology that's possible, and much to do with the technology that
   we choose to create.

means that these concepts are derived from an inherent inter-networking
ethics, I am afraid I have to disagree. Because there is also an
inter-networking solution possible without edge-user empowerment. I also
do not think that the 'values' that are referred to here are
'internetworking values'.

So here you might be guilty of the overenthusiastic hermeneutics you
accused me of earlier ;)

> _apart from_ the social costs and the attack on human users and so on.

Could you also make the argument in relation to 'Internationalization?'
Why would the network care about human parsable languages?

The proposed 'network ethic' might provide a solution for some things,
but not sufficient. Also, it leaves quite a lot of space for
interpretation. What some people think is good for the network, might
not be seen the same by others.

Also: in your argument you now include 'faith in the network' as part of
the 'inherent network ethic', which is I think a bit of a leap, because
earlier you seemed to argue that you wanted to leave usage out of the
equation. It's starting to become a bit blurry for me here, but maybe
that's because I do not sufficiently understand your concept of a
'network ethic'.

> policy makers, but themselves never make such policy decisions. 

You seem to use the term 'technocrats' here as in 'bureaucrats'. Are you
describing IETF-ers here as technocrats that take orders from policy
makers? I think that kind of goes against 'no kings, no presidents', right?

If you look at the discussion between ISO and IETF on the next
generation of IP after IPv4 I think this is also not a correct
representation.

> Of

Yes - that is exactly what 'respecting human rights' means! Fully agree!

We do not need to (re-)negogiate rights here, we should simply think
through what they mean for our field and find procedures to take them
into account.

> particular vision of human rights also.

Am happy to dig deeper into this, but then we would need a more detailed
description of 'internetworking values', and I have thusfar not been
able to find a write up of that.

I think try to understand a 'networking ethic' or any ethic that has
been prevalent in IETF has been what we've been trying to do, but at a
certain moment we got stuck because there were so many different
intepretations. I think dkg summarized it pretty well in saying: "I am
sure there are shared values in the IETF, I also think that we do not
have consensus on what these shared values are".

These guidelines are a beginning to think about that, without
reinventing the wheel, and thus looking at existing standards that are
as universal as they get: human rights.

If your position is that there is such a think as a networking ethic
that has driven the work here for many years, I can write a para about
that. Maybe I can offer rewriting the second paragraph of the Literature
and Discussion Review:

Commercial and political influences on the management of the Internet's
infrastructure are well-documented in the academic literature and will
thus not be discussed here {{Benkler}}  {{Brownetal}}  {{Denardis15}}
{{Lessig}}  {{Mueller}}  {{Zittrain}}. It is sufficient to say that the
IETF community consistently tries to push back against the
standardization of surveillance and certain other issues that negatively
influence end-users' experience of and trust in the Internet
{{Denardis14}}. The IETF thusfar has formally relied on an ethics that
is based on an understanding that the network is its own objective, and
the internetworking between networks is the expected result. There have
been hints of values that lie beyond the network itself {{RFC1958}}
{{RFC3426}}, but these have thusfar not been documented in a detailed
manner or resulted in concrete procedures for protocol design, except
perhaps for Guidelines of Privacy Considerations {{RFC6973}} and work on
Internationalization. The role human rights play in engineering,
infrastructure maintenance and protocol design is much less clear.

What do you think?

I am myself not completely sure of this because the

> those wouldn't be _internets_, even if they'd be interconnectivity.

I hope the description above covers this.

> Descartes.  

So you really think it would add to this draft to describe pre-Kantian
epistemology and subject-object relations here? We're talking
intelectual history far before Internet Protocols or the Internet at
large, so am not sure if it's relevant. If there were modern literature
that is making this case in relation to the Internet I'd be more than
happy to discuss, and then I also think we should. I just have not been
able to find it.

> So it seems a little surprising to wave it away with a

I am simply not sure whether there still is such a thing as a
technocratic stance in contemporary Internet and technology related
literature.

> and that the draft doesn't do so, and therefore the draft is weaker

I hope my text above helps to address that.

>     information and code.  For many, enabling such conections became a

Excellent - added!

Cheers,

Niels

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 14:49:36 +0100

Hi Jeanette,

> This could be addressed in the draft document as an open issue requiring

+1 that is what we aim to do here (in my understanding).

> on one's position in the development work of the standard.

Thanks for this! Let's try to bring the discussion back to the draft. I
think the paragraph people have issues with is this one:

Protocols and standards are regularly seen as merely performing
technical functions. However, these protocols and standards do not exist
outside of their technical context nor outside of their political,
historical, economic, legal or cultural context. This is best
exemplified by the way in which protocols have become part and parcel of
political processes and public policies: one only has to look at the
IANA transition, the RFC on pervasive monitoring or global innovation
policy for concrete examples {{Denardis15}}. To quote {{Abbate}}:
"protocols are politics by other means". This statement confers that
protocols are based on decision making, most often by humans. In this
process the values and ideas about the role that a particular technology
should  perform in society is embedded into the design. Often these
design decisions are part pure-technical, and part inspired by certain
world view of how technology should function that is inspired by
personal and political views. Since the late 1990's a burgeoning group
of academics and practitioners researched questions surrounding the
societal impact of protocols, and the politics of protocols. These
studies vary in focus and scope: some focus on specific standards
{{Davidsonetal}} {{Musiani}}, others look into the political, legal,
commercial or social impact of protocols {{BrownMarsden}} {{Lessig}},
{{Mueller}} and yet others look at how the engineers' personal set of
values get translated into technology {{Abbate}},{{CathFloridi}}
{{Denardis15}}

I think this passes the test set by Jeanette, no? I think it would help
if we concretely look at text instances that are problematic within this
frame instead of continuing a more abstract discussion. I hope that helps.

Best,

Niels

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

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 14:53:55 +0100

Hiya,

> the reason we're still discussing this.

I think the 'network ethic' part is more ambiguous, no? I think the
target group, or rather the 'we', are protocol developers in the IETF.

> an ethics." I said nothing about that, except for my own case

I agree we do not need consensus on a full set of ethics (we probably
never will), discussing an ethical framework, guidelines, and a way to
document choices might be useful though, no?

> though it is not possible to say why for some RFCs," which'd be

I am tempted to respond, but.... in the draft there is no sentence that
says 'protocols are political'. Shall we go back to the text of the
draft and see what issues there are in there? I think it's concentrated
in this para:

{{Denardis15}} {{WynsbergheMoura}}.

Is your main problem with the quote: "protocols are politics by other
means" ?

Best,

Niels

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Jan 2017 09:20:51 -0500

On Fri, Jan 06, 2017 at 02:08:03PM +0100, Niels ten Oever wrote:
> could potentially derive a networking ethic)

Sure.

> , but the second parapgraph clearly explains a (primitive) external
> ethic.

Yes.  Note that it is a claim about "the IETF community" and not "the
IETF".  It has never been plain to me why BCP 95 makes that
distinction, but it appears to.  It's also a claim about beliefs.  But
none of this shows that IETF participants are not choosing what they
think of as "Internet technologies" as opposed to other ones.  The
point is merely that the story I've told is _consistent_ with the
outcome you appear to want.

> ethics, I am afraid I have to disagree.

I don't believe I said that; I certainly didn't intend to.  My point
is rather that the humans doing the work might have some extrinsic
value in mind, but the ethic of the network conveniently aligns with
those extrinsic values.  So, _even if_ a particular IETF participant
doesn't agree with some part of BCP 95, by virtue of working on
Internet technologies they might still be contributing to the same
extrinsic goal.

> Because there is also an
> inter-networking solution possible without edge-user empowerment.

Really?  How?  I think this is tied to your response to my remark
about internetworking as opposed to other kinds of networking.

Perhaps I can put this differently: I think that "the Internet" is a
mass noun that denotes an emergent property, rather like "the traffic
on the Don Valley Parkway" does.  There is no _thing_, "the traffic",
that you can change.  All you can do is change constituent parts by
affecting individuals' behaviour, and so similarly with the Internet.
But unlike "the traffic", which is governed by a single set of rules
that control the road system, "the Internet" is designed so that each
participant can work out the rules between them on their own, just by
using some intercommunication primitives that are predefined.  (One
might say that the Internet is not like driving on the Don Valley, and
is more like driving in Mumbai.)

This is also different from some other kinds of cases.  For instance,
"the flow of water through the pipes in my house" is similar in that
there is no particular chunk of water that one is directing.  Yet any
given flow (as long as the system doesn't have leaks and so on) is
actually entirely under the control of my household, so it's a
centrally-run system.  And in a municipal water system, each
individual connection is via a well-regulated two-way interface
between exactly two parties.  This is very different from
internetworking, even though it's a kind of network.
 
> Why would the network care about human parsable languages?

It doesn't at the protocol layer.  But it does at layers where network
identifiers or other protocol elements are exposed to users, precisely
because a larger body of users (which we can derive trivially from
"people with different writing systems than unaccented Latin in the
ASCII range of Unicode") increases the potential network effects.

> What some people think is good for the network, might

This seems no objection to me at all: what some people think is good
for human rights might not be seen the same by others, or the US, most
EU countries, and China would not have disagreements over the nature
and acceptability of capital punishment (just to pick a totally
non-controversial example ;-) )

> that's because I do not sufficiently understand your concept of a

The notion of the network ethic -- and I cheerfully concede that I
have not worked this out fully, since I gave up on my philosophy
dissertation nearly 20 years ago and now only get to play in the
junior leagues in my spare time -- is that one takes the stance of the
network qua network, and consider what is good for it.  What is good
for the Internet is more internetworking, which means more networking
of other networks.  In a networking ethic, any case that causes an
increase in that internetworking is good, and any case which
reinforces increasing internetworking is a virtuous circle.  Faith in
the network by humans causes increased use, which causes larger
network effects, which causes increased use, and so on; so it is a
virtuous circle.  Therefore, faith in the network by human users is
network-ethic good (even if it is, say, bad from the point of view of
a government that wants to control the communications paths from the
country).

> makers? I think that kind of goes against 'no kings, no presidents', right?

One view of what the IETF does is that it produces clean technical
specifications that are divorced from the policy questions in which
those specifications might be used.  Under this view, the rejection of
kings and presidents is a rejection _for the purposes of the IETF_: we
reject the idea that those with controls over the voting mechanisms or
procedural machinery get to have special influence over which
specifications get published or the contents of those specifications.
(It is not to say that there do not exist kings or presidents.  IETF
participants are sometimes accused of being unworldy, but I don't
think it extends quite that far.)

If we take that view seriously, then it follows that the IETF can
produce the best technical specification to solve a given technical
problem, and it can advise the world of that specification.  But it
cannot adjudicate whether such a specification should be adopted as a
matter of policy.  That is outside the IETF purview.  This approach to
breaking up techno-political problems -- technical people offering
"the right answer to a problem" and policy-makers stating the problem
and deciding whether it is to be solved -- is what I call the
technocratic stance.  I don't think it is unusual to the IETF, and
arguably the entire history of (for instance) urban planning is
dressed up in this same story.  Whether it is a _true_ story is, I
think, debatable.  I think you are arguing that it is _not_ true.  I
might agree with that, but what I keep trying to argue is that the
draft under discussion could be agnostic on its truth and still
produce considerations that any protocol designer could embrace.  It
could also adopt the stance that one _could_ believe the technocratic
stance is wrong, in which case one could use the considerations in the
draft.  Instead, the draft tries to argue that the stance is wrong,
but it mostly makes such arguments by appeal to authority --
authorities that anyone who embraces the technocratic stance will not
accept.  So the draft is less effective than it might be in achieving
its purpose.

> that has driven the work here for many years

No, that is certainly not my position.

> the internetworking between networks is the expected result.

I don't think the IETF has ever formally relied on any ethics, BCP 95
notwithstanding.  

> epistemology and subject-object relations here?

No, but I hope this message makes clearer what I'm suggesting instead.
If not, perhaps this is evidence of Kuhn's view about paradigms.

As I've said, this is a RG document and I have no objection to the RG
proceeding to publication.  If this were an attempt to create an IETF
document that wanted to govern IETF procedure, I'd be very strongly
opposed to going ahead, but as a RG document I am not.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

On Fri, Jan 06, 2017 at 09:20:51AM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 194 lines which said:

> for human rights might not be seen the same by others, or the US,
> most EU countries, and China would not have disagreements over the
> nature and acceptability of capital punishment (just to pick a
> totally non-controversial example ;-) )

It seems to me that, as far as human rights are mentioned, we decided
to use the UN declaration
<https://en.wikipedia.org/wiki/Universal_Declaration_of_Human_Rights>
as the basis.  Not that it is pefect (no human work is, and the
Wikipedia article does a good job of listing various criticisms
against it) but it is probably the best thing we can all agree on.

And, to handle this specific case, the UNDHR does not mention the
death penalty. (IMHO, it should, but this is off-topic for this RG.)

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Jan 2017 09:38:59 -0500

> death penalty. (IMHO, it should, but this is off-topic for this RG.)

I think the controversy is over whether Section 3 of the UDHR means
that capital punishment is an abrogation of a right, which is why I
thought the analogy apt for the objection Neils raised.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Jan 2017 14:54:26 +0000

Hiya,

On 06/01/17 13:53, Niels ten Oever wrote:
> I am tempted to respond, 

I think it'd be useful to know if you agree or not though.
Do you personally think [1] is political? From the mails
so far, I am under the impression that you do think [1] is
political. I do not.

> but.... in the draft there is no sentence that

Yes. Some suggested changes below...

> exemplified by the way in which protocols have become part and parcel of

s/which protocol/which some (but not all) Internet processes
and protocols/

> IANA transition, 

The IANA transition is all process, zero protocol. (Hence adding
processes above.)

> the RFC on pervasive monitoring or global innovation
> policy for concrete examples {{Denardis15}}. 

> To quote {{Abbate}}:

S/To quote/According to/

> personal and political views. 

s/personal and political/personal, corporate and political/

The reality is that corporate beats out political most of the time.

> Since the late 1990's a burgeoning group

I'd also add:

'
Within the community of IETF participants there is a fairly
clear desire to as far as possible restrict IETF activities
to those that are as purely technical and as little political,
as is possible. Many of those participants would not accept
the proposition that "protocols are politics by other means."
'

> Is your main problem with the quote: "protocols are politics by other

Yes, and that the draft text seems to agree with that statement with
no qualifications.

S.

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 16:57:42 +0100

Hiya,

>   [1] https://tools.ietf.org/html/rfc6256

Delay Tolerant Networking can be very relevant for human rights,
especially in areas with low connectivity.
As you know, Delay Tolant Networking is now also used a lot for IoT
devices, so if this technology would enable something such as an
emergency response device for human rights defenders, I think it could
be very useful as well.
One could also think of deployments similar to Outernet
(https://outernet.is/) which would improve the Right to Education.

If this RFC makes de deployment of DTN easier, and thus positively
contributes to  these things, I indeed think it is political.

> s/which protocol/which some (but not all) Internet processes

Accepted - but if you don't mind I leave out '(but not all)', because
that is the meaning of 'some'.
> The IANA transition is all process, zero protocol. (Hence adding

Accepted.
>> policy for concrete examples {{Denardis15}}. 

Accepted

> s/personal and political/personal, corporate and political/

Accepted

> the proposition that "protocols are politics by other means."

Thanks for this suggestion. I thought we could maybe rewrite it like this:

Within the community of IETF participants there is a strong desire to
solve technical problems and minimize the engagement with political
problems.

But then I thought: would people working on privacy agree with this? I
think for a lot of them this actually _is_ a political issue (same for
people active in GAIA, etc). So maybe something like:

Within the community of IETF participants there is a strong desire to
solve technical problems and minimize its engagement with political
processes and non-protocol related political issues.

Might need some fine-tuning, but curious to hear what you think.

> Yes, and that the draft text seems to agree with that statement with

Hope we addressed that now :)

Cheers,

Niels

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Jan 2017 16:22:57 +0000

Hiya,

Progress! Great:-)

> contributes to  these things, I indeed think it is political.

I fully disagree. We don't need to argue about it though so just
for the record: my reasoning is that yes aspects of DTN deployment
are political in the sense you describe, and yes aspects of DTN
protocol design were political in the corporate sense (I could go
into details, but they're still irritating to some folks so I
won't:-), but this particular aspect (use of SNDV as a way to
represent numbers) is just not political in any sense. Therefore
that RFC is apolitical too. I'd also assert that there are many
other aspects of DTN technology that are similarly purely technical
and apolitical. To offer a contrast though - whether or not to
include a checksum in bundles is something that could have been
purely technical but ended up being political (in the corporate
sense) due to the players involved. So it could have been the
case that SDNVs and this RFC were political, but the facts are
otherwise in that case. (And just to be clear: when I say
"corporate politics" I would include e.g. academic politics and
as was relevant in the case of DTN, non-technical disagreements
that happen inside even just one not-for-profit organisaton;-)

If an analogy might help: voting in elections is political,
but whether I walk or cycle to the polling station is not, in
itself, political. (It could be if I were a cycling advocate,
but in my case, my mode of transport to the polling station
is not a political act.)

Again - I'm happy to chat about the above, as it's interesting
where different folks draw the lines, but we definitely don't
need to resolve that discussion to be done with this draft. So
if someone does want to chat about that maybe best to start a
new thread.

> that is the meaning of 'some'.

Sure. Though I prefer the emphasis:-)

> solve technical problems and minimize its engagement with political

nearly-non-nit: s/its// many of us also want to minimise their
engagement with us:-)

> Might need some fine-tuning, but curious to hear what you think.

That'd be fine if you also include this bit, which I think is
important:

'
  Many of those participants would not accept
  the proposition that "protocols are politics by other means."
'

It seems fairly clear that very different opinions on that quote
have been expressed on the RG list and that that didn't resolve
into us all agreeing with the quote.

Cheers,
S.

---

From: Jeanette Hofmann <[email-masked]>
Date: Fri, 6 Jan 2017 17:25:51 +0100

Am 06.01.17 um 15:37 schrieb Eliot Lear:
> Jeanette,
>
> On 1/6/17 1:43 PM, Jeanette Hofmann wrote:
>
> That's a really interesting aspect.  From my own memory, the example you
> give is a good one in several dimensions.  One aspect of the decision
> was whether or not the IETF would itself have control of the results.

The change control issue was probably regarded as political by nearly 
everyone involved in the debate about IPNG.

> If we chose TUBA, which based itself on ITU-T's X.233 standard, it was
> far from clear whether who would have change control.  Separately there
> was a question of address lengths.  At the time there were at least two
> factions, one who believed that performance required a fixed address
> size, and another who felt that we should never again put ourselves in
> the position of having to do another transition.

As you describe it, one could say that technical and non-technical 
concerns both played a role: performance (technical) and avoiding future 
transitions (non-technical).

  Those factions split
> largely along endpoint versus router lines.  I wouldn't call that purely
> technical either.  Endpoint developers wanted to spend their precious
> cycles doing things other than parsing IP packets, whereas that is where
> the bread and butter is for routing people.

Now, this is surely a non-technical interpretation of what was going on.
>
> (...)
>>
>> I do agree that to declare everything as political does not help in
>> this context. Yet, I am not sure political/non-political is an
>> inherent quality of a technical standard. It might be something that
>> is rather ascribed to it, depending either on one's definition of the
>> political or on one's position in the development work of the standard.
>
> Say more about this?

As you say above, the debates about address length were not purely 
technical. But some IETF people at that time discussed and regarded them 
as technical issues. So, it is perhaps more in the eye of the beholder 
or a matter of interpretation whether an issue is technical or political.

jeanette
> Eliot

---

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

Hi Stephen,

> if someone does want to chat about that maybe best to start a

I propose we discuss this in person, maybe even during a hrpc RG
session. I don't think this discussion is relevant now for the draft.

Accepted.

> into us all agreeing with the quote.

Hmmmmm. We did not poll IETF-ers about this so this would be
guestimating. We're not saying IETF-ers agree with this either, right?

Cheers,

Niels

---

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

Hiya,

On 06/01/17 17:13, Niels ten Oever wrote:
> Hmmmmm. We did not poll IETF-ers about this 

Well, not counting heads is what we do:-)

> so this would be

I agree that saying "many" could be arguable, though I think it's
the case from my experience with IETFers. If you really feel a
need to water this down (or Avri as consensus-caller on this one
does), I could live with the weasely worded:

'
  Note that a number of HRPC participants do not accept
  the proposition that "protocols are politics by other
  means" - whether or not that means there would be
  an IETF consensus for or against that proposition
  is unclear, the question not having been asked.
'

But to be clear: I prefer the non weasel word version.

Cheers,
S.

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 18:27:43 +0100

Hiya,
> But to be clear: I prefer the non weasel word version.

What about this, I think it's a bit more elegant and says the same and
ensure we don't have repetition:

According to {{Abbate}}: "protocols are politics by other means". This
statement would probably not get IETF consensus, but it nonetheless
confers that protocols are based on decision making, most often by
humans. In this process the values and ideas about the role that a
particular technology should  perform in society is embedded into the
design. Often these design decisions are part pure-technical, and part
inspired by certain world view of how technology should function that is
inspired by personal, corporate and political views. Within the
community of IETF participants there is a strong desire to solve
technical problems and minimize engagement with political processes and
non-protocol related poltical issues.

Cheers,

Niels

---

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

I could live with that, thanks. One tweak suggested below.

Cheers,
S.

> statement would probably not get IETF consensus, but it nonetheless

s/get/garner/

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 18:39:08 +0100

Hi Andrew,

> ASCII range of Unicode") increases the potential network effects.

I think we had this discussion in several times, mostly informed by the
presentation by Ramsey on his Arabic programming language. This resulted
in this text in the draft:

   In the current IETF policy [RFC2277], internationalization is aimed
   at user-facing strings, not protocol elements, such as the verbs used
   by some text-based protocols.  (Do note that some strings are both
   content and protocol elements, such as the identifiers.)  If the
   Internet wants to be a global network of networks, the protocols
   should work with other languages than English and other character
   sets than latin characters.  It is therefore crucial that at least
   the content carried by the protocol can be in any script, and that
   all scripts are treated equally.

> non-controversial example ;-) )

Not everyone needs to agree on interpretations or implement in the exact
same way, but having a standard helps a lot to compare against. This is
why there are Universal Periodic Reviews of all countries. No country
has a perfect score sheet where it comes to human rights.

> network qua network, and consider what is good for it.  

I still have some problems with this because the network is not a force
of nature, right? It came into being, based on certain ideas, and is
also still evolving. So I find it hard to pinpoint and ethics to it, and
I think that is exactly the problem, right?

> What is good
> of other networks. 

For the arguments sake: Could one not say it would be best for the
network if we not focus on the expansion of the network but improving
the quality of the network? I think this is something that could be
argued based on your networking ethics, no? Or is more always better?

> In a networking ethic, any case that causes an

So it's a numbers game? More is better? More networks, more hosts, more
packets transported, or more users?

What should we do in case we could add more users if we would add more
opportunities for censorship. How would a networking ethic help us make
a decision in such a case?

> technocratic stance. 

This is hardly the case, right? It's not like standards go to government
approval after they have been approved by the IESG.

> I don't think it is unusual to the IETF, and

Wait, so you're _proposing_ a network ethic. I thought you were making
the argument that currently there _exists_ something as a network ethic.

> I don't think the IETF has ever formally relied on any ethics, BCP 95

OK - won't add then.

> If not, perhaps this is evidence of Kuhn's view about paradigms.

Would this draft then be an anomaly? Let's get the scientific revolution
started ;)

> opposed to going ahead, but as a RG document I am not.

Clear. Thanks!

Niels

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 18:42:18 +0100

>> statement would probably not get IETF consensus, but it nonetheless

Accepted!

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Jan 2017 13:33:32 -0500

> session. I don't think this discussion is relevant now for the draft.

I don't see how not.  The claim in the draft that is causing the
controversy is that protocols are politics by other means, that all
protocol design decisions are necessarily political, and so on.  If
consenus is desired, that's the topic that needs to get sorted out.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 Jan 2017 19:35:09 +0100

> consenus is desired, that's the topic that needs to get sorted out.

AFAIK we have addressed all text in the draft that might have insinuated
that. If not, am happy to address the text with which you have issues.

Best,

Niels

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Jan 2017 13:41:58 -0500

> consenus is desired, that's the topic that needs to get sorted out.

Of course, this is essentially an observation about the world, not a decision about what to do.   If it were to _not_ gain consensus, it would be because someone said something that demonstrated that it was not true.   We could have consensus not to actually admit to this truth, but it's hard to deny the truth of it, particularly looking at the giant footprint we've placed on the face of recent history with our protocols.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 7 Jan 2017 16:19:26 +0100

On 1/6/17 7:41 PM, Ted Lemon wrote:
> On Jan 6, 2017, at 1:33 PM, Andrew Sullivan <[email-masked]
> <mailto:[email-masked]>> wrote:
> Of course, this is essentially an observation about the world, not a
> decision about what to do.   If it were to _not_ gain consensus, it
> would be because someone said something that demonstrated that it was
> not true.   We could have consensus not to actually admit to this
> truth, but it's hard to deny the truth of it, particularly looking at
> the giant footprint we've placed on the face of recent history with
> our protocols.
>
>

It is demonstrably not true that ALL protocol decisions are political. 
We don't encode passwords in the clear, for instance, because the
probability of them being stolen approaches 1 over time.  Whether the
draft actually says that, quite frankly, is hard for me to determine. 
Also, it is enough to debate that some protocol decisions are inherently
political.  And as Jeanette Hoffman wrote, it is sometimes tricky to
tease out which is which.

This leads me to a point: I wonder if there is room for more than one
work in this space in this research group.  Just teasing out political
from technical seems like a good piece of work on its own.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sat, 7 Jan 2017 16:42:51 +0100

Neils,

Just on this point:

> approval after they have been approved by the IESG.

Color me confused (again).

There are two interpretations of what you wrote above- that Andrew's
observation is false-

 1. because governments do not have approval of standards, or
 2. because policy makers are free to ignore whatever approach the IETF
    puts forth.

Certainly the latter premise is true, but it is not clear to me that is
what you meant nor that it invalidates Andrew's point about the division
of labor (rather it restates it).

Eliot

---

From: avri doria <[email-masked]>
Date: Sat, 7 Jan 2017 11:09:23 -0500

On 07-Jan-17 10:19, Eliot Lear wrote:
> work in this space in this research group.

certainly.

avri

---

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

> of labor (rather it restates it).

It is the second. But policy makers don't really have a say about what
protocols are being used. Maybe there could be a theoretical case, or in
the narrow cases of crypto exports control, but external government
intervention in Internet protocols (outside of NSA + crypto) is hardly a
thing we encounter regularly, right? Or am I wrong to assume this?

Best,

Niels

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Jan 2017 12:59:03 -0500

On Jan 7, 2017, at 10:19 AM, Eliot Lear <[email-masked]> wrote:
> We don't encode passwords in the clear, for instance, because the probability of them being stolen approaches 1 over time.  Whether the draft actually says that, quite frankly, is hard for me to determine.

Well, actually, this general question was a matter of public debate just a few months ago.   Supposedly serious people came out on the side of not encrypting the password.   Of course, they claimed (and perhaps believed) that that wasn't really what they were saying, but that was really what they were saying.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 9 Jan 2017 09:05:00 -0800

On 1/7/17 9:59 AM, Ted Lemon wrote:
> On Jan 7, 2017, at 10:19 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
> Well, actually, this general question was a matter of public debate
> just a few months ago.   Supposedly serious people came out on the
> side of not encrypting the password.   Of course, they claimed (and
> perhaps believed) that that wasn't really what they were saying, but
> that was really what they were saying.
>

I don't think this really changes the point.  We don't encode passwords
in the clear for *technical* reasons rather than political ones.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jan 2017 12:09:17 -0500

On Jan 9, 2017, at 12:05 PM, Eliot Lear <[email-masked]> wrote:
> I don't think this really changes the point.  We don't encode passwords in the clear for technical reasons rather than political ones.

That's correct: our decision is not motivated by a political goal.   Nevertheless, our position on encoding passwords is an obstacle to a political goal.   Hence, our position is political.   The fact that we don't see it that way doesn't make it not true.   That's the point being made in the document.   It may feel repugnant that a technical issue could also be political, but nevertheless that is the reality.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Jan 2017 18:22:09 -0500

On Mon, Jan 09, 2017 at 12:09:17PM -0500, Ted Lemon wrote:

> Nevertheless, our position on encoding passwords is an obstacle to
> a political goal.  Hence, our position is political.  The fact that
> we don't see it that way doesn't make it not true.  That's the point
> being made in the document.  It may feel repugnant that a technical
> issue could also be political, but nevertheless that is the reality.

I think this rides right over a distinction that is important, and
that I think _is_ sometimes made in the draft.  Some things are
constraints on the political without themselves being political,
unless one casts the term "political" very widely.

The value of π, for instance, despite once having been the obstacle to
someone's political goal, is not itself a political thing.  The
emissions of carbon and contamination of water as a result of
extraction of bituminous sands in Canada are not political things,
even though those raw facts are used in various political discussions
and stand in the way of some people's preferred policy outcome.  

Now, if one adopts certain views about the nature of truth, one
_might_ decide that these are political anyway.  So, some say,
since only propositions are true and since all propositions are in
language and since all languages happen in a socio-linguistic context,
then all truth is socio-linguistically bound.  And if one adopts
certain views about the nature of socio-linguistic situations, then
all such socio-linguistic interactions are inherently political.
There is a thread starting roughly with Wittgenstein leading through
Rorty that can be read this way.  There is almost certainly a
reasonable reading of Derrida that sounds like this.  There is an
extremely reasonable reading of Michel Foucault along these lines.  And
some people think that the social constructivist interpration of
science (so, say, Bruno Latour and Andrew Pickering and _maybe_ Donna
Haraway) says this too.

However much I believe those views, it is very far from obvious to me
that such an interpretation of "facts" or "truth" would be widely
shared around the IETF.  If one is going to rely on such a view then I
think it's going to need a fairly serious airing of the arguments in
favour of it.  The draft has been altered, I think, to get away from
this problem a little bit, so I think this is less of a problem for
the draft as it stands now.  But I don't want to allow the conflation
of these two issues to stand anyway.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Roland Bless <[email-masked]>
Date: Tue, 10 Jan 2017 01:35:13 +0100

Hi Avri and all,

On 04.12.2016 at 20:54 avri doria wrote:
> Please send all comment to the HRPC email list: [email-masked].  I do
> hope that some good discussions occur on this list where the
> resolution to any issues may be forged. Discussion has been shown to
> improve this draft.

Unfortunately, I didn't manage the full review write-up after returning
from holidays today. Nevertheless, I have some general comments and try
to provide more detailed comments later today.

Overall, I think the draft is good to raise awareness for
the issue that sometimes technical decisions may impact human rights.
However, it falls a bit short on the problem that even human rights
get in conflict with each other and that conflict resolution is
hard to decide on, or is maybe not possible or desirable to built
into a technical system (because it's too rigid then).
For example, considering anonymity and authenticity at the same time is
not easy (cf. the APIP design
http://dl.acm.org/citation.cfm?id=2626306). Sometimes it may be better
to refrain from
embedding technical solutions (i.e., specification and
operationalization) and think of institutionalization, i.e.,
considering solutions based on policy/governance or choice and markets.
Technical support for such solutions can sometimes be beneficial (e.g.,
providing transparency solutions). More details here:
http://dl.acm.org/citation.cfm?doid=2935634.2935640
or slides for the impatient:
http://conferences.sigcomm.org/sigcomm/2016/files/program/sigcomm/SessionCCR-Paper02-Values-Carsten-Slides.pdf

There are some inaccuracies with the vocabulary section and I have
several comments for section 4. I'll come back to that later in more detail.

Best regards,
 Roland

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 10 Jan 2017 11:22:17 +0100

Hi Roland,

Thanks for this. Reply inline:

Niels ten Oever
Head of Digital

Article 19
www.article19.org

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

On 01/10/2017 01:35 AM, Roland Bless wrote:
> hard to decide on,

This section aims to address that:

   Human rights can be in conflict with each other, such as the right to
   freedom of expression and the right to privacy.  In such as case the
   different affected rights need to be balanced.  In order to do this
   it is crucial that the rights impacts are clearly documented in order
   to mitigate the potential harm in a proportional way.  Making that
   process tangible and practical for protocol developers is what this
   research aims to ultimately contribute to.  Technology can never be
   fully equated with a human right.  Whereas a specific technology
   might be strong enabler of a specific human right, it might have an
   adverse impact on another human right.  In this case decisions on
   design and deployment need to take this into account.

You think this is inadequeate? If so, would you have text suggestions?

 or is maybe not possible or desirable to built
> into a technical system (because it's too rigid then).

This sections aims to address this:

ur position is that hard-coding human rights into
   protocols is complicated and changes with the context.  At this point

You think this is inadequeate? If so, would you have text suggestions?

> http://conferences.sigcomm.org/sigcomm/2016/files/program/sigcomm/SessionCCR-Paper02-Values-Carsten-Slides.pdf

Do you think this is a sufficient representation of your positions?

   Bless and Orwat [Bless] represent a fourth position.  They argue that
   it is too early to make any definitive claims, but that there is a
   need for more careful analysis of the impact of protocol design
   choices on human rights.  They also argue that it is important to
   search for solutions that 'create awareness in the technical
   community about impact of design choices on social values.  And work
   towards a methodology for co-design of technical and institutional
   systems.'

I'd me more than happy to have a bit more elaborate description.

> several comments for section 4. I'll come back to that later in more detail.

Looking forward!

Thanks,

Niels

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 10 Jan 2017 16:41:47 +0100

Hi,

> several comments for section 4. I'll come back to that later in more detail.

Here we go...
Since other work prevented me to follow the hrpc list closely in the
last weeks, I apologize for repeating some comments that others already
made.

Abstract:
---------
IMHO the abstract should not start with a "list of sections" it
provides. It should rather start with the main issue of providing
considerations on human rights in protocols (or protocol design),
comprising proposals for consideration guidelines, vocabulary,
and a description of the methodology as well as a coarse literature review.

Introduction:
-------------
I find it a bit confusing to directly start with citations without
setting the context first, so probably move the citations somewhere
into the text, where they fit.

In a broader sense, protocols touch also other values, not only
human rights. So probably, a short motivation should be given, why
this draft/RG concentrates on human rights.

While the draft talks a lot about human rights, it doesn't list
a few of them as examples (e.g., at least those used later in section
4). Therefore, I propose to extend the vocabulary and also define
"human rights" there (it's ok to list some of them and repeat the
references for further details...).

Typo: "This has led to an broad" -> "This has led to a broad"

"The purpose of the Internet to be a global network of networks that
provides unfettered connectivity to all users and for any content
[RFC1958]." -> I couldn't find this statement in RFC 1958.
(general comment: please be more accurate when you cite documents, this
also applies to several other places, esp. in the vocabulary, see below).
RFC 1958 talks about connectivity as a goal of the Internet
architecture, but doesn't mention "unfettered connectivity to all users
and for any content".

"Additionally, access to information gives people access to knowledge..."
-> probably qualify this by using "generally accessible information"
or "freely available information" (some information on the Internet
isn't freely accessible or available for all on purpose).

"In order to do this it is crucial that the rights impacts are clearly
documented in order to mitigate the potential harm in a proportional
way." -> I find this statement problematic.
Sometimes the impacts are complicated since several rights
may be affected at once. Moreover, how to actually balance between
conflicts isn't clear at all sometimes.
So I don't know what "mitigate the potential harm in a _proportional
way_" actually means nor how to achieve it...

Vocabulary:
-----------
"Authenticity" -> while other security terms are taken from RFC 4949,
this one isn't (any other reference for this particular definition?).
Usually Authenticity includes data integrity as defined
in RFC4949 (just stating that it is strongly linked with integrity
is IMHO a bit too weak).

Censorship isn't defined but used in the definition of Censorship
resistance.

Confidentiality: the definition isn't correct (unintended ->
unauthorized) and also isn't taken literally from RFC 4949 although
referenced... better replace it with the definition from RFC4949.

End-to-End:
- Typo "principal -> principle"
- This definition here mixes "end-to-end transparency" issues with
  the "end-to-end argument in systems design" (the Saltzer, Reed, Clark
  paper). I think it is indeed
  clearer to separate the two (see also
https://tools.ietf.org/html/rfc2775 and
https://tools.ietf.org/html/rfc4924).

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 10 Jan 2017 16:44:33 +0100

Hi,

I'm very sorry, I accidentally hit the send button too early, so please
ignore this version, a more complete one will follow... :-]

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 12 Jan 2017 01:14:41 +0100

Hi,

> several comments for section 4. I'll come back to that later in more
detail.

This write-up took much longer than expected...
Since other work prevented me to follow the hrpc list closely in the
last weeks, I apologize for repeating some comments that others already
made.

tl;dr:
Major issue from my perspective:
the rationale why certain technical concepts or properties impact
particular human rights is often missing. In many cases it remains
unclear how/why certain human rights are listed in figure 2 and
section 4 while others aren't. This really needs to be fixed IMHO.

Detailed comments:

Abstract:
---------

Introduction:
-------------

While the draft talks a lot about human rights, it doesn't list
a few of them as examples (e.g., at least those used later in section
4). Therefore, I propose to extend the vocabulary and also define
"human rights" there (it's probably enough to list some of them and
repeat the references for further details...).

Vocabulary:
-----------

End-to-End:
- Typo "principal -> principle"
- This definition here mixes "end-to-end transparency" issues with
  the "end-to-end argument in systems design" (the Saltzer, Reed, Clark
  paper). I think it is indeed
  clearer to separate the two (see also
https://tools.ietf.org/html/rfc2775 and
https://tools.ietf.org/html/rfc4924).
  IMHO the statement "Functionality should be expanded at the end-points to
  ensure that the network interconnects rather than controls."
  is somewhat confusing and doesn't reflect the end-to-end argument:
  Application-specific functions should not be embedded into the
  network and thus stay at the end-points: in many cases, esp.
  when dealing with failures, the right decisions can only
  be made with the corresponding application-specific knowledge,
  which is available there. So the quoted statement is too general
  (just speaks of functionality), the meaning of "expand" is unclear
  and some control functions (e.g., routing) are even necessary for
  providing the interconnection between networks. Consequences
  of the end-to-end argument are robustness and (easier) innovation
  at the edges.

- I don't understand the point of the following text
  "For example, end-to-end instant message encryption would conceal
  communications from one user's instant messaging application..."
  in this context. From the Internet layer perspective encryption
  between an instant messaging client and an intermediate server
  using TLS is end-to-end. From the application layer
  perspective, it is not really end-to-end (user-to-user) encrypted.
  Moreover, in many cases only content can be protected end-to-end
  while some meta-data (mostly in form of protocol headers) need to
  be processed by intermediate nodes.

Integrity: the used definition references RFC 4949 again, but isn't
  taken from there. Please use the one from 4949:
  data integrity:
  "The property that data has not been changed, destroyed, or
   lost in an unauthorized or accidental manner."

Internet censorship: while correctly cited from [Elahi],
the definition is somewhat imprecise, since there is
definitely information available in the Internet at
some servers that is access controlled etc. for good reasons,
e.g., in order to prevent its unauthorized disclosure. That
confidential information is also in many cases relevant
for decision making. According to the definition this
"protected confidential information" is censored. The fix is
probably as follows:
 "Internet censorship is the intentional suppression of otherwise
 freely accessible information originating, flowing or stored on
 systems connected to the Internet where that information is
 relevant for decision making to some entity." (based on [Elahi]).

Interoperable: I don't understand what "without any restricted access or
functionality." means here. Restricted access to what?
Moreover, I think that "interoperable" is more a property of
_implementations_ rather than the protocol specification:
usually one checks whether two independent implementations
(originating from the same protocol specification) interoperate with
each other.

"Open Standards Conform": though I'm not a native speaker, I think
it should be "Open Standards Conforming" or "Conforming to Open
Standards". The reference RFC2606 is incorrect, it should be RFC2026?

Openness: not so clear what is meant here. Unrestricted access to
freely accessible hosts or content, i.e., the absence of Internet
censorship? How is it different from accessibility?

Reliable -> Reliability

Scalable -> Scalability
Scalability is usually defined with respect to certain specific
system parameters (e.g., number of end-systems, users, data flows,
routing entries. etc.). Moreover, growth/shrinkage of these
parameters is typically considered by orders of magnitude.

Connectivity:
- This term needs to be sorted into the right order...
- typo enableing -> enabling (several occurrences in the draft).
- I'm not sure, but I think that the distributed/decentralized
  nature of the Internet is also important for connectivity
  (providing alternative choices of access and routes).

Methodology:
-------------
analysis.The results.... => analysis. The results....

3.2.1.1. Mapping protocols and standards related to human rights

Not sure, but either delete "related" or rephrase as "Relating protocols
and standards to human rights".

   "By combining data from the three data sources named above, an
   extensive list of protocols and standards that potentially enable the
   Internet as a tool for freedom of expression and association."

That sentence is missing a verb, e.g., "an extensive list .... was
created" (or rephrase accordingly to avoid passive voice...).

3.2.1.2. Extracting concepts from mapped RFCs

"mapped RFCs" sounds IMHO a bit odd, maybe replace with "selected RFCs".

   Mapping the protocols and standards that are related to human rights
   and create a human rights enabeling environment was the first step.

Suggestion:

  Identifying the protocols and standards that are related to human
  rights and create a human rights enabling environment was the first
  step.

3.2.1.3.
   While interviewing experts, mapping RFCs and ...

=> While interviewing experts, investigating RFCs and ...

3.2.1.4.
   The previous steps allowed for the clarification of relation between
=>
   The previous steps allowed for the clarification of relations between

This section and the following use many different terms, probably for
the same item: technical definition(s), technical concept(s), technical
term(s) and figure 1 finally uses "architectural principles".

   "allowing for the creation of a list
   of technical concepts that when combined create an enabling"
=>
   "allowing for the creation of a list
   of technical concepts that, when combined, create an enabling"

It is unclear whether one needs to combine _all_ of the technical
concepts or only some of them. Moreover, do we have a "proof" that
this is really the case? The text in 3.2.2 suggests that we probably
have merely hints for the mappings rather than actual evidences or
a very deep understanding of the exact relations between the
technical concepts and human rights.
So I suggest to weaken the statement a bit:
"allowing for the creation of a list of technical concepts that, when
partially combined, _can_ create an enabling"
the same applies to 3.2.1.5. and its title, which is basically a repetition.

figure 1:
it appears to me as if some of the terms are more (system)
properties (the figure mentions characteristics) rather than principles.
We may have/know principles that lead to the mentioned
properties if applied during design, deployment or operation.
Examples:
- Simplicity. Applying minimality principles (KISS or also
the end-to-end argument) may result in simpler systems that eventually
lead to higher robustness (rfc3439 discusses this in more depth).
- Resilience. Every principle that increases robustness may lead
  to higher resilience, e.g., fate-sharing/statelessness,
  end-to-end principle, soft-states, Postel principle, decentralized
  design, etc.

Transparency -> this is missing in the vocabulary. Since transparency
is actually used in very different meanings (transparent=verifiable,
traceable, comprehensible and sometimes even invisible) a clarification
would be good.

Heterogeneity -> Heterogeneity support

figure 2:
- the left column lists not only technical concepts but also (desired)
properties.
- the rationale why the specific rights are impacted by the technical
  concepts or properties are the most interesting part and actually
  missing in the description. It would be very valuable to provide a
  paragraph for each row in section 3.2.2 that explains why there is
  a relation between the concepts/properties and the particular rights.
  For example for the first row: "Connectivity is required, because
  the individual that wants to provide information for others needs
  means to reach potential recipients. Privacy is helpful in case ..."
  Section 4 seems to partially contain some of the reasoning, however,
  I think that it would be better to move it here.

- typo in caption: excise -> exercise

3.2.3.
   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.
=> The goal here is to
   show, with actual examples, that the design of protocols have
   practical consequences for some human rights and these consequences
   should be considered at the design time already.

"have to be" is IMHO too strong.

   network core can make policy decisions and enforce policy shaping and

I'm not sure what meant here by "policy shaping", but probably
policy-based traffic shaping is meant as recently described in
http://dl.acm.org/citation.cfm?id=2934873 (freely accessible via
http://conferences.sigcomm.org/sigcomm/2016/program.php). Thus,
probably rephrase as:
=> network core can make policy decisions and enforce policy-based
traffic shaping and

Typos:

   helping us understand which technical protocol decisions have led to
harm of this human
=> helping us to understand which technical protocol decisions have led
to harm of these human

3.2.3.1.1.
APIP (http://dl.acm.org/citation.cfm?id=2626306) and Hornet
(http://dl.acm.org/citation.cfm?id=2813628) could be mentioned as
alternative designs.

Typo:
to choose a per defined
=>
to choose a pre-defined

3.2.3.1.2.
[RFC1631] is obsoleted by RFC 3022

I skipped most of the rest of section 3...

Section 4
---------
The sub-structure 4.1 -> 4.1.1 doesn't make so much sense since there is
no 4.2 or
4.1.2 etc.

4.1:
Typos:
   This sections details
=>
   This section details

   or proritize some
=>
   or prioritize some

   analysis that can serve as the basis for discussion on whether the
   protocol adequately protects against specific human rights threats.

maybe add text that it may stimulate authors to think about alternative
designs choices..

The following sections also do not always contain a rationale
why certain listed human rights are potentially affected adversely.

4.1.1.1.1 Connectivity

I'm really not convinced that the end-to-end argument directly
relates to connectivity rather than to permissionless innovation,
resilience and robustness...

the example of end-to-end encryption would be more suitable for
Privacy and doesn't cover the problem of nevertheless visibile metadata.

For connectivity I would also expect the
right to access to be listed as potentially impacted
(without proper connectivity, certain freely available
information cannot be accessed).

4.1.1.1.3.
Typo: priotization => prioritization

4.1.1.1.4.
=> What about a right to security?

4.1.1.1.5.
   -  Right to political participation

is listed twice

4.1.1.1.7.  Open Standards

Typo:
The Internet was able to developed
=>
The Internet was able to be developed

4.1.1.1.8.

Typos:
   to allow open innovation possibly have security and privacy
   ramifications, and if so,how can these be dealt with?
=>
   allow open innovation possibly have security and privacy
   ramifications, and if so, how can these be dealt with?

I don't understand how this related to the "right to security"
while I'm missing the
right to access or participation

4.1.1.1.9

   to achieve, it is non-binary concept.  Making pervasive monitoring
=>
   to achieve, it is a non-binary concept.  Making pervasive monitoring

4.1.1.1.10
   generates or processes anything that can be, or be tightly correlated
=>
   generate or process anything that can be, or be tightly correlated

4.1.1.1.11
  "Could your protocol also be developed in a stateless manner?"

I don't understand how this would improve accessibility...

4.1.1.1.12
the difference to internationalization is not that clear to me...

4.1.1.1.13
I'm missing the Right to access (a decentralized architecture allows
probably more points of access to the network).

4.1.1.1.14
This could make use of statelessness and soft-states as technical principles

Why is only the right to security listed here? Right to access would
also fit here...

4.1.1.1.15

what about the right to privacy?

4.1.1.1.16

   Question(s): Does your protocol maintain and assure the accuracy of
   data?  Does your protocol maintain and assure the consistency of
   data?  Does your protocol in any way allow for the data to be
   (intentionally or unintentionally) altered?

I think these are flawed (cf. also my criticism on the definition
in the vocabulary). Especially, "Does your protocol in any way allow for
the data to be
(intentionally or unintentionally) altered?" doesn't make much sense to me.
I suppose that the question consideres alteration while data is in transit.
Which data is meant here? Protocol control information, i.e. headers,
usually needs to be altered in transit, whereas payload data probably
shouldn't be modified. Normally, protocols cannot really
"prevent" that data is modified in transit, but they can have measures
to detect
any unauthorized modification.

This impacts also the right to freedom of expression since
censoring measure can lead to unauthorized modification of
data.

4.1.1.1.17.

Impacts several other rights, e.g., right to privacy, right to freedom
of expression etc. because in some cases that origin can be clearly
identified which discloses information sources.

4.1.1.1.18.
Adaptability is closely interrelated permissionless
=>
Adaptability is closely interrelated to permissionless

----
so much for now...

Regards,
 Roland

---

From: avri doria <[email-masked]>
Date: Thu, 12 Jan 2017 12:00:20 -0500

Hi,

As Jan 9 has come and gone the last call is ended. 

I am still digesting the responses, but from my first reading, do
believe we got significant and substantive comment.

I know of at least one review, from one of the IETF General Area
reviewers, that is still being worked on and would like to be able to
accept it as part of the Last Call comments, assuming it shows up  in
the next few days.  Are they any other pending reviews in progress?

thanks

avri

On 04-Dec-16 14:54, avri doria wrote:
> Hi,
>
> With this note, I am starting a Research Group call on the draft
>
> https://tools.ietf.org/html/draft-irtf-hrpc-research-07
>
>
>   Research into Human Rights Protocol Considerations
>
>
> While RFC 5743 "Definition of an Internet Research Task Force (IRTF) Document Stream" does not mandate a Last Call or any specific action to prove that a document has the correct maturity and review for publication, it is safe to think of this call as similar to a first IETF last call.  If substantive changes to the document are produced based on the reviews we get, there will probably be another call on a later revision of the draft. If, or when, there are no substantive changes made we will be able to move on to IRSG Review of the draft.  If we don't get a wide enough review, we will need to figure out what to do next.
>
> Given that I am hoping to use this call as a way to get a larger audience to review that draft, and the fact that we are coming into one of the global holiday times, I will leave this call open until 9 Jan 2017.
>
> Please send all comment to the HRPC email list: [email-masked].  I do hope that some good discussions occur on this list where the resolution to any issues may be forged. Discussion has been shown to improve this draft.
>
> Happy reviewing
>
> Avri Doria
>
> BTW, I copied the IRSG list on this hoping to get wider review group.
>
>
>
>

---

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

On Thu, Jan 12, 2017 at 01:14:41AM +0100,
 Bless, Roland (TM) <[email-masked]> wrote 
 a message of 462 lines which said:

> In many cases it remains unclear how/why certain human rights are
> listed in figure 2 and section 4 while others aren't. This really
> needs to be fixed IMHO.

There is a good reason to not treat all human rights alike. Some are
already well-covered in IETF work (such as privacy in RFC 6973). I
think we should focus on rights which have not been, until recently,
explicitely discussed in the IETF (such as freedom of expression).

> define "human rights" there

I think it is not up to the IETF/IRTF to define human rights and we
should defer to an external definition (the draft currently uses the
UDHR, which I think is a good idea). May be a sentence in the
terminology section like "Human rights: the rights of every human
being, as defined in the Universal Declaration of Human Rights [Ref]"?

> [RFC1958]." -> I couldn't find this statement in RFC 1958.

I suggest to follow the classical rule: when it is between quotes, it
is a litteral statement. Otherwise, it can be a summary or a
synthesis.

Here, there are in the draft no quotes around the sentence you
mention, meaning clearly that it was not supposed to be an exact
citation.

> Usually Authenticity includes data integrity as defined in RFC4949
> (just stating that it is strongly linked with integrity is IMHO a
> bit too weak).

Agreed. Authenticity without integrity is almost useless.

> The fix is

No. If a system deletes my *private* messages (content which was not
"freely accessible information"), it is still censorship.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Jan 2017 23:00:28 +0100

On Fri, Jan 06, 2017 at 11:20:35AM +0000,
 Stephen Farrell <[email-masked]> wrote 
 a message of 274 lines which said:

> If you assert that [1] is political because everything in the entire
> universe is political then that seems to me to mean that there is no
> need for the "protocols are politics" statements in the draft - one
> tautology less would surely improve things if you are correct.

I tend to have a pragmatic vision here. We can discuss for a long time
between "Everything is political" and "Nothing in the RFC is
political" but the current state at the IETF is that, IMHO, most
protocol authors and RFC authors _underestimate_ the political
consequences of their choices. So, it is a good idea to err on the
side of "there are more things political than you think".

There is may be a risk that some people will take the "protocols are
politics by other means" too seriously and will find political
consequences in the fact that the source IP address is before the
destination IP address, but such a risk is probably very low, and it
won't be a practical problem in the IETF.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jan 2017 22:41:27 +0000

Hiya,

> side of "there are more things political than you think".

I tend to agree with what you say and would also be ok with
a statement like that being in the draft.

> won't be a practical problem in the IETF.

I don't think that'd be the problem but rather that if we
embraced that (IMO plain incorrect) statement we'd risk
ending up damaging our concept that good technical argument
is what wins. While the IETF is nowhere near perfect in
that regard, it seems to me far less imperfect than most
other similar bodies and we ought be careful to not damage
that.

Cheers,
S.

PS: All that said, I remain ok with what I think was the
last version of the text Niels posted to the list.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Jan 2017 17:50:54 -0500

Hi,

On Fri, Jan 13, 2017 at 11:00:28PM +0100, Stephane Bortzmeyer wrote:
> consequences of their choices.

I agree with that.

> So, it is a good idea to err on the

Also that.

> won't be a practical problem in the IETF.

The above is almost certainly the crux of where we disagree, and maybe
why I'm a little grouchy about this.

Having just spent at least the last two years playing Junior
Achievement Internet Politician, I can report that there is an entire
world of people who seem genuinely to believe that this is all just
politics, and that what is really needed is for some grownup
politicians to come along and tell the IETF how it should make
protocols.  Those are people who think that a single root in a
hierachical namespace is a mere political decision, rather than a fact
of math.  Those are people who think that, with the application of
enough political oversight, key escrow is a perfectly good idea for
the world rather than a giant security vulnerability waiting to be
exploited.  And those are people who think that internetwork-style
connectivity as opposed to a dramatically more centralized style is
_simply_ a political question, rather than one that has technical
follow-on consequences with their own technical implications.

There is a limnable difference between "technical decision that has
consequences for politics" and "simply a political question".  I think
we need to be careful about that, both for political reasons (what it
might drag us into) and technical reasons (what it might make possible
or impossible).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jan 2017 23:03:14 +0000

Hiya,

> why I'm a little grouchy about this.

I agree with what Andrew says below, but am less grouchy having
managed to avoid almost all of that particular nonsense;-)

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Jan 2017 18:58:33 -0500

> mention, meaning clearly that it was not supposed to be an exact

I think I also noted, however, that the interpretation offered was
considerably broader than the text in 1958 would justify if the latter
were read strictly.  This has not been fixed in the latest version I
checked in github.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: [email-masked]
Date: Sat, 14 Jan 2017 16:44:50 -0500

> > [RFC1958]." -> I couldn't find this statement in RFC 1958.

It's interesting how the definition of "internet" (even discounting
big "I" vs little "i") has evolved over the years.

Early on it was mostly used to describe a network which used different
media in a reasonably transparent way. Today that might be wi-fi and
ethernet.

35+ years ago media tended to define a network if for no other reason
than the media or its usage within a network was usually proprietary.

Not much later the idea that it could tie together networks with
otherwise incompatible protocols such as NCP, DECNET, UUCP, SNA,
BITNET, Netware, CHAOSnet, etc became very popular much like the
concurrent idea that higher-level programming languages could produce
code for very different architectures, and even operating systems
(Unix-like) became largely architecture-independent.

So the "internet" largely focused on either gatways which for example
moved email or other services between these otherwise incompatible
networks, or the beginnings of what we'd call today virtual networks
which could carry otherwise incompatible protocols typically for
long-distance haul (e.g., UUCP over TCP/IP.)

As media compatability became taken for granted and most of the other
network protocols faded into obscurity the concept began to move to a
more political and administrative meaning -- that the internet tied
together separately administered but technically mostly identical
networks.

[THE POINT]

So one can quote a platitude such as the above but what the words
actually were intended to mean tends to be embedded in either its own
ancient or some current historical context.

-- 
        -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: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 16 Jan 2017 10:03:25 +0100

Hi Stephane,

> explicitely discussed in the IETF (such as freedom of expression).

Agreed, but this wasn't my point. I think that some human rights
aren't listed which should be there, I gave hints for section 4
with respect to that. However, since the rationale is missing,
it's unclear why some are there, but others which hare related
IMHO aren't listed.

> being, as defined in the Universal Declaration of Human Rights [Ref]"?

Yes, that was what I meant, since there are several definitions out
there and it's unclear which ones are used within the draft. It should
also include a list of HRs which are considered within the draft. That
would make it clearer to read the draft without checking the original
definitions.

> is a litteral statement. Otherwise, it can be a summary or a

Yep, but in this case it's neither literally nor as synthesis contained.

> mention, meaning clearly that it was not supposed to be an exact

Yes, but I tried to explain that I wasn't able to extract this statement
- even as summary - out of RFC 1958 and that's IMHO really
misleading. Otherwise, I'd really like to see a more specific pointer
to the content where that statement was derived from...

> "freely accessible information"), it is still censorship.

Yes, that's probably correct, so my proposal to fix it doesn't seem to
work :-)
However, I'm not sure that a firewall that is used to protect business
secrets is really "Internet censorship" and that was my point of the
more general statement.

Regards,
 Roland

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 17 Jan 2017 14:30:19 +0100

Thanks a lot for the extensive review Roland, reply inline:

> section 4 while others aren't. This really needs to be fixed IMHO.

That is pretty clearly addressed and outlined in section 3.2.2, right?

> and a description of the methodology as well as a coarse literature review.

I think this is a good suggestion, so I cut the first sentence into two
and changed the order of thing. The abstract reads now:

This document aims to propose guidelines for human rights
considerations, similar to the work done on the guidelines for privacy
considerations {{RFC6973}}. This is achieved by providing a proposal for
a vocabulary to discuss the relation between human rights and Internet
protocols, an overview of the discussion in technical and academic
literature and communities, a proposal for the mapping of the relation
between human rights and technical concepts, as well as guidelines.

If you want to see how to apply this work to your own, you can directly
go to <xref
target="model-for-developing-human-rights-protocol-considerations" />.
The rest of the document explains the background of the guidelines and
how they were developed.

> Introduction:

I think it's a good habit to have a quote at the beginning to set the tone.

> this draft/RG concentrates on human rights.

That's what the first paragraph of the introduction does imho.

> repeat the references for further details...).

I drafted this:

Human rights
: Human rights are principles and norms that are indivisible,
interrelated, unalienable, universal, and mutually reinforcing that have
been codified in national and international bodies of law. The Universal
Declaration of Human Rights {{UDHR}} is the most well-known document in
the history of human rights. The apirations from this documents were
later codified into treaties such as the {{ICCPR}} and the {{ICESCR}},
after which signatory countries were obliged to reflect them in their
national bodies of law. There is also a broad recognition that not only
states have an obligations vis a vis human rights, but non-state actors
do so as well.

> Typo: "This has led to an broad" -> "This has led to a broad"

Thanks - added

> architecture, but doesn't mention "unfettered connectivity to all users

Stephane already responded to this, it is not a literal quote but a synposis

> isn't freely accessible or available for all on purpose).

Thanks added.

> way_" actually means nor how to achieve it...

I think this is addressed in section 4.1.1:

Note that the guidance provided in this section does not recommend
specific practices. The range of protocols developed in the IETF is too
broad to make recommendations about particular uses of data or how human
rights might be balanced against other design goals.  However, by
carefully considering the answers to the following questions, document
authors should be able to produce a comprehensive analysis that can
serve as the basis for discussion on whether the protocol adequately
protects against specific human rights threats. This guidance is meant
to help the thought process of a human rights analysis; it does not
provide specific directions for how to write a human rights protocol
considerations section (following the example set in {{RFC6973}}), and
the addition of a human rights protocol considerations section has also
not yet been proposed.

> Vocabulary:

Thanks for this. I used the definition from RFC 4949.

About merging with integrity, not sure. Alissa in her review just
stimulated us to address them seperately.

> referenced... better replace it with the definition from RFC4949.

Done, thanks.

>   be processed by intermediate nodes.

Changed the typo. Used your suggested language (application-specific
functions... application specific knowledge) in the introduction. For
the second half, clarified that we are referring to the end-to-end
argument as laid out in saltzer et. al. and mentioned that further
aspects of end-to-end connectivity can be found in RFC 2775.

Changed text became:

One of the key architectural guidelines of the Internet is the
end-to-end principle. The argument in favor of the end-to-end approach
to system design is laid out in the fundamental paper by Saltzer, Reed,
and Clark {{Saltzer}} {{Clark}}. In it, the authors argue in favor of
radical simplification:  systems designers should only build the
essential and shared functions into the network, as most functions can
only be implemented at network end points. Building features into the
network for the benefit of certain applications, will come at the
expense of others. As such, as a general system designers should attempt
to steer clear of building anything into the network that is not a bare
necessity for its functioning. Following the end-to-end principle is
crucial for innovation, as it makes innovation at the edges possible
without having to make changes to the network, and the robustness of the
network.

>    lost in an unauthorized or accidental manner."

Thanks - replaced.

>  relevant for decision making to some entity." (based on [Elahi]).

Thanks - added.

> (originating from the same protocol specification) interoperate with

Fair point. Changed into:

Interoperable

: A property of a documented standard or protocol which allows different
independent implementations to work with each other without any
restriction on functionality.

> Standards". The reference RFC2606 is incorrect, it should be RFC2026?

Thanks, made it:

Conform with {{RFC2026}} .....

> censorship? How is it different from accessibility?

Removed the first definition and left the second from Brown.

> Reliable -> Reliability

Changed.

> parameters is typically considered by orders of magnitude.

Made it:

Scalability

: The ability to handle increased or decreased system parameters (e.g.,
number of end-systems, users, data flows, routing entries. etc.)
predictably within defined expectations. There should be a clear
definition of its scope and applicability. The limits of a systems
scalability should be defined. Growth or shrinkage of these parameters
is typically considered by orders of magnitude.

> - typo enableing -> enabling (several occurrences in the draft).

Fixed

>   (providing alternative choices of access and routes).

Added.

> Methodology:

Fixed.

> and standards to human rights".

Fixed.

> created" (or rephrase accordingly to avoid passive voice...).

Thanks
>   rights and create a human rights enabling environment was the first

Accepted and added

> => While interviewing experts, investigating RFCs and ...

Accepted and added

>    The previous steps allowed for the clarification of relations between

Accepted and added

>    of technical concepts that, when combined, create an enabling"

Accepted and added with amendment.

> concepts or only some of them. 

I made the text into this:

On the basis of this list a number of technical concepts that appeared
frequently was extracted, and used to create a second list of technical
terms that, when combined and applied in different circumstances, create
an enabling environment for excercising human rights on the Internet.

They need to be applied in different ways, in different cases. There is
no homogeneous implementation regime in all protocols and
implementations. It is a case by case basis, based on universal principles.

> Moreover, do we have a "proof" that

Accepted and changed.

> properties (the figure mentions characteristics) rather than principles.

Changed.

> traceable, comprehensible and sometimes even invisible) a clarification

I started writing on a lemma for transparency and pretty soon indeed got
in quite some trouble. As you clearly indicated transparency can mean
quite a few different things, often also the exact opposite:

https://en.wikipedia.org/wiki/Transparency_%28human%E2%80%93computer_interaction%29

So instead of writing three paragraphs about all possible definitions of
transparency I'd like to offer this:

Transparency
: In this context transparency is linked to the comprehensibility of a
protocol in relation to the choices it makes for both user and protocol
developers and implementers.

> Heterogeneity -> Heterogeneity support

Changed

> - the left column lists not only technical concepts but also (desired)

Which (desired) property in the left column is not a technical concept?

>   I think that it would be better to move it here.

whereas I agree it would be interesting to do this, I think it would
also easily add twenty pages to the draft, which I think would not
necessarily add much to the usability and readability of the draft.
Furthermore, we will need to do more research to create a more
exhaustive list. So I will defintely put this on the to do list of the
group. We are actually exactly trying this with the new Anonymity draft.

> - typo in caption: excise -> exercise

Changed

>    should be considered at the design time already.

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 in the design phase.

> "have to be" is IMHO too strong.

Why? What is the difference here with should? This is an informational
document so RFC2119 does not apply.

> => network core can make policy decisions and enforce policy-based

Changed.

> => helping us to understand which technical protocol decisions have led

Fixed

Added.

> to choose a pre-defined

Fixed

Fixed

> The sub-structure 4.1 -> 4.1.1 doesn't make so much sense since there is

Fixed (markdown issue).

>    This section details

Fixed

>    or prioritize some

Fixed
> maybe add text that it may stimulate authors to think about alternative

Added.

> Privacy and doesn't cover the problem of nevertheless visibile metadata.

Added explanation as to how end-to-end, in particular robustness relates
to human rights. Removed the example related to end-to-end encryption,
substituted it with an example of middle boxes and connectivity.

> information cannot be accessed).

What do you mean with the right to access? The right to political
particpipation or the right to freedom of expression (which includes the
freedom to receive and impart information)? I guess the latter, which I
added.

Fixed

Added

Fixed

> The Internet was able to be developed

Fixed

Agreed, removed and added.

>    to achieve, it is a non-binary concept.  Making pervasive monitoring

Fixed.

Fixed

In case of high latency and low connection speeds a connection might be
more reliable without state.

Localization is the pratice, internationalization is the technical
pre-condition to do so;

     "Internationalization is the design and development of a
     product, application or document content that enables easy
     localization for target audiences that vary in culture, region,
     or language."  {{W3Ci18nDef}}

Right to Freedom of Expression added.

Right to freedom of expression added

Yes, of course. Added.

> shouldn't be modified. 

Added /s/data/payload data

> Normally, protocols cannot really

/s/maintain and assure/"maintain, assure and/or verify"

> censoring measure can lead to unauthorized modification of

Agreed, added.

Agreed, added.

Changed into: Adaptability is closely interrelated with permissionless
innovation,

> so much for now...

Thanks again for this very thorough review.

Cheers,

Niels and Corinne

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 19 Jan 2017 10:10:40 +0100

Hi Niels,

sorry for the late reply, please see comments inline.

> You think this is inadequeate? If so, would you have text suggestions?

No, that paragraph is really fine (except for that "proportional way"),
my point was that the rest of the document has more a tone of "translate
this human right to a technical concept and make sure that
this concept is used in order to enable the human right." and seems
to suggest enforcing or enabling human rights by building certain
mechanisms into protocols. This is different from trying to achieve
awareness for impacts on human rights. So maybe it is easy to fix by
rephrasing certain passages in the text, e.g.,
"List technical terms that combined create enabling environment
for human rights", "Translating human rights to technical terms",
"on whether the protocol adequately protects against specific human
rights threats." (maybe the protocol doesn't need a built-in
protection, but operational aspects need to be regulated, e.g.,
namespace assignment etc.).

> You think this is inadequeate? If so, would you have text suggestions?

That is basically fine, but as pointed out above the rest of the draft
reads more like suggesting to built-in HR enabling mechanisms or at
least to support those.

It think that this statement here:
>    This will ensure
>    explicit, both for developers and for users.

is a little bit too strong. Even if one has read the document the impact
isn't always _clear_ and explicit. So IMHO the aim is to show that there
_is_ an impact that one should consider, however, in some cases it may
remain quite unclear how strong the impact is etc.

> I'd me more than happy to have a bit more elaborate description.

I'll check with Carsten and propose a text.

Regards,
 Roland

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 19 Jan 2017 17:51:08 +0100

Hi Roland,

Reply inline:
> No, that paragraph is really fine (except for that "proportional way"),

removed 'proportional way'

> for human rights"

This we already changed into:

#### List technical terms that when partially combined can create an
enabling environment for human rights

, "Translating human rights to technical terms",

Would this work:

### Relating human rights to technical concepts

> namespace assignment etc.).

Would this work:

However, by carefully considering the answers to the following
questions, document authors should be able to produce a comprehensive
analysis that can serve as the basis for discussion on whether the
protocol adequately takes specific human rights threats into account

> remain quite unclear how strong the impact is etc.

Would this work:

This will contribute to the understanding of the impact protocols can
have on human rights, both for developers and for users.

> I'll check with Carsten and propose a text.

Thanks!

All changes can also be found here:

https://github.com/nllz/IRTF-HRPC/commit/0b35d70468b202a83bd0d2b22f17b85bdf7b859c

Cheers,

Niels