From nobody Mon Jan 2 07:12:40 2017 Return-Path: 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 239EC12965B for ; Mon, 2 Jan 2017 07:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 swzVvKWZ7qf8 for ; Mon, 2 Jan 2017 07:12:37 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 922AC129654 for ; Mon, 2 Jan 2017 07:12:36 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 82AFB2803B4; Mon, 2 Jan 2017 16:12:34 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 7C2AB280348; Mon, 2 Jan 2017 16:12:34 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 78C52B38026; Mon, 2 Jan 2017 16:12:04 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 71D613FF94; Mon, 2 Jan 2017 16:12:04 +0100 (CET) Date: Mon, 2 Jan 2017 16:12:04 +0100 From: Stephane Bortzmeyer To: S Moonesamy Message-ID: <20170102151204.cnv7brtakd35o6j3@nic.fr> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.7.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: Corinne Cath , Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 15:12:39 -0000 On Sun, Dec 25, 2016 at 10:35:11PM -0800, S Moonesamy wrote a message of 119 lines which said: > https://www.ietf.org/mail-archive/web/ietf/current/msg98613.html Note that this was a reply to a known and obnoxious troll. > The Abstract states that "This documents aims to be a consensus > document of the Human Rights Protocol Consideration Research Group > of the Internet Research Task Force (IRTF)". Will it be the > consensus of the representatives from companies or organizations > from one country, a few countries or more than that? Regarding the human rights themselves, the idea is that the Universal Declaration of Human Rights is a consensus. It is mentioned in draft but may be we should move it to a normative reference :-) Regarding the draft, well, that's the point of the last call, to attract as much people as possible, for diverse backgrounds. Do not hesitate to spread the word. > Section 3.2.3.2.1 is about the removal of DNS records. The second > sentence in that section could be read as meaning that the US-based > registry in charge of .com was involved in the first example which > is referenced. You mean Wikileaks? Indeed, it was done through the registrar (and not the registry, specially not the .com registry since it was not a .com). Proposal: There have been a number of cases where the records for a domain are removed from the name system due to real-world events. Examples of this removal includes the 'seizure' of wikileaks [bbc-wikileaks] and the names of illegally operating gambling operations by the United States Immigrations and Customs Enforcement unit. In the first case, an US court ordered the registrar to take down the domain. In the second, ICE compelled the US-based registry in charge of the .com TLD to hand ownership of those domains over to the US government. The same technique has been used in Libya to remove sites in violation of "our Country's Law and Morality (which) do not allow any kind of pornography or its promotion." [techyum] > There is the following question in Section 4.1.1.1.5: "Does your > protocol allow Unicode encoded in UTF-8 only?" Does that mean that > a protocol supporting UTF-8 only does not enable > internationalization? Quite the opposite. The current text is badly written (I raised the point several times but with little success). The idea (see the entry Internationalization in the terminology) is that the best solution, for internationalisation and interoperability, is to accept UTF-8 only, thus avoiding any compatibility issues. The second best solution is to accept several charsets, which will require mandatory tagging, to avoid guessing. The worst is of course ASCII-only. Proposal: Question(s): Does your protocol have text strings that have to be understood or entered by humans? Does your protocol allow Unicode? If so, do you have accept texts in one charset (which must be UTF-8), or several (which is dangerous for interoperability)? If character sets or encodings other than UTF-8 are allowed, does your protocol mandate a proper tagging of the charset? Did you have a look at [RFC6365]? > There is a discussion of an outage at > https://news.ycombinator.com/item?id=12759520 Is it the protocol, namely > DNS, which is brittle? In the Dyn case, no, the problem was excessive concentration. (In the same way that excessive concentration of email at Gmail is not the fault of SMTP or IMAP.) From nobody Tue Jan 3 00:14:33 2017 Return-Path: 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 D68221294CF for ; Tue, 3 Jan 2017 00:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=rtqeSzQV; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=WAYXSx7/ 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 VodMhyXsP3lK for ; Tue, 3 Jan 2017 00:14:29 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A141294C0 for ; Tue, 3 Jan 2017 00:14:29 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v038E9kk028627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2017 00:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1483431259; x=1483517659; bh=OPTPDb7Y2fXd1PihU6X5gJVKxe6/xia+FxYaxVe9ELo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rtqeSzQVLjxcYaDqjQah/zeQVm5jl6u2iCHB+rZCsVxsBmyzyUpyBUlckEPe/GQ6z oy+TUy3Wv768P4i1Xb76kvupNEjdCTlDJu6jOE6fMeAaT/PP9wCsop/CCVWa9Dv7Wt kHOUbGeZMV8CJB9J9cemL1Sok6p6x9pjns/ZG638= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1483431259; x=1483517659; i=@elandsys.com; bh=OPTPDb7Y2fXd1PihU6X5gJVKxe6/xia+FxYaxVe9ELo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WAYXSx7/ALjDadCmJOrqO+n8K2/3hKXbgppqf2nG8uG5qghXVCsgjTVkcUMDLXiRR Ajej3FofE0Jd0SlXXx4Znxo2I9zJythqkYeNzRpBQ67a76hY0S9HR8ucr759c3BXqA 1rHa9hWekLkXQZxgbP9TPzlqbgK7sr72rnFBzWdY= Message-Id: <6.2.5.6.2.20170102113813.0b94b9e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 Jan 2017 13:01:22 -0800 To: Stephane Bortzmeyer From: S Moonesamy In-Reply-To: <20170102151204.cnv7brtakd35o6j3@nic.fr> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <20170102151204.cnv7brtakd35o6j3@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Corinne Cath , Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 08:14:31 -0000 Hi Stephane, At 07:12 02-01-2017, Stephane Bortzmeyer wrote: >Regarding the human rights themselves, the idea is that the Universal >Declaration of Human Rights is >a consensus. It is mentioned in draft but may be we should move it to >a normative reference :-) I read the declaration. >Regarding the draft, well, that's the point of the last call, to >attract as much people as possible, for diverse backgrounds. Do not >hesitate to spread the word. The reply does not contain an answer to the question. >You mean Wikileaks? Indeed, it was done through the registrar (and not Yes. >the registry, specially not the .com registry since it was not a >.com). Proposal: > > There have been a number of cases where the records for a domain are > removed from the name system due to real-world events. Examples of > this removal includes the 'seizure' of wikileaks [bbc-wikileaks] and > the names of illegally operating gambling operations by the United > States Immigrations and Customs Enforcement unit. In the first > case, an US court ordered the registrar to take down the domain. In the > second, ICE compelled the > US-based registry in charge of the .com TLD to hand ownership of > those domains over to the US government. The same technique has been > used in Libya to remove sites in violation of "our Country's Law and > Morality (which) do not allow any kind of pornography or its > promotion." [techyum] The proposed text looks better. >Quite the opposite. The current text is badly written (I raised the >point several times but with little success). The idea (see the entry >Internationalization in the terminology) is that the best solution, >for internationalisation and interoperability, is to accept UTF-8 >only, thus avoiding any compatibility issues. The second best solution >is to accept several charsets, which will require mandatory tagging, >to avoid guessing. The worst is of course ASCII-only. Proposal: > > Question(s): Does your protocol have text strings that have to be > understood or entered by humans? Does your protocol allow Unicode? > If so, do you have accept texts in one charset (which must be > UTF-8), or several (which is dangerous for interoperability)? If > character sets or encodings other than UTF-8 are > allowed, does your protocol mandate a proper tagging of the > charset? Did you have a look at [RFC6365]? It has been a while since I looked into Internationalization. It is advisable to use UTF-8 to reduce interoperability issues. It is similar to what you have in the first part of the proposed text. It can be an issue when different encodings are allowed in a protocol as an encoding may not be well-supported on the receiver side. For what it is worth, RFC 2277 was written in the previous century. It may be easier to refer to RFC 6365 only. The "text strings that have to be understood or entered by humans" is discussed in Section 6 of RFC 6365. Although your proposed text looks better, that sub-section would still look confusing. >In the Dyn case, no, the problem was excessive concentration. (In the >same way that excessive concentration of email at Gmail is not the >fault of SMTP or IMAP.) Yes. Regards, S. Moonesamy From nobody Thu Jan 5 06:29:04 2017 Return-Path: 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 26969129581 for ; Thu, 5 Jan 2017 06:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 aVShpXtiGPET for ; Thu, 5 Jan 2017 06:28:51 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 748BD12957B for ; Thu, 5 Jan 2017 06:28:50 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cP923-0000Mr-Sh; Thu, 05 Jan 2017 15:28:44 +0100 To: S Moonesamy , Corinne Cath , hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> Date: Thu, 5 Jan 2017 15:28:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WeolC3ANfJS4UMrcWISHaNvpwNjOp46Mo" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4e9a86bacda42c1c15dddd19596d0ef6 Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:28:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WeolC3ANfJS4UMrcWISHaNvpwNjOp46Mo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you very much for this review. Initial responses inline: Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 On 12/26/2016 07:35 AM, S Moonesamy wrote: > Hi Niels, Corinne, >=20 > I have a few comments about draft-irtf-hrpc-research-07. First of all = I > would like to commend Article 19 and the Oxford Internet Institute for > their efforts to research human rights issues. I did a quick search on= > ietf.org and the following thread showed up in the search results: > https://www.ietf.org/mail-archive/web/ietf/current/msg98613.html People= > from different parts of the world have different ways of looking at > topics such as human rights. >=20 That is why reviews are very much welcomed and we've done considerable outreach to get as much reviews from different perspectives on this draft= =2E It can also be said that Human Rights (as laid out in documents like the UDHR, ICCPR and IECSCR) are the most universal values we have in the worl= d. > The Abstract states that "This documents aims to be a consensus documen= t > of the Human Rights Protocol Consideration Research Group of the > Internet Research Task Force (IRTF)". Will it be the consensus of the > representatives from companies or organizations from one country, a few= > countries or more than that? >=20 It will be the consensus of the research group and the people therein. Nothing more, nothing less. > Section 2 cites RFC 2606 for "Open standards Conform". I gather that > the reference is a mistake as RFC 2606 does not pertain to open standar= ds. >=20 Thanks for catching that, it should have been 2026, fixed that. > Section 3.2.3.2.1 is about the removal of DNS records. The second > sentence in that section could be read as meaning that the US-based > registry in charge of .com was involved in the first example which is > referenced. The usage of "real-world events" is not clear. Does it > mean events which could be described as political or something else? Replace 'real-world' with 'political'. Thanks for the suggestion. I also used the text that has been suggested by Stephane with this little tweak.= >=20 > Section 3.2.3.2.2 using dns.telecomix.org as an example. The domain > name does not exist: >=20 > ;; QUESTION SECTION: > ;dns.telecomix.org. IN A >=20 > ;; AUTHORITY SECTION: > telecomix.org. 3600 IN SOA ns3.binero.se. > registry.binero.se. 1482364800 86400 5400 604800 3600 That's sad. Removed the example. >=20 >=20 > Section 3.2.3.3.1 discusses about cryptography. There was an IAB appea= l > related to that in 2014. Was that mentioned during the interviews > (Section 3.1.2)? I could not find a reference to the appeal as it is > not listed on the IAB web site. >=20 Are you referring to RFC7258 ? Am not completely sure how it would fit in here, but text suggestions are always welcome. > Section 3.3.3.6 discusses about Virtual Private Networks. A few years > ago, I asked for feedback about BCP 162 [1] about logging > recommendations due to the lack of privacy considerations. Would this > be viewed as an issue in respect to human rights? >=20 Default log settings have an impact on privacy, privacyis a human rights, so I'd say, yes this could be framed as a human rights issue. Which does not mean that one should never be able to keep logs, but rather we should try to keep the storage and collection of Personal Identifiable Information to a minimum. > There is the following question in Section 4.1.1.1.5: "Does your > protocol allow Unicode encoded in UTF-8 only?" Does that mean that a > protocol supporting UTF-8 only does not enable internationalization? This was badly written, I went with the proposal made my Stephane: Does your protocol have text strings that have to be understood or entered by humans? Does your protocol allow Unicode? If so, do you have accept texts in one charset (which must be UTF-8), or several (which is dangerous for interoperability)? If character sets or encodings other than UTF-8 are allowed, does your protocol mandate a proper tagging of the charset? Did you have a look at {{RFC6365}}? >=20 > One of the definitions for an "Open Standard" (Section 4.1.1.1.7) has > the following: "available in multiple complete implementations by > competing vendors, or as a complete implementation equally available to= > all parties". How many of the IETF protocols qualify for this? For > what it is worth, there is a short thread about standards at > https://www.ietf.org/mail-archive/web/ietf/current/msg88209.html >=20 > A point that may have been missed in that Section is protocol > maintenance, e.g. is there a process to fix a defect in the > specification and does that process actually work? Interesting. But is this an IETF or a protocol issue? Is this something that an protocol develop can/should address? >=20 > The "know what is being decided" is unfortunately not easy especially > when decisions are not taken in a timely manner. What is the use of > making "his or her voice heard on the issue" if that voice is not given= > due consideration when the decision is taken? Does the "right to > non-discrimination" apply here? >=20 I think it depends on the conception of non-discrimination and equality do not apply here, since it is equally miserable for everyone. > There is the following in Section 4.1.1.1.7 "Open standards are > important as they allow for permissionless innovation, which is > important to maintain the freedom and ability to freely create and > deploy new protocols on top of the communications constructs that > currently exist". Could the authors please provide an example of this > "permissionless innovation" in relation to "open standards"? The > example referenced in the draft is not about a protocol. Why could the notification system outlined in RFC6108 not be interpreted as a protocol? >=20 > Section 4.1.1.1.8 is about "heterogeneity by design". On reading RFC > 1958 again I noticed that Section 5.2 of the document list export > controls as an issue of secondary importance. The explanation was that= > "all of the technology required to implement Internet standards can be > fabricated in each country". Does it affect a technical specification > when it cannot be implemented due to restrictions affecting > cryptography? Is there heterogeneity by design if there are > restrictions to "extension points" or export controls on a "mandatory t= o > implement" feature in a standard? >=20 I do indeed think that export control impact heterogeneity, but I do not think this can be addressed by protocol designers. > Section 4.1.1.1.13 discusses about decentralization. Do points of > control affect the "right to freedom of expression"? >=20 Thanks! Added! > There is a discussion of an outage at > https://news.ycombinator.com/item?id=3D12759520 Is it the protocol, > namely DNS, which is brittle? >=20 > Section 4.1.1.1.9 discusses about privacy considerations and lists > "Right to non-discrimination" under "Impacts". This seems to be based > on the constitution of a country which protects unpopular individuals > from retaliation -- and their ideas from suppression -- at the hand of > an intolerant society. Isn't this about "freedom of speech" and > anonymity instead of the "right to non-discrimination"? Is it actuall= y > "right to non-discrimination" or is it the "right to equality"? >=20 It's not only by society. The less information is known about an individual, the harder it is to discriminate against them. Therefore the right to privacy and the right to non-discrimination are linked. There is indeed also a strong link between non-discrimination and the right to equality. this is also why all human rights are universal, indivisible, interrelated, interdependent and mutually reinforcing. > I have mentioned previously that people are encouraged to participate i= n > the IETF and contribute through mailing lists but are completely > disenfranchised relative to other people who attend IETF meetings. It > is odd if a person were to talk about human rights and he/she ignore > such issues. >=20 > Section 9 states that there are no security considerations as the > document concerns research. If there weren't any considerations, would= > several of the participants (Section 3.1.2) opt to remain anonymous? >=20 Security considerations here have been interpreted according to RFC3552. Thanks a lot of the review! All changes can be found here: https://github.com/nllz/IRTF-HRPC/commit/a7a16539939777e947a51127e61b42ed= c30e6931 new version is here: https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md Best, Niels > Regards, > S. Moonesamy >=20 --WeolC3ANfJS4UMrcWISHaNvpwNjOp46Mo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYblgaAAoJEA7YPzpGisiziCEP/2W5LJDuG9O+mrmhQzvM/ID8 R2PdZS+23dC89y/atR8Gnk88PqpLV2TWJyH1YVUT+Mj1wQvaKjzuj1azl+sMZV34 saF40bFFWE1HYNZJ0NocUjxghlxBJeTECDL+fTFDO0Ih/T+jSkrr8jS9vkKYrzWm OQyZQkNc0aPNhu+IKN/a+gOohX5YnlibjnISrBUhm7NI4ohYuFDKx5um9cMelnTm FoqSZdjJnHHAlf3N/htSwlRZGl9Z6bD6ez2V4lKF5HhESWlWM/fqDFaYW4WHBdQD K+7w8jV3NShwRA/1eoIbdg0pGFVomqCJ0C/LnR6AXefvfdreIMNJS54vbZflsp1c Y71QDKDeEhwfRhZpxF2HNH4nknkqJBYpV0TNchDIVrSPn5vbeRttEx0kxUplgSY/ J+6xUNsvVJimY9XSDmUEDlajUn7tmCe3dlYkj/yVT/3mB/8f5TVAW06XvaxVgEx+ ABSm3cix5J0ZhIZjdD8h0jwSxaAq9TaIRWLNwxVrl7TWKeJ5VdhaPgBdMPahBcje 7fjulPcuZTr7v211RI7+5NZ9Ko3nwo+J4s2jMYFumqh8+JNL6kIkgzklNc6LvR/v ZPxG31qEhJGrGpbysOAZchS+Z23AiLfy1XSc8aJT8eo+JRDrayfCBl6X4mnQa/xy r+DgYwamFV0Qv6glpOmM =hNEk -----END PGP SIGNATURE----- --WeolC3ANfJS4UMrcWISHaNvpwNjOp46Mo-- From nobody Thu Jan 5 06:47:01 2017 Return-Path: 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 3BD9B129B37 for ; Thu, 5 Jan 2017 06:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jnLlhY_7NyjN for ; Thu, 5 Jan 2017 06:46:57 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id CE8EC129B36 for ; Thu, 5 Jan 2017 06:46:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id CAB55114CE for ; Thu, 5 Jan 2017 14:47:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrFuTHxrc3lg for ; Thu, 5 Jan 2017 14:47:01 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 137E2114CB for ; Thu, 5 Jan 2017 14:47:01 +0000 (UTC) Date: Thu, 5 Jan 2017 09:46:54 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170105144654.GX12568@mx2.yitter.info> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:46:59 -0000 On Thu, Jan 05, 2017 at 03:28:42PM +0100, Niels ten Oever wrote: > > Section 3.3.3.6 discusses about Virtual Private Networks. A few years > > ago, I asked for feedback about BCP 162 [1] about logging > > recommendations due to the lack of privacy considerations. Would this > > be viewed as an issue in respect to human rights? > > > > Default log settings have an impact on privacy, privacyis a human > rights, so I'd say, yes this could be framed as a human rights issue. > > Which does not mean that one should never be able to keep logs, but > rather we should try to keep the storage and collection of Personal > Identifiable Information to a minimum. It seems rather important for this document, however, to distinguish between "protocol considerations" and "operational considerations". Logging is clearly the latter. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jan 5 08:05:28 2017 Return-Path: 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 2DF14129B92 for ; Thu, 5 Jan 2017 08:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 7rmwVz5nENuI for ; Thu, 5 Jan 2017 08:05:24 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 55A49129B96 for ; Thu, 5 Jan 2017 08:05:15 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPAXQ-0008CQ-EG for hrpc@irtf.org; Thu, 05 Jan 2017 17:05:13 +0100 To: hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 5 Jan 2017 17:05:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161230022007.GD3304@mx2.yitter.info> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PQP35BESV9qGoVOudcvj6ms5MAqTu0pnD" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: bd0815c19477704c2eba9769bb1f3076 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:05:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PQP35BESV9qGoVOudcvj6ms5MAqTu0pnD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Andrew, Thanks a lot for this response, reply inline: On 12/30/2016 03:20 AM, Andrew Sullivan wrote: > Dear colleagues, >=20 > This is my much-overdue response to draft-irtf-hrpc-research. I > apologize for the dilatory notes. I have failed to send these remarks > on every previous occasion, partly because the authors are much better > at turning around drafts than I am at completing my reviews. >=20 > I should say that in general I think this is a useful draft and even > if the authors reject my suggestions I would have no objection to the > RG publishing the draft. >=20 > Part of the reason that I have struggled with this draft is because, > while I do not really disagree with many of its conclusions or > recommendations, I have a number of concerns about how it gets to > those conclusions. I've made some oblique references to these points > in various mic lines and list postings, but I haven't done a good job > of laying out the concern, so this is an effort to do it more > completely. >=20 > My concern is that the draft cannot decide whether it is a human > rights ethics _for_ the Internet protocols, or a HR ethics _of_ > the Internet protocols. >=20 What we're trying to do is to propose a HR ethics for Internet protocols, which finds it roots in the values that are currently a partial (and quite obscure) ethic of Internet protocols. I think the fact that we're talking for so long about what these could be, makes it really clear that the ethics of Internet protocols are by far not as clear as many who have worked on the early network would have wanted them to be. This can also be seen in the film 'Net of Rights'. > The trouble shows up early on. For instance, section 1 says, "The > purpose of the Internet to be a global network of networks that > provides unfettered connectivity to all users and for any content > [RFC1958]" In my reading, RFC 1958 does not actually offer a claim > about the purpose of the Internet. Perhaps of greater concern, RFC > 1958 explicitly notes that its own purpose is not "to lay down dogma > about how Internet protocols should be designed". That is, while RFC > 1958 is about "architecture", it strives not to be prescriptive. It's > therefore strange to see it cited as the source for "this objective" > of the Internet. >=20 I think the sentence 'the community believe that the goals is connectivity' is pretty clear here: 2.1 Many members of the Internet community would argue that there is no architecture, but only a tradition, which was not written down for the first 25 years (or at least not by the IAB). However, in very general terms, the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network. > Now, it is true that RFC 3935 says, "The Internet isn't value-neutral, > and neither is the IETF." But the rest of the text is in fact silent > on _which_ values the Internet has, because the document is about the > IETF, and not the Internet. And while RFC 3935 continues to talk > about the technologies that the IETF "choose[s] to create" as opposed > to ones that are possible, it seems to me that it actually expresses > implicitly a value of the Internet as such. That value can found an > ethic all of its own. RFC3935 seems to have a bit thicker description here: The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society. Also the following description seems to negate your statement that there is such a thing as an inherent network ethic: These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create. According to RFC3935 it's about a conscious ethical choice we're making, that we're not basing on what is possible, but on what we choose to creat= e. You're right that the documents are not very specific about what this should be, and that is exactly the void that this document tries to fill.= >=20 > If there is an ethic of the Internet, it is this: that more > internetworking is better because that makes the Internet better > connected. This is a (more or less) pure engineering value that follow= s > directly from the recognition of network effects. Once you have > network effects, a given network is more valuable from the connections > it can make. But that has special consequences for the Internet, > because internetworking is not flat. It is instead networking of > networks, which means that any given connection to the Internet must > always be treated as the connection of another network. This requires > a formal indifference to the nature of the network on the other > side of that connection, an acknowledgement that the newly-connected > network might be patchy or unreliable, and also an assumption that the > network so connected is not itself the locus of intelligence. We're > not building the Catanet. >=20 > Now, it seems to me that there are two stances that the draft takes > with respect to why human rights ought to matter for Internet > protocols. One of them is more troublesome for the draft's purpose > than the other. The first is that there are human rights, and that > Internet protocols need to be built to support them. =20 I think this is a misrepresentation of the draft. There is an explicit difference between 'support human rights' (which would be an advocacy / enforcement position) and 'respect human rights' (which simply ensures that there is no adverse impact on human rights). We might call > this the "extrinsic value" position. The second is that there are > human rights, and the expression of them aligns nicely with the > (above-outlined) positive engineering value of the Internet; we might > call this the "concordant value" position[1]. We can see this tension = in > the following bit from section 1: >=20 > Therefore, important human rights enabling characteristics > of the Internet might be degraded if they're not properly defined, > described and protected as such. And, the other way around, not > protecting human right enabling characteristics could also result in= > (partial) loss of functionality and connectivity, and other inherent= > parts of the Internet's architecture of networks.[2] >=20 > The first sentence of these is a claim about extrinsic values and why > Internet protocol designers ought to care about those. The second is > about how protecting human rights contributes to the values of the > Internet. My basic concern is that this dual motivation at once > threatens both the goal (of 3935) and the effort. The goal is > threatened because the extrinsic motivation changes the meaning of > "work better". The effort is threatened because it obscures the > engineering value of "the network for its own sake", and subsumes that > value beneath externally-supplied values. >=20 I would not have a problem with a useable inherent network ethic, if there was such a thing. How your concept of an inherent network ethic help us with issues like internationalization, universal availability, and accessibility? It completely leaves the human out of the equation, whereas the Internet is about humans, not about the Internet itself. The Internet is not an interesting science expiriment (anymore), it is mediating central democratic processes, the public debate, and the global economy. The Internet does not simply exist for the Internets sake= =2E Furthermore, there are many different ways in which inter-connectivity is possible, but it gives very little guidance on the hard choices we need to make and the impact they might have. > For the draft, a consequence of all the above is that the motivation > for the human rights considerations is not clearly stated in terms > that a sceptic might endorse. The comparison with the security and > privacy considerations is instructive. Those seem, to my eye, to be > motivated by the value of security or privacy (as appropriate), but > the failure to take them into consideration is framed mostly in terms > of the harm _to the Internet_ that arises if the issue is not taken > into account. Perhaps in the case of the hrpc draft the extrinsic > motivations are more reasonable, because this is not an IETF > document. But if one thinks that technologies are neutral, and that > it is the _use_ of the technologies that can trample on rights, the > focus on human rights might sound like an attempt to make the IETF > into a political actor. Technology is not neutral, neither is the Internet and neither is the IETF. The IETF already is political and also already is a political actor. There is are ample examples of that in the book by Laura DeNardis:= DeNardis, Laura. 2009. Protocol Politics: The Globalization of Internet Governance. Cambridge, MA: MIT Press. as well as: DeNardis, Laura. 2014. The Global War for Internet Governance. I am still waiting for relevant literature that argues that technology is ethically neutral. We've cited quite a body of literature that argues the exact opposite. Repeating that technology is neutral will not make it more true, but I am more than happy to be convinced. >=20 > In order to make this clearer, it might help if the draft discussed > more plainly three possible interactions: how considering rights > might be good for the purposes of the Internet protocols (perhaps > because it makes them more useful and therefore more likely to be > adopted, or because it makes them more resilient to certain kinds of > attacks, or whatever); how considering rights might be useful in > extrinsic value terms (this seems mostly to be what section 3 does); > and how considering rights might be good for the overall > socio-political environment into which the Internet is deployed (some > of section 1 and some of section 6 seems to be doing this). >=20 > Finally, in my view, that very section 6 continues to be troublesome. > It argues that protocols _are_ politics despite outlining some views > that do not seem to support such a view at all. It says >=20 > However, these protocols and standards do not > exist outside of their technical context nor outside of their > political, historical, economic, legal or cultural context. This is= > best exemplified by the way in which protocols have become part and > parcel of political processes and public policies >=20 > The first of these sentences is trivially true: _nothing_ exists > outside if its context, so protocols and standards don't either. But > the best exemplification of that is not that people use protocols as > part of their political arguments or public policies. Indeed, if one > believed that protocols are merely tools and that it is the use of the > tool (not the tool as such) that determines its political > consequences, one could argue that protocols need to be _protected_ > from being dragged into such discussions. =20 So you are arguing here that things actually do exist outside of their context until they are used? And that things do not order reality or shape their usage? In that case it might be interesting to have a look at UI/UX studies and how they are working on increasing the understanding of the relationship between technolog and the user and how specific design stimulated or inhibits specific behavior. Adams, Anne, and Martina Angela Sasse. 1999. =93Users Are Not the Enemy.=94= Commun. ACM 42 (12): 40=9646. doi:10.1145/322796.322806. Gonzalez, Teofilo, Jorge D=EDaz-Herrera, and Heikki Topi, eds. 2014. =93Sociotechnical Approaches to the Study of Information Systems.=94 In Computing Handbook, Third Edition. Boca Raton, FL: CRC Press. https://www.crcpress.com/Computing-Handbook-Third-Edition-Two-Volume-Set/= Tucker-Gonzalez-Topi-Diaz-Herrera/p/book/9781439898444. If you would like a more high level architecture and infrastructure approach to this point, you could have a look at: Star, Susan Leigh. 1999. =93The Ethnography of Infrastructure.=94 America= n Behavioral Scientist 43 (3): 377=9691. doi:10.1177/00027649921955326. Bowker, Geoffrey C., and Susan Leigh Star. 2000. Sorting Things Out: Classification and Its Consequences. The MIT Press. > So there is a faint hint of > circularity in section 6's reasoning about why rights are important > for protocols. This may be because the section never really takes > seriously the position that a tool need not itself have a value > charge, and that the value comes entirely in its use. It's true that > this view of technology fell out of fashion at least after the second > War and arguably earlier. But it's a position entirely in keeping > with the Aristotelian tradition. Moreover, it is rather far from > obvious to me that some of the citations in the section actually agree > with the positions in whose support they are being cited. >=20 I am afraid you're right that your position is a position in line with Aristotelian ethics as they were current before the Second World War. But scienctific literature and opinion has quite significantly changed since then, partially because of the use of technology in the Second World War. Also Artistotelian ethics have moved on. A quick search finds two articles that argue the exact opposite: Aristotle on Technology and Nature, Schummer, Joachim, Philosophia Naturalis, 38 (2001), pp. 105-120 http://www.joachimschummer.net/jslit/aristot.htm Being human in a global age of technology, Whelton, Beverly J. B., Nursing Philosophy, January 2016, Vol.17(1), pp.28-35 In the latter there is also a description of Heidegger and the concept of equipment/tool/technology and mediation (or rather immediation). I might have missed some literature, if so, I am happy to read some books or articles per your suggestion. > This leads to a problem for the following recommendation: >=20 > At this point > is difficult to say whether hard-coding human rights into protocols > is wise or feasible. It is however important to make conscious and > explicit design decisions that take into account the human rights > protocol considerations guidelines developed above. This will ensur= e > that the impact protocols can have on human rights is clear and > explicit, both for developers and for users. In addition, it ensure= s > that the impact of specific protocol on human rights is carefully > considered and that concrete design decisions are documented in the > protocol. >=20 > Why is it important to make the design decisions this way? Why is it > important that the impact on human rights is clear and explicit? If a > protocol designer thinks the protocol's _use_ is what makes for the > consequences for others' rights, what is the motivation for that > individual to think about the rights-effects? (Motivating this all in > terms of the consequences for the network might be effective in this > case.) >=20 > I hope these remarks are useful to the authors. I really hope we can either put the tech-neutrality argument to bed, or continue the discussion based on literature. >=20 > Best regards, >=20 > A >=20 >=20 > [1] As an aside, there's an "intrinsic value" position: that the > Internet inherently is a mechanism for expressing human rights in its > very nature, and so only human rights values are Internet protocol > values. I don't think the draft proposes this, though I note that > there are people who feel strongly that the Internet _should_ work > this way. That's a political problem for the IETF, perhaps, but it's > not an issue for this draft. Eventhough article 19 of the UDHR can be read as a description of the Internet, we quite quickly get into problem if we look at the detailed implications of that statement. It's not easy to bridge the legal and the technical, but this is something we have been trying to do in this draft. >=20 > [2] It's worth noting that the opening of this paragraph contains > historical claims that are in really deep need of citations, because I'= ve > read almost nothing about the early Internet that suggests "everyone" > could join, much less contribute code. The DoD near-end-of-ARPANET > project certainly didn't let "everyone" join. The NSFnet AUP was > _entirely_ clear that not "everyone" could join or contribute code, > even if the AUP was honoured more in the breach. The late-1990s and > early-2000s open source literature has obscured the difficulty for > mere mortals of connecting to the Internet in earlier periods. I was > a motivated-to-connect undergraduate in Ontario, Canada in the late > 1980s/early 1990s, and the best I could do was a commercial dial-up > system that provided a kind of gateway to parts of the Internet > (undergraduates didn't rate connection to ONet in those days). >=20 I _really_ like this point. But I feel hesitant to go deeper into this, because I would be tempted to go into histories of the Radiatation Lab, FIDONET and ARPAnet. Some of this has been excellently described here: Flichy, Patrice. 2007. The internet imaginaire. Cambridge, Mass.: MIT Pre= ss. and Turner, Fred. 2006. From Counterculture to Cyberculture: Stewart Brand, the Whole Earth Network, and the Rise of Digital Utopianism. Chicago: University of Chicago Press. What if I simply change the text into this?: The open nature of the initial technical design (open standards, open source, etc) fostered freedom of communication as a core value, the aim was to create a network which would enable everyone to connect and to exchange data, information and code. All the best, Niels PS New version with changes: https://github.com/nllz/IRTF-HRPC/commit/e59d18db0e98409731bee3a1da4870ba= 057700ca --PQP35BESV9qGoVOudcvj6ms5MAqTu0pnD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYbm63AAoJEA7YPzpGisizReIQAJUmeTTMKCkNBUFlEy59XFoF ixBtQKolUNVhzFVI+y//mM/uT5rdOvSXdFV9m/s2Jg7mHbOfZofzTNkCOgOMlj6x 4rAUAOLPgqZcVz3U+Vz4Vj/i2vN7D+rr7jVpC3cvW3QvVYWpX1mAYiZZDXOWZfu/ 5x8oKmkWJnIwtUdKFH4UYvnUl9wn6868OwQAk2EBum38tjMGZEdUj/HFiQkm2IeH 2AaF71cgt0CEl29ERhNVKcm9KBMslHVBQnnFhHSwifwd0AKcI+53KOKfFl+cRFsR SzdHx5KHAvRCamsiTqLH4d9R+NyEPue1oCUsz32qZQQIYhno79mQyo5mtxMLKwZi +2trKwyx1EO4GZkgaGA6omVPhrLYjchXLt38TpbplWnb5FtC13YKCNOgAqIg5FEb EPfK33PRYAiWm8efWqi22HDToP0faDPcLgfsvQITKPJ04hjZb1Nr/AXxzhZfZSAj MCrztmQgBFyWQ6Ii7lie+SFci87embahs3VygpOIAI9a0mQIGIjZakV5xYWOKcf3 3nflJveg4M0qSRiodCAp30sSAoP/B6Aly9p4Xt675dR5PnmjqSIuOIO3DY6jHGAQ xFkdrE87rgxpKrl3xbwhJUqZ0GpuX1ApyegrvnYE/Ly15sFN7aizeUTwLK3ir8IL 41TQFafUY7a+kK3FslIn =iuXR -----END PGP SIGNATURE----- --PQP35BESV9qGoVOudcvj6ms5MAqTu0pnD-- From nobody Thu Jan 5 08:35:18 2017 Return-Path: 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 A7D80129496 for ; Thu, 5 Jan 2017 08:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Vq8Xg7Ow2nOX for ; Thu, 5 Jan 2017 08:35:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D19B12941C for ; Thu, 5 Jan 2017 08:35:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E1479BE58; Thu, 5 Jan 2017 16:35:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2DHh88EGS1Y; Thu, 5 Jan 2017 16:35:10 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2B5D2BE50; Thu, 5 Jan 2017 16:35:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483634110; bh=lGc4Lrv78v5pkjU4xkKCGm638Quw72t6a4v/V1jQscU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QWxJXWjJ4FARk14WzsOXwY+DiOO+ZMK5uIao3KxRFb1HkArfaL6FIgWhJMBbVAdAF 1kkeuPq+06MN3pFs4VuaQCEgye9TAW/c613tVVKaNTnb/+tklEoa0TIp5D7R3pDAH2 en7YFXXegFUVNHkrNYK6TpmLJOVQARKst5nlMkCQ= To: Niels ten Oever , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 5 Jan 2017 16:35:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h7gGMduuDbBRa1Kt2PWPUS6U6pEuUtrqR" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:35:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h7gGMduuDbBRa1Kt2PWPUS6U6pEuUtrqR Content-Type: multipart/mixed; boundary="mdaBMd5NP0W0HGrt2xLdchVMMFjmJBTPk"; protected-headers="v1" From: Stephen Farrell To: Niels ten Oever , hrpc@irtf.org Message-ID: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> In-Reply-To: --mdaBMd5NP0W0HGrt2xLdchVMMFjmJBTPk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Comments on two of your responses below, other text elided... On 05/01/17 16:05, Niels ten Oever wrote: > On 12/30/2016 03:20 AM, Andrew Sullivan wrote: > I think the fact that we're talking for so long about what these could > be, makes it really clear that the ethics of Internet protocols are by > far not as clear as many who have worked on the early network would hav= e > wanted them to be. This can also be seen in the film 'Net of Rights'. I don't find the above argument convincing and perhaps for a reason that's useful to elucidate: we do not know that the "wanted them to be" above applies. In my own case, I do have some opinions that you (Niels) would likely call some relevant ethics. In the IETF context however, I have not found it necessary that we reach consensus on those. And I am not at all sure we ought try - I can't see a useful subset of my or what I imagine are others' ethical opinions on which it'd be good for the IETF to have reached consensus, and I really doubt that the IETF would find any such subset on which it could reach consensus. >> For the draft, a consequence of all the above is that the motivation >> for the human rights considerations is not clearly stated in terms >> that a sceptic might endorse. The comparison with the security and >> privacy considerations is instructive. Those seem, to my eye, to be >> motivated by the value of security or privacy (as appropriate), but >> the failure to take them into consideration is framed mostly in terms >> of the harm _to the Internet_ that arises if the issue is not taken >> into account. Perhaps in the case of the hrpc draft the extrinsic >> motivations are more reasonable, because this is not an IETF >> document. But if one thinks that technologies are neutral, and that >> it is the _use_ of the technologies that can trample on rights, the >> focus on human rights might sound like an attempt to make the IETF >> into a political actor. >=20 > Technology is not neutral, neither is the Internet and neither is the > IETF. The IETF already is political and also already is a political > actor. There is are ample examples of that in the book by Laura DeNardi= s: I'm sorry but I (and I think others) do not agree with you on this point, no matter how oft asserted, and even though that literature does exist. >=20 > DeNardis, Laura. 2009. Protocol Politics: The Globalization of Internet= > Governance. Cambridge, MA: MIT Press. >=20 > as well as: >=20 > DeNardis, Laura. 2014. The Global War for Internet Governance. >=20 > I am still waiting for relevant literature that argues that technology > is ethically neutral.=20 That is not what I claimed. Some technology is not ethically neutral. But I do assert that IETF technology some is ethically neutral. You seem to be asserting that no technology can ever be ethically neutral and I disagree with that. > We've cited quite a body of literature that argues > the exact opposite.=20 No, you did not provide exact opposites above. Yes, there is a body of literature that argues as you do. It's fine that we do not all share the exact same opinions, but would be better if the draft did reflect that divergence. > Repeating that technology is neutral will not make > it more true, but I am more than happy to be convinced. That was not repeated because it was not stated, by me at least and nor I think by Andrew. *Some* technology is neutral was my assertion. Cheers, S. --mdaBMd5NP0W0HGrt2xLdchVMMFjmJBTPk-- --h7gGMduuDbBRa1Kt2PWPUS6U6pEuUtrqR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYbnW9AAoJEC88hzaAX42iDo4H/iFk3X5+nad9hjjXhHs5sheh pjZvnnVMgDNGSmwoNtGSVgyYo/1RK9CEktCtcpj8q0LgEB2tZHpjEdcJPoJFO0ke 70CjOO7/m3/HdBbhXHbt2LLp7q0/53YF569gUc1gW3WQSrlqOZbky0P6fy2Rl0NN /3Z0NP0x6vNik8/hy68serEWln3EBgwagK8WjdXGIkWsasfa1LnxeIFdgqS0k9Ro XZ3s4hfM+aP4WyrBynvwsLPcbB63fesAf5CkYhfQUQNoeA7jriJbElD2LuguuOxG TckEWDK7b+azGQUV+sbvIWNvlx64RYF8FmR4lYd81Z1CYQWFnIiCwiVvKzb56m8= =WKv1 -----END PGP SIGNATURE----- --h7gGMduuDbBRa1Kt2PWPUS6U6pEuUtrqR-- From nobody Thu Jan 5 08:55:11 2017 Return-Path: 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 A37DD1294F1 for ; Thu, 5 Jan 2017 08:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 E5gURsUWzHd4 for ; Thu, 5 Jan 2017 08:55:07 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5201293F5 for ; Thu, 5 Jan 2017 08:55:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 27CE3114CF for ; Thu, 5 Jan 2017 16:55:12 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_ZPGpHO8xOq for ; Thu, 5 Jan 2017 16:55:11 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id E7162114CB for ; Thu, 5 Jan 2017 16:55:10 +0000 (UTC) Date: Thu, 5 Jan 2017 11:55:03 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170105165503.GZ12568@mx2.yitter.info> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:55:09 -0000 Hi, Some further follow up. On Thu, Jan 05, 2017 at 05:05:11PM +0100, Niels ten Oever wrote: > > The trouble shows up early on. For instance, section 1 says, "The > > purpose of the Internet to be a global network of networks that > > provides unfettered connectivity to all users and for any content > > [RFC1958]" > I think the sentence 'the community believe that the goals is > connectivity' is pretty clear here: […] > > the first 25 years (or at least not by the IAB). However, in very > general terms, the community believes that the goal is connectivity, > the tool is the Internet Protocol, and the intelligence is end to end > rather than hidden in the network. I think there is a difference between "connectivity" and "unfettered connectivity to all users and for any content". Indeed, I bet there are countries today who think they have a goal of connectivity without having the latter more expansive goal. I think this puts the finger on what's bothering me, though: in my reading the draft is too keen to take the most expansive, rights-supporting reading of any text even when alternative readings are available. A more conservative approach to the literature would, I think, actually make the draft's conclusions stronger. > RFC3935 seems to have a bit thicker description here: > > The IETF community wants the Internet to succeed because we > believe that the existence of the Internet, and its influence on > economics, communication, and education, will help us to build a > better human society. This is a claim about what the community that makes up the IETF believes, not what "the IETF" considered in itself believes. There may or may not be a difference between those two things. > Also the following description seems to negate your statement that there > is such a thing as an inherent network ethic: > > These concepts have little to do with the > technology that's possible, and much to do with the technology that > we choose to create. Nope, it shows my point. The "we" there are choosing to make _internetworking_ technology, and that technology might itself have an inherent ethic. The IETF participants could choose to create technologies that run against internetworking (arguably, sometimes they do. One could make the argument -- I've heard people do it -- that MPLS is not terribly internetty). > I think this is a misrepresentation of the draft. There is an explicit > difference between 'support human rights' (which would be an advocacy / > enforcement position) and 'respect human rights' (which simply ensures > that there is no adverse impact on human rights). Perhaps (though I confess this distinction is not always quite so plain to me in the text). But I don't think that this alters the point I was making, which is that the difference between extrinsic and concordant values might be important. > I would not have a problem with a useable inherent network ethic, if > there was such a thing. How your concept of an inherent network ethic > help us with issues like internationalization, universal availability, > and accessibility? It completely leaves the human out of the equation, > whereas the Internet is about humans, not about the Internet itself. I don't think so. The argument, for instance, about why pervasive monitoring is an attack _on the network_ and not on the users works the same way. It says (in part) that the attack is on the network because the pervasive monitoring undermines the utility of and faith in the network, which thereby reduces the incentives to use it, which reduces the positive-feedback network effects of the network. That is _apart from_ the social costs and the attack on human users and so on. > Internet is not an interesting science expiriment (anymore), it is > mediating central democratic processes, the public debate, and the > global economy. The Internet does not simply exist for the Internets sake. The trouble here is that, if _that_ is the basis of internetworking, then there is a strong position available to sceptics of this draft. It is that engineers ought to inform but not decide policy debates. This is the classic technocratic position: that the technocrats advise policy makers, but themselves never make such policy decisions. Of course, the draft is arguing that this position is wishful thinking, because protocols are in fact politics anyway. But unless you deal with the technocratic point of view head on -- and it just rejects the postwar position about the combination of protocols and politics -- then the draft will remain subjecto attack from that technocratic point of view. (More on this below.) What you claim above is that the values are in fact all extrinsic. If that's true, then the debate over which rights and which interpretation (China's? The US's? NL's or CA's?) of the UDHR ought to count is something that happens outside the IETF. It remains only for protocol designers to take these values "into account" somehow. If, on the other hand, there is a concordant value that flows from internetworking values themselves, then protocol engineers have a positive duty when writing Internet protocols to consider those internetworking values and promote them when possible. I claim (but it'd be a hard problem to show, I suppose) that these are a concordant set of values that have the interesting property of supporting a particular vision of human rights also. > Furthermore, there are many different ways in which inter-connectivity > is possible, but it gives very little guidance on the hard choices we > need to make and the impact they might have. It is possible that we are not in alignment about the nature of the project. The Internet is not merely about inter-connectivity of nodes. It is about inter-connectivity of networks with a particular style of inter-connectivity in which the edges have most of the intelligence, the individual networks interconnect without necessarily having pre-existing contractual or other such arrangements among them, and where messages flow from one part of the internetwork to another without a lot of molestation from intermediate nodes. That's quite a lot more than inter-connectivity. I agree that inter-connectivity could, for instance, be achieved by the Catanet approach that a certain IETF gadfly often promotes, and probably by something like the old telephone networks suitably updated for packet switching. But those wouldn't be _internets_, even if they'd be interconnectivity. > So you are arguing here that things actually do exist outside of their > context until they are used? And that things do not order reality or > shape their usage? Well, of course, that is (roughly) a metaphysical position that basically ruled Western philosophy from at least Plato through Descartes. So it seems a little surprising to wave it away with a couple rhetorical questions, especially because it undergirds the strict separation of roles that is implied in the technocratic stance. > I am afraid you're right that your position is a position in line with > Aristotelian ethics as they were current before the Second World War. > But scienctific literature and opinion has quite significantly changed > since then, partially because of the use of technology in the Second > World War. If your argument is at bottom that the old position is wrong because it's old, then I fear we are far apart. I am not arguing that old position is true. I am arguing that it needs to be taken seriously, and that the draft doesn't do so, and therefore the draft is weaker than it needs to be. > The open nature of the initial technical design (open standards, open > source, etc) fostered freedom of communication as a core value, the aim > was to create a network which would enable everyone to connect and to > exchange data, information and code. I am always leery of claims about the aim of actors in the past (and ironically, I get even more leery when many of those actors are still around, because I know my own motivations for what I did in the past are now quite fuzzy to me, and I tell stories to myself about how I got to this place where I am). So I'd suggest this instead: The open nature of the initial technical design and its open standards, as well as developments like open source, fostered freedom of communication. What emerged was a network of networks that could enable everyone to connect and to exchange data, information and code. For many, enabling such conections became a core value. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jan 5 09:45:12 2017 Return-Path: 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 4FDA51295CF for ; Thu, 5 Jan 2017 09:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=qaNyVI6J; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=XoyvspLk 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 nJla0FHd8XDp for ; Thu, 5 Jan 2017 09:45:09 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46271295CE for ; Thu, 5 Jan 2017 09:45:06 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 197E821003 for ; Thu, 5 Jan 2017 12:45:06 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 05 Jan 2017 12:45:06 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=tghBzYHrkeDfx2k5F7x+nkrQZQE=; b=qaNyVI 6JgV0ye3oBmWYhSlt13ObIEbZ6d8uHINejgGjlFFAnjYKSktxR99w+8+Jj8c/8JQ fezvTi68sOvtx3an0WwVdAje/ui4SW2x6i54t4dBwnMx5XI9EGgrKhChfHkJG3iV NDbowYsxHAZMI60cZ7TJh7E8f7M8ViUT7iuJo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=tghBzYHrkeDfx2 k5F7x+nkrQZQE=; b=XoyvspLkRSQD9C9N1V7QU84WlHxTAQfor9GNOos/wq/wVX YoEZCSpcYZ29Kx8T9WQKLCCGgea/MmjKXmXc0jwZtaNj9iTrtOtYB+cVNtic3TF+ GV4fYz7IMzeZbd5CeNmOILv/l7ugPEY5PDrRmoRzjOJPPpGnd8CqjaTcX7vOw= X-ME-Sender: X-Sasl-enc: xe9sKPIKO/0EZHEFZpnsfXqRMHDuid8Z2F58wSAEzbVo 1483638305 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 6EC2F7F064 for ; Thu, 5 Jan 2017 12:45:05 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> Date: Thu, 5 Jan 2017 12:45:04 -0500 To: hrpc@irtf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 17:45:11 -0000 Below is a review of draft-irtf-hrpc-research-07. I have not been = involved in the RG so these comments are for what they're worth and I = apologize if some of this ground has been trod before. This was an = interesting read and most of my comments are provided with an eye = towards making the document more useful/actionable in the IETF = eventually, which I realize may not be a shared goal necessarily. Substantive comments: =3D Section 3.2.3 and 3.2.3.1 =3D If the point of the IPv4 example is to demonstrate the human rights = impacts -- both positive and negative -- of various protocol designs, I = find the section to be narrow, slanted, and incomplete. It seems focused = almost exclusively on the potential harms, which, for a protocol as = fundamental to the operation of the Internet as IPv4, is not justified = and renders this section somewhat useless IMO. IPv4 is the basis for packet-switching on the Internet. What would the = human rights impacts be if packet-switching was never invented? It seems = to me that any evaluation of the human rights impacts of IPv4 needs to = take this more wholistic view into account. IPv4 completely = revolutionized networking and allowed for the amazing innovation that = the purposes for which people were connecting could be disassociated = from the providers of the physical circuits. Had that not happened, how = would the capacity for human freedom of expression in the world be = different from what it is today? I don't think an assessment of the = human rights impacts of IPv4 can ignore this and still be credible. The above is just one example of a fundamental aspect of the protocol = that is overlooked in the existing analysis. Section 3.2.3.1.1 bemoans = the visibility of source and destination addresses, while overlooking = the fact that such addresses can actually provide a great deal of = anonymity protection compared to other identifiers that could have been = chosen to be made part of the protocol. Having decried address = visibility, Section 3.2.3.1.2 then makes no mention of the fact that NAT = can actually provide protection from such visibility. For this section to add value, it either needs to provide a wholistic = analysis of both the positive and negative impacts of the protocol that = takes into consideration the space of alternative designs and outcomes, = or it needs to state up front that it is cherry-picking a few harms = identified as being linked to the protocol design just for demonstration = purposes. I think the same goes for the other examples in Section 3.2.3. The = existing set of design and deployment decisions seem to be taken as = givens rather than as a set of inflection points where things could have = turned out much worse for human rights. What if the DNS hadn't been = designed in a distributed fashion? What if we hadn't managed to make = HTTP performant such that it could support rich media and applications = as it does today? What if instead of the near-ubiquitous ability for = stacks to deploy TLS we were all relying on IPSec as our underlying = security protocol? All of those were real possibilities. Not = acknowledging them makes the section read like a litany of criticisms = rather than a balanced assessment of the positive and negative rights = impacts of the protocols. I was also surprised to see P2P, VPNs, a specific HTTP status code, and = DDoS attacks in this section which is purportedly about protocols. This = seems like a good bit of mixing apples and oranges; I think the section = would be more effective if it focused on specific protocols since that = is the unit of design most familiar to and most actionable for IETF = engineers. Analyzing protocol-level design decisions is particularly = important because what can be controlled within a protocol design space = is different from what can be controlled within a particular = implementation or deployment. =3D Section 3.2.3.5.2 =3D "Peer-to-Peer traffic (and BitTorrent in particular) represents a high percentage of global Internet traffic" Is there a citation for this? My understanding is that by most = measurements the share of p2p traffic is pretty low these days. =3D Section 4.1.1.1 =3D Two overall comments about this section:=20 (1) The questionnaire seems like it took the kitchen sink approach. Many = of the considerations covered here are already covered in other existing = IETF documents. In a number of cases this document took specific items = from those existing documents and broke them out into their own separate = subsections with many detailed questions (e.g., privacy, anonymity, = pseudonymity, confidentiality, integrity, reliability, authenticity). I = think most protocol designers will find the sheer volume of questions = here daunting and will find the redundancy both within the section and = together with existing guidance documents reason enough to skip a human = rights analysis altogether. I would recommend really trying to = streamline this section down to the essence of the questions that = protocol designers are not already asking themselves but should be. If = you want to include a comprehensive mapping between the technical = concepts and specific human rights, put that mapping in a different = section and focus this section on the most important and actionable = questions. (2) I think it would be a lot clearer if the various subsections were = explicit about where the recommendations here are different than = recommendations in existing IETF documents and policies. For privacy, = security, internationalization, and extensibility, the document mixes in = references to existing guidance/policies with its own text and = suggestions. If the suggestion is to just go read the other documents, a = simple reference would do; otherwise, I think the document could be a = lot clearer about where it is asking protocol designers to depart from = or go beyond what the existing guidance requires. Other than drawing = explicit links between the concepts and human rights affected, I think = 4.1.1.1.2, .4, .9, .10, .14, .15, .16, and .17 could all be removed or = replaced with simple pointers to existing documents (possibly also true = for .5 and .12 but it=E2=80=99s not my area of expertise). =3D Section 4.1.1.1.1 =3D The example doesn't seem to be responsive to the question. The question = is about requiring functionality at intermediaries whereas the example = is about a design decision to prevent intermediaries from carrying out = such functionality. =3D Section 4.1.1.1.3 =3D "Question(s): If your protocol impacts packet handling, does it look at the packet payload? Is it making decisions based on the payload of the packet? Does your protocol prioritize certain content or services over others in the routing process ? Is the protocol transparent about the priotization that is made (if any)?" I think this set of questions could benefit from some refinement, in = particular in terms of the actor(s) being targeted. I don't quite = understand the notion of a protocol itself "looking" at a payload or = making a decision. I'm guessing this one is actually targeted at network = intermediaries, as in 4.1.1.1.1, since the whole point of many protocols = is for endpoints to take some action based on packet payloads. I also think the example in this section (and all the subsections of = 4.1.1.1, actually) would be more useful if it cited a specific protocol = that has the effect that the section raises concerns about, because it's = hard to understand what is being implied here. That is, I'm not sure = what the implications would be of the answers to these questions if = applied to, say RFC 2474 and RFC 2475, because the implications all = depend on the deployment context. =3D Section 4.1.1.1.6 =3D "Question(s): Does this protocol introduce new identifiers or reuse existing identifiers (e.g. MAC addresses) that might be associated with persons or content? ... Example: Identifiers of content exposed within a protocol might be used to facilitate censorship, as in the case of IP based censorship, which affects protocols like HTTP." I'm not sure how much mileage there is to be had out of this question = and example, because most protocols use identifiers. I don't think this = is a bad thing, it's just really hard to design a way to communicate = between two endpoints about something without using identifiers of some = sort. The question is phrased broadly enough that I think the answer = will almost always be "yes" but I'm not sure to what end. =3D Section 4.1.1.1.7 =3D This section is concerning because it seems to be trying to re-interpret = or change existing IETF policies, which seems inappropriate even for an = informational IRTF document. For example, this bit in particular caught = my eye: "All standards that need to be normatively implemented should be freely available and with reasonable protection for patent infringement claims, so it can also be implemented in open source or free software." As nice as it would be if this were always true, it's not, and it's not = likely going to be any time in the foreseeable future for the 8000+ = specifications the IETF has produced. Many of the reasons for that are = outside the control of IETF participants. So I find it unhelpful to = suggest these as requirements. I also don't think BCP 78 and 79 and the = note well should be further elaborated in a document such as this one; = even as informational people can get confused. I would suggest deleting this section as there is a high potential for = confusion and I'm not sure that it provides much countervailing benefit. Also, I don't understand how the example relates to the rest of the = section or why the emphasis on DPI is there. =3D Section 4.1.1.1.10 =3D The example doesn't seem to relate to pseudonymity and I'm not sure what = is meant by a "feature." Again here giving a specific protocol example = would be more helpful I think. =3D Section 4.1.1.1.11 =3D I think combining access for those with disabilities and access for = those with poor connectivity under a single heading is confusing. These = imply some rather disparate design decisions, not all of which will = apply to all protocols nor in the same ways.=20 =3D Section 4.1.1.1.16 =3D I think it would be better not to mix integrity with authentication (via = the example reference) since you can have one without the other. Nits: =3D Section 1 =3D "the privacy ... of the network" doesn't seem like the concept actually = being described here. Usually we're focused on privacy of individuals, = and confidentiality of corporations (e.g., network operators). =3D Section 2 =3D There are two different definitions offered for "Connectivity." =3D Section 3.2.2 =3D Accessibility is listed twice for "Right to political participation." =3D Section 3.2.3 =3D "For instance, relying on an external server can be bad for freedom of = speech" -- without any further context provided, it's hard to understand = what is meant by an "external" server. =3D Section 4.1.1.1.2 =3D "If a protocol provides insufficient privacy it may stifle speech" -- I = don't think it's the protocol that would be doing the stifling. =3D Section 4.1.1.1.6 =3D Given that censorship is much more narrowly defined than filtering = (presumably, although neither term is explicitly defined in the = document), I think it would be better to use the term censorship rather = than filtering. In some protocol contexts, filtering is an explicit goal = and it has nothing to do with censorship. From nobody Fri Jan 6 01:56:21 2017 Return-Path: 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 48357129400 for ; Fri, 6 Jan 2017 01:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 UNKUPlsnYolh for ; Fri, 6 Jan 2017 01:56:18 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 1EB5C129874 for ; Fri, 6 Jan 2017 01:56:14 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPRFq-0003fV-Tx; Fri, 06 Jan 2017 10:56:11 +0100 To: Stephen Farrell , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> Date: Fri, 6 Jan 2017 10:56:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5nqbS44UgJcubI5j2SeH4fj9AETi9sha4" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 96c675144ba71ec85d2a502517ab107c Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 09:56:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5nqbS44UgJcubI5j2SeH4fj9AETi9sha4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Stephen, Thanks for this, reply inline: On 01/05/2017 05:35 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > Comments on two of your responses below, other text > elided... >=20 > On 05/01/17 16:05, Niels ten Oever wrote: >> On 12/30/2016 03:20 AM, Andrew Sullivan wrote: >=20 >> I think the fact that we're talking for so long about what these could= >> be, makes it really clear that the ethics of Internet protocols are by= >> far not as clear as many who have worked on the early network would ha= ve >> wanted them to be. This can also be seen in the film 'Net of Rights'. >=20 > I don't find the above argument convincing and perhaps for > a reason that's useful to elucidate: we do not know that > the "wanted them to be" above applies. In my own case, I do > have some opinions that you (Niels) would likely call some > relevant ethics. In the IETF context however, I have not > found it necessary that we reach consensus on those. And I > am not at all sure we ought try - I can't see a useful > subset of my or what I imagine are others' ethical opinions > on which it'd be good for the IETF to have reached consensus, > and I really doubt that the IETF would find any such subset > on which it could reach consensus. >=20 Andrew made the point: we already have an ethics (namely an inherent network ethic). You seem to make the point here: we don't need an ethics, which is different. >>> For the draft, a consequence of all the above is that the motivation >>> for the human rights considerations is not clearly stated in terms >>> that a sceptic might endorse. The comparison with the security and >>> privacy considerations is instructive. Those seem, to my eye, to be >>> motivated by the value of security or privacy (as appropriate), but >>> the failure to take them into consideration is framed mostly in terms= >>> of the harm _to the Internet_ that arises if the issue is not taken >>> into account. Perhaps in the case of the hrpc draft the extrinsic >>> motivations are more reasonable, because this is not an IETF >>> document. But if one thinks that technologies are neutral, and that >>> it is the _use_ of the technologies that can trample on rights, the >>> focus on human rights might sound like an attempt to make the IETF >>> into a political actor. >> >> Technology is not neutral, neither is the Internet and neither is the >> IETF. The IETF already is political and also already is a political >> actor. There is are ample examples of that in the book by Laura DeNard= is: >=20 > I'm sorry but I (and I think others) do not agree with you on > this point, no matter how oft asserted, and even though that > literature does exist. >=20 But it would be great if you (and maybe others) provide arguments for it except for repeating the point. We wrote a draft, cited literature, offered more literature, we had several discussions about this at sessions, also at the last one, so at this point I am not sure what I can do to address this. Could you perhaps provide an argument why you think protocols are not political? >> >> DeNardis, Laura. 2009. Protocol Politics: The Globalization of Interne= t >> Governance. Cambridge, MA: MIT Press. >> >> as well as: >> >> DeNardis, Laura. 2014. The Global War for Internet Governance. >> >> I am still waiting for relevant literature that argues that technology= >> is ethically neutral.=20 >=20 > That is not what I claimed. Some technology is not ethically neutral. > But I do assert that IETF technology some is ethically neutral. > You seem to be asserting that no technology can ever be ethically > neutral and I disagree with that. >=20 All technology has the characteristic of ordering and re-ordering the world we live in. It stimulates certain behavior, and it inhibits others. In this way it influences our public and private sphere and thus is political. It does so in major ways, such as where it directly touches upon civil liberties such as privacy and freedom of expression. But it also does so in more subtle ways, via (lack of) availability in local languages, centralized vs distributed solutions, and reliability and performance on high latency networks vs low latency networks. And of course even the possibility of making specific things possible. This is all inherently political. >> We've cited quite a body of literature that argues >> the exact opposite.=20 >=20 > No, you did not provide exact opposites above. Yes, there is a body > of literature that argues as you do. It's fine that we do not all > share the exact same opinions, but would be better if the draft did > reflect that divergence. >=20 I think your argument diverges from the one Andrew makes. If you think we should capture your line of argumentation in the draft, let's have a discussion about it. What kind of protocols do you think are not politica= l? >> Repeating that technology is neutral will not make >> it more true, but I am more than happy to be convinced. >=20 > That was not repeated because it was not stated, by me at least > and nor I think by Andrew. *Some* technology is neutral was my > assertion. >=20 OK - let's work it out! Thanks again! Cheers, Niels > Cheers, > S. >=20 --5nqbS44UgJcubI5j2SeH4fj9AETi9sha4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb2m5AAoJEA7YPzpGisizdBEQAJFMt/gXfoiFQN6GQn2LNEHi 27nu8JkNXoqeJiBIZSIM3mYMcW6yo7oxQU9+ZMmIEPF3lFRGGkE9j1R3OL8FhJT3 53HKmBwbOJBb24atPVO2pyg31zXfLPSJVv6pcCdf9r9oi046RHkIYD/E507KSung A9Q2MvLftQUui7kp/o7RhjBIw5BsGFC4TbHwCHECBQL8nu+3sKNo3NkBoa+VQu78 HWt9ste3hxhcIVb11+9Ybj8szL+2xgpuiVjJfE3FEXO5zE4TsqDKaAY6auz5et0Y 9zanCX51EqrNKe+zGeRXRVSJ1VRfFuJX+8YxWyqMyDkETbidPbmg8EHbtK6Y9Ez/ PS9BKnKOG62kDK1j7mn39nsWI6+b2K0qXlPsnZlzdlS3+GLmXCicYhB5kj/++2cT i/A1J44BIISd0YZeOe97h/7aLs91pD2S+GKZHDqwmLMUMzqHZLFh0iGmXsxtabRG CVe8hbufBkYXWQJeVcUJ3ouCOsTepbXLqIMFNYf0oaVKQ1z3l22ARKmcx6AJZ4Ee IGPLy5M14LndOe5sjvspG9NpmyVma8KIFRQ2OznHIzhm1aLAFKKJ9dvdo4KvboKA 7+txoRwWPcp64R8vuExoQCplGzMFFSoDSEUdGuRpGZ4LGtAm6qdhvxqcBim0Wehd vgvv6X4EpWp/YyBmsYx8 =Ok4K -----END PGP SIGNATURE----- --5nqbS44UgJcubI5j2SeH4fj9AETi9sha4-- From nobody Fri Jan 6 03:20:48 2017 Return-Path: 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 B0DD41294EE for ; Fri, 6 Jan 2017 03:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 wCZsGyZWPOqY for ; Fri, 6 Jan 2017 03:20:44 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593AB1204D9 for ; Fri, 6 Jan 2017 03:20:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5D3DCBED9; Fri, 6 Jan 2017 11:20:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZtwZw7gHpV6; Fri, 6 Jan 2017 11:20:37 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 95EECBE5D; Fri, 6 Jan 2017 11:20:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483701637; bh=fbyOp5h6/JrC9T1T7nBCgeiXk0dN0tmWSArgBniB7ps=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tRv6eHaFaA86spNZ6Prz3FW/E4M6s5f4A4k47LP+JcBxVLYUzUevc5C5xXyZ1VLfl mtytJ7SCBWMZvfNq48Y/BS05v6fs0kwwgBbPZFs9skIuCC3KUhs8gHWCsUFp548e9F hGly8Ka3VZIeG4CbBZZgRmFnqsMPvbbWjklW6Aus= To: Niels ten Oever , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> Date: Fri, 6 Jan 2017 11:20:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SBLdarmPabUr8aCLEg4TOaSWgXgMsetHo" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 11:20:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SBLdarmPabUr8aCLEg4TOaSWgXgMsetHo Content-Type: multipart/mixed; boundary="EEqLc1tOnxonsNmcoDojjDwlbHV23rE4q"; protected-headers="v1" From: Stephen Farrell To: Niels ten Oever , hrpc@irtf.org Message-ID: <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> In-Reply-To: <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> --EEqLc1tOnxonsNmcoDojjDwlbHV23rE4q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 06/01/17 09:56, Niels ten Oever wrote: > Hiya Stephen, >=20 > Thanks for this, reply inline: > On 01/05/2017 05:35 PM, Stephen Farrell wrote: >> >> Hiya, >> >> Comments on two of your responses below, other text >> elided... >> >> On 05/01/17 16:05, Niels ten Oever wrote: >>> On 12/30/2016 03:20 AM, Andrew Sullivan wrote: >> >>> I think the fact that we're talking for so long about what these coul= d >>> be, makes it really clear that the ethics of Internet protocols are b= y >>> far not as clear as many who have worked on the early network would h= ave >>> wanted them to be. This can also be seen in the film 'Net of Rights'.= >> >> I don't find the above argument convincing and perhaps for >> a reason that's useful to elucidate: we do not know that >> the "wanted them to be" above applies. In my own case, I do >> have some opinions that you (Niels) would likely call some >> relevant ethics. In the IETF context however, I have not >> found it necessary that we reach consensus on those. And I >> am not at all sure we ought try - I can't see a useful >> subset of my or what I imagine are others' ethical opinions >> on which it'd be good for the IETF to have reached consensus, >> and I really doubt that the IETF would find any such subset >> on which it could reach consensus. >> >=20 > Andrew made the point: we already have an ethics (namely an inherent > network ethic). I think the "we" above is ambiguous and that that is part of the reason we're still discussing this. >=20 > You seem to make the point here: we don't need an ethics, which is > different. That was not my point. I said I don't believe the IETF needs to reach consensus on a thing called ethics. I further said that I doubt that the IETF could, in practice, reach rough consensus on such a thing. That does not mean that IETF participants do ot do not "need an ethics." I said nothing about that, except for my own case where I do kinda know. >=20 >=20 >>>> For the draft, a consequence of all the above is that the motivation= >>>> for the human rights considerations is not clearly stated in terms >>>> that a sceptic might endorse. The comparison with the security and >>>> privacy considerations is instructive. Those seem, to my eye, to be= >>>> motivated by the value of security or privacy (as appropriate), but >>>> the failure to take them into consideration is framed mostly in term= s >>>> of the harm _to the Internet_ that arises if the issue is not taken >>>> into account. Perhaps in the case of the hrpc draft the extrinsic >>>> motivations are more reasonable, because this is not an IETF >>>> document. But if one thinks that technologies are neutral, and that= >>>> it is the _use_ of the technologies that can trample on rights, the >>>> focus on human rights might sound like an attempt to make the IETF >>>> into a political actor. >>> >>> Technology is not neutral, neither is the Internet and neither is the= >>> IETF. The IETF already is political and also already is a political >>> actor. There is are ample examples of that in the book by Laura DeNar= dis: >> >> I'm sorry but I (and I think others) do not agree with you on >> this point, no matter how oft asserted, and even though that >> literature does exist. >> >=20 > But it would be great if you (and maybe others) provide arguments for i= t > except for repeating the point. We both seem to be accusing one another of simply repeating arguments. That usually means we're not really reading the other's arguments;-) >=20 > We wrote a draft, cited literature, offered more literature, we had > several discussions about this at sessions, also at the last one, so at= > this point I am not sure what I can do to address this. >=20 > Could you perhaps provide an argument why you think protocols are not > political? It is below but once more: I assert that some IETF technology is political but some is not political. Here's an example. [1] While there were a bunch of "corporate" politics around DTN, (not human rights related, but down to who wanted to promote which technology where and when) [1] was not at all involved in that. You seem to be asserting that even [1] is political. Please explain to me how that is true for that RFC as I just don't see that. If you assert that [1] is political because everything in the entire universe is political then that seems to me to mean that there is no need for the "protocols are politics" statements in the draft - one tautology less would surely improve things if you are correct. (And one incorrect statement less certainly would from my POV:-) If you can't say why [1] is political, then it seems to me you have to accept that not all IETF technology is political. (Unless you are asserting that "all IETF technology is political even though it is not possible to say why for some RFCs," which'd be quite odd;-) Cheers, S. [1] https://tools.ietf.org/html/rfc6256 >=20 >=20 >>> >>> DeNardis, Laura. 2009. Protocol Politics: The Globalization of Intern= et >>> Governance. Cambridge, MA: MIT Press. >>> >>> as well as: >>> >>> DeNardis, Laura. 2014. The Global War for Internet Governance. >>> >>> I am still waiting for relevant literature that argues that technolog= y >>> is ethically neutral.=20 >> >> That is not what I claimed. Some technology is not ethically neutral. >> But I do assert that IETF technology some is ethically neutral. >> You seem to be asserting that no technology can ever be ethically >> neutral and I disagree with that. >> >=20 > All technology has the characteristic of ordering and re-ordering the > world we live in. It stimulates certain behavior, and it inhibits > others. In this way it influences our public and private sphere and thu= s > is political. >=20 > It does so in major ways, such as where it directly touches upon civil > liberties such as privacy and freedom of expression. But it also does s= o > in more subtle ways, via (lack of) availability in local languages, > centralized vs distributed solutions, and reliability and performance o= n > high latency networks vs low latency networks. >=20 > And of course even the possibility of making specific things possible. >=20 > This is all inherently political. >=20 >>> We've cited quite a body of literature that argues >>> the exact opposite.=20 >> >> No, you did not provide exact opposites above. Yes, there is a body >> of literature that argues as you do. It's fine that we do not all >> share the exact same opinions, but would be better if the draft did >> reflect that divergence. >> >=20 > I think your argument diverges from the one Andrew makes. If you think > we should capture your line of argumentation in the draft, let's have a= > discussion about it. What kind of protocols do you think are not politi= cal? >=20 >=20 >>> Repeating that technology is neutral will not make >>> it more true, but I am more than happy to be convinced. >> >> That was not repeated because it was not stated, by me at least >> and nor I think by Andrew. *Some* technology is neutral was my >> assertion. >> >=20 > OK - let's work it out! >=20 > Thanks again! >=20 > Cheers, >=20 > Niels >=20 >=20 >> Cheers, >> S. >> >=20 --EEqLc1tOnxonsNmcoDojjDwlbHV23rE4q-- --SBLdarmPabUr8aCLEg4TOaSWgXgMsetHo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYb32EAAoJEC88hzaAX42iY+AIAIqR6PVRbBE2rF6z5HCafPFX e0HBqq9kXjuW5PIUkTd5Kki06dfChgTqOhVegH3qwP+CxuN8gjiEDFpouLyh0f/U istWarBET1nyeSPvElb2C+lsIWTqR8/h+PIyBgBieAsUgiRmGVPKzvWYCV1bODZw mhqlgiod09WRmsrhhAVkVLZK5gEYfv5BN5femuEh8BhGss6Q/bp++bm/G22+04WT LkQngnmGgX+JcqgOl4hyVJErmrpr3zOP50pRcgWqCWWcsf+3yAIv6tCfr+/X4MnG ODLo5mRdHzP0pBbZhbs2f40l/QTKHCraq45ndKzhodfpClGrc3ROBCY0KN3J9uI= =E0Yx -----END PGP SIGNATURE----- --SBLdarmPabUr8aCLEg4TOaSWgXgMsetHo-- From nobody Fri Jan 6 04:08:09 2017 Return-Path: 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 B5115129CA8 for ; Fri, 6 Jan 2017 04:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.89 X-Spam-Level: X-Spam-Status: No, score=-4.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=He01Tor8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=W+8DV/2C 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 O2I4enUd6ClQ for ; Fri, 6 Jan 2017 04:08:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D7B1294AE for ; Fri, 6 Jan 2017 04:08:05 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v06C7lvE004409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2017 04:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1483704475; x=1483790875; bh=QK6NXF8atnn90WQSJns91JKo3vj7a14AumiT9JPrOrg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=He01Tor8kGAwUiVaARtxlSwuzijVX5WlnNz07aIT6auJW0FIB/YpHMtzagcjrGCLd AAp00E4PvMiJYy3XLtrkE3goSwokMRB03hqPcnu5M4htuKExHMtyqVauOh3W8YnZY4 bpWhL/NO3nr8MxmFjavepcEnZHxBdpLJEviu9/e0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1483704475; x=1483790875; i=@elandsys.com; bh=QK6NXF8atnn90WQSJns91JKo3vj7a14AumiT9JPrOrg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W+8DV/2CCZCRyXRD+00z+72BTmsh9LKJSTfCSZkB+VAZxPf4U70ziEUP/QxZnwbPh bAzC/C8Wz0yjXbpCeHfvqC9oTTCAy+l8B+4OqCaSd8xxRXsVhUwdtwV8gcc725MeJT ZQV9xsnK4nE+kF+XDsBSdnEO43mJi9lu4auTERLA= Message-Id: <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2017 04:03:04 -0800 To: Niels ten Oever , hrpc@irtf.org From: S Moonesamy In-Reply-To: <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Corinne Cath Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 12:08:08 -0000 Hi Niel, At 06:28 05-01-2017, Niels ten Oever wrote: >That is why reviews are very much welcomed and we've done considerable >outreach to get as much reviews from different perspectives on this draft. Ok. >It can also be said that Human Rights (as laid out in documents like the >UDHR, ICCPR and IECSCR) are the most universal values we have in the world. Within a group of persons of diverse backgrounds, values can raise questions about cultural assimilation. >It will be the consensus of the research group and the people therein. >Nothing more, nothing less. The following is related to the previous paragraph about "values": a rough breakdown of the mailing list discussions shows that there were only participants from North America and Europe. I don't think that is adequate for such a delicate matter. According to Article19, once this document is published its "recommendation could be brought into the IETF to see how Human Rights Protocol Considerations could become inherent part of the standards developing process, which would be a technical translation of Human Rights Impact Assessments as outlines by the UN Guiding Principles for Business and Human Rights". That is not stated in the charter of the Human Rights Protocol Considerations Research Group. >Replace 'real-world' with 'political'. Thanks for the suggestion. I also >used the text that has been suggested by Stephane with this little tweak. Ok. >Are you referring to RFC7258 ? Am not completely sure how it would fit >in here, but text suggestions are always welcome. I was not referring to RFC 7258. The point was about not taking a simplistic approach to security in a high-risk environment. >Default log settings have an impact on privacy, privacyis a human >rights, so I'd say, yes this could be framed as a human rights issue. > >Which does not mean that one should never be able to keep logs, but >rather we should try to keep the storage and collection of Personal >Identifiable Information to a minimum. Logging is not a protocol issue as such as it falls outside the communication boundary which was usually viewed as an IETF matter. There isn't much interest in revisiting old recommendations which may have security implications. >This was badly written, I went with the proposal made my Stephane: I suggest dropping the last sentence and moving the reference to the second sentence. >Interesting. But is this an IETF or a protocol issue? Is this something >that an protocol develop can/should address? This is an IETF issue. The protocol developer may not be available or interested in doing an update. >I think it depends on the conception of non-discrimination and equality >do not apply here, since it is equally miserable for everyone. Ok. >Why could the notification system outlined in RFC6108 not be interpreted >as a protocol? That RFC was published in the Independent Submissions Stream and not by the IETF. The document explicitly states that it is not a standard. To put it simply, there aren't any interoperability considerations. >I do indeed think that export control impact heterogeneity, but I do not >think this can be addressed by protocol designers. I suggest discussing about this with an IETF Security Area Director. >It's not only by society. The less information is known about an >individual, the harder it is to discriminate against them. Therefore the >right to privacy and the right to non-discrimination are linked. I guess that I did not explain my point correctly. In a country which is well-known, the "right" is protected through freedom of speech. Anonymity is not protected through freedom of expression in every country. I agree with your argument that it is about privacy. Mixing this with other "rights" may be suitable when doing advocacy. I don't think that it is fitting in a document about considerations for technical specifications. I'll comment more at the end of this message. >There is indeed also a strong link between non-discrimination and the >right to equality. Ok. The question about "permissionless innovation" was not answered. Is an answer ncessary given that the document describes it as "important". Thank you for the responses. The document comes out as pushing an agenda; which some readers may interpret as the preferred political flavor of the IETF. Instead of explaining human rights in technical terms, it does the reverse by drawing a linkage between a technical decision and one or more rights. I am interested in reading the data set mentioned in Section 3.1.2 as some parts of the document have similarities with promotional material which I have come across in an IETF context. Regards, S. Moonesamy From nobody Fri Jan 6 04:43:59 2017 Return-Path: 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 8BC89129B0B for ; Fri, 6 Jan 2017 04:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 lqs7dH42GZmk for ; Fri, 6 Jan 2017 04:43:56 -0800 (PST) Received: from athene.wzb.eu (athene.wzb.eu [193.174.6.3]) (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 0D8B2129AF7 for ; Fri, 6 Jan 2017 04:43:55 -0800 (PST) To: hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> From: Jeanette Hofmann Message-ID: Date: Fri, 6 Jan 2017 13:43:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-WZB-Virus-Scanned: by Clam AntiVirus at athene.wzb.eu X-Priority: 3 (Normal) Importance: Normal Priority: normal Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 12:43:57 -0000 Hi all, I am not sure if it helps if another person gets involved but I give it a try. I want to comment on two things, the question of ethics and the question of politics. re: ethics >> You seem to make the point here: we don't need an ethics, which is >> different. > > That was not my point. > > I said I don't believe the IETF needs to reach consensus on a > thing called ethics. I further said that I doubt that the IETF > could, in practice, reach rough consensus on such a thing. This point can probably be generalised: There is nearly never consensus on ethics. No group ever agrees on more than single ethical statement. The IETF is no different in this respect from any other collective. Another question would be if the IETF as a group would find it helpful or desirable to regard its technical work within an ethical framework. This could be addressed in the draft document as an open issue requiring further debate. > Re political: As a political scientist I'd like to remind you that there are many different understandings of 'the political'. Political can refer to: 1. how a standard (or any other object) is produced 2. how a standard is put to use 3. how it affects its environment 4. who selects or decides over a standard There are probably more definitions around I am not aware of. From my understanding, the IETF used to distinguish technical from political design criteria. In other words, a choice becomes political when non-technical criteria play a role in or dominate protocol development. This definition would refer to 1 and perhaps 4. While I was doing research on the IETF, I was always interested in how and where its participants draw the line between a technical and a political decision. An easy line to draw was that between the IETF (driven by technical criteria) and the ITU (organised around political motives). Yet, when it comes to contested design issues such as IPv6 (which I studied at that time), the distinction between the technical and the political seems to blur. What is technical from one point of view, may appear political from another. I recall the length of IP addresses to be such a case in point. It is certainly an important professional cornerstone to have a common understanding of the distinction between what is technical and what is political, this does not imply that outsiders would draw the line in the same way. I do agree that to declare everything as political does not help in this context. Yet, I am not sure political/non-political is an inherent quality of a technical standard. It might be something that is rather ascribed to it, depending either on one's definition of the political or on one's position in the development work of the standard. Best, Jeanette From nobody Fri Jan 6 05:08:11 2017 Return-Path: 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 81113129516 for ; Fri, 6 Jan 2017 05:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 9zLbO6p-xRxP for ; Fri, 6 Jan 2017 05:08:07 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 3BF27129434 for ; Fri, 6 Jan 2017 05:08:06 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPUFY-0000Ms-Cm for hrpc@irtf.org; Fri, 06 Jan 2017 14:08:05 +0100 To: hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> Date: Fri, 6 Jan 2017 14:08:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170105165503.GZ12568@mx2.yitter.info> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0qMFAVMLxAh6foNa4XTG6MIpVPGxJ7UD0" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 3ae54bf910e1e25eb5e4f236ee2e7766 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:08:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0qMFAVMLxAh6foNa4XTG6MIpVPGxJ7UD0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andrew, Happy new year! Reply inline: On 01/05/2017 05:55 PM, Andrew Sullivan wrote: > Hi, >=20 > Some further follow up. >=20 > On Thu, Jan 05, 2017 at 05:05:11PM +0100, Niels ten Oever wrote: >>> The trouble shows up early on. For instance, section 1 says, "The >>> purpose of the Internet to be a global network of networks that >>> provides unfettered connectivity to all users and for any content >>> [RFC1958]" >=20 >> I think the sentence 'the community believe that the goals is >> connectivity' is pretty clear here: > [=E2=80=A6] >> >> the first 25 years (or at least not by the IAB). However, in very >> general terms, the community believes that the goal is connectivity= , >> the tool is the Internet Protocol, and the intelligence is end to e= nd >> rather than hidden in the network. >=20 > I think there is a difference between "connectivity" and "unfettered > connectivity to all users and for any content". Indeed, I bet there > are countries today who think they have a goal of connectivity without > having the latter more expansive goal. >=20 > I think this puts the finger on what's bothering me, though: in my > reading the draft is too keen to take the most expansive, > rights-supporting reading of any text even when alternative readings > are available. A more conservative approach to the literature would, > I think, actually make the draft's conclusions stronger. >=20 >> RFC3935 seems to have a bit thicker description here: >> >> The IETF community wants the Internet to succeed because we >> believe that the existence of the Internet, and its influence on= >> economics, communication, and education, will help us to build a= >> better human society. >=20 > This is a claim about what the community that makes up the IETF > believes, not what "the IETF" considered in itself believes. There > may or may not be a difference between those two things. >=20 >> Also the following description seems to negate your statement that the= re >> is such a thing as an inherent network ethic: >> >> These concepts have little to do with the >> technology that's possible, and much to do with the technology that= >> we choose to create. >=20 > Nope, it shows my point. The "we" there are choosing to make > _internetworking_ technology, and that technology might itself have an > inherent ethic. The IETF participants could choose to create > technologies that run against internetworking (arguably, sometimes > they do. One could make the argument -- I've heard people do it -- > that MPLS is not terribly internetty). =20 >=20 I think this para refutes your interpretation: The Internet: A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. The term includes both the "core Internet" (ISP networks) and "edge Internet" (corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices). The Internet is a truly global network, reaching into just about every country in the world. The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society. In the first paragraph the technical aspect is explained (from which you could potentially derive a networking ethic), but the second parapgraph clearly explains a (primitive) external ethic. So If you then continue to explain that this quote: We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create. means that these concepts are derived from an inherent inter-networking ethics, I am afraid I have to disagree. Because there is also an inter-networking solution possible without edge-user empowerment. I also do not think that the 'values' that are referred to here are 'internetworking values'. So here you might be guilty of the overenthusiastic hermeneutics you accused me of earlier ;) >> I think this is a misrepresentation of the draft. There is an explicit= >> difference between 'support human rights' (which would be an advocacy = / >> enforcement position) and 'respect human rights' (which simply ensures= >> that there is no adverse impact on human rights). >=20 > Perhaps (though I confess this distinction is not always quite so > plain to me in the text). But I don't think that this alters the > point I was making, which is that the difference between extrinsic and > concordant values might be important. >=20 >> I would not have a problem with a useable inherent network ethic, if >> there was such a thing. How your concept of an inherent network ethic >> help us with issues like internationalization, universal availability,= >> and accessibility? It completely leaves the human out of the equation,= >> whereas the Internet is about humans, not about the Internet itself. >=20 > I don't think so. The argument, for instance, about why pervasive > monitoring is an attack _on the network_ and not on the users works > the same way. It says (in part) that the attack is on the network > because the pervasive monitoring undermines the utility of and faith > in the network, which thereby reduces the incentives to use it, which > reduces the positive-feedback network effects of the network. That is > _apart from_ the social costs and the attack on human users and so on. >=20 Could you also make the argument in relation to 'Internationalization?' Why would the network care about human parsable languages? The proposed 'network ethic' might provide a solution for some things, but not sufficient. Also, it leaves quite a lot of space for interpretation. What some people think is good for the network, might not be seen the same by others. Also: in your argument you now include 'faith in the network' as part of the 'inherent network ethic', which is I think a bit of a leap, because earlier you seemed to argue that you wanted to leave usage out of the equation. It's starting to become a bit blurry for me here, but maybe that's because I do not sufficiently understand your concept of a 'network ethic'. >> Internet is not an interesting science expiriment (anymore), it is >> mediating central democratic processes, the public debate, and the >> global economy. The Internet does not simply exist for the Internets s= ake. >=20 > The trouble here is that, if _that_ is the basis of internetworking, > then there is a strong position available to sceptics of this draft. > It is that engineers ought to inform but not decide policy debates. > This is the classic technocratic position: that the technocrats advise > policy makers, but themselves never make such policy decisions.=20 You seem to use the term 'technocrats' here as in 'bureaucrats'. Are you describing IETF-ers here as technocrats that take orders from policy makers? I think that kind of goes against 'no kings, no presidents', righ= t? If you look at the discussion between ISO and IETF on the next generation of IP after IPv4 I think this is also not a correct representation. > Of > course, the draft is arguing that this position is wishful thinking, > because protocols are in fact politics anyway. But unless you deal > with the technocratic point of view head on -- and it just rejects the > postwar position about the combination of protocols and politics -- > then the draft will remain subjecto attack from that technocratic > point of view. (More on this below.) >=20 > What you claim above is that the values are in fact all extrinsic. If > that's true, then the debate over which rights and which > interpretation (China's? The US's? NL's or CA's?) of the UDHR ought > to count is something that happens outside the IETF. It remains only > for protocol designers to take these values "into account" somehow. Yes - that is exactly what 'respecting human rights' means! Fully agree! We do not need to (re-)negogiate rights here, we should simply think through what they mean for our field and find procedures to take them into account. >=20 > If, on the other hand, there is a concordant value that flows from > internetworking values themselves, then protocol engineers have a > positive duty when writing Internet protocols to consider those > internetworking values and promote them when possible. I claim (but > it'd be a hard problem to show, I suppose) that these are a concordant > set of values that have the interesting property of supporting a > particular vision of human rights also. Am happy to dig deeper into this, but then we would need a more detailed description of 'internetworking values', and I have thusfar not been able to find a write up of that. I think try to understand a 'networking ethic' or any ethic that has been prevalent in IETF has been what we've been trying to do, but at a certain moment we got stuck because there were so many different intepretations. I think dkg summarized it pretty well in saying: "I am sure there are shared values in the IETF, I also think that we do not have consensus on what these shared values are". These guidelines are a beginning to think about that, without reinventing the wheel, and thus looking at existing standards that are as universal as they get: human rights. If your position is that there is such a think as a networking ethic that has driven the work here for many years, I can write a para about that. Maybe I can offer rewriting the second paragraph of the Literature and Discussion Review: Commercial and political influences on the management of the Internet's infrastructure are well-documented in the academic literature and will thus not be discussed here {{Benkler}} {{Brownetal}} {{Denardis15}} {{Lessig}} {{Mueller}} {{Zittrain}}. It is sufficient to say that the IETF community consistently tries to push back against the standardization of surveillance and certain other issues that negatively influence end-users' experience of and trust in the Internet {{Denardis14}}. The IETF thusfar has formally relied on an ethics that is based on an understanding that the network is its own objective, and the internetworking between networks is the expected result. There have been hints of values that lie beyond the network itself {{RFC1958}} {{RFC3426}}, but these have thusfar not been documented in a detailed manner or resulted in concrete procedures for protocol design, except perhaps for Guidelines of Privacy Considerations {{RFC6973}} and work on Internationalization. The role human rights play in engineering, infrastructure maintenance and protocol design is much less clear. What do you think? I am myself not completely sure of this because the >=20 >> Furthermore, there are many different ways in which inter-connectivity= >> is possible, but it gives very little guidance on the hard choices we >> need to make and the impact they might have. >=20 > It is possible that we are not in alignment about the nature of the > project. The Internet is not merely about inter-connectivity of > nodes. It is about inter-connectivity of networks with a particular > style of inter-connectivity in which the edges have most of the > intelligence, the individual networks interconnect without necessarily > having pre-existing contractual or other such arrangements among them, > and where messages flow from one part of the internetwork to another > without a lot of molestation from intermediate nodes. That's quite a > lot more than inter-connectivity. I agree that inter-connectivity > could, for instance, be achieved by the Catanet approach that a > certain IETF gadfly often promotes, and probably by something like the > old telephone networks suitably updated for packet switching. But > those wouldn't be _internets_, even if they'd be interconnectivity. >=20 I hope the description above covers this. >> So you are arguing here that things actually do exist outside of their= >> context until they are used? And that things do not order reality or >> shape their usage? >=20 > Well, of course, that is (roughly) a metaphysical position that > basically ruled Western philosophy from at least Plato through > Descartes. =20 So you really think it would add to this draft to describe pre-Kantian epistemology and subject-object relations here? We're talking intelectual history far before Internet Protocols or the Internet at large, so am not sure if it's relevant. If there were modern literature that is making this case in relation to the Internet I'd be more than happy to discuss, and then I also think we should. I just have not been able to find it. > So it seems a little surprising to wave it away with a > couple rhetorical questions, especially because it undergirds the > strict separation of roles that is implied in the technocratic stance. >=20 I am simply not sure whether there still is such a thing as a technocratic stance in contemporary Internet and technology related literature. >> I am afraid you're right that your position is a position in line with= >> Aristotelian ethics as they were current before the Second World War. >> But scienctific literature and opinion has quite significantly changed= >> since then, partially because of the use of technology in the Second >> World War. >=20 > If your argument is at bottom that the old position is wrong because > it's old, then I fear we are far apart. I am not arguing that old > position is true. I am arguing that it needs to be taken seriously, > and that the draft doesn't do so, and therefore the draft is weaker > than it needs to be. >=20 I hope my text above helps to address that. >> The open nature of the initial technical design (open standards, open >> source, etc) fostered freedom of communication as a core value, the ai= m >> was to create a network which would enable everyone to connect and to >> exchange data, information and code. >=20 > I am always leery of claims about the aim of actors in the past (and > ironically, I get even more leery when many of those actors are still > around, because I know my own motivations for what I did in the past > are now quite fuzzy to me, and I tell stories to myself about how I > got to this place where I am). So I'd suggest this instead: >=20 >=20 > The open nature of the initial technical design and its open > standards, as well as developments like open source, fostered > freedom of communication. What emerged was a network of networks > that could enable everyone to connect and to exchange data, > information and code. For many, enabling such conections became a > core value. Excellent - added! Cheers, Niels >=20 > Best regards, >=20 > A >=20 --0qMFAVMLxAh6foNa4XTG6MIpVPGxJ7UD0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb5azAAoJEA7YPzpGisizqj0P/00lXuJhgC1WwWxvd+N/5uOm 6VdsabeyJKiT/Q3tmKiTIhkYzgKUxlXEECkFAePl50k3/7xP5toGYTh8Xu9wZpjh zYoaeW2AU86XzmSWlku6dBECQBibiRfqdof/sC/lwu+qQ6LLkKIeGMT3pEA9J6Ux hNeKKFXQovi6e/g5pDxpS2P7Ah8UxI9tuUhHYMr6sX+ajEhR5MIVAgUXtLdWgJa2 SfdoovfWX3EFAz+J1EOHk/BhHr5UxVAOhB9Erqm3ziQFpVaeriByua+n88lmg13t ro5J2UN6x7mMQBqxrDe+jMAh3XmW9I5SCWkJzT0gXmQp54pdCTkNlP6sFQqkcytv z4f1fif2izka/sGogd6KLoZTW4Uh3uhgVRMdLhCaeSHWJAn+cyRF6TDMwzApLkDU m4yeIQhYql08M4arRYbbkJwW8UX4U6ejsJg8I/1g6l3+lvaM4FOIXbo8+JgZ5bA/ sqTWyttDgCXgFnyHdDd2QK8RiGqUv4ZjWSUdqlr6Z5snPBsCaKwA9OF0UGZdgWWD /ekRNEEtr9riIxhw5ju/N4Ib5Je1A1Jd/ka+SU3UDzimTEhNIRyXEqVica8q9YGO 1dtwPGiDcskj5mXcHclyFTKJeXRyPIjFzOo3fJCtWTas5qoOlWG7dz/8mbIsd5jG 3Mg+kVa30GdKtQRti4cM =SYNN -----END PGP SIGNATURE----- --0qMFAVMLxAh6foNa4XTG6MIpVPGxJ7UD0-- From nobody Fri Jan 6 05:37:20 2017 Return-Path: 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 BD63C129B0F for ; Fri, 6 Jan 2017 05:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 KAByOhbdFQ4G for ; Fri, 6 Jan 2017 05:37:17 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 2C25512950E for ; Fri, 6 Jan 2017 05:37:16 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPUhi-0007FT-8J; Fri, 06 Jan 2017 14:37:10 +0100 To: S Moonesamy , hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> Date: Fri, 6 Jan 2017 14:37:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N4D9umiodSXmBixN1t6FGkLEveq2pLkW2" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: ff8282cba176f16c0cd93a6055202d23 Archived-At: Cc: Corinne Cath Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:37:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N4D9umiodSXmBixN1t6FGkLEveq2pLkW2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hiya, << snipping the resolved parts>> On 01/06/2017 01:03 PM, S Moonesamy wrote: >> It can also be said that Human Rights (as laid out in documents like t= he >> UDHR, ICCPR and IECSCR) are the most universal values we have in the >> world. >=20 > Within a group of persons of diverse backgrounds, values can raise > questions about cultural assimilation. >=20 I think this draft does exactly the opposite, but please educate me in how you think this happens. May I also point to the report by the UN Special Rapporteur which made the point about responsibility of standards bodies vis a vis freedom of expression and other human rights, which has been adopted by the Human Rights Council. So this is hardly a concern of a geographically limited group. http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/Privatesectorinthedig= italage.aspx >> It will be the consensus of the research group and the people therein.= >> Nothing more, nothing less. >=20 > The following is related to the previous paragraph about "values": a > rough breakdown of the mailing list discussions shows that there were > only participants from North America and Europe. I don't think that is= > adequate for such a delicate matter. >=20 I don't think that is true. We've had involvement in the discussion from people from all continents and have also tried to broaden the input by doing interviews, next to the discussions in the RG sessions of course. > According to Article19, once this document is published its > "recommendation could be brought into the IETF to see how Human Rights > Protocol Considerations could become inherent part of the standards > developing process, which would be a technical translation of Human > Rights Impact Assessments as outlines by the UN Guiding Principles for > Business and Human Rights". That is not stated in the charter of the > Human Rights Protocol Considerations Research Group. >=20 I think the key word in that sentence is _could_. I do not see a discrepancy between the charter and that remark. >=20 >> Are you referring to RFC7258 ? Am not completely sure how it would fit= >> in here, but text suggestions are always welcome. >=20 > I was not referring to RFC 7258. The point was about not taking a > simplistic approach to security in a high-risk environment. >=20 Then I do not get the point. Could you restate it or offer text? >> Default log settings have an impact on privacy, privacyis a human >> rights, so I'd say, yes this could be framed as a human rights issue. >> >> Which does not mean that one should never be able to keep logs, but >> rather we should try to keep the storage and collection of Personal >> Identifiable Information to a minimum. >=20 > Logging is not a protocol issue as such as it falls outside the > communication boundary which was usually viewed as an IETF matter.=20 > There isn't much interest in revisiting old recommendations which may > have security implications. >=20 I agree this is an issue, but not within the scope of this draft. >> This was badly written, I went with the proposal made my Stephane: >=20 > I suggest dropping the last sentence and moving the reference to the > second sentence. >=20 So you propose changing: Does your protocol have text strings that have to be understood or entered by humans? Does your protocol allow Unicode? If so, do you have accept texts in one charset (which must be UTF-8), or several (which is dangerous for interoperability)? If character sets or encodings other than UTF-8 are allowed, does your protocol mandate a proper tagging of the charset? Did you have a look at {{RFC6365}}? I think the last sentence add useful information. Why leave it out? >> Interesting. But is this an IETF or a protocol issue? Is this somethin= g >> that an protocol develop can/should address? >=20 > This is an IETF issue. The protocol developer may not be available or > interested in doing an update. >=20 I agree this is an IETF-wide issue. But that also makes it fall outside of the scope of this draft. >> Why could the notification system outlined in RFC6108 not be interpret= ed >> as a protocol? >=20 > That RFC was published in the Independent Submissions Stream and not by= > the IETF. The document explicitly states that it is not a standard. T= o > put it simply, there aren't any interoperability considerations. > That makes it not a standard, but it is still a protocol. I tihnk this exactly shows how a protocol can make use of permissionless innovation to combine uses of different protocols in other ways than it was originally intended. >> I do indeed think that export control impact heterogeneity, but I do n= ot >> think this can be addressed by protocol designers. >=20 > I suggest discussing about this with an IETF Security Area Director. >=20 Stephen? >> It's not only by society. The less information is known about an >> individual, the harder it is to discriminate against them. Therefore t= he >> right to privacy and the right to non-discrimination are linked. >=20 > I guess that I did not explain my point correctly. In a country which > is well-known, the "right" is protected through freedom of speech.=20 > Anonymity is not protected through freedom of expression in every > country. I agree with your argument that it is about privacy. Mixing > this with other "rights" may be suitable when doing advocacy. I don't > think that it is fitting in a document about considerations for > technical specifications. I'll comment more at the end of this message= =2E >=20 Am not sure I understand this remark. > The question about "permissionless innovation" was not answered. Is an= > answer ncessary given that the document describes it as "important". >=20 Which question? There is a definition, there is an explanation among different topics (connectivity, open standards, adaptability). > Thank you for the responses. The document comes out as pushing an > agenda; which some readers may interpret as the preferred political > flavor of the IETF. Instead of explaining human rights in technical > terms, it does the reverse by drawing a linkage between a technical > decision and one or more rights. =20 That is quite a strong denounciation of the methodology. Could you perhaps be a bit more detailed about this claim? > I am interested in reading the data > set mentioned in Section 3.1.2=20 Have you watched Net of Rights (https://hrpc.io/net-of-rights) ? A lot of the interviews have culminated in that. > as some parts of the document have > similarities with promotional material which I have come across in an > IETF context. What promotional material are you aluding to? Best, Niels >=20 > Regards, > S. Moonesamy --N4D9umiodSXmBixN1t6FGkLEveq2pLkW2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb52FAAoJEA7YPzpGisizhn8QAIR3SHPpcqUCp2wyUlvNZ270 Iyxo+lMYUfOeysIcZlqjVwYhgxhPAfvvuIZnaS8smcOQMd6uX80inNJuI2o9PNTQ a9wQ63GZNfXUrvCgG5s6AQfbPmPhmKc6uI/LLZCMCQpNKIsHgLPD6XDLL452+4ec clLJ9WW9VcglQG165o0ftoV3o/bX5psty8Z6e8X9bVhPvLDF8mC0hKC22+g/Tl0i vBWS1rGM7T2vzoPpZ43aGldiiwXM4Kjao/xE4sy9rxoP95RNPSc+rzzEhUCT0WJQ 8+R51cLwUoJ+QZa/uqsMCTNAWfDpHD4ixw2yrPlTC7BM6DnyiwCEgOuZnBvu4rf4 w/hIfsABf5qHS8o1nlCzFTVHqdD7rFsnt3lIHr11Wlec+g1xZcS7P7B0JFzqXOKa zRiUZRTGXexXgTP8AHHmbyyoG1riWUR41yMTo2+xvkqfAnVKbP5FJyGTtGPwGvjv qEqILOC5IHh667OSnrsLsSUvdobsVEbYp45r5pdjkiGCL1qalH+mtndmaUJnDZZR OijVj7Uo8fxsCrPG/paKvnc0Nc/7XGzFmaaN2ToM3l5aDqbnWotxY8+DpmOwy/Yt sErofzIsRRaEw/wZwfQLKTDJgf208/+fSDEJC3XS7biyi6R+yck6m6R3PO0lcoFI 8lsMz33gS/Gee9XZSxj0 =4cm5 -----END PGP SIGNATURE----- --N4D9umiodSXmBixN1t6FGkLEveq2pLkW2-- From nobody Fri Jan 6 05:49:41 2017 Return-Path: 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 009751294FB for ; Fri, 6 Jan 2017 05:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0uZYJgWLPUlU for ; Fri, 6 Jan 2017 05:49:39 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 0A45F12711D for ; Fri, 6 Jan 2017 05:49:38 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPUtl-0001zj-2z for hrpc@irtf.org; Fri, 06 Jan 2017 14:49:37 +0100 To: hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <878b61b3-de97-c578-36b1-23c1f12fdc87@article19.org> Date: Fri, 6 Jan 2017 14:49:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="befIfjk4b6JKGWhkvsPobgkflXxDVgIra" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 1a05470216d0106dc91b6ca0d322f745 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:49:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --befIfjk4b6JKGWhkvsPobgkflXxDVgIra Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jeanette, On 01/06/2017 01:43 PM, Jeanette Hofmann wrote: > Hi all, >=20 > I am not sure if it helps if another person gets involved but I give it= > a try. >=20 > I want to comment on two things, the question of ethics and the questio= n > of politics. >=20 >=20 > re: ethics >=20 >>> You seem to make the point here: we don't need an ethics, which is >>> different. >> >> That was not my point. >> >> I said I don't believe the IETF needs to reach consensus on a >> thing called ethics. I further said that I doubt that the IETF >> could, in practice, reach rough consensus on such a thing. >=20 > This point can probably be generalised: There is nearly never consensus= > on ethics. No group ever agrees on more than single ethical statement. > The IETF is no different in this respect from any other collective. > Another question would be if the IETF as a group would find it helpful > or desirable to regard its technical work within an ethical framework. > This could be addressed in the draft document as an open issue requirin= g > further debate. +1 that is what we aim to do here (in my understanding). >> >=20 > Re political: >=20 > As a political scientist I'd like to remind you that there are many > different understandings of 'the political'. >=20 > Political can refer to: > 1. how a standard (or any other object) is produced > 2. how a standard is put to use > 3. how it affects its environment > 4. who selects or decides over a standard >=20 > There are probably more definitions around I am not aware of. From my > understanding, the IETF used to distinguish technical from political > design criteria. In other words, a choice becomes political when > non-technical criteria play a role in or dominate protocol development.= > This definition would refer to 1 and perhaps 4. >=20 > While I was doing research on the IETF, I was always interested in how > and where its participants draw the line between a technical and a > political decision. An easy line to draw was that between the IETF > (driven by technical criteria) and the ITU (organised around political > motives). Yet, when it comes to contested design issues such as IPv6 > (which I studied at that time), the distinction between the technical > and the political seems to blur. What is technical from one point of > view, may appear political from another. I recall the length of IP > addresses to be such a case in point. >=20 > It is certainly an important professional cornerstone to have a common > understanding of the distinction between what is technical and what is > political, this does not imply that outsiders would draw the line in th= e > same way. >=20 > I do agree that to declare everything as political does not help in thi= s > context. Yet, I am not sure political/non-political is an inherent > quality of a technical standard. It might be something that is rather > ascribed to it, depending either on one's definition of the political o= r > on one's position in the development work of the standard. >=20 Thanks for this! Let's try to bring the discussion back to the draft. I think the paragraph people have issues with is this one: Protocols and standards are regularly seen as merely performing technical functions. However, these protocols and standards do not exist outside of their technical context nor outside of their political, historical, economic, legal or cultural context. This is best exemplified by the way in which protocols have become part and parcel of political processes and public policies: one only has to look at the IANA transition, the RFC on pervasive monitoring or global innovation policy for concrete examples {{Denardis15}}. To quote {{Abbate}}: "protocols are politics by other means". This statement confers that protocols are based on decision making, most often by humans. In this process the values and ideas about the role that a particular technology should perform in society is embedded into the design. Often these design decisions are part pure-technical, and part inspired by certain world view of how technology should function that is inspired by personal and political views. Since the late 1990's a burgeoning group of academics and practitioners researched questions surrounding the societal impact of protocols, and the politics of protocols. These studies vary in focus and scope: some focus on specific standards {{Davidsonetal}} {{Musiani}}, others look into the political, legal, commercial or social impact of protocols {{BrownMarsden}} {{Lessig}}, {{Mueller}} and yet others look at how the engineers' personal set of values get translated into technology {{Abbate}},{{CathFloridi}} {{Denardis15}} I think this passes the test set by Jeanette, no? I think it would help if we concretely look at text instances that are problematic within this frame instead of continuing a more abstract discussion. I hope that helps= =2E Best, Niels > Best, Jeanette >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --befIfjk4b6JKGWhkvsPobgkflXxDVgIra Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb6BwAAoJEA7YPzpGisizZcIP/RmAoEGZnCB3LgbWufhpUcxm MObip8T/HrnIh7AZMzEu0BgVam+/2PW7HrDtO+ti+6SK76tlaPcs711SvwMS7clG Bt6Akkb3cuO3/N5h3NlowyA47GFsGkey2/ppPQswKaSsatfz092URVY+u78Yfur0 aNJAFklnv+53dg5bZZjkaL3LDZwQoxtl19vj3wYcGN44nn8bQUWwVDNnAOg/d+vR IOf5DNqFXnGkQw2h9ROWnGm1xrk9Yv0MRCMunHdA+eDboCqsWN/uyPn5EIdnUKzb pD9gbb5zPKRSstVltFfQTF9DGArjOo/B8QMvUb/KNnyRhUowbcysAe36rq9Ak/WH mel9q43s0lpfFay0lMpOQyWS07PMvDstNLWtc6tDKWlIskQLmgKHnfGVU/Cd/OIN qaPYXxiVlvzmnAdjXjEcXMfwNxt1d0qnElPjWt7vC6SZhglN0QQWtm0QqI0dENdB 4hBHNjQLvWBwM08wiR4BeaN1OTNMYO/j2TKY4p7IvCgimu7CzYkZYbro2tzRcCrw Kw/rOH0U+ZSFBw8+mhy7PFgoyvM6RRTXZvS8YkWKz77SKFmpO1j4wc0W9MslmLwX yOTGSRVPR2dlstl6DHwYJrceASLRwBTeI4V6dln4QdAQsVllbzC5qMBQIX4uI48E YntiAFEsw60U0fQzbyqI =1TTv -----END PGP SIGNATURE----- --befIfjk4b6JKGWhkvsPobgkflXxDVgIra-- From nobody Fri Jan 6 05:54:01 2017 Return-Path: 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 B8EF0129B12 for ; Fri, 6 Jan 2017 05:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 yurrQe-B_30b for ; Fri, 6 Jan 2017 05:53:58 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 6EDEE129B09 for ; Fri, 6 Jan 2017 05:53:58 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPUxw-0002yS-DA; Fri, 06 Jan 2017 14:53:56 +0100 To: Stephen Farrell , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> Date: Fri, 6 Jan 2017 14:53:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f8hXua1BLpxCSNnIRm67Jq3oB55oU1nIj" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 2d9f92a6a8fd5960702c593e69d2c65b Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:53:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f8hXua1BLpxCSNnIRm67Jq3oB55oU1nIj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/06/2017 12:20 PM, Stephen Farrell wrote: > On 06/01/17 09:56, Niels ten Oever wrote: >> On 01/05/2017 05:35 PM, Stephen Farrell wrote: >>> On 05/01/17 16:05, Niels ten Oever wrote: >>>> On 12/30/2016 03:20 AM, Andrew Sullivan wrote: >>> >>>> I think the fact that we're talking for so long about what these cou= ld >>>> be, makes it really clear that the ethics of Internet protocols are = by >>>> far not as clear as many who have worked on the early network would = have >>>> wanted them to be. This can also be seen in the film 'Net of Rights'= =2E >>> >>> I don't find the above argument convincing and perhaps for >>> a reason that's useful to elucidate: we do not know that >>> the "wanted them to be" above applies. In my own case, I do >>> have some opinions that you (Niels) would likely call some >>> relevant ethics. In the IETF context however, I have not >>> found it necessary that we reach consensus on those. And I >>> am not at all sure we ought try - I can't see a useful >>> subset of my or what I imagine are others' ethical opinions >>> on which it'd be good for the IETF to have reached consensus, >>> and I really doubt that the IETF would find any such subset >>> on which it could reach consensus. >>> >> >> Andrew made the point: we already have an ethics (namely an inherent >> network ethic). >=20 > I think the "we" above is ambiguous and that that is part of > the reason we're still discussing this. >=20 I think the 'network ethic' part is more ambiguous, no? I think the target group, or rather the 'we', are protocol developers in the IETF. >> >> You seem to make the point here: we don't need an ethics, which is >> different. >=20 > That was not my point. >=20 > I said I don't believe the IETF needs to reach consensus on a > thing called ethics. I further said that I doubt that the IETF > could, in practice, reach rough consensus on such a thing. >=20 > That does not mean that IETF participants do ot do not "need > an ethics." I said nothing about that, except for my own case > where I do kinda know. >=20 I agree we do not need consensus on a full set of ethics (we probably never will), discussing an ethical framework, guidelines, and a way to document choices might be useful though, no? >> Could you perhaps provide an argument why you think protocols are not >> political? >=20 > It is below but once more: I assert that some IETF technology > is political but some is not political. >=20 > Here's an example. [1] While there were a bunch of "corporate" > politics around DTN, (not human rights related, but down to who > wanted to promote which technology where and when) [1] was not > at all involved in that. >=20 > You seem to be asserting that even [1] is political. Please > explain to me how that is true for that RFC as I just don't see > that. >=20 > If you assert that [1] is political because everything in the > entire universe is political then that seems to me to mean that > there is no need for the "protocols are politics" statements in > the draft - one tautology less would surely improve things if > you are correct. (And one incorrect statement less certainly > would from my POV:-) >=20 > If you can't say why [1] is political, then it seems to me you > have to accept that not all IETF technology is political. (Unless > you are asserting that "all IETF technology is political even > though it is not possible to say why for some RFCs," which'd be > quite odd;-) >=20 I am tempted to respond, but.... in the draft there is no sentence that says 'protocols are political'. Shall we go back to the text of the draft and see what issues there are in there? I think it's concentrated in this para: Protocols and standards are regularly seen as merely performing technical functions. However, these protocols and standards do not exist outside of their technical context nor outside of their political, historical, economic, legal or cultural context. This is best exemplified by the way in which protocols have become part and parcel of political processes and public policies: one only has to look at the IANA transition, the RFC on pervasive monitoring or global innovation policy for concrete examples {{Denardis15}}. To quote {{Abbate}}: "protocols are politics by other means". This statement confers that protocols are based on decision making, most often by humans. In this process the values and ideas about the role that a particular technology should perform in society is embedded into the design. Often these design decisions are part pure-technical, and part inspired by certain world view of how technology should function that is inspired by personal and political views. Since the late 1990's a burgeoning group of academics and practitioners researched questions surrounding the societal impact of protocols, and the politics of protocols. These studies vary in focus and scope: some focus on specific standards {{Davidsonetal}} {{Musiani}}, others look into the political, legal, commercial or social impact of protocols {{BrownMarsden}} {{Lessig}}, {{Mueller}} and yet others look at how the engineers' personal set of values get translated into technology {{Abbate}},{{CathFloridi}} {{Denardis15}} {{WynsbergheMoura}}. Is your main problem with the quote: "protocols are politics by other means" ? Best, Niels > Cheers, > S. >=20 > [1] https://tools.ietf.org/html/rfc6256 >=20 >> >> >>>> >>>> DeNardis, Laura. 2009. Protocol Politics: The Globalization of Inter= net >>>> Governance. Cambridge, MA: MIT Press. >>>> >>>> as well as: >>>> >>>> DeNardis, Laura. 2014. The Global War for Internet Governance. >>>> >>>> I am still waiting for relevant literature that argues that technolo= gy >>>> is ethically neutral.=20 >>> >>> That is not what I claimed. Some technology is not ethically neutral.= >>> But I do assert that IETF technology some is ethically neutral. >>> You seem to be asserting that no technology can ever be ethically >>> neutral and I disagree with that. >>> >> >> All technology has the characteristic of ordering and re-ordering the >> world we live in. It stimulates certain behavior, and it inhibits >> others. In this way it influences our public and private sphere and th= us >> is political. >> >> It does so in major ways, such as where it directly touches upon civil= >> liberties such as privacy and freedom of expression. But it also does = so >> in more subtle ways, via (lack of) availability in local languages, >> centralized vs distributed solutions, and reliability and performance = on >> high latency networks vs low latency networks. >> >> And of course even the possibility of making specific things possible.= >> >> This is all inherently political. >> >>>> We've cited quite a body of literature that argues >>>> the exact opposite.=20 >>> >>> No, you did not provide exact opposites above. Yes, there is a body >>> of literature that argues as you do. It's fine that we do not all >>> share the exact same opinions, but would be better if the draft did >>> reflect that divergence. >>> >> >> I think your argument diverges from the one Andrew makes. If you think= >> we should capture your line of argumentation in the draft, let's have = a >> discussion about it. What kind of protocols do you think are not polit= ical? >> >> >>>> Repeating that technology is neutral will not make >>>> it more true, but I am more than happy to be convinced. >>> >>> That was not repeated because it was not stated, by me at least >>> and nor I think by Andrew. *Some* technology is neutral was my >>> assertion. >>> >> >> OK - let's work it out! >> >> Thanks again! >> >> Cheers, >> >> Niels >> >> >>> Cheers, >>> S. >>> >> >=20 --f8hXua1BLpxCSNnIRm67Jq3oB55oU1nIj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb6FzAAoJEA7YPzpGisiz4xcQAI5F5ie47m9UIi+yXi0QAEzo iSkCQ45FZBFAW+wI3AEg2+xRrTGPZN+zW6v8zM3LwfupDLlTczwePAeXg/xUb0g4 pVgsTFxCqVEQuLn8XlCqPfj7uHvkiXPJURURdrggKyGDvFfVNazT1RnRhN+Q54fn LJ2tFGRuEl0ZSXm1QsW/G9EkzGEhzCPx9o6dsVze1IQwKrBbcYCHx8AsddNEX5mO FwfjTQ7Iyn2bi9sIMvONqpXsWKvTHFSp3T+ZPFgfG3dojvx1is2yvoiR7olFXJ1y lWSSL/1wTSACuRV4qFLpQcl6L7BR1iZfFLhX2r/Wr9Qe/9302ff68D3rV2eE5gK9 d9mhbOQYl6nKDoiwVH9pK6EEwvzSalTcPvO8DS+jbKrwmM1CVvX9MSLHnGjTPP4X hb0enWZ262JLFF2agDnoI/5/8AXIVQgmclwxq5jJ5TDvvE/tIjUSkJneN6t4qeg4 0tjLcnucAl85x5I91E24+IIei66hNiKFVDRVsIgHvrbVixwIKyxeUwl8QM5gCWyF FZCj437ObBFkrPHr/7Ao+l5+vE4tudF3SKKp3TLDNSQj6Bk6d/TV3ud44VGgUu3f bCui8Cb1bffiYmfVyR8AY8OrrDeXB0ubxQn8DKWbhD6sFbrdE7KpZS0QnvlCRkpg 5xOMILorMxoC48S3Hsr6 =DDhp -----END PGP SIGNATURE----- --f8hXua1BLpxCSNnIRm67Jq3oB55oU1nIj-- From nobody Fri Jan 6 06:17:57 2017 Return-Path: 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 381F9129525 for ; Fri, 6 Jan 2017 06:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 lg4KyDVkc9aD for ; Fri, 6 Jan 2017 06:17:54 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 46FAF129499 for ; Fri, 6 Jan 2017 06:17:54 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5A91E280338; Fri, 6 Jan 2017 15:17:52 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 5503428031A; Fri, 6 Jan 2017 15:17:52 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 52E87B3800C; Fri, 6 Jan 2017 15:17:22 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 4BB4D3FD29; Fri, 6 Jan 2017 15:17:22 +0100 (CET) Date: Fri, 6 Jan 2017 15:17:22 +0100 From: Stephane Bortzmeyer To: Alissa Cooper Message-ID: <20170106141722.3ob7c3otmgu2n5rn@nic.fr> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.7.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:17:56 -0000 On Thu, Jan 05, 2017 at 12:45:04PM -0500, Alissa Cooper wrote a message of 201 lines which said: > = Section 3.2.3 and 3.2.3.1 = > > If the point of the IPv4 example is to demonstrate the human rights > impacts -- both positive and negative -- of various protocol > designs, I find the section to be narrow, slanted, and > incomplete. It seems focused almost exclusively on the potential > harms, which, for a protocol as fundamental to the operation of the > Internet as IPv4, is not justified and renders this section somewhat > useless IMO. You raise an interesting question (which, I believe, was not explicitely discussed in the RG before): should the "human rights" review of the protocols just an example (of the consequences of technical decisions for HR) or should it be a comprehensive and detailed review, with no stone left unturned? I believe the implicit choice was to just give examples. They are necessary because, in the IETF, many people believe that technology is more or less neutral, and do not think that a technical choice can have political consequences. Therefore, it is useful to have concrete examples. But, to quote the draft, "It is important to note that the assessment here is not a general judgment on these protocols. When they were conceived, there were many criteria to take into account. [...] So, when we say 'protocol X has feature Y, which may endanger the freedom of speech', it does not mean that protocol X is bad and even less that its authors were evil. The goal here is to show, with actual examples, that the design of protocols have practical consequences for some human rights and these consequences have to be considered at design time." So, I think I disagree with your review. The goal was not to give a complete assessment of the Internet protocols (a different, and certainly interesting work). > IPv4 is the basis for packet-switching on the Internet. What would > the human rights impacts be if packet-switching was never invented? I don't think that IPv4 needs to be defended, its successes speak for its importance and usefulness :-) > It seems to me that any evaluation of the human rights impacts of > IPv4 needs to take this more wholistic view into account. As I said, I think it is a different work. For instance, section 8 of RFC 6973 does not make a "wholistic" analysis of the presence service, and does not try to explain that it is useful. By the way, the original versions of the draft were much more critical of TCP/IP protocols, sometimes on the verge of paranoia. > The above is just one example of a fundamental aspect of the > protocol that is overlooked in the existing analysis. Section > 3.2.3.1.1 bemoans the visibility of source and destination > addresses, while overlooking the fact that such addresses can > actually provide a great deal of anonymity protection compared to > other identifiers that could have been chosen to be made part of the > protocol. The fact that there were worst choices do not seem to me a sufficient reason to limit the critical analysis. > Section 3.2.3.1.2 then makes no mention of the fact that NAT can > actually provide protection from such visibility. "Home" NAT, the one currently the most common for fixed-line access does not protect at all since the public IP address identifies a home. It could be said that CGN protects a bit, but this is not the case for all usages of NAT. > it needs to state up front that it is cherry-picking a few harms > identified as being linked to the protocol design just for > demonstration purposes. In my opinion, this is stated in section 3.2.3. > = Section 3.2.3 = > > "For instance, relying on an external server can be bad for freedom > of speech" -- without any further context provided, it's hard to > understand what is meant by an "external" server. How about "a server which is not under the direct control of one (or both) of the parties which are communicating"? From nobody Fri Jan 6 06:20:58 2017 Return-Path: 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 1211E129B20 for ; Fri, 6 Jan 2017 06:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PTotVKWklNUq for ; Fri, 6 Jan 2017 06:20:55 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id ED3BE129B1B for ; Fri, 6 Jan 2017 06:20:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 626C3114DD for ; Fri, 6 Jan 2017 14:21:00 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnVaL0K1Omd4 for ; Fri, 6 Jan 2017 14:20:59 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 5161B114C9 for ; Fri, 6 Jan 2017 14:20:59 +0000 (UTC) Date: Fri, 6 Jan 2017 09:20:51 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170106142051.GA12568@mx2.yitter.info> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:20:57 -0000 On Fri, Jan 06, 2017 at 02:08:03PM +0100, Niels ten Oever wrote: > > I think this para refutes your interpretation: > > The Internet: A large, heterogeneous collection of interconnected > systems that can be used for communication of many different types > between any interested parties connected to it. The term includes > both the "core Internet" (ISP networks) and "edge Internet" > (corporate and private networks, often connected via firewalls, > NAT boxes, application layer gateways and similar devices). The > Internet is a truly global network, reaching into just about every > country in the world. > The IETF community wants the Internet to succeed because we > believe that the existence of the Internet, and its influence on > economics, communication, and education, will help us to build a > better human society. > > In the first paragraph the technical aspect is explained (from which you > could potentially derive a networking ethic) Sure. > , but the second parapgraph clearly explains a (primitive) external > ethic. Yes. Note that it is a claim about "the IETF community" and not "the IETF". It has never been plain to me why BCP 95 makes that distinction, but it appears to. It's also a claim about beliefs. But none of this shows that IETF participants are not choosing what they think of as "Internet technologies" as opposed to other ones. The point is merely that the story I've told is _consistent_ with the outcome you appear to want. > We embrace technical concepts such as > decentralized control, edge-user empowerment and sharing of > resources, because those concepts resonate with the core values of > the IETF community. These concepts have little to do with the > technology that's possible, and much to do with the technology that > we choose to create. > > means that these concepts are derived from an inherent inter-networking > ethics, I am afraid I have to disagree. I don't believe I said that; I certainly didn't intend to. My point is rather that the humans doing the work might have some extrinsic value in mind, but the ethic of the network conveniently aligns with those extrinsic values. So, _even if_ a particular IETF participant doesn't agree with some part of BCP 95, by virtue of working on Internet technologies they might still be contributing to the same extrinsic goal. > Because there is also an > inter-networking solution possible without edge-user empowerment. Really? How? I think this is tied to your response to my remark about internetworking as opposed to other kinds of networking. Perhaps I can put this differently: I think that "the Internet" is a mass noun that denotes an emergent property, rather like "the traffic on the Don Valley Parkway" does. There is no _thing_, "the traffic", that you can change. All you can do is change constituent parts by affecting individuals' behaviour, and so similarly with the Internet. But unlike "the traffic", which is governed by a single set of rules that control the road system, "the Internet" is designed so that each participant can work out the rules between them on their own, just by using some intercommunication primitives that are predefined. (One might say that the Internet is not like driving on the Don Valley, and is more like driving in Mumbai.) This is also different from some other kinds of cases. For instance, "the flow of water through the pipes in my house" is similar in that there is no particular chunk of water that one is directing. Yet any given flow (as long as the system doesn't have leaks and so on) is actually entirely under the control of my household, so it's a centrally-run system. And in a municipal water system, each individual connection is via a well-regulated two-way interface between exactly two parties. This is very different from internetworking, even though it's a kind of network. > Could you also make the argument in relation to 'Internationalization?' > Why would the network care about human parsable languages? It doesn't at the protocol layer. But it does at layers where network identifiers or other protocol elements are exposed to users, precisely because a larger body of users (which we can derive trivially from "people with different writing systems than unaccented Latin in the ASCII range of Unicode") increases the potential network effects. > What some people think is good for the network, might > not be seen the same by others. This seems no objection to me at all: what some people think is good for human rights might not be seen the same by others, or the US, most EU countries, and China would not have disagreements over the nature and acceptability of capital punishment (just to pick a totally non-controversial example ;-) ) > Also: in your argument you now include 'faith in the network' as part of > the 'inherent network ethic', which is I think a bit of a leap, because > earlier you seemed to argue that you wanted to leave usage out of the > equation. It's starting to become a bit blurry for me here, but maybe > that's because I do not sufficiently understand your concept of a > 'network ethic'. The notion of the network ethic -- and I cheerfully concede that I have not worked this out fully, since I gave up on my philosophy dissertation nearly 20 years ago and now only get to play in the junior leagues in my spare time -- is that one takes the stance of the network qua network, and consider what is good for it. What is good for the Internet is more internetworking, which means more networking of other networks. In a networking ethic, any case that causes an increase in that internetworking is good, and any case which reinforces increasing internetworking is a virtuous circle. Faith in the network by humans causes increased use, which causes larger network effects, which causes increased use, and so on; so it is a virtuous circle. Therefore, faith in the network by human users is network-ethic good (even if it is, say, bad from the point of view of a government that wants to control the communications paths from the country). > You seem to use the term 'technocrats' here as in 'bureaucrats'. Are you > describing IETF-ers here as technocrats that take orders from policy > makers? I think that kind of goes against 'no kings, no presidents', right? One view of what the IETF does is that it produces clean technical specifications that are divorced from the policy questions in which those specifications might be used. Under this view, the rejection of kings and presidents is a rejection _for the purposes of the IETF_: we reject the idea that those with controls over the voting mechanisms or procedural machinery get to have special influence over which specifications get published or the contents of those specifications. (It is not to say that there do not exist kings or presidents. IETF participants are sometimes accused of being unworldy, but I don't think it extends quite that far.) If we take that view seriously, then it follows that the IETF can produce the best technical specification to solve a given technical problem, and it can advise the world of that specification. But it cannot adjudicate whether such a specification should be adopted as a matter of policy. That is outside the IETF purview. This approach to breaking up techno-political problems -- technical people offering "the right answer to a problem" and policy-makers stating the problem and deciding whether it is to be solved -- is what I call the technocratic stance. I don't think it is unusual to the IETF, and arguably the entire history of (for instance) urban planning is dressed up in this same story. Whether it is a _true_ story is, I think, debatable. I think you are arguing that it is _not_ true. I might agree with that, but what I keep trying to argue is that the draft under discussion could be agnostic on its truth and still produce considerations that any protocol designer could embrace. It could also adopt the stance that one _could_ believe the technocratic stance is wrong, in which case one could use the considerations in the draft. Instead, the draft tries to argue that the stance is wrong, but it mostly makes such arguments by appeal to authority -- authorities that anyone who embraces the technocratic stance will not accept. So the draft is less effective than it might be in achieving its purpose. > If your position is that there is such a think as a networking ethic > that has driven the work here for many years No, that is certainly not my position. > {{Denardis14}}. The IETF thusfar has formally relied on an ethics that > is based on an understanding that the network is its own objective, and > the internetworking between networks is the expected result. I don't think the IETF has ever formally relied on any ethics, BCP 95 notwithstanding. > So you really think it would add to this draft to describe pre-Kantian > epistemology and subject-object relations here? No, but I hope this message makes clearer what I'm suggesting instead. If not, perhaps this is evidence of Kuhn's view about paradigms. As I've said, this is a RG document and I have no objection to the RG proceeding to publication. If this were an attempt to create an IETF document that wanted to govern IETF procedure, I'd be very strongly opposed to going ahead, but as a RG document I am not. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jan 6 06:33:24 2017 Return-Path: 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 DAF89129437 for ; Fri, 6 Jan 2017 06:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 m1x2IDidvqgy for ; Fri, 6 Jan 2017 06:33:21 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 8AD6B1288B8 for ; Fri, 6 Jan 2017 06:33:21 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 027DD280338; Fri, 6 Jan 2017 15:33:20 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id F15EC28031A; Fri, 6 Jan 2017 15:33:19 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id EF943B38003; Fri, 6 Jan 2017 15:32:49 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id E94323FD29; Fri, 6 Jan 2017 15:32:49 +0100 (CET) Date: Fri, 6 Jan 2017 15:32:49 +0100 From: Stephane Bortzmeyer To: Andrew Sullivan Message-ID: <20170106143249.mveqiztkasfjyxse@nic.fr> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> <20170106142051.GA12568@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170106142051.GA12568@mx2.yitter.info> X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.7.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:33:23 -0000 On Fri, Jan 06, 2017 at 09:20:51AM -0500, Andrew Sullivan wrote a message of 194 lines which said: > This seems no objection to me at all: what some people think is good > for human rights might not be seen the same by others, or the US, > most EU countries, and China would not have disagreements over the > nature and acceptability of capital punishment (just to pick a > totally non-controversial example ;-) ) It seems to me that, as far as human rights are mentioned, we decided to use the UN declaration as the basis. Not that it is pefect (no human work is, and the Wikipedia article does a good job of listing various criticisms against it) but it is probably the best thing we can all agree on. And, to handle this specific case, the UNDHR does not mention the death penalty. (IMHO, it should, but this is off-topic for this RG.) From nobody Fri Jan 6 06:39:04 2017 Return-Path: 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 568831294FD for ; Fri, 6 Jan 2017 06:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kgxHhAeiscks for ; Fri, 6 Jan 2017 06:39:02 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 365C51294EB for ; Fri, 6 Jan 2017 06:39:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id BAE15114DE for ; Fri, 6 Jan 2017 14:39:07 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjdhoM6_5yYs for ; Fri, 6 Jan 2017 14:39:07 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id EF5EC114C9 for ; Fri, 6 Jan 2017 14:39:06 +0000 (UTC) Date: Fri, 6 Jan 2017 09:38:59 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170106143859.GC12568@mx2.yitter.info> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> <20170106142051.GA12568@mx2.yitter.info> <20170106143249.mveqiztkasfjyxse@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170106143249.mveqiztkasfjyxse@nic.fr> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:39:03 -0000 On Fri, Jan 06, 2017 at 03:32:49PM +0100, Stephane Bortzmeyer wrote: > And, to handle this specific case, the UNDHR does not mention the > death penalty. (IMHO, it should, but this is off-topic for this RG.) I think the controversy is over whether Section 3 of the UDHR means that capital punishment is an abrogation of a right, which is why I thought the analogy apt for the objection Neils raised. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jan 6 06:50:02 2017 Return-Path: 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 BCF08129555 for ; Fri, 6 Jan 2017 06:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 UTKC4SCjlAhB for ; Fri, 6 Jan 2017 06:50:00 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 BD64C12954A for ; Fri, 6 Jan 2017 06:50:00 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id F3DF828031A; Fri, 6 Jan 2017 15:49:58 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id ED8C52802A0; Fri, 6 Jan 2017 15:49:58 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id EB6E1B3800C; Fri, 6 Jan 2017 15:49:28 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id E5B8C3FD29; Fri, 6 Jan 2017 15:49:28 +0100 (CET) Date: Fri, 6 Jan 2017 15:49:28 +0100 From: Stephane Bortzmeyer To: S Moonesamy Message-ID: <20170106144928.um4lfk7gjpo2ryn2@nic.fr> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.7.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: Corinne Cath , Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:50:02 -0000 On Fri, Jan 06, 2017 at 04:03:04AM -0800, S Moonesamy wrote a message of 117 lines which said: > > Which does not mean that one should never be able to keep logs, > > but rather we should try to keep the storage and collection of > > Personal Identifiable Information to a minimum. > > Logging is not a protocol issue as such as it falls outside the > communication boundary which was usually viewed as an IETF matter. That's clearly not true. There are several RFCs about logging such as RFC 6302, which has clear HR consequences. (There is also RFC 6269 or 7937 or 7422 or even 7011.) From nobody Fri Jan 6 06:54:34 2017 Return-Path: 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 1844C1294FF for ; Fri, 6 Jan 2017 06:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 b1hra70BJuW3 for ; Fri, 6 Jan 2017 06:54:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B2612945F for ; Fri, 6 Jan 2017 06:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D953CBE4D; Fri, 6 Jan 2017 14:54:27 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB3YR8LnVGwJ; Fri, 6 Jan 2017 14:54:27 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4A2EFBE51; Fri, 6 Jan 2017 14:54:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483714467; bh=2NuwIktvOa8Z+1TAt+6dk9WeQHn7V7jcpd3MZn6Gtlw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ADVR3YFF0b5HjXd4ZEixLFM5e6zK+JZBDAQwtDQO2yj+kHeJkX95U7QfDiwQFnv70 M2MI36A22u+0yYoeuKgfOm5+3aJ1+vDnKDBFGW9kyk7xt8Fwg5VB4oNJY5MOEpSP2t fAg8sNDFl6FGPa0E66+IKM+Rg598TkPCOSYXxlrc= To: Niels ten Oever , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> Date: Fri, 6 Jan 2017 14:54:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4ddO4HdKG5p80KPe95dn9uEwVmEqVqJQg" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:54:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4ddO4HdKG5p80KPe95dn9uEwVmEqVqJQg Content-Type: multipart/mixed; boundary="dvSOg6XE33chnRQ426OeK1jgdMig1Qk2K"; protected-headers="v1" From: Stephen Farrell To: Niels ten Oever , hrpc@irtf.org Message-ID: <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> In-Reply-To: <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> --dvSOg6XE33chnRQ426OeK1jgdMig1Qk2K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 06/01/17 13:53, Niels ten Oever wrote: > I am tempted to respond,=20 I think it'd be useful to know if you agree or not though. Do you personally think [1] is political? From the mails so far, I am under the impression that you do think [1] is political. I do not. [1] https://tools.ietf.org/html/rfc6256 > but.... in the draft there is no sentence that > says 'protocols are political'. Shall we go back to the text of the > draft and see what issues there are in there? I think it's concentrated= > in this para: Yes. Some suggested changes below... >=20 > Protocols and standards are regularly seen as merely performing > technical functions. However, these protocols and standards do not exis= t > outside of their technical context nor outside of their political, > historical, economic, legal or cultural context. This is best > exemplified by the way in which protocols have become part and parcel o= f s/which protocol/which some (but not all) Internet processes and protocols/ > political processes and public policies: one only has to look at the > IANA transition,=20 The IANA transition is all process, zero protocol. (Hence adding processes above.) > the RFC on pervasive monitoring or global innovation > policy for concrete examples {{Denardis15}}.=20 > To quote {{Abbate}}: S/To quote/According to/ > "protocols are politics by other means". This statement confers that > protocols are based on decision making, most often by humans. In this > process the values and ideas about the role that a particular technolog= y > should perform in society is embedded into the design. Often these > design decisions are part pure-technical, and part inspired by certain > world view of how technology should function that is inspired by > personal and political views.=20 s/personal and political/personal, corporate and political/ The reality is that corporate beats out political most of the time. > Since the late 1990's a burgeoning group > of academics and practitioners researched questions surrounding the > societal impact of protocols, and the politics of protocols. These > studies vary in focus and scope: some focus on specific standards > {{Davidsonetal}} {{Musiani}}, others look into the political, legal, > commercial or social impact of protocols {{BrownMarsden}} {{Lessig}}, > {{Mueller}} and yet others look at how the engineers' personal set of > values get translated into technology {{Abbate}},{{CathFloridi}} > {{Denardis15}} {{WynsbergheMoura}}. I'd also add: ' Within the community of IETF participants there is a fairly clear desire to as far as possible restrict IETF activities to those that are as purely technical and as little political, as is possible. Many of those participants would not accept the proposition that "protocols are politics by other means." ' >=20 > Is your main problem with the quote: "protocols are politics by other > means" ? Yes, and that the draft text seems to agree with that statement with no qualifications. S. >=20 > Best, >=20 > Niels >=20 >=20 >> Cheers, >> S. >> >> [1] https://tools.ietf.org/html/rfc6256 >> >>> >>> >>>>> >>>>> DeNardis, Laura. 2009. Protocol Politics: The Globalization of Inte= rnet >>>>> Governance. Cambridge, MA: MIT Press. >>>>> >>>>> as well as: >>>>> >>>>> DeNardis, Laura. 2014. The Global War for Internet Governance. >>>>> >>>>> I am still waiting for relevant literature that argues that technol= ogy >>>>> is ethically neutral.=20 >>>> >>>> That is not what I claimed. Some technology is not ethically neutral= =2E >>>> But I do assert that IETF technology some is ethically neutral. >>>> You seem to be asserting that no technology can ever be ethically >>>> neutral and I disagree with that. >>>> >>> >>> All technology has the characteristic of ordering and re-ordering the= >>> world we live in. It stimulates certain behavior, and it inhibits >>> others. In this way it influences our public and private sphere and t= hus >>> is political. >>> >>> It does so in major ways, such as where it directly touches upon civi= l >>> liberties such as privacy and freedom of expression. But it also does= so >>> in more subtle ways, via (lack of) availability in local languages, >>> centralized vs distributed solutions, and reliability and performance= on >>> high latency networks vs low latency networks. >>> >>> And of course even the possibility of making specific things possible= =2E >>> >>> This is all inherently political. >>> >>>>> We've cited quite a body of literature that argues >>>>> the exact opposite.=20 >>>> >>>> No, you did not provide exact opposites above. Yes, there is a body >>>> of literature that argues as you do. It's fine that we do not all >>>> share the exact same opinions, but would be better if the draft did >>>> reflect that divergence. >>>> >>> >>> I think your argument diverges from the one Andrew makes. If you thin= k >>> we should capture your line of argumentation in the draft, let's have= a >>> discussion about it. What kind of protocols do you think are not poli= tical? >>> >>> >>>>> Repeating that technology is neutral will not make >>>>> it more true, but I am more than happy to be convinced. >>>> >>>> That was not repeated because it was not stated, by me at least >>>> and nor I think by Andrew. *Some* technology is neutral was my >>>> assertion. >>>> >>> >>> OK - let's work it out! >>> >>> Thanks again! >>> >>> Cheers, >>> >>> Niels >>> >>> >>>> Cheers, >>>> S. >>>> >>> >> >=20 --dvSOg6XE33chnRQ426OeK1jgdMig1Qk2K-- --4ddO4HdKG5p80KPe95dn9uEwVmEqVqJQg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYb6+iAAoJEC88hzaAX42iw8cH/RxpkSEiH3v3XeJIaOIQ9gWw cT8+THQSpX4AmLLKa87qhq1/fGotkJQZpm9HKUlRYQtKiC0RpH8pux83gO6aHclt fvrlY/aZh4t+rQwO4U2lT9NKG1pwmQwkK/asYgyZDrhN3R0HWinKO6EXW6w6CqEx CHNaipM/de2dwo1W/2OBK7IE+i0WrjBvYsWw750PgXcd3mr+vbvv5EDGU1cyDyuM Wp0dSk5WIy8dEiHETd3QDI5O8gh5l8TVL0o2k/o6rkSi20szB/T0IY/wDoeqla21 yKE3hSUsQXqnu3w0fhPGdt4GJfg+EYy5gZBdFCcE6WG4SQO0NQEtq3tQCooMGww= =IvD7 -----END PGP SIGNATURE----- --4ddO4HdKG5p80KPe95dn9uEwVmEqVqJQg-- From nobody Fri Jan 6 07:57:51 2017 Return-Path: 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 DA34A129B3B for ; Fri, 6 Jan 2017 07:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 xHO4OBZsK5SY for ; Fri, 6 Jan 2017 07:57:47 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 EA5F3129B35 for ; Fri, 6 Jan 2017 07:57:46 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPWtj-00081a-N7; Fri, 06 Jan 2017 16:57:44 +0100 To: Stephen Farrell , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 6 Jan 2017 16:57:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VSMMusr1So50W2DplBaEhXQfUEpeNIcDh" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4cdc0e91b9566e39cd99815614abee53 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 15:57:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VSMMusr1So50W2DplBaEhXQfUEpeNIcDh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/06/2017 03:54 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 06/01/17 13:53, Niels ten Oever wrote: >> I am tempted to respond,=20 >=20 > I think it'd be useful to know if you agree or not though. > Do you personally think [1] is political? From the mails > so far, I am under the impression that you do think [1] is > political. I do not. >=20 > [1] https://tools.ietf.org/html/rfc6256 >=20 Delay Tolerant Networking can be very relevant for human rights, especially in areas with low connectivity. As you know, Delay Tolant Networking is now also used a lot for IoT devices, so if this technology would enable something such as an emergency response device for human rights defenders, I think it could be very useful as well. One could also think of deployments similar to Outernet (https://outernet.is/) which would improve the Right to Education. If this RFC makes de deployment of DTN easier, and thus positively contributes to these things, I indeed think it is political. >> but.... in the draft there is no sentence that >> says 'protocols are political'. Shall we go back to the text of the >> draft and see what issues there are in there? I think it's concentrate= d >> in this para: >=20 > Yes. Some suggested changes below... >=20 >> >> Protocols and standards are regularly seen as merely performing >> technical functions. However, these protocols and standards do not exi= st >> outside of their technical context nor outside of their political, >> historical, economic, legal or cultural context. This is best >> exemplified by the way in which protocols have become part and parcel = of >=20 > s/which protocol/which some (but not all) Internet processes > and protocols/ Accepted - but if you don't mind I leave out '(but not all)', because that is the meaning of 'some'. >=20 >> political processes and public policies: one only has to look at the >> IANA transition,=20 >=20 > The IANA transition is all process, zero protocol. (Hence adding > processes above.) Accepted. >=20 >> the RFC on pervasive monitoring or global innovation >> policy for concrete examples {{Denardis15}}.=20 >=20 >> To quote {{Abbate}}: >=20 > S/To quote/According to/ >=20 Accepted >> "protocols are politics by other means". This statement confers that >> protocols are based on decision making, most often by humans. In this >> process the values and ideas about the role that a particular technolo= gy >> should perform in society is embedded into the design. Often these >> design decisions are part pure-technical, and part inspired by certain= >> world view of how technology should function that is inspired by >> personal and political views.=20 >=20 > s/personal and political/personal, corporate and political/ Accepted >=20 > The reality is that corporate beats out political most of the time. >=20 >> Since the late 1990's a burgeoning group >> of academics and practitioners researched questions surrounding the >> societal impact of protocols, and the politics of protocols. These >> studies vary in focus and scope: some focus on specific standards >> {{Davidsonetal}} {{Musiani}}, others look into the political, legal, >> commercial or social impact of protocols {{BrownMarsden}} {{Lessig}}, >> {{Mueller}} and yet others look at how the engineers' personal set of >> values get translated into technology {{Abbate}},{{CathFloridi}} >> {{Denardis15}} {{WynsbergheMoura}}. >=20 > I'd also add: >=20 > ' > Within the community of IETF participants there is a fairly > clear desire to as far as possible restrict IETF activities > to those that are as purely technical and as little political, > as is possible. Many of those participants would not accept > the proposition that "protocols are politics by other means." >=20 Thanks for this suggestion. I thought we could maybe rewrite it like this= : Within the community of IETF participants there is a strong desire to solve technical problems and minimize the engagement with political problems. But then I thought: would people working on privacy agree with this? I think for a lot of them this actually _is_ a political issue (same for people active in GAIA, etc). So maybe something like: Within the community of IETF participants there is a strong desire to solve technical problems and minimize its engagement with political processes and non-protocol related political issues. Might need some fine-tuning, but curious to hear what you think. >=20 >> >> Is your main problem with the quote: "protocols are politics by other >> means" ? >=20 > Yes, and that the draft text seems to agree with that statement with > no qualifications. Hope we addressed that now :) >=20 > S. >=20 Cheers, Niels >=20 >> >> Best, >> >> Niels >> >> >>> Cheers, >>> S. >>> >>> [1] https://tools.ietf.org/html/rfc6256 >>> >>>> >>>> >>>>>> >>>>>> DeNardis, Laura. 2009. Protocol Politics: The Globalization of Int= ernet >>>>>> Governance. Cambridge, MA: MIT Press. >>>>>> >>>>>> as well as: >>>>>> >>>>>> DeNardis, Laura. 2014. The Global War for Internet Governance. >>>>>> >>>>>> I am still waiting for relevant literature that argues that techno= logy >>>>>> is ethically neutral.=20 >>>>> >>>>> That is not what I claimed. Some technology is not ethically neutra= l. >>>>> But I do assert that IETF technology some is ethically neutral. >>>>> You seem to be asserting that no technology can ever be ethically >>>>> neutral and I disagree with that. >>>>> >>>> >>>> All technology has the characteristic of ordering and re-ordering th= e >>>> world we live in. It stimulates certain behavior, and it inhibits >>>> others. In this way it influences our public and private sphere and = thus >>>> is political. >>>> >>>> It does so in major ways, such as where it directly touches upon civ= il >>>> liberties such as privacy and freedom of expression. But it also doe= s so >>>> in more subtle ways, via (lack of) availability in local languages, >>>> centralized vs distributed solutions, and reliability and performanc= e on >>>> high latency networks vs low latency networks. >>>> >>>> And of course even the possibility of making specific things possibl= e. >>>> >>>> This is all inherently political. >>>> >>>>>> We've cited quite a body of literature that argues >>>>>> the exact opposite.=20 >>>>> >>>>> No, you did not provide exact opposites above. Yes, there is a body= >>>>> of literature that argues as you do. It's fine that we do not all >>>>> share the exact same opinions, but would be better if the draft did= >>>>> reflect that divergence. >>>>> >>>> >>>> I think your argument diverges from the one Andrew makes. If you thi= nk >>>> we should capture your line of argumentation in the draft, let's hav= e a >>>> discussion about it. What kind of protocols do you think are not pol= itical? >>>> >>>> >>>>>> Repeating that technology is neutral will not make >>>>>> it more true, but I am more than happy to be convinced. >>>>> >>>>> That was not repeated because it was not stated, by me at least >>>>> and nor I think by Andrew. *Some* technology is neutral was my >>>>> assertion. >>>>> >>>> >>>> OK - let's work it out! >>>> >>>> Thanks again! >>>> >>>> Cheers, >>>> >>>> Niels >>>> >>>> >>>>> Cheers, >>>>> S. >>>>> >>>> >>> >> >=20 --VSMMusr1So50W2DplBaEhXQfUEpeNIcDh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb752AAoJEA7YPzpGisiz0aMP/ArxFKY0p1nIltimdBg52VaW 0M7z9XgJm8rNbuYbjKJsPPgkfVTtgekqlp5IBQQZ8VgEWrK4XRv6/b767Odwu+I5 2PAi5qFE1KjAiteBxEwg7rt+Alt+mUdo81wWChKFLO32JuRcpXE9KZDgFMtso2Ie 0YjQ1oPOqOSMhk9NxFIzqJC8AS40JR9v/Jn9f9R1R4v4pxSWCPGUzigr7NkE8+k4 g6E0RL5++Ncv9kcST1mbE3hcG2x8hSQ6v7e1WyD0mJlK8JBSZKnctjaSaKZc5k7j wXYaMsiGg6n+v9ok26/YWL4hD135OuYzXhJAXK+yojgn1ZrPNgRpERuTV799Z6MV jyrIIhKM/9iP8/lbd4BCE+0AMFCLU8IrwpIaXytFuvi7Dam42KwoU3uzFiRBV/sW Uhl7iyyKuyjOzkn781KFc+fouSPYwSPfEeCMAnBMgZ55eL6Bc43bng+8MreZo4+k yZwt7Wf52RrSJ2M6tZXAqfD3cKd+VnqG2b0VnnM+lUNBw1sRSC9lwU80uy0/SaRf E0TnEXjQPHw9x4qZl2LmSHb2EAwqjEfesZCHYeERBelmjFnoNcV7RiqvzZ5iDdLK ZHunDbnDINpsSbO1hujxK/mxahxtRv4/jKq4d7EWAccYqZ5HsWpRwjAtV8zAudRh W6xqHtkJ+UXEyQ8QiaKe =gcC/ -----END PGP SIGNATURE----- --VSMMusr1So50W2DplBaEhXQfUEpeNIcDh-- From nobody Fri Jan 6 08:23:05 2017 Return-Path: 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 E0325129411 for ; Fri, 6 Jan 2017 08:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 tVOMS1ULEgtz for ; Fri, 6 Jan 2017 08:23:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020B0124281 for ; Fri, 6 Jan 2017 08:23:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE923BE83; Fri, 6 Jan 2017 16:22:58 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id papubQsVLoQk; Fri, 6 Jan 2017 16:22:58 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5D0C6BE80; Fri, 6 Jan 2017 16:22:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483719778; bh=gTpDDIera4Myhpi/mkQRnDjewgp/n4SrnxgknHJSi3A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=TMN4iwskTXJCU8nEe+6xxzkZwbh+r/8AukiGj1/+sg5PY2lE2eEb6U31vc7yOik2h +b+MfdJPzXKTd0ZS43SNO9XH9jZ/9cPN37tu8eiwh9ubkSs+fdt//CEsucgtPQXVKP P+yrs0HTS7j40NYFwu9NG7cnTdYZ7MQdQMZSE0jM= To: Niels ten Oever , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> Date: Fri, 6 Jan 2017 16:22:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bH7FbTpqcQhrTxP8eplAbqSLnnu1Hb5dQ" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 16:23:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bH7FbTpqcQhrTxP8eplAbqSLnnu1Hb5dQ Content-Type: multipart/mixed; boundary="vwvFAiKbdxE8hXBQcnn95QS1hS41v0nhK"; protected-headers="v1" From: Stephen Farrell To: Niels ten Oever , hrpc@irtf.org Message-ID: <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> In-Reply-To: --vwvFAiKbdxE8hXBQcnn95QS1hS41v0nhK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Progress! Great:-) On 06/01/17 15:57, Niels ten Oever wrote: > Hiya, >=20 > On 01/06/2017 03:54 PM, Stephen Farrell wrote: >> >> Hiya, >> >> On 06/01/17 13:53, Niels ten Oever wrote: >>> I am tempted to respond,=20 >> >> I think it'd be useful to know if you agree or not though. >> Do you personally think [1] is political? From the mails >> so far, I am under the impression that you do think [1] is >> political. I do not. >> >> [1] https://tools.ietf.org/html/rfc6256 >> >=20 > Delay Tolerant Networking can be very relevant for human rights, > especially in areas with low connectivity. > As you know, Delay Tolant Networking is now also used a lot for IoT > devices, so if this technology would enable something such as an > emergency response device for human rights defenders, I think it could > be very useful as well. > One could also think of deployments similar to Outernet > (https://outernet.is/) which would improve the Right to Education. >=20 > If this RFC makes de deployment of DTN easier, and thus positively > contributes to these things, I indeed think it is political. I fully disagree. We don't need to argue about it though so just for the record: my reasoning is that yes aspects of DTN deployment are political in the sense you describe, and yes aspects of DTN protocol design were political in the corporate sense (I could go into details, but they're still irritating to some folks so I won't:-), but this particular aspect (use of SNDV as a way to represent numbers) is just not political in any sense. Therefore that RFC is apolitical too. I'd also assert that there are many other aspects of DTN technology that are similarly purely technical and apolitical. To offer a contrast though - whether or not to include a checksum in bundles is something that could have been purely technical but ended up being political (in the corporate sense) due to the players involved. So it could have been the case that SDNVs and this RFC were political, but the facts are otherwise in that case. (And just to be clear: when I say "corporate politics" I would include e.g. academic politics and as was relevant in the case of DTN, non-technical disagreements that happen inside even just one not-for-profit organisaton;-) If an analogy might help: voting in elections is political, but whether I walk or cycle to the polling station is not, in itself, political. (It could be if I were a cycling advocate, but in my case, my mode of transport to the polling station is not a political act.) Again - I'm happy to chat about the above, as it's interesting where different folks draw the lines, but we definitely don't need to resolve that discussion to be done with this draft. So if someone does want to chat about that maybe best to start a new thread. >=20 >>> but.... in the draft there is no sentence that >>> says 'protocols are political'. Shall we go back to the text of the >>> draft and see what issues there are in there? I think it's concentrat= ed >>> in this para: >> >> Yes. Some suggested changes below... >> >>> >>> Protocols and standards are regularly seen as merely performing >>> technical functions. However, these protocols and standards do not ex= ist >>> outside of their technical context nor outside of their political, >>> historical, economic, legal or cultural context. This is best >>> exemplified by the way in which protocols have become part and parcel= of >> >> s/which protocol/which some (but not all) Internet processes >> and protocols/ >=20 > Accepted - but if you don't mind I leave out '(but not all)', because > that is the meaning of 'some'. Sure. Though I prefer the emphasis:-) >> >>> political processes and public policies: one only has to look at the >>> IANA transition,=20 >> >> The IANA transition is all process, zero protocol. (Hence adding >> processes above.) >=20 > Accepted. >> >>> the RFC on pervasive monitoring or global innovation >>> policy for concrete examples {{Denardis15}}.=20 >> >>> To quote {{Abbate}}: >> >> S/To quote/According to/ >> >=20 > Accepted >=20 >>> "protocols are politics by other means". This statement confers that >>> protocols are based on decision making, most often by humans. In this= >>> process the values and ideas about the role that a particular technol= ogy >>> should perform in society is embedded into the design. Often these >>> design decisions are part pure-technical, and part inspired by certai= n >>> world view of how technology should function that is inspired by >>> personal and political views.=20 >> >> s/personal and political/personal, corporate and political/ >=20 > Accepted >=20 >> >> The reality is that corporate beats out political most of the time. >> >>> Since the late 1990's a burgeoning group >>> of academics and practitioners researched questions surrounding the >>> societal impact of protocols, and the politics of protocols. These >>> studies vary in focus and scope: some focus on specific standards >>> {{Davidsonetal}} {{Musiani}}, others look into the political, legal, >>> commercial or social impact of protocols {{BrownMarsden}} {{Lessig}},= >>> {{Mueller}} and yet others look at how the engineers' personal set of= >>> values get translated into technology {{Abbate}},{{CathFloridi}} >>> {{Denardis15}} {{WynsbergheMoura}}. >> >> I'd also add: >> >> ' >> Within the community of IETF participants there is a fairly >> clear desire to as far as possible restrict IETF activities >> to those that are as purely technical and as little political, >> as is possible. Many of those participants would not accept >> the proposition that "protocols are politics by other means." >> >=20 > Thanks for this suggestion. I thought we could maybe rewrite it like th= is: >=20 > Within the community of IETF participants there is a strong desire to > solve technical problems and minimize the engagement with political > problems. >=20 > But then I thought: would people working on privacy agree with this? I > think for a lot of them this actually _is_ a political issue (same for > people active in GAIA, etc). So maybe something like: >=20 > Within the community of IETF participants there is a strong desire to > solve technical problems and minimize its engagement with political nearly-non-nit: s/its// many of us also want to minimise their engagement with us:-) > processes and non-protocol related political issues. >=20 > Might need some fine-tuning, but curious to hear what you think. That'd be fine if you also include this bit, which I think is important: ' Many of those participants would not accept the proposition that "protocols are politics by other means." ' It seems fairly clear that very different opinions on that quote have been expressed on the RG list and that that didn't resolve into us all agreeing with the quote. Cheers, S. >=20 >> >>> >>> Is your main problem with the quote: "protocols are politics by other= >>> means" ? >> >> Yes, and that the draft text seems to agree with that statement with >> no qualifications. >=20 > Hope we addressed that now :) >=20 >=20 >> >> S. >> >=20 >=20 >=20 > Cheers, >=20 > Niels >=20 >> >>> >>> Best, >>> >>> Niels >>> >>> >>>> Cheers, >>>> S. >>>> >>>> [1] https://tools.ietf.org/html/rfc6256 >>>> >>>>> >>>>> >>>>>>> >>>>>>> DeNardis, Laura. 2009. Protocol Politics: The Globalization of In= ternet >>>>>>> Governance. Cambridge, MA: MIT Press. >>>>>>> >>>>>>> as well as: >>>>>>> >>>>>>> DeNardis, Laura. 2014. The Global War for Internet Governance. >>>>>>> >>>>>>> I am still waiting for relevant literature that argues that techn= ology >>>>>>> is ethically neutral.=20 >>>>>> >>>>>> That is not what I claimed. Some technology is not ethically neutr= al. >>>>>> But I do assert that IETF technology some is ethically neutral. >>>>>> You seem to be asserting that no technology can ever be ethically >>>>>> neutral and I disagree with that. >>>>>> >>>>> >>>>> All technology has the characteristic of ordering and re-ordering t= he >>>>> world we live in. It stimulates certain behavior, and it inhibits >>>>> others. In this way it influences our public and private sphere and= thus >>>>> is political. >>>>> >>>>> It does so in major ways, such as where it directly touches upon ci= vil >>>>> liberties such as privacy and freedom of expression. But it also do= es so >>>>> in more subtle ways, via (lack of) availability in local languages,= >>>>> centralized vs distributed solutions, and reliability and performan= ce on >>>>> high latency networks vs low latency networks. >>>>> >>>>> And of course even the possibility of making specific things possib= le. >>>>> >>>>> This is all inherently political. >>>>> >>>>>>> We've cited quite a body of literature that argues >>>>>>> the exact opposite.=20 >>>>>> >>>>>> No, you did not provide exact opposites above. Yes, there is a bod= y >>>>>> of literature that argues as you do. It's fine that we do not all >>>>>> share the exact same opinions, but would be better if the draft di= d >>>>>> reflect that divergence. >>>>>> >>>>> >>>>> I think your argument diverges from the one Andrew makes. If you th= ink >>>>> we should capture your line of argumentation in the draft, let's ha= ve a >>>>> discussion about it. What kind of protocols do you think are not po= litical? >>>>> >>>>> >>>>>>> Repeating that technology is neutral will not make >>>>>>> it more true, but I am more than happy to be convinced. >>>>>> >>>>>> That was not repeated because it was not stated, by me at least >>>>>> and nor I think by Andrew. *Some* technology is neutral was my >>>>>> assertion. >>>>>> >>>>> >>>>> OK - let's work it out! >>>>> >>>>> Thanks again! >>>>> >>>>> Cheers, >>>>> >>>>> Niels >>>>> >>>>> >>>>>> Cheers, >>>>>> S. >>>>>> >>>>> >>>> >>> >> >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --vwvFAiKbdxE8hXBQcnn95QS1hS41v0nhK-- --bH7FbTpqcQhrTxP8eplAbqSLnnu1Hb5dQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYb8RiAAoJEC88hzaAX42iKtMIALZfxwjUb9G13AzbY7v2C0Us 7KC2B3p09kUX1JDll4GWxLWx42pAs1df+xPoTOJdxUNkU4NirF7FZ+YJaoD2iLGZ eAbAEUJKNIr7F6ZkeuhU3hIpf6DJQ6SVhHlwV3q3L8K4PKZqd9RNxOUBx3wQxRn6 BDN0IJt+/B6GsCjnIWGqh650GivbloH1s6csxjpYbhuLyET59IeesB20s0N0FqSr ZgI7UnOGyqrFco8FYOe+gqFMJyIlQ64QHJ499eRxOsTLi3L6o0qn+AkDfUZtOZCc TP4zQ7rdL2Lf4YhAY60PsPPrCQ37y6UeHFz4vUgikfDd5AD5hT4dhCZBqFKR81s= =JIN2 -----END PGP SIGNATURE----- --bH7FbTpqcQhrTxP8eplAbqSLnnu1Hb5dQ-- From nobody Fri Jan 6 08:25:58 2017 Return-Path: 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 F232E129B6E for ; Fri, 6 Jan 2017 08:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 38x6F-5HD2es for ; Fri, 6 Jan 2017 08:25:54 -0800 (PST) Received: from athene.wzb.eu (athene.wzb.eu [193.174.6.3]) (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 5BB18129411 for ; Fri, 6 Jan 2017 08:25:54 -0800 (PST) To: Eliot Lear , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> From: Jeanette Hofmann Message-ID: Date: Fri, 6 Jan 2017 17:25:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-WZB-Virus-Scanned: by Clam AntiVirus at athene.wzb.eu X-Priority: 3 (Normal) Importance: Normal Priority: normal Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 16:25:56 -0000 Am 06.01.17 um 15:37 schrieb Eliot Lear: > Jeanette, > > On 1/6/17 1:43 PM, Jeanette Hofmann wrote: > >> While I was doing research on the IETF, I was always interested in how >> and where its participants draw the line between a technical and a >> political decision. An easy line to draw was that between the IETF >> (driven by technical criteria) and the ITU (organised around political >> motives). Yet, when it comes to contested design issues such as IPv6 >> (which I studied at that time), the distinction between the technical >> and the political seems to blur. What is technical from one point of >> view, may appear political from another. I recall the length of IP >> addresses to be such a case in point. > > That's a really interesting aspect. From my own memory, the example you > give is a good one in several dimensions. One aspect of the decision > was whether or not the IETF would itself have control of the results. The change control issue was probably regarded as political by nearly everyone involved in the debate about IPNG. > If we chose TUBA, which based itself on ITU-T's X.233 standard, it was > far from clear whether who would have change control. Separately there > was a question of address lengths. At the time there were at least two > factions, one who believed that performance required a fixed address > size, and another who felt that we should never again put ourselves in > the position of having to do another transition. As you describe it, one could say that technical and non-technical concerns both played a role: performance (technical) and avoiding future transitions (non-technical). Those factions split > largely along endpoint versus router lines. I wouldn't call that purely > technical either. Endpoint developers wanted to spend their precious > cycles doing things other than parsing IP packets, whereas that is where > the bread and butter is for routing people. Now, this is surely a non-technical interpretation of what was going on. > > (...) >> >> I do agree that to declare everything as political does not help in >> this context. Yet, I am not sure political/non-political is an >> inherent quality of a technical standard. It might be something that >> is rather ascribed to it, depending either on one's definition of the >> political or on one's position in the development work of the standard. > > Say more about this? As you say above, the debates about address length were not purely technical. But some IETF people at that time discussed and regarded them as technical issues. So, it is perhaps more in the eye of the beholder or a matter of interpretation whether an issue is technical or political. jeanette > > Eliot > From nobody Fri Jan 6 09:00:13 2017 Return-Path: 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 42278129D13 for ; Fri, 6 Jan 2017 09:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=UAd3jVho; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=qADxIK2g 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 9qknqQYsfACa for ; Fri, 6 Jan 2017 09:00:10 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C26B129D0D for ; Fri, 6 Jan 2017 09:00:09 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5C874217CA; Fri, 6 Jan 2017 12:00:09 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Fri, 06 Jan 2017 12:00:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=lQ8P18Jf4AHBAlQ yrzu8/KcBPZ0=; b=UAd3jVhoI3kjfRneWyZobMNzW8u5fZ8gmUPRAANofJusXsx SCdtiGnzRVpKD/bLamwX7XOBgaCQHDRNb52tNTrG8cPCsOnB6BHWflV8B6VfrjkS 9Qam5MfwZVThnv07rWPKJ3ck1yIqCvie1TjOTkXuzG9bTRtHQdTKR/Ck++CI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=lQ8P18Jf4AHBAlQyrzu8/KcBPZ0=; b=qADxIK2gY0cagwNwFjLJ +qKdXZcUTZebU8EIx//WqnUQC5Sy7HQoQwe5wSNddmkxntWJNXNZQaACsb01bDCx gMyM7xbiKR5/O+KKrgQLvfCirRVokalwf7wjmQbinidkvbJ9MIc3PJ2lZhCtSAZn cfYaToD1ODoOrpswex8hqSk= X-ME-Sender: X-Sasl-enc: NZeSOp7IqsBdTP1C3iuBOA7jt2gYDC9udmo5ZYURj4c6 1483722009 Received: from dhcp-10-150-9-183.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 018037E9FB; Fri, 6 Jan 2017 12:00:08 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170106141722.3ob7c3otmgu2n5rn@nic.fr> Date: Fri, 6 Jan 2017 12:00:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:00:11 -0000 Hi Stephane, > On Jan 6, 2017, at 9:17 AM, Stephane Bortzmeyer = wrote: >=20 > On Thu, Jan 05, 2017 at 12:45:04PM -0500, > Alissa Cooper wrote=20 > a message of 201 lines which said: >=20 >> =3D Section 3.2.3 and 3.2.3.1 =3D >>=20 >> If the point of the IPv4 example is to demonstrate the human rights >> impacts -- both positive and negative -- of various protocol >> designs, I find the section to be narrow, slanted, and >> incomplete. It seems focused almost exclusively on the potential >> harms, which, for a protocol as fundamental to the operation of the >> Internet as IPv4, is not justified and renders this section somewhat >> useless IMO. >=20 > You raise an interesting question (which, I believe, was not > explicitely discussed in the RG before): should the "human rights" > review of the protocols just an example (of the consequences of > technical decisions for HR) or should it be a comprehensive and > detailed review, with no stone left unturned? >=20 > I believe the implicit choice was to just give examples. They are > necessary because, in the IETF, many people believe that technology is > more or less neutral, and do not think that a technical choice can > have political consequences. Therefore, it is useful to have concrete > examples. But, to quote the draft, "It is important to note that the > assessment here is not a general judgment on these protocols. When > they were conceived, there were many criteria to take into > account. [...] So, when we say 'protocol X has feature Y, which may > endanger the freedom of speech', it does not mean that protocol X is > bad and even less that its authors were evil. The goal here is to > show, with actual examples, that the design of protocols have > practical consequences for some human rights and these consequences > have to be considered at design time.=E2=80=9D Is the goal to give the impression that those consequences are almost = exclusively negative for human rights? Because almost every example = given in 3.2.3 is used to emphasize how a protocol design choice has had = a negative impact on human rights. I don=E2=80=99t think the examples in = this section need to provide a comprehensive analysis of each protocol. = But at a minimum they should demonstrate both the positive and negative = consequences of design choices for human rights, assuming people think = that both positive and negative implications exist. >=20 > So, I think I disagree with your review. The goal was not to give a > complete assessment of the Internet protocols (a different, and > certainly interesting work). >=20 >> IPv4 is the basis for packet-switching on the Internet. What would >> the human rights impacts be if packet-switching was never invented? >=20 > I don't think that IPv4 needs to be defended, its successes speak for > its importance and usefulness :-)=20 I really disagree. I think there are many people at this point who take = the underlying design of the internet as a given, perhaps more so for = the potential audience for this document than for a typical IETF = protocol spec. For that reason in particular I think it=E2=80=99s = important to reflect both the upsides and downsides when describing the = protocol design decisions. >=20 >> It seems to me that any evaluation of the human rights impacts of >> IPv4 needs to take this more wholistic view into account. >=20 > As I said, I think it is a different work. For instance, section 8 of > RFC 6973 does not make a "wholistic" analysis of the presence service, > and does not try to explain that it is useful. >=20 > By the way, the original versions of the draft were much more critical > of TCP/IP protocols, sometimes on the verge of paranoia. Well, as a first-time reader, the draft came off as excessively = negative. As noted above, I=E2=80=99m willing to concede that it need = not be wholistic, but it would be better if it were more balanced. >=20 >> The above is just one example of a fundamental aspect of the >> protocol that is overlooked in the existing analysis. Section >> 3.2.3.1.1 bemoans the visibility of source and destination >> addresses, while overlooking the fact that such addresses can >> actually provide a great deal of anonymity protection compared to >> other identifiers that could have been chosen to be made part of the >> protocol. >=20 > The fact that there were worst choices do not seem to me a sufficient > reason to limit the critical analysis. I=E2=80=99m not asking to take out the criticism, I=E2=80=99m asking to = add in acknowledgment of where the design decision arrived on the = spectrum of possible choices. I just think it=E2=80=99s too easy to say = retrospectively that the choice could have been better without = accounting for the fact that the choice actually was better than many = other possible choices. >=20 >> Section 3.2.3.1.2 then makes no mention of the fact that NAT can >> actually provide protection from such visibility. >=20 > "Home" NAT, the one currently the most common for fixed-line access > does not protect at all since the public IP address identifies a > home. But not an individual user. > It could be said that CGN protects a bit, but this is not the > case for all usages of NAT. >=20 >> it needs to state up front that it is cherry-picking a few harms >> identified as being linked to the protocol design just for >> demonstration purposes. >=20 > In my opinion, this is stated in section 3.2.3. Section 3.2.3 doesn=E2=80=99t say anything about the fact that it is = focusing specifically on harms or negative consequences. >=20 >> =3D Section 3.2.3 =3D >>=20 >> "For instance, relying on an external server can be bad for freedom >> of speech" -- without any further context provided, it's hard to >> understand what is meant by an "external" server. >=20 > How about "a server which is not under the direct control of one (or > both) of the parties which are communicating=E2=80=9D? Sure, that works. Thanks, Alissa From nobody Fri Jan 6 09:06:36 2017 Return-Path: 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 2C803129D0D for ; Fri, 6 Jan 2017 09:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 IcNbt5e7qh9u for ; Fri, 6 Jan 2017 09:06:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC671289B0 for ; Fri, 6 Jan 2017 09:06:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 73EF0BE8E; Fri, 6 Jan 2017 17:06:30 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOnNYUd5Y5yo; Fri, 6 Jan 2017 17:06:30 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E94ACBE5D; Fri, 6 Jan 2017 17:06:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483722390; bh=c8Cqsm6kCC+pZo4QJHTi650y/mtYCWAvvIRqsbdFR7s=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ikuT96rhXabnuVB7sv6wc83LPG1H5i+hhWGTvfr7ub/X7l2UC5bZQpCFzh5d3wZBY oMevfSLrusPT6zSy3eJXOg10sNzs8NrJpZFVhWoFFktdjUpLPGuuoMpz05IFvjGHbm XTF4mvUdkQYxT8xhOG1wvp132JQ3IQUfQIEX3gIU= To: Alissa Cooper , Stephane Bortzmeyer References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 6 Jan 2017 17:06:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000203010303080007010504" Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:06:35 -0000 This is a cryptographically signed message in MIME format. --------------ms000203010303080007010504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/01/17 17:00, Alissa Cooper wrote: > I think there are many people at this point who take the underlying > design of the internet as a given, perhaps more so for the potential > audience for this document than for a typical IETF protocol spec. For > that reason in particular I think it=E2=80=99s important to reflect bot= h the > upsides and downsides when describing the protocol design decisions. I think the above is a good point and well worth handling in the document. I'm not sure if a general statement along the above lines would be sufficient but it'd certainly be useful to add a paragraph or two ack'ing the HR benefits of current Internet protocols and saying that other text needs to be read with that in mind. Cheers, S. --------------ms000203010303080007010504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDYx NzA2MjlaMC8GCSqGSIb3DQEJBDEiBCAycsg88Gy2ZwDXo79uwwUbQFUOqMOvuh4FcsV31a6e 0zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCj4mYLEibbqI4ajbXu08WtDkBtdfl3sleT/EKb6ntw73apKMXvo6uK XZyb2Ri3SCwRyUNDpkbVvmU4scrKozYTql+K0k4PH1nVLf5CUanvwTaUf3V3isiKIlq1orqP IPPQ9E8XjFrt59mr2faqXIMvotAUfBQWSGyt/LmpGh0RmCj+4aNLLsFdq4v6GY3/ovbFcnJR x/CH+Vmk8NPglkK1qqQxndN6+NPbxC2alC9q4Sr9LuWSJTsfKLj5HMmoY9seRRJaok+J08/0 44jPsmNTVV/mA9wCnrWpUN52C2DeXP2OXNPBGERgDvFAgz8rCzjETxISqSknvGkrRilEI+nr AAAAAAAA --------------ms000203010303080007010504-- From nobody Fri Jan 6 09:13:40 2017 Return-Path: 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 0320E129D13 for ; Fri, 6 Jan 2017 09:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 G93d78dc-tMY for ; Fri, 6 Jan 2017 09:13:36 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 250A2129D10 for ; Fri, 6 Jan 2017 09:13:35 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPY56-0000kR-Ve; Fri, 06 Jan 2017 18:13:33 +0100 To: Stephen Farrell , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> Date: Fri, 6 Jan 2017 18:13:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ajxpUWXkO4UrW0OhMjCSBcPx3ASCFJWJD" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d27855690a8d8f56293e33d48b91aed0 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:13:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ajxpUWXkO4UrW0OhMjCSBcPx3ASCFJWJD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, On 01/06/2017 05:22 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > Progress! Great:-) >=20 > On 06/01/17 15:57, Niels ten Oever wrote: >> Hiya, >> >> On 01/06/2017 03:54 PM, Stephen Farrell wrote: >>> >>> Hiya, >>> >>> On 06/01/17 13:53, Niels ten Oever wrote: >>>> I am tempted to respond,=20 >>> >>> I think it'd be useful to know if you agree or not though. >>> Do you personally think [1] is political? From the mails >>> so far, I am under the impression that you do think [1] is >>> political. I do not. >>> >>> [1] https://tools.ietf.org/html/rfc6256 >>> >> >> Delay Tolerant Networking can be very relevant for human rights, >> especially in areas with low connectivity. >> As you know, Delay Tolant Networking is now also used a lot for IoT >> devices, so if this technology would enable something such as an >> emergency response device for human rights defenders, I think it could= >> be very useful as well. >> One could also think of deployments similar to Outernet >> (https://outernet.is/) which would improve the Right to Education. >> >> If this RFC makes de deployment of DTN easier, and thus positively >> contributes to these things, I indeed think it is political. >=20 > I fully disagree. We don't need to argue about it though so just > for the record: my reasoning is that yes aspects of DTN deployment > are political in the sense you describe, and yes aspects of DTN > protocol design were political in the corporate sense (I could go > into details, but they're still irritating to some folks so I > won't:-), but this particular aspect (use of SNDV as a way to > represent numbers) is just not political in any sense. Therefore > that RFC is apolitical too. I'd also assert that there are many > other aspects of DTN technology that are similarly purely technical > and apolitical. To offer a contrast though - whether or not to > include a checksum in bundles is something that could have been > purely technical but ended up being political (in the corporate > sense) due to the players involved. So it could have been the > case that SDNVs and this RFC were political, but the facts are > otherwise in that case. (And just to be clear: when I say > "corporate politics" I would include e.g. academic politics and > as was relevant in the case of DTN, non-technical disagreements > that happen inside even just one not-for-profit organisaton;-) >=20 > If an analogy might help: voting in elections is political, > but whether I walk or cycle to the polling station is not, in > itself, political. (It could be if I were a cycling advocate, > but in my case, my mode of transport to the polling station > is not a political act.) >=20 > Again - I'm happy to chat about the above, as it's interesting > where different folks draw the lines, but we definitely don't > need to resolve that discussion to be done with this draft. So > if someone does want to chat about that maybe best to start a > new thread. I propose we discuss this in person, maybe even during a hrpc RG session. I don't think this discussion is relevant now for the draft. >=20 >> >>>> but.... in the draft there is no sentence that >>>> says 'protocols are political'. Shall we go back to the text of the >>>> draft and see what issues there are in there? I think it's concentra= ted >>>> in this para: >>> >>> Yes. Some suggested changes below... >>> >>>> >>>> Protocols and standards are regularly seen as merely performing >>>> technical functions. However, these protocols and standards do not e= xist >>>> outside of their technical context nor outside of their political, >>>> historical, economic, legal or cultural context. This is best >>>> exemplified by the way in which protocols have become part and parce= l of >>> >>> s/which protocol/which some (but not all) Internet processes >>> and protocols/ >> >> Accepted - but if you don't mind I leave out '(but not all)', because >> that is the meaning of 'some'. >=20 > Sure. Though I prefer the emphasis:-) >=20 >>> >>>> political processes and public policies: one only has to look at the= >>>> IANA transition,=20 >>> >>> The IANA transition is all process, zero protocol. (Hence adding >>> processes above.) >> >> Accepted. >>> >>>> the RFC on pervasive monitoring or global innovation >>>> policy for concrete examples {{Denardis15}}.=20 >>> >>>> To quote {{Abbate}}: >>> >>> S/To quote/According to/ >>> >> >> Accepted >> >>>> "protocols are politics by other means". This statement confers that= >>>> protocols are based on decision making, most often by humans. In thi= s >>>> process the values and ideas about the role that a particular techno= logy >>>> should perform in society is embedded into the design. Often these >>>> design decisions are part pure-technical, and part inspired by certa= in >>>> world view of how technology should function that is inspired by >>>> personal and political views.=20 >>> >>> s/personal and political/personal, corporate and political/ >> >> Accepted >> >>> >>> The reality is that corporate beats out political most of the time. >>> >>>> Since the late 1990's a burgeoning group >>>> of academics and practitioners researched questions surrounding the >>>> societal impact of protocols, and the politics of protocols. These >>>> studies vary in focus and scope: some focus on specific standards >>>> {{Davidsonetal}} {{Musiani}}, others look into the political, legal,= >>>> commercial or social impact of protocols {{BrownMarsden}} {{Lessig}}= , >>>> {{Mueller}} and yet others look at how the engineers' personal set o= f >>>> values get translated into technology {{Abbate}},{{CathFloridi}} >>>> {{Denardis15}} {{WynsbergheMoura}}. >>> >>> I'd also add: >>> >>> ' >>> Within the community of IETF participants there is a fairly >>> clear desire to as far as possible restrict IETF activities >>> to those that are as purely technical and as little political, >>> as is possible. Many of those participants would not accept >>> the proposition that "protocols are politics by other means." >>> >> >> Thanks for this suggestion. I thought we could maybe rewrite it like t= his: >> >> Within the community of IETF participants there is a strong desire to >> solve technical problems and minimize the engagement with political >> problems. >> >> But then I thought: would people working on privacy agree with this? I= >> think for a lot of them this actually _is_ a political issue (same for= >> people active in GAIA, etc). So maybe something like: >> >> Within the community of IETF participants there is a strong desire to >> solve technical problems and minimize its engagement with political >=20 > nearly-non-nit: s/its// many of us also want to minimise their > engagement with us:-) >=20 Accepted. >> processes and non-protocol related political issues. >> >> Might need some fine-tuning, but curious to hear what you think. >=20 > That'd be fine if you also include this bit, which I think is > important: >=20 > ' > Many of those participants would not accept > the proposition that "protocols are politics by other means." > ' >=20 > It seems fairly clear that very different opinions on that quote > have been expressed on the RG list and that that didn't resolve > into us all agreeing with the quote. >=20 Hmmmmm. We did not poll IETF-ers about this so this would be guestimating. We're not saying IETF-ers agree with this either, right? Cheers, Niels > Cheers, > S. >=20 >> >>> >>>> >>>> Is your main problem with the quote: "protocols are politics by othe= r >>>> means" ? >>> >>> Yes, and that the draft text seems to agree with that statement with >>> no qualifications. >> >> Hope we addressed that now :) >> >> >>> >>> S. >>> >> >> >> >> Cheers, >> >> Niels >> >>> >>>> >>>> Best, >>>> >>>> Niels >>>> >>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> [1] https://tools.ietf.org/html/rfc6256 >>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> DeNardis, Laura. 2009. Protocol Politics: The Globalization of I= nternet >>>>>>>> Governance. Cambridge, MA: MIT Press. >>>>>>>> >>>>>>>> as well as: >>>>>>>> >>>>>>>> DeNardis, Laura. 2014. The Global War for Internet Governance. >>>>>>>> >>>>>>>> I am still waiting for relevant literature that argues that tech= nology >>>>>>>> is ethically neutral.=20 >>>>>>> >>>>>>> That is not what I claimed. Some technology is not ethically neut= ral. >>>>>>> But I do assert that IETF technology some is ethically neutral. >>>>>>> You seem to be asserting that no technology can ever be ethically= >>>>>>> neutral and I disagree with that. >>>>>>> >>>>>> >>>>>> All technology has the characteristic of ordering and re-ordering = the >>>>>> world we live in. It stimulates certain behavior, and it inhibits >>>>>> others. In this way it influences our public and private sphere an= d thus >>>>>> is political. >>>>>> >>>>>> It does so in major ways, such as where it directly touches upon c= ivil >>>>>> liberties such as privacy and freedom of expression. But it also d= oes so >>>>>> in more subtle ways, via (lack of) availability in local languages= , >>>>>> centralized vs distributed solutions, and reliability and performa= nce on >>>>>> high latency networks vs low latency networks. >>>>>> >>>>>> And of course even the possibility of making specific things possi= ble. >>>>>> >>>>>> This is all inherently political. >>>>>> >>>>>>>> We've cited quite a body of literature that argues >>>>>>>> the exact opposite.=20 >>>>>>> >>>>>>> No, you did not provide exact opposites above. Yes, there is a bo= dy >>>>>>> of literature that argues as you do. It's fine that we do not all= >>>>>>> share the exact same opinions, but would be better if the draft d= id >>>>>>> reflect that divergence. >>>>>>> >>>>>> >>>>>> I think your argument diverges from the one Andrew makes. If you t= hink >>>>>> we should capture your line of argumentation in the draft, let's h= ave a >>>>>> discussion about it. What kind of protocols do you think are not p= olitical? >>>>>> >>>>>> >>>>>>>> Repeating that technology is neutral will not make >>>>>>>> it more true, but I am more than happy to be convinced. >>>>>>> >>>>>>> That was not repeated because it was not stated, by me at least >>>>>>> and nor I think by Andrew. *Some* technology is neutral was my >>>>>>> assertion. >>>>>>> >>>>>> >>>>>> OK - let's work it out! >>>>>> >>>>>> Thanks again! >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Niels >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> S. >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >> >=20 --ajxpUWXkO4UrW0OhMjCSBcPx3ASCFJWJD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb9A8AAoJEA7YPzpGisiz3DsP/RiHSBwLivpVcv/EnsNxS74X GRnLw/VMWn8GZyDfDNgPHYXDxJl5AKJUDWOYfZrbdrRLA8n96sOw/jllKrBhuPMc ci34UQYTuwtz+AMTdVJGGcgZnkb5U8+3fe6cIy4yJtjb3pmeVwmNT7nswRuky1Se mF9OZb1u4IVkjKCaxkmjBqiP8KRqv4sYoYIpwmm0vXDW0nyFOpLKSI/0jtf5Ghn7 MrvOXzpUGO5ClIW8S8XXBy0KV355zJy76Hz6C5gpZyl4vQP2A1MkbXMl3K43xCpU mwRkq49Y4bLqgXj33Ye0+ISuCyAyzzkPQS6DMplCehejiq6xPi34gW9HeFraVdR9 ILUyDoc1PuX2RhwliJ5ScaXm/QFlFtDjX/dSMjhtlFNiCkc5sp3hZhuq/+PDPrst 4V9nfJqiWDeudlPpzgMx7T8Aur8Sws3CiWKmL92sRi7NSFBi395QIjBaJfd4ASWG 6rqE2D6d4Y/sohhc2G+C4v+hd4xIyl1yPP3ZSxetpW2Cycc1KNoT1YA/T+K7QiNz cts0ma30IkXbci6XXD5DnNd8K2uozg/UvGOyHgLaPE/EpkLVzDtWz8BAeFv+sIbQ lCngCO2S2ydH1IEVImrUGs/esaRuWS99X0KhtPP8yTSzew9rJvIUj9FlCFcZjUzE fepL/tKzTlvqsycFzQny =Iihh -----END PGP SIGNATURE----- --ajxpUWXkO4UrW0OhMjCSBcPx3ASCFJWJD-- From nobody Fri Jan 6 09:17:07 2017 Return-Path: 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 6153A128B37 for ; Fri, 6 Jan 2017 09:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 f6Wi86gGDunO for ; Fri, 6 Jan 2017 09:17:04 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 7648A1289B0 for ; Fri, 6 Jan 2017 09:17:04 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A85B9280337; Fri, 6 Jan 2017 18:17:02 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id A1D522802B2; Fri, 6 Jan 2017 18:17:02 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 9EA63B38003; Fri, 6 Jan 2017 18:16:32 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 9804C3FE08; Fri, 6 Jan 2017 18:16:32 +0100 (CET) Date: Fri, 6 Jan 2017 18:16:32 +0100 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20170106171632.ywoh52l5al4p5yzp@nic.fr> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.7.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: Stephane Bortzmeyer , Alissa Cooper , hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:17:06 -0000 On Fri, Jan 06, 2017 at 05:06:29PM +0000, Stephen Farrell wrote a message of 105 lines which said: > it'd certainly be useful to add a paragraph or two ack'ing the HR > benefits of current Internet protocols Any specific example in mind? It has to be specific, just saying "IP enables people to communicate, which is good", is not, IMHO, sufficient. From nobody Fri Jan 6 09:18:10 2017 Return-Path: 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 D555612941C for ; Fri, 6 Jan 2017 09:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 tCRdu__OYWsn for ; Fri, 6 Jan 2017 09:18:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AA61289B0 for ; Fri, 6 Jan 2017 09:18:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72AE9BE5D; Fri, 6 Jan 2017 17:18:04 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxan0CCh4oPR; Fri, 6 Jan 2017 17:18:04 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DC13FBE4D; Fri, 6 Jan 2017 17:18:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483723084; bh=oDfdAvratOjwVOeYVZwIE0x3mag1w//9WcpvB7sFiFo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=zeZAJcN75i4FZ8QyC4VE3JviiUjd11D0ZUbKL+mgix/OiJWJEfcvVfujuAms8cv2M KFeqA/CimQnntdtybLst8BTeOq3UP8x98yIpp9glx326ORp//dkml7EqMlp6TL9zNk Zcpw/SPm9ZXssPXPVx9EydGp6yYHK6/WCruBWIxE= To: Stephane Bortzmeyer References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> <20170106171632.ywoh52l5al4p5yzp@nic.fr> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <04f23833-7a7a-339c-aeca-7d4f86c18959@cs.tcd.ie> Date: Fri, 6 Jan 2017 17:18:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170106171632.ywoh52l5al4p5yzp@nic.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050305030102000307030100" Archived-At: Cc: Alissa Cooper , hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:18:09 -0000 This is a cryptographically signed message in MIME format. --------------ms050305030102000307030100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/01/17 17:16, Stephane Bortzmeyer wrote: > On Fri, Jan 06, 2017 at 05:06:29PM +0000, > Stephen Farrell wrote=20 > a message of 105 lines which said: >=20 >> it'd certainly be useful to add a paragraph or two ack'ing the HR >> benefits of current Internet protocols >=20 > Any specific example in mind? It has to be specific, just > saying "IP enables people to communicate, which is good", is not, > IMHO, sufficient. Maybe Alissa has ideas for text? :-) S. >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --------------ms050305030102000307030100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDYx NzE4MDNaMC8GCSqGSIb3DQEJBDEiBCCZ+e7+irHpHrc2W0kl6to31j7E59toN+i19mh8x0oz cDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAA4MREWXWS4q8VdMZJkqWQUffzIjr/3hPJ24EJA/24YunycTA1+l9y NKCjGSV9cxb+0uuXp5FfwhZLsuT93j5A/bUQ+gjHzDr8hh3rtmb+FJ++YK3aClXLABlTVDTt TfyHTTDp4M9621mXFNrSNKlHkvAaJdWH4b+BsHQMQbdOxnSpEpJbUzWtJBOGk6243vTeOI3v r9S1Vcr99oyR3TXSaDLfEMdpV4brU3wOahOYH8pib+wQgWUFPqmOh3/ISd/TSwn8aFqWfcMo TijOGvvQQecbiM4fbpVO46UxJuHaCEXBdMN2dzzgGNnBccCKkjU8eYSN2iaY0RO5VJw3Oim4 AAAAAAAA --------------ms050305030102000307030100-- From nobody Fri Jan 6 09:22:02 2017 Return-Path: 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 68257129D1F for ; Fri, 6 Jan 2017 09:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 UZ8X9uDFt6sw for ; Fri, 6 Jan 2017 09:21:59 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9041C129D1C for ; Fri, 6 Jan 2017 09:21:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7712FBE5D; Fri, 6 Jan 2017 17:21:57 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2U55p7PDjTs; Fri, 6 Jan 2017 17:21:57 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DFD12BE4D; Fri, 6 Jan 2017 17:21:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483723317; bh=hE94b+fuSms1XF5pkM6uAEu9pco9bv7tnO+tE+h+1Uk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=uYcfCgudez/7pUwYDCrHkSEy56GxzTGJywjI7vBPyloXF5YUKtkva+NZ6S9Benvyo AZ6Ka9pomDCY1maWadB/rfosSGJe5USvKN5sZ9Y1attMBBdnk9WjCTF5LVBxR6p3E7 4OFSmQLt+29R49nzKwx0K45a8X9AOjcB35LLUfis= To: Niels ten Oever , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 6 Jan 2017 17:21:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vnHK568g47FlR2A26GMAcOrrn8ohKkElC" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:22:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vnHK568g47FlR2A26GMAcOrrn8ohKkElC Content-Type: multipart/mixed; boundary="9l7TXNDSjv3sBqaqx3MLrdWtoitJbJ79b"; protected-headers="v1" From: Stephen Farrell To: Niels ten Oever , hrpc@irtf.org Message-ID: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> In-Reply-To: <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> --9l7TXNDSjv3sBqaqx3MLrdWtoitJbJ79b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 06/01/17 17:13, Niels ten Oever wrote: >> ' >> Many of those participants would not accept >> the proposition that "protocols are politics by other means." >> ' >> >> It seems fairly clear that very different opinions on that quote >> have been expressed on the RG list and that that didn't resolve >> into us all agreeing with the quote. >> > Hmmmmm. We did not poll IETF-ers about this=20 Well, not counting heads is what we do:-) > so this would be > guestimating. We're not saying IETF-ers agree with this either, right? I agree that saying "many" could be arguable, though I think it's the case from my experience with IETFers. If you really feel a need to water this down (or Avri as consensus-caller on this one does), I could live with the weasely worded: ' Note that a number of HRPC participants do not accept the proposition that "protocols are politics by other means" - whether or not that means there would be an IETF consensus for or against that proposition is unclear, the question not having been asked. ' But to be clear: I prefer the non weasel word version. Cheers, S. --9l7TXNDSjv3sBqaqx3MLrdWtoitJbJ79b-- --vnHK568g47FlR2A26GMAcOrrn8ohKkElC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYb9I0AAoJEC88hzaAX42i5Q0H/2nLbGm/s9NYQ5u+uAO2KK4X QAnPYpHRbnGMaxb9MPFTs117Cz7yJnnjbY8bpbY34+0jDpahN9lkg5FLHM7ZwFkc W3ejU9ekWr1Ymiv5bXPXbDXn+k8rCGXlSI4Wkj5I4Xs6geE+Z0SV2JOMGO/2vBJ0 vH4Mn9P+E6Hdv1Ipt9jK+toqanyUy1ClwqOskaaVt6znv5mJAtBj9VwWU4/PsCvU p8WLO6jD6fZaAStAK1nEY2iFCL1ZVl41fGHG6QzXOqGMey/K7fepLerdzAoEAjAu cNzOTeFOYoOjy/w1HznTLrt445xLxgmy97DuM47vKLtCyp2SSHZhjuPFyAYTIHM= =5qRB -----END PGP SIGNATURE----- --vnHK568g47FlR2A26GMAcOrrn8ohKkElC-- From nobody Fri Jan 6 09:26:36 2017 Return-Path: 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 D5556129532 for ; Fri, 6 Jan 2017 09:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.89 X-Spam-Level: X-Spam-Status: No, score=-4.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=pmsK9imu; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=o8mfgtYy 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 fmJhYSUt9Tll for ; Fri, 6 Jan 2017 09:26:33 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB81D129D1D for ; Fri, 6 Jan 2017 09:26:21 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v06HQ3xT005066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2017 09:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1483723577; x=1483809977; bh=6JvKvpVBNYronVAaOe4YO7te7JIFWW7O0/E4+UNVB2A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pmsK9imuaJDKFq/N752E7hVZeCw9gv8dFYq24ZFtfnU8lHPdtWZKrz5nP5u+OckbS CiemphZ0q2pKbtvhLrngyLwmlN1f0biQHQZdJz7FltqXstW7/3Gp02J3hTsWgN2OAl oES3h332uIgJjG613XA49vzI/rI1aLP7viu43aF0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1483723577; x=1483809977; i=@elandsys.com; bh=6JvKvpVBNYronVAaOe4YO7te7JIFWW7O0/E4+UNVB2A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=o8mfgtYyanXpedkU04bLLuzDZATC5Z+pLb79Z6raBEdZSPEEtua1ZGgtNDGJjIsZK 8lfVlr+MpJzWHP95bXjjjeEi1nl0bIOkDYoiZdMIJUci/SbacIWsY1wv01EWsZpXst fYcwT9e0tKk+IInC7EOOU+9qp3MKm7lQJKWOh9Rc= Message-Id: <6.2.5.6.2.20170106073132.0b87b960@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2017 09:26:00 -0800 To: Stephane Bortzmeyer From: S Moonesamy In-Reply-To: <20170106144928.um4lfk7gjpo2ryn2@nic.fr> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <20170106144928.um4lfk7gjpo2ryn2@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Corinne Cath , Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:26:35 -0000 Hi Stephane, At 06:49 06-01-2017, Stephane Bortzmeyer wrote: >That's clearly not true. There are several RFCs about logging such as >RFC 6302, which has clear HR consequences. (There is also RFC 6269 or >7937 or 7422 or even 7011.) "What is a protocol" is a matter of debate in the IETF. The privacy impact of an IETF specification was not an issue for a significant amount of pre-2014 IETF standards-track documents or it was viewed as an issue to be considered when a IETF participant or IETF Area Director with an interest in security or privacy raised a concern. Logging takes an IETF standards-track document beyond what is known as "end-to-end". Are there privacy issues in respect to logging? Yes. Should an IETF standards-track document (this is not the same as a RFC) recommend what information should be logged? No. Are there HR consequences when logging? Yes. Using RFC 7422 as an example (it is not an IETF document), it says that there is a "legal logging requirement". Can the legal requirements of another country be disputed? Regards, S. Moonesamy From nobody Fri Jan 6 09:27:32 2017 Return-Path: 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 016D0129B73 for ; Fri, 6 Jan 2017 09:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 aGTVvYAXQsCp for ; Fri, 6 Jan 2017 09:27:30 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 10C69129532 for ; Fri, 6 Jan 2017 09:27:30 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 7C6A1280337; Fri, 6 Jan 2017 18:27:28 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 76D372802B2; Fri, 6 Jan 2017 18:27:28 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 75082B38003; Fri, 6 Jan 2017 18:26:58 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 6EB3E3FE08; Fri, 6 Jan 2017 18:26:58 +0100 (CET) Date: Fri, 6 Jan 2017 18:26:58 +0100 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20170106172658.x47wn7vbivg2vn4d@nic.fr> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> <20170106171632.ywoh52l5al4p5yzp@nic.fr> <04f23833-7a7a-339c-aeca-7d4f86c18959@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04f23833-7a7a-339c-aeca-7d4f86c18959@cs.tcd.ie> X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.7.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: Alissa Cooper , Stephane Bortzmeyer , hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:27:31 -0000 On Fri, Jan 06, 2017 at 05:18:03PM +0000, Stephen Farrell wrote a message of 113 lines which said: > Maybe Alissa has ideas for text? I suspect that most "positive benefits for HR" will be "negative features" such as "SMTP does NOT require that the user sending an email has a client certificate, which is good for anonymity" From nobody Fri Jan 6 09:27:48 2017 Return-Path: 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 E270E129B73 for ; Fri, 6 Jan 2017 09:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 pMbnr28AWKyw for ; Fri, 6 Jan 2017 09:27:45 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 AD943129532 for ; Fri, 6 Jan 2017 09:27:45 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPYIq-0003zJ-2W; Fri, 06 Jan 2017 18:27:44 +0100 To: Stephen Farrell , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> From: Niels ten Oever Message-ID: <970334be-2665-33c2-c40f-4838ab632b96@article19.org> Date: Fri, 6 Jan 2017 18:27:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VD3Vr6sP7XkIBvGvSUkABoiKw07Xpg8b5" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: ee739817b6cd2655ac6326818c89325b Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:27:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VD3Vr6sP7XkIBvGvSUkABoiKw07Xpg8b5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/06/2017 06:21 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 06/01/17 17:13, Niels ten Oever wrote: >>> ' >>> Many of those participants would not accept >>> the proposition that "protocols are politics by other means." >>> ' >>> >>> It seems fairly clear that very different opinions on that quote >>> have been expressed on the RG list and that that didn't resolve >>> into us all agreeing with the quote. >>> >> Hmmmmm. We did not poll IETF-ers about this=20 >=20 > Well, not counting heads is what we do:-) >=20 >> so this would be >> guestimating. We're not saying IETF-ers agree with this either, right?= >=20 > I agree that saying "many" could be arguable, though I think it's > the case from my experience with IETFers. If you really feel a > need to water this down (or Avri as consensus-caller on this one > does), I could live with the weasely worded: >=20 > ' > Note that a number of HRPC participants do not accept > the proposition that "protocols are politics by other > means" - whether or not that means there would be > an IETF consensus for or against that proposition > is unclear, the question not having been asked. > ' >=20 > But to be clear: I prefer the non weasel word version. >=20 What about this, I think it's a bit more elegant and says the same and ensure we don't have repetition: According to {{Abbate}}: "protocols are politics by other means". This statement would probably not get IETF consensus, but it nonetheless confers that protocols are based on decision making, most often by humans. In this process the values and ideas about the role that a particular technology should perform in society is embedded into the design. Often these design decisions are part pure-technical, and part inspired by certain world view of how technology should function that is inspired by personal, corporate and political views. Within the community of IETF participants there is a strong desire to solve technical problems and minimize engagement with political processes and non-protocol related poltical issues. Cheers, Niels > Cheers, > S. >=20 >=20 --VD3Vr6sP7XkIBvGvSUkABoiKw07Xpg8b5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb9OPAAoJEA7YPzpGisizpGEP/Ayr533kD5f+KL7eLIOELUHw gY8m0zkk5YbuUyS9X7pBmj0KqmGIHN5jyV5nR/9ZAEvDixTo1v1F9vabgl6c4ncU uKkSZDNGsXwxP1WApEBHp9hq8jXfPrnwFx5bR6V3V5E4YQlzW96kchpGGXDmtfQq Mluo0eMXP6gOiQeYRY9cqNcuIkKjhC1MGjTAML6OD7LDRbSCTPvO2XFfbn/DWVQf MIHdp1eVofmJpI0EpB8qjLII42siALGM1ie45Ti2rS7KcIq1NLvv4vOyN0gwTG6n sLHuEs7gJOZNp2fFNhc+rgAW7mWjRLPWp3uy0U0nu10wSGorMVqYVaIPo8DN5+jE sBZvV9DU2071I8VkqqjvMno3Gw7EtvT4tU698vHS9De2QD2IOgiIS6h/Zfw/YbMy TH8GUphAAm8vs7tmesxk/7nkbJgTj9cmPPLtB1owUP+MBJFDGuLyYrxF+wxvpnOS gnkDSq2WkfFQP7qAwbF6qYR3GnPhWB5ghxQvigF7C1GUnj9oz+70epqWJm5jMuCM 2a7aDJ69cGIWi2mFohBdydUIHUhMU7zJWjI595HNq8jMhXEf0pixUFG4mCBraSfC ZoZOuPa4gjM4bdiAds3mu32bXCnDYTcd8pMPMBH7tpkMDIOhWygEdRZeFXI0q6YN i1ZSMnhtDQZ2w4aFzMCt =DAW4 -----END PGP SIGNATURE----- --VD3Vr6sP7XkIBvGvSUkABoiKw07Xpg8b5-- From nobody Fri Jan 6 09:29:13 2017 Return-Path: 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 1AC71129B73 for ; Fri, 6 Jan 2017 09:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 CucqU5cY7jfc for ; Fri, 6 Jan 2017 09:29:10 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 D0F18129D28 for ; Fri, 6 Jan 2017 09:29:09 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so84675102qtb.0 for ; Fri, 06 Jan 2017 09:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q/+b7jwG+x1698YPeJBRNpKm/1v9gWiR7hMgHJnRKL4=; b=D1YgPkVtVoFUCOHV9Gz62Dazl83pBCaoYGY89wEYUtKkRN1f3JH0imC9Mn+dbtTqO6 aIaz/XYwKk/ZHol+gSV76S9OMQTAriJeY8yzyvw+GuZH2L01eWSqqqvuDR265xRGr0c8 fPRPLXnIizlWLB+CUQ0YPF5Wjbh7Z1sjSbL0Q7UUobt2oEUXSP+Vx0Q62iBzTx8FdsNT APk63/vpN+vkSVR2ICY6RyPQoWZXn9WM1MpVk2gYRTmd4DbzTARprrcQT4cv43TM0Q5s V4lb3FOW/mIJAaLSEQDOwT1HECbgS4m5qSmYV5SpgBt85tFYLCLjkR+niJeBnu4Xvwyi dxPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q/+b7jwG+x1698YPeJBRNpKm/1v9gWiR7hMgHJnRKL4=; b=ZuGbyaiquuxPlXhYsThB0Cqr4Fs5ggy3axqtFyl+7CVzs7VOE9GxCEHf10cgqMCIzI yjBOrisxDdnpCsgo58Yo3QbsUbHzrdJeEgN3kcR/+qEXPkN3W/+fZC3BC4XGRYaoMvpx QqSos4VLgVHJz+z+0WACbYvJGwfs9gqGCkZeQr2HlA8OnGcgwGCTQhgUqve9f4ct54g+ gSYfdeGvU7cHzBaiHQAr2YGb6//Lk+QR6RzMsFu3JpAdbXVDiG/tNzpu6msGSyggMQmz pBH1SpGPjUMHZrfobOMrcFX8qYVeKy9/dJzXJ3iLTvo/j25foq2FiBali4sU9DO0Hv+v gi6Q== X-Gm-Message-State: AIkVDXLsdAn3rcTrYd+QiASN8KONm8Wr6QEkfneOoP0AhLJqZ1MRxAAhMZKmmwhAAqftLw== X-Received: by 10.237.48.99 with SMTP id 90mr64386284qte.228.1483723747037; Fri, 06 Jan 2017 09:29:07 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q88sm40460064qkq.21.2017.01.06.09.29.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 09:29:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <20170106172658.x47wn7vbivg2vn4d@nic.fr> Date: Fri, 6 Jan 2017 12:29:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <78665999-B060-4B6D-9005-008F7A99B62F@fugue.com> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> <20170106171632.ywoh52l5al4p5yzp@nic.fr> <04f23833-7a7a-339c-aeca-7d4f86c18959@cs.tcd.ie> <20170106172658.x47wn7vbivg2vn4d@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Alissa Cooper , hrpc@irtf.org, Stephen Farrell Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:29:12 -0000 folks, please be careful not to give redundant answers or repeat = yourself. this discussion has officially reached the too-fast stage, = where nobody but the four of you can realistically be expected to = actually follow it. From nobody Fri Jan 6 09:31:11 2017 Return-Path: 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 D863C129B73 for ; Fri, 6 Jan 2017 09:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ICkyWfhgF36u for ; Fri, 6 Jan 2017 09:31:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CAC129532 for ; Fri, 6 Jan 2017 09:31:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6611FBE7C; Fri, 6 Jan 2017 17:31:05 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXt8sVwvCCwZ; Fri, 6 Jan 2017 17:31:05 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DD6AFBE5D; Fri, 6 Jan 2017 17:31:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483723865; bh=GFc+MBmHM92o0g9TGKvak7MwLlgIdf4bXQYv3ZLYbJY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NDBRHniROjYuxUnT2N8Fpd0E1WBHbEpUB6dw11XigbDMoBPP0c2NkHpc7q4UUTCEX g903sCjheaXU7mxidzB5gXlI+8MMtP/HydN7UN/hJc1EzGhtL+CsTkXKTs5B5w750W fSh6JoTL+eqDBRvYFCwukf3pc6020Iq+GlSQBUaw= To: Niels ten Oever , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <970334be-2665-33c2-c40f-4838ab632b96@article19.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0a45b4b9-3c8f-b7cf-5440-6fe59e298938@cs.tcd.ie> Date: Fri, 6 Jan 2017 17:31:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <970334be-2665-33c2-c40f-4838ab632b96@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qhxJftgovlkfEA4Rpm44LCnIAWT04wCfG" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:31:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qhxJftgovlkfEA4Rpm44LCnIAWT04wCfG Content-Type: multipart/mixed; boundary="DW8SWg9OSIkmDIg4fWrVbO7Bpswd8a0Ub"; protected-headers="v1" From: Stephen Farrell To: Niels ten Oever , hrpc@irtf.org Message-ID: <0a45b4b9-3c8f-b7cf-5440-6fe59e298938@cs.tcd.ie> Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <970334be-2665-33c2-c40f-4838ab632b96@article19.org> In-Reply-To: <970334be-2665-33c2-c40f-4838ab632b96@article19.org> --DW8SWg9OSIkmDIg4fWrVbO7Bpswd8a0Ub Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I could live with that, thanks. One tweak suggested below. Cheers, S. On 06/01/17 17:27, Niels ten Oever wrote: > According to {{Abbate}}: "protocols are politics by other means". This > statement would probably not get IETF consensus, but it nonetheless s/get/garner/ > confers that protocols are based on decision making, most often by > humans. In this process the values and ideas about the role that a > particular technology should perform in society is embedded into the > design. Often these design decisions are part pure-technical, and part > inspired by certain world view of how technology should function that i= s > inspired by personal, corporate and political views. Within the > community of IETF participants there is a strong desire to solve > technical problems and minimize engagement with political processes and= > non-protocol related poltical issues. --DW8SWg9OSIkmDIg4fWrVbO7Bpswd8a0Ub-- --qhxJftgovlkfEA4Rpm44LCnIAWT04wCfG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYb9RYAAoJEC88hzaAX42iVNwH+gO9YpRQMl8cg38KkH6Bbk4v 7aVKV8mBT6f/CT/ML663Rc6SJHBQUyT1yt+kB8hEd9msyNYj6qisc8sqPTcKDCIz 2U57XUuJIx2FuL6bkeMw/9iGDyQNCZxepcGe5dye5Eas5f8QL4bBHoXJgMtbcThQ Oo19YZKK10upGLdgf6wOujNJ/aldXpaQ8no5uR3RgFcirLFfa43NQy0oslcY6JD+ APu2AsHeNBMtnHRW42yppecDAwKqAJ7S9CvG3jtZHDl+KTRo70rS8PpTpdRS+8e9 TMOHZMbJoEGxaD9QpAsIgc3OQm6XA/ra0CtbiQoWn08a9B5gidV1Ei8VrJxg3wU= =HNKx -----END PGP SIGNATURE----- --qhxJftgovlkfEA4Rpm44LCnIAWT04wCfG-- From nobody Fri Jan 6 09:39:16 2017 Return-Path: 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 7EB06129D18 for ; Fri, 6 Jan 2017 09:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 U_f4mg4rKz16 for ; Fri, 6 Jan 2017 09:39:12 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 26816129591 for ; Fri, 6 Jan 2017 09:39:12 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPYTt-00066X-VX for hrpc@irtf.org; Fri, 06 Jan 2017 18:39:10 +0100 To: hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> <20170106142051.GA12568@mx2.yitter.info> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 6 Jan 2017 18:39:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170106142051.GA12568@mx2.yitter.info> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RKcgjMGXNSO3uFacrlh6BC4s6SQiX1U1v" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 2485fe5ecba3c49e4271528352f521e3 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:39:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RKcgjMGXNSO3uFacrlh6BC4s6SQiX1U1v Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Andrew, On 01/06/2017 03:20 PM, Andrew Sullivan wrote: > On Fri, Jan 06, 2017 at 02:08:03PM +0100, Niels ten Oever wrote: >> >> I think this para refutes your interpretation: >> >> The Internet: A large, heterogeneous collection of interconnected >> systems that can be used for communication of many different typ= es >> between any interested parties connected to it. The term includ= es >> both the "core Internet" (ISP networks) and "edge Internet" >> (corporate and private networks, often connected via firewalls, >> NAT boxes, application layer gateways and similar devices). The= >> Internet is a truly global network, reaching into just about eve= ry >> country in the world. >> The IETF community wants the Internet to succeed because we >> believe that the existence of the Internet, and its influence on= >> economics, communication, and education, will help us to build a= >> better human society. >> >> In the first paragraph the technical aspect is explained (from which y= ou >> could potentially derive a networking ethic) >=20 > Sure. >=20 >> , but the second parapgraph clearly explains a (primitive) external >> ethic. >=20 > Yes. Note that it is a claim about "the IETF community" and not "the > IETF". It has never been plain to me why BCP 95 makes that > distinction, but it appears to. It's also a claim about beliefs. But > none of this shows that IETF participants are not choosing what they > think of as "Internet technologies" as opposed to other ones. The > point is merely that the story I've told is _consistent_ with the > outcome you appear to want. >=20 >=20 >> We embrace technical concepts such as >> decentralized control, edge-user empowerment and sharing of >> resources, because those concepts resonate with the core values of >> the IETF community. These concepts have little to do with the >> technology that's possible, and much to do with the technology that= >> we choose to create. >> >> means that these concepts are derived from an inherent inter-networkin= g >> ethics, I am afraid I have to disagree. >=20 > I don't believe I said that; I certainly didn't intend to. My point > is rather that the humans doing the work might have some extrinsic > value in mind, but the ethic of the network conveniently aligns with > those extrinsic values. So, _even if_ a particular IETF participant > doesn't agree with some part of BCP 95, by virtue of working on > Internet technologies they might still be contributing to the same > extrinsic goal. >=20 >> Because there is also an >> inter-networking solution possible without edge-user empowerment. >=20 > Really? How? I think this is tied to your response to my remark > about internetworking as opposed to other kinds of networking. >=20 > Perhaps I can put this differently: I think that "the Internet" is a > mass noun that denotes an emergent property, rather like "the traffic > on the Don Valley Parkway" does. There is no _thing_, "the traffic", > that you can change. All you can do is change constituent parts by > affecting individuals' behaviour, and so similarly with the Internet. > But unlike "the traffic", which is governed by a single set of rules > that control the road system, "the Internet" is designed so that each > participant can work out the rules between them on their own, just by > using some intercommunication primitives that are predefined. (One > might say that the Internet is not like driving on the Don Valley, and > is more like driving in Mumbai.) >=20 > This is also different from some other kinds of cases. For instance, > "the flow of water through the pipes in my house" is similar in that > there is no particular chunk of water that one is directing. Yet any > given flow (as long as the system doesn't have leaks and so on) is > actually entirely under the control of my household, so it's a > centrally-run system. And in a municipal water system, each > individual connection is via a well-regulated two-way interface > between exactly two parties. This is very different from > internetworking, even though it's a kind of network. > =20 >> Could you also make the argument in relation to 'Internationalization?= ' >> Why would the network care about human parsable languages? >=20 > It doesn't at the protocol layer. But it does at layers where network > identifiers or other protocol elements are exposed to users, precisely > because a larger body of users (which we can derive trivially from > "people with different writing systems than unaccented Latin in the > ASCII range of Unicode") increases the potential network effects. I think we had this discussion in several times, mostly informed by the presentation by Ramsey on his Arabic programming language. This resulted in this text in the draft: In the current IETF policy [RFC2277], internationalization is aimed at user-facing strings, not protocol elements, such as the verbs used by some text-based protocols. (Do note that some strings are both content and protocol elements, such as the identifiers.) If the Internet wants to be a global network of networks, the protocols should work with other languages than English and other character sets than latin characters. It is therefore crucial that at least the content carried by the protocol can be in any script, and that all scripts are treated equally. >=20 >> What some people think is good for the network, might >> not be seen the same by others. >=20 > This seems no objection to me at all: what some people think is good > for human rights might not be seen the same by others, or the US, most > EU countries, and China would not have disagreements over the nature > and acceptability of capital punishment (just to pick a totally > non-controversial example ;-) ) >=20 Not everyone needs to agree on interpretations or implement in the exact same way, but having a standard helps a lot to compare against. This is why there are Universal Periodic Reviews of all countries. No country has a perfect score sheet where it comes to human rights. >> Also: in your argument you now include 'faith in the network' as part = of >> the 'inherent network ethic', which is I think a bit of a leap, becaus= e >> earlier you seemed to argue that you wanted to leave usage out of the >> equation. It's starting to become a bit blurry for me here, but maybe >> that's because I do not sufficiently understand your concept of a >> 'network ethic'. >=20 > The notion of the network ethic -- and I cheerfully concede that I > have not worked this out fully, since I gave up on my philosophy > dissertation nearly 20 years ago and now only get to play in the > junior leagues in my spare time -- is that one takes the stance of the > network qua network, and consider what is good for it. =20 I still have some problems with this because the network is not a force of nature, right? It came into being, based on certain ideas, and is also still evolving. So I find it hard to pinpoint and ethics to it, and I think that is exactly the problem, right? > What is good > for the Internet is more internetworking, which means more networking > of other networks.=20 For the arguments sake: Could one not say it would be best for the network if we not focus on the expansion of the network but improving the quality of the network? I think this is something that could be argued based on your networking ethics, no? Or is more always better? > In a networking ethic, any case that causes an > increase in that internetworking is good, and any case which > reinforces increasing internetworking is a virtuous circle. Faith in > the network by humans causes increased use, which causes larger > network effects, which causes increased use, and so on; so it is a > virtuous circle. Therefore, faith in the network by human users is > network-ethic good (even if it is, say, bad from the point of view of > a government that wants to control the communications paths from the > country). So it's a numbers game? More is better? More networks, more hosts, more packets transported, or more users? What should we do in case we could add more users if we would add more opportunities for censorship. How would a networking ethic help us make a decision in such a case? >=20 >> You seem to use the term 'technocrats' here as in 'bureaucrats'. Are y= ou >> describing IETF-ers here as technocrats that take orders from policy >> makers? I think that kind of goes against 'no kings, no presidents', r= ight? >=20 > One view of what the IETF does is that it produces clean technical > specifications that are divorced from the policy questions in which > those specifications might be used. Under this view, the rejection of > kings and presidents is a rejection _for the purposes of the IETF_: we > reject the idea that those with controls over the voting mechanisms or > procedural machinery get to have special influence over which > specifications get published or the contents of those specifications. > (It is not to say that there do not exist kings or presidents. IETF > participants are sometimes accused of being unworldy, but I don't > think it extends quite that far.) >=20 > If we take that view seriously, then it follows that the IETF can > produce the best technical specification to solve a given technical > problem, and it can advise the world of that specification. But it > cannot adjudicate whether such a specification should be adopted as a > matter of policy. That is outside the IETF purview. This approach to > breaking up techno-political problems -- technical people offering > "the right answer to a problem" and policy-makers stating the problem > and deciding whether it is to be solved -- is what I call the > technocratic stance.=20 This is hardly the case, right? It's not like standards go to government approval after they have been approved by the IESG. > I don't think it is unusual to the IETF, and > arguably the entire history of (for instance) urban planning is > dressed up in this same story. Whether it is a _true_ story is, I > think, debatable. I think you are arguing that it is _not_ true. I > might agree with that, but what I keep trying to argue is that the > draft under discussion could be agnostic on its truth and still > produce considerations that any protocol designer could embrace. It > could also adopt the stance that one _could_ believe the technocratic > stance is wrong, in which case one could use the considerations in the > draft. Instead, the draft tries to argue that the stance is wrong, > but it mostly makes such arguments by appeal to authority -- > authorities that anyone who embraces the technocratic stance will not > accept. So the draft is less effective than it might be in achieving > its purpose. >=20 >> If your position is that there is such a think as a networking ethic >> that has driven the work here for many years >=20 > No, that is certainly not my position. >=20 Wait, so you're _proposing_ a network ethic. I thought you were making the argument that currently there _exists_ something as a network ethic. >> {{Denardis14}}. The IETF thusfar has formally relied on an ethics that= >> is based on an understanding that the network is its own objective, an= d >> the internetworking between networks is the expected result. >=20 > I don't think the IETF has ever formally relied on any ethics, BCP 95 > notwithstanding. =20 >=20 OK - won't add then. >> So you really think it would add to this draft to describe pre-Kantian= >> epistemology and subject-object relations here? >=20 > No, but I hope this message makes clearer what I'm suggesting instead. > If not, perhaps this is evidence of Kuhn's view about paradigms. >=20 Would this draft then be an anomaly? Let's get the scientific revolution started ;) > As I've said, this is a RG document and I have no objection to the RG > proceeding to publication. If this were an attempt to create an IETF > document that wanted to govern IETF procedure, I'd be very strongly > opposed to going ahead, but as a RG document I am not. >=20 Clear. Thanks! Niels > Best regards, >=20 > A >=20 --RKcgjMGXNSO3uFacrlh6BC4s6SQiX1U1v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb9Y8AAoJEA7YPzpGisizVxwP+wb3V+KTL5DFlqGVFGJkBBOA WEX8QLrBqqihzWmZ6lQ4zR1tDtYAy7wwHzUMZxRJIFt+18EtyG3SkiclEZG3wweh xLjO7keIk5E08pR6CbLdIAxIxAdLR+eF6ZK6sXxDwWj844JdCVdR0/5g3WnxvuH8 4jgeSZ4mR56f4ukTIkOb8/fFbMixKJEXZwUWAYd2KwhLqGrMHi1jEVU++Apk+ijF WjPqqOWZ5XOB+spvJGDtI7+SZ9U2YomI5WpSuNjfdH1JbVM4a1nhqgcWuQxVrCHI PyPm3os3OmaUO4wS+5T4pKyeE2pZZlSOHyN5cbWS6zObm0xtV4FBfdYQULTLG9il fwXbEKIGThiwXTLNS9Whn+FKLiH/1jDSS9/MkZEss7gNMyyYxUViRRYqSPcgSl4R VGJ0XJsUF+wMbOxjT2SH7GQQZzEhGxMVfXKOXRMLaLDJPkl+w9LJLH8JWoSmh8rK zu5rxC15+iV5VMlJikJ8ulcH7Yk1gzmiUFQCepscPnU6ChSHk4hNMDx44goPnUEQ k/79Ve107xoGCSQfYg+nbhV8zqYUM8RPYDJt+lcKnFo4aLcGhMT+7S7n2et7PmY/ IGRlV/QmC1udaFyeTosxy0fS6A/7/jZfB1AjBDzcoMEp7uiXVXjKN8sk7RgrT/Cb IA1eFWOF9CcJtrWPoK3/ =DpxA -----END PGP SIGNATURE----- --RKcgjMGXNSO3uFacrlh6BC4s6SQiX1U1v-- From nobody Fri Jan 6 09:42:24 2017 Return-Path: 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 34232129D1D for ; Fri, 6 Jan 2017 09:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 mservGEQUbmt for ; Fri, 6 Jan 2017 09:42:22 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 CFEBE129B73 for ; Fri, 6 Jan 2017 09:42:21 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPYWy-0007GO-5V; Fri, 06 Jan 2017 18:42:20 +0100 To: Stephen Farrell , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <970334be-2665-33c2-c40f-4838ab632b96@article19.org> <0a45b4b9-3c8f-b7cf-5440-6fe59e298938@cs.tcd.ie> From: Niels ten Oever Message-ID: <0a420cf5-d7ee-259a-9737-d8abeb23b68d@article19.org> Date: Fri, 6 Jan 2017 18:42:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <0a45b4b9-3c8f-b7cf-5440-6fe59e298938@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OksJRnnLJQIgm2a7P3DLFnmpmlcCQjsUJ" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d58e29c6f4e42f76447094ef3ccb23d2 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:42:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OksJRnnLJQIgm2a7P3DLFnmpmlcCQjsUJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/06/2017 06:31 PM, Stephen Farrell wrote: >=20 > I could live with that, thanks. One tweak suggested below. >=20 > Cheers, > S. >=20 > On 06/01/17 17:27, Niels ten Oever wrote: >> According to {{Abbate}}: "protocols are politics by other means". This= >> statement would probably not get IETF consensus, but it nonetheless >=20 > s/get/garner/ Accepted! https://github.com/nllz/IRTF-HRPC/commit/cb2298fc782e9d1e0afd9321a1bb716c= e1faf6a7 >=20 >> confers that protocols are based on decision making, most often by >> humans. In this process the values and ideas about the role that a >> particular technology should perform in society is embedded into the >> design. Often these design decisions are part pure-technical, and part= >> inspired by certain world view of how technology should function that = is >> inspired by personal, corporate and political views. Within the >> community of IETF participants there is a strong desire to solve >> technical problems and minimize engagement with political processes an= d >> non-protocol related poltical issues. >=20 --OksJRnnLJQIgm2a7P3DLFnmpmlcCQjsUJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb9b6AAoJEA7YPzpGisizhgoP/1WNO1ssOLNh/j+4lvPwapd9 fQKdqZG67OYoz1Iq3NDSxtJBSbq+QEZRZXTAF6hfJpipcqBaAZp73rvMujYOtBmI GkgMn0cfoFrYQpLsbQf7HvJoN/so0V9mM6faKgiF+kZh/TZDWclTIFZHKNe9q7wu dH3jG2/WR8a9u7WrS2cuY+uKQRWxpwO85tKNMETUiNrZbMuHLCjAAHNO7x70Myb5 Oqw/yqIVem7xhkifDvrjRReqjIGHvOwulVjjh2wLaGb0BjakO4h5fyK9flIq1y5n tZ6OSoUSdwd5Qp0a7y9LC5+KILAtuGFlZsHQqdo6U7oEv4N0aBbj/WcoTLj0MF3a BjEZVjNtXI484FaW5qlJ5iPY3kbEa/QLpymgf5erspR6/c1w25n0Yfy1iPg6UL/K 5omch1KrXIqHy5y4dIgQGHP/Pvty4/16eXL4pHKsYiU81hbJlF1iAJ6IjYDgZHBy eTNKwJhcrLflXs10NJofE2HbEBYXlZpy8qAatvVaw2OqA86J913yNzmCqMzo9GQu 3ZqgLVOvlrg5PcFknASZftX30J5uxVmobQXfWCvxtDYTEHnvq74LZyr4TZfW6r5i HaJy6c4zyC+a4Gcure1VW94xgIuejDyNerKsJAayAbMJ9qJLW+rzIjF0N4Hl0OFC ucK/yLdvJ00I1edG7Jdv =Z0Nm -----END PGP SIGNATURE----- --OksJRnnLJQIgm2a7P3DLFnmpmlcCQjsUJ-- From nobody Fri Jan 6 10:33:40 2017 Return-Path: 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 93DB8129D74 for ; Fri, 6 Jan 2017 10:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 35_Ns6ZvWXzI for ; Fri, 6 Jan 2017 10:33:36 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id C16721295C8 for ; Fri, 6 Jan 2017 10:33:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id BFBF7114E1 for ; Fri, 6 Jan 2017 18:33:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GglstFLi03dr for ; Fri, 6 Jan 2017 18:33:41 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id DBE9B114C9 for ; Fri, 6 Jan 2017 18:33:40 +0000 (UTC) Date: Fri, 6 Jan 2017 13:33:32 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170106183332.GA24054@mx2.yitter.info> References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:33:38 -0000 On Fri, Jan 06, 2017 at 06:13:32PM +0100, Niels ten Oever wrote: > session. I don't think this discussion is relevant now for the draft. I don't see how not. The claim in the draft that is causing the controversy is that protocols are politics by other means, that all protocol design decisions are necessarily political, and so on. If consenus is desired, that's the topic that needs to get sorted out. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jan 6 10:35:15 2017 Return-Path: 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 F3888129D74 for ; Fri, 6 Jan 2017 10:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 hZYCJocFIGn5 for ; Fri, 6 Jan 2017 10:35:12 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 40BDD1295C8 for ; Fri, 6 Jan 2017 10:35:12 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPZM6-0002rd-9v for hrpc@irtf.org; Fri, 06 Jan 2017 19:35:10 +0100 To: hrpc@irtf.org References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> From: Niels ten Oever Message-ID: <734ba775-1254-aaef-8d35-ede839f6c20b@article19.org> Date: Fri, 6 Jan 2017 19:35:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170106183332.GA24054@mx2.yitter.info> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H0gknEgNPF4cuTKhNIkQrLaJBVpj8I2Nq" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: c09395f469c52153b963e4ff2d10f427 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:35:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H0gknEgNPF4cuTKhNIkQrLaJBVpj8I2Nq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/06/2017 07:33 PM, Andrew Sullivan wrote: > On Fri, Jan 06, 2017 at 06:13:32PM +0100, Niels ten Oever wrote: >> session. I don't think this discussion is relevant now for the draft. >=20 > I don't see how not. The claim in the draft that is causing the > controversy is that protocols are politics by other means, that all > protocol design decisions are necessarily political, and so on. If > consenus is desired, that's the topic that needs to get sorted out. >=20 AFAIK we have addressed all text in the draft that might have insinuated that. If not, am happy to address the text with which you have issues. Best, Niels --H0gknEgNPF4cuTKhNIkQrLaJBVpj8I2Nq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYb+NdAAoJEA7YPzpGisizSBoP/1YhXNCkcLGyCBHqxUGLx3TO 8eqR69fz2vc/bfg2HKs9xjn92Ht8j9uwwXTBPQkhrmRVK/fA3u8sgNBemlYawFpZ y6ucWfw6WcPDKco7j9+k2W0FEEqdMzgNJU8WQyeoorPwknPO7khi/p2/J/B0TPWE XootNwdLFFBYnvXR1w4XIaIy97ugs0oeokh6NhzfETm4R8fegwPsNCmxJ348LSEr gsCwCo/nyEKbFmwvS11BQ7tufqtsU0LHEE875BuMMaLqRL1bitxERvPWqpxb3soB pC4CvPU28It44Oq9QDTysFd+XbqXFPemylJZNXD6WAEwB+KtCZA1RSwLXq5H15pj NUUBurRcnoqDHzKtZS8rvNLa0MoB282K77sAM88+K+Fsl6Me3yxoUdRWO1ypV3sA 5XZ5ZNwQT28uhVhc0UiffdX9aGLo47wISiTtlqQ8nw/Kw8P91pGHjnB6PjUdyBpe 1Swh5h6LF1SLSc56mzf5t087Yj671/03ZaHaaoqv5fWVy0rx22mXzmhnUgKPw6v6 i5pxfl77iuxUS7M+Dfpr8YhFZjKaeSw+3lFUcokVwal49EfoRZgwPsdvoDiP84Jb KMkESdkO2Wg3ZA6LG9wqZ2KsP5CK+opGa8sPqZdlElFxYsL6u0+xaahPq5BZ1zRj 3uivQnLVrCXeh3hyEik+ =omDC -----END PGP SIGNATURE----- --H0gknEgNPF4cuTKhNIkQrLaJBVpj8I2Nq-- From nobody Fri Jan 6 10:42:04 2017 Return-Path: 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 1A79E129628 for ; Fri, 6 Jan 2017 10:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 qS1-Kf1JLEhv for ; Fri, 6 Jan 2017 10:42:01 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 79B351295CF for ; Fri, 6 Jan 2017 10:42:01 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id l7so37334199qtd.1 for ; Fri, 06 Jan 2017 10:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F1FstwFnWKUFeQ9DmxkwGJOt+7aNYZGHRUC4yomggMg=; b=rvLxDOl95UvuMYeSIcBE+z9bl7hhRWPYYjvCyelPIFyg9DDKJUw7jQaQtda/TTqueD n4Z8c6eASYTPOK6OA9/gZG2xFp/Uh0ws4kB38eU9Ex5tITyDmcWPPxmQiUYjTiwT0/oc AwcmDxsLFAp4XkILODRZfglBOx4n5ZmZlrdnGTBfG9qZMLS62TpShiD+f9jlKr2994aF j8Xhnub8uU5m/3jbBBJdRde4D+UpDIqRcAHpKKEXcX01MGB4Mc+zU+KmoVN03oR4NT6o nd7hppWTzjtg6zijO6EXAc5SAyFQjJO9D+jxIOGcqFFQv0hMGV9xmxWJ596GXlFKSWDb wSjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F1FstwFnWKUFeQ9DmxkwGJOt+7aNYZGHRUC4yomggMg=; b=FuM7d96LmmZy084wX3uNgNW1uyDbDyRVFxh2QtTv+yiIguLuzLtDwiJSAQOfH5vf6p j/zYBGcgOCtXg6rRAG384sNl0wIy1ShkpkTnr62UmEr24exO+b4OsVRVTTqzdZH/AN2B wOHhDtxbY30JmKlyDaNg55Geb4GUYI8bwVSbmjQLNHcKELSGFGld8+I5DrHfWOhKo9Z8 bEH6pf6uOu+W9ekD47HuUfJD4qtztZfKbgcX2Jhpj7N1CHCc9ygaQVOHrAWjpKFK4AT6 CE2cQ7tBb4MDGAMmLcz575peRXJfOgk2c56hJZYWwi7QmPJCE7p7zOFZhcto8ZVEDgET jTow== X-Gm-Message-State: AIkVDXJaWvlaVns3dQnvMaH/n2hY3+HK3oCo4Mrp9LqxO2fRmn6nBkxsEu8hbLgQFWkUbg== X-Received: by 10.200.48.120 with SMTP id g53mr79604813qte.113.1483728120611; Fri, 06 Jan 2017 10:42:00 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id x13sm19199qkb.45.2017.01.06.10.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 10:41:59 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B9EA3BFF-D2BC-42AF-8A1B-528A90B0715A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 6 Jan 2017 13:41:58 -0500 In-Reply-To: <20170106183332.GA24054@mx2.yitter.info> To: Andrew Sullivan References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:42:03 -0000 --Apple-Mail=_B9EA3BFF-D2BC-42AF-8A1B-528A90B0715A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 6, 2017, at 1:33 PM, Andrew Sullivan = wrote: > I don't see how not. The claim in the draft that is causing the > controversy is that protocols are politics by other means, that all > protocol design decisions are necessarily political, and so on. If > consenus is desired, that's the topic that needs to get sorted out. Of course, this is essentially an observation about the world, not a = decision about what to do. If it were to _not_ gain consensus, it = would be because someone said something that demonstrated that it was = not true. We could have consensus not to actually admit to this truth, = but it's hard to deny the truth of it, particularly looking at the giant = footprint we've placed on the face of recent history with our protocols. --Apple-Mail=_B9EA3BFF-D2BC-42AF-8A1B-528A90B0715A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 6, 2017, at 1:33 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
I don't see how = not.  The claim in the draft that is causing the
controversy is that protocols are politics by = other means, that all
protocol design decisions are necessarily = political, and so on.  If
consenus is desired, that's the = topic that needs to get sorted out.

Of course, this is essentially an observation = about the world, not a decision about what to do.   If it were to = _not_ gain consensus, it would be because someone said something that = demonstrated that it was not true.   We could have consensus not to = actually admit to this truth, but it's hard to deny the truth of it, = particularly looking at the giant footprint we've placed on the face of = recent history with our protocols.

= --Apple-Mail=_B9EA3BFF-D2BC-42AF-8A1B-528A90B0715A-- From nobody Fri Jan 6 17:11:07 2017 Return-Path: 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 427161295B9 for ; Fri, 6 Jan 2017 17:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.89 X-Spam-Level: X-Spam-Status: No, score=-4.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=kSvvyga1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=VTdOhv1q 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 mBN_siGULm3f for ; Fri, 6 Jan 2017 17:11:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD24C12952F for ; Fri, 6 Jan 2017 17:11:03 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v071AicR024482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2017 17:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1483751452; x=1483837852; bh=LRapzLFZFTuTl8VQh3lwas8n5NbmFDxadfu/YRB6D3s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kSvvyga1czJA5fZdNgYpqWFpFKGOhGKxzZhYpP180P7tHrXBGBOKvLuOuRe1Fpx9I gCPuih56TBdx4Q0H0bQoNaQlWpWOD+IFv33t39kgcCxAZgC6jNI7V2wmHKjq6n+DiY 0r0aQ3ndnGwp/FWR9sM1fMtCYkG3hAj4zElPD2Vw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1483751452; x=1483837852; i=@elandsys.com; bh=LRapzLFZFTuTl8VQh3lwas8n5NbmFDxadfu/YRB6D3s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VTdOhv1qmdDSUZ/xn87+cDYgHHvESLR1KpayjcAofRtDsOfRY0tisdoSuNZ0vcW8v bEca/vPlNW0Ci7PkKZJVEf1a5/0Xsz+fB5/kN5WkWKRS2PkaMzvrmuF4DxShWNk7ly g4fhDq1B9agYUdVQcckjbd9pnBzDkYUJ4zn2XwGE= Message-Id: <6.2.5.6.2.20170106104124.102ab508@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2017 16:35:40 -0800 To: Niels ten Oever , hrpc@irtf.org From: S Moonesamy In-Reply-To: <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Corinne Cath Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 01:11:05 -0000 Hi Niels, At 05:37 06-01-2017, Niels ten Oever wrote: >I think this draft does exactly the opposite, but please educate me in >how you think this happens. My guess is that there isn't consensus in the IETF on the UDHR as there hasn't been any IETF discussion about that. What this draft does is that it takes values from an international political context and tries to apply that within a standards-setting context. The Introduction Section borrows a sentence from "the mission" which was written over a decade ago. Is "the mission" to turn the internet in "a human rights enabling environment"? Are there IETF participants (and attendees) who reside in "difficult" countries? Would those persons feel comfortable discussing about human rights publicly within the IETF? Is censorship resistance viewed as acceptable by most of the IETF attendees from the 53 countries? Were there views from attendees who are impacted by that? Do those persons agree that censorship resistance is a technical concept? >May I also point to the report by the UN Special Rapporteur which made >the point about responsibility of standards bodies vis a vis freedom of >expression and other human rights, which has been adopted by the Human >Rights Council. So this is hardly a concern of a geographically limited >group. The report makes a recommendation about ensuring that there is "meaningful civil society participation in policymaking and other standard-setting processes". It recommends that "Private entities ensure the greatest possible transparency in their policies, standards and actions that implicate the freedom of expression and other fundamental rights". Is the IETF part of "private entities" or "international organizations"? Shouldn't it be the responsibility of a person, company or organization with a strong interest in freedom of expression to make his/her/its case? The issue observed by the Commission on Science and Technology for Development of the United Nations is that "meaningful [IETF] participation requires a generally high level of technical expertise, human rights perspectives are not always included in discussions, even though technical and design choices can have a substantial impact on freedom of expression". I would not disagree with that observation as, based on my experience, it is definitely not easy to meaningfully participate in the IETF discussions if the person does not have an adequate level of technical expertise to understand where the technical choice is being made and the policy implications. I suggest relying on statistics to determine whether this group is geographically limited or not as such facts can be easily verified. >I don't think that is true. We've had involvement in the discussion from >people from all continents and have also tried to broaden the input by >doing interviews, next to the discussions in the RG sessions of course. It would be more convincing if there were public reviews from people from all continents. >I think the key word in that sentence is _could_. I do not see a >discrepancy between the charter and that remark. Did the RG Chairs request feedback from the relevant IETF body to find out whether the "could" is acceptable or not? >Then I do not get the point. Could you restate it or offer text? Let's take the case of a person from civil society lobbying against corruption in his/her country. Given the risks that the person may face, can he/she rely on the security mechanisms recommended by the IETF or should he/she do some due diligence? The point is that there isn't a "one size fits all" security. >I agree this is an issue, but not within the scope of this draft. Ok. >So you propose changing: > >Does your protocol have text strings that have to be understood or >entered by humans? Does your protocol allow Unicode? If so, do you have >accept texts in one charset (which must be UTF-8), or several (which is >dangerous for interoperability)? If character sets or encodings other >than UTF-8 are allowed, does your protocol mandate a proper tagging of >the charset? Did you have a look at {{RFC6365}}? > >I think the last sentence add useful information. Why leave it out? The last sentence is about making it possible for the charset to be identified at the receiver's end. That does not mean that the information which was transmitted will be rendered correctly at the receiver's end as that charset may not be supported. In essence, the tagging indirectly causes an interoperability issue. Although the following is not a good example I'll use it for an explanation: https://habrahabr.ru/post/130511/ The webpage is sent with "charset=utf-8". It should display correctly in any up-to-date web browser. What if the webpage was sent as "charset=iso-8859-5"? The up-to-date web browser would require support for that charset to be able to display the webpage correctly. It is not worthwhile to diverge from the recommended UTF-8 as it would be quite an effort to solve the internationalization issues. >I agree this is an IETF-wide issue. But that also makes it fall outside >of the scope of this draft. One of the issues in the draft is that it goes into open standards. It might be easier to stick to protocol discussions and leave out "open standards". The first reference in the draft is to a book which costs USD 12.95. It is at odds with the "not available without cost". >That makes it not a standard, but it is still a protocol. I tihnk this >exactly shows how a protocol can make use of permissionless innovation >to combine uses of different protocols in other ways than it was >originally intended. According to Adam Thiere "permissionless innovation" is the idea that experimentation with new technologies and business models should generally be permitted without prior approval [from government]. It is a bit like Uber. I unfortunately have to disagree with the above response. >Which question? There is a definition, there is an explanation among >different topics (connectivity, open standards, adaptability). I commented about this above (re. permissionless innovation). >That is quite a strong denounciation of the methodology. Could you >perhaps be a bit more detailed about this claim? From what I understand, the methodology is about getting a sense of how the people in the IETF work, their beliefs and rituals, and their interactions with each other and those around them. The actions within the context of this research group were embodied in some of the IETF RFCs. Some of the beliefs do not usually get written into a RFC as those beliefs are non-technical. It is not always possible to understand an IETF decision without the background information. Is that background information relevant if we are discussing about technical details? No. Is it relevant if a person is interested in studying the beliefs? Maybe. There is a political flavor to beliefs; it is better not to have those type of discussions in the IETF as such discussions are usually contentious. One interpretation of ideology is covered in ISBN 0252097106, 9780252097102. >Have you watched Net of Rights (https://hrpc.io/net-of-rights) ? A lot >of the interviews have culminated in that. I watched the video. Are those 19 persons representative of the IETF? >What promotional material are you aluding to? I was referring to "open standards" and "permissionless innovation". Regards, S. Moonesamy From nobody Fri Jan 6 18:12:30 2017 Return-Path: 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 E54AA1297EF for ; Fri, 6 Jan 2017 18:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lFh9dxGbgdbA for ; Fri, 6 Jan 2017 18:12:28 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 7D157129477 for ; Fri, 6 Jan 2017 18:12:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 6AD90114E5 for ; Sat, 7 Jan 2017 02:12:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NEITq3OMtkM for ; Sat, 7 Jan 2017 02:12:32 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 85AE4114DB for ; Sat, 7 Jan 2017 02:12:32 +0000 (UTC) Date: Fri, 6 Jan 2017 21:12:25 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170107021224.GG24054@mx2.yitter.info> References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20170106104124.102ab508@elandnews.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 02:12:30 -0000 Hi, On Fri, Jan 06, 2017 at 04:35:40PM -0800, S Moonesamy wrote: > What this draft does is that it takes values from an international > political context and tries to apply that within a standards-setting > context. Perhaps there is a more charitable reading, which is that the draft tries to take values from an international political context and tries to suggest how they interact with the relevant standards-setting context. (One might disagree about the degree to which it is successful at that, but I think that the documentation of the interaction really is the goal, not application of the values as such.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Jan 7 03:35:19 2017 Return-Path: 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 DE19F1293FB for ; Sat, 7 Jan 2017 03:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 a9-TWuACku3d for ; Sat, 7 Jan 2017 03:35:15 -0800 (PST) Received: from athene.wzb.eu (athene.wzb.eu [193.174.6.3]) (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 43D07127735 for ; Sat, 7 Jan 2017 03:35:14 -0800 (PST) To: hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> From: Jeanette Hofmann Message-ID: Date: Sat, 7 Jan 2017 12:35:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170107021224.GG24054@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-WZB-Virus-Scanned: by Clam AntiVirus at athene.wzb.eu X-Priority: 3 (Normal) Importance: Normal Priority: normal Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 11:35:17 -0000 Hi, this is a follow up from what I wrote about various definitions of "the political". I would like to take issue with 2 aspects of the draft's argument. The first concerns the relationship between human rights and standard development and the second concerns the unclear definition of the political. I am sorry if I am being a bit long. 1. Historically, human rights enable and constrain the relationship between the individual and the government. Resulting from the atrocities of WW 2, governments agreed on various versions of human rights to protect the individual against the abuse of *state* power. (This means that human rights create obligations for the states in two ways. Negative rights restrict state power to protect the individual against it; positive rights make it mandatory for the state to deliver certain services to enable a dignified life of its citizens. I.e. a right to internet access, as in Mexico, Spain and a few others.) Human rights concern and structure the relationship between citizens and public authorities, they do not affect the horizontal relationships between citizens or between citizens and companies, standard setting bodies etc. In fact, the products and services of many commercial companies affect human rights in fundamental ways but it does not follow from these affects that they have to modify their actions. However, there have been debates over the past decades that question the restriction of the applicability of human rights to the relationship between individuals and their governments. (Likewise, there are many debates about restricting the applicability to citizens since on the Internet we are mostly foreigners). Experts are divided over the question of expanding the applicability of human rights to the relationship between individuals and the private sector. Some fear that this could weaken the power of human rights. Others argue that there is no legal infrastructure to ever enforce compliance by the private sector, and that enforcing human rights is the task of governments. This is a very interesting debate, and the spread of digitalisation has fueled it in many ways. I think it is very good that the IETF takes an interest in this debate and that it considers its position with regard to the respect to human rights. The fact that human rights bind governments but not societal or commercial entities does not imply that non-state actors cannot commit themselves to take human rights into account and respect them. So, my question is what does all of this have to do with whether or not standard setting is a political activity? In my view, all the controversial references to "protocols are politics by other means" can be dropped from the draft. They do not add anything substantial to the proposal. The essential question is whether, to what extent and in which form the IETF wants to take into account that its work does impact the human rights of internet users. It is unlikely that anybody seriously doubts that internet standards affect the exercise human rights. But what follows from that is much less obvious. 2. The draft constantly confuses political effects and intentions of protocol development. The fact that a protocol does have politica effects does not necessarily make its development a political process. If Janet Abate concludes in her very good book that "protocols are politics by other means", it is not clear if she refers to the effects of protocols or to the intentions of protocol developers. Based on the interviews I did back in the 1990s, I would claim that many people involved in the development of IPv4 became aware of the political dimension of their work (to the extent that it was competing against another protocol suit) but this political dimension did not drive their work. Many of the early developers primarily wanted to connect computers and experiment with network architecture design not code a political statement. This is why I suggested distinguishing various definitions of "the political" Political can be an effect or an intention or both. But it is not ok to conclude from effects on the intentions of action. I could add a 3. criticism that concerns the idea of hard coding or "baking" human rights into protocols. I think this is misguiding language that unduely simplifies the ways values and norms find their way into technology. But I will leave at that because this post gets too long for consumption. My conclusion is that the draft should be completely rewritten. It should entirely drop the "the Internet is political". It should make the case why the IETF should take human rights into account although there is no formal obgligation to do so. And based on that, it should suggest various ways by which this could be done. Jeanette Am 07.01.17 um 03:12 schrieb Andrew Sullivan: > Hi, > > On Fri, Jan 06, 2017 at 04:35:40PM -0800, S Moonesamy wrote: > >> What this draft does is that it takes values from an international >> political context and tries to apply that within a standards-setting >> context. > > Perhaps there is a more charitable reading, which is that the draft > tries to take values from an international political context and tries > to suggest how they interact with the relevant standards-setting > context. (One might disagree about the degree to which it is > successful at that, but I think that the documentation of the > interaction really is the goal, not application of the values as > such.) > > Best regards, > > A > From nobody Sat Jan 7 07:19:36 2017 Return-Path: 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 EED4F1293E0 for ; Sat, 7 Jan 2017 07:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.82 X-Spam-Level: X-Spam-Status: No, score=-15.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KJlVK4XUpINx for ; Sat, 7 Jan 2017 07:19:32 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4F1126579 for ; Sat, 7 Jan 2017 07:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9709; q=dns/txt; s=iport; t=1483802372; x=1485011972; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=gaZADqxt1wkdJusTqFij7oOZhHBhEMzW91FpP6j4Krk=; b=SAqqncLF8HsawkGmk5kfXBnOKlIbgLgHj69ATroGk4h8gOnTObGQt3c4 nZmbnY4/48Ef14i9Bp1yKCF/1bBa1lBrEGNz5uiSkioHpeBJPol2AVdh0 M978L8DBtrxCbAlwTim30078QepylJN/JmscZtXeJNpN4Y7iNZH+8ILnh M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCUBXFY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFJAQEBAQGCCo1XcpEvj3yFK4IKhh0DAgKCFRQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQUjSQoDEAsOCicDAgJGEQYBDAYCAQGIbLBUgiUriW4BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEOD4hHCIJXh06CXgWbHINngX6LaIonhjWSVR84gRISBxUVhGc?= =?us-ascii?q?cgWA9NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,329,1477958400"; d="asc'?scan'208,217";a="691138695" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2017 15:19:27 +0000 Received: from [10.61.246.163] ([10.61.246.163]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v07FJRI3007510; Sat, 7 Jan 2017 15:19:27 GMT To: Ted Lemon , Andrew Sullivan References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> From: Eliot Lear Message-ID: Date: Sat, 7 Jan 2017 16:19:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W1E0aAB5JevM1tsDRNDTscvgRmnQlNB2G" Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 15:19:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W1E0aAB5JevM1tsDRNDTscvgRmnQlNB2G Content-Type: multipart/mixed; boundary="vNtnicUmN4LRrReUsM4MgNEUirVCnQ38a"; protected-headers="v1" From: Eliot Lear To: Ted Lemon , Andrew Sullivan Cc: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> In-Reply-To: --vNtnicUmN4LRrReUsM4MgNEUirVCnQ38a Content-Type: multipart/alternative; boundary="------------7A4055D56C4BC43691013302" This is a multi-part message in MIME format. --------------7A4055D56C4BC43691013302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/6/17 7:41 PM, Ted Lemon wrote: > On Jan 6, 2017, at 1:33 PM, Andrew Sullivan > wrote: >> I don't see how not. The claim in the draft that is causing the >> controversy is that protocols are politics by other means, that all >> protocol design decisions are necessarily political, and so on. If >> consenus is desired, that's the topic that needs to get sorted out. > > Of course, this is essentially an observation about the world, not a > decision about what to do. If it were to _not_ gain consensus, it > would be because someone said something that demonstrated that it was > not true. We could have consensus not to actually admit to this > truth, but it's hard to deny the truth of it, particularly looking at > the giant footprint we've placed on the face of recent history with > our protocols. > > It is demonstrably not true that ALL protocol decisions are political.=20 We don't encode passwords in the clear, for instance, because the probability of them being stolen approaches 1 over time. Whether the draft actually says that, quite frankly, is hard for me to determine.=20 Also, it is enough to debate that some protocol decisions are inherently political. And as Jeanette Hoffman wrote, it is sometimes tricky to tease out which is which. This leads me to a point: I wonder if there is room for more than one work in this space in this research group. Just teasing out political from technical seems like a good piece of work on its own. Eliot --------------7A4055D56C4BC43691013302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 1/6/17 7:41 PM, Ted Lemon wrote:
On Jan 6, 2017, at 1:33 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
I don't see how not. =C2=A0The claim in the draft that is causing the
controversy is that protocol= s are politics by other means, that all
protocol design decisions ar= e necessarily political, and so on. =C2=A0If
consenus is desired, that's the topic that needs to get sorted out.

Of course, this is essentially an observation about= the world, not a decision about what to do. =C2=A0 If it were to _not_ gain consensus, it would be because someone said something that demonstrated that it was not true. =C2=A0 We could have consensus not to actually admit to this truth, but it's hard to deny the truth of it, particularly looking at the giant footprint we've placed on the face of recent history with our protocols.



It is demonstrably not true that ALL protocol decisions are political.=C2=A0 We don't encode passwords in the clear, for instance= , because the probability of them being stolen approaches 1 over time.=C2=A0 Whether the draft actually says that, quite frankly, is h= ard for me to determine.=C2=A0 Also, it is enough to debate that some protocol decisions are inherently political.=C2=A0 And as Jeanette Hoffman wrote, it is sometimes tricky to tease out which is which.
This leads me to a point: I wonder if there is room for more than one work in this space in this research group.=C2=A0 Just teasing out= political from technical seems like a good piece of work on its own.<= br>
Eliot
--------------7A4055D56C4BC43691013302-- --vNtnicUmN4LRrReUsM4MgNEUirVCnQ38a-- --W1E0aAB5JevM1tsDRNDTscvgRmnQlNB2G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYcQb+AAoJEIe2a0bZ0nozeg8H/RA2zfHrkLAWDhJkyiHgqenz //ecH0Upl+bqBuAVC0+3XHj6qXVmz5yeFaRzAugccfwlkgQFk4dngSYWpMgLF3SE 4RxX2vUFYOKdqsdpycTzaa4ZG5l2GU2kjZhl3Y9jPv5yNoOxUPAGYA4nwKu1dLrQ wFWiH7jwa+rbXrRfeAV9y7N+UIEzlFAsMFthucRWFhMCaYlUc8pUMMbIjDbfItAX G1jwp+TLIxHfor3LvT9hzbAKP2ugu+Ryn8BNsxDylOFTQPaFa74ISVxfadlwH8K6 NwL9nEonubIjYuClEwKHp9JCoUXttAKkaPjvyJlWF/KZoSsXbrGtB39TyJoPKbk= =ahmT -----END PGP SIGNATURE----- --W1E0aAB5JevM1tsDRNDTscvgRmnQlNB2G-- From nobody Sat Jan 7 07:42:58 2017 Return-Path: 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 B978F12941D for ; Sat, 7 Jan 2017 07:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.82 X-Spam-Level: X-Spam-Status: No, score=-15.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 7d0y6p9TyZ46 for ; Sat, 7 Jan 2017 07:42:56 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A9A1204D9 for ; Sat, 7 Jan 2017 07:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5294; q=dns/txt; s=iport; t=1483803776; x=1485013376; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=esvC9xrZ1ooRfvNdD4G3fPKJYeGbsHYUhxun8GeIab8=; b=KTwmt3/Y0d+/E2NbILaVOMObrlQsYdDvBd3rpkY0TUWJzGbmIDQO6Z5M WBpANoGmI0E5bPIrzB2DAOHLceDOR1L799ww/PYbH4ijk07qCvkrBr5uQ 1Y0IV7qtYbXrc+tnvYdhWoh+W8BODBoEnI3i3Bcl02Jvm5HfghEMaO8/8 E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQDjC3FY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAY9hcpEvj3yFK4IKhh0DAgKCFRQBAgEBAQEBAQFjKIR?= =?us-ascii?q?pAQQBI2YLBD4CAlcGAQwIAQGIZAiwRIIlK4luAQEBAQEBAQMBAQEBAQEBAQEQD?= =?us-ascii?q?4hHgl+HToJeBZscg2eBfotoiieGNZJVHziBEhIHFRWGYz2JGwEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,329,1477958400"; d="asc'?scan'208,217";a="648577656" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2017 15:42:52 +0000 Received: from [10.61.246.163] ([10.61.246.163]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v07FgpdZ011775; Sat, 7 Jan 2017 15:42:52 GMT To: Niels ten Oever , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> <20170106142051.GA12568@mx2.yitter.info> From: Eliot Lear Message-ID: <4f053fb5-684d-b5f9-a4b5-b0568250ed33@cisco.com> Date: Sat, 7 Jan 2017 16:42:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U7a43AJVV2H54L8r3NbHjKxTs4vLGJxOT" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 15:42:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U7a43AJVV2H54L8r3NbHjKxTs4vLGJxOT Content-Type: multipart/mixed; boundary="G1gNDru8eiG3iSunrEm6QjSSb7RU7wuPM"; protected-headers="v1" From: Eliot Lear To: Niels ten Oever , hrpc@irtf.org Message-ID: <4f053fb5-684d-b5f9-a4b5-b0568250ed33@cisco.com> Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> <20170106142051.GA12568@mx2.yitter.info> In-Reply-To: --G1gNDru8eiG3iSunrEm6QjSSb7RU7wuPM Content-Type: multipart/alternative; boundary="------------AB082BC99A11F81078A3603F" This is a multi-part message in MIME format. --------------AB082BC99A11F81078A3603F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Neils, Just on this point: On 1/6/17 6:39 PM, Niels ten Oever wrote: >> If we take that view seriously, then it follows that the IETF can >> produce the best technical specification to solve a given technical >> problem, and it can advise the world of that specification. But it >> cannot adjudicate whether such a specification should be adopted as a >> matter of policy. That is outside the IETF purview. This approach to= >> breaking up techno-political problems -- technical people offering >> "the right answer to a problem" and policy-makers stating the problem >> and deciding whether it is to be solved -- is what I call the >> technocratic stance.=20 > This is hardly the case, right? It's not like standards go to governmen= t > approval after they have been approved by the IESG. Color me confused (again). There are two interpretations of what you wrote above- that Andrew's observation is false- 1. because governments do not have approval of standards, or 2. because policy makers are free to ignore whatever approach the IETF puts forth. Certainly the latter premise is true, but it is not clear to me that is what you meant nor that it invalidates Andrew's point about the division of labor (rather it restates it). Eliot --------------AB082BC99A11F81078A3603F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Neils,

Just on this point:

On 1/6/17 6:39 PM, Niels ten Oever wrote:

If we take that view seriously, then it follows th=
at the IETF can
produce the best technical specification to solve a given technical
problem, and it can advise the world of that specification.  But it
cannot adjudicate whether such a specification should be adopted as a
matter of policy.  That is outside the IETF purview.  This approach to
breaking up techno-political problems -- technical people offering
"the right answer to a problem" and policy-makers stating the problem
and deciding whether it is to be solved -- is what I call the
technocratic stance.=20

This is hardly the case, right? It's not like standards go to government
approval after they have been approved by the IESG.

Color me confused (again).

There are two interpretations of what you wrote above- that Andrew's observation is false-
  1. because governments do not have approval of standards, or
    2. =
  2. because policy makers are free to ignore whatever approach the IETF puts forth.
Certainly the latter premise is true, but it is not clear to me that is what you meant nor that it invalidates Andrew's point about the division of labor (rather it restates it).

Eliot
--------------AB082BC99A11F81078A3603F-- --G1gNDru8eiG3iSunrEm6QjSSb7RU7wuPM-- --U7a43AJVV2H54L8r3NbHjKxTs4vLGJxOT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYcQx7AAoJEIe2a0bZ0nozM9QIAKmsFqV6Q2as53k6k936I8fy JS6wnEpKfSpQN+fsKA9J7snx548GnjcSBxHooQ7RWVn09TlrnbPPooeARz5SkC7I opprj4xvZ1DCv4B4jUB/JjbhaikGoZhIHS/3pAoHo0inISOE6SymNNmWGt7UuT2W nYpGNsJYvMIgIpKuSH5MU1x39+2ds82u2MZ5uDonwW9Cb/PT0rUgXGz1EPzeYeyJ jg4NeZbewKbm7tSm+dWWHP/pSHzu4LacwHj43tweV19zrB1OQdw5Q0V6iibu5h3r 6JZn1ZPdhPjLND95uSQYJUs/ljyDBy/YgOpy1j0i9JTd4TzsCEBh7evATKB7ULk= =Cw5J -----END PGP SIGNATURE----- --U7a43AJVV2H54L8r3NbHjKxTs4vLGJxOT-- From nobody Sat Jan 7 08:09:53 2017 Return-Path: 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 8299A129566 for ; Sat, 7 Jan 2017 08:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.952 X-Spam-Level: X-Spam-Status: No, score=0.952 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.972] autolearn=no 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 aqCQpy6g62UL for ; Sat, 7 Jan 2017 08:09:51 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523C012953D for ; Sat, 7 Jan 2017 08:09:51 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 621082691A0 for ; Sat, 7 Jan 2017 16:09:47 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -5, 0, , d41d8cd98f00b204, avri@acm.org, ::, RULES_HIT:41:355:379:599:854:871:988:989:1000:1260:1261:1313:1314:1345:1359:1381:1437:1516:1518:1534:1536:1560:1575:1594:1711:1714:1730:1747:1777:1792:1960:2393:2553:2559:2562:3138:3139:3140:3141:3142:3867:3870:3871:5007:6506:6747:6748:7281:7652:7909:10004:10848:11232:11604:11658:11914:12109:12114:12196:12740:12895:14227:14658:14659:21080:21212:30054, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:4, LUA_SUMMARY:none X-HE-Tag: veil19_383ff5266a608 X-Filterd-Recvd-Size: 3813 Received: from [127.0.0.1] (unknown [64.120.53.43]) (Authenticated sender: avri@doria.org) by omf12.hostedemail.com (Postfix) with ESMTPA for ; Sat, 7 Jan 2017 16:09:46 +0000 (UTC) References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> To: hrpc@irtf.org From: avri doria Message-ID: <0e9495b2-8a5f-7a4b-3bbc-e872f9a3d050@acm.org> Date: Sat, 7 Jan 2017 11:09:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4xJI0kS0fDpH188LXbjodHGsncuPpBCxl" X-Antivirus: avast! (VPS 170102-0, 01/02/2017), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: avri@acm.org List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 16:09:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4xJI0kS0fDpH188LXbjodHGsncuPpBCxl Content-Type: multipart/mixed; boundary="qp0INSohJl9F0EX0fRErCP1Snlx0e9MVl"; protected-headers="v1" From: avri doria Reply-To: avri@acm.org To: hrpc@irtf.org Message-ID: <0e9495b2-8a5f-7a4b-3bbc-e872f9a3d050@acm.org> Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> In-Reply-To: --qp0INSohJl9F0EX0fRErCP1Snlx0e9MVl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07-Jan-17 10:19, Eliot Lear wrote: > This leads me to a point: I wonder if there is room for more than one > work in this space in this research group. certainly. avri --qp0INSohJl9F0EX0fRErCP1Snlx0e9MVl-- --4xJI0kS0fDpH188LXbjodHGsncuPpBCxl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYcRLAAAoJEOo+L8tCe36H2g0IAIpktBnxKkJSjPCLxechdOHn dyO5v3zg7NhdvA9w5Llx2SsR7e5uqvFHSaQz3xwuAIi9GTa1KdHwH80Jlw1uEJHV ektQ5b4bBGG4SMV8+aHy8H8L8N0btB6KEvBuQinIgsOPnNC4HlhlyfjFmgpZc5z1 qcaS1bCffYbhcjluN+BkEVLdJxRo9u1BVwbLkvgY7on0m2Y8tfHYa2ePf5yUHvxA ysR7KQ1tmETijH8QgQRd1OvIGg0yTFa20619Xmgzl6mLC37WI3ZB+O5Ydv4Mav9h oUG6s3Qe9UcvLIEkSbWER/RUvPQf4ifMkZYnUYWBoGsCVsF/gT6k2j30pSzTvCk= =tdAc -----END PGP SIGNATURE----- --4xJI0kS0fDpH188LXbjodHGsncuPpBCxl-- From nobody Sat Jan 7 09:14:47 2017 Return-Path: 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 413D712956C for ; Sat, 7 Jan 2017 09:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 CdLipEq4uWdj for ; Sat, 7 Jan 2017 09:14:43 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 EBC9A1294C1 for ; Sat, 7 Jan 2017 09:14:42 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPuZj-0007Wo-EA; Sat, 07 Jan 2017 18:14:39 +0100 To: Eliot Lear , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <20170105165503.GZ12568@mx2.yitter.info> <9c9235ce-6792-51d0-8c24-2accf7b463a4@article19.org> <20170106142051.GA12568@mx2.yitter.info> <4f053fb5-684d-b5f9-a4b5-b0568250ed33@cisco.com> From: Niels ten Oever Message-ID: Date: Sat, 7 Jan 2017 18:14:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <4f053fb5-684d-b5f9-a4b5-b0568250ed33@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fnoKMmAJMmOH3sVFB3a2m7L98tKbEW7bU" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 98cd051f671ee36aeaf0d6c34a549736 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 17:14:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fnoKMmAJMmOH3sVFB3a2m7L98tKbEW7bU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/07/2017 04:42 PM, Eliot Lear wrote: > Neils, >=20 > Just on this point: >=20 > On 1/6/17 6:39 PM, Niels ten Oever wrote: >=20 >>> If we take that view seriously, then it follows that the IETF can >>> produce the best technical specification to solve a given technical >>> problem, and it can advise the world of that specification. But it >>> cannot adjudicate whether such a specification should be adopted as a= >>> matter of policy. That is outside the IETF purview. This approach t= o >>> breaking up techno-political problems -- technical people offering >>> "the right answer to a problem" and policy-makers stating the problem= >>> and deciding whether it is to be solved -- is what I call the >>> technocratic stance.=20 >> This is hardly the case, right? It's not like standards go to governme= nt >> approval after they have been approved by the IESG. >=20 > Color me confused (again). >=20 > There are two interpretations of what you wrote above- that Andrew's > observation is false- >=20 > 1. because governments do not have approval of standards, or > 2. because policy makers are free to ignore whatever approach the IETF= > puts forth. >=20 > Certainly the latter premise is true, but it is not clear to me that is= > what you meant nor that it invalidates Andrew's point about the divisio= n > of labor (rather it restates it). >=20 It is the second. But policy makers don't really have a say about what protocols are being used. Maybe there could be a theoretical case, or in the narrow cases of crypto exports control, but external government intervention in Internet protocols (outside of NSA + crypto) is hardly a thing we encounter regularly, right? Or am I wrong to assume this? Best, Niels --fnoKMmAJMmOH3sVFB3a2m7L98tKbEW7bU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYcSH9AAoJEA7YPzpGisizNfwQAInKfwSH7jNI1wY6zRKFlMqI o6c6nqrV/RhoLA3idfP1d0MOf/xE2VlNdrROSmLsMp8hRWePbqZJpEfEzPDivC/n bVX/wqKLx/Lx+PItTdTp04Lb8E8jKdFKRjROCSj0V3w27tq3VdjRr9AgpxpIDwGE SAZAFaqbxKptE2QVclQS+THqhdz4IOOWFEfuHIInoEx0seipHrtS7v502YiBxLUa KbwtBTm2WA2mDiqjJF41GKoMuSD+cFkTJOMfdp/n4uwRkL/ZT1aC8TvmciZ2AAJL qcvGE/I1NPrFYnNArElvlH0kvfPaG7E/5D/1qyVSg7cSu59Y//ghop3eqLd5f/h6 /+tPFGAU7HMF6gwaZcBMudIxL7Kl4zEuvbKkdmdDbZuucLz4XglVxbBvBtwM09uB xxE1H3DPD5ei3awj6A7olvX6KWBsHTp+X08TMGhr2t5kffHR5MW2e43Akn/czhF9 mOJ+j38XLCNlZa8LyqRABexA0HAqevv69CnGa45EFMOgMXTNvBWkyBn5Fe1Dsmmg z3J4lXhvkOVGOgzulQu0CI26pLkTLnvdVoKXoLUxe223/LOOUUpCi36EvR5BvjOQ 3+XHZ40ksjR/NhbPgudy0SCQoEogAoGBfs2LTN3RwqlOWeGFPVXzSTOqqwMobbUY 0g3roJXC90Y+wRIORpBM =QTr4 -----END PGP SIGNATURE----- --fnoKMmAJMmOH3sVFB3a2m7L98tKbEW7bU-- From nobody Sat Jan 7 09:21:52 2017 Return-Path: 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 8E10B129588 for ; Sat, 7 Jan 2017 09:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Lf58A7wqGred for ; Sat, 7 Jan 2017 09:21:50 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 56527124281 for ; Sat, 7 Jan 2017 09:21:50 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cPuge-0000ck-31 for hrpc@irtf.org; Sat, 07 Jan 2017 18:21:48 +0100 To: hrpc@irtf.org References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> <20170106171632.ywoh52l5al4p5yzp@nic.fr> <04f23833-7a7a-339c-aeca-7d4f86c18959@cs.tcd.ie> <20170106172658.x47wn7vbivg2vn4d@nic.fr> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <0d2d4bb4-bba6-c1c7-e45f-69fbea099728@article19.org> Date: Sat, 7 Jan 2017 18:21:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170106172658.x47wn7vbivg2vn4d@nic.fr> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u9Q3m2UwbJO47n17Wact9Wtc1N6eDeb3B" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: aadb025e1561638fa3cfee7b14734d3b Archived-At: Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 17:21:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u9Q3m2UwbJO47n17Wact9Wtc1N6eDeb3B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I added some sentences to the third para in the introduction: Open, secure and reliable connectivity is necessary (although not sufficient) to excercise human rights such as freedom of expression and freedom of association {{FOC}}, as defined in the Universal Declaration of Human Rights {{UDHR}}. The purpose of the Internet to be a global network of networks that provides unfettered connectivity to all users and for any content {{RFC1958}}. This objective of stimulating global connectivity contributes to the Internet's role as an enabler of human rights. The Internet has given people a platform to exchange opinions, gather information, enabled people of different background and genders to participate in the public debate whereas this might have been hard for them to do so before, and it has allowed people to congregate and organize. Next to that, the strong commitment to security {{RFC1984}} {{RFC3365}} and privacy {{RFC6973}} {{RFC7258}} in the Internet's architectural design contribute to the strengthening of the Internet as a human rights enabling environment. One could even argue that the Internet is not only an enabler of human rights, but that human rights lie at the basis of, and are ingrained in, the architecture of the networks that make up the Internet. Internet connectivity increases the capacity for individuals to exercise their rights, the core of the Internet, its architectural design is therefore closely intertwined with the human rights framework {{CathFloridi}}. The quintessential link between the Internet's infrastructure and human rights has been argued by many. {{Bless}} for instance argues that, 'to a certain extent, the Internet and its protocols have already facilitated the realization of human rights, e.g., the freedom of assembly and expression. In contrast, measures of censorship and pervasive surveillance violate fundamental human rights.' {{Denardis15}} argues that 'Since the first hints of Internet commercialization and internationalization, the IETF has supported strong security in protocol design and has sometimes served as a force resisting protocol-enabled surveillance features.' By doing so, the IETF enabled the manifestation of the right to privacy, through the Internet's infrastructure. Additionally, access to information gives people access to knowledge that enables them to help satisfy other human rights, as such the Internet increasingly becoming a pre-condition for human rights rather than a supplement. Curious to hear what you all think of this. Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 On 01/06/2017 06:26 PM, Stephane Bortzmeyer wrote: > On Fri, Jan 06, 2017 at 05:18:03PM +0000, > Stephen Farrell wrote=20 > a message of 113 lines which said: >=20 >> Maybe Alissa has ideas for text? >=20 > I suspect that most "positive benefits for HR" will be "negative > features" such as "SMTP does NOT require that the user sending an > email has a client certificate, which is good for anonymity" >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --u9Q3m2UwbJO47n17Wact9Wtc1N6eDeb3B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYcSOqAAoJEA7YPzpGisizetEP/jPO6Htwl4PbB6m393+MrL7m lNPKvWB4duNFMNm0RTIXQBRCCMdBd+9kft06NsHmXW7TEhrCoNZgDa0sEAitx/oJ iTmgx53Z78iWCWVxWPyqXiuEjr2n0sAaQyAilHHUt31OzFUUn09XLLUEf5uSsmGu GPrHczJ/0Cfq+f21uGlYLCE6NBFZchb9wsPKTy5QBPE2TKB3eF2+VOR5yHNLVrv2 /Bwm//0F9kKXuBl57ihDeeZBSWU+8k5vFIZwNfx/70toSd9nTQmr0u/QjWauiiZ3 0QjXzV+sEErB7PRs/UGFNCsFRF96q2Q0f3N/IkQi8mnxcT9VoAh/rW4CTmHDJref ygKm2SSvIEMNHAMlpAlEgFzf/MEPsiix/HonFSQBZky0YYvniTYGppQkbhKRE/hb waXbt8sgc5FKziiu9N/AXVVWFIuetBKu0zBUuV7dlaCTSJm6DDukCaikjSBIJGit OfgIglg073QreBqk88F3gReeqZiIFgSGmDfgWLAjYGljxRRUreTwxRQEtFTZqZs6 JKvMCuelf52d71Q+x6kmLxYBHMmTMjAWpA28S9NQRa2iSbE7sHpSWpMbdkCv8fRi c46mPrOvqiyDrD7KdhBfeM2F4xDECWukf6OsXl3ey5jGq7FBEu8FBCDiPRf6johw jBNfhBzkNXYOovQlfp6A =H4sl -----END PGP SIGNATURE----- --u9Q3m2UwbJO47n17Wact9Wtc1N6eDeb3B-- From nobody Sat Jan 7 09:59:10 2017 Return-Path: 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 337101294D6 for ; Sat, 7 Jan 2017 09:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 lQuP3nUEg9zm for ; Sat, 7 Jan 2017 09:59:06 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 BF0451293D6 for ; Sat, 7 Jan 2017 09:59:06 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id l7so55997856qtd.1 for ; Sat, 07 Jan 2017 09:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8+89c/M69LI4ftLf/6/Vpb22YVYzmkcvp0o/HutuNgM=; b=rK7DJLGCjQNDAb9/+ZnbbBQ/IBdH5TG2c4Akit+WcW8tje66x5VeruMr0yEQJHSqI4 Io3NjrqHg9k6pPSW9S9M6fxGEK6y5x6XrMUxyNlKhPkQPPDtkYf9cFgpeTZI5HqGXVvA kfnixde4JGl68O3gvKYfJlxGOZ3xkQSTFWUPdqOi7ZS1uGEQtV6dZldJDVHt/RoqfkxV tRcdsbPKxzxZlaVIfhwvCv6jjAoYNiXevn/02fyGspG3FhOO/+HRN6tBTIHtTqVYWlLs 4HscdPfbZDW+I1v7HNKVMjVzGHioVC2jBXOfDhFwQQPRT4r0Mz0fw87aXCQ/5olmt1H4 gPdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8+89c/M69LI4ftLf/6/Vpb22YVYzmkcvp0o/HutuNgM=; b=TjOOQOZIilXto435tVCv18CD4xRYDHPFoZ0M4Hs7Qp8gqPtZQr169JJSjPQwkmLla0 oyvBnLkeTeo2BMfK1XpWxF8EDap26NG8bSHggZ9YCTiEP37n27BGyl8y+RqJH+0CXle4 K3w2SQx1AvpmvIec4v66OD6CXOtjf60oxyLnCly+H4w07shfXcYW4Jbqn/mzjINB/gB9 kAsEYs6FQgZ+R0bry5oCKb2b+q3cOYBS/1YcsU0NGtUad8Pz6Lo5B59j1cArHfw0Zz9+ gwp0UY5EyY7ftY1GIN1JYRVNr5umcNtF3y1jAzFavAeIeQJoJ+eHgkySP4WoDUp4S7VQ PMyQ== X-Gm-Message-State: AIkVDXI28BRnnWfeoudyHfFOmSnjyUGLzXYXUAW//cJXViknt4k32L8wLUwh/ER7yzQASA== X-Received: by 10.200.57.134 with SMTP id v6mr74036018qte.36.1483811945858; Sat, 07 Jan 2017 09:59:05 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id o44sm37735126qtc.8.2017.01.07.09.59.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Jan 2017 09:59:04 -0800 (PST) From: Ted Lemon Message-Id: <28533A06-2567-4090-A7AE-5BEA649C9857@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_174F1741-97D9-443C-96FC-545489FC5BBB" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 7 Jan 2017 12:59:03 -0500 In-Reply-To: To: Eliot Lear References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: hrpc@irtf.org, Andrew Sullivan Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 17:59:08 -0000 --Apple-Mail=_174F1741-97D9-443C-96FC-545489FC5BBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 7, 2017, at 10:19 AM, Eliot Lear wrote: > We don't encode passwords in the clear, for instance, because the = probability of them being stolen approaches 1 over time. Whether the = draft actually says that, quite frankly, is hard for me to determine. Well, actually, this general question was a matter of public debate just = a few months ago. Supposedly serious people came out on the side of = not encrypting the password. Of course, they claimed (and perhaps = believed) that that wasn't really what they were saying, but that was = really what they were saying. --Apple-Mail=_174F1741-97D9-443C-96FC-545489FC5BBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 7, 2017, at 10:19 AM, Eliot Lear <lear@cisco.com> = wrote:
We don't encode = passwords in the clear, for instance, because the probability of them = being stolen approaches 1 over time.  Whether the draft actually = says that, quite frankly, is hard for me to = determine.

Well, actually, this general question was a matter of public = debate just a few months ago.   Supposedly serious people came out = on the side of not encrypting the password.   Of course, they = claimed (and perhaps believed) that that wasn't really what they were = saying, but that was really what they were saying.

= --Apple-Mail=_174F1741-97D9-443C-96FC-545489FC5BBB-- From nobody Sat Jan 7 14:02:05 2017 Return-Path: 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 CDB121295E7 for ; Sat, 7 Jan 2017 14:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 d4S5Ts0vZwUQ for ; Sat, 7 Jan 2017 14:02:03 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3F129424 for ; Sat, 7 Jan 2017 14:02:03 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id v07M1ZiM024866; Sat, 7 Jan 2017 17:01:37 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id v07LxpKS031181; Sat, 7 Jan 2017 16:59:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22641.25815.596923.985413@gargle.gargle.HOWL> Date: Sat, 7 Jan 2017 16:59:51 -0500 From: bzs@theworld.com To: hrpc@irtf.org In-Reply-To: <0d2d4bb4-bba6-c1c7-e45f-69fbea099728@article19.org> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> <20170106171632.ywoh52l5al4p5yzp@nic.fr> <04f23833-7a7a-339c-aeca-7d4f86c18959@cs.tcd.ie> <20170106172658.x47wn7vbivg2vn4d@nic.fr> <0d2d4bb4-bba6-c1c7-e45f-69fbea099728@article19.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 22:02:05 -0000 Perhaps a tangent but one early motivation for the establishment of public libraries was so any citizen could access a copy of the laws. How else could they? And isn't access to the law a particularly fundamental right? Much grows out of that one observation. With paper libraries in decline the evolution of thought seems to me obvious: We mustn't decide that online access to the law is a sufficient replacement while not also ensuring careful guarantees of easy, reliable, and accurate access. And the privacy and security of that access. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Sat Jan 7 21:47:08 2017 Return-Path: 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 75B381294DB for ; Sat, 7 Jan 2017 21:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=T+eZsmRp; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=bsNDpoBi 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 T8yGp6YW5oEu for ; Sat, 7 Jan 2017 21:47:05 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D0E1294A9 for ; Sat, 7 Jan 2017 21:47:05 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v085ktOw007861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jan 2017 21:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1483854421; x=1483940821; bh=+XfA71F+xtkGoXv8ialJfx0yumwkYbSA4nMFGLG0A/w=; h=Date:To:From:Subject; b=T+eZsmRpMy2WfdJgawt4y3Vu2w/G/V3rem+HG4JmeqY0+E0/3LWUv3lDiuQOyqOSy P+BAltc1MEWUQlnSRQXPmqZpGAJtRT+dNNqeFNtPxnqQrbXDaRtxR0l6P/wnmEMjpv WEhaPXVcOD2I2pmJyVapR6951oWF9hREbRMUyJm8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1483854421; x=1483940821; i=@elandsys.com; bh=+XfA71F+xtkGoXv8ialJfx0yumwkYbSA4nMFGLG0A/w=; h=Date:To:From:Subject; b=bsNDpoBiF7YmuK89WWEXg/NTKT4qpxiH9BbpQvu15AHO/B1/mqDuLKDHrAqCf2+bz ocjkXsYgILBiMBQFZr6O5Wp48GmX1sqJ0BmRsFyccc5lOVHkz8B80Qe8q0Plp9V9fU 2UYGy5PbugtS/TnAr3d1BjF9hHDZpjZYAV8kQmVA= Message-Id: <6.2.5.6.2.20170107204600.0ad4ab88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jan 2017 21:43:03 -0800 To: Andrew Sullivan , hrpc@irtf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 05:47:06 -0000 Hi Andrew, [This message will not be displayed correctly in the thread as I did not reply to a message from the thread] For context, please see https://www.ietf.org/mail-archive/web/hrpc/current/msg00775.html >Perhaps there is a more charitable reading, which is that the draft >tries to take values from an international political context and tries >to suggest how they interact with the relevant standards-setting >context. (One might disagree about the degree to which it is >successful at that, but I think that the documentation of the >interaction really is the goal, not application of the values as >such.) According to the Charter, one of the outputs is to "define any possible protocol considerations". That may be similar to the "interact" and "interaction" in the above. Regards, S. Moonesamy From nobody Sun Jan 8 01:53:54 2017 Return-Path: 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 B29F9128E18 for ; Sun, 8 Jan 2017 01:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.989 X-Spam-Level: X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=bth1T3A6; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=Znk69RPd 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 KpITJkZ1dMkL for ; Sun, 8 Jan 2017 01:53:52 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6150B12007C for ; Sun, 8 Jan 2017 01:53:52 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v089reY1001033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jan 2017 01:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1483869228; x=1483955628; bh=rMu4BIlq99JwKNdGb5gZfa48mJZUHFshqser23ajfgU=; h=Date:To:From:Subject; b=bth1T3A6Ps3xGcHg1L9e9/v4drn7z+5p02vaZca5/H8zlkXlzxM56KiVj7dTVUvVK r+r4YzoSNA0TjA4uqFbPVevrmZudlDQsTQUWpSjAsWWhHJ1JM8J5IABNNXcoxI762+ PH88IXtSQrUMrZ7i6K0UIaho1G6dwforlUjHlgz4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1483869228; x=1483955628; i=@elandsys.com; bh=rMu4BIlq99JwKNdGb5gZfa48mJZUHFshqser23ajfgU=; h=Date:To:From:Subject; b=Znk69RPdiNNxOnTpZtWoxqjkYMOUHKPjB4G2xexl8JF2pWgRcfNdhV17zcFkN5gUR PUOVmel8IJ/lN9XzlfMfvGW2jhGo8wDgGtixUh/BRJRY1BOmqvY1TQDOiRcRuixRTU a81+BzmudElwLcubQcxNrk8kPfTOSEflr0C9Jfmw= Message-Id: <6.2.5.6.2.20170107220716.0ad4f200@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Jan 2017 01:43:38 -0800 To: Jeanette Hofmann , hrpc@irtf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 09:53:53 -0000 Hi Jeanette, [This message will not be displayed correctly in the thread as I did not reply to a message from the thread] For context, please see https://www.ietf.org/mail-archive/web/hrpc/current/msg00776.html >So, my question is what does all of this have to do with whether or >not standard setting is a political activity? In my view, all the >controversial references to "protocols are politics by other means" >can be dropped from the draft. They do not add anything substantial >to the proposal. > >The essential question is whether, to what extent and in which form >the IETF wants to take into account that its work does impact the >human rights of internet users. It is unlikely that anybody >seriously doubts that internet standards affect the exercise human >rights. But what follows from that is much less obvious. If standards setting is a political activity it would mean that the IETF is a political organization. The first issue is that some persons would either be unable to participate in the IETF because they are either not allowed to take part in political activities or because they will face negative consequences in the country where they reside because of the affiliation. There is a question about an IETF standard at https://www.ietf.org/mail-archive/web/perpass/current/msg01765.html Is it acceptable for the IETF to make a statement about whether the European Parliament is infringing on the human rights of its citizens? >2. The draft constantly confuses political effects and intentions of >protocol development. The fact that a protocol does have politica >effects does not necessarily make its development a political >process. If Janet Abate concludes in her very good book that >"protocols are politics by other means", it is not clear if she >refers to the effects of protocols or to the intentions of protocol >developers. Based on the interviews I did back in the 1990s, I would >claim that many people involved in the development of IPv4 became >aware of the political dimension of their work (to the extent that >it was competing against another protocol suit) but this political >dimension did not drive their work. Many of the early developers >primarily wanted to connect computers and experiment with network >architecture design not code a political statement. > >This is why I suggested distinguishing various definitions of "the >political" Political can be an effect or an intention or both. But >it is not ok to conclude from effects on the intentions of action. Does an IETF action have a political implication? There is the protocol development side and the policy side. The action of approving the development of a protocol within the IETF is not a technical decision. There may be a political effect if the software or hardware in which the protocol is implemented has an effect which is contrary to what the government of a country would like to see. Was it the intention of the IETF body to cause that effect to happen? It is not possible to determine that without looking at an actual case. There is a significant difference between the early network architecture design and the networks of today. There has been several cases over the last year where it could be said that freedom of expression was hindered at a national level. If a political statement was coded in to ensure freedom of expression, it should have been possible to prevent that from happening. Regards, S. Moonesamy From nobody Sun Jan 8 18:06:19 2017 Return-Path: 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 97E0B1295C3 for ; Sun, 8 Jan 2017 18:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 KaRIIsmHeQtQ for ; Sun, 8 Jan 2017 18:06:16 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 5403D12953F for ; Sun, 8 Jan 2017 18:06:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 0D92511507 for ; Mon, 9 Jan 2017 02:06:22 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBnXVKEwKx3R for ; Mon, 9 Jan 2017 02:06:21 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 50057114DB for ; Mon, 9 Jan 2017 02:06:21 +0000 (UTC) Date: Sun, 8 Jan 2017 21:06:12 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170109020612.GA892@mx2.yitter.info> References: <6.2.5.6.2.20170107220716.0ad4f200@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20170107220716.0ad4f200@elandnews.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 02:06:17 -0000 Hi, On Sun, Jan 08, 2017 at 01:43:38AM -0800, S Moonesamy wrote: > Does an IETF action have a political implication? There is the protocol > development side and the policy side. The action of approving the > development of a protocol within the IETF is not a technical decision. Those sentences together represent a pretty bold claim. Could you say more? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jan 9 00:00:57 2017 Return-Path: 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 6E53B129BB4 for ; Mon, 9 Jan 2017 00:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.989 X-Spam-Level: X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=GkaJO7/7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=WAvE70z/ 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 X4xyPhooh4fG for ; Mon, 9 Jan 2017 00:00:55 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1DA129BAB for ; Mon, 9 Jan 2017 00:00:55 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0980mKC015859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2017 00:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1483948854; x=1484035254; bh=8Elh111YdnkafY8QudvA7q47ry3GEy30A0pyTIJPOaQ=; h=Date:To:From:Subject; b=GkaJO7/7Rq7VY8GldADnMURtCqAedaUcDaNQSnjj+zUJzWmDdc7qTL1ux6KUvTzt2 qcaT+3C+aJy4xGcw/baB0uvIwMN7Z/NmexKFzoI6Zo2EHOgh5g8S+1ogfgpVyjSyej uolq/VquBL2pvfNPXZURQeXwQxByXO3W6yEDGdoU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1483948854; x=1484035254; i=@elandsys.com; bh=8Elh111YdnkafY8QudvA7q47ry3GEy30A0pyTIJPOaQ=; h=Date:To:From:Subject; b=WAvE70z/SxKLj2/oyM55KPTiD0KzsrQifhOz6ihhPmCZsc5edFC1AwD1c9UnoyWHY BrPAu7YNtEvSkdX+zwVIXvEcnr3sz/qT7QOoLBe8wHCKzp8LgXPvOuFhZSh3CjRmvU /wg14hDniaOMR+1YH01BasSirKu/B+OoHOUBVYbE= Message-Id: <6.2.5.6.2.20170108213740.0b0924e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Jan 2017 23:50:19 -0800 To: Andrew Sullivan , hrpc@irtf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 08:00:56 -0000 Hi Andrew, >Those sentences together represent a pretty bold claim. Could you say more? The first sentence is not linked to the second sentence. I would list protocol development as what working groups are doing (development side). I would list decisions about how the IETF should work as the policy side, e.g. https://www.ietf.org/mail-archive/web/ietf/current/msg100277.html For the second sentence, taking websockets as an example, the protocol being developed would be a technology for bidirectional communication between an HTTP client and an HTTP server that provides greater efficiency than previous approaches. The decisions which the working group takes would usually be about technical details, e.g. how should the future protocol interact with a HTTP server. The decision about whether such a protocol should be developed within the IETF would not be technical; it would, for example, depend on whether a group of persons are interested in doing that work, what should go into the proposed charter, etc. Is there anything "political" to any of the above? There is one description of "the political" at https://www.ietf.org/mail-archive/web/hrpc/current/msg00744.html The IETF doesn't have any say in (2) as the software developers decide about whether to implement the websocket protocol and how to use it. Are there any political implications? I read Section III and IV of https://documents-dds-ny.un.org/doc/UNDOC/GEN/G16/095/12/PDF/G1609512.pdf?OpenElement to figure out the human rights angle. The only point which might be relevant to the technical standard is the security considerations for the protocol. There is a discussion about that, from a technical perspective, in the IETF RFC. Regards, S. Moonesamy From nobody Mon Jan 9 05:17:09 2017 Return-Path: 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 D2948129CA5 for ; Mon, 9 Jan 2017 05:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 2Uwemk9TocoF for ; Mon, 9 Jan 2017 05:17:06 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 EF9C1129B3A for ; Mon, 9 Jan 2017 05:17:05 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cQZos-0003oN-Tw for hrpc@irtf.org; Mon, 09 Jan 2017 14:17:03 +0100 To: hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> Date: Mon, 9 Jan 2017 14:17:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iFNIkX8f7LdR1KCImcOBloMeJ2BDnJvnO" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4b8baa00aa45d625c6ee6c23f4cb0de1 Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 13:17:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iFNIkX8f7LdR1KCImcOBloMeJ2BDnJvnO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/07/2017 12:35 PM, Jeanette Hofmann wrote: > Human rights concern and structure the relationship between citizens an= d > public authorities, they do not affect the horizontal relationships > between citizens or between citizens and companies, standard setting > bodies etc. In fact, the products and services of many commercial > companies affect human rights in fundamental ways but it does not follo= w > from these affects that they have to modify their actions. Hi Jeanette, You might want to have a look at the UN Guiding Principle for Business and Human Rights [0] as well as the report by the UN Special Rapporteur on Freedom of Expression on 'Freedom of expression, states and the private sector in the digital age' [1] which both explicitly deal with the relationship between human rights and companies, as did the UN Global Compact before. The report of the Special Rapporteur even explicitly mentions standard setting bodies. Cheers, Niels [0] http://www.ohchr.org/Documents/Publications/GuidingPrinciplesBusinessHR_E= N.pdf [1] https://daccess-ods.un.org/TMP/8412558.43639374.html [2] https://www.unglobalcompact.org/ --iFNIkX8f7LdR1KCImcOBloMeJ2BDnJvnO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYc41OAAoJEA7YPzpGisizKBwP+wR7BBWCC7nVmVHS27+uE8d2 vNvT+46YJq2UDQE0QDl0dlphZ2z8/RNZNxjqBTQbi2TlCtj454Hz5m3+o0oVrYaU aN70/3rSv4paG22U3FIFrBqx/ATfQVp/KCSmVGvk4VzKL98fbAliOR3agaQVhNnN eMKIbN0LxyM6xLn+/srJuYXgU3H8NywI//pYFGFgJsAk36usowmDhSsygNJa0J2e p55QQB3a6DJhC+P3XnkGYAEgMFu40wgiF5ZFkMn9EgDWvNO4sVu0avZzqAg5s7Tz mbC0ZHsvl4XcGlkkbV0Nn7/dtNnZX9rv6v2a+PZljFaySn0VKpdPrMW4Vsrtu4Px v08tfgIsD+I2TsYP7dX9VGlIKiaHHFw8Zeyk4CVXOiPZ1I1TMIVaNZGB+IR07NiU 5fA3sTNXKn0t4i9i53/mdnwAn+MSoys7XM9UPi7xksyZ/WbvUU/PLaEA0q+FHGnq QugoZRB4+qxWf/GHYthrxf9Krt7y9EiY7HmPOc7JyDpeIxT3DnhU+KjseKsM13/t VOx2TJWQAWF/oYR71+cR9Q3EuNZ2y6TI+gJuVTRswrHMf/Ob6pZWoNbE8+0/kTKZ i19VSo3IW8fPP+/68woFGYo49PmW5/3NbqBQcNQl9JphtX9UvW1/gzBnT4NmtLns nDyDuVOHDUTHpowKIqC8 =+Evq -----END PGP SIGNATURE----- --iFNIkX8f7LdR1KCImcOBloMeJ2BDnJvnO-- From nobody Mon Jan 9 05:53:31 2017 Return-Path: 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 B02411294C4 for ; Mon, 9 Jan 2017 05:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0Vkmolp-uY37 for ; Mon, 9 Jan 2017 05:53:27 -0800 (PST) Received: from athene.wzb.eu (athene.wzb.eu [193.174.6.3]) (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 4B816128DF6 for ; Mon, 9 Jan 2017 05:53:27 -0800 (PST) To: hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> From: Jeanette Hofmann Message-ID: Date: Mon, 9 Jan 2017 14:53:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-WZB-Virus-Scanned: by Clam AntiVirus at athene.wzb.eu X-Priority: 3 (Normal) Importance: Normal Priority: normal Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 13:53:30 -0000 Am 09.01.17 um 14:17 schrieb Niels ten Oever: > > On 01/07/2017 12:35 PM, Jeanette Hofmann wrote: >> Human rights concern and structure the relationship between citizens and >> public authorities, they do not affect the horizontal relationships >> between citizens or between citizens and companies, standard setting >> bodies etc. In fact, the products and services of many commercial >> companies affect human rights in fundamental ways but it does not follow >> from these affects that they have to modify their actions. > > Hi Jeanette, > > You might want to have a look at the UN Guiding Principle for Business > and Human Rights [0] Hi Niels, I know these principles. They are one laudable attempt among several aiming to expand the scope of applicability of human rights to the private sector. They are not binding and, so far, they have not been overwhelmingly successful. They sort of confirm what I said, that the IETF, as much as any other non-governmental organisation, should clarify its relationship to human rights. The same is true for the reports by UN Special Rapporteurs etc. They don't entail any obligations, they specify recommendations. > The report of the Special Rapporteur even explicitly mentions standard > setting bodies. And what follows from this? And how is this related to the question as to whether or not the IETF's work is political? It is not for me to say whether the IETF would benefit from clarifying the political dimension of its work. But it is obvious to me that different understandings of what is political are used on this list, and that it is not helpful for the discussion to mix them. I would repeat that deciding to respect human rights does not follow from creating standards with political impacts. I don't understand why the draft links these two issues. (Here is a different argument one could make in favor of including human rights into the framework of standard setting for the internet: until the privatisation of the telecommunication sector in the 1980s and 1990s, telecommunication used to be a public service in many if not most countries. As long as they were under public control, telecommunication providers and services had to respect human rights. Given the importance this sector now has for our everyday life, it would make sense to expand the scope of human rights to this sector.) Jeanette > > Cheers, > > Niels > > > [0] > http://www.ohchr.org/Documents/Publications/GuidingPrinciplesBusinessHR_EN.pdf > [1] https://daccess-ods.un.org/TMP/8412558.43639374.html > [2] https://www.unglobalcompact.org/ > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > From nobody Mon Jan 9 05:57:39 2017 Return-Path: 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 B0451128DF6 for ; Mon, 9 Jan 2017 05:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 7oJgDkMNmNPA for ; Mon, 9 Jan 2017 05:57:35 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 1C1891294C9 for ; Mon, 9 Jan 2017 05:57:35 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cQaS5-0002hV-BQ for hrpc@irtf.org; Mon, 09 Jan 2017 14:57:33 +0100 To: hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> From: Niels ten Oever Message-ID: <8dd5598a-7b96-9b09-2408-30b8442ab2a4@article19.org> Date: Mon, 9 Jan 2017 14:57:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FGUnq2TEfPnTSTl34TOadBRoWLioxcXe8" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 00ca572c58d2a72aaa1283be2358df10 Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 13:57:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FGUnq2TEfPnTSTl34TOadBRoWLioxcXe8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jeanette, Reply inline: Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 On 01/09/2017 02:53 PM, Jeanette Hofmann wrote: >=20 >=20 > Am 09.01.17 um 14:17 schrieb Niels ten Oever: >> >> On 01/07/2017 12:35 PM, Jeanette Hofmann wrote: >>> Human rights concern and structure the relationship between citizens = and >>> public authorities, they do not affect the horizontal relationships >>> between citizens or between citizens and companies, standard setting >>> bodies etc. In fact, the products and services of many commercial >>> companies affect human rights in fundamental ways but it does not fol= low >>> from these affects that they have to modify their actions. >> >> Hi Jeanette, >> >> You might want to have a look at the UN Guiding Principle for Business= >> and Human Rights [0] >=20 >=20 > Hi Niels, >=20 > I know these principles. They are one laudable attempt among several > aiming to expand the scope of applicability of human rights to the > private sector. They are not binding and, so far, they have not been > overwhelmingly successful. They sort of confirm what I said, that the > IETF, as much as any other non-governmental organisation, should clarif= y > its relationship to human rights.=20 That's exactly what we're aiming to do here. > The same is true for the reports by UN > Special Rapporteurs etc. They don't entail any obligations, they specif= y > recommendations. >=20 >=20 >> The report of the Special Rapporteur even explicitly mentions standard= >> setting bodies. >=20 > And what follows from this? > And how is this related to the question as to whether or not the IETF's= > work is political? I dont think this is stated in the draft (as it is now). Else, could you point me to the text you have an issue with? https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md >=20 > It is not for me to say whether the IETF would benefit from clarifying > the political dimension of its work. But it is obvious to me that > different understandings of what is political are used on this list, an= d > that it is not helpful for the discussion to mix them. >=20 > I would repeat that deciding to respect human rights does not follow > from creating standards with political impacts. I don't understand why > the draft links these two issues. It doesn't. >=20 > (Here is a different argument one could make in favor of including huma= n > rights into the framework of standard setting for the internet: until > the privatisation of the telecommunication sector in the 1980s and > 1990s, telecommunication used to be a public service in many if not mos= t > countries. As long as they were under public control, telecommunication= > providers and services had to respect human rights. Given the importanc= e > this sector now has for our everyday life, it would make sense to expan= d > the scope of human rights to this sector.) >=20 Best, Niels > Jeanette >=20 >> >> Cheers, >> >> Niels >> >> >> [0] >> http://www.ohchr.org/Documents/Publications/GuidingPrinciplesBusinessH= R_EN.pdf >> >> [1] https://daccess-ods.un.org/TMP/8412558.43639374.html >> [2] https://www.unglobalcompact.org/ >> >> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >> >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --FGUnq2TEfPnTSTl34TOadBRoWLioxcXe8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYc5bIAAoJEA7YPzpGisizJN8P/1p6X1H4hvpDJYNckftQcRpm 8KpnG5x+JkY37DA1Bzd5rq1/2VhjtDKtv7fkZVjPd9JQeKs1yLR1reZ36LFkqaMC lqAhRp/VxQOd1wSSM1GN26gB7I0mEaZcHDoOPi+xp1etH4gIt9UyBJTeLPdjkXhR QHaXq8A6L48BX1NtgoKigu/P2pO0t24fGHhoG2Mtr7zdgLYMGVQkcl04JQUdEBOM bQzzUSPl8UCJLh/MC5FrHDbMidRoG2iL9FkFp4XajgAXYiTFUvSR8bAH85qYkvL/ 6nmwhhUCS/vOrBfe0BVx9H+0PUm7nWnrotln++/upj0aQbKS6LNt7SoiK4jSWIh2 SV7Fx7kqzY0PPdx8AKA2mudFa1c6W7Hshk7gAculxttr8zyFfS/myZXvgG7ng2N3 YaBbgd17QRjFTAvhI31+6M3770T5MA9jkz47vTEZWjJUuYbNYp0IKs/3ZFA67FQk lP0NAEhhE5T01YR8mWeepc4/c00bbn1UkQ1emXlBbKKaPbplAeJism+IvDWjDxW7 B10Cib4YYyPNZZtmnPwv5kC2vSAWCO5Q6dSupFST+C18b7LD5J/m6WyfDwBH4XFq NrHkrMvPcFAPE4j/0lMBOxacxzybPfCyoaInFyQjOikEpCnC/UqmA2EeRUQSzcBM 3FXLooETe+I7MIj4VngA =/rJ7 -----END PGP SIGNATURE----- --FGUnq2TEfPnTSTl34TOadBRoWLioxcXe8-- From nobody Mon Jan 9 06:04:18 2017 Return-Path: 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 571B512947E for ; Mon, 9 Jan 2017 06:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.601 X-Spam-Level: X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Aql1A0t_iTHi for ; Mon, 9 Jan 2017 06:04:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACDF129466 for ; Mon, 9 Jan 2017 06:04:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBA4EBE39; Mon, 9 Jan 2017 14:04:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obxBP3hgAHPB; Mon, 9 Jan 2017 14:04:10 +0000 (GMT) Received: from [172.28.172.2] (unknown [185.51.75.90]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A7EC4BE49; Mon, 9 Jan 2017 14:04:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483970650; bh=/N2zpjRfmUDk/dF5U7br89+wkoQW0J55cUeubqmf9eg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FVezjf+qHZsEkvvAbHQ5+Z6p5k8fOy8TCevigOYjK2XLu6O2JnG2tnfz6WpprhiKA pgaEksewpA6jimQGjoTjwH9XO1b0PJYsQtAgRFxcA/cUrMC0zHHmHk9ybT76+BhGMe pEDMhzLJp14JAG1O/r5SDGo3CpZKHKMYb2nb0kzE= To: Jeanette Hofmann , hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5953ebaa-c845-de8d-c166-30ce7cb9868a@cs.tcd.ie> Date: Mon, 9 Jan 2017 14:03:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080406080007030703050305" Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:04:16 -0000 This is a cryptographically signed message in MIME format. --------------ms080406080007030703050305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 09/01/17 13:53, Jeanette Hofmann wrote: >=20 > (Here is a different argument one could make in favor of including huma= n > rights into the framework of standard setting for the internet: until > the privatisation of the telecommunication sector in the 1980s and > 1990s, telecommunication used to be a public service in many if not mos= t > countries. As long as they were under public control, telecommunication= > providers and services had to respect human rights. Given the importanc= e > this sector now has for our everyday life, it would make sense to expan= d > the scope of human rights to this sector.) While I tend to agree with you overall that getting rid of the protocols-are-politics text from the draft may be better, I'm afraid that I'm not at all sure the above is a good thing to include either, for political reasons;-) The political reason to not add text like the above is that it could be read to imply that government controlled telcos (which do still exist) should have control over the Internet on the basis that it's only those that might respect HR. I don't think that'd be a good statement to make both because it's not correct and because it'd be liable to be misquoted for mischief in some contexts. Cheers, S. PS: I'm still ok if the text Niels and I ended up with after wrangling the other day is included. --------------ms080406080007030703050305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDkx NDAzNTZaMC8GCSqGSIb3DQEJBDEiBCBGyiRKNh3FUkCztnPEuze9YbZ5Rc7JffH9V7w/NqrR HjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAWeLNIoicYb8SknWK7OyV6/1+tlbqsUdSjqe+PiIh28PttBN06JLTb SxG33ZeKcGYBbDEGamNbRbt1cf50eVd5gSQu1sPQGMmSY5LE/ooZ0pAAP+HC5ZRoGvB6IfJU AdsnekZibiCWmmQIJ3k9W1PFdTpjOpskTz0Fq9IwuG/8Qs3FK/ChGL6OWkKLn+V8Zv0gh/W6 lo3QW03SAxiNy3600znbmhUztkeYEAdt+2POh1LJhpoQXzJqVJ0PIUeDxT8g3qz5WR0vGl/J 8ANOt5PBKm4rhiUXNygC2at4kOBu1PAiAPR4gM6nHaDG1BilBbKgJkuffP80xfeqfBEom2mU AAAAAAAA --------------ms080406080007030703050305-- From nobody Mon Jan 9 06:07:27 2017 Return-Path: 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 D1BCE12947E for ; Mon, 9 Jan 2017 06:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0g5HEAomtIR4 for ; Mon, 9 Jan 2017 06:07:24 -0800 (PST) Received: from athene.wzb.eu (athene.wzb.eu [193.174.6.3]) (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 27DAC129466 for ; Mon, 9 Jan 2017 06:07:24 -0800 (PST) To: hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> <5953ebaa-c845-de8d-c166-30ce7cb9868a@cs.tcd.ie> From: Jeanette Hofmann Message-ID: <6cd6f775-21c4-94c3-991a-c29ef0c642e2@wzb.eu> Date: Mon, 9 Jan 2017 15:07:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5953ebaa-c845-de8d-c166-30ce7cb9868a@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-WZB-Virus-Scanned: by Clam AntiVirus at athene.wzb.eu X-Priority: 3 (Normal) Importance: Normal Priority: normal Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:07:26 -0000 Am 09.01.17 um 15:03 schrieb Stephen Farrell: > > Hiya, > > On 09/01/17 13:53, Jeanette Hofmann wrote: >> >> (Here is a different argument one could make in favor of including human >> rights into the framework of standard setting for the internet: until >> the privatisation of the telecommunication sector in the 1980s and >> 1990s, telecommunication used to be a public service in many if not most >> countries. As long as they were under public control, telecommunication >> providers and services had to respect human rights. Given the importance >> this sector now has for our everyday life, it would make sense to expand >> the scope of human rights to this sector.) > > While I tend to agree with you overall that getting rid of the > protocols-are-politics text from the draft may be better, I'm > afraid that I'm not at all sure the above is a good thing to > include either, for political reasons;-) > > The political reason to not add text like the above is that it > could be read to imply that government controlled telcos (which > do still exist) should have control over the Internet on the > basis that it's only those that might respect HR. I don't think > that'd be a good statement to make both because it's not correct > and because it'd be liable to be misquoted for mischief in some > contexts. Yes, I understand that, and for this reason I hesitated making this point. Just look at it as an example for a historically based link between internet standard setting and human rights. Jeanette > > Cheers, > S. > > PS: I'm still ok if the text Niels and I ended up with after > wrangling the other day is included. > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > From nobody Mon Jan 9 06:12:47 2017 Return-Path: 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 18A141294F9 for ; Mon, 9 Jan 2017 06:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 RKfhYcIJxL-h for ; Mon, 9 Jan 2017 06:12:44 -0800 (PST) Received: from athene.wzb.eu (athene.wzb.eu [193.174.6.3]) (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 C66F41294F6 for ; Mon, 9 Jan 2017 06:12:44 -0800 (PST) To: hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> <8dd5598a-7b96-9b09-2408-30b8442ab2a4@article19.org> From: Jeanette Hofmann Message-ID: <4fcaa1eb-d439-0d91-2e92-f382ac7f3c3d@wzb.eu> Date: Mon, 9 Jan 2017 15:12:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <8dd5598a-7b96-9b09-2408-30b8442ab2a4@article19.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-WZB-Virus-Scanned: by Clam AntiVirus at athene.wzb.eu X-Priority: 3 (Normal) Importance: Normal Priority: normal Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:12:46 -0000 > >> >> It is not for me to say whether the IETF would benefit from clarifying >> the political dimension of its work. But it is obvious to me that >> different understandings of what is political are used on this list, and >> that it is not helpful for the discussion to mix them. >> >> I would repeat that deciding to respect human rights does not follow >> from creating standards with political impacts. I don't understand why >> the draft links these two issues. > > It doesn't. If you don't mean to create a link, I don't understand why the draft quotes Abate, DeNardis and others to emphasise that protocols are politics by other means. Why then don't you drop all this stuff? Jeanette > >> >> (Here is a different argument one could make in favor of including human >> rights into the framework of standard setting for the internet: until >> the privatisation of the telecommunication sector in the 1980s and >> 1990s, telecommunication used to be a public service in many if not most >> countries. As long as they were under public control, telecommunication >> providers and services had to respect human rights. Given the importance >> this sector now has for our everyday life, it would make sense to expand >> the scope of human rights to this sector.) >> > > > Best, > > Niels > >> Jeanette >> >>> >>> Cheers, >>> >>> Niels >>> >>> >>> [0] >>> http://www.ohchr.org/Documents/Publications/GuidingPrinciplesBusinessHR_EN.pdf >>> >>> [1] https://daccess-ods.un.org/TMP/8412558.43639374.html >>> [2] https://www.unglobalcompact.org/ >>> >>> >>> >>> _______________________________________________ >>> hrpc mailing list >>> hrpc@irtf.org >>> https://www.irtf.org/mailman/listinfo/hrpc >>> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > From nobody Mon Jan 9 06:19:17 2017 Return-Path: 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 9D83E12946E for ; Mon, 9 Jan 2017 06:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 JTAsTnv5syBi for ; Mon, 9 Jan 2017 06:19:15 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 EFED9129442 for ; Mon, 9 Jan 2017 06:19:14 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cQan2-00068e-Mh for hrpc@irtf.org; Mon, 09 Jan 2017 15:19:12 +0100 To: hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> <20170107021224.GG24054@mx2.yitter.info> <2499e809-8d9b-43f4-952f-4544b909e318@article19.org> <8dd5598a-7b96-9b09-2408-30b8442ab2a4@article19.org> <4fcaa1eb-d439-0d91-2e92-f382ac7f3c3d@wzb.eu> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: Date: Mon, 9 Jan 2017 15:19:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <4fcaa1eb-d439-0d91-2e92-f382ac7f3c3d@wzb.eu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L9obTDNjnHKgEAPugDDPoMEdG0c9tsdLS" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 353bb18b0f14186cd389c275975c39f5 Archived-At: Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:19:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L9obTDNjnHKgEAPugDDPoMEdG0c9tsdLS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> >>> It is not for me to say whether the IETF would benefit from clarifyin= g >>> the political dimension of its work. But it is obvious to me that >>> different understandings of what is political are used on this list, = and >>> that it is not helpful for the discussion to mix them. >>> >>> I would repeat that deciding to respect human rights does not follow >>> from creating standards with political impacts. I don't understand wh= y >>> the draft links these two issues. >> >> It doesn't. >=20 > If you don't mean to create a link, I don't understand why the draft > quotes Abate, DeNardis and others to emphasise that protocols are > politics by other means. Why then don't you drop all this stuff? >=20 Because the literature shows different positions on the 'societal impact of protocols'. It shows how technology performs more than a merely 'technical function'. Best, Niels --L9obTDNjnHKgEAPugDDPoMEdG0c9tsdLS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYc5vfAAoJEA7YPzpGisizF8cP/ij9jW4CLNsOuhNsTwEGeU3K Hf2+KC/nOrJBif+KztmrZRy0hqpaspSUylxksJS8P6O4Di0y5w8CPyojK6/xeT3d BdwPjJWHh6O2cdvCQ7UCoIbg3anwqORL0kMSkXoAvTl9QlrO1VJmKfN9OVJ4Cxrh u7SKsyRWU+geTaJlqH/vTo9c1MfRgy85EtwccycKKFbNJla2Kr8dBAVwiBK9Zkg+ AAHx06YJr8M8hCQP1xuH/t0QU57yA12prb0xnFEKYHYLNT8htraXPvev1FsMAydf 9uvjwNauFv+vP3ffHWhJ3M49zARuHeyyn7ohZotRmGay8NjToOjqxn/6YZcola94 HM0La7DHkvsqUbTn38rvzqEK16Nd+fB3FvdBl7+7ACXcCZZuqHrcbMr5s0xE+aP+ HNXFp7Oyr1TpSGXgn5THWlRMX/S4IihXiheG9i7mOpTQH08dKwTZy/+ECixtWIoY 9CpDAjirEC5qnB7S1Z17bihOqr7PPTucedC8DVB8MWMLUnXAIF8lC1mXipVM1Dbl LwaaAc0kmYjXUtFSYAk0K/sF9P7kukeUqxe+eBukVZ0t9NNFnzrLzr7wK5w5GFzM Z3GM/5pSAQHQAMLFKfbvPCW64j4X0rAuWynDfRFNrawTovdeaoTKbpr4g2Y3d8eh GoP5wkWLT5ezC8pUHD3y =V4Jh -----END PGP SIGNATURE----- --L9obTDNjnHKgEAPugDDPoMEdG0c9tsdLS-- From nobody Mon Jan 9 08:55:50 2017 Return-Path: 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 56F12129759 for ; Mon, 9 Jan 2017 08:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Ff4OP2wgKS0w for ; Mon, 9 Jan 2017 08:55:41 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 A1CB21294FF for ; Mon, 9 Jan 2017 08:55:40 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cQdEP-0003OT-92 for hrpc@irtf.org; Mon, 09 Jan 2017 17:55:38 +0100 To: hrpc@irtf.org References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <72333205-0458-63d9-6d9e-3538266fec1d@article19.org> Date: Mon, 9 Jan 2017 17:55:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="egm7msqjSQEuQfHLjsAm2UgOsdbnNMAgw" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 7a0c9fa4677531eb4377daa68d132878 Archived-At: Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 16:55:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --egm7msqjSQEuQfHLjsAm2UgOsdbnNMAgw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alissa, Thank you very much for this very thorough review. I made quite a few changes based on this. All changes can be found here: https://github.com/nllz/IRTF-HRPC/commit/cb0a9788f9efd2050b7a1912fda8e823= e4019ace Please find my response and some questions inline (and sorry for the delay in response): On 01/05/2017 06:45 PM, Alissa Cooper wrote: > Below is a review of draft-irtf-hrpc-research-07. I have not been > involved in the RG so these comments are for what they're worth and I > apologize if some of this ground has been trod before. This was an > interesting read and most of my comments are provided with an eye > towards making the document more useful/actionable in the IETF > eventually, which I realize may not be a shared goal necessarily. >=20 > Substantive comments: >=20 > =3D Section 3.2.3 and 3.2.3.1 =3D >=20 > If the point of the IPv4 example is to demonstrate the human rights > impacts -- both positive and negative -- of various protocol designs, > I find the section to be narrow, slanted, and incomplete. It seems > focused almost exclusively on the potential harms, which, for a > protocol as fundamental to the operation of the Internet as IPv4, is > not justified and renders this section somewhat useless IMO. >=20 > IPv4 is the basis for packet-switching on the Internet. What would > the human rights impacts be if packet-switching was never invented? > It seems to me that any evaluation of the human rights impacts of > IPv4 needs to take this more wholistic view into account. IPv4 > completely revolutionized networking and allowed for the amazing > innovation that the purposes for which people were connecting could > be disassociated from the providers of the physical circuits. Had > that not happened, how would the capacity for human freedom of > expression in the world be different from what it is today? I don't > think an assessment of the human rights impacts of IPv4 can ignore > this and still be credible. >=20 > The above is just one example of a fundamental aspect of the protocol > that is overlooked in the existing analysis. Section 3.2.3.1.1 > bemoans the visibility of source and destination addresses, while > overlooking the fact that such addresses can actually provide a great > deal of anonymity protection compared to other identifiers that could > have been chosen to be made part of the protocol. Having decried > address visibility, Section 3.2.3.1.2 then makes no mention of the > fact that NAT can actually provide protection from such visibility. >=20 > For this section to add value, it either needs to provide a wholistic > analysis of both the positive and negative impacts of the protocol > that takes into consideration the space of alternative designs and > outcomes, or it needs to state up front that it is cherry-picking a > few harms identified as being linked to the protocol design just for > demonstration purposes. >=20 > I think the same goes for the other examples in Section 3.2.3. The > existing set of design and deployment decisions seem to be taken as > givens rather than as a set of inflection points where things could > have turned out much worse for human rights. What if the DNS hadn't > been designed in a distributed fashion? What if we hadn't managed to > make HTTP performant such that it could support rich media and > applications as it does today? What if instead of the near-ubiquitous > ability for stacks to deploy TLS we were all relying on IPSec as our > underlying security protocol? All of those were real possibilities. > Not acknowledging them makes the section read like a litany of > criticisms rather than a balanced assessment of the positive and > negative rights impacts of the protocols. >=20 > I was also surprised to see P2P, VPNs, a specific HTTP status code, > and DDoS attacks in this section which is purportedly about > protocols. This seems like a good bit of mixing apples and oranges; I > think the section would be more effective if it focused on specific > protocols since that is the unit of design most familiar to and most > actionable for IETF engineers. Analyzing protocol-level design > decisions is particularly important because what can be controlled > within a protocol design space is different from what can be > controlled within a particular implementation or deployment. >=20 As outlined in a subthread by Stephane and Stephen, this part did not aim to do an in-depth Human Rights Impact Analsysis of a single protocol but merely establish that there is a relationship between human rights and protocols based on case studies. I do hope one of the following hrpc drafts indeed can be the development of a model for a Human Rights Impact Assessment of protocols, and maybe even for of combinations of protocols (because that of course brings in different vectors). This will needs more research and experimentation though. I do agree that the cases are a mix of things (even though all have related RFCs) but we exactly aimed at a mix of things so see what different relations between protocols, standards and human rights could look like. I'm sorry to hear that you found the overall tone quite negative. Therefore I added some extra positive text here: https://github.com/nllz/IRTF-HRPC/commit/76375bdbf93c1c63661824fbcb7c89b1= 7ecdb609 > =3D Section 3.2.3.5.2 =3D >=20 > "Peer-to-Peer traffic (and BitTorrent in particular) represents a > high percentage of global Internet traffic" >=20 > Is there a citation for this? My understanding is that by most > measurements the share of p2p traffic is pretty low these days. >=20 This is the most recent stat I could find on this: http://mashable.com/2014/05/14/file-sharing-decline/#FG_t.2P3Uaqf https://www.rt.com/news/162744-p2p-file-sharing-increase/ Which indeed indicated it flattened out. So that's why I propose s/high/significant > =3D Section 4.1.1.1 =3D >=20 > Two overall comments about this section: >=20 > (1) The questionnaire seems like it took the kitchen sink approach. > Many of the considerations covered here are already covered in other > existing IETF documents. In a number of cases this document took > specific items from those existing documents and broke them out into > their own separate subsections with many detailed questions (e.g., > privacy, anonymity, pseudonymity, confidentiality, integrity, > reliability, authenticity). I think most protocol designers will find > the sheer volume of questions here daunting and will find the > redundancy both within the section and together with existing > guidance documents reason enough to skip a human rights analysis > altogether. I would recommend really trying to streamline this > section down to the essence of the questions that protocol designers > are not already asking themselves but should be. If you want to > include a comprehensive mapping between the technical concepts and > specific human rights, put that mapping in a different section and > focus this section on the most important and actionable questions. >=20 Thanks for this suggestion. I do agree that there are double parts, and the parts that are doulbe, are also clearly referenced as such. What we tried to do is create a clear human rights lens to specific problems, that's why I do not think the current parts are redundant. Also: I think that providing a reason for people to look at those documents increases that chance that they actually will, instead of just saying: have a look at this. > (2) I think it would be a lot clearer if the various subsections were > explicit about where the recommendations here are different than > recommendations in existing IETF documents and policies. For privacy, > security, internationalization, and extensibility, the document mixes > in references to existing guidance/policies with its own text and > suggestions. If the suggestion is to just go read the other > documents, a simple reference would do; otherwise, I think the > document could be a lot clearer about where it is asking protocol > designers to depart from or go beyond what the existing guidance > requires. Other than drawing explicit links between the concepts and > human rights affected, I think 4.1.1.1.2, .4, .9, .10, .14, .15, .16, > and .17 could all be removed or replaced with simple pointers to > existing documents (possibly also true for .5 and .12 but it=E2=80=99s = not my > area of expertise). The paragraphs that you outline above are already pointing to the other documents. The guidelines are not means to replace BCP72 or RFC6973, but provide another perspective for looking at protocols from a human rights perspective, and providing extra motivation for people to look at the these standards, because many of them (Internationalization, etc) are not as commonly use as we might like. >=20 > =3D Section 4.1.1.1.1 =3D >=20 > The example doesn't seem to be responsive to the question. The > question is about requiring functionality at intermediaries whereas > the example is about a design decision to prevent intermediaries from > carrying out such functionality. >=20 The example shows that one can implement message encryption in different ways, right? But maybe I am misunderstanding your question. > =3D Section 4.1.1.1.3 =3D >=20 > "Question(s): If your protocol impacts packet handling, does it look=20 > at the packet payload? Is it making decisions based on the payload=20 > of the packet? Does your protocol prioritize certain content or=20 > services over others in the routing process ? Is the protocol=20 > transparent about the priotization that is made (if any)?" >=20 > I think this set of questions could benefit from some refinement, in > particular in terms of the actor(s) being targeted. I don't quite > understand the notion of a protocol itself "looking" at a payload or > making a decision.=20 s/looking at packet payload/use data from the packet payload > I'm guessing this one is actually targeted at > network intermediaries, as in 4.1.1.1.1, since the whole point of > many protocols is for endpoints to take some action based on packet > payloads. >=20 As well as protocols that might make use from packet payload data instead of only using data from the header. > I also think the example in this section (and all the subsections of > 4.1.1.1, actually) would be more useful if it cited a specific > protocol that has the effect that the section raises concerns about, > because it's hard to understand what is being implied here. That is, > I'm not sure what the implications would be of the answers to these > questions if applied to, say RFC 2474 and RFC 2475, because the > implications all depend on the deployment context. >=20 I would be hesitant to target this at specific protocols, because that might exclude other protocols for which this could be relevant as well. I think the first sentence already is kind of a pre-selection, right? > =3D Section 4.1.1.1.6 =3D >=20 > "Question(s): Does this protocol introduce new identifiers or reuse=20 > existing identifiers (e.g. MAC addresses) that might be associated=20 > with persons or content? ... >=20 > Example: Identifiers of content exposed within a protocol might be=20 > used to facilitate censorship, as in the case of IP based > censorship, which affects protocols like HTTP." >=20 > I'm not sure how much mileage there is to be had out of this question > and example, because most protocols use identifiers. I don't think > this is a bad thing, it's just really hard to design a way to > communicate between two endpoints about something without using > identifiers of some sort. The question is phrased broadly enough that > I think the answer will almost always be "yes" but I'm not sure to > what end. >=20 Re-using identifiers might be a bad thing for de-anonymization, and if something can be implemented stateless, it might also be better for privacy, right? I think the last two questions in this para are key for providing perspective: Can your protocol contribute to filtering in a way it could be implemented to censor data or services? Could this be designed to ensure this doesn't happen? I also think the example provides quite some framing which also shows the boundaries of this question. > =3D Section 4.1.1.1.7 =3D >=20 > This section is concerning because it seems to be trying to > re-interpret or change existing IETF policies, which seems > inappropriate even for an informational IRTF document. For example, > this bit in particular caught my eye: >=20 > "All standards that need to be normatively implemented should be=20 > freely available and with reasonable protection for patent=20 > infringement claims, so it can also be implemented in open source or=20 > free software." >=20 > As nice as it would be if this were always true, it's not, and it's > not likely going to be any time in the foreseeable future for the > 8000+ specifications the IETF has produced.=20 How is this not in-line with BCP78 ? I think this is exactly what BCP78 says, the standards are available freely by the IETF. > Many of the reasons for > that are outside the control of IETF participants. So I find it > unhelpful to suggest these as requirements. I also don't think BCP 78 > and 79 and the note well should be further elaborated in a document > such as this one; even as informational people can get confused. >=20 > I would suggest deleting this section as there is a high potential > for confusion and I'm not sure that it provides much countervailing > benefit. >=20 > Also, I don't understand how the example relates to the rest of the > section or why the emphasis on DPI is there. >=20 > =3D Section 4.1.1.1.10 =3D >=20 > The example doesn't seem to relate to pseudonymity and I'm not sure > what is meant by a "feature." Again here giving a specific protocol > example would be more helpful I think. Changed into: Example: Designing a standard that exposes private information, it is important to consider ways to mitigate the obvious impacts. Pseudonymity means using a pseudonym instead of one's "real" name. There are many reasons for users to use pseudoyms, for instance to: hide their gender, protect themselves against harassment, protect their families' privacy, frankly discuss sexuality, or develop a artistic or journalistic persona without retribution from an employer, (potential) customers, or social surrounding. {{geekfeminism}} The difference between anonymity and pseudonymity is that a pseudonym often is persistent. "Pseudonymity is strengthened when less personal data can be linked to the pseudonym; when the same pseudonym is used less often and across fewer contexts; and when independently chosen pseudonyms are more frequently used for new actions (making them, from an observer's or attacker's perspective, unlinkable)." {{RFC6973}} >=20 > =3D Section 4.1.1.1.11 =3D >=20 > I think combining access for those with disabilities and access for > those with poor connectivity under a single heading is confusing. > These imply some rather disparate design decisions, not all of which > will apply to all protocols nor in the same ways. > I agree, I guess the problem lies in the word 'accessibility'. That is why we're offering different definitions for that in the glossary as well. Any suggestion on how we might improve this? > =3D Section 4.1.1.1.16 =3D >=20 > I think it would be better not to mix integrity with authentication > (via the example reference) since you can have one without the > other. >=20 I separated the two and created a different example. >=20 >=20 > Nits: >=20 > =3D Section 1 =3D >=20 > "the privacy ... of the network" doesn't seem like the concept > actually being described here. Usually we're focused on privacy of > individuals, and confidentiality of corporations (e.g., network > operators). >=20 Thanks, fixed! > =3D Section 2 =3D >=20 > There are two different definitions offered for "Connectivity." >=20 You mean this? : The extent to which a device or network is able to reach other devices or networks to exchange data. The Internet is the tool for providing global connectivity {{RFC1958}}. Different types of connectivity are further specified in {{RFC4084}}. The first one provides a definition and the second a subcategorization, right? > =3D Section 3.2.2 =3D >=20 > Accessibility is listed twice for "Right to political > participation." Thanks! That should have been connectivity! >=20 > =3D Section 3.2.3 =3D >=20 > "For instance, relying on an external server can be bad for freedom > of speech" -- without any further context provided, it's hard to > understand what is meant by an "external" server. >=20 s/external server/centralized service > =3D Section 4.1.1.1.2 =3D >=20 > "If a protocol provides insufficient privacy it may stifle speech" -- > I don't think it's the protocol that would be doing the stifling. >=20 Thanks, changed into: If a protocol provides insufficient privacy protection it may have a negative impact on freedom of expression as users self-censor for fear of surveillance, or find themselves unable to express themselves freely. > =3D Section 4.1.1.1.6 =3D >=20 > Given that censorship is much more narrowly defined than filtering > (presumably, although neither term is explicitly defined in the > document), I think it would be better to use the term censorship > rather than filtering. In some protocol contexts, filtering is an > explicit goal and it has nothing to do with censorship. >=20 Thanks fixed! All changes can be found here: https://github.com/nllz/IRTF-HRPC/commit/cb0a9788f9efd2050b7a1912fda8e823= e4019ace >=20 > _______________________________________________ hrpc mailing list=20 > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >=20 --egm7msqjSQEuQfHLjsAm2UgOsdbnNMAgw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYc8CIAAoJEA7YPzpGisizXIoP/3/uZhsF9bcNQ7LiKdja0ZIh YaceqddKqYjhMJnc1VHPr8fwVVKmnLRXtVIqjmFJThJlF3LSz1EawRBFj1fiINQR qsmwD4npT2DInNaJCKIkcr4hWnl374XKrYkmYJjrBmD+taCqibVpXWwoBrOILVWk FTSqOmyEiUjG1G+L7O0HbttOZxkTVBDibGqT3IB/FNHmX7phN5WsMvl5yjrAYybC jwKPGRsOB0M4t9UW+h2KVr7RdsgfoRYwdmMMfMGYvh78tjB3YjNsaR4mVPqdehnt 7x0aa6l1KOkhUp6tKuIASlw05hOsBxVaCIaS+5/9Ad2TgepTlS7lrx6hlz1H+HDY V7uwlTxMWLLr7NZ2Bn1Y3AhzeDb2aLU3uN7La/2AZxgQ/VyUBuwg9VHh0+T/SBeH QA0rZn4wYfCG8jfXE5CSEmP6wFvrKrDk3rDyhlNBXygvQnGZjAjnxmHni2B9Lf2e 0b4e98x6/yGno2vmrm/3LIqRqt1jnjlslK//4c3X/iMDb1ekLgdXjxlTkJeYfyhn iiO4PNnFLw7viyH58pjSxr/RlZcvmHsqYYsBU0Xj/pSQBlfI3f0cGAEtgGbZAR1I lXKV/egQQ8p1LIcEc2XoJpL45G0+0A1ITud78Az/4g1LOjgdPJ+jfTTC+e1+wEY/ 2foXt2Vs9eSbFeZUhnae =x8Ob -----END PGP SIGNATURE----- --egm7msqjSQEuQfHLjsAm2UgOsdbnNMAgw-- From nobody Mon Jan 9 09:05:08 2017 Return-Path: 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 EF6D4129570 for ; Mon, 9 Jan 2017 09:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 UAa0KiXbNAa9 for ; Mon, 9 Jan 2017 09:05:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24361288B8 for ; Mon, 9 Jan 2017 09:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5631; q=dns/txt; s=iport; t=1483981504; x=1485191104; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=CYJVayDv4X18bxHLri3p4qTZEuAwQZLys53w3gAi3Zc=; b=SBpQ2Vo/nuvDu1sppDZIvaOVN6Pij7RUkWWPEh4PkMQdOOK1+P9HQEWO rin8PTphMQz/e4OW6kQhUXcWu/mt/vtpksLESk6QApcZQo0UDTJLZ+8YD 3t7cM2/zCbtI2nVEmAkzq1vUN6doTvFJqUeyvsp7oLC3gVcGGR7oe9wyx M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAQBrwXNY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAR9iLF2DT4oIkiWPfIUrggqGHQMCAoFlPxQBAgEBAQE?= =?us-ascii?q?BAQFjKIRpAQUjVhALBAoKGAwDAwICRhEGDQYCAQGIbLACgiUrgymGQgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQ4PiEeCX4R8GII6gl4FkBGLC4NngX6LaIonhjWSVR8?= =?us-ascii?q?4gRISBxUVhwMdNYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,340,1477958400"; d="asc'?scan'208,217";a="190165756" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jan 2017 17:05:02 +0000 Received: from [10.41.32.37] ([10.41.32.37]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v09H51OU026061; Mon, 9 Jan 2017 17:05:01 GMT To: Ted Lemon References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> <28533A06-2567-4090-A7AE-5BEA649C9857@fugue.com> From: Eliot Lear Message-ID: Date: Mon, 9 Jan 2017 09:05:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <28533A06-2567-4090-A7AE-5BEA649C9857@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Gd30RtCa6M1W3oMkQorClGO8aBXSGirCb" Archived-At: Cc: hrpc@irtf.org, Andrew Sullivan Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:05:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Gd30RtCa6M1W3oMkQorClGO8aBXSGirCb Content-Type: multipart/mixed; boundary="4Ac2KevdtF6XP0fk1XvUjFV9c5MTGlB0G"; protected-headers="v1" From: Eliot Lear To: Ted Lemon Cc: Andrew Sullivan , hrpc@irtf.org Message-ID: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> <28533A06-2567-4090-A7AE-5BEA649C9857@fugue.com> In-Reply-To: <28533A06-2567-4090-A7AE-5BEA649C9857@fugue.com> --4Ac2KevdtF6XP0fk1XvUjFV9c5MTGlB0G Content-Type: multipart/alternative; boundary="------------ECCCC63C4A5F0D95CC732DB9" This is a multi-part message in MIME format. --------------ECCCC63C4A5F0D95CC732DB9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/7/17 9:59 AM, Ted Lemon wrote: > On Jan 7, 2017, at 10:19 AM, Eliot Lear > wrote: >> We don't encode passwords in the clear, for instance, because the >> probability of them being stolen approaches 1 over time. Whether the >> draft actually says that, quite frankly, is hard for me to determine. > > Well, actually, this general question was a matter of public debate > just a few months ago. Supposedly serious people came out on the > side of not encrypting the password. Of course, they claimed (and > perhaps believed) that that wasn't really what they were saying, but > that was really what they were saying. > I don't think this really changes the point. We don't encode passwords in the clear for *technical* reasons rather than political ones. Eliot --------------ECCCC63C4A5F0D95CC732DB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 1/7/17 9:59 AM, Ted Lemon wrote:
On Jan 7, 2017, at 10:19 AM, Eliot Lear <lear@cisco.com> wrote:
We don't encode passwords in the clear, for instance, because the probability of them being stolen approaches 1 over time.=C2=A0 Whether the draft actu= ally says that, quite frankly, is hard for me to determine.

Well, actually, this general question was a matter of public debate just a few months ago. =C2=A0 Supposedly serious= people came out on the side of not encrypting the password. =C2=A0= Of course, they claimed (and perhaps believed) that that wasn't really what they were saying, but that was really what they were saying.


I don't think this really changes the point.=C2=A0 We don't encode passwords in the clear for technical reasons rather than political ones.

Eliot
--------------ECCCC63C4A5F0D95CC732DB9-- --4Ac2KevdtF6XP0fk1XvUjFV9c5MTGlB0G-- --Gd30RtCa6M1W3oMkQorClGO8aBXSGirCb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYc8K9AAoJEIe2a0bZ0nozCJ4H/idwRm48Z3O6THdC34MLiDPn F4ysIJHJJXA0Oy7VEI/GycYpgJbLu+7RDnzbyO/XqVH+VEF3+HyxwOtqxjX6+1Id F+VMMPcE/JHZcSsX5o+bRq3HRvL0EMoCb8Qe1yYbicpPbtnpanqTJoudHRpRx4sw YY7J6DoFITmR1GGpaFkovihdPBqJP4Gf7iMEmpZLG7CzT9V50laTpKhfhKD0y4VU zZWtC+W21U0Gf0PiLCE8nAmAbGwhzNFgmjc6Tdybyh8oUc4iK6Cz7hmuQXDw3/FX 6GS/BgqRa6veALwFfSj3lFvVnnC7CDhsonCQSdBTo7wfVV0FQtnKi0AlwlCspGA= =ctrW -----END PGP SIGNATURE----- --Gd30RtCa6M1W3oMkQorClGO8aBXSGirCb-- From nobody Mon Jan 9 09:09:23 2017 Return-Path: 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 078CA1297C3 for ; Mon, 9 Jan 2017 09:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 4qjVYkgB9qwr for ; Mon, 9 Jan 2017 09:09:20 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 73F45129568 for ; Mon, 9 Jan 2017 09:09:20 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id l7so92630053qtd.1 for ; Mon, 09 Jan 2017 09:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VQX1jd6WRaRp45KwMCzN4dSCzvvNalgCaRjNkiAPDXo=; b=LFUGPVwxTsxv/pxKWqgrQqkznkilDisBWkvd2tYrJVCFju8ZYluJ5C8Tj/SOisNOaY 2UFtA76n0mi7rGiB5Q2DoPSBArrBJf3nkYtsmLwEO7vsXZe2ZN3nqfWHRf8lPfgWknM+ dUM70PSpWmX6wClKf1ENwJgZGOHy16zxoaJEHBMK/F9iOw7nFPsmsNe1qh3NwFHyB269 bDlUgXtsb2LIhXYlGFjA7GzUDXRKhU78g+jfWaRsAodK80wcPxlI4LOtypZwIHWdQrqR fM4V9h0ZQC6Os+cb3JIJhXd/ChUdDSKWVH6aek+FaJ7+PEBwxAmZ0hbPvrVjxWm0EXTc Mpzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VQX1jd6WRaRp45KwMCzN4dSCzvvNalgCaRjNkiAPDXo=; b=q64vQWczArn3/Fbs3cYHzil3kLxaBJ24AV06uSMObeSxA+QcKQ3WKM4z5/q7WML3yA zydEtiJRc8q7EqxGS9lFt6zaPATQAya8L95RvSXBxaOzk8yUptRM0lN1gPAq71h9zXbz NZ79L/IX1SKHI8rCDjaLTFchZjaDNVE8z4wyA0e60TpqrOIJKOcNAFFgR/EA7bsndKPM F4pKhCI2zJS3RBRf7PekWe93KBXtss2Jv4SUYFpLe7TrSuy1xxAyWr5U6RmvSAms7yJ6 EFKxpvVL10yKStchL6tZJJAfWSx+e5FmO94m1uIN4/FOjbc8JpxELIKNcz+vKCl1qgs8 9pgA== X-Gm-Message-State: AIkVDXLIeS8XNPtyk4DrsHB2rR48WKU/7MB3s7uSYKGQLbuVOY8kJWH00mket+IEinMZ9Q== X-Received: by 10.237.41.99 with SMTP id s90mr3762744qtd.4.1483981759491; Mon, 09 Jan 2017 09:09:19 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b16sm722157qka.9.2017.01.09.09.09.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 09:09:18 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3476652D-8A92-4799-B655-3805CC96A8C4" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 9 Jan 2017 12:09:17 -0500 In-Reply-To: To: Eliot Lear References: <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <93c6e7bc-95b9-10bc-5f49-f9ebd59e3aae@article19.org> <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> <28533A06-2567-4090-A7AE-5BEA649C9857@fugue.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: hrpc@irtf.org, Andrew Sullivan Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:09:22 -0000 --Apple-Mail=_3476652D-8A92-4799-B655-3805CC96A8C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 9, 2017, at 12:05 PM, Eliot Lear wrote: > I don't think this really changes the point. We don't encode = passwords in the clear for technical reasons rather than political ones. That's correct: our decision is not motivated by a political goal. = Nevertheless, our position on encoding passwords is an obstacle to a = political goal. Hence, our position is political. The fact that we = don't see it that way doesn't make it not true. That's the point being = made in the document. It may feel repugnant that a technical issue = could also be political, but nevertheless that is the reality.= --Apple-Mail=_3476652D-8A92-4799-B655-3805CC96A8C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 9, 2017, at 12:05 PM, Eliot Lear <lear@cisco.com> = wrote:
I don't think this = really changes the point.  We don't encode passwords in the clear = for technical reasons rather than = political ones.

That's = correct: our decision is not motivated by a political goal.   = Nevertheless, our position on encoding passwords is an obstacle to a = political goal.   Hence, our position is political.   The fact = that we don't see it that way doesn't make it not true.   That's = the point being made in the document.   It may feel repugnant that = a technical issue could also be political, but nevertheless that is the = reality.
= --Apple-Mail=_3476652D-8A92-4799-B655-3805CC96A8C4-- From nobody Mon Jan 9 13:46:59 2017 Return-Path: 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 864EB1297E4 for ; Mon, 9 Jan 2017 13:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=SXkivPT7; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=d7HnhSDz 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 xynlwbtYGr91 for ; Mon, 9 Jan 2017 13:46:55 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14CB12964C for ; Mon, 9 Jan 2017 13:46:54 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 61A9921D02; Mon, 9 Jan 2017 16:46:54 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 09 Jan 2017 16:46:54 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=YGEiko/9czV2OsJKikPdHCZVl30=; b=SXkivP T7fmPNGqu1kBs0Dti+FGl7B61MQb4Wk2z1rPasv/WWuCHV2BKEm9jLVNMSmOhJgr nYrtk3gU+0pWQgAyURDKQpYSD/rhBIeD5YIDFgUqAuUaCHxLTKY1NTWy+JKM3Fhh QvUo4UAG8ZI++wsC/MAKeVbFPpQyQ98+rqrvE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=YGEiko/9czV2Os JKikPdHCZVl30=; b=d7HnhSDzD9cU79oYNyVc4Ga/vi/uQfHmlBLVfa16rr8w99 O2/r0Pq3Nc6sOjZTf5QTIxAgNDHgG/GbcTzCc3vNaemLbn22JRYiVYygMkei5P4R CjDMCiPbav2fsTiATpge05c+F0uzzn68yoGaFNScxB83GqHXfNEd7XYU6ePQg= X-ME-Sender: X-Sasl-enc: tVqYcequKYxPJKKmLOr3kmDY9IQ6Oev/fW3cQpt8ojMk 1483998413 Received: from dhcp-10-150-9-143.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id E5D737E709; Mon, 9 Jan 2017 16:46:53 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_009DA2DB-4D46-4083-B3F6-012D988FA4F3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <72333205-0458-63d9-6d9e-3538266fec1d@article19.org> Date: Mon, 9 Jan 2017 16:46:53 -0500 Message-Id: References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <72333205-0458-63d9-6d9e-3538266fec1d@article19.org> To: Niels ten Oever X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:46:58 -0000 --Apple-Mail=_009DA2DB-4D46-4083-B3F6-012D988FA4F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Niels, Some comments inline. > On Jan 9, 2017, at 11:55 AM, Niels ten Oever = wrote: >=20 > Hi Alissa, >=20 > Thank you very much for this very thorough review. I made quite a few > changes based on this. All changes can be found here: >=20 > = https://github.com/nllz/IRTF-HRPC/commit/cb0a9788f9efd2050b7a1912fda8e823e= 4019ace >=20 > Please find my response and some questions inline (and sorry for the > delay in response): >=20 >=20 > On 01/05/2017 06:45 PM, Alissa Cooper wrote: >> Below is a review of draft-irtf-hrpc-research-07. I have not been >> involved in the RG so these comments are for what they're worth and I >> apologize if some of this ground has been trod before. This was an >> interesting read and most of my comments are provided with an eye >> towards making the document more useful/actionable in the IETF >> eventually, which I realize may not be a shared goal necessarily. >>=20 >> Substantive comments: >>=20 >> =3D Section 3.2.3 and 3.2.3.1 =3D >>=20 >> If the point of the IPv4 example is to demonstrate the human rights >> impacts -- both positive and negative -- of various protocol designs, >> I find the section to be narrow, slanted, and incomplete. It seems >> focused almost exclusively on the potential harms, which, for a >> protocol as fundamental to the operation of the Internet as IPv4, is >> not justified and renders this section somewhat useless IMO. >>=20 >> ... >>=20 >=20 > As outlined in a subthread by Stephane and Stephen, this part did not > aim to do an in-depth Human Rights Impact Analsysis of a single = protocol > but merely establish that there is a relationship between human rights > and protocols based on case studies. >=20 > I do hope one of the following hrpc drafts indeed can be the = development > of a model for a Human Rights Impact Assessment of protocols, and = maybe > even for of combinations of protocols (because that of course brings = in > different vectors). This will needs more research and experimentation > though. >=20 > I do agree that the cases are a mix of things (even though all have > related RFCs) but we exactly aimed at a mix of things so see what > different relations between protocols, standards and human rights = could > look like. If the section is specifically designed to present cases that cut across = protocols, implementations, and networking paradigms, it should say so = up front. The title and introduction to 3.2.3 indicate that the section = is about protocols. >=20 > I'm sorry to hear that you found the overall tone quite negative. > Therefore I added some extra positive text here: >=20 > = https://github.com/nllz/IRTF-HRPC/commit/76375bdbf93c1c63661824fbcb7c89b17= ecdb609 I think this helps, but what would be better would be specific text in = the intro to 3.2.3 that explains that the emphasis of the examples is on = adverse impacts to human rights. Perhaps even better would be to remove = the positive examples and just focus exclusively on the negative ones, = so it=E2=80=99s clear that the thrust of the entire section is to = provide negative examples. >=20 >=20 >> =3D Section 3.2.3.5.2 =3D >>=20 >> "Peer-to-Peer traffic (and BitTorrent in particular) represents a >> high percentage of global Internet traffic" >>=20 >> Is there a citation for this? My understanding is that by most >> measurements the share of p2p traffic is pretty low these days. >>=20 >=20 > This is the most recent stat I could find on this: >=20 > http://mashable.com/2014/05/14/file-sharing-decline/#FG_t.2P3Uaqf >=20 > https://www.rt.com/news/162744-p2p-file-sharing-increase/ >=20 If you=E2=80=99re comfortable citing Sandvine=E2=80=99s numbers as the = first article does then there are more recent ones to point to:=20 = https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-american-t= raffic-is-now-streaming-video-and-audio.html = https://www.sandvine.com/trends/global-internet-phenomena/ = Both of these challenge even a claim of =E2=80=9Csignificant=E2=80=9D = percentage, although no overall global number is given. In any event, = there should be a cite in the document. >=20 > Which indeed indicated it flattened out. So that's why I propose >=20 > s/high/significant >=20 >> =3D Section 4.1.1.1 =3D >>=20 >> Two overall comments about this section: >>=20 >> (1) The questionnaire seems like it took the kitchen sink approach. >> Many of the considerations covered here are already covered in other >> existing IETF documents. In a number of cases this document took >> specific items from those existing documents and broke them out into >> their own separate subsections with many detailed questions (e.g., >> privacy, anonymity, pseudonymity, confidentiality, integrity, >> reliability, authenticity). I think most protocol designers will find >> the sheer volume of questions here daunting and will find the >> redundancy both within the section and together with existing >> guidance documents reason enough to skip a human rights analysis >> altogether. I would recommend really trying to streamline this >> section down to the essence of the questions that protocol designers >> are not already asking themselves but should be. If you want to >> include a comprehensive mapping between the technical concepts and >> specific human rights, put that mapping in a different section and >> focus this section on the most important and actionable questions. >>=20 >=20 > Thanks for this suggestion. I do agree that there are double parts, = and > the parts that are doulbe, are also clearly referenced as such. What = we > tried to do is create a clear human rights lens to specific problems, > that's why I do not think the current parts are redundant. >=20 > Also: I think that providing a reason for people to look at those > documents increases that chance that they actually will, instead of = just > saying: have a look at this. I think we just disagree about this, which is fine. >=20 >> (2) I think it would be a lot clearer if the various subsections were >> explicit about where the recommendations here are different than >> recommendations in existing IETF documents and policies. For privacy, >> security, internationalization, and extensibility, the document mixes >> in references to existing guidance/policies with its own text and >> suggestions. If the suggestion is to just go read the other >> documents, a simple reference would do; otherwise, I think the >> document could be a lot clearer about where it is asking protocol >> designers to depart from or go beyond what the existing guidance >> requires. Other than drawing explicit links between the concepts and >> human rights affected, I think 4.1.1.1.2, .4, .9, .10, .14, .15, .16, >> and .17 could all be removed or replaced with simple pointers to >> existing documents (possibly also true for .5 and .12 but it=E2=80=99s = not my >> area of expertise). >=20 > The paragraphs that you outline above are already pointing to the = other > documents. The guidelines are not means to replace BCP72 or RFC6973, = but > provide another perspective for looking at protocols from a human = rights > perspective, Just to re-state the point: as someone who is quite familiar with the = content of a number of the referenced specs, it=E2=80=99s not clear to = me whether these sections are asking me to use a different set of = considerations from those specs or not. I suspect other readers would be = similarly confused. > and providing extra motivation for people to look at the > these standards, because many of them (Internationalization, etc) are > not as commonly use as we might like. >=20 >>=20 >> =3D Section 4.1.1.1.1 =3D >>=20 >> The example doesn't seem to be responsive to the question. The >> question is about requiring functionality at intermediaries whereas >> the example is about a design decision to prevent intermediaries from >> carrying out such functionality. >>=20 >=20 > The example shows that one can implement message encryption in = different > ways, right? But maybe I am misunderstanding your question. An instant messaging protocol might be designed such that intermediaries = can make use of application-specific functions. That same protocol might = support end-to-end encryption, or protocol designers might later design = enhancements to the protocol that facilitate end-to-end encryption (an = analogous example for real-time media would be PERC). Whether a protocol = allows for application-specific functions at intermediaries and whether = it supports end-to-end encryption can be mutually exclusive design = decisions.=20 >=20 >> =3D Section 4.1.1.1.3 =3D >>=20 >> "Question(s): If your protocol impacts packet handling, does it look=20= >> at the packet payload? Is it making decisions based on the payload=20= >> of the packet? Does your protocol prioritize certain content or=20 >> services over others in the routing process ? Is the protocol=20 >> transparent about the priotization that is made (if any)?" >>=20 >> I think this set of questions could benefit from some refinement, in >> particular in terms of the actor(s) being targeted. I don't quite >> understand the notion of a protocol itself "looking" at a payload or >> making a decision.=20 >=20 > s/looking at packet payload/use data from the packet payload >=20 >> I'm guessing this one is actually targeted at >> network intermediaries, as in 4.1.1.1.1, since the whole point of >> many protocols is for endpoints to take some action based on packet >> payloads. >>=20 >=20 > As well as protocols that might make use from packet payload data > instead of only using data from the header. Is the implication supposed to be that protocols that require endpoints = to take action based on payload data are somehow better for human rights = than those where endpoints are expected to take action solely based on = header data? I don=E2=80=99t understand why that would be. Also, the = distinction between payloads and headers is not clear, since a header at = one layer is a payload at the next layer. >=20 >=20 >> I also think the example in this section (and all the subsections of >> 4.1.1.1, actually) would be more useful if it cited a specific >> protocol that has the effect that the section raises concerns about, >> because it's hard to understand what is being implied here. That is, >> I'm not sure what the implications would be of the answers to these >> questions if applied to, say RFC 2474 and RFC 2475, because the >> implications all depend on the deployment context. >>=20 >=20 > I would be hesitant to target this at specific protocols, because that > might exclude other protocols for which this could be relevant as = well. > I think the first sentence already is kind of a pre-selection, right? I guess the label =E2=80=9CExample=E2=80=9D caused me to expect, well, = an example of how each consideration might apply to a specific protocol, = so that as a protocol designer I could learn the logic of how it might = apply to my protocol. But if the text under each =E2=80=9CExample=E2=80=9D= label isn=E2=80=99t really meant to provide an example, perhaps it = should be labeled some other way? >=20 >=20 >> =3D Section 4.1.1.1.6 =3D >>=20 >> "Question(s): Does this protocol introduce new identifiers or reuse=20= >> existing identifiers (e.g. MAC addresses) that might be associated=20= >> with persons or content? ... >>=20 >> Example: Identifiers of content exposed within a protocol might be=20 >> used to facilitate censorship, as in the case of IP based >> censorship, which affects protocols like HTTP." >>=20 >> I'm not sure how much mileage there is to be had out of this question >> and example, because most protocols use identifiers. I don't think >> this is a bad thing, it's just really hard to design a way to >> communicate between two endpoints about something without using >> identifiers of some sort. The question is phrased broadly enough that >> I think the answer will almost always be "yes" but I'm not sure to >> what end. >>=20 >=20 > Re-using identifiers might be a bad thing for de-anonymization, and if > something can be implemented stateless, it might also be better for > privacy, right? I don=E2=80=99t think it=E2=80=99s accurate to make those claims = generically. My SDP implementation might re-use SSRCs with no impact one = way or another on anonymity. And using identifiers doesn=E2=80=99t = necessarily imply any state is being maintained. If you could add a few = examples of protocols that exchange content without using identifiers, I = think I would be more convinced that the generic question about content = identifiers has utility. >=20 > I think the last two questions in this para are key for providing > perspective: >=20 > Can your protocol contribute to filtering in a way it could be > implemented to censor data or services? Could this be designed to = ensure > this doesn't happen? >=20 > I also think the example provides quite some framing which also shows > the boundaries of this question. I don=E2=80=99t really understand the example TBH. It talks about = filtering based on IP address but then cites HTTP 451, whose use might = have nothing to do with IP-based filtering. >=20 >> =3D Section 4.1.1.1.7 =3D >>=20 >> This section is concerning because it seems to be trying to >> re-interpret or change existing IETF policies, which seems >> inappropriate even for an informational IRTF document. For example, >> this bit in particular caught my eye: >>=20 >> "All standards that need to be normatively implemented should be=20 >> freely available and with reasonable protection for patent=20 >> infringement claims, so it can also be implemented in open source or=20= >> free software." >>=20 >> As nice as it would be if this were always true, it's not, and it's >> not likely going to be any time in the foreseeable future for the >> 8000+ specifications the IETF has produced.=20 >=20 > How is this not in-line with BCP78 ? I think this is exactly what = BCP78 > says, the standards are available freely by the IETF. If you can find the text in BCP 78 that says the above, please cite it. = We standardize protocols that normatively rely on specifications = produced by other SDOs that are not freely available, even though it=E2=80= =99s not ideal. The most recent one I can remember the IESG approving is = https://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-10 = >=20 >> Many of the reasons for >> that are outside the control of IETF participants. So I find it >> unhelpful to suggest these as requirements. I also don't think BCP 78 >> and 79 and the note well should be further elaborated in a document >> such as this one; even as informational people can get confused. >>=20 >> I would suggest deleting this section as there is a high potential >> for confusion and I'm not sure that it provides much countervailing >> benefit. >>=20 >> Also, I don't understand how the example relates to the rest of the >> section or why the emphasis on DPI is there. >>=20 >=20 >>=20 >> =3D Section 4.1.1.1.11 =3D >>=20 >> I think combining access for those with disabilities and access for >> those with poor connectivity under a single heading is confusing. >> These imply some rather disparate design decisions, not all of which >> will apply to all protocols nor in the same ways. >>=20 >=20 > I agree, I guess the problem lies in the word 'accessibility'. That is > why we're offering different definitions for that in the glossary as > well. Any suggestion on how we might improve this? Split these into separate sections with separate considerations for = each. >=20 >> =3D Section 2 =3D >>=20 >> There are two different definitions offered for "Connectivity." >>=20 >=20 > You mean this? >=20 > : The extent to which a device or network is able to reach other = devices > or networks to exchange data. The Internet is the tool for providing > global connectivity {{RFC1958}}. > Different types of connectivity are further specified in {{RFC4084}}. >=20 That is one of the definitions given. The other definition is at the end = of the section: Connectivity The combination of the end-to-end principle, interoperability, resilience, reliability and robustness are the enableing factors that result in connectivity to and on the Internet. Thanks, Alissa --Apple-Mail=_009DA2DB-4D46-4083-B3F6-012D988FA4F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Niels,

Some comments inline.

On = Jan 9, 2017, at 11:55 AM, Niels ten Oever <niels@article19.org>= wrote:

Hi Alissa,

Thank you very much = for this very thorough review. I made quite a few
changes = based on this. All changes can be found here:

https://github.com/nllz/IRTF-HRPC/commit/cb0a9788f9efd2050b7a19= 12fda8e823e4019ace

Please find my = response and some questions inline (and sorry for the
delay = in response):


On 01/05/2017 = 06:45 PM, Alissa Cooper wrote:
Below is a review of draft-irtf-hrpc-research-07. I have not = been
involved in the RG so these comments are for what = they're worth and I
apologize if some of this ground has = been trod before. This was an
interesting read and most of = my comments are provided with an eye
towards making the = document more useful/actionable in the IETF
eventually, = which I realize may not be a shared goal necessarily.

Substantive comments:

=3D = Section 3.2.3 and 3.2.3.1 =3D

If the point = of the IPv4 example is to demonstrate the human rights
impacts -- both positive and negative -- of various protocol = designs,
I find the section to be narrow, slanted, and = incomplete. It seems
focused almost exclusively on the = potential harms, which, for a
protocol as fundamental to = the operation of the Internet as IPv4, is
not justified = and renders this section somewhat useless IMO.

...


As= outlined in a subthread by Stephane and Stephen, this part did not
aim to do an in-depth Human Rights Impact Analsysis of a = single protocol
but merely establish that there is a = relationship between human rights
and protocols based on = case studies.

I do hope one of the = following hrpc drafts indeed can be the development
of a = model for a Human Rights Impact Assessment of protocols, and maybe
even for of combinations of protocols (because that of course = brings in
different vectors). This will needs more = research and experimentation
though.

I do agree that the cases are a mix of things (even though = all have
related RFCs)  but we exactly aimed at a mix = of things so see what
different relations between = protocols, standards and human rights could
look like.

If = the section is specifically designed to present cases that cut across = protocols, implementations, and networking paradigms, it should say so = up front. The title and introduction to 3.2.3 indicate that the section = is about protocols.


I'm sorry to = hear that you found the overall tone quite negative.
Therefore I added some extra positive text here:

https://github.com/nllz/IRTF-HRPC/commit/76375bdbf93c1c63661824= fbcb7c89b17ecdb609

I think this helps, but what would be better would = be specific text in the intro to 3.2.3 that explains that the emphasis = of the examples is on adverse impacts to human rights. Perhaps even = better would be to remove the positive examples and just focus = exclusively on the negative ones, so it=E2=80=99s clear that the thrust = of the entire section is to provide negative examples.



=3D Section 3.2.3.5.2 =3D

"Peer-to-Peer traffic (and BitTorrent in particular) = represents a
high percentage of global Internet = traffic"

Is there a citation for this? My = understanding is that by most
measurements the share of = p2p traffic is pretty low these days.


This is the most recent stat I = could find on this:

http://mashable.com/2014/05/14/file-sharing-decline/#FG_t.2P3Ua= qf

https://www.rt.com/news/162744-p2p-file-sharing-increase/


If you=E2=80=99re comfortable citing Sandvine=E2=80=99= s numbers as the first article does then there are more recent ones to = point to: 
https://www.sandvine.com/trends/global-internet-phenomena/<= /div>

Both of these challenge even a claim = of =E2=80=9Csignificant=E2=80=9D percentage, although no overall global = number is given. In any event, there should be a cite in the = document.


Which indeed indicated it = flattened out. So that's why I propose

s/high/significant

=3D Section 4.1.1.1 =3D

Two overall comments about this section:

(1) The questionnaire seems like it took the kitchen sink = approach.
Many of the considerations covered here are = already covered in other
existing IETF documents. In a = number of cases this document took
specific items from = those existing documents and broke them out into
their own = separate subsections with many detailed questions (e.g.,
privacy, anonymity, pseudonymity, confidentiality, = integrity,
reliability, authenticity). I think most = protocol designers will find
the sheer volume of questions = here daunting and will find the
redundancy both within the = section and together with existing
guidance documents = reason enough to skip a human rights analysis
altogether. = I would recommend really trying to streamline this
section = down to the essence of the questions that protocol designers
are not already asking themselves but should be. If you want = to
include a comprehensive mapping between the technical = concepts and
specific human rights, put that mapping in a = different section and
focus this section on the most = important and actionable questions.


Thanks for this suggestion. I do = agree that there are double parts, and
the parts that are = doulbe, are also clearly referenced as such. What we
tried = to do is create a clear human rights lens to specific problems,
that's why I  do not think the current parts are = redundant.

Also: I think that providing a = reason for people to look at those
documents increases = that chance that they actually will, instead of just
saying:= have a look at this.

I think we just disagree about this, which is = fine.


(2) I think it would be a lot clearer if the various = subsections were
explicit about where the recommendations = here are different than
recommendations in existing IETF = documents and policies. For privacy,
security, = internationalization, and extensibility, the document mixes
in references to existing guidance/policies with its own text = and
suggestions. If the suggestion is to just go read the = other
documents, a simple reference would do; otherwise, I = think the
document could be a lot clearer about where it = is asking protocol
designers to depart from or go beyond = what the existing guidance
requires. Other than drawing = explicit links between the concepts and
human rights = affected, I think 4.1.1.1.2, .4, .9, .10, .14, .15, .16,
and= .17 could all be removed or replaced with simple pointers to
existing documents (possibly also true for .5 and .12 but = it=E2=80=99s not my
area of expertise).

The paragraphs that you outline = above are already pointing to the other
documents. The = guidelines are not means to replace BCP72 or RFC6973, but
provide another perspective for looking at protocols from a = human rights
perspective, =

Just to re-state = the point: as someone who is quite familiar with the content of a number = of the referenced specs, it=E2=80=99s not clear to me whether these = sections are asking me to use a different set of considerations from = those specs or not. I suspect other readers would be similarly = confused.

and providing extra motivation for people to = look at the
these standards, because many of them = (Internationalization, etc) are
not as commonly use as we = might like.


=3D Section 4.1.1.1.1 =3D

The example doesn't seem to be responsive to the question. = The
question is about requiring functionality at = intermediaries whereas
the example is about a design = decision to prevent intermediaries from
carrying out such = functionality.


The example shows that one can implement message encryption = in different
ways, right? But maybe I am misunderstanding = your question.

An instant messaging protocol might be designed = such that intermediaries can make use of application-specific functions. = That same protocol might support end-to-end encryption, or protocol = designers might later design enhancements to the protocol that = facilitate end-to-end encryption (an analogous example for real-time = media would be PERC). Whether a protocol allows for application-specific = functions at intermediaries and whether it supports end-to-end = encryption can be mutually exclusive design decisions. 


=3D = Section 4.1.1.1.3 =3D

"Question(s): If your = protocol impacts packet handling, does it look
at the = packet payload?  Is it making decisions based on the payload
of the packet?  Does your protocol prioritize certain = content or
services over others in the routing process ? = Is the protocol
transparent about the priotization that = is made (if any)?"

I think this set of = questions could benefit from some refinement, in
particular = in terms of the actor(s) being targeted. I don't quite
understand the notion of a protocol itself "looking" at a = payload or
making a decision.

s/looking at packet payload/use = data from the packet payload

I'm guessing this one is actually targeted = at
network intermediaries, as in 4.1.1.1.1, since the = whole point of
many protocols is for endpoints to take = some action based on packet
payloads.


As well as protocols that might = make use from packet payload data
instead of only using = data from the header.

Is the implication supposed to be that protocols = that require endpoints to take action based on payload data are somehow = better for human rights than those where endpoints are expected to take = action solely based on header data? I don=E2=80=99t understand why that = would be. Also, the distinction between payloads and headers is not = clear, since a header at one layer is a payload at the next = layer.



I also think the example in this section (and = all the subsections of
4.1.1.1, actually) would be more = useful if it cited a specific
protocol that has the effect = that the section raises concerns about,
because it's hard = to understand what is being implied here. That is,
I'm not = sure what the implications would be of the answers to these
questions if applied to, say RFC 2474 and RFC 2475, because = the
implications all depend on the deployment context.


I would be = hesitant to target this at specific protocols, because that
might exclude other protocols for which this could be = relevant as well.
I think the first sentence already is = kind of a pre-selection, right?

I = guess the label =E2=80=9CExample=E2=80=9D caused me to expect, well, an = example of how each consideration might apply to a specific protocol, so = that as a protocol designer I could learn the logic of how it might = apply to my protocol. But if the text under each =E2=80=9CExample=E2=80=9D= label isn=E2=80=99t really meant to provide an example, perhaps it = should be labeled some other way?



=3D = Section 4.1.1.1.6 =3D

"Question(s): Does = this protocol introduce new identifiers or reuse
existing = identifiers (e.g.  MAC addresses) that might be associated
with persons or content?  ...

Example: Identifiers of content exposed within a protocol = might be
used to facilitate censorship, as in the case of = IP based
censorship, which affects protocols like = HTTP."

I'm not sure how much mileage there = is to be had out of this question
and example, because = most protocols use identifiers. I don't think
this is a = bad thing, it's just really hard to design a way to
communicate between two endpoints about something without = using
identifiers of some sort. The question is phrased = broadly enough that
I think the answer will almost always = be "yes" but I'm not sure to
what end.


Re-using identifiers might be a = bad thing for de-anonymization, and if
something can be = implemented stateless, it might also be better for
privacy, = right?

I don=E2=80=99t think it=E2=80=99s accurate to = make those claims generically. My SDP implementation might re-use SSRCs = with no impact one way or another on anonymity. And using identifiers = doesn=E2=80=99t necessarily imply any state is being maintained. If you = could add a few examples of protocols that exchange content without = using identifiers, I think I would be more convinced that the generic = question about content identifiers has utility.


I think the last two questions in this para = are key for providing
perspective:

Can your protocol contribute to filtering in a way it could = be
implemented to censor data or services? Could this be = designed to ensure
this doesn't happen?

I also think the example provides quite some framing which = also shows
the boundaries of this question.

I = don=E2=80=99t really understand the example TBH. It talks about = filtering based on IP address but then cites HTTP 451, whose use might = have nothing to do with IP-based filtering.


=3D = Section 4.1.1.1.7 =3D

This section is = concerning because it seems to be trying to
re-interpret = or change existing IETF policies, which seems
inappropriate = even for an informational IRTF document. For example,
this = bit in particular caught my eye:

"All = standards that need to be normatively implemented should be
freely available and with reasonable protection for patent =
infringement claims, so it can also be implemented in = open source or
free software."

As nice as it would be if this were always true, it's not, = and it's
not likely going to be any time in the = foreseeable future for the
8000+ specifications the IETF = has produced.

How is this not = in-line with BCP78 ? I think this is exactly what BCP78
says, the standards are available freely by the IETF.

If = you can find the text in BCP 78 that says the above, please cite it. We = standardize protocols that normatively rely on specifications produced = by other SDOs that are not freely available, even though it=E2=80=99s = not ideal. The most recent one I can remember the IESG approving = is https://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-10

Many of the reasons for
that are outside the = control of IETF participants. So I find it
unhelpful to = suggest these as requirements. I also don't think BCP 78
and= 79 and the note well should be further elaborated in a document
such as this one; even as informational people can get = confused.

I would suggest deleting this = section as there is a high potential
for confusion and I'm = not sure that it provides much countervailing
benefit.

Also, I don't understand how the example = relates to the rest of the
section or why the emphasis on = DPI is there.



=3D = Section 4.1.1.1.11 =3D

I think combining = access for those with disabilities and access for
those = with poor connectivity under a single heading is confusing.
These imply some rather disparate design decisions, not all = of which
will apply to all protocols nor in the same = ways.


I agree, = I guess the problem lies in the word 'accessibility'. That is
why we're offering different definitions for that in the = glossary as
well. Any suggestion on how we might improve = this?

Split these into separate sections with separate = considerations for each.


=3D Section 2 =3D

There are two different definitions offered for = "Connectivity."


You mean this?

: The extent to = which a device or network is able to reach other devices
or = networks to exchange data. The Internet is the tool for providing
global connectivity {{RFC1958}}.
Different = types of connectivity are further specified in {{RFC4084}}.


That is one of the definitions given. The other = definition is at the end of the section:

Connectivity  The combination of the = end-to-end principle,
      interoperability, = resilience, reliability and robustness are the
    =   enableing factors that result in connectivity to and on = the
      Internet.

Thanks,
Alissa


= --Apple-Mail=_009DA2DB-4D46-4083-B3F6-012D988FA4F3-- From nobody Mon Jan 9 15:22:16 2017 Return-Path: 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 5E4A412997C for ; Mon, 9 Jan 2017 15:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0Ihu7G2OtQrW for ; Mon, 9 Jan 2017 15:22:13 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id F073C12997A for ; Mon, 9 Jan 2017 15:22:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 3024A11515 for ; Mon, 9 Jan 2017 23:22:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcVLbZGZ5v_l for ; Mon, 9 Jan 2017 23:22:18 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 761BC114EE for ; Mon, 9 Jan 2017 23:22:18 +0000 (UTC) Date: Mon, 9 Jan 2017 18:22:09 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170109232209.GC1426@mx2.yitter.info> References: <46ea18e7-37a4-6c2e-6c37-1789c13e7c8d@cs.tcd.ie> <22bafc03-6b7f-09aa-9161-5a041ca12c43@cs.tcd.ie> <83f74da6-0f72-0369-d35d-b98c7d625943@article19.org> <20170106183332.GA24054@mx2.yitter.info> <28533A06-2567-4090-A7AE-5BEA649C9857@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 23:22:14 -0000 On Mon, Jan 09, 2017 at 12:09:17PM -0500, Ted Lemon wrote: > Nevertheless, our position on encoding passwords is an obstacle to > a political goal. Hence, our position is political. The fact that > we don't see it that way doesn't make it not true. That's the point > being made in the document. It may feel repugnant that a technical > issue could also be political, but nevertheless that is the reality. I think this rides right over a distinction that is important, and that I think _is_ sometimes made in the draft. Some things are constraints on the political without themselves being political, unless one casts the term "political" very widely. The value of π, for instance, despite once having been the obstacle to someone's political goal, is not itself a political thing. The emissions of carbon and contamination of water as a result of extraction of bituminous sands in Canada are not political things, even though those raw facts are used in various political discussions and stand in the way of some people's preferred policy outcome. Now, if one adopts certain views about the nature of truth, one _might_ decide that these are political anyway. So, some say, since only propositions are true and since all propositions are in language and since all languages happen in a socio-linguistic context, then all truth is socio-linguistically bound. And if one adopts certain views about the nature of socio-linguistic situations, then all such socio-linguistic interactions are inherently political. There is a thread starting roughly with Wittgenstein leading through Rorty that can be read this way. There is almost certainly a reasonable reading of Derrida that sounds like this. There is an extremely reasonable reading of Michel Foucault along these lines. And some people think that the social constructivist interpration of science (so, say, Bruno Latour and Andrew Pickering and _maybe_ Donna Haraway) says this too. However much I believe those views, it is very far from obvious to me that such an interpretation of "facts" or "truth" would be widely shared around the IETF. If one is going to rely on such a view then I think it's going to need a fairly serious airing of the arguments in favour of it. The draft has been altered, I think, to get away from this problem a little bit, so I think this is less of a problem for the draft as it stands now. But I don't want to allow the conflation of these two issues to stand anyway. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jan 9 16:35:22 2017 Return-Path: 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 831CF1295D0 for ; Mon, 9 Jan 2017 16:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 qmBxAicTDYJ2 for ; Mon, 9 Jan 2017 16:35:19 -0800 (PST) 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 2418B12946B for ; Mon, 9 Jan 2017 16:35:18 -0800 (PST) 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 1cQkPC-0007bP-CT; Tue, 10 Jan 2017 01:35:14 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 1E669B00453; Tue, 10 Jan 2017 01:35:14 +0100 (CET) To: avri@acm.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> Date: Tue, 10 Jan 2017 01:35:13 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 In-Reply-To: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> 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 1484008514. Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 00:35:21 -0000 Hi Avri and all, On 04.12.2016 at 20:54 avri doria wrote: > Please send all comment to the HRPC email list: hrpc@irtf.org. I do > hope that some good discussions occur on this list where the > resolution to any issues may be forged. Discussion has been shown to > improve this draft. Unfortunately, I didn't manage the full review write-up after returning from holidays today. Nevertheless, I have some general comments and try to provide more detailed comments later today. Overall, I think the draft is good to raise awareness for the issue that sometimes technical decisions may impact human rights. However, it falls a bit short on the problem that even human rights get in conflict with each other and that conflict resolution is hard to decide on, or is maybe not possible or desirable to built into a technical system (because it's too rigid then). For example, considering anonymity and authenticity at the same time is not easy (cf. the APIP design http://dl.acm.org/citation.cfm?id=2626306). Sometimes it may be better to refrain from embedding technical solutions (i.e., specification and operationalization) and think of institutionalization, i.e., considering solutions based on policy/governance or choice and markets. Technical support for such solutions can sometimes be beneficial (e.g., providing transparency solutions). More details here: http://dl.acm.org/citation.cfm?doid=2935634.2935640 or slides for the impatient: http://conferences.sigcomm.org/sigcomm/2016/files/program/sigcomm/SessionCCR-Paper02-Values-Carsten-Slides.pdf There are some inaccuracies with the vocabulary section and I have several comments for section 4. I'll come back to that later in more detail. Best regards, Roland From nobody Tue Jan 10 02:07:01 2017 Return-Path: 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 4310D1296A7 for ; Tue, 10 Jan 2017 02:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.989 X-Spam-Level: X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=yTCHQQ3l; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=HqqVYLLF 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 t4rcqxNIvYjA for ; Tue, 10 Jan 2017 02:06:58 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB821293DB for ; Tue, 10 Jan 2017 02:06:58 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0AA6hTY025183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2017 02:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484042811; x=1484129211; bh=P7SYbpdyL+abI2Jp9t64UeQnCLSjehQoz9VDVWX+5ng=; h=Date:To:From:Subject; b=yTCHQQ3l04yJPu1I94onYLBOSri4oC2Z5hr265Smd+XHdmP1E0Q5RzpMXVdO30dCp fABfsH3h2BJJYnzrjx+SozKmwCmne/Spy/OZ0GC+dZfX6ciD6wz1I7108JhRUJ1z0U zDGpMbImbVEw5wt4We4RfuDsGwe9Ltrojehm5DrM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484042811; x=1484129211; i=@elandsys.com; bh=P7SYbpdyL+abI2Jp9t64UeQnCLSjehQoz9VDVWX+5ng=; h=Date:To:From:Subject; b=HqqVYLLF7uE0CmTuTVSBUK6dg6VJyJaDW5eD8EpANiwu9mLwzim256TGGLuhxTLLv ldpZPCbv9Y2a6qkF05XglG8+BpWqbl4JA8xMJXaOWa8U594kxxTyYhwg0DugiodkJk HtT4kxDIK5Zr3fmLy2F2MzGTEVlhVH4YpX4/ko18= Message-Id: <6.2.5.6.2.20170110011236.0be8f348@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jan 2017 02:04:12 -0800 To: Niels ten Oever , hrpc@irtf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:07:00 -0000 Hi Niels, >Because the literature shows different positions on the 'societal impact >of protocols'. It shows how technology performs more than a merely >'technical function'. If I understood the above correctly, what you are saying is that "technical standards" are not neutral. For example, the technical standard(s) may directly or indirectly give a country or entities in a country an economic or political advantage, sometimes, at the expense of other countries. That is the central thesis of one of the books cited in the draft. It is also being argued that public policy is part of all this, i.e. it is not a technical function if public policy is included. There are research papers in which all this is discussed from a "standards-setting" perspective. Regards, S. Moonesamy From nobody Tue Jan 10 02:22:26 2017 Return-Path: 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 0471A129BA9 for ; Tue, 10 Jan 2017 02:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 6ypUpA1OLE8c for ; Tue, 10 Jan 2017 02:22:22 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 637B4129BA5 for ; Tue, 10 Jan 2017 02:22:21 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cQtZL-0005CF-CF for hrpc@irtf.org; Tue, 10 Jan 2017 11:22:19 +0100 To: hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> From: Niels ten Oever Message-ID: <1bc65daf-42ec-4836-61d4-a5fa0ece0062@article19.org> Date: Tue, 10 Jan 2017 11:22:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u4PCh2hGmBfQiGF2PpKEGCKEEbRhAHpQa" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 1cc067c3b15672d9939cf417dd12a4d6 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:22:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u4PCh2hGmBfQiGF2PpKEGCKEEbRhAHpQa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roland, Thanks for this. Reply inline: Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 On 01/10/2017 01:35 AM, Roland Bless wrote: > Hi Avri and all, >=20 > On 04.12.2016 at 20:54 avri doria wrote: >> Please send all comment to the HRPC email list: hrpc@irtf.org. I do >> hope that some good discussions occur on this list where the >> resolution to any issues may be forged. Discussion has been shown to >> improve this draft. >=20 > Unfortunately, I didn't manage the full review write-up after returning= > from holidays today. Nevertheless, I have some general comments and try= > to provide more detailed comments later today. >=20 > Overall, I think the draft is good to raise awareness for > the issue that sometimes technical decisions may impact human rights. > However, it falls a bit short on the problem that even human rights > get in conflict with each other and that conflict resolution is > hard to decide on, This section aims to address that: Human rights can be in conflict with each other, such as the right to freedom of expression and the right to privacy. In such as case the different affected rights need to be balanced. In order to do this it is crucial that the rights impacts are clearly documented in order to mitigate the potential harm in a proportional way. Making that process tangible and practical for protocol developers is what this research aims to ultimately contribute to. Technology can never be fully equated with a human right. Whereas a specific technology might be strong enabler of a specific human right, it might have an adverse impact on another human right. In this case decisions on design and deployment need to take this into account. You think this is inadequeate? If so, would you have text suggestions? or is maybe not possible or desirable to built > into a technical system (because it's too rigid then). This sections aims to address this: ur position is that hard-coding human rights into protocols is complicated and changes with the context. At this point is difficult to say whether hard-coding human rights into protocols is wise or feasible. It is however important to make conscious and explicit design decisions that take into account the human rights protocol considerations guidelines developed above. This will ensure that the impact protocols can have on human rights is clear and explicit, both for developers and for users. In addition, it ensures that the impact of specific protocol on human rights is carefully considered and that concrete design decisions are documented in the protocol. You think this is inadequeate? If so, would you have text suggestions? > For example, considering anonymity and authenticity at the same time is= > not easy (cf. the APIP design > http://dl.acm.org/citation.cfm?id=3D2626306). Sometimes it may be bette= r > to refrain from > embedding technical solutions (i.e., specification and > operationalization) and think of institutionalization, i.e., > considering solutions based on policy/governance or choice and markets.= > Technical support for such solutions can sometimes be beneficial (e.g.,= > providing transparency solutions). More details here: > http://dl.acm.org/citation.cfm?doid=3D2935634.2935640 > or slides for the impatient: > http://conferences.sigcomm.org/sigcomm/2016/files/program/sigcomm/Sessi= onCCR-Paper02-Values-Carsten-Slides.pdf >=20 Do you think this is a sufficient representation of your positions? Bless and Orwat [Bless] represent a fourth position. They argue that it is too early to make any definitive claims, but that there is a need for more careful analysis of the impact of protocol design choices on human rights. They also argue that it is important to search for solutions that 'create awareness in the technical community about impact of design choices on social values. And work towards a methodology for co-design of technical and institutional systems.' I'd me more than happy to have a bit more elaborate description. > There are some inaccuracies with the vocabulary section and I have > several comments for section 4. I'll come back to that later in more de= tail. >=20 Looking forward! Thanks, Niels > Best regards, > Roland >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --u4PCh2hGmBfQiGF2PpKEGCKEEbRhAHpQa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYdLXZAAoJEA7YPzpGisizhTAP/3jk+6JLrfyLOn2u64LoKG0e FYzSPLVZmQkEg0RFeBj6SBm1Vdpd+PR0k4WUtWVqCB5/H8C7J5A3I3tG9Va6X5hW k7eUZ/6vhVWGRuzkN1QVpUjYyOGK70gdaeMFe7HY2S9+XFc/KoWV+4i0Mq+fxhqT +/fu9GkwiKSuh8LUUxVn6MbiJh8btyzIRe1rgpYSxF0gnCcSzWmIByWunn2MqPSF 9N0gqLE/uTcJc2I1dQZVTAcy8IyD1Q0RLqvmDNAJV5aGu94DsdGzjEe4YKp4zTvO 7qtjD/e9k2jGkL0IZ0oWeD225fcSG+5RvYymSh1k191kZwZRf9CYC66ncEE765UE 4duhXTQRVggJhG0PuLP9UZiNglFzT86zhBbfAF7dHz9Aywo/hVNjDtevy2L03Lb9 sFQazkHkmfPXJU2m7Y5upyHefSfbrVMIJOYqiQXPsHdOEc2cgncmenLWoOsOWN9Q TaHBPdjtKkcpBttlgdMyleiSRos3VIY+qsKxEAGVgYSCrDRN8cnZS8KXSeBN3CLx D6Ojfni5h2hVMuy6vowoQMEvSiPQfQnZhp2kUGpnULkOv5lGd/+bZOABOiRAvEE2 BiPa+tThVy9otx9PTg+/GuhRcl5mLY9xWKeZ/Onv9Nm4I1aELv3HRPZbQywVKK7Z R91EiHDcr3hEVvuiJS1o =G44T -----END PGP SIGNATURE----- --u4PCh2hGmBfQiGF2PpKEGCKEEbRhAHpQa-- From nobody Tue Jan 10 03:11:20 2017 Return-Path: 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 ED4691299FA for ; Tue, 10 Jan 2017 03:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 syD4gqJx46PC for ; Tue, 10 Jan 2017 03:11:17 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 D030C127A91 for ; Tue, 10 Jan 2017 03:11:16 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E1C10280136 for ; Tue, 10 Jan 2017 12:11:14 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id DBB6B2800B3 for ; Tue, 10 Jan 2017 12:11:14 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id D8A54B38003 for ; Tue, 10 Jan 2017 12:10:44 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id CCB45431E0; Tue, 10 Jan 2017 12:10:44 +0100 (CET) Date: Tue, 10 Jan 2017 12:10:44 +0100 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20170110111044.tyfvvt3sx7ssfg42@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="osr7p6ggdfpcvfqq" Content-Disposition: inline X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.7.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Subject: [hrpc] draft-hall-censorship-tech expired X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 11:11:19 -0000 --osr7p6ggdfpcvfqq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline At the Seoul face-to-face meeting, someone (Stephen Farrell, I believe), said that this important Internet-Draft would be publsihed outside of the HRPC RG, as an individual publication. But now it expired :-( [Such a document ages quite quickly. Publishing it in one or two years would probably be useless.] --osr7p6ggdfpcvfqq Content-Type: message/rfc822 Content-Disposition: inline Return-Path: ietf-secretariat-reply@ietf.org Received: from hebe.prod-int.prive.th3.nic.fr [10.1.81.80] by b12.tech.prive.nic.fr with IMAP (fetchmail-6.3.26) for (single-drop); Mon, 09 Jan 2017 09:08:26 +0100 (CET) Received: from hebe.prod-int.prive.th3.nic.fr (LHLO zimbra.afnic.fr) (10.1.81.80) by zimbra.afnic.fr with LMTP; Mon, 9 Jan 2017 09:07:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id 15E3A10C401C for ; Mon, 9 Jan 2017 09:07:11 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham autolearn_force=no Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id hTsL1y9RpzgX for ; Mon, 9 Jan 2017 09:07:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id 4F3F310C401B for ; Mon, 9 Jan 2017 09:07:10 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.afnic.fr Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q3HF4pfD1R1U for ; Mon, 9 Jan 2017 09:07:10 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by zimbra.afnic.fr (Postfix) with ESMTP id 161B710C401A for ; Mon, 9 Jan 2017 09:07:10 +0100 (CET) Received: by relay1.nic.fr (Postfix) id 1384A4C002C; Mon, 9 Jan 2017 09:07:10 +0100 (CET) Delivered-To: bortzmeyer+ietf@nic.fr Received: from mx5.nic.fr (mx5.nic.fr [IPv6:2001:67c:2218:2::4:13]) by relay1.nic.fr (Postfix) with ESMTP id 131094C002B for ; Mon, 9 Jan 2017 09:07:10 +0100 (CET) Received: from mx5.nic.fr (localhost [127.0.0.1]) by mx5.nic.fr (Postfix) with SMTP id 117F93002B1 for ; Mon, 9 Jan 2017 09:07:10 +0100 (CET) Received: by mx5.nic.fr (Postfix, from userid 1137) id EEC483002FD; Mon, 9 Jan 2017 09:07:09 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx5.nic.fr (Postfix) with ESMTPS id C23EE3002B1 for ; Mon, 9 Jan 2017 09:07:09 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9149B129BBD for ; Mon, 9 Jan 2017 00:07:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Old-From: IETF Secretariat To: Old-Subject: Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes to draft-hall-censorship-tech X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148394922859.32546.15176213110480231932.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 00:07:08 -0800 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.9.80015 X-PerlMx-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODYTEXTP_SIZE_400_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, SINGLE_URI_IN_BODY 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_SUBJ_A 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __NO_HTML_TAG_RAW 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_END 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0' X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Subject: Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes to draft-hall-censorship-tech From: IETF Secretariat Hello, This is a notification from the Personal ID list of bortzmeyer+ietf@nic.fr. Document: draft-hall-censorship-tech, https://datatracker.ietf.org/doc/draft-hall-censorship-tech/ Change: Document has expired Best regards, The Datatracker draft tracking service (for the IETF Secretariat) --osr7p6ggdfpcvfqq-- From nobody Tue Jan 10 03:45:24 2017 Return-Path: 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 05AD5129BC2 for ; Tue, 10 Jan 2017 03:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 BTnW1GZ47r3V for ; Tue, 10 Jan 2017 03:45:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B16129BB2 for ; Tue, 10 Jan 2017 03:45:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7BA05BE58; Tue, 10 Jan 2017 11:45:19 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbZ-prIh3qoB; Tue, 10 Jan 2017 11:45:19 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E0933BE53; Tue, 10 Jan 2017 11:45:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484048719; bh=RZ4vqXflOsmJZHadmoNvHIlkBsYk0VU0MqUw1/Vuf68=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NGlaEkJt1rCkNXHg4wTpnHmRq9sQTmfteJ5JdimQ9CDpPXh6T4Q2apL1v2TjmJxN0 e5THSBgTFD5p3jfcBKb2Jc/EXxH6C2cIq8M9fBxfeTrkCvVJjKGpYChx+vSPlSLwLg 8fp1uLWM3VkHEZtzg/pYpKNVy6tcOspIrnaXD8Fw= To: Stephane Bortzmeyer , hrpc@irtf.org References: <20170110111044.tyfvvt3sx7ssfg42@nic.fr> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <65044640-8c6a-15b8-9e8c-3233b9be6783@cs.tcd.ie> Date: Tue, 10 Jan 2017 11:45:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170110111044.tyfvvt3sx7ssfg42@nic.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020501080203060703040500" Archived-At: Subject: Re: [hrpc] draft-hall-censorship-tech expired X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 11:45:23 -0000 This is a cryptographically signed message in MIME format. --------------ms020501080203060703040500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 10/01/17 11:10, Stephane Bortzmeyer wrote: > At the Seoul face-to-face meeting, someone (Stephen Farrell, I > believe), said that this important Internet-Draft would be publsihed > outside of the HRPC RG, as an individual publication. But now it > expired :-( >=20 > [Such a document ages quite quickly. Publishing it in one or two years > would probably be useless.] >=20 I'm chatting with Joe about progressing that as an AD sponsored IETF draft. That's been a bit delayed for good reasons but I hope we'll get IETF last call started soon. Cheers, S. >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --------------ms020501080203060703040500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMTAx MTQ1MThaMC8GCSqGSIb3DQEJBDEiBCApftmDSWNsAjjZP9M1l8MCk9JiOOzqIdy3v+F7HP+e oTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCj8f/7cDgktRgrCJQk5bpucJt9hfAHwtmk+AO2seuABZOr5n5RV/4k ONtIqjKs9xFYPTmj84U0xZqu6i0hkEvReTSbvuf5EONrvARKEMTrLEiPWoeFqQU1LV7Ac93a 4RT9pAFlPRmIP2BuUoOENowIqlwy6yhc27PqCY1QxQnuuWHzuSZUooKkuWPpLnX8HzzBI5mi CkUlnrooKMBh/sJb6kL2xFIN2bK92WdADgV/kov7G8VgxAwPZ2zIy1MqvPZbQT+yR5genSrT 1AtFl7oyPWpY5yLt4uvERvHPwqPM8vcCaSy2CwZvaiB3J63mHjHp5sKqmnghNhS8r8dElo8f AAAAAAAA --------------ms020501080203060703040500-- From nobody Tue Jan 10 07:41:57 2017 Return-Path: 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 5E07D12950D for ; Tue, 10 Jan 2017 07:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 6t3Xe3WPrt-Q for ; Tue, 10 Jan 2017 07:41:52 -0800 (PST) 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 7D44F129507 for ; Tue, 10 Jan 2017 07:41:52 -0800 (PST) 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 1cQyYW-000277-5G for ; Tue, 10 Jan 2017 16:41:48 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 0A35EB002B5 for ; Tue, 10 Jan 2017 16:41:48 +0100 (CET) References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> To: hrpc@irtf.org From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <1d010e09-7ad6-9b47-b871-4680f7aeb9a5@kit.edu> Date: Tue, 10 Jan 2017 16:41:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> 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 1484062908. Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 15:41:56 -0000 Hi, > There are some inaccuracies with the vocabulary section and I have > several comments for section 4. I'll come back to that later in more detail. Here we go... Since other work prevented me to follow the hrpc list closely in the last weeks, I apologize for repeating some comments that others already made. Abstract: --------- IMHO the abstract should not start with a "list of sections" it provides. It should rather start with the main issue of providing considerations on human rights in protocols (or protocol design), comprising proposals for consideration guidelines, vocabulary, and a description of the methodology as well as a coarse literature review. Introduction: ------------- I find it a bit confusing to directly start with citations without setting the context first, so probably move the citations somewhere into the text, where they fit. In a broader sense, protocols touch also other values, not only human rights. So probably, a short motivation should be given, why this draft/RG concentrates on human rights. While the draft talks a lot about human rights, it doesn't list a few of them as examples (e.g., at least those used later in section 4). Therefore, I propose to extend the vocabulary and also define "human rights" there (it's ok to list some of them and repeat the references for further details...). Typo: "This has led to an broad" -> "This has led to a broad" "The purpose of the Internet to be a global network of networks that provides unfettered connectivity to all users and for any content [RFC1958]." -> I couldn't find this statement in RFC 1958. (general comment: please be more accurate when you cite documents, this also applies to several other places, esp. in the vocabulary, see below). RFC 1958 talks about connectivity as a goal of the Internet architecture, but doesn't mention "unfettered connectivity to all users and for any content". "Additionally, access to information gives people access to knowledge..." -> probably qualify this by using "generally accessible information" or "freely available information" (some information on the Internet isn't freely accessible or available for all on purpose). "In order to do this it is crucial that the rights impacts are clearly documented in order to mitigate the potential harm in a proportional way." -> I find this statement problematic. Sometimes the impacts are complicated since several rights may be affected at once. Moreover, how to actually balance between conflicts isn't clear at all sometimes. So I don't know what "mitigate the potential harm in a _proportional way_" actually means nor how to achieve it... Vocabulary: ----------- "Authenticity" -> while other security terms are taken from RFC 4949, this one isn't (any other reference for this particular definition?). Usually Authenticity includes data integrity as defined in RFC4949 (just stating that it is strongly linked with integrity is IMHO a bit too weak). Censorship isn't defined but used in the definition of Censorship resistance. Confidentiality: the definition isn't correct (unintended -> unauthorized) and also isn't taken literally from RFC 4949 although referenced... better replace it with the definition from RFC4949. End-to-End: - Typo "principal -> principle" - This definition here mixes "end-to-end transparency" issues with the "end-to-end argument in systems design" (the Saltzer, Reed, Clark paper). I think it is indeed clearer to separate the two (see also https://tools.ietf.org/html/rfc2775 and https://tools.ietf.org/html/rfc4924). From nobody Tue Jan 10 07:44:44 2017 Return-Path: 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 681AB129513 for ; Tue, 10 Jan 2017 07:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 uOf59j3Ah_y7 for ; Tue, 10 Jan 2017 07:44:34 -0800 (PST) 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 9B86612951E for ; Tue, 10 Jan 2017 07:44:34 -0800 (PST) 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 1cQybB-0002Fx-4h for ; Tue, 10 Jan 2017 16:44:33 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 15D9EB002B5 for ; Tue, 10 Jan 2017 16:44:33 +0100 (CET) To: hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <1d010e09-7ad6-9b47-b871-4680f7aeb9a5@kit.edu> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <4c2bfb81-50ca-3a7e-48ad-28ff33456ff6@kit.edu> Date: Tue, 10 Jan 2017 16:44:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1d010e09-7ad6-9b47-b871-4680f7aeb9a5@kit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1484063073. Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 15:44:42 -0000 Hi, I'm very sorry, I accidentally hit the send button too early, so please ignore this version, a more complete one will follow... :-] Regards, Roland >> There are some inaccuracies with the vocabulary section and I have >> several comments for section 4. I'll come back to that later in more detail. > > Here we go... > Since other work prevented me to follow the hrpc list closely in the > last weeks, I apologize for repeating some comments that others already > made. > > Abstract: > --------- > IMHO the abstract should not start with a "list of sections" it > provides. It should rather start with the main issue of providing > considerations on human rights in protocols (or protocol design), > comprising proposals for consideration guidelines, vocabulary, > and a description of the methodology as well as a coarse literature review. > > Introduction: > ------------- > I find it a bit confusing to directly start with citations without > setting the context first, so probably move the citations somewhere > into the text, where they fit. > > In a broader sense, protocols touch also other values, not only > human rights. So probably, a short motivation should be given, why > this draft/RG concentrates on human rights. > > While the draft talks a lot about human rights, it doesn't list > a few of them as examples (e.g., at least those used later in section > 4). Therefore, I propose to extend the vocabulary and also define > "human rights" there (it's ok to list some of them and repeat the > references for further details...). > > Typo: "This has led to an broad" -> "This has led to a broad" > > "The purpose of the Internet to be a global network of networks that > provides unfettered connectivity to all users and for any content > [RFC1958]." -> I couldn't find this statement in RFC 1958. > (general comment: please be more accurate when you cite documents, this > also applies to several other places, esp. in the vocabulary, see below). > RFC 1958 talks about connectivity as a goal of the Internet > architecture, but doesn't mention "unfettered connectivity to all users > and for any content". > > "Additionally, access to information gives people access to knowledge..." > -> probably qualify this by using "generally accessible information" > or "freely available information" (some information on the Internet > isn't freely accessible or available for all on purpose). > > "In order to do this it is crucial that the rights impacts are clearly > documented in order to mitigate the potential harm in a proportional > way." -> I find this statement problematic. > Sometimes the impacts are complicated since several rights > may be affected at once. Moreover, how to actually balance between > conflicts isn't clear at all sometimes. > So I don't know what "mitigate the potential harm in a _proportional > way_" actually means nor how to achieve it... > > Vocabulary: > ----------- > "Authenticity" -> while other security terms are taken from RFC 4949, > this one isn't (any other reference for this particular definition?). > Usually Authenticity includes data integrity as defined > in RFC4949 (just stating that it is strongly linked with integrity > is IMHO a bit too weak). > > Censorship isn't defined but used in the definition of Censorship > resistance. > > Confidentiality: the definition isn't correct (unintended -> > unauthorized) and also isn't taken literally from RFC 4949 although > referenced... better replace it with the definition from RFC4949. > > End-to-End: > - Typo "principal -> principle" > - This definition here mixes "end-to-end transparency" issues with > the "end-to-end argument in systems design" (the Saltzer, Reed, Clark > paper). I think it is indeed > clearer to separate the two (see also > https://tools.ietf.org/html/rfc2775 and > https://tools.ietf.org/html/rfc4924). > From nobody Tue Jan 10 14:05:45 2017 Return-Path: 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 D4EC312A053 for ; Tue, 10 Jan 2017 14:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 8xm4IxZ_CgwC for ; Tue, 10 Jan 2017 14:05:42 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 61C3B129DD1 for ; Tue, 10 Jan 2017 14:05:42 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id v0AM5A48017969; Tue, 10 Jan 2017 17:05:12 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id v0AM3ELD031304; Tue, 10 Jan 2017 17:03:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22645.23074.738779.39876@gargle.gargle.HOWL> Date: Tue, 10 Jan 2017 17:03:14 -0500 From: bzs@theworld.com To: hrpc@irtf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: [hrpc] Possibly interesting, Bloomberg TV X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 22:05:44 -0000 Bloomberg TV is running a feature on "The Dark Side of Algorithms", interview guest Cathy O'Neil author of "Weapons of Math Destruction". It runs periodically, only a few minutes long. A lot of it touches on what we all know. But she does make a good general point about how something algorithmic rights violations causes is they intimidate people who feel they aren't equipped to argue about flaws in "algorithms". It raises the question of: Just as when people are intimidated by legal jargon and seek lawyers whom should they seek if they feel their rights were violated by an algorithm (or protocol)? How many lawyers, for example, are competent to build such a case? Or without needing to immediately resort to expensive expert witnesses etc. over what probably should be a relatively minor matter. But it's the public airing which is probably most interesting. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Wed Jan 11 16:14:54 2017 Return-Path: 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 486211294BC for ; Wed, 11 Jan 2017 16:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 cVY4Kr6637TI for ; Wed, 11 Jan 2017 16:14:48 -0800 (PST) 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 9BADD129542 for ; Wed, 11 Jan 2017 16:14:48 -0800 (PST) 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 1cRT2Q-00088k-Fn; Thu, 12 Jan 2017 01:14:42 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 2EEF4B005C2; Thu, 12 Jan 2017 01:14:42 +0100 (CET) From: "Bless, Roland (TM)" To: hrpc@irtf.org, Niels ten Oever , Corinne Cath References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> Date: Thu, 12 Jan 2017 01:14:41 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 In-Reply-To: <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> 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 1484180082. Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 00:14:52 -0000 Hi, > There are some inaccuracies with the vocabulary section and I have > several comments for section 4. I'll come back to that later in more detail. This write-up took much longer than expected... Since other work prevented me to follow the hrpc list closely in the last weeks, I apologize for repeating some comments that others already made. tl;dr: Major issue from my perspective: the rationale why certain technical concepts or properties impact particular human rights is often missing. In many cases it remains unclear how/why certain human rights are listed in figure 2 and section 4 while others aren't. This really needs to be fixed IMHO. Detailed comments: Abstract: --------- IMHO the abstract should not start with a "list of sections" it provides. It should rather start with the main issue of providing considerations on human rights in protocols (or protocol design), comprising proposals for consideration guidelines, vocabulary, and a description of the methodology as well as a coarse literature review. Introduction: ------------- I find it a bit confusing to directly start with citations without setting the context first, so probably move the citations somewhere into the text, where they fit. In a broader sense, protocols touch also other values, not only human rights. So probably, a short motivation should be given, why this draft/RG concentrates on human rights. While the draft talks a lot about human rights, it doesn't list a few of them as examples (e.g., at least those used later in section 4). Therefore, I propose to extend the vocabulary and also define "human rights" there (it's probably enough to list some of them and repeat the references for further details...). Typo: "This has led to an broad" -> "This has led to a broad" "The purpose of the Internet to be a global network of networks that provides unfettered connectivity to all users and for any content [RFC1958]." -> I couldn't find this statement in RFC 1958. (general comment: please be more accurate when you cite documents, this also applies to several other places, esp. in the vocabulary, see below). RFC 1958 talks about connectivity as a goal of the Internet architecture, but doesn't mention "unfettered connectivity to all users and for any content". "Additionally, access to information gives people access to knowledge..." -> probably qualify this by using "generally accessible information" or "freely available information" (some information on the Internet isn't freely accessible or available for all on purpose). "In order to do this it is crucial that the rights impacts are clearly documented in order to mitigate the potential harm in a proportional way." -> I find this statement problematic. Sometimes the impacts are complicated since several rights may be affected at once. Moreover, how to actually balance between conflicts isn't clear at all sometimes. So I don't know what "mitigate the potential harm in a _proportional way_" actually means nor how to achieve it... Vocabulary: ----------- "Authenticity" -> while other security terms are taken from RFC 4949, this one isn't (any other reference for this particular definition?). Usually Authenticity includes data integrity as defined in RFC4949 (just stating that it is strongly linked with integrity is IMHO a bit too weak). Confidentiality: the definition isn't correct (unintended -> unauthorized) and also isn't taken literally from RFC 4949 although referenced... better replace it with the definition from RFC4949. End-to-End: - Typo "principal -> principle" - This definition here mixes "end-to-end transparency" issues with the "end-to-end argument in systems design" (the Saltzer, Reed, Clark paper). I think it is indeed clearer to separate the two (see also https://tools.ietf.org/html/rfc2775 and https://tools.ietf.org/html/rfc4924). IMHO the statement "Functionality should be expanded at the end-points to ensure that the network interconnects rather than controls." is somewhat confusing and doesn't reflect the end-to-end argument: Application-specific functions should not be embedded into the network and thus stay at the end-points: in many cases, esp. when dealing with failures, the right decisions can only be made with the corresponding application-specific knowledge, which is available there. So the quoted statement is too general (just speaks of functionality), the meaning of "expand" is unclear and some control functions (e.g., routing) are even necessary for providing the interconnection between networks. Consequences of the end-to-end argument are robustness and (easier) innovation at the edges. - I don't understand the point of the following text "For example, end-to-end instant message encryption would conceal communications from one user's instant messaging application..." in this context. From the Internet layer perspective encryption between an instant messaging client and an intermediate server using TLS is end-to-end. From the application layer perspective, it is not really end-to-end (user-to-user) encrypted. Moreover, in many cases only content can be protected end-to-end while some meta-data (mostly in form of protocol headers) need to be processed by intermediate nodes. Integrity: the used definition references RFC 4949 again, but isn't taken from there. Please use the one from 4949: data integrity: "The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner." Internet censorship: while correctly cited from [Elahi], the definition is somewhat imprecise, since there is definitely information available in the Internet at some servers that is access controlled etc. for good reasons, e.g., in order to prevent its unauthorized disclosure. That confidential information is also in many cases relevant for decision making. According to the definition this "protected confidential information" is censored. The fix is probably as follows: "Internet censorship is the intentional suppression of otherwise freely accessible information originating, flowing or stored on systems connected to the Internet where that information is relevant for decision making to some entity." (based on [Elahi]). Interoperable: I don't understand what "without any restricted access or functionality." means here. Restricted access to what? Moreover, I think that "interoperable" is more a property of _implementations_ rather than the protocol specification: usually one checks whether two independent implementations (originating from the same protocol specification) interoperate with each other. "Open Standards Conform": though I'm not a native speaker, I think it should be "Open Standards Conforming" or "Conforming to Open Standards". The reference RFC2606 is incorrect, it should be RFC2026? Openness: not so clear what is meant here. Unrestricted access to freely accessible hosts or content, i.e., the absence of Internet censorship? How is it different from accessibility? Reliable -> Reliability Scalable -> Scalability Scalability is usually defined with respect to certain specific system parameters (e.g., number of end-systems, users, data flows, routing entries. etc.). Moreover, growth/shrinkage of these parameters is typically considered by orders of magnitude. Connectivity: - This term needs to be sorted into the right order... - typo enableing -> enabling (several occurrences in the draft). - I'm not sure, but I think that the distributed/decentralized nature of the Internet is also important for connectivity (providing alternative choices of access and routes). Methodology: ------------- analysis.The results.... => analysis. The results.... 3.2.1.1. Mapping protocols and standards related to human rights Not sure, but either delete "related" or rephrase as "Relating protocols and standards to human rights". "By combining data from the three data sources named above, an extensive list of protocols and standards that potentially enable the Internet as a tool for freedom of expression and association." That sentence is missing a verb, e.g., "an extensive list .... was created" (or rephrase accordingly to avoid passive voice...). 3.2.1.2. Extracting concepts from mapped RFCs "mapped RFCs" sounds IMHO a bit odd, maybe replace with "selected RFCs". Mapping the protocols and standards that are related to human rights and create a human rights enabeling environment was the first step. Suggestion: Identifying the protocols and standards that are related to human rights and create a human rights enabling environment was the first step. 3.2.1.3. While interviewing experts, mapping RFCs and ... => While interviewing experts, investigating RFCs and ... 3.2.1.4. The previous steps allowed for the clarification of relation between => The previous steps allowed for the clarification of relations between This section and the following use many different terms, probably for the same item: technical definition(s), technical concept(s), technical term(s) and figure 1 finally uses "architectural principles". "allowing for the creation of a list of technical concepts that when combined create an enabling" => "allowing for the creation of a list of technical concepts that, when combined, create an enabling" It is unclear whether one needs to combine _all_ of the technical concepts or only some of them. Moreover, do we have a "proof" that this is really the case? The text in 3.2.2 suggests that we probably have merely hints for the mappings rather than actual evidences or a very deep understanding of the exact relations between the technical concepts and human rights. So I suggest to weaken the statement a bit: "allowing for the creation of a list of technical concepts that, when partially combined, _can_ create an enabling" the same applies to 3.2.1.5. and its title, which is basically a repetition. figure 1: it appears to me as if some of the terms are more (system) properties (the figure mentions characteristics) rather than principles. We may have/know principles that lead to the mentioned properties if applied during design, deployment or operation. Examples: - Simplicity. Applying minimality principles (KISS or also the end-to-end argument) may result in simpler systems that eventually lead to higher robustness (rfc3439 discusses this in more depth). - Resilience. Every principle that increases robustness may lead to higher resilience, e.g., fate-sharing/statelessness, end-to-end principle, soft-states, Postel principle, decentralized design, etc. Transparency -> this is missing in the vocabulary. Since transparency is actually used in very different meanings (transparent=verifiable, traceable, comprehensible and sometimes even invisible) a clarification would be good. Heterogeneity -> Heterogeneity support figure 2: - the left column lists not only technical concepts but also (desired) properties. - the rationale why the specific rights are impacted by the technical concepts or properties are the most interesting part and actually missing in the description. It would be very valuable to provide a paragraph for each row in section 3.2.2 that explains why there is a relation between the concepts/properties and the particular rights. For example for the first row: "Connectivity is required, because the individual that wants to provide information for others needs means to reach potential recipients. Privacy is helpful in case ..." Section 4 seems to partially contain some of the reasoning, however, I think that it would be better to move it here. - typo in caption: excise -> exercise 3.2.3. The goal here is to show, with actual examples, that the design of protocols have practical consequences for some human rights and these consequences have to be considered at design time. => The goal here is to show, with actual examples, that the design of protocols have practical consequences for some human rights and these consequences should be considered at the design time already. "have to be" is IMHO too strong. network core can make policy decisions and enforce policy shaping and I'm not sure what meant here by "policy shaping", but probably policy-based traffic shaping is meant as recently described in http://dl.acm.org/citation.cfm?id=2934873 (freely accessible via http://conferences.sigcomm.org/sigcomm/2016/program.php). Thus, probably rephrase as: => network core can make policy decisions and enforce policy-based traffic shaping and Typos: helping us understand which technical protocol decisions have led to harm of this human => helping us to understand which technical protocol decisions have led to harm of these human 3.2.3.1.1. APIP (http://dl.acm.org/citation.cfm?id=2626306) and Hornet (http://dl.acm.org/citation.cfm?id=2813628) could be mentioned as alternative designs. Typo: to choose a per defined => to choose a pre-defined 3.2.3.1.2. [RFC1631] is obsoleted by RFC 3022 I skipped most of the rest of section 3... Section 4 --------- The sub-structure 4.1 -> 4.1.1 doesn't make so much sense since there is no 4.2 or 4.1.2 etc. 4.1: Typos: This sections details => This section details or proritize some => or prioritize some analysis that can serve as the basis for discussion on whether the protocol adequately protects against specific human rights threats. maybe add text that it may stimulate authors to think about alternative designs choices.. The following sections also do not always contain a rationale why certain listed human rights are potentially affected adversely. 4.1.1.1.1 Connectivity I'm really not convinced that the end-to-end argument directly relates to connectivity rather than to permissionless innovation, resilience and robustness... the example of end-to-end encryption would be more suitable for Privacy and doesn't cover the problem of nevertheless visibile metadata. For connectivity I would also expect the right to access to be listed as potentially impacted (without proper connectivity, certain freely available information cannot be accessed). 4.1.1.1.3. Typo: priotization => prioritization 4.1.1.1.4. => What about a right to security? 4.1.1.1.5. - Right to political participation is listed twice 4.1.1.1.7. Open Standards Typo: The Internet was able to developed => The Internet was able to be developed 4.1.1.1.8. Typos: to allow open innovation possibly have security and privacy ramifications, and if so,how can these be dealt with? => allow open innovation possibly have security and privacy ramifications, and if so, how can these be dealt with? I don't understand how this related to the "right to security" while I'm missing the right to access or participation 4.1.1.1.9 to achieve, it is non-binary concept. Making pervasive monitoring => to achieve, it is a non-binary concept. Making pervasive monitoring 4.1.1.1.10 generates or processes anything that can be, or be tightly correlated => generate or process anything that can be, or be tightly correlated 4.1.1.1.11 "Could your protocol also be developed in a stateless manner?" I don't understand how this would improve accessibility... 4.1.1.1.12 the difference to internationalization is not that clear to me... 4.1.1.1.13 I'm missing the Right to access (a decentralized architecture allows probably more points of access to the network). 4.1.1.1.14 This could make use of statelessness and soft-states as technical principles Why is only the right to security listed here? Right to access would also fit here... 4.1.1.1.15 what about the right to privacy? 4.1.1.1.16 Question(s): Does your protocol maintain and assure the accuracy of data? Does your protocol maintain and assure the consistency of data? Does your protocol in any way allow for the data to be (intentionally or unintentionally) altered? I think these are flawed (cf. also my criticism on the definition in the vocabulary). Especially, "Does your protocol in any way allow for the data to be (intentionally or unintentionally) altered?" doesn't make much sense to me. I suppose that the question consideres alteration while data is in transit. Which data is meant here? Protocol control information, i.e. headers, usually needs to be altered in transit, whereas payload data probably shouldn't be modified. Normally, protocols cannot really "prevent" that data is modified in transit, but they can have measures to detect any unauthorized modification. This impacts also the right to freedom of expression since censoring measure can lead to unauthorized modification of data. 4.1.1.1.17. Impacts several other rights, e.g., right to privacy, right to freedom of expression etc. because in some cases that origin can be clearly identified which discloses information sources. 4.1.1.1.18. Adaptability is closely interrelated permissionless => Adaptability is closely interrelated to permissionless ---- so much for now... Regards, Roland From nobody Thu Jan 12 09:00:44 2017 Return-Path: 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 B4BCF12949D for ; Thu, 12 Jan 2017 09:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no 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 eG_4u2py0neP for ; Thu, 12 Jan 2017 09:00:42 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69FB128BA2 for ; Thu, 12 Jan 2017 09:00:41 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id EDAED12BCFE for ; Thu, 12 Jan 2017 17:00:39 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -15, 0, , d41d8cd98f00b204, avri@acm.org, ::, RULES_HIT:41:355:379:599:800:854:871:967:973:988:989:1000:1260:1261:1313:1314:1345:1359:1381:1437:1516:1518:1534:1542:1575:1594:1711:1730:1747:1777:1792:1960:1963:2194:2198:2199:2200:2393:2525:2553:2561:2564:2682:2685:2691:2693:2741:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:4362:4425:4559:4860:5007:6117:6119:6506:6747:6748:7281:7652:7903:7909:8660:9010:9025:10004:10848:11232:11604:11658:11914:12043:12050:12109:12114:12291:12379:12438:12663:12683:12740:12895:13019:13148:13161:13229:13230:13846:13868:14095:14096:14180:14181:14227:14658:14659:14721:14877:21060:21080:21212:21433:30022:30054:30060:30083:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:4, LUA_SUMMARY:none X-HE-Tag: view59_3ff66d9e39a44 X-Filterd-Recvd-Size: 4530 Received: from [127.0.0.1] (wsip-68-15-42-104.ri.ri.cox.net [68.15.42.104]) (Authenticated sender: avri@doria.org) by omf11.hostedemail.com (Postfix) with ESMTPA for ; Thu, 12 Jan 2017 17:00:39 +0000 (UTC) References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> To: hrpc@irtf.org From: avri doria Message-ID: <5bdd6692-2a88-0ff4-37cc-3c23f34783dd@acm.org> Date: Thu, 12 Jan 2017 12:00:20 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JLIUOVsaPHNVu3lLjAGRaONG9gl0nC2n1" X-Antivirus: avast! (VPS 170112-0, 01/12/2017), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: avri@acm.org List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:00:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JLIUOVsaPHNVu3lLjAGRaONG9gl0nC2n1 Content-Type: multipart/mixed; boundary="mCg99PmvPAV2nhpmQrb2uOQfQsmIRUgfl"; protected-headers="v1" From: avri doria Reply-To: avri@acm.org To: hrpc@irtf.org Message-ID: <5bdd6692-2a88-0ff4-37cc-3c23f34783dd@acm.org> Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> In-Reply-To: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> --mCg99PmvPAV2nhpmQrb2uOQfQsmIRUgfl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, As Jan 9 has come and gone the last call is ended.=20 I am still digesting the responses, but from my first reading, do believe we got significant and substantive comment. I know of at least one review, from one of the IETF General Area reviewers, that is still being worked on and would like to be able to accept it as part of the Last Call comments, assuming it shows up in the next few days. Are they any other pending reviews in progress? thanks avri On 04-Dec-16 14:54, avri doria wrote: > Hi, > > With this note, I am starting a Research Group call on the draft > > https://tools.ietf.org/html/draft-irtf-hrpc-research-07 > > > Research into Human Rights Protocol Considerations > > > While RFC 5743 "Definition of an Internet Research Task Force (IRTF) Do= cument Stream" does not mandate a Last Call or any specific action to pro= ve that a document has the correct maturity and review for publication, i= t is safe to think of this call as similar to a first IETF last call. If= substantive changes to the document are produced based on the reviews we= get, there will probably be another call on a later revision of the draf= t. If, or when, there are no substantive changes made we will be able to = move on to IRSG Review of the draft. If we don't get a wide enough revie= w, we will need to figure out what to do next. > > Given that I am hoping to use this call as a way to get a larger audien= ce to review that draft, and the fact that we are coming into one of the = global holiday times, I will leave this call open until 9 Jan 2017. > > Please send all comment to the HRPC email list: hrpc@irtf.org. I do ho= pe that some good discussions occur on this list where the resolution to = any issues may be forged. Discussion has been shown to improve this draft= =2E > > Happy reviewing > > Avri Doria > > BTW, I copied the IRSG list on this hoping to get wider review group. > > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --mCg99PmvPAV2nhpmQrb2uOQfQsmIRUgfl-- --JLIUOVsaPHNVu3lLjAGRaONG9gl0nC2n1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYd7Y1AAoJEOo+L8tCe36HFbkH/jjaini952flgpXsHOWVenqi 6CiB0s0jwTMq86+KySlAmDNZlKGVb592Wt9QuhZAi4iCrFK8WCTXESW/onvmxmA+ ecAB7whRT8IHW6T3AuuI/5D6Ybx5+kysXiMjgc+Ni5YX7pCre7j/8fHLqgsNdUyM X/VHp3KJpyHMqSUEyDy9GlUY8mjXH97p82eF9nb+5+85MYWxOgaP6F9j+lfE8G9P 7ViXrbtfDDkx+X/tAxMy88yNI6WQNlzkmdtpEvQ4VylT6E7ivG9RzX/a0EbFfmH9 DK0x1BIggQMcSvEtaci0lDCzLd8ttaK7IMtQwRwp9vARE2Z4ebswXFZklzPKrp4= =CD/b -----END PGP SIGNATURE----- --JLIUOVsaPHNVu3lLjAGRaONG9gl0nC2n1-- From nobody Thu Jan 12 13:30:32 2017 Return-Path: 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 491B4129500 for ; Thu, 12 Jan 2017 13:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=QKXHvcpG; dkim=pass (1024-bit key) header.d=elandsys.com header.b=HY8o824j 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 8fQnZgigj6Ij for ; Thu, 12 Jan 2017 13:30:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B0129503 for ; Thu, 12 Jan 2017 13:30:22 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0CLU5YK012909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2017 13:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484256611; x=1484343011; bh=AfcnW/7JxxXF7Mn0olQltdD7b1ctX8xXK8cNtC81YuM=; h=Date:To:From:Subject:Cc; b=QKXHvcpGqMhDK0x7nCycQ9lhhKFXuuDrydiPUwQLnZd/dJ8+Bb1c4xPdO5zG5ugRN E8pNTe0i6UWWdw8cIVXDHOH04CK8spbqhRdtm2Uul4UN9bJ/SHelauGPydCSse9mEE HzATKIQN9+0K761ay/b6vmgyPkvRwi7+Q2TP58PI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484256611; x=1484343011; i=@elandsys.com; bh=AfcnW/7JxxXF7Mn0olQltdD7b1ctX8xXK8cNtC81YuM=; h=Date:To:From:Subject:Cc; b=HY8o824j7hpZ62YqsKWTw+HLSB+57aAci9XiyTkTUXLEPWM4Do75LvWhqAZUh+VUa HJA7x5D3goicsgOIeX+u3cLcgtLwJeRu+cs5rcQiC6FPlve+tfTk9sNwOACrTf1qlt FHJGBCNXG8Fbx28aBZaKjl3aQlRqF0e6QrKsl0wM= Message-Id: <6.2.5.6.2.20170112130222.0bf05a90@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Jan 2017 13:06:30 -0800 To: avri doria From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:30:24 -0000 Hi Avri, >I know of at least one review, from one of the IETF General Area >reviewers, that is still being worked on and would like to be able to >accept it as part of the Last Call comments, assuming it shows up in >the next few days. Are they any other pending reviews in progress? The comments which I sent (please see https://www.ietf.org/mail-archive/web/hrpc/current/msg00774.html ) have not been addressed. Regards, S. Moonesamy From nobody Fri Jan 13 13:38:13 2017 Return-Path: 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 1197A129435 for ; Fri, 13 Jan 2017 13:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 u6Yq4rulwKND for ; Fri, 13 Jan 2017 13:38:09 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 A86E51204D9 for ; Fri, 13 Jan 2017 13:38:09 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id F0BD031D54; Fri, 13 Jan 2017 22:38:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 078E1190661; Fri, 13 Jan 2017 22:35:19 +0100 (CET) Date: Fri, 13 Jan 2017 22:35:19 +0100 From: Stephane Bortzmeyer To: "Bless, Roland (TM)" Message-ID: <20170113213519.GA21524@sources.org> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Corinne Cath , Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:38:12 -0000 On Thu, Jan 12, 2017 at 01:14:41AM +0100, Bless, Roland (TM) wrote a message of 462 lines which said: > In many cases it remains unclear how/why certain human rights are > listed in figure 2 and section 4 while others aren't. This really > needs to be fixed IMHO. There is a good reason to not treat all human rights alike. Some are already well-covered in IETF work (such as privacy in RFC 6973). I think we should focus on rights which have not been, until recently, explicitely discussed in the IETF (such as freedom of expression). > define "human rights" there I think it is not up to the IETF/IRTF to define human rights and we should defer to an external definition (the draft currently uses the UDHR, which I think is a good idea). May be a sentence in the terminology section like "Human rights: the rights of every human being, as defined in the Universal Declaration of Human Rights [Ref]"? > "The purpose of the Internet to be a global network of networks that > provides unfettered connectivity to all users and for any content > [RFC1958]." -> I couldn't find this statement in RFC 1958. I suggest to follow the classical rule: when it is between quotes, it is a litteral statement. Otherwise, it can be a summary or a synthesis. Here, there are in the draft no quotes around the sentence you mention, meaning clearly that it was not supposed to be an exact citation. > Usually Authenticity includes data integrity as defined in RFC4949 > (just stating that it is strongly linked with integrity is IMHO a > bit too weak). Agreed. Authenticity without integrity is almost useless. > The fix is > probably as follows: > "Internet censorship is the intentional suppression of otherwise > freely accessible information originating, flowing or stored on > systems connected to the Internet where that information is > relevant for decision making to some entity." (based on [Elahi]). No. If a system deletes my *private* messages (content which was not "freely accessible information"), it is still censorship. From nobody Fri Jan 13 13:48:12 2017 Return-Path: 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 BF50D129E7C for ; Fri, 13 Jan 2017 13:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zJH-I64ohzXA for ; Fri, 13 Jan 2017 13:48:09 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 21624129C72 for ; Fri, 13 Jan 2017 13:48:09 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 43CF831D54; Fri, 13 Jan 2017 22:48:07 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 417D3190661; Fri, 13 Jan 2017 22:44:34 +0100 (CET) Date: Fri, 13 Jan 2017 22:44:34 +0100 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20170113214434.GB21524@sources.org> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <20170106141722.3ob7c3otmgu2n5rn@nic.fr> <93A95FD3-3DC7-4D0A-811D-C1F72312F13B@cooperw.in> <20170106171632.ywoh52l5al4p5yzp@nic.fr> <04f23833-7a7a-339c-aeca-7d4f86c18959@cs.tcd.ie> <20170106172658.x47wn7vbivg2vn4d@nic.fr> <0d2d4bb4-bba6-c1c7-e45f-69fbea099728@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0d2d4bb4-bba6-c1c7-e45f-69fbea099728@article19.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:48:10 -0000 On Sat, Jan 07, 2017 at 06:21:44PM +0100, Niels ten Oever wrote a message of 120 lines which said: > {{Bless}} for instance argues that, 'to a certain extent, the > Internet and its protocols have already facilitated the realization > of human rights, e.g., the freedom of assembly and expression. You can quote A. J. Liebling "Freedom of the press is guaranteed only to those who own one" or Benjamin Bayart "L’imprimerie a permis au peuple de lire, Internet va lui permettre d’écrire" ("the printing press allowed the people to read, Internet will enable it to write"). From nobody Fri Jan 13 13:58:10 2017 Return-Path: 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 5476F129E8A for ; Fri, 13 Jan 2017 13:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JZHTbp3PNNHa for ; Fri, 13 Jan 2017 13:58:08 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 D1221129C87 for ; Fri, 13 Jan 2017 13:58:07 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 731FD31D54; Fri, 13 Jan 2017 22:58:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 94A5A190661; Fri, 13 Jan 2017 22:53:18 +0100 (CET) Date: Fri, 13 Jan 2017 22:53:18 +0100 From: Stephane Bortzmeyer To: Alissa Cooper Message-ID: <20170113215318.GC21524@sources.org> References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <72333205-0458-63d9-6d9e-3538266fec1d@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:58:09 -0000 On Mon, Jan 09, 2017 at 04:46:53PM -0500, Alissa Cooper wrote a message of 783 lines which said: > what would be better would be specific text in the intro to 3.2.3 > that explains that the emphasis of the examples is on adverse > impacts to human rights. Perhaps even better would be to remove the > positive examples and just focus exclusively on the negative ones, > so it’s clear that the thrust of the entire section is to provide > negative examples. I disagree. The goal of the section is certainly not to focus on negative examples. I personnally think it would be a welcome addition to add posituve examples but I asked for some and nobody suggested anything (besides the very general "IP is efficient, it works, and it allows a wonderful thing, the Internet"). May be we should search harder? > > Can your protocol contribute to filtering in a way it could be > > implemented to censor data or services? Could this be designed to > > ensure this doesn't happen? > > > > I also think the example provides quite some framing which also > > shows > > the boundaries of this question. > > I don’t really understand the example TBH. It talks about filtering > based on IP address but then cites HTTP 451, whose use might have > nothing to do with IP-based filtering. I think it is two different things. "Filtering can be made apparent by the use of status code 451" is an answer to the question "Does your protocol make it apparent or transparent when filtering happens?" and "Identifiers of content exposed within a protocol might be used to facilitate censorship" is an answer to the question "Does this protocol introduce new identifiers or reuse existing identifiers (e.g. MAC addresses) that might be associated with persons or content?" From nobody Fri Jan 13 14:03:10 2017 Return-Path: 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 C5FB2129E9B for ; Fri, 13 Jan 2017 14:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YHe0BQKKKrWy for ; Fri, 13 Jan 2017 14:03:08 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 40211129E95 for ; Fri, 13 Jan 2017 14:03:08 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id BFAB831D54; Fri, 13 Jan 2017 23:03:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 6AF0D190661; Fri, 13 Jan 2017 23:00:28 +0100 (CET) Date: Fri, 13 Jan 2017 23:00:28 +0100 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20170113220028.GD21524@sources.org> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:03:10 -0000 On Fri, Jan 06, 2017 at 11:20:35AM +0000, Stephen Farrell wrote a message of 274 lines which said: > If you assert that [1] is political because everything in the entire > universe is political then that seems to me to mean that there is no > need for the "protocols are politics" statements in the draft - one > tautology less would surely improve things if you are correct. I tend to have a pragmatic vision here. We can discuss for a long time between "Everything is political" and "Nothing in the RFC is political" but the current state at the IETF is that, IMHO, most protocol authors and RFC authors _underestimate_ the political consequences of their choices. So, it is a good idea to err on the side of "there are more things political than you think". There is may be a risk that some people will take the "protocols are politics by other means" too seriously and will find political consequences in the fact that the source IP address is before the destination IP address, but such a risk is probably very low, and it won't be a practical problem in the IETF. From nobody Fri Jan 13 14:41:36 2017 Return-Path: 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 BE12D129EE5 for ; Fri, 13 Jan 2017 14:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 gnYkdjXGD2Zl for ; Fri, 13 Jan 2017 14:41:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03551294D8 for ; Fri, 13 Jan 2017 14:41:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89079BECC; Fri, 13 Jan 2017 22:41:29 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3liHrTFyi6cc; Fri, 13 Jan 2017 22:41:28 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E1BEBECA; Fri, 13 Jan 2017 22:41:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484347288; bh=sA+iHPd1BgYu1DPkddsiNdCch2Cp6ASs9/knqn8Jf2Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=EaoAXW46WpL+wjJEj/J+Hp42k3QGp3kMwh6L9kAEZiq/WctqlkxpO6mJymedMvPdF m2sXxfC4j4lUIqqgaoraVzEMdJKAtUX8b4AmBD28O7sNa0fSbvmS97oAIo+xCuXtXY Ocq1hKv/KskVVwjAIGyn6JwWzehJ1ZS9EsFJR77Q= To: Stephane Bortzmeyer References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <20170113220028.GD21524@sources.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 13 Jan 2017 22:41:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170113220028.GD21524@sources.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070103030305090500040408" Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:41:35 -0000 This is a cryptographically signed message in MIME format. --------------ms070103030305090500040408 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/01/17 22:00, Stephane Bortzmeyer wrote: > On Fri, Jan 06, 2017 at 11:20:35AM +0000, > Stephen Farrell wrote=20 > a message of 274 lines which said: >=20 >> If you assert that [1] is political because everything in the entire >> universe is political then that seems to me to mean that there is no >> need for the "protocols are politics" statements in the draft - one >> tautology less would surely improve things if you are correct. >=20 > I tend to have a pragmatic vision here. We can discuss for a long time > between "Everything is political" and "Nothing in the RFC is > political" but the current state at the IETF is that, IMHO, most > protocol authors and RFC authors _underestimate_ the political > consequences of their choices. So, it is a good idea to err on the > side of "there are more things political than you think". I tend to agree with what you say and would also be ok with a statement like that being in the draft. >=20 > There is may be a risk that some people will take the "protocols are > politics by other means" too seriously and will find political > consequences in the fact that the source IP address is before the > destination IP address, but such a risk is probably very low, and it > won't be a practical problem in the IETF. I don't think that'd be the problem but rather that if we embraced that (IMO plain incorrect) statement we'd risk ending up damaging our concept that good technical argument is what wins. While the IETF is nowhere near perfect in that regard, it seems to me far less imperfect than most other similar bodies and we ought be careful to not damage that. Cheers, S. PS: All that said, I remain ok with what I think was the last version of the text Niels posted to the list. >=20 >=20 --------------ms070103030305090500040408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMTMy MjQxMjdaMC8GCSqGSIb3DQEJBDEiBCDrTUCEsB+NxMagjuyg57qqmm50a8eC7dZvIAbpI/fe LDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBReFj7qpD5kGMzYaWC2DIwytXweYFo0rlZ37fpWH/vevPTjhTgUyYf i+x6N32/HAQViYvT+QBr+iUD9OM9DSXEZq1+3rKvOYipUPAJXrHgziW6RDmKp8Gf/VWXO7zg DJ4ErdBVvBK1VZQOOD8jg0SwtMH7pr7l8QvZacPuD/8oQx5i2EW9Lm5z/oDbkMBPT5WbB4xf 79mbRSrlOE1J3bsAry+Gc5yNjqyup6MmNDufYSWUbd9RbCwx4OxSKDWAkhXCPVWEmoU5ZUJZ fJAk0koTKqoofUTpYGysbAdz+hSH2xG/TNjc99mzCBUSBwFuHSLKXrchhsdiOWi8AUOEBpEm AAAAAAAA --------------ms070103030305090500040408-- From nobody Fri Jan 13 14:51:01 2017 Return-Path: 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 53AE21299A6 for ; Fri, 13 Jan 2017 14:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 E58mGdGQoiO3 for ; Fri, 13 Jan 2017 14:50:57 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 99ECF129972 for ; Fri, 13 Jan 2017 14:50:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 7D51C1154D for ; Fri, 13 Jan 2017 22:50:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBi03suHLbtW for ; Fri, 13 Jan 2017 22:50:56 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 996FA1153D for ; Fri, 13 Jan 2017 22:50:56 +0000 (UTC) Date: Fri, 13 Jan 2017 17:50:54 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170113225054.GE662@mx2.yitter.info> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <20170113220028.GD21524@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170113220028.GD21524@sources.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:50:59 -0000 Hi, On Fri, Jan 13, 2017 at 11:00:28PM +0100, Stephane Bortzmeyer wrote: > political" but the current state at the IETF is that, IMHO, most > protocol authors and RFC authors _underestimate_ the political > consequences of their choices. I agree with that. > So, it is a good idea to err on the > side of "there are more things political than you think". Also that. > politics by other means" too seriously and will find political > consequences in the fact that the source IP address is before the > destination IP address, but such a risk is probably very low, and it > won't be a practical problem in the IETF. The above is almost certainly the crux of where we disagree, and maybe why I'm a little grouchy about this. Having just spent at least the last two years playing Junior Achievement Internet Politician, I can report that there is an entire world of people who seem genuinely to believe that this is all just politics, and that what is really needed is for some grownup politicians to come along and tell the IETF how it should make protocols. Those are people who think that a single root in a hierachical namespace is a mere political decision, rather than a fact of math. Those are people who think that, with the application of enough political oversight, key escrow is a perfectly good idea for the world rather than a giant security vulnerability waiting to be exploited. And those are people who think that internetwork-style connectivity as opposed to a dramatically more centralized style is _simply_ a political question, rather than one that has technical follow-on consequences with their own technical implications. There is a limnable difference between "technical decision that has consequences for politics" and "simply a political question". I think we need to be careful about that, both for political reasons (what it might drag us into) and technical reasons (what it might make possible or impossible). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jan 13 15:03:22 2017 Return-Path: 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 28F7D129F27 for ; Fri, 13 Jan 2017 15:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 sLgcluegKPgN for ; Fri, 13 Jan 2017 15:03:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52A2129F25 for ; Fri, 13 Jan 2017 15:03:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6EFE8BED6; Fri, 13 Jan 2017 23:03:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCu1kSf0Nefn; Fri, 13 Jan 2017 23:03:15 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AD28DBED5; Fri, 13 Jan 2017 23:03:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484348595; bh=QV98obLibr6FOzyAUkfOWqLhIitb84Le6uAXVqjNv3I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JDCKDyTmw1pXHL4wVeGJsbW78LYV4j59ald9OreVYYppcwl5Gi2E6ggOisEobJ7hG OxXGThhbaLf5sGPpbumQlt+nI16vgraPHfgK1DcSAEp/YrcMpo4SlqHc5EQc1Dz2S5 ZHEa9kQRnFgR/+WPtCf/n8P60R4FVDYERgCw5n9s= To: Andrew Sullivan , hrpc@irtf.org References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <20161230022007.GD3304@mx2.yitter.info> <6f55ea9a-2248-650d-2344-958f67d830d6@article19.org> <444d5d85-14fc-b27c-1ad0-a50d441b48c9@cs.tcd.ie> <20170113220028.GD21524@sources.org> <20170113225054.GE662@mx2.yitter.info> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 13 Jan 2017 23:03:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170113225054.GE662@mx2.yitter.info> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020302020602070409010802" Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 23:03:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020302020602070409010802 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/01/17 22:50, Andrew Sullivan wrote: > The above is almost certainly the crux of where we disagree, and maybe > why I'm a little grouchy about this. I agree with what Andrew says below, but am less grouchy having managed to avoid almost all of that particular nonsense;-) S. >=20 > Having just spent at least the last two years playing Junior > Achievement Internet Politician, I can report that there is an entire > world of people who seem genuinely to believe that this is all just > politics, and that what is really needed is for some grownup > politicians to come along and tell the IETF how it should make > protocols. Those are people who think that a single root in a > hierachical namespace is a mere political decision, rather than a fact > of math. Those are people who think that, with the application of > enough political oversight, key escrow is a perfectly good idea for > the world rather than a giant security vulnerability waiting to be > exploited. And those are people who think that internetwork-style > connectivity as opposed to a dramatically more centralized style is > _simply_ a political question, rather than one that has technical > follow-on consequences with their own technical implications. >=20 > There is a limnable difference between "technical decision that has > consequences for politics" and "simply a political question". I think > we need to be careful about that, both for political reasons (what it > might drag us into) and technical reasons (what it might make possible > or impossible). --------------ms020302020602070409010802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMTMy MzAzMTRaMC8GCSqGSIb3DQEJBDEiBCAnu6eNwp5efHJqkZlDZfrxPhVUE+j6z/8xJ4iAGqlt xjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCuC31NRt3++2dMTQzQGNOLBc/VvDdTlXn7XZ031GhrKV6bx9WuTEHS p8B6SZT/+KKEDN4FMrGBusFAc4grebXlI9eZGUSyhS0sTxENslPwR858eNqzjgrrCy5Vno8n JQ8ppO7S8FTMD0OJj+HPs3HaeqL+N0/ImeCSe1GXO3sWstoFbq6GcPwdagCaV/r4UJH6lCaC nyrS4kcEpsfBOTVsUO4xAfx7sRD3yewzJrZodnLhLHIsHBCcuu9cWwWLKYsVmoP1PcMJRwNO NFSHkFvmFHZpz/qtOnvf3InoeyptSFfXiL+muKeOdVtaAVD9fx1Trx72JBq6OE/GUFWm2J9u AAAAAAAA --------------ms020302020602070409010802-- From nobody Fri Jan 13 15:58:39 2017 Return-Path: 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 8A117129F7C for ; Fri, 13 Jan 2017 15:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sOQwnkjQxP5L for ; Fri, 13 Jan 2017 15:58:37 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id ED6351294A7 for ; Fri, 13 Jan 2017 15:58:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 0856A1154D for ; Fri, 13 Jan 2017 23:58:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR7ZHy4f7CaS for ; Fri, 13 Jan 2017 23:58:36 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 266D01153D for ; Fri, 13 Jan 2017 23:58:36 +0000 (UTC) Date: Fri, 13 Jan 2017 18:58:33 -0500 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20170113235833.GF662@mx2.yitter.info> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> <20170113213519.GA21524@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170113213519.GA21524@sources.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 23:58:38 -0000 On Fri, Jan 13, 2017 at 10:35:19PM +0100, Stephane Bortzmeyer wrote: > > > "The purpose of the Internet to be a global network of networks that > > provides unfettered connectivity to all users and for any content > > [RFC1958]." -> I couldn't find this statement in RFC 1958. > > I suggest to follow the classical rule: when it is between quotes, it > is a litteral statement. Otherwise, it can be a summary or a > synthesis. > > Here, there are in the draft no quotes around the sentence you > mention, meaning clearly that it was not supposed to be an exact > citation. I think I also noted, however, that the interpretation offered was considerably broader than the text in 1958 would justify if the latter were read strictly. This has not been fixed in the latest version I checked in github. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Jan 14 13:47:24 2017 Return-Path: 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 090DF12949F for ; Sat, 14 Jan 2017 13:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 d0iHbJ5HbTi6 for ; Sat, 14 Jan 2017 13:47:21 -0800 (PST) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADFD126579 for ; Sat, 14 Jan 2017 13:47:21 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id v0ELkmOt016351; Sat, 14 Jan 2017 16:46:50 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id v0ELiobq019604; Sat, 14 Jan 2017 16:44:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22650.39890.626181.942997@gargle.gargle.HOWL> Date: Sat, 14 Jan 2017 16:44:50 -0500 From: bzs@theworld.com To: Stephane Bortzmeyer In-Reply-To: <20170113213519.GA21524@sources.org> References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> <20170113213519.GA21524@sources.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Cc: Niels ten Oever , "Bless, Roland \(TM\)" , Corinne Cath , hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 21:47:23 -0000 On January 13, 2017 at 22:35 bortzmeyer@nic.fr (Stephane Bortzmeyer) wrote: > > "The purpose of the Internet to be a global network of networks that > > provides unfettered connectivity to all users and for any content > > [RFC1958]." -> I couldn't find this statement in RFC 1958. It's interesting how the definition of "internet" (even discounting big "I" vs little "i") has evolved over the years. Early on it was mostly used to describe a network which used different media in a reasonably transparent way. Today that might be wi-fi and ethernet. 35+ years ago media tended to define a network if for no other reason than the media or its usage within a network was usually proprietary. Not much later the idea that it could tie together networks with otherwise incompatible protocols such as NCP, DECNET, UUCP, SNA, BITNET, Netware, CHAOSnet, etc became very popular much like the concurrent idea that higher-level programming languages could produce code for very different architectures, and even operating systems (Unix-like) became largely architecture-independent. So the "internet" largely focused on either gatways which for example moved email or other services between these otherwise incompatible networks, or the beginnings of what we'd call today virtual networks which could carry otherwise incompatible protocols typically for long-distance haul (e.g., UUCP over TCP/IP.) As media compatability became taken for granted and most of the other network protocols faded into obscurity the concept began to move to a more political and administrative meaning -- that the internet tied together separately administered but technically mostly identical networks. [THE POINT] So one can quote a platitude such as the above but what the words actually were intended to mean tends to be embedded in either its own ancient or some current historical context. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Mon Jan 16 01:03:35 2017 Return-Path: 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 929F0129401 for ; Mon, 16 Jan 2017 01:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 1N2UfaX1ZuB3 for ; Mon, 16 Jan 2017 01:03:30 -0800 (PST) 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 8588A12948A for ; Mon, 16 Jan 2017 01:03:29 -0800 (PST) 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 1cT3CH-000081-Fg; Mon, 16 Jan 2017 10:03:25 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 53E6FB0025A; Mon, 16 Jan 2017 10:03:25 +0100 (CET) To: Stephane Bortzmeyer References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> <20170113213519.GA21524@sources.org> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <2e44a308-63a0-bae8-3e92-1c5b12babf44@kit.edu> Date: Mon, 16 Jan 2017 10:03:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170113213519.GA21524@sources.org> 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 1484557405. Archived-At: Cc: Corinne Cath , Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 09:03:33 -0000 Hi Stephane, Am 13.01.2017 um 22:35 schrieb Stephane Bortzmeyer: > On Thu, Jan 12, 2017 at 01:14:41AM +0100, > Bless, Roland (TM) wrote > a message of 462 lines which said: > >> In many cases it remains unclear how/why certain human rights are >> listed in figure 2 and section 4 while others aren't. This really >> needs to be fixed IMHO. > > There is a good reason to not treat all human rights alike. Some are > already well-covered in IETF work (such as privacy in RFC 6973). I > think we should focus on rights which have not been, until recently, > explicitely discussed in the IETF (such as freedom of expression). Agreed, but this wasn't my point. I think that some human rights aren't listed which should be there, I gave hints for section 4 with respect to that. However, since the rationale is missing, it's unclear why some are there, but others which hare related IMHO aren't listed. >> define "human rights" there > > I think it is not up to the IETF/IRTF to define human rights and we > should defer to an external definition (the draft currently uses the > UDHR, which I think is a good idea). May be a sentence in the > terminology section like "Human rights: the rights of every human > being, as defined in the Universal Declaration of Human Rights [Ref]"? Yes, that was what I meant, since there are several definitions out there and it's unclear which ones are used within the draft. It should also include a list of HRs which are considered within the draft. That would make it clearer to read the draft without checking the original definitions. >> "The purpose of the Internet to be a global network of networks that >> provides unfettered connectivity to all users and for any content >> [RFC1958]." -> I couldn't find this statement in RFC 1958. > > I suggest to follow the classical rule: when it is between quotes, it > is a litteral statement. Otherwise, it can be a summary or a > synthesis. Yep, but in this case it's neither literally nor as synthesis contained. > Here, there are in the draft no quotes around the sentence you > mention, meaning clearly that it was not supposed to be an exact > citation. Yes, but I tried to explain that I wasn't able to extract this statement - even as summary - out of RFC 1958 and that's IMHO really misleading. Otherwise, I'd really like to see a more specific pointer to the content where that statement was derived from... >> Usually Authenticity includes data integrity as defined in RFC4949 >> (just stating that it is strongly linked with integrity is IMHO a >> bit too weak). > > Agreed. Authenticity without integrity is almost useless. > >> The fix is >> probably as follows: >> "Internet censorship is the intentional suppression of otherwise >> freely accessible information originating, flowing or stored on >> systems connected to the Internet where that information is >> relevant for decision making to some entity." (based on [Elahi]). > > No. If a system deletes my *private* messages (content which was not > "freely accessible information"), it is still censorship. Yes, that's probably correct, so my proposal to fix it doesn't seem to work :-) However, I'm not sure that a firewall that is used to protect business secrets is really "Internet censorship" and that was my point of the more general statement. Regards, Roland From nobody Tue Jan 17 05:30:29 2017 Return-Path: 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 81441129418 for ; Tue, 17 Jan 2017 05:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 zTGZalggK_ug for ; Tue, 17 Jan 2017 05:30:25 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 550CB126FDC for ; Tue, 17 Jan 2017 05:30:24 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cTTq9-00008R-0K; Tue, 17 Jan 2017 14:30:22 +0100 From: Niels ten Oever To: "Bless, Roland (TM)" , hrpc@irtf.org, Corinne Cath References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> Message-ID: Date: Tue, 17 Jan 2017 14:30:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="78MJ0Ho41q7i5ORinsG92PQ4ta1PIlm2m" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: a1d92489c29b984e4d64e980f11d05e4 Archived-At: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 13:30:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --78MJ0Ho41q7i5ORinsG92PQ4ta1PIlm2m Content-Type: multipart/mixed; boundary="Q7fR7D3E2BTMcejwhrnXduns4Akfrk2ju"; protected-headers="v1" From: Niels ten Oever To: "Bless, Roland (TM)" , hrpc@irtf.org, Corinne Cath Message-ID: Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07 References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> In-Reply-To: <38768631-3503-e50c-c7c6-455a8079da56@kit.edu> --Q7fR7D3E2BTMcejwhrnXduns4Akfrk2ju Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks a lot for the extensive review Roland, reply inline: On 01/12/2017 01:14 AM, Bless, Roland (TM) wrote: > Hi, >=20 >> There are some inaccuracies with the vocabulary section and I have >> several comments for section 4. I'll come back to that later in more > detail. >=20 > This write-up took much longer than expected... > Since other work prevented me to follow the hrpc list closely in the > last weeks, I apologize for repeating some comments that others already= > made. >=20 > tl;dr: > Major issue from my perspective: > the rationale why certain technical concepts or properties impact > particular human rights is often missing. In many cases it remains > unclear how/why certain human rights are listed in figure 2 and > section 4 while others aren't. This really needs to be fixed IMHO. >=20 That is pretty clearly addressed and outlined in section 3.2.2, right? > Detailed comments: >=20 > Abstract: > --------- > IMHO the abstract should not start with a "list of sections" it > provides. It should rather start with the main issue of providing > considerations on human rights in protocols (or protocol design), > comprising proposals for consideration guidelines, vocabulary, > and a description of the methodology as well as a coarse literature rev= iew. I think this is a good suggestion, so I cut the first sentence into two and changed the order of thing. The abstract reads now: This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations {{RFC6973}}. This is achieved by providing a proposal for a vocabulary to discuss the relation between human rights and Internet protocols, an overview of the discussion in technical and academic literature and communities, a proposal for the mapping of the relation between human rights and technical concepts, as well as guidelines. If you want to see how to apply this work to your own, you can directly go to . The rest of the document explains the background of the guidelines and how they were developed. >=20 > Introduction: > ------------- > I find it a bit confusing to directly start with citations without > setting the context first, so probably move the citations somewhere > into the text, where they fit. >=20 I think it's a good habit to have a quote at the beginning to set the ton= e. > In a broader sense, protocols touch also other values, not only > human rights. So probably, a short motivation should be given, why > this draft/RG concentrates on human rights. >=20 That's what the first paragraph of the introduction does imho. > While the draft talks a lot about human rights, it doesn't list > a few of them as examples (e.g., at least those used later in section > 4). Therefore, I propose to extend the vocabulary and also define > "human rights" there (it's probably enough to list some of them and > repeat the references for further details...). I drafted this: Human rights : Human rights are principles and norms that are indivisible, interrelated, unalienable, universal, and mutually reinforcing that have been codified in national and international bodies of law. The Universal Declaration of Human Rights {{UDHR}} is the most well-known document in the history of human rights. The apirations from this documents were later codified into treaties such as the {{ICCPR}} and the {{ICESCR}}, after which signatory countries were obliged to reflect them in their national bodies of law. There is also a broad recognition that not only states have an obligations vis a vis human rights, but non-state actors do so as well. >=20 > Typo: "This has led to an broad" -> "This has led to a broad" >=20 Thanks - added > "The purpose of the Internet to be a global network of networks that > provides unfettered connectivity to all users and for any content > [RFC1958]." -> I couldn't find this statement in RFC 1958. > (general comment: please be more accurate when you cite documents, this= > also applies to several other places, esp. in the vocabulary, see below= ). > RFC 1958 talks about connectivity as a goal of the Internet > architecture, but doesn't mention "unfettered connectivity to all users= > and for any content". Stephane already responded to this, it is not a literal quote but a synpo= sis >=20 > "Additionally, access to information gives people access to knowledge..= =2E" > -> probably qualify this by using "generally accessible information" > or "freely available information" (some information on the Internet > isn't freely accessible or available for all on purpose). Thanks added. >=20 > "In order to do this it is crucial that the rights impacts are clearly > documented in order to mitigate the potential harm in a proportional > way." -> I find this statement problematic. > Sometimes the impacts are complicated since several rights > may be affected at once. Moreover, how to actually balance between > conflicts isn't clear at all sometimes. > So I don't know what "mitigate the potential harm in a _proportional > way_" actually means nor how to achieve it... >=20 I think this is addressed in section 4.1.1: Note that the guidance provided in this section does not recommend specific practices. The range of protocols developed in the IETF is too broad to make recommendations about particular uses of data or how human rights might be balanced against other design goals. However, by carefully considering the answers to the following questions, document authors should be able to produce a comprehensive analysis that can serve as the basis for discussion on whether the protocol adequately protects against specific human rights threats. This guidance is meant to help the thought process of a human rights analysis; it does not provide specific directions for how to write a human rights protocol considerations section (following the example set in {{RFC6973}}), and the addition of a human rights protocol considerations section has also not yet been proposed. > Vocabulary: > ----------- >=20 > "Authenticity" -> while other security terms are taken from RFC 4949, > this one isn't (any other reference for this particular definition?). > Usually Authenticity includes data integrity as defined > in RFC4949 (just stating that it is strongly linked with integrity > is IMHO a bit too weak). Thanks for this. I used the definition from RFC 4949. About merging with integrity, not sure. Alissa in her review just stimulated us to address them seperately. >=20 > Confidentiality: the definition isn't correct (unintended -> > unauthorized) and also isn't taken literally from RFC 4949 although > referenced... better replace it with the definition from RFC4949. >=20 Done, thanks. > End-to-End: > - Typo "principal -> principle" > - This definition here mixes "end-to-end transparency" issues with > the "end-to-end argument in systems design" (the Saltzer, Reed, Clark= > paper). I think it is indeed > clearer to separate the two (see also > https://tools.ietf.org/html/rfc2775 and > https://tools.ietf.org/html/rfc4924). > IMHO the statement "Functionality should be expanded at the end-point= s to > ensure that the network interconnects rather than controls." > is somewhat confusing and doesn't reflect the end-to-end argument: > Application-specific functions should not be embedded into the > network and thus stay at the end-points: in many cases, esp. > when dealing with failures, the right decisions can only > be made with the corresponding application-specific knowledge, > which is available there. So the quoted statement is too general > (just speaks of functionality), the meaning of "expand" is unclear > and some control functions (e.g., routing) are even necessary for > providing the interconnection between networks. Consequences > of the end-to-end argument are robustness and (easier) innovation > at the edges. >=20 > - I don't understand the point of the following text > "For example, end-to-end instant message encryption would conceal > communications from one user's instant messaging application..." > in this context. From the Internet layer perspective encryption > between an instant messaging client and an intermediate server > using TLS is end-to-end. From the application layer > perspective, it is not really end-to-end (user-to-user) encrypted. > Moreover, in many cases only content can be protected end-to-end > while some meta-data (mostly in form of protocol headers) need to > be processed by intermediate nodes. Changed the typo. Used your suggested language (application-specific functions... application specific knowledge) in the introduction. For the second half, clarified that we are referring to the end-to-end argument as laid out in saltzer et. al. and mentioned that further aspects of end-to-end connectivity can be found in RFC 2775. Changed text became: One of the key architectural guidelines of the Internet is the end-to-end principle. The argument in favor of the end-to-end approach to system design is laid out in the fundamental paper by Saltzer, Reed, and Clark {{Saltzer}} {{Clark}}. In it, the authors argue in favor of radical simplification: systems designers should only build the essential and shared functions into the network, as most functions can only be implemented at network end points. Building features into the network for the benefit of certain applications, will come at the expense of others. As such, as a general system designers should attempt to steer clear of building anything into the network that is not a bare necessity for its functioning. Following the end-to-end principle is crucial for innovation, as it makes innovation at the edges possible without having to make changes to the network, and the robustness of the network. >=20 > Integrity: the used definition references RFC 4949 again, but isn't > taken from there. Please use the one from 4949: > data integrity: > "The property that data has not been changed, destroyed, or > lost in an unauthorized or accidental manner." >=20 Thanks - replaced. > Internet censorship: while correctly cited from [Elahi], > the definition is somewhat imprecise, since there is > definitely information available in the Internet at > some servers that is access controlled etc. for good reasons, > e.g., in order to prevent its unauthorized disclosure. That > confidential information is also in many cases relevant > for decision making. According to the definition this > "protected confidential information" is censored. The fix is > probably as follows: > "Internet censorship is the intentional suppression of otherwise > freely accessible information originating, flowing or stored on > systems connected to the Internet where that information is > relevant for decision making to some entity." (based on [Elahi]). >=20 Thanks - added. > Interoperable: I don't understand what "without any restricted access o= r > functionality." means here. Restricted access to what? > Moreover, I think that "interoperable" is more a property of > _implementations_ rather than the protocol specification: > usually one checks whether two independent implementations > (originating from the same protocol specification) interoperate with > each other. >=20 Fair point. Changed into: Interoperable : A property of a documented standard or protocol which allows different independent implementations to work with each other without any restriction on functionality. > "Open Standards Conform": though I'm not a native speaker, I think > it should be "Open Standards Conforming" or "Conforming to Open > Standards". The reference RFC2606 is incorrect, it should be RFC2026? >=20 Thanks, made it: Conform with {{RFC2026}} ..... > Openness: not so clear what is meant here. Unrestricted access to > freely accessible hosts or content, i.e., the absence of Internet > censorship? How is it different from accessibility? >=20 Removed the first definition and left the second from Brown. > Reliable -> Reliability >=20 Changed. > Scalable -> Scalability > Scalability is usually defined with respect to certain specific > system parameters (e.g., number of end-systems, users, data flows, > routing entries. etc.). Moreover, growth/shrinkage of these > parameters is typically considered by orders of magnitude. Made it: Scalability : The ability to handle increased or decreased system parameters (e.g., number of end-systems, users, data flows, routing entries. etc.) predictably within defined expectations. There should be a clear definition of its scope and applicability. The limits of a systems scalability should be defined. Growth or shrinkage of these parameters is typically considered by orders of magnitude. >=20 > Connectivity: > - This term needs to be sorted into the right order... > - typo enableing -> enabling (several occurrences in the draft). Fixed > - I'm not sure, but I think that the distributed/decentralized > nature of the Internet is also important for connectivity > (providing alternative choices of access and routes). Added. >=20 > Methodology: > ------------- > analysis.The results.... =3D> analysis. The results.... Fixed. >=20 > 3.2.1.1. Mapping protocols and standards related to human rights >=20 > Not sure, but either delete "related" or rephrase as "Relating protocol= s > and standards to human rights". Fixed. >=20 > "By combining data from the three data sources named above, an > extensive list of protocols and standards that potentially enable th= e > Internet as a tool for freedom of expression and association." >=20 > That sentence is missing a verb, e.g., "an extensive list .... was > created" (or rephrase accordingly to avoid passive voice...). Thanks >=20 >=20 >=20 > 3.2.1.2. Extracting concepts from mapped RFCs >=20 > "mapped RFCs" sounds IMHO a bit odd, maybe replace with "selected RFCs"= =2E >=20 > Mapping the protocols and standards that are related to human rights= > and create a human rights enabeling environment was the first step. >=20 > Suggestion: >=20 > Identifying the protocols and standards that are related to human > rights and create a human rights enabling environment was the first > step. >=20 >=20 Accepted and added > 3.2.1.3. > While interviewing experts, mapping RFCs and ... >=20 > =3D> While interviewing experts, investigating RFCs and ... >=20 Accepted and added > 3.2.1.4. > The previous steps allowed for the clarification of relation between= > =3D> > The previous steps allowed for the clarification of relations betwee= n >=20 Accepted and added > This section and the following use many different terms, probably for > the same item: technical definition(s), technical concept(s), technical= > term(s) and figure 1 finally uses "architectural principles". >=20 > "allowing for the creation of a list > of technical concepts that when combined create an enabling" > =3D> > "allowing for the creation of a list > of technical concepts that, when combined, create an enabling" >=20 Accepted and added with amendment. > It is unclear whether one needs to combine _all_ of the technical > concepts or only some of them.=20 I made the text into this: On the basis of this list a number of technical concepts that appeared frequently was extracted, and used to create a second list of technical terms that, when combined and applied in different circumstances, create an enabling environment for excercising human rights on the Internet. They need to be applied in different ways, in different cases. There is no homogeneous implementation regime in all protocols and implementations. It is a case by case basis, based on universal principle= s. > Moreover, do we have a "proof" that > this is really the case? The text in 3.2.2 suggests that we probably > have merely hints for the mappings rather than actual evidences or > a very deep understanding of the exact relations between the > technical concepts and human rights. > So I suggest to weaken the statement a bit: > "allowing for the creation of a list of technical concepts that, when > partially combined, _can_ create an enabling" > the same applies to 3.2.1.5. and its title, which is basically a repeti= tion. >=20 Accepted and changed. > figure 1: > it appears to me as if some of the terms are more (system) > properties (the figure mentions characteristics) rather than principles= =2E Changed. > We may have/know principles that lead to the mentioned > properties if applied during design, deployment or operation. > Examples: > - Simplicity. Applying minimality principles (KISS or also > the end-to-end argument) may result in simpler systems that eventually > lead to higher robustness (rfc3439 discusses this in more depth). > - Resilience. Every principle that increases robustness may lead > to higher resilience, e.g., fate-sharing/statelessness, > end-to-end principle, soft-states, Postel principle, decentralized > design, etc. >=20 > Transparency -> this is missing in the vocabulary. Since transparency > is actually used in very different meanings (transparent=3Dverifiable, > traceable, comprehensible and sometimes even invisible) a clarification= > would be good. >=20 I started writing on a lemma for transparency and pretty soon indeed got in quite some trouble. As you clearly indicated transparency can mean quite a few different things, often also the exact opposite: https://en.wikipedia.org/wiki/Transparency_%28human%E2%80%93computer_inte= raction%29 So instead of writing three paragraphs about all possible definitions of transparency I'd like to offer this: Transparency : In this context transparency is linked to the comprehensibility of a protocol in relation to the choices it makes for both user and protocol developers and implementers. > Heterogeneity -> Heterogeneity support Changed >=20 > figure 2: > - the left column lists not only technical concepts but also (desired) > properties. Which (desired) property in the left column is not a technical concept? > - the rationale why the specific rights are impacted by the technical > concepts or properties are the most interesting part and actually > missing in the description. It would be very valuable to provide a > paragraph for each row in section 3.2.2 that explains why there is > a relation between the concepts/properties and the particular rights.= > For example for the first row: "Connectivity is required, because > the individual that wants to provide information for others needs > means to reach potential recipients. Privacy is helpful in case ..." > Section 4 seems to partially contain some of the reasoning, however, > I think that it would be better to move it here. >=20 whereas I agree it would be interesting to do this, I think it would also easily add twenty pages to the draft, which I think would not necessarily add much to the usability and readability of the draft. Furthermore, we will need to do more research to create a more exhaustive list. So I will defintely put this on the to do list of the group. We are actually exactly trying this with the new Anonymity draft. > - typo in caption: excise -> exercise >=20 Changed > 3.2.3. > The goal here is to > show, with actual examples, that the design of protocols have > practical consequences for some human rights and these consequences > have to be considered at design time. > =3D> The goal here is to > show, with actual examples, that the design of protocols have > practical consequences for some human rights and these consequences > should be considered at the design time already. >=20 The goal here is to show, with actual examples, that the design of protocols have practical consequences for some human rights and these consequences have to be considered in the design phase. > "have to be" is IMHO too strong. Why? What is the difference here with should? This is an informational document so RFC2119 does not apply. > network core can make policy decisions and enforce policy shaping an= d >=20 > I'm not sure what meant here by "policy shaping", but probably > policy-based traffic shaping is meant as recently described in > http://dl.acm.org/citation.cfm?id=3D2934873 (freely accessible via > http://conferences.sigcomm.org/sigcomm/2016/program.php). Thus, > probably rephrase as: > =3D> network core can make policy decisions and enforce policy-based > traffic shaping and >=20 Changed. > Typos: >=20 > helping us understand which technical protocol decisions have led to= > harm of this human > =3D> helping us to understand which technical protocol decisions have l= ed > to harm of these human Fixed >=20 > 3.2.3.1.1. > APIP (http://dl.acm.org/citation.cfm?id=3D2626306) and Hornet > (http://dl.acm.org/citation.cfm?id=3D2813628) could be mentioned as > alternative designs. >=20 Added. > Typo: > to choose a per defined > =3D> > to choose a pre-defined >=20 Fixed > 3.2.3.1.2. > [RFC1631] is obsoleted by RFC 3022 >=20 Fixed > I skipped most of the rest of section 3... >=20 > Section 4 > --------- > The sub-structure 4.1 -> 4.1.1 doesn't make so much sense since there i= s > no 4.2 or > 4.1.2 etc. >=20 Fixed (markdown issue). > 4.1: > Typos: > This sections details > =3D> > This section details >=20 Fixed >=20 > or proritize some > =3D> > or prioritize some >=20 Fixed >=20 > analysis that can serve as the basis for discussion on whether the > protocol adequately protects against specific human rights threats. >=20 > maybe add text that it may stimulate authors to think about alternative= > designs choices.. Added. >=20 > The following sections also do not always contain a rationale > why certain listed human rights are potentially affected adversely. >=20 >=20 > 4.1.1.1.1 Connectivity >=20 > I'm really not convinced that the end-to-end argument directly > relates to connectivity rather than to permissionless innovation, > resilience and robustness... >=20 > the example of end-to-end encryption would be more suitable for > Privacy and doesn't cover the problem of nevertheless visibile metadata= =2E >=20 Added explanation as to how end-to-end, in particular robustness relates to human rights. Removed the example related to end-to-end encryption, substituted it with an example of middle boxes and connectivity. > For connectivity I would also expect the > right to access to be listed as potentially impacted > (without proper connectivity, certain freely available > information cannot be accessed). >=20 What do you mean with the right to access? The right to political particpipation or the right to freedom of expression (which includes the freedom to receive and impart information)? I guess the latter, which I added. > 4.1.1.1.3. > Typo: priotization =3D> prioritization >=20 Fixed > 4.1.1.1.4. > =3D> What about a right to security? >=20 Added > 4.1.1.1.5. > - Right to political participation >=20 > is listed twice Fixed >=20 > 4.1.1.1.7. Open Standards >=20 > Typo: > The Internet was able to developed > =3D> > The Internet was able to be developed >=20 Fixed > 4.1.1.1.8. >=20 > Typos: > to allow open innovation possibly have security and privacy > ramifications, and if so,how can these be dealt with? > =3D> > allow open innovation possibly have security and privacy > ramifications, and if so, how can these be dealt with? >=20 > I don't understand how this related to the "right to security" > while I'm missing the > right to access or participation Agreed, removed and added. >=20 > 4.1.1.1.9 >=20 > to achieve, it is non-binary concept. Making pervasive monitoring > =3D> > to achieve, it is a non-binary concept. Making pervasive monitoring= >=20 Fixed. > 4.1.1.1.10 > generates or processes anything that can be, or be tightly correlate= d > =3D> > generate or process anything that can be, or be tightly correlated >=20 Fixed > 4.1.1.1.11 > "Could your protocol also be developed in a stateless manner?" >=20 > I don't understand how this would improve accessibility... >=20 In case of high latency and low connection speeds a connection might be more reliable without state. > 4.1.1.1.12 > the difference to internationalization is not that clear to me... >=20 Localization is the pratice, internationalization is the technical pre-condition to do so; "Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language." {{W3Ci18nDef}} > 4.1.1.1.13 > I'm missing the Right to access (a decentralized architecture allows > probably more points of access to the network). >=20 Right to Freedom of Expression added. > 4.1.1.1.14 > This could make use of statelessness and soft-states as technical princ= iples >=20 > Why is only the right to security listed here? Right to access would > also fit here... >=20 Right to freedom of expression added >=20 > 4.1.1.1.15 >=20 > what about the right to privacy? >=20 Yes, of course. Added. > 4.1.1.1.16 >=20 > Question(s): Does your protocol maintain and assure the accuracy of > data? Does your protocol maintain and assure the consistency of > data? Does your protocol in any way allow for the data to be > (intentionally or unintentionally) altered? >=20 > I think these are flawed (cf. also my criticism on the definition > in the vocabulary). Especially, "Does your protocol in any way allow fo= r > the data to be > (intentionally or unintentionally) altered?" doesn't make much sense to= me. > I suppose that the question consideres alteration while data is in tran= sit. > Which data is meant here? Protocol control information, i.e. headers, > usually needs to be altered in transit, whereas payload data probably > shouldn't be modified.=20 Added /s/data/payload data > Normally, protocols cannot really > "prevent" that data is modified in transit, but they can have measures > to detect > any unauthorized modification. >=20 /s/maintain and assure/"maintain, assure and/or verify" > This impacts also the right to freedom of expression since > censoring measure can lead to unauthorized modification of > data. Agreed, added. >=20 > 4.1.1.1.17. >=20 > Impacts several other rights, e.g., right to privacy, right to freedom > of expression etc. because in some cases that origin can be clearly > identified which discloses information sources. >=20 Agreed, added. > 4.1.1.1.18. > Adaptability is closely interrelated permissionless > =3D> > Adaptability is closely interrelated to permissionless >=20 Changed into: Adaptability is closely interrelated with permissionless innovation, > ---- > so much for now... >=20 Thanks again for this very thorough review. Cheers, Niels and Corinne > Regards, > Roland >=20 >=20 --Q7fR7D3E2BTMcejwhrnXduns4Akfrk2ju-- --78MJ0Ho41q7i5ORinsG92PQ4ta1PIlm2m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAlh+HGsACgkQDtg/OkaK yLPcbw//RtS06205EVPo3Gm7fL5iFqUp1A+rMAjBo22FdiAiwCEjn5H/NR/mYVNk 6I5oV59ANU+uWMFdV6pX3kUCS20vm+huGfMWADpRtXfDr+kRdmo0rD4h8UBCtdUR V+BS5eJldMn+KKiRFh9OTdO5UWG8AN2pebNA0W28anED2Pe4pP7rMOsVAxc/cxH1 Tl0Lh0Z+GuoUbewbE4WUHhhpg/R/tFQ98PIpHvy+jK+e/U6K1KtGMFqjZWm0oMhR 342oIzfccE6WD/fRQWWQMiL4fYWsvHdMaMhYbsVy5jqACmkirAx6XuP9kqCr4GP8 4oKro3A6kZ9aFymwHi2uie0Vk/J3/d6j2TzTbbQgYDhfMyn/0cefSV6kHS4zEItm 3K12GlW/UOL2AQ3n6mqhvHqFq3dle5dKXFFueTjYufhlGRH4SfnKFOKjT7X+OsdO DgKl2TgCfj/Y9CqQN4ZOKxOfxFGJXiVI6lIfOO9YcaFj+EUf3SxyWlUULTH0/t/F CTIepmDIDSeHsiGQYCgLo1L37U580NWW2GJM/0mtOlgNEuCXWmes7beU8k5CEIlX vnUJoSPrHluMlOS3+5Yhl5LuNrf65Jl0Q4XA+kREcRUCYdBxAncN2BpPaCRHRUEQ LVaQKaRdktdsRoSWW364a8Lvv2bzqvHmpJ0EWYHRENLsSyrJMPI= =yFj+ -----END PGP SIGNATURE----- --78MJ0Ho41q7i5ORinsG92PQ4ta1PIlm2m-- From nobody Tue Jan 17 14:36:46 2017 Return-Path: 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 A3EBA1295A5 for ; Tue, 17 Jan 2017 14:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 1BDsFiWyYTIT for ; Tue, 17 Jan 2017 14:36:42 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 0F84E1294A1 for ; Tue, 17 Jan 2017 14:36:41 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cTcMl-0001bv-IY; Tue, 17 Jan 2017 23:36:36 +0100 From: Niels ten Oever To: S Moonesamy , hrpc@irtf.org References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> Message-ID: Date: Tue, 17 Jan 2017 23:36:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20170106104124.102ab508@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QQErpibJuOXKuNQXOPfb49f5J4cpVgKHu" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4f71c219e509acf9077fe043d52904d9 Archived-At: Cc: Corinne Cath Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:36:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QQErpibJuOXKuNQXOPfb49f5J4cpVgKHu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi S. Moonesamy, Reply inline: On 01/07/2017 01:35 AM, S Moonesamy wrote: > Hi Niels, > At 05:37 06-01-2017, Niels ten Oever wrote: >> I think this draft does exactly the opposite, but please educate me in= >> how you think this happens. >=20 > My guess is that there isn't consensus in the IETF on the UDHR as there= > hasn't been any IETF discussion about that. =20 I don't think the UDHR needs IETF consensus. > What this draft does is > that it takes values from an international political context and tries > to apply that within a standards-setting context. The Introduction > Section borrows a sentence from "the mission" which was written over a > decade ago. Is "the mission" to turn the internet in "a human rights > enabling environment"? =20 I don't think the mission would be at odds with that. > Are there IETF participants (and attendees) who > reside in "difficult" countries? Would those persons feel comfortable > discussing about human rights publicly within the IETF? >=20 I do not know. > Is censorship resistance viewed as acceptable by most of the IETF > attendees from the 53 countries? Were there views from attendees who > are impacted by that? Do those persons agree that censorship resistanc= e > is a technical concept? If you have an posiyion about this it would be great to hear your argumen= ts. >=20 >> May I also point to the report by the UN Special Rapporteur which made= >> the point about responsibility of standards bodies vis a vis freedom o= f >> expression and other human rights, which has been adopted by the Human= >> Rights Council. So this is hardly a concern of a geographically limite= d >> group. >=20 > The report makes a recommendation about ensuring that there is > "meaningful civil society participation in policymaking and other > standard-setting processes". It recommends that "Private entities > ensure the greatest possible transparency in their policies, standards > and actions that implicate the freedom of expression and other > fundamental rights". Is the IETF part of "private entities" or > "international organizations"? =20 The IETF is indeed a private entity. > Shouldn't it be the responsibility of a > person, company or organization with a strong interest in freedom of > expression to make his/her/its case? >=20 Not sure what is meant by this. > The issue observed by the Commission on Science and Technology for > Development of the United Nations is that "meaningful [IETF] > participation requires a generally high level of technical expertise, > human rights perspectives are not always included in discussions, even > though technical and design choices can have a substantial impact on > freedom of expression". I would not disagree with that observation as,= > based on my experience, it is definitely not easy to meaningfully > participate in the IETF discussions if the person does not have an > adequate level of technical expertise to understand where the technical= > choice is being made and the policy implications. >=20 > I suggest relying on statistics to determine whether this group is > geographically limited or not as such facts can be easily verified. >=20 I am not sure what the consequences of a conclusion on this would be. As said, we have been aiming to get quite a lot of input on this draft, and we had reviewers and contributors from different continents. >> I don't think that is true. We've had involvement in the discussion fr= om >> people from all continents and have also tried to broaden the input by= >> doing interviews, next to the discussions in the RG sessions of course= =2E >=20 > It would be more convincing if there were public reviews from people > from all continents. >=20 It would be great if you could help us find a reviewer from Africa. Then we would have reviewers from all continents. >> I think the key word in that sentence is _could_. I do not see a >> discrepancy between the charter and that remark. >=20 > Did the RG Chairs request feedback from the relevant IETF body to find > out whether the "could" is acceptable or not? >=20 What IETF body do you mean? And what has that to do with a text on an external website? >> Then I do not get the point. Could you restate it or offer text? >=20 > Let's take the case of a person from civil society lobbying against > corruption in his/her country. Given the risks that the person may > face, can he/she rely on the security mechanisms recommended by the IET= F > or should he/she do some due diligence? The point is that there isn't = a > "one size fits all" security. >=20 >> I agree this is an issue, but not within the scope of this draft. >=20 > Ok. >=20 >> So you propose changing: >> >> Does your protocol have text strings that have to be understood or >> entered by humans? Does your protocol allow Unicode? If so, do you hav= e >> accept texts in one charset (which must be UTF-8), or several (which i= s >> dangerous for interoperability)? If character sets or encodings other >> than UTF-8 are allowed, does your protocol mandate a proper tagging of= >> the charset? Did you have a look at {{RFC6365}}? >> >> I think the last sentence add useful information. Why leave it out? >=20 > The last sentence is about making it possible for the charset to be > identified at the receiver's end. That does not mean that the > information which was transmitted will be rendered correctly at the > receiver's end as that charset may not be supported. In essence, the > tagging indirectly causes an interoperability issue. Although the > following is not a good example I'll use it for an explanation: > https://habrahabr.ru/post/130511/ The webpage is sent with > "charset=3Dutf-8". It should display correctly in any up-to-date web > browser. What if the webpage was sent as "charset=3Diso-8859-5"? The > up-to-date web browser would require support for that charset to be abl= e > to display the webpage correctly. It is not worthwhile to diverge from= > the recommended UTF-8 as it would be quite an effort to solve the > internationalization issues. >=20 I agree, but not all scripts are serviced by UTF-8, that is the reason for this addition, so if someone uses something else, it should be properly tagged. >> I agree this is an IETF-wide issue. But that also makes it fall outsid= e >> of the scope of this draft. >=20 > One of the issues in the draft is that it goes into open standards. It= > might be easier to stick to protocol discussions and leave out "open > standards". >=20 > The first reference in the draft is to a book which costs USD 12.95. I= t > is at odds with the "not available without cost". >=20 The reference is not to an open standard. >> That makes it not a standard, but it is still a protocol. I tihnk this= >> exactly shows how a protocol can make use of permissionless innovation= >> to combine uses of different protocols in other ways than it was >> originally intended. >=20 > According to Adam Thiere "permissionless innovation" is the idea that > experimentation with new technologies and business models should > generally be permitted without prior approval [from government]. It is= > a bit like Uber. I unfortunately have to disagree with the above respo= nse. >=20 I think the definition follows the one of Adam Thiere, and he does not solely aim at governments as you indicate between square brackets. https://www.cato.org/publications/cato-online-forum/embracing-culture-per= missionless-innovation >> Which question? There is a definition, there is an explanation among >> different topics (connectivity, open standards, adaptability). >=20 > I commented about this above (re. permissionless innovation). >=20 >> That is quite a strong denounciation of the methodology. Could you >> perhaps be a bit more detailed about this claim? >=20 > From what I understand, the methodology is about getting a sense of how= > the people in the IETF work, their beliefs and rituals, and their > interactions with each other and those around them. The actions within= > the context of this research group were embodied in some of the IETF > RFCs. Some of the beliefs do not usually get written into a RFC as > those beliefs are non-technical.=20 The relation between values and design is address in the literature discussion. > It is not always possible to > understand an IETF decision without the background information. Is tha= t > background information relevant if we are discussing about technical > details? No. =20 If an IETF decision is not understandable, that is a problem. > Is it relevant if a person is interested in studying the > beliefs? Maybe. There is a political flavor to beliefs; it is better > not to have those type of discussions in the IETF as such discussions > are usually contentious. One interpretation of ideology is covered in > ISBN 0252097106, 9780252097102. I think there are a lot of contentious discussion in the IETF, else we would not have as many discussions. They are exactly about encryption, privacy, etc, as the topics that are covered in the book you refer to. >=20 >> Have you watched Net of Rights (https://hrpc.io/net-of-rights) ? A lot= >> of the interviews have culminated in that. >=20 > I watched the video. Are those 19 persons representative of the IETF? No, that was also not what I claimed at any time. >=20 >> What promotional material are you aluding to? >=20 > I was referring to "open standards" and "permissionless innovation". >=20 ? Cheers, Niels PS It would be great if you could leave the thread intact so the discussion is easier for people to follow (and to respond to). > Regards, > S. Moonesamy=20 --QQErpibJuOXKuNQXOPfb49f5J4cpVgKHu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYfpxvAAoJEA7YPzpGisiz+vkP/3DJ2d1tUXndgHohWi6YYLgP zq4E9BNvzNZkKHimV0yyGM8BpwhYlf9JarrkaEDpaBLXkFlGmW+8nseOCFSsef5C BgH4Z98uoJZyE+LJIKOjZ9r38Djlxb3hxMrUtSGRPujq8YfztNUkRU3OH7mF9CR3 LwvYka4P61lK03rCMsuf/t5BWTPaEqxQpVW8pixNBpdELkDQ83DpvOHIHZkTFZWK 7SZ9ImXOTdRWF5tLsBJwoYUNUgbwueWhWBTSLuT37hLpA4XMTYwsfnBLnQq+ZzHv fnhrR22YYNJF2AsfVz4GPN29+VQC8aEGh3Vw4RAIEeNxV3vOhZk06jarcTDDsAyy XHBUGHOElDzw38RPapN3F5AME1Y1FNLF+hZlLWaPm2VACspv4+cIZXtL8ClQoN/M 0Y7ZxrQRDiEeriUfAgB2bsCi8ou+VBy2OauuyG+vLyY46kUPbQlIyaQLArc7bHIN IGjFEv3wZRq8JSB/hMR0z4GkOOt2xfRfG56uswiF7wldbZeQ7mJA7D7t8i3AWrKA Kk7ksHhlCo9MCDzbUDH+1zW8pJ8xd7IVQunVdEbc/egtXRDgO6dEQZ665n+c9b+g 19un9X1CMCof2zWV1Omum5lt9mOz1F+ri96LU6K9yxyNYyQjDxZOucmUM99F18Rf XlBGMWjDnOGNp/WaLwAJ =tbfX -----END PGP SIGNATURE----- --QQErpibJuOXKuNQXOPfb49f5J4cpVgKHu-- From nobody Wed Jan 18 04:19:14 2017 Return-Path: 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 5490212940C for ; Wed, 18 Jan 2017 04:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 v5XwF9jQJbnJ for ; Wed, 18 Jan 2017 04:19:10 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 B069F1295D2 for ; Wed, 18 Jan 2017 04:19:09 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cTpCi-0006CX-Ur; Wed, 18 Jan 2017 13:19:06 +0100 From: Niels ten Oever To: Alissa Cooper References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <72333205-0458-63d9-6d9e-3538266fec1d@article19.org> Message-ID: <6528e14c-ddac-c425-7911-3a48c100b158@article19.org> Date: Wed, 18 Jan 2017 13:18:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gxUiOGsVsWOPBVc2X83KK6VHUAxQwdaQ9" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: fe97acb5f006070c812c3a7a6280af65 Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 12:19:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gxUiOGsVsWOPBVc2X83KK6VHUAxQwdaQ9 Content-Type: multipart/mixed; boundary="RO2MRRc1RPU4PKVJQUl57Jp8RNdoxQGL6"; protected-headers="v1" From: Niels ten Oever To: Alissa Cooper Cc: hrpc@irtf.org Message-ID: <6528e14c-ddac-c425-7911-3a48c100b158@article19.org> Subject: Re: [hrpc] Review of draft-irtf-hrpc-research-07 References: <7D2A41AC-88BF-4A47-B340-914976FF566C@cooperw.in> <72333205-0458-63d9-6d9e-3538266fec1d@article19.org> In-Reply-To: --RO2MRRc1RPU4PKVJQUl57Jp8RNdoxQGL6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alissa, Comments inline: Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 On 01/09/2017 10:46 PM, Alissa Cooper wrote: > Hi Niels, >=20 > Some comments inline. >=20 >> On Jan 9, 2017, at 11:55 AM, Niels ten Oever > > wrote: >> >> Hi Alissa, >> >> Thank you very much for this very thorough review. I made quite a few >> changes based on this. All changes can be found here: >> >> https://github.com/nllz/IRTF-HRPC/commit/cb0a9788f9efd2050b7a1912fda8e= 823e4019ace >> >> Please find my response and some questions inline (and sorry for the >> delay in response): >> >> >> On 01/05/2017 06:45 PM, Alissa Cooper wrote: >>> Below is a review of draft-irtf-hrpc-research-07. I have not been >>> involved in the RG so these comments are for what they're worth and I= >>> apologize if some of this ground has been trod before. This was an >>> interesting read and most of my comments are provided with an eye >>> towards making the document more useful/actionable in the IETF >>> eventually, which I realize may not be a shared goal necessarily. >>> >>> Substantive comments: >>> >>> =3D Section 3.2.3 and 3.2.3.1 =3D >>> >>> If the point of the IPv4 example is to demonstrate the human rights >>> impacts -- both positive and negative -- of various protocol designs,= >>> I find the section to be narrow, slanted, and incomplete. It seems >>> focused almost exclusively on the potential harms, which, for a >>> protocol as fundamental to the operation of the Internet as IPv4, is >>> not justified and renders this section somewhat useless IMO. >>> >>> ... >>> >> >> As outlined in a subthread by Stephane and Stephen, this part did not >> aim to do an in-depth Human Rights Impact Analsysis of a single protoc= ol >> but merely establish that there is a relationship between human rights= >> and protocols based on case studies. >> >> I do hope one of the following hrpc drafts indeed can be the developme= nt >> of a model for a Human Rights Impact Assessment of protocols, and mayb= e >> even for of combinations of protocols (because that of course brings i= n >> different vectors). This will needs more research and experimentation >> though. >> >> I do agree that the cases are a mix of things (even though all have >> related RFCs) but we exactly aimed at a mix of things so see what >> different relations between protocols, standards and human rights coul= d >> look like. >=20 > If the section is specifically designed to present cases that cut acros= s > protocols, implementations, and networking paradigms, it should say so > up front. The title and introduction to 3.2.3 indicate that the section= > is about protocols. >=20 Added: ### Map cases of protocols, implementations and networking paradigms that adversely impact human rights or are enablers thereof Given the information above, the following list of cases of protocols, implenentations and networking paradigms that adversely impact or enable human rights was formed. >> >> I'm sorry to hear that you found the overall tone quite negative. >> Therefore I added some extra positive text here: >> >> https://github.com/nllz/IRTF-HRPC/commit/76375bdbf93c1c63661824fbcb7c8= 9b17ecdb609 >=20 > I think this helps, but what would be better would be specific text in > the intro to 3.2.3 that explains that the emphasis of the examples is o= n > adverse impacts to human rights. Perhaps even better would be to remove= > the positive examples and just focus exclusively on the negative ones, > so it=E2=80=99s clear that the thrust of the entire section is to provi= de > negative examples. >=20 Added some text: It is important to note that the assessment here is not a general judgment on these protocols, nor an exhaustive listing of all the potential negative or positive impacts on human rights they might have. >> >> >>> =3D Section 3.2.3.5.2 =3D >>> >>> "Peer-to-Peer traffic (and BitTorrent in particular) represents a >>> high percentage of global Internet traffic" >>> >>> Is there a citation for this? My understanding is that by most >>> measurements the share of p2p traffic is pretty low these days. >>> >> >> This is the most recent stat I could find on this: >> >> http://mashable.com/2014/05/14/file-sharing-decline/#FG_t.2P3Uaqf >> >> https://www.rt.com/news/162744-p2p-file-sharing-increase/ >> >=20 > If you=E2=80=99re comfortable citing Sandvine=E2=80=99s numbers as the = first article > does then there are more recent ones to point to:=20 > https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-america= n-traffic-is-now-streaming-video-and-audio.html > https://www.sandvine.com/trends/global-internet-phenomena/ >=20 > Both of these challenge even a claim of =E2=80=9Csignificant=E2=80=9D p= ercentage, > although no overall global number is given. In any event, there should > be a cite in the document. >=20 Added >> >> Which indeed indicated it flattened out. So that's why I propose >> >> s/high/significant >> >>> =3D Section 4.1.1.1 =3D >>> >>> Two overall comments about this section: >>> >>> (1) The questionnaire seems like it took the kitchen sink approach. >>> Many of the considerations covered here are already covered in other >>> existing IETF documents. In a number of cases this document took >>> specific items from those existing documents and broke them out into >>> their own separate subsections with many detailed questions (e.g., >>> privacy, anonymity, pseudonymity, confidentiality, integrity, >>> reliability, authenticity). I think most protocol designers will find= >>> the sheer volume of questions here daunting and will find the >>> redundancy both within the section and together with existing >>> guidance documents reason enough to skip a human rights analysis >>> altogether. I would recommend really trying to streamline this >>> section down to the essence of the questions that protocol designers >>> are not already asking themselves but should be. If you want to >>> include a comprehensive mapping between the technical concepts and >>> specific human rights, put that mapping in a different section and >>> focus this section on the most important and actionable questions. >>> >> >> Thanks for this suggestion. I do agree that there are double parts, an= d >> the parts that are doulbe, are also clearly referenced as such. What w= e >> tried to do is create a clear human rights lens to specific problems, >> that's why I do not think the current parts are redundant. >> >> Also: I think that providing a reason for people to look at those >> documents increases that chance that they actually will, instead of ju= st >> saying: have a look at this. >=20 > I think we just disagree about this, which is fine. >=20 >> >>> (2) I think it would be a lot clearer if the various subsections were= >>> explicit about where the recommendations here are different than >>> recommendations in existing IETF documents and policies. For privacy,= >>> security, internationalization, and extensibility, the document mixes= >>> in references to existing guidance/policies with its own text and >>> suggestions. If the suggestion is to just go read the other >>> documents, a simple reference would do; otherwise, I think the >>> document could be a lot clearer about where it is asking protocol >>> designers to depart from or go beyond what the existing guidance >>> requires. Other than drawing explicit links between the concepts and >>> human rights affected, I think 4.1.1.1.2, .4, .9, .10, .14, .15, .16,= >>> and .17 could all be removed or replaced with simple pointers to >>> existing documents (possibly also true for .5 and .12 but it=E2=80=99= s not my >>> area of expertise). >> >> The paragraphs that you outline above are already pointing to the othe= r >> documents. The guidelines are not means to replace BCP72 or RFC6973, b= ut >> provide another perspective for looking at protocols from a human righ= ts >> perspective,=20 >=20 > Just to re-state the point: as someone who is quite familiar with the > content of a number of the referenced specs, it=E2=80=99s not clear to = me > whether these sections are asking me to use a different set of > considerations from those specs or not. I suspect other readers would b= e > similarly confused. >=20 Am trying to understand this better. If a questions says: Did you have a look at the Privacy Considerations for Internet Protocols {{RFC6973}}, especially section 6.1.1 ? or: Did you have a look at Guidelines for Writing RFC Text on Security Considerations {{BCP72}}? Have you found any attacks that are out of scope for your protocol? Would these attacks be pertinent to the human rights enabling features of the Internet (as described throughout this document)? I don't not necessarily understand how this could be confusing. But to resolve this I would like to offer: This section provides guidance for document authors in the form of a questionnaire about protocols and their (potential) impact. The questionnaire may be useful at any point in the design process, particularly after document authors have developed a high-level protocol model as described in {{RFC4101}}. These guidelines do not seek to replace any existing referenced specifications, but rather contribute to them and look at the design process from a human rights perspective. >> and providing extra motivation for people to look at the >> these standards, because many of them (Internationalization, etc) are >> not as commonly use as we might like. >> >>> >>> =3D Section 4.1.1.1.1 =3D >>> >>> The example doesn't seem to be responsive to the question. The >>> question is about requiring functionality at intermediaries whereas >>> the example is about a design decision to prevent intermediaries from= >>> carrying out such functionality. >>> >> >> The example shows that one can implement message encryption in differe= nt >> ways, right? But maybe I am misunderstanding your question. >=20 > An instant messaging protocol might be designed such that intermediarie= s > can make use of application-specific functions. That same protocol migh= t > support end-to-end encryption, or protocol designers might later design= > enhancements to the protocol that facilitate end-to-end encryption (an > analogous example for real-time media would be PERC). Whether a protoco= l > allows for application-specific functions at intermediaries and whether= > it supports end-to-end encryption can be mutually exclusive design > decisions.=20 >=20 You're right, we replaced the end-to-end example to a middle-box example.= Thanks for this. >> >>> =3D Section 4.1.1.1.3 =3D >>> >>> "Question(s): If your protocol impacts packet handling, does it look >>> at the packet payload? Is it making decisions based on the payload >>> of the packet? Does your protocol prioritize certain content or >>> services over others in the routing process ? Is the protocol >>> transparent about the priotization that is made (if any)?" >>> >>> I think this set of questions could benefit from some refinement, in >>> particular in terms of the actor(s) being targeted. I don't quite >>> understand the notion of a protocol itself "looking" at a payload or >>> making a decision. >> >> s/looking at packet payload/use data from the packet payload >> >>> I'm guessing this one is actually targeted at >>> network intermediaries, as in 4.1.1.1.1, since the whole point of >>> many protocols is for endpoints to take some action based on packet >>> payloads. >>> >> >> As well as protocols that might make use from packet payload data >> instead of only using data from the header. >=20 > Is the implication supposed to be that protocols that require endpoints= > to take action based on payload data are somehow better for human right= s > than those where endpoints are expected to take action solely based on > header data?=20 Exactly the other way around. > I don=E2=80=99t understand why that would be. Also, the distinction > between payloads and headers is not clear, since a header at one layer > is a payload at the next layer. >=20 I never thought payload like that, not sure if that is very colloquial use. What term could we use to describe the non-header part of a packet? Data portion? Would this work better: If your protocol impacts packet handling, does it use user data (packet data that is not included in the header)? Is it making decisions based on the payload of the packet? Does your protocol prioritize certain content or services over others in the routing process ? Is the protocol transparent about the prioritization that is made (if any)? >> >> >>> I also think the example in this section (and all the subsections of >>> 4.1.1.1, actually) would be more useful if it cited a specific >>> protocol that has the effect that the section raises concerns about, >>> because it's hard to understand what is being implied here. That is, >>> I'm not sure what the implications would be of the answers to these >>> questions if applied to, say RFC 2474 and RFC 2475, because the >>> implications all depend on the deployment context. >>> >> >> I would be hesitant to target this at specific protocols, because that= >> might exclude other protocols for which this could be relevant as well= =2E >> I think the first sentence already is kind of a pre-selection, right? >=20 > I guess the label =E2=80=9CExample=E2=80=9D caused me to expect, well, = an example of how > each consideration might apply to a specific protocol, so that as a > protocol designer I could learn the logic of how it might apply to my > protocol. But if the text under each =E2=80=9CExample=E2=80=9D label is= n=E2=80=99t really meant > to provide an example, perhaps it should be labeled some other way? >=20 It's more of an impact example than a specific protocol example. >> >> >>> =3D Section 4.1.1.1.6 =3D >>> >>> "Question(s): Does this protocol introduce new identifiers or reuse >>> existing identifiers (e.g. MAC addresses) that might be associated >>> with persons or content? ... >>> >>> Example: Identifiers of content exposed within a protocol might be >>> used to facilitate censorship, as in the case of IP based >>> censorship, which affects protocols like HTTP." >>> >>> I'm not sure how much mileage there is to be had out of this question= >>> and example, because most protocols use identifiers. I don't think >>> this is a bad thing, it's just really hard to design a way to >>> communicate between two endpoints about something without using >>> identifiers of some sort. The question is phrased broadly enough that= >>> I think the answer will almost always be "yes" but I'm not sure to >>> what end. >>> >> >> Re-using identifiers might be a bad thing for de-anonymization, and if= >> something can be implemented stateless, it might also be better for >> privacy, right? >=20 > I don=E2=80=99t think it=E2=80=99s accurate to make those claims generi= cally. My SDP > implementation might re-use SSRCs with no impact one way or another on > anonymity. And using identifiers doesn=E2=80=99t necessarily imply any = state is > being maintained. If you could add a few examples of protocols that > exchange content without using identifiers, I think I would be more > convinced that the generic question about content identifiers has utili= ty. >=20 Using an identifier doesn't mean state is being kept, but no state can be kept without using an identifier. If state identifiers are used this can have a negative effect on anonymity, especially if these are also re-used in other protocols, and thereby creating a more persistent identifier. This does not mean that every identifier will have that effect. I think RFC4941 and RFC7217 could be a good example of this. >> >> I think the last two questions in this para are key for providing >> perspective: >> >> Can your protocol contribute to filtering in a way it could be >> implemented to censor data or services? Could this be designed to ensu= re >> this doesn't happen? >> >> I also think the example provides quite some framing which also shows >> the boundaries of this question. >=20 > I don=E2=80=99t really understand the example TBH. It talks about filte= ring > based on IP address but then cites HTTP 451, whose use might have > nothing to do with IP-based filtering. >=20 Added: In the development of the IPv6 protocol it was discussed to embed a Media Access Control (MAC) address into unique IP addresses. This would make it possible for 'eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. {{RFC4941}} This is why Privacy Extensions for Stateless Address Autoconfiguration in IPv6 have been introduced. {{RFC4941}} >> >>> =3D Section 4.1.1.1.7 =3D >>> >>> This section is concerning because it seems to be trying to >>> re-interpret or change existing IETF policies, which seems >>> inappropriate even for an informational IRTF document. For example, >>> this bit in particular caught my eye: >>> >>> "All standards that need to be normatively implemented should be >>> freely available and with reasonable protection for patent >>> infringement claims, so it can also be implemented in open source or >>> free software." >>> >>> As nice as it would be if this were always true, it's not, and it's >>> not likely going to be any time in the foreseeable future for the >>> 8000+ specifications the IETF has produced. >> >> How is this not in-line with BCP78 ? I think this is exactly what BCP7= 8 >> says, the standards are available freely by the IETF. >=20 > If you can find the text in BCP 78 that says the above, please cite it.= > We standardize protocols that normatively rely on specifications > produced by other SDOs that are not freely available, even though it=E2= =80=99s > not ideal. The most recent one I can remember the IESG approving > is https://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-10 >=20 I've added: Do you normatively reference another standard that is not available without cost (and could it possible be done without)? [...] All standards that need to be normatively implemented should be freely available and with reasonable protection for patent infringement claims, so it can also be implemented in open source or free software. Patents have often held back open standardization or been used against those deploying open standards, particularly in the domain of cryptography {{newegg}}. An exemption of this is sometimes made when a protocol is standardized that normatively relies on speficiations produced by others SDOs that are not freely available. >> >>> Many of the reasons for >>> that are outside the control of IETF participants. So I find it >>> unhelpful to suggest these as requirements. I also don't think BCP 78= >>> and 79 and the note well should be further elaborated in a document >>> such as this one; even as informational people can get confused. >>> >>> I would suggest deleting this section as there is a high potential >>> for confusion and I'm not sure that it provides much countervailing >>> benefit. >>> >>> Also, I don't understand how the example relates to the rest of the >>> section or why the emphasis on DPI is there. >>> >> >>> >>> =3D Section 4.1.1.1.11 =3D >>> >>> I think combining access for those with disabilities and access for >>> those with poor connectivity under a single heading is confusing. >>> These imply some rather disparate design decisions, not all of which >>> will apply to all protocols nor in the same ways. >>> >> >> I agree, I guess the problem lies in the word 'accessibility'. That is= >> why we're offering different definitions for that in the glossary as >> well. Any suggestion on how we might improve this? >=20 > Split these into separate sections with separate considerations for eac= h. >=20 I've added the 'Accessibility' in relation to connectivity to the header 'Connectivity', and kept 'Accessibility' in relation to the design of protocols, services or implementation that provide an enabling environment for people with disabilities. >> >>> =3D Section 2 =3D >>> >>> There are two different definitions offered for "Connectivity." >>> >> >> You mean this? >> >> : The extent to which a device or network is able to reach other devic= es >> or networks to exchange data. The Internet is the tool for providing >> global connectivity {{RFC1958}}. >> Different types of connectivity are further specified in {{RFC4084}}. >> >=20 > That is one of the definitions given. The other definition is at the en= d > of the section: >=20 > Connectivity The combination of the end-to-end principle, > interoperability, resilience, reliability and robustness are the > enableing factors that result in connectivity to and on the > Internet. Fixed. Thanks again! Best, Niels >=20 > Thanks, > Alissa >=20 >=20 --RO2MRRc1RPU4PKVJQUl57Jp8RNdoxQGL6-- --gxUiOGsVsWOPBVc2X83KK6VHUAxQwdaQ9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAlh/XS0ACgkQDtg/OkaK yLMSGg//fAuF9hENCYMDYQiBaKMJKoi0kt4bBAJGjNEgtpuqGqCDlKgOFGOuFpzL +9ed1hI/apEjf4cm0DSC/yAgS2A0gYVM4cwFrbqbSVP4RGlYZvMrD8ibXCG6rrI8 Ll5mWfpNcSaQ7KVGO6TcygqqQOqTGpstOqcsBjTWRdx5eJDxR3rXgl6PRlifo36O nBtz0osUCoVfG4MmwEODcU4tB4MAwp996ksO2irFr+Fwsr/wEAZBk5sJqyT0cpQn PpIQkRrK0M+3bhSD7/qaZh9epu0XfZYDIZUdatk2L8uCSYDPkqhUnZxDIzxMo5MV i0EkgZgd7t4uldd5qVfycNbW8rGe4tL5nidbOvAWn22cyqBLQmlUeH5ojwhNSbtS L5zQxd9z+E024LYvRl+sfvfjOleDnzEdsDYJeSc0BM9QjeDM6n85AiU+8jekdUoD +oSE018OmR6BV8Ay3M5JrbPm85e0PNIqeWdnHUeLIr7hDruWEnhD++zTQqND+yaN mOGJ1kkz1dQkZOdinXnzcxHYI3wW3lcAXGL+JrQ4Ax8WLkQNIVZf0Dzll37mTuOa DdnV3+fGoxsNwP9cBOJjK0AiBq3EuZCCdPImQeFnudEOkEVEYvcbtniSemfvc5pB MlvYvMD5iqc/hHEr0OCMZckHcUPP585CxDkpa/ME7rB6Zn30KRw= =1kVZ -----END PGP SIGNATURE----- --gxUiOGsVsWOPBVc2X83KK6VHUAxQwdaQ9-- From nobody Wed Jan 18 05:22:44 2017 Return-Path: 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 B98191270B4 for ; Wed, 18 Jan 2017 05:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Liomo55NIwCg for ; Wed, 18 Jan 2017 05:22:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92BB11296CF for ; Wed, 18 Jan 2017 05:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2722; q=dns/txt; s=iport; t=1484745760; x=1485955360; h=to:from:subject:message-id:date:mime-version; bh=cRbGuWPF82qFydcySDmFFdisJAK8gq6WMwswfEmI4Zg=; b=CK8wFl63j+/ZV+Rak0E9d0xYICOhIHkb7c0GfzUBSna0t+d3hOLu4pZV QyQ3KGjRj4WoD24OOz+H7A7pY8tcUE6Du8/5AfhriTVOgema9VAWCDM0w IJNu2y0CA6/0gj4G9iEtv7X003fKHDNRvEcEj8J3relKvQApC3c8GUeEq 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6BgCXa39Y/xbLJq1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzkBAQEBAYEBhFeKepBxlUuCC4hUFgECAQEBAQEBAWMdC4UTSAdkAl8NCAE?= =?us-ascii?q?BiH+fSZABgiUZig8BAQgCARYPiFAIijCCXgWbQYNqggCLeIovhj6SbyYGK4EVE?= =?us-ascii?q?ggVFYZuPYk2AQEB?= X-IronPort-AV: E=Sophos;i="5.33,249,1477958400"; d="asc'?scan'208";a="648905439" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 13:22:38 +0000 Received: from [10.61.64.129] (ams3-vpn-dhcp129.cisco.com [10.61.64.129]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0IDMcj8000620 for ; Wed, 18 Jan 2017 13:22:38 GMT To: "hrpc@irtf.org" From: Eliot Lear Message-ID: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> Date: Wed, 18 Jan 2017 14:22:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XH0VLSGlJeLDjRiupVOauAILHgHx8UPrM" Archived-At: Subject: [hrpc] challenges regarding draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 13:22:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XH0VLSGlJeLDjRiupVOauAILHgHx8UPrM Content-Type: multipart/mixed; boundary="fbIgRnVrwGeqlAlkulLDMR30IGI59NT6L"; protected-headers="v1" From: Eliot Lear To: "hrpc@irtf.org" Message-ID: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> Subject: challenges regarding draft-irtf-hrpc-research-07 --fbIgRnVrwGeqlAlkulLDMR30IGI59NT6L Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Following up on Roland Bless' note, and as last call has closed, I wish to raise a concern about repeated discussion about the selection of rights that has been discussed in the draft. The interplay between different human rights and the impact of that interplay on this interdisciplinary work requires that there be some reasonable level of cross-disciplinary review, and yet unfortunately that has not happened.=20 The one review we do have from someone clearly working within political science disputes the premise of the work and concludes that the draft be completely rewritten.[1][*] This wouldn't matter that much for an individual submission. However, that's not the current intended trajecto= ry. I suggest the chairs seek broader review from additional people with subject matter expertise re human rights, political science, and / or international relations. Absent that level of review neither this group nor the IRSG are competent to assess the political / human rights aspects of the draft, and the draft should not proceed. We don't go to network nerds for medical advice; neither should we rely on ourselves for the human rights / political aspects of the draft. Eliot [1] Jeanette Hofmann, 7 Jan 2017 [*] This is not to say there aren't learned people in this discussion.=20 I count no fewer than five PhDs engaged, and several otherwise knowledgeable people. --fbIgRnVrwGeqlAlkulLDMR30IGI59NT6L-- --XH0VLSGlJeLDjRiupVOauAILHgHx8UPrM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYf2weAAoJEIe2a0bZ0nozsSwH/iKa74RoynAiIwxDTx1sKoCK XLBIKtQqu/n3L2JpS8m8xfXI35g6Gy81+qrVxHpBX9z5oFFcrS5URZ4jDEj4nhmZ bCj0RKvvyiyhV/86TDGuJ4HpYcBN7Pp5Ihf4JoS3RU3v8bCz0/1e/0SCvSZMXm72 L+pdy843xXi97YBUjmTPNmUba2Rrx88uhi/lZ7BhvLowIOAt84aJybaB3sx2hLjM EOy4vtn/rGJuwvlGetkVuviA79Y5ZGFv/NIGnZrHJ+r1pAxjDtTy8QmDywFpUUqU yfawEQsoyB1bj6VhpjVkyuy9KGApMqJiS1tyfxMka/Fo1xXSMuAY/q5jmmvsLYM= =6oaj -----END PGP SIGNATURE----- --XH0VLSGlJeLDjRiupVOauAILHgHx8UPrM-- From nobody Wed Jan 18 05:48:12 2017 Return-Path: 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 149991296F7 for ; Wed, 18 Jan 2017 05:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3j9ZGTfoBeNc for ; Wed, 18 Jan 2017 05:48:09 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 50DAA12952C for ; Wed, 18 Jan 2017 05:48:09 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 86E2B31D52; Wed, 18 Jan 2017 14:48:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 058A01906FF; Wed, 18 Jan 2017 14:44:32 +0100 (CET) Date: Wed, 18 Jan 2017 14:44:32 +0100 From: Stephane Bortzmeyer To: Eliot Lear Message-ID: <20170118134432.GA15699@sources.org> References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 13:48:11 -0000 On Wed, Jan 18, 2017 at 02:22:37PM +0100, Eliot Lear wrote a message of 83 lines which said: > We don't go to network nerds for medical advice; neither should we > rely on ourselves for the human rights / political aspects of the > draft. I strongly disagree with this line of reasoning. It seems common (the famous New Yorker cartoon... ) but it is nevertheless wrong. Politics is special because it comes from the citizens, not from experts (or not just from experts). It is quite different from medecine (or computer networking...), where things are right or wrong, and people can learn the difference. If having studied political science would make you better at judging issues around human rights, then we could shutdown democracy (not just the current instances, but any idea of democracry as well) and replace it by a governement of PhDs in political sciences. But, in the current state of science, it is not true. From nobody Wed Jan 18 05:51:20 2017 Return-Path: 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 084151296FD for ; Wed, 18 Jan 2017 05:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 HT8MdOP5LXUQ for ; Wed, 18 Jan 2017 05:51:17 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397601296F7 for ; Wed, 18 Jan 2017 05:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3059; q=dns/txt; s=iport; t=1484747477; x=1485957077; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=lHXl1ptyn65v4NfjprQsBfWN3R+/MH9GjyCtPa/thcU=; b=PDYLGstOLB0BWrpOqwI+QJNxCqW4K+5gUVbyzkweGgwxEKFlTQKw6sPu D4VXxsHc/1ZnEm+iOYBI0Tvw0ZXvuC7TH/C0mVCscvDhtUXQegghcmgg9 T3z3gSF6LZpd/TzZCZfILr65rTBVt8A1KKoQDpof+nSmN18N667KCBfRI o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAQDlcX9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAX4DgQaDUYoIcpBxH5UsggsqhS5KAoIyGAECAQEBAQE?= =?us-ascii?q?BAWMohGoBBSNIDhALGCoCAlcGDQYCAQGIfw6vRIIlGYoPAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBEQoFiFAIgmGHT4JeBZtBg2qCAHWLA4ovhj6Sbx84gRUSCBUVhHEcgWE?= =?us-ascii?q?9NYkBAQEB?= X-IronPort-AV: E=Sophos;i="5.33,249,1477958400"; d="asc'?scan'208";a="691468550" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 13:51:15 +0000 Received: from [10.61.64.129] (ams3-vpn-dhcp129.cisco.com [10.61.64.129]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0IDpFKb007607; Wed, 18 Jan 2017 13:51:15 GMT To: Stephane Bortzmeyer References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> From: Eliot Lear Message-ID: <003ca204-b264-0150-7163-15a657acc312@cisco.com> Date: Wed, 18 Jan 2017 14:51:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170118134432.GA15699@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UEhtOon1U7JQjUksRO2hDXswgSCwW0oEA" Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 13:51:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UEhtOon1U7JQjUksRO2hDXswgSCwW0oEA Content-Type: multipart/mixed; boundary="FSxBvQ3LiGXlwf7NIJMFBjeuVdKhSm5JS"; protected-headers="v1" From: Eliot Lear To: Stephane Bortzmeyer Cc: "hrpc@irtf.org" Message-ID: <003ca204-b264-0150-7163-15a657acc312@cisco.com> Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> In-Reply-To: <20170118134432.GA15699@sources.org> --FSxBvQ3LiGXlwf7NIJMFBjeuVdKhSm5JS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephane, There is a difference between participation in politics and research into the discipline. This is the Internet RESEARCH Task Force, not the Internet POLITCAL PARTICIPATION Task Force (although I'll grant it feels like that sometimes). If the document does proceed without the academic review, then let us at least be honest with ourselves that it is a political work and not a work of research. Eliot On 1/18/17 2:44 PM, Stephane Bortzmeyer wrote: > On Wed, Jan 18, 2017 at 02:22:37PM +0100, > Eliot Lear wrote=20 > a message of 83 lines which said: > >> We don't go to network nerds for medical advice; neither should we >> rely on ourselves for the human rights / political aspects of the >> draft. > I strongly disagree with this line of reasoning. It seems common (the > famous New Yorker > cartoon... = ) > but it is nevertheless wrong. Politics is special because it comes > from the citizens, not from experts (or not just from experts). It is > quite different from medecine (or computer networking...), where > things are right or wrong, and people can learn the difference. > > If having studied political science would make you better at judging > issues around human rights, then we could shutdown democracy (not just > the current instances, but any idea of democracry as well) and replace > it by a governement of PhDs in political sciences. But, in the current > state of science, it is not true. > --FSxBvQ3LiGXlwf7NIJMFBjeuVdKhSm5JS-- --UEhtOon1U7JQjUksRO2hDXswgSCwW0oEA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYf3LSAAoJEIe2a0bZ0nozWykH/iJWzrF1WbS9p3jSn51C7icN Mc7M5pywfIwM6hnYCKgGBqT5DxL3gzZspL8mq2j0jNSaNks1i7CLxq3Bj3Ejn4li WYq3n2OTPMIos4EDHZx5IYxvpQhHWrHiOES5WnBhO4imxWMiwn2ackUVyY/APGi3 InjGW0ZtGNJiNXguwSUghnt9M4jhR71osfLcCyylgm53sSw4GJV4QZQOUymVdAeg fXuzSntYI8/1uEx6FiUrOkYJginsDFrN7qrPzXAeUs6Xf5T6rJ/YWE6bren3m5t2 aFF13Uu7cbAqbneuNiePDDHuCDlPwAkcyj+VtKFM+y3pcAEtK9dXcemKwcbqpD4= =Xrpj -----END PGP SIGNATURE----- --UEhtOon1U7JQjUksRO2hDXswgSCwW0oEA-- From nobody Wed Jan 18 05:52:36 2017 Return-Path: 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 A90AD1296FA for ; Wed, 18 Jan 2017 05:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 luG9lbICSTmL for ; Wed, 18 Jan 2017 05:52:23 -0800 (PST) Received: from athene.wzb.eu (athene.wzb.eu [193.174.6.3]) (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 524FF12970A for ; Wed, 18 Jan 2017 05:52:21 -0800 (PST) To: Stephane Bortzmeyer , Eliot Lear References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> From: Jeanette Hofmann Message-ID: Date: Wed, 18 Jan 2017 14:52:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170118134432.GA15699@sources.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-WZB-Virus-Scanned: by Clam AntiVirus at athene.wzb.eu X-Priority: 3 (Normal) Importance: Normal Priority: normal Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 13:52:35 -0000 +1 jeanette Am 18.01.2017 um 14:44 schrieb Stephane Bortzmeyer: > On Wed, Jan 18, 2017 at 02:22:37PM +0100, > Eliot Lear wrote > a message of 83 lines which said: > >> We don't go to network nerds for medical advice; neither should we >> rely on ourselves for the human rights / political aspects of the >> draft. > > I strongly disagree with this line of reasoning. It seems common (the > famous New Yorker > cartoon... ) > but it is nevertheless wrong. Politics is special because it comes > from the citizens, not from experts (or not just from experts). It is > quite different from medecine (or computer networking...), where > things are right or wrong, and people can learn the difference. > > If having studied political science would make you better at judging > issues around human rights, then we could shutdown democracy (not just > the current instances, but any idea of democracry as well) and replace > it by a governement of PhDs in political sciences. But, in the current > state of science, it is not true. > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > From nobody Wed Jan 18 06:04:58 2017 Return-Path: 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 E89D81297AC for ; Wed, 18 Jan 2017 06:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 bG1v5dSGOLqC for ; Wed, 18 Jan 2017 06:04:54 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 9D2811297AA for ; Wed, 18 Jan 2017 06:04:54 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cTqr4-0002Sz-UZ for hrpc@irtf.org; Wed, 18 Jan 2017 15:04:52 +0100 To: hrpc@irtf.org References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> From: Niels ten Oever Message-ID: <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> Date: Wed, 18 Jan 2017 15:04:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <003ca204-b264-0150-7163-15a657acc312@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ikg3TxBMJq6rwjcBQIeFp1toEh7sv7ACl" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 0420c3252dbee8b9b50dacb1a1909624 Archived-At: Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:04:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ikg3TxBMJq6rwjcBQIeFp1toEh7sv7ACl Content-Type: multipart/mixed; boundary="0HMxIxfXTWt34P1FuEXa3CJ0eTq905s8L"; protected-headers="v1" From: Niels ten Oever To: hrpc@irtf.org Message-ID: <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> In-Reply-To: <003ca204-b264-0150-7163-15a657acc312@cisco.com> --0HMxIxfXTWt34P1FuEXa3CJ0eTq905s8L Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable May I suggest that this document has been reviewed by academics? For instance Molly Sauter, Harry Halpin, Roland Bless, Nathalie Marechal, Scott Craig are all academics as well as Stephen Farrell. Furthermore, I've replied to Roland where he brought this up and offered a solution to that specific issue. I also do not think that conflating all issues to one (and not taking the discussion and solutions into account) and therefore dismissing the draft is not really fair imho. Best, Niels (with his author hat on) Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 On 01/18/2017 02:51 PM, Eliot Lear wrote: > Stephane, >=20 > There is a difference between participation in politics and research > into the discipline. This is the Internet RESEARCH Task Force, not the= > Internet POLITCAL PARTICIPATION Task Force (although I'll grant it feel= s > like that sometimes). If the document does proceed without the academi= c > review, then let us at least be honest with ourselves that it is a > political work and not a work of research. >=20 > Eliot >=20 > On 1/18/17 2:44 PM, Stephane Bortzmeyer wrote: >> On Wed, Jan 18, 2017 at 02:22:37PM +0100, >> Eliot Lear wrote=20 >> a message of 83 lines which said: >> >>> We don't go to network nerds for medical advice; neither should we >>> rely on ourselves for the human rights / political aspects of the >>> draft. >> I strongly disagree with this line of reasoning. It seems common (the >> famous New Yorker >> cartoon... ) >> but it is nevertheless wrong. Politics is special because it comes >> from the citizens, not from experts (or not just from experts). It is >> quite different from medecine (or computer networking...), where >> things are right or wrong, and people can learn the difference. >> >> If having studied political science would make you better at judging >> issues around human rights, then we could shutdown democracy (not just= >> the current instances, but any idea of democracry as well) and replace= >> it by a governement of PhDs in political sciences. But, in the current= >> state of science, it is not true. >> >=20 >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --0HMxIxfXTWt34P1FuEXa3CJ0eTq905s8L-- --ikg3TxBMJq6rwjcBQIeFp1toEh7sv7ACl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAlh/dfQACgkQDtg/OkaK yLPaWQ//WlTri3CzPZYjWchWECOprQGxOHmyaF6H0Ol6UBDx6fxBBk9kXeFk9Q7O ZWroLViXz3/kAzuisCSHwqwn6S9LdE+wfFgJmt8eBzk13c862q59qFAcWysMaUPK RXtQS+hvUWY/bTiqdwDZlo2D0eBAreBxlCtQg+EMNKKRFreLOOQ9Ke3GxPH5n0oI xr64DsIBOy0/PSFQjFwl2PpuDhGnu0XGCJ79jzzf8xBqKVkIbzkWJOETGnSjiRZk XLWasUGyCKxXiHgBJNP9WVzoUB7O71wefJ1wv8sb8YPa9UzYWD9C8v2uIEQ88WxD 2KflQLGSzH5OQx5Nnu8buJIiWurFG5SgYcTkwNLwx9aS2LIo9eWzxJlSD3UiWtxu lMJ+67tKqN2Nr2nQkKl0RDVryWXTFERzlgpjT3Mo0Ew1TKBas34mnAi3SYtTRwhO vPsthEqPMkuL/7HZSpwtUAmPakdwqo7MbTKWT8RjSnS3HGvyTYTNH50HMjZCuH8F 63utoKyy7Xij12kaUI3IJ+jByppfTe+CoLmUr7qsQMBNRva6O4cF94qvTPXqxs35 Jrwr1fSjKFXbfc5xlPI6yUfXZ7fjwFVCtOz9U20H9pG9XgvOUWuHKo7MB3EgrWAr DYjU0zmL8JKxLMWA38Axu4OlExAxsBSYWBmfMhXLkhwaL5j8c4E= =0yhN -----END PGP SIGNATURE----- --ikg3TxBMJq6rwjcBQIeFp1toEh7sv7ACl-- From nobody Wed Jan 18 06:38:52 2017 Return-Path: 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 EFD8212946B for ; Wed, 18 Jan 2017 06:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 N_rX3Rr3MXZO for ; Wed, 18 Jan 2017 06:38:49 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D579A126FDC for ; Wed, 18 Jan 2017 06:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10349; q=dns/txt; s=iport; t=1484750329; x=1485959929; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=L21eToZs+ydMqaslDp+vqw3WF6w6KyEfq4Od1D9O7+Y=; b=jrmASXety54YAicEkz0NCjLPAgTJGjH5LFzQHSTwAfXAW+2Vbm1ww69T 5cKmHu2/F0c+HIXP9DZZU9mmods2gx7o/HP7uY16IySfbyZo2BYhth03M 7q9MwaI/I75bcA+mMy7exP8gdofUi+wrBE/d2sKkXSqXPp4mBaFoFiqWu o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AQCffX9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAX4DgQaDUYoIcpEPkAGFK4ILHwEKhS5KAoI4GAECAQE?= =?us-ascii?q?BAQEBAWMohGoBAQQBASEmIgMbCxgVFQICJzAGAQwGAgEBF4hoDq9LgiUZEol7A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEPD4hQgWCBCYUIgkeCXgWbQYNqggB1iwOKL4Y?= =?us-ascii?q?+km8fOIEVEggVFTqENxyBYT01iQEBAQE?= X-IronPort-AV: E=Sophos;i="5.33,249,1477958400"; d="asc'?scan'208,217";a="691469943" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 14:38:37 +0000 Received: from [10.61.64.129] (ams3-vpn-dhcp129.cisco.com [10.61.64.129]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0IEcbIP003124; Wed, 18 Jan 2017 14:38:37 GMT To: Niels ten Oever , hrpc@irtf.org References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> From: Eliot Lear Message-ID: <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com> Date: Wed, 18 Jan 2017 15:38:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3bak42sjCoAIdGfrgwkIk6k5KFo3ujOLX" Archived-At: Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:38:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3bak42sjCoAIdGfrgwkIk6k5KFo3ujOLX Content-Type: multipart/mixed; boundary="FISU5KUP9ka6UxejfCCL53HnJ0PbTSNc7"; protected-headers="v1" From: Eliot Lear To: Niels ten Oever , hrpc@irtf.org Message-ID: <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com> Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07 References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> In-Reply-To: <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> --FISU5KUP9ka6UxejfCCL53HnJ0PbTSNc7 Content-Type: multipart/alternative; boundary="------------3CBF6E7398E3D63987639DF9" This is a multi-part message in MIME format. --------------3CBF6E7398E3D63987639DF9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Niels, You are missing my point. What I asked for was additional review from people in the other disciplines be sought. Nowhere did I suggest that the draft be thrown away, nor would I (that was Jeanette Hofmann, by the way, who wrote that on the 7th of January). For one thing, on the precise interplay I mention, I myself do not feel qualified to go much further but to note that it is there. Second, of the people you mention many are computer scientists. Also, of the people you mentioned there is no record of the review of some of them. I think it's fine that you got review from them, but if this is to be a consensus document, perhaps you would share those? Eliot On 1/18/17 3:04 PM, Niels ten Oever wrote: > May I suggest that this document has been reviewed by academics? For > instance Molly Sauter, Harry Halpin, Roland Bless, Nathalie Marechal, > Scott Craig are all academics as well as Stephen Farrell. > > Furthermore, I've replied to Roland where he brought this up and offere= d > a solution to that specific issue. > > I also do not think that conflating all issues to one (and not taking > the discussion and solutions into account) and therefore dismissing the= > draft is not really fair imho. > > Best, > > Niels (with his author hat on) > > > > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > > On 01/18/2017 02:51 PM, Eliot Lear wrote: >> Stephane, >> >> There is a difference between participation in politics and research >> into the discipline. This is the Internet RESEARCH Task Force, not th= e >> Internet POLITCAL PARTICIPATION Task Force (although I'll grant it fee= ls >> like that sometimes). If the document does proceed without the academ= ic >> review, then let us at least be honest with ourselves that it is a >> political work and not a work of research. >> >> Eliot >> >> On 1/18/17 2:44 PM, Stephane Bortzmeyer wrote: >>> On Wed, Jan 18, 2017 at 02:22:37PM +0100, >>> Eliot Lear wrote=20 >>> a message of 83 lines which said: >>> >>>> We don't go to network nerds for medical advice; neither should we >>>> rely on ourselves for the human rights / political aspects of the >>>> draft. >>> I strongly disagree with this line of reasoning. It seems common (the= >>> famous New Yorker >>> cartoon... ) >>> but it is nevertheless wrong. Politics is special because it comes >>> from the citizens, not from experts (or not just from experts). It is= >>> quite different from medecine (or computer networking...), where >>> things are right or wrong, and people can learn the difference. >>> >>> If having studied political science would make you better at judging >>> issues around human rights, then we could shutdown democracy (not jus= t >>> the current instances, but any idea of democracry as well) and replac= e >>> it by a governement of PhDs in political sciences. But, in the curren= t >>> state of science, it is not true. >>> >> >> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >> > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --------------3CBF6E7398E3D63987639DF9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Niels,

You are missing my point.=C2=A0 What I asked for was additional re= view from people in the other disciplines be sought.=C2=A0 Nowhere did I= suggest that the draft be thrown away, nor would I (that was Jeanette Hofmann, by the way, who wrote that on the 7th of January).=C2=A0 For one thing, on the precise interplay I mention, = I myself do not feel qualified to go much further but to note that it is there.=C2=A0 Second, of the people you mention many are compu= ter scientists.=C2=A0 Also, of the people you mentioned there is no rec= ord of the review of some of them.=C2=A0 I think it's fine that you got= review from them, but if this is to be a consensus document, perhaps you would share those?

Eliot


On 1/18/17 3:04 PM, Niels ten Oever wrote:
May I suggest that this document has been reviewed b=
y academics? For
instance Molly Sauter, Harry Halpin, Roland Bless, Nathalie Marechal,
Scott Craig are all academics as well as Stephen Farrell.

Furthermore, I've replied to Roland where he brought this up and offered
a solution to that specific issue.

I also do not think that conflating all issues to one (and not taking
the discussion and solutions into account) and therefore dismissing the
draft is not really fair imho.

Best,

Niels (with his author hat on)



Niels ten Oever
Head of Digital

Article 19
w=
ww.article19.org

PGP fingerprint    2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3

On 01/18/2017 02:51 PM, Eliot Lear wrote:

Stephane,

There is a difference between participation in politics and research
into the discipline.  This is the Internet RESEARCH Task Force, not the
Internet POLITCAL PARTICIPATION Task Force (although I'll grant it feels
like that sometimes).  If the document does proceed without the academic
review, then let us at least be honest with ourselves that it is a
political work and not a work of research.

Eliot

On 1/18/17 2:44 PM, Stephane Bortzmeyer wrote:

On Wed, Jan 18, 2017 at 02:22:37PM +0100,
 Eliot Lear <lear@cisco.com> wrote=20
 a message of 83 lines which said:


We don't go to network nerds for medical advic=
e; neither should we
rely on ourselves for the human rights / political aspects of the
draft.

I strongly disagree with this line of reasoning.=
 It seems common (the
famous New Yorker
cartoon... <https://twitter.com/WillMcPh=
ail/status/815899174474567680/>)
but it is nevertheless wrong. Politics is special because it comes
from the citizens, not from experts (or not just from experts). It is
quite different from medecine (or computer networking...), where
things are right or wrong, and people can learn the difference.

If having studied political science would make you better at judging
issues around human rights, then we could shutdown democracy (not just
the current instances, but any idea of democracry as well) and replace
it by a governement of PhDs in political sciences. But, in the current
state of science, it is not true.





_______________________________________________
hrpc mailing list
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc



      

      

      

      
_______________________________________________
hrpc mailing list
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


    

    

  


--------------3CBF6E7398E3D63987639DF9--

--FISU5KUP9ka6UxejfCCL53HnJ0PbTSNc7--

--3bak42sjCoAIdGfrgwkIk6k5KFo3ujOLX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJYf33tAAoJEIe2a0bZ0nozD7EH/0HHbILM76opv9E+rmi4xsaA
InVffb4QmRodpg98r67QS4sye1skXx1DBbIUYWdwSXqvU3a8OFU9pxCIjuq7xJPy
1Tahn90sESrY22dqa2xLNeXtkmBVTAhurylSWpeAyrhbq4HVb5NBo5cPP/V7N9uc
dU4LhZa0Ym8zZppv0yifT04zO+uUO1ETHJlvnNG9S4kfQEsZag+kvMJl/0APVLTy
LIkwTLMrWMojndPbTZ3H8B+XiHFcJGmZB/kujnxk1HsutttnpP0dfJFwEKS0tyX5
CJM4u0Ww5AbLLnm3D3xkuBYYuJFpgnkF4d+ZbMzQtQncJB3O7eDMNXcdbMM6LLw=
=hVWK
-----END PGP SIGNATURE-----

--3bak42sjCoAIdGfrgwkIk6k5KFo3ujOLX--


From nobody Wed Jan 18 09:35:55 2017
Return-Path: 
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 087C61294EF for ; Wed, 18 Jan 2017 09:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 FBPIHuDtb_yQ for ; Wed, 18 Jan 2017 09:35:47 -0800 (PST)
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 95B9D1294A9 for ; Wed, 18 Jan 2017 09:35:47 -0800 (PST)
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 1cTu9B-0004Zw-47; Wed, 18 Jan 2017 18:35:45 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 0E9A1B00226; Wed, 18 Jan 2017 18:35:45 +0100 (CET)
To: Eliot Lear , "hrpc@irtf.org" 
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>
From: "Bless, Roland (TM)" 
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: 
Date: Wed, 18 Jan 2017 18:35:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.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 1484760945.
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 17:35:51 -0000

Hi Eliot,

I agree that interdisciplinary work is required, but people
from social sciences alone won't fix it. Interdisciplinary work
is usually hard, because we (as mostly technical people) need to
understand the viewpoints / perspectives of the other disciplines
(e.g., social sciences, legal sciences, ethics etc.) and vice versa.
That starts with a common understanding of certain terms and probably
ends up in finding out methods how to consider human rights impacts
in protocol design. So the main point of this draft and RG is to
raise awareness on issues related to HR impact. This indeed needs
more discussion between the disciplines.

Moreover, protocol specifications are only a small part of the
story. I think that a large part has to do with operational and
administrative practices and entities: especially authorities who manage
addresses and namespaces exert power in certain ways, e.g.,
affecting the right to access, right to participate, the right to
freedom of assembly and expression. In some cases authorization
may be enforced by technical means (e.g., building access control
into the network), in other cases merely by operational
means (e.g., being the administrative entity who owns and operates the
corresponding server). The IETF covers operational issues to some
extent, while others are left to the market. The mentioned impacts
by operations would largely fall into the institutionalization domain.
This should also be discussed a bit in the draft, however, IMHO it is ok
to firstly concentrate on protocol design and protocol mechanism issues.

Regards,
 Roland


Am 18.01.2017 um 14:22 schrieb Eliot Lear:
> Following up on Roland Bless' note, and as last call has closed, I wish
> to raise a concern about repeated discussion about the selection of
> rights that has been discussed in the draft.  The interplay between
> different human rights and the impact of that interplay on this
> interdisciplinary work requires that there be some reasonable level of
> cross-disciplinary review, and yet unfortunately that has not happened. 
> The one review we do have from someone clearly working within political
> science disputes the premise of the work and concludes that the draft be
> completely rewritten.[1][*]  This wouldn't matter that much for an
> individual submission.  However, that's not the current intended trajectory.
> 
> I suggest the chairs seek broader review from additional people with
> subject matter expertise re human rights, political science, and / or
> international relations.  Absent that level of review neither this group
> nor the IRSG are competent to assess the political / human rights
> aspects of the draft, and the draft should not proceed.  We don't go to
> network nerds for medical advice; neither should we rely on ourselves
> for the human rights / political aspects of the draft.
> 
> Eliot
> 
> [1] Jeanette Hofmann, 7 Jan 2017
> 
> [*] This is not to say there aren't learned people in this discussion. 
> I count no fewer than five PhDs engaged, and several otherwise
> knowledgeable people.


From nobody Wed Jan 18 09:57:15 2017
Return-Path: 
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 E446E1294C8 for ; Wed, 18 Jan 2017 09:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WCkuPPxufNvI for ; Wed, 18 Jan 2017 09:57:11 -0800 (PST)
Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2C3129529 for ; Wed, 18 Jan 2017 09:57:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id D953C11598 for ; Wed, 18 Jan 2017 17:57:12 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLHINQUHEVL7 for ; Wed, 18 Jan 2017 17:57:12 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 1069011572 for ; Wed, 18 Jan 2017 17:57:12 +0000 (UTC)
Date: Wed, 18 Jan 2017 12:57:08 -0500
From: Andrew Sullivan 
To: hrpc@irtf.org
Message-ID: <20170118175708.GE664@mx2.yitter.info>
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 17:57:13 -0000

On Wed, Jan 18, 2017 at 03:38:36PM +0100, Eliot Lear wrote:
> got review from them, but if this is to be a consensus document, perhaps
> you would share those?

It was always sort of strange to me that we were trying to make this a
consensus document anyway.  It's an IRTF product, and the IRTF need
not work by consensus.  It's also a research document.

Maybe the problem is that we're trying to hit the wrong goal.  I think
the document has been widely reviewed.  I think there are some known
issues that some have with it; I've made several suggestions not all
of which have been IMO incorporated, but I think the authors are in a
position to do make that call.

If this were an IETF document, I think it would be in trouble because
the rough seems large and multifaceted.  But for a research document,
there's nothing wrong with that outcome normally.  Why is this case
special?

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Wed Jan 18 11:59:29 2017
Return-Path: 
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 C02A51298D0 for ; Wed, 18 Jan 2017 11:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level: 
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=lees8nx7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=TbIrCN77
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 4c1Kyniu8eUd for ; Wed, 18 Jan 2017 11:59:26 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0986E129424 for ; Wed, 18 Jan 2017 11:59:26 -0800 (PST)
Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0IJx5oV017296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jan 2017 11:59:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484769553; x=1484855953; bh=zTcn7ewYyCLv/C1rwApJs+QwHjLF2eUrOdCv7kqbR80=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lees8nx7Km3mHu+de530qqEFnSFAR59UV+a1FLpfi53/9R1sJD4eaL2HrGJHVlH3E Vsg5jOgD+VDDN7GJlQWbuiMfD7RxwkRM5oDOKTfJWqgFpruAr+1Equb+k0gridBvz1 s9q8DyO+gCvLdT5CcpWwYbsPr5lnlO9CKpVT+OzM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484769553; x=1484855953; i=@elandsys.com; bh=zTcn7ewYyCLv/C1rwApJs+QwHjLF2eUrOdCv7kqbR80=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TbIrCN775NuTN+6rLvlhPEVf6Ie7n+IGD8clVMm/0w9vUlKUJUZDvUglU8FpJ34Te ROFzEjn4VdwEaoSvQ8kGzoAt9iChfSZJbWshi++AgSpfwuRCGYPbV2bZMAQa2VRn8q okGU2iHCVrqsYFIJ4kH8e61vvpZw2eVpNqIvvcIQ=
Message-Id: <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 18 Jan 2017 11:57:31 -0800
To: Niels ten Oever , hrpc@irtf.org
From: S Moonesamy 
In-Reply-To: 
References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 19:59:28 -0000

Hi Niels,
At 14:36 17-01-2017, Niels ten Oever wrote:
>PS It would be great if you could leave the thread intact so the
>discussion is easier for people to follow (and to respond to).

I apologize for that.  I sent a subscription request last year 
through https://www.irtf.org/mailman/listinfo/hrpc  I assumed that 
the research group might be a closed group as I did not receive an 
email confirmation.  For what it is worth, the threading should work 
correctly for this reply.

>I don't think the UDHR needs IETF consensus.

I'll comment about the UDHR below.

>I don't think the mission would be at odds with that.

The following may turn into an issue then: 
https://www.ietf.org/mail-archive/web/hrpc/current/msg00801.html

>I do not know.

If I recall correctly, I provided a reference to show that there are 
at least a few participants who are uncomfortable to discuss about 
"non-technical" topics.  I have met attendees who reside in what some 
people might view as "difficult" countries.

>If you have an posiyion about this it would be great to hear your arguments.

I would describe "censorship resistance" as a public policy issue if 
I were to write to the regulator about it.  I usually avoid 
discussing such matters outside the national context.

>The IETF is indeed a private entity.

There are some recommendations at 
https://documents-dds-ny.un.org/doc/UNDOC/GEN/G16/095/12/PDF/G1609512.pdf?OpenElement 
Page 9 states that "technical and design choices can have a 
substantial impact on freedom of expression".  I could not find any 
statement about the UDHR or any other right in respect to technical standards.

>Not sure what is meant by this.

I was asking about whether it would be the responsibility of the 
companies or NGOs participating in the IETF to make human 
rights-oriented contributions to technical discussions.

>I am not sure what the consequences of a conclusion on this would be. As
>said, we have been aiming to get quite a lot of input on this draft, and
>we had reviewers and contributors from different continents.

In the absence of statistics it is not possible to verify whether the 
above is actually correct.  I took a quick look at the mailing list 
archive and I could not find any review from, for example, South 
America.  I could not find any review from, for example, a country 
from Asia from which a significant number of IETF attendees come 
from.  It may raise questions about the conclusion has some bias.

>It would be great if you could help us find a reviewer from Africa. Then
>we would have reviewers from all continents.

I doubt that one reviewer would be representative of that 
continent.  There is an "IETF Africa" mailing list.  I am not sure 
whether it would help you find a reviewer; still, it may be worth a try.

>What IETF body do you mean? And what has that to do with a text on an
>external website?

I don't think that a statement to a UN Office has the same weight as 
one sent to an external website.  I would have to ask questions to 
find out which IETF body is responsible for such issues.

>I agree, but not all scripts are serviced by UTF-8, that is the reason
>for this addition, so if someone uses something else, it should be
>properly tagged.

Could the research group please provide an example of a script which 
is not serviced by UTF-8?

It is not that easy to reply on tagging as there are cases where the 
tagging would fail in practice.

>The reference is not to an open standard.

Ok.

>I think the definition follows the one of Adam Thiere, and he does not
>solely aim at governments as you indicate between square brackets.
>
>https://www.cato.org/publications/cato-online-forum/embracing-culture-permissionless-innovation

I read that part of the book again.  If the approval of a government 
entity was not required, which other entity which is not considered 
as "government" would give such approval?

The reference provided above is one related to "Strategy for American 
Innovation".  There is the following point: "Unless a compelling case 
can be made that a new invention or business model will bring serious 
harm to individuals, innovation should be allowed to continue 
unabated and problems, if they develop at all, can be addressed 
later".  That could be read as meaning that human rights 
considerations should be addressed later when there is evidence that 
there has been a compelling case of serious harm.

>I think there are a lot of contentious discussion in the IETF, else we
>would not have as many discussions. They are exactly about encryption,
>privacy, etc, as the topics that are covered in the book you refer to.

Yes.

>No, that was also not what I claimed at any time.

Ok.

Regards,
S. Moonesamy  


From nobody Wed Jan 18 12:37:50 2017
Return-Path: 
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 6D43512947E for ; Wed, 18 Jan 2017 12:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 qcz4IqKzIDu8 for ; Wed, 18 Jan 2017 12:37:46 -0800 (PST)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 9EA3512007C for ; Wed, 18 Jan 2017 12:37:46 -0800 (PST)
Received: by mail-yb0-x22a.google.com with SMTP id w194so7943695ybe.0 for ; Wed, 18 Jan 2017 12:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=NS6wojuPeqmh2z3pKGlhT+YYOMVuM2ycaKu+AYq04f8=; b=GOVJsEt7em04AwYKVO5xGQbVdEnOLNxAg1ftIEv7gLRghJc/qyIzHzq8tpg2XhutKh ZoDeRni+YeIGnB8MMYLsidgG8lhId8d9ZQ+6WxJ1x1P7yX6VFygE90ki8O0kY9P9Tl1N oIlFp1oSTgavWlMIJA3bwKM2U+9dnARHq85tMJVVi7Stq3HaSwwgeJjWhVTvyUpjEIaS Oa67uNZu3dnW4eNK3a+L7fCx7ON1gbBQXJgS1oMrA9nyzBcm16vMqTFr5nsxmUHk3J/8 0Hs2OYnddke8mQ9Eup1iGHnRcp96mnLEL6X8spyAR3P4sH7eBui1yBP43MvXjm6VWL1+ o/0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NS6wojuPeqmh2z3pKGlhT+YYOMVuM2ycaKu+AYq04f8=; b=sD3tPcjFg/LjPLEuhhUmKMbDMqIzP3HSDqp7CCdnm92F9Zzr6JU3he+FF6D+Y16k51 aa06SIul+kjD/FTtdR2oYRsXLeHYunMs5/YJjVOn5aAZQEV+spDNIcEPQNCSCxX3nSpz pzWuWZMzc1cCsEfeUzCl1Moz4sRaxiN6TMKXovx1NIS3Xj23SnTRh9v5Z/mQQfepvw7Z v0pGsYdI9ZA1xsqIOgQZdxBIZhhgRF5qa47LbEkS0Y37FWsFgvSjNzABS2lsux2ykXA/ I0y/QPe7ow2259crgVszzVO9ANad1/u7R3cG6gjRUJpCDpz4y233MEZyrOPJPJS+jj8u TEig==
X-Gm-Message-State: AIkVDXKltxhoypYY75FTuAHWBxO4ihGQqPslqsiLQOBV2+Ovpqla4/X+ObYAAFGoAFmTem34Llxz8RQVhwpIbA==
X-Received: by 10.37.76.137 with SMTP id z131mr3828131yba.183.1484771865803; Wed, 18 Jan 2017 12:37:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.65.2 with HTTP; Wed, 18 Jan 2017 12:37:45 -0800 (PST)
From: "Matthias C. Kettemann" 
Date: Wed, 18 Jan 2017 21:37:45 +0100
Message-ID: 
To: S Moonesamy 
Content-Type: multipart/alternative; boundary=001a113e5468a2730205466463f2
Archived-At: 
Cc: Corinne Cath , Niels ten Oever , hrpc@irtf.org
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 20:37:49 -0000

--001a113e5468a2730205466463f2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi there

On Wed, Jan 18, 2017 at 8:57 PM, S Moonesamy  wrote:
>
>
> There are some recommendations at https://documents-dds-ny.un.or
> g/doc/UNDOC/GEN/G16/095/12/PDF/G1609512.pdf?OpenElement Page 9 states
> that "technical and design choices can have a substantial impact on freed=
om
> of expression".  I could not find any statement about the UDHR or any oth=
er
> right in respect to technical standards.
>
> Not sure what is meant by this.
>>
>
> I was asking about whether it would be the responsibility of the companie=
s
> or NGOs participating in the IETF to make human rights-oriented
> contributions to technical discussions.



Just my two cents here, especially as the silent college of international
human rights lawyers-scholars was called upon in an earlier mail:

As the "Ruggie Principles
"
(the UN "Protect, Respect and Remedy" Framework) cofirm, Internet companies
must in all their actions respect the internationally recognised human
rights and fundamental freedoms of their users and of non-users who are
affected by their activities. The responsibility to respect human rights
exists independently of the States=E2=80=99 ability or willingness to fulfi=
ll their
own human rights obligations. The same applies arguably to non-governmental
actors. Therefore the answer would be: yes, companies and company
representatives (and anyone really) involved in standardization in any form
must respect human rights.

Though interpretations of the concrete duties flowing from this duty of
respect may differ, the duty itself isn't really controversial anymore.

See, e.g., the Principles of the Telecommunications Industry Dialogue


"The UN =E2=80=98Protect, Respect, and Remedy=E2=80=99 framework defines it=
 as; 1. the
state=C2=B4s duty to protect human rights, and 2. the corporate responsibil=
ity
to respect human rights.iii =E2=80=A2 The ICCPR recognises that the rights =
to
freedom of expression and privacy can only be restricted in limited
circumstances.iv =E2=80=A2 The OECD framework states that =E2=80=9C[a] Stat=
e=E2=80=99s failure
either to enforce relevant domestic laws, or to implement international
human rights obligations or the fact that it may act contrary to such laws
or international obligations does not diminish the expectation that
enterprises respect human rights."

We find a similar approach in the Global Network Initiative's Principles
:

"The duty of governments to respect, protect, promote and fulfill human
rights is the foundation of this human rights framework. That duty includes
ensuring that national laws, regulations and policies are consistent with
international human rights laws and standards on freedom of expression and
privacy.

Information and Communications Technology (ICT) companies have the
responsibility to respect and protect the freedom of expression and privacy
rights of their users. ICT has the potential to enable the exchange of
ideas and access to information in a way that supports economic
opportunity, advances knowledge and improves quality of life."

In implementing the duty to respect, companies have to prepare, inter
alia, human
rights impact assessment and ensure that HR-sensitive due diligence
processes are implemented at all stages of business.

If I understand this laudable effort here correctly, setting standards for
an HR impact assessment in standardization processes is exactly its
(important) aim.

Kind regards

Matthias





--=20

Dr. Matthias C. Kettemann, LL.M. (Harvard)
Post-Doc Fellow | Co-Head | Research Group Internet and Society
,
Cluster of Excellence =E2=80=9E
=
Normative
Orders
=
=E2=80=9D
=
,
University of Frankfurt am Main
Lecturer | Institute of International Law and International Relations
, University of Graz, Austria


Goethe-Universit=C3=A4t Frankfurt am Main, Exzellenzcluster =E2=80=9ENormat=
ive Ordnungen=E2=80=9C
Max-Horkheimer-Stra=C3=9Fe 2, 60323 Frankfurt am Main, Germany

E | matthias.kettemann@gmail.com
Blog  | Google Scholar
 | Twitter
 | Facebook
 | Google+




European Yearbook on Human Rights 2016 (2016)
V=C3=B6lkerrecht
in Zeiten des Netzes (2015)

Freedom of Expression and the Internet (2014, co-author)


--001a113e5468a2730205466463f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi there

On Wed, Jan 18, 2017 at 8:57 PM, S Moonesamy =
<sm+ietf@eland=
sys.com> wrote:



There are some recommendations at https://documents-dds-ny.un.org/doc/UNDOC/GEN/G16/0=
95/12/PDF/G1609512.pdf?OpenElement Page 9 states that "techni=
cal and design choices can have a substantial impact on freedom of expressi=
on".=C2=A0 I could not find any statement about the UDHR or any other =
right in respect to technical standards.





Not sure what is meant by this.





I was asking about whether it would be the responsibility of the companies =
or NGOs participating in the IETF to make human rights-oriented contributio=
ns to technical discussions.


Just my two cents here, especially as the silent college of international =
human rights lawyers-scholars was called upon in an earlier mail:=C2=A0

As the "Ruggie Principles" (the UN "Prot=
ect, Respect and Remedy" Framework) cofirm, Internet companies must in=
 all their actions respect the internationally
recognised human rights and fundamental freedoms of their users and of
non-users who are affected by their activities. The responsibility to respe=
ct
human rights exists independently of the States=E2=80=99 ability or willing=
ness to
fulfill their own human rights obligations. The same applies arguably to no=
n-governmental actors. Therefore the answer would be: yes, companies and co=
mpany representatives (and anyone really) involved in standardization in an=
y form must respect human rights.

Though interpretations of the concrete duties =
flowing from this duty of respect may differ, the duty itself isn't rea=
lly controversial anymore.

See, e.g., the=C2=A0Principles of the Telecommunications Industry Dialo=
gue=C2=A0

"The UN =E2=80=98Protect, Respect, and Remedy=E2=80=99 framew=
ork defines it as;
1. the state=C2=B4s duty to protect human rights, and
2. the corporate responsibility to respect human rights.iii
=E2=80=A2 The ICCPR recognises that the rights to freedom of expression and=
 privacy can only be
restricted in limited circumstances.iv
=E2=80=A2 The OECD framework states that =E2=80=9C[a] State=E2=80=99s failu=
re either to enforce relevant domestic laws,
or to implement international human rights obligations or the fact that it =
may act contrary to
such laws or international obligations does not diminish the expectation th=
at enterprises respect
human rights."
We fin=
d a similar approach in the Global Network Initiative's Principles:=C2=A0=


=

"The duty of governments to r=
espect, protect, promote and fulfill human rights is the foundation of this=
 human rights framework. That duty includes ensuring that national laws, re=
gulations and policies are consistent with international human rights laws =
and standards on freedom of expression and privacy. =C2=A0

Information and Com=
munications Technology (ICT) companies have the responsibility to respect a=
nd protect the freedom of expression and privacy rights of their users. ICT=
 has the potential to enable the exchange of ideas and access to informatio=
n in a way that supports economic opportunity, advances knowledge and impro=
ves quality of life."

In implementing the duty to=
 respect, companies have to prepare, inter alia,=C2=A0human rights impact assessment and ensure t=
hat HR-sensitive=C2=A0due diligence processes are implemented at all stages of business.

If I u=
nderstand this laudable effort here correctly, setting standards for an HR =
impact assessment in standardization processes is exactly its (important) a=
im.=C2=A0

Kind regards

Matthias=C2=A0








-- 
<=
div dir=3D"ltr">
Dr. Matthias C. Kettemann, L=
L.M. (Harvard)
Post-Doc Fellow | Co-Head | Research Group Internet and Society, Cluster of=
 Excellence =E2=80=9ENormative
Orders=E2=80=
=9D, University of Frankfurt am Main=

Lecturer |=C2=A0Institute of In=
ternational Law and International Relations, University of Graz, Austri=
a
Goethe-Universit=C3=A4t Frankfurt am Main, Exzellenzcluster =
=E2=80=9ENormative Ordnungen=E2=80=9C
Max-Horkheimer-Stra=C3=9Fe 2, 6032=
3 Frankfurt am Main, Germany
E=
 |=C2=A0m=
atthias.kettemann@gmail.com
Blog<=
/a>=C2=A0|=C2=A0Google Scholar=
=C2=A0| Twitter=C2=A0|=
=C2=A0Facebook=
=C2=A0|=C2=A0Google+
<=
p style=3D"margin-bottom:0.0001pt">


European
Yearbook on Human Rights 2016 (2016)
V=C3=B6lkerrecht in Zeiten des Net=
zes (2015)
Freedom of Expression and th=
e Internet (2014, co-author)
<=
/div>




--001a113e5468a2730205466463f2--


From nobody Wed Jan 18 15:06:52 2017
Return-Path: 
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 76234129410 for ; Wed, 18 Jan 2017 15:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level: 
X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 m0aHelfWyTnV for ; Wed, 18 Jan 2017 15:06:50 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A23B1294BD for ; Wed, 18 Jan 2017 15:06:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2437; q=dns/txt; s=iport; t=1484780809; x=1485990409; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=qI8Hu9DgYNjiP5NaBtNEdtpNSL7bveBB91mHOx2ncek=; b=MKaY9IXZzUIbBnpvkm68rC7Ti07T7/cydGBV56qu+BBKQ6hc19s66BTb rNEprmUZMUY/r9Dv/CLyZJPnuS8eVVUaUwprAd4xriz/4qe1+OzPHASp3 m4w5qEzPgITBpJkZs0nsD56A12N6OZbpZLXOhTpBMWXro7l6iKzLwWber 8=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQBr9H9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAYEphDCKCHKQcR+VLIILhiICgkMYAQIBAQEBAQEBYyi?= =?us-ascii?q?EagEFI2YLDgoqAgJXBgEMCAEBiH+wEoIlGYolAQEBAQEBBAEBAQEBARMPiFAIg?= =?us-ascii?q?mGHT4JeBZtBg2qCAIt4ii+GPpJvHziBFRIIFRWGbj2JNgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,250,1477958400";  d="asc'?scan'208";a="691482059"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 23:06:47 +0000
Received: from [10.61.64.129] (ams3-vpn-dhcp129.cisco.com [10.61.64.129]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0IN6lBY030373; Wed, 18 Jan 2017 23:06:47 GMT
To: Andrew Sullivan , hrpc@irtf.org
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com> <20170118175708.GE664@mx2.yitter.info>
From: Eliot Lear 
Message-ID: <4075fb17-2446-01c8-41e2-150d9b229a2f@cisco.com>
Date: Thu, 19 Jan 2017 00:06:46 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170118175708.GE664@mx2.yitter.info>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4wq1T82uDOnKDo8X0MxJN3DLw3P3iO0Fx"
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 23:06:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4wq1T82uDOnKDo8X0MxJN3DLw3P3iO0Fx
Content-Type: multipart/mixed; boundary="kOwXaiNgem6CFRkhtRiCf1ORw7B5EtC5J";
 protected-headers="v1"
From: Eliot Lear 
To: Andrew Sullivan , hrpc@irtf.org
Message-ID: <4075fb17-2446-01c8-41e2-150d9b229a2f@cisco.com>
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>
 <20170118134432.GA15699@sources.org>
 <003ca204-b264-0150-7163-15a657acc312@cisco.com>
 <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org>
 <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com>
 <20170118175708.GE664@mx2.yitter.info>
In-Reply-To: <20170118175708.GE664@mx2.yitter.info>

--kOwXaiNgem6CFRkhtRiCf1ORw7B5EtC5J
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Andrew,

I too find it strange to aim for consensus, mostly because truth doesn't
rest on such a political concept.  Be that as it may, I'm not seeking
perfection, either in the process or the work.  Still, it's best to know
that there are those who understand and agree (or at least do not
object) to the usage of such references as [UDHR], [Cath], [Jabri],
[Schroeder], and [King] in the same way that you would assess reference
to [RFC1958].

Eliot

On 1/18/17 6:57 PM, Andrew Sullivan wrote:
> If this were an IETF document, I think it would be in trouble because
> the rough seems large and multifaceted.  But for a research document,
> there's nothing wrong with that outcome normally.  Why is this case
> special?
>



--kOwXaiNgem6CFRkhtRiCf1ORw7B5EtC5J--

--4wq1T82uDOnKDo8X0MxJN3DLw3P3iO0Fx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJYf/UHAAoJEIe2a0bZ0nozHMkIANay37NBd3nZbh7J9w1mlDVZ
/mpRenyNZTI2Zho/Y9UHiLAXwOqXy4f/Xlpa++TdCQZ0fic5OjV3NH/znANUQmE4
eECForE6UHh3nYF19utrGh+fkWFuxmo16ksV4dour9NbgIvAen72R48ZUoie7ayZ
gGmAs89pNFZ/AEKuWJ3zYO8RykRdJeElFUboaEwIgwTBklI7SNmT1+yteZUvBGN5
ZchY5Cn0KecWr/0SZjT8yY/a3MOWP1pP1ttdXjmAFpxcC1FjR9uWc4w1Risdzobu
4oNMYO7UU8w3SzN+goJJP2CoXlVWhvQXsQxskJjexJ7TqVajmic5iy3FUNxDERc=
=s5r6
-----END PGP SIGNATURE-----

--4wq1T82uDOnKDo8X0MxJN3DLw3P3iO0Fx--


From nobody Wed Jan 18 15:46:44 2017
Return-Path: 
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 31ABF126D74 for ; Wed, 18 Jan 2017 15:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0Sd9qJ3V9SiR for ; Wed, 18 Jan 2017 15:46:40 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 6B3611294C1 for ; Wed, 18 Jan 2017 15:46:39 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cTzw1-0005jT-Kh; Thu, 19 Jan 2017 00:46:34 +0100
To: S Moonesamy , hrpc@irtf.org
References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com>  <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>
From: Niels ten Oever 
Message-ID: 
Date: Thu, 19 Jan 2017 00:46:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xUixXoGbs670GWaUolKFLSOXcGWwt6JnP"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: dc8946a4a12faf76f1d2482f064982a7
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 23:46:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xUixXoGbs670GWaUolKFLSOXcGWwt6JnP
Content-Type: multipart/mixed; boundary="TWMf6CflIwkLVbBGt3I3A5iu0Nrk2iuqr";
 protected-headers="v1"
From: Niels ten Oever 
To: S Moonesamy , hrpc@irtf.org
Cc: Corinne Cath 
Message-ID: 
Subject: Re: Comments about draft-irtf-hrpc-research-07
References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com>
 <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org>
 <6.2.5.6.2.20170105220522.0c4da628@elandnews.com>
 <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org>
 <6.2.5.6.2.20170106104124.102ab508@elandnews.com>
 
 <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>
In-Reply-To: <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>

--TWMf6CflIwkLVbBGt3I3A5iu0Nrk2iuqr
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi S Moonesamy,


On 01/18/2017 08:57 PM, S Moonesamy wrote:
> Hi Niels,
> At 14:36 17-01-2017, Niels ten Oever wrote:
>> PS It would be great if you could leave the thread intact so the
>> discussion is easier for people to follow (and to respond to).
>=20
> I apologize for that.  I sent a subscription request last year through
> https://www.irtf.org/mailman/listinfo/hrpc  I assumed that the research=

> group might be a closed group as I did not receive an email
> confirmation.  For what it is worth, the threading should work correctl=
y
> for this reply.
>=20
>> I don't think the UDHR needs IETF consensus.
>=20
> I'll comment about the UDHR below.
>=20
>> I don't think the mission would be at odds with that.
>=20
> The following may turn into an issue then:
> https://www.ietf.org/mail-archive/web/hrpc/current/msg00801.html
>=20

Why?

>> I do not know.
>=20
> If I recall correctly, I provided a reference to show that there are at=

> least a few participants who are uncomfortable to discuss about
> "non-technical" topics.  I have met attendees who reside in what some
> people might view as "difficult" countries.
>=20

That was a reference to the IETF 100 discussion, I think that was quite
a different context. That was also the email of one person.

I think the draft also shows the relation to technical topics, if it had
nothing to do with technology or protocols it would indeed not belong her=
e.

>> If you have an posiyion about this it would be great to hear your
>> arguments.
>=20
> I would describe "censorship resistance" as a public policy issue if I
> were to write to the regulator about it.  I usually avoid discussing
> such matters outside the national context.
>=20

Would you say the same about pervasive monitoring?

>> The IETF is indeed a private entity.
>=20
> There are some recommendations at
> https://documents-dds-ny.un.org/doc/UNDOC/GEN/G16/095/12/PDF/G1609512.p=
df?OpenElement
> Page 9 states that "technical and design choices can have a substantial=

> impact on freedom of expression".  I could not find any statement about=

> the UDHR or any other right in respect to technical standards.
>=20

The right to freedom of expression is article 19 of the UDHR.

>> Not sure what is meant by this.
>=20
> I was asking about whether it would be the responsibility of the
> companies or NGOs participating in the IETF to make human
> rights-oriented contributions to technical discussions.
>=20

See the e-mail of Matthias Ketteman about this, as well as the report of
the UN Special Rapporteur on Freedom of Exporession I referred to earlier=
=2E


>> I am not sure what the consequences of a conclusion on this would be. =
As
>> said, we have been aiming to get quite a lot of input on this draft, a=
nd
>> we had reviewers and contributors from different continents.
>=20
> In the absence of statistics it is not possible to verify whether the
> above is actually correct.  I took a quick look at the mailing list
> archive and I could not find any review from, for example, South
> America. =20

Giovane Moura

> I could not find any review from, for example, a country from
> Asia from which a significant number of IETF attendees come from.  It
> may raise questions about the conclusion has some bias.
>=20

I am happy to name more people (you've also seen several in the film),
but it still actually a precondition to any document in the IRTF or IETF
? I think this is something we actually address; more diversity is
needed. But that should not bar us from doing work now, because that
would not solve the issue either.

>> It would be great if you could help us find a reviewer from Africa. Th=
en
>> we would have reviewers from all continents.
>=20
> I doubt that one reviewer would be representative of that continent.=20
> There is an "IETF Africa" mailing list.  I am not sure whether it would=

> help you find a reviewer; still, it may be worth a try.
>=20

I have already posted there, but thanks for the advice.

>> What IETF body do you mean? And what has that to do with a text on an
>> external website?
>=20
> I don't think that a statement to a UN Office has the same weight as on=
e
> sent to an external website.  I would have to ask questions to find out=

> which IETF body is responsible for such issues.
>=20

You got me confused now. What statement to which UN office?

>> I agree, but not all scripts are serviced by UTF-8, that is the reason=

>> for this addition, so if someone uses something else, it should be
>> properly tagged.
>=20
> Could the research group please provide an example of a script which is=

> not serviced by UTF-8?
>=20

This point was brought up by Stephane, Stephane could you help out?

> It is not that easy to reply on tagging as there are cases where the
> tagging would fail in practice.
>=20
>> The reference is not to an open standard.
>=20
> Ok.
>=20
>> I think the definition follows the one of Adam Thiere, and he does not=

>> solely aim at governments as you indicate between square brackets.
>>
>> https://www.cato.org/publications/cato-online-forum/embracing-culture-=
permissionless-innovation
>>
>=20
> I read that part of the book again.  If the approval of a government
> entity was not required, which other entity which is not considered as
> "government" would give such approval?
>=20

Thiere talks about needing no permission from social norms,
institutions, companies as well as governments to innovate. Not solely
governments.

> The reference provided above is one related to "Strategy for American
> Innovation".  There is the following point: "Unless a compelling case
> can be made that a new invention or business model will bring serious
> harm to individuals, innovation should be allowed to continue unabated
> and problems, if they develop at all, can be addressed later".  That
> could be read as meaning that human rights considerations should be
> addressed later when there is evidence that there has been a compelling=

> case of serious harm.
>=20

I think what we're doing here is not throw up a barrier, exactly the
opposite, ensure that the model will not be hampered by external
barriers (governments), because we have thought of a way to respect
human rights ourselves. Else other parties might come in and do it for
us, if we don't take our responsibility.

>> I think there are a lot of contentious discussion in the IETF, else we=

>> would not have as many discussions. They are exactly about encryption,=

>> privacy, etc, as the topics that are covered in the book you refer to.=

>=20
> Yes.
>=20
>> No, that was also not what I claimed at any time.
>=20
> Ok.
>=20

Best,

Niels

> Regards,
> S. Moonesamy=20


--TWMf6CflIwkLVbBGt3I3A5iu0Nrk2iuqr--

--xUixXoGbs670GWaUolKFLSOXcGWwt6JnP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAlh//lAACgkQDtg/OkaK
yLMRXhAAjuxGacQF6hVDMFrBJ97zeaQAdzO/hiNd5Mv7EDEYbgr4rR3hKKjtYwPq
g3p4hIBMsIvVZ1yOjH5EoA3BJUVUgi1SA1Q5AX6VwkKBV1FY5SJVbVfdh6UC0qrx
Pe5WghewpVwrrbQ4NWdjuX+8+/6SK5eDEvTOwZzgVqgw77Vw5ggG1aMja1BKN5nf
qdCSCxSbosalHvKtdfN7vNgcodRHJkp4mXBMNk+1BYl3TqhuCCrWtqBCpq5mhnS1
ASoBKUr2HzHSdaW5SCckDopoggd4s+ycJrWgQ5oR4qfNU/ZZaoXUsra8mvsn5rYS
qDIZTpoZrcCJqRRbg+DjjQLRMb12bqLVbZYlQtAkVbOo+6SjxmlFyTezHpgc99zA
KCQ3eo1WTTr3ejBHBj+GKZNpjrD523ZeU+AfHNng1iwo0ek9O9dxbiuTHniZvAeC
hH8LkPuwuXQ/jDR6615QGDR9GVM5IatKy9zqFDq86mrjMpOqARlEAYOPrDyrYlVa
3RDjukGahjF0EEkDvQKSNv1jWW0ELalmEDkf+Fzd3Ki2btiLa0btbyG6hdkSQbvT
eGwyYOKOOFTeWpTLUQxsXy1w/xScFALjAn4q6Lxfc8tMP8yHzUueP4LNjdDp/IUa
5f15ezRj4Eh6ZuBJpANglw8mnrI2EGgEkS0FhnrBpvV03Bt5ndM=
=0A1S
-----END PGP SIGNATURE-----

--xUixXoGbs670GWaUolKFLSOXcGWwt6JnP--


From nobody Wed Jan 18 15:50:43 2017
Return-Path: 
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 9C3FE129410 for ; Wed, 18 Jan 2017 15:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 XjD4-jAWUeE6 for ; Wed, 18 Jan 2017 15:50:41 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 A124D126D74 for ; Wed, 18 Jan 2017 15:50:41 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cU000-0006WJ-24 for hrpc@irtf.org; Thu, 19 Jan 2017 00:50:40 +0100
To: hrpc@irtf.org
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com> <20170118175708.GE664@mx2.yitter.info>
From: Niels ten Oever 
Message-ID: 
Date: Thu, 19 Jan 2017 00:50:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <20170118175708.GE664@mx2.yitter.info>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vxPkd8xBmBU59LdsEwDF42aR30X5eNXCU"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 388a8ff653e0601f0215f26536afca72
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 23:50:42 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vxPkd8xBmBU59LdsEwDF42aR30X5eNXCU
Content-Type: multipart/mixed; boundary="JcGGMWABeJd4vdENcMvENimLD40a68VNC";
 protected-headers="v1"
From: Niels ten Oever 
To: hrpc@irtf.org
Message-ID: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>
 <20170118134432.GA15699@sources.org>
 <003ca204-b264-0150-7163-15a657acc312@cisco.com>
 <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org>
 <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com>
 <20170118175708.GE664@mx2.yitter.info>
In-Reply-To: <20170118175708.GE664@mx2.yitter.info>

--JcGGMWABeJd4vdENcMvENimLD40a68VNC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Andrew,

On 01/18/2017 06:57 PM, Andrew Sullivan wrote:
> I've made several suggestions not all
> of which have been IMO incorporated, but I think the authors are in a
> position to do make that call.
>=20

I am sorry to hear that, I would be happy to review specific issues
again to see if we can come to compromise. I thought we had already come
to that point.


> If this were an IETF document, I think it would be in trouble because
> the rough seems large and multifaceted.=20

I was under the impression we were doing quite OK with addressing issues
and finding solutions. Luckily I will not need to be the judge of that.

But if people want to point out issues I am more than eager to work
finding solution for consensus with you all.

Best,

Niels (with author hat on)



--JcGGMWABeJd4vdENcMvENimLD40a68VNC--

--vxPkd8xBmBU59LdsEwDF42aR30X5eNXCU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAlh//04ACgkQDtg/OkaK
yLOJZA/+IJC1R4LBoO7LbPNd8vWH19+c9CFGeukIXucSLNHJBsDchuwfivwNiXqY
ss5ZLtzp4EQ1gVQTCLH93k6ap7zKn7oVggdSqXs6UcncmXd+UqZ88DDxr1WzcRe4
SKN5NvnsRzAwnBQADL8IdMZuqydE2kbRpLQbmametudRl4+F9P7SyS4NKTJYQhJg
IBIy44Rc3BtKX5USrBEtliCrQXqZ8+oPD2okZ5Dx72HdXQHvZH4DalTj3we80V6X
4gftSpnhwXoLZQ81WqKkFsSkls7ClAZDPVp/E66W79E4ifgSaLIJhwScRqP/28Eg
lChu+6Pi6O+dpo384mrmNyaRRvmCrpHxs5yLqWeSrxxOKmzZCwbY9LvvQmqk/HbN
UqV+Ssa91AxCeQXpSluAxMWqXRAeWqrXEXT1GSLWSXW5+lWLUFVtoiRvEsW1HpIr
4bawBcxkgg1+7KgW4q3FL1lP24p4sVj5Cni8wSHGcyHucBz//4bmlDFKoGNmEr01
V8cBgfkklV25yssc6sNnW0UY5UV86KBEqrQ5t3uHNyh01AimPVQNlfpGegBsvhwn
FD+wr7uqwVsIKNrWmg06+uawg+Wq/iW2CxuGUHYPjD0stp2idC4GOPW2gdiNwI7W
yKx0Ikn50OhRCzkm5is+yf2nZQGiPMLnzhw2UVk8RSmJrYTdUm0=
=nG7s
-----END PGP SIGNATURE-----

--vxPkd8xBmBU59LdsEwDF42aR30X5eNXCU--


From nobody Wed Jan 18 17:40:13 2017
Return-Path: 
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 0168E129451 for ; Wed, 18 Jan 2017 17:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YepIxejiLyky for ; Wed, 18 Jan 2017 17:40:10 -0800 (PST)
Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id B51801295DF for ; Wed, 18 Jan 2017 17:40:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 321CB1159A for ; Thu, 19 Jan 2017 01:40:12 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj42jiGMwySg for ; Thu, 19 Jan 2017 01:40:11 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 6800B1155F for ; Thu, 19 Jan 2017 01:40:11 +0000 (UTC)
Date: Wed, 18 Jan 2017 20:40:07 -0500
From: Andrew Sullivan 
To: hrpc@irtf.org
Message-ID: <20170119014007.GM664@mx2.yitter.info>
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com> <20170118175708.GE664@mx2.yitter.info> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 01:40:12 -0000

On Thu, Jan 19, 2017 at 12:50:38AM +0100, Niels ten Oever wrote:
> 
> I am sorry to hear that, I would be happy to review specific issues
> again to see if we can come to compromise. I thought we had already come
> to that point.

I've pointed out recently, for instance, a case where we deeply
disagree about the interpretation of RFC 1958.  It's your research
publication, so you get to say what you want, though, and therefore I
don't think it appropriate to press any more on it.  

> > If this were an IETF document, I think it would be in trouble because
> > the rough seems large and multifaceted. 
> 
> I was under the impression we were doing quite OK with addressing issues
> and finding solutions.

I think the RG appears to be converging on things in a way that the RG
can live with and that would be appropriate for an IRTF RG to publish.
My comments, at least, have all been with the filter that this is an
IRTF RG document and that ultimately it cannot govern IETF work.  I
think the questions that people might ask themselves are potentially
useful, and a way to learn about their utility is to publish a
document and then see what people do with it.  

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Thu Jan 19 01:10:48 2017
Return-Path: 
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 BAB8C129424 for ; Thu, 19 Jan 2017 01:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Oa17Tsd0NhNp for ; Thu, 19 Jan 2017 01:10:44 -0800 (PST)
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 089EE127ABE for ; Thu, 19 Jan 2017 01:10:43 -0800 (PST)
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 1cU8jw-00038W-Oc; Thu, 19 Jan 2017 10:10:40 +0100
Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 9D34FB00589; Thu, 19 Jan 2017 10:10:40 +0100 (CET)
From: "Bless, Roland (TM)" 
To: Niels ten Oever , hrpc@irtf.org
References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <1bc65daf-42ec-4836-61d4-a5fa0ece0062@article19.org>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Message-ID: <027298fb-c427-7a17-e41a-13c93b5b7063@kit.edu>
Date: Thu, 19 Jan 2017 10:10:40 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
In-Reply-To: <1bc65daf-42ec-4836-61d4-a5fa0ece0062@article19.org>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1484817040.
Archived-At: 
Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 09:10:48 -0000

Hi Niels,

sorry for the late reply, please see comments inline.

Am 10.01.2017 um 11:22 schrieb Niels ten Oever:
> On 01/10/2017 01:35 AM, Roland Bless wrote:
>> Hi Avri and all,
>>
>> On 04.12.2016 at 20:54 avri doria wrote:
>>> Please send all comment to the HRPC email list: hrpc@irtf.org.  I do
>>> hope that some good discussions occur on this list where the
>>> resolution to any issues may be forged. Discussion has been shown to
>>> improve this draft.
>>
>> Unfortunately, I didn't manage the full review write-up after returning
>> from holidays today. Nevertheless, I have some general comments and try
>> to provide more detailed comments later today.
>>
>> Overall, I think the draft is good to raise awareness for
>> the issue that sometimes technical decisions may impact human rights.
>> However, it falls a bit short on the problem that even human rights
>> get in conflict with each other and that conflict resolution is
>> hard to decide on,
> 
> This section aims to address that:
> 
>    Human rights can be in conflict with each other, such as the right to
>    freedom of expression and the right to privacy.  In such as case the
>    different affected rights need to be balanced.  In order to do this
>    it is crucial that the rights impacts are clearly documented in order
>    to mitigate the potential harm in a proportional way.  Making that
>    process tangible and practical for protocol developers is what this
>    research aims to ultimately contribute to.  Technology can never be
>    fully equated with a human right.  Whereas a specific technology
>    might be strong enabler of a specific human right, it might have an
>    adverse impact on another human right.  In this case decisions on
>    design and deployment need to take this into account.
> 
> You think this is inadequeate? If so, would you have text suggestions?

No, that paragraph is really fine (except for that "proportional way"),
my point was that the rest of the document has more a tone of "translate
this human right to a technical concept and make sure that
this concept is used in order to enable the human right." and seems
to suggest enforcing or enabling human rights by building certain
mechanisms into protocols. This is different from trying to achieve
awareness for impacts on human rights. So maybe it is easy to fix by
rephrasing certain passages in the text, e.g.,
"List technical terms that combined create enabling environment
for human rights", "Translating human rights to technical terms",
"on whether the protocol adequately protects against specific human
rights threats." (maybe the protocol doesn't need a built-in
protection, but operational aspects need to be regulated, e.g.,
namespace assignment etc.).

>  or is maybe not possible or desirable to built
>> into a technical system (because it's too rigid then).
> 
> This sections aims to address this:
> 
> ur position is that hard-coding human rights into
>    protocols is complicated and changes with the context.  At this point
>    is difficult to say whether hard-coding human rights into protocols
>    is wise or feasible.  It is however important to make conscious and
>    explicit design decisions that take into account the human rights
>    protocol considerations guidelines developed above.  This will ensure
>    that the impact protocols can have on human rights is clear and
>    explicit, both for developers and for users.  In addition, it ensures
>    that the impact of specific protocol on human rights is carefully
>    considered and that concrete design decisions are documented in the
>    protocol.
> 
> You think this is inadequeate? If so, would you have text suggestions?

That is basically fine, but as pointed out above the rest of the draft
reads more like suggesting to built-in HR enabling mechanisms or at
least to support those.

It think that this statement here:
>    This will ensure
>    that the impact protocols can have on human rights is clear and
>    explicit, both for developers and for users.

is a little bit too strong. Even if one has read the document the impact
isn't always _clear_ and explicit. So IMHO the aim is to show that there
_is_ an impact that one should consider, however, in some cases it may
remain quite unclear how strong the impact is etc.

> Do you think this is a sufficient representation of your positions?
> 
>    Bless and Orwat [Bless] represent a fourth position.  They argue that
>    it is too early to make any definitive claims, but that there is a
>    need for more careful analysis of the impact of protocol design
>    choices on human rights.  They also argue that it is important to
>    search for solutions that 'create awareness in the technical
>    community about impact of design choices on social values.  And work
>    towards a methodology for co-design of technical and institutional
>    systems.'
> 
> I'd me more than happy to have a bit more elaborate description.

I'll check with Carsten and propose a text.

Regards,
 Roland


From nobody Thu Jan 19 01:31:59 2017
Return-Path: 
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 A50CA128B37 for ; Thu, 19 Jan 2017 01:31:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 XrKYjA_XOkfB for ; Thu, 19 Jan 2017 01:31:56 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 9685B127ABE for ; Thu, 19 Jan 2017 01:31:56 -0800 (PST)
Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cU94T-00058I-PA; Thu, 19 Jan 2017 10:31:55 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::110]) by titi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cU94T-0002kw-Jp; Thu, 19 Jan 2017 10:31:53 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Marco Hogewoning 
In-Reply-To: <20170119014007.GM664@mx2.yitter.info>
Date: Thu, 19 Jan 2017 10:31:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com> <20170118175708.GE664@mx2.yitter.info>  <20170119014007.GM664@mx2.yitter.info>
To: Andrew Sullivan 
X-Mailer: Apple Mail (2.3259)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ------------
X-RIPE-Spam-Report: Spam Total Points:   -12.6 points pts rule name              description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED            Passed through trusted hosts only via SMTP -3.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: a70a6483a823252ec3b6bf3d5f17fdcdffe7f4aa084b6559710986031ff0b941
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 09:31:59 -0000

> On 19 Jan 2017, at 02:40, Andrew Sullivan  =
wrote:
>=20
> My comments, at least, have all been with the filter that this is an
> IRTF RG document and that ultimately it cannot govern IETF work.

HI Andrew, Niels, all,

Although I wholly agree with you on process and the status of this work =
as research paper produced by IRTF. We might have to be careful on how =
people further away perceive this. Unfortunately I do not have any =
straight away answer on how to fix this. But for people who are less =
engaged with the inner workings of our forums and especially the =
difference and relationship between IRTF and IETF, this might still =
parse as =E2=80=9CIETF work=E2=80=9D as they are unable to distinguish =
the difference. This could be especially the case when people start =
quoting from it in non-scientific publications, a headline =E2=80=9CThe =
IETF recently=E2=80=A6.=E2=80=9D is quickly written :(

Again, process wise we are totally on the right track here, but it might =
be worth to at least think about the possible side effects, also because =
this topic is so broad and has a lot of interest from groups outside the =
technical community.

MarcoH
(no hats, concerned citizen)=


From nobody Thu Jan 19 03:06:14 2017
Return-Path: 
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 E7A99129465 for ; Thu, 19 Jan 2017 03:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level: 
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=IcHjGTbe; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=P5fE4RaC
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 GVsRzfd4bW2S for ; Thu, 19 Jan 2017 03:06:10 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E86129441 for ; Thu, 19 Jan 2017 03:06:10 -0800 (PST)
Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0JB5pGs016999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2017 03:05:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484823960; x=1484910360; bh=O9VScY63dydWh3a3vGae/A0RfpyJjZjN2YaWceDbc2Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IcHjGTbeJVIuHfYFwdzo2fyo+Dve+mIc/d5UWpVP5YUyC0NxK9tCIWRd+jhy9jB+H S97sbVPEBBZWk0szP6OzbNxDuuaLKtCmxwBd/wApzxJedqGPgzLhRvIAhgGj3QKM2M 9OER+g1v3z5lImtmm4O1bq7AwsCU0RPXkI5uwINc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484823960; x=1484910360; i=@elandsys.com; bh=O9VScY63dydWh3a3vGae/A0RfpyJjZjN2YaWceDbc2Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=P5fE4RaCWH5Lk56UeaC1n4ksEjCwEc6XK0P82c5MuqjgdglyE5Wo8JIwtvtcvtWJH PC4s3Ud+35NUueREOPRvj6HBVyU8YwMUU9OM7SXOd0rQxenPY5ZBrCk3BSae+pwrb/ GrepTsxHLJTPPs8nKvIATV972eNYRF+NFuQab38s=
Message-Id: <6.2.5.6.2.20170118211058.0b393d18@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 19 Jan 2017 03:01:33 -0800
To: Niels ten Oever , hrpc@irtf.org
From: S Moonesamy 
In-Reply-To: 
References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com>  <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 11:06:12 -0000

Hi Niels,
At 15:46 18-01-2017, Niels ten Oever wrote:
>Why?

There are different perspectives to the discussions about "technical 
standards".  The one on which the draft is based is that "the 
mission" is about an entity (or entities) gaining an economic or 
political advantage.  It will be problematic for the IETF if that is 
its mission.

>Would you say the same about pervasive monitoring?

That is an interesting question.  I might review a draft, e.g. 
https://www.ietf.org/mail-archive/web/ietf/current/msg96446.html  Is 
that anything in that review which is a political or public policy question?

>See the e-mail of Matthias Ketteman about this, as well as the report of
>the UN Special Rapporteur on Freedom of Exporession I referred to earlier.

I read the substantive comments from Dr Ketteman and I found them informative.

>[person name removed]

There is a mailing list archive at 
https://www.ietf.org/mail-archive/web/hrpc/current/maillist.html  I 
could not find any review from that person.  A quick verification 
shows that the person resides in The Netherlands.  According to an 
overview published by the European Union, the Netherlands is not a 
country located in South America ( 
https://europa.eu/european-union/about-eu/countries/member-countries/netherlands_en 
).

>I am happy to name more people (you've also seen several in the film),
>but it still actually a precondition to any document in the IRTF or IETF
>? I think this is something we actually address; more diversity is
>needed. But that should not bar us from doing work now, because that
>would not solve the issue either.

My preference is to be provided with URLs to reviews from those 
persons if the draft is to be based on reviews instead of 
endorsements.  The document discusses about society, the right to 
non-discrimination, the right to political participation, etc. and 
yet it did not gather any views from the other side of the 
equator.  IRTF or IETF documents, in general, do not discuss about 
human rights or political participation.

I am not opposed, outside a standards-setting context, to your 
views.  I did commend the two organizations for their efforts ( 
https://www.ietf.org/mail-archive/web/hrpc/current/msg00731.html 
).  Based on the discussions, I am left with a sense that the bar for 
research within this research group is quite low.

>I have already posted there, but thanks for the advice.

That is strange.  I went through the messages from that mailing list 
and I could not find your message.  I doubt that you will find 
reviewers if your message was not delivered by the mailing list.

>You got me confused now. What statement to which UN office?

It is the submission at 
https://www.article19.org/data/files/medialibrary/38604/Submission-to-UNSR---Telecos-and-access-sector-A19-2016.pdf 
I gather that the submission was to the UN Special Rapporteur on the 
protection of the right to freedom of opinion and expression ( 
http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/CallTelecommunications.aspx 
).

>This point was brought up by Stephane, Stephane could you help out?

I'll wait for Stephane to comment.

>Thiere talks about needing no permission from social norms,
>institutions, companies as well as governments to innovate. Not solely
>governments.

At my location, it is usually government/regulatory roadblocks.  This 
news article is about innovation in a country in Europe: 
https://www.ft.com/content/3d65be7a-2e22-11e6-bf8d-26294ad519fc  I 
don't think that it a protocol consideration.  Permissionless 
innovation does not fit within the end-to-end model which the draft 
uses as a boundary for it discussions about (IETF) protocol considerations.

>I think what we're doing here is not throw up a barrier, exactly the
>opposite, ensure that the model will not be hampered by external
>barriers (governments), because we have thought of a way to respect
>human rights ourselves. Else other parties might come in and do it for
>us, if we don't take our responsibility.

The external barriers are already there.  People who are not 
residents of that part of the world do not see it or ignore it as it 
is in their interest to do so.  Those barriers are not directly 
related to IETF standardization work.  The interactions related to 
human rights occur at the public policy level.  The model will be 
hampered if an IETF body crosses the line.

Regards,
S. Moonesamy 


From nobody Thu Jan 19 03:26:20 2017
Return-Path: 
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 C76DA12943A for ; Thu, 19 Jan 2017 03:26:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ijTBc7WesPut for ; Thu, 19 Jan 2017 03:26:16 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 18D53126BF7 for ; Thu, 19 Jan 2017 03:26:15 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cUAr4-0006TC-N8; Thu, 19 Jan 2017 12:26:12 +0100
To: S Moonesamy , hrpc@irtf.org
References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com>  <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>  <6.2.5.6.2.20170118211058.0b393d18@elandnews.com>
From: Niels ten Oever 
Message-ID: 
Date: Thu, 19 Jan 2017 12:25:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <6.2.5.6.2.20170118211058.0b393d18@elandnews.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="brS4vrcBFDpDMBPs4taogtfKlu0mpv7i9"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: fae0992e6f8dd0c1164808f182426692
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 11:26:20 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--brS4vrcBFDpDMBPs4taogtfKlu0mpv7i9
Content-Type: multipart/mixed; boundary="megk19PoJ0cDrapkRr1HoH9TlRwDkg8TR";
 protected-headers="v1"
From: Niels ten Oever 
To: S Moonesamy , hrpc@irtf.org
Cc: Corinne Cath 
Message-ID: 
Subject: Re: Comments about draft-irtf-hrpc-research-07
References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com>
 <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org>
 <6.2.5.6.2.20170105220522.0c4da628@elandnews.com>
 <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org>
 <6.2.5.6.2.20170106104124.102ab508@elandnews.com>
 
 <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>
 
 <6.2.5.6.2.20170118211058.0b393d18@elandnews.com>
In-Reply-To: <6.2.5.6.2.20170118211058.0b393d18@elandnews.com>

--megk19PoJ0cDrapkRr1HoH9TlRwDkg8TR
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Dear S Moonesamy,

Somehow the earlier responses got cut from the mail again, it would be
great if you could leave them intact.
On 01/19/2017 12:01 PM, S Moonesamy wrote:
> Hi Niels,
> At 15:46 18-01-2017, Niels ten Oever wrote:
>> Why?
>=20
> There are different perspectives to the discussions about "technical
> standards".  The one on which the draft is based is that "the mission"
> is about an entity (or entities) gaining an economic or political
> advantage.  It will be problematic for the IETF if that is its mission.=

>=20

Where do you read this in the draft?


>> Would you say the same about pervasive monitoring?
>=20
> That is an interesting question.  I might review a draft, e.g.
> https://www.ietf.org/mail-archive/web/ietf/current/msg96446.html  Is
> that anything in that review which is a political or public policy
> question?
>=20

That was not the question. The problem is that many technical choices
have an impact on real life events, we cannot deny or ignore that.

>> See the e-mail of Matthias Ketteman about this, as well as the report =
of
>> the UN Special Rapporteur on Freedom of Exporession I referred to
>> earlier.
>=20
> I read the substantive comments from Dr Ketteman and I found them
> informative.
>=20
>> [person name removed]
>=20
> There is a mailing list archive at
> https://www.ietf.org/mail-archive/web/hrpc/current/maillist.html  I
> could not find any review from that person.  A quick verification shows=

> that the person resides in The Netherlands.  According to an overview
> published by the European Union, the Netherlands is not a country
> located in South America (
> https://europa.eu/european-union/about-eu/countries/member-countries/ne=
therlands_en
> ).
>=20

I was not aware that nationality is based on where one resides. But if
that is the case the nationality of authors and contributors is actually
more more diverse.

>> I am happy to name more people (you've also seen several in the film),=

>> but it still actually a precondition to any document in the IRTF or IE=
TF
>> ? I think this is something we actually address; more diversity is
>> needed. But that should not bar us from doing work now, because that
>> would not solve the issue either.
>=20
> My preference is to be provided with URLs to reviews from those persons=

> if the draft is to be based on reviews instead of endorsements.  The
> document discusses about society, the right to non-discrimination, the
> right to political participation, etc. and yet it did not gather any
> views from the other side of the equator. =20
> IRTF or IETF documents, in
> general, do not discuss about human rights or political participation.
>=20

Firstly, one of the first co-authors of this draft was from Latin
America. There have been many contributions from people all over the
world, and I would not know why this topic would set a higher bar
document process.

> I am not opposed, outside a standards-setting context, to your views.  =
I
> did commend the two organizations for their efforts (
> https://www.ietf.org/mail-archive/web/hrpc/current/msg00731.html ).=20
> Based on the discussions, I am left with a sense that the bar for
> research within this research group is quite low.
>=20

If you come to this conclusion, it would be great to understand where
you base this on.

>> I have already posted there, but thanks for the advice.
>=20
> That is strange.  I went through the messages from that mailing list an=
d
> I could not find your message.  I doubt that you will find reviewers if=

> your message was not delivered by the mailing list.
>=20

I see my message bounced and the mailinglist is not open, could you
request my subscription?

>> You got me confused now. What statement to which UN office?
>=20
> It is the submission at
> https://www.article19.org/data/files/medialibrary/38604/Submission-to-U=
NSR---Telecos-and-access-sector-A19-2016.pdf
> I gather that the submission was to the UN Special Rapporteur on the
> protection of the right to freedom of opinion and expression (
> http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/CallTelecommunicati=
ons.aspx
> ).
>=20

So a independent organization submits something to a UN body, and you
think the IETF should have a say about that? How so?

>> This point was brought up by Stephane, Stephane could you help out?
>=20
> I'll wait for Stephane to comment.
>=20
>> Thiere talks about needing no permission from social norms,
>> institutions, companies as well as governments to innovate. Not solely=

>> governments.
>=20
> At my location, it is usually government/regulatory roadblocks.  This
> news article is about innovation in a country in Europe:
> https://www.ft.com/content/3d65be7a-2e22-11e6-bf8d-26294ad519fc  I don'=
t
> think that it a protocol consideration. =20

This is not the argument Thiere makes.

> Permissionless innovation does
> not fit within the end-to-end model which the draft uses as a boundary
> for it discussions about (IETF) protocol considerations.
>=20

Why not?

>> I think what we're doing here is not throw up a barrier, exactly the
>> opposite, ensure that the model will not be hampered by external
>> barriers (governments), because we have thought of a way to respect
>> human rights ourselves. Else other parties might come in and do it for=

>> us, if we don't take our responsibility.
>=20
> The external barriers are already there. =20

Which ones are you referring to?

> People who are not residents
> of that part of the world do not see it or ignore it as it is in their
> interest to do so.=20

If you provide examples we could discuss them or integrate them in the
draft.

> Those barriers are not directly related to IETF
> standardization work. =20

I cannot judge if I do not know which barriers you mean.

> The interactions related to human rights occur at
> the public policy level.  The model will be hampered if an IETF body
> crosses the line.

That is not the conclusion of what Dr. Ketteman or the UN Special
Rapporteur on Freedom of Expression said.

Best,

Niels

>=20
> Regards,
> S. Moonesamy


--megk19PoJ0cDrapkRr1HoH9TlRwDkg8TR--

--brS4vrcBFDpDMBPs4taogtfKlu0mpv7i9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliAolAACgkQDtg/OkaK
yLOk+xAAlWn2hjBqHrfd+JLBaWkXO2nhfDzkiA5wwesOSLdryxf5IPw8+7daxpfO
fu5iEYTpvNupBlwe8ipKOBtwilaoG1dHbBB5rosSZ2gvQoqh/2nFMBh3U87AJ6Nc
b1IGWjpCUX8GZqnJDn6zqRGydaWw7hd8S4hOS/yNHOEK6Uy9f+ANK6jGoZ38tyBM
9TZsCRmLBu+VWolqIm0tBzfBF8SGevehpSmJc2Dk6jGXb4dpYUff3OtjTZLR0Q6v
Z7dMZZzyayvxEblY9bvIKUdfLTawgrJn1RMKNRqjtvpbteit59xT4D9d2sDDzwmz
EIotjPqrBC35FGefNMOLjiaCRsbsHUQYv4b5IwUBhRgnn9BRbVVfPxW2e9YBubQV
0NSijFD3Kl4erq1Q9nraedzKqdLlyg767Y/o0hVp2EYhLkSuWfMgy4fMaDpG37AC
CNl/azGriUj85FtPF4wlKNK3hyUCHUdu2+AORrWYQQgEwu46GnmG/O/Mx23Jai4T
vOKHe8qvXURPiCjU3Sk6Pi1V+9sCbi8PlW1id419E/eMRozfs+O5qM6rv34z83Vr
uIFz+TVCu4R8cQkQLAQESI/c7m6AS77lPZn8H/Tkht9udA7c7UX95Jh3me4Xx/7K
5hC8it7+KRaHiyyziAnm+pEpvLv5UzaVZHCtLGHGv6PtSDQ223c=
=+yO/
-----END PGP SIGNATURE-----

--brS4vrcBFDpDMBPs4taogtfKlu0mpv7i9--


From nobody Thu Jan 19 06:55:33 2017
Return-Path: 
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 BE45D129602 for ; Thu, 19 Jan 2017 06:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YH29rh1YdYv5 for ; Thu, 19 Jan 2017 06:55:30 -0800 (PST)
Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 594161270B4 for ; Thu, 19 Jan 2017 06:55:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id F1F44115A3 for ; Thu, 19 Jan 2017 14:55:28 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rz3wcZxUD23 for ; Thu, 19 Jan 2017 14:55:28 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 4624011572 for ; Thu, 19 Jan 2017 14:55:28 +0000 (UTC)
Date: Thu, 19 Jan 2017 09:55:26 -0500
From: Andrew Sullivan 
To: hrpc@irtf.org
Message-ID: <20170119145526.GB1255@mx2.yitter.info>
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <20170118134432.GA15699@sources.org> <003ca204-b264-0150-7163-15a657acc312@cisco.com> <3cca1dea-221a-f7fa-0cf8-e95a4405cd17@article19.org> <82162d61-e102-e2b9-5b05-2136540d0b36@cisco.com> <20170118175708.GE664@mx2.yitter.info>  <20170119014007.GM664@mx2.yitter.info> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 14:55:32 -0000

Hi,

On Thu, Jan 19, 2017 at 10:31:54AM +0100, Marco Hogewoning wrote:

> work as research paper produced by IRTF. We might have to be careful
> on how people further away perceive this. Unfortunately I do not
> have any straight away answer on how to fix this. But for people who
> are less engaged with the inner workings of our forums and
> especially the difference and relationship between IRTF and IETF,
> this might still parse as “IETF work” as they are unable to
> distinguish the difference.

Yes.  Some of us (I am actually among them) think that it's been many
years since "the RFC series" was understood as having different
streams, and that we should stop publishing anything except IETF
consensus documents in it (which means no IAB stream, no IRTF stream,
and no independent submissions).  But that's not the rule that we're
living under today, alas, and we'll have to deal with the fallout.

For the alternative consequence of the above observations is basically
just that the RG shouldn't publish an RFC on this topic, period,
because it doesn't have IETF consensus and cannot.  I doubt the RG is
going to accept that conclusion.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Thu Jan 19 08:16:21 2017
Return-Path: 
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 CC58E1296A9 for ; Thu, 19 Jan 2017 08:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 r7nuGm0aGmaN for ; Thu, 19 Jan 2017 08:16:06 -0800 (PST)
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 75C11129681 for ; Thu, 19 Jan 2017 08:16:02 -0800 (PST)
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 1cUFNX-0000Sp-Pi; Thu, 19 Jan 2017 17:15:59 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id B41FCB00589; Thu, 19 Jan 2017 17:15:59 +0100 (CET)
To: Eliot Lear , "hrpc@irtf.org" 
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>
From: "Bless, Roland (TM)" 
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <21ed686a-c141-fe7a-f926-2356659ba364@kit.edu>
Date: Thu, 19 Jan 2017 17:15:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.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 1484842559.
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 16:16:19 -0000

Hi,

one more comment below.

Am 18.01.2017 um 14:22 schrieb Eliot Lear:
> Following up on Roland Bless' note, and as last call has closed, I wish
> to raise a concern about repeated discussion about the selection of
> rights that has been discussed in the draft.  The interplay between

This is actually not so difficult to solve.
I proposed to list the considered human rights and to provide a
rationale when HR impacts from technical properties/mechanisms are derived.
As a start one could use the same reasoning as in our paper [*]:
"The main source of the values of human rights is the International
Bill of Human Rights that is composed of the Universal Declaration of
Human Rights (UDHR) [33] along with the International Covenant on Civil
and Political Rights (ICCPR) [34] and the International Covenant on
Economic, Social and Cultural Rights (ICESCR) [35]. In the light of
several cases of Internet censorship, the Human Rights Council
Resolution 20/8 was adopted in 2012, affirming . . . that the same
rights that people have offline must also be protected online. . . 
[36]. In 2015, the Charter of Human Rights and Principles for the
Internet [17] was developed and released [18]. According to these
documents, some examples of human rights relevant for ICT systems are
human dignity (Art. 1 UDHR),
non-discrimination (Art. 2),
rights to life,
liberty and security (Art. 3),
freedom of opinion and expression (Art. 19),
freedom of assembly and association (Art. 20),
rights to equal protection, legal remedy, fair trial, due process,
presumed innocent (Art. 711),
appropriate social and international order (Art. 28),
participation in public affairs (Art. 21),
participation in cultural life,
protection of intellectual property (Art. 27), and
privacy (Art. 12)."

[*] http://dl.acm.org/citation.cfm?doid=2935634.2935640 can be freely
accessed via http://conferences.sigcomm.org/sigcomm/2016/program.php
(last paper).

Regards,
 Roland


From nobody Thu Jan 19 08:51:19 2017
Return-Path: 
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 712BD12948F for ; Thu, 19 Jan 2017 08:51:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 O96tK7ldXHMO for ; Thu, 19 Jan 2017 08:51:16 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 7DAAB1294B5 for ; Thu, 19 Jan 2017 08:51:14 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cUFvc-0001dB-Jg; Thu, 19 Jan 2017 17:51:13 +0100
To: "Bless, Roland (TM)" , hrpc@irtf.org
References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu> <1bc65daf-42ec-4836-61d4-a5fa0ece0062@article19.org> <027298fb-c427-7a17-e41a-13c93b5b7063@kit.edu>
From: Niels ten Oever 
Message-ID: 
Date: Thu, 19 Jan 2017 17:51:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <027298fb-c427-7a17-e41a-13c93b5b7063@kit.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tMG9hjCgAx9aVT4fflbJ8Dc44g6nhHAcP"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 326ae57122e7e55f093438bd1fe32346
Archived-At: 
Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 16:51:18 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tMG9hjCgAx9aVT4fflbJ8Dc44g6nhHAcP
Content-Type: multipart/mixed; boundary="KtHOBGMOV30QCfW37iiuWsGKtoP1i7cMH";
 protected-headers="v1"
From: Niels ten Oever 
To: "Bless, Roland (TM)" , hrpc@irtf.org
Message-ID: 
Subject: Re: [hrpc] Human Rights Research Group Call on
 draft-irtf-hrpc-research-07
References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org>
 <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu>
 <1bc65daf-42ec-4836-61d4-a5fa0ece0062@article19.org>
 <027298fb-c427-7a17-e41a-13c93b5b7063@kit.edu>
In-Reply-To: <027298fb-c427-7a17-e41a-13c93b5b7063@kit.edu>

--KtHOBGMOV30QCfW37iiuWsGKtoP1i7cMH
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Roland,

Reply inline:
On 01/19/2017 10:10 AM, Bless, Roland (TM) wrote:
> Hi Niels,
>=20
> sorry for the late reply, please see comments inline.
>=20
> Am 10.01.2017 um 11:22 schrieb Niels ten Oever:
>> On 01/10/2017 01:35 AM, Roland Bless wrote:
>>> Hi Avri and all,
>>>
>>> On 04.12.2016 at 20:54 avri doria wrote:
>>>> Please send all comment to the HRPC email list: hrpc@irtf.org.  I do=

>>>> hope that some good discussions occur on this list where the
>>>> resolution to any issues may be forged. Discussion has been shown to=

>>>> improve this draft.
>>>
>>> Unfortunately, I didn't manage the full review write-up after returni=
ng
>>> from holidays today. Nevertheless, I have some general comments and t=
ry
>>> to provide more detailed comments later today.
>>>
>>> Overall, I think the draft is good to raise awareness for
>>> the issue that sometimes technical decisions may impact human rights.=

>>> However, it falls a bit short on the problem that even human rights
>>> get in conflict with each other and that conflict resolution is
>>> hard to decide on,
>>
>> This section aims to address that:
>>
>>    Human rights can be in conflict with each other, such as the right =
to
>>    freedom of expression and the right to privacy.  In such as case th=
e
>>    different affected rights need to be balanced.  In order to do this=

>>    it is crucial that the rights impacts are clearly documented in ord=
er
>>    to mitigate the potential harm in a proportional way.  Making that
>>    process tangible and practical for protocol developers is what this=

>>    research aims to ultimately contribute to.  Technology can never be=

>>    fully equated with a human right.  Whereas a specific technology
>>    might be strong enabler of a specific human right, it might have an=

>>    adverse impact on another human right.  In this case decisions on
>>    design and deployment need to take this into account.
>>
>> You think this is inadequeate? If so, would you have text suggestions?=

>=20
> No, that paragraph is really fine (except for that "proportional way"),=


removed 'proportional way'

> my point was that the rest of the document has more a tone of "translat=
e
> this human right to a technical concept and make sure that
> this concept is used in order to enable the human right." and seems
> to suggest enforcing or enabling human rights by building certain
> mechanisms into protocols. This is different from trying to achieve
> awareness for impacts on human rights. So maybe it is easy to fix by
> rephrasing certain passages in the text, e.g.,
> "List technical terms that combined create enabling environment
> for human rights"

This we already changed into:

#### List technical terms that when partially combined can create an
enabling environment for human rights


, "Translating human rights to technical terms",

Would this work:

### Relating human rights to technical concepts

> "on whether the protocol adequately protects against specific human
> rights threats." (maybe the protocol doesn't need a built-in
> protection, but operational aspects need to be regulated, e.g.,
> namespace assignment etc.).

Would this work:

However, by carefully considering the answers to the following
questions, document authors should be able to produce a comprehensive
analysis that can serve as the basis for discussion on whether the
protocol adequately takes specific human rights threats into account

>=20
>>  or is maybe not possible or desirable to built
>>> into a technical system (because it's too rigid then).
>>
>> This sections aims to address this:
>>
>> ur position is that hard-coding human rights into
>>    protocols is complicated and changes with the context.  At this poi=
nt
>>    is difficult to say whether hard-coding human rights into protocols=

>>    is wise or feasible.  It is however important to make conscious and=

>>    explicit design decisions that take into account the human rights
>>    protocol considerations guidelines developed above.  This will ensu=
re
>>    that the impact protocols can have on human rights is clear and
>>    explicit, both for developers and for users.  In addition, it ensur=
es
>>    that the impact of specific protocol on human rights is carefully
>>    considered and that concrete design decisions are documented in the=

>>    protocol.
>>
>> You think this is inadequeate? If so, would you have text suggestions?=

>=20
> That is basically fine, but as pointed out above the rest of the draft
> reads more like suggesting to built-in HR enabling mechanisms or at
> least to support those.
>=20
> It think that this statement here:
>>    This will ensure
>>    that the impact protocols can have on human rights is clear and
>>    explicit, both for developers and for users.
>=20
> is a little bit too strong. Even if one has read the document the impac=
t
> isn't always _clear_ and explicit. So IMHO the aim is to show that ther=
e
> _is_ an impact that one should consider, however, in some cases it may
> remain quite unclear how strong the impact is etc.
>=20

Would this work:

This will contribute to the understanding of the impact protocols can
have on human rights, both for developers and for users.

>> Do you think this is a sufficient representation of your positions?
>>
>>    Bless and Orwat [Bless] represent a fourth position.  They argue th=
at
>>    it is too early to make any definitive claims, but that there is a
>>    need for more careful analysis of the impact of protocol design
>>    choices on human rights.  They also argue that it is important to
>>    search for solutions that 'create awareness in the technical
>>    community about impact of design choices on social values.  And wor=
k
>>    towards a methodology for co-design of technical and institutional
>>    systems.'
>>
>> I'd me more than happy to have a bit more elaborate description.
>=20
> I'll check with Carsten and propose a text.
>=20

Thanks!

All changes can also be found here:

https://github.com/nllz/IRTF-HRPC/commit/0b35d70468b202a83bd0d2b22f17b85b=
df7b859c

Cheers,

Niels

> Regards,
>  Roland
>=20


--KtHOBGMOV30QCfW37iiuWsGKtoP1i7cMH--

--tMG9hjCgAx9aVT4fflbJ8Dc44g6nhHAcP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliA7nwACgkQDtg/OkaK
yLM9Ng//TgbkqZFIpTERD2qqSFFmquwNbCBhAR2ektSO1NSTNuKeXx8CTEaav3XC
VW6TzOEB7ts1IXu6eXsHXvxfq1AaFyJuCNKpSkKpkYNSqEwfg1DI9HkQPYL8pvbg
tUVP2ds73FmEypZsI4ZF0gkwrF77T942dSn7HiCnmlaijIaQ0kHN5hi708iIhy01
RMLOb8ihceXBrOK4XK//DNWJrYQNDXYj9RbsRmV7iPZiZ5CkdMiFmWCplU29QXgE
wj5FkJiGhyebvG6cSUVBWlgef6hNsdAuRg/u8LdOHJ3BYjoQLXKDnLZULgX65yG0
xJLegTbiBt0Uiks8dxwthZhqMX7yXwmCLzM7P1We2eIbQwZ+E517W7PISTMgokIG
z8qDPE+OfyNSYsOBi1uI1LnWkGRp2myE+c+BnvtbBMigrtDiV2xdrMYUJ5RGzb1s
e3ePjYB2ugwR/EZECRQrh+phB2iRDlm4y9ABGlTlxVzNlM+BFTlgAMUoSedbwb95
rftzHhaAl+kzOv58UKZGyDs0ojcV+m92HHWJhjPyes2MMNWRJ0J1aLTqmplfoUmv
VbQzUTuQsiB439PhCnFmtFWFlbqNbtll6fN+HvRMBPGFw7BQJK5YwO7TrsTw6F4C
lpFgoYqmZiRaqjd/UgRcdVzDo0rbki8fK+hWwI6dGtRsx9N/ykc=
=CtXs
-----END PGP SIGNATURE-----

--tMG9hjCgAx9aVT4fflbJ8Dc44g6nhHAcP--


From nobody Thu Jan 19 11:20:29 2017
Return-Path: 
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 A268B12943B for ; Thu, 19 Jan 2017 11:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level: 
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=glgJtlPr; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=aZwL7gFv
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 wAz0WarMuafm for ; Thu, 19 Jan 2017 11:20:26 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23521129407 for ; Thu, 19 Jan 2017 11:20:26 -0800 (PST)
Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0JJK7UP009751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2017 11:20:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484853615; x=1484940015; bh=BIaQOYefIEDZqu4ZDU6yNEwm2kUo3cvkU5IfVs1uzp8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=glgJtlPr7H99YT/uhcSkXJw9c3VhU8TTlJD0vMPASWe1y5i65if9wwj0ov/LtNnRH dwG3aUMfBBwR7GY5MY75b5u34Oma0FKzO77L/90EYu+0nh5heS9323ynIqgs1bCKsn je6eK5XfvlfePDDGnV+QOMuBu3j4l9WFrqDkyQvw=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484853615; x=1484940015; i=@elandsys.com; bh=BIaQOYefIEDZqu4ZDU6yNEwm2kUo3cvkU5IfVs1uzp8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aZwL7gFvLRCpXPfm9+LufcbyLv+vUKB/dBUnUULgx5UR+OspDRrCF2iyovhO/NqM4 qgv268s7u3/dc1f8bLZt8hZDcx8olueLJ/o94U9efXCHuPTa260DGUdxwKQmBi4Yq4 /lKEez7LfuX+rBNZnaJDShhndxtKBdrL1QHB2ORo=
Message-Id: <6.2.5.6.2.20170119075405.0b642d50@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 19 Jan 2017 11:11:39 -0800
To: Niels ten Oever , hrpc@irtf.org
From: S Moonesamy 
In-Reply-To: 
References: <6.2.5.6.2.20161224235445.0b10dab0@elandnews.com> <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com>  <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>  <6.2.5.6.2.20170118211058.0b393d18@elandnews.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 19:20:27 -0000

Hi Niels,
At 03:25 19-01-2017, Niels ten Oever wrote:
>Where do you read this in the draft?

The draft starts with a quotation from RFC 3935.  There is a message 
at https://www.ietf.org/mail-archive/web/hrpc/current/msg00794.html 
about "technology performs more than a merely 'technical function'" 
and some discussion over different threads about the link with the IETF.

>That was not the question. The problem is that many technical choices
>have an impact on real life events, we cannot deny or ignore that.

I was asked a question about pervasive surveillance and I provided a 
URL to a review which anyone reading the mailing list can assess for 
himself/herself.  The argument in the above (see quoted paragraph) is 
that "many technical choices have an impact on real life 
events".  The argument is not accompanied by actual cases which are 
directly related to IETF protocols or standards-setting.

>I was not aware that nationality is based on where one resides. But if
>that is the case the nationality of authors and contributors is actually
>more more diverse.

It is not about nationality.  In order to know how a person in 
Country X is affected by a decision it is better to ask a person in 
that country as he or she is directly impacted by the laws of that 
country.  I could ask, for example, a person in Europe who is from 
another country (nationality).  Would I get a good view of what is 
actually happening from that input?

To put it differently, would a person living in The Netherlands be 
impacted if HTTP is blocked in, for example, New Zealand?  Would the 
human rights of that person be infringed by that decision?

>Firstly, one of the first co-authors of this draft was from Latin
>America. There have been many contributions from people all over the
>world, and I would not know why this topic would set a higher bar
>document process.

Human rights can be based on academic literature or it can be a 
matter which a person in a far away country with internet access can 
relate to.  As for the higher bar, I did not argue for the draft to 
be a consensus document. If it is claimed that there are people from 
all over the world reviewing this document, that information should 
be verifiable if this draft is research work.  It might help Afnic in 
its efforts (e.g. 
https://www.afnic.fr/en/about-afnic/news/general-news/9961/show/afnic-reveals-figures-on-diversity-within-icann-1.html 
).

>If you come to this conclusion, it would be great to understand where
>you base this on.

As an example, I asked about UTF8 and I have yet to receive an 
adequate answer.  If the research group had already done a 
significant amount of technical research it should not be too 
difficult to point me to the answer.

>I see my message bounced and the mailinglist is not open, could you
>request my subscription?

I sent an (off-list) email about your subscription and copied it to you.

>So a independent organization submits something to a UN body, and you
>think the IETF should have a say about that? How so?

My answer to the first question is "no".  The independent 
organization has its name on draft-irtf-hrpc-research and one of RG 
Chairs is affiliated with the independent organization.  I asked 
whether the RG Chairs asked the relevant IETF body about that.  The 
independent organization described the IETF as a sibling.  It does 
not look good when siblings cannot talk to each other.

>Why not?

There is a draft written by the IAB in which it is mentioned that 
"The deployment of ECN across the Interent had failed."  It is nearly 
impossible to innovate at that layer and get deployment across the 
Internet.  Most of the services in wide use on the Internet are built 
above what the IETF calls the "application layer".  It could be said 
that the web is the transport layer.

On a tangent, if services in wide use were permissionless, the 
following should not be an issue: 
https://www.ft.com/content/75796bce-d9dd-11e6-944b-e7eb37a6aa8e

>Which ones are you referring to?

I was referring to regulatory barriers.  I have asked my regulator 
about that; I don't consider the regulation(s) as related to the IETF 
in any way.

>If you provide examples we could discuss them or integrate them in the
>draft.

If I am not mistaken, the draft is not about regulatory barriers.  As 
such, the examples which I might provide won't fit in it.

Regards,
S. Moonesamy  


From nobody Thu Jan 19 11:46:12 2017
Return-Path: 
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 DACE51294C0 for ; Thu, 19 Jan 2017 11:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zxkydi7xrqYc for ; Thu, 19 Jan 2017 11:46:09 -0800 (PST)
Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2EA12943B for ; Thu, 19 Jan 2017 11:46:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 013D2115A6 for ; Thu, 19 Jan 2017 19:46:09 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPurqXDZdoBR for ; Thu, 19 Jan 2017 19:46:03 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 31B8610A0C for ; Thu, 19 Jan 2017 19:46:03 +0000 (UTC)
Date: Thu, 19 Jan 2017 14:46:01 -0500
From: Andrew Sullivan 
To: hrpc@irtf.org
Message-ID: <20170119194601.GC1699@mx2.yitter.info>
References: <655c1b7f-b06e-1a04-ea83-51b4b98924c2@article19.org> <6.2.5.6.2.20170105220522.0c4da628@elandnews.com> <5a24f4bd-7900-bdc6-8f6e-fb30379f6076@article19.org> <6.2.5.6.2.20170106104124.102ab508@elandnews.com>  <6.2.5.6.2.20170117145713.0dd6fd88@elandnews.com>  <6.2.5.6.2.20170118211058.0b393d18@elandnews.com>  <6.2.5.6.2.20170119075405.0b642d50@elandnews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6.2.5.6.2.20170119075405.0b642d50@elandnews.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 19:46:11 -0000

Hi,

On Thu, Jan 19, 2017 at 11:11:39AM -0800, S Moonesamy wrote:
 
> It is not about nationality.  In order to know how a person in Country X is
> affected by a decision it is better to ask a person in that country as he or
> she is directly impacted by the laws of that country.  I could ask, for
> example, a person in Europe who is from another country (nationality).
> Would I get a good view of what is actually happening from that input?
> 
> To put it differently, would a person living in The Netherlands be impacted
> if HTTP is blocked in, for example, New Zealand?  Would the human rights of
> that person be infringed by that decision?

I have two problems with this claim, and since this discussion about
consulting everyone appears to be continuing I think I want to object
to the apparent line of reasoning.

The first problem I have is that it simply isn't true that it is
always better to ask someone from Country X about the situation in
Country X than it is to ask some expert about the relevant situation.
People are often extraordinarily confused about how their own country
works.  Many Canadians, for instance, persist in believing that they
vote for the Prime Minister, but I could ask anyone properly familiar
with Westminster systems and each would answer the question correctly.

The second problem I have is that the second ¶ contains two questions,
one of which appears to be a question about how people feel and the
other of which is one of simple entailment given the definitions of
"human rights" and "infringed".  Neither of them, anyway, is relevant
to what is in the previous ¶, except of course that _ex hypothesi_ we
have to ask the person in the Netherlands about the effect on him or
her.  

I think there is a legitimate question about the population of
reviewers for this document (given that it's in the IRTF, that's
hardly surprising).  I think the representativity of nationals of the
countries of the world is not that legitimate question.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Thu Jan 19 12:24:34 2017
Return-Path: 
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 5D2F812954B for ; Thu, 19 Jan 2017 12:24:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 gyH2tJwvbs3Y for ; Thu, 19 Jan 2017 12:24:31 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 0C135129539 for ; Thu, 19 Jan 2017 12:24:30 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cUJFw-0006jr-MZ; Thu, 19 Jan 2017 21:24:26 +0100
Date: Thu, 19 Jan 2017 21:24:19 +0100
From: Niels ten Oever 
To: S Moonesamy 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Message-Id: <20170119202424.0E9C6BCE37@mail.article19.org>
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 01ccc3eb840dc35651f50b798cb06ae8
Archived-At: 
Cc: Corinne Cath , hrpc@irtf.org
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 20:24:33 -0000

RGVhciBTIE1vb25lc2FteSwKCkkgYW0gc29ycnkgYnV0IEkgZmluZCBpdCBpbXBvc3NpYmxlIHRv
IGhhdmUgYW4gdW50aHJlYWRlZCBkaXNjdXNzaW9uIGluIHRoaXMgd2F5LiBDb3VsZCB5b3UgcGxl
YXNlIGtlZXAgdGhlIGRpc2N1c3Npb24gaW5saW5lIGluIHlvdXIgcmVzcG9uc2VzPyBUaGFua3Mg
aW4gYWR2YW5jZS4KClJlcGx5IGlubGluZToKCk9uIEphbiAxOSwgMjAxNyA4OjExIFBNLCBTIE1v
b25lc2FteSA8c20raWV0ZkBlbGFuZHN5cy5jb20+IHdyb3RlOgo+Cj4gSGkgTmllbHMsIAo+IEF0
IDAzOjI1IDE5LTAxLTIwMTcsIE5pZWxzIHRlbiBPZXZlciB3cm90ZTogCj4gPldoZXJlIGRvIHlv
dSByZWFkIHRoaXMgaW4gdGhlIGRyYWZ0PyAKPgo+IFRoZSBkcmFmdCBzdGFydHMgd2l0aCBhIHF1
b3RhdGlvbiBmcm9tIFJGQyAzOTM1LsKgIFRoZXJlIGlzIGEgbWVzc2FnZSAKPiBhdCBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2hycGMvY3VycmVudC9tc2cwMDc5NC5odG1s
IAo+IGFib3V0ICJ0ZWNobm9sb2d5IHBlcmZvcm1zIG1vcmUgdGhhbiBhIG1lcmVseSAndGVjaG5p
Y2FsIGZ1bmN0aW9uJyIgCj4gYW5kIHNvbWUgZGlzY3Vzc2lvbiBvdmVyIGRpZmZlcmVudCB0aHJl
YWRzIGFib3V0IHRoZSBsaW5rIHdpdGggdGhlIElFVEYuIAo+Cj4gPlRoYXQgd2FzIG5vdCB0aGUg
cXVlc3Rpb24uIFRoZSBwcm9ibGVtIGlzIHRoYXQgbWFueSB0ZWNobmljYWwgY2hvaWNlcyAKPiA+
aGF2ZSBhbiBpbXBhY3Qgb24gcmVhbCBsaWZlIGV2ZW50cywgd2UgY2Fubm90IGRlbnkgb3IgaWdu
b3JlIHRoYXQuIAo+Cj4gSSB3YXMgYXNrZWQgYSBxdWVzdGlvbiBhYm91dCBwZXJ2YXNpdmUgc3Vy
dmVpbGxhbmNlIGFuZCBJIHByb3ZpZGVkIGEgCj4gVVJMIHRvIGEgcmV2aWV3IHdoaWNoIGFueW9u
ZSByZWFkaW5nIHRoZSBtYWlsaW5nIGxpc3QgY2FuIGFzc2VzcyBmb3IgCj4gaGltc2VsZi9oZXJz
ZWxmLsKgIFRoZSBhcmd1bWVudCBpbiB0aGUgYWJvdmUgKHNlZSBxdW90ZWQgcGFyYWdyYXBoKSBp
cyAKPiB0aGF0ICJtYW55IHRlY2huaWNhbCBjaG9pY2VzIGhhdmUgYW4gaW1wYWN0IG9uIHJlYWwg
bGlmZSAKPiBldmVudHMiLsKgIFRoZSBhcmd1bWVudCBpcyBub3QgYWNjb21wYW5pZWQgYnkgYWN0
dWFsIGNhc2VzIHdoaWNoIGFyZSAKPiBkaXJlY3RseSByZWxhdGVkIHRvIElFVEYgcHJvdG9jb2xz
IG9yIHN0YW5kYXJkcy1zZXR0aW5nLiAKPgoKU28geW91J3JlIHNheWluZyB0aGF0IHByb3RvY29s
cyBoYXZlIG5vIGltcGFjdCBvbiBzb2NpZXR5PyBUaGVuIHBsZWFzZSByZXZpZXcgdGhlIGNhc2Vz
IGluIHRoZSBkcmFmdC4KCj4gPkkgd2FzIG5vdCBhd2FyZSB0aGF0IG5hdGlvbmFsaXR5IGlzIGJh
c2VkIG9uIHdoZXJlIG9uZSByZXNpZGVzLiBCdXQgaWYgCj4gPnRoYXQgaXMgdGhlIGNhc2UgdGhl
IG5hdGlvbmFsaXR5IG9mIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyBpcyBhY3R1YWxseSAKPiA+
bW9yZSBtb3JlIGRpdmVyc2UuIAo+Cj4gSXQgaXMgbm90IGFib3V0IG5hdGlvbmFsaXR5LsKgIElu
IG9yZGVyIHRvIGtub3cgaG93IGEgcGVyc29uIGluIAo+IENvdW50cnkgWCBpcyBhZmZlY3RlZCBi
eSBhIGRlY2lzaW9uIGl0IGlzIGJldHRlciB0byBhc2sgYSBwZXJzb24gaW4gCj4gdGhhdCBjb3Vu
dHJ5IGFzIGhlIG9yIHNoZSBpcyBkaXJlY3RseSBpbXBhY3RlZCBieSB0aGUgbGF3cyBvZiB0aGF0
IAo+IGNvdW50cnkuwqAgSSBjb3VsZCBhc2ssIGZvciBleGFtcGxlLCBhIHBlcnNvbiBpbiBFdXJv
cGUgd2hvIGlzIGZyb20gCj4gYW5vdGhlciBjb3VudHJ5IChuYXRpb25hbGl0eSkuwqAgV291bGQg
SSBnZXQgYSBnb29kIHZpZXcgb2Ygd2hhdCBpcyAKPiBhY3R1YWxseSBoYXBwZW5pbmcgZnJvbSB0
aGF0IGlucHV0PyAKPgo+IFRvIHB1dCBpdCBkaWZmZXJlbnRseSwgd291bGQgYSBwZXJzb24gbGl2
aW5nIGluIFRoZSBOZXRoZXJsYW5kcyBiZSAKPiBpbXBhY3RlZCBpZiBIVFRQIGlzIGJsb2NrZWQg
aW4sIGZvciBleGFtcGxlLCBOZXcgWmVhbGFuZD/CoCBXb3VsZCB0aGUgCj4gaHVtYW4gcmlnaHRz
IG9mIHRoYXQgcGVyc29uIGJlIGluZnJpbmdlZCBieSB0aGF0IGRlY2lzaW9uPyAKPgoKU28gaXQn
cyBub3QgYWJvdXQgbmF0aW9uYWxpdHkgb2YgYXV0aG9ycyBidXQgY291bnRyeSBvZiByZXNpZGVu
Y2U/IEFtIGNvbmZ1c2VkIG5vdy4KCkFsc28gd2UncmUgbm90IGNsYWltaW5nIHRvIHJlcHJlc2Vu
dCB0aGUgd29ybGQsIGJ1dCBtZXJlbHkgdGhpcyByZXNlYXJjaCBncm91cC4gU28gSSB0aGluayB3
ZSBjYW4gY2xvc2UgdGhlIGRpc2N1c3Npb24gYWJvdXQgdGhpcy4gCgpJIGFtIGhvd2V2ZXIgbW9y
ZSB0aGFuIGhhcHB5IHRvIHdvcmsgdG9nZXRoZXIgd2l0aCB5b3Ugb24gb3V0cmVhY2ggYW5kIGRp
dmVyc2l0eS4KCj4gPkZpcnN0bHksIG9uZSBvZiB0aGUgZmlyc3QgY28tYXV0aG9ycyBvZiB0aGlz
IGRyYWZ0IHdhcyBmcm9tIExhdGluIAo+ID5BbWVyaWNhLiBUaGVyZSBoYXZlIGJlZW4gbWFueSBj
b250cmlidXRpb25zIGZyb20gcGVvcGxlIGFsbCBvdmVyIHRoZSAKPiA+d29ybGQsIGFuZCBJIHdv
dWxkIG5vdCBrbm93IHdoeSB0aGlzIHRvcGljIHdvdWxkIHNldCBhIGhpZ2hlciBiYXIgCj4gPmRv
Y3VtZW50IHByb2Nlc3MuIAo+Cj4gSHVtYW4gcmlnaHRzIGNhbiBiZSBiYXNlZCBvbiBhY2FkZW1p
YyBsaXRlcmF0dXJlIG9yIGl0IGNhbiBiZSBhIAo+IG1hdHRlciB3aGljaCBhIHBlcnNvbiBpbiBh
IGZhciBhd2F5IGNvdW50cnkgd2l0aCBpbnRlcm5ldCBhY2Nlc3MgY2FuIAo+IHJlbGF0ZSB0by7C
oCBBcyBmb3IgdGhlIGhpZ2hlciBiYXIsIEkgZGlkIG5vdCBhcmd1ZSBmb3IgdGhlIGRyYWZ0IHRv
IAo+IGJlIGEgY29uc2Vuc3VzIGRvY3VtZW50LiBJZiBpdCBpcyBjbGFpbWVkIHRoYXQgdGhlcmUg
YXJlIHBlb3BsZSBmcm9tIAo+IGFsbCBvdmVyIHRoZSB3b3JsZCByZXZpZXdpbmcgdGhpcyBkb2N1
bWVudCwgdGhhdCBpbmZvcm1hdGlvbiBzaG91bGQgCj4gYmUgdmVyaWZpYWJsZSBpZiB0aGlzIGRy
YWZ0IGlzIHJlc2VhcmNoIHdvcmsuwqAgSXQgbWlnaHQgaGVscCBBZm5pYyBpbiAKPiBpdHMgZWZm
b3J0cyAoZS5nLiAKPiBodHRwczovL3d3dy5hZm5pYy5mci9lbi9hYm91dC1hZm5pYy9uZXdzL2dl
bmVyYWwtbmV3cy85OTYxL3Nob3cvYWZuaWMtcmV2ZWFscy1maWd1cmVzLW9uLWRpdmVyc2l0eS13
aXRoaW4taWNhbm4tMS5odG1sIAo+ICkuIAo+CgpTZWUgYWJvdmUuCgoKPiA+SWYgeW91IGNvbWUg
dG8gdGhpcyBjb25jbHVzaW9uLCBpdCB3b3VsZCBiZSBncmVhdCB0byB1bmRlcnN0YW5kIHdoZXJl
IAo+ID55b3UgYmFzZSB0aGlzIG9uLiAKPgo+IEFzIGFuIGV4YW1wbGUsIEkgYXNrZWQgYWJvdXQg
VVRGOCBhbmQgSSBoYXZlIHlldCB0byByZWNlaXZlIGFuIAo+IGFkZXF1YXRlIGFuc3dlci7CoCBJ
ZiB0aGUgcmVzZWFyY2ggZ3JvdXAgaGFkIGFscmVhZHkgZG9uZSBhIAo+IHNpZ25pZmljYW50IGFt
b3VudCBvZiB0ZWNobmljYWwgcmVzZWFyY2ggaXQgc2hvdWxkIG5vdCBiZSB0b28gCj4gZGlmZmlj
dWx0IHRvIHBvaW50IG1lIHRvIHRoZSBhbnN3ZXIuIAo+CgpMZXQncyBnaXZlIG91ciBmZWxsb3cg
cmVzZWFyY2ggZ3JvdXAgcGFydGljaXBhbnRzIHNvbWUgdGltZSB0byByZXNwb25kLiBFbHNlIHdl
IGNhbiBkcm9wIHRoZSBzZW50ZW5jZSBhYm91dCB0YWdnaW5nLiAKCkkgdGhpbmsgdGhhdCBoYXZp
bmcgdGhlIGRpc2N1c3Npb24gdW50aHJlYWRlZCBpcyBub3QgaGVscGluZyBmb3IgcmVhZGFiaWxp
dHkuIAoKPiA+SSBzZWUgbXkgbWVzc2FnZSBib3VuY2VkIGFuZCB0aGUgbWFpbGluZ2xpc3QgaXMg
bm90IG9wZW4sIGNvdWxkIHlvdSAKPiA+cmVxdWVzdCBteSBzdWJzY3JpcHRpb24/IAo+Cj4gSSBz
ZW50IGFuIChvZmYtbGlzdCkgZW1haWwgYWJvdXQgeW91ciBzdWJzY3JpcHRpb24gYW5kIGNvcGll
ZCBpdCB0byB5b3UuIAo+CgpUaGFua3MsIEkgcmVzcG9uZGVkLgoKPiA+U28gYSBpbmRlcGVuZGVu
dCBvcmdhbml6YXRpb24gc3VibWl0cyBzb21ldGhpbmcgdG8gYSBVTiBib2R5LCBhbmQgeW91IAo+
ID50aGluayB0aGUgSUVURiBzaG91bGQgaGF2ZSBhIHNheSBhYm91dCB0aGF0PyBIb3cgc28/IAo+
Cj4gTXkgYW5zd2VyIHRvIHRoZSBmaXJzdCBxdWVzdGlvbiBpcyAibm8iLsKgIFRoZSBpbmRlcGVu
ZGVudCAKPiBvcmdhbml6YXRpb24gaGFzIGl0cyBuYW1lIG9uIGRyYWZ0LWlydGYtaHJwYy1yZXNl
YXJjaCBhbmQgb25lIG9mIFJHIAo+IENoYWlycyBpcyBhZmZpbGlhdGVkIHdpdGggdGhlIGluZGVw
ZW5kZW50IG9yZ2FuaXphdGlvbi7CoCBJIGFza2VkIAo+IHdoZXRoZXIgdGhlIFJHIENoYWlycyBh
c2tlZCB0aGUgcmVsZXZhbnQgSUVURiBib2R5IGFib3V0IHRoYXQuwqAgVGhlIAo+IGluZGVwZW5k
ZW50IG9yZ2FuaXphdGlvbiBkZXNjcmliZWQgdGhlIElFVEYgYXMgYSBzaWJsaW5nLsKgIEl0IGRv
ZXMgCj4gbm90IGxvb2sgZ29vZCB3aGVuIHNpYmxpbmdzIGNhbm5vdCB0YWxrIHRvIGVhY2ggb3Ro
ZXIuIAo+CgpJIGRvIG5vdCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuIAoKPiA+V2h5IG5vdD8gCj4K
PiBUaGVyZSBpcyBhIGRyYWZ0IHdyaXR0ZW4gYnkgdGhlIElBQiBpbiB3aGljaCBpdCBpcyBtZW50
aW9uZWQgdGhhdCAKPiAiVGhlIGRlcGxveW1lbnQgb2YgRUNOIGFjcm9zcyB0aGUgSW50ZXJlbnQg
aGFkIGZhaWxlZC4iwqAgSXQgaXMgbmVhcmx5IAo+IGltcG9zc2libGUgdG8gaW5ub3ZhdGUgYXQg
dGhhdCBsYXllciBhbmQgZ2V0IGRlcGxveW1lbnQgYWNyb3NzIHRoZSAKPiBJbnRlcm5ldC7CoCBN
b3N0IG9mIHRoZSBzZXJ2aWNlcyBpbiB3aWRlIHVzZSBvbiB0aGUgSW50ZXJuZXQgYXJlIGJ1aWx0
IAo+IGFib3ZlIHdoYXQgdGhlIElFVEYgY2FsbHMgdGhlICJhcHBsaWNhdGlvbiBsYXllciIuwqAg
SXQgY291bGQgYmUgc2FpZCAKPiB0aGF0IHRoZSB3ZWIgaXMgdGhlIHRyYW5zcG9ydCBsYXllci4g
Cj4KPiBPbiBhIHRhbmdlbnQsIGlmIHNlcnZpY2VzIGluIHdpZGUgdXNlIHdlcmUgcGVybWlzc2lv
bmxlc3MsIHRoZSAKPiBmb2xsb3dpbmcgc2hvdWxkIG5vdCBiZSBhbiBpc3N1ZTogCj4gaHR0cHM6
Ly93d3cuZnQuY29tL2NvbnRlbnQvNzU3OTZiY2UtZDlkZC0xMWU2LTk0NGItZTdlYjM3YTZhYThl
IAo+Cj4gPldoaWNoIG9uZXMgYXJlIHlvdSByZWZlcnJpbmcgdG8/IAo+Cj4gSSB3YXMgcmVmZXJy
aW5nIHRvIHJlZ3VsYXRvcnkgYmFycmllcnMuwqAgSSBoYXZlIGFza2VkIG15IHJlZ3VsYXRvciAK
PiBhYm91dCB0aGF0OyBJIGRvbid0IGNvbnNpZGVyIHRoZSByZWd1bGF0aW9uKHMpIGFzIHJlbGF0
ZWQgdG8gdGhlIElFVEYgCj4gaW4gYW55IHdheS4gCj4KPiA+SWYgeW91IHByb3ZpZGUgZXhhbXBs
ZXMgd2UgY291bGQgZGlzY3VzcyB0aGVtIG9yIGludGVncmF0ZSB0aGVtIGluIHRoZSAKPiA+ZHJh
ZnQuIAo+Cj4gSWYgSSBhbSBub3QgbWlzdGFrZW4sIHRoZSBkcmFmdCBpcyBub3QgYWJvdXQgcmVn
dWxhdG9yeSBiYXJyaWVycy7CoCBBcyAKPiBzdWNoLCB0aGUgZXhhbXBsZXMgd2hpY2ggSSBtaWdo
dCBwcm92aWRlIHdvbid0IGZpdCBpbiBpdC4gCj4KCkkgY29tcGxldGVseSBsb3N0IHRoaXMgZGlz
Y3Vzc2lvbiB0aHJlYWQgYXMgd2VsbC4gQXJlIHlvdSBzYXlpbmcgdGhlIGlzIG5vIHBlcm1pc3Np
b25sZXNzIGlubm92YXRpb24gYmVjYXVzZSBpbm5vdmF0aW9ucyBmYWlsPyBPciB0aGVyZSBpcyBw
ZXJtaXNzaW9ubGVzcyBpbm5vdmF0aW9uIGJlY2F1c2UgdGhlcmUgYXJlIG5vIGJhcnJpZXJzPyAK
Ck5pZWxzCgo+IFJlZ2FyZHMsIAo+IFMuIE1vb25lc2FtecKgIAo+Cg==


From nobody Thu Jan 19 12:56:22 2017
Return-Path: 
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 538BB129610 for ; Thu, 19 Jan 2017 12:56:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ENZJZ6cF2ZVB for ; Thu, 19 Jan 2017 12:56:18 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id BE216129598 for ; Thu, 19 Jan 2017 12:56:18 -0800 (PST)
Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id v0JKtKO7016982; Thu, 19 Jan 2017 15:55:22 -0500
Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id v0JKrI3j000389; Thu, 19 Jan 2017 15:53:18 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22657.10046.3870.908360@gargle.gargle.HOWL>
Date: Thu, 19 Jan 2017 15:53:18 -0500
From: bzs@theworld.com
To: "Bless\, Roland \(TM\)" 
In-Reply-To: 
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> 
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu)
Archived-At: 
Cc: "hrpc@irtf.org" , Eliot Lear 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 20:56:20 -0000

Three things an interdisciplinary approach would bring in would be:

1. People adept at their discipline tend to develop one skill and
that's an eye towards unintended consequences.

Accounting may seem like just a lot of arithmetic and some pages of
rules until your accountant sees you've created a risk of an expensive
govt audit. Computer and networking systems people obsess, and rightly
so, on looking for unintended consequences. And so with govt policy
veterans, lawyers, etc. As is often said in business the primary
purpose of professionals you hire is to keep you out of trouble, not
get you out of trouble.

2. People from other disciplines can help improve language
particularly where that language is to be understood by people in
their discipline as the authors intended. But also just general
accuracy and precision. Mere dictionaries are often not sufficient,
terms of art abound, even intellectual fashions abound and may push
the wrong buttons. How many here might be comfortable using the word
"populism" in a sentence to be read by a wide policy audience?

3. Professionals in their discipline tend to have a lot of experience
in the cost of actually implementing what might seem on the surface
good ideas. Not only in money but in terms of controversy,
distraction, and benefit. A software professional can make a good
guess at what the cost of implementing a protocol change might be. A
policy professional might do the same in the effort it would take to
gain broad acceptance of its intentions, and from whom.

Which is to say I agree with what Eliot Lear actually said.

-- 
        -Barry Shein

Software Tool & Die    | bzs@TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*


From nobody Thu Jan 19 13:53:30 2017
Return-Path: 
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 D3F6D129659 for ; Thu, 19 Jan 2017 13:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level: 
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=OvHqbcEm; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=ORUCAeQt
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 gqtMBMZ7NMed for ; Thu, 19 Jan 2017 13:53:27 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F31A12962C for ; Thu, 19 Jan 2017 13:53:27 -0800 (PST)
Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0JLr7Kl022584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2017 13:53:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484862796; x=1484949196; bh=6K5H4aAPjp0gNnkGPba/Pz8teujIDa/oD3x232pB3NU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OvHqbcEmzVpmtdbqsnop9+pwfZj145+R1JbsLsr0j/NUmYd+cFaz2MfYFaxY+h4HX JbsrB3+/VbSKsPVyR8tQnseyMn+/1zpU5z3h+swDWiYZv/6CUmKeH6MbA6xRNYO0rA kinPF/G7Cqd4L/4pkbOs/E/W9GFQhZ6Z3tRfeGP0=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484862796; x=1484949196; i=@elandsys.com; bh=6K5H4aAPjp0gNnkGPba/Pz8teujIDa/oD3x232pB3NU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ORUCAeQtGTkJaTnz5kbPZf4O0gOubUPpMDk7YA7ZB26n4Cq6YHIU/9CY8fUuue56T foZ/s5Y5Xsl48c5PG8wZR0RYvb0fXmioXgN1TuOeIvyYwB4lTHs7bC4/nqD+f/HLzE DXAaufMxtfT2YwUwikVwgQdXl7uKDI8qJpOnzExY=
Message-Id: <6.2.5.6.2.20170119122813.0b950200@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 19 Jan 2017 13:49:29 -0800
To: Niels ten Oever , hrpc@irtf.org
From: S Moonesamy 
In-Reply-To: <20170119202424.0E9C6BCE37@mail.article19.org>
References: <20170119202424.0E9C6BCE37@mail.article19.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 21:53:29 -0000

Hi Niels,
At 12:24 19-01-2017, Niels ten Oever wrote:
>I am sorry but I find it impossible to have an unthreaded discussion 
>in this way. Could you please keep the discussion inline in your 
>responses? Thanks in advance.

I interpreted threaded as what is specified in RFC 5322 while you 
probably mean something different.  I'll try a different style of 
reply as it may be what you mean by "discussion inline".

> > >That was not the question. The problem is that many technical choices
> > >have an impact on real life events, we cannot deny or ignore that.
> >
> > I was asked a question about pervasive surveillance and I provided a
> > URL to a review which anyone reading the mailing list can assess for
> > himself/herself.  The argument in the above (see quoted paragraph) is
> > that "many technical choices have an impact on real life
> > events".  The argument is not accompanied by actual cases which are
> > directly related to IETF protocols or standards-setting.
> >
>
>So you're saying that protocols have no impact on society? Then 
>please review the cases in the draft.

I would not say that protocols have no impact on society.  I'll use a 
case from the draft:  "[RFC7540] does not mandate Transport Layer 
Security or any other form of encryption, is also does not support 
opportunistic encryption, so the vulnerabilities listed above for 
HTTP/1 are also valid for HTTP/2 as defined in [RFC7540]".  Are the 
considerations in Section 10 of RFC 7450 inadequate?

Would I advise a customer deploying that protocol to support 
encryption?  Yes.  What about the human rights aspect?  Are there 
cases which I can use as evidence to show that the vulnerability 
harmed a person(s)?  That's what the customer is going to ask.  The 
customer will not be convinced by the examples in the draft as it is 
unfortunately stuff which the customer cannot relate to.  It is 
similar to the "impact on real life events" which you mentioned.

>So it's not about nationality of authors but country of residence? 
>Am confused now.

I'll comment in my reply to Andrew.

>Also we're not claiming to represent the world, but merely this 
>research group. So I think we can close the discussion about this.
>
>I am however more than happy to work together with you on outreach 
>and diversity.

Although I may provide some support, I do not usually do outreach or 
diversity at the regional level.  I would be happy to work with you 
as long as it is not related to a political matter.  My preference up 
to now is to remain neutral.

>Let's give our fellow research group participants some time to 
>respond. Else we can drop the sentence about tagging.

Ok.

>I think that having the discussion unthreaded is not helping for readability.

Sorry about that.

> > I was referring to regulatory barriers.  I have asked my regulator
> > about that; I don't consider the regulation(s) as related to the IETF
> > in any way.
> >
> > >If you provide examples we could discuss them or integrate them in the
> > >draft.
> >
> > If I am not mistaken, the draft is not about regulatory barriers.  As
> > such, the examples which I might provide won't fit in it.
> >
>
>I completely lost this discussion thread as well. Are you saying the 
>is no permissionless innovation because innovations fail? Or there 
>is permissionless innovation because there are no barriers?

In my opinion, permissionless innovation is economic and/or 
political, e.g. business models.  At a national level, it may be a 
matter of public policy.  It does not have much to do with 
"end-to-end".  What I am saying is that the barriers are of a 
regulatory nature.  Permissionless innovation may be workable in, for 
example, the U.S.  I doubt that it would work well in markets whether 
the Internet regulations are different.

Regards,
S. Moonesamy 


From nobody Thu Jan 19 15:16:41 2017
Return-Path: 
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 36C1F1295C2 for ; Thu, 19 Jan 2017 15:16:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level: 
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=WA5KbmZY; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=wu+BRmf+
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 PNU-e3CNYDZX for ; Thu, 19 Jan 2017 15:16:37 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C29DB12948F for ; Thu, 19 Jan 2017 15:16:37 -0800 (PST)
Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0JNGPV2001284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2017 15:16:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484867792; x=1484954192; bh=zXZlBP2QEpftOBY8t0Gk0fCCeimXIoqaQKRpFrHS4G0=; h=Date:To:From:Subject:In-Reply-To:References; b=WA5KbmZYVNO8Wfj+qABa+hKhkcLh+3PzpCeUn6QMkpOqpLyjrnKWY9shUHWOfV/vh pkCbHGjodDE78moKNkdgnkc3PJpa4YHUKlzIB2lwyarRlEIVV6M9mP5Rcd88KfcLG/ S/qdsD7IjKQdPKpbdtdkdLdGNH1eZJQOgi+hG5Ww=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484867792; x=1484954192; i=@elandsys.com; bh=zXZlBP2QEpftOBY8t0Gk0fCCeimXIoqaQKRpFrHS4G0=; h=Date:To:From:Subject:In-Reply-To:References; b=wu+BRmf+TSRB/TG0MU1wEMx4x1tVNwrs6hjU5Ue+W2zzZq2MWvN6pARtCCRx99CHa jYIbIHMBfNBLTcfof/2V0LEiinVDt7IQDGy1aXfSJ723pMlpD2i97pF1bJDhLrNKsG y9evcjV2BhaOdS3Zo7tKgbEBsUghjmIKaYWjQNIY=
Message-Id: <6.2.5.6.2.20170119135337.0eceffa0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 19 Jan 2017 15:13:41 -0800
To: Andrew Sullivan , hrpc@irtf.org
From: S Moonesamy 
In-Reply-To: <20170119202424.0E9C6BCE37@mail.article19.org>
References: <20170119202424.0E9C6BCE37@mail.article19.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 23:16:39 -0000

Hi Andrew,

Quoting from the message at=20
https://www.ietf.org/mail-archive/web/hrpc/current/msg00846.html

>I have two problems with this claim, and since this discussion about
>consulting everyone appears to be continuing I think I want to object
>to the apparent line of reasoning.
>
>The first problem I have is that it simply isn't true that it is
>always better to ask someone from Country X about the situation in
>Country X than it is to ask some expert about the relevant situation.
>People are often extraordinarily confused about how their own country
>works.  Many Canadians, for instance, persist in believing that they
>vote for the Prime Minister, but I could ask anyone properly familiar
>with Westminster systems and each would answer the question correctly.

I'll refrain from commenting about Canada as it=20
is a matter for the citizens of that country to discuss about.

My comment was about how a person is affected by=20
the decision, and not, how a person feels about=20
the decision.  If the decision is about the=20
(local) laws it would be better to ask a person=20
with relevant expertise or experience about that.

>The second problem I have is that the second =B6 contains two questions,
>one of which appears to be a question about how people feel and the
>other of which is one of simple entailment given the definitions of
>"human rights" and "infringed".  Neither of them, anyway, is relevant
>to what is in the previous =B6, except of course that _ex hypothesi_ we
>have to ask the person in the Netherlands about the effect on him or
>her.

The point was about whether the person would be=20
able to challenge that decision.  One of the=20
arguments being made for blocking HTTP [1] is to=20
restrict foreign influence on issues which may be=20
considered as a matter of national security.

>I think there is a legitimate question about the population of
>reviewers for this document (given that it's in the IRTF, that's
>hardly surprising).  I think the representativity of nationals of the
>countries of the world is not that legitimate question.

I used "nationals" as an example.  There is=20
another way to look at this.  For example, are=20
you (used in general terms) trying to get a=20
breath of reviews or would you settle=20
for  reviews from one part of the world?  If it=20
is the latter, it will be used as an example by=20
countries which are concerned about unbalanced representativity.

Regards,
S. Moonesamy

1. It is usually done through DNS. =20


From nobody Fri Jan 20 01:18:35 2017
Return-Path: 
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 D54AB129ACB for ; Fri, 20 Jan 2017 01:18:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 U2UqmDZGQ0KS for ; Fri, 20 Jan 2017 01:18:30 -0800 (PST)
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 59FB2129ABF for ; Fri, 20 Jan 2017 01:18:30 -0800 (PST)
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 1cUVL1-0003KQ-F3; Fri, 20 Jan 2017 10:18:27 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 602A1B00226; Fri, 20 Jan 2017 10:18:27 +0100 (CET)
To: bzs@theworld.com
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>  <22657.10046.3870.908360@gargle.gargle.HOWL>
From: "Bless, Roland (TM)" 
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: 
Date: Fri, 20 Jan 2017 10:18:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <22657.10046.3870.908360@gargle.gargle.HOWL>
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 1484903907.
Archived-At: 
Cc: "hrpc@irtf.org" , Eliot Lear 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 09:18:34 -0000

Hi,

Am 19.01.2017 um 21:53 schrieb bzs@theworld.com:
> Three things an interdisciplinary approach would bring in would be:
> 
> 1. People adept at their discipline tend to develop one skill and
> that's an eye towards unintended consequences.
> 
> Accounting may seem like just a lot of arithmetic and some pages of
> rules until your accountant sees you've created a risk of an expensive
> govt audit. Computer and networking systems people obsess, and rightly
> so, on looking for unintended consequences. And so with govt policy
> veterans, lawyers, etc. As is often said in business the primary
> purpose of professionals you hire is to keep you out of trouble, not
> get you out of trouble.
> 
> 2. People from other disciplines can help improve language
> particularly where that language is to be understood by people in
> their discipline as the authors intended. But also just general
> accuracy and precision. Mere dictionaries are often not sufficient,
> terms of art abound, even intellectual fashions abound and may push
> the wrong buttons. How many here might be comfortable using the word
> "populism" in a sentence to be read by a wide policy audience?
> 
> 3. Professionals in their discipline tend to have a lot of experience
> in the cost of actually implementing what might seem on the surface
> good ideas. Not only in money but in terms of controversy,
> distraction, and benefit. A software professional can make a good
> guess at what the cost of implementing a protocol change might be. A
> policy professional might do the same in the effort it would take to
> gain broad acceptance of its intentions, and from whom.
> 
> Which is to say I agree with what Eliot Lear actually said.

I'm not sure whether there is a misunderstanding, but
I also supported Eliot's suggestion (I said
"This indeed needs more discussion between the disciplines").
My point was that interdisciplinary work requires even more
than just several reviews by a community from other disciplines.
Especially, a common understanding of terms, thinking and
viewpoints usually requires lots of (close) interactions. More reviews
from other disciplines is inevitable and a good start, but
probably not sufficient.

Regards,
 Roland


From nobody Fri Jan 20 02:57:14 2017
Return-Path: 
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 EE3C3129B15 for ; Fri, 20 Jan 2017 02:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 fnz2IP0zNhRt for ; Fri, 20 Jan 2017 02:56:59 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 021D4129428 for ; Fri, 20 Jan 2017 02:56:55 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cUWsC-0005hh-8S; Fri, 20 Jan 2017 11:56:48 +0100
To: S Moonesamy , hrpc@irtf.org
References: <20170119202424.0E9C6BCE37@mail.article19.org> <6.2.5.6.2.20170119122813.0b950200@elandnews.com>
From: Niels ten Oever 
Message-ID: <32d98638-681a-3e8e-a888-94a6675f014c@article19.org>
Date: Fri, 20 Jan 2017 11:56:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <6.2.5.6.2.20170119122813.0b950200@elandnews.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fg16LNoSU3XC4fpi8Serl0W9d2RKqUjwM"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 106f16f4827d0062d5eea3a45c95681c
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 10:57:05 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fg16LNoSU3XC4fpi8Serl0W9d2RKqUjwM
Content-Type: multipart/mixed; boundary="IFS5V6CvISScfG11k08B61BIeHxOIhFHs";
 protected-headers="v1"
From: Niels ten Oever 
To: S Moonesamy , hrpc@irtf.org
Cc: Corinne Cath 
Message-ID: <32d98638-681a-3e8e-a888-94a6675f014c@article19.org>
Subject: Re: Comments about draft-irtf-hrpc-research-07
References: <20170119202424.0E9C6BCE37@mail.article19.org>
 <6.2.5.6.2.20170119122813.0b950200@elandnews.com>
In-Reply-To: <6.2.5.6.2.20170119122813.0b950200@elandnews.com>

--IFS5V6CvISScfG11k08B61BIeHxOIhFHs
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi SM,
On 01/19/2017 10:49 PM, S Moonesamy wrote:
> Hi Niels,
> At 12:24 19-01-2017, Niels ten Oever wrote:
>> I am sorry but I find it impossible to have an unthreaded discussion
>> in this way. Could you please keep the discussion inline in your
>> responses? Thanks in advance.
>=20
> I interpreted threaded as what is specified in RFC 5322 while you
> probably mean something different.  I'll try a different style of reply=

> as it may be what you mean by "discussion inline".
>=20

Much appreciated.

>> > >That was not the question. The problem is that many technical choic=
es
>> > >have an impact on real life events, we cannot deny or ignore that.
>> >
>> > I was asked a question about pervasive surveillance and I provided a=

>> > URL to a review which anyone reading the mailing list can assess for=

>> > himself/herself.  The argument in the above (see quoted paragraph) i=
s
>> > that "many technical choices have an impact on real life
>> > events".  The argument is not accompanied by actual cases which are
>> > directly related to IETF protocols or standards-setting.
>> >
>>
>> So you're saying that protocols have no impact on society? Then please=

>> review the cases in the draft.
>=20
> I would not say that protocols have no impact on society.  I'll use a
> case from the draft:  "[RFC7540] does not mandate Transport Layer
> Security or any other form of encryption, is also does not support
> opportunistic encryption, so the vulnerabilities listed above for HTTP/=
1
> are also valid for HTTP/2 as defined in [RFC7540]".  Are the
> considerations in Section 10 of RFC 7450 inadequate?
>=20
> Would I advise a customer deploying that protocol to support
> encryption?  Yes.  What about the human rights aspect?  Are there cases=

> which I can use as evidence to show that the vulnerability harmed a
> person(s)?  That's what the customer is going to ask.  The customer wil=
l
> not be convinced by the examples in the draft as it is unfortunately
> stuff which the customer cannot relate to.  It is similar to the "impac=
t
> on real life events" which you mentioned.
>=20

I find it hard to argue about whether a fictional customer might or
might not be convinced. On the other hand, a lot of companies do care
about their human rights impact and even implement the UN Guiding
Principles on Business and Human Rights:

https://www.business-humanrights.org/en/find-companies

So I some companies are convinced, and they might think their customers
care about this too.

>> So it's not about nationality of authors but country of residence? Am
>> confused now.
>=20
> I'll comment in my reply to Andrew.
>=20
>> Also we're not claiming to represent the world, but merely this
>> research group. So I think we can close the discussion about this.
>>
>> I am however more than happy to work together with you on outreach and=

>> diversity.
>=20
> Although I may provide some support, I do not usually do outreach or
> diversity at the regional level.  I would be happy to work with you as
> long as it is not related to a political matter.  My preference up to
> now is to remain neutral.
>=20
>> Let's give our fellow research group participants some time to
>> respond. Else we can drop the sentence about tagging.
>=20
> Ok.
>=20
>> I think that having the discussion unthreaded is not helping for
>> readability.
>=20
> Sorry about that.
>=20
>> > I was referring to regulatory barriers.  I have asked my regulator
>> > about that; I don't consider the regulation(s) as related to the IET=
F
>> > in any way.
>> >
>> > >If you provide examples we could discuss them or integrate them in =
the
>> > >draft.
>> >
>> > If I am not mistaken, the draft is not about regulatory barriers.  A=
s
>> > such, the examples which I might provide won't fit in it.
>> >
>>
>> I completely lost this discussion thread as well. Are you saying the
>> is no permissionless innovation because innovations fail? Or there is
>> permissionless innovation because there are no barriers?
>=20
> In my opinion, permissionless innovation is economic and/or political,
> e.g. business models.  At a national level, it may be a matter of publi=
c
> policy.  It does not have much to do with "end-to-end".  What I am
> saying is that the barriers are of a regulatory nature.  Permissionless=

> innovation may be workable in, for example, the U.S.  I doubt that it
> would work well in markets whether the Internet regulations are differe=
nt.
>=20

Could you name an example of a country / locale where there is no
permissionless innovation on the Internet?

Best,

Niels

> Regards,
> S. Moonesamy


--IFS5V6CvISScfG11k08B61BIeHxOIhFHs--

--fg16LNoSU3XC4fpi8Serl0W9d2RKqUjwM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliB7O4ACgkQDtg/OkaK
yLNEwg//dc4JKlqesE37NJ1PE4xUeNjmYbXJcCpNbbaaUOc9JokgW1RT+nU71nD3
+QMrNzWuWM+liGv1Fu9murdMZW75W8rIt+nodr2u+ge+AErw7tgOGY54N+pLp72X
ca/3v07A8/6GtUgkQmhLFku0GDoWtJrwvSTpq45tBpZVXQzhgl8nkwMCw971xigu
0IHui/GN/Xj05wmaGKMpZ/+fe/7oWHh2Dyp7whhqyH26y26rDkBOynOlNxCvkGNi
Pq2V4VGZNjGpME0KvOv6WlCTjtxeGukYj3yUfSVm27fleEHZudio7P+LP7iI3aHj
AgrzWcR8AV1QEQL08DBIwNiqNkAjxP1c3Dtgs/EVI1JjUFrv88ox7nSaYNVALM0x
CMyOHv94JkCa4f1ca5Whpno8ir4GLVY/3qVCC1icyl2bEbfHPxmFWjLUyRoj4d1C
7zxPPVhF1pOS2AOfyhUH8MntgaUXG6KlFDCDyy9U3IGJbF8jqKP5O1EGsJwts5ei
aNJrHM+usH/kuOX/zfwHa/Wt/iEj6QlOJxHh+xvw1lTQa8ankgMeN+BaR8uw6xsC
1N+XnS7KPdr92QXWhAQcVh4K9XU1nxS2RG5ZQ48j8Ow0M37dhl//SRAaNT7NyNxd
KFzKUHIqmhV3Ob5B+0g5medcNpzdQau4hbrmiXWUK7LRVeOTvuU=
=aVvB
-----END PGP SIGNATURE-----

--fg16LNoSU3XC4fpi8Serl0W9d2RKqUjwM--


From nobody Fri Jan 20 03:19:04 2017
Return-Path: 
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 AF73812946A for ; Fri, 20 Jan 2017 03:19:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 YJUPDsB2JH6k for ; Fri, 20 Jan 2017 03:19:01 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 0BFCB12943F for ; Fri, 20 Jan 2017 03:19:00 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cUXDe-0001h9-GL for hrpc@irtf.org; Fri, 20 Jan 2017 12:18:58 +0100
To: hrpc@irtf.org
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>  <22657.10046.3870.908360@gargle.gargle.HOWL> 
From: Niels ten Oever 
Message-ID: <236be392-6ced-861c-5ae3-a087f9048fa1@article19.org>
Date: Fri, 20 Jan 2017 12:18:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LIbdTa8uuQQJ7jfTufUGlw6aHDLnfl1S9"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: d2b65465fd2235632e6f1ea95c39dbf6
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 11:19:03 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LIbdTa8uuQQJ7jfTufUGlw6aHDLnfl1S9
Content-Type: multipart/mixed; boundary="m7UOPHrVPvGgFVfj0V9vCnjGQXopNe4NO";
 protected-headers="v1"
From: Niels ten Oever 
To: hrpc@irtf.org
Message-ID: <236be392-6ced-861c-5ae3-a087f9048fa1@article19.org>
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>
 
 <22657.10046.3870.908360@gargle.gargle.HOWL>
 
In-Reply-To: 

--m7UOPHrVPvGgFVfj0V9vCnjGQXopNe4NO
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi all,

On 01/20/2017 10:18 AM, Bless, Roland (TM) wrote:
> Hi,
>=20
> Am 19.01.2017 um 21:53 schrieb bzs@theworld.com:
>> Three things an interdisciplinary approach would bring in would be:
>>
>> 1. People adept at their discipline tend to develop one skill and
>> that's an eye towards unintended consequences.
>>
>> Accounting may seem like just a lot of arithmetic and some pages of
>> rules until your accountant sees you've created a risk of an expensive=

>> govt audit. Computer and networking systems people obsess, and rightly=

>> so, on looking for unintended consequences. And so with govt policy
>> veterans, lawyers, etc. As is often said in business the primary
>> purpose of professionals you hire is to keep you out of trouble, not
>> get you out of trouble.
>>
>> 2. People from other disciplines can help improve language
>> particularly where that language is to be understood by people in
>> their discipline as the authors intended. But also just general
>> accuracy and precision. Mere dictionaries are often not sufficient,
>> terms of art abound, even intellectual fashions abound and may push
>> the wrong buttons. How many here might be comfortable using the word
>> "populism" in a sentence to be read by a wide policy audience?
>>
>> 3. Professionals in their discipline tend to have a lot of experience
>> in the cost of actually implementing what might seem on the surface
>> good ideas. Not only in money but in terms of controversy,
>> distraction, and benefit. A software professional can make a good
>> guess at what the cost of implementing a protocol change might be. A
>> policy professional might do the same in the effort it would take to
>> gain broad acceptance of its intentions, and from whom.
>>
>> Which is to say I agree with what Eliot Lear actually said.
>=20
> I'm not sure whether there is a misunderstanding, but
> I also supported Eliot's suggestion (I said
> "This indeed needs more discussion between the disciplines").
> My point was that interdisciplinary work requires even more
> than just several reviews by a community from other disciplines.
> Especially, a common understanding of terms, thinking and
> viewpoints usually requires lots of (close) interactions. More reviews
> from other disciplines is inevitable and a good start, but
> probably not sufficient.
>=20

I think we're actually already doing quite a good job of (starting to)
attracting people from other disciplines here. I'd hope this is only the
beginning, and pushing out a draft would probably get us more exposure
and thus a higher ability to get people in and work on follow-up drafts.

With the film we've made, and a lot of talks Corinne and I held about
this topic to ISOC fellows, at universities, at NGO's in the global
south (Argentina, Brazil (Rio and Sao Paulo), Kenya) and the global
north (Amsterdam, Brussels, Washington DC, Wellington), we see that
there is interest, but there are still barriers. Both Avri and I
publicized the draft in a lot of non-IETF/IRTF mailinglists for
reviewed, but unfortunately some response I got was that quite some
people did not feel confident enough to post here, which is a pity imho.

Therefore I hope the perfect will not be the enemy of the good here. As
someone who is quite invested into cross-disciplinary research, I could
not support this quest more, but as a lot of things, I think this is
iterative.

All the best,

Niels


--m7UOPHrVPvGgFVfj0V9vCnjGQXopNe4NO--

--LIbdTa8uuQQJ7jfTufUGlw6aHDLnfl1S9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliB8iEACgkQDtg/OkaK
yLMFwhAAk214b7Fx1QOAhqCrRcZM5y/EYWUjupLQeh+ZOq1QIuVC4Me/lBBX9BMO
v/yXOoA733gCC3UzTmlU32p9XjbfiwcTiY91MqBcvxHAKthStOre2jQIn7u/cMoa
Xjr+/7fuLI1J8RMwyurI9y1QHQnbh9IgxhHQuY+SjHA3ree9ELODv/i0qCtOVakO
jW3i4iAsoHmmm42AhGLqHWx4BwyRLZw1OVDnY/gT4EGe4Eb6su6o2Ch4ftUdJjdM
VK3qmA8NCGwveeWI8G4ZB0ILjMIuvYE7JoF9MOtJkepXK35MN3gnP+Th4wVEBd1W
n3oqHSpu+ukO5+N0qn75naQQEQxxNip+F8yZWybAnXQFLrFwrr/OwQ8yqzQK8seB
ISPPK2iQI5iaKLzcCmgaj0e98wvwAvrXbPU3KHhrHVO6etvYW+mvxGPaBL3T+7gZ
Rie7PtL2/N8j8gkbuf+bZa1HbgXjX7HPhTqkJe2tGE+FpDOzbspZeHc1zEiQXnwt
us6cbEtKBg80z42BPOevVvaHQnfsDoOOyyOvltbC3h9SFMcpq2uCOno+sGhPmA2w
FNbm9EfPpJuzel74J3SkoVolGq8rLoWuXdz9PbG8ahX4TJJW9AGkMW9BSMro7h68
iGvb1wC7rAj2Zgf4gWXYyQcfzFgGs2t1XQSpgl4AgXcZnZQr5V4=
=u1zq
-----END PGP SIGNATURE-----

--LIbdTa8uuQQJ7jfTufUGlw6aHDLnfl1S9--


From nobody Fri Jan 20 03:41:14 2017
Return-Path: 
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 568DA129B38 for ; Fri, 20 Jan 2017 03:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 39csCZX23sX0 for ; Fri, 20 Jan 2017 03:41:11 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 5254C129B18 for ; Fri, 20 Jan 2017 03:41:11 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cUXZ7-0006CX-DW for hrpc@irtf.org; Fri, 20 Jan 2017 12:41:09 +0100
To: hrpc@irtf.org
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com> <21ed686a-c141-fe7a-f926-2356659ba364@kit.edu>
From: Niels ten Oever 
Message-ID: <7a6da8a1-fb64-b443-5780-b7b403e8f50a@article19.org>
Date: Fri, 20 Jan 2017 12:40:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <21ed686a-c141-fe7a-f926-2356659ba364@kit.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aaBTgxC7lK8Rfo4621N6uQdIIjEn7p1Ps"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 71c358205736690f5000c0a682c32dd6
Archived-At: 
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 11:41:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aaBTgxC7lK8Rfo4621N6uQdIIjEn7p1Ps
Content-Type: multipart/mixed; boundary="e228rHO6EwLumh6PEWg1MMr2E6W3XgJCx";
 protected-headers="v1"
From: Niels ten Oever 
To: hrpc@irtf.org
Message-ID: <7a6da8a1-fb64-b443-5780-b7b403e8f50a@article19.org>
Subject: Re: [hrpc] challenges regarding draft-irtf-hrpc-research-07
References: <141eb9e1-d158-0fe7-2270-298d16ada09b@cisco.com>
 <21ed686a-c141-fe7a-f926-2356659ba364@kit.edu>
In-Reply-To: <21ed686a-c141-fe7a-f926-2356659ba364@kit.edu>

--e228rHO6EwLumh6PEWg1MMr2E6W3XgJCx
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Roland,

On 01/19/2017 05:15 PM, Bless, Roland (TM) wrote:
> Hi,
>=20
> one more comment below.
>=20
> Am 18.01.2017 um 14:22 schrieb Eliot Lear:
>> Following up on Roland Bless' note, and as last call has closed, I wis=
h
>> to raise a concern about repeated discussion about the selection of
>> rights that has been discussed in the draft.  The interplay between
>=20
> This is actually not so difficult to solve.
> I proposed to list the considered human rights and to provide a
> rationale when HR impacts from technical properties/mechanisms are deri=
ved.
> As a start one could use the same reasoning as in our paper [*]:
> "The main source of the values of human rights is the International
> Bill of Human Rights that is composed of the Universal Declaration of
> Human Rights (UDHR) [33] along with the International Covenant on Civil=

> and Political Rights (ICCPR) [34] and the International Covenant on
> Economic, Social and Cultural Rights (ICESCR) [35]. In the light of
> several cases of Internet censorship, the Human Rights Council
> Resolution 20/8 was adopted in 2012, affirming =93. . . that the same
> rights that people have offline must also be protected online. . . =94
> [36]. In 2015, the Charter of Human Rights and Principles for the
> Internet [17] was developed and released [18]. According to these
> documents, some examples of human rights relevant for ICT systems are
> human dignity (Art. 1 UDHR),
> non-discrimination (Art. 2),
> rights to life,
> liberty and security (Art. 3),
> freedom of opinion and expression (Art. 19),
> freedom of assembly and association (Art. 20),
> rights to equal protection, legal remedy, fair trial, due process,
> presumed innocent (Art. 7=9611),
> appropriate social and international order (Art. 28),
> participation in public affairs (Art. 21),
> participation in cultural life,
> protection of intellectual property (Art. 27), and
> privacy (Art. 12)."
>=20
> [*] http://dl.acm.org/citation.cfm?doid=3D2935634.2935640 can be freely=

> accessed via http://conferences.sigcomm.org/sigcomm/2016/program.php
> (last paper).

I like this proposal a lot and would indeed add more clarity, a
justification as well as a genealogy. I have added it to the text:

https://github.com/nllz/IRTF-HRPC/commit/894fca9c626d72040747c0bdb5aefcb8=
e7d470bf

Best,

Niels

>=20
> Regards,
>  Roland
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


--e228rHO6EwLumh6PEWg1MMr2E6W3XgJCx--

--aaBTgxC7lK8Rfo4621N6uQdIIjEn7p1Ps
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliB90gACgkQDtg/OkaK
yLMysA/9GgQ6d1IrOpzNmKCzsbL9LTObXIsR1T29hgw7P+Lz8bZ0irpw5w6JKMaC
R6XhvO/mFL7EJsTmXM6u5E/fdr+A1D3SROlOuiHWg08pQlfIZ2Hwp2MAkoGmaf0F
dX1jOeFc2StP9mw03zcahZBtSfScSj4frGBHLpS7z5yAgXhlpEA6mq4tGw9VZiF0
L7sZBCp4eIjss2S5ZvNc+HzvzCz2LJlfKaTjOksTPe/VgN7pQfvh55PsBZSnDrkn
CwxQqc0L+FZAct0RRGClLO6DxiFOQEo+0CLFnHwaU6wKcEPKx3k+/1P6gmQ/YieE
mSJrl2YiDHHS3jXd3JuYNKgUG7A3eEMn5sVw3ye1AB80fN6OkhFbeEGWMvCJ9Ka/
hxZlj3CoD54A20oq8qUniwS5i4nOCCIBpCm07E4xJ9Vo8lE+pi2y0B8DMMYDzRWl
1gaYHp9XA3Eaia2dktpU9flaVg4x4NfXzlci8HCBtzaibXIq0+jveOPtLMCJC2D0
Htkq71A/ujq8ZBOcXVueK01roTrdk6JrCcfNo+KXXH37t302Kx+8z51C/7pnM6l/
ws1L2z5XQcIX8Lz4Ymzptor5AMNlsL3cJnhEkNpXRk+0Of1fTN/V6cSyskDH8uZG
BuiMgZFJjTgClCljPfh34iWKgTSzrLpmol7Pi/G2Vr0tuGyTBCY=
=DRVV
-----END PGP SIGNATURE-----

--aaBTgxC7lK8Rfo4621N6uQdIIjEn7p1Ps--


From nobody Fri Jan 20 03:42:21 2017
Return-Path: 
X-Original-To: hrpc@irtf.org
Delivered-To: hrpc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 976E2129B39; Fri, 20 Jan 2017 03:42:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>
Date: Fri, 20 Jan 2017 03:42:18 -0800
Archived-At: 
Cc: hrpc@irtf.org
Subject: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 11:42:18 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Human Rights Protocol Considerations of the IETF.

        Title           : Research into Human Rights Protocol Considerations
        Authors         : Niels ten Oever
                          Corinne Cath
	Filename        : draft-irtf-hrpc-research-08.txt
	Pages           : 72
	Date            : 2017-01-20

Abstract:
   This document aims to propose guidelines for human rights
   considerations, similar to the work done on the guidelines for
   privacy considerations [RFC6973].  This is achieved by providing a
   proposal for a vocabulary to discuss the relation between human
   rights and Internet protocols, an overview of the discussion in
   technical and academic literature and communities, a proposal for the
   mapping of the relation between human rights and technical concepts,
   as well as guidelines.

   If you want to see how to apply this work to your own, you can
   directly go to Section 6.  The rest of the document explains the
   background of the guidelines and how they were developed.

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  This documents aims to be a consensus
   document of the Human Rights Protocol Consideration Research Group of
   the Internet Research Task Force (IRTF).

   Discussion of this draft at: hrpc@irtf.org //
   https://www.irtf.org/mailman/listinfo/hrpc


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-hrpc-research-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-research-08


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Jan 20 03:47:37 2017
Return-Path: 
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 24809129B39 for ; Fri, 20 Jan 2017 03:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 By-KwxynToo7 for ; Fri, 20 Jan 2017 03:47:34 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 853B7129441 for ; Fri, 20 Jan 2017 03:47:34 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cUXfI-0007R4-Oe for hrpc@irtf.org; Fri, 20 Jan 2017 12:47:33 +0100
To: hrpc@irtf.org
References: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>
From: Niels ten Oever 
Message-ID: 
Date: Fri, 20 Jan 2017 12:47:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rRBeagDKGO7DQAr0XNmVP617bA30dXDQJ"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 025acf9a139f050bc01ccdeba87e03e0
Archived-At: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 11:47:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rRBeagDKGO7DQAr0XNmVP617bA30dXDQJ
Content-Type: multipart/mixed; boundary="RUPl5g4pnSHRAg3GtL2pqgo9m7ddPKCI1";
 protected-headers="v1"
From: Niels ten Oever 
To: hrpc@irtf.org
Message-ID: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
References: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>
In-Reply-To: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>

--RUPl5g4pnSHRAg3GtL2pqgo9m7ddPKCI1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Dear all,

Based on all the really great suggestions, comments and discussions
we've had during and after the last call I created a new version.

I would like to thank everyone for taking the time to help this draft
getting better.

All the best,

Niels



Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3

On 01/20/2017 12:42 PM, internet-drafts@ietf.org wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> This draft is a work item of the Human Rights Protocol Considerations o=
f the IETF.
>=20
>         Title           : Research into Human Rights Protocol Considera=
tions
>         Authors         : Niels ten Oever
>                           Corinne Cath
> 	Filename        : draft-irtf-hrpc-research-08.txt
> 	Pages           : 72
> 	Date            : 2017-01-20
>=20
> Abstract:
>    This document aims to propose guidelines for human rights
>    considerations, similar to the work done on the guidelines for
>    privacy considerations [RFC6973].  This is achieved by providing a
>    proposal for a vocabulary to discuss the relation between human
>    rights and Internet protocols, an overview of the discussion in
>    technical and academic literature and communities, a proposal for th=
e
>    mapping of the relation between human rights and technical concepts,=

>    as well as guidelines.
>=20
>    If you want to see how to apply this work to your own, you can
>    directly go to Section 6.  The rest of the document explains the
>    background of the guidelines and how they were developed.
>=20
>    This document is not an Internet Standards Track specification; it i=
s
>    published for informational purposes.
>=20
>    This document is a product of the Internet Research Task Force
>    (IRTF).  The IRTF publishes the results of Internet-related research=

>    and development activities.  This documents aims to be a consensus
>    document of the Human Rights Protocol Consideration Research Group o=
f
>    the Internet Research Task Force (IRTF).
>=20
>    Discussion of this draft at: hrpc@irtf.org //
>    https://www.irtf.org/mailman/listinfo/hrpc
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-irtf-hrpc-research-08
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-hrpc-research-08
>=20
>=20
> Please note that it may take a couple of minutes from the time of submi=
ssion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


--RUPl5g4pnSHRAg3GtL2pqgo9m7ddPKCI1--

--rRBeagDKGO7DQAr0XNmVP617bA30dXDQJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliB+NMACgkQDtg/OkaK
yLPabRAAo5xTPq2bwnhcFomtj0gNyEaDLwUWub0OYtXKmOuU5opkGDh7ZHhJFryZ
k3EvkTiaKkI57SMzwZ+sXKTa2aL8FLUoiL6wCEbhUz6KG3gSb6yE2gA+0KIKOLom
erUzxX3iNVyvNRu05boQEvbA6JunqG7cFkmhqoYTQcJowIDYmSKm+1hpCGDOyvEh
1GZrWHgGz1BUpOicIuwc7G5lr9CP6uqMYSNPMclr+lm1Bz2mHxJeUaT5D986FKJv
XSdUbIosCUm2hhj2B74UgV9viIUUM/iGUMS8zi1Vn++803SncIgEJRG9oTdoEqCc
NGavGk5KRZzK2UH9QXYzNfcPWMyzfYMhRTI1iqj1s/i1YDcP0OL8wcNg3YfXI0yZ
1Fc1g+AahftHML/o3Hcg3SDp5A+iCkLOrgJ6ivP0lrGK3iKe0ivmIAny8/BnUgke
8SM7cvxs9BHQXmVtHGfuRH20W+9Wsm+ZYKUCp3dlIuTN06HZzsWExjJAzNUfukdi
F7bHN+H8oG+AgqQnYEvBPYzh7m/pAFI1SB5h/bTGi9J4yb6XjcBF8MmHuFyXn/Y9
fEJX5hp5prCMd3lFlvTKc7iDOt7g1tYKHYQPZpmWQixqV+R68XHRX5aKXlCJwIp1
Wl8HvZf9Wj+3tm+V6iL5Vtq7f9tS6+T1OT2aS+xZtnSnWRH5iyk=
=eb9c
-----END PGP SIGNATURE-----

--rRBeagDKGO7DQAr0XNmVP617bA30dXDQJ--


From nobody Fri Jan 20 07:27:10 2017
Return-Path: 
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 D8DFE1295FA for ; Fri, 20 Jan 2017 07:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level: 
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 Dg6omLvv5eRQ for ; Fri, 20 Jan 2017 07:27:06 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 AE1211295D0 for ; Fri, 20 Jan 2017 07:27:06 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 825F8280667; Fri, 20 Jan 2017 16:27:04 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 7CA14280644; Fri, 20 Jan 2017 16:27:04 +0100 (CET)
Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 795E1B3800C; Fri, 20 Jan 2017 16:26:34 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 73B4A4322E; Fri, 20 Jan 2017 16:26:34 +0100 (CET)
Date: Fri, 20 Jan 2017 16:26:34 +0100
From: Stephane Bortzmeyer 
To: Stephen Farrell , draft-hall-censorship-tech.authors@ietf.org
Message-ID: <20170120152634.z73lroetf73qhn5t@nic.fr>
References: <20170110111044.tyfvvt3sx7ssfg42@nic.fr> <65044640-8c6a-15b8-9e8c-3233b9be6783@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <65044640-8c6a-15b8-9e8c-3233b9be6783@cs.tcd.ie>
X-Operating-System: Debian GNU/Linux stretch/sid
X-Kernel: Linux 4.7.0-1-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20161126 (1.7.1)
Archived-At: 
Cc: Stephane Bortzmeyer , hrpc@irtf.org
Subject: Re: [hrpc] draft-hall-censorship-tech expired
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 15:27:09 -0000

On Tue, Jan 10, 2017 at 11:45:18AM +0000,
 Stephen Farrell  wrote 
 a message of 114 lines which said:

> I'm chatting with Joe about progressing that as an AD sponsored IETF
> draft. That's been a bit delayed for good reasons but I hope we'll
> get IETF last call started soon.

OK, I'll wait.

In the mean time, an interesting read on this subject:

The Dictator's Digital Toolkit: Explaining Variation in Internet Filtering in Authoritarian Regimes

http://onlinelibrary.wiley.com/doi/10.1111/polp.12189/full

Not available online but you can find it on a well-know platform for
sharing of scientific papers.


From nobody Fri Jan 20 13:32:56 2017
Return-Path: 
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 75B6E1294AD for ; Fri, 20 Jan 2017 13:32:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level: 
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=vVH39riX; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=y0oy4HIl
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 9IbO4zX-wPNL for ; Fri, 20 Jan 2017 13:32:54 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6990F1294A8 for ; Fri, 20 Jan 2017 13:32:54 -0800 (PST)
Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0KLWXMO008332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jan 2017 13:32:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484947962; x=1485034362; bh=UILpJ014JYjfEJsPwYx+33mITicvLSfSxhZKGwATR9Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vVH39riXyhPQGMcEB0hFClVJicmluSmM/YykRK/qS5IScOMySap2IwlDBjGL+pYfw AJ7yFDX8NZEBWBSA0g+ZmDCJhwFA1rIoDb+HXlXS4cMlA9WDr68Id/S7HqywW9aStv RWTHQg6nvSOFSw7dcuaXshlY/mM/npoKNrhNc+N8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484947962; x=1485034362; i=@elandsys.com; bh=UILpJ014JYjfEJsPwYx+33mITicvLSfSxhZKGwATR9Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=y0oy4HIlpD+qYsIpBDtdGerUzIK/P3kRnj1MNUqY1FJSOHbxdoeJp0xCMJhrbneFv +GSxvpFtz+BzvKUCr2usJD5NsvcBuO3rywPxX31qu3VYcBv5Ck5tbBKDsSASFdiufD SKFvMhXkO0QdVay0JL1lDkfvVp0tkyBUb1WA5Keo=
Message-Id: <6.2.5.6.2.20170120102544.0ae3e010@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 20 Jan 2017 11:41:00 -0800
To: Niels ten Oever , hrpc@irtf.org
From: S Moonesamy 
In-Reply-To: <32d98638-681a-3e8e-a888-94a6675f014c@article19.org>
References: <20170119202424.0E9C6BCE37@mail.article19.org> <6.2.5.6.2.20170119122813.0b950200@elandnews.com> <32d98638-681a-3e8e-a888-94a6675f014c@article19.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Cc: Corinne Cath 
Subject: Re: [hrpc] Comments about draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 21:32:55 -0000

Hi Niels,
At 02:56 20-01-2017, Niels ten Oever wrote:
> > Would I advise a customer deploying that protocol to support
> > encryption?  Yes.  What about the human rights aspect?  Are there cases
> > which I can use as evidence to show that the vulnerability harmed a
> > person(s)?  That's what the customer is going to ask.  The customer will
> > not be convinced by the examples in the draft as it is unfortunately
> > stuff which the customer cannot relate to.  It is similar to the "impact
> > on real life events" which you mentioned.
> >
>
>I find it hard to argue about whether a fictional customer might or
>might not be convinced. On the other hand, a lot of companies do care
>about their human rights impact and even implement the UN Guiding
>Principles on Business and Human Rights:

I'll leave it to anyone who has experience in the field to determine 
whether what I wrote reflects reality or not.  The draft mentions a 
few cases where companies sold surveillance  products to monitor 
internet users.  I will be convinced about those guiding principles 
when I see people doing what they say.

> > In my opinion, permissionless innovation is economic and/or political,
> > e.g. business models.  At a national level, it may be a matter of public
> > policy.  It does not have much to do with "end-to-end".  What I am
> > saying is that the barriers are of a regulatory nature.  Permissionless
> > innovation may be workable in, for example, the U.S.  I doubt that it
> > would work well in markets whether the Internet regulations are different.
> >
>
>Could you name an example of a country / locale where there is no
>permissionless innovation on the Internet?

I suggest researching about countries with historic monopolies [1].

Regards,
S. Moonesamy

1. In relation to the Internet 


From nobody Wed Jan 25 12:04:24 2017
Return-Path: 
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 C87F2129B64 for ; Wed, 25 Jan 2017 12:04:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.255
X-Spam-Level: 
X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no 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 5mGrUKzXRuul for ; Wed, 25 Jan 2017 12:04:16 -0800 (PST)
Received: from smtprelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2D6129B9B for ; Wed, 25 Jan 2017 12:03:45 -0800 (PST)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id D012729DD77; Wed, 25 Jan 2017 20:03:44 +0000 (UTC)
X-Session-Marker: 6176726940646F7269612E6F7267
X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, ::, RULES_HIT:2:41:355:379:599:800:854:967:969:973:988:989:1042:1049:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1513:1515:1516:1518:1521:1535:1593:1594:1605:1606:1683:1730:1747:1777:1792:1801:1963:2194:2198:2199:2200:2288:2393:2525:2553:2568:2630:2682:2685:2741:2743:2771:2829:2859:2891:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4117:4184:4250:4321:4362:4605:4641:4860:5007:6117:6119:7652:7903:7974:8660:8985:9010:9025:9108:10004:10848:11232:11658:11914:12043:12109:12114:12291:12295:12379:12438:12663:12683:12740:12895:12926:13019:13132:13148:13161:13191:13192:13229:13230:13231:13548:13846:14096:14097:21060:21080:21366:21433:21451:30022:30041:30046:30054:30060:30069:30070:30075:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rul
X-HE-Tag: salt95_5ac9d61dde040
X-Filterd-Recvd-Size: 6525
Received: from [127.0.0.1] (unknown [64.120.53.75]) (Authenticated sender: avri@doria.org) by omf03.hostedemail.com (Postfix) with ESMTPA; Wed, 25 Jan 2017 20:03:43 +0000 (UTC)
References: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com> 
To: hrpc@irtf.org
From: avri doria 
Message-ID: 
Date: Wed, 25 Jan 2017 15:03:42 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Antivirus: avast! (VPS 170125-0, 01/25/2017), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: avri@acm.org
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2017 20:04:18 -0000

Hi,

Thanks for getting a revision out so quickly.  Am having trouble keeping
up with you and am still reading. I figure I need to reread it all as a
coherent piece of work.

It would be helpful if those who had issues with the reviewed version
could check the diff, at minimum, to see if they are now ok with what
the doc says. And then let the list know.


Also want to throw out another question that has been rumbling about in
the back of my thoughts: is this informational or experimental RFC track?

I think it is recommending something that can be tried experimentally
and is part of a research effort. On an informational, I would think it
was suggesting something that was no longer so speculative but was
information that could be used reliably without confusion, and I am not
sure the group thinks we are there yet.

It may just be a quibble, but would like opinions.

Continuing thanks to the authors and reviewers.

avri

from https://www.ietf.org/iesg/informational-vs-experimental.html

4.2.1 Experimental

The "Experimental" designation typically denotes a specification that is
part of some research or development effort. Such a specification is
published for the general information of the Internet technical
community and as an archival record of the work, subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process (see below). An
Experimental specification may be the output of an organized Internet
research effort (e.g., a Research Group of the IRTF), an IETF Working
Group, or it may be an individual contribution.

4.2.2 Informational

An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation. The Informational
designation is intended to provide for the timely publication of a very
broad range of responsible informational documents from many sources,
subject only to editorial considerations and to verification that there
has been adequate coordination with the standards process (see section


On 20-Jan-17 06:47, Niels ten Oever wrote:
> Dear all,
>
> Based on all the really great suggestions, comments and discussions
> we've had during and after the last call I created a new version.
>
> I would like to thank everyone for taking the time to help this draft
> getting better.
>
> All the best,
>
> Niels
>
>
>
> Niels ten Oever
> Head of Digital
>
> Article 19
> www.article19.org
>
> PGP fingerprint    2458 0B70 5C4A FD8A 9488
>                    643A 0ED8 3F3A 468A C8B3
>
> On 01/20/2017 12:42 PM, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>> This draft is a work item of the Human Rights Protocol Considerations of=
 the IETF.
>>
>>         Title           : Research into Human Rights Protocol Considerat=
ions
>>         Authors         : Niels ten Oever
>>                           Corinne Cath
>> 	Filename        : draft-irtf-hrpc-research-08.txt
>> 	Pages           : 72
>> 	Date            : 2017-01-20
>>
>> Abstract:
>>    This document aims to propose guidelines for human rights
>>    considerations, similar to the work done on the guidelines for
>>    privacy considerations [RFC6973].  This is achieved by providing a
>>    proposal for a vocabulary to discuss the relation between human
>>    rights and Internet protocols, an overview of the discussion in
>>    technical and academic literature and communities, a proposal for the=

>>    mapping of the relation between human rights and technical concepts,
>>    as well as guidelines.
>>
>>    If you want to see how to apply this work to your own, you can
>>    directly go to Section 6.  The rest of the document explains the
>>    background of the guidelines and how they were developed.
>>
>>    This document is not an Internet Standards Track specification; it is=

>>    published for informational purposes.
>>
>>    This document is a product of the Internet Research Task Force
>>    (IRTF).  The IRTF publishes the results of Internet-related research
>>    and development activities.  This documents aims to be a consensus
>>    document of the Human Rights Protocol Consideration Research Group of=

>>    the Internet Research Task Force (IRTF).
>>
>>    Discussion of this draft at: hrpc@irtf.org //
>>    https://www.irtf.org/mailman/listinfo/hrpc
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-irtf-hrpc-research-08
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-hrpc-research-08
>>
>>
>> Please note that it may take a couple of minutes from the time of submis=
sion
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From nobody Thu Jan 26 02:15:05 2017
Return-Path: 
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 2484A129511 for ; Thu, 26 Jan 2017 02:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 es2q4JkkiaZp for ; Thu, 26 Jan 2017 02:15:02 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 C7A621294CF for ; Thu, 26 Jan 2017 02:15:00 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cWh4y-0004sc-Us; Thu, 26 Jan 2017 11:14:58 +0100
Date: Thu, 26 Jan 2017 11:14:53 +0100
From: Niels ten Oever 
To: avri doria 
Message-ID: <20170126101453.u2vagwtiizaioby2@mir>
References: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>  
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i5wnv7hvartz3dhx"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20161126 (1.7.1)
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: c3edc4b356c29f837f5791f340b827b9
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2017 10:15:04 -0000

--i5wnv7hvartz3dhx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Thanks for this Avri,

This might also help with people making up their mind about your questions =
vis a vis informational vs experimental:

https://www.ietf.org/iesg/informational-vs-experimental.html

In my opinion this would work best as informational.

Best,

Niels

On Wed, Jan 25, 2017 at 03:03:42PM -0500, avri doria wrote:
> Hi,
>=20
> Thanks for getting a revision out so quickly.  Am having trouble keeping
> up with you and am still reading. I figure I need to reread it all as a
> coherent piece of work.
>=20
> It would be helpful if those who had issues with the reviewed version
> could check the diff, at minimum, to see if they are now ok with what
> the doc says. And then let the list know.
>=20
>=20
> Also want to throw out another question that has been rumbling about in
> the back of my thoughts: is this informational or experimental RFC track?
>=20
> I think it is recommending something that can be tried experimentally
> and is part of a research effort. On an informational, I would think it
> was suggesting something that was no longer so speculative but was
> information that could be used reliably without confusion, and I am not
> sure the group thinks we are there yet.
>=20
> It may just be a quibble, but would like opinions.
>=20
> Continuing thanks to the authors and reviewers.
>=20
> avri
>=20
> from https://www.ietf.org/iesg/informational-vs-experimental.html
>=20
> 4.2.1 Experimental
>=20
> The "Experimental" designation typically denotes a specification that is
> part of some research or development effort. Such a specification is
> published for the general information of the Internet technical
> community and as an archival record of the work, subject only to
> editorial considerations and to verification that there has been
> adequate coordination with the standards process (see below). An
> Experimental specification may be the output of an organized Internet
> research effort (e.g., a Research Group of the IRTF), an IETF Working
> Group, or it may be an individual contribution.
>=20
> 4.2.2 Informational
>=20
> An "Informational" specification is published for the general
> information of the Internet community, and does not represent an
> Internet community consensus or recommendation. The Informational
> designation is intended to provide for the timely publication of a very
> broad range of responsible informational documents from many sources,
> subject only to editorial considerations and to verification that there
> has been adequate coordination with the standards process (see section
>=20
>=20
> On 20-Jan-17 06:47, Niels ten Oever wrote:
> > Dear all,
> >
> > Based on all the really great suggestions, comments and discussions
> > we've had during and after the last call I created a new version.
> >
> > I would like to thank everyone for taking the time to help this draft
> > getting better.
> >
> > All the best,
> >
> > Niels
> >
> >
> >
> > Niels ten Oever
> > Head of Digital
> >
> > Article 19
> > www.article19.org
> >
> > PGP fingerprint    2458 0B70 5C4A FD8A 9488
> >                    643A 0ED8 3F3A 468A C8B3
> >
> > On 01/20/2017 12:42 PM, internet-drafts@ietf.org wrote:
> >> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
> >> This draft is a work item of the Human Rights Protocol Considerations =
of the IETF.
> >>
> >>         Title           : Research into Human Rights Protocol Consider=
ations
> >>         Authors         : Niels ten Oever
> >>                           Corinne Cath
> >> 	Filename        : draft-irtf-hrpc-research-08.txt
> >> 	Pages           : 72
> >> 	Date            : 2017-01-20
> >>
> >> Abstract:
> >>    This document aims to propose guidelines for human rights
> >>    considerations, similar to the work done on the guidelines for
> >>    privacy considerations [RFC6973].  This is achieved by providing a
> >>    proposal for a vocabulary to discuss the relation between human
> >>    rights and Internet protocols, an overview of the discussion in
> >>    technical and academic literature and communities, a proposal for t=
he
> >>    mapping of the relation between human rights and technical concepts,
> >>    as well as guidelines.
> >>
> >>    If you want to see how to apply this work to your own, you can
> >>    directly go to Section 6.  The rest of the document explains the
> >>    background of the guidelines and how they were developed.
> >>
> >>    This document is not an Internet Standards Track specification; it =
is
> >>    published for informational purposes.
> >>
> >>    This document is a product of the Internet Research Task Force
> >>    (IRTF).  The IRTF publishes the results of Internet-related research
> >>    and development activities.  This documents aims to be a consensus
> >>    document of the Human Rights Protocol Consideration Research Group =
of
> >>    the Internet Research Task Force (IRTF).
> >>
> >>    Discussion of this draft at: hrpc@irtf.org //
> >>    https://www.irtf.org/mailman/listinfo/hrpc
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/
> >>
> >> There's also a htmlized version available at:
> >> https://tools.ietf.org/html/draft-irtf-hrpc-research-08
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-hrpc-research-08
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of subm=
ission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> hrpc mailing list
> >> hrpc@irtf.org
> >> https://www.irtf.org/mailman/listinfo/hrpc
> >>
> >
> >
> > _______________________________________________
> > hrpc mailing list
> > hrpc@irtf.org
> > https://www.irtf.org/mailman/listinfo/hrpc
>=20
>=20
>=20
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc

--=20

Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint	   2458 0B70 5C4A FD8A 9488 =20
                   643A 0ED8 3F3A 468A C8B3


--i5wnv7hvartz3dhx
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliJzBQACgkQDtg/OkaK
yLPZHg/+JRzEvp4u1QWDr7Ku0QzJaLigKG9eVMAs9ABzmLqoYlvj3PRZdnxlVx/M
JKc/YWEEPrFZn+vt+f8rKq4DEX3yhABA2lMLgvBe7aRkxVgcxhEdQvH+67Jx0tlc
x61VaYatED71AC5/A2tcsZ0gkfHqghtzCwYs+QlssQtBUX83DreZWW3C4/iRWcJV
Qgb9KV5ZFbTUIMRHm5LU6+879RGds9LA6PEWVFqwgjX3ciURYSY/McvIayZK9aZP
TLUTwpKKztyLbzadq6JjuVvT7QmhwJSA5lDAXSeOxyTe6vYaitzjfCVnEEyWcjVk
/nkFGkqyxJ7LuFhts7U57GrWpraIU+5OAD2HwdUCwcCQF/KkLXetMQXARLa37QHN
TzJMcOHqssr0OmhF2HkBYVo7aAzNHkvWJURnUS5Q4suC0zkLryRZQr7h9QjebXPu
b/pU654C+kIL4BytgnkvB+RBOa+HKfHOOkZnwcvtnZl7b3mOKm0EwKmB5dsA4nKb
pJpcXZiV6AF0tF58PscqvuRGZjhJpaWPYcKS30Sh4rmI/ZdWTDbk/12a1YKKJ1iY
LUc3eFUu7kKKD3qBvb5JyS+/WglrtH7i8T4RIf1bYBaArsw/bvbg5f9qB8WjJWnz
dHgZibWO2wylcST222HWXjCIBh87IrN7EBO4YULeBiohK3XsvZU=
=zxQ+
-----END PGP SIGNATURE-----

--i5wnv7hvartz3dhx--


From nobody Thu Jan 26 02:20:57 2017
Return-Path: 
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 3C112129512 for ; Thu, 26 Jan 2017 02:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level: 
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2JLwriK6opoC for ; Thu, 26 Jan 2017 02:20:55 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1C1129448 for ; Thu, 26 Jan 2017 02:20:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7900; q=dns/txt; s=iport; t=1485426055; x=1486635655; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=W2sLgTTB3KeWlUzaIia1k3fsPrGTdazMha+2EEVWAJ8=; b=RQsNiQYFXR+jP3oA7dMpwETcinPddjGlQsr3cvekxkD1s/lM114VRcAd zWeqH+pHin5xcFXhFHLaa8xhQ/9LshsrWsHtnEtGzdhNX+o5NLW8ipsOb D06Kpf8oqtgAh4gZxaUTBRanN0OFx8nNR1k+u1tIRAh01TaxY3gTRkiTY 4=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AwBrzIlY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAX8qX4NViglykRqVLoINHwuCQoM2AoJpGAECAQEBAQE?= =?us-ascii?q?BAWIohGoBAQQBASEmIgMEFwsYKgICJzAHDAYCAQEQiQ4OrieCJYpwAQEBAQYBA?= =?us-ascii?q?QEBFQ+IUIFhgQmDDIEPEQGDIoJfBZtQg22CA3WLEYF3U4Q/gyqGPpJ7Hzh2JRM?= =?us-ascii?q?IFRUYI4Y6PzUBhXKCLgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,288,1477958400";  d="asc'?scan'208";a="650168194"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2017 10:20:52 +0000
Received: from [10.61.102.19] (dhcp-10-61-102-19.cisco.com [10.61.102.19]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0QAKqR9003600; Thu, 26 Jan 2017 10:20:52 GMT
To: avri@acm.org, hrpc@irtf.org
References: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>  
From: Eliot Lear 
Message-ID: 
Date: Thu, 26 Jan 2017 11:20:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SmOgGFpb4G60kxwgS388SI8RGiOtRU0kU"
Archived-At: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2017 10:20:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--SmOgGFpb4G60kxwgS388SI8RGiOtRU0kU
Content-Type: multipart/mixed; boundary="E1iEQPFTBvL06q9g2S9Sdk50LGVEL5PXN";
 protected-headers="v1"
From: Eliot Lear 
To: avri@acm.org, hrpc@irtf.org
Message-ID: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
References: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>
 
 
In-Reply-To: 

--E1iEQPFTBvL06q9g2S9Sdk50LGVEL5PXN
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Avri,

I myself seek no more changes to the document.  I would, however, just
ask that you take on board seeking more reviewers prior to advancing
this work, specifically to check that references to work in fields
outside the classic expertise of the IRTF/IETF are being appropriately
applied.  I view this as a bare minimum test.

Eliot


On 1/25/17 9:03 PM, avri doria wrote:
> Hi,
>
> Thanks for getting a revision out so quickly.  Am having trouble keepin=
g
> up with you and am still reading. I figure I need to reread it all as a=

> coherent piece of work.
>
> It would be helpful if those who had issues with the reviewed version
> could check the diff, at minimum, to see if they are now ok with what
> the doc says. And then let the list know.
>
>
> Also want to throw out another question that has been rumbling about in=

> the back of my thoughts: is this informational or experimental RFC trac=
k?
>
> I think it is recommending something that can be tried experimentally
> and is part of a research effort. On an informational, I would think it=

> was suggesting something that was no longer so speculative but was
> information that could be used reliably without confusion, and I am not=

> sure the group thinks we are there yet.
>
> It may just be a quibble, but would like opinions.
>
> Continuing thanks to the authors and reviewers.
>
> avri
>
> from https://www.ietf.org/iesg/informational-vs-experimental.html
>
> 4.2.1 Experimental
>
> The "Experimental" designation typically denotes a specification that i=
s
> part of some research or development effort. Such a specification is
> published for the general information of the Internet technical
> community and as an archival record of the work, subject only to
> editorial considerations and to verification that there has been
> adequate coordination with the standards process (see below). An
> Experimental specification may be the output of an organized Internet
> research effort (e.g., a Research Group of the IRTF), an IETF Working
> Group, or it may be an individual contribution.
>
> 4.2.2 Informational
>
> An "Informational" specification is published for the general
> information of the Internet community, and does not represent an
> Internet community consensus or recommendation. The Informational
> designation is intended to provide for the timely publication of a very=

> broad range of responsible informational documents from many sources,
> subject only to editorial considerations and to verification that there=

> has been adequate coordination with the standards process (see section
>
>
> On 20-Jan-17 06:47, Niels ten Oever wrote:
>> Dear all,
>>
>> Based on all the really great suggestions, comments and discussions
>> we've had during and after the last call I created a new version.
>>
>> I would like to thank everyone for taking the time to help this draft
>> getting better.
>>
>> All the best,
>>
>> Niels
>>
>>
>>
>> Niels ten Oever
>> Head of Digital
>>
>> Article 19
>> www.article19.org
>>
>> PGP fingerprint    2458 0B70 5C4A FD8A 9488
>>                    643A 0ED8 3F3A 468A C8B3
>>
>> On 01/20/2017 12:42 PM, internet-drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts di=
rectories.
>>> This draft is a work item of the Human Rights Protocol Considerations=
 of the IETF.
>>>
>>>         Title           : Research into Human Rights Protocol Conside=
rations
>>>         Authors         : Niels ten Oever
>>>                           Corinne Cath
>>> 	Filename        : draft-irtf-hrpc-research-08.txt
>>> 	Pages           : 72
>>> 	Date            : 2017-01-20
>>>
>>> Abstract:
>>>    This document aims to propose guidelines for human rights
>>>    considerations, similar to the work done on the guidelines for
>>>    privacy considerations [RFC6973].  This is achieved by providing a=

>>>    proposal for a vocabulary to discuss the relation between human
>>>    rights and Internet protocols, an overview of the discussion in
>>>    technical and academic literature and communities, a proposal for =
the
>>>    mapping of the relation between human rights and technical concept=
s,
>>>    as well as guidelines.
>>>
>>>    If you want to see how to apply this work to your own, you can
>>>    directly go to Section 6.  The rest of the document explains the
>>>    background of the guidelines and how they were developed.
>>>
>>>    This document is not an Internet Standards Track specification; it=
 is
>>>    published for informational purposes.
>>>
>>>    This document is a product of the Internet Research Task Force
>>>    (IRTF).  The IRTF publishes the results of Internet-related resear=
ch
>>>    and development activities.  This documents aims to be a consensus=

>>>    document of the Human Rights Protocol Consideration Research Group=
 of
>>>    the Internet Research Task Force (IRTF).
>>>
>>>    Discussion of this draft at: hrpc@irtf.org //
>>>    https://www.irtf.org/mailman/listinfo/hrpc
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-irtf-hrpc-research-08
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-hrpc-research-08
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of sub=
mission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>



--E1iEQPFTBvL06q9g2S9Sdk50LGVEL5PXN--

--SmOgGFpb4G60kxwgS388SI8RGiOtRU0kU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJYic2EAAoJEIe2a0bZ0noz3N4IAMIzy8sGahnAGugqpuais8Tb
K0gNSd8wDfWNAPi1a2ZSf4EU2J7YHepo6kmLzSsv/GyKAZtVTK/uHunYhX8HyrjF
mODCY2EBUwzyEATG3fymtmm117IvlYlZ6mD7u3lRUEGN1+VqJ0OCVIUiXOWXJ/Ej
PUy/HQY8EWV94q9+gE9tjvf3Tq99pCpAa+IYLLtFWjYuobQPqy1/6DX/vxbxC0ck
ee1FMnFWpdW/EZVFGelba1sZLZvfnsqDdZefVV55WEYm+dI52rMqQpwlFJnyqNPr
M5BCXhFy61qOO74b12A6JcjCcIy4+SxZCXjc2QueFkEvYLdk2wV1IyVNEY4wLgg=
=SBVW
-----END PGP SIGNATURE-----

--SmOgGFpb4G60kxwgS388SI8RGiOtRU0kU--


From nobody Thu Jan 26 04:25:40 2017
Return-Path: 
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 7E7E8129540 for ; Thu, 26 Jan 2017 04:25:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 Fycw1LluZ9aK for ; Thu, 26 Jan 2017 04:25:37 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 7AE2A12951A for ; Thu, 26 Jan 2017 04:25:37 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cWj7P-0005IZ-Ni for hrpc@irtf.org; Thu, 26 Jan 2017 13:25:35 +0100
To: "hrpc@irtf.org" 
From: Niels ten Oever 
Message-ID: <5ed90f4f-e9a0-8546-6019-424a8452e274@article19.org>
Date: Thu, 26 Jan 2017 13:25:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cP6k0MxJcoTc4CtD2M6I0C2OU62VwNotp"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 448baf4759cd3283a5930955cc61e1db
Archived-At: 
Subject: [hrpc] figure 2 broken in -08
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2017 12:25:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cP6k0MxJcoTc4CtD2M6I0C2OU62VwNotp
Content-Type: multipart/mixed; boundary="qrHsivcgtUN68ILkIprkkJ4iCJuH3PSdb";
 protected-headers="v1"
From: Niels ten Oever 
To: "hrpc@irtf.org" 
Message-ID: <5ed90f4f-e9a0-8546-6019-424a8452e274@article19.org>
Subject: figure 2 broken in -08

--qrHsivcgtUN68ILkIprkkJ4iCJuH3PSdb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

I saw that I broke figure 2 with some indent kramdown mistakes, should
be fixed now here:
https://github.com/nllz/IRTF-HRPC/commit/091888ad88f4744866b6bed68fbe9b18=
02110f97

Will corrrect in -09.

Cheers,

Niels
--=20
Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3


--qrHsivcgtUN68ILkIprkkJ4iCJuH3PSdb--

--cP6k0MxJcoTc4CtD2M6I0C2OU62VwNotp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAliJ6r4ACgkQDtg/OkaK
yLMBbxAAkUK5gKLJpPS79gBGD2oNK8spiEMddtrLKtwVpZmHYhDR843UblfPxFne
RsbuvgORWJttXFcIYzEw74wYn/LvH39efo/qoR5anhVrV26T57dGXy2JhYSR3jPj
Leo+RN/9bhEo/t/yKXDad8+/wDpy5OyQlN3F10stu02iTqU+RVd+BdLFVysG6i2g
NUbEK5IHGkM4f6qWBvunHhcdo5i40nOAZk85dduZQ+E/RoLBo8/ICMMAUD3+DhuB
rvhO9HRT3QXbcKGwF/mWELtEe4jFbSgRhhcnagT8BolyymPN60t+ep54BqzxNdYw
v2cPHnPErrA4O3l9/navgs15QiAKddGZO53prqOJ8NPrf5lnrWKJ0qsXSPZ0/3AQ
wD9AHjLXfJvPVqBUvo9Wg5PnPkMp0UNKwxVA5QvDX5usl7sOFhkoMQcqDf+hQ5HG
QkENeqJA5XAOo5wuBeOQcEYQJA1EuwxoYumCWvYjq4xbAZVI5/kquw/mbqekydQ6
zmvjj79R0T3/XTNDczfrNZzB4ACxrxh0CmQ/lA1zaZIHazWUa00MCBPlc9Ytiwtt
CW8GqX8m0c/jwI8DcAarwNOUkxqepxYKWnz3fCO9a3UQdjcA9YWj0IP3idQLZoja
dXHJf1rwOlg41+ev5wxfQa3oa8+RCxewohxyI7+NjzunJV6SA/c=
=PcFz
-----END PGP SIGNATURE-----

--cP6k0MxJcoTc4CtD2M6I0C2OU62VwNotp--


From nobody Fri Jan 27 05:24:11 2017
Return-Path: 
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 149B9129562 for ; Fri, 27 Jan 2017 05:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.255
X-Spam-Level: 
X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no 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 242i3q3XsgWa for ; Fri, 27 Jan 2017 05:24:07 -0800 (PST)
Received: from smtprelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0164129560 for ; Fri, 27 Jan 2017 05:24:06 -0800 (PST)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id CEF9B237BC for ; Fri, 27 Jan 2017 13:24:05 +0000 (UTC)
X-Session-Marker: 6176726940646F7269612E6F7267
X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:2:41:355:379:599:800:854:967:969:973:988:989:1042:1049:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1535:1593:1594:1605:1683:1730:1747:1777:1792:1801:1963:2194:2198:2199:2200:2288:2393:2525:2553:2568:2633:2682:2685:2693:2741:2743:2771:2829:2859:2891:2892:2898:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4050:4119:4184:4250:4321:4362:4423:4425:4605:4641:4860:5007:6117:6119:7652:7903:7974:8660:8985:9010:9025:9036:9108:10848:11232:11658:11914:12043:12109:12114:12291:12295:12379:12438:12663:12683:12740:12760:12895:12926:13132:13148:13230:13231:13846:14096:14097:21060:21080:21324:21366:21433:21451:30022:30041:30046:30054:30060:30069:30070:30075:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:1:0, LF
X-HE-Tag: man05_40cd936d94346
X-Filterd-Recvd-Size: 8120
Received: from [127.0.0.1] (unknown [64.120.53.43]) (Authenticated sender: avri@doria.org) by omf06.hostedemail.com (Postfix) with ESMTPA for ; Fri, 27 Jan 2017 13:24:05 +0000 (UTC)
References: <148491253861.13304.5861309823133608940.idtracker@ietfa.amsl.com>   
To: hrpc@irtf.org
From: avri doria 
Message-ID: <7d55b812-78bb-7cc0-9d5c-e090e55b3d70@acm.org>
Date: Fri, 27 Jan 2017 08:24:03 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 170127-0, 01/27/2017), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: avri@acm.org
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2017 13:24:10 -0000

Hi,

Thanks Eliot.  I would note that we have had at least on full fledged
academic who is not one of the normal IETF/IRTF crowd review it, and she
did make some remarks about the references and how they are being used. 
I have been looking for academics and other advocacy people to review
and will continue to do so.

Thanks

avri


On 26-Jan-17 05:20, Eliot Lear wrote:
> Avri,
>
> I myself seek no more changes to the document.  I would, however, just
> ask that you take on board seeking more reviewers prior to advancing
> this work, specifically to check that references to work in fields
> outside the classic expertise of the IRTF/IETF are being appropriately
> applied.  I view this as a bare minimum test.
>
> Eliot
>
>
> On 1/25/17 9:03 PM, avri doria wrote:
>> Hi,
>>
>> Thanks for getting a revision out so quickly.  Am having trouble keeping
>> up with you and am still reading. I figure I need to reread it all as a
>> coherent piece of work.
>>
>> It would be helpful if those who had issues with the reviewed version
>> could check the diff, at minimum, to see if they are now ok with what
>> the doc says. And then let the list know.
>>
>>
>> Also want to throw out another question that has been rumbling about in
>> the back of my thoughts: is this informational or experimental RFC track?
>>
>> I think it is recommending something that can be tried experimentally
>> and is part of a research effort. On an informational, I would think it
>> was suggesting something that was no longer so speculative but was
>> information that could be used reliably without confusion, and I am not
>> sure the group thinks we are there yet.
>>
>> It may just be a quibble, but would like opinions.
>>
>> Continuing thanks to the authors and reviewers.
>>
>> avri
>>
>> from https://www.ietf.org/iesg/informational-vs-experimental.html
>>
>> 4.2.1 Experimental
>>
>> The "Experimental" designation typically denotes a specification that is
>> part of some research or development effort. Such a specification is
>> published for the general information of the Internet technical
>> community and as an archival record of the work, subject only to
>> editorial considerations and to verification that there has been
>> adequate coordination with the standards process (see below). An
>> Experimental specification may be the output of an organized Internet
>> research effort (e.g., a Research Group of the IRTF), an IETF Working
>> Group, or it may be an individual contribution.
>>
>> 4.2.2 Informational
>>
>> An "Informational" specification is published for the general
>> information of the Internet community, and does not represent an
>> Internet community consensus or recommendation. The Informational
>> designation is intended to provide for the timely publication of a very
>> broad range of responsible informational documents from many sources,
>> subject only to editorial considerations and to verification that there
>> has been adequate coordination with the standards process (see section
>>
>>
>> On 20-Jan-17 06:47, Niels ten Oever wrote:
>>> Dear all,
>>>
>>> Based on all the really great suggestions, comments and discussions
>>> we've had during and after the last call I created a new version.
>>>
>>> I would like to thank everyone for taking the time to help this draft
>>> getting better.
>>>
>>> All the best,
>>>
>>> Niels
>>>
>>>
>>>
>>> Niels ten Oever
>>> Head of Digital
>>>
>>> Article 19
>>> www.article19.org
>>>
>>> PGP fingerprint    2458 0B70 5C4A FD8A 9488
>>>                    643A 0ED8 3F3A 468A C8B3
>>>
>>> On 01/20/2017 12:42 PM, internet-drafts@ietf.org wrote:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the Human Rights Protocol Considerations of the IETF.
>>>>
>>>>         Title           : Research into Human Rights Protocol Considerations
>>>>         Authors         : Niels ten Oever
>>>>                           Corinne Cath
>>>> 	Filename        : draft-irtf-hrpc-research-08.txt
>>>> 	Pages           : 72
>>>> 	Date            : 2017-01-20
>>>>
>>>> Abstract:
>>>>    This document aims to propose guidelines for human rights
>>>>    considerations, similar to the work done on the guidelines for
>>>>    privacy considerations [RFC6973].  This is achieved by providing a
>>>>    proposal for a vocabulary to discuss the relation between human
>>>>    rights and Internet protocols, an overview of the discussion in
>>>>    technical and academic literature and communities, a proposal for the
>>>>    mapping of the relation between human rights and technical concepts,
>>>>    as well as guidelines.
>>>>
>>>>    If you want to see how to apply this work to your own, you can
>>>>    directly go to Section 6.  The rest of the document explains the
>>>>    background of the guidelines and how they were developed.
>>>>
>>>>    This document is not an Internet Standards Track specification; it is
>>>>    published for informational purposes.
>>>>
>>>>    This document is a product of the Internet Research Task Force
>>>>    (IRTF).  The IRTF publishes the results of Internet-related research
>>>>    and development activities.  This documents aims to be a consensus
>>>>    document of the Human Rights Protocol Consideration Research Group of
>>>>    the Internet Research Task Force (IRTF).
>>>>
>>>>    Discussion of this draft at: hrpc@irtf.org //
>>>>    https://www.irtf.org/mailman/listinfo/hrpc
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/
>>>>
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-irtf-hrpc-research-08
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-research-08
>>>>
>>>>
>>>> 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.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> hrpc mailing list
>>>> hrpc@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From nobody Fri Jan 27 07:28:30 2017
Return-Path: 
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 D45581295FC for ; Fri, 27 Jan 2017 07:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Level: 
X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=Qn/axM8d; dkim=pass (1024-bit key) header.d=elandsys.com header.b=yaFaFVn9
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 vg1kFZd_nCoN for ; Fri, 27 Jan 2017 07:28:28 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC121295FB for ; Fri, 27 Jan 2017 07:28:27 -0800 (PST)
Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0RFSA3p020360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2017 07:28:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1485530895; x=1485617295; bh=f2QbGDt1DKvVPB3Cde/2oo9p8h6YscrlWsBx6OQftTs=; h=Date:To:From:Subject:Cc; b=Qn/axM8dqobauhGVKePzVo2hwngZU0//ysiBQXOat/SS041g7VQBxpsQ79TzBrzLx fZLkpSoaMqSmWLw6EfxZ2iS3HvBHzYE/7hOFJ9T7WnF2mWYyT/gaZHZed6FA3Afn4g CeK9u2UNLoDFgngkOGZxXc0ZNPEGv3XS81VsVfnE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1485530895; x=1485617295; i=@elandsys.com; bh=f2QbGDt1DKvVPB3Cde/2oo9p8h6YscrlWsBx6OQftTs=; h=Date:To:From:Subject:Cc; b=yaFaFVn94+zmYXZ0IgMTAi4m0XVDwWw97WX2Ctab3paQbkGWG1yXpQyR7up3PI6Gi 262vFPTTsHxSIxKGsbzTSjqa7Vwfm7UbtyCkb435XsR2gEr5CKN66K/eRAmmVpgPDv DWvnVZCcxAlTjVG6wmw5lkmKEqzvbVhPoVgU78v0=
Message-Id: <6.2.5.6.2.20170127071631.0aff49a8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 27 Jan 2017 07:27:22 -0800
To: avri doria 
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-08.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2017 15:28:29 -0000

Hi Avri,

>Also want to throw out another question that has been rumbling about in
>the back of my thoughts: is this informational or experimental RFC track?
>
>I think it is recommending something that can be tried experimentally
>and is part of a research effort. On an informational, I would think it
>was suggesting something that was no longer so speculative but was
>information that could be used reliably without confusion, and I am not
>sure the group thinks we are there yet.

I would look at "Experimental" v/s "Informational" in terms of future 
standardization of a protocol.  The document is not about a 
protocol.  As such, "Informational" is a better fit.  There isn't a 
RFC track; the document is intended for publication in the IRTF Stream.

Regards,
S. Moonesamy