[hrpc] Fwd: Continuing discussion and questions on Corinne's thesis - A Case Study of Coding Rights

[Corinne Cath <[e-mail]>]

​Under the heading: better late than never. ​


---------- Forwarded message ----------
From: Corinne Cath <[e-mail]>
Date: Mon, Dec 14, 2015 at 2:23 PM
Subject: Re: [hrpc] Continuing discussion and questions on Corinne's thesis
- A Case Study of Coding Rights
To: Niels ten Oever <[e-mail]>


Dear all,

Apologies for the delay in answering. I gave my replies in text. I hope
this covers some of the questions raised by Niels. Please reach out if
anything is unclear.

Best,

Corinne

On Fri, Dec 4, 2015 at 5:47 PM, Niels ten Oever <[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> We had to cut off the questions and discussion on Corinne's thesis - A
> Case Study of Coding Rights [0] in Yokohama. I wanted to create one
> more opportunity to discuss the thesis. Mostly because I think the
> thesis is a great piece of work and very constructive overview of
> different issues we're working on and because it could also lead us
> forward. Also because I still have a few questions left. Of course
> other peoples questions and comments are also very much encouraged.
>
> 1.
> You define 'openness' as 'the absence of centralised points of
> control' (p17). Do you think this is the mainly used definition of
> openness? Or are there others? If this is the main one, should we
> perhaps add it to the glossary? Openess is currently defined in the
> glossary as:
>  The quality of the unfiltered Internet that allows for free
>       access to other hosts
> Which is quite a different definition. Could you please elaborate on
> your rationale / choice for this definitions
>
>

> I do not think that is the main definition of openness. I think openness
means different things looking at different layers of the Internet, or
perhaps even within different discussions on Internet related issues. I
think openness in the net neutrality discussions takes on a different
meaning than in the encryption discussions. There are thus many definitions
of ‘openness’. The advantage of this is that it allows for a tailored
discussion that is sensitive to the (technical) context. The danger is that
the concept for ‘openness’ becomes a void-catch-all.


I use the definition of Brown and Ziewitz of openness as it builds upon the
work of Zittrain (2008) – who argues that the fundamental strength of the
Internet is the fact that it is open in the sense that people don’t need
anybody’s authority to build upon it. I believe this view of openness
encompasses some of the fundamental strengths of the Internet that need to
be preserved (like for instance permissionless innovation).


I prefer this definition over the one in the glossary for several reasons:
a. it takes a broader view of openness, b. I find the terms ‘unfiltered’
and ‘free’ in the glossary ambiguous (we all know that filtering happens
almost everywhere – and s for legitimate reasons in some casa). I am
equally interested in the rational behind the decision to incorporate your
specific definition of openness into the glossary.



> 2.
> You connect 'content agnosticism' with 'all packets are equal'. I am
> not sure if that is correct. I think content agnosticism means:
> packets are not treated differently based on their content. Would you
> agree?
> Glossary definition:
>         Treating network traffic identically regardless of content.
>

> Agreed, in the sense that perhaps I have taken too positive a view of
content agnosticism and should have been more nuanced in my definition
​. ​
I am aware of the fact that not all packets are (treated) equal (nor
should/can they be, see previous answer).



>
> 3. On p.20 you seem to use distributed and decentralized
> interchangeably, is this intentional?
>
> > no, mindfart. Although I do see them as very closely related. But
perhaps I am mistaken – so any input or
​ ​
explanation on the precise difference between distributed and decentralized
is very welcome.

4. I like the conclusion on page 23, this quote from RFC3935 could
> make it even stronger:
>    The Internet isn't value-neutral, and neither is the IETF.  We want
>    the Internet to be useful for communities that share our commitment
>    to openness and fairness.  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.
>

​> ​
thanks! Will add it to the next iteration of this research.

>
> 5. You use different ways of describing the relationship between
> protocol developers and human rights. Sometimes you talk about
> encoding human rights (which you put on the same level with
> 'protecting human rights') p.42, sometimes you also talk about
> 'instantiating human rights in protocols p.47, sometimes also
> 'directly instantiating the right ....' p.53
> Later on you make the clear difference between 'protocol development
> [that is] guided by human rights principles' and 'instantiating [human
> rights] in protocols' p. 53. Could you give definitions of the
> different processes or explain the differences among them?
>
>

> Sure, great question! I think the thesis really shows the academic roller
​ ​
coaster I went through trying to figure what it means to develop human
rights protocol considerations (hence the slightly vague terminology in the
beginning of my work). However, eventually I make a difference between 2
potential paths I see this work going down:


1. Developing human rights’ protocol considerations that are meant to guide
and inform the protocol creation process (much like privacy and security
considerations do). This road would not automatically ensure that protocols
are in line with human rights principles as it leaves space for engineers
to simply ‘check the box’ that they considered the potential implications
of their work (which we all know never-ever-ever happens *ahum*) or for
​those who implement​
to just ignore that part of the protocol.


2. Translating human rights to technical concepts and instantiating them
into protocols by ensuring a minimum number of technical properties are
present in the protocol ensuring certain human rights (in a Lessig code =
law kind of way). This would leave much less room for ‘tussle’ as Clark
calls it, or for faulty development/implementation of the protocol. It is
in my opinion a much harsher and thus also undesirable way to ensure
protocols are in line with human rights principles.


> 6. Sometimes you seem to argue there is a relative homogeneous
> normative conceptualization of the Internet among engineers at the
> IETF and sometimes you seem to argue that there is much diversity
> (which stimulates a tussle). Could you elaborate on this?
>

> Agreed – although I do not feel that a relatively homogeneous
conceptualization of the Internet among engineers and diversity and tussle
on certain issues are mutually exclusive.


Short summary of my argument on the shared normative conceptualization of
the Internet: The IETF strives to create an Internet that provides
continuous connectivity for all its users at all times, and for any
content. Although the four main architectural design principles – openness,
interoperability, redundancy and end-to-end – are presented as strictly
technical, it was illustrated (through examples of RFCs and the interviews)
that these principles represent a socio-political conceptualization of what
technical engineers view the Internet to be: a medium for connectivity and
by extension freedom of speech. This underlying normative framework drives
technological design decisions by IETF engineers, and is reinforced by the
particular make-up of the IETF participant base.

The tussles I identify come from various sources:


1. The participant base of the IETF is diversifying and includes more
individuals who are sent by political (instead of technical) organizations
to participate in the IETF.


2. Economic pressure and larger market developments that have led many
companies to favor ‘walled garden models’ of the Internet. Although I argue
that many engineers push back against such commercial developments they
perceive to threaten their definition of the Internet, in the end they’re
beholden to the economic interest of the organizations they work for. These
economic and market developments create a situation in which engineers on
the one hand have a certain vision of what the Internet is meant for, but
on the other hand are tasked with developing protocols that don’t
necessarily align with that vision.


3. Increased participation of civil society representatives and explicit
discussions of social values are increasing. This might seem counter
intuitive – but the fact that there is more discussion about the potential
societal impact of protocols has also increased the tussle within the IETF.
Although many engineers share the aforementioned view of the Internet there
is less consensus on their professional role, or responsibility, to ensure
the Internet as such remains a human rights enabling medium.



7. Which parts of your paper do you think could / would fit well inthe
methodology draft [1], glossary draft [2] and/or report draft [3]
​?​

> methodology draft [1]: I think a large part of the methodology section I
wrote could be transplanted to our methodology.

> Glossary draft: not sure, perhaps some parts that reemphasize the
importance of openness, redundancy, end-to-end etc?

> Report draft: conclusions + perhaps even part of the policy
recommendations?



> Greatly looking forward to your response.
>

​> Let me know if I left any questions unanswered.​


>
> Best,
>
>
> Niels
>
>
> [0] https://mailarchive.ietf.org/arch/attach/hrpc/pdfbyB1Dp.pdf
> [1] https://tools.ietf.org/html/draft-varon-hrpc-methodology-02
> [2] https://tools.ietf.org/html/draft-dkg-hrpc-glossary-01
> [3] https://tools.ietf.org/html/draft-doria-hrpc-report-00
> - --
> Niels ten Oever
> Head of Digital
>
> Article 19
> www.article19.org
>
> PGP fingerprint    8D9F C567 BEE4 A431 56C4
>                    678B 08B5 A0F2 636D 68E9
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWYdGhAAoJEAi1oPJjbWjpXr0H/32trYS3LnudUKznT3fX7aDz
> Q5NJLGACVsQUcPjF2uBl0I67LaBZy/yu6PcMeUmPdP6Q2IX5mX+T1Lo5/SwtAb9W
> NQHhGd0h/zhy/+JSDU/YX5YYD22d3aXhm2hcBHSP+Bm/sPTbwZ2GRsXkwqBoSIky
> 1BJy8ZUSrnTNx2a0Hgel1oe6jpvCbffFeMERQJQCb4GDPBDYRyOYhlj1bVqGEra7
> Z4dK1t3+cUl7FqbvBRD1e5GtY/FYGFdv1GqKdEP6T/i6Cj2qDq6OHRrFfUDHV1QQ
> lgVGcEcSKJQlXyb0qGaQvTndaehs7CEBui2ZKYhjSQK/3WKCi5i1R5koPLQ1LTM=
> =iwyg
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> hrpc mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hrpc
>



-- 


'The management of normality is hard work'




-- 


'The management of normality is hard work'