Subject: [hrpc] Fwd: New Version Notification for draft-tenoever-hrpc-association-03.txt

From: Niels ten Oever <[email-masked]>
Date: Fri, 16 Feb 2018 21:50:57 +0100

Hi all,

Gisela and I are very happy to share a new version of the association
draft with you.  We have added quite a bit of new text, many pieces
based on discussions here on the list and your contributions.

We have also tossed the DDoS, spam, echo-chamber part, since we did not
add anything useful about DDoS or spam which has not already been said
in other RFCs, and online echo-chambers actually don't seem to be so bad.

We're greatly looking forward to your comments - maybe we can make a new
version before IETF101.

All the best,

Niels

*
http://www.tandfonline.com/doi/abs/10.1080/1369118X.2018.1428656?journalCode=rics20#.WnHNzhqT4Fw.twitter

-------- Forwarded Message --------
Subject: New Version Notification for draft-tenoever-hrpc-association-03.txt
Date: Fri, 16 Feb 2018 12:41:33 -0800
From: [email-masked]
To: Niels ten Oever <[email-masked]>, Gisela de Acha
<[email-masked]>, Gisela Perez de Acha
<[email-masked]>

A new version of I-D, draft-tenoever-hrpc-association-03.txt
has been successfully submitted by Niels ten Oever and posted to the
IETF repository.

Name:		draft-tenoever-hrpc-association
Revision:	03
Title:		Freedom of Association on the Internet
Document date:	2018-02-16
Group:		Individual Submission
Pages:		23
URL:
https://www.ietf.org/internet-drafts/draft-tenoever-hrpc-association-03.txt
Status:
https://datatracker.ietf.org/doc/draft-tenoever-hrpc-association/
Htmlized:
https://tools.ietf.org/html/draft-tenoever-hrpc-association-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-tenoever-hrpc-association-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-tenoever-hrpc-association-03

Abstract:
   This document scopes the relation between Internet protocols and the
   right to freedom of assembly and association.  Increasingly, the
   Internet mediates our lives, our relationships and our ability to
   excercise our human rights.  The Internet provides a global public
   space, but one that is built on private infrastructure.  Since
   Internet protocols play a central role in the management, development
   and use of the Internet, the relation between protocols and the
   aforementioned rights should be documented and any adverse impacts of
   this relation should be mitigated.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 22 Feb 2018 15:09:54 +0100

On Fri, Feb 16, 2018 at 09:50:57PM +0100,
 Niels ten Oever <[email-masked]> wrote 
 a message of 76 lines which said:

> Gisela and I are very happy to share a new version of the
> association draft with you.

Summary: I agree, I think it is important, and I think the synthesis
in section 8, and its conclusion, are fine.

Now, the details.

> The Internet provides a global public space, but one that is built
> on private infrastructure.

*Mostly* (may be) on private infrastructure but not all. NRENs are a
good example of public infrastructure, but there are others. (Even
more if you regard DNS registries as infrastructure.)

> This is also true for the Border Gateway Protocol

The last paragraph of section 6 is very confused. The fact that "there
is no transparency about the routes that packets have taken" has
nothing to do with BGP (it is an IP issue, since "record route" - RFC
791, section 3.1 - was never deployed). Pull Request incoming.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 23 Feb 2018 11:30:08 +0100

On Thu, Feb 22, 2018 at 03:09:54PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 30 lines which said:

> "record route" - RFC 791, section 3.1 - was never deployed).

Fact checking: this is false. I'm very surprised to see it still
works. I change my Pull Request.

% sudo ping -c 1 -4 -R www.ietf.org
PING www.ietf.org.cdn.cloudflare.net (104.20.0.85) 56(124) bytes of data.
64 bytes from 104.20.0.85: icmp_seq=1 ttl=58 time=4.61 ms
RR:     ...
	209.66.115.110.t01331.above.net (209.66.115.110)
	lo0.mpr1.ewr1.us.zip.zayo.com (64.125.0.242)
	lo0.er2.lga5.us.zip.zayo.com (64.125.0.194)
	199.27.132.1         <- Cloudflare router 
	104.20.0.85          <- Cloudflare (IETF hosting provider)
	[Here, the return path, incomplete]
	104.20.0.85          <- Cloudflare (IETF hosting provider)
	199.27.132.1         <- Cloudflare router
	lo0.er2.lga5.us.zip.zayo.com (64.125.0.194)

--- www.ietf.org.cdn.cloudflare.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.616/4.616/4.616/0.000 ms

A traceroute from the same machine (showing only the first leg). Note the
small differences (router recording a different address, or not
recording at all):

% traceroute www.ietf.org traceroute to www.ietf.org (104.20.0.85), 30
hops max, 60 byte packets ...
 2  xe-3-2-1.mpr1.ewr1.us.above.net (209.66.115.109)  0.497 ms  0.542 ms  0.539 ms
 3  * * *
 4  ae1.cs1.lga5.us.eth.zayo.com (64.125.29.200)  0.897 ms  1.053 ms  1.044 ms
 5  ae10.er2.lga5.us.zip.zayo.com (64.125.27.157)  0.989 ms  1.023 ms  1.027 ms
 6  198.32.118.206 (198.32.118.206)  1.238 ms  1.269 ms  1.420 ms
 7  104.20.0.85 (104.20.0.85)  1.470 ms  1.471 ms  1.464 ms

Note also the limits mentioned in the ping man page:

* Note that the IP header is only large enough for nine such routes.
* Many  hosts ignore or discard this option.