Re: [hrpc] Thoughts on the end-to-end principle and Human Rights

Corinne Cath <corinnecath@gmail.com> Sun, 16 April 2017 16:27 UTC

Return-Path: <cattekwaad@gmail.com>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2BF124D68 for <hrpc@ietfa.amsl.com>; Sun, 16 Apr 2017 09:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1IYFdlQ3duF for <hrpc@ietfa.amsl.com>; Sun, 16 Apr 2017 09:26:59 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C93E1292F4 for <hrpc@irtf.org>; Sun, 16 Apr 2017 09:26:58 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id u2so20601533wmu.0 for <hrpc@irtf.org>; Sun, 16 Apr 2017 09:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KX2F+bNWuhDuZcn6BDkz7mG54zGYxB1odu0OJ2Q52AI=; b=Whf5lBMKDoB8jDCK6juWF1Q1Ld/0NgbQeV7coXc/Pe+1/X7zKkuyEkw8dIaVOXm/rm pc5jsg+qG+rKskDxevyE3CNcPzODKwzJclN0irbpuEFz22rsFlSqseRdZmzZa+WYFpTT RJFA8Hq0UT0f14wpRWA0nOoNv0zmVSjN4CLG48d7jBZmmhnuWwxdDn5aCzAvNHJ4grQF nGKdawQCYM5+gqMHSH9exATO3d2K4uB/PW3xX6kuQnUefzQupaGP9kv4kWGIkd08ott6 4L0XBUIaDO6jPvKGQ/rDYrJiXA2WhxzUce9n+HUM7pctohWskS64txnmNiySwJViJqoW GVwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KX2F+bNWuhDuZcn6BDkz7mG54zGYxB1odu0OJ2Q52AI=; b=SdJ8XwmxLwinrmLIkR9J6iBuNb1HifgQJhRY+Ol4gBPpIDrIbVxoX0T8wR0Dg8Zs7Y JPfAKoc63t7lyAa5dWw5NBqjBYiYggs+k3wi/Or5VqfHX1wSidrrCSH/Cgzm9nF+y9Cp Z/7MLQ8SRFB8Xj6cTiXWeicm6b00msc26iZ4NHUq+ezBlXzT6YhWSK3jYip4/bVh0FzP /sOzrvtz5H5HhE1jclsGv7iaIlZr/+ThZ0B8kSJtG5tEckOYf7uF6XISmDNYdDSusDrW 36KI1EdHiHJtV5P/CG9e7kzQxSCUhVAU3yHuBI7XZmIgKo1XrZvx2UWtImCUmzRF6BV/ EYQA==
X-Gm-Message-State: AN3rC/6K1LpxDz0Q9fDWHTnwyr7zc7JPnru6fy6AJON62tKmWlL0FwEz 5/ue4ydqtmpb3a/f6XUfG7bv0eOp4g==
X-Received: by 10.28.40.198 with SMTP id o189mr6238836wmo.108.1492360017443; Sun, 16 Apr 2017 09:26:57 -0700 (PDT)
MIME-Version: 1.0
Sender: cattekwaad@gmail.com
Received: by 10.223.139.220 with HTTP; Sun, 16 Apr 2017 09:26:56 -0700 (PDT)
In-Reply-To: <16D3E756-64EE-405B-AB1F-035BD0FD4579@gmail.com>
References: <81A10909-149C-4054-958E-76779D941C3B@gmail.com> <f3b5d1a6-6b5f-bb60-ef4f-22f98b064387@kit.edu> <16D3E756-64EE-405B-AB1F-035BD0FD4579@gmail.com>
From: Corinne Cath <corinnecath@gmail.com>
Date: Sun, 16 Apr 2017 18:26:56 +0200
X-Google-Sender-Auth: PcHNu_iMP9vvzS0B6N8f5zHqQH4
Message-ID: <CAD499eJ2zCUXDCEDauXhbASGdN=y+njxtQt_0jGOk6TssYffSA@mail.gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: "Bless, Roland (TM)" <roland.bless@kit.edu>, draft-irtf-hrpc-research.all@ietf.org, hrpc@irtf.org
Content-Type: multipart/alternative; boundary="001a1141d8aab786b8054d4b24a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/oYAbx2XNtDVvTzT9Vhc99U0nNW8>
Subject: Re: [hrpc] Thoughts on the end-to-end principle and Human Rights
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "niels@article19.org" <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Apr 2017 16:27:02 -0000

Hi,

I think the question of responsibilities and rights is not either/or. As
Mando indicated human rights are inherently linked to responsibilities (or
duties as she phrases it). Also in the case of non-state actors.

I think the UN Guiding Principles for Business and Human rights, show how
responsibility imply rights fom business actors. See:
http://www.ohchr.org/Documents/Publications/GuidingPrinciplesBusinessHR_EN.pdf

I understand the phrase business actors is not a perfect fit for the IETF.
The UN Special Rapporteur on the right to freedom of expression does a good
job of explaining in one of his latest reports how the UN guiding
principles can be applied to guide the work of technical actors like the
IETF.
https://documents-dds-ny.un.org/doc/UNDOC/GEN/G16/095/12/PDF/G1609512.pdf?OpenElement

For a slightly different approach see this article that Luciano Floridi and
I wrote last year. We look at how and why the IETF should incorporate human
rights in their work through a 'responsibility-by-design' approach:
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2912308

Although we take a different route (moral responsibility instead of
referring to the UN guiding principles) we end up at the same end point:
there is a reason and an obligation for the IETF to foster human rights
through their work.

Best,




On Wed, Mar 29, 2017 at 5:13 PM, Fred Baker <fredbaker.ietf@gmail.com>
wrote:

>
> > On Mar 29, 2017, at 6:50 AM, Bless, Roland (TM) <roland.bless@kit.edu>
> wrote:
> >
> > Hi Fred,
> >
> > I think you made a very good point about rights, responsibilities,
> > and an Internet of Things without humans in the loop. I'd like to
> > expand a bit on the potential role of the end-to-end argument in this
> > context.
> >
> > If I understood you correctly, you are interpreting the "end-to-end
> > principle" more in the direction of transport "Transparency" (see also
> > https://tools.ietf.org/rfc/rfc2775.txt) and I'm not sure that I can
> > derive it from the actual paper here:
> > http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>
> I'm keying off the abstract ("The principle, called the end-to-end
> argument, suggests that functions placed at low levels of a system may be
> redundant or of little value when compared with the cost of providing them
> at that low level."). The other statement in the document is in the
> introductory text, and is quoted in RFC 1958: "The function in question can
> completely and correctly be implemented only with the knowledge and help of
> the application standing at the end points of the communication system.
> Therefore, providing that questioned function as a feature of the
> communication system itself is not possible. (Sometimes an incomplete
> version of the function provided by the communication system may be useful
> as a performance enhancement.)" I observe that Internet Routing, both IGP
> and BGP, operate within the network at the network layer rather than
> finding help from the application, which it calls the "host", and therefore
> is not consistent with that version of the argument.
>
> If one agrees with the common statement that network address translation
> or filtering of routes and traffic violate the end-to-end principle, then
> transparency is critical to the end-to-end principle.
>
> > To me it's a minimality principle that suggests to avoid putting
> > application-dependent functions into the network (the paper also
> > speaks of a "kind of Occam's Razor" in the conclusion). Otherwise
> > the network would become unnecessarily complex and in the end, the
> > network may not have enough knowledge to make the correct decision
> > anyway. Consequences are higher robustness, broader application support
> > and easier innovation, because you don't need to change the network in
> > case of new applications.
>
> I would suggest that you read a couple of books like Russ White's "The Art
> of Network Architecture: Business-Driven Design (Networking Technology)" or
> Bill Norton's "The Internet Peering Playbook: Connecting to the Core of the
> Internet", and then comment on how simple the Internet is...
>
> > I think that the draft - among others - tries to point out that some
> > human rights may be affected adversely depending on how protocols are
> > designed and networks are operated. One suggestion is to use a
> > (protocol) design that minimizes such potential interference. IMHO
> > finding potential impacts is difficult and the draft wants to provide
> > some guidance.
>
> I'm not sure that I disagree with that. However, it's fairly easy to say
> "Firewall X prevents free speech" or "Route filtering in BGP Routing can be
> used to prevent connectivity, and is commonly used for that purpose with
> low reputation networks". It is also largely vacuous from the perspective
> of someone writing a protocol. Yes, things can be abused - anything can be
> abused. One RFC that I co-authored, https://www.rfc-editor.org/
> rfc/rfc3924.txt, was explicitly written because of that - it required an
> audit trail when lawful intercept technology is in use, because once it
> exists (and governments worldwide mandate its existence) the tool can be
> used by anyone - and there are known cases in which it has been used by
> organized crime and state actors (RFC 7528). That said, how might that
> consideration apply to RFC 3315 (MIB for Frame Relay) or the interconnect
> architecture (RFC 2427)? RFC 6018 (Greynets)? When I talk about "60 RFCs",
> one of those is RFC 3924; the rest are pretty deeply technical, along the
> lines of RFCs 2427 or 6018.
>
> As I said, I am pretty comfortable talking about responsibilities. In the
> RFC 6018 context, if I have traffic in my network that acts like attack
> traffic, I could argue that the network (its technology and its
> administration) have a responsibility to protect users and equipment, and
> the network element implementing the Greynet technology has the
> responsibility to *only* interdict that traffic. I might go so far as to
> say that a low reputation link or route usually has a low reputation
> because that responsibility has been abrogated, and the argument for
> restoring its reputation has to do with an inaccurate verdict or a change
> in behavior. Stating that in terms of the UNDP - I could probably twist
> something until it resembled a relevant statement, but it would not be a
> straightforward application of those concepts.
>
> Responding to a previous comment, yes, rights probably imply duties, but
> I'm not at all sure that duties imply rights. The argument that has to be
> made is that responsibilities imply rights worded in ways found in the
> UNDP. Contracts, in this case, imply duties, and business imperatives imply
> duties. But I'm not convinced that they imply rights, or are driven by
> rights.




-- 
Corinne J.N. Cath
Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: ccath@turing.ac.uk & corinnecath@gmail.com
Twitter: @C_Cath