Subject: Re: [hrpc] way forward draft-tenoever-hrpc-research - reviewers needed

From: Niels ten Oever <[email-masked]>
Date: Wed, 06 Jul 2016 18:21:51 +0200

Thanks for this Scott.

If we look at the current standing practice for security considerations then I think we should go for examples instead of a test.

So would more examples (per feature and right impacted) be sufficient in your opinion?

Best,

Niels

On 6 Jul 2016 5:40 p.m., Scott Craig <[email-masked]> wrote:

Hey Niels,

Thanks for this.

The fundamental issue I have is that the method you have used to claim links between features and rights is a black box. There is no discernible basis for the links other than your own judgement.

I don’t in any way doubt the quality of your judgement. But I struggle to see how it provides sufficient grounds on which to expect every IETF engineer to pay additional attention to the features in the document.

The idea of a test was simply a way to add some rigour to these claims in order to give them some means of defence if they are challenged and some means of adjudication if they are disputed.  Right now you are literally just saying that you talked to some people and then you decided which things were linked.

" It is on the basis of these various case studies, elaborate discussion on the mailing list and at various IETF conferences that we came to determine whether an architectural feature is a 'crucial ingredient for enabling the ability to exercise specific rights’. "

Simply saying ‘We came to determine’ as the method for determining the central claims made in the document just isn’t good enough. You can describe this process as  ‘proposing vectors of analysis’ if you want but this is no more than an obfuscated synonym for authors judgement.

If I was an aircraft engineer and my colleagues informed me that the contents of the pre-flight check had been determined by people who had talked to aircraft engineers doing doing ‘vectors of analysis’ and that no criteria had then been used to evaluate and prioritise what we were being asked to check then I would be terrified for the passengers. This exercise is no less serious and demands no less rigour.

If the point of the document is to ask engineers to give greater attention to the architectural features it highlights then a black box judgement cannot be a solid enough basis on which to make that request.

It would be great to know whether others think the current method is sufficient.

Scott Craig

On Mon, Jul 4, 2016 at 10:28 PM, Niels ten Oever <[email-masked]> wrote:

Hi Scott,

I have been thinking a lot about your suggestions. I think the test you

have been proposing might not be applicable for a technical environment

(but am happy to be proven wrong).

I do not think we can exhaustively list and map the risks that protocols

generate in relation to rights.

I would also like to add that the test you propose is neither part nor a

requirement in for instance security considerations:

https://tools.ietf.org/html/rfc2223#section-9

https://tools.ietf.org/html/rfc3552

Similar to the guidelines on security considerations RFC3552 and the

guidelines on privacy considerations RFC6973 we've proposed vectors of

analysis and provided examples.

That these vectors might not be exhaustive and always context dependent

are for me no arguments to hold the draft back.

Furthermore I think the guidelines provide an input for discussion of

drafts during drafting phase, but also when they're discussed for review

in other WGs or later on in the IESG. Decisions and reviews are

documented (and arguments are provided), so I am not sure whether one

can say the standpoints are arbitrary, nor that the judgments are not

replicable or cannot be contested (there are processes for that, that

can get weighed by the appropriate groups). It is not like these

guidelines for considerations are applied blindly.

If I understood you incorrectly, could you perhaps illustrate the test a

bit more in the specific case of security considerations?

Best,

Niels

Niels ten Oever

Head of Digital

Article 19

www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4

678B 08B5 A0F2 636D 68E9

On 06/27/2016 12:57 PM, Scott Craig wrote:

> Hi Niels,

> I’ve attached a document with comments on the pre-adoption draft.

> I am still hoping that someone can address the concerns I raised on the

> list about the methodology. I refer specifically to the method by which

> an architectural feature has been (or can be) claimed to 'shape the

> enabling environment' for a right.

> Raised here https://www.ietf.org/mail-archive/web/hrpc/current/msg00401.html

> here https://www.ietf.org/mail-archive/web/hrpc/current/msg00408.html

> and here https://www.ietf.org/mail-archive/web/hrpc/current/msg00417.html

> Though I agree with some of your conclusions, I do not think the

> justification for the claims you have made withstands scrutiny. As a

> result it’s presently difficult to see how an engineer could justify

> giving additional attention to the features highlighted in the draft.

> To re-state what I said previously:

> I think the method you have described (quoted below)*_is great for

> identifying _**/_candidate features_/*. But my concern is that it’s

> insufficient to determine that a candidate feature is an enabling (or

> restricting) feature.

>     /" It is on the basis of these various case studies, elaborate

>     discussion on the mailinglist and at various IETF conferences that

>     *we came to determine whether an architectural feature* is a

>     'crucial ingredient for enabling the ability to exercise specific

>     rights’. "/

> If no explicit test is applied to the candidate features

> after identification, I think this causes three problems:

> (1) *Judgements* *are arbitrary    *

> i.e there is no basis on which to argue that the threshold for inclusion

> was the same for one technical concept as for another.

> (2) *Judgements are not replicable. *

> i.e it is not possible to claim that different authors would not have

> come to significantly different conclusions than you have.

> (3) *Judgements cannot be contested  *

> e.g if someone were to disagree with your contention that

> internationalisation has a bearing on the right to political

> participation, on what basis would we adjudicate who is correct?

> Scott

> On Mon, Jun 13, 2016 at 3:15 PM, Niels ten Oever <[email-masked]

> <mailto:[email-masked]>> wrote:

>     Hi all,

>     To create a next RG version of the draft-tenoever-hrpc-research ID, it's

>     probably good to draft a clear way forward.

>     We have had some really good comments and reviews during and before the

>     call for adoption, thanks for that, but if we want to bring this further

>     we will need some more reviews.

>     Two people (Shane and Giovanni) are currently testing the guidelines for

>     human rights considerations on two actual drafts, which we hope can be

>     presented in Berlin.

>     Avri mentioned she had elaborate feedback on the current draft and

>     Collin Anderson mentioned he would do a review of the draft, which would

>     both be greatly appeciated.

>     So now we're looking for a third and potentially fourth reviewer who

>     could review the draft in within the coming two weeks so we can create a

>     new version ahead of IETF96 in Berlin.

>     What we're looking for is a review of the whole document with more or

>     less coherent notes, suggestions and/or criticisms with which we could

>     improve the document.

>     Looking forward to hear from you!

>     Best,

>     Niels

>     --

>     Niels ten Oever

>     Head of Digital

>     Article 19

>     www.article19.org <http://www.article19.org>

>     PGP fingerprint    8D9F C567 BEE4 A431 56C4

>                        678B 08B5 A0F2 636D 68E9

>     _______________________________________________

>     hrpc mailing list

>     [email-masked] <mailto:[email-masked]>

>     https://www.irtf.org/mailman/listinfo/hrpc

> --

> *Scott Craig* | Ford-Mozilla Fellow

> Center for Democracy & Technology |* cdt.org <https://cdt.org/>*

> *E:* [email-masked] <http://cdt.org/> | *D:* 1.202.407.8887

> <tel:202.407.8887> | **@scottdavidcraig

> */

> /*

--

Scott Craig | Ford-Mozilla Fellow
Center for Democracy & Technology | cdt.org
E: [email-masked] | D: 1.202.407.8887 | @scottdavidcraig

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jul 2016 12:43:44 -0400

On Wed, Jul 06, 2016 at 06:21:51PM +0200, Niels ten Oever wrote:
> <p dir="ltr">If we look at the current standing practice for security considerations then I think we should go for examples instead of a test.</p>

I find this claim unconvincing.

The security considerations approach had several historical features
that are quite different from the present case:

    1.  There was a security area with a fairly well-developed
    community involved directly in protocol design.

    2.  The failure mode in a missed security consideration is
    generally an immediate exposure of some particular bit of data.
    (This is part of the reason why, historically, pervasive
    surveillance didn't count.)

    3.  Nobody thought that the security of protocols was just an
    irrelevant political injection into protocol design.  There were
    questions about _which_ security ought to count, but not whether
    security as such was even relevant to protocol design.

It's (3) that seems to me to be the biggest issue here.  The I-D makes
a claim that human rights considerations are in fact relevant to
protocols, but as the I-D points out itself in §4, that is not a
completely uncontroversial claim.

Therefore, to me, a relationship between the rights in some framework
and a particular protocol or piece of functionality in a protocol is
what's needed, and the relationship needs to be demonstratable by
entailment from within the rights-framework in question.  If it's not,
then there's really no evidence that there's a rights consideration at
all.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 6 Jul 2016 19:21:07 +0200

> then there's really no evidence that there's a rights consideration at

Hi Andrew,

Does this mean that you find the case studies and guidelines for
considerations unconvincing?

Best,

Niels

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jul 2016 13:44:37 -0400

> considerations unconvincing?

Sometimes.

For instance, in 5.2.3, there's this:

    These capabilities for
   network control and limitations of the freedom of expression by end
   hosts can be traced back to the IPv4 design, helping us understand
   which technical protocol decisions have led to harm of these human
   rights.

It isn't clear to me whether that's a claim that is supposed to
introduce the next ¶ or whether it's a free standing one.  If it is
intended as introduction, the ¶ break makes it confusing.  If it's a
free-standing one, it's made completely without argument, is not
obviously true, and may just be empty since it's so imprecise.

The following ¶ is also problematic:

   Two major shifts have occurred to harm freedom of expression through
   misuse of the Internet Protocol.  The first is the network's
   exploitation of the public visibility of the host pairs for all
   communications, and the corresponding ability to discriminate and
   block traffic as a result of that metadata.  The second is the
   selective development of IP options.  Protocol extensions including
   Mobility and Multicasting have proposed alternate communication modes
   and suggest that different forms of assembly could be supported by a
   robust IP layer.  Instead, the protocol limited the deployability of
   such extensions by not providing a mechanism for appropriate fallback
   behavior when unrecognized extensions are encountered.

First, it isn't actually "the network" that has "exploited" the public
visibility of host pairs.  It is some operators of networks.  The
network design remains exactly as neutral as ever, and the ability to
block traffic may not anyway be a feature of the protocol so much as a
feature of Internetworking: your network, your rules, and that has to
mean the concomitant ability for you to block traffic on your network.
The claim about fallback behaviour is similarly contentious, and I
think perhaps somewhat anachronistic.  (You can't really have that two
ways: complaining about failures of v4 while ignoring features of v6
that are specifically there to correct some of these things appears to
demand some evidence that people are impeding v6 deployment.  For the
non-deployment of v6 suggests that maybe people don't care that much
about this.)

Now, one can read the follow-on sections as providing some of the
argument for the above.  But in that case, it's not clear to me why
some of the claims are expanded as they are in this section.

This is an example; I don't think the difficulties stop there.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 6 Jul 2016 20:54:46 +0200

Hi Andrew,

> obviously true, and may just be empty since it's so imprecise.

Great point, removed the break. Thanks.

> network design remains exactly as neutral as ever, 

I think we have discussed the non-neutrality of technology already at
lenghth. Also RFC3935:

   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.

> and the ability to

The ease and ability of doing filtering (and surveillance) can still be
very different based on design of the protocol.

> non-deployment of v6 suggests that maybe people don't care that much

I think there are many reasons for adoption / non-adoption of IPv6, but
I don't think this is within the scope of this draft.

> some of the claims are expanded as they are in this section.

It is (trying to) show impact of specific design choices on human
rights. Please allow me to reiterate that this can be completely
legitimate, the excercise is trying to stimulate people to make
conscious choices about this and make aim to make it visible.

> This is an example; I don't think the difficulties stop there.

I would really appreciate a longer review, either on list or in person
in Berlin (or during the hrpc session there).

Best,

Niels