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

"Bless, Roland (TM)" <roland.bless@kit.edu> Wed, 29 March 2017 11:50 UTC

Return-Path: <roland.bless@kit.edu>
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 9FD8F1296BA; Wed, 29 Mar 2017 04:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LGDUTH9Cw_P5; Wed, 29 Mar 2017 04:50:21 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F19C1294F4; Wed, 29 Mar 2017 04:50:21 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ctC7E-0003Kh-L4; Wed, 29 Mar 2017 13:50:16 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 88E37B00520; Wed, 29 Mar 2017 13:50:16 +0200 (CEST)
To: Fred Baker <fredbaker.ietf@gmail.com>, draft-irtf-hrpc-research.all@ietf.org
References: <81A10909-149C-4054-958E-76779D941C3B@gmail.com>
Cc: hrpc@irtf.org
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <f3b5d1a6-6b5f-bb60-ef4f-22f98b064387@kit.edu>
Date: Wed, 29 Mar 2017 13:50:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <81A10909-149C-4054-958E-76779D941C3B@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1490788216.
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/iSUSqu55K80GVbbOAFUz55T6Ho8>
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: Wed, 29 Mar 2017 11:50:24 -0000

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

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.

So especially in case of error or failure handling, application-specific
knowledge is often required (as made clearer by the examples in the
paper). This knowledge may stem from the programmer or even
from the user, e.g., the application can be configured with user
preferences and try to act accordingly. So it is quite likely that
in an Internet of Things, you may possess devices that act on your
behalf and according to your policies. These devices may also
interact with devices of other users according to their policies.

Applying the end-to-end argument in systems design would now suggest
to leave the decision in case of conflicts(*) to the endpoints, since
they have (probably user-specified) knowledge how to react accordingly
(I think the "Tussle in Cyberspace" paper also fits here).
In the end, you are responsible for the devices that you own
and attach to the Internet - thus there is probably still a human
involved, although not in the direct communication loop.

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.

Regards,
 Roland

(*) Technically, we may frequently see (often resource) conflicts that
originally stem from different user preferences, e.g., a router needs
to decide which packet is the next to serve, normally without knowing
the importance of the packet to the user. How much intelligence
should/must be built into the network for conflict resolution and how
much can we leave to the application/user?



Am 28.03.2017 um 18:23 schrieb Fred Baker:
> Following up on the ISOC Policy Fellows discussion yesterday and a
> conversation I had with Corrine later.
> 
> I found myself disconcerted, as I usually do (I have made this
> comment before, but this time I have a little more noodling behind
> it), when Niels showed the slide that referred to RFC 1958's comment
> on the end-to-end principle and human rights. Here's my discomfort
> point.
> 
> I'm glad to see that the principles that underly the Internet lend
> themselves to a Human Rights discussion; that's a good thing, and I
> might be bothered if they didn't. However, the assertion that the
> designers of the Internet were thinking about Human Rights doesn't
> hold. The End-to-End Principle is stated twice in Saltzer's paper;
> the statement in the abstract is the one I concern myself with (a
> lower layer should perform the intent of a higher layer, so that a
> message sent by one system to another arrives at the intended system,
> and the message delivered is the one that was sent), as the one made
> in the body of the text doesn't hold in the Internet (routing is done
> by the network without help from or reference to the opinions of an
> application; the application identifies its intended correspondent by
> name or address, and the network gets the packet there).
> 
> The reason we assert that a lower layer should perform the intent of
> a higher layer has nothing to do with rights, human or otherwise. It
> has everything to do with the operation of a reliable and predictable
> service. When I communicate with a peer, if I find myself
> communicating with someone else or the message delivered is changed,
> I have a security issue and a privacy issue. In time, people will
> learn that this happens, and cease using the service - as their
> intentions are thwarted. The objectives of the principles by which
> the Internet is designed are about the usefulness of a service for
> the purpose of communication, nothing more and nothing less.
> 
> This distinction becomes very important in the Internet of Things. In
> IoT, there is no human in the loop. If our intentions are about human
> rights, the rules could be completely different when there is no
> human to have a right. But if the principle is about providing a
> reliable and predictable service, the principle always applies.
> 
> I also commented to Corrine that I'm far less concerned about
> "rights" than I am about "responsibilities", and would prefer that
> the discussion were framed in those terms. A "right", to me, is a
> license to get upset and perhaps to sue. If I ask what "rights" might
> apply to TCP, I guess the TCP user would have the "right" to send a
> SYN, to attempt to open a session. That's not much of a right. But
> the responsibilities of a TCP would include management of the window
> to maximize good put without undue interaction or stress on the
> network or other TCP sessions, the responsibility to respond to an
> incoming SYN, and so on. As someone who writes RFCs, if I'm asked to
> enumerate the "rights" impacts of a protocol, procedure, or white
> paper, I'm likely to be a little lost - beyond dealing with
> personally identifiable information, which doesn't occur below the
> application layer except by inference in the presence of other data,
> I'm not sure I have anything to say. Responsibilities, however, can 
> be pretty apparent.
> 
> I personally would wish that the discussion were framed as being
> about the responsibilities of a person or system that communicates,
> not the rights of a human being that may or may not even exist in the
> context. _______________________________________________ hrpc mailing
> list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc
>