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

[Fred Baker <[e-mail]>]

> On Mar 29, 2017, at 6:50 AM, Bless, Roland (TM) <[e-mail]> 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.