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

From: Fred Baker <[email-masked]>
Date: Tue, 28 Mar 2017 11:23:30 -0500

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.

---

From: Mando Rachovitsa <[email-masked]>
Date: Tue, 28 Mar 2017 23:01:02 +0200

Dear Fred,

curiously enough your last point makes lots of sense from a human rights
law point of view too.
A right has always a corresponding duty. As a matter of fact a right can
have a corresponding set of duties of either a specific or general nature.
For example, the duty of of the State to take (or refrain from) a specific
action or the duty of a State to set up a general framework which will
enable the effective exercise of rights (the latter category we call them
positive obligations).
>From your point of view it is very reasonable that you are thinking in
terms of what your duties would be when you design something. At the same
time, however, having a rights-based approach (assessing the impact of a
protocol) could also help identifying some (not necessarily all) of one's
duties.

Hope this makes sense to you too.
Mando

On 28 March 2017 at 18:23, Fred Baker <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 28 Mar 2017 21:45:12 -0500

> On Mar 28, 2017, at 4:01 PM, Mando Rachovitsa <[email-masked]> wrote:
> 
> Dear Fred,
> 
> curiously enough your last point makes lots of sense from a human rights law point of view too. 
> A right has always a corresponding duty. As a matter of fact a right can have a corresponding set of duties of either a specific or general nature. For example, the duty of of the State to take (or refrain from) a specific action or the duty of a State to set up a general framework which will enable the effective exercise of rights (the latter category we call them positive obligations).
> From your point of view it is very reasonable that you are thinking in terms of what your duties would be when you design something. At the same time, however, having a rights-based approach (assessing the impact of a protocol) could also help identifying some (not necessarily all) of one's duties. 
> 

None whatsoever. For most, perhaps all, of the 60 RFCs I have written, if I were asked what rights applied, I would have no idea how to answer.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Mar 2017 22:38:23 -0500

> None whatsoever. For most, perhaps all, of the 60 RFCs I have written, if I were asked what rights applied, I would have no idea how to answer.

Possibly this is a problem statement, rather than a statement of immutable fact.

It is certainly the case that when you make a screw, you do not know and cannot know whether or not it is going to be used to assemble a tractor or a tank.   So if all 60 of your RFCs were things like screws, then it would be difficult for you to see what implication they might have toward human rights.

However, many RFCs describe protocols that have clear implications for human rights.   If you can't conceive of a document for which that would be true, one of the implicit and perhaps explicit goals of this effort is to give you the tools to make this sort of differentiation.

It is not clear to me that this project can succeed, but it does seem to me to be the case that such implications do exist, and can be explored, even if fully enumerating them is an NP-complete problem.

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 29 Mar 2017 13:50:16 +0200

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:
> 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.
> 
> 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 [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 29 Mar 2017 10:13:49 -0500

> On Mar 29, 2017, at 6:50 AM, Bless, Roland (TM) <[email-masked]> wrote:
> 
> Hi Fred,
> 

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.

> 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...

> finding potential impacts is difficult and the draft wants to provide

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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 29 Mar 2017 19:57:10 -0500

On Tue, Mar 28, 2017 at 10:38:23PM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 88 lines which said:

> If you can't conceive of a document for which that would be true,
> one of the implicit and perhaps explicit goals of this effort is to
> give you the tools to make this sort of differentiation.

By the way, this is, in my opinion, what we should do once
draft-ietf-hrpc-research is published: "outreach", go to working
groups, explain them, draw attention to this RFC.

Otherwise, the project risk to be, like the "ethics" project at IEEE,
just a small spot of ethics, disconnected from the main activity.