From nobody Sun Sep 18 08:50:16 2016 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 94F5312B109 for ; Sun, 18 Sep 2016 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 lBLkS_OglRQo for ; Sun, 18 Sep 2016 08:50:14 -0700 (PDT) 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 901D512B03F for ; Sun, 18 Sep 2016 08:50:14 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CB668280109; Sun, 18 Sep 2016 17:50:12 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id C56AD280107; Sun, 18 Sep 2016 17:50:12 +0200 (CEST) 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 C38FEB3800C; Sun, 18 Sep 2016 17:49:42 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id BACA6402C6; Sun, 18 Sep 2016 17:49:42 +0200 (CEST) Date: Sun, 18 Sep 2016 17:49:42 +0200 From: Stephane Bortzmeyer To: Joseph Lorenzo Hall Message-ID: <20160918154942.ymir3kiph65jplgk@nic.fr> References: <147233472292.3325.465914304898428105.idtracker@ietfa.amsl.com> <8d99c782-e84a-1971-aef4-e3ef80205653@article19.org> 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.6.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/ (1.7.0) Archived-At: Cc: Avri Doria , hrpc@irtf.org Subject: Re: [hrpc] I-D Action: draft-tenoever-hrpc-research-05.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: Sun, 18 Sep 2016 15:50:15 -0000 On Wed, Aug 31, 2016 at 12:11:09PM -0400, Joseph Lorenzo Hall wrote a message of 180 lines which said: > Great, two weeks sounds fine. > > (We've had a number of full reviews, so it should be in good shape for that.) What happened since? Was there a RG Last Call or not? (I'm awfully late for my review.) From nobody Sun Sep 18 09:18:12 2016 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 3139412B122 for ; Sun, 18 Sep 2016 09:18:11 -0700 (PDT) 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 arVfi4ecnlKI for ; Sun, 18 Sep 2016 09:18:09 -0700 (PDT) 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 8EC42127A91 for ; Sun, 18 Sep 2016 09:18:09 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 499CA31CA6; Sun, 18 Sep 2016 18:18:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 2DBAA190650; Sun, 18 Sep 2016 18:15:01 +0200 (CEST) Date: Sun, 18 Sep 2016 18:15:01 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20160918161501.GA7539@sources.org> References: <20160724162909.GA1086@sources.org> <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] A review of draft-tenoever-hrpc-research-04.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: Sun, 18 Sep 2016 16:18:11 -0000 On Fri, Jul 29, 2016 at 12:16:14PM +0200, Niels ten Oever wrote a message of 219 lines which said: > > Last important point, when rereading the evaluation of XMPP in > > 5.2.6, I cannot help thinking it is technically correct but it may > > make people consider that the XMPP authors were working for the > > NSA or the FSB, trying very hard to break human rights in the > > protocol. May be adding something that these evaluations are done > > on the basis of HR influence, and that the engineers who built > > these protocols had many other issues, and many trade-offs to > > consider (in the case of XMPP, the use of the servers, which has a > > lot of consequences for HR, is because user's machines are not > > reachable 100 % of the time.) > > Sure! We don't want to lambast XMPP, but simply show how hard it is. > Would you like to offer text? A proposal to add at the end of 5.2.2.1 (stored in ): 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. For instance, relying on an external server can be bad for freedom of speech (it creates one more control point, where censorship could be applied) but it may be a necessity if the endpoints are not connected and reachable permanently. 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. From nobody Sun Sep 18 09:33:10 2016 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 DCE9A12B134 for ; Sun, 18 Sep 2016 09:33:08 -0700 (PDT) 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 WKTIxFBPfrsM for ; Sun, 18 Sep 2016 09:33:08 -0700 (PDT) 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 E2ABB12B09C for ; Sun, 18 Sep 2016 09:33:07 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 87E7531CA6; Sun, 18 Sep 2016 18:33:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id D80E0190650; Sun, 18 Sep 2016 18:28:26 +0200 (CEST) Date: Sun, 18 Sep 2016 18:28:26 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160918162826.GA8851@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [hrpc] Sloppy use of "centralized" in draft-research 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, 18 Sep 2016 16:33:09 -0000 In version -05, section 5.2.4, I read: > The DNS is centralized, and this brings up political and social > concerns over control. This is not a correct assessment. If the DNS were really centralized, each time I want to add/modify something in bortzmeyer.org, I would have to ask to the Center. (This was true of the previous system, HOSTS.TXT, described in RFC 608.) I suggest instead: > The DNS is organized as a rooted tree, and this brings up political > and social concerns over control. From nobody Sun Sep 18 09:38:10 2016 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 58A6F12B139 for ; Sun, 18 Sep 2016 09:38:09 -0700 (PDT) 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 mzB_kIq5EwNT for ; Sun, 18 Sep 2016 09:38:08 -0700 (PDT) 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 0DD0912B134 for ; Sun, 18 Sep 2016 09:38:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A413631CA6; Sun, 18 Sep 2016 18:38:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 07A2C190650; Sun, 18 Sep 2016 18:33:25 +0200 (CEST) Date: Sun, 18 Sep 2016 18:33:25 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20160918163325.GB7539@sources.org> References: <20160724162909.GA1086@sources.org> <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] A review of draft-tenoever-hrpc-research-04.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: Sun, 18 Sep 2016 16:38:09 -0000 On Fri, Jul 29, 2016 at 12:16:14PM +0200, Niels ten Oever wrote a message of 219 lines which said: > > Another issue (which is not easy to solve) is the mention of > > Namecoin in 5.2.4.1. The current text is technically correct but > > may give the impression that Namecoin has only strengths, not > > weaknesses, and that we endorse its use. I know it is not the case > > but I do not like the current text, not because of what it says, > > but because of what it omits. It claims "there is no technical > > auditing for name ownership [in the DNS]" which is true but > > forgets to add that, in Namecoin, there is a public ledger of > > changes, but based only on the possession of a cryptographic > > key. If your machine is infected with malware, you may lose your > > Namecoin name and there is no audit or recourse for that (the > > ledger will only show "legitimate" changes.) > > > > So, mentioning alternative techniques is a good idea, to > > illustrate a point, but we must be careful to add that it is not a > > fair comparison. > > > > Sure, can you offer some text for this? I suggest (see ): Speaking of alternative techniques, this is not a complete comparison of DNS with Namecoin: the later has its own problems and limitations. The idea here is to show that there are several possible choices, and they have consequences for human rights. From nobody Sun Sep 18 09:43:10 2016 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 82E6C12B140 for ; Sun, 18 Sep 2016 09:43:09 -0700 (PDT) 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 Z3xhkTv1HRu6 for ; Sun, 18 Sep 2016 09:43:08 -0700 (PDT) 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 585BD12B13B for ; Sun, 18 Sep 2016 09:43:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id D5B6331CA6; Sun, 18 Sep 2016 18:43:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id E51F9190650; Sun, 18 Sep 2016 18:42:19 +0200 (CEST) Date: Sun, 18 Sep 2016 18:42:19 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160918164219.GC7539@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [hrpc] Turkey and draft-tenoever-hrpc-research-05 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, 18 Sep 2016 16:43:09 -0000 The current text says (section 5.2.4.2) that DPI is used to modify DNS answers in Turkey. There is no evidence of that (specially in the mentioned article), quite the contrary: during recent censorship events in Turkey, switching to an alternative resolver worked, proving there was no DPI (another trick used was route hijacking, see presentation at RIPE ) I suggest to rewrite as : > all DNS protocol messages are inspected by the network, and > objectionable content is distorted, as in China. [China replacing Turkey] See and for previous remarks about Turkey. From nobody Sun Sep 18 09:51:22 2016 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 9B78412B145 for ; Sun, 18 Sep 2016 09:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ekus9JQLnQWB for ; Sun, 18 Sep 2016 09:51:20 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DC712B142 for ; Sun, 18 Sep 2016 09:51:20 -0700 (PDT) Received: from filter.hostedemail.com (unknown [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id F18CF9EA15 for ; Sun, 18 Sep 2016 16:51:18 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:355:379:599:854:967:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1513:1515:1516:1518:1521:1534:1540:1593:1594:1683:1711:1719:1730:1747:1777:1792:2198:2199:2393:2525:2553:2561:2564:2682:2685:2859:2909:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3352:3673:3865:3866:3867:3868:3870:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:4362:4425:5007:6119:7652:7903:8660:8985:9025:10004:10400:10848:11232:11658:11914:12043:12050:12109:12114:12438:12663:12740:13019:13069:13071:13148:13160:13161:13229:13230:13311:13357:13845:14096:14097:14180:14181:14721:14764:14777:21060:21080:21366:21433:30016:30022:30054:30083, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:error, Custom_rules:0:0:0, LFtime:2000, LUA_SUMMARY:none X-HE-Tag: talk55_4513faee6642d X-Filterd-Recvd-Size: 2289 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 omf05.hostedemail.com (Postfix) with ESMTPA for ; Sun, 18 Sep 2016 16:51:14 +0000 (UTC) References: <147233472292.3325.465914304898428105.idtracker@ietfa.amsl.com> <8d99c782-e84a-1971-aef4-e3ef80205653@article19.org> <20160918154942.ymir3kiph65jplgk@nic.fr> To: hrpc@irtf.org From: avri doria Message-ID: <50090d35-8d21-f7fb-1c59-47cb2c0ab0da@acm.org> Date: Sun, 18 Sep 2016 12:51:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160918154942.ymir3kiph65jplgk@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 160918-0, 09/18/2016), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] I-D Action: draft-tenoever-hrpc-research-05.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: Sun, 18 Sep 2016 16:51:21 -0000 Hi, The last call has not happened yet. I just finished a review last week but am still in discussion with the authors about how to proceed. My review was most all editorial and can be found at: https://drive.google.com/file/d/0B4C745NEsGNqR0FFaS12SUhYZEE/view?usp=3Dsha= ring One thing, I was assuming that silence on the current version meant there were no open issues, though I do plan to confirm that before starting the last call. If you still have comments, please do send them. I am also considering asking for a 4 week last call so we can try to include a wider review group, including HR experts and researchers who might not be part of this research group. thanks avri On 18-Sep-16 11:49, Stephane Bortzmeyer wrote: > What happened since? Was there a RG Last Call or not? (I'm awfully > late for my review.) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Sun Sep 18 09:53:12 2016 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 049DB12B140 for ; Sun, 18 Sep 2016 09:53:11 -0700 (PDT) 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 ra5qWgdsrlUp for ; Sun, 18 Sep 2016 09:53:09 -0700 (PDT) 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 C500712B13B for ; Sun, 18 Sep 2016 09:53:09 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 2D36231CA6; Sun, 18 Sep 2016 18:53:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 2BDAB190650; Sun, 18 Sep 2016 18:52:51 +0200 (CEST) Date: Sun, 18 Sep 2016 18:52:51 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20160918165251.GD7539@sources.org> References: <20160724162909.GA1086@sources.org> <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] A review of draft-tenoever-hrpc-research-04.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: Sun, 18 Sep 2016 16:53:11 -0000 On Fri, Jul 29, 2016 at 12:16:14PM +0200, Niels ten Oever wrote a message of 219 lines which said: > > 5.2.5.1 : HSTS and certificate pinning are mentioned as solutions > > against TLS stripping but not DANE (RFC 6698). Why? > > > > Let's add DANE, stupid to have not mentioned it. PR ? Done in but I cannot submit a PR (there is another one pending before). From nobody Sun Sep 18 12:03:12 2016 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 22EF512B068 for ; Sun, 18 Sep 2016 12:03:11 -0700 (PDT) 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 lPp0nP8HLkeD for ; Sun, 18 Sep 2016 12:03:09 -0700 (PDT) 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 D669B12B02B for ; Sun, 18 Sep 2016 12:03:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 58B5231CA6; Sun, 18 Sep 2016 21:03:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 3ADAD190650; Sun, 18 Sep 2016 20:59:17 +0200 (CEST) Date: Sun, 18 Sep 2016 20:59:17 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20160918185917.GE7539@sources.org> References: <20160724162909.GA1086@sources.org> <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: [hrpc] A definition of public space (Was: A review of draft-tenoever-hrpc-research-04.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: Sun, 18 Sep 2016 19:03:11 -0000 On Fri, Jul 29, 2016 at 12:16:14PM +0200, Niels ten Oever wrote a message of 219 lines which said: > > 5.2.11 : the end of the section is quite sudden. It regrets the > > lack of a "de facto public space" but does not explain what it is > > (the concept of "public space", where free speech and > > demonstrations are possible, is not introduced anywhere). [Same problem in -05] > We used to have much more text here, you can see it here: The definition is not too bad (the final rant against IETF is quite wrong, the IETF, for good or for bad, is certainly not responsible of all of what is the Internet). May be keep only: > Collectively, we have allowed the construction of an entire public > sphere, the Internet, which by accidents of evolution and design, > has none of the inherent free speech guarantees we have come to > expect. Dissenting voices are pushed out of the paths of potential > audiences, effectively removing them from the public > discourse. There is nowhere online for an activist to stand with her > friends and her sign. She might set up a dedicated blog—which may or > may not ever be read—but it is much harder for her to stand > collectively with others against a corporate giant in the online > space. Although the Internet is often compared to public space, it > is not. Rather the opposite. The Internet is almost entirely owned > by private entities. But I have another, milder, suggestion (), which, I believe, does not change the current consensus on DDoS attacks: Some people may say that DDoS attacks are the only mean to be heard, in the current Internet. It is true that Internet has no "public space", a place where everyone can go and protest and raise issues in front of everyone. The Internet, and specially the Web, is a more a series of commercial malls, hold by private entities and where free speech is limited. This is a complicated issue for human rights, and specially freedom of speech, but it does not mean that DDoS are a solution to this real problem. From nobody Sun Sep 18 12:28:11 2016 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 BB8CE12B00D for ; Sun, 18 Sep 2016 12:28:09 -0700 (PDT) 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 qSACZ5ZVB26B for ; Sun, 18 Sep 2016 12:28:08 -0700 (PDT) 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 9F1BD12B0BE for ; Sun, 18 Sep 2016 12:28:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 234C331CA7; Sun, 18 Sep 2016 21:28:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 8D22D190650; Sun, 18 Sep 2016 21:26:47 +0200 (CEST) Date: Sun, 18 Sep 2016 21:26:47 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160918192647.GA26129@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [hrpc] Sorting encryption/DDoS issue in draft-tenoever-hrpc-research-05 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, 18 Sep 2016 19:28:09 -0000 I suggest to change a part of section 5.2.11 ("DDoS attacks") as in . I fail to see the relationship between DDoS (the subject of the section) and encryption / passive surveillance. I suggest to delete everything related to HTTPS. From nobody Sun Sep 18 12:33:11 2016 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 D728A12B0BE for ; Sun, 18 Sep 2016 12:33:10 -0700 (PDT) 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 vkzpE-2v-cWI for ; Sun, 18 Sep 2016 12:33:10 -0700 (PDT) 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 E4AA212B091 for ; Sun, 18 Sep 2016 12:33:09 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3516F31CA6; Sun, 18 Sep 2016 21:33:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 5E679190650; Sun, 18 Sep 2016 21:33:00 +0200 (CEST) Date: Sun, 18 Sep 2016 21:33:00 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160918193300.GA27226@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [hrpc] A question on HTTP status code 451 in draft-tenoever-hrpc-research-05 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, 18 Sep 2016 19:33:11 -0000 I do not understand this sentence in section 5.2.9: > The major use case is thus clearly on the Web server itself, not the > network. It seems to me the opposite: 451 is probably used by proxies. If the origin Web site wants to comply with censorship, they just have to remove content. (Sections 3 and 4 of RFC 7725 are clear about that.) From nobody Sun Sep 18 12:33:20 2016 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 2333312B0D4 for ; Sun, 18 Sep 2016 12:33:12 -0700 (PDT) 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 1PbDr_Zc6T4S for ; Sun, 18 Sep 2016 12:33:10 -0700 (PDT) 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 E140112B00D for ; Sun, 18 Sep 2016 12:33:09 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3A90431CA7; Sun, 18 Sep 2016 21:33:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 022AC190650; Sun, 18 Sep 2016 21:32:25 +0200 (CEST) Date: Sun, 18 Sep 2016 21:32:25 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160918193225.GA26233@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [hrpc] A question about UTF-8 in draft-tenoever-hrpc-research-05 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, 18 Sep 2016 19:33:12 -0000 Ins ection 5.3.2.1.5, there is an advice to protocol developers, phrased as a question: > Question(s): Does your protocol have text strings that are readable > or entered by humans? Does your protocol allow Unicode encoded in > UTF-8 only, thereby shifting conversion issues away from individual > choices? Did you have a look at [RFC6365]? It took me some time to be sure that "allowing Unicode in UTF-8 only" was regarded as the best practice ("shifting away from individual choices" seemed a fascist decision at first). Why not rewriting it: Does your protocol have text strings that are readable or entered by humans? Does your protocol allow Unicode encoded in UTF-8 only, thereby preventing any conversion issues? If other character sets / encodings are allowed, does your protocol mandates a proper tagging of the charset? Did you have a look at [RFC6365]? From nobody Sun Sep 18 12:43:09 2016 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 1E2B512B0BE for ; Sun, 18 Sep 2016 12:43:09 -0700 (PDT) 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 DdNm4lyolQXe for ; Sun, 18 Sep 2016 12:43:08 -0700 (PDT) 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 1BA6D12B00D for ; Sun, 18 Sep 2016 12:43:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A57E731CA6; Sun, 18 Sep 2016 21:43:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 1A67F190650; Sun, 18 Sep 2016 21:38:30 +0200 (CEST) Date: Sun, 18 Sep 2016 21:38:30 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160918193829.GA27308@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [hrpc] Patents in draft-tenoever-hrpc-research-05 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, 18 Sep 2016 19:43:09 -0000 Section 5.3.2.1.7 says: > Are you aware of any patents that would prevent your standard from > being fully implemented? First, this is already covered in length in other IETF documents (RFC 3979, RFC 6701, etc) note wells and things like that. And it is well implemented by the tools we use, such as the datatracker. IMHO, we could simply drop this sentence: the average RFC author is already well aware there are issus with patents. If we insist on keeping it, I would disagree with it because it seems to imply we should not standardize patented technologies. If so, we would standardize nothing: almost every sensible algorithm is patented. Most (all?) software patents are futile and groundless (not to mention the fact they are valid only in some countries). If we take them at face value, we would tie our hands. From nobody Sun Sep 18 22:01:30 2016 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 4E82512B037 for ; Sun, 18 Sep 2016 22:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 r_QaSdij0QgA for ; Sun, 18 Sep 2016 22:01:27 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379BE12B008 for ; Sun, 18 Sep 2016 22:01:26 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 09CCC16401D; Mon, 19 Sep 2016 05:01:25 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id DED0781A5; Mon, 19 Sep 2016 05:01:24 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id C010C2400BC; Mon, 19 Sep 2016 05:01:24 +0000 (UTC) To: Stephane Bortzmeyer References: <20160724162909.GA1086@sources.org> <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> <20160918163325.GB7539@sources.org> From: Niels ten Oever Message-ID: <46fe6b30-2193-020d-3431-836e9d342262@article19.org> Date: Mon, 19 Sep 2016 17:01:23 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918163325.GB7539@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A6mmpVFQTXC6nKVT433PCFwtblFqrcVUe" Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] A review of draft-tenoever-hrpc-research-04.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: Mon, 19 Sep 2016 05:01:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A6mmpVFQTXC6nKVT433PCFwtblFqrcVUe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Accepted, with small grammar changes, Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 04:33 AM, Stephane Bortzmeyer wrote: > On Fri, Jul 29, 2016 at 12:16:14PM +0200, > Niels ten Oever wrote=20 > a message of 219 lines which said: >=20 >>> Another issue (which is not easy to solve) is the mention of >>> Namecoin in 5.2.4.1. The current text is technically correct but >>> may give the impression that Namecoin has only strengths, not >>> weaknesses, and that we endorse its use. I know it is not the case >>> but I do not like the current text, not because of what it says, >>> but because of what it omits. It claims "there is no technical >>> auditing for name ownership [in the DNS]" which is true but >>> forgets to add that, in Namecoin, there is a public ledger of >>> changes, but based only on the possession of a cryptographic >>> key. If your machine is infected with malware, you may lose your >>> Namecoin name and there is no audit or recourse for that (the >>> ledger will only show "legitimate" changes.) >>> >>> So, mentioning alternative techniques is a good idea, to >>> illustrate a point, but we must be careful to add that it is not a >>> fair comparison. >>> >> >> Sure, can you offer some text for this? >=20 > I suggest (see > ): >=20 > Speaking of alternative techniques, this is not a complete comparison > of DNS with Namecoin: the later has its own problems and > limitations. The idea here is to show that there are several possible > choices, and they have consequences for human rights. >=20 --A6mmpVFQTXC6nKVT433PCFwtblFqrcVUe 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 iQEcBAEBCAAGBQJX33EkAAoJEAi1oPJjbWjpOIwH/34I3sVGavbW18h9pv+6xLi0 DlcnTMUrD+m7uykgHchbVZTmWv1OcdFYCUARfdbbmXinzFscKwq6gRLBno+Wj+Lb Le5YUxv1q4Yhdfk9EOsJPvMwF6+25E+omugPEHIipMiTQtOrW6LIQ/b0wZCm4I+9 HxKlpLreNItwEbyGAB2bXDEf21V9VOTRRdxmfE2KD59VtNkYmfDQpu6z02Mjjx9u 0GvApoiVZIZPNWoLBXLFPxEtrrxjA8vFryUGpGAJ6ZmlwxDGmT0K1ylTUo/9xJY2 E1H9+qbzRnsiocRRPm1Cm0dMZ2Ki2qAPA2Efv49yDEVavqfgVzB9Owjw/d9xnmc= =13je -----END PGP SIGNATURE----- --A6mmpVFQTXC6nKVT433PCFwtblFqrcVUe-- From nobody Sun Sep 18 22:01:52 2016 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 9AB7712B121 for ; Sun, 18 Sep 2016 22:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 X9GZb3p632HI for ; Sun, 18 Sep 2016 22:01:49 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C4F12B008 for ; Sun, 18 Sep 2016 22:01:49 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5AA3481A5; Mon, 19 Sep 2016 05:01:48 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 4A82E2400BC; Mon, 19 Sep 2016 05:01:48 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 3DE2318858B; Mon, 19 Sep 2016 05:01:48 +0000 (UTC) To: Stephane Bortzmeyer References: <20160724162909.GA1086@sources.org> <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> <20160918165251.GD7539@sources.org> From: Niels ten Oever Message-ID: Date: Mon, 19 Sep 2016 17:01:47 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918165251.GD7539@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jSOCTnesCUKE3bKbJW9QhOmU4KoT78bRJ" Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] A review of draft-tenoever-hrpc-research-04.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: Mon, 19 Sep 2016 05:01:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jSOCTnesCUKE3bKbJW9QhOmU4KoT78bRJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Accepted Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 04:52 AM, Stephane Bortzmeyer wrote: > On Fri, Jul 29, 2016 at 12:16:14PM +0200, > Niels ten Oever wrote=20 > a message of 219 lines which said: >=20 >>> 5.2.5.1 : HSTS and certificate pinning are mentioned as solutions >>> against TLS stripping but not DANE (RFC 6698). Why? >>> >> >> Let's add DANE, stupid to have not mentioned it. PR ? >=20 > Done in > > but I cannot submit a PR (there is another one pending before). >=20 --jSOCTnesCUKE3bKbJW9QhOmU4KoT78bRJ 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 iQEcBAEBCAAGBQJX33E7AAoJEAi1oPJjbWjpNpAH/jrD61Teq1H5DugV5CaNismy l1MyQ6neB31J5Ut3/7c5nhj4utuhUErtEWM+tOFx5ThrQvzRa2ESVak8++COzSWb 9/5/32QuqgPTkQSYBGN2Li0Q3Jr0Kz/cum+n3G23hqzwGKcJOJ4lCTAFwFy1g0VK 5K8VQM+2jI0A1Ir4E0zbqDsq9/+AP+ruMDf06vS52ok3lGJ2WajXAWkGW7me48Ra yWuMey+5aDrDwJg1LpYU23LhWQZ+mm/8fstWSCUfxOKHcJJ5ybOAjnQvyC3LJgOd GiM6sfs5t+KzrQi4MteZQtJrxGx1ImHZkIXnywcRtUAofQxxBvWEYHf5Dh5Bn2U= =LTpU -----END PGP SIGNATURE----- --jSOCTnesCUKE3bKbJW9QhOmU4KoT78bRJ-- From nobody Sun Sep 18 22:06:55 2016 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 0AD0812B037 for ; Sun, 18 Sep 2016 22:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 5AW5LAUjPzXU for ; Sun, 18 Sep 2016 22:06:53 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E728412B0DB for ; Sun, 18 Sep 2016 22:06:52 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id AE91116401D for ; Mon, 19 Sep 2016 05:06:51 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 8F4CD18858B for ; Mon, 19 Sep 2016 05:06:51 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 7552116401D for ; Mon, 19 Sep 2016 05:06:51 +0000 (UTC) To: hrpc@irtf.org References: <20160918193300.GA27226@sources.org> From: Niels ten Oever Message-ID: <9492270e-2261-b0f7-2173-d8fc5de21615@article19.org> Date: Mon, 19 Sep 2016 17:06:50 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918193300.GA27226@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KR4xqBEpRSgwErEepKgtWV1nuQnRVWSLp" Archived-At: Subject: Re: [hrpc] A question on HTTP status code 451 in draft-tenoever-hrpc-research-05 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, 19 Sep 2016 05:06:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KR4xqBEpRSgwErEepKgtWV1nuQnRVWSLp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed, sentence removed. Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 07:33 AM, Stephane Bortzmeyer wrote: > I do not understand this sentence in section 5.2.9: >=20 >> The major use case is thus clearly on the Web server itself, not the >> network. >=20 > It seems to me the opposite: 451 is probably used by proxies. If the > origin Web site wants to comply with censorship, they just have to > remove content. (Sections 3 and 4 of RFC 7725 are clear about that.) >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --KR4xqBEpRSgwErEepKgtWV1nuQnRVWSLp 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 iQEcBAEBCAAGBQJX33JqAAoJEAi1oPJjbWjpBWgH/30tps4/4IBl9bofppTiQlSG +wezjUyQ4Vwh4Sl5z5ofIs6sMaM1mUWYSA9jfiyQuVs8/V0TAK34ws7RfkRk3L6c 9wAZY423hFg0Y1+C6hpWDqvVyJuMkwQS5ey75WAHvEfL+83eR6aYJ9cYRvNinT52 7nT3raEWteTCMYQaGLaapBRCv2xtsjA0udHTsUVPDrXsDe0L1ElBXTLTh2FtFZJF W7ApFPZQuzKzhwa2iK+MD8LYJNFybZAQ21MmBY465JGkfKOs+G2W2PUh2vn1aX43 tZRXNW3roCPXkdFjsFBe4EHj38BhW0MJLogBUbE9k++osqrZl2JWLWJQutAEBZE= =Xc1G -----END PGP SIGNATURE----- --KR4xqBEpRSgwErEepKgtWV1nuQnRVWSLp-- From nobody Sun Sep 18 22:08:16 2016 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 8CDED12B037 for ; Sun, 18 Sep 2016 22:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 v_4n-koFISQf for ; Sun, 18 Sep 2016 22:08:13 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3C112B0DB for ; Sun, 18 Sep 2016 22:08:13 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 7825016401D for ; Mon, 19 Sep 2016 05:08:12 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 6AB8118858B for ; Mon, 19 Sep 2016 05:08:12 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 5F8F116401D for ; Mon, 19 Sep 2016 05:08:12 +0000 (UTC) To: hrpc@irtf.org References: <20160918193225.GA26233@sources.org> From: Niels ten Oever Message-ID: Date: Mon, 19 Sep 2016 17:08:11 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918193225.GA26233@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ix4A7jxoxp498o7LC5BfoUDKQUqmtWoWL" Archived-At: Subject: Re: [hrpc] A question about UTF-8 in draft-tenoever-hrpc-research-05 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, 19 Sep 2016 05:08:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ix4A7jxoxp498o7LC5BfoUDKQUqmtWoWL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed. Added. Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 07:32 AM, Stephane Bortzmeyer wrote: > Ins ection 5.3.2.1.5, there is an advice to protocol developers, > phrased as a question: >=20 >> Question(s): Does your protocol have text strings that are readable >> or entered by humans? Does your protocol allow Unicode encoded in >> UTF-8 only, thereby shifting conversion issues away from individual >> choices? Did you have a look at [RFC6365]? >=20 > It took me some time to be sure that "allowing Unicode in UTF-8 only" > was regarded as the best practice ("shifting away from individual > choices" seemed a fascist decision at first). Why not rewriting it: >=20 > Does your protocol have text strings that are readable or entered by > humans? Does your protocol allow Unicode encoded in UTF-8 only, > thereby preventing any conversion issues? If other character sets / > encodings are allowed, does your protocol mandates a proper tagging of > the charset? Did you have a look at [RFC6365]? >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --Ix4A7jxoxp498o7LC5BfoUDKQUqmtWoWL 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 iQEcBAEBCAAGBQJX33K8AAoJEAi1oPJjbWjpLkQH/jw6GwnCgizODo4TIaT/WBQ/ dcAa2isPJbpiyFLSCFdfQ6QvdPYYmzxSeokmIRv59rN7NO2b2zDxqapmPXswrVRi CeuD0FGmRuetQChpNnPRVzcnujvXpc8ip6BMG8q/8IopqEj1xLyB4tP+9v/7C804 fquYD7l/jrpOdKy03kQBPbugJtWHyU/SzxEFbcD63Bkpij/GBgkf39q64AarEsiR B3c3ShtlUx6g9BbG6XjpuErOttK0sg/0ddXnSCu6qKD8KOSAtDu83ztxPplmhhvK 4LMVfjtdRYUe66mwlgvlTWZ80WJ5Me6h4x3QumUmDYuJJEwM1YdZnpt3z1DJE5Q= =7lWj -----END PGP SIGNATURE----- --Ix4A7jxoxp498o7LC5BfoUDKQUqmtWoWL-- From nobody Sun Sep 18 22:08:34 2016 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 D7B8712B0DB for ; Sun, 18 Sep 2016 22:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 EoJUI5xTxOMW for ; Sun, 18 Sep 2016 22:08:32 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0705912B008 for ; Sun, 18 Sep 2016 22:08:32 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id CE7BB16401D for ; Mon, 19 Sep 2016 05:08:30 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id BFCD218858B for ; Mon, 19 Sep 2016 05:08:30 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id B48D716401D for ; Mon, 19 Sep 2016 05:08:30 +0000 (UTC) To: hrpc@irtf.org References: <20160918192647.GA26129@sources.org> From: Niels ten Oever Message-ID: Date: Mon, 19 Sep 2016 17:08:30 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918192647.GA26129@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UowaR48mA9gKJxFb20lERlrbLXaQ0K5OR" Archived-At: Subject: Re: [hrpc] Sorting encryption/DDoS issue in draft-tenoever-hrpc-research-05 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, 19 Sep 2016 05:08:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UowaR48mA9gKJxFb20lERlrbLXaQ0K5OR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed, accepted. Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 07:26 AM, Stephane Bortzmeyer wrote: >=20 > I suggest to change a part of section 5.2.11 ("DDoS attacks") as in > . I > fail to see the relationship between DDoS (the subject of the section) > and encryption / passive surveillance. I suggest to delete everything > related to HTTPS. >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --UowaR48mA9gKJxFb20lERlrbLXaQ0K5OR 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 iQEcBAEBCAAGBQJX33LOAAoJEAi1oPJjbWjp+dwH/i8Kmhkrifd5/dflbp3OdE+2 AW3K2lGgCe1yGgGEhLVZRx3rgGsfJ+8B0RI6fh6AZn3ojZElvP5LnGoIxn5VdR1t 7Z/C+u/BlQw6n5Y/rhJe91VFcI6ZN7LtVjBHCxQf3CseN0IANCvphlz8mlyGHc6R 5I4RAALmJkAwsj2Tk2leTUL1oSzch1P+/4yPZFMmO/XO2ME5kMOzDQdiYF4AwzAE UmmBDmU2ImWkV0dAHPZz60Z/WIfXfEPdwvsdR+FQIs9AeBXrXqNgTJnKChmgiMNv 4cLeKBI+U7dSwYoc2O8fx5nsQcSOiozaLB5mDudey7sI22Bq8C6fjHIhO8yRBMM= =B1DK -----END PGP SIGNATURE----- --UowaR48mA9gKJxFb20lERlrbLXaQ0K5OR-- From nobody Sun Sep 18 22:09:44 2016 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 6F27512B037 for ; Sun, 18 Sep 2016 22:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 wVfR0-QYaGwD for ; Sun, 18 Sep 2016 22:09:42 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2A412B008 for ; Sun, 18 Sep 2016 22:09:42 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 6C3D32400BC; Mon, 19 Sep 2016 05:02:03 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5C13181A5; Mon, 19 Sep 2016 05:02:03 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 4E1C92400BC; Mon, 19 Sep 2016 05:02:03 +0000 (UTC) To: Stephane Bortzmeyer References: <20160724162909.GA1086@sources.org> <4ad1257c-6e53-592b-19f5-b9eda45d8bbe@article19.org> <20160918185917.GE7539@sources.org> From: Niels ten Oever Message-ID: <9fb377ea-c9c3-10e6-01ee-29802b352924@article19.org> Date: Mon, 19 Sep 2016 17:02:02 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918185917.GE7539@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jVQXIS2KS1SCPDRSIdLTFIqMgHCDgaLDh" Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] A definition of public space (Was: A review of draft-tenoever-hrpc-research-04.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: Mon, 19 Sep 2016 05:09:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jVQXIS2KS1SCPDRSIdLTFIqMgHCDgaLDh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Accepted Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 06:59 AM, Stephane Bortzmeyer wrote: > On Fri, Jul 29, 2016 at 12:16:14PM +0200, > Niels ten Oever wrote=20 > a message of 219 lines which said: >=20 >>> 5.2.11 : the end of the section is quite sudden. It regrets the >>> lack of a "de facto public space" but does not explain what it is >>> (the concept of "public space", where free speech and >>> demonstrations are possible, is not introduced anywhere). >=20 > [Same problem in -05] > =20 >> We used to have much more text here, you can see it here: >=20 > The definition is not too bad (the final rant against IETF is quite > wrong, the IETF, for good or for bad, is certainly not responsible of > all of what is the Internet). May be keep only: >=20 >> Collectively, we have allowed the construction of an entire public >> sphere, the Internet, which by accidents of evolution and design, >> has none of the inherent free speech guarantees we have come to >> expect. Dissenting voices are pushed out of the paths of potential >> audiences, effectively removing them from the public >> discourse. There is nowhere online for an activist to stand with her >> friends and her sign. She might set up a dedicated blog=E2=80=94which = may or >> may not ever be read=E2=80=94but it is much harder for her to stand >> collectively with others against a corporate giant in the online >> space. Although the Internet is often compared to public space, it >> is not. Rather the opposite. The Internet is almost entirely owned >> by private entities. >=20 > But I have another, milder, suggestion > (), > which, I believe, does not change the current consensus on DDoS > attacks: >=20 > Some people may say that DDoS attacks are the only mean to be heard, > in the current Internet. It is true that Internet has no "public > space", a place where everyone can go and protest and raise issues in > front of everyone. The Internet, and specially the Web, is a more a > series of commercial malls, hold by private entities and where free > speech is limited. This is a complicated issue for human rights, and > specially freedom of speech, but it does not mean that DDoS are a > solution to this real problem. >=20 --jVQXIS2KS1SCPDRSIdLTFIqMgHCDgaLDh 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 iQEcBAEBCAAGBQJX33FKAAoJEAi1oPJjbWjp20IH/0fFoLd3kf0pNKnaLzlQ4nes BRqVcj1c1Mazz3but0fPBVXlWPL1NVp3N80amVipbi7wbhoQFNRAkpfyAL+Uu5gr /cohUebWFQm9ZoSuVL11oCSIogRfbBEo9yKxmbU1kSYIf8i7+Q6NFobKPNWYwaJu 2CurCv3fvX/S0lGlKSZ8JujWEekUgW3SYsT5xOn5TYjgUSc/mLPNVfyByx+trg3P sBmcs+CHxBtfXOOuH04h8reJms3afkswAq/DboAZWW1siyg1EJgGgihTRaXVCLbQ e58zqPKgKzkFEwHclacCn1b2oAzmVEMkk9Owv3YNkUBTTm5034FqIq3FQg0PjRk= =nR16 -----END PGP SIGNATURE----- --jVQXIS2KS1SCPDRSIdLTFIqMgHCDgaLDh-- From nobody Sun Sep 18 22:14:01 2016 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 1738612B037 for ; Sun, 18 Sep 2016 22:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 vX3ijajsxK6p for ; Sun, 18 Sep 2016 22:13:58 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B1112B008 for ; Sun, 18 Sep 2016 22:13:58 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id ADC702400BC for ; Mon, 19 Sep 2016 05:13:57 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 9DC9881A5 for ; Mon, 19 Sep 2016 05:13:57 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 906FF2400BC for ; Mon, 19 Sep 2016 05:13:57 +0000 (UTC) To: hrpc@irtf.org References: <20160918193829.GA27308@sources.org> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <3112c805-66db-ed18-9f0f-42137938db80@article19.org> Date: Mon, 19 Sep 2016 17:13:56 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918193829.GA27308@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HpX6fkHk1hh8ieCsVm6QlfOQ58bJPIOj5" Archived-At: Subject: Re: [hrpc] Patents in draft-tenoever-hrpc-research-05 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, 19 Sep 2016 05:14:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HpX6fkHk1hh8ieCsVm6QlfOQ58bJPIOj5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephane, First of all, thanks a lot for your extensive review! It was really helpful. I agreed with all point, except for this one, so let's discuss: On 09/19/2016 07:38 AM, Stephane Bortzmeyer wrote: > Section 5.3.2.1.7 says: >=20 >> Are you aware of any patents that would prevent your standard from >> being fully implemented? >=20 > First, this is already covered in length in other IETF documents (RFC > 3979, RFC 6701, etc) note wells and things like that. And it is well > implemented by the tools we use, such as the datatracker. IMHO, we > could simply drop this sentence: the average RFC author is already > well aware there are issus with patents. True, but also other issues that are documented have been discussed in the draft. Patents can have an impact on human rights, so why not mentioned them? >=20 > If we insist on keeping it, I would disagree with it because it seems > to imply we should not standardize patented technologies. If so, we > would standardize nothing: almost every sensible algorithm is > patented. Most (all?) software patents are futile and groundless (not > to mention the fact they are valid only in some countries). If we take > them at face value, we would tie our hands. >=20 >=20 The question does not say one should not implement because of patents but asks whether the patent 'would prevent your standard from being fully implemented'. So it asks whether the limits the use (which is not necessarily the case). I've added a reference to RFC3979 and EFC6701, hope that helps. Happy to discuss and thanks again for your review! Best, Niels > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --HpX6fkHk1hh8ieCsVm6QlfOQ58bJPIOj5 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 iQEcBAEBCAAGBQJX33QVAAoJEAi1oPJjbWjph1gH/RK3btO4g6I63fuNpD+xODwo hGSPldgsNBiOhrV1El+1SjZwsk5nRlQhnLETNOxHK+zuDINQz2BRhUO9T38HfqVf wfVgpzi+CDP1ukqPFIuIoyHGt3VNUPEf2posAtv7P2KqhU56DPasiwFcKnTaz4yN YRTZoVLdEENdOa6sEw7Nq1/x2gwqacxf5FITzcM1lHLHdUt9EQdMpaN+m39pIosV fTLxsGkvwsDQTeQA9iM+c7UZdntZljdyomVMs991paeDIdID9X4NnMI8j89HJ3W1 76ZxKUdC/BShD6Eb0wBdqolIYG077P7e0CqRXADUCzy1lzHM9kGDhJDBn0KCMpo= =665g -----END PGP SIGNATURE----- --HpX6fkHk1hh8ieCsVm6QlfOQ58bJPIOj5-- From nobody Sun Sep 18 22:14:44 2016 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 86BC212B11F for ; Sun, 18 Sep 2016 22:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 zsvzbvb6433H for ; Sun, 18 Sep 2016 22:14:42 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F96012B008 for ; Sun, 18 Sep 2016 22:14:42 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5E18618858B for ; Mon, 19 Sep 2016 05:08:56 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 4F1EA16401D for ; Mon, 19 Sep 2016 05:08:56 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 44F543A1269 for ; Mon, 19 Sep 2016 05:08:56 +0000 (UTC) To: hrpc@irtf.org References: <20160918164219.GC7539@sources.org> From: Niels ten Oever Message-ID: <2eb238ff-8369-385b-a62e-b530ba2b68d8@article19.org> Date: Mon, 19 Sep 2016 17:08:55 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918164219.GC7539@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wVQDh4wcS8O6lQeuaovgCobQDW60ViIfG" Archived-At: Subject: Re: [hrpc] Turkey and draft-tenoever-hrpc-research-05 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, 19 Sep 2016 05:14:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wVQDh4wcS8O6lQeuaovgCobQDW60ViIfG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed, accepted with minor grammar changes. Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 04:42 AM, Stephane Bortzmeyer wrote: > The current text says (section 5.2.4.2) that DPI is used to modify > DNS answers in Turkey. There is no evidence of that (specially in the > mentioned article), quite the contrary: during recent censorship > events in Turkey, switching to an alternative resolver worked, proving > there was no DPI (another trick used was route hijacking, see > presentation at RIPE > ) >=20 > I suggest to rewrite as > : >=20 >> all DNS protocol messages are inspected by the network, and >> objectionable content is distorted, as in China. [China replacing Turk= ey] >=20 > See > and > for > previous remarks about Turkey. >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --wVQDh4wcS8O6lQeuaovgCobQDW60ViIfG 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 iQEcBAEBCAAGBQJX33LnAAoJEAi1oPJjbWjpcTQIAKaXNDs/CN9PSky6iQWcox8Z g+6LjOAzHxihx72W8SvCdoSYIcXhmC4mE3DEiN5rGPy2ax1od8qM7kjiKtAbgQN7 5Qt1MJMo8mmKcdvcxStYmUEL/j6pKt0dqbmqNw4skKA9qBw7P1EPGbLA+ZSkA4sp 43YdVAdv2UWJfzndf80aZ0yHO2IHP22U5+X9giQeRanHPX+s76U6/6ieCHkH0uW6 m3vWLjUDx1Xt7E5LOuUN3ijTAV3/eAPghhNN5F9REGeC3VZW4x6o6oK6DKq1r1Cg BD6kzHJtfLhCTyZzrsj/YL6yzo4zDOzvCMY/MMkNlASUYmpdzgM951XAak5ISI0= =XCsE -----END PGP SIGNATURE----- --wVQDh4wcS8O6lQeuaovgCobQDW60ViIfG-- From nobody Sun Sep 18 22:24:45 2016 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 C98A212B17C for ; Sun, 18 Sep 2016 22:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 06vSlsaFb0WH for ; Sun, 18 Sep 2016 22:24:42 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8D812B104 for ; Sun, 18 Sep 2016 22:24:42 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 6A13716401D for ; Mon, 19 Sep 2016 05:09:10 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5BD243A1269 for ; Mon, 19 Sep 2016 05:09:10 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 5120C16401D for ; Mon, 19 Sep 2016 05:09:10 +0000 (UTC) To: hrpc@irtf.org References: <20160918162826.GA8851@sources.org> From: Niels ten Oever Message-ID: <42ee0022-3e9f-8a94-d175-22ef6d5bb9e8@article19.org> Date: Mon, 19 Sep 2016 17:09:09 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918162826.GA8851@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eNOh8Rn12CDlUHdn3nmJAAnw3qoFkrSGT" Archived-At: Subject: Re: [hrpc] Sloppy use of "centralized" in draft-research 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, 19 Sep 2016 05:24:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eNOh8Rn12CDlUHdn3nmJAAnw3qoFkrSGT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed, accepted and inserted. Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 04:28 AM, Stephane Bortzmeyer wrote: > In version -05, section 5.2.4, I read: >=20 >> The DNS is centralized, and this brings up political and social >> concerns over control. >=20 > This is not a correct assessment. If the DNS were really centralized, > each time I want to add/modify something in bortzmeyer.org, I would > have to ask to the Center. (This was true of the previous system, > HOSTS.TXT, described in RFC 608.) >=20 > I suggest instead: >=20 >> The DNS is organized as a rooted tree, and this brings up political >> and social concerns over control. >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --eNOh8Rn12CDlUHdn3nmJAAnw3qoFkrSGT 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 iQEcBAEBCAAGBQJX33L2AAoJEAi1oPJjbWjp97sH/1wXERdj/vSpq16F4IJWDdi7 5vx0jAK0DCvWHadnGyB1C6e7DeERL4ki7BvDj+bhhFCZ5fYqQzbpAYnVqERu6p/G DWrVYpVCszuzGrgTukN7QNQEskmgkUssvCJXzGMAmmJu7GBGGav1w6QJnQGXy+wX YpGxXlTcMZ01LZYb0gaaKkeW9D336uOI6f2DNxbLGbYBE+4Y71ylBre7M/TDQVpJ lfYVaD+s2fZwXH/8Aj8rxauD02vP57M+Imkn5CerEMZpj6qIgLiag/vmDHAnAf2p I448NS1IzskiNlaligE/nt81HwGKFQTT09j9YD4bL2nFsjVm2Fxoh2mqQJWWzx8= =PGtw -----END PGP SIGNATURE----- --eNOh8Rn12CDlUHdn3nmJAAnw3qoFkrSGT-- From nobody Sun Sep 18 23:28:16 2016 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 9175112B13F; Sun, 18 Sep 2016 23:28:14 -0700 (PDT) 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.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147426649458.15026.17311272259655986875.idtracker@ietfa.amsl.com> Date: Sun, 18 Sep 2016 23:28:14 -0700 Archived-At: Cc: hrpc@irtf.org Subject: [hrpc] I-D Action: draft-irtf-hrpc-research-00.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: Mon, 19 Sep 2016 06:28:14 -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-00.txt Pages : 71 Date : 2016-09-18 Abstract: The evergrowing interconnectedness of Internet and society increases the impact of the Internet on the lives of individuals. Because of this, the design and development of the architecture of the Internet also has a growing impact on society. This has led to an broad recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in the development and management of the Internet [HRC2012] [UNGA2013] [NETmundial]. It has also been argued that the Internet should be strengthened as a human rights enabling environment [Brown]. This document provides 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, and a proposal for guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations [RFC6973]. 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-00 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 Mon Sep 19 00:21:26 2016 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 733E212B0B3 for ; Mon, 19 Sep 2016 00:21:25 -0700 (PDT) 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 YafOQ5w76NPC for ; Mon, 19 Sep 2016 00:21:24 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 19CF112B195 for ; Mon, 19 Sep 2016 00:21:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 75B8B10722 for ; Mon, 19 Sep 2016 07:21:23 +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 GWn0qx50qYPf for ; Mon, 19 Sep 2016 07:21:22 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2c0f:f9a8::4852:be98:e93:f19a]) by mx2.yitter.info (Postfix) with ESMTPSA id CDCFF106B5 for ; Mon, 19 Sep 2016 07:21:21 +0000 (UTC) Date: Mon, 19 Sep 2016 03:21:17 -0400 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20160919072116.GB756@mx2.yitter.info> References: <20160918193829.GA27308@sources.org> <3112c805-66db-ed18-9f0f-42137938db80@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3112c805-66db-ed18-9f0f-42137938db80@article19.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [hrpc] Patents in draft-tenoever-hrpc-research-05 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, 19 Sep 2016 07:21:25 -0000 On Mon, Sep 19, 2016 at 05:13:56PM +1200, Niels ten Oever wrote: > The question does not say one should not implement because of patents > but asks whether the patent 'would prevent your standard from being > fully implemented'. So it asks whether the limits the use (which is not > necessarily the case). I think the question goes sort of to the heart of who we think the audience is. If the goal is for individuals to consider these considerations (which is I think formally what the document says) then I don't (speaking personally) have a concern about this question. If the practical goal, however, is actually to influence the way the IETF or WGs or something make decisions about these matters, then I think Stephane's point is that IPR generally is an issue the IETF has wrestled with, and it has come out on the side of not taking a position on these matters. The question above militates against taking that non-position, and that might be reason to worry a little about this discussion. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Sep 19 00:46:50 2016 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 239E512B0BF for ; Mon, 19 Sep 2016 00:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 kDMXBFuNm_eE for ; Mon, 19 Sep 2016 00:46:47 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE7012B08C for ; Mon, 19 Sep 2016 00:46:47 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id AA4951C8730 for ; Mon, 19 Sep 2016 07:46:45 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 9BE9A1A11CF for ; Mon, 19 Sep 2016 07:46:45 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 9125F18858B for ; Mon, 19 Sep 2016 07:46:45 +0000 (UTC) To: hrpc@irtf.org References: <20160918193829.GA27308@sources.org> <3112c805-66db-ed18-9f0f-42137938db80@article19.org> <20160919072116.GB756@mx2.yitter.info> From: Niels ten Oever Message-ID: <5064cd05-a545-92a7-11db-9dedc31ea73b@article19.org> Date: Mon, 19 Sep 2016 09:46:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160919072116.GB756@mx2.yitter.info> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bds957AWKE2VWLR7FaiAhnx0rn3UfpapG" Archived-At: Subject: Re: [hrpc] Patents in draft-tenoever-hrpc-research-05 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, 19 Sep 2016 07:46:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Bds957AWKE2VWLR7FaiAhnx0rn3UfpapG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Andrew, On 09/19/2016 09:21 AM, Andrew Sullivan wrote: > On Mon, Sep 19, 2016 at 05:13:56PM +1200, Niels ten Oever wrote: >> The question does not say one should not implement because of patents >> but asks whether the patent 'would prevent your standard from being >> fully implemented'. So it asks whether the limits the use (which is no= t >> necessarily the case). >=20 > I think the question goes sort of to the heart of who we think the > audience is. If the goal is for individuals to consider these > considerations (which is I think formally what the document says) then > I don't (speaking personally) have a concern about this question. >=20 This is exactly what it aims to do. > If the practical goal, however, is actually to influence the way the > IETF or WGs or something make decisions about these matters, then I > think Stephane's point is that IPR generally is an issue the IETF has > wrestled with, and it has come out on the side of not taking a > position on these matters. The question above militates against > taking that non-position, and that might be reason to worry a little > about this discussion. >=20 Would you have a language suggestion which would help people interpret this question? I thought the references to RFC3979 RFC6701 would help reiterate the former reading. Best, Niels > Best regards, >=20 > A >=20 --Bds957AWKE2VWLR7FaiAhnx0rn3UfpapG 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 iQEcBAEBCAAGBQJX35flAAoJEAi1oPJjbWjplO8H/0N04+PbEGVhvW1npBw9MS4j hyIT/uC7O1TLpKeHzLq4FKyvzSvAelaWhMuhebD8y7ENvbsXc3YT6W9l59YxcaRq 3MjOFXTOa3UAcf8Rml3ZdBKdfsvfAcqRxVD4ZD6Y1laUUzA6Zv4s9DpzqbYA2jDo apypumw5m4ly8sLu0LXWK/dmXmDtez5sZ4vRRjREo9lMwSUkIMINGvOLWvLpsz9f Vl3N+BqI8btSNsmW6amPqLbs3CYyNoi8amamz7Pda2ZtXQI8PXy8t/Ua0EQXlvoc e/wPuV3BZDq9AhaMXp21VXI4hLHQgr//MvmCMqK/jefqqEPfMuOY27lC5OKonHY= =8jMs -----END PGP SIGNATURE----- --Bds957AWKE2VWLR7FaiAhnx0rn3UfpapG-- From nobody Mon Sep 19 01:25:01 2016 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 1411312B1D5 for ; Mon, 19 Sep 2016 01:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 dl7NFM8VosGg for ; Mon, 19 Sep 2016 01:24:58 -0700 (PDT) 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 F30EE12B1D4 for ; Mon, 19 Sep 2016 01:24:57 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2DC432803CD for ; Mon, 19 Sep 2016 10:24:56 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 2940F2800B3 for ; Mon, 19 Sep 2016 10:24:56 +0200 (CEST) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 2769EB3800C for ; Mon, 19 Sep 2016 10:24:26 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 205C83FE2C; Mon, 19 Sep 2016 10:24:26 +0200 (CEST) Date: Mon, 19 Sep 2016 10:24:26 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160919082426.zq5chversnld4xbz@nic.fr> References: <147426649458.15026.17311272259655986875.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147426649458.15026.17311272259655986875.idtracker@ietfa.amsl.com> X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.6.0-1-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/ (1.7.0) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-00.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: Mon, 19 Sep 2016 08:25:00 -0000 On Sun, Sep 18, 2016 at 11:28:14PM -0700, internet-drafts@ietf.org wrote a message of 59 lines which said: > Title : Research into Human Rights Protocol Considerations > Authors : Niels ten Oever > Corinne Cath > Filename : draft-irtf-hrpc-research-00.txt I don't know if it was in the Markdown source, or because the workflow has bugs, but some sentences are mangled. 5.3.2.1.5 : > Does your protocol allow Unicode encoded in UTF-8 only,[missing > something here]If other character sets /encodings are allowed, does > your protocol mandates a proper tagging of the charset? 5.2.11 : > The IETF can clearly play a role in bringing about some of these > changes. it is important to consider that DDoS attacks are sometimes > seen as a method for exercising freedom of speech [Sauter]. [then a repetition] > Eventhough it is important to consider that DDoS attacks are > sometimes seen as a method for exercising freedom of speech > [Sauter]. From nobody Mon Sep 19 01:46:19 2016 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 7DD3512B222 for ; Mon, 19 Sep 2016 01:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 TPAOHNvZ1e5T for ; Mon, 19 Sep 2016 01:46:16 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3176812B21C for ; Mon, 19 Sep 2016 01:46:15 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 99A88240083 for ; Mon, 19 Sep 2016 08:46:14 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 8875924009F for ; Mon, 19 Sep 2016 08:46:14 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 7AB0F240083 for ; Mon, 19 Sep 2016 08:46:14 +0000 (UTC) To: hrpc@irtf.org References: <147426649458.15026.17311272259655986875.idtracker@ietfa.amsl.com> <20160919082426.zq5chversnld4xbz@nic.fr> From: Niels ten Oever Message-ID: <339dfd82-882a-281b-629f-ec199ae91aaa@article19.org> Date: Mon, 19 Sep 2016 10:46:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160919082426.zq5chversnld4xbz@nic.fr> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hU1NpRv72EQGfDh6CwfP6NnQvjQjHpNv8" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-00.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: Mon, 19 Sep 2016 08:46:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hU1NpRv72EQGfDh6CwfP6NnQvjQjHpNv8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Oops, I messed up when merging in Git. Fixed here now: https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md Cheers, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/19/2016 10:24 AM, Stephane Bortzmeyer wrote: > On Sun, Sep 18, 2016 at 11:28:14PM -0700, > internet-drafts@ietf.org wrote=20 > a message of 59 lines which said: >=20 >> Title : Research into Human Rights Protocol Consider= ations >> Authors : Niels ten Oever >> Corinne Cath >> Filename : draft-irtf-hrpc-research-00.txt >=20 > I don't know if it was in the Markdown source, or because the workflow > has bugs, but some sentences are mangled. >=20 > 5.3.2.1.5 : >=20 >> Does your protocol allow Unicode encoded in UTF-8 only,[missing >> something here]If other character sets /encodings are allowed, does >> your protocol mandates a proper tagging of the charset? >=20 > 5.2.11 : >=20 >> The IETF can clearly play a role in bringing about some of these >> changes. it is important to consider that DDoS attacks are sometimes >> seen as a method for exercising freedom of speech [Sauter]. > [then a repetition] >> Eventhough it is important to consider that DDoS attacks are >> sometimes seen as a method for exercising freedom of speech >> [Sauter]. >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --hU1NpRv72EQGfDh6CwfP6NnQvjQjHpNv8 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 iQEcBAEBCAAGBQJX36XVAAoJEAi1oPJjbWjpESIH/Awj44Y+fUcjZ+83Z/Jf7LFA D+8Y4XXOUdHgbP8h7UNp9w0WnyOXSZultf4eEqqBD4vD8pdvSX4lIhqKhS+UvAwx 1aeYsDrYr8JFjx/hXxFHmf6nKuBd4QRvI0eC4Jcmb8s55RxaaXHGSPWvfIFuw7aI 7OPUgPqkZggGn3Mj5U/LcafQl5kZI4GKxcHKUdZJDHdoRMQHQLmgmWar4rqHiT2h iT7sENnanb+5mLu0OX6MBT+fuPUMlURdn0Re7xamw5xnq3aMZ788+nxvkVIvaoE9 Cqyf7L5Qhct8iVF/RZljmBWxCT652gVFogMD1jmk9dG0XpyJdO8Ku4wnMKRdp/g= =0Um2 -----END PGP SIGNATURE----- --hU1NpRv72EQGfDh6CwfP6NnQvjQjHpNv8-- From nobody Mon Sep 19 12:58:13 2016 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 7BE1912B50F for ; Mon, 19 Sep 2016 12:58:12 -0700 (PDT) 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 1aiW_mFgRe7A for ; Mon, 19 Sep 2016 12:58:10 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F2712B43C for ; Mon, 19 Sep 2016 12:58:10 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 38D0A31CA5; Mon, 19 Sep 2016 21:58:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 5A0A5190B20; Mon, 19 Sep 2016 21:55:46 +0200 (CEST) Date: Mon, 19 Sep 2016 21:55:46 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20160919195546.GA23686@sources.org> References: <20160918193829.GA27308@sources.org> <3112c805-66db-ed18-9f0f-42137938db80@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3112c805-66db-ed18-9f0f-42137938db80@article19.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Patents in draft-tenoever-hrpc-research-05 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, 19 Sep 2016 19:58:12 -0000 On Mon, Sep 19, 2016 at 05:13:56PM +1200, Niels ten Oever wrote a message of 95 lines which said: > Patents can have an impact on human rights, so why not mentioned > them? Another issue with the current wording is that it seems to say that it is up to the RFC / protocol author to check / inquire on possible patents, a huge task. (And it is very different from IETF policy, which requires no such effort.) From nobody Tue Sep 20 00:42:12 2016 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 2E3C512B653 for ; Tue, 20 Sep 2016 00:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 zT0QHpCYTU1B for ; Tue, 20 Sep 2016 00:42:09 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226BF12B657 for ; Tue, 20 Sep 2016 00:42:08 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id E45B8C7B9C5A; Tue, 20 Sep 2016 07:42:06 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id D441414122BD1; Tue, 20 Sep 2016 07:42:06 +0000 (UTC) Received: from [10.9.0.26] (tunnel.greenhost.nl [195.190.28.22]) by mail.article19.io (Postfix) with ESMTPSA id ADD5BC7B9C5A; Tue, 20 Sep 2016 07:42:06 +0000 (UTC) To: Stephane Bortzmeyer References: <20160918193829.GA27308@sources.org> <3112c805-66db-ed18-9f0f-42137938db80@article19.org> <20160919195546.GA23686@sources.org> From: Niels ten Oever Message-ID: <6879ccfc-861d-480e-d477-39d5d97364c0@article19.org> Date: Tue, 20 Sep 2016 09:42:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160919195546.GA23686@sources.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qSFuj30DL8wGlFdqhWatSuRk3KAtM4BI3" Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Patents in draft-tenoever-hrpc-research-05 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, 20 Sep 2016 07:42:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qSFuj30DL8wGlFdqhWatSuRk3KAtM4BI3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=20 > Another issue with the current wording is that it seems to say that it > is up to the RFC / protocol author to check / inquire on possible > patents, a huge task. (And it is very different from IETF policy, > which requires no such effort.) >=20 The text reads: Are you aware of any patents that would prevent your standard from being fully implemented [RFC3979] [RFC6701]? Is does not say: you MUST check all potential patents on the technology used to implement your protocol. So I don't share your concerns and I do not think a necessary check / inquiry is invoked by this guideline question. Best, Niels --qSFuj30DL8wGlFdqhWatSuRk3KAtM4BI3 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 iQEcBAEBCAAGBQJX4OhOAAoJEAi1oPJjbWjpIxgH/inWx0U48q6j8t5kxYhmyYPb 6Jjyc8/MKCVyFGk8pm6pqgSUo1rmINtLXzeocMDN1OsHTqWSwPfRvSlHl4mNx1F4 y74eq9am3fGVlKg2K3sJMRPZEQcm0wE5P4swUawT5mJWdRXjzOJ3UZPgIGut53Tf iTyQDNbG1tqeGdCrw0c1yzmePMzbvdGwq+jxDjGZwUkQ6NxmSR88AMAgtrtEsoxE k0xrmCiz1pJ6W+dRbe7PUj4YBOMsW7eA0hnCmiVv/nA0dLYAZDuv49CUwoAoqOTZ L/38L1B10hfyJ5iHheeQEDVrnAj1QM3UCbgg/RFIO7wDAfDSaQKlfCe24EBzJDM= =FWPX -----END PGP SIGNATURE----- --qSFuj30DL8wGlFdqhWatSuRk3KAtM4BI3-- From nobody Tue Sep 20 01:05:22 2016 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 6866312B675 for ; Tue, 20 Sep 2016 01:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.838 X-Spam-Level: X-Spam-Status: No, score=-16.838 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 gXxkvSudGtA6 for ; Tue, 20 Sep 2016 01:05:15 -0700 (PDT) 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 3C97F12B67B for ; Tue, 20 Sep 2016 01:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5842; q=dns/txt; s=iport; t=1474358713; x=1475568313; h=to:from:subject:message-id:date:mime-version; bh=GEpLsF7ONoPUSgulrZrDAOAtv1VmoenAbcu3SdG4Qi0=; b=eA/nClLnYWoBR1Qb8ZEKo3AMDpfS7A1VUXitQ4GioGhvOBYX1T7OP4gs y4kXQAFTchU4xb6qW7ADyr95gcbzOHhdkruQCp1lquf7W/oRQI7Sy21FK EAff87lRnrRP4HzrxG6UU7kjVH5N+q4bWCrEBfluSd/tZSrEVK6Ui8Ksl I=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAwBX7OBX/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzsBAQEBAXUqjgWrQYIEJoVzA4IYFAECAQEBAQEBAV4cC4RjBCRLAQ9?= =?us-ascii?q?YAlMMDQgBARaIKAgOoDWPZoxFAQEBBwIBFgkFiDMIgUuFJoMlgloFlBqFVoNAg?= =?us-ascii?q?XZwcoFMhnqBbod3I4VikF8eNoUFPIUpgi0BAQE?= X-IronPort-AV: E=Sophos;i="5.30,366,1470700800"; d="asc'?scan'208";a="688375157" 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; 20 Sep 2016 08:05:10 +0000 Received: from [10.61.210.213] ([10.61.210.213]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u8K85ARV013730 for ; Tue, 20 Sep 2016 08:05:10 GMT To: "hrpc@irtf.org" From: Eliot Lear Message-ID: Date: Tue, 20 Sep 2016 10:05:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NbxCBpr94etbwvbFs4DC19svfMS80qmf5" Archived-At: Subject: [hrpc] more on open standards and ipr 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, 20 Sep 2016 08:05:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NbxCBpr94etbwvbFs4DC19svfMS80qmf5 Content-Type: multipart/mixed; boundary="3whVqCfXfKthRGIqTVsRrDdDPGSTrlNSC"; protected-headers="v1" From: Eliot Lear To: "hrpc@irtf.org" Message-ID: Subject: more on open standards and ipr --3whVqCfXfKthRGIqTVsRrDdDPGSTrlNSC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Niels and everyone, Following the previous discussion I would propose a few changes: > Explanation: The Internet was able to developed into the global > network of networks because of the existence of open, non-proprietar= y > standards [Zittrain]. They are crucial for enabling > interoperability. Yet, open standards are not explicitly defined > within the IETF. =20 This would be considered news to most people at the IETF. That doesn't mean the IETF does ALL open standards but all IETF standards are as close to open as any I know. Indeed it's not clear that the focus here should be the IETF, but rather more general. There are two approaches you could take to address this issue: 1. Drop the sentence. I think that generalizes the point. 2. Replace the sentence with something more factually grounded, such as the following: "Organizations that espouse open standards philosophies may find themselves entangled through normative references to closed standards or proprietary approaches." And then go on from there. > On the subject, [RFC2606] states: Various national > and international standards bodies, such as ANSI, ISO, IEEE, and ITU= - > T, develop a variety of protocol and service specifications that are= > similar to Technical Specifications defined at the IETF. National > and international groups also publish "implementors' agreements" tha= t > are analogous to Applicability Statements, capturing a body of > implementation-specific detail concerned with the practical > application of their standards. All of these are considered to be > "open external standards" for the purposes of the Internet Standards= > Process. Similarly, [RFC3935] does not define open standards but > does emphasize the importance of 'open process': any interested > person can participate in the work, know what is being decided, and > make his or her voice heard on the issue. Part of this principle is= > the IETF's commitment to making its documents, WG mailing lists, > attendance lists, and meeting minutes publicly available on the > Internet. Again here you may wish to use the IETF as an examplar, but not make this about the IETF. By the way, OpenStand is probably worth considering= =2E Finally, I think it's useful to explain some of the complexity around open standards. This is not an easy subject. There was an excellent article by Steven Levy on the impact of normative references in code.[1] Some of us remember Carl Malamud, who used to participate in the IETF. This is a great read, and his cause is good. But the IETF is in a bit of a privileged spot: ISOC and ICANN foot our bills and those of the W3C, at least in part. That helps keep things open. Other standards organizations still have to pay the bills. Some do that by selling documents, others do it through membership fees as a price of influence. Traveling around the world to participate is also expensive. And so there are many aspects that limit openness. At the same time, openness tends to slow things down. In a hot market, that's death to a young company. I would finally point out that open standards on the web is almost an oxymoron. Much of the communication to and from the browser is in javascript, and apps on your phone are written generally to be two-sided, such that there is NO standardization. Should there be?=20 What is the value to society and what human rights are at stake? This causes me to think a bit about the hourglass model and how we standardize at its neck more so than elsewhere. And this brings me back to an earlier point: if this draft is intended to inform the discussion, let's insure we have captured these sorts of complexities. And then if there are clear recommendations to be made, let's hear them. > > Open standards are important as they allow for permissionless > innovation, which is important to maintain the freedom and ability t= o > freely create and deploy new protocols on top of the communications > constructs that currently exist. While I like a good turn of phrase as much as the next person, I suggest that "permissionless innovation" is something of a marketing term, and it goes undefined within the document. If you are going to use it, you should explain what it is and why it is important. Eliot [1] https://backchannel.com/the-internets-own-instigator-cb6347e693b#.6wht8ih= 7b --3whVqCfXfKthRGIqTVsRrDdDPGSTrlNSC-- --NbxCBpr94etbwvbFs4DC19svfMS80qmf5 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 iQEcBAEBCAAGBQJX4O21AAoJEIe2a0bZ0nozh1IH/3aS6y/xcgnpB8IwBRjm9KX/ E2IZl1LxxX6YJ5CS3rK1JuLZPMxQQoCmBbifAEiWRFcr0IvfsYQ1daLh+f9FjM0s lWfxkf8OSO6TC/M4j8ZcB5O4wjFFJA6d+cV4j3i+VMIU2c4YYXoznljABjraQIpt Q+iqEwUdWyptefs5PoGaumiBd+MNroNzhab0PVWS2GtxhOFUPIPs3djufMijBDlO R5k0vDqj9RdBi2YagcTUyUO1VEKMs25oM1QQGSuQx027tR22kCVGk674PRmJhL9o 1ECsOWskMUA/+p3W5hyM9aFQjI2bcy5D8wlXCnXpPD1yxKsCq6yozwBVrAK2TXA= =mcxJ -----END PGP SIGNATURE----- --NbxCBpr94etbwvbFs4DC19svfMS80qmf5-- From nobody Tue Sep 20 01:38:29 2016 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 A07B712B6DA for ; Tue, 20 Sep 2016 01:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 yk59ItzCIaIg for ; Tue, 20 Sep 2016 01:38:25 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1531B12B739 for ; Tue, 20 Sep 2016 01:29:58 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5B520A0BBF9 for ; Tue, 20 Sep 2016 08:29:57 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 4910FB0F9A9 for ; Tue, 20 Sep 2016 08:29:57 +0000 (UTC) Received: from [10.9.0.26] (tunnel.greenhost.nl [195.190.28.22]) by mail.article19.io (Postfix) with ESMTPSA id 3B6DEA0BBF9 for ; Tue, 20 Sep 2016 08:29:57 +0000 (UTC) To: hrpc@irtf.org References: From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> Date: Tue, 20 Sep 2016 10:29:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gC20DPk8gfIlLWahAFMc1PnJJIW7hEmNj" Archived-At: Subject: Re: [hrpc] more on open standards and ipr 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, 20 Sep 2016 08:38:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gC20DPk8gfIlLWahAFMc1PnJJIW7hEmNj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Elliot, On 09/20/2016 10:05 AM, Eliot Lear wrote: > Hi Niels and everyone, >=20 > Following the previous discussion I would propose a few changes: >=20 >=20 >=20 >> Explanation: The Internet was able to developed into the global >> network of networks because of the existence of open, non-proprieta= ry >> standards [Zittrain]. They are crucial for enabling >> interoperability. Yet, open standards are not explicitly defined >> within the IETF. =20 >=20 >=20 > This would be considered news to most people at the IETF. That doesn't= > mean the IETF does ALL open standards but all IETF standards are as > close to open as any I know. =20 This might be a language issue. What is meant is that there is no IETF definition for what an 'open standard' is. Indeed it's not clear that the focus here > should be the IETF, but rather more general. There are two approaches > you could take to address this issue: >=20 > 1. Drop the sentence. I think that generalizes the point. >=20 > 2. Replace the sentence with something more factually grounded, such a= s > the following: >=20 > "Organizations that espouse open standards philosophies may find > themselves entangled through normative references to closed standards o= r > proprietary approaches." >=20 > And then go on from there. >=20 >=20 >> On the subject, [RFC2606] states: Various national >> and international standards bodies, such as ANSI, ISO, IEEE, and IT= U- >> T, develop a variety of protocol and service specifications that ar= e >> similar to Technical Specifications defined at the IETF. National >> and international groups also publish "implementors' agreements" th= at >> are analogous to Applicability Statements, capturing a body of >> implementation-specific detail concerned with the practical >> application of their standards. All of these are considered to be >> "open external standards" for the purposes of the Internet Standard= s >> Process. Similarly, [RFC3935] does not define open standards but >> does emphasize the importance of 'open process': any interested >> person can participate in the work, know what is being decided, and= >> make his or her voice heard on the issue. Part of this principle i= s >> the IETF's commitment to making its documents, WG mailing lists, >> attendance lists, and meeting minutes publicly available on the >> Internet. >=20 > Again here you may wish to use the IETF as an examplar, but not make > this about the IETF. By the way, OpenStand is probably worth consideri= ng. >=20 > Finally, I think it's useful to explain some of the complexity around > open standards. This is not an easy subject. There was an excellent > article by Steven Levy on the impact of normative references in > code.[1] Some of us remember Carl Malamud, who used to participate in > the IETF. This is a great read, and his cause is good. But the IETF i= s > in a bit of a privileged spot: ISOC and ICANN foot our bills and those > of the W3C, at least in part. That helps keep things open. Other > standards organizations still have to pay the bills. Some do that by > selling documents, others do it through membership fees as a price of > influence. Traveling around the world to participate is also > expensive. And so there are many aspects that limit openness. At the > same time, openness tends to slow things down. In a hot market, that's= > death to a young company. >=20 Not sure if the ecnomic models of open standards are within the scope of this document. > I would finally point out that open standards on the web is almost an > oxymoron. Much of the communication to and from the browser is in > javascript, and apps on your phone are written generally to be > two-sided, such that there is NO standardization. Should there be?=20 > What is the value to society and what human rights are at stake? =20 I am not sure whether web standards fall within the scope of this draft. > This > causes me to think a bit about the hourglass model and how we > standardize at its neck more so than elsewhere. >=20 > And this brings me back to an earlier point: if this draft is intended > to inform the discussion, let's insure we have captured these sorts of > complexities. And then if there are clear recommendations to be made, > let's hear them. >=20 >=20 I think starting of with documenting the issues is already a great step, actually. >> >> 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. >=20 > While I like a good turn of phrase as much as the next person, I > suggest that "permissionless innovation" is something of a marketing > term, and it goes undefined within the document. If you are going to > use it, you should explain what it is and why it is important. >=20 We could add this definition to the glossary: "Permissionless innovation," is the freedom to explore new technologies or businesses without seeking prior approval. from: Thierer, A. Permissionless Innovation: The Continuing Case for Comprehensive Technological Freedom. Mercatus Center at George Mason University, 2014. Best, Niels > Eliot >=20 > [1] > https://backchannel.com/the-internets-own-instigator-cb6347e693b#.6wht8= ih7b >=20 >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --gC20DPk8gfIlLWahAFMc1PnJJIW7hEmNj 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 iQEcBAEBCAAGBQJX4POEAAoJEAi1oPJjbWjpGd0H/28vFJdpl3XN+kSFfJ+n1d9x +Bt+LKob4xA/XHIxF64s6ZE0+kPB8+eYvD4V5bTxACvzDWSmqQoC/JM3Z6FsZ2zW jsbkfs/bHieQrFhiz/5NlYrwSAdoX2V4jrmBXplMs7o4cprY5HI9DncJCQ5ecHE8 lsiNVyehR6HgdeVa/MTE1k3kkJ05MRENkQly6xM2k/gO3LwwaPyXR5EvZKt69mgb lnwMYFrVTMBjEDZU3rKjClqUUP23y14MZTaDAWCxIqqBOYWbT6w4Y9KWv+yX6QUL s9+M8yaI08fr91/q9Gy+UB7t9LC4ot1CjM3RejV4f8IG6iNBFnn0UnV3IGsYnQA= =j0ZH -----END PGP SIGNATURE----- --gC20DPk8gfIlLWahAFMc1PnJJIW7hEmNj-- From nobody Tue Sep 20 02:08:27 2016 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 6B5FA12B1D1 for ; Tue, 20 Sep 2016 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.838 X-Spam-Level: X-Spam-Status: No, score=-16.838 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 UPEJR3EP3OOp for ; Tue, 20 Sep 2016 02:08:21 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DBB112B1CE for ; Tue, 20 Sep 2016 02:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7481; q=dns/txt; s=iport; t=1474362501; x=1475572101; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=uGgRw2eVN7eW+kh09kqRbP9gxB65iU7nara1ljTh8LU=; b=EPnaZT82NUwrq4ksjowZkb5Ef19V4KJlyhKGV8UX4GD4CYmhY1HRrpqy YsxFdAITb65ug15hkAAc37C5nKgBreBK30BdEhm5va6/klfUw+P4tkuhd Uuqh9MA1Vbwh3PHsHMoY740txW6K5iBCpFpNbegzpkhqQvknf7xL8qzOK k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAwBd++BX/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzsBAQEBAYEfjgWrQYIEhh4CghYUAQIBAQEBAQEBXieEYQEBAQMBI0w?= =?us-ascii?q?DFwsYKgICVwYBDAgBARAGiCgIsCWMQwEBAQEBAQEDAQEBAQEBARIOiDOBU4EFh?= =?us-ascii?q?BYLBgGDHoJaBYgmh0aKBINAgXaBYoFMhnqBbod3I4VihwKFYoN7HjaFBTyFKQ4?= =?us-ascii?q?XgggBAQE?= X-IronPort-AV: E=Sophos;i="5.30,367,1470700800"; d="asc'?scan'208";a="648659177" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2016 09:08:18 +0000 Received: from [10.61.160.191] ([10.61.160.191]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u8K98IhH009069; Tue, 20 Sep 2016 09:08:18 GMT To: Niels ten Oever , hrpc@irtf.org References: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> From: Eliot Lear Message-ID: <42126a3d-781d-ac78-b04b-8c84517765b3@cisco.com> Date: Tue, 20 Sep 2016 11:08:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1HRRG0k5h8baGKAVnAKn0biWtwKkpfwMe" Archived-At: Subject: Re: [hrpc] more on open standards and ipr 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, 20 Sep 2016 09:08:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1HRRG0k5h8baGKAVnAKn0biWtwKkpfwMe Content-Type: multipart/mixed; boundary="HKeKDnFCw66fDX09OAHtido6no9TioxU4"; protected-headers="v1" From: Eliot Lear To: Niels ten Oever , hrpc@irtf.org Message-ID: <42126a3d-781d-ac78-b04b-8c84517765b3@cisco.com> Subject: Re: [hrpc] more on open standards and ipr References: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> In-Reply-To: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> --HKeKDnFCw66fDX09OAHtido6no9TioxU4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Niels (and sorry for so many "finally"s that were not in fact final ;-= ) Summary: I've the same problem as Andrew. Is your target audience the IETF or the broader community? An answer to that question will help us in many ways. On 9/20/16 10:29 AM, Niels ten Oever wrote: > Hi Elliot, > > On 09/20/2016 10:05 AM, Eliot Lear wrote: >> Hi Niels and everyone, >> >> Following the previous discussion I would propose a few changes: >> >> >> >>> Explanation: The Internet was able to developed into the global >>> network of networks because of the existence of open, non-propriet= ary >>> standards [Zittrain]. They are crucial for enabling >>> interoperability. Yet, open standards are not explicitly defined >>> within the IETF. =20 >> >> This would be considered news to most people at the IETF. That doesn'= t >> mean the IETF does ALL open standards but all IETF standards are as >> close to open as any I know. =20 > This might be a language issue. What is meant is that there is no IETF > definition for what an 'open standard' is. > > Indeed it's not clear that the focus here Well so this is the issue. Is this draft intended to address just the IETF or be more broadly applicable? If you want it to be more broadly applicable the trick here is to use the IETF or other SDOs as examples.=20 Remember, we're here in the iRtf and we don't need to focus on the IETF. Choose wisely ;-) >> Again here you may wish to use the IETF as an examplar, but not make >> this about the IETF. By the way, OpenStand is probably worth consider= ing. >> >> Finally, I think it's useful to explain some of the complexity around >> open standards. This is not an easy subject. There was an excellent >> article by Steven Levy on the impact of normative references in >> code.[1] Some of us remember Carl Malamud, who used to participate in= >> the IETF. This is a great read, and his cause is good. But the IETF = is >> in a bit of a privileged spot: ISOC and ICANN foot our bills and those= >> of the W3C, at least in part. That helps keep things open. Other >> standards organizations still have to pay the bills. Some do that by >> selling documents, others do it through membership fees as a price of >> influence. Traveling around the world to participate is also >> expensive. And so there are many aspects that limit openness. At the= >> same time, openness tends to slow things down. In a hot market, that'= s >> death to a young company. >> > Not sure if the ecnomic models of open standards are within the scope o= f > this document. I'm sympathetic to the idea of not wildly expanding the scope of this document or research group to go beyond human rights. But I think this hangs on the notion of whether permissionless innovation is a human right, and then whether open standards are required for permissionless innovation. Carl's work, and the quote from Justice Breyer, get to the heart of the risks of normative references by laws themselves. In this sense, the IETF is just about ideal for a reference, not that most of us would encourage any such references (what happens if we update an RFC, for example). And so again: it depends on your intended purpose. If it is to inform society about the relationship between standards and human rights, the I would say there is a relationship. If your intent is to improve IETF processes through an informational document within the context of the IRTF, then I would say it is possible to scope down. But that does limit the applicability of your work. Again, choose wisely. >> I would finally point out that open standards on the web is almost an >> oxymoron. Much of the communication to and from the browser is in >> javascript, and apps on your phone are written generally to be >> two-sided, such that there is NO standardization. Should there be?=20 >> What is the value to society and what human rights are at stake? =20 > I am not sure whether web standards fall within the scope of this draft= =2E See above. If you are strictly focused on the IETF, I guess you're right, but I would claim that then this is a missed opportunity. > >> This >> causes me to think a bit about the hourglass model and how we >> standardize at its neck more so than elsewhere. >> >> And this brings me back to an earlier point: if this draft is intended= >> to inform the discussion, let's insure we have captured these sorts of= >> complexities. And then if there are clear recommendations to be made,= >> let's hear them. >> >> > I think starting of with documenting the issues is already a great step= , > actually. Ok. How much depends on the answer to the question at the top of this email, right? > >>> 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 communication= s >>> constructs that currently exist. >> While I like a good turn of phrase as much as the next person, I >> suggest that "permissionless innovation" is something of a marketing >> term, and it goes undefined within the document. If you are going to >> use it, you should explain what it is and why it is important. >> > We could add this definition to the glossary: > > "Permissionless innovation," is the freedom to explore new technologies= > or businesses without seeking prior approval. > > from: Thierer, A. Permissionless Innovation: The Continuing Case for > Comprehensive Technological Freedom. Mercatus Center at George Mason > University, 2014. > That is as good as any, but then I would say there should be some discussion as to its relationship to human rights. And that in itself will also inform you as to how much of the open standards discussion should be captured. Eliot --HKeKDnFCw66fDX09OAHtido6no9TioxU4-- --1HRRG0k5h8baGKAVnAKn0biWtwKkpfwMe 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 iQEcBAEBCAAGBQJX4PyBAAoJEIe2a0bZ0nozx+4H/i656O0q/zpdf7+a/HX5Fq2z 0dCqryo87MDnYz5XAFfQxN0NyZXc8zCV4M96zwg8cOY7Kuxo+rOd/VPn13xKrHI8 n36E7wRzkg4KL6pJ3HlXL6XSveao7eHRZhvw8itdqIaxGW4LHS9YFZXqV7mxWGYD QHvCe5GBU6Xtn0oVk3RCEQo4y8AXwjTJ5Up87DYZAKCiZLHsFRBwNbNfQYPTFy7w cYfDySUn+8NdXMTyAj8sD2/avfhCU/4Tg1Qp5ZPTi+YVISv6IqHBrCxsXhd4Ylq2 JM3rOQs2YPRuByxjiiQ330ejo6xAeadO6PoT2R+3VyHgQXZpbdnxoAbwxe/96qk= =WYgM -----END PGP SIGNATURE----- --1HRRG0k5h8baGKAVnAKn0biWtwKkpfwMe-- From nobody Tue Sep 20 03:02:50 2016 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 A928512B691 for ; Tue, 20 Sep 2016 03:02:48 -0700 (PDT) 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 eX76XPgBGlk6 for ; Tue, 20 Sep 2016 03:02:45 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id C483B12B25E for ; Tue, 20 Sep 2016 03:02:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 032CD1111A for ; Tue, 20 Sep 2016 10:02:44 +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 BXFcf89Y2PnI for ; Tue, 20 Sep 2016 10:02:41 +0000 (UTC) Received: from mx2.yitter.info (unknown [155.93.206.61]) by mx2.yitter.info (Postfix) with ESMTPSA id 8825D10723 for ; Tue, 20 Sep 2016 10:02:40 +0000 (UTC) Date: Tue, 20 Sep 2016 06:02:37 -0400 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20160920100236.GB2685@mx2.yitter.info> References: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [hrpc] more on open standards and ipr 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, 20 Sep 2016 10:02:48 -0000 On Tue, Sep 20, 2016 at 10:29:56AM +0200, Niels ten Oever wrote: > > This might be a language issue. What is meant is that there is no IETF > definition for what an 'open standard' is. This gap is not quite an accident, though, and I think that may be part of the reason you're hearing some anxiety about the target audience for this document. And given that this is an RG inside the IRTF, I don't understand why an IETF consensus about what an open standard is would matter anyway. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Sep 20 03:49:57 2016 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 2357C12B09F for ; Tue, 20 Sep 2016 03:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 YUqIxhL5tANt for ; Tue, 20 Sep 2016 03:49:50 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76E212B14E for ; Tue, 20 Sep 2016 03:49:50 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id E604AB7ADA13 for ; Tue, 20 Sep 2016 10:49:48 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id D2AC8B7ADA14 for ; Tue, 20 Sep 2016 10:49:48 +0000 (UTC) Received: from [10.9.0.26] (tunnel.greenhost.nl [195.190.28.22]) by mail.article19.io (Postfix) with ESMTPSA id C470BB7ADA13 for ; Tue, 20 Sep 2016 10:49:48 +0000 (UTC) To: hrpc@irtf.org References: <9b81a665-6192-2623-86ec-bd4801210081@article19.org> <42126a3d-781d-ac78-b04b-8c84517765b3@cisco.com> From: Niels ten Oever Message-ID: Date: Tue, 20 Sep 2016 12:49:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <42126a3d-781d-ac78-b04b-8c84517765b3@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6VC2phshqOWlo8ewxfQdh3VKcrhwnMv4p" Archived-At: Subject: Re: [hrpc] more on open standards and ipr 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, 20 Sep 2016 10:49:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6VC2phshqOWlo8ewxfQdh3VKcrhwnMv4p Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Short answer: IETF community. Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/20/2016 11:08 AM, Eliot Lear wrote: > Hi Niels (and sorry for so many "finally"s that were not in fact final = ;-) >=20 > Summary: >=20 > I've the same problem as Andrew. Is your target audience the IETF or > the broader community? An answer to that question will help us in many= > ways. >=20 >=20 > On 9/20/16 10:29 AM, Niels ten Oever wrote: >> Hi Elliot, >> >> On 09/20/2016 10:05 AM, Eliot Lear wrote: >>> Hi Niels and everyone, >>> >>> Following the previous discussion I would propose a few changes: >>> >>> >>> >>>> Explanation: The Internet was able to developed into the global >>>> network of networks because of the existence of open, non-proprie= tary >>>> standards [Zittrain]. They are crucial for enabling >>>> interoperability. Yet, open standards are not explicitly defined= >>>> within the IETF. =20 >>> >>> This would be considered news to most people at the IETF. That doesn= 't >>> mean the IETF does ALL open standards but all IETF standards are as >>> close to open as any I know. =20 >> This might be a language issue. What is meant is that there is no IETF= >> definition for what an 'open standard' is. >> >> Indeed it's not clear that the focus here >=20 > Well so this is the issue. Is this draft intended to address just the > IETF or be more broadly applicable? If you want it to be more broadly > applicable the trick here is to use the IETF or other SDOs as examples.= =20 > Remember, we're here in the iRtf and we don't need to focus on the > IETF. Choose wisely ;-) >=20 >=20 >>> Again here you may wish to use the IETF as an examplar, but not make >>> this about the IETF. By the way, OpenStand is probably worth conside= ring. >>> >>> Finally, I think it's useful to explain some of the complexity around= >>> open standards. This is not an easy subject. There was an excellent= >>> article by Steven Levy on the impact of normative references in >>> code.[1] Some of us remember Carl Malamud, who used to participate i= n >>> the IETF. This is a great read, and his cause is good. But the IETF= is >>> in a bit of a privileged spot: ISOC and ICANN foot our bills and thos= e >>> of the W3C, at least in part. That helps keep things open. Other >>> standards organizations still have to pay the bills. Some do that by= >>> selling documents, others do it through membership fees as a price of= >>> influence. Traveling around the world to participate is also >>> expensive. And so there are many aspects that limit openness. At th= e >>> same time, openness tends to slow things down. In a hot market, that= 's >>> death to a young company. >>> >> Not sure if the ecnomic models of open standards are within the scope = of >> this document. >=20 > I'm sympathetic to the idea of not wildly expanding the scope of this > document or research group to go beyond human rights. But I think this= > hangs on the notion of whether permissionless innovation is a human > right, and then whether open standards are required for permissionless > innovation. Carl's work, and the quote from Justice Breyer, get to the= > heart of the risks of normative references by laws themselves. In this= > sense, the IETF is just about ideal for a reference, not that most of u= s > would encourage any such references (what happens if we update an RFC, > for example). And so again: it depends on your intended purpose. If i= t > is to inform society about the relationship between standards and human= > rights, the I would say there is a relationship. If your intent is to > improve IETF processes through an informational document within the > context of the IRTF, then I would say it is possible to scope down. Bu= t > that does limit the applicability of your work. Again, choose wisely. >=20 >=20 >>> I would finally point out that open standards on the web is almost an= >>> oxymoron. Much of the communication to and from the browser is in >>> javascript, and apps on your phone are written generally to be >>> two-sided, such that there is NO standardization. Should there be?=20 >>> What is the value to society and what human rights are at stake? =20 >> I am not sure whether web standards fall within the scope of this draf= t. >=20 > See above. If you are strictly focused on the IETF, I guess you're > right, but I would claim that then this is a missed opportunity. >> >>> This >>> causes me to think a bit about the hourglass model and how we >>> standardize at its neck more so than elsewhere. >>> >>> And this brings me back to an earlier point: if this draft is intende= d >>> to inform the discussion, let's insure we have captured these sorts o= f >>> complexities. And then if there are clear recommendations to be made= , >>> let's hear them. >>> >>> >> I think starting of with documenting the issues is already a great ste= p, >> actually. >=20 > Ok. How much depends on the answer to the question at the top of this > email, right? >=20 >> >>>> Open standards are important as they allow for permissionless >>>> innovation, which is important to maintain the freedom and abilit= y to >>>> freely create and deploy new protocols on top of the communicatio= ns >>>> constructs that currently exist. >>> While I like a good turn of phrase as much as the next person, I >>> suggest that "permissionless innovation" is something of a marketing >>> term, and it goes undefined within the document. If you are going to= >>> use it, you should explain what it is and why it is important. >>> >> We could add this definition to the glossary: >> >> "Permissionless innovation," is the freedom to explore new technologie= s >> or businesses without seeking prior approval. >> >> from: Thierer, A. Permissionless Innovation: The Continuing Case for >> Comprehensive Technological Freedom. Mercatus Center at George Mason >> University, 2014. >> >=20 > That is as good as any, but then I would say there should be some > discussion as to its relationship to human rights. And that in itself > will also inform you as to how much of the open standards discussion > should be captured. >=20 > Eliot >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --6VC2phshqOWlo8ewxfQdh3VKcrhwnMv4p 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 iQEcBAEBCAAGBQJX4RRMAAoJEAi1oPJjbWjp/gUH/R/dMV6e8wF/ERn/LTLxs63N EU6nZv3/CwYWwtqU1MZRsP4syRXl5+FmQsE1rQALjCFl7cg3Jg2Era3kvdUVCzsj M06LlFErCL0fwqybJ7hhIJXxRbSEThmKqUIeTjmoM5B9xJwfFESX9wDNno4h/wW/ U6ETpD/nxEUbALm7TGTqw1qSArhPhzm/hfVGtfLbGslPwZrNgOs7EABVglZm1n3f oBXHzyNAcb8FckIq+VwB7xv/tkReAjDu7dz0BCix9SSlpImbfr7zbMKkQqkDb8cn /ik6gK66Rmnv/RaZyTmAjh1mfVOkaZ5uvouAiQhR6vhIc+Km6Dzusl7FPHOX5rQ= =MqGy -----END PGP SIGNATURE----- --6VC2phshqOWlo8ewxfQdh3VKcrhwnMv4p-- From nobody Tue Sep 20 08:16:58 2016 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 CFEB812B867 for ; Tue, 20 Sep 2016 08:16:55 -0700 (PDT) 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 OEC8rLrPA0IG for ; Tue, 20 Sep 2016 08:16:53 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6533112BB29 for ; Tue, 20 Sep 2016 07:54:38 -0700 (PDT) Received: from filter.hostedemail.com (unknown [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 554CBC2120 for ; Tue, 20 Sep 2016 14:54:26 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:355:379:599:800:854:967:973:988:989:1042:1049:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1513:1515:1516:1518:1521:1534:1543:1593:1594:1605:1683:1711:1730:1747:1777:1792:1801:1963:2288:2393:2525:2553:2568:2627:2682:2685:2741:2743:2771:2859:2891:2895:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:4321:4362:4425:4605:4860:5007:6117:6119:7652:7903:8985:9010:9025:10004:10400:10848:11232:11658:11914:12043:12050:12109:12114:12291:12379:12438:12683:12740:13019:13071:13161:13229:13618:13846:14096:14097:14180:14181:14721:14819:21060:21080:21366:21433:21451:30022:30046:30054:30060:30070: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:3, LUA_SUMMARY:none X-HE-Tag: iron61_26b01b1baba5d X-Filterd-Recvd-Size: 4568 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 omf01.hostedemail.com (Postfix) with ESMTPA for ; Tue, 20 Sep 2016 14:54:25 +0000 (UTC) References: <147426649458.15026.17311272259655986875.idtracker@ietfa.amsl.com> To: hrpc@irtf.org From: avri doria Message-ID: Date: Tue, 20 Sep 2016 10:54:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147426649458.15026.17311272259655986875.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 160920-0, 09/20/2016), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-00.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: Tue, 20 Sep 2016 15:16:56 -0000 Hi, Thanks to Niels and Corrine for this update. While I want to start the RGLC as soon as possible, I want to make sure that anyone who is actively reviewing this draft before the RGLC, has a chance to finish their review before the documents changes under them. Already got one request to hold until comments were sent in. I have asked the authors to hold off with a correct update until ongoing reviews are in, or so delayed as to be worth including in the RGLC on the -01. Curious if anyone else in the 'in active review' situation. If so, please let me and/or the list know. Hopefully any of these reviews can come in within days to a week so we can take the next step. Thanks avri On 19-Sep-16 02:28, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Human Rights Protocol Considerations of = the IETF. > > Title : Research into Human Rights Protocol Considerati= ons > Authors : Niels ten Oever > Corinne Cath > Filename : draft-irtf-hrpc-research-00.txt > Pages : 71 > Date : 2016-09-18 > > Abstract: > The evergrowing interconnectedness of Internet and society increases > the impact of the Internet on the lives of individuals. Because of > this, the design and development of the architecture of the Internet > also has a growing impact on society. This has led to an broad > recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in > the development and management of the Internet [HRC2012] [UNGA2013] > [NETmundial]. It has also been argued that the Internet should be > strengthened as a human rights enabling environment [Brown]. > > This document provides 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, and a proposal for guidelines for human rights > considerations, similar to the work done on the guidelines for > privacy considerations [RFC6973]. > > 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-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Thu Sep 22 05:43:10 2016 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 CF28D12B845 for ; Thu, 22 Sep 2016 05:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 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=-2.316, 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 D7rbio-mGYvd for ; Thu, 22 Sep 2016 05:43:04 -0700 (PDT) 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 8F75B12BE81 for ; Thu, 22 Sep 2016 05:33:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 43C77BE47 for ; Thu, 22 Sep 2016 13:33:48 +0100 (IST) 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 EhGvYJrrjZvS for ; Thu, 22 Sep 2016 13:33:43 +0100 (IST) Received: from [172.28.172.2] (unknown [109.125.19.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E44E6BDCC for ; Thu, 22 Sep 2016 13:33:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1474547623; bh=3XIZitlEJLMEvVQ3e2PeH/ElszlLF9udCzFqwo8+TlI=; h=To:From:Subject:Date:From; b=1U3rkY6txv1OL32DHJwGwrLy0MM4XfONGvmD3cqZbpotSEWiypu4qfCZd/otUU1Dp 0hYff6tOis720Yv7t4BG8CRAz//4MTAf5H7dDIMCa+wRnJlTUMwMlCc1k4RyaotpG7 yF6+WknByF6z6V/eoDmoU2YweAzbvJ0z8uqd8spY= To: "hrpc@irtf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 22 Sep 2016 13:33:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090200000604020501070409" Archived-At: Subject: [hrpc] review of draft-irtf-hrpc-research-00 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, 22 Sep 2016 12:43:09 -0000 This is a cryptographically signed message in MIME format. --------------ms090200000604020501070409 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I spent a bit of time reviewing this finally. Overall, I think this is a fine piece of work and I look forward to it becoming an RFC. I don't think it's nearly ready yet though, there's a lot to fix. (But see #1 below for a suggested short-cut.) Cheers, S. General, and, I think, important to handle... (1) What kind of consensus are we aiming for here? I'm not sure if this would be better off aiming to be a document that has RG consensus or not. There's a lot of fine text here, but there's also quite a few instances of text for which I think it may be quite hard to establish RG consensus, and where that may take some time and draft iterations. (You'll see some examples in my specific conments.) Clearly, processing the document aiming for RG consensus is an option, and maybe the default option, but I wondered if it'd also be an option to proceed more quickly with this documenting the author's research and opinions/conclusions (and not necessarily RG consensus) and to then later try to extract an updated version of the guidlines/questionnaire into a separate RFC aiming for RG consensus. I'm not arguing strongly for that latter plan but just wanted to ask in case it helps the RG (and Avri who I guess will have the fun of figuring this out:-). (2) Length and structure for protocol developers. I think this is too long to be very useful for protocol developers. I doubt many of them will wade through 40+ pages to get to the bit that's really aimed at them. (And which pretty much needs a total re-write.) The plan mentioned in #1 might help there I guess but another idea might be to move section 5.3.2 to the front and make a lot of the rest of the text into subsequent explanatory material and/or appendices. (3) What architecture do you mean? There are 25 lines that mention the term architecture in the draft and I'm not at all sure the term is used to mean the same thing throughout. I'm also not sure that there is an accepted thing that is "the one true Internet architecture" that has IETF consensus but you seem to me to be assuming that there is such a beast. Is this just a language issue or a deep(er) problem? I'm not sure, but eliminating references to the Internet architecture where possible would I think help. See some of the specific comments below, but I'd recommend a pass over the document to check how this term is used as well. (To try head off some lines of debate that might follow from this comment, I do think there are aspects of Internet architecture for which we do have IETF consensus, but I don't think the IETF has consensus on any one way in which to put all those together into something that'd be rightly termed the (or an) Internet architecture. I think RFC1958 section 2.1 supports that position btw.) (4) What does "=3D" mean here? In section 2 and later (in 5.2.2) you have diagrams with bracketed terms on the left, then "=3D" and then another term on the right. I just don't get what you mean by that "=3D" sign. You say "combine" and "makes up" but frankly I don't get it, even though I was in some of the meetings where those pictures were presented. E.g. in section 2, I don't get how to combine authenticity and anonymity in any useful sense, as those are mostly in conflict. And the 2nd picture in section 2 has connectivity on the RHS, which you defined as being an "extent" and none of the things on the LHS seem to reflect that at all. While those pictures may well have been ok for use in presentations, I'm less happy that they're useful in an RFC. So, what does "=3D" mean? Can you actually define that relation? (Apologies if I'm being all "techie" and anal here, but I really don't get it, honest;-) (5) The DDoS discussion is still wrong. I think the discussion of DDoS in section 5.2.11 (see below for specifics) is not good enough and that section needs to be re-written or mostly deleted. (Not all list discussions need to end up with a section in the document.) It may be the case that what is needed is some discussion of forms of protest using the Internet, but that I think would better be the topic for another document, if soeone has the energy/interest. (That could be interesting too!) For this document, if it is aimed at the IETF audience, the current text is not useful as it ends up as a (controversial) NOOP - "don't enable DoS" is already in RFC3552 since 2003. (6) The questionnaire is not good enough. 5.3.2.x.y: Please go through these questions yourself (for some protocol) and write down answers and see then what you think of the questions. I think a number of these questions will not produce meaningful answers in any real attempt at using them. I also think that someone who is not an author and who is developing a new protocol needs to have gone through the exercise at least once before we should publish this document as any RFC. It is far too easy to ask unanswerable or non-useful questions otherwise. (7) Missing introductory text. I think there's a missing bit of explanatory text about rights in general that'd help some more IETF-oriented readers. As I understand it, in HR all rights are contingent in the sense that governments are expected to balance competing rights in all cases. So e.g. even though we have a right to life, governments can legislate for capital punishment and still consider themselves signed up to the UDHR. I think this is worth noting, as for example, it means that we do not necessarily want to enshrine all the fine concepts on which the IETF has consensus as human rights, in particular, claiming that one had a right to encrypt could as a side-effect allow some governments to claim that they had a right to limit one's knowledge of mathematics, if that is claimed to compete with other rights (e.g. to safety). I'm not sure if this is the right HRPC document to capture that, but it was a surprise for me when I first found that out, so it may be worth adding a bit of text explaining basic rights concepts like that here or somewhere else. Specific comments (without reference to importance:-) Note: I'm not quite sure why, but I read this through and commented as if it were a PhD thesis, which is a bit more stringent that e.g. IESG evaluation. Apologies if that seems like nitpicking, but I think given the possibly political (ab)uses to which this RFC could be put, and since we might effectively kill the impact of the RG if we do this first RFC badly, we might be better off to take that approach. I'm willing to believe that I'm being too nit-picky though:-) abstract: These ought not have references and I think is too long. I'd suggest keeping the 2nd para (minus the reference) and move the rest to the intro. intro, p3: How do you know that "open, secure and reliable" are necessary conditions here? I think you're likely correct, but I'm not sure that claim is justified in the document or in the references. intro, p3: "The Internet aims to be a global network of networks that provides unfettered connectivity to all users at all times and for any content [RFC1958]. " The "aims to be" there seems odd, and I don't see where 1958 says "at all times" which seems to me overstated. intro, p3: "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 network." Sure one could argue that but is that claimed as an RG consensus? And you're assuming that there is one true Internet architecture there I think, which is problematic. intro, p3: "By doing so, the IETF enabled the manifestation of the right to privacy, through the Internet's architecture." I think this shows a misconception of the IETF's role, at least as I see it. I don't believe that the IETF controls the Internet's architecture in the sense implied here. If you'd said "through it's protocol design processes" at the end instead, then I think that'd be better. And saying "Enabled" makes it sound like a done-deal and we can all go home, which strikes me as pretty optimistic;-) intro, p3, "Openness of communications of the technical design" what does that mean? And how does it "foster freedom of communication"? I don't get the argument here. intro, p3, "galvanize" is overstated and the IETF doesn't "ensure" what happens in the network, but only in the protocols we define - what implementers and operators do with that is really up to them and not the IETF. That's an important distinction that's mixed up in a few places in the document, including in the next sentence - if the IRTF produces this RFC, that's great and will help to ensure better realisation of HR issues, but the existence of the RFC itself will not ensure anything. section 2: "unfettered" - while I myself do like that term, I think following the approach from RFC 4084 which you quote here would be a good general approach for this entire document. 4084 section 1.2 says that it intentionally avoide pejorative terms so as to increase the likelihood that operators will pay attention. I think following that guidance in this document would be good. Most of the text is actually fine in this respect, but an editing pass based on a review from some (as yet uninvolved) protocol developers would be a good thing. For example, some of the references to companies and products later on might raise hackles in a way that'd be counter productive. Anyway, 4084 does not use the term unfettered at all so better to not say that here. section 2, and elsewhere: I think the use of the term anonymity is wrong in almost all cases in this document. While it is the case that users (and non-technical folk in general, including law makers) may talk about anonymity, I think there are few to zero technical folks who think that anonymity is achievable at any scale today. Tor may be the closest we get, but it's not at all clear to me that anonymity is really a requirement or a goal for almost all protocol designers almost all of the time. I do think we should consider "being hard to track" and similar as requirements/goals but that's different and I'm not sure we even have that good an idea about all the trade-offs that are involved here. I'd recommend checking every time you use this tern, and getting rid of most of them. (Will try to point out the ones I think are problematic below.) Note that the 4949 definition is probably ok(ish:-) but once there are muliple protocols involved things become very unclear and in real networks, there's almost always someone somewhere who can identify (or re-identify) a person, host or bit of s/w and that context seems to be missing here when you use the term. 2, Defining connectivity as an "extent" is interesting. I'm not sure if it's precise enough though, e.g., what'd "twice better connectivity" mean? Not sure what to suggest but I do think you're right to not define it as binary. Maybe refer to RFC4084 here again for some different types of connectivity? 2, "content-agnosticism" - hmm, that seems a bit broken to me as a definition, it is ok to treat delay intolerant traffic differently and we do want that sometimes. "Identically" seems too strong, but I'm not sure what better definition to use without getting into an essay about net neutrality and similar things that I don't know much about;-) 2, "end-to-end" - I much prefer to refer to this as an argument and not a principle. You'll get different opinions on that though:-) 2, "Internet censorship" - I think this definition is too broad and could even be read to discourage data minimisation. It seems to be missing the concept that the censor is acting without the agreement of the endpoints, but agreement/consent is such a slippy concept on the Internet maybe that'd be a bad idea. Anyway, this seems to broad to me fwiw. 2, "Internet Standards as an Arena for Conflict"... eh... What? That's not a term to define, it's an argument for over beer! I think you need to delete that from this section. If you want to include the text somewhere then find a better way to do that I'd say. (But I'd still then ask: where is the principle of constant change defined for all time? :-) 2, "i18n" - I think you're wrong that "Many protocols..." don't support i18n. It's for sure true that a bunch don't do this well and ought, but "many" seems overstated. Did you count them? (Note that for many binary protocols i18n isn't very relevant at all, if one assume that i18n is mostly important for end-users and less so for developers or bigger operators.) 2, "Open Standards Conform" - what? That's not a term to define. I think you also say this elsewhere so deleting this would be right. And what's RFC2606 got to do with it? 2, "Openness" - I think this is just wrong and am not sure what you even want to define. You cannot for example have free access to hosts in my home network, no matter how openly you ask:-) If you want to define openness, then I think it'd have to be about processes and not access to hosts. 2, "permissionless innovation" is not all about new protocols. It's also about using existing protocols in new ways without having to ask. Not all such uses are usefully described as new protocols. 2, "Privacy" - I think adding some references to the HR and legal literature about privacy could help the more technical readers here. 2, reliable, resiliance and robustness - I'm surprised there're no references for the first two and puzzled by the references for the 3rd. There also seem to be very few reference to these later, which makes it odd to find them here. I wonder if the formalism you're using (introduced at the end of section 2) has caused you to shoe-horn in definitions of these? 2, scalable - it's often a challenge in proocol design to ensure that a protocol scales down as well as up, in the sense of working well for smaller networks/deployments. Might be worth pointing that out as it's relevant here when one considers designing new protocols potentially putting too much emphasis on the requirements of only bigger operators (who are in the room). 2, stateless - is used exactly once later, and stateful is not used at all later - do you really need this here? (Just define it when used, but I think protocol developers will get the meaning anyway.) You could also say that retaining state has potential privacy impact, which may not be so obvious. (That retaining state impacts on other protocol features such as hard-reboot is fairly well understood I think.) 2, "Strong encryption / cryptography" I don't think this is needed or useful - why is it here? I think the IETF community know this already, is it useful for some other readership? If so who? (Since I'm not sure it'd be that useful for any readership.) 2, "transparent" - I don't like this definition which I think is not actually definining the term in the sense in which you use it in this document. As you actually use the term, it is mostly about processes, which is not what RFC2775 is about. In fact, I think you're actually using the term in it's normal English usage and don't really need a specific definition. (Though I didn't check all uses of the term.) 2, " The combination of reliability, confidentiality, integrity, anonymity, and authenticity is what makes up security on the Internet." No. That is just wrong. For example, that list omits DoS resilience, bugs (and protocol flaws) that cause problems like heartbleed, and I think, much else besides. I'm not sure how to fix this. (But see my general question wrt "=3D" as used here.) section 4: I don't accept that "protocols are politics by other means" - if I develop a way for two computers to interact in my (non-existent as it happens:-) basement, that is not politics. If I publish an academic paper on a faster way to do ECDH that's not politics. I know it's a quote, but I don't think you ought present that quote in that way (reading IMO as if it were an RG consensus statement) without qualification. The relevant qualification I think is tricky to formulate but has something to do with broad deployment or with deployment at some technical choke point that offers significant control to someone. 4: I don't get the "values-by-design" point and how it's relevant to the IETF. I don't recall discussions about that on IETF/IRTF lists. Is this perhaps something that's really being discussed outside the IETF/IRTF context? If so, then the statement that these are a "new focal point" is not correct. (If you want to say this should or could be a discussion to have, that'd be fine but that's a different statement.) 4: "tools of enforcement" - I'm not sure what you mean here. If you mean law enforcement then saying that would be better, but the sentence is vague, for me anyway so would be better rephrased. 4: "This document sets out some preliminary steps and considerations for engineers to take into account when developing standards and protocols." I think that's a good and fair statement of where this document is at. But don't you elsewhere go further? (CHECK) section 5: It'd be great if you could add links or references to the source materials here. For example, who'd you interview? Are the videos avaiable? What's the list of RFCs you read and which were considered (most) relevant? Similarly for WG lists analysed etc. I'm sure you have all that stuff and making that available for later would be great. 5.2.1.4 and 5.2.1.5: (See general point #4 above about "=3D") I don't think you actually have achieved this "the creation of a list of technical concepts that when combined create an enabling environment for human rights." It's a fine goal, but I'm not sure it's achievable in reality with the kind of precision claimed in this section. I don't think the terms used in the figure in 5.2.1.5 are at all precise TBH, e.g. the phrase "good enough" only occurs in this figure and nowehere else. 5.2.3: "These capabilities for network control and limitations of the freedom of expression by end hosts can be traced back to the IPv4 design..." I don't think you have justified this claim. My argument would be that there is no simlarly scaled/robust nework against which to compare IP and that does not have the feature that it allows deployments to limit freedom of expression. So it may be that this feature/bug is not IP specific but inherent in large networks. In any case, the claim seems too much to me. (That might be a useful topic for the RG to tackle, or maybe someone has already studied this issue?) 5.2.3.1: On what do you base the claim that source-routing could be better here? Source-routing seems to usually generate objections from transport folks. (You'd have to ask them for the history of that.) Spoofed source IP is a common mechaism for abuse. While you do say these are not considered good practice, you don't say why (or provide a reference) so it looks to this reader as if you're saying that those "features" could have been better, but without evidence for that. (Tor is lovely, but as currently defined, would not scale to the size of the Internet as it was quite some years ago.) 5.2.3.2: are you referring to the protocol number here? (As listed at [1]) That has about 140 protocols many of which aren't in widespread use. If so, then I question the claim that this is really the cause of DPI - I suspect that DPI devices mostly look deeper into the packet. That also seems to be indicated when you talk about transports and spdy. I think this section is confused about the differences between headers at various layers, and our history of sending cleartext. That said, I could see that in future, as we encypt more Internet traffic, someone may find rights-invading ways to use layer 3 headers but I'm not sure this is a significant issue today. (If there is evidence of this being done, I'd be interested in knowing about that. I guess there may be IPv6 options that are in use like that or have been suggested but you don't cover those at all that I can see.) [1] https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 5.2.3.3: I don't think mobile IP could never have displaced NAT for IPv4. We'd still have run out of addresses. So I'm not sure the point made here (that there was a "viable alternative") is correct at all. 5.2.4: "which enact ICANN's policy" Do you thnk that the ccTLDs would agree with that? I don't. 5.2.4: I think the fact that new gTLDs are hugely expensive is well worth a mention, as a deterrent to various freedoms. 5.2.4: I think you're missing some points here, maybe even an entire subsection. One of the ways around some of the issues listed is for clients to choose their resolver, e.g. so as to pick one that does check DNSSEC or that is not subject to the same regime as a default resolver. That can be blocked at the IP level, which is one issue. But even if I do that and use DPRIVE, then that creates a new threat of centralisation of lots of queries (e.g. at 8.8.8.8) which introduces yet another point at which control can be enforced or where traffic can be analysed. Passive DNS also has good and bad aspects. I'd say some or all of these points would be good to note. (But I'm not the right person to suggest good text sorry.) 5.2.5: The lack of a mandate for TLS was not the only reason why the web started out largely cleartext. There were also significant performance, UI, tooling and missing infrastructure issues, as well as the charging per certificate business model. Those were more important issues IMO, even though they do not nicely tie into the discussion of h2 and it's lack of a mandate for use of TLS. While I personally regret that, it was the result of a real and extended and open debate, which I think also ought be noted. 5.2.5 and 5.2.5.x: While I'm fine with you calling the development of TLS MitM devices and similar "malicious," I am pretty sure plenty of folks might argue that. It'd be better to skip the pejorative language I think, but it is entirely correct to have the references to the attacks mounted using such technologies. I'd also tend to not mention specific companies and products in the body of the text, except where that is really necessary to make the point. 5.2.5.1: How do you know it was Snowden's relevations that caused mail service providers (not ISPs!) to "follow Google's lead"? That may be correct, but I'm not sure there's the public evidence that they said that was why. (If there is, great, but please provide a reference, the one you do provide, [Peterson], is about gmail and not yahoo.) Also, Google use TLS, not SSL for gmail. 5.2.5.1: "less democratic" - I think it's an error to say that, since many countries that are considered role models for democracy could do the same things, "some countries" and examples would be better. Same with "oppressive regimes" - there's no need to include that judgement here. The reference here [RSF] wasn't accessible to me (no route to host) from a hotel network and eduroam. That could be nicely ironic, or a badly chosen reference. (But you need a reference.) The 2012 Libya report also really needs a reference. [RSF] https://en.rsf.org/syria-syria-using-34-blue-coat-servers-23-05-2013,4466= 4.html 5.2.5.2: wrt great-cannon, you might want to note that the IESG issued a related statement [2]. That's a bit tangential, but I think is relevant for this work. [2] https://www.ietf.org/iesg/statement/maximizing-encrypted-access.html 5.2.5.2: "Companies like" is pejorative and the patent application seems irrelevant. "has been largely documented" calls for a reference. "Oppressive regimes" is also not needed here as is "little concern for bad human rights records." The right thing here I think is to note the documented record without pejoratives and to then let the reader draw their own conclusions. 5.2.5.2: I don't think the text about h2 is fair. You're missing a) that there was a real and open debate on the topic, b) that some important implementations are exclusively h2/tls and c) that there is a spec for OS for HTTP being developed. Those are all as relevant as the fact that the outcome of the debate was to not mandate use of TLS all the time. (Which I do think is worth saying in this document, but needs more complete context.) 5.2.6: I think this section is missing some things. First, the IETF/XSF relationship is relevant here and needs a mention. (As both good and bad!) Second, OTR is important, as is the community's failure to produce a better e2e standard for xmpp. And lastly, I think the tendency of IM deployments to not deploy interoperable standarsd is missing, which also has good and bad aspects (good: they can do telegram etc, bad: no interop). I'd suggest asking an XMPP expert to review/suggest text. (Happy to help find you one if needed.) 5.2.6: "The protocol also has facets that may stifle speech as users self-censor for fear of surveillance, or find themselves unable to express themselves freely." That's not an XMPP specific point - the same applies to email and the web and to any other protocol that supports interpersonal messaging or access to sensitive information. I think you ought up-level this point to a more generic section that calls out issues with multiple protocols. (Not sure where exactly, but having it here only isn't great.) 5.2.7: Is this section about P2P in general (I'd consider P2P a design pattern) or about PPSPP or about BT? Each of those choices seems wrong. If the first, then that's not the same as other 5.2.x sections and doesn't mention other P2P protocols (e.g. RELOAD maybe). If the second, is the deployment of that sufficient to justify the text? If the 3rd - that's not an IETF protocol. So I'm not sure what to make of this. 5.2.7: Is it still true to say that P2P is an "increasingly becoming a popular architecture"? I thought usage stats were showing the opposite nowadays? The examples given are odd: as BTC doesn't do file sharing/interpersonal messaging, skype is no longer really P2P iiuc, and I don't know if spotify really is or not. Surely BT is the canonical real example? 5.2.7: "mostly delegated" - I'm not sure this is correct. I could argue that RELOAD is a counter example. I could further argue that the lack of deployment of RELOAD (iiuc) may be evidence that your implied argument that it'd be better for an organisation like the IETF to try produce complete specs in this space might be unwise in that it's less likely to result in deployment. 5.2.7.3: I think ledbat has some protocol features that would allow deployments (if they are nice) to reduce the scope for tracking. That's RFC 6817 but I'd have to reread it to check if there's something useful there, also not sure about ledbat deployment. 5.2.7.4: Sybil attacks in this context (e.g. astroturfing) seem to be relevant to more than p2p protocols. In fact wouldn't they be more common on web based systems, at least as exploited by/for governments and commercial entities? 5.2.8: There are many kinds of VPN - I think it'd be better to rename this section to something like "personal VPNs" or similar, as you don't get into e.g. corporate VPNs. 5.2.8.1: "local illegitimate wiretapping" - that's another pejorative term for some, "monitoring" would be just as clear. (Again, not because what you say is wrong, but because there's no point in antagonising those who read this.) 5.2.8.1: "are way less analyzed and understood" I think I recall some papers on these kinds of VPN that found some issues - be good to reference such work if possible, esp if there's a survey. 5.2.8.3: " VPN providers should at least be transparent on what information do they store and for how long is being kept" I fully agree with this, but what's it telling the IETF readership? Perhaps that RFCs ought identity potentially sensitive logged data or for how long that needs to be retained for technical reasons? That migth not belong here anyway but could be relevant somewhere in the document. 5.2.9: This could be shorter and may better as a part of section 5.2.5 - why is this one status code so important? 5.2.10: I'm really not sure this (all) belongs here. The middlebox debate is old and won't be resolved here, so I'm don't think it's worthwhile regurgitating the arguments in such detail. And I think you already said what you need to say when discussing NATs. I'd say deleting this section is maybe right. 5.2.10: (If you keep it) "IETF's role to prevent such censorship" again, the IETF is not the Internet police and does not "prevent" things like that. If you refer to the SPUD BoF, you should include references to the minutes etc. 5.2.10: "Middleboxes are becoming a proxy for the debate on the extent to which commercial interests are a valid reason to undermine the end- to-end principle." That seems like an opinion, and one I'd be surprised had consensus. Do you need to say that? 5.2.11: "Some people may say that DDoS attacks are the only mean to be heard, in the current Internet." Some people say that the moon landings were faked. Vague reportage like that is useless. I'd say this entire section needs to be redone with a strong statement that there is no valid use-case for DDos, and that DDoS is not a valid form of protest. I think such a statement is one that would have RG and indeed IETF consensus. I'm very sure that no concept of DDoS as a valid form of protest would garner consensus in either the RG or the IETF. 5.2.11: "seem to suggest that the IETF should try to ensure that their protocols cannot be used for DDoS attacks" That's very understated and maybe even misleading. I would say that the IETF has long-standing consensus that DDoS is an attack that protocols should mitigate to the extent they can and that DDoS vectors in protocols are basically bugs. RFC3552 (section 4.6) from 2003 covers this and says that standards MUST describe DoS issues. 5.2.11: The linkage between private sector control of networks and DDoS is IMO entirely unconvincing. NRENs are generally private sector and have major issues with DDoS. (I'm sitting in a talk on that topic right now.) It is not at all clear that anyone who'd claim that they are using a DDoS attack to protest would actually be protesting about a network operator - it is much more likely they are protesting about some content owner, who may be public or private sector. 5.2.11: I don't think we need or want the argument based on PM here at all. The argument about motivations for PM in RFC7258 depends on there being some justifiable reasons for monitoring. (Otherwise we would not need to even point out that motivations don't matter.) There are no such close-to-good arguments at all for DDoS, so drawing that analogy is misleading. 5.2.11: If the RG feel there is a need to discuss a possibility for fully opted-in people to collectively protest, (I do not) then you should invent a new term for that and clearly say that even though such protest might appear to the network as beng the same as a DDoS (and hence be treated as an attack), that is not the same as a DDoS, where 100% of real cases involve compromised hosts or hosts being used as reflectors without permission. If the RG feel there is a need to discuss forms of protest on the Internet, then I think an entirely different section is needed, probably with a different structure. 5.3.1: I'm not sure the "HR threats" model is the right thing here. The same was true of rfc6973 as well, as you say, but in this case, I'm not sure you really even need the concept. 5.3.2 just says stuff like "did you think about " so I don't see a need to say that " is a threat." I don't think you lose anything by losing that concept entirely. There is also a danger in including that risk analysis model here in that doing so might cause later disussion to be somewhat blinkered. 5.3.1: "This is by no means an attempt to cherry picks rights, if other rights seem relevant, please contact the authors and/or the hrpc mailinglist." I'd delete that, it's not that appropriate for an RFC (it was for an I-D). But if you do want to say something about a contact point, the RG list would be better. (The phrasing "cherry pick" is also a bit odd.) 5.3.2: The title here is a bit inaccurate and misleading. You're presenting guidelines for protocol designers, and not for "HR considerations." 5.3.2: I don't think that many IETFers follow or read RFC4101. (RFC4101 is a useful, good thing, but one that's not much used iiuc.) 5.3.2.1.2: We're updating RFC3552 now, and the update will include some guidance on privacy considerations. I'm not sure if it'd be better to reference that draft now or not though, as it's early days. Probably best to refer to BCP72 though, as that'll remain the right reference when the 3552bis work is done. 5.3.2.1.2: "Could your protocol counter traffic analysis, or data minimization?" oops - I don't think you want to counter data minimisation. Better to split that into two questions probably. 5.3.2.1.3: This set of questions need work. All protocols "look at the packet content" or else do nothing at all. I think you want to ask people to think about which fields in the packet they need to access and to try to minimize those, and if possible, discourage others from looking at the rest (e.g. by enabling encryption of those). I also have no clue what " Is the protocol transparent about its decisions?" means. And the last question is also pretty meaningless when looked at in isolation. (I think I already commented on the agnosticism phrase as used here before. The same issues apply to the explanatory text here.) 5.3.2.1.5: "readable by humans" is not the right criterion here. What you need to say is that "have to be understood by humans." For example, DNS names are mostly readable but IDNs are not, depending on which form one uses. For some protocols it is entirely fine still to use ascii for human-readable labels, if those are only seen by developers or more capable admins. 5.3.2.1.6: Re-using existing identifiers (e.g. MAC addresses) is the more common way that (re-)identification is enabled in protocols. You should point that out. I think the "make ... transparent" point is worth splitting from the identifier issue too - identifiers are very common, but making filtering apparent is much less so, and will be missed if you bundle these two things together. The last two questions aren't really useful though and are more explanatory text then real new questions. 5.3.2.1.7: These are not useful, as phrased for IETFers. The only useful part here is the 2nd last question (use other things that are proprietary), the rest are not as they are already handled in IETF processes, and we do not want yet more bureaucracy. The explanatory material is way too long and also not useful for the IETF audience. The example given is an interesting thing, but far from a typical protocol, so therefore is not a good example. 5.3.2.1.8: This entire section is useless for IETFers, except the last question about extensibility. The explanatory text and example however don't address that and are also not useful. 5.3.2.1.9: The question was asked already. Anonymity is not a useful goal in almost all IETF protocols, and if it were, it'd be a first order requirement (e.g. if we wrote an RFC for Tor) and would not be missed. Delete this section entirely. 5.3.2.1.10: The emphasis here is wrong. You should be asking about whether the protocol generates or processes anything that can be, or be tightly correlated with, PII. Many protocols have identifiers that are perfectly safe, until the host running the protocol is something that a person carries with them. The section needs a rewrite to take that approach. 5.3.2.1.11: Mixing accessibility and statefulness is wrong. Both are fine questions, but should not be bundled. The example is bad - HTML5 is the current spec and is not that RFC. 5.3.2.1.12: I think this is arguably duplicative and the issue will (or should) be caught via other IETF processes apart from HR considerations. I'd delete this, though it's mostly harmless here. 5.3.2.1.13: Again, this bundles things in a counterproductive manner. Split the topology/architecture points from the discriminaton/implication ones. (Even if you think those relate in terms of HR, that does not mean that they ought be bundled together in a questionnaire.) 5.3.2.1.14: I don't think this belongs in the questionnaire either. It's covered alredy in other IETF processes, when most relevant, so is not useful to ask about here. 5.3.2.1.15: This needs to be rewritten, there are 13 questions in the text which is entirely pointless. I would not bother to try answer those. You should just ask how confidentiality is supported and between what endpoints and how keying is done. (Or something like that, I didn't try the full re-write that is needed.) The re-write should also bundle this with most of the next two sections. (See below.) 5.3.2.1.15: The cryptographic parts of this should be merged into a rewritten 5.3.2.1.14. If there are non-crypto bits of this then those need better explanatory text as it'd not be relevant for most protocols. (I mean things like database consistency.) I'm not sure if anything would remain when this and the previous section were re-written.) 5.3.2.1.17: As per 5.3.2.1.16. 5.3.2.1.18: This is entirely duplicative and should be deleted. 5.3.2.1.19: I've no clue if this'd be useful to ask. Only testing would tell. (It might be, but I'm really not sure.) Nits/editorial... lots of places: there are too many over-long sentences that make this hard to read and less clear. I'd really recommend getting rid of as many of those as you can. The first non-quote paragraph of the intro is a good example. intro, "the core of the Internet, its architectural design is..." Using "core" is a bad term there, mostly we mean something quite different when we talk about the Internet's core or similar. (And that's another assumption that there's one true architecture.) intro, "properly defined, described and protected as such" - I don't think "defined" is needed there, and it might not be correct either. intro, "New protocols, particularly those that upgrade the core infrastructure of the Net, should be designed to continue to enable fundamental human rights." I'd drop the "core infrastructure" bit there, it's a distraction and liable to generate argument about what is or is not core, e.g. BGP is clearly core but is not otherwise mentioned in this document, and maybe correctly. intro, "The authors believe that the issues that have been raised by the reviewers have been addressed." Sorry to be raising more:-) section 2: I think some better formatting is needed here to distinguish the terms defined from the text, which in some cases is fairly long. Just add bullets or quoting or something. 2: "In the discussion of human rights and Internet architecture concepts developed in computer science, networking, law, policy-making and advocacy are coming together" Sorry, what is coming together in what discussion(s)? Too many commas there to be sure I think. (BTW, "architecture concepts" may well be an ok use of that word:-) 2, "censorship resistance" does not "prevent" censorship, I'd say mitigate is better than prevent. 2, "confidentiality" - why not refer to 4949 there? 2, "debugging" - the term debug is not used in the draft, why do you need the definition? 2, "decentralized" - why is "opportunity for" needed in this definition? I don't get that. 2, "technical this means..." needs fixing. 2, "Heterogenity" typo 2, "autonomous organizations" do you mean ASes? If so, say so. If not, better to avoid the word autonomous here. 2, "integrity" - why not refer to 4949? 2, "Inter-operable" is normally not hyphenated in the IETF 2, i18n - funny line breaks there make that hard to read 2, l10n - you don't actually use that abbreviation so why define it? 2, "The combination of the end-to-end principle, interoperability, resilience, reliability and robustness are the enableing factors that result in on the Internet. " That (non-)sentence needs fixing. I don't even know what you want to say tbh. section 3: I think this short section is missing text to the effect that you think the answer to question 2 is yes. section 4: you say "five clear positions" but they are not clearly delineated in the document. I'd suggest using some headings or some other way to make these more distinct in the document. 4: "embedded into the Internet's architecture" (top of p13) has another claim that there's one true Internet architecture. You could change this one to be the set of protocols defined by the IETF or something similar. 4: " As it stems from the issues as they arise in the field of technical engineering." That's not a sentence. 5: "step taken by the research group" that's ambiguous - I think you mean the set of authors and their research groups at home and not the HRPC, which I don't think collectively read all the RFCs you mean. (I think it's fine to say that the authors were the one who did the work, if that's what you mean.) 5.1: This section duplicates the intro to section 5. Is there a new point being made? 5.2: "(detailed under "2.vocabulary used")" do you mean section 2 there? Saying "Section 2" with the right xml2rfc incantation will cause the tools rendering to make that a link, which'd be nice. 5.2.1.1: "was assembly" typo. 5.2.1.5: figures are better numbered and with captions. 5.2.2.1: I guess there's a heading level bug here in the document sounce? 5.2.3.1: "ability for those hosts to assemble or to consensually express themselves" huh? When/how do hosts assemble or do things consensually? Confusing people and hosts like that is odd. 5.2.3.2: Why refer to spdy and not h2? And is that even a good reference? The 4906 reference also puzzled me. (Even more:-) 5.2.5: Why "because of it's simple design"? I'd have thought it was more complicated than that and that a combination of HTTP, HTML, open-source browsers and web servers and cool content was involved. 5.2.5: TLS and SSL could do with references. 5.2.5: Gen-ART? Huh? That's wrong. Gen-ART are fine people but they don't do what you say they do any more than any other set of IETFers. Are you confusing them with the IAB statement on encryption perhaps? Otherwise that is quite the puzzle for me:-) 5.2.5.1: What does "of the first" mean? "From the start"? 5.2.5.1: "have been corrected in TLS1.3" is in the wrong tense - "are being corrected" is correct. 5.2.5.1: TEMPORA, XKEYSCORE etc need references. Those can get hard to find later, at least good references can be hard to find. 5.2.6.1: I assume the URLs [1] and [2] don't need to be there and are xml2rfc artefacts to be fixed. Also, you should use example.com and example.net as per the usual way of handling examples in RFCs. 5.2.7: "often seen" - by whom? I'm not sure that IETFers would share that opinion, so better to say who you do mean. "remains critical" is also overstated. 5.2.7.1: "directed directly" typo 5.2.7.2: "throtteling" typo 5.2.7.5: Why does only this section have a conclusions subsction? I'd say be consistent. 5.2.8.1: you could lose the heading here (consistency again:-) 5.2.8.1: some VPNs (but not the ones you care about) are not point-to-point. 5.2.8.1: "There are multiple implementations and protocols used in provisioning a VPN" do you really mean provisioning a VPN there? That'd mean something else for some IETFers. I think you mean setting up a personal VPN for a single user but not quite sure. 5.2.8.5: The URL for [PET2015VPN] didn't work for me. I found the paper elsewhere though. 5.2.8.7: This bit seems fairly repetitive, other than the timing/correlation issues. You could maybe say that more briefly. 5.2.10: The URL for [Walfish] doesn't point at the named paper - what's up there? 5.2.11 (and elsewhere): "Many individuals, not excluding IETF engineers, have argued..." I hate constructs like that that assert that somebody somewhere (unnamed) thinks/says something. I don't see why any such assertions (of rumour basically) ought be in the RFC series. There are other examples of this construct in the draft. 5.2.11: Not all DoS attacks flood with traffic. Some might consume CPU cycles, in future some will consume limited power, and could be used in a DDoS. I don't think it's useful here (for the IETF audience) to define 3 types of DDoS attack. 5.3: "Having established how..." I don't think you established the "how." It'd be fair to do s/how/that/ though. (Twice.) That sentence is also overlong. Also "... by detailing how..." is similarly not correct. 5.3.1: 1st para is repetitive. Delete it. 5.3.1: The term "ICTs" isn't common in the IETF community. I'd say rephrase stuff to not use that. 5.3.2.x.y: Having such deep levels of TOC makes life harder for readers and those commenting and later using this. Flatten it tall out. Or, do you even need the 5.3.2.x.y headings at all? (Some of the section titles don't map that well to the content.) 5.3.2.1.1: s/e2e principle/e2e argument/ again:-) 5.3.2.1.1: the communication content would be concealed, not the act of communication 5.3.2.x.y: It'd be a very good idea to add an appendix that lists the questionnaire questions only (with those being numbered). That way, people who want to do this analysis can just use that part (at least the 2nd time). If doing that, please ensure each question also has an unique number/label in the body of the document too, so that folks can find/correlate things. 5.3.2.1.4: The last para of explanatory material should not re-define COMSEC etc. Just point people at RFC3552/BCP72. (But as BCP72.) The global adversary is also not purely passive, I'd lose that phrase. 5.3.2.1.5: "many protocols" is not usefully true I think. 10.2: delete this. --------------ms090200000604020501070409 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MjIx MjMzNDBaMC8GCSqGSIb3DQEJBDEiBCDAdMENCBa/c4o19K0kHmgZN+vK35AdZAszXeca2h+w zDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCKT8SYOPWmGSdWMs+MCZkBarFKe7Cqz8wsurpmQjx7FE1/HiE6loju IC9wJn70hEJ7A+htMOUOaOYVhm2XHmvOBEBGbRAN1syfgN6zNEhh9HGxDBJ0o8yOtQ1JEiUa NQ9tYosoTAjK2CQY2+irX6CBi+iJ+/EUUjsrV4Oo06p07XW9cT21FMKyq4aylwL3QltSa5+X BCWAUq35HzKoL1HgOtSyPCQeD/QQlcNO+/c4PlEHd4n2eqkMB9shayhFhLvzuR0HOLHIA5Ou WEPEkHF90k5tk1d4Mm+kxbAoAoo3KutgWWY5Z8kLx2Wp50XqFYiUi0IDlD/DHZEHY4bctgb7 AAAAAAAA --------------ms090200000604020501070409-- From nobody Thu Sep 22 13:46:30 2016 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 0FECB12BDB8 for ; Thu, 22 Sep 2016 13:46:29 -0700 (PDT) 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 1LW7LbwXE5te for ; Thu, 22 Sep 2016 13:46:24 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC7312BDB5 for ; Thu, 22 Sep 2016 13:46:24 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 4E42329DD77 for ; Thu, 22 Sep 2016 20:46:23 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:355:371:372:379:421:599:854:857:960:966:967:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1593:1594:1605:1683:1730:1747:1777:1792:1963:1981:2110:2194:2196:2198:2199:2200:2201:2393:2525:2567:2682:2685:2691:2692:2693:2731:2734:2736:2859:2890:2891:2892:2893:2894:2895:2898:2899:2900:2901:2902:2903:2906:2907:2910:2911:2917:2920:2922:2923:2924:2925:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3304:3834:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4031:4042:4184:4250:4321:4362:4385:4425:4559:4860:5007:6757:7652:7875:7903:7974:7996:8527:8550:8568:8603:8985:9010:9025:9108:9174:10026:10848:11232:11914:11967:12043:12050:12109:12114:12291:12295:12305:12379:12438:12555:12660:12663:12683:12740:12760:13134:13138:13143:13146:13149:13153:13228:13230:13231:13846:14096:14097:21060:21063:21080:21155:21222:21324:21325:21326: X-HE-Tag: cave44_1a8851e027b3c X-Filterd-Recvd-Size: 50233 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 omf08.hostedemail.com (Postfix) with ESMTPA for ; Thu, 22 Sep 2016 20:46:22 +0000 (UTC) References: To: hrpc@irtf.org From: avri doria Message-ID: <9c2cb576-9baf-c231-1056-7920dd60a0b7@acm.org> Date: Thu, 22 Sep 2016 16:46:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 160922-1, 09/22/2016), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00 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, 22 Sep 2016 20:46:29 -0000 Hi, Stephen, thanks for this review. Just wanted to give a quick ack, but indicate that I am still working my way through it and looking forward to the authors' responses and any list discussion that may occur on some of the points that were made in this review. At this point, are there any other reviews on the -00 we should be waiting for? Thanks avri On 22-Sep-16 08:33, Stephen Farrell wrote: > Hiya, > > I spent a bit of time reviewing this finally. > > Overall, I think this is a fine piece of work and I look > forward to it becoming an RFC. I don't think it's nearly ready > yet though, there's a lot to fix. (But see #1 below for a > suggested short-cut.) > > Cheers, > S. > > General, and, I think, important to handle... > > (1) What kind of consensus are we aiming for here? > > I'm not sure if this would be better off aiming to be a > document that has RG consensus or not. There's a lot of fine > text here, but there's also quite a few instances of text for > which I think it may be quite hard to establish RG consensus, > and where that may take some time and draft iterations. > (You'll see some examples in my specific conments.) Clearly, > processing the document aiming for RG consensus is an option, > and maybe the default option, but I wondered if it'd also be an > option to proceed more quickly with this documenting the > author's research and opinions/conclusions (and not necessarily > RG consensus) and to then later try to extract an updated > version of the guidlines/questionnaire into a separate RFC > aiming for RG consensus. I'm not arguing strongly for that > latter plan but just wanted to ask in case it helps the RG (and > Avri who I guess will have the fun of figuring this out:-). > > (2) Length and structure for protocol developers. > > I think this is too long to be very useful for protocol > developers. I doubt many of them will wade through 40+ pages > to get to the bit that's really aimed at them. (And which > pretty much needs a total re-write.) The plan mentioned in #1 > might help there I guess but another idea might be to move > section 5.3.2 to the front and make a lot of the rest of the > text into subsequent explanatory material and/or appendices. > > (3) What architecture do you mean? > > There are 25 lines that mention the term architecture in the > draft and I'm not at all sure the term is used to mean the same > thing throughout. I'm also not sure that there is an accepted > thing that is "the one true Internet architecture" that has > IETF consensus but you seem to me to be assuming that there is > such a beast. Is this just a language issue or a deep(er) > problem? I'm not sure, but eliminating references to the > Internet architecture where possible would I think help. See > some of the specific comments below, but I'd recommend a pass > over the document to check how this term is used as well. (To > try head off some lines of debate that might follow from this > comment, I do think there are aspects of Internet architecture > for which we do have IETF consensus, but I don't think the IETF > has consensus on any one way in which to put all those together > into something that'd be rightly termed the (or an) Internet > architecture. I think RFC1958 section 2.1 supports that > position btw.) > > (4) What does "=" mean here? > > In section 2 and later (in 5.2.2) you have diagrams with > bracketed terms on the left, then "=" and then another term on > the right. I just don't get what you mean by that "=" sign. You > say "combine" and "makes up" but frankly I don't get it, even > though I was in some of the meetings where those pictures were > presented. E.g. in section 2, I don't get how to combine > authenticity and anonymity in any useful sense, as those are > mostly in conflict. And the 2nd picture in section 2 has > connectivity on the RHS, which you defined as being an "extent" > and none of the things on the LHS seem to reflect that at all. > While those pictures may well have been ok for use in > presentations, I'm less happy that they're useful in an RFC. > So, what does "=" mean? Can you actually define that relation? > (Apologies if I'm being all "techie" and anal here, but I > really don't get it, honest;-) > > (5) The DDoS discussion is still wrong. > > I think the discussion of DDoS in section 5.2.11 (see below for > specifics) is not good enough and that section needs to be > re-written or mostly deleted. (Not all list discussions need to > end up with a section in the document.) It may be the case that > what is needed is some discussion of forms of protest using the > Internet, but that I think would better be the topic for > another document, if soeone has the energy/interest. (That > could be interesting too!) For this document, if it is aimed at > the IETF audience, the current text is not useful as it ends up > as a (controversial) NOOP - "don't enable DoS" is already in > RFC3552 since 2003. > > (6) The questionnaire is not good enough. > > 5.3.2.x.y: Please go through these questions yourself (for some > protocol) and write down answers and see then what you think of > the questions. I think a number of these questions will not > produce meaningful answers in any real attempt at using them. > I also think that someone who is not an author and who is > developing a new protocol needs to have gone through the > exercise at least once before we should publish this document > as any RFC. It is far too easy to ask unanswerable or > non-useful questions otherwise. > > (7) Missing introductory text. > > I think there's a missing bit of explanatory text about rights > in general that'd help some more IETF-oriented readers. As I > understand it, in HR all rights are contingent in the sense > that governments are expected to balance competing rights in > all cases. So e.g. even though we have a right to life, > governments can legislate for capital punishment and still > consider themselves signed up to the UDHR. I think this is > worth noting, as for example, it means that we do not > necessarily want to enshrine all the fine concepts on which the > IETF has consensus as human rights, in particular, claiming > that one had a right to encrypt could as a side-effect allow > some governments to claim that they had a right to limit one's > knowledge of mathematics, if that is claimed to compete with > other rights (e.g. to safety). I'm not sure if this is the > right HRPC document to capture that, but it was a surprise for > me when I first found that out, so it may be worth adding a bit > of text explaining basic rights concepts like that here or > somewhere else. > > Specific comments (without reference to importance:-) > > Note: I'm not quite sure why, but I read this through and > commented as if it were a PhD thesis, which is a bit more > stringent that e.g. IESG evaluation. Apologies if that seems > like nitpicking, but I think given the possibly political > (ab)uses to which this RFC could be put, and since we might > effectively kill the impact of the RG if we do this first RFC > badly, we might be better off to take that approach. I'm > willing to believe that I'm being too nit-picky though:-) > > abstract: These ought not have references and I think is too > long. I'd suggest keeping the 2nd para (minus the reference) > and move the rest to the intro. > > intro, p3: How do you know that "open, secure and reliable" are > necessary conditions here? I think you're likely correct, but > I'm not sure that claim is justified in the document or in the > references. > > intro, p3: "The Internet aims to be a global network of > networks that provides unfettered connectivity to all users at > all times and for any content [RFC1958]. " The "aims to be" > there seems odd, and I don't see where 1958 says "at all times" > which seems to me overstated. > > intro, p3: "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 > network." Sure one could argue that but is that claimed as an > RG consensus? And you're assuming that there is one true > Internet architecture there I think, which is problematic. > > intro, p3: "By doing so, the IETF enabled the manifestation of > the right to privacy, through the Internet's architecture." I > think this shows a misconception of the IETF's role, at least > as I see it. I don't believe that the IETF controls the > Internet's architecture in the sense implied here. If you'd > said "through it's protocol design processes" at the end > instead, then I think that'd be better. And saying "Enabled" > makes it sound like a done-deal and we can all go home, which > strikes me as pretty optimistic;-) > > intro, p3, "Openness of communications of the technical design" > what does that mean? And how does it "foster freedom of > communication"? I don't get the argument here. > > intro, p3, "galvanize" is overstated and the IETF doesn't > "ensure" what happens in the network, but only in the protocols > we define - what implementers and operators do with that is > really up to them and not the IETF. That's an important > distinction that's mixed up in a few places in the document, > including in the next sentence - if the IRTF produces this RFC, > that's great and will help to ensure better realisation of HR > issues, but the existence of the RFC itself will not ensure > anything. > > section 2: "unfettered" - while I myself do like that term, I > think following the approach from RFC 4084 which you quote here > would be a good general approach for this entire document. > 4084 section 1.2 says that it intentionally avoide pejorative > terms so as to increase the likelihood that operators will pay > attention. I think following that guidance in this document > would be good. Most of the text is actually fine in this > respect, but an editing pass based on a review from some (as > yet uninvolved) protocol developers would be a good thing. For > example, some of the references to companies and products later > on might raise hackles in a way that'd be counter productive. > Anyway, 4084 does not use the term unfettered at all so better > to not say that here. > > section 2, and elsewhere: I think the use of the term anonymity > is wrong in almost all cases in this document. While it is the > case that users (and non-technical folk in general, including > law makers) may talk about anonymity, I think there are few to > zero technical folks who think that anonymity is achievable at > any scale today. Tor may be the closest we get, but it's not at > all clear to me that anonymity is really a requirement or a > goal for almost all protocol designers almost all of the time. > I do think we should consider "being hard to track" and similar > as requirements/goals but that's different and I'm not sure we > even have that good an idea about all the trade-offs that are > involved here. I'd recommend checking every time you use this > tern, and getting rid of most of them. (Will try to point out > the ones I think are problematic below.) Note that the 4949 > definition is probably ok(ish:-) but once there are muliple > protocols involved things become very unclear and in real > networks, there's almost always someone somewhere who can > identify (or re-identify) a person, host or bit of s/w and that > context seems to be missing here when you use the term. > > 2, Defining connectivity as an "extent" is interesting. I'm not > sure if it's precise enough though, e.g., what'd "twice better > connectivity" mean? Not sure what to suggest but I do think > you're right to not define it as binary. Maybe refer to RFC4084 > here again for some different types of connectivity? > > 2, "content-agnosticism" - hmm, that seems a bit broken to me > as a definition, it is ok to treat delay intolerant traffic > differently and we do want that sometimes. "Identically" seems > too strong, but I'm not sure what better definition to use > without getting into an essay about net neutrality and similar > things that I don't know much about;-) > > 2, "end-to-end" - I much prefer to refer to this as an argument > and not a principle. You'll get different opinions on that > though:-) > > 2, "Internet censorship" - I think this definition is too broad > and could even be read to discourage data minimisation. It > seems to be missing the concept that the censor is acting > without the agreement of the endpoints, but agreement/consent > is such a slippy concept on the Internet maybe that'd be a bad > idea. Anyway, this seems to broad to me fwiw. > > 2, "Internet Standards as an Arena for Conflict"... eh... > What? That's not a term to define, it's an argument for over > beer! I think you need to delete that from this section. If you > want to include the text somewhere then find a better way to do > that I'd say. (But I'd still then ask: where is the principle > of constant change defined for all time? :-) > > 2, "i18n" - I think you're wrong that "Many protocols..." don't > support i18n. It's for sure true that a bunch don't do this > well and ought, but "many" seems overstated. Did you count > them? (Note that for many binary protocols i18n isn't very > relevant at all, if one assume that i18n is mostly important > for end-users and less so for developers or bigger operators.) > > 2, "Open Standards Conform" - what? That's not a term to > define. I think you also say this elsewhere so deleting this > would be right. And what's RFC2606 got to do with it? > > 2, "Openness" - I think this is just wrong and am not sure what > you even want to define. You cannot for example have free > access to hosts in my home network, no matter how openly you > ask:-) If you want to define openness, then I think it'd have > to be about processes and not access to hosts. > > 2, "permissionless innovation" is not all about new protocols. > It's also about using existing protocols in new ways without > having to ask. Not all such uses are usefully described as new > protocols. > > 2, "Privacy" - I think adding some references to the HR and > legal literature about privacy could help the more technical > readers here. > > 2, reliable, resiliance and robustness - I'm surprised there're > no references for the first two and puzzled by the references > for the 3rd. There also seem to be very few reference to these > later, which makes it odd to find them here. I wonder if the > formalism you're using (introduced at the end of section 2) has > caused you to shoe-horn in definitions of these? > > 2, scalable - it's often a challenge in proocol design to > ensure that a protocol scales down as well as up, in the sense > of working well for smaller networks/deployments. Might be > worth pointing that out as it's relevant here when one > considers designing new protocols potentially putting too much > emphasis on the requirements of only bigger operators (who are > in the room). > > 2, stateless - is used exactly once later, and stateful is not > used at all later - do you really need this here? (Just define > it when used, but I think protocol developers will get the > meaning anyway.) You could also say that retaining state has > potential privacy impact, which may not be so obvious. (That > retaining state impacts on other protocol features such as > hard-reboot is fairly well understood I think.) > > 2, "Strong encryption / cryptography" I don't think this is > needed or useful - why is it here? I think the IETF community > know this already, is it useful for some other readership? If > so who? (Since I'm not sure it'd be that useful for any > readership.) > > 2, "transparent" - I don't like this definition which I think > is not actually definining the term in the sense in which you > use it in this document. As you actually use the term, it is > mostly about processes, which is not what RFC2775 is about. In > fact, I think you're actually using the term in it's normal > English usage and don't really need a specific definition. > (Though I didn't check all uses of the term.) > > 2, " The combination of reliability, confidentiality, > integrity, anonymity, and authenticity is what makes up > security on the Internet." No. That is just wrong. For example, > that list omits DoS resilience, bugs (and protocol flaws) that > cause problems like heartbleed, and I think, much else besides. > I'm not sure how to fix this. (But see my general question wrt > "=" as used here.) > > section 4: I don't accept that "protocols are politics by other > means" - if I develop a way for two computers to interact in my > (non-existent as it happens:-) basement, that is not politics. > If I publish an academic paper on a faster way to do ECDH > that's not politics. I know it's a quote, but I don't think > you ought present that quote in that way (reading IMO as if it > were an RG consensus statement) without qualification. The > relevant qualification I think is tricky to formulate but has > something to do with broad deployment or with deployment at > some technical choke point that offers significant control to > someone. > > 4: I don't get the "values-by-design" point and how it's > relevant to the IETF. I don't recall discussions about that on > IETF/IRTF lists. Is this perhaps something that's really being > discussed outside the IETF/IRTF context? If so, then the > statement that these are a "new focal point" is not correct. > (If you want to say this should or could be a discussion to > have, that'd be fine but that's a different statement.) > > 4: "tools of enforcement" - I'm not sure what you mean here. If > you mean law enforcement then saying that would be better, but > the sentence is vague, for me anyway so would be better > rephrased. > > 4: "This document sets out some preliminary steps and > considerations for engineers to take into account when > developing standards and protocols." I think that's a good and > fair statement of where this document is at. But don't you > elsewhere go further? (CHECK) > > section 5: It'd be great if you could add links or references > to the source materials here. For example, who'd you interview? > Are the videos avaiable? What's the list of RFCs you read and > which were considered (most) relevant? Similarly for WG lists > analysed etc. I'm sure you have all that stuff and making that > available for later would be great. > > 5.2.1.4 and 5.2.1.5: (See general point #4 above about "=") I > don't think you actually have achieved this "the creation of a > list of technical concepts that when combined create an > enabling environment for human rights." It's a fine goal, but > I'm not sure it's achievable in reality with the kind of > precision claimed in this section. I don't think the terms > used in the figure in 5.2.1.5 are at all precise TBH, e.g. the > phrase "good enough" only occurs in this figure and nowehere > else. > > 5.2.3: "These capabilities for network control and limitations > of the freedom of expression by end hosts can be traced back to > the IPv4 design..." I don't think you have justified this > claim. My argument would be that there is no simlarly > scaled/robust nework against which to compare IP and that does > not have the feature that it allows deployments to limit > freedom of expression. So it may be that this feature/bug is > not IP specific but inherent in large networks. In any case, > the claim seems too much to me. (That might be a useful topic > for the RG to tackle, or maybe someone has already studied this > issue?) > > 5.2.3.1: On what do you base the claim that source-routing > could be better here? Source-routing seems to usually generate > objections from transport folks. (You'd have to ask them for > the history of that.) Spoofed source IP is a common mechaism > for abuse. While you do say these are not considered good > practice, you don't say why (or provide a reference) so it > looks to this reader as if you're saying that those "features" > could have been better, but without evidence for that. (Tor is > lovely, but as currently defined, would not scale to the size > of the Internet as it was quite some years ago.) > > 5.2.3.2: are you referring to the protocol number here? (As > listed at [1]) That has about 140 protocols many of which > aren't in widespread use. If so, then I question the claim > that this is really the cause of DPI - I suspect that DPI > devices mostly look deeper into the packet. That also seems to > be indicated when you talk about transports and spdy. I think > this section is confused about the differences between headers > at various layers, and our history of sending cleartext. That > said, I could see that in future, as we encypt more Internet > traffic, someone may find rights-invading ways to use layer 3 > headers but I'm not sure this is a significant issue today. (If > there is evidence of this being done, I'd be interested in > knowing about that. I guess there may be IPv6 options that are > in use like that or have been suggested but you don't cover > those at all that I can see.) > > [1] > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > > 5.2.3.3: I don't think mobile IP could never have displaced NAT > for IPv4. We'd still have run out of addresses. So I'm not > sure the point made here (that there was a "viable > alternative") is correct at all. > > 5.2.4: "which enact ICANN's policy" Do you thnk that the ccTLDs > would agree with that? I don't. > > 5.2.4: I think the fact that new gTLDs are hugely expensive is > well worth a mention, as a deterrent to various freedoms. > > 5.2.4: I think you're missing some points here, maybe even an > entire subsection. One of the ways around some of the issues > listed is for clients to choose their resolver, e.g. so as to > pick one that does check DNSSEC or that is not subject to the > same regime as a default resolver. That can be blocked at the > IP level, which is one issue. But even if I do that and use > DPRIVE, then that creates a new threat of centralisation of > lots of queries (e.g. at 8.8.8.8) which introduces yet another > point at which control can be enforced or where traffic can be > analysed. Passive DNS also has good and bad aspects. I'd say > some or all of these points would be good to note. (But I'm not > the right person to suggest good text sorry.) > > 5.2.5: The lack of a mandate for TLS was not the only reason > why the web started out largely cleartext. There were also > significant performance, UI, tooling and missing infrastructure > issues, as well as the charging per certificate business model. > Those were more important issues IMO, even though they do not > nicely tie into the discussion of h2 and it's lack of a mandate > for use of TLS. While I personally regret that, it was the > result of a real and extended and open debate, which I think > also ought be noted. > > 5.2.5 and 5.2.5.x: While I'm fine with you calling the > development of TLS MitM devices and similar "malicious," I am > pretty sure plenty of folks might argue that. It'd be better to > skip the pejorative language I think, but it is entirely > correct to have the references to the attacks mounted using > such technologies. I'd also tend to not mention specific > companies and products in the body of the text, except where > that is really necessary to make the point. > > 5.2.5.1: How do you know it was Snowden's relevations that > caused mail service providers (not ISPs!) to "follow Google's > lead"? That may be correct, but I'm not sure there's the public > evidence that they said that was why. (If there is, great, but > please provide a reference, the one you do provide, [Peterson], > is about gmail and not yahoo.) Also, Google use TLS, not SSL > for gmail. > > 5.2.5.1: "less democratic" - I think it's an error to say that, > since many countries that are considered role models for > democracy could do the same things, "some countries" and > examples would be better. Same with "oppressive regimes" - > there's no need to include that judgement here. The reference > here [RSF] wasn't accessible to me (no route to host) from a > hotel network and eduroam. That could be nicely ironic, or a > badly chosen reference. (But you need a reference.) The 2012 > Libya report also really needs a reference. > > [RSF] > https://en.rsf.org/syria-syria-using-34-blue-coat-servers-23-05-2013,44664.html > > 5.2.5.2: wrt great-cannon, you might want to note that the IESG > issued a related statement [2]. That's a bit tangential, but I > think is relevant for this work. > > [2] > https://www.ietf.org/iesg/statement/maximizing-encrypted-access.html > > 5.2.5.2: "Companies like" is pejorative and the patent > application seems irrelevant. "has been largely documented" > calls for a reference. "Oppressive regimes" is also not needed > here as is "little concern for bad human rights records." The > right thing here I think is to note the documented record > without pejoratives and to then let the reader draw their own > conclusions. > > 5.2.5.2: I don't think the text about h2 is fair. You're > missing a) that there was a real and open debate on the topic, > b) that some important implementations are exclusively h2/tls > and c) that there is a spec for OS for HTTP being developed. > Those are all as relevant as the fact that the outcome of the > debate was to not mandate use of TLS all the time. (Which I do > think is worth saying in this document, but needs more complete > context.) > > 5.2.6: I think this section is missing some things. First, the > IETF/XSF relationship is relevant here and needs a mention. (As > both good and bad!) Second, OTR is important, as is the > community's failure to produce a better e2e standard for xmpp. > And lastly, I think the tendency of IM deployments to not > deploy interoperable standarsd is missing, which also has good > and bad aspects (good: they can do telegram etc, bad: no > interop). I'd suggest asking an XMPP expert to review/suggest > text. (Happy to help find you one if needed.) > > 5.2.6: "The protocol also has facets that may stifle speech as > users self-censor for fear of surveillance, or find themselves > unable to express themselves freely." That's not an XMPP > specific point - the same applies to email and the web and to > any other protocol that supports interpersonal messaging or > access to sensitive information. I think you ought up-level > this point to a more generic section that calls out issues with > multiple protocols. (Not sure where exactly, but having it here > only isn't great.) > > 5.2.7: Is this section about P2P in general (I'd consider P2P a > design pattern) or about PPSPP or about BT? Each of those > choices seems wrong. If the first, then that's not the same as > other 5.2.x sections and doesn't mention other P2P protocols > (e.g. RELOAD maybe). If the second, is the deployment of that > sufficient to justify the text? If the 3rd - that's not an IETF > protocol. So I'm not sure what to make of this. > > 5.2.7: Is it still true to say that P2P is an "increasingly > becoming a popular architecture"? I thought usage stats were > showing the opposite nowadays? The examples given are odd: as > BTC doesn't do file sharing/interpersonal messaging, skype is > no longer really P2P iiuc, and I don't know if spotify really > is or not. Surely BT is the canonical real example? > > 5.2.7: "mostly delegated" - I'm not sure this is correct. I > could argue that RELOAD is a counter example. I could further > argue that the lack of deployment of RELOAD (iiuc) may be > evidence that your implied argument that it'd be better for an > organisation like the IETF to try produce complete specs in > this space might be unwise in that it's less likely to result > in deployment. > > 5.2.7.3: I think ledbat has some protocol features that would > allow deployments (if they are nice) to reduce the scope for > tracking. That's RFC 6817 but I'd have to reread it to check if > there's something useful there, also not sure about ledbat > deployment. > > 5.2.7.4: Sybil attacks in this context (e.g. astroturfing) seem > to be relevant to more than p2p protocols. In fact wouldn't > they be more common on web based systems, at least as exploited > by/for governments and commercial entities? > > 5.2.8: There are many kinds of VPN - I think it'd be better to > rename this section to something like "personal VPNs" or > similar, as you don't get into e.g. corporate VPNs. > > 5.2.8.1: "local illegitimate wiretapping" - that's another > pejorative term for some, "monitoring" would be just as clear. > (Again, not because what you say is wrong, but because there's > no point in antagonising those who read this.) > > 5.2.8.1: "are way less analyzed and understood" I think I > recall some papers on these kinds of VPN that found some issues > - be good to reference such work if possible, esp if there's a > survey. > > 5.2.8.3: " VPN providers should at least be transparent on what > information do they store and for how long is being kept" I > fully agree with this, but what's it telling the IETF > readership? Perhaps that RFCs ought identity potentially > sensitive logged data or for how long that needs to be retained > for technical reasons? That migth not belong here anyway but > could be relevant somewhere in the document. > > 5.2.9: This could be shorter and may better as a part of > section 5.2.5 - why is this one status code so important? > > 5.2.10: I'm really not sure this (all) belongs here. The > middlebox debate is old and won't be resolved here, so I'm > don't think it's worthwhile regurgitating the arguments in such > detail. And I think you already said what you need to say when > discussing NATs. I'd say deleting this section is maybe right. > > 5.2.10: (If you keep it) "IETF's role to prevent such > censorship" again, the IETF is not the Internet police and does > not "prevent" things like that. If you refer to the SPUD BoF, > you should include references to the minutes etc. > > 5.2.10: "Middleboxes are becoming a proxy for the debate on the > extent to which commercial interests are a valid reason to > undermine the end- to-end principle." That seems like an > opinion, and one I'd be surprised had consensus. Do you need to > say that? > > 5.2.11: "Some people may say that DDoS attacks are the only > mean to be heard, in the current Internet." Some people say > that the moon landings were faked. Vague reportage like that is > useless. I'd say this entire section needs to be redone with a > strong statement that there is no valid use-case for DDos, and > that DDoS is not a valid form of protest. I think such a > statement is one that would have RG and indeed IETF consensus. > I'm very sure that no concept of DDoS as a valid form of > protest would garner consensus in either the RG or the IETF. > > 5.2.11: "seem to suggest that the IETF should try to ensure > that their protocols cannot be used for DDoS attacks" That's > very understated and maybe even misleading. I would say that > the IETF has long-standing consensus that DDoS is an attack > that protocols should mitigate to the extent they can and that > DDoS vectors in protocols are basically bugs. RFC3552 (section > 4.6) from 2003 covers this and says that standards MUST > describe DoS issues. > > 5.2.11: The linkage between private sector control of networks > and DDoS is IMO entirely unconvincing. NRENs are generally > private sector and have major issues with DDoS. (I'm sitting in > a talk on that topic right now.) It is not at all clear that > anyone who'd claim that they are using a DDoS attack to protest > would actually be protesting about a network operator - it is > much more likely they are protesting about some content owner, > who may be public or private sector. > > 5.2.11: I don't think we need or want the argument based on PM > here at all. The argument about motivations for PM in RFC7258 > depends on there being some justifiable reasons for monitoring. > (Otherwise we would not need to even point out that motivations > don't matter.) There are no such close-to-good arguments at all > for DDoS, so drawing that analogy is misleading. > > 5.2.11: If the RG feel there is a need to discuss a possibility > for fully opted-in people to collectively protest, (I do not) > then you should invent a new term for that and clearly say that > even though such protest might appear to the network as beng > the same as a DDoS (and hence be treated as an attack), that is > not the same as a DDoS, where 100% of real cases involve > compromised hosts or hosts being used as reflectors without > permission. If the RG feel there is a need to discuss forms of > protest on the Internet, then I think an entirely different > section is needed, probably with a different structure. > > 5.3.1: I'm not sure the "HR threats" model is the right thing > here. The same was true of rfc6973 as well, as you say, but in > this case, I'm not sure you really even need the concept. 5.3.2 > just says stuff like "did you think about " so I don't see > a need to say that " is a threat." I don't think you lose > anything by losing that concept entirely. There is also a > danger in including that risk analysis model here in that doing > so might cause later disussion to be somewhat blinkered. > > 5.3.1: "This is by no means an attempt to cherry picks rights, > if other rights seem relevant, please contact the authors > and/or the hrpc mailinglist." I'd delete that, it's not that > appropriate for an RFC (it was for an I-D). But if you do want > to say something about a contact point, the RG list would be > better. (The phrasing "cherry pick" is also a bit odd.) > > 5.3.2: The title here is a bit inaccurate and misleading. > You're presenting guidelines for protocol designers, and not > for "HR considerations." > > 5.3.2: I don't think that many IETFers follow or read RFC4101. > (RFC4101 is a useful, good thing, but one that's not much used > iiuc.) > > > 5.3.2.1.2: We're updating RFC3552 now, and the update will > include some guidance on privacy considerations. I'm not sure > if it'd be better to reference that draft now or not though, as > it's early days. Probably best to refer to BCP72 though, as > that'll remain the right reference when the 3552bis work is > done. > > 5.3.2.1.2: "Could your protocol counter traffic analysis, or > data minimization?" oops - I don't think you want to counter > data minimisation. Better to split that into two questions > probably. > > 5.3.2.1.3: This set of questions need work. All protocols "look > at the packet content" or else do nothing at all. I think you > want to ask people to think about which fields in the packet > they need to access and to try to minimize those, and if > possible, discourage others from looking at the rest (e.g. by > enabling encryption of those). I also have no clue what " Is > the protocol transparent about its decisions?" means. And the > last question is also pretty meaningless when looked at in > isolation. (I think I already commented on the agnosticism > phrase as used here before. The same issues apply to the > explanatory text here.) > > 5.3.2.1.5: "readable by humans" is not the right criterion > here. What you need to say is that "have to be understood by > humans." For example, DNS names are mostly readable but IDNs > are not, depending on which form one uses. For some protocols > it is entirely fine still to use ascii for human-readable > labels, if those are only seen by developers or more capable > admins. > > 5.3.2.1.6: Re-using existing identifiers (e.g. MAC addresses) > is the more common way that (re-)identification is enabled in > protocols. You should point that out. I think the "make ... > transparent" point is worth splitting from the identifier issue > too - identifiers are very common, but making filtering > apparent is much less so, and will be missed if you bundle > these two things together. The last two questions aren't really > useful though and are more explanatory text then real new > questions. > > 5.3.2.1.7: These are not useful, as phrased for IETFers. The > only useful part here is the 2nd last question (use other > things that are proprietary), the rest are not as they are > already handled in IETF processes, and we do not want yet more > bureaucracy. The explanatory material is way too long and also > not useful for the IETF audience. The example given is an > interesting thing, but far from a typical protocol, so > therefore is not a good example. > > 5.3.2.1.8: This entire section is useless for IETFers, except > the last question about extensibility. The explanatory text and > example however don't address that and are also not useful. > > 5.3.2.1.9: The question was asked already. Anonymity is not a > useful goal in almost all IETF protocols, and if it were, it'd > be a first order requirement (e.g. if we wrote an RFC for Tor) > and would not be missed. Delete this section entirely. > > 5.3.2.1.10: The emphasis here is wrong. You should be asking > about whether the protocol generates or processes anything that > can be, or be tightly correlated with, PII. Many protocols have > identifiers that are perfectly safe, until the host running the > protocol is something that a person carries with them. The > section needs a rewrite to take that approach. > > 5.3.2.1.11: Mixing accessibility and statefulness is wrong. > Both are fine questions, but should not be bundled. The > example is bad - HTML5 is the current spec and is not that RFC. > > 5.3.2.1.12: I think this is arguably duplicative and the issue > will (or should) be caught via other IETF processes apart from > HR considerations. I'd delete this, though it's mostly harmless > here. > > 5.3.2.1.13: Again, this bundles things in a counterproductive > manner. Split the topology/architecture points from the > discriminaton/implication ones. (Even if you think those relate > in terms of HR, that does not mean that they ought be bundled > together in a questionnaire.) > > 5.3.2.1.14: I don't think this belongs in the questionnaire > either. It's covered alredy in other IETF processes, when most > relevant, so is not useful to ask about here. > > 5.3.2.1.15: This needs to be rewritten, there are 13 questions > in the text which is entirely pointless. I would not bother to > try answer those. You should just ask how confidentiality is > supported and between what endpoints and how keying is done. > (Or something like that, I didn't try the full re-write that is > needed.) The re-write should also bundle this with most of the > next two sections. (See below.) > > 5.3.2.1.15: The cryptographic parts of this should be merged > into a rewritten 5.3.2.1.14. If there are non-crypto bits of > this then those need better explanatory text as it'd not be > relevant for most protocols. (I mean things like database > consistency.) I'm not sure if anything would remain when this > and the previous section were re-written.) > > 5.3.2.1.17: As per 5.3.2.1.16. > > 5.3.2.1.18: This is entirely duplicative and should be deleted. > > 5.3.2.1.19: I've no clue if this'd be useful to ask. Only > testing would tell. (It might be, but I'm really not sure.) > > Nits/editorial... > > lots of places: there are too many over-long sentences that > make this hard to read and less clear. I'd really recommend > getting rid of as many of those as you can. The first non-quote > paragraph of the intro is a good example. > > intro, "the core of the Internet, its architectural design > is..." Using "core" is a bad term there, mostly we mean > something quite different when we talk about the Internet's > core or similar. (And that's another assumption that there's > one true architecture.) > > intro, "properly defined, described and protected as such" - I > don't think "defined" is needed there, and it might not be > correct either. > > intro, "New protocols, particularly those that upgrade the core > infrastructure of the Net, should be designed to continue to > enable fundamental human rights." I'd drop the "core > infrastructure" bit there, it's a distraction and liable to > generate argument about what is or is not core, e.g. BGP is > clearly core but is not otherwise mentioned in this document, > and maybe correctly. > > intro, "The authors believe that the issues that have been > raised by the reviewers have been addressed." Sorry to be > raising more:-) > > section 2: I think some better formatting is needed here to > distinguish the terms defined from the text, which in some > cases is fairly long. Just add bullets or quoting or something. > > 2: "In the discussion of human rights and Internet architecture > concepts developed in computer science, networking, law, > policy-making and advocacy are coming together" Sorry, what is > coming together in what discussion(s)? Too many commas there to > be sure I think. (BTW, "architecture concepts" may well be an > ok use of that word:-) > > 2, "censorship resistance" does not "prevent" censorship, I'd > say mitigate is better than prevent. > > 2, "confidentiality" - why not refer to 4949 there? > > 2, "debugging" - the term debug is not used in the draft, why > do you need the definition? > > 2, "decentralized" - why is "opportunity for" needed in this > definition? I don't get that. > > 2, "technical this means..." needs fixing. > > 2, "Heterogenity" typo > > 2, "autonomous organizations" do you mean ASes? If so, say so. > If not, better to avoid the word autonomous here. > > 2, "integrity" - why not refer to 4949? > > 2, "Inter-operable" is normally not hyphenated in the IETF > > 2, i18n - funny line breaks there make that hard to read > > 2, l10n - you don't actually use that abbreviation so why > define it? > > 2, "The combination of the end-to-end principle, > interoperability, resilience, reliability and robustness are > the enableing factors that result in on the Internet. " That > (non-)sentence needs fixing. I don't even know what you want to > say tbh. > > section 3: I think this short section is missing text to the > effect that you think the answer to question 2 is yes. > > section 4: you say "five clear positions" but they are not > clearly delineated in the document. I'd suggest using some > headings or some other way to make these more distinct in the > document. > > 4: "embedded into the Internet's architecture" (top of p13) has > another claim that there's one true Internet architecture. You > could change this one to be the set of protocols defined by the > IETF or something similar. > > 4: " As it stems from the issues as they arise in the field of > technical engineering." That's not a sentence. > > 5: "step taken by the research group" that's ambiguous - I > think you mean the set of authors and their research groups at > home and not the HRPC, which I don't think collectively read > all the RFCs you mean. (I think it's fine to say that the > authors were the one who did the work, if that's what you > mean.) > > 5.1: This section duplicates the intro to section 5. Is there a > new point being made? > > 5.2: "(detailed under "2.vocabulary used")" do you mean section > 2 there? Saying "Section 2" with the right xml2rfc incantation > will cause the tools rendering to make that a link, which'd be > nice. > > 5.2.1.1: "was assembly" typo. > > 5.2.1.5: figures are better numbered and with captions. > > 5.2.2.1: I guess there's a heading level bug here in the > document sounce? > > 5.2.3.1: "ability for those hosts to assemble or to > consensually express themselves" huh? When/how do hosts > assemble or do things consensually? Confusing people and hosts > like that is odd. > > 5.2.3.2: Why refer to spdy and not h2? And is that even a good > reference? The 4906 reference also puzzled me. (Even more:-) > > 5.2.5: Why "because of it's simple design"? I'd have thought it > was more complicated than that and that a combination of HTTP, > HTML, open-source browsers and web servers and cool content was > involved. > > 5.2.5: TLS and SSL could do with references. > > 5.2.5: Gen-ART? Huh? That's wrong. Gen-ART are fine people but > they don't do what you say they do any more than any other set > of IETFers. Are you confusing them with the IAB statement on > encryption perhaps? Otherwise that is quite the puzzle for > me:-) > > 5.2.5.1: What does "of the first" mean? "From the start"? > > 5.2.5.1: "have been corrected in TLS1.3" is in the wrong tense > - "are being corrected" is correct. > > 5.2.5.1: TEMPORA, XKEYSCORE etc need references. Those can get > hard to find later, at least good references can be hard to > find. > > 5.2.6.1: I assume the URLs [1] and [2] don't need to be there > and are xml2rfc artefacts to be fixed. Also, you should use > example.com and example.net as per the usual way of handling > examples in RFCs. > > 5.2.7: "often seen" - by whom? I'm not sure that IETFers would > share that opinion, so better to say who you do mean. "remains > critical" is also overstated. > > 5.2.7.1: "directed directly" typo > > 5.2.7.2: "throtteling" typo > > 5.2.7.5: Why does only this section have a conclusions > subsction? I'd say be consistent. > > 5.2.8.1: you could lose the heading here (consistency again:-) > > 5.2.8.1: some VPNs (but not the ones you care about) are not > point-to-point. > > 5.2.8.1: "There are multiple implementations and protocols used > in provisioning a VPN" do you really mean provisioning a VPN > there? That'd mean something else for some IETFers. I think you > mean setting up a personal VPN for a single user but not quite > sure. > > 5.2.8.5: The URL for [PET2015VPN] didn't work for me. I found > the paper elsewhere though. > > 5.2.8.7: This bit seems fairly repetitive, other than the > timing/correlation issues. You could maybe say that more > briefly. > > 5.2.10: The URL for [Walfish] doesn't point at the named paper > - what's up there? > > 5.2.11 (and elsewhere): "Many individuals, not excluding IETF > engineers, have argued..." I hate constructs like that that > assert that somebody somewhere (unnamed) thinks/says something. > I don't see why any such assertions (of rumour basically) ought > be in the RFC series. There are other examples of this > construct in the draft. > > 5.2.11: Not all DoS attacks flood with traffic. Some might > consume CPU cycles, in future some will consume limited power, > and could be used in a DDoS. I don't think it's useful here > (for the IETF audience) to define 3 types of DDoS attack. > > 5.3: "Having established how..." I don't think you established > the "how." It'd be fair to do s/how/that/ though. (Twice.) That > sentence is also overlong. Also "... by detailing how..." is > similarly not correct. > > 5.3.1: 1st para is repetitive. Delete it. > > 5.3.1: The term "ICTs" isn't common in the IETF community. I'd > say rephrase stuff to not use that. > > 5.3.2.x.y: Having such deep levels of TOC makes life harder for > readers and those commenting and later using this. Flatten it > tall out. Or, do you even need the 5.3.2.x.y headings at all? > (Some of the section titles don't map that well to the > content.) > > 5.3.2.1.1: s/e2e principle/e2e argument/ again:-) > > 5.3.2.1.1: the communication content would be concealed, not > the act of communication > > 5.3.2.x.y: It'd be a very good idea to add an appendix that > lists the questionnaire questions only (with those being > numbered). That way, people who want to do this analysis can > just use that part (at least the 2nd time). If doing that, > please ensure each question also has an unique number/label in > the body of the document too, so that folks can find/correlate > things. > > 5.3.2.1.4: The last para of explanatory material should not > re-define COMSEC etc. Just point people at RFC3552/BCP72. (But > as BCP72.) The global adversary is also not purely passive, I'd > lose that phrase. > > 5.3.2.1.5: "many protocols" is not usefully true I think. > > 10.2: delete this. > > > > > _______________________________________________ > 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 Sep 22 14:26:08 2016 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 3A2FD12B7F3 for ; Thu, 22 Sep 2016 14:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 58N3eiWxTEuV for ; Thu, 22 Sep 2016 14:26:03 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F9812B61D for ; Thu, 22 Sep 2016 14:26:02 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 6726518115983 for ; Thu, 22 Sep 2016 21:26:00 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 54A8A180D400D for ; Thu, 22 Sep 2016 21:26:00 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 2D74118115983 for ; Thu, 22 Sep 2016 21:26:00 +0000 (UTC) To: hrpc@irtf.org References: <9c2cb576-9baf-c231-1056-7920dd60a0b7@acm.org> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 22 Sep 2016 23:25:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <9c2cb576-9baf-c231-1056-7920dd60a0b7@acm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UC5Dis7q8gttkor1FHvRbATKitsP5qTch" Archived-At: Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00 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, 22 Sep 2016 21:26:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UC5Dis7q8gttkor1FHvRbATKitsP5qTch Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Stephen, Thanks a lot for this extensive review! I hope you (and others) will allow us some time to give it the attention it deserves, I hope to be coming back with a full response at the beginning of next week. Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 09/22/2016 10:46 PM, avri doria wrote: > Hi, >=20 > Stephen, thanks for this review. Just wanted to give a quick ack, but > indicate that I am still working my way through it and looking forward > to the authors' responses and any list discussion that may occur on som= e > of the points that were made in this review. >=20 > At this point, are there any other reviews on the -00 we should be > waiting for? >=20 > Thanks >=20 > avri >=20 >=20 > On 22-Sep-16 08:33, Stephen Farrell wrote: >> Hiya, >> >> I spent a bit of time reviewing this finally. >> >> Overall, I think this is a fine piece of work and I look >> forward to it becoming an RFC. I don't think it's nearly ready >> yet though, there's a lot to fix. (But see #1 below for a >> suggested short-cut.) >> >> Cheers, >> S. >> >> General, and, I think, important to handle... >> >> (1) What kind of consensus are we aiming for here? >> >> I'm not sure if this would be better off aiming to be a >> document that has RG consensus or not. There's a lot of fine >> text here, but there's also quite a few instances of text for >> which I think it may be quite hard to establish RG consensus, >> and where that may take some time and draft iterations. >> (You'll see some examples in my specific conments.) Clearly, >> processing the document aiming for RG consensus is an option, >> and maybe the default option, but I wondered if it'd also be an >> option to proceed more quickly with this documenting the >> author's research and opinions/conclusions (and not necessarily >> RG consensus) and to then later try to extract an updated >> version of the guidlines/questionnaire into a separate RFC >> aiming for RG consensus. I'm not arguing strongly for that >> latter plan but just wanted to ask in case it helps the RG (and >> Avri who I guess will have the fun of figuring this out:-). >> >> (2) Length and structure for protocol developers. >> >> I think this is too long to be very useful for protocol >> developers. I doubt many of them will wade through 40+ pages >> to get to the bit that's really aimed at them. (And which >> pretty much needs a total re-write.) The plan mentioned in #1 >> might help there I guess but another idea might be to move >> section 5.3.2 to the front and make a lot of the rest of the >> text into subsequent explanatory material and/or appendices. >> >> (3) What architecture do you mean? >> >> There are 25 lines that mention the term architecture in the >> draft and I'm not at all sure the term is used to mean the same >> thing throughout. I'm also not sure that there is an accepted >> thing that is "the one true Internet architecture" that has >> IETF consensus but you seem to me to be assuming that there is >> such a beast. Is this just a language issue or a deep(er) >> problem? I'm not sure, but eliminating references to the >> Internet architecture where possible would I think help. See >> some of the specific comments below, but I'd recommend a pass >> over the document to check how this term is used as well. (To >> try head off some lines of debate that might follow from this >> comment, I do think there are aspects of Internet architecture >> for which we do have IETF consensus, but I don't think the IETF >> has consensus on any one way in which to put all those together >> into something that'd be rightly termed the (or an) Internet >> architecture. I think RFC1958 section 2.1 supports that >> position btw.) >> >> (4) What does "=3D" mean here? >> >> In section 2 and later (in 5.2.2) you have diagrams with >> bracketed terms on the left, then "=3D" and then another term on >> the right. I just don't get what you mean by that "=3D" sign. You >> say "combine" and "makes up" but frankly I don't get it, even >> though I was in some of the meetings where those pictures were >> presented. E.g. in section 2, I don't get how to combine >> authenticity and anonymity in any useful sense, as those are >> mostly in conflict. And the 2nd picture in section 2 has >> connectivity on the RHS, which you defined as being an "extent" >> and none of the things on the LHS seem to reflect that at all. >> While those pictures may well have been ok for use in >> presentations, I'm less happy that they're useful in an RFC. >> So, what does "=3D" mean? Can you actually define that relation? >> (Apologies if I'm being all "techie" and anal here, but I >> really don't get it, honest;-) >> >> (5) The DDoS discussion is still wrong. >> >> I think the discussion of DDoS in section 5.2.11 (see below for >> specifics) is not good enough and that section needs to be >> re-written or mostly deleted. (Not all list discussions need to >> end up with a section in the document.) It may be the case that >> what is needed is some discussion of forms of protest using the >> Internet, but that I think would better be the topic for >> another document, if soeone has the energy/interest. (That >> could be interesting too!) For this document, if it is aimed at >> the IETF audience, the current text is not useful as it ends up >> as a (controversial) NOOP - "don't enable DoS" is already in >> RFC3552 since 2003. >> >> (6) The questionnaire is not good enough. >> >> 5.3.2.x.y: Please go through these questions yourself (for some >> protocol) and write down answers and see then what you think of >> the questions. I think a number of these questions will not >> produce meaningful answers in any real attempt at using them. >> I also think that someone who is not an author and who is >> developing a new protocol needs to have gone through the >> exercise at least once before we should publish this document >> as any RFC. It is far too easy to ask unanswerable or >> non-useful questions otherwise. >> >> (7) Missing introductory text. >> >> I think there's a missing bit of explanatory text about rights >> in general that'd help some more IETF-oriented readers. As I >> understand it, in HR all rights are contingent in the sense >> that governments are expected to balance competing rights in >> all cases. So e.g. even though we have a right to life, >> governments can legislate for capital punishment and still >> consider themselves signed up to the UDHR. I think this is >> worth noting, as for example, it means that we do not >> necessarily want to enshrine all the fine concepts on which the >> IETF has consensus as human rights, in particular, claiming >> that one had a right to encrypt could as a side-effect allow >> some governments to claim that they had a right to limit one's >> knowledge of mathematics, if that is claimed to compete with >> other rights (e.g. to safety). I'm not sure if this is the >> right HRPC document to capture that, but it was a surprise for >> me when I first found that out, so it may be worth adding a bit >> of text explaining basic rights concepts like that here or >> somewhere else. >> >> Specific comments (without reference to importance:-) >> >> Note: I'm not quite sure why, but I read this through and >> commented as if it were a PhD thesis, which is a bit more >> stringent that e.g. IESG evaluation. Apologies if that seems >> like nitpicking, but I think given the possibly political >> (ab)uses to which this RFC could be put, and since we might >> effectively kill the impact of the RG if we do this first RFC >> badly, we might be better off to take that approach. I'm >> willing to believe that I'm being too nit-picky though:-) >> >> abstract: These ought not have references and I think is too >> long. I'd suggest keeping the 2nd para (minus the reference) >> and move the rest to the intro. >> >> intro, p3: How do you know that "open, secure and reliable" are >> necessary conditions here? I think you're likely correct, but >> I'm not sure that claim is justified in the document or in the >> references. >> >> intro, p3: "The Internet aims to be a global network of >> networks that provides unfettered connectivity to all users at >> all times and for any content [RFC1958]. " The "aims to be" >> there seems odd, and I don't see where 1958 says "at all times" >> which seems to me overstated. >> >> intro, p3: "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 >> network." Sure one could argue that but is that claimed as an >> RG consensus? And you're assuming that there is one true >> Internet architecture there I think, which is problematic. >> >> intro, p3: "By doing so, the IETF enabled the manifestation of >> the right to privacy, through the Internet's architecture." I >> think this shows a misconception of the IETF's role, at least >> as I see it. I don't believe that the IETF controls the >> Internet's architecture in the sense implied here. If you'd >> said "through it's protocol design processes" at the end >> instead, then I think that'd be better. And saying "Enabled" >> makes it sound like a done-deal and we can all go home, which >> strikes me as pretty optimistic;-) >> >> intro, p3, "Openness of communications of the technical design" >> what does that mean? And how does it "foster freedom of >> communication"? I don't get the argument here. >> >> intro, p3, "galvanize" is overstated and the IETF doesn't >> "ensure" what happens in the network, but only in the protocols >> we define - what implementers and operators do with that is >> really up to them and not the IETF. That's an important >> distinction that's mixed up in a few places in the document, >> including in the next sentence - if the IRTF produces this RFC, >> that's great and will help to ensure better realisation of HR >> issues, but the existence of the RFC itself will not ensure >> anything. >> >> section 2: "unfettered" - while I myself do like that term, I >> think following the approach from RFC 4084 which you quote here >> would be a good general approach for this entire document. >> 4084 section 1.2 says that it intentionally avoide pejorative >> terms so as to increase the likelihood that operators will pay >> attention. I think following that guidance in this document >> would be good. Most of the text is actually fine in this >> respect, but an editing pass based on a review from some (as >> yet uninvolved) protocol developers would be a good thing. For >> example, some of the references to companies and products later >> on might raise hackles in a way that'd be counter productive. >> Anyway, 4084 does not use the term unfettered at all so better >> to not say that here. >> >> section 2, and elsewhere: I think the use of the term anonymity >> is wrong in almost all cases in this document. While it is the >> case that users (and non-technical folk in general, including >> law makers) may talk about anonymity, I think there are few to >> zero technical folks who think that anonymity is achievable at >> any scale today. Tor may be the closest we get, but it's not at >> all clear to me that anonymity is really a requirement or a >> goal for almost all protocol designers almost all of the time. >> I do think we should consider "being hard to track" and similar >> as requirements/goals but that's different and I'm not sure we >> even have that good an idea about all the trade-offs that are >> involved here. I'd recommend checking every time you use this >> tern, and getting rid of most of them. (Will try to point out >> the ones I think are problematic below.) Note that the 4949 >> definition is probably ok(ish:-) but once there are muliple >> protocols involved things become very unclear and in real >> networks, there's almost always someone somewhere who can >> identify (or re-identify) a person, host or bit of s/w and that >> context seems to be missing here when you use the term. >> >> 2, Defining connectivity as an "extent" is interesting. I'm not >> sure if it's precise enough though, e.g., what'd "twice better >> connectivity" mean? Not sure what to suggest but I do think >> you're right to not define it as binary. Maybe refer to RFC4084 >> here again for some different types of connectivity? >> >> 2, "content-agnosticism" - hmm, that seems a bit broken to me >> as a definition, it is ok to treat delay intolerant traffic >> differently and we do want that sometimes. "Identically" seems >> too strong, but I'm not sure what better definition to use >> without getting into an essay about net neutrality and similar >> things that I don't know much about;-) >> >> 2, "end-to-end" - I much prefer to refer to this as an argument >> and not a principle. You'll get different opinions on that >> though:-) >> >> 2, "Internet censorship" - I think this definition is too broad >> and could even be read to discourage data minimisation. It >> seems to be missing the concept that the censor is acting >> without the agreement of the endpoints, but agreement/consent >> is such a slippy concept on the Internet maybe that'd be a bad >> idea. Anyway, this seems to broad to me fwiw. >> >> 2, "Internet Standards as an Arena for Conflict"... eh... >> What? That's not a term to define, it's an argument for over >> beer! I think you need to delete that from this section. If you >> want to include the text somewhere then find a better way to do >> that I'd say. (But I'd still then ask: where is the principle >> of constant change defined for all time? :-) >> >> 2, "i18n" - I think you're wrong that "Many protocols..." don't >> support i18n. It's for sure true that a bunch don't do this >> well and ought, but "many" seems overstated. Did you count >> them? (Note that for many binary protocols i18n isn't very >> relevant at all, if one assume that i18n is mostly important >> for end-users and less so for developers or bigger operators.) >> >> 2, "Open Standards Conform" - what? That's not a term to >> define. I think you also say this elsewhere so deleting this >> would be right. And what's RFC2606 got to do with it? >> >> 2, "Openness" - I think this is just wrong and am not sure what >> you even want to define. You cannot for example have free >> access to hosts in my home network, no matter how openly you >> ask:-) If you want to define openness, then I think it'd have >> to be about processes and not access to hosts. >> >> 2, "permissionless innovation" is not all about new protocols. >> It's also about using existing protocols in new ways without >> having to ask. Not all such uses are usefully described as new >> protocols. >> >> 2, "Privacy" - I think adding some references to the HR and >> legal literature about privacy could help the more technical >> readers here. >> >> 2, reliable, resiliance and robustness - I'm surprised there're >> no references for the first two and puzzled by the references >> for the 3rd. There also seem to be very few reference to these >> later, which makes it odd to find them here. I wonder if the >> formalism you're using (introduced at the end of section 2) has >> caused you to shoe-horn in definitions of these? >> >> 2, scalable - it's often a challenge in proocol design to >> ensure that a protocol scales down as well as up, in the sense >> of working well for smaller networks/deployments. Might be >> worth pointing that out as it's relevant here when one >> considers designing new protocols potentially putting too much >> emphasis on the requirements of only bigger operators (who are >> in the room). >> >> 2, stateless - is used exactly once later, and stateful is not >> used at all later - do you really need this here? (Just define >> it when used, but I think protocol developers will get the >> meaning anyway.) You could also say that retaining state has >> potential privacy impact, which may not be so obvious. (That >> retaining state impacts on other protocol features such as >> hard-reboot is fairly well understood I think.) >> >> 2, "Strong encryption / cryptography" I don't think this is >> needed or useful - why is it here? I think the IETF community >> know this already, is it useful for some other readership? If >> so who? (Since I'm not sure it'd be that useful for any >> readership.) >> >> 2, "transparent" - I don't like this definition which I think >> is not actually definining the term in the sense in which you >> use it in this document. As you actually use the term, it is >> mostly about processes, which is not what RFC2775 is about. In >> fact, I think you're actually using the term in it's normal >> English usage and don't really need a specific definition. >> (Though I didn't check all uses of the term.) >> >> 2, " The combination of reliability, confidentiality, >> integrity, anonymity, and authenticity is what makes up >> security on the Internet." No. That is just wrong. For example, >> that list omits DoS resilience, bugs (and protocol flaws) that >> cause problems like heartbleed, and I think, much else besides. >> I'm not sure how to fix this. (But see my general question wrt >> "=3D" as used here.) >> >> section 4: I don't accept that "protocols are politics by other >> means" - if I develop a way for two computers to interact in my >> (non-existent as it happens:-) basement, that is not politics. >> If I publish an academic paper on a faster way to do ECDH >> that's not politics. I know it's a quote, but I don't think >> you ought present that quote in that way (reading IMO as if it >> were an RG consensus statement) without qualification. The >> relevant qualification I think is tricky to formulate but has >> something to do with broad deployment or with deployment at >> some technical choke point that offers significant control to >> someone. >> >> 4: I don't get the "values-by-design" point and how it's >> relevant to the IETF. I don't recall discussions about that on >> IETF/IRTF lists. Is this perhaps something that's really being >> discussed outside the IETF/IRTF context? If so, then the >> statement that these are a "new focal point" is not correct. >> (If you want to say this should or could be a discussion to >> have, that'd be fine but that's a different statement.) >> >> 4: "tools of enforcement" - I'm not sure what you mean here. If >> you mean law enforcement then saying that would be better, but >> the sentence is vague, for me anyway so would be better >> rephrased. >> >> 4: "This document sets out some preliminary steps and >> considerations for engineers to take into account when >> developing standards and protocols." I think that's a good and >> fair statement of where this document is at. But don't you >> elsewhere go further? (CHECK) >> >> section 5: It'd be great if you could add links or references >> to the source materials here. For example, who'd you interview? >> Are the videos avaiable? What's the list of RFCs you read and >> which were considered (most) relevant? Similarly for WG lists >> analysed etc. I'm sure you have all that stuff and making that >> available for later would be great. >> >> 5.2.1.4 and 5.2.1.5: (See general point #4 above about "=3D") I >> don't think you actually have achieved this "the creation of a >> list of technical concepts that when combined create an >> enabling environment for human rights." It's a fine goal, but >> I'm not sure it's achievable in reality with the kind of >> precision claimed in this section. I don't think the terms >> used in the figure in 5.2.1.5 are at all precise TBH, e.g. the >> phrase "good enough" only occurs in this figure and nowehere >> else. >> >> 5.2.3: "These capabilities for network control and limitations >> of the freedom of expression by end hosts can be traced back to >> the IPv4 design..." I don't think you have justified this >> claim. My argument would be that there is no simlarly >> scaled/robust nework against which to compare IP and that does >> not have the feature that it allows deployments to limit >> freedom of expression. So it may be that this feature/bug is >> not IP specific but inherent in large networks. In any case, >> the claim seems too much to me. (That might be a useful topic >> for the RG to tackle, or maybe someone has already studied this >> issue?) >> >> 5.2.3.1: On what do you base the claim that source-routing >> could be better here? Source-routing seems to usually generate >> objections from transport folks. (You'd have to ask them for >> the history of that.) Spoofed source IP is a common mechaism >> for abuse. While you do say these are not considered good >> practice, you don't say why (or provide a reference) so it >> looks to this reader as if you're saying that those "features" >> could have been better, but without evidence for that. (Tor is >> lovely, but as currently defined, would not scale to the size >> of the Internet as it was quite some years ago.) >> >> 5.2.3.2: are you referring to the protocol number here? (As >> listed at [1]) That has about 140 protocols many of which >> aren't in widespread use. If so, then I question the claim >> that this is really the cause of DPI - I suspect that DPI >> devices mostly look deeper into the packet. That also seems to >> be indicated when you talk about transports and spdy. I think >> this section is confused about the differences between headers >> at various layers, and our history of sending cleartext. That >> said, I could see that in future, as we encypt more Internet >> traffic, someone may find rights-invading ways to use layer 3 >> headers but I'm not sure this is a significant issue today. (If >> there is evidence of this being done, I'd be interested in >> knowing about that. I guess there may be IPv6 options that are >> in use like that or have been suggested but you don't cover >> those at all that I can see.) >> >> [1] >> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xht= ml >> >> 5.2.3.3: I don't think mobile IP could never have displaced NAT >> for IPv4. We'd still have run out of addresses. So I'm not >> sure the point made here (that there was a "viable >> alternative") is correct at all. >> >> 5.2.4: "which enact ICANN's policy" Do you thnk that the ccTLDs >> would agree with that? I don't. >> >> 5.2.4: I think the fact that new gTLDs are hugely expensive is >> well worth a mention, as a deterrent to various freedoms. >> >> 5.2.4: I think you're missing some points here, maybe even an >> entire subsection. One of the ways around some of the issues >> listed is for clients to choose their resolver, e.g. so as to >> pick one that does check DNSSEC or that is not subject to the >> same regime as a default resolver. That can be blocked at the >> IP level, which is one issue. But even if I do that and use >> DPRIVE, then that creates a new threat of centralisation of >> lots of queries (e.g. at 8.8.8.8) which introduces yet another >> point at which control can be enforced or where traffic can be >> analysed. Passive DNS also has good and bad aspects. I'd say >> some or all of these points would be good to note. (But I'm not >> the right person to suggest good text sorry.) >> >> 5.2.5: The lack of a mandate for TLS was not the only reason >> why the web started out largely cleartext. There were also >> significant performance, UI, tooling and missing infrastructure >> issues, as well as the charging per certificate business model. >> Those were more important issues IMO, even though they do not >> nicely tie into the discussion of h2 and it's lack of a mandate >> for use of TLS. While I personally regret that, it was the >> result of a real and extended and open debate, which I think >> also ought be noted. >> >> 5.2.5 and 5.2.5.x: While I'm fine with you calling the >> development of TLS MitM devices and similar "malicious," I am >> pretty sure plenty of folks might argue that. It'd be better to >> skip the pejorative language I think, but it is entirely >> correct to have the references to the attacks mounted using >> such technologies. I'd also tend to not mention specific >> companies and products in the body of the text, except where >> that is really necessary to make the point. >> >> 5.2.5.1: How do you know it was Snowden's relevations that >> caused mail service providers (not ISPs!) to "follow Google's >> lead"? That may be correct, but I'm not sure there's the public >> evidence that they said that was why. (If there is, great, but >> please provide a reference, the one you do provide, [Peterson], >> is about gmail and not yahoo.) Also, Google use TLS, not SSL >> for gmail. >> >> 5.2.5.1: "less democratic" - I think it's an error to say that, >> since many countries that are considered role models for >> democracy could do the same things, "some countries" and >> examples would be better. Same with "oppressive regimes" - >> there's no need to include that judgement here. The reference >> here [RSF] wasn't accessible to me (no route to host) from a >> hotel network and eduroam. That could be nicely ironic, or a >> badly chosen reference. (But you need a reference.) The 2012 >> Libya report also really needs a reference. >> >> [RSF] >> https://en.rsf.org/syria-syria-using-34-blue-coat-servers-23-05-2013,4= 4664.html >> >> 5.2.5.2: wrt great-cannon, you might want to note that the IESG >> issued a related statement [2]. That's a bit tangential, but I >> think is relevant for this work. >> >> [2] >> https://www.ietf.org/iesg/statement/maximizing-encrypted-access.html >> >> 5.2.5.2: "Companies like" is pejorative and the patent >> application seems irrelevant. "has been largely documented" >> calls for a reference. "Oppressive regimes" is also not needed >> here as is "little concern for bad human rights records." The >> right thing here I think is to note the documented record >> without pejoratives and to then let the reader draw their own >> conclusions. >> >> 5.2.5.2: I don't think the text about h2 is fair. You're >> missing a) that there was a real and open debate on the topic, >> b) that some important implementations are exclusively h2/tls >> and c) that there is a spec for OS for HTTP being developed. >> Those are all as relevant as the fact that the outcome of the >> debate was to not mandate use of TLS all the time. (Which I do >> think is worth saying in this document, but needs more complete >> context.) >> >> 5.2.6: I think this section is missing some things. First, the >> IETF/XSF relationship is relevant here and needs a mention. (As >> both good and bad!) Second, OTR is important, as is the >> community's failure to produce a better e2e standard for xmpp. >> And lastly, I think the tendency of IM deployments to not >> deploy interoperable standarsd is missing, which also has good >> and bad aspects (good: they can do telegram etc, bad: no >> interop). I'd suggest asking an XMPP expert to review/suggest >> text. (Happy to help find you one if needed.) >> >> 5.2.6: "The protocol also has facets that may stifle speech as >> users self-censor for fear of surveillance, or find themselves >> unable to express themselves freely." That's not an XMPP >> specific point - the same applies to email and the web and to >> any other protocol that supports interpersonal messaging or >> access to sensitive information. I think you ought up-level >> this point to a more generic section that calls out issues with >> multiple protocols. (Not sure where exactly, but having it here >> only isn't great.) >> >> 5.2.7: Is this section about P2P in general (I'd consider P2P a >> design pattern) or about PPSPP or about BT? Each of those >> choices seems wrong. If the first, then that's not the same as >> other 5.2.x sections and doesn't mention other P2P protocols >> (e.g. RELOAD maybe). If the second, is the deployment of that >> sufficient to justify the text? If the 3rd - that's not an IETF >> protocol. So I'm not sure what to make of this. >> >> 5.2.7: Is it still true to say that P2P is an "increasingly >> becoming a popular architecture"? I thought usage stats were >> showing the opposite nowadays? The examples given are odd: as >> BTC doesn't do file sharing/interpersonal messaging, skype is >> no longer really P2P iiuc, and I don't know if spotify really >> is or not. Surely BT is the canonical real example? >> >> 5.2.7: "mostly delegated" - I'm not sure this is correct. I >> could argue that RELOAD is a counter example. I could further >> argue that the lack of deployment of RELOAD (iiuc) may be >> evidence that your implied argument that it'd be better for an >> organisation like the IETF to try produce complete specs in >> this space might be unwise in that it's less likely to result >> in deployment. >> >> 5.2.7.3: I think ledbat has some protocol features that would >> allow deployments (if they are nice) to reduce the scope for >> tracking. That's RFC 6817 but I'd have to reread it to check if >> there's something useful there, also not sure about ledbat >> deployment. >> >> 5.2.7.4: Sybil attacks in this context (e.g. astroturfing) seem >> to be relevant to more than p2p protocols. In fact wouldn't >> they be more common on web based systems, at least as exploited >> by/for governments and commercial entities? >> >> 5.2.8: There are many kinds of VPN - I think it'd be better to >> rename this section to something like "personal VPNs" or >> similar, as you don't get into e.g. corporate VPNs. >> >> 5.2.8.1: "local illegitimate wiretapping" - that's another >> pejorative term for some, "monitoring" would be just as clear. >> (Again, not because what you say is wrong, but because there's >> no point in antagonising those who read this.) >> >> 5.2.8.1: "are way less analyzed and understood" I think I >> recall some papers on these kinds of VPN that found some issues >> - be good to reference such work if possible, esp if there's a >> survey. >> >> 5.2.8.3: " VPN providers should at least be transparent on what >> information do they store and for how long is being kept" I >> fully agree with this, but what's it telling the IETF >> readership? Perhaps that RFCs ought identity potentially >> sensitive logged data or for how long that needs to be retained >> for technical reasons? That migth not belong here anyway but >> could be relevant somewhere in the document. >> >> 5.2.9: This could be shorter and may better as a part of >> section 5.2.5 - why is this one status code so important? >> >> 5.2.10: I'm really not sure this (all) belongs here. The >> middlebox debate is old and won't be resolved here, so I'm >> don't think it's worthwhile regurgitating the arguments in such >> detail. And I think you already said what you need to say when >> discussing NATs. I'd say deleting this section is maybe right. >> >> 5.2.10: (If you keep it) "IETF's role to prevent such >> censorship" again, the IETF is not the Internet police and does >> not "prevent" things like that. If you refer to the SPUD BoF, >> you should include references to the minutes etc. >> >> 5.2.10: "Middleboxes are becoming a proxy for the debate on the >> extent to which commercial interests are a valid reason to >> undermine the end- to-end principle." That seems like an >> opinion, and one I'd be surprised had consensus. Do you need to >> say that? >> >> 5.2.11: "Some people may say that DDoS attacks are the only >> mean to be heard, in the current Internet." Some people say >> that the moon landings were faked. Vague reportage like that is >> useless. I'd say this entire section needs to be redone with a >> strong statement that there is no valid use-case for DDos, and >> that DDoS is not a valid form of protest. I think such a >> statement is one that would have RG and indeed IETF consensus. >> I'm very sure that no concept of DDoS as a valid form of >> protest would garner consensus in either the RG or the IETF. >> >> 5.2.11: "seem to suggest that the IETF should try to ensure >> that their protocols cannot be used for DDoS attacks" That's >> very understated and maybe even misleading. I would say that >> the IETF has long-standing consensus that DDoS is an attack >> that protocols should mitigate to the extent they can and that >> DDoS vectors in protocols are basically bugs. RFC3552 (section >> 4.6) from 2003 covers this and says that standards MUST >> describe DoS issues. >> >> 5.2.11: The linkage between private sector control of networks >> and DDoS is IMO entirely unconvincing. NRENs are generally >> private sector and have major issues with DDoS. (I'm sitting in >> a talk on that topic right now.) It is not at all clear that >> anyone who'd claim that they are using a DDoS attack to protest >> would actually be protesting about a network operator - it is >> much more likely they are protesting about some content owner, >> who may be public or private sector. >> >> 5.2.11: I don't think we need or want the argument based on PM >> here at all. The argument about motivations for PM in RFC7258 >> depends on there being some justifiable reasons for monitoring. >> (Otherwise we would not need to even point out that motivations >> don't matter.) There are no such close-to-good arguments at all >> for DDoS, so drawing that analogy is misleading. >> >> 5.2.11: If the RG feel there is a need to discuss a possibility >> for fully opted-in people to collectively protest, (I do not) >> then you should invent a new term for that and clearly say that >> even though such protest might appear to the network as beng >> the same as a DDoS (and hence be treated as an attack), that is >> not the same as a DDoS, where 100% of real cases involve >> compromised hosts or hosts being used as reflectors without >> permission. If the RG feel there is a need to discuss forms of >> protest on the Internet, then I think an entirely different >> section is needed, probably with a different structure. >> >> 5.3.1: I'm not sure the "HR threats" model is the right thing >> here. The same was true of rfc6973 as well, as you say, but in >> this case, I'm not sure you really even need the concept. 5.3.2 >> just says stuff like "did you think about " so I don't see >> a need to say that " is a threat." I don't think you lose >> anything by losing that concept entirely. There is also a >> danger in including that risk analysis model here in that doing >> so might cause later disussion to be somewhat blinkered. >> >> 5.3.1: "This is by no means an attempt to cherry picks rights, >> if other rights seem relevant, please contact the authors >> and/or the hrpc mailinglist." I'd delete that, it's not that >> appropriate for an RFC (it was for an I-D). But if you do want >> to say something about a contact point, the RG list would be >> better. (The phrasing "cherry pick" is also a bit odd.) >> >> 5.3.2: The title here is a bit inaccurate and misleading. >> You're presenting guidelines for protocol designers, and not >> for "HR considerations." >> >> 5.3.2: I don't think that many IETFers follow or read RFC4101. >> (RFC4101 is a useful, good thing, but one that's not much used >> iiuc.) >> >> >> 5.3.2.1.2: We're updating RFC3552 now, and the update will >> include some guidance on privacy considerations. I'm not sure >> if it'd be better to reference that draft now or not though, as >> it's early days. Probably best to refer to BCP72 though, as >> that'll remain the right reference when the 3552bis work is >> done. >> >> 5.3.2.1.2: "Could your protocol counter traffic analysis, or >> data minimization?" oops - I don't think you want to counter >> data minimisation. Better to split that into two questions >> probably. >> >> 5.3.2.1.3: This set of questions need work. All protocols "look >> at the packet content" or else do nothing at all. I think you >> want to ask people to think about which fields in the packet >> they need to access and to try to minimize those, and if >> possible, discourage others from looking at the rest (e.g. by >> enabling encryption of those). I also have no clue what " Is >> the protocol transparent about its decisions?" means. And the >> last question is also pretty meaningless when looked at in >> isolation. (I think I already commented on the agnosticism >> phrase as used here before. The same issues apply to the >> explanatory text here.) >> >> 5.3.2.1.5: "readable by humans" is not the right criterion >> here. What you need to say is that "have to be understood by >> humans." For example, DNS names are mostly readable but IDNs >> are not, depending on which form one uses. For some protocols >> it is entirely fine still to use ascii for human-readable >> labels, if those are only seen by developers or more capable >> admins. >> >> 5.3.2.1.6: Re-using existing identifiers (e.g. MAC addresses) >> is the more common way that (re-)identification is enabled in >> protocols. You should point that out. I think the "make ... >> transparent" point is worth splitting from the identifier issue >> too - identifiers are very common, but making filtering >> apparent is much less so, and will be missed if you bundle >> these two things together. The last two questions aren't really >> useful though and are more explanatory text then real new >> questions. >> >> 5.3.2.1.7: These are not useful, as phrased for IETFers. The >> only useful part here is the 2nd last question (use other >> things that are proprietary), the rest are not as they are >> already handled in IETF processes, and we do not want yet more >> bureaucracy. The explanatory material is way too long and also >> not useful for the IETF audience. The example given is an >> interesting thing, but far from a typical protocol, so >> therefore is not a good example. >> >> 5.3.2.1.8: This entire section is useless for IETFers, except >> the last question about extensibility. The explanatory text and >> example however don't address that and are also not useful. >> >> 5.3.2.1.9: The question was asked already. Anonymity is not a >> useful goal in almost all IETF protocols, and if it were, it'd >> be a first order requirement (e.g. if we wrote an RFC for Tor) >> and would not be missed. Delete this section entirely. >> >> 5.3.2.1.10: The emphasis here is wrong. You should be asking >> about whether the protocol generates or processes anything that >> can be, or be tightly correlated with, PII. Many protocols have >> identifiers that are perfectly safe, until the host running the >> protocol is something that a person carries with them. The >> section needs a rewrite to take that approach. >> >> 5.3.2.1.11: Mixing accessibility and statefulness is wrong. >> Both are fine questions, but should not be bundled. The >> example is bad - HTML5 is the current spec and is not that RFC. >> >> 5.3.2.1.12: I think this is arguably duplicative and the issue >> will (or should) be caught via other IETF processes apart from >> HR considerations. I'd delete this, though it's mostly harmless >> here. >> >> 5.3.2.1.13: Again, this bundles things in a counterproductive >> manner. Split the topology/architecture points from the >> discriminaton/implication ones. (Even if you think those relate >> in terms of HR, that does not mean that they ought be bundled >> together in a questionnaire.) >> >> 5.3.2.1.14: I don't think this belongs in the questionnaire >> either. It's covered alredy in other IETF processes, when most >> relevant, so is not useful to ask about here. >> >> 5.3.2.1.15: This needs to be rewritten, there are 13 questions >> in the text which is entirely pointless. I would not bother to >> try answer those. You should just ask how confidentiality is >> supported and between what endpoints and how keying is done. >> (Or something like that, I didn't try the full re-write that is >> needed.) The re-write should also bundle this with most of the >> next two sections. (See below.) >> >> 5.3.2.1.15: The cryptographic parts of this should be merged >> into a rewritten 5.3.2.1.14. If there are non-crypto bits of >> this then those need better explanatory text as it'd not be >> relevant for most protocols. (I mean things like database >> consistency.) I'm not sure if anything would remain when this >> and the previous section were re-written.) >> >> 5.3.2.1.17: As per 5.3.2.1.16. >> >> 5.3.2.1.18: This is entirely duplicative and should be deleted. >> >> 5.3.2.1.19: I've no clue if this'd be useful to ask. Only >> testing would tell. (It might be, but I'm really not sure.) >> >> Nits/editorial... >> >> lots of places: there are too many over-long sentences that >> make this hard to read and less clear. I'd really recommend >> getting rid of as many of those as you can. The first non-quote >> paragraph of the intro is a good example. >> >> intro, "the core of the Internet, its architectural design >> is..." Using "core" is a bad term there, mostly we mean >> something quite different when we talk about the Internet's >> core or similar. (And that's another assumption that there's >> one true architecture.) >> >> intro, "properly defined, described and protected as such" - I >> don't think "defined" is needed there, and it might not be >> correct either. >> >> intro, "New protocols, particularly those that upgrade the core >> infrastructure of the Net, should be designed to continue to >> enable fundamental human rights." I'd drop the "core >> infrastructure" bit there, it's a distraction and liable to >> generate argument about what is or is not core, e.g. BGP is >> clearly core but is not otherwise mentioned in this document, >> and maybe correctly. >> >> intro, "The authors believe that the issues that have been >> raised by the reviewers have been addressed." Sorry to be >> raising more:-) >> >> section 2: I think some better formatting is needed here to >> distinguish the terms defined from the text, which in some >> cases is fairly long. Just add bullets or quoting or something. >> >> 2: "In the discussion of human rights and Internet architecture >> concepts developed in computer science, networking, law, >> policy-making and advocacy are coming together" Sorry, what is >> coming together in what discussion(s)? Too many commas there to >> be sure I think. (BTW, "architecture concepts" may well be an >> ok use of that word:-) >> >> 2, "censorship resistance" does not "prevent" censorship, I'd >> say mitigate is better than prevent. >> >> 2, "confidentiality" - why not refer to 4949 there? >> >> 2, "debugging" - the term debug is not used in the draft, why >> do you need the definition? >> >> 2, "decentralized" - why is "opportunity for" needed in this >> definition? I don't get that. >> >> 2, "technical this means..." needs fixing. >> >> 2, "Heterogenity" typo >> >> 2, "autonomous organizations" do you mean ASes? If so, say so. >> If not, better to avoid the word autonomous here. >> >> 2, "integrity" - why not refer to 4949? >> >> 2, "Inter-operable" is normally not hyphenated in the IETF >> >> 2, i18n - funny line breaks there make that hard to read >> >> 2, l10n - you don't actually use that abbreviation so why >> define it? >> >> 2, "The combination of the end-to-end principle, >> interoperability, resilience, reliability and robustness are >> the enableing factors that result in on the Internet. " That >> (non-)sentence needs fixing. I don't even know what you want to >> say tbh. >> >> section 3: I think this short section is missing text to the >> effect that you think the answer to question 2 is yes. >> >> section 4: you say "five clear positions" but they are not >> clearly delineated in the document. I'd suggest using some >> headings or some other way to make these more distinct in the >> document. >> >> 4: "embedded into the Internet's architecture" (top of p13) has >> another claim that there's one true Internet architecture. You >> could change this one to be the set of protocols defined by the >> IETF or something similar. >> >> 4: " As it stems from the issues as they arise in the field of >> technical engineering." That's not a sentence. >> >> 5: "step taken by the research group" that's ambiguous - I >> think you mean the set of authors and their research groups at >> home and not the HRPC, which I don't think collectively read >> all the RFCs you mean. (I think it's fine to say that the >> authors were the one who did the work, if that's what you >> mean.) >> >> 5.1: This section duplicates the intro to section 5. Is there a >> new point being made? >> >> 5.2: "(detailed under "2.vocabulary used")" do you mean section >> 2 there? Saying "Section 2" with the right xml2rfc incantation >> will cause the tools rendering to make that a link, which'd be >> nice. >> >> 5.2.1.1: "was assembly" typo. >> >> 5.2.1.5: figures are better numbered and with captions. >> >> 5.2.2.1: I guess there's a heading level bug here in the >> document sounce? >> >> 5.2.3.1: "ability for those hosts to assemble or to >> consensually express themselves" huh? When/how do hosts >> assemble or do things consensually? Confusing people and hosts >> like that is odd. >> >> 5.2.3.2: Why refer to spdy and not h2? And is that even a good >> reference? The 4906 reference also puzzled me. (Even more:-) >> >> 5.2.5: Why "because of it's simple design"? I'd have thought it >> was more complicated than that and that a combination of HTTP, >> HTML, open-source browsers and web servers and cool content was >> involved. >> >> 5.2.5: TLS and SSL could do with references. >> >> 5.2.5: Gen-ART? Huh? That's wrong. Gen-ART are fine people but >> they don't do what you say they do any more than any other set >> of IETFers. Are you confusing them with the IAB statement on >> encryption perhaps? Otherwise that is quite the puzzle for >> me:-) >> >> 5.2.5.1: What does "of the first" mean? "From the start"? >> >> 5.2.5.1: "have been corrected in TLS1.3" is in the wrong tense >> - "are being corrected" is correct. >> >> 5.2.5.1: TEMPORA, XKEYSCORE etc need references. Those can get >> hard to find later, at least good references can be hard to >> find. >> >> 5.2.6.1: I assume the URLs [1] and [2] don't need to be there >> and are xml2rfc artefacts to be fixed. Also, you should use >> example.com and example.net as per the usual way of handling >> examples in RFCs. >> >> 5.2.7: "often seen" - by whom? I'm not sure that IETFers would >> share that opinion, so better to say who you do mean. "remains >> critical" is also overstated. >> >> 5.2.7.1: "directed directly" typo >> >> 5.2.7.2: "throtteling" typo >> >> 5.2.7.5: Why does only this section have a conclusions >> subsction? I'd say be consistent. >> >> 5.2.8.1: you could lose the heading here (consistency again:-) >> >> 5.2.8.1: some VPNs (but not the ones you care about) are not >> point-to-point. >> >> 5.2.8.1: "There are multiple implementations and protocols used >> in provisioning a VPN" do you really mean provisioning a VPN >> there? That'd mean something else for some IETFers. I think you >> mean setting up a personal VPN for a single user but not quite >> sure. >> >> 5.2.8.5: The URL for [PET2015VPN] didn't work for me. I found >> the paper elsewhere though. >> >> 5.2.8.7: This bit seems fairly repetitive, other than the >> timing/correlation issues. You could maybe say that more >> briefly. >> >> 5.2.10: The URL for [Walfish] doesn't point at the named paper >> - what's up there? >> >> 5.2.11 (and elsewhere): "Many individuals, not excluding IETF >> engineers, have argued..." I hate constructs like that that >> assert that somebody somewhere (unnamed) thinks/says something. >> I don't see why any such assertions (of rumour basically) ought >> be in the RFC series. There are other examples of this >> construct in the draft. >> >> 5.2.11: Not all DoS attacks flood with traffic. Some might >> consume CPU cycles, in future some will consume limited power, >> and could be used in a DDoS. I don't think it's useful here >> (for the IETF audience) to define 3 types of DDoS attack. >> >> 5.3: "Having established how..." I don't think you established >> the "how." It'd be fair to do s/how/that/ though. (Twice.) That >> sentence is also overlong. Also "... by detailing how..." is >> similarly not correct. >> >> 5.3.1: 1st para is repetitive. Delete it. >> >> 5.3.1: The term "ICTs" isn't common in the IETF community. I'd >> say rephrase stuff to not use that. >> >> 5.3.2.x.y: Having such deep levels of TOC makes life harder for >> readers and those commenting and later using this. Flatten it >> tall out. Or, do you even need the 5.3.2.x.y headings at all? >> (Some of the section titles don't map that well to the >> content.) >> >> 5.3.2.1.1: s/e2e principle/e2e argument/ again:-) >> >> 5.3.2.1.1: the communication content would be concealed, not >> the act of communication >> >> 5.3.2.x.y: It'd be a very good idea to add an appendix that >> lists the questionnaire questions only (with those being >> numbered). That way, people who want to do this analysis can >> just use that part (at least the 2nd time). If doing that, >> please ensure each question also has an unique number/label in >> the body of the document too, so that folks can find/correlate >> things. >> >> 5.3.2.1.4: The last para of explanatory material should not >> re-define COMSEC etc. Just point people at RFC3552/BCP72. (But >> as BCP72.) The global adversary is also not purely passive, I'd >> lose that phrase. >> >> 5.3.2.1.5: "many protocols" is not usefully true I think. >> >> 10.2: delete this. >> >> >> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --UC5Dis7q8gttkor1FHvRbATKitsP5qTch 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 iQEcBAEBCAAGBQJX5ExnAAoJEAi1oPJjbWjpvcEIAKfnt1BPmmBSNPwcS6wtpuw0 2aQ/BGtS1fNGkOgv2GtqRmrsvKSrjHN7DugSsz8AZGHGTW4EnvDRV0qcPinJmVWM yZtmNZinvbXkoMtmkwsbyOFy3OWHe2KcS2gJHznlDMn35crEvYMdLQ4NtJw+Ly/2 PIc9rqEk84PNe1xdaID47iSfkva2rubXNfENlZDSEF6hD5aRFGSqgoXd2crZ5mTI xmwoAF97AajiLOKx3PCOEhxc9uQiT2T6splboiRxK1YQ5n4Dz++b7U0qAWwpTyoK H/kT31c19DRjamet5yRaaasnUqjf8RyV6bg3/clbRECa151hVWiG982bDXpRr3g= =ZiqG -----END PGP SIGNATURE----- --UC5Dis7q8gttkor1FHvRbATKitsP5qTch-- From nobody Thu Sep 22 14:41:14 2016 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 C799D12BF3B; Thu, 22 Sep 2016 14:41:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147458047077.22430.14160074212792384567.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2016 14:41:10 -0700 Archived-At: Cc: hrpc-chairs@ietf.org, niels@article19.org, hrpc@irtf.org, irtf-chair@irtf.org Subject: [hrpc] hrpc - New Meeting Session Request for IETF 97 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: Thu, 22 Sep 2016 21:41:11 -0000 A new meeting session request has just been submitted by Niels ten Oever, a Chair of the hrpc working group. --------------------------------------------------------- Working Group Name: Human Rights Protocol Considerations Area Name: IRTF Session Requester: Niels Oever Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: saag Second Priority: dnsop Third Priority: homenet Special Requests: please also not schedule together with openpgp ---------------------------------------------------------