From nobody Mon Sep 2 06:30:59 2019 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 A47A1120219 for ; Mon, 2 Sep 2019 06:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gub5pMKVIwU1 for ; Mon, 2 Sep 2019 06:30:50 -0700 (PDT) Received: from mail.gn.apc.org (mail.gn.apc.org [37.220.108.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351BB120169 for ; Mon, 2 Sep 2019 06:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id D71C6203C791 for ; Mon, 2 Sep 2019 14:30:47 +0100 (BST) X-Virus-Scanned: by amavisd-new at mail.gn.apc.org Received: from mail.gn.apc.org ([127.0.0.1]) by localhost (mail.gn.apc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4AVC4tVYwED for ; Mon, 2 Sep 2019 14:30:36 +0100 (BST) Received: from anonymous ([10.254.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: avri) by mail.gn.apc.org (Postfix) with ESMTPSA id 6638F203CAB7 for ; Mon, 2 Sep 2019 14:29:16 +0100 (BST) From: avri doria Autocrypt: addr=avri@apc.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemi yf8Pp8BdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K 1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV 5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOG B8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO7 6/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanx Fk4vCRfjfl8wt27n9xt27ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2HOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmEqG/rIj0w3XfV3bQsDBUU dH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrMMqO7SYUTB6Tx8vIoqmy/ T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq3lrUp2mRzDXBWZLhPVUq x6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006QeZQKfAZinaq3ICEyimWZ bLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wjzrwwsxypxUiEac/7bVwg Ev5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemiyf8Pp8BdIAQZAQIABgUC UleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K1oIc+pxGmr7RUfpOcB63 +1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV5mPBI7kWYNbD99278ZtY TO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOGB8par+/2zKx1MwrZFCnT tlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO76/QFmerwwN89qLAh1pAN oJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanxFk4vCRfjfl8wt27n9xt2 7ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWaSy7OQDKa1N838tTsRVLO MpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBslZea+G2UUV2WSXZPiTci 8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+GjqFR3R2AMLhwK/Nu9uw +cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z6yQ42xcvoUbQ6lLXW0fj NNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPgDoZoktZXmyHIh2E= To: hrpc@irtf.org Message-ID: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> Date: Mon, 2 Sep 2019 09:29:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Antivirus: Avast (VPS 190902-0, 09/02/2019), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 13:30:57 -0000 Hi, Recently there has been an ongoing discussion about taking this draft to Research group last call and then toward RFC using the IRTF process. Mallory and I have also been discussing it for a bit. =C2=A0 We are tryin= g to determine whether its time for the last call. During the Montreal session, from my remote perspective it seemed that there was a willingness for it move to last call, or at least no objection.=C2=A0 At least one person indicated they would do a review. Ar= e there reviews in progress that are on their way? At this point I wanted to ask the list, is it ready for a last call and are there people who have read it who either agree or who do not agree with taking it a step toward RFC. Does anyone object to taking it to last call. If you have read it and have a opinion/analysis, please do tel= l. I also want to confirm that the latest copy is still -03 as found in datatracker (17 May) https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ I have one other question about the draft at this point. In the Abstract, it claims=C2=A0 that it is 'undisputed' that the IETF process of developing standards is a political process. While I personally agree that it is a political process, reading through the history of the discussions on this issue, makes me hesitate to call it undisputed. While the question of the degree to which it is a political process does not necessarily need to be definitively resolved in a draft, it is enough to discuss the idea, we should probably be confident on the degree to which it is=C2=A0 indisputable, or not.=C2=A0 Thanks avri From nobody Mon Sep 2 08:41:46 2019 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 D86B3120071 for ; Mon, 2 Sep 2019 08:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAidD9CIcdAd for ; Mon, 2 Sep 2019 08:41:43 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 E4D34120024 for ; Mon, 2 Sep 2019 08:41:42 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i4oS5-0004wn-Gp for hrpc@irtf.org; Mon, 02 Sep 2019 17:41:40 +0200 To: hrpc@irtf.org References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Mon, 2 Sep 2019 17:41:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 938925967a2432a0d8c7279c30be63be Archived-At: Subject: Re: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 15:41:45 -0000 On 9/2/19 3:29 PM, avri doria wrote: > I also want to confirm that the latest copy is still -03 as found in > datatracker (17 May) Thanks for progressing on this discussion! -03 is indeed the most recent version. I have on little change ready, based on a suggestion of SM, to replace the sentence: The discussion list for the IRTF Human Rights Protocol Considerations working group is located at the e-mail address . Information on the group and information on how to subscribe to the list is at: with: The discussion list for the IRTF Human Rights Protocol Considerations Research Group is located at the e-mail address . Information on the group and information on how to subscribe to the list is at: https://github.com/IRTF-HRPC/drafts/commit/89dd530ce663750d14fb9647a4e4908c29552ad7#diff-fb9d617868a367dd946ef225cc5e6de1 But am not sure that warrants a new version already. Best, Niels -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Mon Sep 2 11:11:46 2019 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 5D43D12004E for ; Mon, 2 Sep 2019 11:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 V39V_QpFGl-w for ; Mon, 2 Sep 2019 11:11:43 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD05120047 for ; Mon, 2 Sep 2019 11:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10851; q=dns/txt; s=iport; t=1567447902; x=1568657502; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=KWGhoCYurwqTwCdKEVRLUPngrN36vMl1v5bVcdXHOTM=; b=mith4iAFPL5sxwOqyMYh6C5JiN6hLyejeYGH0EuIJ4Jv6eWZplsbtTU6 lp7Os/578HAIV0kvkgxb5AYAfL0pu3fIPNI60HyWqd1BWEXUhxfaiGpOa qxoXxoUTD+3fkhbRqRY6NG7X1buT+4SmP0OuXIPXxiWZsfByG7MqWuU69 g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAAAZWm1d/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBgRWBfkQgEiqEIYh8h3olhz+LUYgFAgc?= =?us-ascii?q?BAQEJAwEBLwEBhD8Cgw83Bg4CAwECAgMBAQQBAQECAQYEbYU6hUoBAQEDASN?= =?us-ascii?q?WBQsLGCoCAlcZgyIBgXsPqgCBMoVKhHIQgTQBgVCKP4F/gREnDBOCTD6HTzK?= =?us-ascii?q?CJgSMbIhcllGCKYIngRGRIxuCM4c2g3YnimCjMIMPAgQGBQIVgWYiKoEuMxo?= =?us-ascii?q?IGxU7KgGCQT4SEBSQFT4DMJAGAQE?= X-IronPort-AV: E=Sophos;i="5.64,460,1559520000"; d="asc'?scan'208,217";a="16207949" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Sep 2019 18:11:39 +0000 Received: from [10.61.200.200] ([10.61.200.200]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x82IBbQZ006480 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Sep 2019 18:11:38 GMT From: Eliot Lear Message-Id: <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_824FBA4F-44D6-4DA7-90D5-87F72CF2DBD2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 2 Sep 2019 20:11:37 +0200 In-Reply-To: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> Cc: hrpc@irtf.org To: avri@apc.org References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.200.200, [10.61.200.200] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 18:11:46 -0000 --Apple-Mail=_824FBA4F-44D6-4DA7-90D5-87F72CF2DBD2 Content-Type: multipart/alternative; boundary="Apple-Mail=_4B7D8616-CB78-47C3-91DB-6B0624FB890C" --Apple-Mail=_4B7D8616-CB78-47C3-91DB-6B0624FB890C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Avri, > On 2 Sep 2019, at 15:29, avri doria wrote: >=20 > Hi, >=20 > Recently there has been an ongoing discussion about taking this draft = to > Research group last call and then toward RFC using the IRTF process. > Mallory and I have also been discussing it for a bit. We are trying = to > determine whether its time for the last call. >=20 > During the Montreal session, from my remote perspective it seemed that > there was a willingness for it move to last call, or at least no > objection. At least one person indicated they would do a review. Are > there reviews in progress that are on their way? >=20 > At this point I wanted to ask the list, is it ready for a last call = and > are there people who have read it who either agree or who do not agree > with taking it a step toward RFC. Does anyone object to taking it to > last call. If you have read it and have a opinion/analysis, please do = tell. I do not think this work is ready. There are several major issues: The abstract does not clearly state what the paper attempts to address, = and thus it is not clear whether the goal has been achieved. Section 3 states a thesis (in exactly one sentence). Section 4 = addresses the thesis. And then there=E2=80=99s a Section 5 which has = nothing to do with the thesis. I presume the correction is to combine = section 3 and 4, but it leaves open what questions are meant to be = answered in this document, and to what end. There is not a clear delineation between protocols and standards. Why = are they viewed separately? Section 6 makes the following statement: =03 it is undisputed that standards and protocols are both products of a = political process, and they can also be used for political means. If it=E2=80=99s not disputed, then what were the earlier sections meant = to answer? The use of the terms =E2=80=9Cnormative=E2=80=9D and =E2=80=9Cde = facto=E2=80=9D requires clarity. The author is essentially saying that = standards are in effect normative, even if we claim them to be = voluntary. That should be stated more explicitly, because seems = central. People differ on what constitutes =E2=80=9Cde facto=E2=80=9D = vs. =E2=80=9Cde jure=E2=80=9D. In some people=E2=80=99s view, IETF = standards are de facto (I don=E2=80=99t hold that view myself, but some = government types certainly do). Most importantly, I am left with a major question: So what? What are = the implications of the answer to this question and why is it important = to ask. In addition, I have some questions about the supporting material. Regarding this text in Section 4.5: The process that led to [RFC6973] is similar: the Snowden disclosures, = which occured[sic] in the political space, engendered the IETF to act. I believe the author is actually referring to RFC 7258 (6973 was in the = RFC Editor queue when Snowden hit, and is the product of the IAB), but = even here, some additional support is necessary. 7258 was indeed = motivated by Snowden. But it addresses what is viewed as a technical = problem. That technical problem itself has political ramifications, but = this isn=E2=80=99t really teased out well. Keep in mind that people = supported the publication of that document for reasons of their own, and = we cannot really ascribe motivations. Section 1 of the document references RFC 49 with regard to privacy and = security. I understand the mention of security in that document, but = not privacy. Perhaps the author can clarify? I have not checked the other references, but I suggest that they be = checked. Eliot --Apple-Mail=_4B7D8616-CB78-47C3-91DB-6B0624FB890C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Avri,

On 2 Sep 2019, at 15:29, avri doria <avri@apc.org> = wrote:

Hi,

Recently there has been an = ongoing discussion about taking this draft to
Research = group last call and then toward RFC using the IRTF process.
Mallory and I have also been discussing it for a bit.   = We are trying to
determine whether its time for the last = call.

During the Montreal session, from my = remote perspective it seemed that
there was a willingness = for it move to last call, or at least no
objection.  = At least one person indicated they would do a review. Are
there reviews in progress that are on their way?

At this point I wanted to ask the list, is it = ready for a last call and
are there people who have read = it who either agree or who do not agree
with taking it a = step toward RFC. Does anyone object to taking it to
last = call. If you have read it and have a opinion/analysis, please do = tell.


I do not think this work = is ready.  There are several major issues:

  1. The = abstract does not clearly state what the paper attempts to address, and = thus it is not clear whether the goal has been achieved.
  2. Section 3 states a thesis (in exactly one sentence). =  Section 4 addresses the thesis.  And then there=E2=80=99s a = Section 5 which has nothing to do with the thesis.  I presume the = correction is to combine section 3 and 4, but it leaves open what = questions are meant to be answered in this document, and to what = end.
  3. There is not a clear delineation between = protocols and standards.  Why are they viewed separately?
  4. Section 6 makes the following statement: =03

    it is undisputed that standards and protocols = are both products of a political process, and they can also= be used for political means.

    If it=E2=80=99s not disputed, then what were the earlier = sections meant to answer?
  5. The use of the terms = =E2=80=9Cnormative=E2=80=9D and =E2=80=9Cde facto=E2=80=9D requires = clarity.  The author is essentially saying that standards are in = effect normative, even if we claim them to be voluntary.  That = should be stated more explicitly, because seems central.  People = differ on what constitutes =E2=80=9Cde facto=E2=80=9D vs. =E2=80=9Cde = jure=E2=80=9D.  In some people=E2=80=99s view, IETF standards are = de facto (I don=E2=80=99t hold that view myself, but some government = types certainly do).
  6. Most importantly, I am left with = a major question: So what?  What are the = implications of the answer to this question and why is it important to = ask.

In = addition, I have some questions about the supporting material. =  

Regarding= this text in Section 4.5:

The process that led to = [RFC6973] is similar: the Snowden disclosures, which occured[sic] in the = political space, engendered the IETF to = act.

I = believe the author is actually referring to RFC 7258 (6973 was in the = RFC Editor queue when Snowden hit, and is the product of the IAB), but = even here, some additional support is necessary.  7258 was indeed = motivated by Snowden.  But it addresses what is viewed as a technical problem.  That technical problem = itself has political ramifications, but this isn=E2=80=99t really teased = out well.  Keep in mind that people supported the publication of = that document for reasons of their own, and we cannot really ascribe = motivations.

Section 1 of the document references RFC 49 = with regard to privacy and security.  I understand the mention of = security in that document, but not privacy.  Perhaps the author can = clarify?

I have not = checked the other references, but I suggest that they be checked.

Eliot


= --Apple-Mail=_4B7D8616-CB78-47C3-91DB-6B0624FB890C-- --Apple-Mail=_824FBA4F-44D6-4DA7-90D5-87F72CF2DBD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl1tW1kACgkQh7ZrRtnS ejP/awf6AwmJyyFN3GoWIWX+Gd4+YcXMGIDiAqUqIoJxacrUoWwJ5YSNAlp6Rfne vGUQsrnrMPSudt2OmZnEUqikTaERdzro9aTp3g8m0sIzcKqogGmLnmlKMJpA19Oc W5N6dySn5lk1B9IXAbUY+24m/ByjPwm8MPmTz5zTa9a/QYm9huXxak5qcUkfQpra Cu+R1SbI51nCfUEu9nKZMQPw8QtuWxg7QXKgYaYH3+08iIdhYxLYc10NVZ4gb/O3 Y1lA+g1NLgaNV4ciY+Bz+N3UDjqwjciroUXA6wtAh0+nwUzVH1M/KZhmj5tBUaMf RG9PO1OdHR5n3mZVK18XEWOLQR722g== =8Ofp -----END PGP SIGNATURE----- --Apple-Mail=_824FBA4F-44D6-4DA7-90D5-87F72CF2DBD2-- From nobody Mon Sep 9 12:52:19 2019 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 E33351200F5 for ; Mon, 9 Sep 2019 12:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 sVyXWWhJmeiQ for ; Mon, 9 Sep 2019 12:52:14 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 B9E941200C7 for ; Mon, 9 Sep 2019 12:52:14 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i7Phl-0005cM-Ox; Mon, 09 Sep 2019 21:52:06 +0200 Date: Mon, 9 Sep 2019 12:50:43 +0200 From: Niels ten Oever To: Eliot Lear Cc: avri@apc.org, hrpc@irtf.org Message-ID: <20190909105043.GC26052@mir> References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eqp4TxRxnD4KrmFZ" Content-Disposition: inline In-Reply-To: <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Authenticated-As-Hash: 54a52893e10ae071b73780542c02a8d9e3f33e6f X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d10d7cb89ab8138c693deac6b6dd4d63 Archived-At: Subject: Re: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 19:52:17 -0000 --eqp4TxRxnD4KrmFZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Eliot, Thank you very for you review. On Mon, Sep 02, 2019 at 08:11:37PM +0200, Eliot Lear wrote: > Hi Avri, >=20 > > On 2 Sep 2019, at 15:29, avri doria wrote: > >=20 > > Hi, > >=20 > > Recently there has been an ongoing discussion about taking this draft to > > Research group last call and then toward RFC using the IRTF process. > > Mallory and I have also been discussing it for a bit. We are trying to > > determine whether its time for the last call. > >=20 > > During the Montreal session, from my remote perspective it seemed that > > there was a willingness for it move to last call, or at least no > > objection. At least one person indicated they would do a review. Are > > there reviews in progress that are on their way? > >=20 > > At this point I wanted to ask the list, is it ready for a last call and > > are there people who have read it who either agree or who do not agree > > with taking it a step toward RFC. Does anyone object to taking it to > > last call. If you have read it and have a opinion/analysis, please do t= ell. >=20 >=20 > I do not think this work is ready. There are several major issues: >=20 > The abstract does not clearly state what the paper attempts to address, a= nd thus it is not clear whether the goal has been achieved. I have added the following sentence to the abstract: This document aims to bring about a better understanding on the political n= ature of standards and protocols. > Section 3 states a thesis (in exactly one sentence). =20 As you know this part expanded and then got boiled down again to exactly sh= ow what this draft is about.=20 > Section 4 addresses the thesis. =20 This section addresses what opinions on the question exist within the commu= nity, and seeks to locate them within academic debates on this topic. > And then there=E2=80=99s a Section 5 which has nothing to do with the the= sis. =20 Section 5 documents the political nature of standard setting processes in g= eneral, so it does related to the question. > I presume the correction is to combine section 3 and 4, but it leaves ope= n what questions are meant to be answered in this document, and to what end. I think it is quite clear that the political nature of protocols has been e= xtensively discussed both on ietf@ietf, on this list, in plenary sessions a= nd in the hallways. Documenting those discussions in a structured manner, a= nd providing a framework to understand them will hopefully help us to progr= ess in this discussion. > There is not a clear delineation between protocols and standards. Why ar= e they viewed separately? Not all standards are protocols.=20 > Section 6 makes the following statement: =03 >=20 > it is undisputed that standards and protocols are both products of a poli= tical process, and they can also be used for political means. >=20 > If it=E2=80=99s not disputed, then what were the earlier sections meant t= o answer? Because it shows a qualified and nuanced answer to the research question. > The use of the terms =E2=80=9Cnormative=E2=80=9D and =E2=80=9Cde facto=E2= =80=9D requires clarity. The author is essentially saying that standards a= re in effect normative, even if we claim them to be voluntary. =20 Exactly, that is what emerges from the research. > That should be stated more explicitly, because seems central. =20 Does section 5 not do this sufficiently? > People differ on what constitutes =E2=80=9Cde facto=E2=80=9D vs. =E2=80= =9Cde jure=E2=80=9D. In some people=E2=80=99s view, IETF standards are de = facto (I don=E2=80=99t hold that view myself, but some government types cer= tainly do).> Most importantly, I am left with a major question: So what? W= hat are the implications of the answer to this question and why is it impor= tant to ask. As you know, previous versions of this document came up with recommendation= s. But it was then brought up that a research cannot make recommendations f= or the IETF. Therefore this document serves as a platform for further discu= ssion, and thus ensuring we don't need to repeat all the doscussions we've = had. >=20 > In addition, I have some questions about the supporting material. >=20 > Regarding this text in Section 4.5: >=20 > The process that led to [RFC6973] is similar: the Snowden disclosures, wh= ich occured[sic] in the political space, engendered the IETF to act. >=20 > I believe the author is actually referring to RFC 7258 (6973 was in the R= FC Editor queue when Snowden hit, and is the product of the IAB), but even = here, some additional support is necessary. 7258 was indeed motivated by S= nowden. But it addresses what is viewed as a technical problem. That tech= nical problem itself has political ramifications, but this isn=E2=80=99t re= ally teased out well. Keep in mind that people supported the publication o= f that document for reasons of their own, and we cannot really ascribe moti= vations. The argument that is made is that is was a technical argument, which was al= so a political position. It does not say what the psotion it, but it foregr= ounds the socio-political nature of a technical statement. >=20 > Section 1 of the document references RFC 49 with regard to privacy and se= curity. I understand the mention of security in that document, but not pri= vacy. Perhaps the author can clarify? >=20 I have added a semicolon to make sure it is understood that that reference = is only understood to link to security, and not privacy AND security. Thanks again for the review. I'll push a new version based on the changes. Best, Niels > I have not checked the other references, but I suggest that they be check= ed. >=20 > Eliot >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --=20 Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 643A 0ED8 3F3A 468A C8B3 --eqp4TxRxnD4KrmFZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl12LoMACgkQDtg/OkaK yLM0rw/+OjC3wjv833/BdyyH8wMfRfNWsZnfxEtQrTagBcxIOEEdNJFTyqn3OTON gLouSYcWxEXWt2a/aVf9yXZMh7+1p4Frh9HTsTbjhi6Nksc8nqfrcl8GuMbCrcQR D2+1hJW/WALhZ6+lGRDVBUYkdcgbp1vNXe92CjmMTvIaIAaEofzpDvKg3Up1egc/ GXhD4PY/Q5Cec2EkwxMqyKO2LtJ2CavLf3rIfZ9xaVLPpx8txVnDwfHCD1BBrLTu vRdvzdxn0xfwg/iDyEn2+kPqsAbcmFTJ8oSwbLYprUYzrAZx/Ki895ABnjP/FGBq CCPWSUS3jnIjv0v0DqYm6wHu5MyLXOBKBKZqnc8fsO+hA7mfUQfdM6ebDLDOKhi0 29xrnPRkDj7hwRg+Y4gFUK+h5Kh0C4UZrI5OpxeBHfVGu93swu2UdI832HDeDAwR 7B/e8Icd2vHYPMYI58jpzfvowrEcvtfHEoQnd1aH6o5nte8+zjGGjhMsFiMZHXZW xkV1GpcHA+X804h3HZf1Piz76GdYvFrzd0Wmse0lxxV50knf3I0TS0EzKYRwHtZf mGCXPfqPdOibxZgjddx4U5XqnELyu1wYXjUDmUwR5/egqF1EIjO8zaXxJ3A0R2ve /9KUEHDKRw9QEYFLjyWRrmvai4ZtZGaf99rDYsR/tU6JIfJVm58= =DMPU -----END PGP SIGNATURE----- --eqp4TxRxnD4KrmFZ-- From nobody Mon Sep 9 13:14:11 2019 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 6DB551200A1 for ; Mon, 9 Sep 2019 13:14: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzPuTLA4HJLQ for ; Mon, 9 Sep 2019 13:14:07 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 D6DD0120048 for ; Mon, 9 Sep 2019 13:14:06 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i7Q2Y-0003IL-3i for hrpc@irtf.org; Mon, 09 Sep 2019 22:14:04 +0200 To: hrpc@irtf.org References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> <20190909105043.GC26052@mir> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <226bc1dc-0b1b-eeaf-07b9-ca032417df79@nielstenoever.net> Date: Mon, 9 Sep 2019 22:13:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190909105043.GC26052@mir> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0waEzVzgDBireC5HG03u9JCiQV69kMLLI" X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 489808b07d62a0c4c5724b3b0aec1e0b Archived-At: Subject: Re: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 20:14:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0waEzVzgDBireC5HG03u9JCiQV69kMLLI Content-Type: multipart/mixed; boundary="fUcIw5sjB7Jh0Dq2zyxFWYTxSQy4ZzVzo"; protected-headers="v1" From: Niels ten Oever To: hrpc@irtf.org Message-ID: <226bc1dc-0b1b-eeaf-07b9-ca032417df79@nielstenoever.net> Subject: Re: [hrpc] status on draft-irtf-hrpc-political References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> <20190909105043.GC26052@mir> In-Reply-To: <20190909105043.GC26052@mir> --fUcIw5sjB7Jh0Dq2zyxFWYTxSQy4ZzVzo Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Eliot, Of course I meant to say 'thank you very much for your review', was typin= g in a tight airplane seat, that probably did not help. Am currently struggling a bit with xml2rfc, but expect to push a new vers= ion soon. The changes can already be found here: https://github.com/IRTF-HRPC/drafts/commits/master/draft-political.md Best, Niels On 9/9/19 12:50 PM, Niels ten Oever wrote: > Hi Eliot, >=20 > Thank you very much for your review. >=20 > On Mon, Sep 02, 2019 at 08:11:37PM +0200, Eliot Lear wrote: >> Hi Avri, >> >>> On 2 Sep 2019, at 15:29, avri doria wrote: >>> >>> Hi, >>> >>> Recently there has been an ongoing discussion about taking this draft= to >>> Research group last call and then toward RFC using the IRTF process. >>> Mallory and I have also been discussing it for a bit. We are trying= to >>> determine whether its time for the last call. >>> >>> During the Montreal session, from my remote perspective it seemed tha= t >>> there was a willingness for it move to last call, or at least no >>> objection. At least one person indicated they would do a review. Are= >>> there reviews in progress that are on their way? >>> >>> At this point I wanted to ask the list, is it ready for a last call a= nd >>> are there people who have read it who either agree or who do not agre= e >>> with taking it a step toward RFC. Does anyone object to taking it to >>> last call. If you have read it and have a opinion/analysis, please do= tell. >> >> >> I do not think this work is ready. There are several major issues: >> >> The abstract does not clearly state what the paper attempts to address= , and thus it is not clear whether the goal has been achieved. >=20 > I have added the following sentence to the abstract: >=20 > This document aims to bring about a better understanding on the politic= al nature of standards and protocols. >=20 >> Section 3 states a thesis (in exactly one sentence). =20 >=20 > As you know this part expanded and then got boiled down again to exactl= y show what this draft is about.=20 >=20 >> Section 4 addresses the thesis. =20 >=20 > This section addresses what opinions on the question exist within the c= ommunity, and seeks to locate them within academic debates on this topic.= >=20 >> And then there=92s a Section 5 which has nothing to do with the thesis= =2E =20 >=20 > Section 5 documents the political nature of standard setting processes = in general, so it does related to the question. >=20 >> I presume the correction is to combine section 3 and 4, but it leaves = open what questions are meant to be answered in this document, and to wha= t end. >=20 > I think it is quite clear that the political nature of protocols has be= en extensively discussed both on ietf@ietf, on this list, in plenary sess= ions and in the hallways. Documenting those discussions in a structured m= anner, and providing a framework to understand them will hopefully help u= s to progress in this discussion. >=20 >> There is not a clear delineation between protocols and standards. Why= are they viewed separately? >=20 > Not all standards are protocols.=20 >=20 >> Section 6 makes the following statement: =03 >> >> it is undisputed that standards and protocols are both products of a p= olitical process, and they can also be used for political means. >> >> If it=92s not disputed, then what were the earlier sections meant to a= nswer? >=20 > Because it shows a qualified and nuanced answer to the research questio= n. >=20 >> The use of the terms =93normative=94 and =93de facto=94 requires clari= ty. The author is essentially saying that standards are in effect normat= ive, even if we claim them to be voluntary. =20 >=20 > Exactly, that is what emerges from the research. >=20 >> That should be stated more explicitly, because seems central. =20 >=20 > Does section 5 not do this sufficiently? >=20 >> People differ on what constitutes =93de facto=94 vs. =93de jure=94. I= n some people=92s view, IETF standards are de facto (I don=92t hold that = view myself, but some government types certainly do).> Most importantly, = I am left with a major question: So what? What are the implications of t= he answer to this question and why is it important to ask. >=20 > As you know, previous versions of this document came up with recommenda= tions. But it was then brought up that a research cannot make recommendat= ions for the IETF. Therefore this document serves as a platform for furth= er discussion, and thus ensuring we don't need to repeat all the doscussi= ons we've had. >=20 >> >> In addition, I have some questions about the supporting material. >> >> Regarding this text in Section 4.5: >> >> The process that led to [RFC6973] is similar: the Snowden disclosures,= which occured[sic] in the political space, engendered the IETF to act. >> >> I believe the author is actually referring to RFC 7258 (6973 was in th= e RFC Editor queue when Snowden hit, and is the product of the IAB), but = even here, some additional support is necessary. 7258 was indeed motivat= ed by Snowden. But it addresses what is viewed as a technical problem. = That technical problem itself has political ramifications, but this isn=92= t really teased out well. Keep in mind that people supported the publica= tion of that document for reasons of their own, and we cannot really ascr= ibe motivations. >=20 > The argument that is made is that is was a technical argument, which wa= s also a political position. It does not say what the psotion it, but it = foregrounds the socio-political nature of a technical statement. >=20 >> >> Section 1 of the document references RFC 49 with regard to privacy and= security. I understand the mention of security in that document, but no= t privacy. Perhaps the author can clarify? >> >=20 > I have added a semicolon to make sure it is understood that that refere= nce is only understood to link to security, and not privacy AND security.= >=20 > Thanks again for the review. I'll push a new version based on the chang= es. >=20 > Best, >=20 > Niels >=20 >=20 >> I have not checked the other references, but I suggest that they be ch= ecked. >> >> Eliot >> >> >=20 >=20 >=20 >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --=20 Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 643A 0ED8 3F3A 468A C8B3 --fUcIw5sjB7Jh0Dq2zyxFWYTxSQy4ZzVzo-- --0waEzVzgDBireC5HG03u9JCiQV69kMLLI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl12smkACgkQDtg/OkaK yLMd1hAApq1hZpXCl+lp0MEgscuU67GqQ9Xbi8tKwewf2gfTcu9FKZ4pbcJ3kvej bfkdpfZer3fYXmnJMv4t/W5YEVZ+4Y7CWALjGBJe7Ca2ejbzd+r8wK8QLPVarN4O 6mJ1XoA3+EQrlFTVEmN18Dk6z5LIZWERRiCWYErtvC5dF8aKFri3I+AqVsLQ3kQ2 GsvvZLQUhBA0hVPCGV6g3lHiATfWLKXzLsiFAP4mx8nyZ0ZNa8s4Qb6LsqIcoPKF QcN3f9s9Rd43x7L3k1pSIV6VXEO5JJIDF1PhomHKlIw4T37zgigPkJt7+q5WnRxC YQOLkPQ4jxAJj5Ck+6g+sPZUEJ88F4vnINVu8O3rQJ+0F1Tlr6z5zcrcKDNi5xH6 XGIcDVWilJL8EtdvLBVWQRXMaPRD1mnf5Mv4QSIJsr6puiP4cDkeL4cvz75TcNlv BXlVRYp565P8EIT5aplRX+7f1U80OSm7o9nIzAdZ1iXiQkeW0Z+SmbVo7hQ2e5Zo 33blGPwns/+4mxvD2KqOW7gUWofyXqQFFgfd0dhORCM6NPnAID2fe8ZJ4vSQxw/0 ND3aagJdT9etS7Lw9W/2OCM2KngJlO1RGdPi7eQ7qVoTqlJ/eqmXrW8G8hYkUsx/ fSrPwBIao+p/W35LhCOTwlqWbZ5vhRMgM1z2SjD83eZhYCz3+EQ= =Xciq -----END PGP SIGNATURE----- --0waEzVzgDBireC5HG03u9JCiQV69kMLLI-- From nobody Mon Sep 9 23:26:13 2019 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 3BFC8120882 for ; Mon, 9 Sep 2019 23:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skCH3Ufo1iKx for ; Mon, 9 Sep 2019 23:26:09 -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 CC20B120875 for ; Mon, 9 Sep 2019 23:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36752; q=dns/txt; s=iport; t=1568096769; x=1569306369; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=BkooFqAC/WRdQtz+ZIW/avPo9a1v24XIjxfoKhFVTk4=; b=MYFJWL7TkGMChS/Dg0HtCPYQO6gCwqoqaZXz6XTOncLN1/pQ/To12PVU nasa5RdTxXQ6bTjVP7SAphJlXNNiHthqD1aG1cNwe0PNpzL22ApH8wrFd m3wCSAmQ1UETCZdjqiqdQ0WvgedAI+MkdwsL6QMcY062wGGpVcOKNAI3U Y=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAADhQHdd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZwKBFIFvUyASKoQhiHyFYIIdJYdDjUmGCwICBwEBAQk?= =?us-ascii?q?DAQElCgEBhD8Cgls4EwIDCQEBBAEBAQIBBgRthS4MQgEQAYR2AQEBAQEBASN?= =?us-ascii?q?WBQsLGCABCQICVwYTFIMOATSBRw8PA6YvgTKENgFRA0CEagoGgTQBgVCIBgS?= =?us-ascii?q?CNYF/gREnDBOBTn4+gXloAQIBgT8BAYMpMoImBJR/XogVjlGCK4IsgRGIT4h?= =?us-ascii?q?oG4I0hz6DeieGR4QqjzeUI4MRAgQGBQIVgWkhKoEaDAgzGggbFTsqAYJBPoI?= =?us-ascii?q?QF4hjhUE+AzABCQmEDIlEgkUBAQ?= X-IronPort-AV: E=Sophos;i="5.64,487,1559520000"; d="asc'?scan'208,217";a="16539382" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Sep 2019 06:26:05 +0000 Received: from [10.61.225.239] ([10.61.225.239]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8A6Q3QY007681 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Sep 2019 06:26:04 GMT From: Eliot Lear Message-Id: <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F5EA76FF-85AC-42ED-A517-ED073A772862"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 10 Sep 2019 08:26:00 +0200 In-Reply-To: <20190909105043.GC26052@mir> Cc: avri@apc.org, hrpc@irtf.org To: Niels ten Oever References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> <20190909105043.GC26052@mir> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.225.239, [10.61.225.239] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 06:26:12 -0000 --Apple-Mail=_F5EA76FF-85AC-42ED-A517-ED073A772862 Content-Type: multipart/alternative; boundary="Apple-Mail=_2FBC2332-B9DB-43B7-B96A-B8FEAAD538BB" --Apple-Mail=_2FBC2332-B9DB-43B7-B96A-B8FEAAD538BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Niels, I will look for your update. I understand your enthusiasm and = impatience to publish (I share with you both of those traits myself = after a certain point). Now please see below. > On 9 Sep 2019, at 12:50, Niels ten Oever = wrote: >=20 > Hi Eliot, >=20 > Thank you very for you review. >=20 > On Mon, Sep 02, 2019 at 08:11:37PM +0200, Eliot Lear wrote: >> Hi Avri, >>=20 >>> On 2 Sep 2019, at 15:29, avri doria wrote: >>>=20 >>> Hi, >>>=20 >>> Recently there has been an ongoing discussion about taking this = draft to >>> Research group last call and then toward RFC using the IRTF process. >>> Mallory and I have also been discussing it for a bit. We are = trying to >>> determine whether its time for the last call. >>>=20 >>> During the Montreal session, from my remote perspective it seemed = that >>> there was a willingness for it move to last call, or at least no >>> objection. At least one person indicated they would do a review. = Are >>> there reviews in progress that are on their way? >>>=20 >>> At this point I wanted to ask the list, is it ready for a last call = and >>> are there people who have read it who either agree or who do not = agree >>> with taking it a step toward RFC. Does anyone object to taking it to >>> last call. If you have read it and have a opinion/analysis, please = do tell. >>=20 >>=20 >> I do not think this work is ready. There are several major issues: >>=20 >> The abstract does not clearly state what the paper attempts to = address, and thus it is not clear whether the goal has been achieved. >=20 > I have added the following sentence to the abstract: >=20 > This document aims to bring about a better understanding on the = political nature of standards and protocols. I think there=E2=80=99s more to be said. Please read down. >=20 >> Section 3 states a thesis (in exactly one sentence). >=20 > As you know this part expanded and then got boiled down again to = exactly show what this draft is about. >=20 >> Section 4 addresses the thesis. >=20 > This section addresses what opinions on the question exist within the = community, and seeks to locate them within academic debates on this = topic. Again, think about it from the reader=E2=80=99s perspective. How many = papers have you read that has a single sentence section? My suggestion = is simply to state the question in Section 1 and eliminate Section 3. = In fact, it might make for a good first sentence. It=E2=80=99s bold and = invites exploration. >=20 >> And then there=E2=80=99s a Section 5 which has nothing to do with the = thesis. >=20 > Section 5 documents the political nature of standard setting processes = in general, so it does related to the question. Ok, on closer reading I think you=E2=80=99re right, and I was wrong on = that point. I still think your exploration should go a bit further. While I like = that you talk about interference in order to promote de facto standards, = one can also show examples of interference to disrupt de facto = standards. In fact, the entire de jure standardization process is a = form of that disruption. In addition, one can find a great many examples of where purported de = jure standards are never implemented, even absent interference. One = need only look at certain international standards bodies=E2=80=99 work = to see it littered with science experiments (that includes the IETF), = and the sad state of affairs with regard to network security. A simple = imprimatur does not guarantee implementation =E2=80=93 thus the notion = of =E2=80=9Cvoluntary=E2=80=9D. There has to be something more: there = has to be an economic need for the standard (de jure or de facto). = Professor Rebecca Henderson @ Harvard has done a lot of work on this = subject, and on technology in general (I=E2=80=99m a big fan). May be = worth adding to your literature review, but it goes beyond the bounds of = Section 4, which is really focused on a single question. Putting that previous paragraph more simply, it would be useful to bound = the effects you are attempting to characterize. You might even show a = few examples. To name a few, we can borrow a bit from the ITAT workshop = report in RFC 7305 and RFC 5218, looking at Bitcoin (see B=C3=B6hme[1]), = DNSSEC (see Eklund L=C3=B6winder[2]), and of course our two favorites, = IPv6 and HTTP. In fact, such a correlation would be, I think, a great = addition, even if it is follow-on work. If you want to go even further in terms of formal analysis, you may wish = to review Greenstein and Stango.[3]. The nice thing about that book is = that it gets well beyond the IETF or even Internet technology, but also = includes some. Its examples are a bit dated, tho. >=20 >> The use of the terms =E2=80=9Cnormative=E2=80=9D and =E2=80=9Cde = facto=E2=80=9D requires clarity. The author is essentially saying that = standards are in effect normative, even if we claim them to be = voluntary. >=20 > Exactly, that is what emerges from the research. Then isn=E2=80=99t that a far stronger thesis? The question you are = asking in Section 3 is trivially true, IMHO. It boils down to the old = maxim, that politics exists in a room of more than one person. Which = brings me to my next point. >=20 >> I am left with a major question: So what? What are the implications = of the answer to this question and why is it important to ask. >=20 > As you know, previous versions of this document came up with = recommendations. But it was then brought up that a research cannot make = recommendations for the IETF. Therefore this document serves as a = platform for further discussion, and thus ensuring we don't need to = repeat all the discussions we've had. I fear you may have taken away the wrong conclusion from those = discussions. It is perfectly fine to make recommendations to the IETF. = Indeed I would say that the IRTF is at its best when it can make = recommendations. You just cannot do so in a normative fashion from the = IRTF. More importantly, showing some example of societal benefit/harm = will ground the work. Just be sure to ground your analysis in your = recommendations. >=20 >>=20 >> In addition, I have some questions about the supporting material. >>=20 >> Regarding this text in Section 4.5: >>=20 >> The process that led to [RFC6973] is similar: the Snowden = disclosures, which occured[sic] in the political space, engendered the = IETF to act. >>=20 >> I believe the author is actually referring to RFC 7258 (6973 was in = the RFC Editor queue when Snowden hit, and is the product of the IAB), = but even here, some additional support is necessary. 7258 was indeed = motivated by Snowden. But it addresses what is viewed as a technical = problem. That technical problem itself has political ramifications, but = this isn=E2=80=99t really teased out well. Keep in mind that people = supported the publication of that document for reasons of their own, and = we cannot really ascribe motivations. >=20 > The argument that is made is that is was a technical argument, which = was also a political position. It does not say what the position it, but = it foregrounds the socio-political nature of a technical statement. Yes- but your statement could be read to infer political motivations on = the part of the IETF. And that is what I would be cautious about. I = think this is editorial. Regards, Eliot [1] = https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_5.= docx [2] = https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_17= .pdf [3] = https://www.cambridge.org/core/books/standards-and-public-policy/9439DB66D= 660C8131578652F547A9E82 --Apple-Mail=_2FBC2332-B9DB-43B7-B96A-B8FEAAD538BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Niels,

I will look = for your update.  I understand your enthusiasm and impatience to = publish (I share with you both of those traits myself after a certain = point).

Now = please see below.

On 9 Sep 2019, at 12:50, Niels = ten Oever <mail@nielstenoever.net> wrote:

Hi Eliot,

Thank you very for you = review.

On Mon, Sep = 02, 2019 at 08:11:37PM +0200, Eliot Lear wrote:
Hi = Avri,

On= 2 Sep 2019, at 15:29, avri doria <avri@apc.org> wrote:

Hi,
Recently there has been an ongoing discussion = about taking this draft to
Research group last call and = then toward RFC using the IRTF process.
Mallory and I have = also been discussing it for a bit.   We are trying to
determine whether its time for the last call.
During the Montreal session, from my remote perspective it = seemed that
there was a willingness for it move to last = call, or at least no
objection.  At least one person = indicated they would do a review. Are
there reviews in = progress that are on their way?

At this = point I wanted to ask the list, is it ready for a last call and
are there people who have read it who either agree or who do = not agree
with taking it a step toward RFC. Does anyone = object to taking it to
last call. If you have read it and = have a opinion/analysis, please do tell.


I do not think this work is ready.  There = are several major issues:

The abstract does = not clearly state what the paper attempts to address, and thus it is not = clear whether the goal has been achieved.

I have added the following = sentence to the abstract:

This document aims to bring about a better understanding on = the political nature of standards and protocols.

I think = there=E2=80=99s more to be said.  Please read down.


Section= 3 states a thesis (in exactly one sentence).  

As you know this part expanded and then got boiled down again = to exactly show what this draft is about. 

Section= 4 addresses the thesis.  

This section addresses what = opinions on the question exist within the community, and seeks to locate = them within academic debates on this topic.

Again, = think about it from the reader=E2=80=99s perspective.  How many = papers have you read that has a single sentence section?  My = suggestion is simply to state the question in Section 1 and eliminate = Section 3.  In fact, it might make for a good first sentence. =  It=E2=80=99s bold and invites exploration.


And = then there=E2=80=99s a Section 5 which has nothing to do with the = thesis.  

Section 5 documents the political nature of standard setting = processes in general, so it does related to the question.


Ok, on closer reading I think you=E2=80=99re = right, and I was wrong on that point.

I still think your exploration should go a bit = further.  While I like that you talk about interference in order to = promote de facto standards, one can also show examples of interference = to disrupt de facto standards.  In fact, the entire de jure = standardization process is a form of that disruption.

In addition, one can find a great many examples of = where purported de jure standards are never implemented, even absent = interference.  One need only look at certain international = standards bodies=E2=80=99 work to see it littered with science = experiments (that includes the IETF), and the sad state of affairs with = regard to network security.  A simple imprimatur does not guarantee = implementation =E2=80=93 thus the notion of =E2=80=9Cvoluntary=E2=80=9D. =  There has to be something more: there has to be an economic need = for the standard (de jure or de facto).  Professor Rebecca = Henderson @ Harvard has done a lot of work on this subject, and on = technology in general (I=E2=80=99m a big fan).  May be worth adding = to your literature review, but it goes beyond the bounds of Section 4, = which is really focused on a single question.

Putting that previous paragraph more simply, it = would be useful to bound the effects you are attempting to characterize. =  You might even show a few examples.  To name a few, we can = borrow a bit from the ITAT workshop report in RFC 7305 and RFC 5218, = looking at Bitcoin (see B=C3=B6hme[1]), DNSSEC (see Eklund L=C3=B6winder[2]), and of course our two favorites, = IPv6 and HTTP.  In fact, such a correlation would = be, I think, a great addition, even if it is follow-on = work.

If you want to go even further = in terms of formal analysis, you may wish to review Greenstein and = Stango.[3]. The nice thing about that book is that it gets well beyond = the IETF or even Internet technology, but also includes some.  Its = examples are a bit dated, tho.



The use of the terms =E2=80=9Cnormative= =E2=80=9D and =E2=80=9Cde facto=E2=80=9D requires clarity.  The = author is essentially saying that standards are in effect normative, = even if we claim them to be voluntary.  

Exactly, that is what emerges from the research.


Then isn=E2=80=99t that a far stronger thesis? =  The question you are asking in Section 3 is trivially true, IMHO. =  It boils down to the old maxim, that politics exists in a room of = more than one person.  Which brings me to my next = point.



I am left with a major question: So = what?  What are the implications of the answer to this question and = why is it important to ask.

As you know, previous versions = of this document came up with recommendations. But it was then brought = up that a research cannot make recommendations for the IETF. Therefore = this document serves as a platform for further discussion, and thus = ensuring we don't need to repeat all the discussions we've = had.


I fear you may have taken away the wrong = conclusion from those discussions.  It is perfectly fine to make = recommendations to the IETF.  Indeed I would say that the IRTF is = at its best when it can make recommendations.  You just cannot do = so in a normative fashion from the IRTF.  More importantly, showing = some example of societal benefit/harm will ground the work.  Just = be sure to ground your analysis in your recommendations.



In addition, I have some questions about the supporting = material.

Regarding this text in Section = 4.5:

The process that led to [RFC6973] is = similar: the Snowden disclosures, which occured[sic] in the political = space, engendered the IETF to act.

I = believe the author is actually referring to RFC 7258 (6973 was in the = RFC Editor queue when Snowden hit, and is the product of the IAB), but = even here, some additional support is necessary.  7258 was indeed = motivated by Snowden.  But it addresses what is viewed as a = technical problem.  That technical problem itself has political = ramifications, but this isn=E2=80=99t really teased out well.  Keep = in mind that people supported the publication of that document for = reasons of their own, and we cannot really ascribe motivations.

The argument that is made is that is was a technical = argument, which was also a political position. It does not say what the = position it, but it foregrounds the socio-political nature of a = technical statement.

Yes- but your statement could be read to infer = political motivations on the part of the IETF.  And that is what I = would be cautious about.  I think this is editorial.

Regards,

Eliot

[1] = https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_su= bmission_5.docx
[2] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_su= bmission_17.pdf
[3] https://www.cambridge.org/core/books/standards-and-public-polic= y/9439DB66D660C8131578652F547A9E82
= --Apple-Mail=_2FBC2332-B9DB-43B7-B96A-B8FEAAD538BB-- --Apple-Mail=_F5EA76FF-85AC-42ED-A517-ED073A772862 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl13QfgACgkQh7ZrRtnS ejOt2Af/d9IEGviEedeqDUot93zWjhxslolsUcOKC7slqQNQRh4haT9mHz2a4mLE LyZOu80nKcXzOx89jlRpO+DIBNRZQ3bmzD48Ma5GuAQmETNRUsKWp/vwRhnMT7Un 1pc/efKTtBvC7n7ZZ3nISJZD7uEXmhz8a3SyZ0Zs0bARBh2CR9UNYXtyn7yonUxk 5uXB8PwNtx+QSZVIbQ3cdPuGbN8uzvlt7U9RN766nHPD/UiRkTUVxlOdj8Zs/wGq VDe3n4SmPm40f7wNQn4GGpG33J1ArqhYaF639J4mtcuYjj001xwVQZhNlVzKjwnF 3sJTfWfjCvjKnjqex8TQGxqIEV4/NA== =Q2A7 -----END PGP SIGNATURE----- --Apple-Mail=_F5EA76FF-85AC-42ED-A517-ED073A772862-- From nobody Mon Sep 9 23:52:36 2019 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 579C6120897 for ; Mon, 9 Sep 2019 23:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sNaWVgXzvWF for ; Mon, 9 Sep 2019 23:52:31 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 8DCB812089E for ; Mon, 9 Sep 2019 23:52:30 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i7a0k-0000Ae-I9; Tue, 10 Sep 2019 08:52:23 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-D6B2C2CA-AEB0-4F84-8E36-2F54F9959B76 Mime-Version: 1.0 (1.0) From: Mallory Knodel X-Mailer: iPhone Mail (16D57) In-Reply-To: <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com> Date: Tue, 10 Sep 2019 08:52:21 +0200 Cc: Niels ten Oever , avri@apc.org, hrpc@irtf.org Content-Transfer-Encoding: 7bit Message-Id: References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> <20190909105043.GC26052@mir> <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com> To: Eliot Lear X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 1aface135a56bc3c00430d8c4acb72ca Archived-At: Subject: Re: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 06:52:34 -0000 --Apple-Mail-D6B2C2CA-AEB0-4F84-8E36-2F54F9959B76 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10 Sep 2019, at 08:26, Eliot Lear wrote: >>> The use of the terms =E2=80=9Cnormative=E2=80=9D and =E2=80=9Cde facto=E2= =80=9D requires clarity. The author is essentially saying that standards ar= e in effect normative, even if we claim them to be voluntary. =20 >>=20 >> Exactly, that is what emerges from the research. >=20 >=20 > Then isn=E2=80=99t that a far stronger thesis? The question you are askin= g in Section 3 is trivially true, IMHO. It boils down to the old maxim, tha= t politics exists in a room of more than one person. Which brings me to my n= ext point. Agree that this is trivially true, but surprisingly difficult to reference, a= problem that is central to the existence of this document. I would be very interested in works that go deeper and beyond this, but for t= he moment we haven=E2=80=99t established this by consensus within the commun= ity. -M --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 >>=20 >>> I am left with a major question: So what? What are the implications of t= he answer to this question and why is it important to ask. >>=20 >> As you know, previous versions of this document came up with recommendati= ons. But it was then brought up that a research cannot make recommendations f= or the IETF. Therefore this document serves as a platform for further discus= sion, and thus ensuring we don't need to repeat all the discussions we've ha= d. >=20 >=20 > I fear you may have taken away the wrong conclusion from those discussions= . It is perfectly fine to make recommendations to the IETF. Indeed I would= say that the IRTF is at its best when it can make recommendations. You jus= t cannot do so in a normative fashion from the IRTF. More importantly, show= ing some example of societal benefit/harm will ground the work. Just be sur= e to ground your analysis in your recommendations. >=20 >>=20 >>>=20 >>> In addition, I have some questions about the supporting material. >>>=20 >>> Regarding this text in Section 4.5: >>>=20 >>> The process that led to [RFC6973] is similar: the Snowden disclosures, w= hich occured[sic] in the political space, engendered the IETF to act. >>>=20 >>> I believe the author is actually referring to RFC 7258 (6973 was in the R= FC Editor queue when Snowden hit, and is the product of the IAB), but even h= ere, some additional support is necessary. 7258 was indeed motivated by Sno= wden. But it addresses what is viewed as a technical problem. That technic= al problem itself has political ramifications, but this isn=E2=80=99t really= teased out well. Keep in mind that people supported the publication of tha= t document for reasons of their own, and we cannot really ascribe motivation= s. >>=20 >> The argument that is made is that is was a technical argument, which was a= lso a political position. It does not say what the position it, but it foreg= rounds the socio-political nature of a technical statement. >=20 > Yes- but your statement could be read to infer political motivations on th= e part of the IETF. And that is what I would be cautious about. I think th= is is editorial. >=20 > Regards, >=20 > Eliot >=20 > [1] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submissio= n_5.docx > [2] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submissio= n_17.pdf > [3] https://www.cambridge.org/core/books/standards-and-public-policy/9439D= B66D660C8131578652F547A9E82 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --Apple-Mail-D6B2C2CA-AEB0-4F84-8E36-2F54F9959B76 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 10 Sep 2019, at 08:26, Eliot Lear <lear@cisco.com> wrote:

The use of the terms =E2=80=9Cnormative=E2=80=9D an= d =E2=80=9Cde facto=E2=80=9D requires clarity.  The author is essential= ly saying that standards are in effect normative, even if we claim them to b= e voluntary.  

Exactly, that is what emerges from the research.


Then isn=E2=80=99t that a far stronger thesis?  Th= e question you are asking in Section 3 is trivially true, IMHO.  It boi= ls down to the old maxim, that politics exists in a room of more than one pe= rson.  Which brings me to my next point.


Agree that this is= trivially true, but surprisingly difficult to reference, a problem that is c= entral to the existence of this document.

I would b= e very interested in works that go deeper and beyond this, but for the momen= t we haven=E2=80=99t established this by consensus within the community.

-M

-- 
Mallory Knodel
Head of Digita= l :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 &= nbsp;B071 0C32 A271 BD3C C780


I am left with a major question: So what? &nbs= p;What are the implications of the answer to this question and why is it imp= ortant to ask.

As you know, previous versions of this document came up with recommendation= s. But it was then brought up that a research cannot make recommendations fo= r the IETF. Therefore this document serves as a platform for further discuss= ion, and thus ensuring we don't need to repeat all the discussions we've had= .


I fear you may have taken away the wro= ng conclusion from those discussions.  It is perfectly fine to make rec= ommendations to the IETF.  Indeed I would say that the IRTF is at its b= est when it can make recommendations.  You just cannot do so in a norma= tive fashion from the IRTF.  More importantly, showing some example of s= ocietal benefit/harm will ground the work.  Just be sure to ground your= analysis in your recommendations.



In addition, I have some questions about the suppor= ting material.

Regarding this text in Section 4= .5:

The process that led to [RFC6973] is simila= r: the Snowden disclosures, which occured[sic] in the political space, engen= dered the IETF to act.

I believe the author is a= ctually referring to RFC 7258 (6973 was in the RFC Editor queue when Snowden= hit, and is the product of the IAB), but even here, some additional support= is necessary.  7258 was indeed motivated by Snowden.  But it addr= esses what is viewed as a technical problem.  That technical problem it= self has political ramifications, but this isn=E2=80=99t really teased out w= ell.  Keep in mind that people supported the publication of that docume= nt for reasons of their own, and we cannot really ascribe motivations.

The argument that i= s made is that is was a technical argument, which was also a political posit= ion. It does not say what the position it, but it foregrounds the socio-poli= tical nature of a technical statement.

Yes- but your statement coul= d be read to infer political motivations on the part of the IETF.  And t= hat is what I would be cautious about.  I think this is editorial.

Regards,

Eliot

[1] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_5= .docx
[2] https://ww= w.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_17.pdf
[3] http= s://www.cambridge.org/core/books/standards-and-public-policy/9439DB66D660C81= 31578652F547A9E82
______________________________________________= _
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc<= br>
= --Apple-Mail-D6B2C2CA-AEB0-4F84-8E36-2F54F9959B76-- From nobody Tue Sep 10 06:01:59 2019 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 0618E12011C for ; Tue, 10 Sep 2019 06:01:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIv9I8K0dgRk for ; Tue, 10 Sep 2019 06:01:54 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 3819412011E for ; Tue, 10 Sep 2019 06:01:53 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i7flb-0003mU-U8; Tue, 10 Sep 2019 15:01:48 +0200 Date: Tue, 10 Sep 2019 15:01:03 +0200 From: Niels ten Oever To: Eliot Lear Cc: avri@apc.org, hrpc@irtf.org Message-ID: <20190910130103.GB4318@mir> References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> <20190909105043.GC26052@mir> <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Authenticated-As-Hash: 54a52893e10ae071b73780542c02a8d9e3f33e6f X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 7969115219f8fafc5e1233f7e15217de Archived-At: Subject: Re: [hrpc] status on draft-irtf-hrpc-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 13:01:58 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2019 at 08:26:00AM +0200, Eliot Lear wrote: > Hi Niels, >=20 > I will look for your update. I understand your enthusiasm and impatience= to publish (I share with you both of those traits myself after a certain p= oint). >=20 It's been over two years since the publication of the first version, so I t= hink I am doing relativley OK on the impatience part ;) BTW, anyone ever seen this make error for xml2rfc? Am a bit at a loss: $ make xml2rfc draft-political.xml --html Traceback (most recent call last): File "/usr/bin/xml2rfc", line 11, in load_entry_point('xml2rfc=3D=3D2.25.0', 'console_scripts', 'xml2rfc')() File "/usr/lib/python3/dist-packages/xml2rfc/run.py", line 482, in main htmlwriter.write(filename) File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1430,= in write self._build_document() File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1376,= in _build_document self.write_reference_list(references[0]) File "/usr/lib/python3/dist-packages/xml2rfc/writers/legacy_html.py", lin= e 569, in write_reference_list initials, surname =3D short_author_name_parts(author) File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 26, in s= hort_author_name_parts initials =3D get_initials(a) File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 22, in g= et_initials initials =3D initials.split('.')[0] AttributeError: 'NoneType' object has no attribute 'split' make: *** [Makefile:12: draft-political.html] Error 1 More inline: > Now please see below. >=20 > > On 9 Sep 2019, at 12:50, Niels ten Oever wrote: > >=20 > > Hi Eliot, > >=20 > > Thank you very for you review. > >=20 > > On Mon, Sep 02, 2019 at 08:11:37PM +0200, Eliot Lear wrote: > >> Hi Avri, > >>=20 > >>> On 2 Sep 2019, at 15:29, avri doria wrote: > >>>=20 > >>> Hi, > >>>=20 > >>> Recently there has been an ongoing discussion about taking this draft= to > >>> Research group last call and then toward RFC using the IRTF process. > >>> Mallory and I have also been discussing it for a bit. We are trying= to > >>> determine whether its time for the last call. > >>>=20 > >>> During the Montreal session, from my remote perspective it seemed that > >>> there was a willingness for it move to last call, or at least no > >>> objection. At least one person indicated they would do a review. Are > >>> there reviews in progress that are on their way? > >>>=20 > >>> At this point I wanted to ask the list, is it ready for a last call a= nd > >>> are there people who have read it who either agree or who do not agree > >>> with taking it a step toward RFC. Does anyone object to taking it to > >>> last call. If you have read it and have a opinion/analysis, please do= tell. > >>=20 > >>=20 > >> I do not think this work is ready. There are several major issues: > >>=20 > >> The abstract does not clearly state what the paper attempts to address= , and thus it is not clear whether the goal has been achieved. > >=20 > > I have added the following sentence to the abstract: > >=20 > > This document aims to bring about a better understanding on the politic= al nature of standards and protocols. >=20 > I think there=E2=80=99s more to be said. Please read down. >=20 > >=20 > >> Section 3 states a thesis (in exactly one sentence). > >=20 > > As you know this part expanded and then got boiled down again to exactl= y show what this draft is about. > >=20 > >> Section 4 addresses the thesis. > >=20 > > This section addresses what opinions on the question exist within the c= ommunity, and seeks to locate them within academic debates on this topic. >=20 > Again, think about it from the reader=E2=80=99s perspective. How many pa= pers have you read that has a single sentence section? My suggestion is si= mply to state the question in Section 1 and eliminate Section 3. In fact, = it might make for a good first sentence. It=E2=80=99s bold and invites exp= loration. >=20 > >=20 > >> And then there=E2=80=99s a Section 5 which has nothing to do with the = thesis. > >=20 > > Section 5 documents the political nature of standard setting processes = in general, so it does related to the question. >=20 >=20 > Ok, on closer reading I think you=E2=80=99re right, and I was wrong on th= at point. >=20 > I still think your exploration should go a bit further. While I like tha= t you talk about interference in order to promote de facto standards, one c= an also show examples of interference to disrupt de facto standards. In fa= ct, the entire de jure standardization process is a form of that disruption. >=20 > In addition, one can find a great many examples of where purported de jur= e standards are never implemented, even absent interference. One need only= look at certain international standards bodies=E2=80=99 work to see it lit= tered with science experiments (that includes the IETF), and the sad state = of affairs with regard to network security. A simple imprimatur does not g= uarantee implementation =E2=80=93 thus the notion of =E2=80=9Cvoluntary=E2= =80=9D. There has to be something more: there has to be an economic need f= or the standard (de jure or de facto). Professor Rebecca Henderson @ Harva= rd has done a lot of work on this subject, and on technology in general (I= =E2=80=99m a big fan). May be worth adding to your literature review, but = it goes beyond the bounds of Section 4, which is really focused on a single= question. >=20 > Putting that previous paragraph more simply, it would be useful to bound = the effects you are attempting to characterize. You might even show a few = examples. To name a few, we can borrow a bit from the ITAT workshop report= in RFC 7305 and RFC 5218, looking at Bitcoin (see B=C3=B6hme[1]), DNSSEC (= see Eklund L=C3=B6winder[2]), and of course our two favorites, IPv6 and HTT= P. In fact, such a correlation would be, I think, a great addition, even i= f it is follow-on work. >=20 > If you want to go even further in terms of formal analysis, you may wish = to review Greenstein and Stango.[3]. The nice thing about that book is that= it gets well beyond the IETF or even Internet technology, but also include= s some. Its examples are a bit dated, tho. Thanks a lot for these suggestion Eliot, really appreciated. I would really= like to build on this draft by studying adoption and non-adoption and the = complex of economic, political, and technical reasons of adoption and imple= mentation, but I don't think it should take place in this draft. This draft= is meant to be a platform for those discussions and analyses, and thus for= for a iterative, or if you will layered, approach. >=20 >=20 > >=20 > >> The use of the terms =E2=80=9Cnormative=E2=80=9D and =E2=80=9Cde facto= =E2=80=9D requires clarity. The author is essentially saying that standard= s are in effect normative, even if we claim them to be voluntary. > >=20 > > Exactly, that is what emerges from the research. >=20 >=20 > Then isn=E2=80=99t that a far stronger thesis? The question you are aski= ng in Section 3 is trivially true, IMHO. It boils down to the old maxim, t= hat politics exists in a room of more than one person. Which brings me to = my next point. These discussions come back again and again, and this makes it very hard to= have a deeper discussion on the topic. That is why I think this document i= s important, because sometimes I feel we are spinning our wheels. I hope th= is draft will give us a platform on which we can continue the work, without= repeating older discussions. Best, Niels=20 >=20 >=20 > >=20 > >> I am left with a major question: So what? What are the implications o= f the answer to this question and why is it important to ask. > >=20 > > As you know, previous versions of this document came up with recommenda= tions. But it was then brought up that a research cannot make recommendatio= ns for the IETF. Therefore this document serves as a platform for further d= iscussion, and thus ensuring we don't need to repeat all the discussions we= 've had. >=20 >=20 > I fear you may have taken away the wrong conclusion from those discussion= s. It is perfectly fine to make recommendations to the IETF. Indeed I wou= ld say that the IRTF is at its best when it can make recommendations. You = just cannot do so in a normative fashion from the IRTF. More importantly, = showing some example of societal benefit/harm will ground the work. Just b= e sure to ground your analysis in your recommendations. >=20 > >=20 > >>=20 > >> In addition, I have some questions about the supporting material. > >>=20 > >> Regarding this text in Section 4.5: > >>=20 > >> The process that led to [RFC6973] is similar: the Snowden disclosures,= which occured[sic] in the political space, engendered the IETF to act. > >>=20 > >> I believe the author is actually referring to RFC 7258 (6973 was in th= e RFC Editor queue when Snowden hit, and is the product of the IAB), but ev= en here, some additional support is necessary. 7258 was indeed motivated b= y Snowden. But it addresses what is viewed as a technical problem. That t= echnical problem itself has political ramifications, but this isn=E2=80=99t= really teased out well. Keep in mind that people supported the publicatio= n of that document for reasons of their own, and we cannot really ascribe m= otivations. > >=20 > > The argument that is made is that is was a technical argument, which wa= s also a political position. It does not say what the position it, but it f= oregrounds the socio-political nature of a technical statement. >=20 > Yes- but your statement could be read to infer political motivations on t= he part of the IETF. And that is what I would be cautious about. I think = this is editorial. >=20 > Regards, >=20 > Eliot >=20 > [1] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submissi= on_5.docx > [2] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submissi= on_17.pdf > [3] https://www.cambridge.org/core/books/standards-and-public-policy/9439= DB66D660C8131578652F547A9E82 --=20 Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 643A 0ED8 3F3A 468A C8B3 --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl13no4ACgkQDtg/OkaK yLNVVA//dOfBcq/HUnvMrgwm7KBsznzt1YrMG7ePzqw/K3n1mDSkL/sofYD8sEP9 CuKwNznkROclN3EP4LOCKXRy5DMRHwio1TI6d8xT8pNLF/JtOWaN5LC/c1tXu9gO AQQjnD1k1t6LvTv6eiteTSqQyyhxV0to0bqbHK4w0ljb47piYqKYPfUXtglHgv/J m9TERvB3RAoDK5YOK8To500eHcZAh4Q1KjirJUhhjHA5RTWfG/t9B8Re3WFPaP5b bpnqhaOMOoG9o7DzLpVSUR7+SdJHrWsJeyVsAGeyyUIFluDz3Js0ByCtTnfowI00 V7St32bkXbHkzFXFAN/eifX2UqnwuWpxEojSU/QJizaSIje/Lk7H+cp+2x4o3irX G/5zPX4KbI32EYOyx6ab60ov9bhMEI1iBCWE7FquR1GYundJ6OHGcm9Yt3BxZrlo YxE0QZLtCmMTD4NMDXxFpVnTMEpbS+Gm2nN+nDp6dZsYp/oNHKfqUQOfopd9XPky U5cOyqzhi3g97RhKbKXZfljmJSukgHFzrfANP7eMqDGvba7oL1zA53FYI1OtTd8g J8XXU31Rq3KfBWtWyNqwW7kpcdYdp9pyNBSQUd9hJgYbLZF2STJRjAoisAkDC6op dG1I2waslAnN1z8bYxnaa3iSvWKvpPmluuNwn1DJTGs0a1aEoyI= =4PJ7 -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From nobody Fri Sep 13 18:32:08 2019 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 6CAB7120048; Fri, 13 Sep 2019 18:32:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: hrpc-chairs@ietf.org, mallory@article19.org, hrpc@irtf.org, irtf-chair@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156842472638.31850.11312808136459854381.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2019 18:32:06 -0700 Archived-At: Subject: [hrpc] hrpc - New Meeting Session Request for IETF 106 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2019 01:32:06 -0000 A new meeting session request has just been submitted by Mallory Knodel, a Chair of the hrpc working group. --------------------------------------------------------- Working Group Name: Human Rights Protocol Considerations Area Name: IRTF Session Requester: Mallory Knodel Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: dprive gaia irtfopen pearg Technology Overlap: mls doh regext Key Participant Conflict: capport dnsop People who must be present: Avri Doria Mallory Knodel Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Sep 16 02:11:14 2019 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 7CC11120019; Mon, 16 Sep 2019 02:11:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hrpc@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hrpc@irtf.org Message-ID: <156862506643.28251.9847319195246702362@ietfa.amsl.com> Date: Mon, 16 Sep 2019 02:11:06 -0700 Archived-At: Subject: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 09:11:07 -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 RG of the IRTF. Title : Notes on networking standards and politics Author : Niels ten Oever Filename : draft-irtf-hrpc-political-04.txt Pages : 15 Date : 2019-09-16 Abstract: The IETF cannot ordain what standards or protocols are to be used on networks, but the standards development process in the IETF does have an impact on society through its normative standards setting process. This document aims to bring about a better understanding on the political nature of standards and protocols. Among other things, the IETF's work affects what is perceived as technologically possible and useful where networking technologies are being deployed, and its standards reflect what is considered by the technical community to be feasible and good practice. Whereas there might not be agreement among the Internet protocol community on the specific political nature of the technological development process and its outputs, it is undisputed that standards and protocols are both products of a political process, and they can also be used for political means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-hrpc-political-04 https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-04 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 16 08:01:59 2019 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 A9A0812084E for ; Mon, 16 Sep 2019 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKWZGOHg3J6N for ; Mon, 16 Sep 2019 08:01:51 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 CEEF212084D for ; Mon, 16 Sep 2019 08:01:50 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i9sUs-0004h1-8N for hrpc@irtf.org; Mon, 16 Sep 2019 17:01:46 +0200 To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> Date: Mon, 16 Sep 2019 17:00:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156862506643.28251.9847319195246702362@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 3ced5df4177ef3a93a84b902ce7c160e Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 15:01:54 -0000 Hi all, As promised, after ironing out some bugs with xml2rfc (thanks Henrik), here is an updated version of draft-political which addresses the comments from SM and Eliot. Best, Niels On 9/16/19 11:11 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Human Rights Protocol Considerations RG of the IRTF. > > Title : Notes on networking standards and politics > Author : Niels ten Oever > Filename : draft-irtf-hrpc-political-04.txt > Pages : 15 > Date : 2019-09-16 > > Abstract: > The IETF cannot ordain what standards or protocols are to be used on > networks, but the standards development process in the IETF does have > an impact on society through its normative standards setting process. > This document aims to bring about a better understanding on the > political nature of standards and protocols. Among other things, the > IETF's work affects what is perceived as technologically possible and > useful where networking technologies are being deployed, and its > standards reflect what is considered by the technical community to be > feasible and good practice. Whereas there might not be agreement > among the Internet protocol community on the specific political > nature of the technological development process and its outputs, it > is undisputed that standards and protocols are both products of a > political process, and they can also be used for political means. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-hrpc-political-04 > https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Mon Sep 16 14:16:19 2019 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 0F22B120041 for ; Mon, 16 Sep 2019 14:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4Bn02Izsaf2 for ; Mon, 16 Sep 2019 14:16:15 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0755F1200DB for ; Mon, 16 Sep 2019 14:16:14 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 60CCD180A68DB for ; Mon, 16 Sep 2019 21:16:13 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -8.5, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:41:152:355:379:599:800:854:967:973:988:989:1049:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1535:1542:1593:1594:1711:1730:1747:1777:1792:1963:2194:2199:2288:2328:2393:2525:2553:2560:2568:2627:2682:2685:2741:2771:2859:2895:2906:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4117:4184:4250:4321:4362:4605:4860:5007:6117:6119:7652:7903:9010:9025:9036:9108:10004:10400:10848:11232:11658:11914:12043:12109:12114:12291:12297:12379:12438:12683:12740:12760:12895:12926:13071:13846:14095:14096:14180:14181:14721:14819:21060:21080:21433:21451:21627:21740:21881:30046:30054:30060:30090, 0, RBL:72.221.122.28:@doria.org:.lbl8.mailshell.net-62.14.0.100 64.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:2 X-HE-Tag: mass39_53513be860845 X-Filterd-Recvd-Size: 6944 Received: from [192.168.0.21] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf02.hostedemail.com (Postfix) with ESMTPA for ; Mon, 16 Sep 2019 21:16:12 +0000 (UTC) To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> From: avri@doria.org Autocrypt: addr=avri@doria.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemi yf8Pp8BdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K 1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV 5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOG B8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO7 6/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanx Fk4vCRfjfl8wt27n9xt27ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2HOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmEqG/rIj0w3XfV3bQsDBUU dH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrMMqO7SYUTB6Tx8vIoqmy/ T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq3lrUp2mRzDXBWZLhPVUq x6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006QeZQKfAZinaq3ICEyimWZ bLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wjzrwwsxypxUiEac/7bVwg Ev5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemiyf8Pp8BdIAQZAQIABgUC UleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K1oIc+pxGmr7RUfpOcB63 +1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV5mPBI7kWYNbD99278ZtY TO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOGB8par+/2zKx1MwrZFCnT tlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO76/QFmerwwN89qLAh1pAN oJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanxFk4vCRfjfl8wt27n9xt2 7ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWaSy7OQDKa1N838tTsRVLO MpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBslZea+G2UUV2WSXZPiTci 8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+GjqFR3R2AMLhwK/Nu9uw +cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z6yQ42xcvoUbQ6lLXW0fj NNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPgDoZoktZXmyHIh2E= Message-ID: <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> Date: Mon, 16 Sep 2019 17:16:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Antivirus: Avast (VPS 190916-2, 09/16/2019), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 21:16:17 -0000 Hi, Thanks Niels. SM & Eliot, are you satisfied with the way your comments were addressed? Any other reviews in the wind? thanks avri On 16-Sep-19 11:00, Niels ten Oever wrote: > Hi all, > > As promised, after ironing out some bugs with xml2rfc (thanks Henrik), here is an updated version of draft-political which addresses the comments from SM and Eliot. > > Best, > > Niels > > On 9/16/19 11:11 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Human Rights Protocol Considerations RG of the IRTF. >> >> Title : Notes on networking standards and politics >> Author : Niels ten Oever >> Filename : draft-irtf-hrpc-political-04.txt >> Pages : 15 >> Date : 2019-09-16 >> >> Abstract: >> The IETF cannot ordain what standards or protocols are to be used on >> networks, but the standards development process in the IETF does have >> an impact on society through its normative standards setting process. >> This document aims to bring about a better understanding on the >> political nature of standards and protocols. Among other things, the >> IETF's work affects what is perceived as technologically possible and >> useful where networking technologies are being deployed, and its >> standards reflect what is considered by the technical community to be >> feasible and good practice. Whereas there might not be agreement >> among the Internet protocol community on the specific political >> nature of the technological development process and its outputs, it >> is undisputed that standards and protocols are both products of a >> political process, and they can also be used for political means. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-irtf-hrpc-political-04 >> https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-04 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >> From nobody Mon Sep 16 14:23:31 2019 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 CFC461200DB for ; Mon, 16 Sep 2019 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZo1zFOrKQ41 for ; Mon, 16 Sep 2019 14:23:27 -0700 (PDT) Received: from mail.gn.apc.org (mail.gn.apc.org [37.220.108.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC35120041 for ; Mon, 16 Sep 2019 14:23:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id 5065F203B867 for ; Mon, 16 Sep 2019 22:23:25 +0100 (BST) X-Virus-Scanned: by amavisd-new at mail.gn.apc.org Received: from mail.gn.apc.org ([127.0.0.1]) by localhost (mail.gn.apc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yer8WTjfW5S2 for ; Mon, 16 Sep 2019 22:23:21 +0100 (BST) Received: from anonymous ([10.254.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: avri) by mail.gn.apc.org (Postfix) with ESMTPSA id 27DF7203B862 for ; Mon, 16 Sep 2019 22:23:21 +0100 (BST) To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> From: avri doria Autocrypt: addr=avri@apc.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemi yf8Pp8BdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K 1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV 5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOG B8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO7 6/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanx Fk4vCRfjfl8wt27n9xt27ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2HOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmEqG/rIj0w3XfV3bQsDBUU dH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrMMqO7SYUTB6Tx8vIoqmy/ T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq3lrUp2mRzDXBWZLhPVUq x6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006QeZQKfAZinaq3ICEyimWZ bLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wjzrwwsxypxUiEac/7bVwg Ev5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemiyf8Pp8BdIAQZAQIABgUC UleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K1oIc+pxGmr7RUfpOcB63 +1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV5mPBI7kWYNbD99278ZtY TO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOGB8par+/2zKx1MwrZFCnT tlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO76/QFmerwwN89qLAh1pAN oJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanxFk4vCRfjfl8wt27n9xt2 7ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWaSy7OQDKa1N838tTsRVLO MpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBslZea+G2UUV2WSXZPiTci 8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+GjqFR3R2AMLhwK/Nu9uw +cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z6yQ42xcvoUbQ6lLXW0fj NNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPgDoZoktZXmyHIh2E= Message-ID: <75cfc980-5751-3473-38d8-4551d5f222d6@apc.org> Date: Mon, 16 Sep 2019 17:23:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Antivirus: Avast (VPS 190916-2, 09/16/2019), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 21:23:29 -0000 Hi, On a personal note: I am still somewhat insecure about the statement: "it is undisputed that standards and protocols are both products of a political process, and they can also be used for political means." I wont dispute the the idea of process and some use being political, but is the statement really undisputed? Will read the rest of the new draft in the next day or so. thanks avri On 16-Sep-19 11:00, Niels ten Oever wrote: > Hi all, > > As promised, after ironing out some bugs with xml2rfc (thanks Henrik), = here is an updated version of draft-political which addresses the comment= s from SM and Eliot. > > Best, > > Niels > > On 9/16/19 11:11 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Human Rights Protocol Considerations = RG of the IRTF. >> >> Title : Notes on networking standards and politics >> Author : Niels ten Oever >> Filename : draft-irtf-hrpc-political-04.txt >> Pages : 15 >> Date : 2019-09-16 >> >> Abstract: >> The IETF cannot ordain what standards or protocols are to be used o= n >> networks, but the standards development process in the IETF does ha= ve >> an impact on society through its normative standards setting proces= s. >> This document aims to bring about a better understanding on the >> political nature of standards and protocols. Among other things, t= he >> IETF's work affects what is perceived as technologically possible a= nd >> useful where networking technologies are being deployed, and its >> standards reflect what is considered by the technical community to = be >> feasible and good practice. Whereas there might not be agreement >> among the Internet protocol community on the specific political >> nature of the technological development process and its outputs, it= >> is undisputed that standards and protocols are both products of a >> political process, and they can also be used for political means. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-irtf-hrpc-political-04 >> https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-hrpc-political-04 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >> From nobody Mon Sep 16 22:47:58 2019 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 44B1B120147 for ; Mon, 16 Sep 2019 22:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 L1VsD7NaDyJs for ; Mon, 16 Sep 2019 22:47:55 -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 0FADD12007C for ; Mon, 16 Sep 2019 22:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4727; q=dns/txt; s=iport; t=1568699275; x=1569908875; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=2S2ehpaS7bMkcsWXgu2vAXCBNpEfyrfT8TNgXB1fhw0=; b=BOvQaaugglLJ6tHEPDQI0n1qUC/7x/OnLMzVNB0DZgGqcrUKkz+U/nu0 D+HhP3Fo6a0Z5Jl6yQNjMAujnKnIm72wocleqmb9EFk6SZ+X7zEYn/x1/ awArM5M0E4w5mlXXAVufk+4ijJTHgVQN50xWqJJrxHLgA6PotAMWsLfLi g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADocoBd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGDVyAShEuIHGCbMIYKgXsCBwEBAQkDAQEvAQG?= =?us-ascii?q?EPwKDFTQJDgIDCQEBBAEBAQIBBQRthTqFSwYjVhALBD4CAleDOwGCCq0ggTK?= =?us-ascii?q?FTIRwEIE0AYFQij+Bf4E4H4JMPoURgj4ygiYElXGWeYIsgi6BE5E/G4I1h0e?= =?us-ascii?q?Dfosfo3qDEQIEBgUCFYFSOIFYMxoIGxU7KgGCQj2QSz4DkSYBAQ?= X-IronPort-AV: E=Sophos;i="5.64,515,1559520000"; d="asc'?scan'208,217";a="16843169" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2019 05:47:53 +0000 Received: from [10.61.225.65] ([10.61.225.65]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x8H5lqkY027530 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Sep 2019 05:47:52 GMT From: Eliot Lear Message-Id: <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_494E62A9-FA3D-490B-AD4F-1E1C52AEAC75"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Sep 2019 07:47:50 +0200 In-Reply-To: <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> Cc: hrpc@irtf.org To: avri@doria.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.225.65, [10.61.225.65] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 05:47:57 -0000 --Apple-Mail=_494E62A9-FA3D-490B-AD4F-1E1C52AEAC75 Content-Type: multipart/alternative; boundary="Apple-Mail=_C477DDDE-90A9-4918-8A4B-4510BAEA2B4F" --Apple-Mail=_C477DDDE-90A9-4918-8A4B-4510BAEA2B4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Avri, I ask for guidance from the chair and from the RG as to what qualifies = as ready for publication. What are the criteria? What are we aiming = for? Academic quality? My view? There are some real problems in the document. This is not an = exhaustive list: The thesis statement conflicts with the introduction, and conflates = protocols and standards. As both protocols and standards are central to the document, you would = think that they would be defined early on, like in the definitions = section. The difference between protocols and standards is not made, nor is = equivalence. There is no statement of import in the form of what real contribution = the work is making and why that contribution matters. The general and the specific are conflated. Are protocols and standards = at issue here or are we talking about IETF protocols and standards? The lack of examples is really quite frustrating. There are a great many other problems with the draft, not the least of = which is that the author makes unsupported claims, either by reference = or proof, one example being the discussion in Section 5 about the WTO. Are these show stoppers? Please before we continue, let=E2=80=99s = understand our own standard for publication. Eliot --Apple-Mail=_C477DDDE-90A9-4918-8A4B-4510BAEA2B4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Avri,

I ask for guidance from the chair and from the RG as to what = qualifies as ready for publication.  What are the criteria? =  What are we aiming for?  Academic quality?

My view?   There = are some real problems in the document.  This is not an exhaustive = list:

  • The thesis statement conflicts with = the introduction, and conflates protocols and standards.
  • As both protocols and standards are central to the document, = you would think that they would be defined early on, like in the = definitions section.
  • The difference between protocols = and standards is not made, nor is equivalence.
  • There = is no statement of import in the form of what real contribution the work = is making and why that contribution matters.
  • The = general and the specific are conflated.  Are protocols and = standards at issue here or are we talking about IETF protocols and = standards?
  • The lack of examples is really quite = frustrating.

There are a great many other problems with the draft, not the = least of which is that the author makes unsupported claims, either by = reference or proof, one example being the discussion in Section 5 about = the WTO.

Are these show stoppers?  Please before we continue, = let=E2=80=99s understand our own standard for publication.

Eliot

= --Apple-Mail=_C477DDDE-90A9-4918-8A4B-4510BAEA2B4F-- --Apple-Mail=_494E62A9-FA3D-490B-AD4F-1E1C52AEAC75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2Ac4cACgkQh7ZrRtnS ejN9AQgAovEJNlVHQTErME/NMW58wY9IUyIwAaatsY5Z3ZrJTbDtulNRWVdNjtQs /Vbe5YkzTMIXKV9Ly1b9mdwUOYWlHhQVjzc6zoBZepcie2+B3lPfYPaDVJX0tsg1 xK5sVPZAb/8HQI36n1M/e6XDTavBYZh71UXGFwKJ7rRY1kzkDPtJAmD1vpKeHSbq UuKtkoCNG5NgvnWEpz337FW7oVyTQKF5MQ+GBYCK/DyYTBTkTAQLJprBEY+82eSK h4wTRpsluo8JK/xfXn89116s97Dwvu1MOhxnQ0Uw/MfbZCQ1nsl4oPH4nsTRKOYW MhRClKXDH7H8tw8ZTyT0otFzXEJK7A== =4HAE -----END PGP SIGNATURE----- --Apple-Mail=_494E62A9-FA3D-490B-AD4F-1E1C52AEAC75-- From nobody Tue Sep 17 02:09:44 2019 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 36E7D12020A for ; Tue, 17 Sep 2019 02:09:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCLrtfPXnkHm for ; Tue, 17 Sep 2019 02:09:40 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 C7F461200EF for ; Tue, 17 Sep 2019 02:09:40 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iA9Tv-0006Ea-I9 for hrpc@irtf.org; Tue, 17 Sep 2019 11:09:37 +0200 To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Tue, 17 Sep 2019 11:09:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WUgdTkqM3wZyJz9HcbVHtlukvSwWOZzAg" X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: f0e1c9854a9562d49e95611d158cd3d0 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 09:09:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WUgdTkqM3wZyJz9HcbVHtlukvSwWOZzAg Content-Type: multipart/mixed; boundary="2vANoDDsmue6EhgXCK8mG1D0lQasArthR"; protected-headers="v1" From: Niels ten Oever To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> In-Reply-To: <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> --2vANoDDsmue6EhgXCK8mG1D0lQasArthR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Eliot, On 9/17/19 7:47 AM, Eliot Lear wrote: > Hi Avri, >=20 > I ask for guidance from the chair and from the RG as to what qualifies = as ready for publication. =C2=A0What are the criteria? =C2=A0What are we = aiming for? =C2=A0Academic quality? >=20 > My view? =C2=A0 There are some real problems in the document. =C2=A0Thi= s is not an exhaustive list: >=20 I am a bit surprised by this, since these are not points you brought up i= n your past email. But I am happy to address them of course. > * The thesis statement conflicts with the introduction, and conflates= protocols and standards. Could you be so kind to point out the conflict? > * As both protocols and standards are central to the document, you wo= uld think that they would be defined early on, like in the definitions se= ction. These definitions were there in the -01 version of the document: https://tools.ietf.org/html/draft-irtf-hrpc-political-01 Then the RG asked me to remove them, am happy to put them back in if peop= le think that is the right way to go.=20 > * The difference between protocols and standards is not made, nor is = equivalence. See above. I also explained in my previous mail that I use standards wher= e the argument supersedes protocols, especially for section 5 where lessi= ons are brought in from other standard setting fields.=20 Not all standards are protocols, but all protocols are standards.=20 > * There is no statement of import in the form of what real contributi= on the work is making and why that contribution matters. What about these sentences? =46rom abstract: This document aims to bring about a better understanding on the political nature of standards and protocols. =46rom intro: In this document we aim to outline different views on the relation between standards and politics, and seek to answer the question of whether standards are political, and if so, how. > * The general and the specific are conflated. =C2=A0Are protocols and= standards at issue here or are we talking about IETF protocols and stand= ards? We are talking about the political nature of networking protocols, specif= ically those in the IETF. > * The lack of examples is really quite frustrating. >=20 Why are examples, or cases, needed to proof the point? In an earlier comm= ent you said that the thesis was extremely obvious? Am a bit at a loss. >=20 > There are a great many other problems with the draft, not the least of = which is that the author makes unsupported claims, either by reference or= proof, one example being the discussion in Section 5 about the WTO. >=20 Which claim do you mean specifically? Best, Niels > Are these show stoppers? =C2=A0Please before we continue, let=E2=80=99s= understand our own standard for publication. >=20 > Eliot >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --=20 Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 643A 0ED8 3F3A 468A C8B3 --2vANoDDsmue6EhgXCK8mG1D0lQasArthR-- --WUgdTkqM3wZyJz9HcbVHtlukvSwWOZzAg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl2AorIACgkQDtg/OkaK yLMI1w/+Ox8HX+bSd4WLOUlPyEWJvQSMviHxCnM5e1H4xZJPbekxZXp0Jd+zD2Yq 6wmHPlN4Idv0XiGvpz8izTZs28jlwzevwaPM2FCPvP0/4ut90inQZJm417rhmRo1 yclblVAi0TeYuXK4i/DAWiSU+3u4kLP3iXO/eB79IP/saHiTKm11XR/sgmKWcnIS 66gfNF8EahqiK8ZARbfO6OUjYp18BqdWli30++pYL++ilA3CkV+wJGPvpco8nibR cp9pO7yDzQcjkykTrQfV3VLuKPwozbAaz+PFgNUbxCH22iC3+nZqpDPXGmIA+9F7 SnIUyoFfxjBikAn1mWit/dkSRQsef4I1AweH7pCGFhFkkHPBxkQ3KJWIg46kBaeC hf8Phk121fjsMiTMZ/F2qlErWa7GJ5KOuYYBZYiZjv+EpJJFBTKxx4GIE5ZhQggl 2PvsFKERUyP3RCnl34xhvRqM6wSUTOSL4I4hDB0zGFRLAaBaRdgq9lcu/WTzuhQ1 lC6bRyCxsFug2ifL2mhs7Xxqec5mVf4mQW2nt+k2KCyHs+SRtqPt/ah+k3RO52YU mf2Ok/ThAtpXVNgypLInoRybsn7pLfcD+F+mnpyx1WzmAJ7H+HBo+wgk5KQGrIlI tkWqt2z3ULo2a/Ujq6Kqh83Z6L12FvkjptX8hkgR70HGlA5wQgE= =LRnZ -----END PGP SIGNATURE----- --WUgdTkqM3wZyJz9HcbVHtlukvSwWOZzAg-- From nobody Tue Sep 17 05:22:49 2019 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 8B5C4120020 for ; Tue, 17 Sep 2019 05:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr8uBJ7QnYzb for ; Tue, 17 Sep 2019 05:22:44 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4DE120831 for ; Tue, 17 Sep 2019 05:22:44 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 198DF181D3377 for ; Tue, 17 Sep 2019 12:22:43 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -15, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:41:152:355:379:599:800:854:871:967:973:988:989:1000:1260:1261:1313:1314:1345:1359:1381:1437:1516:1518:1535:1543:1575:1594:1605:1711:1730:1747:1777:1792:2198:2199:2393:2525:2553:2560:2563:2682:2685:2691:2692:2693:2859:2861:2898:2911:2912:2915:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4119:4184:4250:4362:4425:4860:5007:6117:6119:6506:6747:6748:7281:7652:7903:7909:8660:8666:9010:9025:10004:10848:11232:11604:11658:11914:12043:12109:12114:12291:12297:12379:12438:12663:12683:12740:12895:13148:13151:13161:13172:13228:13229:13230:13618:13846:14095:14180:14181:14227:14658:14659:14721:21060:21080:21324:21433:21627:21740:21771:21790:21939:30054:30060:30070, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA X-HE-Tag: knife69_8c0698c5b0161 X-Filterd-Recvd-Size: 8571 Received: from [192.168.0.6] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf13.hostedemail.com (Postfix) with ESMTPA for ; Tue, 17 Sep 2019 12:22:42 +0000 (UTC) To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> From: avri@doria.org Autocrypt: addr=avri@doria.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemi yf8Pp8BdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K 1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV 5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOG B8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO7 6/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanx Fk4vCRfjfl8wt27n9xt27ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2HOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmEqG/rIj0w3XfV3bQsDBUU dH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrMMqO7SYUTB6Tx8vIoqmy/ T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq3lrUp2mRzDXBWZLhPVUq x6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006QeZQKfAZinaq3ICEyimWZ bLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wjzrwwsxypxUiEac/7bVwg Ev5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemiyf8Pp8BdIAQZAQIABgUC UleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K1oIc+pxGmr7RUfpOcB63 +1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV5mPBI7kWYNbD99278ZtY TO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOGB8par+/2zKx1MwrZFCnT tlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO76/QFmerwwN89qLAh1pAN oJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanxFk4vCRfjfl8wt27n9xt2 7ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWaSy7OQDKa1N838tTsRVLO MpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBslZea+G2UUV2WSXZPiTci 8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+GjqFR3R2AMLhwK/Nu9uw +cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z6yQ42xcvoUbQ6lLXW0fj NNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPgDoZoktZXmyHIh2E= Message-ID: <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> Date: Tue, 17 Sep 2019 08:22:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QQnbcDgH8bdRzlIoOo1hKAkCIapvaAAGI" X-Antivirus: Avast (VPS 190916-2, 09/16/2019), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 12:22:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QQnbcDgH8bdRzlIoOo1hKAkCIapvaAAGI Content-Type: multipart/mixed; boundary="EoMrzxY2EUOelnR9pWzNnE9HGiPTsoqEm" --EoMrzxY2EUOelnR9pWzNnE9HGiPTsoqEm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, I too am looking for RG guidance. While I am not personally convinced of its readiness I believe my co--chair does think it ready, so I am looking for RG evidence.=C2=A0 Eli= ot, I really appreciate your reviews. Unfortunately I am having trouble gauging the views of the rest of the RG. I have gotten 2 messages off list telling me of issues, and ask that those that have a view on its readiness, positive or not, speak up. As for judging by academic quality, yes, I do look for some academic quality.=C2=A0 Not perhaps full academic rigor but sufficient academic ri= gor, ; i.e no obvious defects in the argumentation, adequate references to counter arguments &c. I am also looking for clarity, which academic rigor does not necessary measure. Also since this is no longer a personal doc but a RG doc, I am looking for a positive evidence that the group finds it acceptable.=C2=A0 Yes, th= e LC is meant to verify that, but I feel I need to have the impression that is is ready and acceptable to most before I am willing to start a LC to verify the degree of rough consensus. Since I can neither assume silence means consent nor means dissent, in the absence of more comment, I keep asking.=C2=A0 I would hate to call a LC, have few to none respond and tak= e to the IRSG review on scant evidence.=C2=A0 I will keep asking. Some people have offered to review, so I live in hope we will get those reviews soon. Thanks again for your comments. avri On 17-Sep-19 01:47, Eliot Lear wrote: > Hi Avri, > > I ask for guidance from the chair and from the RG as to what qualifies > as ready for publication. =C2=A0What are the criteria? =C2=A0What are w= e aiming > for? =C2=A0Academic quality? > > My view? =C2=A0 There are some real problems in the document. =C2=A0Thi= s is not > an exhaustive list: > > * The thesis statement conflicts with the introduction, and > conflates protocols and standards. > * As both protocols and standards are central to the document, you > would think that they would be defined early on, like in the > definitions section. > * The difference between protocols and standards is not made, nor is > equivalence. > * There is no statement of import in the form of what real > contribution the work is making and why that contribution matters. > * The general and the specific are conflated. =C2=A0Are protocols and= > standards at issue here or are we talking about IETF protocols and > standards? > * The lack of examples is really quite frustrating. > > > There are a great many other problems with the draft, not the least of > which is that the author makes unsupported claims, either by reference > or proof, one example being the discussion in Section 5 about the WTO. > > Are these show stoppers? =C2=A0Please before we continue, let=E2=80=99s= understand > our own standard for publication. > > Eliot > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --EoMrzxY2EUOelnR9pWzNnE9HGiPTsoqEm-- --QQnbcDgH8bdRzlIoOo1hKAkCIapvaAAGI 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 iQEcBAEBCAAGBQJdgNAQAAoJEOo+L8tCe36HOHUIAJihy6eb+AmnbBfY1eLohijy RppQO25ff6hYERiAs4Jlo6AmUSM+twAPZYWhnwrtMag7pc8hlaC31H3AP/Ry8mZo bIO4Bx3p8TqjTtov4QRrU2E6Aq+xPDOFkTYyYqD5bOqXCYYvuoacxDRcn/FVc4Ii LisBzXdKeWkZ+HwE7N/ReLypxhHMRSXwiLQtMctXy+pkB2z9peq2llHf1FFuBs5q P+Jm+IThZMXfHf0urm2UMKeFLaPM2g/vRS5ztRhcWbJvRITKAKQJU/PjsCAhTAzY 2xN5VPbRewz+eyaXG1XKUn50peZpi0FZH0YVsoIA/P7bxoImfbxuJNlltQIim8c= =cVQr -----END PGP SIGNATURE----- --QQnbcDgH8bdRzlIoOo1hKAkCIapvaAAGI-- From nobody Tue Sep 17 05:50:43 2019 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 42802120889 for ; Tue, 17 Sep 2019 05:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux9D0l2miiNN for ; Tue, 17 Sep 2019 05:50:33 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E3312085B for ; Tue, 17 Sep 2019 05:50:33 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id y144so3815419qkb.7 for ; Tue, 17 Sep 2019 05:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VqB8oucG1ZCDZMVpwsAam2hNQ6va7rrTpKfl0jw+6L4=; b=l1cyLlRbh6E5v+LnAF/9p6EiAV+kLV4Py+aWXvKa6XIiDdRxUPer/KgXvRDlmZwpmX rH2KskbN1t1xmaE/yH9YHnqfiyI9TKUCmHM4FFfY0xbuVpKYxHnPcX4VcEEUclJ+IEwj xtghoW5nPhLgZ25fnzPkplP5+PFXesUQpBTCQ/gwBYkJ0VI+GbISQ2b+QOaIJLCco/D5 7yW8M+5sE9YQq8w083OVjqBsbgD3rXJRhvblyOhi3SDZ6Mz8WPZgOboW33l3LlzNxzB7 jmOzLicZTYPihzEsUnUGNyvJdC1cvfxtCrsAQbwaoPWYs5pmMQQ7/BSUchn6sx8Roz6F L/4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VqB8oucG1ZCDZMVpwsAam2hNQ6va7rrTpKfl0jw+6L4=; b=eC3ey0aZc/XtDEMeDkAB+hxoxS5BhUzgCR5g+3ZEI7186GHFrUn4pRQg7iSMFw6Znd /AEhPLFDbuUnS4tyIUA66g1cKKPsG3hM1nlnbhTXfC7EJrx4FVfLd2jxixVEjYpm5/tO VpCwnh2INyj68wThSto9FGS4J2soLI/Nfn6PqzyznKCLtBt/pPMILjBMwY7eqhCvD7en R7BMESY34rcSjCRu7t5bzMjNARV63C5StI9mwfZYYUaw8XZ+r6IKAAfER3A1ZcFEvCbh eUQy7S9x5uVEJjlhLLYfJN9KthSWRUJhvM0wScy4nOZe/v0QrfcxQAAxLKetvYrlCHjt 4K+A== X-Gm-Message-State: APjAAAVwa0LcIaHGjqvtwK+imxMBN1fOKL+hRxgqqe8fcRNd70l6j/9a VBNcMRD+c+XivN56RSUPThjiSVi0fm0p8w== X-Google-Smtp-Source: APXvYqzvwerUSvNvPfzJigLP+jZVWjaET1reHMxxHKr/T4wrs/naoFA/XnRWIA9TpSmfZ1xL3jT3GA== X-Received: by 2002:ae9:f443:: with SMTP id z3mr3376607qkl.193.1568724632495; Tue, 17 Sep 2019 05:50:32 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id h9sm1094750qke.12.2019.09.17.05.50.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 05:50:31 -0700 (PDT) From: Ted Lemon Message-Id: <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FED09A6D-8811-4A4A-A9AB-8F8DE55C189E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) Date: Tue, 17 Sep 2019 08:50:30 -0400 In-Reply-To: <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> Cc: hrpc@irtf.org To: avri@doria.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 12:50:43 -0000 --Apple-Mail=_FED09A6D-8811-4A4A-A9AB-8F8DE55C189E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 17, 2019, at 8:22 AM, avri@doria.org wrote: > I too am looking for RG guidance. FWIW, the objections I raised probably a year ago haven=E2=80=99t been = addressed yet. An RG document should make a clear case for whatever = point it=E2=80=99s making, but this document doesn=E2=80=99t do that. = The introduction is not really doing the job of an introduction=E2=80=94it= starts with several quotes, and never really says what the document is = about nor why we should read it. Section 3 should be the introduction, = and could start with the question stated there, and then give an = overview of what the document talks about and what research methodology = was used. The quotations in the introduction could either be chucked, = or woven in appropriately, but as they are, they just prevent the reader = from proceeding further. The text from the abstract could be useful in the introduction; the = abstract itself is meant to be a sales pitch for why you should read = further and what the document is about, and so this one is way too long. The methodology that produced the subsections of 4 is unclear; it seems = to be the author summarizing these viewpoints, but the author clearly = has opinions about these viewpoints, and the summaries are difficult to = follow and full of detail that is really part of the author=E2=80=99s = conclusion, and not part of the explanation of the position. So they = aren=E2=80=99t really doing the job of helping us to understand the = issues. Furthermore, we don=E2=80=99t know how the author decided to = represent just these viewpoints, and no others, nor is there any = discussion of the relationships between these views, which I think = clearly exist: they are presented as orthogonal. As an example of the difficulty of following these subsections, consider = subsection 4.4. We have an initial paragraph that explains the topic = decently well, followed by a long quotation from Heidegger that explains = it better, followed by a paragraph that introduces a new analogy, = finally followed by a paragraph that tries to relate these analogies to = the Internet and to protocols, but thoroughly fails to do so. I think = part of the reason it fails is that the author is really trying to = express his view of how the Internet is analogous to the two examples he = has given, and that distorts the analogy enough to make it quite = difficult to follow. There are two major issues with this document as an RG document. First, = I don=E2=80=99t think it is an RG document. I think it=E2=80=99s the = author=E2=80=99s document. Secondly, it desperately needs a = developmental edit. I think the ideas being expressed here are probably = worth expressing, but if it=E2=80=99s going to be Niels=E2=80=99 = document, then Niels needs to get some outside feedback to turn it into = a good document that says what Niels wants to say in a way is useful to = other readers. And if it=E2=80=99s to be an RG document, then it needs = to have more participation from the RG. In order for that to happen, it = probably needs Neils to be a contributing author rather than the editor, = and for someone else to take over the editorial role. --Apple-Mail=_FED09A6D-8811-4A4A-A9AB-8F8DE55C189E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 17, 2019, at 8:22 AM, avri@doria.org wrote:
I too am looking for RG guidance.

FWIW, the objections I raised probably a year ago haven=E2=80=99= t been addressed yet.  An RG document should make a clear case for = whatever point it=E2=80=99s making, but this document doesn=E2=80=99t do = that.  The introduction is not really doing the job of an = introduction=E2=80=94it starts with several quotes, and never really = says what the document is about nor why we should read it.   = Section 3 should be the introduction, and could start with the question = stated there, and then give an overview of what the document talks about = and what research methodology was used.  The quotations in the = introduction could either be chucked, or woven in appropriately, but as = they are, they just prevent the reader from proceeding = further.

The = text from the abstract could be useful in the introduction; the abstract = itself is meant to be a sales pitch for why you should read further and = what the document is about, and so this one is way too long.

The methodology that = produced the subsections of 4 is unclear; it seems to be the author = summarizing these viewpoints, but the author clearly has opinions about = these viewpoints, and the summaries are difficult to follow and full of = detail that is really part of the author=E2=80=99s conclusion, and not = part of the explanation of the position. So they aren=E2=80=99t really = doing the job of helping us to understand the issues.  Furthermore, = we don=E2=80=99t know how the author decided to represent just these = viewpoints, and no others, nor is there any discussion of the = relationships between these views, which I think clearly exist: they are = presented as orthogonal.

As an example of the difficulty of following these = subsections, consider subsection 4.4.  We have an initial paragraph = that explains the topic decently well, followed by a long quotation from = Heidegger that explains it better, followed by a paragraph that = introduces a new analogy, finally followed by a paragraph that tries to = relate these analogies to the Internet and to protocols, but thoroughly = fails to do so.  I think part of the reason it fails is that the = author is really trying to express his view of how the Internet is = analogous to the two examples he has given, and that distorts the = analogy enough to make it quite difficult to follow.

There are two major = issues with this document as an RG document.  First, I don=E2=80=99t = think it is an RG document.  I think it=E2=80=99= s the author=E2=80=99s document.  Secondly, it desperately needs a = developmental edit.  I think the ideas being expressed here are = probably worth expressing, but if it=E2=80=99s going to be Niels=E2=80=99 = document, then Niels needs to get some outside feedback to turn it into = a good document that says what Niels wants to say in a way is useful to = other readers.  And if it=E2=80=99s to be an RG document, then it = needs to have more participation from the RG.  In order for that to = happen, it probably needs Neils to be a contributing author rather than = the editor, and for someone else to take over the editorial = role.

= --Apple-Mail=_FED09A6D-8811-4A4A-A9AB-8F8DE55C189E-- From nobody Tue Sep 17 06:13:30 2019 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 00873120838 for ; Tue, 17 Sep 2019 06:13:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19XsnORIfTtC for ; Tue, 17 Sep 2019 06:13:26 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 2546E12006B for ; Tue, 17 Sep 2019 06:13:25 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iADHo-0005rB-Nb for hrpc@irtf.org; Tue, 17 Sep 2019 15:13:23 +0200 To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Tue, 17 Sep 2019 15:12:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 02b201d9c048bcde4aa7ed91fc024d05 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 13:13:29 -0000 Dear Ted, Thanks for this. On 9/17/19 2:50 PM, Ted Lemon wrote: > On Sep 17, 2019, at 8:22 AM, avri@doria.org wrote: >> I too am looking for RG guidance. > > FWIW, the objections I raised probably a year ago haven’t been addressed yet.  An RG document should make a clear case for whatever point it’s making, but this document doesn’t do that.  The introduction is not really doing the job of an introduction—it starts with several quotes, and never really says what the document is about nor why we should read it.   When the I-D started without references (not quotes), people said it should be based on existing literature and opinions within the IETF, and not on intuitions. Then I added these references to anchor the introduction documents. If Ted and the RG would prefer, I could also change around para 1 and para 2, but the academic way would be to start with embedding it in literature. I leave it to you all to let me know your preferences. Section 3 should be the introduction, and could start with the question stated there, and then give an overview of what the document talks about and what research methodology was used. It is highly unusual to start a paper with the research question (section 3.) and the methods (section 4).  The quotations in the introduction could either be chucked, or woven in appropriately, but as they are, they just prevent the reader from proceeding further. Have you tried reading the sentences without looking at the references? Am also happy to remove them and connect the two paragraphs. As said, it are not quotes, but references to show that we are not making this up. > > The text from the abstract could be useful in the introduction; the abstract itself is meant to be a sales pitch for why you should read further and what the document is about, and so this one is way too long. The abstract is 137 words, generally an abstract is 250 words in Science and Technology Studies, so am curious where this standards comes from. > > The methodology that produced the subsections of 4 is unclear; it seems to be the author summarizing these viewpoints, but the author clearly has opinions about these viewpoints, and the summaries are difficult to follow and full of detail that is really part of the author’s conclusion, The titles of these positions are taken literally from this mailinglist and discussions in the session, and then built up further by embedding them with existing literature. Where do you see a bad representation? > and not part of the explanation of the position. So they aren’t really doing the job of helping us to understand the issues. It would be great if you could point out where so we can improve.  Furthermore, we don’t know how the author decided to represent just these viewpoints, and no others, Because these were the viewpoints of 'positions that have been observed in the IETF and IRTF community, and have been observed during interviews, mailinglist exchanges, and during research group sessions. These positions were observed during participatory observation, through 39 interviews' nor is there any discussion of the relationships between these views, which I think clearly exist: they are presented as orthogonal. Where? Happy to correct that. > > As an example of the difficulty of following these subsections, consider subsection 4.4.  We have an initial paragraph that explains the topic decently well, followed by a long quotation from Heidegger that explains it better, followed by a paragraph that introduces a new analogy, finally followed by a paragraph that tries to relate these analogies to the Internet and to protocols, but thoroughly fails to do so.  I think part of the reason it fails is that the author is really trying to express his view of how the Internet is analogous to the two examples he has given, and that distorts the analogy enough to make it quite difficult to follow. This was provided by Andrew Sullivan, not by me. But happy to correct. > > There are two major issues with this document as an RG document.  First, I don’t think it /is/ an RG document.  I think it’s the author’s document.   Why, it has been adopted by the RG. Secondly, it desperately needs a developmental edit.  I think the ideas being expressed here are probably worth expressing, but if it’s going to be Niels’ document, then Niels needs to get some outside feedback to turn it into a good document that says what Niels wants to say in a way is useful to other readers.   I take issue with this description. There have been a lot of people who have contributed a lot of text to this document, among which Andrew Sullivan, Michael Rogers, and Amelia Andersdotter. And if it’s to be an RG document, then it needs to have more participation from the RG.  In order for that to happen, it probably needs Neils to be a contributing author rather than the editor, and for someone else to take over the editorial role. Where does this rule stem from? This was not how we progressed with RFC8280. Best, Niels > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Tue Sep 17 06:33:23 2019 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 2F8D41200BA for ; Tue, 17 Sep 2019 06:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUTC1jlHfQw9 for ; Tue, 17 Sep 2019 06:33:19 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E51120099 for ; Tue, 17 Sep 2019 06:33:19 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id m15so4419861qtq.2 for ; Tue, 17 Sep 2019 06:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=njXk2vgYhvA4bpqRrlLfusbi1e7PhIZ4+4tsSgcip14=; b=vKmRJGeRP2x2G/DwyggYpmrPhEbytNyRbYh0Eyr5zsrEe6RNUt4D1AKZ0S8rEB7CG9 boBOsNBeuD6uaHYKXB6VB8vwot+do3fjYp7JIfg2ZI63pfEUi23dIZgN22jaRUCUcyVQ UaAcpkvcyjdeBGxoBpWBAbhHKN7F+vIdxr+muHtZBw/ylJy6baTk3IJfJpJHjs8dZq5Q Y+mEC2q8taadoEWC7cxkRrdMoC2RdDWAK5oZ0pt+/tkgUewuAprIThlVApU8giXSBrlT Q8t64Qh+5hI7RKaCw/IGBICtFnItMjpadyOSlyX0mutOia+2hFAEwTKWNobDmGV6FH+l +ePQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=njXk2vgYhvA4bpqRrlLfusbi1e7PhIZ4+4tsSgcip14=; b=soMAoKtdnhpUW7jQ2BrthYtRb4Nm6VUy5S8Y7amlmiup83VLuh/emakw8qUfL1iX8L dVNmpXA6xROXn2q61bhxNEOv4n74vqfFb3dVy8vA3p4pSd+19K7exLaCfDuOdLTXjR1g eFLsdKqq8kZ9i0ZLyUeosRE5i9SLjBs/P8rQCCMUvf4tPIEktPXySihldloW/KnJcSwv hhB8pdVFzMUZgP2x/9PmqhftVgWxyyLzT5Ms7ypcnl6Sb4NdnfTfRSiV8GaS8SWM2nR0 G9U1PSi/47FC/u6WkngqY2buOAjB371SER2vMgBNNUGRulu4QQ0Zlk+YBbtT53yJkISZ Zycw== X-Gm-Message-State: APjAAAW6ehsaxd47rfH6Ija/9+XNf0U+sHFCSUwFslXdL/iozQkg+Xa4 gh8fAVSSGZOzXHzc9ig9ThKQqE12QDxrtQ== X-Google-Smtp-Source: APXvYqxdFY25GEzOMWCUkEMgArtcfaleO9rCjLfmD1DKCBaSFUZX191Ji71og1HehH4Ad3OZfSfrrw== X-Received: by 2002:ac8:2d09:: with SMTP id n9mr3638904qta.10.1568727198028; Tue, 17 Sep 2019 06:33:18 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id v26sm1488557qta.88.2019.09.17.06.33.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 06:33:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) From: Ted Lemon In-Reply-To: Date: Tue, 17 Sep 2019 09:33:16 -0400 Cc: hrpc@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> To: Niels ten Oever X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 13:33:22 -0000 This is an IRTF document, which will show up in the RFC series, and not = a standard academic document. If the goal is for this to be useful to = the community of users for which the IRTF and IETF are the core, then it = should look like an RFC, not like an academic paper. This means that the abstract should be just long enough to tell the = reader what is inside the package and why they should read it, and no = longer. It should not say anything about the structure of the RFC. Similarly, it may be that an academic research paper can=E2=80=99t start = with the research question because that=E2=80=99s the custom in academic = research papers; if this RG has as its goal to speak only to the = academic community, perhaps that is okay. But then why publish it here = and not in an academic journal? Isn=E2=80=99t the point of doing = academic work in the IRTF that it is part of the greater IETF community, = and that its work is the production of useful RFCs? Furthermore, if = academic papers generally suffer usability issues (and IMHO they do), = should we replicate those usability issues here, or should we do better? Anyway, as I read through the rest of the response, it appears that you = are simply disagreeing with my viewpoint. That=E2=80=99s fine=E2=80=94I=E2= =80=99m responding to Avri=E2=80=99s request for feedback with my = opinion, not trying to speak authoritatively to you as the author. I = have made similar comments in the past, and not seen the document change = as a result, nor seen my comments addressed. Perhaps this document = represents more views than just yours, but it certainly hasn=E2=80=99t = captured my feedback. As for the thicket of citations in the introduction, you have, at = minimum, a usability problem here. Don=E2=80=99t ask me to read past = the thicket of citations. Figure out a way to present these citations = so that they are usable. Your job as an editor is to produce a useful = document; when you get feedback that makes the document less useful, you = have to figure out a way to act on that feedback that is beneficial: = it=E2=80=99s not enough to take the feedback in its original form and = apply it, knowing that it=E2=80=99s making the document worse. > On Sep 17, 2019, at 9:12 AM, Niels ten Oever = wrote: >=20 > Dear Ted, >=20 > Thanks for this. >=20 > On 9/17/19 2:50 PM, Ted Lemon wrote: >> On Sep 17, 2019, at 8:22 AM, avri@doria.org = wrote: >>> I too am looking for RG guidance. >>=20 >> FWIW, the objections I raised probably a year ago haven=E2=80=99t = been addressed yet. An RG document should make a clear case for = whatever point it=E2=80=99s making, but this document doesn=E2=80=99t do = that. The introduction is not really doing the job of an = introduction=E2=80=94it starts with several quotes, and never really = says what the document is about nor why we should read it. =20 >=20 > When the I-D started without references (not quotes), people said it = should be based on existing literature and opinions within the IETF, and = not on intuitions. Then I added these references to anchor the = introduction documents.=20 >=20 > If Ted and the RG would prefer, I could also change around para 1 and = para 2, but the academic way would be to start with embedding it in = literature. I leave it to you all to let me know your preferences. >=20 >=20 > Section 3 should be the introduction, and could start with the = question stated there, and then give an overview of what the document = talks about and what research methodology was used.=20 >=20 > It is highly unusual to start a paper with the research question = (section 3.) and the methods (section 4).=20 >=20 > The quotations in the introduction could either be chucked, or woven = in appropriately, but as they are, they just prevent the reader from = proceeding further. >=20 > Have you tried reading the sentences without looking at the = references? Am also happy to remove them and connect the two paragraphs. = As said, it are not quotes, but references to show that we are not = making this up. >=20 >>=20 >> The text from the abstract could be useful in the introduction; the = abstract itself is meant to be a sales pitch for why you should read = further and what the document is about, and so this one is way too long. >=20 > The abstract is 137 words, generally an abstract is 250 words in = Science and Technology Studies, so am curious where this standards comes = from.=20 >=20 >>=20 >> The methodology that produced the subsections of 4 is unclear; it = seems to be the author summarizing these viewpoints, but the author = clearly has opinions about these viewpoints, and the summaries are = difficult to follow and full of detail that is really part of the = author=E2=80=99s conclusion, > The titles of these positions are taken literally from this = mailinglist and discussions in the session, and then built up further by = embedding them with existing literature.=20 >=20 > Where do you see a bad representation? >=20 >=20 >> and not part of the explanation of the position. So they aren=E2=80=99t= really doing the job of helping us to understand the issues.=20 >=20 > It would be great if you could point out where so we can improve. >=20 > Furthermore, we don=E2=80=99t know how the author decided to = represent just these viewpoints, and no others,=20 >=20 > Because these were the viewpoints of 'positions that have been = observed in the IETF and IRTF community, and have been observed during = interviews, mailinglist exchanges, and during research group sessions. = These positions were observed during participatory observation, through = 39 interviews' >=20 > nor is there any discussion of the relationships between these views, = which I think clearly exist: they are presented as orthogonal. >=20 > Where? Happy to correct that. >=20 >>=20 >> As an example of the difficulty of following these subsections, = consider subsection 4.4. We have an initial paragraph that explains the = topic decently well, followed by a long quotation from Heidegger that = explains it better, followed by a paragraph that introduces a new = analogy, finally followed by a paragraph that tries to relate these = analogies to the Internet and to protocols, but thoroughly fails to do = so. I think part of the reason it fails is that the author is really = trying to express his view of how the Internet is analogous to the two = examples he has given, and that distorts the analogy enough to make it = quite difficult to follow. >=20 >=20 > This was provided by Andrew Sullivan, not by me. But happy to correct. >=20 >>=20 >> There are two major issues with this document as an RG document. = First, I don=E2=80=99t think it /is/ an RG document. I think it=E2=80=99s= the author=E2=80=99s document. =20 >=20 > Why, it has been adopted by the RG. >=20 > Secondly, it desperately needs a developmental edit. I think the = ideas being expressed here are probably worth expressing, but if it=E2=80=99= s going to be Niels=E2=80=99 document, then Niels needs to get some = outside feedback to turn it into a good document that says what Niels = wants to say in a way is useful to other readers. =20 >=20 > I take issue with this description. There have been a lot of people = who have contributed a lot of text to this document, among which Andrew = Sullivan, Michael Rogers, and Amelia Andersdotter. >=20 >=20 > And if it=E2=80=99s to be an RG document, then it needs to have more = participation from the RG. In order for that to happen, it probably = needs Neils to be a contributing author rather than the editor, and for = someone else to take over the editorial role. >=20 > Where does this rule stem from? This was not how we progressed with = RFC8280. >=20 >=20 > Best, >=20 > Niels >=20 >>=20 >>=20 >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >>=20 >=20 > --=20 > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam >=20 > PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 > 643A 0ED8 3F3A 468A C8B3 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Tue Sep 17 06:46:03 2019 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 C8D31120855 for ; Tue, 17 Sep 2019 06:46:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsK5UZoLyvOA for ; Tue, 17 Sep 2019 06:45:58 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 AE20012084F for ; Tue, 17 Sep 2019 06:45:58 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iADnH-00022S-EG; Tue, 17 Sep 2019 15:45:54 +0200 To: Ted Lemon Cc: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> Date: Tue, 17 Sep 2019 15:45:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: f1b3c07d35a4e285624b5d01cbfc750a Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 13:46:02 -0000 Hi Ted, On 9/17/19 3:33 PM, Ted Lemon wrote: > This is an IRTF document, which will show up in the RFC series, and not a standard academic document. If the goal is for this to be useful to the community of users for which the IRTF and IETF are the core, then it should look like an RFC, not like an academic paper. > > This means that the abstract should be just long enough to tell the reader what is inside the package and why they should read it, and no longer. It should not say anything about the structure of the RFC. > > Similarly, it may be that an academic research paper can’t start with the research question because that’s the custom in academic research papers; if this RG has as its goal to speak only to the academic community, perhaps that is okay. But then why publish it here and not in an academic journal? Isn’t the point of doing academic work in the IRTF that it is part of the greater IETF community, and that its work is the production of useful RFCs? Furthermore, if academic papers generally suffer usability issues (and IMHO they do), should we replicate those usability issues here, or should we do better? I have tried in my work in this RG to build a bridge between the IETF and academia. When I write things in IETF/RFC format, people say it is not academic enough, when things are more academic, it is not IETF/RFC enough. I am really at a loss here. If you want to be a co-author, I am happy to have you on as one. I am also happy to take pull requests, as you have seen in the past there is an almost 100% acceptance rate for them, as with text suggestions. > > Anyway, as I read through the rest of the response, it appears that you are simply disagreeing with my viewpoint. I am happy to address your viewpoints, but it is hard to navigate suggestions from the RG that are simply going in different directions. That’s fine—I’m responding to Avri’s request for feedback with my opinion, not trying to speak authoritatively to you as the author. I have made similar comments in the past, and not seen the document change as a result, nor seen my comments addressed. I am very sorry about that, since I really do try to respond to all comments and take them into account. It saddens me that you feel I don't. Perhaps this document represents more views than just yours, but it certainly hasn’t captured my feedback. > > As for the thicket of citations in the introduction, you have, at minimum, a usability problem here. Don’t ask me to read past the thicket of citations. Figure out a way to present these citations so that they are usable. Your job as an editor is to produce a useful document; when you get feedback that makes the document less useful, you have to figure out a way to act on that feedback that is beneficial: it’s not enough to take the feedback in its original form and apply it, knowing that it’s making the document worse. Maybe I could add a footnote to the introduction, or to the document in general, where I would place these references? Any suggestions on how this is done within the RFC context would be very welcome. Best, Niels > >> On Sep 17, 2019, at 9:12 AM, Niels ten Oever wrote: >> >> Dear Ted, >> >> Thanks for this. >> >> On 9/17/19 2:50 PM, Ted Lemon wrote: >>> On Sep 17, 2019, at 8:22 AM, avri@doria.org wrote: >>>> I too am looking for RG guidance. >>> >>> FWIW, the objections I raised probably a year ago haven’t been addressed yet. An RG document should make a clear case for whatever point it’s making, but this document doesn’t do that. The introduction is not really doing the job of an introduction—it starts with several quotes, and never really says what the document is about nor why we should read it. >> >> When the I-D started without references (not quotes), people said it should be based on existing literature and opinions within the IETF, and not on intuitions. Then I added these references to anchor the introduction documents. >> >> If Ted and the RG would prefer, I could also change around para 1 and para 2, but the academic way would be to start with embedding it in literature. I leave it to you all to let me know your preferences. >> >> >> Section 3 should be the introduction, and could start with the question stated there, and then give an overview of what the document talks about and what research methodology was used. >> >> It is highly unusual to start a paper with the research question (section 3.) and the methods (section 4). >> >> The quotations in the introduction could either be chucked, or woven in appropriately, but as they are, they just prevent the reader from proceeding further. >> >> Have you tried reading the sentences without looking at the references? Am also happy to remove them and connect the two paragraphs. As said, it are not quotes, but references to show that we are not making this up. >> >>> >>> The text from the abstract could be useful in the introduction; the abstract itself is meant to be a sales pitch for why you should read further and what the document is about, and so this one is way too long. >> >> The abstract is 137 words, generally an abstract is 250 words in Science and Technology Studies, so am curious where this standards comes from. >> >>> >>> The methodology that produced the subsections of 4 is unclear; it seems to be the author summarizing these viewpoints, but the author clearly has opinions about these viewpoints, and the summaries are difficult to follow and full of detail that is really part of the author’s conclusion, >> The titles of these positions are taken literally from this mailinglist and discussions in the session, and then built up further by embedding them with existing literature. >> >> Where do you see a bad representation? >> >> >>> and not part of the explanation of the position. So they aren’t really doing the job of helping us to understand the issues. >> >> It would be great if you could point out where so we can improve. >> >> Furthermore, we don’t know how the author decided to represent just these viewpoints, and no others, >> >> Because these were the viewpoints of 'positions that have been observed in the IETF and IRTF community, and have been observed during interviews, mailinglist exchanges, and during research group sessions. These positions were observed during participatory observation, through 39 interviews' >> >> nor is there any discussion of the relationships between these views, which I think clearly exist: they are presented as orthogonal. >> >> Where? Happy to correct that. >> >>> >>> As an example of the difficulty of following these subsections, consider subsection 4.4. We have an initial paragraph that explains the topic decently well, followed by a long quotation from Heidegger that explains it better, followed by a paragraph that introduces a new analogy, finally followed by a paragraph that tries to relate these analogies to the Internet and to protocols, but thoroughly fails to do so. I think part of the reason it fails is that the author is really trying to express his view of how the Internet is analogous to the two examples he has given, and that distorts the analogy enough to make it quite difficult to follow. >> >> >> This was provided by Andrew Sullivan, not by me. But happy to correct. >> >>> >>> There are two major issues with this document as an RG document. First, I don’t think it /is/ an RG document. I think it’s the author’s document. >> >> Why, it has been adopted by the RG. >> >> Secondly, it desperately needs a developmental edit. I think the ideas being expressed here are probably worth expressing, but if it’s going to be Niels’ document, then Niels needs to get some outside feedback to turn it into a good document that says what Niels wants to say in a way is useful to other readers. >> >> I take issue with this description. There have been a lot of people who have contributed a lot of text to this document, among which Andrew Sullivan, Michael Rogers, and Amelia Andersdotter. >> >> >> And if it’s to be an RG document, then it needs to have more participation from the RG. In order for that to happen, it probably needs Neils to be a contributing author rather than the editor, and for someone else to take over the editorial role. >> >> Where does this rule stem from? This was not how we progressed with RFC8280. >> >> >> Best, >> >> Niels >> >>> >>> >>> _______________________________________________ >>> hrpc mailing list >>> hrpc@irtf.org >>> https://www.irtf.org/mailman/listinfo/hrpc >>> >> >> -- >> Niels ten Oever >> Researcher and PhD Candidate >> DATACTIVE Research Group >> University of Amsterdam >> >> PGP fingerprint 2458 0B70 5C4A FD8A 9488 >> 643A 0ED8 3F3A 468A C8B3 >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Tue Sep 17 07:11:53 2019 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 814C612006A for ; Tue, 17 Sep 2019 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LezoZksIWMNz for ; Tue, 17 Sep 2019 07:11:50 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CE3120059 for ; Tue, 17 Sep 2019 07:11:49 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id x5so4553292qtr.7 for ; Tue, 17 Sep 2019 07:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xwvzfXa6Z865+N0sGV8XRNpxRafFu/aXqWwLiEeQ5us=; b=01AQuXMDhr2guY+24fn9xXsb5Wc94rGPQGsEyX4p92fQhq9Ly8Vg+TjHWqNHU0m8uu uMnna9w6SsKiP0W+19PqaYgRkkw6hLzO3NFSwfFLmAgrrn0KFRksl9Ldqt4XA9por888 sBNnuRuqbcXpB5cdtOeP6T32Qgv2ydnSiC8WR93NcH9qfXhauDHmRRJJmrDrcupUI8ke 7Ij0ucGt4MhPj7b3/qpO18FOGMakLjQg4Rudb3lXYj5gRBvWVoJ/kwHiellcfRP8f/Am 0/aIh9JP0NZrrVTSSW+qlj04J70r8OidctVvjHx6FaSnHKlbaWgbXBVV4P8WvmScO01i Q9hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xwvzfXa6Z865+N0sGV8XRNpxRafFu/aXqWwLiEeQ5us=; b=T0WS31QlSoKBLWqwlAxuFtIIMdK92rwtOzFxpoNZwDmCwa0eCo67X4ssvT+NbjIklR xjAK3vY9/fJcYaFypcGstFxAfw+n3z76V1AVe0Y5wsoL1AlgrXe7XLx6H2cHZtg9CsI4 zP05TSiuBcAu0m9DKFmEYP66aFV0wRzOrirz2pIRVkFZPDMLmOwazTAkn5mWKQQRNx2F yMG/4p28PzqCA1at17yNVPsFSTWwG6l3ZvgxKcKbC3DjLCg7eziREam6jL8/uc53ETNe V0oq8j3mcMT6Nz4hkVKFKzbmUVRQKkCJK6AZ6jj627Oce9SLR6DOJyMM/ouZMfnLGDX/ oJ0g== X-Gm-Message-State: APjAAAXZzE46+96uk4I7FBAwlpWtuA7R3dYfqU4Tdq3XDGNkriUScCwj IIjuUkmmQWsPRsBdGA6pX4ZV/w== X-Google-Smtp-Source: APXvYqyPAn6m6SXIdq0ujYPGunB5Y//xj63uvTNUf+F4sOrO+WxI871bgxCAAIXfXBm0ib3YDOuJ9g== X-Received: by 2002:ac8:3195:: with SMTP id h21mr4041394qte.350.1568729508918; Tue, 17 Sep 2019 07:11:48 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id r7sm1263334qkb.82.2019.09.17.07.11.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 07:11:48 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9DC453E4-0FFA-427B-BE07-E3552F98AFD1" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) Date: Tue, 17 Sep 2019 10:11:46 -0400 In-Reply-To: <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> Cc: hrpc@irtf.org To: Niels ten Oever References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:11:52 -0000 --Apple-Mail=_9DC453E4-0FFA-427B-BE07-E3552F98AFD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 17, 2019, at 9:45 AM, Niels ten Oever = wrote: > I have tried in my work in this RG to build a bridge between the IETF = and academia. When I write things in IETF/RFC format, people say it is = not academic enough, when things are more academic, it is not IETF/RFC = enough. I am really at a loss here. It may be that you have taken on an impossible task. But let=E2=80=99s = assume for a moment that you have not. If not, then when you are faced = with a choice between readability and conformity, which do you think is = the right choice to make? > If you want to be a co-author, I am happy to have you on as one. I am = also happy to take pull requests, as you have seen in the past there is = an almost 100% acceptance rate for them, as with text suggestions. I hate to continue to give you a hard time, but this may be part of the = problem=E2=80=A6 :] >> Anyway, as I read through the rest of the response, it appears that = you are simply disagreeing with my viewpoint. >=20 > I am happy to address your viewpoints, but it is hard to navigate = suggestions from the RG that are simply going in different directions.=20= When we get into situations like this, it might help to step back and = ask the question: what is it that we want out of this document? Why are = we doing this? What I generally want out of documents is that they provide a clear = picture of something that we need to understand, but do not all = collectively understand well. They should be written in such a way that = with as little effort as possible, I can read them and come away = understanding the problem or solution being discussed more clearly. I = can know what the authors opinions are, and where what they said was = opinion, and where what they said was intended to be objective. I can = reason about whether it was objective. Writing documents like this is really hard. There is nothing to be = ashamed of when you don=E2=80=99t succeed at first attempt. Speaking of academic publishing, it is frequently the case that the goal = of the document is not what I stated above. Because of the =E2=80=9Cpubli= sh or perish=E2=80=9D problem, and also the =E2=80=9CI need to look = smart=E2=80=9D problem, and the =E2=80=9CI need to signal that I am an = academic=E2=80=9D problem, much is typically said in the document that = has nothing to do with communicating about the ostensible subject of the = document. While we can=E2=80=99t pretend that these pressures don=E2=80=99t exist = for authors of IRTF documents, I think it=E2=80=99s worth actually = aspiring to produce useful stuff, and to notice when the various = pressures of academia distort the writing and make it less useful. Of course, this is just my opinion. It may be that there isn=E2=80=99t = consensus on this. There are valid reasons to try to conform to = academic forms: if we don=E2=80=99t, there=E2=80=99s a risk that = academics won=E2=80=99t take us seriously. But if we are to compromise = in service of that goal, let=E2=80=99s at least understand why it is = that we want to be taken seriously, and what our options are for = achieving that goal. At present it feels like it=E2=80=99s a bit contemptuous of academics to = suggest that they will not read a useful, clear document because it=E2=80=99= s not in the right form. If there are academics for whom this = conjecture is true, are they the ones we want to reach? What is the good outcome here? Is it being heard, or is it being = influential? Do we actually have something valuable to say? Who needs = to hear what we have to say? Why will it be beneficial for them to do = so? --Apple-Mail=_9DC453E4-0FFA-427B-BE07-E3552F98AFD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 17, 2019, at 9:45 AM, Niels ten Oever <mail@nielstenoever.net> wrote:
I have tried in my work in this RG to build a bridge between = the IETF and academia. When I write things in IETF/RFC format, people = say it is not academic enough, when things are more academic, it is not = IETF/RFC enough. I am really at a loss here.

It may be = that you have taken on an impossible task.  But let=E2=80=99s = assume for a moment that you have not.  If not, then when you are = faced with a choice between readability and conformity, which do you = think is the right choice to make?

If you want to be a co-author, I am happy to have you on as = one. I am also happy to take pull requests, as you have seen in the past = there is an almost 100% acceptance rate for them, as with text = suggestions.

I hate to = continue to give you a hard time, but this may be part of the problem=E2=80= =A6 :]

Anyway,= as I read through the rest of the response, it appears that you are = simply disagreeing with my viewpoint.

I am happy to = address your viewpoints, but it is hard to navigate suggestions from the = RG that are simply going in different directions. 

When we = get into situations like this, it might help to step back and ask the = question: what is it that we want out of this document?  Why are we = doing this?

What I generally want = out of documents is that they provide a clear picture of something that = we need to understand, but do not all collectively understand well. =  They should be written in such a way that with as little effort as = possible, I can read them and come away understanding the problem or = solution being discussed more clearly.  I can know what the authors = opinions are, and where what they said was opinion, and where what they = said was intended to be objective.  I can reason about whether it = was objective.

Writing documents like this is really hard. =  There is nothing to be ashamed of when you don=E2=80=99t succeed = at first attempt.

Speaking of = academic publishing, it is frequently the case that the goal of the = document is not what I stated above. =  Because of the =E2=80=9Cpublish or perish=E2=80=9D problem, = and also the =E2=80=9CI need to look smart=E2=80=9D problem, and the = =E2=80=9CI need to signal that I am an academic=E2=80=9D problem, much = is typically said in the document that has nothing to do with = communicating about the ostensible subject of the = document.

While we can=E2=80=99t = pretend that these pressures don=E2=80=99t exist for authors of IRTF = documents, I think it=E2=80=99s worth actually aspiring to produce = useful stuff, and to notice when the various pressures of academia = distort the writing and make it less useful.

Of course, this is just my opinion.  It may = be that there isn=E2=80=99t consensus on this.  There are valid = reasons to try to conform to academic forms: if we don=E2=80=99t, = there=E2=80=99s a risk that academics won=E2=80=99t take us seriously. =  But if we are to compromise in service of that goal, let=E2=80=99s = at least understand why it is that we want to be taken seriously, and = what our options are for achieving that goal.

At present it feels like it=E2=80=99s a bit = contemptuous of academics to suggest that they will not read a useful, = clear document because it=E2=80=99s not in the right form.  If = there are academics for whom this conjecture is true, are they the ones = we want to reach?

What is the good = outcome here?   Is it being heard, or is it being influential? =   Do we actually have something valuable to say?  Who needs to = hear what we have to say?   Why will it be beneficial for them to = do so?

= --Apple-Mail=_9DC453E4-0FFA-427B-BE07-E3552F98AFD1-- From nobody Tue Sep 17 07:20:11 2019 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 A1DBF120855 for ; Tue, 17 Sep 2019 07:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cis-india.org 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 l3845bA5nazX for ; Tue, 17 Sep 2019 07:20:06 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 AFCD512006A for ; Tue, 17 Sep 2019 07:20:05 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iAEKo-0007YV-Vc for hrpc@irtf.org; Tue, 17 Sep 2019 16:20:03 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org 58976580BC03E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1568729999; bh=YBgeBxNKP9nPs3xpCLXUmNEzKG18M+2rjplRTnRH/Ow=; h=To:From:Message-ID:Date:MIME-Version; b=cJCfovXLBWdhqQ7TJbGP5jZRYqh2gqgggRk8yH3USHm4aScjeAJeZ2nbfJhJD0VcM mkCBvvaEw4QNwKrGicOR/HqFeAGbA0FBULMzw5eKgbO3TJUX+fRL9wMqYq8jHlZze6 995vxJRJQRJQfFtyp5yWQvbH/ndHJRLSjv60FtlqTZr+Aq60ixF5cy95ZbzBAG3Mcv KCR9lB23tiugicbuFLx3xx7tF/bDixSkwYNbzxkmPNAYyN/Frwrv2Wb0SxenHsAu6E kXo4esyOXaLfMi6YhFEYujdsoE1qOaGBhpuWaXcwzQpMHGyknS485rU8vil4iagkzm nlqwjdpxWtIaA== To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> From: Gurshabad Grover Openpgp: preference=signencrypt Autocrypt: addr=gurshabad@cis-india.org; keydata= mQINBFriroIBEADfyDpCD8eborMUMXKtZzjo4t2KzrAlUVYgE/TFtrwUP+4Xw4dzakDIzST8 sVYmlXIWhM5NBBTZSQ190vsxrkbi0xxLcXYM2olZEtqkJ8zONZeZLBeGvcfMymtHqD4jHwYb Zm7OXnS45fWDL+HOoMP/VCwEn098rYfnllIkYQD1Gc28Ig+ywjGg8y5p0qMmmmhm2ckgLjnG MJX8t273MSc8wsn/UYH922yif3MQXmrzqgnRl9hRzf90SKqAw38bw7wccb55pIItloKYsi0r zYBKJSOPXn91Z21TpOSTy21M0MZYEAlDn1zeea+q8TggfHNWxOXoKrIm1pqZFRz0k+8i2siJ AHf8bRm/fhukA6szZ6b2nNPxjkAmOv9zvGu6RZGbmeLvQYVBSSnZ67ayZrkKwn7KIyAV6hQM /bVnD8eEZ2tZ0S8lxoZFYSNeMGt2b6WelFZO97/LbjxaJUHd9K8g5H0MwqN1NXoBxRwllVRC 3sVHVoWTBqnKo8qplzvQEAto69PpvuxxKTOFEJeQqmn1b/fo3sLRb4YiIg8Ax+Np7Huzzjk6 vKKgpIwIN7yEUj/ReWi/UA/W4wSg3XkcqTf7h73crnN/1At0PdgozbDV2UbcApaldStP4DfG UiQl0/7MiYLKapDDuSahmoeH3xrNnrzS9BAfuGHezzDbMyPLXQARAQABtCpHdXJzaGFiYWQg R3JvdmVyIDxndXJzaGFiYWRAY2lzLWluZGlhLm9yZz6JAj0EEwEIACcFAlriroICGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQrbl/X+ubfC7/bQ//YQv7zqQE433xxsN/ 3GYKoOFccBy3WvV4DxrTskJ3n3k5lfcZolbc8TQksQOTzyerNt2ZA7fsGZa7eFSW+xR4Yq3/ C9o+5FOoHGhyZhb+x17MILhmyvyUNSj7SdKrRISgurMbV2Vv8LxmTcdrK6CdFF6JLH+opzU1 NlRKwZqROPgbYZEB2QFIUbGfgh2I5AXNyV2XbT7fagfkHk+v9AUV7POP2H1+AZ1xq6iFTm2o 9ufNZsp2bInsDohcVBKC3aH2cnFMjvIXpNoUOx8vb5A2xW0aBUTTJDB/uZw53WOg3kehrCNb ZkML3FnDZLRuu1e8DSWmwk5YIoDzt5bMCgfUwb0C6Q+JuM8lC+8CEEa9qamLc+fhvFAzcrWp VWuSaVeLdhe5NxmtlRYNZdGuKy6sRHjwsEWlwzRylhm74fiDR3aA1eIFsfmYLd4z+i1Fp23Y dHJf7/Gor2CmOxphog9DEA9WCuORXfx4De7hoMKwW4gWKw1A8B12Cv4EOkXmCsWsOnfDEarr 2Yl6elxkhQRfKjAesXb0cezRzZgwsWIsbeYsuWFF7Xi6IzUJ27lxU3p5PcyY8O8aDYOn+pu0 YFJ7s3u2VRRgptVZJmkcN3WTApXSHY8fGl5xAakM/bqFJj9uj5zlMnFN2EplC6/mQkfYfy2f siaGTP/GQV4OSuOeuMK5Ag0EWuKuggEQAJ4lAzB72gHw4+rbyxmQNNVmvgYVZPjFtO/MQdYi x1QwRP/gxxqPqTd/ZwQvmPGzXRKw10B7uKSRk6YP12+IG0mXJwHGp9q5CWJE0XNGqX3UWbAc KIzxqPNpsf8e6Bv7jdW0YwLBxJ+RW0NNL6uAxz0sr2frbnS+EZB3cU+zOZzp/9YfTUZO2lxF NzgJoErKe/HLp7aBeJXBBcwO0LQlIT80rTZx2KihBa/Ww/y9E9gV/HacJu/Ncb6E/G3e4xGj 9w9L+UW43q01wy+FSUKy9FLc7D40WqQsj8SXZEpl84SyLcJRoX3mtj59bX2SAN2VB2BAksTu qCh00IcIUGfyHziu5PwUWYM96gOhDSocP4wSeiQ8TwLzaffllz2qhdI296a9lCIYIeWVytEd NU9jJ3RbzXAgE0pnDauNXDaQv1FS5jYi8rlslJUxKnrS69BFNjM5RqQ16Cm0C4rKL7/a8wHC r4VjcjSCM8Lzv8YOOitJ9Yt4Y8SVfO5s3YvxcdSr56nX0W3B1kGbG1GpqWTzOgXzGF5bIsbV 7SPecwUs9ShvmLmZzDUxIQ68n4zj3lMZn5I+pP+Ew6nAAiuSmKdr5cygnCH/NVJzil07t+X4 uR6oKHBhuMFYF1c6Wxk36m+EZz5ZHFaT4rN0WDIJdAEqRzD0Z56V6ansDF8y+ksh0SHlABEB AAGJAiUEGAEIAA8FAlriroICGwwFCQlmAYAACgkQrbl/X+ubfC50rhAAloTaq/fZC1gtiVtU wOB+00gEkjgmzt+rLkW+l2EySTST7tje57W83UZwzCX746B2O//Bqardxz9R1Vr0VFiwHA8g 3qeBqPqiv1WoQch/iZ5d/1MxK4A9xDag1uyqLR8RuGlZ8lATmcP3IabKiuiBV4MlFZ7V2Ib6 5ToPf28xxSyjMzTjQObIG0e009uHlu2z+iQVshLyoyVVAOWWa88D6iuBDC/EtBRjlpjLAjuR YhWVYX6KHdVUijKMHN2RqjpX5O2wPL7NcMY/wsTq7EteUeI75hxFvargRXkEt1XR8t52LC0u IE2OjpzY5re/ROUbfsqL8trjAOrSJ+Fx5H8AYl9JaoVxohhxDZgNtgNtPbh/8Nnlf9daj/bh lZcTBO98XLQwMnyHGPdyhIodpWPq2C09Ys3TkQsbcdMMB1pqnEK5Vz1zIKkEEX7QVsLdrz7C 2CFsauc/9PHj+4njCHslXtzBOiVu5FXTnbCwPrLJs5iEUkUCb6qtE/2mSCTrAanzOTTOmqiM cnNTI1Tj0ht462S9VypppQnKCv8shGxXG7BadZTv+pNCA/WfB2kk1sS3ZwB0wBWX4p41fxs+ ArM9ew2SzQ/vBrEfO7ljPfZZmBqH4t/vgAZBnOtTxCGlPEIJqiMqtGHRqIqpiR20QfxEUuXI MfMfa9QJpisdNmqoUyc= Message-ID: <396911d9-63c4-09a0-77d0-a09f72689c19@cis-india.org> Date: Tue, 17 Sep 2019 19:50:00 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 729ef2e9e2cd27dd49f9ca04774c95e6 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:20:10 -0000 On 17/09/19 5:52 PM, avri@doria.org wrote: > > I too am looking for RG guidance. > Hello. Some thoughts on the research question and the conclusion in the draft: Andrew Sullivan's comments from a while ago [fn0] ring true to me. I actually think there are three questions the draft is trying to comment on: (1) Do networking standards have political use and/or impact? (2) Is there politics in the development of networking standards? (3) "Are protocols political?" The conclusion (and abstract) say that (1) and (2) are undisputed: "it is undisputed that standards and protocols are both products of a political process, and they can also be used for political means." I think it would be useful to clarify how this is arrived at: is this statement relying on the views summarised in Section 4, i.e. through participant observation, discussions and interviews? Because to me, all subsections of Section 4 do not seem to be answering all the three questions. (See [fn1] for how I'm reading each subsection in Section 4, please correct me if I'm wrong). While the draft says that it does not aim to check participants' views for consistency, I still think the addition of text to this effect is important because this claim is relied upon in the conclusion to answer (3), i.e. the research question, in the affirmative. This seems to be suggesting that if (1) and (2) are true, then (3) is true. Is this a correct interpretation? Quick summary of my suggestions: * explicitly add what specific question out of the three was discussed/asked in Section 4; * clarify whether Section 4 is being used to arrive at the conclusion; * clarify the link between the three questions Thank you. -Gurshabad [fn0] https://mailarchive.ietf.org/arch/msg/hrpc/FjPucFoWPCaVzNbYOycp3TH1Z4I [fn1] For each claim, I interpret the answers in sub-sections of Section 4 to be: * 4.1: (1) True; (2) Unclear; (3) False * 4.2: (1) Unclear; (2) Unclear; (3) Sometimes true * 4.3: (1) True; (2) Unclear; (3) Unclear * 4.4: (1) True; (2) Unclear; (3) Maybe true? * 4.5: (1) True; (2) True; (3) True From nobody Tue Sep 17 07:23:33 2019 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 674551208BC for ; Tue, 17 Sep 2019 07:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzxoqHtrN0z8 for ; Tue, 17 Sep 2019 07:23:30 -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 CB4D71208B6 for ; Tue, 17 Sep 2019 07:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4280; q=dns/txt; s=iport; t=1568730210; x=1569939810; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=vDAFGtDiRI7hQXSgAlr/la+rGD+kw5AFUbkI2dq2NDM=; b=jUKLvYtNXUYU8Fs6wVUCb6e2/ROSFd116ij+VMtUKgX7B31pCMbHvhSk RXWd38QQRBTzCD6a/tOByZ0CispB7Qo8p31VDh7ff801W/Oy6rMUN9c5R Eur+wW3E5J09sqznvHXmNR/+Vrj22nDjF2e9autm4VhaEQdauxX+EaPS5 o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAAAK7IBd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBFYJCIBIqhCGIfIggh0OLUogGAgcBAQEJAwE?= =?us-ascii?q?BLwEBhD8Cgx83Bg4CAwkBAQQBAQECAQUEbYU6hUoBAQEBAgEjVgULCwQKCio?= =?us-ascii?q?CAlcGE4MiAYF7D614gTKFTIRvEIE0AYFQij+Bf4E4H4JMPodPMoImBJV0lnu?= =?us-ascii?q?CLIIugRORQBuNeosgo32DEQIEBgUCFYFoIoFYMxoIGxVlAYJBPpBLPgMwkHY?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.64,516,1559520000"; d="asc'?scan'208,217";a="16861851" 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-SEED-SHA; 17 Sep 2019 14:23:25 +0000 Received: from [10.61.225.65] ([10.61.225.65]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x8HENOMi023473 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Sep 2019 14:23:25 GMT From: Eliot Lear Message-Id: <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_656CE826-6C7A-49E8-B0BD-6779995628B6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Sep 2019 16:23:24 +0200 In-Reply-To: Cc: Niels ten Oever , hrpc@irtf.org To: Ted Lemon References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.225.65, [10.61.225.65] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:23:32 -0000 --Apple-Mail=_656CE826-6C7A-49E8-B0BD-6779995628B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_668C0C72-7B75-4DA9-AA68-67A237D0B898" --Apple-Mail=_668C0C72-7B75-4DA9-AA68-67A237D0B898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ted, > On 17 Sep 2019, at 16:11, Ted Lemon wrote: >=20 > When we get into situations like this, it might help to step back and = ask the question: what is it that we want out of this document? Why are = we doing this? Indeed. Niels is in a hard spot because there are a variety of = expectations about what this document should contain. Just between you = and me there are differences. And this boils down a bit to =E2=80=9CWhose= document is it anyway?=E2=80=9D RGs have some latitude on this, by the = way: this document does not need to be a consensus view. But if it is, = then our differences should be explored. To your point, and to the point Avri made, the document must be clear as = to its purpose, and that is where I think some of the trouble lies now. = The =E2=80=9Cwhy=E2=80=9D is a very important question because it = provides some scoping as to audience and focus. The way I put this is = that there has to be some import to the work that is clear to the = reader. Eliot --Apple-Mail=_668C0C72-7B75-4DA9-AA68-67A237D0B898 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ted,

On 17 Sep 2019, at 16:11, Ted Lemon <mellon@fugue.com> = wrote: 

When we = get into situations like this, it might help to step back and ask the = question: what is it that we want out of this document?  Why are we = doing this?


Indeed.  Niels is = in a hard spot because there are a variety of expectations about what = this document should contain. Just between you and me there are = differences.  And this boils down a bit to =E2=80=9CWhose document = is it anyway?=E2=80=9D  RGs have some latitude on this, by the way: = this document does not need to be a consensus = view.  But if it is, then our differences should be = explored.

To your point, and to the = point Avri made, the document must be clear as to its purpose, and that = is where I think some of the trouble lies now.  The =E2=80=9Cwhy=E2=80= =9D is a very important question because it provides some scoping as to = audience and focus.  The way I put this is that there has to be = some import to the work that is clear to the reader.

Eliot
= --Apple-Mail=_668C0C72-7B75-4DA9-AA68-67A237D0B898-- --Apple-Mail=_656CE826-6C7A-49E8-B0BD-6779995628B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2A7FwACgkQh7ZrRtnS ejM6Pgf/V+jJ6O/MKVCukNI8u0guYkbw4/qz8h4bq/On65mjHbCLexUnHdO6oINN dCrDh2DhL3gpARntYnNoPbItzCaWaFDVRtv3VZOlL3nNO38DKkGnJYva9hnNl2Yx 6iYsCrp1ofmCP7eFxBIEGJ0nvkye3xdDdF/FdLj9CQlqWrp2A9SDhwHV2R7QjUQg 8eYV93GRgUS/bNtpxDsuxp9hXgX3fEbWZgbgMpQvrXVeb2473/W/QIDVCIJF7+Cp 1WYSOd+JV1fOHRmTJhiVZLcrC5p13dB2w1E+Q+jcMoFLDyqkEuEXjKlvsAP80KpQ esEuAZbStrkwO/vBdtcisv89KtMp4w== =THNw -----END PGP SIGNATURE----- --Apple-Mail=_656CE826-6C7A-49E8-B0BD-6779995628B6-- From nobody Tue Sep 17 08:03:07 2019 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 1237B120928 for ; Tue, 17 Sep 2019 08:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Gw105ngR; dkim=pass (1024-bit key) header.d=yitter.info header.b=m7cl/sjE 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 atsnJao7BYiq for ; Tue, 17 Sep 2019 08:03:02 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99851208E7 for ; Tue, 17 Sep 2019 08:03:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id CF9C3BCC7D for ; Tue, 17 Sep 2019 15:02:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568732579; bh=YeeGVfyixrugY7+KIMaV1UvfcSrtTDFS2od4DnPP6c0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Gw105ngRjp+FfrpxJeg9DCdu8Bf+fmlnv4SPoc20/Xq93sOm6RB9PC1og7YnC+Jmi V2GCjQurzJWxL4U7LNBbZA0VEKMtxTSu2auX9h/JDfkdCVGp6wg83C8yTeMKX3aZjx yGRfpVmYS1SbO55YDJtNpTIeRerAgMvuSvVM9WYk= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3mFjJa2Sp_J for ; Tue, 17 Sep 2019 15:02:58 +0000 (UTC) Date: Tue, 17 Sep 2019 11:02:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568732578; bh=YeeGVfyixrugY7+KIMaV1UvfcSrtTDFS2od4DnPP6c0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=m7cl/sjEPaBDlLzTxcFYviVJ+8fg1l/sG2m69zqQrdX0nTzaLfTKyx+CvuAS+b5D8 RyawJb1qzaUiDBJGMpL/eKXiwcRqtURYz1IR35DgI+AR5Y6xu36Lfy89BzSCBPqM/K hZpqdgjqg9UsaDji/gP0QkjaQhwYOGx1VloigM78= From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 15:03:05 -0000 Hi, Speaking as usual only for myself (but I am employed by the Internet Society). On Tue, Sep 17, 2019 at 04:23:24PM +0200, Eliot Lear wrote: > And this boils down a bit to “Whose document is it anyway?” RGs have some latitude on this, by the way: this document does not need to be a consensus view. But if it is, then our differences should be explored. > I simply don't understand why that self-imposed rule is being followed in this case anyway. It has been long clear, in my opinion, that the authors of this document have a strong view they wish to press, and that they will do so. Several of us have extremely serious reservations about that view (for my part, I have given up on making those arguments, because I was unsatisfied with the way they were addressed and I just don't have the time to invest to continue to press the point). In such an environment, a consensus document will either be too watery to be interesting or else will not really represent consensus. The solution to such a dilemma is surely to refuse the conditions that make it possible. No? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Sep 17 08:17:02 2019 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 9394B12085E for ; Tue, 17 Sep 2019 08:17:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4hx-VQuyuwg for ; Tue, 17 Sep 2019 08:16:58 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 EAF1412085D for ; Tue, 17 Sep 2019 08:16:57 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iAFDq-0007bs-7P for hrpc@irtf.org; Tue, 17 Sep 2019 17:16:55 +0200 To: hrpc@irtf.org References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <396911d9-63c4-09a0-77d0-a09f72689c19@cis-india.org> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <1ceabc70-3ffc-d9b5-6845-b25e00c672bb@nielstenoever.net> Date: Tue, 17 Sep 2019 17:16:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <396911d9-63c4-09a0-77d0-a09f72689c19@cis-india.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 788438cbfdc4dc137ce560360a3a99c7 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 15:17:01 -0000 On 9/17/19 4:20 PM, Gurshabad Grover wrote: > On 17/09/19 5:52 PM, avri@doria.org wrote: >> >> I too am looking for RG guidance. >> > > > Hello. > > Some thoughts on the research question and the conclusion in the draft: > > Andrew Sullivan's comments from a while ago [fn0] ring true to me. I > actually think there are three questions the draft is trying to comment on: > > (1) Do networking standards have political use and/or impact? > (2) Is there politics in the development of networking standards? > (3) "Are protocols political?" > Thanks a lot for this Gurshabad, I think this is very insightful, since it brings back the original framing. I am happy to integrate the changes proposed by Gurshabad, which I think make a lot of sense, but then I would like to hear from Eliot and Ted whether this would also help answer their questions. As said earlier, this document is not aimed to provide recommendations to the IETF, but to be a platform for further discussion. And to prevent the RG of going in circles sometimes also about things that seem 'trivially true' [0]. Best, Niels [0] https://mailarchive.ietf.org/arch/msg/hrpc/rwa2nQfNKodd8ZYQ3DqRD5kg3sU -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Tue Sep 17 08:26:52 2019 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 9698C1208B8 for ; Tue, 17 Sep 2019 08:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeeAJuHho14K for ; Tue, 17 Sep 2019 08:26:48 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 D977612088A for ; Tue, 17 Sep 2019 08:26:47 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iAFMs-00015C-8z for hrpc@irtf.org; Tue, 17 Sep 2019 17:26:45 +0200 To: "hrpc@irtf.org" References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <0d967d7c-fa05-5729-a84f-59b518e757c2@nielstenoever.net> Date: Tue, 17 Sep 2019 17:26:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: a350ae07b5350cdad28cef237d2e7179 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 15:26:50 -0000 On 9/17/19 5:02 PM, Andrew Sullivan wrote: > the > authors of this document have a strong view they wish to press, and > that they will do so There is no normative view expressed in this document whatsoever. So I am having a hard time following this argument (that btw seems borderline ad hominem). > Several of us have extremely serious > reservations about that view (for my part, I have given up on making > those arguments, because I was unsatisfied with the way they were > addressed and I just don't have the time to invest to continue to > press the point). Happy to review archival emails, as I did with previous versions, and integrate comments. Links and comments are very welcome. Best, Niels -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Tue Sep 17 08:46:06 2019 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 818C4120894 for ; Tue, 17 Sep 2019 08:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 ts321wuYTXp1 for ; Tue, 17 Sep 2019 08:46:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 E58C112087C for ; Tue, 17 Sep 2019 08:46:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46XnWm1zTmzDJv; Tue, 17 Sep 2019 17:45:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1568735156; bh=uqpUAxwvNWW2oxPG+AKBvFiyVYncRNJOjWIKhk4ZmD0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sJDRuSmIAk6blZCJ+jdrVFWI2n+K0Y58trfFs8O3i2zGlm1uZ19pjjd2MZz5dxW6R MWhMvbwB8c5DIODqZxes6MV1TxSrDYT7NIJh3MtBd3I4kD7O17uToHi/N8+bCy44LO e5a0CyPt+LwYa5YDH3neAxshYJBqHleTfZ9CCtKg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5KUErrBNW4Iv; Tue, 17 Sep 2019 17:45:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Sep 2019 17:45:52 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 78773886; Tue, 17 Sep 2019 11:45:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 78773886 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6E40D401AF03; Tue, 17 Sep 2019 11:45:51 -0400 (EDT) Date: Tue, 17 Sep 2019 11:45:51 -0400 (EDT) From: Paul Wouters To: Ted Lemon cc: Niels ten Oever , hrpc@irtf.org In-Reply-To: Message-ID: References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 15:46:05 -0000 On Tue, 17 Sep 2019, Ted Lemon wrote: > It may be that you have taken on an impossible task.  But let’s assume for a moment that you have not.  If not, then when you > are faced with a choice between readability and conformity, which do you think is the right choice to make? I think the document is small enough that this can be handled on a case to case basis. And that comments should be given regarding specific sections of text that you think are not in the expected IETF style. > While we can’t pretend that these pressures don’t exist for authors of IRTF documents, I think it’s worth actually aspiring to > produce useful stuff, and to notice when the various pressures of academia distort the writing and make it less useful. And I would say this applies to commenting or suggested change as well. Your argument of "Let's step back and see" is rather vague and questions the whole process. I think there are already enough people who agree with the process outcome of having a useful document, and we are at a point where we are looking for concrete input in improving the document. Do you have any concrete OLD / NEW text suggestions? > What is the good outcome here? "This document aims to bring about a better understanding on the political nature of standards and protocols." > Is it being heard, or is it being influential? It is a bit early to say that, as the document is still in the draft stage. The question to ask is more "can this document in the current form, positvely influence or shape future IETF developments". I think the answer is yes. If you have suggestions of making this document even better, I'd love to hear those specific suggestions. > Do we actually have something valuable to say? I would love to have this document as a reference for document authors to think about their specific IETF work impacts the global internet, and via the internet, society. That is, this document would be a great starting point for a document author to consider if their document needs a Human Rights Consideration section. Writing such a section has as goal to confirm (or perhaps improve) the protocol described causes no unintentional harm to society. In other words, the old IETF mantra of "making the internet work better" is falling short of what we should be thinking of. Engineers like to live in the ideology that "better" can be a purely technological issue, but it is not. For example, by making encryption with TLS ubiquitous, engineers feel they have only made the internet better. Yet, some remote communities that relied on proxy/caching servers to be able to have affordable internet are now seeing a prohibitively expensive internet bill since nothing can be cached anymore. Worse, some hacked up solutions now to run the browser remotely in the cloud and only show a graphical output, which can be strongly compressed and sometimes even largely cached, to the client. This is resulting in a significantly reduced security for those users, the equivalent of giving companies or nation states administrative access to your personal laptop or mobile phone which full surveilance powers. The opposite of what TLS was supposed to accomplish. With documents as RFC 1984 and RFC 7258 we have done some specific work in the areas of non-technical awareness inside the IETF. This document does a good job in providing an update to that old mantra. What I am mostly afraid of, is that the "rough concensus" that works great for technical protocol issues, is working quite poorly for IETF as an organisation because it enforces the Status Quo. This can be painfully seen in recent discussions where discussing how to be nicer to each other ends up in fanatical censorship and organisational distrust arguments. >  Who needs to hear what we have to say?   Why will it be beneficial for them to do so? I think the answer to that is clear and obvious. I understand and agree with the IETF's goal of reducing the political aspects of internet engineering as much as possible. But a line must be drawn somewhere. Just like we are seeing employees walk out of some Silican Valley companies in protest of certain technologies they are told ti develop that are used to suppress civil liberties and human rights, so does the IETF need to take on some responsibility that it is not aiding in turning internet technologies against human rights. That requires people to sometimes step out of their engineering room, and look at the world at large. And this document precisely tries to do that. Make a document that engineers will read that is slightly outside their area of expertise and comfort zone, and educate them about things they might otherwise not think about. In fact, I wonder if we should not have an item about this topic for our newcomer sessions on Sunday, where we remind the engineers that their work on internet protocols does not happen in a vacuum. Hopefully, we can soon point those newcomers (and the old guard) at the very least to this document. Paul From nobody Tue Sep 17 08:53:09 2019 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 5A4BD120106 for ; Tue, 17 Sep 2019 08:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CZS0LYdfjmx for ; Tue, 17 Sep 2019 08:53:06 -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 A9FAD120045 for ; Tue, 17 Sep 2019 08:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9163; q=dns/txt; s=iport; t=1568735585; x=1569945185; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Y5gQFaEPGpw1jdBLVmFrBgP9aRoTykc9YGgA/14FebA=; b=gDqQithurfU9o5qlFILWIDc7ezpCdZ8eED2pIE+Syk4ZdUwCHQq08sE/ kzHVNcxzkjAEG9xuCL70xKr6VFwYMhG5qJo67AWj6zg2gqYpyrXgGd2ba 8KuEj/WJRtfktYY2uILfqBBVw1mnhvwfHJVxkz4GJ9Z9ueo/MM7zvyMYE o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAABjAIFd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBFYJCIBIqhCGIfIggh0OLUogGAgcBAQEJAwE?= =?us-ascii?q?BLwEBhD8Cgx83Bg4CAwkBAQQBAQECAQUEbYU6hUoBAQEBAgEjVgULCxgqAgJ?= =?us-ascii?q?XBhODIgGBew+uV4EyhUyEdBCBNAGBUIo/gX+BOB+CTD6HTzKCJgSVdJZ7giy?= =?us-ascii?q?CLoETkUAbgjWLRSeKeaN9gxECBAYFAhWBaCKBWDMaCBsVZQGCQT6QSz4DMJB?= =?us-ascii?q?2AQE?= X-IronPort-AV: E=Sophos;i="5.64,517,1559520000"; d="asc'?scan'208,217";a="16921649" 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-SEED-SHA; 17 Sep 2019 15:53:03 +0000 Received: from [10.61.225.65] ([10.61.225.65]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x8HFr2it000875 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Sep 2019 15:53:03 GMT From: Eliot Lear Message-Id: <57F41E72-6BAC-4BD6-847E-0AA082C8BFDA@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5B1C3B1C-7690-4D37-AE03-FC6D9D88D740"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Sep 2019 17:53:01 +0200 In-Reply-To: Cc: Ted Lemon , hrpc@irtf.org, Niels ten Oever To: Paul Wouters References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.225.65, [10.61.225.65] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 15:53:09 -0000 --Apple-Mail=_5B1C3B1C-7690-4D37-AE03-FC6D9D88D740 Content-Type: multipart/alternative; boundary="Apple-Mail=_73F63CDD-843D-456E-BAD8-AA3E7B51E159" --Apple-Mail=_73F63CDD-843D-456E-BAD8-AA3E7B51E159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, > On 17 Sep 2019, at 17:45, Paul Wouters wrote: >=20 > I would love to have this document as a reference for document authors > to think about their specific IETF work impacts the global internet, = and > via the internet, society. That is, this document would be a great > starting point for a document author to consider if their document = needs > a Human Rights Consideration section. Writing such a section has as = goal > to confirm (or perhaps improve) the protocol described causes no > unintentional harm to society. I think it would help the rest of us if you could explain what actions = you would or would not have taken on any document you have written, = based on what you read in this document. By the way, if you could do = that, it would be a very good example for Niels to include. It would also help address a key concern of mine, which is that Niels = could then more clearly express the import of the work. This is not the only issue to be addressed, but it=E2=80=99s a big one. Eliot --Apple-Mail=_73F63CDD-843D-456E-BAD8-AA3E7B51E159 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Paul,

On 17 Sep 2019, at 17:45, Paul = Wouters <paul@nohats.ca> wrote:

I would love to have this = document as a reference for document authors
to think about their specific = IETF work impacts the global internet, and
via the internet, society. That is, this document would be a = great
starting = point for a document author to consider if their document = needs
a Human = Rights Consideration section. Writing such a section has as = goal
to confirm = (or perhaps improve) the protocol described causes no
unintentional harm to = society.

I think it would help the rest of us = if you could explain what actions you would or would not have taken on = any document you have written, based on what you read in this document. =  By the way, if you could do that, it would be a very good example = for Niels to include.

It would also help address a key concern of mine, which is = that Niels could then more clearly express the import of the = work.

This is = not the only issue to be addressed, but it=E2=80=99s a big = one.

Eliot

= --Apple-Mail=_73F63CDD-843D-456E-BAD8-AA3E7B51E159-- --Apple-Mail=_5B1C3B1C-7690-4D37-AE03-FC6D9D88D740 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2BAV0ACgkQh7ZrRtnS ejOJlwgA2Cxp6wm4AIed4NnXtc+YKjd+KYFXs8FJq9jzZYqR9R6RopffM++14EQN Cv8MsRlTCU/3W7G7TWckPlPvlCRNJxbBOlyI9WhDQypgSxDtTMXUUDKgpaymvEHx FHeeJbEm2WVv6jD9B8olZcLb40uXE2ozOwCbjDg1fK6PBzE1Oybxca5Cwj4RTzwX aW0+hyhdbxvnWPjk3CPjwdrkWJGAWTE0Vm0KpR9QILbC2aHgPUCK3O5JmJg6GBDv 1kP2a34u+mb+/hpuaZNA/CPN10XIzN/Ci1y/qG0A4xSXEfTZpjRUVbpWURQHPBxG DfVH0x6AXxM7XKC+aapxaGyjTstMAg== =oKic -----END PGP SIGNATURE----- --Apple-Mail=_5B1C3B1C-7690-4D37-AE03-FC6D9D88D740-- From nobody Tue Sep 17 09:02:35 2019 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 DF775120841 for ; Tue, 17 Sep 2019 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 cdD2u88NXomY for ; Tue, 17 Sep 2019 09:02:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7761112011F for ; Tue, 17 Sep 2019 09:02:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46Xntr5Ls2zDJv; Tue, 17 Sep 2019 18:02:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1568736148; bh=nMSoXwgo5WGfpkNiL58ginMHu50dz4H1p6c+Ys4qAZk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jF+fmXxkWOAXKKBSkfeDT094SaWnDwtSgvYVFi2WvWcCPoQtqBeczfOilel5rx4Gm GCfS+m2Zcy1qluwf068gejztM173tez51cWTjCdXqi6t8KNGriIcCzNcsiD8q9LfQf YZXa+5jn+JI+sCL1jT6241LJoc+B+QDO/7yMrnPQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 27EDsL89OLUn; Tue, 17 Sep 2019 18:02:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Sep 2019 18:02:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 31EE3886; Tue, 17 Sep 2019 12:02:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 31EE3886 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 29578406A92B; Tue, 17 Sep 2019 12:02:25 -0400 (EDT) Date: Tue, 17 Sep 2019 12:02:25 -0400 (EDT) From: Paul Wouters To: Ted Lemon cc: Niels ten Oever , hrpc@irtf.org In-Reply-To: Message-ID: References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-7 Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 16:02:34 -0000 On Tue, 17 Sep 2019, Ted Lemon wrote: > As for the thicket of citations in the introduction, you have, at minimum, a usability problem here. Dont ask me to read past the thicket of citations. Figure out a way to present these citations so that they are usable. Your job as an editor is to produce a useful document; when you get feedback that makes the document less useful, you have to figure out a way to act on that feedback that is beneficial: its not enough to take the feedback in its original form and apply it, knowing that its making the document worse. I agree this section is (too) hard to read and could be improved. Note that this issue came up seperately recently in the discussion regarding the draft-klensin-idna-rfc5891bis document, and there might be (or soon will be) a way to cite xref's without the explicit [blue link block]. So this is a minor issue that can be resolved to satisfy all parties. Paul From nobody Tue Sep 17 09:38:36 2019 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 2275812088F for ; Tue, 17 Sep 2019 09:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ok7d1ylg-aJ for ; Tue, 17 Sep 2019 09:38:31 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89BC12086E for ; Tue, 17 Sep 2019 09:38:31 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 117728368EF3 for ; Tue, 17 Sep 2019 16:38:30 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:41:152:355:379:599:854:973:988:989:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1513:1515:1516:1518:1521:1535:1542:1593:1594:1711:1730:1747:1777:1792:2194:2198:2199:2200:2393:2553:2559:2562:2692:2693:2741:2898:2917:3138:3139:3140:3141:3142:3355:3421:3865:3866:3867:3868:3870:3871:3872:3874:4118:4184:4250:4361:4362:4470:5007:6117:6119:7652:7903:9036:9108:10004:10400:10848:11232:11658:11914:12109:12114:12297:12663:12740:12895:13071:13130:13231:14096:14097:14180:14721:21060:21063:21080:21324:21433:21611:21627:21740:21790:21881:21939:30054:30070:30090:30091, 0, RBL:72.221.122.28:@doria.org:.lbl8.mailshell.net-62.14.0.100 64.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: lead32_2d09752312f04 X-Filterd-Recvd-Size: 7387 Received: from [192.168.0.6] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf07.hostedemail.com (Postfix) with ESMTPA for ; Tue, 17 Sep 2019 16:38:29 +0000 (UTC) To: hrpc@irtf.org References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> From: avri@doria.org Autocrypt: addr=avri@doria.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemi yf8Pp8BdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K 1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV 5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOG B8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO7 6/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanx Fk4vCRfjfl8wt27n9xt27ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2HOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmEqG/rIj0w3XfV3bQsDBUU dH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrMMqO7SYUTB6Tx8vIoqmy/ T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq3lrUp2mRzDXBWZLhPVUq x6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006QeZQKfAZinaq3ICEyimWZ bLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wjzrwwsxypxUiEac/7bVwg Ev5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemiyf8Pp8BdIAQZAQIABgUC UleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K1oIc+pxGmr7RUfpOcB63 +1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV5mPBI7kWYNbD99278ZtY TO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOGB8par+/2zKx1MwrZFCnT tlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO76/QFmerwwN89qLAh1pAN oJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanxFk4vCRfjfl8wt27n9xt2 7ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWaSy7OQDKa1N838tTsRVLO MpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBslZea+G2UUV2WSXZPiTci 8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+GjqFR3R2AMLhwK/Nu9uw +cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z6yQ42xcvoUbQ6lLXW0fj NNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPgDoZoktZXmyHIh2E= Message-ID: Date: Tue, 17 Sep 2019 12:38:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Antivirus: Avast (VPS 190917-6, 09/17/2019), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 16:38:34 -0000 Hi, To explain why I am looking for rough consensus. As far as I am concerned we can publish work in the IRTF stream or outside as papers, books, conference presentations &c.=C2=A0 In trying to= run this group on grounds that are similarto IETF WGs, I have always taken this hybrid approach.=C2=A0 But when doing the work in the IRTF stream, I= try to adhere to the IETF type of procedures within the constraints defined in the IRTF track.=C2=A0 While we could have decided to do a closed group= of distinguished scholars, engineers and activists with an authoritative chair, or some other approach, at the beginning we decided on this approach for the group. This is also why I can be such a stubborn pain when I ask whether someone really wants to turn their document over to the RG.=C2=A0 If this= were a personal draft, I would look at it differently.=C2=A0 I think we c= ould support personal RFCs that present an individual argument. I would still look for it to well formed and cover all the issues before sending it on, but would not look for rough consensus. I think we can reach rough consensus, even when we disagree, without watering the content down to pabulum.=C2=A0 It is harder and, at least to= my mind, is part of the exercise we are engaged in. In a RG document, we should be able to discuss all relevant sides of the issue, especially if our purpose is to inform. thanks avri On 17-Sep-19 11:02, Andrew Sullivan wrote: > Hi, > > Speaking as usual only for myself (but I am employed by the Internet > Society). > > On Tue, Sep 17, 2019 at 04:23:24PM +0200, Eliot Lear wrote: >> And this boils down a bit to =E2=80=9CWhose document is it anyway?=E2= =80=9D RGs have some latitude on this, by the way: this document does no= t need to be a consensus view. But if it is, then our differences should= be explored. >> > I simply don't understand why that self-imposed rule is being followed > in this case anyway. It has been long clear, in my opinion, that the > authors of this document have a strong view they wish to press, and > that they will do so. Several of us have extremely serious > reservations about that view (for my part, I have given up on making > those arguments, because I was unsatisfied with the way they were > addressed and I just don't have the time to invest to continue to > press the point). In such an environment, a consensus document will > either be too watery to be interesting or else will not really > represent consensus. The solution to such a dilemma is surely to > refuse the conditions that make it possible. No? > > Best regards, > > A > From nobody Tue Sep 17 09:52:10 2019 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 D15F3120108 for ; Tue, 17 Sep 2019 09:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk2Ln7tdwWmm for ; Tue, 17 Sep 2019 09:52:06 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3943120112 for ; Tue, 17 Sep 2019 09:52:06 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id u40so5216129qth.11 for ; Tue, 17 Sep 2019 09:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NJPqln1Fv7MyYMfZ0FWlZ+SDnRat6ER6Ft+2OceHDQY=; b=NN20LGFXnWPPprMMTSCGwEDS+7DVfBZE43qvzGzMSxoH3F56S3JSyefPx+WoTCsE7x OL3m3bWDghCIG/SReC0kotyeKqGs15PrKwYavx2QJBjAqRLzIUh8eUBtOfPLnGz2UrGe cDJ4EHegL1ai0DkQ33ZEBuitYs588wavr53aRRMEiRXWTv93L+OB3pPRM1BA4/BWX7hm XMqf2CmB8DPbMUlwiaRW5gJAvaYP0fVmwQK7bAUFP2VojjivmlYAt6U/0+v8Y6Zcr+8Q t1yLbRV1Lzzbj+6Phg+0atpiMQNgYhCQ1XZ4JRuJqVSqvJqYcHOrZRJ4USbtgesYsFbU P7uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NJPqln1Fv7MyYMfZ0FWlZ+SDnRat6ER6Ft+2OceHDQY=; b=cKvJTZiqfaPqbdHA2m5dZgsEwE/I1G35jn55zLtTrkZ44eoo524iTkVRgLwgNQ3f8r ftcwaCuHaYgIQVOcKRJ6pbpeFPAGX1mj5E8BCcwhH/ilR9fQLLmEsnIW2DjZmwcWlzqW zy2Gf+m1B8BLMzdlt/PgKyl+q6ldTfCqF+4gl963M36A0B1llsuuGbnYXCLBOZEZoH8J 07FfYDuB1bZZcYfINEcFocHiAAdp5IY0xUkxyzhl/AtlP0/dvpeqFCTO862vtrDSsoYE sApLt7cjYfRQw+AmSbkK6BhZ+Hvz2pxYDWLSucfHWxgFU2C8g2KzYXCfCLxtnIG6tNVC oTbg== X-Gm-Message-State: APjAAAU9qKAAUWTadXb9/y410bJs8EmyT8+GJkIa64ODr1SxKvFo1mhC vU1I+CvuqqtUi4UWCUVeYQLzUw== X-Google-Smtp-Source: APXvYqxXG6UIOmllkL/aYp83GAEKHfqf+mt9oNERZ7/SaL/dY/k5kEoKHPNZPtM7lk5XpsOvLmXTtQ== X-Received: by 2002:ac8:5216:: with SMTP id r22mr4695301qtn.281.1568739125585; Tue, 17 Sep 2019 09:52:05 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id b26sm1450932qkl.43.2019.09.17.09.52.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 09:52:05 -0700 (PDT) From: Ted Lemon Message-Id: <9EA8EA59-2A05-4D91-AECE-1D42F004530B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7585A159-34D0-495A-B985-AA3F2AA9A9A1" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) Date: Tue, 17 Sep 2019 12:52:03 -0400 In-Reply-To: Cc: Niels ten Oever , hrpc@irtf.org To: Paul Wouters References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 16:52:09 -0000 --Apple-Mail=_7585A159-34D0-495A-B985-AA3F2AA9A9A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 17, 2019, at 11:45 AM, Paul Wouters wrote: >> What is the good outcome here? >=20 > "This document aims to bring about a better understanding on the = political nature of standards and protocols.=E2=80=9D To whom? >> Is it being heard, or is it being influential? >=20 > It is a bit early to say that, as the document is still in the draft > stage. The question to ask is more "can this document in the current > form, positvely influence or shape future IETF developments". I think > the answer is yes. If you have suggestions of making this document > even better, I'd love to hear those specific suggestions. That=E2=80=99s the question I was asking. Sorry for being unclear. > I would love to have this document as a reference for document authors > to think about their specific IETF work impacts the global internet, = and > via the internet, society. That is, this document would be a great > starting point for a document author to consider if their document = needs > a Human Rights Consideration section. Writing such a section has as = goal > to confirm (or perhaps improve) the protocol described causes no > unintentional harm to society. This was my understanding as well. I think it=E2=80=99s currently not = going to succeed at meeting that need. > Yet, some remote communities > that relied on proxy/caching servers to be able to have affordable > internet are now seeing a prohibitively expensive internet bill since > nothing can be cached anymore. Worse, some hacked up solutions now to > run the browser remotely in the cloud and only show a graphical = output, > which can be strongly compressed and sometimes even largely cached, > to the client. This is resulting in a significantly reduced security > for those users, the equivalent of giving companies or nation states > administrative access to your personal laptop or mobile phone which > full surveilance powers. The opposite of what TLS was supposed to > accomplish. These are great examples. I wonder if this document as it is at present = could have helped to avoid this problem. I think the answer is no. It = would be fantastic if this document could be written in such a way that = it could help to avoid problems of this type. The bottom line is that I agree completely with all the aspirations that = you have stated. I just don=E2=80=99t see how this document helps to = bring us closer to achieving them. The canonical answer to that is =E2=80=9Csend text.=E2=80=9D However, = when I have commented in the past, my comments have seemed not to be = heard. If I were to send text, it would almost be a complete rewrite. = I=E2=80=99m certainly not willing to undertake that sort of effort = without some notion that it would be useful. --Apple-Mail=_7585A159-34D0-495A-B985-AA3F2AA9A9A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 17, 2019, at 11:45 AM, Paul Wouters <paul@nohats.ca> = wrote:
What = is the good outcome here?

"This = document aims to bring about a better understanding on the political = nature of standards and = protocols.=E2=80=9D

To whom?

Is it being heard, or is it being = influential?

It is a bit early to say that, as the document is still in = the draft
stage. The question to = ask is more "can this document in the current
form, positvely = influence or shape future IETF developments". I think
the answer is yes. If = you have suggestions of making this document
even better, I'd love = to hear those specific suggestions.
That=E2=80=99s the question I was asking.  Sorry = for being unclear.

I would love to have = this document as a reference for document authors
to think about their = specific IETF work impacts the global internet, and
via the internet, = society. That is, this document would be a great
starting point for a = document author to consider if their document needs
a Human Rights = Consideration section. Writing such a section has as goal
to confirm (or perhaps = improve) the protocol described causes no
unintentional harm to society.

This was my understanding as well. =  I think it=E2=80=99s currently not going to succeed at meeting = that need.

Yet, some remote = communities
that = relied on proxy/caching servers to be able to have affordable
internet are now seeing = a prohibitively expensive internet bill since
nothing can be cached = anymore. Worse, some hacked up solutions now to
run the browser = remotely in the cloud and only show a graphical output,
which can be strongly = compressed and sometimes even largely cached,
to the client. This is = resulting in a significantly reduced security
for those users, the = equivalent of giving companies or nation states
administrative access = to your personal laptop or mobile phone which
full surveilance = powers. The opposite of what TLS was supposed to
accomplish.

These are great examples.  I wonder if this document as = it is at present could have helped to avoid this problem.  I think = the answer is no.  It would be fantastic if this document could be = written in such a way that it could help to avoid problems of this = type.

The = bottom line is that I agree completely with all the aspirations that you = have stated.  I just don=E2=80=99t see how this document helps to = bring us closer to achieving them.

The canonical = answer to that is =E2=80=9Csend text.=E2=80=9D  However, when I = have commented in the past, my comments have seemed not to be heard. =  If I were to send text, it would almost be a complete rewrite. =  I=E2=80=99m certainly not willing to undertake that sort of effort = without some notion that it would be useful.

= --Apple-Mail=_7585A159-34D0-495A-B985-AA3F2AA9A9A1-- From nobody Tue Sep 17 10:04:49 2019 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 614561209DD for ; Tue, 17 Sep 2019 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwFUdr05ne_y for ; Tue, 17 Sep 2019 10:04:45 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A749B1209FB for ; Tue, 17 Sep 2019 10:04:45 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id 4so2316717pgm.12 for ; Tue, 17 Sep 2019 10:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=jYGXgBHFC3l0Ibwt1H0LKlx2H9V2KkVsp5x3iiO0XKA=; b=ADniEaU1KGQ6Hk8AgQgteh5weXVmfHPIuapgU4i8HNQogx5QE0428kZghiRMovRx8W WdJxmSJrHHNh0vnQHXuJor0+Gvnqp+pwbkwBGEPZG9VV1+q0dWoyaA/Jme3JuKiPv0+0 kUoy3L0xlk39qG2xcJVCRvqwypcV/WmlUG6Le87Q+CAd+UumfBODo2n3q96+AT+wAqlT U1tZrWXhHDronl6++2IU6MzfCPULKsLfnGTfRMLVwfmzmdNxfVbgB3apomosAM97jS2k eFU76C6iQtgJoKD7xCIwTLj/VB57XCuJjM/TXK48Zq3qBjKWCpSwyC74Dp+qqRAIHH5r c1JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=jYGXgBHFC3l0Ibwt1H0LKlx2H9V2KkVsp5x3iiO0XKA=; b=PjLPbLVA015S6A6jvDXEiqjXeez2jNdpYO1vPW8Y8dA5buOQxpt6we+8R3TQVjT2OL Z2Q25XRQicPnLW4J56wy/jDPfEhqvY8mv8QlQ3PDYQjVcwaDOXwwq0MS8HKKL++YNOm8 NPEYM3i53bekb3ls4YfPaDm5/qRxtwEmcws25lJ+wg/MfNJ41fCjb10kSXdpR2yaGiFI /C+nqmDNCRJAlCd8u8RPIxr61iWJsqjDJ9J29LljVGSAEZ6x5jtCZWol5zIuSzr9cSdC qI9rzsGM0hvLmopYp0laHiBgVGCjTDvauwGpov4Z549o0RyV4iP3PF2WT77DPS58qka1 a/bg== X-Gm-Message-State: APjAAAVJFd3sOgmS4i4iX9rZOIA5bPOBQ1GXr7z4B2Fwd1GF+qLREQdE UPyZNL/urebxwLTaztpR9l8aJv/GQW1O X-Google-Smtp-Source: APXvYqxpNixa1kgqxLl7eqydeyGNzi4qVHUEx/+2tPlVtRSnPhfqJe8eIOTZSStUYOVnkbQlPC3Udg== X-Received: by 2002:a17:90a:8d0c:: with SMTP id c12mr5999740pjo.119.1568739884516; Tue, 17 Sep 2019 10:04:44 -0700 (PDT) Received: from aspen.local (63-140-65-24.dynamic.lte.acsalaska.net. [63.140.65.24]) by smtp.gmail.com with ESMTPSA id c8sm3757608pfi.117.2019.09.17.10.04.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 10:04:43 -0700 (PDT) To: hrpc@irtf.org References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: Date: Tue, 17 Sep 2019 09:04:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wBfvTKeiYMLUYEoJVAIzgoJCkwJKbaMtA" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 17:04:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wBfvTKeiYMLUYEoJVAIzgoJCkwJKbaMtA Content-Type: multipart/mixed; boundary="ub4DWzVVDRBBsPUzmEKSGgz2ZVEamrhOu"; protected-headers="v1" From: Melinda Shore To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> In-Reply-To: --ub4DWzVVDRBBsPUzmEKSGgz2ZVEamrhOu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/19 8:38 AM, avri@doria.org wrote: > I think we can reach rough consensus, even when we disagree, without > watering the content down to pabulum.=C2=A0 It is harder and, at least = to my > mind, is part of the exercise we are engaged in. In a RG document, we > should be able to discuss all relevant sides of the issue, especially i= f > our purpose is to inform. I suppose this is another opportunity to remind people to distinguish between disagreements that they can live with and disagreements they cannot. Also, sometimes (often, actually, I think) it's necessary to document points of view we disagree with, and presenting those points of view is not the same as arguing for them. However, I think it's worth noting that if this is published as an RFC it's likely to be widely misconstrued as representing the IETF view and it's probably a good idea to be sensitive to that. Also, as noted elsewhere, IRTF documents do not need to represent RG consensus but I think it's a good idea if there's at least RG agreement that the contents are correct. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --ub4DWzVVDRBBsPUzmEKSGgz2ZVEamrhOu-- --wBfvTKeiYMLUYEoJVAIzgoJCkwJKbaMtA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl2BEikACgkQ37iRcpp2 24/CIQ//bLHRwk5J16Taoe6vciwHLB+FNWGR66mYebQlTS7lOANdWKqc6zrZiZFb /bs9sfHOHJquWmLxqqGDM7j83V7ldmIIbO2y16eSdQs3BcocIGKkivsDgzpyWkNY DM4VqkSkxWrrbZs4qxcVe1SOeH1f0b/eomyecgyoUnfDZbj868rVxkLi+Tmnju+v jm5ku5XNZ9k+1w1BlP6XLinLlyX2MZS2iymhsJ1fMBBTA6doEjQ3dnrEBrVR/USD +Iv8np5Hs2kgGc2gyNwTOj9TTF+N0G5dlNpInExL/NqezNUtcsfoREK5qYDki81B XXyqVtCqkXgi4Mq6nxz+WRHLd0yAuosXZ319zuTRdGYMLmf9AMswj4lS8npA1ZKL dAJTqeooAA3VgD2FcEbHzluV5RVvUr8ZTcpADi/ozHP884JPWwV761eDKO9x1UoU sqFPaDYCJvZu4dnH7dldlzMP+V0HyDltrFDpq3q006JFhC8o4AQlwdWLmVDFSBvA B49Y0Ig2c2L3d9PH6wmwCpLUu3hFP0O2/JHLxa2BA6Z4wpkFQYZxQicSEfv1lQih Tnoo7u8wdTadXoIAQ0qZBJg4pD1OBMTlBQtmXteZaHiZYkFUoprP9MbRNYXXRXAO PP0XaSfsbGor90Q6dJbFsSmuITipzIrWNO3KAR6j/AbH//8aWM0= =pUXr -----END PGP SIGNATURE----- --wBfvTKeiYMLUYEoJVAIzgoJCkwJKbaMtA-- From nobody Tue Sep 17 12:41:55 2019 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 63F771208B5 for ; Tue, 17 Sep 2019 12:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 lA8I9w0J7P-L for ; Tue, 17 Sep 2019 12:41:52 -0700 (PDT) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EBF120046 for ; Tue, 17 Sep 2019 12:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1568749311; bh=O75k59vAwyW5e5qHxYwGpDBlAATLGQO+ruiYO5Y6h40=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=n11ihzRAk5AnqID5Irs1rB1hlD6D41U5+42ruA05v8TnMSlJ2LPNE73lqbsfd/52QEVYv09KlM8gT3kE9zzhfZLV6EAlMuNLLgLdLPyTgTlOqRbxWcdMLblGNcmZxXtAyQyH4j0yEXJfnPFgSFBCn5pvb2w+JYJ/D73qtuCLz/k+GeuEjdvmXBcHKtBDNP4X5UtzPH9DU7XuDQz5wP8s9n8P/a+NKgmaFqYo2U0uJfRzKMW5qAL84aBqbcl+2hsyMQsvZBzR1G2++uYrP/YNUeFFMZuNb7O20F5/9PDebaHVMP1ISR0Vu3LRkQs3kOjcDnAPRlzLmkS1d1EPuIvwcw== X-YMail-OSG: ENo4TK8VM1mypO1jqQ13iBLNJBtMBov0GpOn5VSuhI.hxpWlTGd8Fu15k1J080x WSnz0mxwZ9hJI3hPQx4pNiyiFjQpHwSCIUb6LJtsA2VCCI9mcp2oQanhGvoAdIlq2sihRcIRjz16 0UEXEnuc3GyMChWJH4o8K2G7hAfdcWiD.eF1KR6MzsXGEaQMNEL3_VlTqWLFobvC.II7ABRTYrxg eLZyTFWe369pxyFNp97f0ZdxhHnCFGTXli0_yJWt4FsBNlOSBH.ztai5H_9P2ytz_t0ILtCU60Qk TX0EO15mHestEuA5SOTwDV9IUxsHpGZNgWS41XO4JW1mDmX3vaqRpFlTu5GJ5W2g7C8MGbLTvijC 3BJQ46.FEEVqViFLle3FjXXvu8DMh47DCmEETv.bbCzS4rbqLrjFrn5ihgQPypxjk92bOYo_h1TI 1GNsca2koIfOZen7sA7surW9p0QkeHQ3TD6J5S626_23dDs2cgHZ6C6E3mw7FlvaMDtYlcUY3a7Q xJgV_a8ckAPnx_ToPcHvfeC8zn4CZKkXOxeAOeRtA.AyowPJ7jjSSU1qY_2cDwKkNE0D8UWoHbCy 3fQdxA_7i0h70qBDHnBxflrbV25uHWRWSR7wIPb9S2TpSOJi7grDe28_tbgFpoa_xv0wUJBBXRul VE3A0.ZOFfX1ffmNIObPlxuTJW9ZDlcKseIkIfjG77Ps3OFP8InB0ZlWGB59K_6DgYdv3fcjK_DZ E_gdcVod55pyoxTDRV4Bt82OHqmJn68l3xLyp40VH343K9cfhrLEb5elCJHliwFr9msjpCFfKjNJ Wh97dF9IVoVZi5uOZd5anBOXZ4CrMuANVV6NI9DIGE7kzwv8bOCEdwehBrSSWd3D6lwlafr8nRS7 .s8IoD8UiVC7UCjhxMLwXu40inMd0twxQ.RONS65vuCUWqD3u6_KNW1fFcJ7V1Lf7gwbW7Em4Q5w AzkE93Iykc6gGh_HNelVk0o.e2bPt3QlqvHcKbgwcUGjXVLlqptfBOM250OHA5SKVWCq.UZRh7t8 DrB6chwtnZrXq_qTGDvOnzE70jdkAhbRtzaEGvrxLcv7wfetpNQJeNWYolQKNOQtw96pL_gT3aIu oxb7GqvXJ6MOCnyAfLAP01yTiyDkVe7BIqe1_ItPn8sGxjZLbL44bC0CxirrJuZgqeFeuZSFZ3cm 2JMmKuQ21ilKe_xw36GzvKVdWhzJm8uuNcdXXmNlnJDzsdEHOwJdNR7o7ig6koYYRpOASOpp3_.2 Q8x22Yj9ix58GWkuJ0Q7bp5uCGRfjEqGoJxssUQ2MQqs8MrdhJjY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Tue, 17 Sep 2019 19:41:51 +0000 Date: Tue, 17 Sep 2019 19:41:46 +0000 (UTC) From: Mark Perkins To: hrpc@irtf.org Message-ID: <1138709738.5923109.1568749306948@mail.yahoo.com> In-Reply-To: References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5923108_1521602573.1568749306947" X-Mailer: WebService/1.1.14303 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 19:41:54 -0000 ------=_Part_5923108_1521602573.1568749306947 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I disagree that these are real problems - more like things that need corre= ction rather than 'show stoppers'. The difference between standards and protocols is implicit in section 4.5, = but I agree this needs to be made explicit in the vocabulary section (which= is far too short). To note, this is not specific to this document, but is = unfortunately widespread leading to the conflation of the two - as mentione= d by Eliot. So, vocabulary entries for protocol; standard; internet protocol; internet = standard; ietf protocol; ietf standard. The lack of WTO citation is not critical, just something that needs to be r= ecitified (I have no argument with the WTO paragraph, it is fairly anodine)= . Lack of citations need to be indicated, and provided to the author(s) whe= n aware. The draft is full of examples - where precisely do people think they are mi= ssing? This question of citations and examples is also linked to the question of '= readability', by which people here seem to mean creating the wish to read f= urther - rather than legibility. BUT, given the subject matter, I think the= supporting citations and examples are essential 'somewhere' in the documen= t, even if in a section of their own (to increase the documents overall 're= adability') I agree that the importance of the research question needs explaining, alth= ough Neils states it clearly outside the document: 'And to prevent the RG o= f going in circles sometimes also about things that seem 'trivially true' ' Personally, I think that many 'techies' try to pretend that their work is '= not political', whereas it is clear from the document that this is not the = case. Why is this important? Human rights ARE political, and internet proto= col & standard processes, especially where they impact on human rights (esp= ecially 'fundamental' human rights) ARE political. This means that aside fr= om 'Security considerations' for protocols, there are other, 'political', '= human rights' considerations that should be made clear, and not avoided. Pa= ul Wouters puts this more diplomatically than I do. Mark Perkins On Wednesday, September 18, 2019, 4:04:57 AM GMT+11, Melinda Shore wrote: =20 =20 On 9/17/19 8:38 AM, avri@doria.org wrote: > I think we can reach rough consensus, even when we disagree, without > watering the content down to pabulum.=C2=A0 It is harder and, at least to= my > mind, is part of the exercise we are engaged in. In a RG document, we > should be able to discuss all relevant sides of the issue, especially if > our purpose is to inform. I suppose this is another opportunity to remind people to distinguish between disagreements that they can live with and disagreements they cannot.=C2=A0 Also, sometimes (often, actually, I think) it's necessary to document points of view we disagree with, and presenting those points of view is not the same as arguing for them.=C2=A0 However, I think it's worth noting that if this is published as an RFC it's likely to be widely misconstrued as representing the IETF view and it's probably a good idea to be sensitive to that. Also, as noted elsewhere, IRTF documents do not need to represent RG consensus but I think it's a good idea if there's at least RG agreement that the contents are correct. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_5923108_1521602573.1568749306947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I disagree that these a= re real problems - more like things that need correction rather than 'show = stoppers'.

The difference between standards and protocols is implici= t in section 4.5, but I agree this needs to be made explicit in the vocabul= ary section (which is far too short). To note, this is not specific to this= document, but is unfortunately widespread leading to the conflation of the= two - as mentioned by Eliot.

So, vocabulary entries for protocol; s= tandard; internet protocol; internet standard; ietf protocol; ietf standard= .

The lack of WTO citation is not critical, just something that need= s to be recitified (I have no argument with the WTO paragraph, it is fairly= anodine). Lack of citations need to be indicated, and provided to the auth= or(s) when aware.

The draft is full of examples - where precisely do= people think they are missing?

This question of citations and examp= les is also linked to the question of 'readability', by which people here s= eem to mean creating the wish to read further - rather than legibility. BUT= , given the subject matter, I think the supporting citations and examples a= re essential 'somewhere' in the document, even if in a section of their own= (to increase the documents overall 'readability')

I agree that the = importance of the research question needs explaining, although Neils states= it clearly outside the document: 'And to prevent the RG of going in circle= s sometimes also about things that seem 'trivially true' '

Personall= y, I think that many 'techies' try to pretend that their work is 'not polit= ical', whereas it is clear from the document that this is not the case. Why= is this important? Human rights ARE political, and internet protocol &= standard processes, especially where they impact on human rights (especial= ly 'fundamental' human rights) ARE political. This means that aside from 'S= ecurity considerations' for protocols, there are other, 'political', 'human= rights' considerations that should be made clear, and not avoided. Paul Wo= uters puts this more diplomatically than I do.

Mark Perkins

=20
=20
On Wednesday, September 18, 2019, 4:04:57 AM GMT+11, Me= linda Shore <melinda.shore@nomountain.net> wrote:


On 9/17/19 8:38 AM, avri@dori= a.org wrote:

> I think we can reach rough consensus, even when we disagree, wi= thout
> watering the content down to pabulum.  It= is harder and, at least to my
> mind, is part of the = exercise we are engaged in. In a RG document, we
> sho= uld be able to discuss all relevant sides of the issue, especially if
> our purpose is to inform.


I suppose this is another opportunity to remind people to
distinguish between disagreements that they can live with and<= br clear=3D"none">disagreements they cannot.  Also, sometimes (often, = actually, I
think) it's necessary to document points of v= iew we disagree
with, and presenting those points of view= is not the same as
arguing for them.  However, I th= ink it's worth noting that if
this is published as an RFC= it's likely to be widely misconstrued
as representing th= e IETF view and it's probably a good idea to be
sensitive= to that.

Also, as noted elsewhere, IR= TF documents do not need to represent
RG consensus but I = think it's a good idea if there's at least RG
agreement t= hat the contents are correct.

Melinda<= br clear=3D"none">
--
Melinda Shoremelinda.shore@nomountai= n.net

Software longa, hardware bre= vis

=
______________________= _________________________
hrpc mailing list
hrpc@irtf.org
https://www.irt= f.org/mailman/listinfo/hrpc
------=_Part_5923108_1521602573.1568749306947-- From nobody Tue Sep 17 15:06:12 2019 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 EB1F11208DC for ; Tue, 17 Sep 2019 15:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=derechosdigitales.org header.b=F91Mg6gF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xay5Z5ut 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 yilw0W2RdCpR for ; Tue, 17 Sep 2019 15:06:08 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C50612011A for ; Tue, 17 Sep 2019 15:06:08 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B712B520 for ; Tue, 17 Sep 2019 18:06:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 17 Sep 2019 18:06:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= derechosdigitales.org; h=to:references:from:subject:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; s=fm3; bh=zexyNCq17EYYWwDD2/X0dHRwj2 eXGTFBSKBkkOKdeI8=; b=F91Mg6gF69MWudJj3/6ATqOG+doregjYe5vJKAFdbG 6XD2ZyjpBSjQ5onr8Zp9r0aaUJZl9wsQcSannE4BKG7c8YgRFfuQd18zvh/76Qfk iu2zjy/VinLrGDsCCZnguPXmTiu5n602RWqCJmiLluCDkFuwM6cBxCB+P9D1z7Au 2WDfyIRYQgqwRKOTyRLptE+UcRjrpFq6Vrx6WrjojgHGKIqfNGx2lAPhc6v/uZLs iKJVgMIpjpDy3+Xdfujx052YUC3LYVjSxZJ5rzxSrFTUiSy3brGpy4dMNuJcB3lp 7ocnm6pvPkYOE9/KsrsIdrgBBUTAzBBScQH1ksVY1AkQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zexyNCq17EYYWwDD2/X0dHRwj2eXGTFBSKBkkOKde I8=; b=Xay5Z5ut+YI4zJMGKOPqCougHihRPdfAnKPoEHF7LN/tzDKhT0r2BU++G w7sjj8WCCTczMMKxPYHxTzlSITkDt94QO+AbK1KntPcO2RgYDSsscrr9h32EbdLH y4FYwmdWIVi28SNTt/rUpEDU508pdBlD4VDW9hzep8eri4dSssF+3W4+h2uuroep AYioqS1T6MbXC5UChewILkztd3LWDc9oIh11iv0bYrX+VHDL3RnDfa7a3pgTgIID yUqKvmQKa5EQA3Vbi+KHm4xhdfHwwBIgb1nQy+R99rLouIv7r1l+PjUjY/nTj5lC 227NzIPAiAFeJ7WNQWqA+QXAiSrdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejgddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepvfhfhffukffffgggjggtgfesthekre dttdefjeenucfhrhhomheplfhulhhirghnrgcuifhuvghrrhgruceojhhulhhirghnrges uggvrhgvtghhohhsughighhithgrlhgvshdrohhrgheqnecukfhppeduiedvrddvgeejrd ejfedrudelfeenucfrrghrrghmpehmrghilhhfrhhomhepjhhulhhirghnrgesuggvrhgv tghhohhsughighhithgrlhgvshdrohhrghenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [10.41.0.177] (testbed-users.calyx.net [162.247.73.193]) by mail.messagingengine.com (Postfix) with ESMTPA id B1C9180059 for ; Tue, 17 Sep 2019 18:06:06 -0400 (EDT) To: hrpc@irtf.org References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> <1138709738.5923109.1568749306948@mail.yahoo.com> From: Juliana Guerra Openpgp: preference=signencrypt Autocrypt: addr=juliana@derechosdigitales.org; prefer-encrypt=mutual; keydata= mQINBFfRsLcBEACuW2xcKhPTcaSD9ZnXQLQmJFiQR8/NLlfbEc1+Cmwd1neMoXkjhM0AtTlz 1zlyTPC08zl4gBhZjDnuMXROhWK02MYKmotAgJuAK1XcUv0ay67MddvAspJCPqkiJiwFxWsN h5x4rx+Ib5+gIGKQyB27PU/fM2G2uJajnjl0UY54QxCTt2YqomH5uYMH6rqqxKs6XVQbptDP 1EXOvrkn0bCcIlzXAKwFQuByXrMWgNG5yPztyYMVvn68/R9HSIyCWpvLCqcNTp+AmNCs2Qmp 4c/Be4ZFlZ9tyEUz9CGDZD+Scm/mqgUBb6q/T4h2LRfDLmiLqp0mERC5tDJCBeOIHb/x0jW5 KOctl3lz63MsGC4JeoR9iT8sMQEx+sWZEpJdXXyuBiK0Q1tWPUruHAmv4oPXijNzx/+xs7/d 3uoft8RFxjTS1v8YUSb2yJFCJatVl/QZKSC3zqXJVWFNr1M64IJAC9M3AHFNVVOq/+3Llju7 PjQeYm5MuwMLqXrViiNgvo/sWohARGU8eJKGsnJz/Y9oXk2RG/Uqehefo9VodDpRn6B3XZko F1of3HyInrVDxDjU1r3qJ5Amd1np9OQpX3lfHZjYTUrHg7eWBUM280gH0UBfEWZqgV9m13tv IiG/aBo59D+dm9p+1YTknP4G6LCn9e5jex6xlftkbqyE90okHwARAQABtCdqdWxpYW5hIDxq dWxpYW5hQGRlcmVjaG9zZGlnaXRhbGVzLm9yZz6JAlcEEwEIAEECGwEFCwkIBwIGFQgJCgsC BBYCAwECHgECF4ACGQEWIQSp/zHnpPrlOCiIMjpGVA/C9RoCAAUCW8H1twUJBdF4gAAKCRBG VA/C9RoCAKVrD/wPBa1tM2eYvKD4q/hn+tG7tylmp+IzSibJ3g1HaXcgkvk3yMb28C0gGzmA M2KDLyaUHX1uZIFC6XsWz2PA5gag5p73b8l1xokG5Sqt53eJrzR4b5TQaWPlp9JGFakVH55Q 9Xbu5QG1OEtZtUmJ3FDyWa41ADZ+KxMqQtvY6qDMBudkvSt/GbR+36v7Uw/8SlyHr0sd6cWb LdMq8+MNGjLISlxuhlQPZ54dSKgOWQoD1pYQ9kJWlCV7LVlqHwdKeF9EgkircH6dvoWClxoF f7NJJuLUVPergjHFFsLPS6WpkY0vxLv6u1q5fyHSUME20HXgDjhCwBEaaZNZknDJqUgS++50 S2uED71QmVkPxluV6QrbuiPVuOig+Th0/JBsDxGYJltVmeiyBT2OiLPc2L+Bx70OPoxt8Mao nafl4CxH4UOjfCB98tv6UurXxNoKzcIri3H02zjGCtGuaUxcHmPpWO2cWvmxSM7tcEvPXcbx 3ntFTK6rqMTm1roC38SUB+xWiAQAFqLjLxqQKcoXRqvPxr8S5A4fE5ONdQgbpdkOJYWuy0bj zpC4alrhDL9lbWTv+zpq1EsJgHvQzjpqHAE5xg5yfzbm3RbuHr3rja6je6z/8aAVIasP0olW 8yGO2OXnvs0WfIZ46HB5eSZ/hsOeknqWvKMKyyKKaqHomMDdaLkCDQRX0bFgARAAsOjgr8qu Y/ToUM923T1/HSPVxnnqak/wuwY+HTCjsnq9U8fzjoepLZb54aJMAysD91oXoleEsYVtGwZM auDIyLxvppJWDrmkJ2Vs7cB84Ey+KvK6Ix+ylaQW0P0faHTTgrYVpSghg8M2b93uKdeJrDVt QvgGWWYe4l04BBtnZFEDkg65DLd54ybTl8yS4I+5nYQG8CqP1t7PGjftKchr2zr0RSS331o2 bw79NUpORAk3QuHX3YmUdtAJlU/WUTP+GtcLuOVpYap+7saXfm0KGznTUwLuVx7f3cI7qC+F eWGQsZQm9hCbezf0EggL6KeoxtHSW3kTO4Qey4mk5b3iVQ1uNcIOjBySdr0iMF6fHCo+iCmQ SQ1wVdh6/txqXQwIczwFMcI4XtZ0hkFhzdwSCHNCwe+pJyysrmKD8HilLUHFm629khB73y/H GSwPoyHqhx6LuXNgT/7yZtXmx4if9jHRcLA5+ge8R4Sl6nOEHni8wUMlpFLwtyuovcu1hG+v 77imd0wr4Pn1M6xZtXAN3UISLNNaIcevoPGu1mcEGvoftS8peRe1H7J6ScTAYkV2FU7zFUBV KQYNAT+Z6cd3Vv7NaC/+mJbkIa/TzXkM0TVrgK/tqGMEFn/AyQL2KFUBM3ck7ROQSj0hffyq wHkvz9DTP0jmmeS7wFUh432YmC0AEQEAAYkCPAQYAQgAJgIbDBYhBKn/Meek+uU4KIgyOkZU D8L1GgIABQJbwfW3BQkF0XfXAAoJEEZUD8L1GgIAplcP/j0JMvVGUB+jwPMQOSWrukflUCOo 6/gof227aOESX7sZXadcuIXmp+1VeCL7TNYKi7e6ml898FeYrGMBoozgj4zsWQ1xbJFAO+7Y 5VMcD4LOhn/Ux/nnMUqa52KjlMnR7FU+/kVPAM1lO1LgkoQbTze3Bz2012AV5xkOqVdLHTsQ 1nIu5e25Cv8bQwLyOKuD584V5gqFQUDowk1KJ7KFay3PvoBsDGvFDfnMjZ4SEiFSPaOD02eR pZCLhx32dxKo2R0EvesBE2MECGyYMBGmtTGrh++MpbfV3mHu5HO0WJQTUEGmeWKYURiqlQrw OwXM3l4TfeYTQwX1rEvB5IUheFml2d7nSWba+Resr9dkGpne4qhuG57MsUcYFGpztrd+PE5M RKx1nVcVAIpKxsoQE/lC4f7qn45MNbRZFfsL1Yvg36duPxUacDhW3S2B2EWwHlCQKlgYURia DCCNDsC6fVwrBneYtyF/YGslG7ewJJKNPCNNLGpHWXzV/W+ViSSZJ/ZCaassvo9K/dZ8kbcA 69/vXgwpYtQ0P8X0btw7GeU9hZoII0cG+Hm5AeDa5fdbD2R/YDHC7O6DTW4UhJcOEq57cDH+ Atn7M3Jk0ZdXyZ0sQ84iReGjKe0+Frik5td0OxoBUDzkMdQSkOJO8uznUS/fmQD00Ac+TLcx FxK+HJ6suQINBFfRscABEADKBbUpz5DJaoqqoECqt6zQckTP+quOqq5YWxbDrVniLjrHy+jA OENI+ZuTLeiFWK2A12X7sU2JuzTGMy8GV83ni58cEWHzUeejECJyG3hC3G1jUwFlGxz5mEM3 8yOH85dyFy/mfZZlbtt/GwhfHJmiiI66wh4QrmQv2//i+K4EV9uhZ7D3iPMIrCUblRQYRdaJ zA6DV31d+DHg3kHxLOg1X9jlza/j2tHUOEr5qkVTAVkDCTT/JmwW48BOCQioG9h9zzCJSaTS o5qrKGGk+Npb1k6wVZLWlaEdIOtoAcRha5g8jaT2Yo2AinnfrWpLMaM+N7hgaXCVp+/B+J2k AWM9liN0WOFUlNds9Kxl278wiVLtYaygCTqG6hq7Lgn1xPfCyv8uNxN6oxOqkRhiZh7zyEFP x0t5CkojclzWBvBcfSl3lk8dLbtft7ZX0jsi+rkW8tDzZ2G9zVpczRVOkPAMiOm3O07rWVao oLvWEnBzcmPQuHUlyNS3YnH4PhHbDx40Je4G8ClraKdjKGp3DAi74u79HqnF3nApieNGky9X 0ciLgqpzPmO/NjrpyP738WlMf1NkDAw5xyY4OEcY7lWc735krQ+VTww6Vz3BM0LkSuiQJ26I sUbAgqqAXhe6zQw3uGekJfcONX2TQFuGKix4SHF2snGIWZEaJPyvguwSpwARAQABiQRbBBgB CAAmAhsCFiEEqf8x56T65TgoiDI6RlQPwvUaAgAFAlvB9bcFCQXRd3cCKcFdIAQZAQgABgUC V9GxwAAKCRB/v3mnzxmcqAqJD/4sNUttXXEHIBvBnKlvYmqTfBwuhRenixrXjq4GHi4Ib8Wy lcqIwenY+NYsA1McVhWSxHWUr6d8zjTLvKxjbCeXIScnG+eMkt2KptmwliFTbQaJ+0YRSwRS SYNGLl/wKTnkf+AcQwI+EKhOm2/TwebVbwJUlcEYcpHsmBl822AlIiHIJeG57wLDEAWPd3lH NrkpcACsAkvmaEkBf4HEkYdTj3ivwKVFaikXrR3HtYNkl0sLr1aqyIHnf6C63fUVG/eh+p9N WeXt93lynvKBBFrRz/6aGLwiG4MzaRsOe75QsgS8k+hN1Mf1rv/TaadnSDjqG1dhpP5fpYfJ nWNsYU44Aa1s6pnddbMf2unppQo6ar4oWvcKiS97wezwHNc8OT7w+LNDyR/KlQ2bUXNikXLh msMSrM1IHq1pYUMP86HMdy9ONVxn5QHKH/BP1TYtnisLDeIDVpJq7Y/uvNedXR9J2SBZjNVO Edbrt0IsQZheScsy9Ex7hJdblsT8IDEAUjFO+BxJtpFxa3ZOogxpLKmda/QQ//N7YLSVbhTf AaAFOBXTKrJFpqclQTVj+16klQ5gPCits00i0v5NaPiZPV3ZyBD3cgJO1ojceLGfOb5ocKUe anRMuKr0c6JhAeoXrjMzY3IJ4qDLP8uAiN0jVkvdA2A1J+gCcf3VhU2VFLNCOQkQRlQPwvUa AgA+vA//VpMg9NPcrkJERlwlk5+VH460GVkhj/HQYAJnHd7Njj0l3e73e2Vlt7qI3KD1Stcz 6TrPJaN0IwSSCLANt1Bm21brH+mjZittXztvOBVcVTleR0MCLwjwK6JALlaIC3fgZDqJ94FN vzpoJsrbCIlO/lKRljX9JYGiZdGmrle4GEflw8D32X0AoajxZEYT3LNu9AmdaN1mB7/HMQJg ozvYKZY4HC2u9K95qSP5HGiTttmnD/8H5fGYHJmQ3IW8b732cSm5GAFvU+nadB6wqW9PxnQR kcaa5pg8T/ehdo67lY7DDuKz642FPY74w3CRwxI3Rfdn6+WF8bthRfe+dSB2E7osWtsUvH8z 9j4cqFT/zzrFR4zUH56/b1HSQJ6UUlgYnY3HSAlQt8qtQhRV5G/BOGcVEHRrfUaj3KG6qSPr UZq2uqxRcRdQ8QYY24334Hhw3rRvz6HJWZxcjGQZe4k6+x94Sw0U3DzKoP+e0g6JRkmx/Asz u2vml7T5MbYB8O55m85M3BydKjHNlvBlbo6Ee1u6UPtf5S+OE66M0QIJZGXXN0lx2DVqQ+BM R5HGv7sbQA1EgxUxSWweQE6STAcBjKnDc45c8kWeaet/d53lEd51OTR+NJ+AD9ZGedsZbhyn mkO+/Is4xPvFt8TZspp+8ayFxe8z6z0M8J09RCOgZkg= Message-ID: <305f4516-9b7d-3960-1b6b-76e22dc99470@derechosdigitales.org> Date: Tue, 17 Sep 2019 17:06:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <1138709738.5923109.1568749306948@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 22:06:11 -0000 Hi, I think this draft is complete in terms of content, recognizing its purpose as a platform for further discussion. For me, it's still difficult to get all the rules and acceptable manners in IETF/IRTF but I suppose (correct me if I'm wrong, please) that RGs need an interdisciplinary discussion, which also implies other methodologies and problem statements, different from -and in dialog with- engineering. I totally think this document is useful and valuable, and I second Paul's idea of including it in the newcomers introduction conference. I also think that making some text changes will help to clarify the problem. Reading the draft I feel there are a lot of implicit ideas that can be explicitly stated. I propose some changes, different from those proposed by Gurshabad. Hope it can help. - For me it's a little weird to find only one sentence in Section 3. Although the question is suggestive, its not a research question because there are only two possible answers: yes or not. It would be interesting to find a problem statement, for example one referring terms like open, formal, voluntary, competition and collaboration, which appear as problematic in relation to standardization processes throughout the draft. Articulating these terms in one sentence may help to explicitly tie Sections 4 and 5. - I haven't followed in detail earlier discussions about this draft, and I don't know why the definition of "protocols" and "standards" were removed from Section 2 (Vocabulary Used). Beyond that, for me -an external reader or an already new participant- in Section 5 it is not clear what exactly is referred to as "standard setting processes" in general, and in particular in IETF. This discussion about 'de facto' vs. 'de jure' and normative vs. voluntary in IETF particular case, can be stated in one paragraph, may be in the Conclusions. - For me it's not clear where exactly emerges the conclusion, mentioned in a previous discussion, about "that standards are in effect normative, even if we claim them to be voluntary". Reading and reading again the draft I'm not sure if it emerges from the general review or from the interviews, mailinglist and meetings exchanges, and participatory observation. I don't think this part needs more content but to be presented in a clearer form. best, Juliana Guerra From nobody Tue Sep 17 15:12:43 2019 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 E18431208FE for ; Tue, 17 Sep 2019 15:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJaPIK-e3170 for ; Tue, 17 Sep 2019 15:12:39 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966FA1200B5 for ; Tue, 17 Sep 2019 15:12:39 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id r5so6474533qtd.0 for ; Tue, 17 Sep 2019 15:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=I/rabZrElUB5Zv6gXL6Oa72aoyo4uJ+9P+tazsm2I+c=; b=W59Z4VlNroBj3P2uRax0ib6UqJ4cD2C/wXdvza/tt7EbGZsl+x63rvsUhElL5U4Tx3 RxKRCIFJlhuQldKb8EWfaLhtKn57wKl7biIIprkyKj8vt7jWbcxEE7zlx2Z7fp2yV1GG wo/DiXiXVQYzIU4/7kzy9yii5I8QqAWRyYfsSVEsHP9NX0+ZWOgmbKXampFdBAngoHb3 9ESFqAWUgEcGfEMl/KCkT84kEWQSmLBkltB9bNLjQsEFLryhBulxOU1qPnBsBqFHR4Fr QPoZp1fiqIegQgljtlZNncp8BAwbyr7DEZ0Wd2qAHX8ekdBwGZD/7B0/QPpDUyP6nbG5 hdCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=I/rabZrElUB5Zv6gXL6Oa72aoyo4uJ+9P+tazsm2I+c=; b=Rs+gaSUt6VRqzv6roakPu0mJByHqPm5ui/Iklp/HjuUvPI+Z617e/umq5BZ/vCvV7j CJmlYAPoZD4fATjUucUPk1MYyzbqb7upoT+HsFjNI3SUEEWPMZ5Y5Keq0frDHmEDXA7D l88ch2fC5IUPW30/2SavarmlY4xcA338U5K7X6fWMP1dN5RM5XHN2haGmVN5FcyhbLEh 961vyHFwd6HFiGDzugCMgX11VMtRDms0oFKguouYgObsHBBnYDs98u7ODpDWLF60FZTn x6uwyCeyd60dV9BrmGPnM2/kh8JzF+tCDlUfApvdl4EoGoNrQCmUKN7DR87mI1+D4dUB //sw== X-Gm-Message-State: APjAAAXMAvETrkRK2cAwagtLw1qb/AylMR+ACgJ7P1H7szFRGkHRdvhX wBHkAs/SFpxdDr8XOX4ycK4RJhdoUNNr1g== X-Google-Smtp-Source: APXvYqw1CkcEo5VolDpBxxatmi17HTLXDUd6cq7/MHuYEO8J5f0wiXiKjxn9/Kjv5z2k85cyYlI+/Q== X-Received: by 2002:ac8:45d2:: with SMTP id e18mr1107758qto.321.1568758358529; Tue, 17 Sep 2019 15:12:38 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id u39sm2424111qtj.34.2019.09.17.15.12.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 15:12:37 -0700 (PDT) From: Ted Lemon Message-Id: <123AA784-DA56-421B-A190-D08301252207@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0CFD325F-B4D8-4067-9135-B9C5A35A92A1" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) Date: Tue, 17 Sep 2019 18:12:36 -0400 In-Reply-To: Cc: hrpc@irtf.org To: Melinda Shore References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 22:12:42 -0000 --Apple-Mail=_0CFD325F-B4D8-4067-9135-B9C5A35A92A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 17, 2019, at 1:04 PM, Melinda Shore = wrote: > I suppose this is another opportunity to remind people to > distinguish between disagreements that they can live with and > disagreements they cannot. FWIW, I responded because Avri asked for feedback, not because I need = for my complaints to be addressed. If the WG generally feels that the = document is useful as is, I don=E2=80=99t want to stand in the way. --Apple-Mail=_0CFD325F-B4D8-4067-9135-B9C5A35A92A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 17, 2019, at 1:04 PM, Melinda Shore <melinda.shore@nomountain.net> wrote:
I suppose this is another opportunity to remind people = to
distinguish = between disagreements that they can live with and
disagreements = they cannot.

FWIW, I responded because Avri asked for feedback, not = because I need for my complaints to be addressed.   If the WG = generally feels that the document is useful as is, I don=E2=80=99t want = to stand in the way.

= --Apple-Mail=_0CFD325F-B4D8-4067-9135-B9C5A35A92A1-- From nobody Tue Sep 17 18:15:27 2019 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 D6A3512006F for ; Tue, 17 Sep 2019 18:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 zpEFSs_VvxGN for ; Tue, 17 Sep 2019 18:15:22 -0700 (PDT) Received: from sonic302-1.consmr.mail.bf2.yahoo.com (sonic302-1.consmr.mail.bf2.yahoo.com [74.6.135.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC5412007A for ; Tue, 17 Sep 2019 18:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1568769320; bh=t4ehX/2r2jNE8dNkse2bFbZdm0RWAcdnQlZiI85Ks54=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=hfOeCz1QwTJzFZICsDUMC4AoAhfLA5lRGfFtym1uPs9gp5Xf2PxmNozVVaTz9RxISb25XHN+JNJ6CYVieSue7HrJjiKio6P1iEMJiz3Bct4MjxqcgarH6bA0B2WCSk0FHgIk/fvOsBazEo/d/mx8PZLQM4+Vl32oFSeGAdgG6kz3Bk4KZgVTOUFFgbWaxHBN1kI5cwWXZfL08r8vaD1DqiG2rWvB7CeSke7D1CChqCRiLq4wKijcmCu/5nwto0ag5sdqSxojwNledxOY82CUwe40ihHI4p/Lx72sJo2vq5xQsUJ5dklDyBPsn0FpbdowaCOkIbrB5tADbkvl6JScoQ== X-YMail-OSG: W2n6n9QVM1l8WTYJluFlukmuKX.2roI_zY1fekq2X7B6Ab1SVFfkP_EG2u9r6MY DjcU3mGjTBoIPFspDxIhNTr94pH2KUIHX.gwCU.vkmt4WnpblCVnvYPI_NAGWQ9Grz6uNl8MECnD KrqwzfrfD0MeButhY57GY8zLmJkv2FHT5bMfOYyrjiz5imr0mij6MKmd0dT.DFBuqlmUmKKOBstw u_FGDHb3HVeht0ZBbe2b48ckmz03sVNoE9cYa1m3raXa.I4K8n8TyJNwSD7wh0D40z5BkN.cw2hn o9OMBHTlq_CBTnUy4H6R8cAWD3MKsbBB7p4Psgrp_Qy0mBuzGmVIq_0713aoGWCHeIxliTG_AX9W now17e7ia9w8GtpIO8ZATTMKkI1hGOM2Ht1GniNU95NZNVPk7xj_86.NIRoO2rRNcF0inHcDCLlf a8P3vbBAb7wBhZwuugfRCmxeR0SWEpNw17.ldZH2u6e_TKu_gOCe9kM5XlRYW0FW.bUSuEzy4GKY W8e3XNzioaqOZugJSG5EpIz4SNKmhZg5f74HAI7jUP3iV9hfvhHGp0U_uQ.K7fnOdYwbUxuoMO8_ EWSatekow7.XMFuf1wIaj1r8trUJCnpKqxNdWtf1cQ2yrxGoxHH32DKQDOsZOXxeSq5bDHcmDlpw UNvAwc6fdI5MQFNbxo82D06SxQckoLqHuoxsTAowxEENubMQwIZgheGOuiXEVDPQGPeDDt_Fxl4i criEEj.q1t8ZehwaHsRLRTSJLj556QOgb6hH6TCRFV49GKN57zpefWQlQaXKFi7R.ZVruOGxOEvy AUNoFxkRn0GQFPA_jg9vnFd4nAAEVKLQAx8NDmoWxDR2qJikK0Sj18oGbCxqCS4a96uvHSTSHs61 AKfFh66_.oL5Fz3XvLvUhmnSsodTkiH1zPlLb0yDLU_otr2I4PH0NuSLk5J8nZq0Teym39wgN_dy V01qz4vNOY7WGEdOXm5XIN8xAxu268g7fRIN059IebnX4c.8FjCzmbLZXIvE2Z1Rs3nTX0JSRzPk gWFbStZ69Oe6OOF93Ve0a3eTe7oVF.Z9XyDysNoLF7BAfwfCI2rAWcn4wLgNqllmV3XBU8zqI2O3 WCsFOGsNHKjVKW.nihhdqq_Hsg3w2SRCyjL9JsCRwLGUb_bhJZuIuVc0C0vGaiDwz_UdHfukp.dr racW350TKxlLQB5aAdJuxp9h_Ybhh0J2dUmvvp4nZtf4MKstjZVPHWcNkp0d6I0uJhJiVunFm26u S50UxQ_dT1GzrB8AXQPstZLvLf4q5_J6C9paczJ03AtQi1Q5tUXhZwrlq0Hw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 18 Sep 2019 01:15:20 +0000 Date: Wed, 18 Sep 2019 01:15:17 +0000 (UTC) From: Mark Perkins To: hrpc@irtf.org Message-ID: <536937311.6017158.1568769317514@mail.yahoo.com> In-Reply-To: <305f4516-9b7d-3960-1b6b-76e22dc99470@derechosdigitales.org> References: <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> <1138709738.5923109.1568749306948@mail.yahoo.com> <305f4516-9b7d-3960-1b6b-76e22dc99470@derechosdigitales.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6017157_1863423974.1568769317512" X-Mailer: WebService/1.1.14303 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 01:15:25 -0000 ------=_Part_6017157_1863423974.1568769317512 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all Personally, I agree with the argument of the document and its importance, w= hich is why I believe that it should be both be readable (people should wan= t to read it), legible, well documented and supported by examples & citatio= ns. Those who have pointed out lacking (or incorrect) citations &/or places whe= re examples are missing, PLEASE be precise in pointing these out & providin= g citations, examples or corrections. I agree that the vocabulary section needs to be filled out, and the text co= ncord with definitions given (standards vs protocols, etc). As for readability, I am not sure how this can be improved, unless many cit= ations & examples are moved to a 'reference' section. Given the subject mat= ter of the document, I do not think we can avoid providing many of the cita= tions/examples... As for the research question, as given it is clearly a binary yes/no.=C2=A0= Perhaps within the conclusion, a sub-section of 'resulting research questi= ons' could be useful. My 2 pacific francs Mark Perkins On Wednesday, September 18, 2019, 9:06:18 AM GMT+11, Juliana Guerra wrote: =20 =20 Hi, I think this draft is complete in terms of content, recognizing its purpose as a platform for further discussion. For me, it's still difficult to get all the rules and acceptable manners in IETF/IRTF but I suppose (correct me if I'm wrong, please) that RGs need an interdisciplinary discussion, which also implies other methodologies and problem statements, different from -and in dialog with- engineering. I totally think this document is useful and valuable, and I second Paul's idea of including it in the newcomers introduction conference. I also think that making some text changes will help to clarify the problem. Reading the draft I feel there are a lot of implicit ideas that can be explicitly stated. I propose some changes, different from those proposed by Gurshabad. Hope it can help. - For me it's a little weird to find only one sentence in Section 3. Although the question is suggestive, its not a research question because there are only two possible answers: yes or not. It would be interesting to find a problem statement, for example one referring terms like open, formal, voluntary, competition and collaboration, which appear as problematic in relation to standardization processes throughout the draft. Articulating these terms in one sentence may help to explicitly tie Sections 4 and 5. - I haven't followed in detail earlier discussions about this draft, and I don't know why the definition of "protocols" and "standards" were removed from Section 2 (Vocabulary Used). Beyond that, for me -an external reader or an already new participant- in Section 5 it is not clear what exactly is referred to as "standard setting processes" in general, and in particular in IETF. This discussion about 'de facto' vs. 'de jure' and normative vs. voluntary in IETF particular case, can be stated in one paragraph, may be in the Conclusions. - For me it's not clear where exactly emerges the conclusion, mentioned in a previous discussion, about "that standards are in effect normative, even if we claim them to be voluntary". Reading and reading again the draft I'm not sure if it emerges from the general review or from the interviews, mailinglist and meetings exchanges, and participatory observation. I don't think this part needs more content but to be presented in a clearer form. best, Juliana Guerra _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_6017157_1863423974.1568769317512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all

Personally, I agree with the argument of the document and its=20 importance, which is why I believe that it should be both be=20 readable (people should want to read it), legible, well documented and=20 supported by examples & citations.

Those who have pointed out lacking (or incorrect) citations = &/or places where examples are missing, PLEASE be precise in pointing t= hese out & providing citations, examples or corrections.

I agree that the vocabulary section needs to be filled out, and the te= xt concord with definitions given (standards vs protocols, etc).

As for readability, I am not sure how this can be improved, unless = many citations & examples are moved to a 'reference' section. Given the= subject matter of the document, I do not think we can avoid providing many= of the citations/examples...
<= br>
As for the research questio= n, as given it is clearly a binary yes/no.  Perhaps within the conclus= ion, a sub-section of 'resulting research questions' could be useful.
=

My 2 pacific francs

Mark Perkins
=20
=20
On Wednesday, September 18, 2019, 9:06:18 AM GMT+11, Ju= liana Guerra <juliana@derechosdigitales.org> wrote:


Hi,

I think this draft is complete in terms of content, recognizing its
purpose as a platform for further discussion.

For me, it's still difficult to get all the rules an= d acceptable manners
in IETF/IRTF but I suppose (correct = me if I'm wrong, please) that RGs
need an interdisciplina= ry discussion, which also implies other
methodologies and= problem statements, different from -and in dialog
with- = engineering.

I totally think this docu= ment is useful and valuable, and I second
Paul's idea of = including it in the newcomers introduction conference.
I also think that making some text changes will help to cl= arify the
problem. Reading the draft I feel there are a l= ot of implicit ideas that
can be explicitly stated. I pro= pose some changes, different from those
proposed by Gursh= abad. Hope it can help.

- For me it's = a little weird to find only one sentence in Section 3.
Al= though the question is suggestive, its not a research question because
there are only two possible answers: yes or not. It would be = interesting
to find a problem statement, for example one = referring terms like open,
formal, voluntary, competition= and collaboration, which appear as
problematic in relati= on to standardization processes throughout the
draft. Art= iculating these terms in one sentence may help to explicitly
tie Sections 4 and 5.

- I haven't = followed in detail earlier discussions about this draft, and
I don't know why the definition of "protocols" and "standards"
were removed from Section 2 (Vocabulary Used). Beyond that, for m= e -an
external reader or an already new participant- in S= ection 5 it is not
clear what exactly is referred to as "= standard setting processes" in
general, and in particular= in IETF. This discussion about 'de facto' vs.
'de jure' = and normative vs. voluntary in IETF particular case, can be
stated in one paragraph, may be in the Conclusions.
- For me it's not clear where exactly emerges the conclusi= on, mentioned
in a previous discussion, about "that stand= ards are in effect normative,
even if we claim them to be= voluntary". Reading and reading again the
draft I'm not = sure if it emerges from the general review or from the
in= terviews, mailinglist and meetings exchanges, and participatory
observation. I don't think this part needs more content but to bepresented in a clearer form.

best,

Juliana Guerra


=
_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
------=_Part_6017157_1863423974.1568769317512-- From nobody Tue Sep 17 18:40:14 2019 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 B72B91200D6 for ; Tue, 17 Sep 2019 18:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=f6HB1R1D; dkim=pass (1024-bit key) header.d=yitter.info header.b=UhtfSSdj 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 8wxjaCR5i3mD for ; Tue, 17 Sep 2019 18:40:08 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7441E12007A for ; Tue, 17 Sep 2019 18:40:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id E96BFBCC7D for ; Wed, 18 Sep 2019 01:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568770775; bh=iuFEr6PH8zR6Mvxf67BxthI2IhZULpijWlLotcE5yeQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=f6HB1R1DpCJLeFwADvM6WtFbjlQnzGSyjQm5Rs0XsLBAff1ZVahnnSNRgd3f0ubpi 42+nSqZ1OKTkNOXL2mgovJin9ct+ostgg/+OGfUYIXt8bPHMPI8BIl0xPM0O5qgTrM F1AlQbgaC0v8mbRljCxfEQPxzB6kl/ktVLrqcsro= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liggCRGECAUs for ; Wed, 18 Sep 2019 01:39:34 +0000 (UTC) Date: Tue, 17 Sep 2019 21:39:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568770774; bh=iuFEr6PH8zR6Mvxf67BxthI2IhZULpijWlLotcE5yeQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UhtfSSdjp2cOt7fm4+sWG7LA338Jiykm/UECE25QwFjCzI6rL7rpPayphxZbfFGVU uAMG9Alb2L++rNpspqz8tYFDr0YTnezP1txEcip10ErExMGm49km88711om/GkzWlE tgVT75D89pn46xlgdZH7gDoQZiAjeomC30YniOMw= From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20190918013932.eurns5h63oljz2pl@mx4.yitter.info> References: <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> <1138709738.5923109.1568749306948@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1138709738.5923109.1568749306948@mail.yahoo.com> Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 01:40:12 -0000 Hi, Speaking only for myself. On Tue, Sep 17, 2019 at 07:41:46PM +0000, Mark Perkins wrote: > > Personally, I think that many 'techies' try to pretend that their work is 'not political', whereas it is clear from the document that this is not the case. Whether it is clear from this document is precisely what I find contentious about the document, and asserting that it is so clear does not make that true. Despite not having the time for a complete review, I feel some affection for this document because I made some early contributions to it, so I had another look. The assertion that the document "shows" that protocols are in fact political is still not, in my reading, borne out. Section 4 attempts to outline various positions about the claim that protocols are inherently political. I think it mostly succeeds in this, although I think some of the descriptions are more complete, more charitable, or both than others. I continue to suspect that §4.5 makes the conflation I asked about once before, but I can't really focus on this such that I could make the case properly. I really don't understand section 5. I guess I understand that it is an attempt to hook up the discussion of protocols and politics to the function of standards. Ironically, however, this undermines any argument about protocols being necessarily political based on §4, because not every protocol is a standard. It would seem that a Venn diagram would show this pretty clearly, but they're hard to make in ASCII art. But the real problem comes in §6, where claims are made that are poorly supported by the text, and not obviously true. For instance, Economics, competition, collaboration, openness, and political impact have been an inherent part of the work of the IETF since its early beginnings. strikes me as a claim that may or may not be empirically true, but it would need rather a lot of argument to support it. … but [the IETF] does set open standards for interoperability on the Internet, and has done so since the inception of the Internet. is at least possibly false, since many of the early standards for Internet interoperability were set by the IAB, of which the IETF was a subsidiary (see https://tools.ietf.org/html/rfc1120). Because a standard is the blue- print for how to accomplish a particular task, the adopted standards have a normative effect. This claim is belied by the number of IETF standards that are widely ignored or have not been implemented, and it suggests that the IETF has a kind of control that it does not actually have (as acknowledged only in the previous sentence). The best we can get is that adopted standards _may_ have a normative effect, sometimes. That seems hardly surprising, but it's also a pretty weak claim on which to build a universally-quantified claim about protocols and politics. I'll number some propositions in the next passage for ease of reference: [0] Whereas there might not be agreement among the Internet protocol community on the specific political nature of the technological development process and its outputs, [1] it is undisputed that standards and protocols are both products of a political process, [2] and they can also be used for political means. [3] Therefore protocols and standards are not 'value-neutral, [4] and neither is the IETF' [RFC3935]. [5] Thus we can answer the research question 'are protocols political' in affirmative fashion. In the above, [0] is simply an acknowledgemwnt of the differences in §4. [1] appears to be a claim that each of these propositions is true: [A] all standards are always a product of a political process [B] all protocols are always a product of a political process It is entirely unclear to me that [B] is in fact true, much less that it has been demonstrated anywhere in this draft. And it seems trivial to come up with an example where this is false -- for instance, the process where some lone programmer writes v0 of some protocol for his or her software such that others can use it (this is sometimes called "an API", but it's often just as easily described as an immature protocol). At the very least, to call such a process "political" is to render the meaning of "political" empty. So, the truth of [1], which depends on both [A] and [B] being true, seems suspect to me. It seems to me that [2] is trivially true, since it is merely a claim about both protocols and standards being possibly used for political means, and as long as we can think of one example this proposition is then true. [3] is a very fast conclusion that, with liberal application of the principle of charity, can be rendered thus [a] If a thing is both the product of a political process and possibly used for political means, then it is not value-neutral. [b.1] ARGUMENT FROM [1] GOES HERE therefore [b] protocols and standards are not value-neutral therefore [c] Protocols and standards are not value-neutral (As you can see, [c] is the same as [3].) The problem here starts with the difficulty in accepting [1], as I outline above. If we do not believe that [1] is demonstrated, then the antecedent of the conditional in [a] is not shown as [b], so the syllogism that gets us to [c] can't proceed. That's the first problem. But the second problem is in the premise [a] itself. For the truth is that [a] is just an _assertion_ that a political process and use for political means entails that the result is somehow political. That is not actually demonstrated, however, and as a refutation of "the politics lies entirely in the human use, not in the object itself" described in §4.1 it is simply begging the question. The number of seats in the Canadian House of Commons is the product of a political process and it is certainly used for political means. That does not make the number of seats "political" in itself: it might be just a contingent fact about the current composition of the House of Commons. In other words, this depends very much on how one interprets "φ is political", which was of course the very question that was open in the first place, so the text has reasoned in a circle. [4] does not follow from [3] at all, and I don't see how it follows from any of the other premises either. I don't know that it matters, because it isn't obvious to me that the draft ever wanted to make the claim that the IETF is or is not political. One suspects that the goal is to make an approving appeal to authority of RFC 3935, but it's hard to tell. [5] is false in case [3] does not hold, and since [3] is in trouble [5] is too. In case anyone wanted my recommendation, it would be for the RG to change the focus of the document: In this document we aim to outline different views on the relation between standards and politics. This would be enough and would be a contribution to the RFC Series because it would document some positions (in §4). In this case §6 could simply be removed. I don't know what to do with §5 because I don't understand it. Alternatively, the author could publish this document without it being an RG document, thereby avoiding the need to come to consensus on a position that I believe unlikely to yield such consensus (mostly because I believe the position to be manifestly false). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Sep 17 20:32:25 2019 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 AC3B4120073 for ; Tue, 17 Sep 2019 20:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 2_pO-lCsFZAk for ; Tue, 17 Sep 2019 20:32:21 -0700 (PDT) Received: from sonic304-56.consmr.mail.bf2.yahoo.com (sonic304-56.consmr.mail.bf2.yahoo.com [74.6.128.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4A4120096 for ; Tue, 17 Sep 2019 20:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1568777539; bh=7gdJ+DEyBly/PP+CSFTpbIXqXZEw/hT4byUQ3Yug50Y=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=M12bk48dA/xOA6+1+KFn7xGKKE8CRTtwdK7dmz/UZ70B/mEoDBxd2Qn4Bg+tFiwmx5aqXYTxto1/nO8wcGzBWsJvbyK3JbqvXw1owtx8ilBbWbWGM/kIOhD5Nf5RqZXeJWNE4AFDJSSdnpipzIsyXd4ywSflLZKBPYrcOg3EoD0Go+qKnY0Ve7ZZ8Z02Yb0cpASWUlTnyg0xuErdPCLhIt/tgPlTI93owsjPRyvZ4eYgA4e+0kCE/5Wh7EWJT0zf5JsMCjzptjbTgwvfftbYGKXzu/TMGPYkroHvqGcmUIhYad77StlZuJnI9HNJER3bd+rbw9mI17LFqVrPybHG2g== X-YMail-OSG: 7jHLcb0VM1lWDJJGU7QFLhzko7AcosAFV7T.2AnOJWmwES_72OGYZqpMx_K0yW_ 6OZ8HV3xMF4D6ckTAN5tEtST9dvjEGFLTfBdAr1OGAPLslUBY0K4vDTzRMPuSFq5ruQD9qMJzxFx yqiIBFhWc5L7iVZN7W3EHEYomtqpSd3YCa.tXezwrlUkC6qvlnaLrMXLUIe1iPcGKFGZvnmGbfRw zyPzsq8N7k7yiveo1t7IQYb39h5WkZJq3bNrpt.wms6Gqcs9cuGIAGSF6LSZk6v2KhhG0WD5Wm95 h4L91ag7pOr0e2YJ6TDUNwGcuIbxhJBGnpoj4ksLxO0.zmsqn7BTscBp5M71rLzB8ycbu68W7OG4 7L5YSiWY1Yr6CFh.en84o92ZE1Q356jeNUGvylIHpULEDD2m1NzKWoGQZCMDU_kCdzqkJvIGcN1a xrgzIOetDcDP8q0MZH.OYdSp6BxGhtrCf0Do_8KEB1aiP9Lk7H1VpsxH8yveoV9H_NnZP1DAqYtl GhA0TBkAcai1VOEOgcBwZAl_1p35sxj3Ab356088pgm.fQAbMVVoSC89Vzqo.DiGW6zLhCWnfagj MoRTlFPbyWHfX2ZQVanU8j0onoWU7_0fVKl6X9pVHYMuxu9Pe6si9xhf48mwUWKS.wAVV_ZrffMm nxsZSt9ySwP6jvTzzu78iUEDHW4SI0N2SCskoqwjgz_swGWx4vxKN9MoSx3b3ubdJmQWQhCS_wyI 4CeOOK2QxdANjdftPz5r1cRemggyJW9XLCfiuhWWauFtl1iMbqeingDBbydkwpQ7v38g5J829_mb 0aZY4lvA0NXU6ofIjnrTWr9AA.hgabzQS6usNHeDf5GTeKttarc6Idyx3RFVl5Mw6dyXT39Q32Pd OrQYSAD2lZBvR7rYUqBYrgK3_dQ_1NolgFnL6RrwXg4QYxa3t93Ke1VZ3AtMMwrTZuT94WJmG1F6 DSmBFZUMu_ttSPJ_wAv4F01hoJMLGINsV2bWuwRr5clSkcXuPjbfSN1ur3114zAp9F.8Oa43I6yy hcpEdVj7WIhsn9G3sJ3U18NRW4Bsdj2KuD8rTWj9DTGOgr2NGkFROgXB9P3T5AExf4Y2PmdCVVRE MkK8cE_xLc_mgNHsv5B5Ib7PfbZ4b0ajJCD7_EstZSawGZiQQpz7iZCKFUmdHf4_K5vVDb4avDa8 169cT39Gwu1apoo5hZtVIFXmGqryrxHUEEnxYBDtDcAR33DrHlgz7yMXRqBWh5p52D9o9CE5jQ1d jvMdeZ1PUDcmNKtg2LVMlq8.XCa31b.mDEkyXzvlzW1jP_lfgId7_eLxiY0fraOkhTp1WLpCKrQ- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 18 Sep 2019 03:32:19 +0000 Date: Wed, 18 Sep 2019 03:32:17 +0000 (UTC) From: Mark Perkins To: hrpc@irtf.org, Andrew Sullivan Message-ID: <296695201.6028595.1568777537962@mail.yahoo.com> In-Reply-To: <20190918013932.eurns5h63oljz2pl@mx4.yitter.info> References: <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> <1138709738.5923109.1568749306948@mail.yahoo.com> <20190918013932.eurns5h63oljz2pl@mx4.yitter.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6028594_1763590850.1568777537959" X-Mailer: WebService/1.1.14303 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 03:32:24 -0000 ------=_Part_6028594_1763590850.1568777537959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Andrew I think that you are reiterating, in a more detailed form, why it is essent= ial that the vocabulary section distinguises between protocols & standards,= and that the following text clearly applies that distinction. I would argue that standards are inherently political, and that protocols t= hat become standards thus also become political. Protocols can be developed in a myriad of ways; while it COULD be argued th= at since an individual is a product of a social/political process, his prot= ocols, for the purposes of this document, I think that would be unecessary = sociology. However, some protocols are developed by groups of people (comme= rcial, academic, non-profit, etc), which are clearly embedded in a politica= l context which constrains/directs their development of protocols; in this = case, the protocols can clearly be seen as 'political' as well as 'technica= l', some more so than others. While standards come in a variety of flavors, with a variety of coercive me= chanisms (market, legal, technical, etc), their very development as standar= ds is political. Whether they are used or not can change over time, as can = be the extent of their use (individual, local, international, etc.) and is = a reflection not only of their technical nature, but also of their politica= l nature - which can also change over time. For me, the document does show that protocol and, especially, standard deve= lopment / work is political, BUT I come from a political rather than techie= background ;) I am glad that Andrew (& others) are pointing out weaknesses= that need to be addressed in the argumentation, and hopefully (along with = clear citations & examples) we can address those weaknesses so that he (& o= thers) agree that document has shown its assertions to be true Mark Perkins On Wednesday, September 18, 2019, 12:40:20 PM GMT+11, Andrew Sullivan <= ajs@anvilwalrusden.com> wrote: =20 =20 Hi, Speaking only for myself. On Tue, Sep 17, 2019 at 07:41:46PM +0000, Mark Perkins wrote: >=20 > Personally, I think that many 'techies' try to pretend that their work is= 'not political', whereas it is clear from the document that this is not th= e case. Whether it is clear from this document is precisely what I find contentious about the document, and asserting that it is so clear does not make that true. Despite not having the time for a complete review, I feel some affection for this document because I made some early contributions to it, so I had another look.=C2=A0 The assertion that the document "shows" that protocols are in fact political is still not, in my reading, borne out. Section 4 attempts to outline various positions about the claim that protocols are inherently political.=C2=A0 I think it mostly succeeds in this, although I think some of the descriptions are more complete, more charitable, or both than others.=C2=A0 I continue to suspect that =C2= =A74.5 makes the conflation I asked about once before, but I can't really focus on this such that I could make the case properly. I really don't understand section 5.=C2=A0 I guess I understand that it is an attempt to hook up the discussion of protocols and politics to the function of standards.=C2=A0 Ironically, however, this undermines any argument about protocols being necessarily political based on =C2=A74, because not every protocol is a standard.=C2=A0 It would seem that a Venn diagram would show this pretty clearly, but they're hard to make in ASCII art. But the real problem comes in =C2=A76, where claims are made that are poorly supported by the text, and not obviously true.=C2=A0 For instance, =C2=A0 Economics, competition, collaboration, openness, and political impac= t =C2=A0 have been an inherent part of the work of the IETF since its early =C2=A0 beginnings. strikes me as a claim that may or may not be empirically true, but it would need rather a lot of argument to support it. =C2=A0=C2=A0=C2=A0 =E2=80=A6 but [the IETF] does set =C2=A0 open standards for interoperability on the Internet, and has done so =C2=A0 since the inception of the Internet.=C2=A0=20 is at least possibly false, since many of the early standards for Internet interoperability were set by the IAB, of which the IETF was a subsidiary (see https://tools.ietf.org/html/rfc1120). =C2=A0=C2=A0=C2=A0 Because a standard is the blue- =C2=A0 print for how to accomplish a particular task, the adopted standards =C2=A0 have a normative effect.=C2=A0=20 This claim is belied by the number of IETF standards that are widely ignored or have not been implemented, and it suggests that the IETF has a kind of control that it does not actually have (as acknowledged only in the previous sentence).=C2=A0 The best we can get is that adopted standards _may_ have a normative effect, sometimes.=C2=A0 That seems hardly surprising, but it's also a pretty weak claim on which to build a universally-quantified claim about protocols and politics. I'll number some propositions in the next passage for ease of reference: =C2=A0 [0] Whereas there might not be agreement among the Internet protocol =C2=A0 community on the specific political nature of the technological =C2=A0 development process and its outputs, [1] it is undisputed that stand= ards =C2=A0 and protocols are both products of a political process, [2] and they= can =C2=A0 also be used for political means.=C2=A0 [3] Therefore protocols and = standards =C2=A0 are not 'value-neutral, [4] and neither is the IETF' [RFC3935].=C2= =A0 [5] Thus we =C2=A0 can answer the research question 'are protocols political' in =C2=A0 affirmative fashion. In the above, [0] is simply an acknowledgemwnt of the differences in =C2=A74.=C2=A0 [1] appears to be a claim that each of these propositions is= true: =C2=A0=C2=A0=C2=A0 [A] all standards are always a product of a political pr= ocess =C2=A0=C2=A0=C2=A0 [B] all protocols are always a product of a political pr= ocess It is entirely unclear to me that [B] is in fact true, much less that it has been demonstrated anywhere in this draft.=C2=A0 And it seems trivial to come up with an example where this is false -- for instance, the process where some lone programmer writes v0 of some protocol for his or her software such that others can use it (this is sometimes called "an API", but it's often just as easily described as an immature protocol).=C2=A0 At the very least, to call such a process "political" is to render the meaning of "political" empty.=C2=A0 So, the truth of [1], which depends on both [A] and [B] being true, seems suspect to me. It seems to me that [2] is trivially true, since it is merely a claim about both protocols and standards being possibly used for political means, and as long as we can think of one example this proposition is then true. [3] is a very fast conclusion that, with liberal application of the principle of charity, can be rendered thus =C2=A0=C2=A0=C2=A0 [a] If a thing is both the product of a political proces= s and =C2=A0=C2=A0=C2=A0 possibly used for political means, then it is not value-= neutral. =C2=A0=C2=A0=C2=A0 [b.1] ARGUMENT FROM [1] GOES HERE =C2=A0=C2=A0=C2=A0 therefore =C2=A0=C2=A0=C2=A0 [b] protocols and standards are not value-neutral =C2=A0=C2=A0=C2=A0 therefore =C2=A0=C2=A0=C2=A0 [c] Protocols and standards are not value-neutral (As you can see, [c] is the same as [3].)=C2=A0 The problem here starts with the difficulty in accepting [1], as I outline above.=C2=A0 If we do not believe that [1] is demonstrated, then the antecedent of the conditional in [a] is not shown as [b], so the syllogism that gets us to [c] can't proceed.=C2=A0 That's the first problem.=C2=A0 But the second problem is in the premise [a] itself.=C2=A0 For the truth is that [a] is just an _assertion_ that a political process and use for political means entails that the result is somehow political.=C2=A0 That is not actually demonstrated, however, and as a refutation of "the politics lies entirely in the human use, not in the object itself" described in =C2=A74.1 it is simply begging the question.=C2=A0 The number of seats in t= he Canadian House of Commons is the product of a political process and it is certainly used for political means.=C2=A0 That does not make the number of seats "political" in itself: it might be just a contingent fact about the current composition of the House of Commons.=C2=A0 In other words, this depends very much on how one interprets "=CF=86 is political", which was of course the very question that was open in the first place, so the text has reasoned in a circle. [4] does not follow from [3] at all, and I don't see how it follows from any of the other premises either.=C2=A0 I don't know that it matters, because it isn't obvious to me that the draft ever wanted to make the claim that the IETF is or is not political.=C2=A0 One suspects that the goal is to make an approving appeal to authority of RFC 3935, but it's hard to tell.=C2=A0 [5] is false in case [3] does not hold, and since [3] is in trouble [5] is too. In case anyone wanted my recommendation, it would be for the RG to change the focus of the document: =C2=A0=C2=A0=C2=A0 In this document we aim to outline different views on th= e relation =C2=A0 between standards and politics. This would be enough and would be a contribution to the RFC Series because it would document some positions (in =C2=A74).=C2=A0 In this case = =C2=A76 could simply be removed.=C2=A0 I don't know what to do with =C2=A75 because= I don't understand it.=C2=A0 Alternatively, the author could publish this document without it being an RG document, thereby avoiding the need to come to consensus on a position that I believe unlikely to yield such consensus (mostly because I believe the position to be manifestly false). Best regards, A --=20 Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_6028594_1763590850.1568777537959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Andrew

I think that you are reiterating, in a more detailed form, why it is e= ssential that the vocabulary section distinguises between protocols & s= tandards, and that the following text clearly applies that distinction.

I would argue that standards are inherently political, and t= hat protocols that become standards thus also become political.

Protocols can be developed in a myriad of ways; while it COULD be ar= gued that since an individual is a product of a social/political process, h= is protocols, for the purposes of this document, I think that would be unec= essary sociology. However, some protocols are developed by groups of people= (commercial, academic, non-profit, etc), which are clearly embedded in a p= olitical context which constrains/directs their development of protocols; i= n this case, the protocols can clearly be seen as 'political' as well as 't= echnical', some more so than others.

While standards come= in a variety of flavors, with a variety of coercive mechanisms (market, le= gal, technical, etc), their very development as standards is political. Whe= ther they are used or not can change over time, as can be the extent of the= ir use (individual, local, international, etc.) and is a reflection not onl= y of their technical nature, but also of their political nature - which can= also change over time.

For me, the document does show th= at protocol and, especially, standard development / work is political, BUT = I come from a political rather than techie background ;) I am = glad that Andrew (& others) are pointing out weaknesses that need to be= addressed in the argumentation, and hopefully (along with clear citations = & examples) we can address those weaknesses so that he (& others) a= gree that document has shown its assertions to be true

Ma= rk Perkins

=20
=20
On Wednesday, September 18, 2019, 12:40:20 PM GMT+11, A= ndrew Sullivan <ajs@anvilwalrusden.com> wrote:


Hi,

Speaking only= for myself.

On Tue, Sep 17, 2019 at 0= 7:41:46PM +0000, Mark Perkins wrote:
>
> Personally, I think that many 'techies' try to pretend that their = work is 'not political', whereas it is clear from the document that this is= not the case.

Whether it is clear fro= m this document is precisely what I find
contentious abou= t the document, and asserting that it is so clear does
no= t make that true.

Despite not having t= he time for a complete review, I feel some
affection for = this document because I made some early contributions to
= it, so I had another look.  The assertion that the document "shows"that protocols are in fact political is still not, in my re= ading,
borne out.

Se= ction 4 attempts to outline various positions about the claim that
protocols are inherently political.  I think it mostly succe= eds in
this, although I think some of the descriptions ar= e more complete,
more charitable, or both than others.&nb= sp; I continue to suspect that =C2=A74.5
makes the confla= tion I asked about once before, but I can't really
focus = on this such that I could make the case properly.

I really don't understand section 5.  I guess I understand= that it is
an attempt to hook up the discussion of proto= cols and politics to the
function of standards.  Iro= nically, however, this undermines any
argument about prot= ocols being necessarily political based on =C2=A74,
becau= se not every protocol is a standard.  It would seem that a Venn
diagram would show this pretty clearly, but they're hard to mak= e in
ASCII art.

But = the real problem comes in =C2=A76, where claims are made that are
poorly supported by the text, and not obviously true.  For i= nstance,

  Economics, competitio= n, collaboration, openness, and political impact
  = have been an inherent part of the work of the IETF since its early
  beginnings.

strikes = me as a claim that may or may not be empirically true, but it
would need rather a lot of argument to support it.
<= br clear=3D"none">    =E2=80=A6 but [the IETF] does set
  open standards for interoperability on the Internet, = and has done so
  since the inception of the Intern= et. 

is at least possibly false,= since many of the early standards for
Internet interoper= ability were set by the IAB, of which the IETF was a
subs= idiary (see https://tools.ietf.org/html/rfc1120).

    Because a standard is the blue-  print for how to accomplish a particular task, the = adopted standards
  have a normative effect.  =

This claim is belied by the number of= IETF standards that are widely
ignored or have not been = implemented, and it suggests that the IETF
has a kind of = control that it does not actually have (as acknowledged
o= nly in the previous sentence).  The best we can get is that adoptedstandards _may_ have a normative effect, sometimes.  T= hat seems hardly
surprising, but it's also a pretty weak = claim on which to build a
universally-quantified claim ab= out protocols and politics.

I'll numbe= r some propositions in the next passage for ease of
refer= ence:

  [0] Whereas there might = not be agreement among the Internet protocol
  comm= unity on the specific political nature of the technological
  development process and its outputs, [1] it is undisputed that s= tandards
  and protocols are both products of a pol= itical process, [2] and they can
  also be used for= political means.  [3] Therefore protocols and standards
  are not 'value-neutral, [4] and neither is the IETF' [RFC3935]= .  [5] Thus we
  can answer the research quest= ion 'are protocols political' in
  affirmative fash= ion.

In the above, [0] is simply an ac= knowledgemwnt of the differences in
=C2=A74.  [1] ap= pears to be a claim that each of these propositions is true:

    [A] all standards are always a pr= oduct of a political process
    [B] all p= rotocols are always a product of a political process

It is entirely unclear to me that [B] is in fact true, much = less that
it has been demonstrated anywhere in this draft= .  And it seems trivial
to come up with an example w= here this is false -- for instance, the
process where som= e lone programmer writes v0 of some protocol for his
or h= er software such that others can use it (this is sometimes called
"an API", but it's often just as easily described as an immature<= br clear=3D"none">protocol).  At the very least, to call such a proces= s "political" is
to render the meaning of "political" emp= ty.  So, the truth of [1],
which depends on both [A]= and [B] being true, seems suspect to me.

It seems to me that [2] is trivially true, since it is merely a claimabout both protocols and standards being possibly used for= political
means, and as long as we can think of one exam= ple this proposition is
then true.

[3] is a very fast conclusion that, with liberal application= of the
principle of charity, can be rendered thus

    [a] If a thing is both th= e product of a political process and
    p= ossibly used for political means, then it is not value-neutral.

    [b.1] ARGUMENT FROM [1] GOES H= ERE
    therefore
 =    [b] protocols and standards are not value-neutral

    therefore
    [c] Protocols and standards are not valu= e-neutral

(As you can see, [c] is the = same as [3].)  The problem here starts
with the diff= iculty in accepting [1], as I outline above.  If we do
not believe that [1] is demonstrated, then the antecedent of the
conditional in [a] is not shown as [b], so the syllogism that ge= ts us
to [c] can't proceed.  That's the first proble= m.  But the second
problem is in the premise [a] its= elf.  For the truth is that [a] is
just an _assertio= n_ that a political process and use for political
means e= ntails that the result is somehow political.  That is not
actually demonstrated, however, and as a refutation of "the politics<= br clear=3D"none">lies entirely in the human use, not in the object itself"= described in
=C2=A74.1 it is simply begging the question= .  The number of seats in the
Canadian House of Comm= ons is the product of a political process and it
is certa= inly used for political means.  That does not make the number
of seats "political" in itself: it might be just a contingent fac= t
about the current composition of the House of Commons.&= nbsp; In other
words, this depends very much on how one i= nterprets "=CF=86 is political",
which was of course the = very question that was open in the first
place, so the te= xt has reasoned in a circle.

[4] does = not follow from [3] at all, and I don't see how it follows
from any of the other premises either.  I don't know that it matters= ,
because it isn't obvious to me that the draft ever want= ed to make the
claim that the IETF is or is not political= .  One suspects that the
goal is to make an approvin= g appeal to authority of RFC 3935, but it's
hard to tell.=   [5] is false in case [3] does not hold, and since [3]
is in trouble [5] is too.

In case = anyone wanted my recommendation, it would be for the RG to
change the focus of the document:

&n= bsp;   In this document we aim to outline different views on the = relation
  between standards and politics.

This would be enough and would be a contributi= on to the RFC Series
because it would document some posit= ions (in =C2=A74).  In this case =C2=A76
could simpl= y be removed.  I don't know what to do with =C2=A75 because I
don't understand it.  Alternatively, the author could publis= h this
document without it being an RG document, thereby = avoiding the need to
come to consensus on a position that= I believe unlikely to yield such
consensus (mostly becau= se I believe the position to be manifestly
false).

Best regards,

A

--
Andrew = Sullivan
ajs@anvilwalrusden.com
------=_Part_6028594_1763590850.1568777537959-- From nobody Wed Sep 18 06:59:55 2019 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 F260E12009E for ; Wed, 18 Sep 2019 06:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=UxqxOzGa; dkim=pass (1024-bit key) header.d=yitter.info header.b=m9dG/GCk 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 Sq9DsPg0AQA4 for ; Wed, 18 Sep 2019 06:59:51 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D43F12009C for ; Wed, 18 Sep 2019 06:59:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 691E7BCC7D for ; Wed, 18 Sep 2019 13:59:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568815160; bh=JklgjmUilsIbTapeYB+fKRXIEp1bwMeAHCJzSnWYy9Y=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UxqxOzGaV3dRQ85U3w1dmxp1OnZe3QMR1w2ew+X3mSdQVReCYhtKGnJZmtx6EAHSo ih+/SUmA4zyVAGNm7mMSasf1INFQ7eygymR7UTL1STwz71T+CiY2tlnlW8gQBd20K5 s1jBjmNUllwXt7PMcFEEjuMmT4FWtNYpk8rk+WOE= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uupp0kLSSDVr for ; Wed, 18 Sep 2019 13:59:19 +0000 (UTC) Date: Wed, 18 Sep 2019 09:59:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568815159; bh=JklgjmUilsIbTapeYB+fKRXIEp1bwMeAHCJzSnWYy9Y=; h=Date:From:To:Subject:References:In-Reply-To:From; b=m9dG/GCkhwfE02LB0E4fCMpDs8J8SDNYDOM6vPtNAubPxo1lvw+EYDVJIa67VTVv4 q8IZEZ3sMYioOO7AG54N1l7GYDsJkoN7kjePlnzxvOly8eOsn9ejB7aAjjWT+rZHUI yax+TRh6JZhQ7hFS3dZPw/ynxhgDXjZ6r0HbkLvI= From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20190918135917.a4eb66p2banbekuv@mx4.yitter.info> References: <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> <1138709738.5923109.1568749306948@mail.yahoo.com> <20190918013932.eurns5h63oljz2pl@mx4.yitter.info> <296695201.6028595.1568777537962@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <296695201.6028595.1568777537962@mail.yahoo.com> Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 13:59:53 -0000 Hi, On Wed, Sep 18, 2019 at 03:32:17AM +0000, Mark Perkins wrote: > some protocols are developed by groups of people (commercial, academic, non-profit, etc), which are clearly embedded in a political context which constrains/directs their development of protocols; in this case, the protocols can clearly be seen as 'political' as well as 'technical', some more so than others. That formulation repeats the equivocation between "_x_ is developed through a process that includes politics" and "_x_ is political". I guess it is no longer clear to me what "_x_ is political" means. But it seems pretty clear to me that such a conclusion could be used for all sorts of mischief. Look, the US state of Indiana once considered a bill that was supposed to have a method to square the circle and that imputed a value of π≈3.2. Does this mean that the value of π is political? Well, yes, in some trivial sense: it has been the subject of a process that was itself entirely political. But that does not mean that the value of π is political in the ordinary sense of "_x_ is political" or that it would be in any way appropriate to try to use the legislature to settle once and for all the correct way to calculate diameter. I think the manifold sense of "_x_ is political" is obscured rather than clarified at least in §6 of the draft. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Sep 18 08:20:56 2019 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 54CDC120878; Wed, 18 Sep 2019 08:20:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hrpc@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hrpc@irtf.org Message-ID: <156882005427.4606.6393818361687491816@ietfa.amsl.com> Date: Wed, 18 Sep 2019 08:20:54 -0700 Archived-At: Subject: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 15:20:54 -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 RG of the IRTF. Title : Notes on networking standards and politics Author : Niels ten Oever Filename : draft-irtf-hrpc-political-05.txt Pages : 16 Date : 2019-09-18 Abstract: The IETF cannot ordain what standards or protocols are to be used on networks, but the standards development process in the IETF does have an impact on society through its normative standards setting process. This document aims to bring about a better understanding on the political nature of standards and protocols. Among other things, the IETF's work affects what is perceived as technologically possible and useful where networking technologies are being deployed, and its standards reflect what is considered by the technical community to be feasible and good practice. Whereas there might not be agreement among the Internet protocol community on the specific political nature of the technological development process and its outputs, it is undisputed that standards and protocols are both products of a political process, and they can also be used for political means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-hrpc-political-05 https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-05 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 Wed Sep 18 08:28:31 2019 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 542F41208FF for ; Wed, 18 Sep 2019 08:28:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSREGsLIvPCE for ; Wed, 18 Sep 2019 08:28:27 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 DBC7E1208AE for ; Wed, 18 Sep 2019 08:28:26 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iAbs2-0003PO-Hh for hrpc@irtf.org; Wed, 18 Sep 2019 17:28:24 +0200 To: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Wed, 18 Sep 2019 17:27:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <156882005427.4606.6393818361687491816@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d5aa70a8063fc4d8c9ef9eac2991db7d Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 15:28:29 -0000 Dear all, Thank you all very much for your feedback on this draft. Instead of responding to everyone in-line, I thought I'd try to address the issues that are emerging and converging in a new version. The issues, in my analysis, that people agreed upon that needed more work were: - Vocabulary entries are needed on protocols and standards; - The conclusions need to be further qualified; - The research question needs to be better framed; - The introduction needs be better readable; (and several smaller nits). Other ways of structuring and re-structuring were also offered, but they went in directions that I found hard to reconcile. I am curious to hear whether you think these adaptations help address some of your issues. Suggestion, comments, discussion, and pull requests are always welcome: https://github.com/IRTF-HRPC/drafts/blob/master/draft-political.md Best, Niels On 9/18/19 5:20 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Human Rights Protocol Considerations RG of the IRTF. > > Title : Notes on networking standards and politics > Author : Niels ten Oever > Filename : draft-irtf-hrpc-political-05.txt > Pages : 16 > Date : 2019-09-18 > > Abstract: > The IETF cannot ordain what standards or protocols are to be used on > networks, but the standards development process in the IETF does have > an impact on society through its normative standards setting process. > This document aims to bring about a better understanding on the > political nature of standards and protocols. Among other things, the > IETF's work affects what is perceived as technologically possible and > useful where networking technologies are being deployed, and its > standards reflect what is considered by the technical community to be > feasible and good practice. Whereas there might not be agreement > among the Internet protocol community on the specific political > nature of the technological development process and its outputs, it > is undisputed that standards and protocols are both products of a > political process, and they can also be used for political means. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-hrpc-political-05 > https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Wed Sep 18 17:01:26 2019 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 79C1A120091 for ; Wed, 18 Sep 2019 17:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOe9jzt0sOoV for ; Wed, 18 Sep 2019 17:01:22 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D7612004A for ; Wed, 18 Sep 2019 17:01:21 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id y91so1510528ede.9 for ; Wed, 18 Sep 2019 17:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ahYX3a8zRwf7tXANoeJ4AC3Joou6SDznYStNJY3EtO8=; b=t6AAYuKsb6UfpjGfBpgzaQtFKa5i7zrSCUwK8V9czdrYDz36b+F5pgzsSgPJt4HvMi N0t/Vhzog2E9Y70GJqpBTIqscDXHU1YdSTr6P4RRK7t7X3+QcIUP6PM83GZLPqP0mAsA IcZlr9RtNYa3CEb4xeWa1yHeERWwL8uRijL0o7vOzql+7lbCmROTpUOzH2xQsNSo+RWr 5L8gRei4V4utl4veq0+Yk6tEbZ4Ym2Zeib23o5oYdxpthEYqtH5QRZ9khI0IqgfFBiVs x8+MxQjiLAAeNNA/mXWDiNDR/Kz6yizpogXHh0DkYAPtuN637dQIeXxFICJiGSMUgguJ AW7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ahYX3a8zRwf7tXANoeJ4AC3Joou6SDznYStNJY3EtO8=; b=qjrw7liF3vPq9SoMzegU7MYMjKFDl9S4wYgNchA0ugQ1eOPL4o66oVUA6RHDLH/V7L DwStsROFkpcm2MAIVhqyztItn+g/DOYhbvPywsG9cH5k0EOIfp1cieyB7dwW5IhohKbu xWiCdjUvXvAK7FMD3mbOPi9GfLaF8l549d5R0D2RnIwW2SS3nbrZOeUR0AdIA39aP22V kJ6J3pUXOhPdpJ4G1GQTtcM7IRXWpgcSSgDp82pEpvAwGdYTZrgZRkqesj5SzgRi5+5P 3gteLdqooVXvsnQpFvTTr/NHRDbbDCrDPUmhHjdgbvi2TfhcVu26SA9STwXuLd3FDGjh UhyA== X-Gm-Message-State: APjAAAVglZ2k6VDBs8x4yo97mVSqmIFc/1w0wLa7NmhN4HveG6j7sD90 qh8DGYNdoPnC7S3+TC7ZGyGWvpf2lsOaiphjOzA= X-Google-Smtp-Source: APXvYqwN4k7BM5v0DmEWD4kB/lh8q4Ic5fmawXtdX3Ul5QQBiLQssBmvwp2y3R4ywwv8MCBBe/DNg7SeW7YXq5DtPE0= X-Received: by 2002:a50:d2d4:: with SMTP id q20mr5247503edg.172.1568851279963; Wed, 18 Sep 2019 17:01:19 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> In-Reply-To: From: Shivan Date: Wed, 18 Sep 2019 17:00:43 -0700 Message-ID: To: Niels ten Oever Cc: Hrpc Content-Type: multipart/alternative; boundary="0000000000003f6b150592dca75c" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 00:01:25 -0000 --0000000000003f6b150592dca75c Content-Type: text/plain; charset="UTF-8" Hi Niels, thanks for the update. I do think the document is important for the RG. I agree with Andrew Sullivan's breakdown of the argumentation (in the email thread for draft-irtf-hrpc-political-04), and think that Gurshabad's framing would help a lot. Just seeing a discussion about what it means for a "protocol to be political" would be immediately helpful - is it just shorthand for saying "process is political && impact is political"? On Wed, Sep 18, 2019 at 8:28 AM Niels ten Oever wrote: > Dear all, > > Thank you all very much for your feedback on this draft. Instead of > responding to everyone in-line, I thought I'd try to address the issues > that are emerging and converging in a new version. The issues, in my > analysis, that people agreed upon that needed more work were: > > - Vocabulary entries are needed on protocols and standards; > - The conclusions need to be further qualified; > - The research question needs to be better framed; > - The introduction needs be better readable; > (and several smaller nits). > > Other ways of structuring and re-structuring were also offered, but they > went in directions that I found hard to reconcile. > > I am curious to hear whether you think these adaptations help address some > of your issues. > > Suggestion, comments, discussion, and pull requests are always welcome: > > https://github.com/IRTF-HRPC/drafts/blob/master/draft-political.md > > Best, > > Niels > > > On 9/18/19 5:20 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Human Rights Protocol Considerations RG > of the IRTF. > > > > Title : Notes on networking standards and politics > > Author : Niels ten Oever > > Filename : draft-irtf-hrpc-political-05.txt > > Pages : 16 > > Date : 2019-09-18 > > > > Abstract: > > The IETF cannot ordain what standards or protocols are to be used on > > networks, but the standards development process in the IETF does have > > an impact on society through its normative standards setting process. > > This document aims to bring about a better understanding on the > > political nature of standards and protocols. Among other things, the > > IETF's work affects what is perceived as technologically possible and > > useful where networking technologies are being deployed, and its > > standards reflect what is considered by the technical community to be > > feasible and good practice. Whereas there might not be agreement > > among the Internet protocol community on the specific political > > nature of the technological development process and its outputs, it > > is undisputed that standards and protocols are both products of a > > political process, and they can also be used for political means. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-irtf-hrpc-political-05 > > https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-05 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > -- > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --0000000000003f6b150592dca75c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Niels, thanks for the = update. I do think the=C2=A0document=C2=A0is important for the RG.=C2=A0

I=C2=A0agree with Andrew Sullivan's breakdown of the argumentation = (in the email thread for=C2=A0draft-irtf-hrpc-political-04), and think that= Gurshabad's framing would help a lot. Just seeing a discussion about w= hat it means for a "protocol to be political" would be immediatel= y helpful - is it just=C2=A0shorthand for saying "process is political= && impact is political"?=C2=A0


On Wed, Sep 18, 2019 at 8:28 AM Niels ten Oever <mail@nielstenoever.net> wrote:<= br>
Dear all,

Thank you all very much for your feedback on this draft. Instead of respond= ing to everyone in-line, I thought I'd try to address the issues that a= re emerging and converging in a new version. The issues, in my analysis, th= at people agreed upon that needed more work were:

- Vocabulary entries are needed on protocols and standards;
- The conclusions need to be further qualified;
- The research question needs to be better framed;
- The introduction needs be better readable;
(and several smaller nits).

Other ways of structuring and re-structuring were also offered, but they we= nt in directions that I found hard to reconcile.

I am curious to hear whether you think these adaptations help address some = of your issues.

Suggestion, comments, discussion, and pull requests are always welcome:

https://github.com/IRTF-HRPC/draft= s/blob/master/draft-political.md

Best,

Niels


On 9/18/19 5:20 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Human Rights Protocol Considerations = RG of the IRTF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Notes on networking standards and politics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Niels ten Oever
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= irtf-hrpc-political-05.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 16
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-09-18
>
> Abstract:
>=C2=A0 =C2=A0 The IETF cannot ordain what standards or protocols are to= be used on
>=C2=A0 =C2=A0 networks, but the standards development process in the IE= TF does have
>=C2=A0 =C2=A0 an impact on society through its normative standards sett= ing process.
>=C2=A0 =C2=A0 This document aims to bring about a better understanding = on the
>=C2=A0 =C2=A0 political nature of standards and protocols.=C2=A0 Among = other things, the
>=C2=A0 =C2=A0 IETF's work affects what is perceived as technologica= lly possible and
>=C2=A0 =C2=A0 useful where networking technologies are being deployed, = and its
>=C2=A0 =C2=A0 standards reflect what is considered by the technical com= munity to be
>=C2=A0 =C2=A0 feasible and good practice.=C2=A0 Whereas there might not= be agreement
>=C2=A0 =C2=A0 among the Internet protocol community on the specific pol= itical
>=C2=A0 =C2=A0 nature of the technological development process and its o= utputs, it
>=C2=A0 =C2=A0 is undisputed that standards and protocols are both produ= cts of a
>=C2=A0 =C2=A0 political process, and they can also be used for politica= l means.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dra= ft-irtf-hrpc-political/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-= hrpc-political-05
> https://datatracker.ietf.org/= doc/html/draft-irtf-hrpc-political-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-irtf-hrpc-political-05
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc
>

--
Niels ten Oever
Researcher and PhD Candidate
DATACTIVE Research Group
University of Amsterdam

PGP fingerprint=C2=A0 =C2=A0 2458 0B70 5C4A FD8A 9488=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0643A 0= ED8 3F3A 468A C8B3

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--0000000000003f6b150592dca75c-- From nobody Thu Sep 19 12:46:30 2019 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 B4620120152 for ; Thu, 19 Sep 2019 12:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 DQJxZfTH04p5 for ; Thu, 19 Sep 2019 12:46:26 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id D803B120129 for ; Thu, 19 Sep 2019 12:46:26 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.140.165]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id x8JJjpYH028049 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2019 12:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1568922381; x=1569008781; i=@elandsys.com; bh=E1Z6SRCQaU2sQktdXnvMKsG6AUVtXrt4aHS4kNprAdo=; h=Date:To:From:Subject; b=BpRjLS7LUy4Uv2RjGLCT4KLSLHnSHdF83cbrkcvn1g6D3RZ2ykKjH10CjhOmTJ/oz Art0QhnKfUSDMRwDraDmqQoB0NuvTg79M7JMdPxvZE/sdTuXGkSnlaeW4kvT9P1r6a szQexex1MVKIIyc0bjWTMkGq7KArxFY0n9vh7BIY= Message-Id: <6.2.5.6.2.20190919123748.0745a0c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Sep 2019 12:45:31 -0700 To: avri@doria.org, hrpc@irtf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 19:46:28 -0000 Dear Avri, >SM & Eliot, are you satisfied with the way your comments were addressed? Thank you for asking for feedback. The comment was about something which I noticed. I am okay with the way it was addressed. Regards, S. Moonesamy From nobody Thu Sep 19 13:46:18 2019 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 3C7C512006A for ; Thu, 19 Sep 2019 13:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 R5z6eQIH5skf for ; Thu, 19 Sep 2019 13:46:12 -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 6E730120129 for ; Thu, 19 Sep 2019 13:46:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC55EBE51 for ; Thu, 19 Sep 2019 21:46:08 +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 iE_2EGnXXOWw for ; Thu, 19 Sep 2019 21:46:06 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F0497BE53 for ; Thu, 19 Sep 2019 21:46:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1568925966; bh=X2klU2mFG6iMgoHh2YZ0sDv9CA2S4nhmYD0zhOanp60=; h=Subject:To:References:From:Date:In-Reply-To:From; b=N+Zd5+YQEzDigeymafV/yiqWtPvTC9muJhYSE29tmDRa+OEh97pdfwqJvGlDcev8a gQdLK6FSDeVnd9JFUX8jYNI4PGSCAgM+C4WMqWPBevTFGit2MfBZ3SfmWtJ/0tKzMz CPOicdTM0Dh7NwF8MojOpN74RbReU6D61kphdoEE= To: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 19 Sep 2019 21:46:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156882005427.4606.6393818361687491816@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K2daFOFqxA5w11STTPuB6zQzU7LTQtv3F" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 20:46:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K2daFOFqxA5w11STTPuB6zQzU7LTQtv3F Content-Type: multipart/mixed; boundary="uK3TvQr4vU8UHb831fncBQQiAZ78s2ekK"; protected-headers="v1" From: Stephen Farrell To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> In-Reply-To: <156882005427.4606.6393818361687491816@ietfa.amsl.com> --uK3TvQr4vU8UHb831fncBQQiAZ78s2ekK Content-Type: multipart/mixed; boundary="------------6BE239129614F264D2031C14" Content-Language: en-GB This is a multi-part message in MIME format. --------------6BE239129614F264D2031C14 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I had a read of -05. I didn't read (but just skimmed) all the other comments before doing that so apologies if my comments repeat (or utterly contradict:-) others that've been sent to the list already. Cheers, S. General: - Overall, I don't think this is ready. I do think it could be with some more work, maybe another rev or two. Or it might take longer, not sure. - If the authors didn't want to try aim for RG consensus on all of the text, then I think that'd make it easier to get an RFC published. I'd be ok with that, though I still think it'd need another rev or two (but the changes might be easier/less). - I'd argue to entirely re-do or delete section 5. I see why it's included but I think in the end it didn't work out to be useful in the same document as section 4. Detailed comments: - "undisputed" in the abstract is likely to be disputed:-) By readers, I mean. s/undisputed/seems evident to the authors/ or something might be better. - intro: the Callon quote could do with a reference so readers can go find more context if they want. The first sentence of that quote could mean lots of different things and I've no idea what exactly was meant - I'd ditch that sentence or maybe the entire quote. - intro: "affordances" - I've heard that term a number of times, but I don't think I really understand it. Also - how are users "shaped"? I think you could have said that "people are affected by" the technology, left it at that and been clearer. (I see you define that in section 2, so I do get it now that I've gotten that far. Still might be better to avoid the forward reference if possible.) - intro: does the document really "seek to answer" the question or rather try to explore the question? The latter seems more tractable. - intro: "The design of the Internet through protocols and standards..." That seems to ignore the "running code" aspect which is critical to understanding how the Internet has arisen and evolves. - The URL for [BramamI] doesn't work for me - my browser times out on that. (And why http and not https? :-) As below, it'd be better to say a bit more about i18n here - it's fairly obvious but no harm expanding the bullet beyond one word. - intro: The reference to RFC101 (better that than RFC0101 btw:-) is unclear to me. There are many occurrences of the word access in that RFC so what's meant by the bullet point here? It's not clear to me. - intro: same point about rfc49 - that has two mentions of "security" neither of which seem that relevant to this draft, so maybe say what/why that reference is for. (And there may be a better one, if what you've done is try find the earliest reference, that might not be the best thing.) - intro: same points for the other early RFC references and I guess [BramanII]. - intro: "This has been clearly shown in the work done by Sandra Braman..." - what "this" do you mean has been shown? It's not clear to this reader. - section 3: Suggest s/Answering/Exploring/ - section 4: RFC1087 says "The Internet is a national facility..." so I wonder if it's really so obvious a basis for the argument here. The problem is that 1087 kinda says "be ethical or we'll tell the Feds" and there aren't really equivalent Feds for today's Internet, so the sentence here could be a bit misleading. Maybe better to qualify the reference here with something like "... even if the Internet in 1989 was largely a US thing, similar problems and requirements for ethical behaviour ought still apply." Not sure. - 4.1: I note the references here are from 1991 and 1992 - isn't there a more recent expression of this position that could be quoted? It left me wondering if the referenced authors might have changed their positions since (I've no idea if they have or not, just wondering, as my own ideas now are not what they were then:-) - 4.2: This one is closest to my own position, but I wouldn't go along with "requires" which is far too strong - for me it's more like this position "implies that protocols could be evaluated for..." - 4.3: Even if the Internet is too complex, that doesn't imply anything for any one protocol. The rest of the 4.3 text also seems unclear to me. I'd say a rewrite of this section would be good. - 4.4: "The network..." do you mean the Internet or one of the networks that make up the Internet here? Or do you mean any network of networks? I assume you mean any network of networks, like the Internet but I'm not sure. - 4.4: This seems to finish early or something. The end of the section talks about social and technical but never says political so I'm unsure what a proponent of this position might believe vs. the other positions in section 4. - 4.5 (1): I've no clue what the emotional bias of a medium such as audio might be, or am I missing the point? - 4.5 (2): "speed of their information" is an odd phrase, and I'm not sure what's meant. - 4.5: IMO the raven process was an attempt to be technical and apolitical, at least as understood by some participants. It's likely incorrect to give the impression that everybody thinks that the raven process was "largely political." (I do agree that many people think that.) Similarly, while I agree that what "engendered" 7258 was Snowdonia, I do not agree that 7258 requires any justification that is non-technical (i.e. IMO 2804 and 7258 and 1984 can all be sufficiently justified on purely technical grounds). Again, I think the change to make here is to say that someone espousing the position of 4.5 might agree with the current text, but that those statements about 2804 and 7258 are not universally accepted. - 4.5: Neither 2804 nor 7258 are protocol specifications. For me that significantly weakens the overall argument proposed in 4.5. Surely soeomne who espouses this position could provide at least one actual protocol example? Presumably something that refers to 2804 or 7258 might suffice, but without that, there's a hole in the argument. (Not that I agree with the argument in 4.5, but I feel better disagreeing with something that isn't holed beneath the water line:-) - 4.5: "consumer class" seems wrong to me. I don't believe there's what I'd call a "consumer class" for NTP for example. I'm not clear from the phraseology as to whether the authors are asserting that espousing 4.5 means agreeing with Winner here or not. In any case, I think Winner is wrong here, for some protocols. - section 5: "the different existing positions" - that's a claim that secction 4 has the full set. My bet is that I could easily find an IETFer who espouses none of the above. s/the/some/ is better. Or you could say those are the postions that were considered in this work. - section 5: s/were created/are created/ and "formal" isn't quite right - TLS1.3 is getting closer to formal since bits of it were formally verified but it is not formally specified in one well-known sense of the term. s/formal// would be my suggestion. (I guess you just mean "written down" by this use of "formal" which seems unnecessary to me.) - section 5: "100% royalty-free"? What? I'm misundertanding something here. We had years of RSA and ECC being encumbered to the detriment of the Internet IMO, but 100% seems just wrong or else must be a badly stated statement of something else? - 5.1: "enhance competition" may be true sometimes but is a) not always true (I'll try assert NTP again as an example) and b) is far down my list of why to do work in the IETF, but is presented as if we all think this is the most important thing ever. - 5.1: the discussion of "de facto" seems broken to me. Consider RFC 3986 vs. whatwg for a real example that doesn't seem to fit your description. (And I barf again at the mention of competition law for such things as URL syntax:-) - 5.1: mention of ISO, BIS... etc with no references or URLs seems wrong. (I've no idea what ABNT is for example, but I guess it's not what first shows up in my search [1].) [1] https://acronyms.thefreedictionary.com/ABNT - 5.4: Are the authors agreeing with [Nadvi] or not? I think you ought be clear. I'm not sure I'd agree that applies to the IETF though, as IETF participants don't, in general, seem to me to be well-decscribed as "transnational stakeholders" even though some or many of them may be. I don't feel like one of those anyway;-) - 5.4: The big [RogersEden] quote goes against IETF lore. I forget where we have that written down in an RFC but I think we do. (Where "that" is "don't just end up with the union of the input proposals but instead try find the right outcome" or something like that. - Section 5 generally: I was left thinking "huh, what was the point of that section" when I finished reading that. I think you could mostly delete the entire section and be ok. - Section 6: I'd be happier if statements such as your opener did not depend on buying books. Haven't Russel or Abate ever written these arguments down in something openly accessible? (And BramanII is still a broken link.) I don't think you've made the case via text or accessible references that this opening conclusion statement is correct. (I may agree with it, but I don't think you can justify it based on this.) - Section 6: "undisputed" again - I dispute that that's the right term. - Section 6: I do not accept the [Russell] quote as being correct but haven't bought his/her book. I don't think you ought present that quote as being an accepted statement. - Section 6: I dispute that the implementation of protocols "is" political. I wrote some code last night for an I-D. That was not a politcal act (I assert). - Section 6: I dispute that "protocols can never be understood" without some inherently political framing. (If that's what you meant.) I can teach kids about TLS and they can understand the protocol without all the political add-ons. As it happens I do think they better understand what TLS is and how it's used, if I include some bits of that, but I don't believe it's needed for them to understand the protocol itself. - Section 6: I dunno if I agree about the future research. --------------6BE239129614F264D2031C14 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------6BE239129614F264D2031C14-- --uK3TvQr4vU8UHb831fncBQQiAZ78s2ekK-- --K2daFOFqxA5w11STTPuB6zQzU7LTQtv3F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2D6QwACgkQWrL68XsX K+r+7g/+M6U0jTs983C/in/DxTVSdbAOuYj6xj/5JTk1c3EbIjRXlFg3BDNpgsU3 8ugmsVIV6Q53oiQ9wB/1yCZkBeSInZcjPUtITomVg1znLVEjRpdW5OhaXOf+B3HW EI3VqNoBeaOHNe0hXKXBw16ARCLmpb1FeaKzRkbfEpND2sFt3wYBd5Vot2gOZRYC WqoOtCx117oq2Rvdhe/TYPbySzD+eS1g63m59S2UKOQ/Ch81hNyCGCXmv5v/+506 15oxIN9ixSDeLqFglxdvFd4J9L4Yi3fI4a+PqtvXB/VjFnqQ9Xs8CSwlfyJWiVs+ pTG8cBHAr1CWEqPy7qvBmQUPYur2W6dIwj0sSN9jXvrFZ0yp4Q01IGw01YYkQLqz Rr3rb545dvhUTK/PkuBJ8pjsysXwtSSZF9WNaNZ/XMfvgrYqvPqo+HkghMvQ7Vs6 bBv1OBF8OmDYoBbgCI5ikEiEWStrPy+KWOeFNtxCnKEvck6PMnXBfXaOfms+8nba bTgLWYIHwUJBlDzLxLjXaPCcjllmT7+SjPC1lpf/R48liAkjQfgGqVt89UpU7rVX BjEdHbkTd4N0RiAbXoR8HVWITLB2NSAhmXIffIJeYbFPM8BO5ChttzawPCTmKUcq YXKbxIw7GfYR2BJ/OVYK1HgslrDZjjYLMh+9VOSZ4QrHOrJ0Mjo= =liGx -----END PGP SIGNATURE----- --K2daFOFqxA5w11STTPuB6zQzU7LTQtv3F-- From nobody Fri Sep 20 05:46:59 2019 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 44B7E120098 for ; Fri, 20 Sep 2019 05:46:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb_hix5Ek0l4 for ; Fri, 20 Sep 2019 05:46:53 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 4379212003F for ; Fri, 20 Sep 2019 05:46:52 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iBIIl-0004EY-Rm for hrpc@irtf.org; Fri, 20 Sep 2019 14:46:50 +0200 To: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Fri, 20 Sep 2019 14:46:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oOvsOZa6wvL2sOAfFqTkd0E5MYYaN9GxY" X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 13680c0b130c155475ecde42c45f1d6c Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 12:46:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oOvsOZa6wvL2sOAfFqTkd0E5MYYaN9GxY Content-Type: multipart/mixed; boundary="J6VYZnOjjkCY5FH0QAYrPNer8g12aZRh8"; protected-headers="v1" From: Niels ten Oever To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> In-Reply-To: --J6VYZnOjjkCY5FH0QAYrPNer8g12aZRh8 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks for this detailed review Stephen. Because there was some quiet on the list (which might indicate some level= of agreement (either with -05 and/or Stephen's comments, but I'll leave = that to others to decide), I wrote a detailed response underneath and mad= e changes in version -06. On 9/19/19 10:46 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > I had a read of -05. I didn't read (but just skimmed) all > the other comments before doing that so apologies if my > comments repeat (or utterly contradict:-) others that've > been sent to the list already. >=20 > Cheers, > S. >=20 > General: >=20 > - Overall, I don't think this is ready. I do think it could be with > some more work, maybe another rev or two. Or it might take longer, > not sure. >=20 Working on next rev :) > - If the authors didn't want to try aim for RG consensus on all of > the text, then I think that'd make it easier to get an RFC > published. I'd be ok with that, though I still think it'd need > another rev or two (but the changes might be easier/less). >=20 I'll leave that decision to the RG chairs. I am happy with either. But I = do see this as a product of the discussions in hrpc, so publishing it out= side of that would not do justice to the document and the people that con= tributed to it imho. > - I'd argue to entirely re-do or delete section 5. I see why it's > included but I think in the end it didn't work out to be useful in > the same document as section 4. >=20 I removed section 5, but kept two para's and added them to the intro. > Detailed comments: >=20 > - "undisputed" in the abstract is likely to be disputed:-) By > readers, I mean. s/undisputed/seems evident to the authors/ or > something might be better. >=20 I do think it _is_ undisputed that the standards creation process is poli= tical and that they can be used for political means, right? But to make i= t go down easier: s/undisputed/generally agreed=20 > - intro: the Callon quote could do with a reference so readers can go > find more context if they want. The first sentence of that quote > could mean lots of different things and I've no idea what exactly was > meant - I'd ditch that sentence or maybe the entire quote. >=20 Callon is one of the parents of Science and Technology Studies, but I do = agree that outside of the discipline, this quote might seem open for a lo= t of different interpretations. I removed it, with pain in my heart, and = replaced it with two more specific quotes from the literature on standard= s. > - intro: "affordances" - I've heard that term a number of times, but > I don't think I really understand it. Also - how are users > "shaped"? I think you could have said that "people are affected by" Suggestion accepted and changed. > the technology, left it at that and been clearer. (I see you define > that in section 2, so I do get it now that I've gotten that far. > Still might be better to avoid the forward reference if possible.) >> - intro: does the document really "seek to answer" the question or > rather try to explore the question? The latter seems more > tractable. > Accepted and changed. =20 > - intro: "The design of the Internet through protocols and > standards..." That seems to ignore the "running code" aspect which > is critical to understanding how the Internet has arisen and evolves. >=20 It doesn't say 'exclusively through', but I appreciate the point. I chang= ed it into: The design of the Internet, and its codification through protocols and st= andards, is a technical issue with great political and economic impacts, = as is described in {{RFC0613}} and {{RFC3271}}.=20 > - The URL for [BramamI] doesn't work for me - my browser times out on > that.=20 Fixed BramanI and Braman two, unfortunately Texas A&M does not offer TLS = for this URI (And why http and not https? :-)=20 > As below, it'd be better to > say a bit more about i18n here - it's fairly obvious but no harm > expanding the bullet beyond one word. >=20 Am afraid this would deviate from the main point, since these are just il= lustrations. Previously the bullets were comma's, but Ted and Paul object= ed against that because with the references it impacted the readability. But it indeed seems weird to have one word bullets, so I added one senten= ce summaries. > - intro: The reference to RFC101 (better that than RFC0101 btw:-) is > unclear to me. There are many occurrences of the word access in > that RFC so what's meant by the bullet point here? It's not clear to > me. >=20 'how people are able to access the network, and who has control {{RFC0101= }};' > - intro: same point about rfc49 - that has two mentions of "security" > neither of which seem that relevant to this draft, so maybe say > what/why that reference is for. (And there may be a better one, if > what you've done is try find the earliest reference, that might not > be the best thing.) Added better reference and added privacy, as well as a description: * privacy and security {{BramanIII}};=20 >=20 > - intro: same points for the other early RFC references and I guess > [BramanII]. >=20 > - intro: "This has been clearly shown in the work done by Sandra > Braman..." - what "this" do you mean has been shown? It's not clear > to this reader. >=20 Changed into:=20 Sandra Braman has foregrounded these political consideration in historica= l RFC in her extensively analysis of these documents {{BramanII}}. > - section 3: Suggest s/Answering/Exploring/ >=20 Accepted and changed > - section 4: RFC1087 says "The Internet is a national facility..." so > I wonder if it's really so obvious a basis for the argument here. > The problem is that 1087 kinda says "be ethical or we'll tell the > Feds" and there aren't really equivalent Feds for today's Internet, > so the sentence here could be a bit misleading. Maybe better to > qualify the reference here with something like "... even if the > Internet in 1989 was largely a US thing, similar problems and > requirements for ethical behaviour ought still apply." Not sure. >=20 Hmmm. This sentence does not say that the Internet is still the same, rig= ht? Just that is has been extensively discussed in earlier days? But I've changed the sentence into: Ethics and the Internet was already a topic of an RFC by the IAB in 1989 = {{RFC1087}}, when the Internet was still looking entirely different. > - 4.1: I note the references here are from 1991 and 1992 - isn't > there a more recent expression of this position that could be > quoted? It left me wondering if the referenced authors might have > changed their positions since (I've no idea if they have or not, just > wondering, as my own ideas now are not what they were then:-) >=20 This is a relatively classical expression of this position, that is why I= went with the classical definition of it (and the author expressing it).= =20 > - 4.2: This one is closest to my own position, but I wouldn't go > along with "requires" which is far too strong - for me it's more > like this position "implies that protocols could be evaluated for..." >=20 Changed. > - 4.3: Even if the Internet is too complex, that doesn't imply > anything for any one protocol.=20 It means that the interrelation between protocols in hard to predict. The rest of the 4.3 text also seems > unclear to me. I'd say a rewrite of this section would be good. >=20 Added text and sought to increase readability. > - 4.4: "The network..." do you mean the Internet or one of the > networks that make up the Internet here? Or do you mean any network > of networks? I assume you mean any network of networks, like the > Internet but I'm not sure. >=20 Fixed that by making it all 'network of networks' > - 4.4: This seems to finish early or something. The end of the > section talks about social and technical but never says political > so I'm unsure what a proponent of this position might believe vs. the > other positions in section 4. >=20 > - 4.5 (1): I've no clue what the emotional bias of a medium such as > audio might be, or am I missing the point? >=20 What is meant here that a newspaper instills a very different perception = than radio does. But to decrease misunderstanding I removed the second pa= rt of that sentence. > - 4.5 (2): "speed of their information" is an odd phrase, and I'm not > sure what's meant. >=20 I think we can safely assume high bandwith and low latency is what is mea= nt here. > - 4.5: IMO the raven process was an attempt to be technical and > apolitical, at least as understood by some participants. It's > likely incorrect to give the impression that everybody thinks that > the raven process was "largely political." (I do agree that many > people think that.)=20 > Similarly, while I agree that what "engendered" > 7258 was Snowdonia, I do not agree that 7258 requires any > justification that is non-technical (i.e. IMO 2804 and 7258 and 1984 > can all be sufficiently justified on purely technical grounds). > Again, I think the change to make here is to say that someone > espousing the position of 4.5 might agree with the current text, but > that those statements about 2804 and 7258 are not universally > accepted. OK, I propose the following: The Raven process in which the IETF refused to standardize wiretapping --= which resulted in {{RFC2804}} -- was an instance where an international = governance body took a position that was perceived by many as political, = although driven by a technical argument.=20 >=20 > - 4.5: Neither 2804 nor 7258 are protocol specifications. For me > that significantly weakens the overall argument proposed in 4.5. > Surely soeomne who espouses this position could provide at least one > actual protocol example? Presumably something that refers to 2804 or > 7258 might suffice, but without that, there's a hole in the argument. > (Not that I agree with the argument in 4.5, but I feel better > disagreeing with something that isn't holed beneath the water line:-) >=20 Added: The Raven process in which the IETF refused to standardize wiretapping --= which resulted in {{RFC2804}} -- was an instance where an international = governance body took a position that was perceived by many as political, = although driven by a technical argument. The process that led to {{RFC725= 8}} is similar: the Snowden disclosures, which occurred in the political = space, engendered the IETF to act. While {{RFC2804}} was a statement abou= t how a protocol for wiretapping would _not_ be developed, {{RFC7258}} wa= s a statement that contributed to the development of protocols such as {{= RFC7858}}, {{RFC8226}}, and {{RFC8404}}. The impact of political tensions= on protocol development is summarized in {{Abbate}} who says: "protocols= are politics by other means," emphasizing the interests that are at play= in the process of designing standards. > - 4.5: "consumer class" seems wrong to me. I don't believe there's > what I'd call a "consumer class" for NTP for example. I'm not clear > from the phraseology as to whether the authors are asserting that > espousing 4.5 means agreeing with Winner here or not. In any case, I > think Winner is wrong here, for some protocols. Removed 'consumer class', to avoid discussions about class, groups, and c= onsumerism. I would offer the following: Those who had the power to introduce a new technology also had the power = to largely frame the uses of the technology "with new practices, relation= ships, and identities supplanting the old, --- and those who had the wher= ewithal to implement new technologies often molded society to match the n= eeds of emerging technologies and organizations." {{Winner}}. >=20 > - section 5: "the different existing positions" - that's a claim that > secction 4 has the full set. My bet is that I could easily find an > IETFer who espouses none of the above. s/the/some/ is better. Or you > could say those are the postions that were considered in this work. >=20 Removed > - section 5: s/were created/are created/ and "formal" isn't quite > right - TLS1.3 is getting closer to formal since bits of it were > formally verified but it is not formally specified in one well-known > sense of the term. s/formal// would be my suggestion. (I guess you > just mean "written down" by this use of "formal" which seems > unnecessary to me.) >=20 Removed > - section 5: "100% royalty-free"? What? I'm misundertanding something > here. We had years of RSA and ECC being encumbered to the detriment > of the Internet IMO, but 100% seems just wrong or else must be a > badly stated statement of something else? >=20 Removed > - 5.1: "enhance competition" may be true sometimes but is a) not > always true (I'll try assert NTP again as an example) and b) is far > down my list of why to do work in the IETF, but is presented as if we > all think this is the most important thing ever. >=20 Removed > - 5.1: the discussion of "de facto" seems broken to me. Consider RFC > 3986 vs. whatwg for a real example that doesn't seem to fit your > description. (And I barf again at the mention of competition law for > such things as URL syntax:-) >=20 Removed > - 5.1: mention of ISO, BIS... etc with no references or URLs seems > wrong. (I've no idea what ABNT is for example, but I guess it's not > what first shows up in my search [1].) >=20 > [1] https://acronyms.thefreedictionary.com/ABNT Removed >=20 > - 5.4: Are the authors agreeing with [Nadvi] or not? I think you > ought be clear. I'm not sure I'd agree that applies to the IETF > though, as IETF participants don't, in general, seem to me to be > well-decscribed as "transnational stakeholders" even though some or > many of them may be. I don't feel like one of those anyway;-) I've added that these are not exclusively transnational corporations. >=20 > - 5.4: The big [RogersEden] quote goes against IETF lore. I forget > where we have that written down in an RFC but I think we do. (Where > "that" is "don't just end up with the union of the input proposals > but instead try find the right outcome" or something like that. Removed >=20 > - Section 5 generally: I was left thinking "huh, what was the point > of that section" when I finished reading that. I think you could > mostly delete the entire section and be ok. >=20 Done > - Section 6: I'd be happier if statements such as your opener did not > depend on buying books. Haven't Russel or Abate ever written these > arguments down in something openly accessible? =20 Nopes, they did not publish their papers in open access journals. I do ha= ve a problem with that, but I am afraid that is beyond my power to fix.=20 > (And BramanII is > still a broken link.)=20 Fixed > I don't think you've made the case via text or > accessible references that this opening conclusion statement is > correct. (I may agree with it, but I don't think you can justify it > based on this.) >=20 > - Section 6: "undisputed" again - I dispute that that's the right > term. s/undisputed/generally agreed >=20 > - Section 6: I do not accept the [Russell] quote as being correct but > haven't bought his/her book. I don't think you ought present that > quote as being an accepted statement. Made that more clear. >=20 > - Section 6: I dispute that the implementation of protocols "is" > political. I wrote some code last night for an I-D. That was not a > politcal act (I assert). >=20 Would adding 'often' help? While understanding that 'standards emerge from contested contexts, they = immediately function as a means of control within the political and econo= mic order' {{Russell}}, protocols and standards as abstract isolated arte= facts might not be political, but their design, development, deployment, = and implementation often is. > - Section 6: I dispute that "protocols can never be understood" > without some inherently political framing. (If that's what you > meant.) I can teach kids about TLS and they can understand the > protocol without all the political add-ons. As it happens I do think > they better understand what TLS is and how it's used, if I include > some bits of that, but I don't believe it's needed for them to > understand the protocol itself. >=20 I propose: 'Therefore we might need to give a qualified answer to the research quest= ion, in the sense that protocols can only be understood in part outside o= f their actual shaping, use, and applied function, which is political.' > - Section 6: I dunno if I agree about the future research. Would you care to elaborate? Happy to sketch other paths forward.=20 Thanks again and happy to discuss. Best, Niels PS If other people think their point(s) is a/are showstopper(s) and shoul= d be addressed, feel free to re-up your comments or message me off-list s= o I can address them in a following version. >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --=20 Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 643A 0ED8 3F3A 468A C8B3 --J6VYZnOjjkCY5FH0QAYrPNer8g12aZRh8-- --oOvsOZa6wvL2sOAfFqTkd0E5MYYaN9GxY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl2EyhsACgkQDtg/OkaK yLOyrQ//abipeW5OA/A6Vw2g+DttU8Yfpb1etNwrigCbdZaVa3j4P72VhQ1VzJzo 4l7Mrjx2TqUtqBGmxnlQIlRyMkyLhS27m0k7GhN91szZrWvUek7jlk5sT18FsFJC x48xJST4HV2G8YSfTjRZmKq09IHAbspU7hgASk8RUruURDDpQNjUTr6p8psD8diz PTr3xtuFHosRovQ/lT6RswgUVqSqvipYhArKXGFwhEHGLtc4aO/EBI53cED8eWak iEcX03S7PKTQ/GLnvEwdO+tQtNWW0BES9ZTaD2f2MT0UzqgcEJoXb5tdQdTHHVOI Vj6cmiTKW9PElx62kAF1S7VqZ7OJ7OhrkZ13syDhvRYGPy0sQS8SgzC5Lwr/7K0A w8XxdmbHWowhXPyu97rEK4/2gImc/a+1BYZXCvutCD0lzEP0aPb16N8VDVzZL4Z+ C/Wot+hs5XNbeg2xMO3VRqgkHX4zLR1ZowYnIm9I1M+FnYwpOlpiV8WZqNBfbMxi 6OCOoeEsCG5qEzKjwUkwbDu7MJXjf5U7tm/ITSp6WLYWXnogo/k58sRjtoFemvZz 7098zC3GmMlP3Dm4wQF3Av9InJ5324rbpqrNgzNrGhRKkij2LB3er7unSXb3f2uw SGdlBiGT3HuCSKY3oHvctLps9RxYLxFRDEz6/d9F9bbe+leNzlQ= =JLQU -----END PGP SIGNATURE----- --oOvsOZa6wvL2sOAfFqTkd0E5MYYaN9GxY-- From nobody Fri Sep 20 05:48:53 2019 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 E0E2912003F; Fri, 20 Sep 2019 05:48:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hrpc@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hrpc@irtf.org Message-ID: <156898373085.30287.13601344831913215147@ietfa.amsl.com> Date: Fri, 20 Sep 2019 05:48:50 -0700 Archived-At: Subject: [hrpc] I-D Action: draft-irtf-hrpc-political-06.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 12:48:51 -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 RG of the IRTF. Title : Notes on networking standards and politics Author : Niels ten Oever Filename : draft-irtf-hrpc-political-06.txt Pages : 14 Date : 2019-09-20 Abstract: The IETF cannot ordain what standards or protocols are to be used on networks, but the standards development process in the IETF does have an impact on society through its normative standards setting process. This document aims to bring about a better understanding on the political nature of standards and protocols. Among other things, the IETF's work affects what is perceived as technologically possible and useful where networking technologies are being deployed, and its standards reflect what is considered by the technical community to be feasible and good practice. Whereas there might not be agreement among the Internet protocol community on the specific political nature of the technological development process and its outputs, it is generally agreed that standards and protocols are both products of a political process, and they can also be used for political means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-hrpc-political-06 https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 20 08:57:06 2019 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 0DF0B12026E for ; Fri, 20 Sep 2019 08:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5f2CDRxCby3 for ; Fri, 20 Sep 2019 08:57:03 -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 078FC12024E for ; Fri, 20 Sep 2019 08:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3233; q=dns/txt; s=iport; t=1568995023; x=1570204623; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=l9TbtKaYikcnpxk8AjsGYYovVr3L+pVlqm6uh42q0v4=; b=KWES04ne7qZFHmy+flgHE20nyohsBzWZ9CQ38kXu17VUPbIQUGvA7JIO +4tGMoBgMJIU+Yh99B69erNPIqZUallWCb9jN9DTnuXPD0827DidHgxfo oybQxpTghODf62lzXUOCPigS3v6e1TfyYFS8Hxy/mynUpK3kC4ChPLw3K M=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADQ9YRd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgRuCQiASKow+YId8JYdEi1OGC4F7Agc?= =?us-ascii?q?BAQEJAwEBLwEBhD8Cgyw0CQ4CAwkBAQQBAQECAQUEbYU5hUoBAQEBAgF5BQs?= =?us-ascii?q?LBAETLlcGE4MiAYF7D608hUyEbhCBNAGBUIpQgX+BOAwTgkw+hCQBAYNbgiY?= =?us-ascii?q?ElgKXC4Isgi6BE5FJG5kmpCCDEQIEBgUCFYFSOIFYMxoIGxVlAYJBPhIQFJA?= =?us-ascii?q?VPgMwjHmCRQEB?= X-IronPort-AV: E=Sophos;i="5.64,529,1559520000"; d="asc'?scan'208,217";a="17063991" 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-SEED-SHA; 20 Sep 2019 15:57:00 +0000 Received: from ams3-vpn-dhcp3639.cisco.com (ams3-vpn-dhcp3639.cisco.com [10.61.78.55]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x8KFv04S024438 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Sep 2019 15:57:00 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_51CB9B25-5674-4859-9054-5DFEEAD57C69"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Sep 2019 17:56:59 +0200 In-Reply-To: Cc: hrpc@irtf.org To: Niels ten Oever References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.78.55, ams3-vpn-dhcp3639.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 15:57:05 -0000 --Apple-Mail=_51CB9B25-5674-4859-9054-5DFEEAD57C69 Content-Type: multipart/alternative; boundary="Apple-Mail=_E1BC3EC8-DB1D-4B4D-8D2B-F73C49BCC567" --Apple-Mail=_E1BC3EC8-DB1D-4B4D-8D2B-F73C49BCC567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 20 Sep 2019, at 14:46, Niels ten Oever = wrote: >=20 > I do think it _is_ undisputed that the standards creation process is = political and that they can be used for political means, right? On its face I would agree. But your work would benefit from saying when = that would be the case. Again, the value of the work is exploring the = limits of your thesis and its ramifications. Eliot --Apple-Mail=_E1BC3EC8-DB1D-4B4D-8D2B-F73C49BCC567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 20 Sep 2019, at 14:46, Niels ten Oever <mail@nielstenoever.net> wrote:

I do think it _is_ undisputed = that the standards creation process is political and that they can be = used for political means, right?


On its face I would agree.  But your work would benefit = from saying when that would be the case.  Again, the value of the = work is exploring the limits of your thesis and its = ramifications.

Eliot
= --Apple-Mail=_E1BC3EC8-DB1D-4B4D-8D2B-F73C49BCC567-- --Apple-Mail=_51CB9B25-5674-4859-9054-5DFEEAD57C69 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2E9ssACgkQh7ZrRtnS ejNkLggAgnd6/gPWVrrLFAGsqpWJwY3CmJwC4rDrqyrzKSn9VoBK+L1VpVLamr6+ mIDL1KmIhckVuQ2+lhzwe7zWudRXukV5k4JxfuxWRb6MarYguqLcBz6BboehHSGl 8AbRUd/RdK+dB5KLtrfijf9Efx/ojX78i8JUoSzV3MrKX40CFwT9FgKAeqUYJfCu WDUHIj2AgYikDbYQG81D1gzd5UWT4Bgn/Bp/DbzLXYMsKN9xg8Ju7JG84AQ9aw/a r9T7iFQhoRXfl6V8A3Cg6BwftW0LwLKy6r8WX+WXMynfzCO3XCYs3xWf1GNWtD6d my+NmW2garZau0g1ypcLsuFwHjP5ag== =hJck -----END PGP SIGNATURE----- --Apple-Mail=_51CB9B25-5674-4859-9054-5DFEEAD57C69-- From nobody Fri Sep 20 11:40:02 2019 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 8769912081A for ; Fri, 20 Sep 2019 11:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=AQRAVlb9; dkim=pass (1024-bit key) header.d=yitter.info header.b=ilpeExYE 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 vXTLtL-Tax5s for ; Fri, 20 Sep 2019 11:39:58 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B67120852 for ; Fri, 20 Sep 2019 11:39:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 4CF95BCC7D for ; Fri, 20 Sep 2019 18:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1569004767; bh=eg8q+elmOO7bfJ6yW/5QJaXxrPrmlIG/cecTdnWg+v0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=AQRAVlb9/FoCRMvi1RJYr2Ntej9ofPTR4wX8+lEqfU9wBGoyB13wGph/AdIJVGqvg VR8ugc/AX7eGzVkWXS9OVmiH+qSggMv7VGRTVCC7UEwTjNDclK6EFue/F09iAvGja7 ZzTFXGWoU5Eon1qXK05wXHpWTwBa1H54tZD73UBQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8gQXf24SrFa for ; Fri, 20 Sep 2019 18:39:25 +0000 (UTC) Date: Fri, 20 Sep 2019 14:39:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1569004765; bh=eg8q+elmOO7bfJ6yW/5QJaXxrPrmlIG/cecTdnWg+v0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ilpeExYEP1Wn0zIoo8b7IWi5Nq4f1BW+OTSyHm+abfGsjjAtIYYd8R7UNNcJUdY9X 9zo0AF9SX6uWMd1yxArdf9Zp00jFoX5/tQNhmrKxgRDY/mIyxs2hpkAS8aUxMZha7r Ey41dpZPHgUuQpZoMOpbNgU0mFMODhj+fgB5K6As= From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 18:40:01 -0000 Hi, Apparently I haven't taken my OCD medications, and therefore I'm looking at this and responding. I mostly looked at diffs between -04 and -06. Still speaking just for me. On Wed, Sep 18, 2019 at 05:27:53PM +0200, Niels ten Oever wrote: > I am curious to hear whether you think these adaptations help address some of your issues. > > Suggestion, comments, discussion, and pull requests are always welcome: In §1, I do not find economic impacts described in RFC 613. I find RFC 3271 to be a bizarre reference, and very hard to justify given the way cited here. I am totally mystified about how RFC 101 illustrates early community members making political decisions. I'm having a hard time hooking up most of these other RFCs with this claim, too, and I wonder if it isn't the same question-begging I've raised before: just because a thing has somehow been the implication of a political process does not actually show that the thing is _itself_ political. If the entire approach is simply to take BramanII thesis as proven, then state that and get rid of all the other supposed support here, which is inadequate to prove the point and is obscure enough that the reader needs to do the work of chasing the references anyway. The reliance on the definition of Internet Standards in §2 is going to yield a rather underwhelming conclusion, since an awful lot of the Internet runs on stuff that isn't Internet Standard. This includes HTTP 1.0, 1.1, and 2, so it's not like it's a little gap. In §5, the claim of "general agreement" is empirical and has nowhere been demonstrated that I can see. And this discussion is _prima facie_ evidence against the claim. In §6, again things that are presented as "conclusions" are really just positions that are not actually argued for in the text. This conclusion basically says that if you accept Russell, then the use-context counts. But unstated here is the acceptance that Russell is right and also that therefore the use-context counts. That's literally what's at stake in the discussion, and the I-D has not proven any of this at all. The entire section continues to beg the question. Either make an argument somewhere for this conclusion, or just take it out. I'm unlikely to have another train ride soon where I get to look at this again, so please don't take my future silence as agreement (or disagreement). It's just silence. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Sep 20 18:33:13 2019 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 35E16120091 for ; Fri, 20 Sep 2019 18:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiOkxRmu3YpR for ; Fri, 20 Sep 2019 18:33:09 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AE012008F for ; Fri, 20 Sep 2019 18:33:09 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id y3so7344541ljj.6 for ; Fri, 20 Sep 2019 18:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/bNJs0uF7vqsMQhM8jwyMrk0NFpKK0JzBXHSWP2SZ4Q=; b=SskvHEt/d3p+QrB6Cs2SrteEwcq09X65oOCKp33PoVvG04ZymqxxnNNKKHJ9kpoK5O 2qtggZrUel9AhPwZMIviunX8D40zQhkMeWmcxSBsnIf3Fl6IqhN919uUHmrkdgaPJbGi wUbg92iIFJ7k0sYH7yH1c/frAJpv091tAvBqELXLo7CC6nrqVVq+/jUKGV/R1p2a+GYM pMJR6dkGsOd5hZb7JmD4xEVamNEB1+IXP783BJf1fiwIg5QGIKhAIheGMPCf+E2PIhee XoTYqP3gTrDr885lYXRnLPzImNN2+1e+xumiWf/V86eYwCwWqogaBECGTFb9AaBHkx5M diNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/bNJs0uF7vqsMQhM8jwyMrk0NFpKK0JzBXHSWP2SZ4Q=; b=qLMuQgryV0ekRU4pnqAEoP+IAyjCANw71ijKnd7oM9rOL4uwH26wrP7BC9A66NRGlp gU6PRGzRa+Vo/CjkrTWuc/8HjkWWA33Fi1GfayZ0ro4fGfh6plCYaZeLKmRYU4YWutwW 3Cq1p9mG7U2VIWtelKGv22Hm9hEnrOsji/kkkKT60urzK2q/THHxDfVMm6FrqbsE2xXe mxqo5mUxfboCOwrOee0otJdH2XX4rZvC59O1IdYZBpxPxOSo9WAx0tkhVrpATkTHrn/B M3PvAarLEAHRXH8V7h2m1ravAPJmxsJlskpowO0vaEICU0l2xyGhjTyG5/1LkspShEwI ek1Q== X-Gm-Message-State: APjAAAXMg8HCFm/ZA+d6HY782RPUMv2FLN0mIXnkHHXcDS459QABuTzB VUvyywcdIPgkPE8OY5mkd3uvsxTU3QNNIgbkWFZvbrrhAPYJKQ== X-Google-Smtp-Source: APXvYqwARD1kWrC752ZmGVbcuuNlVFfiMhiSIwhQBN0pegrTMEHAwEVwkcIONo31TDMOzRTxf4yCpNPjF7FbAZomPT8= X-Received: by 2002:a2e:9584:: with SMTP id w4mr2612287ljh.145.1569029587437; Fri, 20 Sep 2019 18:33:07 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> In-Reply-To: <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> From: Eric Rescorla Date: Fri, 20 Sep 2019 18:32:30 -0700 Message-ID: To: Andrew Sullivan Cc: hrpc@irtf.org Content-Type: multipart/alternative; boundary="00000000000033a93c0593062b7f" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 01:33:12 -0000 --00000000000033a93c0593062b7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Whereas there might not be agreement among the Internet protocol community on the specific political nature of the technological development process and its outputs, it is generally agreed that standards and protocols are both products of a political process, and they can also be used for political means. I would like to register my agrement with Andrew and focus in on this one point: there are many protocols (in fact, by count probably most protocols) which are just designed by proprietary organizations. It's not clear on what basis you are claiming that they are the output of political processes and this certainly doesn't seem like something that's generally agreed. I certainly agree that they "can be used" for political means, though any "can" statement is pretty weak. This is even true at some level for many standards, especially because your definition of "standard" is so expansive: Standards 'A standard is an agreed-upon way of doing something or measuring something.' [Sisson] By this definition I think it would be pretty hard to argue that SSLv2, and SSLv3 weren't standards given their wide use, even though they were just designed by people at one company. Another example would be the Philips screwdriver head. What's the political process that produced these? More generally, it seems like depending on how one interprets the major claims in this document, they are either too strong (all protocol and standards development is political) or trivial (some protocol and standards development is political). The first is too strong for the reasons I indicate above, and the second seems pretty obvious and doesn't really need much theorizing; one needs just point to the development of some protocol which was a political process, and it seems like that's been pretty amply documented for a number of protocols/standards (e.g., HTTP/2 or TLS 1.0). As I noted above, the claim that protocols can be used for political means also seems relatively obvious (cf. Tor). In short, I don't think this document should be published as an RFC without major revision, which would presumably start with fleshing out some more interesting claims. -Ekr On Fri, Sep 20, 2019 at 11:40 AM Andrew Sullivan wrote: > Hi, > > Apparently I haven't taken my OCD medications, and therefore I'm > looking at this and responding. I mostly looked at diffs between -04 > and -06. Still speaking just for me. > > On Wed, Sep 18, 2019 at 05:27:53PM +0200, Niels ten Oever wrote: > > I am curious to hear whether you think these adaptations help address > some of your issues. > > > > Suggestion, comments, discussion, and pull requests are always welcome: > > In =C2=A71, I do not find economic impacts described in RFC 613. I find > RFC 3271 to be a bizarre reference, and very hard to justify given the > way cited here. I am totally mystified about how RFC 101 illustrates > early community members making political decisions. I'm having a hard > time hooking up most of these other RFCs with this claim, too, and I > wonder if it isn't the same question-begging I've raised before: just > because a thing has somehow been the implication of a political > process does not actually show that the thing is _itself_ political. > If the entire approach is simply to take BramanII thesis as proven, > then state that and get rid of all the other supposed support here, > which is inadequate to prove the point and is obscure enough that the > reader needs to do the work of chasing the references anyway. > > The reliance on the definition of Internet Standards in =C2=A72 is going = to > yield a rather underwhelming conclusion, since an awful lot of the > Internet runs on stuff that isn't Internet Standard. This includes > HTTP 1.0, 1.1, and 2, so it's not like it's a little gap. > > In =C2=A75, the claim of "general agreement" is empirical and has nowhere > been demonstrated that I can see. And this discussion is _prima > facie_ evidence against the claim. > > In =C2=A76, again things that are presented as "conclusions" are really > just positions that are not actually argued for in the text. This > conclusion basically says that if you accept Russell, then the > use-context counts. But unstated here is the acceptance that Russell > is right and also that therefore the use-context counts. That's > literally what's at stake in the discussion, and the I-D has not > proven any of this at all. The entire section continues to beg the > question. Either make an argument somewhere for this conclusion, or > just take it out. > > I'm unlikely to have another train ride soon where I get to look at > this again, so please don't take my future silence as agreement (or > disagreement). It's just silence. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --00000000000033a93c0593062b7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0=C2=A0 Whereas there might not be agreement among th= e Internet protocol
=C2=A0 =C2=A0community on the specific political nat= ure of the technological
=C2=A0 =C2=A0development process and its output= s, it is generally agreed that
=C2=A0 =C2=A0standards and protocols are = both products of a political process, and
=C2=A0 =C2=A0they can also be = used for political means.
=C2=A0 =C2=A0
I would like to register my a= grement with Andrew and focus in on this
one point: there are many proto= cols (in fact, by count probably most
protocols) which are just designed= by proprietary organizations.=C2=A0 It's
not clear on what basis yo= u are claiming that they are the output of
political processes and this = certainly doesn't seem like something
that's generally agreed. I= certainly agree that they "can be used"
for political means, = though any "can" statement is pretty weak.

This is even tr= ue at some level for many standards, especially
because your definition = of "standard" is so expansive:

=C2=A0 =C2=A0Standards =C2= =A0'A standard is an agreed-upon way of doing something or
=C2=A0 = =C2=A0 =C2=A0 measuring something.' =C2=A0[Sisson]

By this defin= ition I think it would be pretty hard to argue that
SSLv2, =C2=A0and SSL= v3 weren't standards given their wide use, even
though they were jus= t designed by people at one company. Another
example would be the Philip= s screwdriver head. What's the political
process that produced these= ?


More generally, it seems like depending on how one interprets = the
major claims in this document, they are either too strong (all
pr= otocol and standards development is political) or trivial (some
protocol= and standards development is political). The first is too
strong for th= e reasons I indicate above, and the second seems pretty
obvious and does= n't really need much theorizing; one needs just point
to the develop= ment of some protocol which was a political process, and
it seems like t= hat's been pretty amply documented for a number of
protocols/standar= ds (e.g., HTTP/2 or TLS 1.0).

As I noted above, the claim that proto= cols can be used for political
means also seems relatively obvious (cf. = Tor).

In short, I don't think this document should be published = as an RFC
without major revision, which would presumably start with fles= hing
out some more interesting claims.

-Ekr





On= Fri, Sep 20, 2019 at 11:40 AM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,

Apparently I haven't taken my OCD medications, and therefore I'm looking at this and responding.=C2=A0 I mostly looked at diffs between -04<= br> and -06.=C2=A0 Still speaking just for me.

On Wed, Sep 18, 2019 at 05:27:53PM +0200, Niels ten Oever wrote:
> I am curious to hear whether you think these adaptations help address = some of your issues.
>
> Suggestion, comments, discussion, and pull requests are always welcome= :

In =C2=A71, I do not find economic impacts described in RFC 613.=C2=A0 I fi= nd
RFC 3271 to be a bizarre reference, and very hard to justify given the
way cited here.=C2=A0 I am totally mystified about how RFC 101 illustrates<= br> early community members making political decisions.=C2=A0 I'm having a = hard
time hooking up most of these other RFCs with this claim, too, and I
wonder if it isn't the same question-begging I've raised before: ju= st
because a thing has somehow been the implication of a political
process does not actually show that the thing is _itself_ political.
If the entire approach is simply to take BramanII thesis as proven,
then state that and get rid of all the other supposed support here,
which is inadequate to prove the point and is obscure enough that the
reader needs to do the work of chasing the references anyway.

The reliance on the definition of Internet Standards in =C2=A72 is going to=
yield a rather underwhelming conclusion, since an awful lot of the
Internet runs on stuff that isn't Internet Standard.=C2=A0 This include= s
HTTP 1.0, 1.1, and 2, so it's not like it's a little gap.

In =C2=A75, the claim of "general agreement" is empirical and has= nowhere
been demonstrated that I can see.=C2=A0 And this discussion is _prima
facie_ evidence against the claim.

In =C2=A76, again things that are presented as "conclusions" are = really
just positions that are not actually argued for in the text.=C2=A0 This
conclusion basically says that if you accept Russell, then the
use-context counts.=C2=A0 But unstated here is the acceptance that Russell<= br> is right and also that therefore the use-context counts.=C2=A0 That's literally what's at stake in the discussion, and the I-D has not
proven any of this at all.=C2=A0 The entire section continues to beg the question.=C2=A0 Either make an argument somewhere for this conclusion, or just take it out.

I'm unlikely to have another train ride soon where I get to look at
this again, so please don't take my future silence as agreement (or
disagreement).=C2=A0 It's just silence.

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--00000000000033a93c0593062b7f-- From nobody Sat Sep 21 06:09:52 2019 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 5CAE91200E7 for ; Sat, 21 Sep 2019 06:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiU3wG5hHLoU for ; Sat, 21 Sep 2019 06:09:47 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 920A71200D5 for ; Sat, 21 Sep 2019 06:09:47 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iBf8w-0003hR-Oy for hrpc@irtf.org; Sat, 21 Sep 2019 15:09:43 +0200 To: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Sat, 21 Sep 2019 15:09:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 7cd323abaa3d0c03d168080f9b069a49 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 13:09:50 -0000 Dear Andrew, On 9/20/19 8:39 PM, Andrew Sullivan wrote: > Hi, > > Apparently I haven't taken my OCD medications, and therefore I'm > looking at this and responding. I mostly looked at diffs between -04 > and -06. Still speaking just for me. > > On Wed, Sep 18, 2019 at 05:27:53PM +0200, Niels ten Oever wrote: >> I am curious to hear whether you think these adaptations help address some of your issues. >> >> Suggestion, comments, discussion, and pull requests are always welcome: > > In §1, I do not find economic impacts described in RFC 613. Sentence one of RFC613 is: "Network topology is a complicated political and economic question with obvious technical overtones" > I find > RFC 3271 to be a bizarre reference, and very hard to justify given the > way cited here. RFC3271 extensively talk about the interrelation between the Internet and economics and politics. I have a really hard time understanding how you can argue against that. > I am totally mystified about how RFC 101 illustrates > early community members making political decisions. The involvement of Terry Shepard and the demands the Canadian government made for the Internet infrastructure and architecture is not political? > I'm having a hard > time hooking up most of these other RFCs with this claim, too, and I > wonder if it isn't the same question-begging I've raised before: just > because a thing has somehow been the implication of a political > process does not actually show that the thing is _itself_ political. The claim that things in itself is something is removed from the conclusion. > If the entire approach is simply to take BramanII thesis as proven, > then state that and get rid of all the other supposed support here, > which is inadequate to prove the point and is obscure enough that the > reader needs to do the work of chasing the references anyway. > > The reliance on the definition of Internet Standards in §2 is going to > yield a rather underwhelming conclusion, since an awful lot of the > Internet runs on stuff that isn't Internet Standard. This includes > HTTP 1.0, 1.1, and 2, so it's not like it's a little gap. > I do not see how this contradicts the definition from RFC2026, but maybe I am missing something? > In §5, the claim of "general agreement" is empirical and has nowhere > been demonstrated that I can see. And this discussion is _prima > facie_ evidence against the claim. > We are seeking what we can agree upon, right? Several times people have now acknowledged that it is obvious that protocols are the conclusion of a political process, and political things can be done with them. If we document that agreement, then I think we have achieved the goal of this document. The fact that it is so hard to agree on this, show the importance of the document, and that shows that the statement is not trivial. > In §6, again things that are presented as "conclusions" are really > just positions that are not actually argued for in the text. This > conclusion basically says that if you accept Russell, then the > use-context counts. But unstated here is the acceptance that Russell > is right and also that therefore the use-context counts. That's > literally what's at stake in the discussion, and the I-D has not > proven any of this at all. The entire section continues to beg the > question. Either make an argument somewhere for this conclusion, or > just take it out. > The conclusion emerges from the analysis of the different documented positions. Best, Niels > I'm unlikely to have another train ride soon where I get to look at > this again, so please don't take my future silence as agreement (or > disagreement). It's just silence. > > Best regards, > > A > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Sat Sep 21 06:09:58 2019 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 1B10E1200D5 for ; Sat, 21 Sep 2019 06:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGRkn7b-gmTj for ; Sat, 21 Sep 2019 06:09:47 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 92040120033 for ; Sat, 21 Sep 2019 06:09:47 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iBf8z-0003hU-AO for hrpc@irtf.org; Sat, 21 Sep 2019 15:09:45 +0200 To: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> Date: Sat, 21 Sep 2019 15:09:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: a2a1964a1561ab7a63907465a561ffe8 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 13:09:51 -0000 On 9/21/19 3:32 AM, Eric Rescorla wrote: >    Whereas there might not be agreement among the Internet protocol >    community on the specific political nature of the technological >    development process and its outputs, it is generally agreed that >    standards and protocols are both products of a political process, and >    they can also be used for political means. >     > I would like to register my agrement with Andrew and focus in on this > one point: there are many protocols (in fact, by count probably most > protocols) which are just designed by proprietary organizations.  It's > not clear on what basis you are claiming that they are the output of > political processes and this certainly doesn't seem like something > that's generally agreed. Aren't proprietary standards, and the way they make it possible and impossible to do certain things, a prime example of a political process and political impact? > I certainly agree that they "can be used" > for political means, though any "can" statement is pretty weak. > If we can document *that*, we would have made a lot of progress in the IETF imho. > This is even true at some level for many standards, especially > because your definition of "standard" is so expansive: > >    Standards  'A standard is an agreed-upon way of doing something or >       measuring something.'  [Sisson] > > By this definition I think it would be pretty hard to argue that > SSLv2,  and SSLv3 weren't standards given their wide use, even > though they were just designed by people at one company. I don't see how that definition would make that impossible. > Another > example would be the Philips screwdriver head. What's the political > process that produced these? > > The patenting of process by Henry F. Philips, the regimes under which is was patented, its competition with other screw heads (torx, etc). There is an enormous amount of politics, and societal ordering connected with screws. Maybe this text by Bruno Latour might help further illustrate that: http://www.bruno-latour.fr/sites/default/files/46-TECHNOLOGY-DURABLE-GBpdf.pdf > More generally, it seems like depending on how one interprets the > major claims in this document, they are either too strong (all > protocol and standards development is political) Why is that too strong? > or trivial (some > protocol and standards development is political). The first is too > strong for the reasons I indicate above, I don't think so, but I am happy to discuss. and the second seems pretty > obvious and doesn't really need much theorizing; As said, I think it would be very useful if we would document this, so we don't need to repeat the discussion. > one needs just point > to the development of some protocol which was a political process, and > it seems like that's been pretty amply documented for a number of > protocols/standards (e.g., HTTP/2 or TLS 1.0). > > As I noted above, the claim that protocols can be used for political > means also seems relatively obvious (cf. Tor). I am happy to conclude that we agree on the two statements: - some protocol and standards development is political and - protocols can be used for political means That's progress for me in this discussion. Now let's see if we can further flesh out: - all protocol and standards development is political Best, Niels > > In short, I don't think this document should be published as an RFC > without major revision, which would presumably start with fleshing > out some more interesting claims. > > -Ekr > > > > > > On Fri, Sep 20, 2019 at 11:40 AM Andrew Sullivan > wrote: > > Hi, > > Apparently I haven't taken my OCD medications, and therefore I'm > looking at this and responding.  I mostly looked at diffs between -04 > and -06.  Still speaking just for me. > > On Wed, Sep 18, 2019 at 05:27:53PM +0200, Niels ten Oever wrote: > > I am curious to hear whether you think these adaptations help address some of your issues. > > > > Suggestion, comments, discussion, and pull requests are always welcome: > > In §1, I do not find economic impacts described in RFC 613.  I find > RFC 3271 to be a bizarre reference, and very hard to justify given the > way cited here.  I am totally mystified about how RFC 101 illustrates > early community members making political decisions.  I'm having a hard > time hooking up most of these other RFCs with this claim, too, and I > wonder if it isn't the same question-begging I've raised before: just > because a thing has somehow been the implication of a political > process does not actually show that the thing is _itself_ political. > If the entire approach is simply to take BramanII thesis as proven, > then state that and get rid of all the other supposed support here, > which is inadequate to prove the point and is obscure enough that the > reader needs to do the work of chasing the references anyway. > > The reliance on the definition of Internet Standards in §2 is going to > yield a rather underwhelming conclusion, since an awful lot of the > Internet runs on stuff that isn't Internet Standard.  This includes > HTTP 1.0, 1.1, and 2, so it's not like it's a little gap. > > In §5, the claim of "general agreement" is empirical and has nowhere > been demonstrated that I can see.  And this discussion is _prima > facie_ evidence against the claim. > > In §6, again things that are presented as "conclusions" are really > just positions that are not actually argued for in the text.  This > conclusion basically says that if you accept Russell, then the > use-context counts.  But unstated here is the acceptance that Russell > is right and also that therefore the use-context counts.  That's > literally what's at stake in the discussion, and the I-D has not > proven any of this at all.  The entire section continues to beg the > question.  Either make an argument somewhere for this conclusion, or > just take it out. > > I'm unlikely to have another train ride soon where I get to look at > this again, so please don't take my future silence as agreement (or > disagreement).  It's just silence. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Sat Sep 21 07:09:58 2019 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 7E77B12003F for ; Sat, 21 Sep 2019 07:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 PuVeuS0GpIDs for ; Sat, 21 Sep 2019 07:09:53 -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 2D07C120033 for ; Sat, 21 Sep 2019 07:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23179; q=dns/txt; s=iport; t=1569074993; x=1570284593; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=HW8dfSmOPaK1k6C8k6oKYRLKFoK5TaOFbzkakKp5ooI=; b=fpQ6JK8E0Q37M760YkD6UQEWU3Ei+gyTNudrYadlAmvbv6a94HPwXy4j BzDFi9qaABEvAJO0frPh7KtObPE67TGLVlztyJjO0xlvEgbCh/2U/OhBh KwXLmAkT6k0DKhfyXxFbM4L2WvEj+id6wzGj6qoIe0frbc+LJtCNRMaZI 4=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAACcLoZd/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBZ4MLUyASKoQiiHyHeiWTF4gGAgcBAQEJAwEBGAEMCgE?= =?us-ascii?q?BgUuCdAKDLDgTAgMJAQEEAQEBAgEFBG2FLQyFSgEBAQEBAQEBASFLCwULCxg?= =?us-ascii?q?nAwICJx8RBhMUgw4BgXsPD6d7c4EyhEoCOwQBQIRnEIE0gVGKKSeBf4ERJww?= =?us-ascii?q?Tgkw+gkgZAQKBQAEBVIJVMoImBIxUiS6XCoIsgi6BE4xvBYIdgjgbgjaHS4N?= =?us-ascii?q?+iyakHoMRAgQGBQIVgWkhKoEuMxoIGxU7KgGCQQk1EhAUgVoXhQ2DVoVBPgM?= =?us-ascii?q?wAY0ogkUBAQ?= X-IronPort-AV: E=Sophos;i="5.64,532,1559520000"; d="asc'?scan'208,217";a="17099395" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Sep 2019 14:09:50 +0000 Received: from [10.61.161.140] ([10.61.161.140]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8LE9nlM019223 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Sep 2019 14:09:50 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E9E0C8C8-B06B-41D6-94CE-DBEA0299C3A9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Sep 2019 16:09:49 +0200 In-Reply-To: <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> Cc: hrpc@irtf.org To: Niels ten Oever References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.161.140, [10.61.161.140] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 14:09:57 -0000 --Apple-Mail=_E9E0C8C8-B06B-41D6-94CE-DBEA0299C3A9 Content-Type: multipart/alternative; boundary="Apple-Mail=_4039ADE6-30C3-40F6-BD35-19D2F90DF1BF" --Apple-Mail=_4039ADE6-30C3-40F6-BD35-19D2F90DF1BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi again, Niels, > On 21 Sep 2019, at 15:09, Niels ten Oever = wrote: >=20 > Aren't proprietary standards, and the way they make it possible and = impossible to do certain things, a prime example of a political process = and political impact? Let=E2=80=99s take a good example of a de facto standard that probably = had very little to do with politics: the vt100 terminal. It was never = intended to be a standard. It was a terminal, and a darned good one[*]. = Most terminal emulators emulated the vt100 which is precisely how it = became a standard, to the point where it was probably the first really = well known example of =E2=80=9Cbug-for-bug compatibility=E2=80=9D. Was = it a proprietary standard? Digital specified the terminal design. Was = there political impact? I don=E2=80=99t think so, but it=E2=80=99s hard = to say. The same was largely true for the IOS CLI for a good long while. Others = would emulate it as a good jumping off point. Political impact? I = wouldn=E2=80=99t think so, but perhaps I lack appropriate imagination in = this space. Right now the NTIA is looking at Software Bill of Materials (SBoM). One = of the challenges they face is uniquely identifying software packages. = This naming requires some sort of source of authority for the names in = use. Anything having to do with naming is bound to have political = implications. Another example of a de facto standard that at best has very minor = political implications is the simple key bindings in your mail editor. = There is a good chance that they line up with EMACS, just because that = is what a lot of people have gotten used to. Political impact? I=E2=80=99= d be hard pressed to find one, though maybe someone with a non-latin = keyboard would disagree. Eliot *(though I was a weirdo and preferred a Data Media 1520 or the later = Visual 55). >=20 >> I certainly agree that they "can be used" >> for political means, though any "can" statement is pretty weak. >>=20 >=20 > If we can document *that*, we would have made a lot of progress in the = IETF imho. >=20 >> This is even true at some level for many standards, especially >> because your definition of "standard" is so expansive: >>=20 >> Standards 'A standard is an agreed-upon way of doing something or >> measuring something.' [Sisson] >>=20 >> By this definition I think it would be pretty hard to argue that >> SSLv2, and SSLv3 weren't standards given their wide use, even >> though they were just designed by people at one company. >=20 > I don't see how that definition would make that impossible. >=20 >> Another >> example would be the Philips screwdriver head. What's the political >> process that produced these? >>=20 >>=20 >=20 > The patenting of process by Henry F. Philips, the regimes under which = is was patented, its competition with other screw heads (torx, etc). = There is an enormous amount of politics, and societal ordering connected = with screws. >=20 > Maybe this text by Bruno Latour might help further illustrate that: >=20 > = http://www.bruno-latour.fr/sites/default/files/46-TECHNOLOGY-DURABLE-GBpdf= .pdf >=20 >=20 >> More generally, it seems like depending on how one interprets the >> major claims in this document, they are either too strong (all >> protocol and standards development is political) >=20 > Why is that too strong? >=20 >> or trivial (some >> protocol and standards development is political). The first is too >> strong for the reasons I indicate above, >=20 > I don't think so, but I am happy to discuss. >=20 > and the second seems pretty >> obvious and doesn't really need much theorizing; >=20 > As said, I think it would be very useful if we would document this, so = we don't need to repeat the discussion. >=20 >> one needs just point >> to the development of some protocol which was a political process, = and >> it seems like that's been pretty amply documented for a number of >> protocols/standards (e.g., HTTP/2 or TLS 1.0). >>=20 >> As I noted above, the claim that protocols can be used for political >> means also seems relatively obvious (cf. Tor). >=20 > I am happy to conclude that we agree on the two statements: >=20 > - some protocol and standards development is political >=20 > and >=20 > - protocols can be used for political means >=20 > That's progress for me in this discussion. Now let's see if we can = further flesh out: >=20 > - all protocol and standards development is political >=20 > Best, >=20 > Niels >=20 >=20 >=20 >=20 >=20 >>=20 >> In short, I don't think this document should be published as an RFC >> without major revision, which would presumably start with fleshing >> out some more interesting claims. >>=20 >> -Ekr >>=20 >>=20 >>=20 >>=20 >>=20 >> On Fri, Sep 20, 2019 at 11:40 AM Andrew Sullivan = > wrote: >>=20 >> Hi, >>=20 >> Apparently I haven't taken my OCD medications, and therefore I'm >> looking at this and responding. I mostly looked at diffs between = -04 >> and -06. Still speaking just for me. >>=20 >> On Wed, Sep 18, 2019 at 05:27:53PM +0200, Niels ten Oever wrote: >>> I am curious to hear whether you think these adaptations help = address some of your issues. >>>=20 >>> Suggestion, comments, discussion, and pull requests are always = welcome: >>=20 >> In =C2=A71, I do not find economic impacts described in RFC 613. = I find >> RFC 3271 to be a bizarre reference, and very hard to justify given = the >> way cited here. I am totally mystified about how RFC 101 = illustrates >> early community members making political decisions. I'm having a = hard >> time hooking up most of these other RFCs with this claim, too, and = I >> wonder if it isn't the same question-begging I've raised before: = just >> because a thing has somehow been the implication of a political >> process does not actually show that the thing is _itself_ = political. >> If the entire approach is simply to take BramanII thesis as = proven, >> then state that and get rid of all the other supposed support = here, >> which is inadequate to prove the point and is obscure enough that = the >> reader needs to do the work of chasing the references anyway. >>=20 >> The reliance on the definition of Internet Standards in =C2=A72 is = going to >> yield a rather underwhelming conclusion, since an awful lot of the >> Internet runs on stuff that isn't Internet Standard. This = includes >> HTTP 1.0, 1.1, and 2, so it's not like it's a little gap. >>=20 >> In =C2=A75, the claim of "general agreement" is empirical and has = nowhere >> been demonstrated that I can see. And this discussion is _prima >> facie_ evidence against the claim. >>=20 >> In =C2=A76, again things that are presented as "conclusions" are = really >> just positions that are not actually argued for in the text. This >> conclusion basically says that if you accept Russell, then the >> use-context counts. But unstated here is the acceptance that = Russell >> is right and also that therefore the use-context counts. That's >> literally what's at stake in the discussion, and the I-D has not >> proven any of this at all. The entire section continues to beg = the >> question. Either make an argument somewhere for this conclusion, = or >> just take it out. >>=20 >> I'm unlikely to have another train ride soon where I get to look = at >> this again, so please don't take my future silence as agreement = (or >> disagreement). It's just silence. >>=20 >> Best regards, >>=20 >> A >>=20 >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >>=20 >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >>=20 >>=20 >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >>=20 >=20 > -- > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam >=20 > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --Apple-Mail=_4039ADE6-30C3-40F6-BD35-19D2F90DF1BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = again, Niels,


On 21 = Sep 2019, at 15:09, Niels ten Oever <mail@nielstenoever.net> wrote:

Aren't proprietary standards, and the way = they make it possible and impossible to do certain things, a prime = example of a political process and political impact?


Let=E2=80=99s take a good example of a de facto = standard that probably had very little to do with politics: the vt100 = terminal.  It was never intended to be a = standard.  It was a terminal, and a darned good one[*].  Most = terminal emulators emulated the vt100 which is = precisely how it became a standard, to the point where it was probably = the first really well known example of =E2=80=9Cbug-for-bug = compatibility=E2=80=9D.  Was it a proprietary standard? =  Digital specified the terminal design.  Was there political = impact?  I don=E2=80=99t think so, but it=E2=80=99s hard to = say.

The same was largely true for = the IOS CLI for a good long while.  Others would emulate it as a = good jumping off point.  Political impact?  I wouldn=E2=80=99t = think so, but perhaps I lack appropriate imagination in this = space.

Right now the NTIA is looking = at Software Bill of Materials (SBoM).  One of the challenges they = face is uniquely identifying software packages.  This naming = requires some sort of source of authority for the names in use. =  Anything having to do with naming is bound to have political = implications.

Another example of a = de facto standard that at best has very minor political implications is = the simple key bindings in your mail editor.  There is a good = chance that they line up with EMACS, just because that is what a lot of = people have gotten used to.  Political impact?  I=E2=80=99d be = hard pressed to find one, though maybe someone with a non-latin keyboard = would disagree.

Eliot
*(though I was a weirdo and = preferred a Data Media 1520 or the later Visual 55).


I = certainly agree that they "can be used"
for political = means, though any "can" statement is pretty weak.


If we can document *that*, we = would have made a lot of progress in the IETF imho.

This is even true at = some level for many standards, especially
because your = definition of "standard" is so expansive:

   Standards  'A standard is an agreed-upon = way of doing something or
      measuring = something.'  [Sisson]

By this = definition I think it would be pretty hard to argue that
SSLv2,  and SSLv3 weren't standards given their wide = use, even
though they were just designed by people at one = company.

I don't see how that = definition would make that impossible.

Another
example would be the Philips screwdriver head. What's the = political
process that produced these?



The patenting of = process by Henry F. Philips, the regimes under which is was patented, = its competition with other screw heads (torx, etc). There is an enormous = amount of politics, and societal ordering connected with screws.

Maybe this text by Bruno Latour might help = further illustrate that:

http://www.bruno-latour.fr/sites/default/files/46-TECHNOLOGY-DU= RABLE-GBpdf.pdf


More generally, it seems = like depending on how one interprets the
major claims in = this document, they are either too strong (all
protocol = and standards development is political)

Why is that too strong?

or trivial (some
protocol and standards development is political). The first = is too
strong for the reasons I indicate above,

I don't think so, but I am happy = to discuss.

and the second seems pretty
obvious and doesn't = really need much theorizing;

As = said, I think it would be very useful if we would document this, so we = don't need to repeat the discussion.

one needs just point
to the development of some protocol which was a political = process, and
it seems like that's been pretty amply = documented for a number of
protocols/standards (e.g., = HTTP/2 or TLS 1.0).

As I noted above, the = claim that protocols can be used for political
means also = seems relatively obvious (cf. Tor).

I am happy to conclude that we agree on the two = statements:

- some protocol and standards = development is political

and

- protocols can be used for political means

That's progress for me in this discussion. Now = let's see if we can further flesh out:

- = all protocol and standards development is political

Best,

Niels






In short, = I don't think this document should be published as an RFC
without major revision, which would presumably start with = fleshing
out some more interesting claims.
-Ekr





On Fri, Sep 20, 2019 at 11:40 = AM Andrew Sullivan <ajs@anvilwalrusden.com = <mailto:ajs@anvilwalrusden.com>> wrote:

   Hi,

=    Apparently I haven't taken my OCD medications, and = therefore I'm
   looking at this and = responding.  I mostly looked at diffs between -04
=    and -06.  Still speaking just for me.

   On Wed, Sep 18, 2019 at = 05:27:53PM +0200, Niels ten Oever wrote:
I am curious to hear whether you think these = adaptations help address some of your issues.

Suggestion, comments, discussion, and pull requests are = always welcome:

=    In =C2=A71, I do not find economic impacts described = in RFC 613.  I find
   RFC 3271 to be = a bizarre reference, and very hard to justify given the
=    way cited here.  I am totally mystified about how = RFC 101 illustrates
   early community = members making political decisions.  I'm having a hard
=    time hooking up most of these other RFCs with this = claim, too, and I
   wonder if it isn't = the same question-begging I've raised before: just
=    because a thing has somehow been the implication of a = political
   process does not actually = show that the thing is _itself_ political.
=    If the entire approach is simply to take BramanII = thesis as proven,
   then state that and = get rid of all the other supposed support here,
=    which is inadequate to prove the point and is obscure = enough that the
   reader needs to do the = work of chasing the references anyway.

=    The reliance on the definition of Internet Standards = in =C2=A72 is going to
   yield a rather = underwhelming conclusion, since an awful lot of the
=    Internet runs on stuff that isn't Internet = Standard.  This includes
   HTTP 1.0, = 1.1, and 2, so it's not like it's a little gap.

   In =C2=A75, the claim of "general = agreement" is empirical and has nowhere
=    been demonstrated that I can see.  And this = discussion is _prima
   facie_ evidence = against the claim.

   In = =C2=A76, again things that are presented as "conclusions" are really
   just positions that are not actually = argued for in the text.  This
=    conclusion basically says that if you accept Russell, = then the
   use-context counts.  But = unstated here is the acceptance that Russell
=    is right and also that therefore the use-context = counts.  That's
   literally what's = at stake in the discussion, and the I-D has not
=    proven any of this at all.  The entire section = continues to beg the
   question.  = Either make an argument somewhere for this conclusion, or
=    just take it out.

=    I'm unlikely to have another train ride soon where I = get to look at
   this again, so please = don't take my future silence as agreement (or
=    disagreement).  It's just silence.

   Best regards,

   A

   --
=    Andrew Sullivan
=    ajs@anvilwalrusden.com = <mailto:ajs@anvilwalrusden.com>

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


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


--
Niels ten = Oever
Researcher and PhD Candidate
DATACTIVE = Research Group
University of Amsterdam

PGP fingerprint   2458 0B70 5C4A FD8A = 9488  
=             &n= bsp;     643A 0ED8 3F3A 468A C8B3

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

= --Apple-Mail=_4039ADE6-30C3-40F6-BD35-19D2F90DF1BF-- --Apple-Mail=_E9E0C8C8-B06B-41D6-94CE-DBEA0299C3A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2GLy0ACgkQh7ZrRtnS ejOUaQf/QWq6PLyt2ihAkFIPs6Q7BR0ayncTiWwQ76RTYCHFiTScuHzmUqpfeSD5 l1r/fsGcaL74zX8cdx3+BEj3s8prafY2caYcOCo7kExzD9LcTGNawpEgIWFKTrqi KagmtP5f8gKUf9SqDBRKlW1HkSodPQpPPWByp2LHZp8TfLzvaViTqZ06ij+DlJqg KpNnuquRrFnvJNT5WPZHBdhkQQPltfkBuKqS3LPwmS6bf+TlivqiaEoCtFVheABQ vS6nrUdc0w/VoK4Lzjp2FbwhlGy4PccIc2A4k2palHqyWSZklz3W/ytGknSPBbOI LmKzKiW0Y8zu9hpptwctBY0Bo+3Gcw== =GTDa -----END PGP SIGNATURE----- --Apple-Mail=_E9E0C8C8-B06B-41D6-94CE-DBEA0299C3A9-- From nobody Sat Sep 21 07:13:45 2019 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 43A0612003F for ; Sat, 21 Sep 2019 07:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12FGbaCVxCwm for ; Sat, 21 Sep 2019 07:13:42 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90084120033 for ; Sat, 21 Sep 2019 07:13:41 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id x80so7004052lff.3 for ; Sat, 21 Sep 2019 07:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xscMnoEUXPlMxflgObvK6KsQjnC5Bc5G+ADP9uTU27E=; b=UocOQSIk8q5qYbyPK4ub7biBog+MN7W3/8Yl6gp0VSQQ1HxBKMc/RSE5vDOLSwVZZc zed2iXkAv0j0DfIXbXqnMZrOjugDkLsfiYVSg6173CacvSWOauXTVrspxYtaDjbMBjWW AoTkRxBN+Njwf4iZi21mXOd0VL2xacdaSIjfWlA894ImuVFHM82fMFIiOTQO0Em/cN8n TRpp8JdVk4MSFa2tGtqJLgmhbwcEa+aYoZozIso+UxRGR/7SiyrhlkA+1M8+xFtPYMdj WfG2RhnrlbMadQnPtb9bHHgzm22FOguzSMVAGFIuCVGduhmPELsdm3yOhBvMWkFzfIL5 e0vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xscMnoEUXPlMxflgObvK6KsQjnC5Bc5G+ADP9uTU27E=; b=GvgfV5oPi9rf9N7bReda4KFyeq9nawUp0RSYO/Ge5E0to2txouugwm6yL5owQyM+lG JOMJq3fQyeGDn0VbhfPCoAWSfNsWWnlHsToIpPQaiohnya2TOynOa9D9+VT9zeQZ/4Ao LOhCckEKYBPasETFq0FRC9bdxvIWOhIskSxx5jG/Y5naEiUQzH+YPrOeeqePvBFh33lF WG1i4Hs4xmzKR154IuluCq/yT0Fyy43oyTcQqM8VFqiPne67BhX0haI2a/VsTpamb8mp ge/Pqczpl7FUTkrHOs4/nrE67I49ijmJhhT9Ichaaw3bOyTBhqkGO5QUijriQfBQyur+ wb5A== X-Gm-Message-State: APjAAAWsvfvHAp4XHHShQeRzeJk9GUZTbBZRSaraWdVfNT1hpm99/Iuz IFs868LiUfc3CxWB5SFuuGmitwM/HTmn3Gmi6GFthDP1qS1qxw== X-Google-Smtp-Source: APXvYqwYu2/a01OksHp2thquO3VleDFrkTa+FrZhr0/Wv3tp2o+Zf+9BrgPVh2DLXtPyVGRMPSQanpIO1hjs+m2O/c0= X-Received: by 2002:a19:a408:: with SMTP id q8mr11284799lfc.94.1569075219672; Sat, 21 Sep 2019 07:13:39 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> In-Reply-To: <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> From: Eric Rescorla Date: Sat, 21 Sep 2019 07:13:03 -0700 Message-ID: To: Niels ten Oever Cc: hrpc@irtf.org Content-Type: multipart/alternative; boundary="000000000000184551059310cba8" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 14:13:44 -0000 --000000000000184551059310cba8 Content-Type: text/plain; charset="UTF-8" > Niels ten Oever via ietf.org > > 6:10 AM (48 minutes ago) > > to hrpc > > > On 9/21/19 3:32 AM, Eric Rescorla wrote: > > Whereas there might not be agreement among the Internet protocol > > community on the specific political nature of the technological > > development process and its outputs, it is generally agreed that > > standards and protocols are both products of a political process, and > > they can also be used for political means. > > > > I would like to register my agrement with Andrew and focus in on this > > one point: there are many protocols (in fact, by count probably most > > protocols) which are just designed by proprietary organizations. It's > > not clear on what basis you are claiming that they are the output of > > political processes and this certainly doesn't seem like something > > that's generally agreed. > > Aren't proprietary standards, and the way they make it possible and > impossible to do certain things, a prime example of a political > process and political impact? Well, I don't think without stretching the term "political" outside of the point where saying something is political is trivial, no, I don't think so. Again, let's take the example of SSL, which was designed by Netscape for its own market purposes and became a de facto standard because Netscape had the dominant browser and people wanted to interoperate with it. What's poltical about that process? > > I certainly agree that they "can be used" > > for political means, though any "can" statement is pretty weak. > > > > If we can document *that*, we would have made a lot of progress in > the IETF imho. I don't know anyone disagrees with that. But in any case, demonstrating that doesn't require hauling in the theoretical apparatus you are trying to deploy here, but rather requires *history*. I.e., demonstrate that the process of developing some set of standards involved the political process of balancing the objectives of the various stakeholders, finding compromise, etc. Given that every IETF standards development process I have ever been involved in has had some of this, that doesn't seem hard. As a non-IETF example "The Box", a history of the shipping container, has a nice description of the standardization of that technology. > > This is even true at some level for many standards, especially > > because your definition of "standard" is so expansive: > > > > Standards 'A standard is an agreed-upon way of doing something or > > measuring something.' [Sisson] > > > > By this definition I think it would be pretty hard to argue that > > SSLv2, and SSLv3 weren't standards given their wide use, even > > though they were just designed by people at one company. > > I don't see how that definition would make that impossible. I'm not sure I understand your response here. Are you saying that protocols defined by one company and that then achieve wide use are standards, or they are not? > > Another > > example would be the Philips screwdriver head. What's the political > > process that produced these? > > > > > > The patenting of process by Henry F. Philips, the regimes under > which is was patented, its competition with other screw heads (torx, > etc). There is an enormous amount of politics, and societal ordering > connected with screws. Again, this just seems to serve to make the definition of "political" meaningless. By this definition, what human commercial activity would *not* be political, as it all occurs against a political backdrop. > > More generally, it seems like depending on how one interprets the > > major claims in this document, they are either too strong (all > > protocol and standards development is political) > > Why is that too strong? For the reasons I indicated above: I don't think the development of many protocols, especially the small ones which get use internally as in, for instance, mobile apps, is generally political, And sometimes becoome standards and that's not necessarily political either. > > or trivial (some > > protocol and standards development is political). The first is too > > strong for the reasons I indicate above, > > I don't think so, but I am happy to discuss. > > and the second seems pretty > > obvious and doesn't really need much theorizing; > > As said, I think it would be very useful if we would document this, > so we don't need to repeat the discussion. Well, I'm not sure it matters if we repeat this discussion or even come to a conclusion on it. What's at stake in the answer? But, again, if you want to demonstrate that standards development can be political -- which, as I said, is a rather weak claim -- then I would discard this document and instead focus on documenting the history of the development of some protocols that was clealr political. > > > one needs just point > > to the development of some protocol which was a political process, and > > it seems like that's been pretty amply documented for a number of > > protocols/standards (e.g., HTTP/2 or TLS 1.0). > > > > As I noted above, the claim that protocols can be used for political > > means also seems relatively obvious (cf. Tor). > > I am happy to conclude that we agree on the two statements: > > - some protocol and standards development is political > > and > > - protocols can be used for political means Well, I don't think this document demonstrates that, it's just conclusory. To the extent to which we think these statements are actually in debate and need demonstrating, then I would, as I said, focus on demonstrating them with reference to actual standards rather than by referring to other people's views about these statements. I would think 3-5 of each of these should be sufficient (though of course logically one alone is sufficient to prove existence, but several is more convincing) > That's progress for me in this discussion. Now let's see if we can > further flesh out: > > - all protocol and standards development is political I think what would help at this point that would be for you to describe some commercial activities that you think are *not* political. -Ekr --000000000000184551059310cba8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Niels ten Oever via ietf.org
>
> 6:10 AM (48 minutes ago)
>= ;
> to hrpc
>
>
> On 9/21/19 3:32 AM, Eric Resc= orla wrote:
> > =C2=A0 =C2=A0Whereas there might not be agreement = among the Internet protocol
> > =C2=A0 =C2=A0community on the spec= ific political nature of the technological
> > =C2=A0 =C2=A0develo= pment process and its outputs, it is generally agreed that
> > =C2= =A0 =C2=A0standards and protocols are both products of a political process,= and
> > =C2=A0 =C2=A0they can also be used for political means.> > =C2=A0 =C2=A0
> > I would like to register my agrement= with Andrew and focus in on this
> > one point: there are many pr= otocols (in fact, by count probably most
> > protocols) which are = just designed by proprietary organizations.=C2=A0 It's
> > not= clear on what basis you are claiming that they are the output of
> &= gt; political processes and this certainly doesn't seem like something<= br>> > that's generally agreed.
>
> Aren't propr= ietary standards, and the way they make it possible and
> impossible = to do certain things, a prime example of a political
> process and po= litical impact?

Well, I don't think without stretching the term = "political" outside
of the point where saying something is pol= itical is trivial, no,
I don't think so.

Again, let's tak= e the example of SSL, which was designed by Netscape
for its own market = purposes and became a de facto standard because
Netscape had the dominan= t browser and people wanted to interoperate
with it. What's poltical= about that process?



> > I certainly agree that they = "can be used"
> > for political means, though any "= can" statement is pretty weak.
> >
>
> If we ca= n document *that*, we would have made a lot of progress in
> the IETF= imho.

I don't know anyone disagrees with that. But in any case,= demonstrating
that doesn't require hauling in the theoretical appar= atus you
are trying to deploy here, but rather requires *history*. I.e.,=
demonstrate that the process of developing some set of standards
inv= olved the political process of balancing the objectives of
the various s= takeholders, finding compromise, etc. Given that
every IETF standards de= velopment process I have ever been involved in
has had some of this, tha= t doesn't seem hard. As a non-IETF example
"The Box", a hi= story of the shipping container, has a nice description
of the standardi= zation of that technology.


> > This is even true at some l= evel for many standards, especially
> > because your definition of= "standard" is so expansive:
> >
> > =C2=A0 = =C2=A0Standards =C2=A0'A standard is an agreed-upon way of doing someth= ing or
> > =C2=A0 =C2=A0 =C2=A0 measuring something.' =C2=A0[S= isson]
> >
> > By this definition I think it would be pr= etty hard to argue that
> > SSLv2, =C2=A0and SSLv3 weren't sta= ndards given their wide use, even
> > though they were just design= ed by people at one company.
>
> I don't see how that def= inition would make that impossible.

I'm not sure I understand yo= ur response here. Are you saying that
protocols defined by one company a= nd that then achieve wide use
are standards, or they are not?

>= ; > Another
> > example would be the Philips screwdriver head. = What's the political
> > process that produced these?
> = >
> >
>
> The patenting of process by Henry F. P= hilips, the regimes under
> which is was patented, its competition wi= th other screw heads (torx,
> etc). There is an enormous amount of po= litics, and societal ordering
> connected with screws.

Again, = this just seems to serve to make the definition of "political"meaningless. By this definition, what human commercial activity
would *= not* be political, as it all occurs against a political
backdrop.

> > More generally, it seems like depending on how one interpre= ts the
> > major claims in this document, they are either too stro= ng (all
> > protocol and standards development is political)
&g= t;
> Why is that too strong?

For the reasons I indicated abov= e: I don't think the development
of many protocols, especially the s= mall ones which get use internally
as in, for instance, mobile apps, is = generally political, And sometimes
becoome standards and that's not = necessarily political either.


> > or trivial (some
>= > protocol and standards development is political). The first is too> > strong for the reasons I indicate above,
>
> I don&= #39;t think so, but I am happy to discuss.
>
> and the second = seems pretty
> > obvious and doesn't really need much theorizi= ng;
>
> As said, I think it would be very useful if we would d= ocument this,
> so we don't need to repeat the discussion.
Well, I'm not sure it matters if we repeat this discussion or
even = come to a conclusion on it. What's at stake in the answer?

But, = again, if you want to demonstrate that standards development
can be poli= tical -- which, as I said, is a rather weak claim --
then I would discar= d this document and instead focus on documenting
the history of the deve= lopment of some protocols that was clealr
political.


> > > one needs just point
> > to the development of some pro= tocol which was a political process, and
> > it seems like that= 9;s been pretty amply documented for a number of
> > protocols/sta= ndards (e.g., HTTP/2 or TLS 1.0).
> >
> > As I noted abo= ve, the claim that protocols can be used for political
> > means a= lso seems relatively obvious (cf. Tor).
>
> I am happy to conc= lude that we agree on the two statements:
>
> - some protocol = and standards development is political
>
> and
>
>= ; - protocols can be used for political means

Well, I don't thin= k this document demonstrates that, it's just
conclusory.=C2=A0 To th= e extent to which we think these statements are
actually in debate and n= eed demonstrating, then I would, as I said,
focus on demonstrating them = with reference to actual standards
rather than by referring to other peo= ple's views about these
statements. I would think 3-5 of each of the= se should be sufficient
(though of course logically one alone is suffici= ent to prove
existence, but several is more convincing)

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0
> That's progress for me in this disc= ussion. Now let's see if we can
> further flesh out:
>
= > - all protocol and standards development is political

I think w= hat would help at this point that would be for you to
describe some comm= ercial activities that you think are *not*
political.

-Ekr


--000000000000184551059310cba8-- From nobody Sat Sep 21 07:18:16 2019 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 95C2812003F for ; Sat, 21 Sep 2019 07:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_HELO_NONE=0.001, 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 qD3ilOe0d_JZ for ; Sat, 21 Sep 2019 07:18:13 -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 96D69120033 for ; Sat, 21 Sep 2019 07:18:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4CEEFBE50; Sat, 21 Sep 2019 15:18:11 +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 Y8WbMdHNddhT; Sat, 21 Sep 2019 15:18:09 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94FB3BE2E; Sat, 21 Sep 2019 15:18:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1569075489; bh=6S2WC34FSlpMl5lQMa0RPmInI6EIJRhVG6h28R2Dqyc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fIxG46hKkrfd0XF9qfCxb57MDxeRU2xCIUQppga1jX+hKbj+7UUDyuQJ6EZzHMMgB R/sMT2BDTtIfSbJs324eNjYmcGR2hynZFg8bEqd6AHPF+sJQYIBrkQ6DSHOiukXcbR dU8QlIT2c0/b3OgnxDsnaQnM8eBizTYO4LKu9giI= To: Eric Rescorla , Niels ten Oever Cc: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> Date: Sat, 21 Sep 2019 15:18:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rjWgoZg4tZViLoW2bynUMZgZgvHmJs70M" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 14:18:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rjWgoZg4tZViLoW2bynUMZgZgvHmJs70M Content-Type: multipart/mixed; boundary="FMAbU5MjFM6crjogq6RvtsAxluE8rDRGg"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Niels ten Oever Cc: hrpc@irtf.org Message-ID: <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> In-Reply-To: --FMAbU5MjFM6crjogq6RvtsAxluE8rDRGg Content-Type: multipart/mixed; boundary="------------123E991F47F5041C8B5D665C" Content-Language: en-GB This is a multi-part message in MIME format. --------------123E991F47F5041C8B5D665C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/09/2019 15:13, Eric Rescorla wrote: > Again, let's take the example of SSL, which was designed by Netscape > for its own market purposes and became a de facto standard because > Netscape had the dominant browser and people wanted to interoperate > with it. What's poltical about that process? To be fair, there was a lot of IETF politics around Netscape and Microsoft related to that and IIRC TLS was only called that as part of an explicit compromise. I think Eliot's examples (and NTP, which I raised) are maybe better examples of less/apolitical standards and protocols than SSL/TLS. S. --------------123E991F47F5041C8B5D665C Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------123E991F47F5041C8B5D665C-- --FMAbU5MjFM6crjogq6RvtsAxluE8rDRGg-- --rjWgoZg4tZViLoW2bynUMZgZgvHmJs70M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2GMSAACgkQWrL68XsX K+rS1w//TRSaPv4oQ7rwH7jeQ+vKzjETjEkNahM5T4wCQ5IQkUn5dQKNv5Sy3X3J 0U/iZEQQZzlHCAfT+/RbjIuiAfb6Tgf9LD2iey49LEqMlqzn/HLftHRaXXPSTVwn bE35CP0hqky6nf0YHwgNVkzapTHgK72XErhDYXVl7/mcN+HyN7E7+6dxpU2CZXs6 xMf6FryRCfRfcvC07UTICOqVf3Irlv2DHYItC3NOMaVmMb/XZRRmGlgxmGv9KZ8c XfUbOR6c2g4Jqryexn519jB0IuGmNCGeGy8k6ZPEQIUDrnNhoTY2WAc0dLmq1YJG WiMqglz3xvJtchEcxUHKXoy5tW+X49tV5dlLg8txY51cAwhOOib8hYyvIwEaSi3Q m2597RjXnW8lDNzfCsFyW8wq0htS4Ur7MNpT13w7QsFKapOXAMfoS7WFHHrelY25 5yO2VcMeMhbrSsqwNusE6Gdc5rTFXZg8vAIfmVtyytgHqCaMnmvbPpIgAAdRQSSc cqWi4LGBvlgNyTpZ8iSbRVp1iWXBhRoo+48dTF6I6CLtv27P4Iu4HpTgM20eFH35 t30iN4wMieri1HYrFaL7+JTUawDCR1ipaYZbSr5ys3AvBw48hrxDY1lxZKZZ5ICg l7U6O1CRhg8wN6qPwy11HD+p55/JC6ZSOSQS4xrcfRLcovf6C8k= =0nZQ -----END PGP SIGNATURE----- --rjWgoZg4tZViLoW2bynUMZgZgvHmJs70M-- From nobody Sat Sep 21 09:15:13 2019 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 939E2120044 for ; Sat, 21 Sep 2019 09:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92woHEOozQEP for ; Sat, 21 Sep 2019 09:15:10 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D64412002E for ; Sat, 21 Sep 2019 09:15:10 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id m13so9795779ljj.11 for ; Sat, 21 Sep 2019 09:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r/wLEOnPoMeCNvAIG7RcF4asifTP8YuegJWiCR+Sneo=; b=nQIYkaxSJKIc+d92gi5K2P6tV/BMTQhR+iFZvOohNseYPNwsT1CL7CLL+BASBghEw2 oY+s6DkISRdsqlFD0yc09YOwe8FyJKDm39CeN9rTj9Mz4pDOVYvL/Epzvjd8LkYMWuWV 3terIdViu/bygQs/TYWUgCQ1BbVY6S9ErY5IAu6tWF/t7uU33eN3acJb3e3LP7Ui/Pxc ox3kjExJvBHO5TXOxPd3Dlrdc35Se6axSoZnpwOfaiEGX0QE4U8B84mjQjvl9ywUZRfe wcgqUoq4TtQ1B/PHkauoJRTXYhwhxglI8MIrpdimSGKuSO1Lu3l8CbEZpmFMqIbyezjh GXrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r/wLEOnPoMeCNvAIG7RcF4asifTP8YuegJWiCR+Sneo=; b=KqdaSL2hUGQRCYrfgKiLfo0QD2vcIQ0Gep01c1ORIf2phex8YW518VVOKRoRkGG/TP /Z77X1VRJ9i6pXPCNV5hMnePC1d4JBqmEcs6UtyR6IKqLPO0wAyu5M4H14AVgkhITQtV dAKaTP+LXg/ISin8ABJpAP6FFhXrFH6L3fEoQWedANqk9/WysHEdG5ZSSm8hVQnf62xS Ixbunbjx1bEvm7+iaCI6GJRRLr3Eq+AcphAJngm1NuCftHBEHVI+OYbLXYFud/vx/zik omavl6pojzImyRNVw3z9wPLSncZL1Q2LlrQiF7NYiKiIlFQMmuugiJlOaKVpGBPnGGqu NlvA== X-Gm-Message-State: APjAAAXw21GZDM3cyz4sJXzel1ACjp0SyMkBHPMJyDQuEGGutk4w8OrD z+yo83H8VfiVCYhZPw8aH/gf85i6T3llKHD5GRc48g== X-Google-Smtp-Source: APXvYqx6P7LWQqapwBM1lOsEr+EGwOKBtR4ZP7BJM/G1GNIrKeW13dBi5osSGddHEJmYhFuHyvNJLWi0z7QbnvKcITk= X-Received: by 2002:a2e:9584:: with SMTP id w4mr4175487ljh.145.1569082508271; Sat, 21 Sep 2019 09:15:08 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> In-Reply-To: <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> From: Eric Rescorla Date: Sat, 21 Sep 2019 09:14:31 -0700 Message-ID: To: Stephen Farrell Cc: Niels ten Oever , hrpc@irtf.org Content-Type: multipart/alternative; boundary="0000000000008778920593127dd4" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 16:15:13 -0000 --0000000000008778920593127dd4 Content-Type: text/plain; charset="UTF-8" On Sat, Sep 21, 2019 at 7:18 AM Stephen Farrell wrote: > > Hiya, > > On 21/09/2019 15:13, Eric Rescorla wrote: > > Again, let's take the example of SSL, which was designed by Netscape > > for its own market purposes and became a de facto standard because > > Netscape had the dominant browser and people wanted to interoperate > > with it. What's poltical about that process? > > To be fair, there was a lot of IETF politics around > Netscape and Microsoft related to that and IIRC TLS > was only called that as part of an explicit compromise. > Yes, that's why I said that *TLS* was the outcome of a political process. However, SSLv2 was just something Netscape published and SSLv3 was also prepared internally by Netscape in response to criticisms of SSLv2. -Ekr > I think Eliot's examples (and NTP, which I raised) > are maybe better examples of less/apolitical standards > and protocols than SSL/TLS. > > S. > --0000000000008778920593127dd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Sep 21, 2019 at 7:18 AM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 21/09/2019 15:13, Eric Rescorla wrote:
> Again, let's take the example of SSL, which was designed by Netsca= pe
> for its own market purposes and became a de facto standard because
> Netscape had the dominant browser and people wanted to interoperate > with it. What's poltical about that process?

To be fair, there was a lot of IETF politics around
Netscape and Microsoft related to that and IIRC TLS
was only called that as part of an explicit compromise.

Yes, that's why I said that *TLS* was the outcome of a= political process. However, SSLv2 was just something Netscape published an= d SSLv3 was also prepared internally by Netscape in response to criticisms = of SSLv2.

-Ekr


I think Eliot's examples (and NTP, which I raised)
are maybe better examples of less/apolitical standards
and protocols than SSL/TLS.

S.
--0000000000008778920593127dd4-- From nobody Sat Sep 21 12:03:30 2019 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 2213D120024 for ; Sat, 21 Sep 2019 12:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlW9RnqoTpyi for ; Sat, 21 Sep 2019 12:03:26 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDAF1200B8 for ; Sat, 21 Sep 2019 12:03:26 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id q12so6613741pff.9 for ; Sat, 21 Sep 2019 12:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=Ggu1OtUMsLtKFI9BHwek0UexlYz+QU3etXev7pwlkNQ=; b=a7ciryJ/x0exf6WTiswrZOa83UdyIlHw4TW5zmWOR63+l+oERcBwQEBZU+dp+ux1aP m1cYka7I6hlSEp0Z3x/e6QQ/1NuRdZcwCaIA3HgFGPOgl0BFsSo01MmjY5iKH6+jCWSQ BLvJ8EAmZqaMDartZnGzNvUiDbktlM6lyj70ycdXBYMMJObLa8RzxaxJvwCZ9DttSILv vcdDzoWEr1vjbZVWzKXy23ZzhxjJZXfco5j3uu1uRh4ZjS8+pEIRYH8f89Wvo365iVYd xEsYvxeTWKOSmJix2NlLfaYF7F0FY2vZNjgq2/BPZDEM00/sWtInvSrmMjNh7f7/POkn oHGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=Ggu1OtUMsLtKFI9BHwek0UexlYz+QU3etXev7pwlkNQ=; b=JffAAFHk39hCQ7caUllTL4fdWkGr2RiXb/W7MfZs9gfaWwSGOZ8E0m8gR6hQ9+pdBE SUEvl+JUmlXRzaLXOQRR3QCVRLcNoTfHx9LPRT9Ocdh+L/KhvhNSeM5lov+4MqVzcGx5 SJaYes7rzm5ksn/tvzLzSIVjSpOgvK98BkOdaNlcK9fP45xjIk6ZEuVx4mDdvGswQtq+ 6eNGUbudxQeqk+RnT4Pn1Nrge9dIoVYWo5OK92b22PuGZSwGQLr8b4eSr2dUJbb1CpIi WFC3DmbbVN7twV453ieqCOI3NGo6jwAlj5DK5cS/nixMwy4leC4y4WPM+XmD6Xvxa0sL QfUQ== X-Gm-Message-State: APjAAAWDQX21mJhrOaptzgkG7hNaRYKHBPy2dCJXwrjRfhc8erH2Xpx4 YLSV0Fnei0SyTgkf1Bed3lYkLxouE2A+ X-Google-Smtp-Source: APXvYqyDcLXKrT8+Taq3XXU+8gQO9DCpNs5UHiBxWA3TZYYVOsDnJUIZyRnp3C90toAreepX2/kVog== X-Received: by 2002:a63:594f:: with SMTP id j15mr7117819pgm.57.1569092605383; Sat, 21 Sep 2019 12:03:25 -0700 (PDT) Received: from aspen.local (63-140-65-24.dynamic.lte.acsalaska.net. [63.140.65.24]) by smtp.gmail.com with ESMTPSA id d76sm3399913pga.80.2019.09.21.12.03.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Sep 2019 12:03:24 -0700 (PDT) To: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: Date: Sat, 21 Sep 2019 11:03:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DtGDKJEFNqBuWrS1XWtStv0zsDr7xnXD0" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 19:03:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DtGDKJEFNqBuWrS1XWtStv0zsDr7xnXD0 Content-Type: multipart/mixed; boundary="EWAy21djzgsRWnfCqXtnlDlgVWx4aEMPX"; protected-headers="v1" From: Melinda Shore To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> In-Reply-To: --EWAy21djzgsRWnfCqXtnlDlgVWx4aEMPX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/21/19 5:09 AM, Niels ten Oever wrote: > "Network topology is a complicated political and economic question with= > obvious technical overtones" I don't think that answers Andrew's question. The economic argument being advanced in 613 is: 2. "Loops" are not good per se, they appear good because the act of making loops increases the connectivity and thereby reduces the effect of multiple failures. Adding more circuits costs ARPA money, both capital cost for IMP interfaces and recurring cost for the circuits. so there's a cost/benefit question there that's inherently economic. Anyway, how the IETF usually responds to discussions like this is to narrow the scope of the document. From my perspective the value in the document as it currently stands is primarily in the literature review, and there's much political in the IETF process (corporate jockeying, involvement of national governments) that isn't covered but which would make it incredibly difficult to get through any sort of consensus process if it were. I'd also argue that the literature review avoids, for the most part, problems around perceptions that opinions are being presented as facts. So, it seems to me that it might be useful to strip out section 5, rewrite the research question and conclusion, and to publish this as a literature review. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --EWAy21djzgsRWnfCqXtnlDlgVWx4aEMPX-- --DtGDKJEFNqBuWrS1XWtStv0zsDr7xnXD0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl2Gc/kACgkQ37iRcpp2 24+kvhAAxA2ARUfRCEc+goxS5C/y3A8UYjV3uVW/f+w8nApIHG+dxhpuymvvAjDw WT/o4t7uOQsJFVWzdHHvjTjum5ifQU52766zv/RUefInJPREnb46ois4pzsyXkJ9 AerNzAfOXvLLsgBzzQXeahFQBmGwwYumpyY4xAMDeBYNTNSVr79MKKBKo6u7ISh7 QK74Dxctf1Tger/A7lo/OzAb1yK8MgDE7er9Oc3ZVaoXLRkHvwL+HmOj1Whs1R2V NokRlYpkmp1wFmMh9CkbtaHps6JNhUnQBahvytRZvBHwU+BILN1raoNw6vrYuCvi i7KxOdhsicwmEZkT4FBkbFZcJmpHdAYkanJB5GBim+tc/m6HjJ68exNs6wpPq6kh f2MX4ydb30v0qnRzqyaLd791GJmtc4nG5SabeQpqONhVg3NCTKxWsLHKfQ3bRUid /6sXQ1FwRvU7cgtnIJ0d8wy+elEy2jGNishbK4DpOEbu6zZpdTMI5R5h1WTDX4Js u1mcKKCq425zAEv7WmjpKXrNrZRqv83eOVWTIhYV3ytMcqC9ibiSGAs+66SDeG6m 3D7R8wbnZrxdS3Pj4WHZsBjfxx5347lOdLTuyWEcBKfaUCSWtNnjbjt+YtjWuWBC EBrULxeY2ZLIgXj9u5eHjVQEZkx3uNMe+vf/HtvnWHOYNuALhsU= =vQsC -----END PGP SIGNATURE----- --DtGDKJEFNqBuWrS1XWtStv0zsDr7xnXD0-- From nobody Sun Sep 22 09:24:20 2019 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 18D851200DB for ; Sun, 22 Sep 2019 09:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mLeBz00YFUF for ; Sun, 22 Sep 2019 09:24:15 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E2A120059 for ; Sun, 22 Sep 2019 09:24:15 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id d2so14456464qtr.4 for ; Sun, 22 Sep 2019 09:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jlHJZFJctpG5QcYGy7VHVf4nfAV23WCTnNT2SRAbolA=; b=DaF/Z/eSx9QaGivD8dcJ31tesrKwo3iacCoZdc8ilBNWv0V2l6tLKwoU5qxOExwICS jQfUJfiyVYOByLSjtHj14yDhS+M9SPNOaDmpbru3BRWi4aU2OEvtpWXDtcVS/ITkZwA4 ikSVTYvnvooZqSsOmiXtDsr/8gHuaOHhix9HnwazgvesuWnRzvTl+2w1AOERu1WZKMOj K8CTh9wESujECdJHytpRzTAq/yeh+r7Pvoum1DaqeVR/TzFBxFIuGzO+C5WbvD3EpDOy ohS6Oh8lA3HxmVI+topZA7VnMNn7VEntwtjhoNNtzTsa5io8r6bSNxtvcmHGhrl8QiLZ +jKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jlHJZFJctpG5QcYGy7VHVf4nfAV23WCTnNT2SRAbolA=; b=KAaBf1c4ddM/mX6yDRwJpOK8t32pYk5azGBk1e9gjzSjqafetEzCh4Z+nni08cIQ5l A06mGjPNWDXey0OeMmnpF8HhUOpVpN583etIL+RQhpEAV8PSAPVr03JZpIUMfQneINHF C2fKnEQ49GFX6tIqHGmyBPk/NG85r6IToDxxnxOAt6qd+VYnKomM51yEdTzLugzThlNJ PIFVsGSQjnNQ3UCkSA5+1tT7osmvNfZWB/9IFUAQMMmrJDopAtzXVq81eEhUolNM8U9+ SWMymExt8WwWF6Bmxy7/fFBKQZrPKwkDpYyQJL2FA54r9B02GGB7JwwPii147YS9CU3g Qx4g== X-Gm-Message-State: APjAAAXGmbxiX62H05WekYFhxqlnsTLUZM1/+fU4WkRrayALsmJ21lR4 v6FJaobkPiIIwH1s4uwUu/DT8FwZRsfe6rKqX/E= X-Google-Smtp-Source: APXvYqxPM/3GuX+Dto+ZQ0ZXdWam243IwXaXGTbY/j0wBMflLxkxSE36Kw4SXkvJuLMAryG/3buLWON+JkxhApQRorI= X-Received: by 2002:a0c:c541:: with SMTP id y1mr21563214qvi.116.1569169454081; Sun, 22 Sep 2019 09:24:14 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> In-Reply-To: From: farzaneh badii Date: Sun, 22 Sep 2019 12:23:47 -0400 Message-ID: To: Melinda Shore Cc: hrpc@irtf.org Content-Type: multipart/alternative; boundary="000000000000e73510059326bb02" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2019 16:24:18 -0000 --000000000000e73510059326bb02 Content-Type: text/plain; charset="UTF-8" Hello, It is not enough to invoke certain authors' assertions or an RFC and present them as evidence. The claims and arguments in this document have to be analyzed in much more depth and every argument needs to be backed up with evidence. Additionally, I think the author is asking one question which he does not sufficiently address and then in its conclusion, he provides a whole different argument and in my opinion another hypothesis. He asks: To bring about a better understanding on the political nature of standards and protocols, this documents asks the questions: If, and if so how, are protocols, standards, and politics interrelated? He concludes: we might need to give a qualified answer to the research question, in the sense that protocols can only be understood in part outside of their actual shaping, use, and applied function, which is political. This document is simply incomplete and not ready to be even discussed further. Also I think I have read the literature review part somewhere else. If that is the case, then we don't have to publish it as a lit rev either. Farzaneh On Sat, Sep 21, 2019 at 3:03 PM Melinda Shore wrote: > On 9/21/19 5:09 AM, Niels ten Oever wrote: > > "Network topology is a complicated political and economic question with > > obvious technical overtones" > > I don't think that answers Andrew's question. The economic argument > being advanced in 613 is: > > 2. "Loops" are not good per se, they appear good because the act of > making loops increases the connectivity and thereby reduces the > effect of multiple failures. Adding more circuits costs ARPA money, > both capital cost for IMP interfaces and recurring cost for the > circuits. > > so there's a cost/benefit question there that's inherently economic. > > Anyway, how the IETF usually responds to discussions like this is to > narrow the scope of the document. From my perspective the value in > the document as it currently stands is primarily in the literature > review, and there's much political in the IETF process (corporate > jockeying, involvement of national governments) that isn't covered > but which would make it incredibly difficult to get through any sort > of consensus process if it were. I'd also argue that the literature > review avoids, for the most part, problems around perceptions that > opinions are being presented as facts. > > So, it seems to me that it might be useful to strip out section 5, > rewrite the research question and conclusion, and to publish this as > a literature review. > > Melinda > > -- > Melinda Shore > melinda.shore@nomountain.net > > Software longa, hardware brevis > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000e73510059326bb02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

=C2=A0It is not enough=C2=A0to invoke certain autho= rs' assertions or an RFC and present them as evidence. The claims and a= rguments in this document have to be analyzed in much more depth and every = argument needs to be backed up with evidence.=C2=A0

Additionally, I th= ink the author is asking one question which he does not sufficiently addres= s and then in its conclusion, he provides a whole different argument and in= my opinion another hypothesis.=C2=A0

He asks: To=C2=A0bring about a better understanding = on the political nature of
=C2=A0 =C2=A0standards and protocols= , this documents asks the questions: If, and
=C2=A0 =C2=A0if so how, are= protocols, standards, and politics interrelated?

He conclude= s:=C2=A0we might nee= d to give a qualified answer to the research question, in=C2=A0=C2=A0the sense that prot= ocols can only be understood in part outside of
=C2=A0 =C2=A0their actual shaping, use, = and applied function, which is political.



This docum= ent is simply incomplete and not ready to be even discussed further. Also I= think I have read the literature review part somewhere else. If that is th= e case, then we don't have to publish it as a lit rev either.


=



Farzaneh


On Sat, Sep 21,= 2019 at 3:03 PM Melinda Shore <melinda.shore@nomountain.net> wrote:
On 9/21/19 5:09 AM, Niels ten Oever wro= te:
> "Network topology is a complicated political and economic questio= n with
> obvious technical overtones"

I don't think that answers Andrew's question.=C2=A0 The economic ar= gument
being advanced in 613 is:

=C2=A0 =C2=A0 2.=C2=A0 "Loops" are not good per se, they appear g= ood because the act of
=C2=A0 =C2=A0 making loops increases the connectivity and thereby reduces t= he
=C2=A0 =C2=A0 effect of multiple failures.=C2=A0 Adding more circuits costs= ARPA money,
=C2=A0 =C2=A0 both capital cost for IMP interfaces and recurring cost for t= he
=C2=A0 =C2=A0 circuits.

so there's a cost/benefit question there that's inherently economic= .

Anyway, how the IETF usually responds to discussions like this is to
narrow the scope of the document.=C2=A0 From my perspective the value in the document as it currently stands is primarily in the literature
review, and there's much political in the IETF process (corporate
jockeying, involvement of national governments) that isn't covered
but which would make it incredibly difficult to get through any sort
of consensus process if it were.=C2=A0 I'd also argue that the literatu= re
review avoids, for the most part, problems around perceptions that
opinions are being presented as facts.

So, it seems to me that it might be useful to strip out section 5,
rewrite the research question and conclusion, and to publish this as
a literature review.

Melinda

--
Melinda Shore
melinda.s= hore@nomountain.net

Software longa, hardware brevis

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000e73510059326bb02-- From nobody Sun Sep 22 18:13:52 2019 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 9BFB11200EF for ; Sun, 22 Sep 2019 18:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 rAjjA0KFd1u8 for ; Sun, 22 Sep 2019 18:13:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 BE31F1200B8 for ; Sun, 22 Sep 2019 18:13:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46c5td3g93zFLK; Mon, 23 Sep 2019 03:13:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1569201225; bh=6K8r/AvbjJ2SMKkzkhOIMPkuX+jx2UHEW58TGQTvgzo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gIYKjUUFy3k9vncvTnaYzbPDPVolfU9iri2jS/yXzE9tmb2L+squiv/10djGZ9JOp ebec/Ku9NXtBpI5noN3pHxj533f4qlFc/FnKG7EPoCR2RQfuTSMuxcvSSiIE/EkD72 6DA7IzdRAEdZTBEnZVsodAaznh5hmVjT2yr8rtyU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4oRrILlXGkbh; Mon, 23 Sep 2019 03:13:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 23 Sep 2019 03:13:43 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 48F8D5E4338; Sun, 22 Sep 2019 21:13:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 48F8D5E4338 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3F0ED401AF14; Sun, 22 Sep 2019 21:13:42 -0400 (EDT) Date: Sun, 22 Sep 2019 21:13:42 -0400 (EDT) From: Paul Wouters To: farzaneh badii cc: hrpc@irtf.org In-Reply-To: Message-ID: References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 01:13:51 -0000 On Sun, 22 Sep 2019, farzaneh badii wrote: > This document is simply incomplete and not ready to be even discussed further. Documents can always be discussed and that is the way to improve documents. Documents might not get published by lack of progress or lack of consensus, but discussion is always valid. Paul From nobody Mon Sep 23 02:32:23 2019 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 4753A120106 for ; Mon, 23 Sep 2019 02:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBoVDgyDTlQG for ; Mon, 23 Sep 2019 02:32:18 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 4089A120072 for ; Mon, 23 Sep 2019 02:32:17 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iCKh5-0000Za-Pn; Mon, 23 Sep 2019 11:32:14 +0200 To: Eric Rescorla Cc: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <793367e8-7151-354e-04ca-b472760c6af7@nielstenoever.net> Date: Mon, 23 Sep 2019 11:31:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: f82a8ff824242e9d9dacb8e7c095c811 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 09:32:21 -0000 On 9/21/19 4:13 PM, Eric Rescorla wrote: >> Niels ten Oever via ietf.org >> >> 6:10 AM (48 minutes ago) >> >> to hrpc >> >> >> On 9/21/19 3:32 AM, Eric Rescorla wrote: >> >    Whereas there might not be agreement among the Internet protocol >> >    community on the specific political nature of the technological >> >    development process and its outputs, it is generally agreed that >> >    standards and protocols are both products of a political process, and >> >    they can also be used for political means. >> >     >> > I would like to register my agrement with Andrew and focus in on this >> > one point: there are many protocols (in fact, by count probably most >> > protocols) which are just designed by proprietary organizations.  It's >> > not clear on what basis you are claiming that they are the output of >> > political processes and this certainly doesn't seem like something >> > that's generally agreed. >> >> Aren't proprietary standards, and the way they make it possible and >> impossible to do certain things, a prime example of a political >> process and political impact? > > Well, I don't think without stretching the term "political" outside > of the point where saying something is political is trivial, no, > I don't think so. > > Again, let's take the example of SSL, which was designed by Netscape > for its own market purposes and became a de facto standard because > Netscape had the dominant browser and people wanted to interoperate > with it. What's poltical about that process? > > There are several political aspects about this, we had for instance text in a previous version that read about dominance and de facto standards: Within economy studies, _de facto_ standards arise in market situations where one entity is particularly dominant; downstream competitors are therefore tied to the dominant entity's technological solutions [Ahlborn]. Under EU anti-trust law, _de facto_ standards have been found to restrict competition for downstream services in PC software products [CJEU2007], as well as downstream services dependent on health information [CJEU2004]. Another interesting aspect that SSL introduced were of course certificate authorities, that served as trust anchors, which is ultimately defining trusted authorities. SSLv2 was introduced as open standard (while v1 was not), which of course was also quite a change, I reckon I don't need to elaborate on the politics of licensing in this audience. > >> > I certainly agree that they "can be used" >> > for political means, though any "can" statement is pretty weak. >> > >> >> If we can document *that*, we would have made a lot of progress in >> the IETF imho. > > I don't know anyone disagrees with that. Great. But I meet them at every IETF meeting, and it is brought up very regularly in discussion. > But in any case, demonstrating > that doesn't require hauling in the theoretical apparatus you > are trying to deploy here, but rather requires *history*. I.e., > demonstrate that the process of developing some set of standards > involved the political process of balancing the objectives of > the various stakeholders, finding compromise, etc. Given that > every IETF standards development process I have ever been involved in > has had some of this, that doesn't seem hard. As a non-IETF example > "The Box", a history of the shipping container, has a nice description > of the standardization of that technology. > > >> > This is even true at some level for many standards, especially >> > because your definition of "standard" is so expansive: >> > >> >    Standards  'A standard is an agreed-upon way of doing something or >> >       measuring something.'  [Sisson] >> > >> > By this definition I think it would be pretty hard to argue that >> > SSLv2,  and SSLv3 weren't standards given their wide use, even >> > though they were just designed by people at one company. >> >> I don't see how that definition would make that impossible. > > I'm not sure I understand your response here. Are you saying that > protocols defined by one company and that then achieve wide use > are standards, or they are not? > SSLv2 and SSLv3 were standards because people agreed that they were the standard? For something to be a standard it does not need to be a formal process to accept them as such. >> > Another >> > example would be the Philips screwdriver head. What's the political >> > process that produced these? >> > >> > >> >> The patenting of process by Henry F. Philips, the regimes under >> which is was patented, its competition with other screw heads (torx, >> etc). There is an enormous amount of politics, and societal ordering >> connected with screws. > > Again, this just seems to serve to make the definition of "political" > meaningless. By this definition, what human commercial activity > would *not* be political, as it all occurs against a political > backdrop. > A transaction can be political, but of course does not need to be. (Trans)action, such as standards, that change the market, are political activities. > >> > More generally, it seems like depending on how one interprets the >> > major claims in this document, they are either too strong (all >> > protocol and standards development is political) >> >> Why is that too strong? > > For the reasons I indicated above: I don't think the development > of many protocols, especially the small ones which get use internally > as in, for instance, mobile apps, is generally political, And sometimes > becoome standards and that's not necessarily political either. > > >> > or trivial (some >> > protocol and standards development is political). The first is too >> > strong for the reasons I indicate above, >> >> I don't think so, but I am happy to discuss. >> >> and the second seems pretty >> > obvious and doesn't really need much theorizing; >> >> As said, I think it would be very useful if we would document this, >> so we don't need to repeat the discussion. > > Well, I'm not sure it matters if we repeat this discussion or > even come to a conclusion on it. What's at stake in the answer? > > But, again, if you want to demonstrate that standards development > can be political -- which, as I said, is a rather weak claim -- > then I would discard this document and instead focus on documenting > the history of the development of some protocols that was clealr > political. > > As you know, what this draft meant to do, is to document a discussion so it doesn't need to be repeated in the study of every different protocol. We could paste in a lot of examples here, for instance some of the review of the human rights review team. But the discussion in 4.5 might be enough? >> >> > one needs just point >> > to the development of some protocol which was a political process, and >> > it seems like that's been pretty amply documented for a number of >> > protocols/standards (e.g., HTTP/2 or TLS 1.0). >> > >> > As I noted above, the claim that protocols can be used for political >> > means also seems relatively obvious (cf. Tor). >> >> I am happy to conclude that we agree on the two statements: >> >> - some protocol and standards development is political >> >> and >> >> - protocols can be used for political means > > Well, I don't think this document demonstrates that, it's just > conclusory.  To the extent to which we think these statements are > actually in debate and need demonstrating, then I would, as I said, > focus on demonstrating them with reference to actual standards > rather than by referring to other people's views about these > statements. I would think 3-5 of each of these should be sufficient > (though of course logically one alone is sufficient to prove > existence, but several is more convincing) > Again, the document seeks to document existing positions in the community and provide background in existing literature on the topic, that could then be a platform for further work. For instance on specific drafts, and or specific tendencies (based on case studies, quantitative models, etc). Best, Niels >           >> That's progress for me in this discussion. Now let's see if we can >> further flesh out: >> >> - all protocol and standards development is political > > I think what would help at this point that would be for you to > describe some commercial activities that you think are *not* > political. > > -Ekr > > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Mon Sep 23 02:44:22 2019 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 10048120072 for ; Mon, 23 Sep 2019 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNQlqlIgg98G for ; Mon, 23 Sep 2019 02:44:19 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 4ADB912002F for ; Mon, 23 Sep 2019 02:44:19 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iCKt2-0002O9-PJ; Mon, 23 Sep 2019 11:44:15 +0200 To: Stephen Farrell , Eric Rescorla Cc: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Mon, 23 Sep 2019 11:44:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y1dO2XgkxizxE1zUPoi9DAnhNOhnb7VTe" X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4c1f0696016754537de762f13eb96caa Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 09:44:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --y1dO2XgkxizxE1zUPoi9DAnhNOhnb7VTe Content-Type: multipart/mixed; boundary="krZDJRZcJ06YYgJmyN2W0d4uvPAZxh8Ax"; protected-headers="v1" From: Niels ten Oever To: Stephen Farrell , Eric Rescorla Cc: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> In-Reply-To: <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> --krZDJRZcJ06YYgJmyN2W0d4uvPAZxh8Ax Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/21/19 4:18 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 21/09/2019 15:13, Eric Rescorla wrote: >> Again, let's take the example of SSL, which was designed by Netscape >> for its own market purposes and became a de facto standard because >> Netscape had the dominant browser and people wanted to interoperate >> with it. What's poltical about that process? >=20 > To be fair, there was a lot of IETF politics around > Netscape and Microsoft related to that and IIRC TLS > was only called that as part of an explicit compromise. >=20 > I think Eliot's examples (and NTP, which I raised) > are maybe better examples of less/apolitical standards > and protocols than SSL/TLS. >=20 Time, and its standardization, is a very political project. Going back to= Aristotle (Physics iv 10-14) there is the difference between Chronos and= Kairos, where Chronos became the number to measure motion (kinesis). The= re have been many other perceptions and measurements of time, that were a= ble to exist next to each other, but as part of the colonial project, the= European concept of what time was, was made the universal standard. That= is why Greenwich Mean Time (in Great Britain) is used as a standard for = the whole world.=20 There are also many stories about the development of timezones, and their= consequences, the way in which time helped shape labor, life, and how it= altered complete societies. I am not making a value judgment about this re-odering, but I am trying t= o show that NTP, which helps synchronize to a specific time regime, on wh= ich a lot of computing depends, helps promulgate a specific, and politica= l, ordering.=20 This book on the topic is quite interesting: https://www.amazon.com/Colonisation-Time-Studies-Imperialism/dp/071908271= 4 Best, Niels --=20 Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 643A 0ED8 3F3A 468A C8B3 --krZDJRZcJ06YYgJmyN2W0d4uvPAZxh8Ax-- --y1dO2XgkxizxE1zUPoi9DAnhNOhnb7VTe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl2Ik+MACgkQDtg/OkaK yLMjshAAlK+xPtYUl4/JwPJgc4rQWj+SKU8CMIc0k11rCFcXjhaiTGStdrJ2wFx4 0jjajE+HUgs982xxJLlQFYShoBEgU2vhCDDybylH/kgBsa31DivwNtWCTWVUCHn5 pHLfPOqQWWmURF0BMRxBG72HKFLPkaDAM9Ocb7Yd8K7S9tJyYI0nVb0aLj3SGEIp KN/yVkRzuKwg69tfk7lSNsrgw8Rqeila4uSTCHrbsVRZklqRcsSJoPhuS1DgHPfe 762zNNlGsfrB1pTZdhHNB/1H69jNaOqqu5w8Pqu8q0u5Ltky1gOfBd3klyUqB4W/ qL4rggfxHBc6PsdeZ4bz6+HfwGqHTPNR4Sx0da5t/dWld729QJa/eiGfYv/Jl0Sl DdKdgGdQLIFQwB/b1FFQwcAnHKzsqWKS9dz8dRzTs06wpVMpJp8i3dVivkErzHzd knkGJutf50DBkYzNga0MuKGu3PyD5E3ttKZNbRG9g7R765vztO3I4K3azCIteN1A EnpttqOVIyollihy8Jfo5FMseHOGAGv/o79A2d8E0fgTx8X8O3zr2DPo04eBTRE3 C9PZ7b/JV5KY1QE5JCOg6ozv884JQN7Bg6ch7Lym3CnTe3uiLXXhp3JlYmeKSyKo K4HKaNeox48pRQY+j/OOvrzVc3u7eKA7XTGh2btcGGOvPiikVT8= =oMsa -----END PGP SIGNATURE----- --y1dO2XgkxizxE1zUPoi9DAnhNOhnb7VTe-- From nobody Mon Sep 23 04:18:44 2019 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 6C528120807 for ; Mon, 23 Sep 2019 04:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxDJZPhsO2p7 for ; Mon, 23 Sep 2019 04:18:39 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FD9120073 for ; Mon, 23 Sep 2019 04:18:39 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id u22so16538761qtq.13 for ; Mon, 23 Sep 2019 04:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jDBrZZWGx/v/kk2BfpdFT5F8VI3AWVsHZjSXDkdXCbo=; b=IfiZJ4VDTIIdR3POSoxZxiZ3hwt/h2Pdhn3ig3W1YTPlE81HYWCl415EY8kpkotWfL mpWiPxj1zT/67okcN6ClIZ/4wb1c/puVFeNTfoxDIjuEDttmKufTs9H1xnPzQbBC379q SXdU5i9N19lTy/+NdwwzulGfRoQeGosPLfrQaoSkBb6l0kwJRtWq9SMolGWCdtC3U+Kq 4rnoSSxmey5R3Ris+8+2X5rDDBtYLxUfZmgNWo9hJQDuLHhF6kN4fjJC5VRm4feHRKh5 FURCzOH5VM9SOyLYMM5gQpzzLRKBLqckyVv3JvngK7f7sgONB0Mmw/Jc4aYibaQBgEN6 /3+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jDBrZZWGx/v/kk2BfpdFT5F8VI3AWVsHZjSXDkdXCbo=; b=NE5pdFERFWUosmPl1FvYwb2JOuCzEYNyN59PW+q4oHnGKnRPaGQOUfFY0l2lLZO0/u FQVa5DRRCKlOSxCKFPLxWOXedOnMZN/FCoT0dRKVV1SMtkY8acbvE0AtzJEOSuOgSMTO 0t1RQ599zhFgYvONWUU5ND/ccY5iwYBNpoouSDgOBwshFz6yv4wc/iNeFLkjweHJAxES pDp7fefB59mlnPVehPXiJ2SMCNQBT/c/6f4ZjicClTOnjaKw2FhrOdrSLhVInJvJVQZ+ SBBv2oHHXC9F3Xgq1qDquur9JO+l7nIF5yXGVIFmR/crKJYeK1pLmAlrXEt40Wy6Xvi7 H6mA== X-Gm-Message-State: APjAAAV69neHFs4npjT+39j1BRJ81utDHLxfFgim5t8X48DlLkatkECG //qVKD97DwReKmERbrWoaqGCKA== X-Google-Smtp-Source: APXvYqzHJ1Wj/ulnZfx8UCMzxWm9muoG5bmp+LFhUI02nCDhvGoLvH2FomrO3XZhVvVbef+8e7R+Vw== X-Received: by 2002:ac8:110a:: with SMTP id c10mr16287325qtj.259.1569237518750; Mon, 23 Sep 2019 04:18:38 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id f10sm4961574qtj.3.2019.09.23.04.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Sep 2019 04:18:38 -0700 (PDT) From: Ted Lemon Message-Id: <26C776B9-3301-4E7A-BC37-5E2DA08EE4F7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_56E32E67-EF19-4714-9234-4E1242D27965" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.13\)) Date: Mon, 23 Sep 2019 07:18:36 -0400 In-Reply-To: Cc: Stephen Farrell , Eric Rescorla , hrpc@irtf.org To: Niels ten Oever References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> X-Mailer: Apple Mail (2.3594.4.13) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 11:18:42 -0000 --Apple-Mail=_56E32E67-EF19-4714-9234-4E1242D27965 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 23, 2019, at 5:44 AM, Niels ten Oever = wrote: > Time, and its standardization, is a very political project. Going back = to Aristotle (Physics iv 10-14) there is the difference between Chronos = and Kairos, where Chronos became the number to measure motion (kinesis). = There have been many other perceptions and measurements of time, that = were able to exist next to each other, but as part of the colonial = project, the European concept of what time was, was made the universal = standard. That is why Greenwich Mean Time (in Great Britain) is used as = a standard for the whole world.=20 This might actually be an interesting angle to explore. I think in one = sense you are right about this (and don=E2=80=99t forget the Julian = calendar while you=E2=80=99re at it). But here we are, in this time period that exists long after this = political discussion occurred. Do you think that time is still = political in the sense that you are saying now? Can you talk about what = that means? What the tensions are? Who benefits from the status quo? = Who might benefit from a change? I point this out because I think in a sense the Internet is in a time = when a lot of things are in flux, and so we can see that there might be = political pressures. And we can posit that there will be some time, = perhaps in the far future, when these questions are no longer political, = or at least no longer political in the same way. What is between here and there? What are the reefs around which we must = navigate? Or is it in fact not the case that we will ever reach that = open ocean? --Apple-Mail=_56E32E67-EF19-4714-9234-4E1242D27965 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 23, 2019, at 5:44 AM, Niels ten Oever <mail@nielstenoever.net> wrote:
Time, and its standardization, is a very political project. = Going back to Aristotle (Physics iv 10-14) there is the difference = between Chronos and Kairos, where Chronos became the number to measure = motion (kinesis). There have been many other perceptions and = measurements of time, that were able to exist next to each other, but as = part of the colonial project, the European concept of what time was, was = made the universal standard. That is why Greenwich Mean Time (in Great = Britain) is used as a standard for the whole world. 

This might actually be an interesting = angle to explore.   I think in one sense you are right about this = (and don=E2=80=99t forget the Julian calendar while you=E2=80=99re at = it).

But here = we are, in this time period that exists long after this political = discussion occurred.  Do you think that time is still political in the sense that you are saying now? =  Can you talk about what that means?  What the tensions are? =  Who benefits from the status quo?  Who might benefit from a = change?

I point this out because I = think in a sense the Internet is in a time when a lot of things are in = flux, and so we can see that there might be political pressures. =  And we can posit that there will be some time, perhaps in the far = future, when these questions are no longer political, or at least no = longer political in the same way.

What is = between here and there?  What are the reefs around which we must = navigate?   Or is it in fact not the case that we will ever reach = that open ocean?

= --Apple-Mail=_56E32E67-EF19-4714-9234-4E1242D27965-- From nobody Mon Sep 23 04:49:50 2019 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 7166E120073 for ; Mon, 23 Sep 2019 04:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 qksk3Xi6rrGN for ; Mon, 23 Sep 2019 04:49:45 -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 8E3A612008C for ; Mon, 23 Sep 2019 04:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13629; q=dns/txt; s=iport; t=1569239384; x=1570448984; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=XXRd1PL8s/886DYpkc5hlXdrEta3Ki7fyPPY14KNOjc=; b=hAjupDtTHpvBzd5nX5rrx/SpGGUzhYEF7/J/94qwKHMVHNgSzjaAVNnv h2FY1Nfiledgy3Im2FELt0hquUGcNBcoMFi+TMPZkeEESpWm/b4McahrE jH3zfFsJhjf/+S3xH0jb55nfeHpB7uth9puOn8Roa1NmLVhVi8PVsVHyy A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAADrsIhd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBZ4EcgW9TIBIqhCKIfId6JYdEi1OIBgIHAQEBCQMBASM?= =?us-ascii?q?MAQGEPwKDOTgTAgMJAQEEAQEBAgEFBG2FLQyFSgEBAQECASNWBQsLGCoCAlc?= =?us-ascii?q?GExUEgwkBgXsPD6s6c4EyhDcBgRSEaQoGgTSBUYpQgX+BECgME4JMPoJhAQI?= =?us-ascii?q?BgT8BAYMpMoImBIpRgX1SiGKXCoIsgi6BE4I0hiSIcRuNf4Z6hCykHoMRAgQ?= =?us-ascii?q?GBQIVgWkhRIEUMxoIGxVlAYJBPhIQFIN6jBs+AzABjCeCRQEB?= X-IronPort-AV: E=Sophos;i="5.64,539,1559520000"; d="asc'?scan'208,217";a="17170105" 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-SEED-SHA; 23 Sep 2019 11:49:42 +0000 Received: from [10.61.212.69] ([10.61.212.69]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x8NBnfFJ014422 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Sep 2019 11:49:42 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6A5CD394-C969-4291-83A3-523E38A8352F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 13:49:40 +0200 In-Reply-To: Cc: Stephen Farrell , hrpc@irtf.org To: Niels ten Oever References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.212.69, [10.61.212.69] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 11:49:48 -0000 --Apple-Mail=_6A5CD394-C969-4291-83A3-523E38A8352F Content-Type: multipart/alternative; boundary="Apple-Mail=_537CC251-26F2-4589-ACF0-AA17DC136E43" --Apple-Mail=_537CC251-26F2-4589-ACF0-AA17DC136E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! This is mostly geeky entertainment. [Ted, I saw your note after putting most of this together. Time has = been explored=E2=80=A6 ad infinitum :-), but see below for some = entertainment.] > On 23 Sep 2019, at 11:44, Niels ten Oever = wrote: >=20 > Time, and its standardization, is a very political project. Going back = to Aristotle (Physics iv 10-14) there is the difference between Chronos = and Kairos, where Chronos became the number to measure motion (kinesis). = There have been many other perceptions and measurements of time, that = were able to exist next to each other, but as part of the colonial = project, the European concept of what time was, was made the universal = standard. That is why Greenwich Mean Time (in Great Britain) is used as = a standard for the whole world. But interestingly enough the initial reason for standardization of time = in Britain was not political, but a simple matter of practicality; and = it wasn=E2=80=99t the government who standardized time per-se, but = rather the railways in 1847, in order to manage train schedules, and = this was known as Railway Time. It wasn=E2=80=99t until 1880 that GMT = was officially standardized across the island of Great Britain. GMT was = set as an international standard in 1925 as a practical way for = astronomers to agree on when the day began. This gives you some idea as to just how recent in our history there was = any sort of standardization of what the time is at any given moment. = However, the much of the actual units of time that we use today date = back to at least 1500 BC and the Egyptians. As Ted points out, NTP and the TZ database are based on the Gregorian = calendar scale. This does indeed prove troublesome for some countries = and cultures who are on a lunar calendar. This was noted in the = development of the calendaring standard, where a =E2=80=9Ccalscale=E2=80=9D= can be specified, but to my knowledge nobody has ever used anything = other than Gregorian.* The folks Calconnect could correct me, tho. >=20 > There are also many stories about the development of timezones, and = their consequences, the way in which time helped shape labor, life, and = how it altered complete societies. Time? Sure, but what part of standardization? Time zones? Not as = much. The first official time zone difference was used by New Zealand in 1868 = as a convenience to know what time it was in the home office, as it = were. This before there was a legal standard on Great Britain. And then there are DST transitions. These were introduced by Germany in = 1916. With Europe about to make a remarkable leap (so to speak) into = the unknown, nobody can possibly say that there isn=E2=80=99t a = political influence on time zones.** The political impact? People = debate them, so I suppose there must be some. There are some interesting stories. One involves a contract with a = satellite operator with the Holy See in which the contract was written = in local time in Brazil. Apparently they booked the wrong hour, and so = a law was passed to change time. This is actually documented in the TZ = file for South America. >=20 > I am not making a value judgment about this re-odering, but I am = trying to show that NTP, which helps synchronize to a specific time = regime, on which a lot of computing depends, helps promulgate a = specific, and political, ordering. Let us be precise: NTP requires only two protocol invariants: the = length of a second itself and a particular epoch. The one field that = has any real political aspect at this point is the leap second = indicator. There have been some, dare I say, highly entertaining = debates in the ITU-R over leap seconds. Indeed it=E2=80=99s those pesky = astronomers who are once again concerned about dinking with leap = seconds.[1] And let=E2=80=99s not even get into whether Pluto is a = planet! Still, the protocol itself is neutral as to how and when the = leap second bit is set, or who has the authority to set it. Eliot [*] I gave at tictoc circa 2010 on a Brief History of Time(Zones) that = shows Israel spiking; that=E2=80=99s because of a combination of time = scale, and issues relating to the High Holidays. This has mostly been = kinked out, but not entirely. If a transition would occur on Rosh = Hashanah, it is moved to the 1st of October. This cannot be accurately = reflected in the TZ database in a programmatic fashion. [**]. No, this is not an invitation to debate Europe=E2=80=99s decision. = Take it to facebook! ;-) [***] If you would like references for the above, I highly recommend A = Brief History of Time, and Wikipedia now does a very decent job of it. [1] https://www.abc.net.au/science/articles/2005/09/23/1466849.htm --Apple-Mail=_537CC251-26F2-4589-ACF0-AA17DC136E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi!

This is = mostly geeky entertainment.

[Ted, I = saw your note after putting most of this together.  Time has been = explored=E2=80=A6 ad infinitum :-), but see below for some = entertainment.]

On 23 Sep 2019, at 11:44, Niels = ten Oever <mail@nielstenoever.net> wrote:

Time, and its standardization, is a very political project. = Going back to Aristotle (Physics iv 10-14) there is the difference = between Chronos and Kairos, where Chronos became the number to measure = motion (kinesis). There have been many other perceptions and = measurements of time, that were able to exist next to each other, but as = part of the colonial project, the European concept of what time was, was = made the universal standard. That is why Greenwich Mean Time (in Great = Britain) is used as a standard for the whole world. 


But = interestingly enough the initial reason for standardization of time in = Britain was not political, but a simple matter of practicality; and it = wasn=E2=80=99t the government who standardized time per-se, but rather = the railways in 1847, in order to manage train schedules, and this was = known as Railway Time.  It wasn=E2=80=99t until 1880 that GMT was = officially standardized across the island of Great Britain.  GMT = was set as an international standard in 1925 as a practical way for = astronomers to agree on when the day began.

This gives you some idea as to just how recent in = our history there was any sort of standardization of what the time is at = any given moment.  However, the much of the actual units of time = that we use today date back to at least 1500 BC and the = Egyptians.

As Ted points out, NTP = and the TZ database are based on the Gregorian calendar scale. =  This does indeed prove troublesome for some countries and cultures = who are on a lunar calendar.  This was noted in the development of = the calendaring standard, where a =E2=80=9Ccalscale=E2=80=9D can be = specified, but to my knowledge nobody has ever used anything other than = Gregorian.*  The folks Calconnect could correct me, = tho.


There are also many stories = about the development of timezones, and their consequences, the way in = which time helped shape labor, life, and how it altered complete = societies.


Time?  Sure, but = what part of standardization?  Time zones?  Not as = much.

The first official time zone = difference was used by New Zealand in 1868 as a convenience to know what = time it was in the home office, as it were.  This before there was = a legal standard on Great Britain.

And= then there are DST transitions.  These were introduced by Germany = in 1916.  With Europe about to make a remarkable leap  (so to = speak) into the unknown, nobody can possibly say that there isn=E2=80=99t = a political influence on time zones.**  The political impact? =  People debate them, so I suppose there must be some.

There are some interesting stories.  One = involves a contract with a satellite operator with the Holy See in which = the contract was written in local time in Brazil.  Apparently they = booked the wrong hour, and so a law was passed to change time. =  This is actually documented in the TZ file for South = America.


I am not making a value = judgment about this re-odering, but I am trying to show that NTP, which = helps synchronize to a specific time regime, on which a lot of computing = depends, helps promulgate a specific, and political, ordering. 


Let us be precise:  NTP requires only two protocol = invariants: the length of a second itself and a particular epoch. =  The one field that has any real political aspect at this point is = the leap second indicator.  There have been some, dare I say, = highly entertaining debates in the ITU-R over leap seconds.  Indeed = it=E2=80=99s those pesky astronomers who are once again concerned about = dinking with leap seconds.[1]  And let=E2=80=99s not even get into = whether Pluto is a planet!  Still, the protocol itself is neutral = as to how and when the leap second bit is set, or who has the authority = to set it.

Eliot

[*]  I gave at tictoc circa 2010 on a Brief = History of Time(Zones) that shows Israel spiking; that=E2=80=99s because = of a combination of time scale, and issues relating to the High = Holidays.  This has mostly been kinked out, but not entirely. =  If a transition would occur on Rosh Hashanah, it is moved to the = 1st of October.  This cannot be accurately reflected in the TZ = database in a programmatic fashion.
[**]. No, this is not an = invitation to debate Europe=E2=80=99s decision.  Take it to = facebook! ;-)
[***] If you would like references for the = above, I highly recommend A Brief History of Time, and Wikipedia now = does a very decent job of it.



= --Apple-Mail=_537CC251-26F2-4589-ACF0-AA17DC136E43-- --Apple-Mail=_6A5CD394-C969-4291-83A3-523E38A8352F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2IsVQACgkQh7ZrRtnS ejM9GQf/SRJ/VIz55Jq4Fs9ntMpl/Ng0WIrbLrZPMXS/eL53LsXE1kNa9Xkb3DQ8 T/8d0QxttrJPiV5dismHVqoF5sxxHkZFMbBLOQsYtC4IUv14qp4JCKvJpCcwTp8k v2DAhtm7p9dMaOg8ByjKeGFRjdmoc2tKK4kZWokYlRv2xF31inQsNY4Nuco7jJ8g VR808h9uv77WpRxugE1EMxjIffdAbqoDhhRGJVlc0gzb/ft+h5Qac6vriEyS6OMy nrBhSQPox2khQc1JwTVe8CZSdLjf72dKtjevEdm4gCEMNUvMFePwNFctYCmo/iFx CPTdVx9w+Kjht+Nh9F9VvD68lboz9Q== =PYzx -----END PGP SIGNATURE----- --Apple-Mail=_6A5CD394-C969-4291-83A3-523E38A8352F-- From nobody Mon Sep 23 04:57:26 2019 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 D3E7F12008C for ; Mon, 23 Sep 2019 04:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZt1kMu23ad2 for ; Mon, 23 Sep 2019 04:57:23 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CAF12006F for ; Mon, 23 Sep 2019 04:57:23 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id c21so16663855qtj.12 for ; Mon, 23 Sep 2019 04:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Hu2Oi8S0mfQDNh2pDHvkY7ihz475PTTmFRl2WprhZ0M=; b=cXDS5kBuqlAVomBg4JB2IqqZtdCqP+TCPNG2odkeAN0LZTuSRzZ52TMaMFFIwJx6SX WeOD8NllNgPais35uN2m+KPMyLd7rnnG5yd60+RwEhICbCo9cQCYGebR3bNjIDs2QIC0 Bd9YiYrRvfPqtyvGLC4xjs68kpnsP1jJquxoJkECX6kRV++UYZCYTATi/LPllPjKthd1 ZlVnKu8CAvlRQGLOcIXhV6N4MC5fAKUCs6bCNOL2mWF8etB/is9HamRaLhQxRBVP/Xh3 pZwFX9/d/V8Lzsxi7oC5RKri6ckHqbmqbqbve9Q07VyWQEfyaXTOTg+lgJ5RFLu6f/La +8IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Hu2Oi8S0mfQDNh2pDHvkY7ihz475PTTmFRl2WprhZ0M=; b=W1Zr/NRWUFCN3SVW4L2yDoaW5UI5uTzl7cOk2FGtZPMRvJSrTu0DE96tk1eHBBNDIl vZ3UsXNqKL6Wpsv9MXKPIgli5faxZN/CXZKgsn3p3tagTDHWf1sA1f5LxQjAPuR+ooua 3LtrLUnMevz2d2b26EGBPaseEyOqnFz+4eZmSgnJ4w4gp0FwpDnmD89R8cYFbMeaHOKX /2mJfg03/m2qDoqsEoQrktqoa3QMQjSg9eicUCWuCuVuMm1HZHJRxyQ7xU+kpWqPSOKF S1nARldT4MdsZudRtQHV47A8jBwnAywBmIJj/ViaTYEYVlHEZkXEB0N6MHqR4V4TGLOV gJaA== X-Gm-Message-State: APjAAAXSZjiw0W5IQ6wgxzn7HbUCMXO9nq1jKvFABa86W8TaT85RNWaK q1R/f3c+AlQ0oCVoqBC2B9Y0Gg== X-Google-Smtp-Source: APXvYqyysJ2cMarVo3OcghKKaY2KeUQAFw1eDGgsz93NGRC/aDuJ3v8CkGPZI9WRLKKN98UeLP4JfQ== X-Received: by 2002:a0c:d0d0:: with SMTP id b16mr23316212qvh.191.1569239841706; Mon, 23 Sep 2019 04:57:21 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id v23sm5167575qto.89.2019.09.23.04.57.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Sep 2019 04:57:21 -0700 (PDT) From: Ted Lemon Message-Id: <8DB437F5-0D1E-4B3B-810F-37AF006139D8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1F84E86-2E52-4657-B1C8-5028FA4E5963" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.13\)) Date: Mon, 23 Sep 2019 07:57:19 -0400 In-Reply-To: Cc: Niels ten Oever , hrpc@irtf.org, Stephen Farrell To: Eliot Lear References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> X-Mailer: Apple Mail (2.3594.4.13) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 11:57:25 -0000 --Apple-Mail=_A1F84E86-2E52-4657-B1C8-5028FA4E5963 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 23, 2019, at 7:49 AM, Eliot Lear wrote: > [Ted, I saw your note after putting most of this together. Time has = been explored=E2=80=A6 ad infinitum :-), but see below for some = entertainment.] I think it=E2=80=99s not only entertaining but useful. I see obvious = parallels between what happened with standard time and time zones, and = what is happening now with Internet protocols. I think it=E2=80=99s a = useful analogy to explore when thinking about how to talk about politics = from the perspective of internet protocols, since it gives us a model = for how the history might unfold. --Apple-Mail=_A1F84E86-2E52-4657-B1C8-5028FA4E5963 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 23, 2019, at 7:49 AM, Eliot Lear <lear@cisco.com> wrote:
[Ted, I saw your note after putting = most of this together.  Time has been explored=E2=80=A6 ad = infinitum :-), but see below for some = entertainment.]

I = think it=E2=80=99s not only entertaining but useful.  I see obvious = parallels between what happened with standard time and time zones, and = what is happening now with Internet protocols.  I think it=E2=80=99s = a useful analogy to explore when thinking about how to talk about = politics from the perspective of internet protocols, since it gives us a = model for how the history might unfold.

= --Apple-Mail=_A1F84E86-2E52-4657-B1C8-5028FA4E5963-- From nobody Mon Sep 23 04:59:42 2019 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 719AC120091 for ; Mon, 23 Sep 2019 04:59:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=BkoYdg5r; dkim=pass (1024-bit key) header.d=yitter.info header.b=GxwoV57w 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 oGRRD0lZxvQg for ; Mon, 23 Sep 2019 04:59:38 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F02012008C for ; Mon, 23 Sep 2019 04:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 65A74BCBD1; Mon, 23 Sep 2019 11:59:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1569239977; bh=KjdK1Mt8GWiCgBbb/j2d5sGv8yumidPbFNh4FPGqG0Y=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=BkoYdg5rWOSjemMPRwxHYedYbRgaOoJdLT2vU346a07bW5CMOmPRPf7Mtv8jc4kKb MbDMrVQP7I5UKiqG9z8/tuQTmHCU2FBAS1mcJ6p24Nuni1ifGcga8i1/JZD0Vrj122 +6EMYz10YcK3g9db7UnANXiQ6yLJZaTLpmUb9MFU= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31tIant9hF9w; Mon, 23 Sep 2019 11:59:36 +0000 (UTC) From: Andrew Sullivan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1569239976; bh=KjdK1Mt8GWiCgBbb/j2d5sGv8yumidPbFNh4FPGqG0Y=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=GxwoV57wxhpusqPC5lTcp/3rNqocMGVVahqaHeMl1QBEWyixzf+RUNdfshoPm62uV e7aKx/1oOUIFcxTaKg42rMn4kEe/f86fmCHJC6FDul1GynKAAUMBOLbEEvyRyq0IUH xqQ2VqKAo3NQJPd8e+I6qLEjh6lKwwZq093PFbS8= To: Niels ten Oever , Stephen Farrell , Eric Rescorla CC: Date: Mon, 23 Sep 2019 07:59:29 -0400 Message-ID: <16d5dfdace8.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> In-Reply-To: References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 11:59:41 -0000 Niels, This post is a perfect example of one problem that I have been complaining about. If everything that is ever touched upon by any politics is thereby itself "political", then your point is true (though, I submit, trivially so). But you haven't actually shown that claim, and any time anyone objects to this point you simply trot out some authority to say, "But it is so true." But the argument is basically over whether those authors are right. So it's either begging the question or fallacious appeal to authority or both. Best regards, A -- Andrew Sullivan Please excuse my clumbsy thums. On September 23, 2019 05:44:33 Niels ten Oever wrote: > On 9/21/19 4:18 PM, Stephen Farrell wrote: >> >> Hiya, >> >> On 21/09/2019 15:13, Eric Rescorla wrote: >>> Again, let's take the example of SSL, which was designed by Netscape >>> for its own market purposes and became a de facto standard because >>> Netscape had the dominant browser and people wanted to interoperate >>> with it. What's poltical about that process? >> >> To be fair, there was a lot of IETF politics around >> Netscape and Microsoft related to that and IIRC TLS >> was only called that as part of an explicit compromise. >> >> I think Eliot's examples (and NTP, which I raised) >> are maybe better examples of less/apolitical standards >> and protocols than SSL/TLS. > > Time, and its standardization, is a very political project. Going back to > Aristotle (Physics iv 10-14) there is the difference between Chronos and > Kairos, where Chronos became the number to measure motion (kinesis). There > have been many other perceptions and measurements of time, that were able > to exist next to each other, but as part of the colonial project, the > European concept of what time was, was made the universal standard. That is > why Greenwich Mean Time (in Great Britain) is used as a standard for the > whole world. > > There are also many stories about the development of timezones, and their > consequences, the way in which time helped shape labor, life, and how it > altered complete societies. > > I am not making a value judgment about this re-odering, but I am trying to > show that NTP, which helps synchronize to a specific time regime, on which > a lot of computing depends, helps promulgate a specific, and political, > ordering. > > This book on the topic is quite interesting: > https://www.amazon.com/Colonisation-Time-Studies-Imperialism/dp/0719082714 > > Best, > > Niels > > > > > > -- > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > > > > > ---------- > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Mon Sep 23 05:20:09 2019 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 38ED01200B5 for ; Mon, 23 Sep 2019 05:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_HELO_NONE=0.001, 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 PBMJ4VGtr8cW for ; Mon, 23 Sep 2019 05:20:05 -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 8F51212003E for ; Mon, 23 Sep 2019 05:20:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4BB93BE53; Mon, 23 Sep 2019 13:20:03 +0100 (IST) 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 tVQsOyA8iB9z; Mon, 23 Sep 2019 13:20:03 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06D23BE24; Mon, 23 Sep 2019 13:20:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1569241203; bh=C42aw+cc6TUx0bkyoXyF5ZjtcElL9K990wLSh4e4uOg=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=pt2ShqHLTNQ1VDKVzmP9bJTD7IpUNsSk/f+TkCnW4lQQWc0AjLoyG0sPpmElqAGCc tTI/TpFjFiEkxzmUuFXPKZzvKrpjMt+gQocHe8eJlms+uCbLRN9tU0JB3AdanUFpXd VpmyPbCjSc+OOZNGsLc/pcMxMaBhaJqbP/JJ3jBI= To: Eliot Lear , Niels ten Oever Cc: hrpc@irtf.org References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Mon, 23 Sep 2019 13:20:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l7BNFhi0wAH99FNPDzCHiRmZkUUmLlj8I" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 12:20:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l7BNFhi0wAH99FNPDzCHiRmZkUUmLlj8I Content-Type: multipart/mixed; boundary="0DsyRvmZJuCvX3KgFv8aS1eEQRQ4Moi6h"; protected-headers="v1" From: Stephen Farrell To: Eliot Lear , Niels ten Oever Cc: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> In-Reply-To: --0DsyRvmZJuCvX3KgFv8aS1eEQRQ4Moi6h Content-Type: multipart/mixed; boundary="------------9DD64CECFBA51DD263B782DE" Content-Language: en-GB This is a multi-part message in MIME format. --------------9DD64CECFBA51DD263B782DE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, FWIW, my impression matches how Ted and Eliot describe NTP as relatively apolitical. On 23/09/2019 12:49, Eliot Lear wrote: > NTP requires only two protocol invariants: the length of a second > itself and a particular epoch. =20 Agreed. And afaik the recent handling of the TZ database also seems relatively free of politics. (Though I'm open to correction there as I don't follow the details.) I guess taking the Devil's (or Niels':-) advocate approach for a second maybe one could argue that NTP is such a well deployed protocol that some putative changes to NTP (or away from NTP) could by highly political, or that the use of certain servers could be political, but that seems to be a bit of a stretch to me, as a basis on which to claim that NTP itself, as a protocol, is political. So maybe NTP is an example of a protocol that was preceded by politics, (as Niels pointed out) and that could in future give rise to moar politics, but that is itself pretty much apolitical? If that's a good way to describe things, then it might be worth nothing that kind of example in the draft. > The one field that has any real > political aspect at this point is the leap second indicator. In order to help geek++ the thread: as it happens, I know someone who generates interesting work measuring those:-) [1] Cheers, S. [1] https://mural.maynoothuniversity.ie/10061/1/DM-Leap-2016.pdf --------------9DD64CECFBA51DD263B782DE Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------9DD64CECFBA51DD263B782DE-- --0DsyRvmZJuCvX3KgFv8aS1eEQRQ4Moi6h-- --l7BNFhi0wAH99FNPDzCHiRmZkUUmLlj8I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2IuHEACgkQWrL68XsX K+ouHRAAoJ54m+/2d5K2itrLNNECzhTo75ryejJVM0PNbgRbcQZZALZNgsPNMlQu fU2xeaRhq44M68u5JSyZ1OU8WPdhco164TG1OsPGJygXz3CptqinyakHcV7hF+l6 LtAEC1DZ4snmahH2qxqLZpn0g8pCLX2zxuZEP91oLcr7ReyxpgfHqlDzpenOvoSv 6moWUIhUayZV8yLv8Kncr6SbbFJvqexzPGuAj4dUQ+KnLSWb8y1kkJBFhO4+6zAP ANVmKlvc9fclZAbluqsu5A+8WkUy4K94W+DVIt7YPAj9KFXKOwas7JFSBuldqR3t rKUAh2ajZwdVJTtPaDG5GBzggvmevGK+3useorNGraHGoT5jm6AZyB/khR1uCM13 jutsSegr2c60/lQ3ni6MRpZC4YI/VVKht66VvB6giWBzCUrB/0dUX0I2HY9sEZ+p AYReEPmaWaFMtbQxvcGRX8iUuUP6edl0ELZ025rfm0Wtg74OQYUJ5vsCEuvDQ5ES 3+Q2nWnXlAv4F+ujNO3A/5Q1NpPuJnM5k352U1whp+In1KN1LlUHkOowxeFGYhdf M08h0qxH/FhoVaPoPOR8si7gH674nqe4Q8H97v4DIk29P09SAdGr4xJ3+A2nVIFr m91V4AtSwtnaHf9dgWAfuCsEWeEgLmZF1Qn2OzuF7n2RS5PyRUY= =PE1Y -----END PGP SIGNATURE----- --l7BNFhi0wAH99FNPDzCHiRmZkUUmLlj8I-- From nobody Mon Sep 23 05:28:14 2019 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 026591200B5 for ; Mon, 23 Sep 2019 05:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peIYj8QfN6un for ; Mon, 23 Sep 2019 05:28:10 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 C506B1200B3 for ; Mon, 23 Sep 2019 05:28:10 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iCNRJ-0007si-IE; Mon, 23 Sep 2019 14:28:07 +0200 Date: Mon, 23 Sep 2019 14:27:36 +0200 From: Niels ten Oever To: Andrew Sullivan Cc: Stephen Farrell , Eric Rescorla , hrpc@irtf.org Message-ID: <20190923122736.GE15078@mir> References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> <16d5dfdace8.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BQPnanjtCNWHyqYD" Content-Disposition: inline In-Reply-To: <16d5dfdace8.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Authenticated-As-Hash: 54a52893e10ae071b73780542c02a8d9e3f33e6f X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d03c6668c40393d71259a55b271b8ef3 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 12:28:13 -0000 --BQPnanjtCNWHyqYD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 23, 2019 at 07:59:29AM -0400, Andrew Sullivan wrote: > Niels, >=20 > This post is a perfect example of one problem that I have been > complaining about. If everything that is ever touched upon by any > politics is thereby itself "political", then your point is true > (though, I submit, trivially so). =20 The draft no longer makes the point that protocols are political. But that = their development and implementation can be. That probably makes that discu= ssion easier.=20 > But you haven't actually shown > that claim, and any time anyone objects to this point you simply > trot out some authority to say, "But it is so true." But the > argument is basically over whether those authors are right. So > it's either begging the question or fallacious appeal to authority > or both. >=20 I am not sure what kind of bar for 'showning my claim' you are setting here= =2E I just wrote that:=20 as part of the colonial project, the European concept of what time was, was= made the universal standard. That is why Greenwich Mean Time (in Great Bri= tain) is used as a standard for the whole world.=20 Do you want to contest this? Do you think this is not convincing? Or do I n= eed to establish what GMT is through a historical analysis? Should I furthe= r elaborate how NTP faciliates the prumulgation of this standard? I just tr= ied to give another example of how seemingly unpolitical protocols is part = of a political process of reodering the world, and thus setting a specific = norm.=20 The idea of this draft is to clear the way for such research to happen, wit= hout having to re-discuss the base premisse of such research. But now we se= em caught in a kind of catch 22.=20 Best, Niels > Best regards, >=20 > A > -- > Andrew Sullivan > Please excuse my clumbsy thums. >=20 > On September 23, 2019 05:44:33 Niels ten Oever w= rote: >=20 > > On 9/21/19 4:18 PM, Stephen Farrell wrote: > > >=20 > > > Hiya, > > >=20 > > > On 21/09/2019 15:13, Eric Rescorla wrote: > > > > Again, let's take the example of SSL, which was designed by Netscape > > > > for its own market purposes and became a de facto standard because > > > > Netscape had the dominant browser and people wanted to interoperate > > > > with it. What's poltical about that process? > > >=20 > > > To be fair, there was a lot of IETF politics around > > > Netscape and Microsoft related to that and IIRC TLS > > > was only called that as part of an explicit compromise. > > >=20 > > > I think Eliot's examples (and NTP, which I raised) > > > are maybe better examples of less/apolitical standards > > > and protocols than SSL/TLS. > >=20 > > Time, and its standardization, is a very political project. > > Going back to Aristotle (Physics iv 10-14) there is the > > difference between Chronos and Kairos, where Chronos became > > the number to measure motion (kinesis). There have been many > > other perceptions and measurements of time, that were able to > > exist next to each other, but as part of the colonial project, > > the European concept of what time was, was made the universal > > standard. That is why Greenwich Mean Time (in Great Britain) > > is used as a standard for the whole world. > >=20 > > There are also many stories about the development of > > timezones, and their consequences, the way in which time > > helped shape labor, life, and how it altered complete > > societies. > >=20 > > I am not making a value judgment about this re-odering, but I > > am trying to show that NTP, which helps synchronize to a > > specific time regime, on which a lot of computing depends, > > helps promulgate a specific, and political, ordering. > >=20 > > This book on the topic is quite interesting: > > https://www.amazon.com/Colonisation-Time-Studies-Imperialism/dp/0719082= 714 > >=20 > > Best, > >=20 > > Niels > >=20 > >=20 > >=20 > >=20 > >=20 > > -- > > Niels ten Oever > > Researcher and PhD Candidate > > DATACTIVE Research Group > > University of Amsterdam > >=20 > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > > 643A 0ED8 3F3A 468A C8B3 > >=20 > >=20 > >=20 > >=20 > > ---------- > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 >=20 --=20 Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 =20 643A 0ED8 3F3A 468A C8B3 --BQPnanjtCNWHyqYD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl2IujgACgkQDtg/OkaK yLOI1w//djDdwAN7zInsjlBXcQhzeZmvtWZiNwEBiNkEUcWNHlgxZfCNCBVpzD6i opnwqID8f1a6+0bNCiD53xye2PXUxxQ6WJREbF4IJxxHY1ViPlaTFB2/mbD3UVaj r+FNQIHY/sYDzpZl7qLi+cu1b4mzY7n7b5rEASSpar36VmTPqJIiOhhz//arEQPZ ezJnvy0CBaUm/6GVb27dkuVC1yGgEAzTQjgqfwwPE6DMVvFpSQRgwLVPEuh92Lfl hHp9wWDlZj40hCY2MXgsjX1fuBB/091B0LbIIqE/U8VHrpD7GOoimLnjG0qe+uQZ 0Mnuqpj4EI8qpVX+lJAx9AP5V74ZeGLlfLryT3w+oO1L79NHb1s1jAZiSFb3sdTp 0ICYfNLK/fg/upD4AhIi0iKEnDjYukByJcnlirnf+j958Ljs3GGD/D9G8YZ+lqhz KTHn73pMS+X+p286+pSTa+PRo99BcuUHtlGU0Dpy3p1Ddpuo652u14FuJ9pmffWT dvECFlQdmMZvHvMUefhwI9i/ylQmGyu9t6JNzP4dzGjwEW2afbZrv2Dzo4Uym2Ee s1W+s4SODkCzAPdaj0cb6+RnEL4t1HXU5cxRubaeZHjWEE0O/ayGSsMX7DqezORQ oobvbXi9E7g9vp7Sf1WILmCK5QF0ysqtN7SZhbah58kIxBFHReU= =yuYf -----END PGP SIGNATURE----- --BQPnanjtCNWHyqYD-- From nobody Mon Sep 23 05:32:02 2019 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 51FAA1200B3 for ; Mon, 23 Sep 2019 05:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiaWJIExdXz7 for ; Mon, 23 Sep 2019 05:31:58 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B09E1200B2 for ; Mon, 23 Sep 2019 05:31:58 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id c3so16818016qtv.10 for ; Mon, 23 Sep 2019 05:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vwGE+zbB2zAwVyOhdObkAmCcdz1Ai/9zpHwmfu8gIPk=; b=k8RVMyVDoACbBrGfK44dRe3uCTkMJD60/5WustsAVCsP9HTFdzt+z/uoonOKwPXzv7 uibOSSrzbUg4sIDek+TL1XXHLbOeC+XcFmOLtYu2BSkRB3wsSn9hhjPusiEAhssIREGL hCCL2ONVFpuAIqDWOFVy//jL0dD+xPgRobaYtSv/lXfkwRUfNwXCEMH3wekNGrBlVBVu OYuK8Pctzr9LiJJkbro6hClz6qvAdk6ebLX1gB3m38jLto9xk9jzivUPtGLnzlGLT6b6 jPcAt64UEBcRR8KSqCsZWhl3kf1KQTJAh++sqtJRN+qczc0H1QfcRWv4zkFNJ+SnW7iS 72Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vwGE+zbB2zAwVyOhdObkAmCcdz1Ai/9zpHwmfu8gIPk=; b=ZK21O0CQhq8kqfXdYvVYQ/8EqjNyQGzbV/chYSVtZRx6WAXjgXZhh3VTTdyUEu7Xfi BJXtoFlkTCTQBUC68CICk5sw9GL8+ArtD0ndrsYH6UKreIxAWlc2Bep/Nifmf5VfjI3Y v/fRG8HaJ/sUGn3cTqxhmZ9tQklXZA1aPwP4F9ON0nkuQAkf/HHlHfBx3rIg9ZmtfZlT VONkxgK0TD3XRUYtVwAogRGwmCINuYLxv6odFELLSGhNyiECaf0T94y9icawXuh3SPdw iSVVhG00nf7RkZ3IoSfKjNPS2l4QtmksO7GsBcMNbjoGssJZXsejhCbmN3J44O3YzFEu n/YQ== X-Gm-Message-State: APjAAAUAtkOSHz1r9C8wIwHxmDBjF2MZVp5iv0fjjZHIfUmxMcKEeu61 mXVQ6H5SMK3cBO2AcvVPx8MkoQ== X-Google-Smtp-Source: APXvYqyQny1x22RDX6gJ2Q8dBxq152sqX9ay0igrAqBALcLbT74BDeJ+HdungPcz8inoeEMy50eLUQ== X-Received: by 2002:a0c:d7cf:: with SMTP id g15mr24520081qvj.73.1569241917551; Mon, 23 Sep 2019 05:31:57 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id w18sm5428412qts.44.2019.09.23.05.31.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Sep 2019 05:31:56 -0700 (PDT) From: Ted Lemon Message-Id: <36E38C8C-D092-49A8-BEC7-01A1C03751C2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_529A708F-AF8B-484D-9B29-534712F6C5D9" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.13\)) Date: Mon, 23 Sep 2019 08:31:54 -0400 In-Reply-To: <20190923122736.GE15078@mir> Cc: Andrew Sullivan , Eric Rescorla , hrpc@irtf.org, Stephen Farrell To: Niels ten Oever References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> <16d5dfdace8.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <20190923122736.GE15078@mir> X-Mailer: Apple Mail (2.3594.4.13) Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 12:32:01 -0000 --Apple-Mail=_529A708F-AF8B-484D-9B29-534712F6C5D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 23, 2019, at 8:27 AM, Niels ten Oever = wrote: > The idea of this draft is to clear the way for such research to = happen, without having to re-discuss the base premisse of such research. = But now we seem caught in a kind of catch 22.=20 IOW, the purpose of this document is to establish a set of givens from = which subsequent reasoning can be done. But we don=E2=80=99t agree on = the givens. So it can=E2=80=99t possibly do that. It=E2=80=99s = possible that it can do something else that is useful, but it certainly = can=E2=80=99t do that particular thing. --Apple-Mail=_529A708F-AF8B-484D-9B29-534712F6C5D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 23, 2019, at 8:27 AM, Niels ten Oever <mail@nielstenoever.net> wrote:
The idea of this draft is to clear the way for such research = to happen, without having to re-discuss the base premisse of such = research. But now we seem caught in a kind of catch 22. 

IOW, the purpose of this document is = to establish a set of givens from which subsequent reasoning can be = done.  But we don=E2=80=99t agree on the givens.  So it = can=E2=80=99t possibly do that.  It=E2=80=99s possible that it can = do something else that is useful, but it certainly can=E2=80=99t do that = particular thing.

= --Apple-Mail=_529A708F-AF8B-484D-9B29-534712F6C5D9-- From nobody Mon Sep 23 05:40:34 2019 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 3D3BA1200B2 for ; Mon, 23 Sep 2019 05:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 QZYQ4-h3Ucbt for ; Mon, 23 Sep 2019 05:40:28 -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 43449120026 for ; Mon, 23 Sep 2019 05:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10109; q=dns/txt; s=iport; t=1569242428; x=1570452028; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=wa5NA6VXtxDfPrpaon3uZQ7yamqOByBa3IcO2PE0si0=; b=FtvTYxb1V3Q7Hqef3E5v+3P0t1E6s40CcJzGkTon7fSHDTNK2wDsruzN a5Q9+LV4QS5Lp59tqLsHdiYXU2ptMj29NielyK4jGfuUqxK1MXW5bIDjU ST4Gv1FhkmHRJNWhIcqH3NS65xQhjyOKKQr219hfLmDt6YIU0R94XO+XQ w=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACVvIhd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBZ4EcgW9TIBIqjR6HeiWHRItTiAYCBwEBAQkDAQEjDAE?= =?us-ascii?q?BhD8Cgzk4EwIDCQEBBAEBAQIBBQRthS0MhUoBAQEBAgF5BQsLGC5XBhODIgG?= =?us-ascii?q?Bew8Pq02CJYVMhGkKBoE0gVGKUIF/gTgME4IXNT6CYQIDhRuCJgSWApcKgiy?= =?us-ascii?q?CLoETg0SOBRuNf4smli2NcYMRAgQGBQIVgWkhgVgzGggbFWUBgkE+EhAUhUC?= =?us-ascii?q?FFIVBPgMwAQGOawEB?= X-IronPort-AV: E=Sophos;i="5.64,539,1559520000"; d="asc'?scan'208,217";a="17171677" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Sep 2019 12:40:26 +0000 Received: from [10.61.212.69] ([10.61.212.69]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x8NCeP4w018126 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Sep 2019 12:40:26 GMT From: Eliot Lear Message-Id: <6DD570B9-7102-4D93-89DC-CAFC10C41A0C@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7035A206-6698-4794-9483-E08458482A81"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 14:40:24 +0200 In-Reply-To: Cc: Niels ten Oever , hrpc@irtf.org To: Stephen Farrell References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.212.69, [10.61.212.69] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 12:40:33 -0000 --Apple-Mail=_7035A206-6698-4794-9483-E08458482A81 Content-Type: multipart/alternative; boundary="Apple-Mail=_5A66B6CC-A6ED-4FBD-8E2D-3C2D17626002" --Apple-Mail=_5A66B6CC-A6ED-4FBD-8E2D-3C2D17626002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Stephen, > On 23 Sep 2019, at 14:20, Stephen Farrell = wrote: >=20 > I guess taking the Devil's (or Niels':-) advocate approach > for a second maybe one could argue that NTP is such a well > deployed protocol that some putative changes to NTP (or > away from NTP) could by highly political, or that the use > of certain servers could be political, but that seems to > be a bit of a stretch to me, as a basis on which to claim > that NTP itself, as a protocol, is political. Indeed, but this is where I think we have to understand the intersection = of politics and economics. The WTO views those sorts of changes, when = they come from a national standards authority in the form of a normative = requirement as a trade barrier, and rightly so. But viewed from the = IETF perspective it would invole a tussle of entrenched players versus = those who seek some sort of disruptive advantage. In as much as the = latter are some socio-economic class, perhaps one could turn this into a = political discussion, but here I am mindful of the words of Milton and = Farzaneh, who caution us that it is difficult to predict political = impact a priori.[2] Eliot [1] https://en.wikipedia.org/wiki/Indiana_Pi_Bill [2] https://onlinelibrary.wiley.com/doi/full/10.1002/poi3.190 --Apple-Mail=_5A66B6CC-A6ED-4FBD-8E2D-3C2D17626002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Stephen,

On 23 Sep 2019, at 14:20, Stephen Farrell = <stephen.farrell@cs.tcd.ie> wrote:

I guess taking the Devil's (or = Niels':-) advocate approach
for a second maybe one could argue that NTP is such a = well
deployed = protocol that some putative changes to NTP (or
away from NTP) could by highly = political, or that the use
of certain servers could be political, but that seems = to
be a bit of a = stretch to me, as a basis on which to claim
that NTP itself, as a protocol, = is political.


Indeed, but this is where I think we have to = understand the intersection of politics and economics.  The WTO = views those sorts of changes, when they come from a national standards = authority in the form of a normative requirement as a trade barrier, and = rightly so.  But viewed from the IETF perspective it would invole =  a tussle of entrenched players versus those who seek some sort of = disruptive advantage.  In as much as the latter are some = socio-economic class, perhaps one could turn this into a political = discussion, but here I am mindful of the words of Milton and Farzaneh, = who caution us that it is difficult to predict political impact a = priori.[2]

Eliot
[1] https://en.wikipedia.org/wiki/Indiana_Pi_Bill
= --Apple-Mail=_5A66B6CC-A6ED-4FBD-8E2D-3C2D17626002-- --Apple-Mail=_7035A206-6698-4794-9483-E08458482A81 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2IvTgACgkQh7ZrRtnS ejNr6QgAzqIec9mzJdRb8P+Mqv1lIoJccIiWW0D9leaEOb8qSqc0IKWZ9yzueQ+W w4hscOaAmkOrv88DroQvYOI6S1lKJTf5ObgiXGEAImDgLg7GAj59lbxu9YGZA25t QnAtWpxNVUHA8gUClHvzX/pe3mILEd01Qkzw8qLwGoTeS9G8OBjfSiRKTXCeT4DJ C7E3FbMNWhYQKYlhkBOCy3OI6KbXi02PZPPNL+JjsEawX7skZRCb7Zs6gbQmfPmz 8kdUlXTX2VOtIw1MOA/CGjXHHqv0PYswZNiU5hGKR5yOP+JljqSLMfvBMZstCRvt 2sPgDggHrb21Gf6dI4srQ5mab2R6tA== =iwUc -----END PGP SIGNATURE----- --Apple-Mail=_7035A206-6698-4794-9483-E08458482A81-- From nobody Mon Sep 23 09:11:44 2019 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 D791B12018D for ; Mon, 23 Sep 2019 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb7Ju7RrGJph for ; Mon, 23 Sep 2019 09:11:39 -0700 (PDT) Received: from homere.koumbit.net (homere.koumbit.net [199.58.80.81]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE95120879 for ; Mon, 23 Sep 2019 09:11:39 -0700 (PDT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: steph@stephcouture.info) by homere.koumbit.net (Postfix) with ESMTPSA id 12EB31E47FE2 for ; Mon, 23 Sep 2019 12:11:37 -0400 (EDT) Received: by mail-wr1-f52.google.com with SMTP id i1so14639350wro.4 for ; Mon, 23 Sep 2019 09:11:37 -0700 (PDT) X-Gm-Message-State: APjAAAVoAJRgf0WYQtng1k0hVYtwpCL+5JQQaCiAm+Ps2zlxpRnH3X8T VJ8mVsCgDJzSY1BH7Jt5SLabYBs8J1gBM8/4P2A= X-Google-Smtp-Source: APXvYqxj2NBKN2ZzOzGP6It0qve2Imd1yuVjQEXL9KdjKVCm7dafPRInQctBRbIYjFYp0q2r1WwWqa6OrHCkd19RpFk= X-Received: by 2002:a5d:6a06:: with SMTP id m6mr175264wru.190.1569255096410; Mon, 23 Sep 2019 09:11:36 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> <16d5dfdace8.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> In-Reply-To: <16d5dfdace8.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> From: =?UTF-8?Q?St=C3=A9phane_Couture?= Date: Mon, 23 Sep 2019 12:11:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: Niels ten Oever , Stephen Farrell , Eric Rescorla , hrpc@irtf.org Content-Type: multipart/alternative; boundary="00000000000095727905933aac0f" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 16:11:43 -0000 --00000000000095727905933aac0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This is a very interesting discussion. I wanted to jump in following this last comment, to make a small contribution. Not sure if it is coherent with IETF discussions, but I hope this helps. First, I agree with Niels that there is a near consensus in certain academic fields (like STS and many works in philosophy of technology) that technological forms (standards, protocols, machines, tools) are political. Without making it as an argument of authority, I am wondering if it could be helpful to simply better describe the "location" of this consensus, instead of making sound like this is an absolute truth. This would avoid the delicate process of verifying the claims of every authors, while also informing the community that these scholarly work exists. Second, it might be worth having a section to explain what we mean by "political" and "how" the politics of technologies have been articulated in the literature. We have a section like this, but it's more like a "conclusion" than a framework. I like for instance this characterization by Darin Barney (following Andrew Feenberg) of the politics of technologies: -Technology as a *mean* of political activity : for instance, using a tool (or protocol) to suppress freedom of expression or enhance citizenship participation. -Technology as an *object* of political activity or deliberation: discussions and social process in the making of technologies : who is making the decision about protocols? Is it democratic and legitimate? Who is excluded in these spaces of decision about protocols/standards? Who should be included, and why? -As the *setting" of political activity : what are the constraints and possibilities of our particular technological culture ? How is the history of this technological culture affecting our choices today? Here you could, I think, include discussions like the previous one on the impact of historical standardization of time in our current technological choices (why taking Greenwich as the reference point, and not Tashkent or Nairobi?)= . St=C3=A9phane Barney, D. (2007). One Nation Under Google. *Hart Lecture*. http://darinbarneyresearch.mcgill.ca/Work/One_Nation_Under_Google.pdf Le lun. 23 sept. 2019 =C3=A0 07:59, Andrew Sullivan a =C3=A9crit : > Niels, > > This post is a perfect example of one problem that I have been complainin= g > about. If everything that is ever touched upon by any politics is thereb= y > itself "political", then your point is true (though, I submit, trivially > so). But you haven't actually shown that claim, and any time anyone > objects to this point you simply trot out some authority to say, "But it > is > so true." But the argument is basically over whether those authors are > right. So it's either begging the question or fallacious appeal to > authority or both. > > Best regards, > > A > -- > Andrew Sullivan > Please excuse my clumbsy thums. > > On September 23, 2019 05:44:33 Niels ten Oever > wrote: > > > On 9/21/19 4:18 PM, Stephen Farrell wrote: > >> > >> Hiya, > >> > >> On 21/09/2019 15:13, Eric Rescorla wrote: > >>> Again, let's take the example of SSL, which was designed by Netscape > >>> for its own market purposes and became a de facto standard because > >>> Netscape had the dominant browser and people wanted to interoperate > >>> with it. What's poltical about that process? > >> > >> To be fair, there was a lot of IETF politics around > >> Netscape and Microsoft related to that and IIRC TLS > >> was only called that as part of an explicit compromise. > >> > >> I think Eliot's examples (and NTP, which I raised) > >> are maybe better examples of less/apolitical standards > >> and protocols than SSL/TLS. > > > > Time, and its standardization, is a very political project. Going back > to > > Aristotle (Physics iv 10-14) there is the difference between Chronos an= d > > Kairos, where Chronos became the number to measure motion (kinesis). > There > > have been many other perceptions and measurements of time, that were > able > > to exist next to each other, but as part of the colonial project, the > > European concept of what time was, was made the universal standard. Tha= t > is > > why Greenwich Mean Time (in Great Britain) is used as a standard for th= e > > whole world. > > > > There are also many stories about the development of timezones, and > their > > consequences, the way in which time helped shape labor, life, and how i= t > > altered complete societies. > > > > I am not making a value judgment about this re-odering, but I am trying > to > > show that NTP, which helps synchronize to a specific time regime, on > which > > a lot of computing depends, helps promulgate a specific, and political, > > ordering. > > > > This book on the topic is quite interesting: > > > https://www.amazon.com/Colonisation-Time-Studies-Imperialism/dp/071908271= 4 > > > > Best, > > > > Niels > > > > > > > > > > > > -- > > Niels ten Oever > > Researcher and PhD Candidate > > DATACTIVE Research Group > > University of Amsterdam > > > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > > 643A 0ED8 3F3A 468A C8B3 > > > > > > > > > > ---------- > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --00000000000095727905933aac0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=20 This is a very interesting discussion. I wanted to jump in following this l= ast comment, to make a small contribution.=C2=A0Not sure if it is coherent = with IETF discussions, but I hope this helps.


First, I agree with Niels that= there is a near consensus in certain academic fields (like STS and many wo= rks in philosophy of technology) that technological forms (standards, proto= cols, machines, tools) are political. Without making it as an argument of a= uthority, I am wondering if it could be helpful to simply better describe t= he "location" of this consensus, instead of making sound like thi= s is an absolute truth. This would avoid the delicate process of verifying = the claims of every authors, while also informing the community that these = scholarly work exists.


Second, it might be worth havi= ng a section to explain what we mean by "political" and "how= " the politics of technologies have been articulated in the literature= . We have a section like this, but it's more like a "conclusion&qu= ot; than a framework. I like for instance this characterization by Darin Ba= rney (following Andrew Feenberg) of the politics of technologies:


-Technology as a *mean* of= political activity : for instance, using a tool (or protocol) to suppress = freedom of expression or enhance citizenship participation.=C2=A0


-Technology as an *object* of = political activity or deliberation: discussions and social process in the m= aking of technologies : who is making the decision about protocols? Is it d= emocratic and legitimate? Who is excluded in these spaces of decision about= protocols/standards? Who should be included, and why?


-As the *setting" of = political activity : what are the constraints and possibilities of our part= icular technological culture ? How is the history of this technological cul= ture affecting our choices today? Here you could, I think, include discussi= ons like the previous one on the impact of historical standardization of ti= me in our current technological choices (why taking Greenwich as the refere= nce point, and not Tashkent or Nairobi?).


St=C3=A9phane


Barney, D. (2007). One Nation Under Google. Hart Lecture.= =C2=A0=C2=A0http://darinbarneyresearch.mcgill.ca/Work/One_Nation_Und= er_Google.pdf



Le=C2=A0lun. 23 sept. 2019 =C3=A0=C2=A007:5= 9, Andrew Sullivan <ajs@anvilwalrusden.com> a =C3=A9crit=C2=A0:
Niels,

This post is a perfect example of one problem that I have been complaining =
about.=C2=A0 If everything that is ever touched upon by any politics is the= reby
itself "political", then your point is true (though, I submit, tr= ivially
so).=C2=A0 But you haven't actually shown that claim, and any time anyo= ne
objects to this point you simply trot out some authority to say, "But = it is
so true." But the argument is basically over whether those authors are=
right. So it's either begging the question or fallacious appeal to
authority or both.

Best regards,

A
--
Andrew Sullivan
Please excuse my clumbsy thums.

On September 23, 2019 05:44:33 Niels ten Oever <mail@nielstenoever.net> wrote:
> On 9/21/19 4:18 PM, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> On 21/09/2019 15:13, Eric Rescorla wrote:
>>> Again, let's take the example of SSL, which was designed b= y Netscape
>>> for its own market purposes and became a de facto standard bec= ause
>>> Netscape had the dominant browser and people wanted to interop= erate
>>> with it. What's poltical about that process?
>>
>> To be fair, there was a lot of IETF politics around
>> Netscape and Microsoft related to that and IIRC TLS
>> was only called that as part of an explicit compromise.
>>
>> I think Eliot's examples (and NTP, which I raised)
>> are maybe better examples of less/apolitical standards
>> and protocols than SSL/TLS.
>
> Time, and its standardization, is a very political project. Going back= to
> Aristotle (Physics iv 10-14) there is the difference between Chronos a= nd
> Kairos, where Chronos became the number to measure motion (kinesis). T= here
> have been many other perceptions and measurements of time, that were a= ble
> to exist next to each other, but as part of the colonial project, the =
> European concept of what time was, was made the universal standard. Th= at is
> why Greenwich Mean Time (in Great Britain) is used as a standard for t= he
> whole world.
>
> There are also many stories about the development of timezones, and th= eir
> consequences, the way in which time helped shape labor, life, and how = it
> altered complete societies.
>
> I am not making a value judgment about this re-odering, but I am tryin= g to
> show that NTP, which helps synchronize to a specific time regime, on w= hich
> a lot of computing depends, helps promulgate a specific, and political= ,
> ordering.
>
> This book on the topic is quite interesting:
> https://www.amazon.co= m/Colonisation-Time-Studies-Imperialism/dp/0719082714
>
> Best,
>
> Niels
>
>
>
>
>
> --
> Niels ten Oever
> Researcher and PhD Candidate
> DATACTIVE Research Group
> University of Amsterdam
>
> PGP fingerprint=C2=A0 =C2=A02458 0B70 5C4A FD8A 9488
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A064= 3A 0ED8 3F3A 468A C8B3
>
>
>
>
> ----------
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc



_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--00000000000095727905933aac0f-- From nobody Mon Sep 23 09:47:30 2019 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 34D141200CC for ; Mon, 23 Sep 2019 09:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG-spA3abFUy for ; Mon, 23 Sep 2019 09:47:25 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F8D1208E3 for ; Mon, 23 Sep 2019 09:47:22 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id m7so14421017lji.2 for ; Mon, 23 Sep 2019 09:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j0Gmyipas0MJdFhBChf9hrdQwqirUTEgjv4rm99nTCA=; b=GBmQdCfcfwU4vqhdwnEuwA2zvvxjQhvkXCN6q0S8vuMdg7ADjODgeA7LInmcHvMlxG f4HUktw1B/uThxGG0mbhjWYzr2xWbUY7VaQsbkPC+EIG76ajBm1zklO3JcP7cQuSIlSW AKa4ZVRLe+3kdOXJ9g89FBfEb4k4ZPlmCJ4dm+B5NozXXLcfIVvPbeWRf0BJqYzm0rT7 tt6bVv0eAHMseKz8y70aEftJt4DcEgtWRUktNKAPIF8Ggr6Fyv8upJEY8iOd/6gGeust O01E46KN4lzp/k00K+yhYxl2PIkcByBrZITiu3CrKRVETRkU8vllIsICJH7aZKC9qmlW cp9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j0Gmyipas0MJdFhBChf9hrdQwqirUTEgjv4rm99nTCA=; b=jVQoPaRFYHvGMJNQwOnTioXWkO05r8h9UJjE9y08OWgjfrev6TuRwYQiSIGikBwbbh p9Q6ppniItneb0WVLij3pk5uVxkhu6ObhRYbSbBC6RdX6xER0NnKtcuDZ+W6ETmMghJc U4RteR0IBclK2Qjdt5CGfSPIQ2DoTJ0aVNgmHfsrf3w/8zxaD6EztLvYZggZLHoAVTpW ZiQZWJefwN/lCS6PWNG5whx06Wkw+HBitx0htNvgXCtUIrWM3omBKzUOReX0fZ8HNR5A Z8dLCebQPgMoX6BLCOc9ERRtWVVtHoXmRixOW6a0I0LWIpwpLPibiKISv0FPL5D/HE+N zXEw== X-Gm-Message-State: APjAAAW+dMJKJ9/BCGGxt1BgxgsOShbj2cmksMnbTMgjn4wMlalMdKEi LtsOc7CQrZXBIMxzeiRFHIV4wDt+Bx0CLlBm4le7yw== X-Google-Smtp-Source: APXvYqxNE+xgVim+IkjwpDopEMmBLvNrMppUl5DwUz0acaQ4D9no5Y27o+m8Xr4xtuKuhCE5eWjVEIQfkFIYUC9dCWM= X-Received: by 2002:a2e:8ec1:: with SMTP id e1mr231231ljl.14.1569257240633; Mon, 23 Sep 2019 09:47:20 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <793367e8-7151-354e-04ca-b472760c6af7@nielstenoever.net> In-Reply-To: <793367e8-7151-354e-04ca-b472760c6af7@nielstenoever.net> From: Eric Rescorla Date: Mon, 23 Sep 2019 09:46:43 -0700 Message-ID: To: Niels ten Oever Cc: hrpc@irtf.org Content-Type: multipart/alternative; boundary="00000000000063bec505933b2c76" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 16:47:28 -0000 --00000000000063bec505933b2c76 Content-Type: text/plain; charset="UTF-8" Hi Niels, I think we're sort of talking past each other, so I'm going to focus on one point, namely the purpose of this document. Based on this discussion, you seem to be arguing that the purpose is to *demonstrate* the political nature of protocols and standards: > >> > I certainly agree that they "can be used" > >> > for political means, though any "can" statement is pretty weak. > >> > > >> > >> If we can document *that*, we would have made a lot of progress in > >> the IETF imho. > > > > I don't know anyone disagrees with that. > > Great. But I meet them at every IETF meeting, and it is brought up > very regularly in discussion. However, the draft just asserts that there is agreement on this: development process and its outputs, it is generally agreed that standards and protocols are both products of a political process, and they can also be used for political means. Therefore protocols and So, which is it, generally agreed or regularly contested? In any case, if the point is to demonstrate that protocols can be derived from politically derived processes and that they can be used politically, then IMO you are going about it entirely the wrong way, which is by using a very expansive (and not really that familiar to the people here) definition political and then making a strong claim which forces you to defend cases that people think are questionable (e.g., NTP or SSLv2). To the extent to which there is debate about the claims that protocols *can* be politically derived and *can* be deployed in political ways, the way to go about demonstrating that is to focus on the easy cases that are clearly political (I've named a number in this discussion). That doesn't require going and mining the literature you are citing here, but rather requires engaging with the history and use of these protocols. -Ekr On Mon, Sep 23, 2019 at 2:32 AM Niels ten Oever wrote: > > > On 9/21/19 4:13 PM, Eric Rescorla wrote: > >> Niels ten Oever via ietf.org > >> > >> 6:10 AM (48 minutes ago) > >> > >> to hrpc > >> > >> > >> On 9/21/19 3:32 AM, Eric Rescorla wrote: > >> > Whereas there might not be agreement among the Internet protocol > >> > community on the specific political nature of the technological > >> > development process and its outputs, it is generally agreed that > >> > standards and protocols are both products of a political process, > and > >> > they can also be used for political means. > >> > > >> > I would like to register my agrement with Andrew and focus in on this > >> > one point: there are many protocols (in fact, by count probably most > >> > protocols) which are just designed by proprietary organizations. It's > >> > not clear on what basis you are claiming that they are the output of > >> > political processes and this certainly doesn't seem like something > >> > that's generally agreed. > >> > >> Aren't proprietary standards, and the way they make it possible and > >> impossible to do certain things, a prime example of a political > >> process and political impact? > > > > Well, I don't think without stretching the term "political" outside > > of the point where saying something is political is trivial, no, > > I don't think so. > > > > Again, let's take the example of SSL, which was designed by Netscape > > for its own market purposes and became a de facto standard because > > Netscape had the dominant browser and people wanted to interoperate > > with it. What's poltical about that process? > > > > > > There are several political aspects about this, we had for instance text > in a previous version that read about dominance and de facto standards: > > Within economy studies, _de facto_ standards arise in market > situations where one entity is particularly dominant; downstream > competitors are therefore tied to the dominant entity's technological > solutions [Ahlborn]. Under EU anti-trust law, _de facto_ standards > have been found to restrict competition for downstream services in PC > software products [CJEU2007], as well as downstream services > dependent on health information [CJEU2004]. > > Another interesting aspect that SSL introduced were of course certificate > authorities, that served as trust anchors, which is ultimately defining > trusted authorities. > > SSLv2 was introduced as open standard (while v1 was not), which of course > was also quite a change, I reckon I don't need to elaborate on the politics > of licensing in this audience. > > > > >> > I certainly agree that they "can be used" > >> > for political means, though any "can" statement is pretty weak. > >> > > >> > >> If we can document *that*, we would have made a lot of progress in > >> the IETF imho. > > > > I don't know anyone disagrees with that. > > Great. But I meet them at every IETF meeting, and it is brought up very > regularly in discussion. > > > But in any case, demonstrating > > that doesn't require hauling in the theoretical apparatus you > > are trying to deploy here, but rather requires *history*. I.e., > > demonstrate that the process of developing some set of standards > > involved the political process of balancing the objectives of > > the various stakeholders, finding compromise, etc. Given that > > every IETF standards development process I have ever been involved in > > has had some of this, that doesn't seem hard. As a non-IETF example > > "The Box", a history of the shipping container, has a nice description > > of the standardization of that technology. > > > > >> > This is even true at some level for many standards, especially > >> > because your definition of "standard" is so expansive: > >> > > >> > Standards 'A standard is an agreed-upon way of doing something or > >> > measuring something.' [Sisson] > >> > > >> > By this definition I think it would be pretty hard to argue that > >> > SSLv2, and SSLv3 weren't standards given their wide use, even > >> > though they were just designed by people at one company. > >> > >> I don't see how that definition would make that impossible. > > > > I'm not sure I understand your response here. Are you saying that > > protocols defined by one company and that then achieve wide use > > are standards, or they are not? > > > > SSLv2 and SSLv3 were standards because people agreed that they were the > standard? For something to be a standard it does not need to be a formal > process to accept them as such. > > >> > Another > >> > example would be the Philips screwdriver head. What's the political > >> > process that produced these? > >> > > >> > > >> > >> The patenting of process by Henry F. Philips, the regimes under > >> which is was patented, its competition with other screw heads (torx, > >> etc). There is an enormous amount of politics, and societal ordering > >> connected with screws. > > > > Again, this just seems to serve to make the definition of "political" > > meaningless. By this definition, what human commercial activity > > would *not* be political, as it all occurs against a political > > backdrop. > > > > A transaction can be political, but of course does not need to be. > (Trans)action, such as standards, that change the market, are political > activities. > > > > > >> > More generally, it seems like depending on how one interprets the > >> > major claims in this document, they are either too strong (all > >> > protocol and standards development is political) > >> > >> Why is that too strong? > > > > For the reasons I indicated above: I don't think the development > > of many protocols, especially the small ones which get use internally > > as in, for instance, mobile apps, is generally political, And sometimes > > becoome standards and that's not necessarily political either. > > > > > >> > or trivial (some > >> > protocol and standards development is political). The first is too > >> > strong for the reasons I indicate above, > >> > >> I don't think so, but I am happy to discuss. > >> > >> and the second seems pretty > >> > obvious and doesn't really need much theorizing; > >> > >> As said, I think it would be very useful if we would document this, > >> so we don't need to repeat the discussion. > > > > Well, I'm not sure it matters if we repeat this discussion or > > even come to a conclusion on it. What's at stake in the answer? > > > > But, again, if you want to demonstrate that standards development > > can be political -- which, as I said, is a rather weak claim -- > > then I would discard this document and instead focus on documenting > > the history of the development of some protocols that was clealr > > political. > > > > > > As you know, what this draft meant to do, is to document a discussion so > it doesn't need to be repeated in the study of every different protocol. > > We could paste in a lot of examples here, for instance some of the review > of the human rights review team. But the discussion in 4.5 might be enough? > > >> > >> > one needs just point > >> > to the development of some protocol which was a political process, and > >> > it seems like that's been pretty amply documented for a number of > >> > protocols/standards (e.g., HTTP/2 or TLS 1.0). > >> > > >> > As I noted above, the claim that protocols can be used for political > >> > means also seems relatively obvious (cf. Tor). > >> > >> I am happy to conclude that we agree on the two statements: > >> > >> - some protocol and standards development is political > >> > >> and > >> > >> - protocols can be used for political means > > > > Well, I don't think this document demonstrates that, it's just > > conclusory. To the extent to which we think these statements are > > actually in debate and need demonstrating, then I would, as I said, > > focus on demonstrating them with reference to actual standards > > rather than by referring to other people's views about these > > statements. I would think 3-5 of each of these should be sufficient > > (though of course logically one alone is sufficient to prove > > existence, but several is more convincing) > > > > Again, the document seeks to document existing positions in the community > and provide background in existing literature on the topic, that could then > be a platform for further work. > > For instance on specific drafts, and or specific tendencies (based on case > studies, quantitative models, etc). > > Best, > > Niels > > > > > > > > >> That's progress for me in this discussion. Now let's see if we can > >> further flesh out: > >> > >> - all protocol and standards development is political > > > > I think what would help at this point that would be for you to > > describe some commercial activities that you think are *not* > > political. > > > > -Ekr > > > > > > -- > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > --00000000000063bec505933b2c76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Niels,

I think we're sort of talking past ea= ch other, so I'm going
to focus on one point, namely the purpose of = this document.

Based on this discussion, you seem to be arguing that= the
purpose is to *demonstrate* the political nature of protocols
an= d standards:

> >> > I certainly agree that they "ca= n be used"
> >> > for political means, though any "= ;can" statement is pretty weak.
> >> >
> >>=
> >> If we can document *that*, we would have made a lot of pr= ogress in
> >> the IETF imho.
> >
> > I don&= #39;t know anyone disagrees with that.
>
> Great. But I meet = them at every IETF meeting, and it is brought up
> very regularly in = discussion.


However, the draft just asserts that there is agreem= ent on this:

=C2=A0 =C2=A0development process and its outputs, it is= generally agreed that
=C2=A0 =C2=A0standards and protocols are both pro= ducts of a political process, and
=C2=A0 =C2=A0they can also be used for= political means.=C2=A0 Therefore protocols and

So, which is it, gen= erally agreed or regularly contested?


In any case, if the point = is to demonstrate that protocols
can be derived from politically derived= processes and that
they can be used politically, then IMO you are going= about
it entirely the wrong way, which is by using a very expansive
= (and not really that familiar to the people here) definition
political a= nd then making a strong claim which forces you
to defend cases that peop= le think are questionable (e.g.,
NTP or SSLv2).

To the extent to = which there is debate about the claims
that protocols *can* be political= ly derived and *can* be
deployed in political ways, the way to go about = demonstrating
that is to focus on the easy cases that are clearly politi= cal
(I've named a number in this discussion). That doesn't requi= re
going and mining the literature you are citing here, but rather
re= quires engaging with the history and use of these protocols.

-Ekr

On Mon, Sep 23, 2019 at 2:32 AM Niels ten Oever <mail@nielstenoever.net> wrote:


On 9/21/19 4:13 PM, Eric Rescorla wrote:
>> Niels ten Oever via ietf.org <http://ietf.org>
>>
>> 6:10 AM (48 minutes ago)
>>
>> to hrpc
>>
>>
>> On 9/21/19 3:32 AM, Eric Rescorla wrote:
>> > =C2=A0 =C2=A0Whereas there might not be agreement among the I= nternet protocol
>> > =C2=A0 =C2=A0community on the specific political nature of th= e technological
>> > =C2=A0 =C2=A0development process and its outputs, it is gener= ally agreed that
>> > =C2=A0 =C2=A0standards and protocols are both products of a p= olitical process, and
>> > =C2=A0 =C2=A0they can also be used for political means.
>> > =C2=A0 =C2=A0
>> > I would like to register my agrement with Andrew and focus in= on this
>> > one point: there are many protocols (in fact, by count probab= ly most
>> > protocols) which are just designed by proprietary organizatio= ns.=C2=A0 It's
>> > not clear on what basis you are claiming that they are the ou= tput of
>> > political processes and this certainly doesn't seem like = something
>> > that's generally agreed.
>>
>> Aren't proprietary standards, and the way they make it possibl= e and
>> impossible to do certain things, a prime example of a political >> process and political impact?
>
> Well, I don't think without stretching the term "political&qu= ot; outside
> of the point where saying something is political is trivial, no,
> I don't think so.
>
> Again, let's take the example of SSL, which was designed by Netsca= pe
> for its own market purposes and became a de facto standard because
> Netscape had the dominant browser and people wanted to interoperate > with it. What's poltical about that process?
>
>

There are several political aspects about this, we had for instance text in= a previous version that read about dominance and de facto standards:

=C2=A0 =C2=A0Within economy studies, _de facto_ standards arise in market =C2=A0 =C2=A0situations where one entity is particularly dominant; downstre= am
=C2=A0 =C2=A0competitors are therefore tied to the dominant entity's te= chnological
=C2=A0 =C2=A0solutions [Ahlborn].=C2=A0 Under EU anti-trust law, _de facto_= standards
=C2=A0 =C2=A0have been found to restrict competition for downstream service= s in PC
=C2=A0 =C2=A0software products [CJEU2007], as well as downstream services =C2=A0 =C2=A0dependent on health information [CJEU2004].

Another interesting aspect that SSL introduced were of course certificate a= uthorities, that served as trust anchors, which is ultimately defining trus= ted authorities.

SSLv2 was introduced as open standard (while v1 was not), which of course w= as also quite a change, I reckon I don't need to elaborate on the polit= ics of licensing in this audience.

>
>> > I certainly agree that they "can be used"
>> > for political means, though any "can" statement is = pretty weak.
>> >
>>
>> If we can document *that*, we would have made a lot of progress in=
>> the IETF imho.
>
> I don't know anyone disagrees with that.

Great. But I meet them at every IETF meeting, and it is brought up very reg= ularly in discussion.

> But in any case, demonstrating
> that doesn't require hauling in the theoretical apparatus you
> are trying to deploy here, but rather requires *history*. I.e.,
> demonstrate that the process of developing some set of standards
> involved the political process of balancing the objectives of
> the various stakeholders, finding compromise, etc. Given that
> every IETF standards development process I have ever been involved in<= br> > has had some of this, that doesn't seem hard. As a non-IETF exampl= e
> "The Box", a history of the shipping container, has a nice d= escription
> of the standardization of that technology.
> >
>> > This is even true at some level for many standards, especiall= y
>> > because your definition of "standard" is so expansi= ve:
>> >
>> > =C2=A0 =C2=A0Standards =C2=A0'A standard is an agreed-upo= n way of doing something or
>> > =C2=A0 =C2=A0 =C2=A0 measuring something.' =C2=A0[Sisson]=
>> >
>> > By this definition I think it would be pretty hard to argue t= hat
>> > SSLv2, =C2=A0and SSLv3 weren't standards given their wide= use, even
>> > though they were just designed by people at one company.
>>
>> I don't see how that definition would make that impossible. >
> I'm not sure I understand your response here. Are you saying that<= br> > protocols defined by one company and that then achieve wide use
> are standards, or they are not?
>

SSLv2 and SSLv3 were standards because people agreed that they were the sta= ndard? For something to be a standard it does not need to be a formal proce= ss to accept them as such.

>> > Another
>> > example would be the Philips screwdriver head. What's the= political
>> > process that produced these?
>> >
>> >
>>
>> The patenting of process by Henry F. Philips, the regimes under >> which is was patented, its competition with other screw heads (tor= x,
>> etc). There is an enormous amount of politics, and societal orderi= ng
>> connected with screws.
>
> Again, this just seems to serve to make the definition of "politi= cal"
> meaningless. By this definition, what human commercial activity
> would *not* be political, as it all occurs against a political
> backdrop.
>

A transaction can be political, but of course does not need to be. (Trans)a= ction, such as standards, that change the market, are political activities.=


>
>> > More generally, it seems like depending on how one interprets= the
>> > major claims in this document, they are either too strong (al= l
>> > protocol and standards development is political)
>>
>> Why is that too strong?
>
> For the reasons I indicated above: I don't think the development > of many protocols, especially the small ones which get use internally<= br> > as in, for instance, mobile apps, is generally political, And sometime= s
> becoome standards and that's not necessarily political either.
>
>
>> > or trivial (some
>> > protocol and standards development is political). The first i= s too
>> > strong for the reasons I indicate above,
>>
>> I don't think so, but I am happy to discuss.
>>
>> and the second seems pretty
>> > obvious and doesn't really need much theorizing;
>>
>> As said, I think it would be very useful if we would document this= ,
>> so we don't need to repeat the discussion.
>
> Well, I'm not sure it matters if we repeat this discussion or
> even come to a conclusion on it. What's at stake in the answer? >
> But, again, if you want to demonstrate that standards development
> can be political -- which, as I said, is a rather weak claim --
> then I would discard this document and instead focus on documenting > the history of the development of some protocols that was clealr
> political.
>
>

As you know, what this draft meant to do, is to document a discussion so it= doesn't need to be repeated in the study of every different protocol.<= br>
We could paste in a lot of examples here, for instance some of the review o= f the human rights review team. But the discussion in 4.5 might be enough?<= br>
>>
>> > one needs just point
>> > to the development of some protocol which was a political pro= cess, and
>> > it seems like that's been pretty amply documented for a n= umber of
>> > protocols/standards (e.g., HTTP/2 or TLS 1.0).
>> >
>> > As I noted above, the claim that protocols can be used for po= litical
>> > means also seems relatively obvious (cf. Tor).
>>
>> I am happy to conclude that we agree on the two statements:
>>
>> - some protocol and standards development is political
>>
>> and
>>
>> - protocols can be used for political means
>
> Well, I don't think this document demonstrates that, it's just=
> conclusory.=C2=A0 To the extent to which we think these statements are=
> actually in debate and need demonstrating, then I would, as I said, > focus on demonstrating them with reference to actual standards
> rather than by referring to other people's views about these
> statements. I would think 3-5 of each of these should be sufficient > (though of course logically one alone is sufficient to prove
> existence, but several is more convincing)
>

Again, the document seeks to document existing positions in the community a= nd provide background in existing literature on the topic, that could then = be a platform for further work.

For instance on specific drafts, and or specific tendencies (based on case = studies, quantitative models, etc).

Best,

Niels





> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>> That's progress for me in this discussion. Now let's see i= f we can
>> further flesh out:
>>
>> - all protocol and standards development is political
>
> I think what would help at this point that would be for you to
> describe some commercial activities that you think are *not*
> political.
>
> -Ekr
>
>

--
Niels ten Oever
Researcher and PhD Candidate
DATACTIVE Research Group
University of Amsterdam

PGP fingerprint=C2=A0 =C2=A0 2458 0B70 5C4A FD8A 9488=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0643A 0= ED8 3F3A 468A C8B3
--00000000000063bec505933b2c76-- From nobody Mon Sep 23 11:47:55 2019 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 0FBFC12082B for ; Mon, 23 Sep 2019 11:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llCeS5adNMsI for ; Mon, 23 Sep 2019 11:47:47 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5DC1201C6 for ; Mon, 23 Sep 2019 11:47:46 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id d2so18446349qtr.4 for ; Mon, 23 Sep 2019 11:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d4+Chc0LE5e6nRyFjra+esWbHYuF9lyUDgEBwVk0by8=; b=COuyIF0z8x+QeIcEivdDy7PXQsT7Ll9Cqn3HhsPcyrQ92Dnzk2nBLJV5e94vJ8Yb74 NHmfs7EoXFeF/X9Q5BjtqunQApfBZCEsp2lMPquKYnTS2W2hRZbPXXw+OGigy1v2YbSo eJUv4iwym0qJ0twMDbVI1Umelvh0IH7lVpDCsfh50Jry2O1aePA/OZvzpPUv4KJ7MjFh q2welWbjUuK42fcGP8R/co+ATbmwjrOIrSQ1uFcuuUZIifd13N/WGXoYK4dqS/rQfQmm 8hf6jSamijSmcHJOzUl+uftl9v4vK/dPtq3zDymrp43IIlaxcxcdCypJl0BjEQurREKH iH/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d4+Chc0LE5e6nRyFjra+esWbHYuF9lyUDgEBwVk0by8=; b=ngyeRrw2i7WQIVIfVNCUICfA6k0InIJ0s64f6QKEtGLTsY6ahBX5ce5n+UEuPUXRTX Ms4V+O0dVwPT+lK8AtsI4J/KfTBc3ESAmp7pXxEKck9HY5S03WXLGtM230HZvO9OJwBJ Wx7VueEKDer/2bGG9cdxh4jN8AnpT6ybV5pqplRewqFwe5Mi9EdRVJSIXqqWAHQwm1PW UjZL0xAX7lGk4ew5Ioh355avzRWHe4U3zVgitiRpP9fQqN6zxSUcvx+Y2z8UVP0IPIvX HGgmChkBIRiz3Qnd0Zt+6QkS0/xaCjFOxFBATR/1PnA+cdMNKx3/+A0wqEOGviLfZl1m hoQA== X-Gm-Message-State: APjAAAWrDDcE7nZWarZ4y6ofnWEEobPQUVCU+RuFNnBP+jAxaiH9D9Zx 2FmGpy/LSy3NCu7M3rNY7oIdVluC6GeSzD+O2g0= X-Google-Smtp-Source: APXvYqxLS2zYJORgYl/F+8+l89ze06RagGzfcmCnZm81rlRaKPhGN6r1Aq7Wtrq4WIk9S1p5pgTqXzclQQf0xiWPl34= X-Received: by 2002:a05:6214:1549:: with SMTP id t9mr686601qvw.68.1569264465664; Mon, 23 Sep 2019 11:47:45 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <793367e8-7151-354e-04ca-b472760c6af7@nielstenoever.net> In-Reply-To: From: Corinne Cath Date: Mon, 23 Sep 2019 21:47:09 +0300 Message-ID: To: Eric Rescorla Cc: Niels ten Oever , Hrpc Content-Type: multipart/alternative; boundary="00000000000008df5d05933cdbe9" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 18:47:53 -0000 --00000000000008df5d05933cdbe9 Content-Type: text/plain; charset="UTF-8" Hi, I think Stephane Couture made an important point: it is important to locate consensus on the politics of protocols in its respective academic disciplines and literatures, and have the document reflect that nuance. Furthermore, having followed this discussion for a while now (about a year or four) I feel part of the continued disagreement seems to stem from the fact that people have very different understandings of the word "political" and "politics". For some it refers to the subtle ways by which protocol design is influenced by the values/interests/power dynamics between various folks present in the IETF and to others it refers to capital R or D conversations among politicians happening outside of the IETF, and yet to others its definition lies somewhere in the middle of these two. As Stephane also mentioned - perhaps this document (and perhaps even the discussion) could benefit from further clarification and state this conceptual disagreement on what it means for some to have politics to begin with? Just my .2, -- Corinne Cath - Speth Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute Web: www.oii.ox.ac.uk/people/corinne-cath Email: ccath@turing.ac.uk & corinnecath@gmail.com Twitter: @C_CS On Mon, Sep 23, 2019 at 7:47 PM Eric Rescorla wrote: > Hi Niels, > > I think we're sort of talking past each other, so I'm going > to focus on one point, namely the purpose of this document. > > Based on this discussion, you seem to be arguing that the > purpose is to *demonstrate* the political nature of protocols > and standards: > > > >> > I certainly agree that they "can be used" > > >> > for political means, though any "can" statement is pretty weak. > > >> > > > >> > > >> If we can document *that*, we would have made a lot of progress in > > >> the IETF imho. > > > > > > I don't know anyone disagrees with that. > > > > Great. But I meet them at every IETF meeting, and it is brought up > > very regularly in discussion. > > > However, the draft just asserts that there is agreement on this: > > development process and its outputs, it is generally agreed that > standards and protocols are both products of a political process, and > they can also be used for political means. Therefore protocols and > > So, which is it, generally agreed or regularly contested? > > > In any case, if the point is to demonstrate that protocols > can be derived from politically derived processes and that > they can be used politically, then IMO you are going about > it entirely the wrong way, which is by using a very expansive > (and not really that familiar to the people here) definition > political and then making a strong claim which forces you > to defend cases that people think are questionable (e.g., > NTP or SSLv2). > > To the extent to which there is debate about the claims > that protocols *can* be politically derived and *can* be > deployed in political ways, the way to go about demonstrating > that is to focus on the easy cases that are clearly political > (I've named a number in this discussion). That doesn't require > going and mining the literature you are citing here, but rather > requires engaging with the history and use of these protocols. > > -Ekr > > On Mon, Sep 23, 2019 at 2:32 AM Niels ten Oever > wrote: > >> >> >> On 9/21/19 4:13 PM, Eric Rescorla wrote: >> >> Niels ten Oever via ietf.org >> >> >> >> 6:10 AM (48 minutes ago) >> >> >> >> to hrpc >> >> >> >> >> >> On 9/21/19 3:32 AM, Eric Rescorla wrote: >> >> > Whereas there might not be agreement among the Internet protocol >> >> > community on the specific political nature of the technological >> >> > development process and its outputs, it is generally agreed that >> >> > standards and protocols are both products of a political process, >> and >> >> > they can also be used for political means. >> >> > >> >> > I would like to register my agrement with Andrew and focus in on this >> >> > one point: there are many protocols (in fact, by count probably most >> >> > protocols) which are just designed by proprietary organizations. >> It's >> >> > not clear on what basis you are claiming that they are the output of >> >> > political processes and this certainly doesn't seem like something >> >> > that's generally agreed. >> >> >> >> Aren't proprietary standards, and the way they make it possible and >> >> impossible to do certain things, a prime example of a political >> >> process and political impact? >> > >> > Well, I don't think without stretching the term "political" outside >> > of the point where saying something is political is trivial, no, >> > I don't think so. >> > >> > Again, let's take the example of SSL, which was designed by Netscape >> > for its own market purposes and became a de facto standard because >> > Netscape had the dominant browser and people wanted to interoperate >> > with it. What's poltical about that process? >> > >> > >> >> There are several political aspects about this, we had for instance text >> in a previous version that read about dominance and de facto standards: >> >> Within economy studies, _de facto_ standards arise in market >> situations where one entity is particularly dominant; downstream >> competitors are therefore tied to the dominant entity's technological >> solutions [Ahlborn]. Under EU anti-trust law, _de facto_ standards >> have been found to restrict competition for downstream services in PC >> software products [CJEU2007], as well as downstream services >> dependent on health information [CJEU2004]. >> >> Another interesting aspect that SSL introduced were of course certificate >> authorities, that served as trust anchors, which is ultimately defining >> trusted authorities. >> >> SSLv2 was introduced as open standard (while v1 was not), which of course >> was also quite a change, I reckon I don't need to elaborate on the politics >> of licensing in this audience. >> >> > >> >> > I certainly agree that they "can be used" >> >> > for political means, though any "can" statement is pretty weak. >> >> > >> >> >> >> If we can document *that*, we would have made a lot of progress in >> >> the IETF imho. >> > >> > I don't know anyone disagrees with that. >> >> Great. But I meet them at every IETF meeting, and it is brought up very >> regularly in discussion. >> >> > But in any case, demonstrating >> > that doesn't require hauling in the theoretical apparatus you >> > are trying to deploy here, but rather requires *history*. I.e., >> > demonstrate that the process of developing some set of standards >> > involved the political process of balancing the objectives of >> > the various stakeholders, finding compromise, etc. Given that >> > every IETF standards development process I have ever been involved in >> > has had some of this, that doesn't seem hard. As a non-IETF example >> > "The Box", a history of the shipping container, has a nice description >> > of the standardization of that technology. >> > > >> >> > This is even true at some level for many standards, especially >> >> > because your definition of "standard" is so expansive: >> >> > >> >> > Standards 'A standard is an agreed-upon way of doing something or >> >> > measuring something.' [Sisson] >> >> > >> >> > By this definition I think it would be pretty hard to argue that >> >> > SSLv2, and SSLv3 weren't standards given their wide use, even >> >> > though they were just designed by people at one company. >> >> >> >> I don't see how that definition would make that impossible. >> > >> > I'm not sure I understand your response here. Are you saying that >> > protocols defined by one company and that then achieve wide use >> > are standards, or they are not? >> > >> >> SSLv2 and SSLv3 were standards because people agreed that they were the >> standard? For something to be a standard it does not need to be a formal >> process to accept them as such. >> >> >> > Another >> >> > example would be the Philips screwdriver head. What's the political >> >> > process that produced these? >> >> > >> >> > >> >> >> >> The patenting of process by Henry F. Philips, the regimes under >> >> which is was patented, its competition with other screw heads (torx, >> >> etc). There is an enormous amount of politics, and societal ordering >> >> connected with screws. >> > >> > Again, this just seems to serve to make the definition of "political" >> > meaningless. By this definition, what human commercial activity >> > would *not* be political, as it all occurs against a political >> > backdrop. >> > >> >> A transaction can be political, but of course does not need to be. >> (Trans)action, such as standards, that change the market, are political >> activities. >> >> >> > >> >> > More generally, it seems like depending on how one interprets the >> >> > major claims in this document, they are either too strong (all >> >> > protocol and standards development is political) >> >> >> >> Why is that too strong? >> > >> > For the reasons I indicated above: I don't think the development >> > of many protocols, especially the small ones which get use internally >> > as in, for instance, mobile apps, is generally political, And sometimes >> > becoome standards and that's not necessarily political either. >> > >> > >> >> > or trivial (some >> >> > protocol and standards development is political). The first is too >> >> > strong for the reasons I indicate above, >> >> >> >> I don't think so, but I am happy to discuss. >> >> >> >> and the second seems pretty >> >> > obvious and doesn't really need much theorizing; >> >> >> >> As said, I think it would be very useful if we would document this, >> >> so we don't need to repeat the discussion. >> > >> > Well, I'm not sure it matters if we repeat this discussion or >> > even come to a conclusion on it. What's at stake in the answer? >> > >> > But, again, if you want to demonstrate that standards development >> > can be political -- which, as I said, is a rather weak claim -- >> > then I would discard this document and instead focus on documenting >> > the history of the development of some protocols that was clealr >> > political. >> > >> > >> >> As you know, what this draft meant to do, is to document a discussion so >> it doesn't need to be repeated in the study of every different protocol. >> >> We could paste in a lot of examples here, for instance some of the review >> of the human rights review team. But the discussion in 4.5 might be enough? >> >> >> >> >> > one needs just point >> >> > to the development of some protocol which was a political process, >> and >> >> > it seems like that's been pretty amply documented for a number of >> >> > protocols/standards (e.g., HTTP/2 or TLS 1.0). >> >> > >> >> > As I noted above, the claim that protocols can be used for political >> >> > means also seems relatively obvious (cf. Tor). >> >> >> >> I am happy to conclude that we agree on the two statements: >> >> >> >> - some protocol and standards development is political >> >> >> >> and >> >> >> >> - protocols can be used for political means >> > >> > Well, I don't think this document demonstrates that, it's just >> > conclusory. To the extent to which we think these statements are >> > actually in debate and need demonstrating, then I would, as I said, >> > focus on demonstrating them with reference to actual standards >> > rather than by referring to other people's views about these >> > statements. I would think 3-5 of each of these should be sufficient >> > (though of course logically one alone is sufficient to prove >> > existence, but several is more convincing) >> > >> >> Again, the document seeks to document existing positions in the community >> and provide background in existing literature on the topic, that could then >> be a platform for further work. >> >> For instance on specific drafts, and or specific tendencies (based on >> case studies, quantitative models, etc). >> >> Best, >> >> Niels >> >> >> >> >> >> > >> >> That's progress for me in this discussion. Now let's see if we can >> >> further flesh out: >> >> >> >> - all protocol and standards development is political >> > >> > I think what would help at this point that would be for you to >> > describe some commercial activities that you think are *not* >> > political. >> > >> > -Ekr >> > >> > >> >> -- >> Niels ten Oever >> Researcher and PhD Candidate >> DATACTIVE Research Group >> University of Amsterdam >> >> PGP fingerprint 2458 0B70 5C4A FD8A 9488 >> 643A 0ED8 3F3A 468A C8B3 >> > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Corinne Cath - Speth Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute Web: www.oii.ox.ac.uk/people/corinne-cath Email: ccath@turing.ac.uk & corinnecath@gmail.com Twitter: @C_CS --00000000000008df5d05933cdbe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think Stephane Couture made an important point: it i= s important to locate consensus on the politics of protocols in its respect= ive academic disciplines and literatures, and have the document reflect tha= t nuance.=C2=A0

Furthermore, having followed this discussion for a whi= le now (about a year or four) I feel part of the continued disagreement see= ms to stem from the fact that people have very different understandings of = the word "political" and "politics". For some it refers= to the subtle ways by which protocol design is influenced by the values/in= terests/power dynamics between various folks present in the IETF and to oth= ers it refers to capital R or D conversations among politicians happening o= utside of the IETF, and yet to others its definition lies somewhere in the = middle of these two.=C2=A0

As Stephane also mentioned - perhaps this d= ocument (and perhaps even the discussion) could benefit from further clarif= ication and state this conceptual disagreement on what it means for some to= have politics to begin with?=C2=A0

Just my .2,


= --
Cori= nne Cath - Speth
Ph.D. Candidate, Oxford Internet Institute & Alan T= uring Institute

Web: www.oii.ox.= ac.uk/people/corinne-cath
Email: ccath@turing.ac.uk & corinnecath@gmail.com
Twitter: @C= _CS


On Mon, Sep 23, 2019 at 7:47 PM E= ric Rescorla <ekr@rtfm.com> wrote= :
Hi Niels,

I think we're sort of talking past each other, so I= 'm going
to focus on one point, namely the purpose of this document.=

Based on this discussion, you seem to be arguing that the
purpos= e is to *demonstrate* the political nature of protocols
and standards:
> >> > I certainly agree that they "can be used"= ;
> >> > for political means, though any "can" sta= tement is pretty weak.
> >> >
> >>
> >&= gt; If we can document *that*, we would have made a lot of progress in
&= gt; >> the IETF imho.
> >
> > I don't know any= one disagrees with that.
>
> Great. But I meet them at every = IETF meeting, and it is brought up
> very regularly in discussion.

However, the draft just asserts that there is agreement on this:
=C2=A0 =C2=A0development process and its outputs, it is generally agr= eed that
=C2=A0 =C2=A0standards and protocols are both products of a pol= itical process, and
=C2=A0 =C2=A0they can also be used for political mea= ns.=C2=A0 Therefore protocols and

So, which is it, generally agreed = or regularly contested?


In any case, if the point is to demonstr= ate that protocols
can be derived from politically derived processes and= that
they can be used politically, then IMO you are going about
it e= ntirely the wrong way, which is by using a very expansive
(and not reall= y that familiar to the people here) definition
political and then making= a strong claim which forces you
to defend cases that people think are q= uestionable (e.g.,
NTP or SSLv2).

To the extent to which there is= debate about the claims
that protocols *can* be politically derived and= *can* be
deployed in political ways, the way to go about demonstrating<= br>that is to focus on the easy cases that are clearly political
(I'= ve named a number in this discussion). That doesn't require
going an= d mining the literature you are citing here, but rather
requires engagin= g with the history and use of these protocols.

-Ekr

On Mon, Sep 2= 3, 2019 at 2:32 AM Niels ten Oever <mail@nielstenoever.net> wrote:


On 9/21/19 4:13 PM, Eric Rescorla wrote:
>> Niels ten Oever via ietf.org <http://ietf.org>
>>
>> 6:10 AM (48 minutes ago)
>>
>> to hrpc
>>
>>
>> On 9/21/19 3:32 AM, Eric Rescorla wrote:
>> > =C2=A0 =C2=A0Whereas there might not be agreement among the I= nternet protocol
>> > =C2=A0 =C2=A0community on the specific political nature of th= e technological
>> > =C2=A0 =C2=A0development process and its outputs, it is gener= ally agreed that
>> > =C2=A0 =C2=A0standards and protocols are both products of a p= olitical process, and
>> > =C2=A0 =C2=A0they can also be used for political means.
>> > =C2=A0 =C2=A0
>> > I would like to register my agrement with Andrew and focus in= on this
>> > one point: there are many protocols (in fact, by count probab= ly most
>> > protocols) which are just designed by proprietary organizatio= ns.=C2=A0 It's
>> > not clear on what basis you are claiming that they are the ou= tput of
>> > political processes and this certainly doesn't seem like = something
>> > that's generally agreed.
>>
>> Aren't proprietary standards, and the way they make it possibl= e and
>> impossible to do certain things, a prime example of a political >> process and political impact?
>
> Well, I don't think without stretching the term "political&qu= ot; outside
> of the point where saying something is political is trivial, no,
> I don't think so.
>
> Again, let's take the example of SSL, which was designed by Netsca= pe
> for its own market purposes and became a de facto standard because
> Netscape had the dominant browser and people wanted to interoperate > with it. What's poltical about that process?
>
>

There are several political aspects about this, we had for instance text in= a previous version that read about dominance and de facto standards:

=C2=A0 =C2=A0Within economy studies, _de facto_ standards arise in market =C2=A0 =C2=A0situations where one entity is particularly dominant; downstre= am
=C2=A0 =C2=A0competitors are therefore tied to the dominant entity's te= chnological
=C2=A0 =C2=A0solutions [Ahlborn].=C2=A0 Under EU anti-trust law, _de facto_= standards
=C2=A0 =C2=A0have been found to restrict competition for downstream service= s in PC
=C2=A0 =C2=A0software products [CJEU2007], as well as downstream services =C2=A0 =C2=A0dependent on health information [CJEU2004].

Another interesting aspect that SSL introduced were of course certificate a= uthorities, that served as trust anchors, which is ultimately defining trus= ted authorities.

SSLv2 was introduced as open standard (while v1 was not), which of course w= as also quite a change, I reckon I don't need to elaborate on the polit= ics of licensing in this audience.

>
>> > I certainly agree that they "can be used"
>> > for political means, though any "can" statement is = pretty weak.
>> >
>>
>> If we can document *that*, we would have made a lot of progress in=
>> the IETF imho.
>
> I don't know anyone disagrees with that.

Great. But I meet them at every IETF meeting, and it is brought up very reg= ularly in discussion.

> But in any case, demonstrating
> that doesn't require hauling in the theoretical apparatus you
> are trying to deploy here, but rather requires *history*. I.e.,
> demonstrate that the process of developing some set of standards
> involved the political process of balancing the objectives of
> the various stakeholders, finding compromise, etc. Given that
> every IETF standards development process I have ever been involved in<= br> > has had some of this, that doesn't seem hard. As a non-IETF exampl= e
> "The Box", a history of the shipping container, has a nice d= escription
> of the standardization of that technology.
> >
>> > This is even true at some level for many standards, especiall= y
>> > because your definition of "standard" is so expansi= ve:
>> >
>> > =C2=A0 =C2=A0Standards =C2=A0'A standard is an agreed-upo= n way of doing something or
>> > =C2=A0 =C2=A0 =C2=A0 measuring something.' =C2=A0[Sisson]=
>> >
>> > By this definition I think it would be pretty hard to argue t= hat
>> > SSLv2, =C2=A0and SSLv3 weren't standards given their wide= use, even
>> > though they were just designed by people at one company.
>>
>> I don't see how that definition would make that impossible. >
> I'm not sure I understand your response here. Are you saying that<= br> > protocols defined by one company and that then achieve wide use
> are standards, or they are not?
>

SSLv2 and SSLv3 were standards because people agreed that they were the sta= ndard? For something to be a standard it does not need to be a formal proce= ss to accept them as such.

>> > Another
>> > example would be the Philips screwdriver head. What's the= political
>> > process that produced these?
>> >
>> >
>>
>> The patenting of process by Henry F. Philips, the regimes under >> which is was patented, its competition with other screw heads (tor= x,
>> etc). There is an enormous amount of politics, and societal orderi= ng
>> connected with screws.
>
> Again, this just seems to serve to make the definition of "politi= cal"
> meaningless. By this definition, what human commercial activity
> would *not* be political, as it all occurs against a political
> backdrop.
>

A transaction can be political, but of course does not need to be. (Trans)a= ction, such as standards, that change the market, are political activities.=


>
>> > More generally, it seems like depending on how one interprets= the
>> > major claims in this document, they are either too strong (al= l
>> > protocol and standards development is political)
>>
>> Why is that too strong?
>
> For the reasons I indicated above: I don't think the development > of many protocols, especially the small ones which get use internally<= br> > as in, for instance, mobile apps, is generally political, And sometime= s
> becoome standards and that's not necessarily political either.
>
>
>> > or trivial (some
>> > protocol and standards development is political). The first i= s too
>> > strong for the reasons I indicate above,
>>
>> I don't think so, but I am happy to discuss.
>>
>> and the second seems pretty
>> > obvious and doesn't really need much theorizing;
>>
>> As said, I think it would be very useful if we would document this= ,
>> so we don't need to repeat the discussion.
>
> Well, I'm not sure it matters if we repeat this discussion or
> even come to a conclusion on it. What's at stake in the answer? >
> But, again, if you want to demonstrate that standards development
> can be political -- which, as I said, is a rather weak claim --
> then I would discard this document and instead focus on documenting > the history of the development of some protocols that was clealr
> political.
>
>

As you know, what this draft meant to do, is to document a discussion so it= doesn't need to be repeated in the study of every different protocol.<= br>
We could paste in a lot of examples here, for instance some of the review o= f the human rights review team. But the discussion in 4.5 might be enough?<= br>
>>
>> > one needs just point
>> > to the development of some protocol which was a political pro= cess, and
>> > it seems like that's been pretty amply documented for a n= umber of
>> > protocols/standards (e.g., HTTP/2 or TLS 1.0).
>> >
>> > As I noted above, the claim that protocols can be used for po= litical
>> > means also seems relatively obvious (cf. Tor).
>>
>> I am happy to conclude that we agree on the two statements:
>>
>> - some protocol and standards development is political
>>
>> and
>>
>> - protocols can be used for political means
>
> Well, I don't think this document demonstrates that, it's just=
> conclusory.=C2=A0 To the extent to which we think these statements are=
> actually in debate and need demonstrating, then I would, as I said, > focus on demonstrating them with reference to actual standards
> rather than by referring to other people's views about these
> statements. I would think 3-5 of each of these should be sufficient > (though of course logically one alone is sufficient to prove
> existence, but several is more convincing)
>

Again, the document seeks to document existing positions in the community a= nd provide background in existing literature on the topic, that could then = be a platform for further work.

For instance on specific drafts, and or specific tendencies (based on case = studies, quantitative models, etc).

Best,

Niels





> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>> That's progress for me in this discussion. Now let's see i= f we can
>> further flesh out:
>>
>> - all protocol and standards development is political
>
> I think what would help at this point that would be for you to
> describe some commercial activities that you think are *not*
> political.
>
> -Ekr
>
>

--
Niels ten Oever
Researcher and PhD Candidate
DATACTIVE Research Group
University of Amsterdam

PGP fingerprint=C2=A0 =C2=A0 2458 0B70 5C4A FD8A 9488=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0643A 0= ED8 3F3A 468A C8B3
_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


--
Corinne Cath - Speth
Ph.D. Candidate, Oxford Interne= t Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: ccath@turing.ac.uk & = corinnecath@gmai= l.com
Twitter: @C_CS
=
--00000000000008df5d05933cdbe9-- From nobody Mon Sep 23 13:30:35 2019 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 634AF1200F7 for ; Mon, 23 Sep 2019 13:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=dhjhliUV; dkim=pass (1024-bit key) header.d=yitter.info header.b=F4wOOtvC 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 QHBsko0vHadD for ; Mon, 23 Sep 2019 13:30:29 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3AE12000F for ; Mon, 23 Sep 2019 13:30:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 16620BCBD1; Mon, 23 Sep 2019 20:29:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1569270598; bh=qvZP0tUI58lEtkz3MuTogUv1McyUE8jIaVLz5IWIteQ=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=dhjhliUVolmZOfYw/RIzz0tFQ5k4JU2HnKCFcGdFtB8j06ne5KmcUnlz8hOs5EV3D nbIosuXrQbCl84A3Ur7TfMRXMpcqvIzzd59vOIoL7aDrcx3teHMvMfmvan9hBU/KJs y8d9whEqyM7tFqnWapUZHAfiaM7+onR5MNMeElDM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBSBLeQc5QNF; Mon, 23 Sep 2019 20:29:56 +0000 (UTC) From: Andrew Sullivan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1569270596; bh=qvZP0tUI58lEtkz3MuTogUv1McyUE8jIaVLz5IWIteQ=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=F4wOOtvCxmR/XnOZXEkZiGEO7Cr/enmzFE8KLtg8xfeF17FPY9qlQUNLVwT3lwfUQ fqLd0MxAsKOtMbVVl+6ZSkYSqwb7cMJkNgOMXT6eJqwBC78zKzpi917UFmyMNk+DBX dKGIVY1FhD+D9qYDFuGYFQ8V60pYuBJcvNnUGLxE= To: =?UTF-8?B?U3TDqXBoYW5lIENvdXR1cmU=?= CC: Niels ten Oever , Stephen Farrell , Eric Rescorla , Date: Mon, 23 Sep 2019 16:29:52 -0400 Message-ID: <16d5fd0f200.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> In-Reply-To: References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <4aff9b71-b645-903f-bef8-ca86d048c183@cs.tcd.ie> <16d5dfdace8.27a2.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------16d5fd0f3df218a27a23b950a6" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 20:30:34 -0000 This is a multi-part message in MIME format. ------------16d5fd0f3df218a27a23b950a6 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi, Certainly some parts of the STS literature are in agreement about this issue. The fact that other, now less academically fashionable traditions reject the view, of course, does not tell us what is true. But the location of consensus would certainly help. I _really_ like the approach of teasing out what "political" means in this discussion, however. I tried to make that point much less effectively the other day, so thank you for staying well and clearly what I barely managed to suggest. I haven't thought enough to say whether I think this taxonomy is complete, but it's certainly an excellent start. A -- Andrew Sullivan Please excuse my clumbsy thums. On September 23, 2019 12:11:47 Stéphane Couture wrote: > Hi, This is a very interesting discussion. I wanted to jump in following > this last comment, to make a small contribution. Not sure if it is coherent > with IETF discussions, but I hope this helps. > > First, I agree with Niels that there is a near consensus in certain > academic fields (like STS and many works in philosophy of technology) that > technological forms (standards, protocols, machines, tools) are political. > Without making it as an argument of authority, I am wondering if it could > be helpful to simply better describe the "location" of this consensus, > instead of making sound like this is an absolute truth. This would avoid > the delicate process of verifying the claims of every authors, while also > informing the community that these scholarly work exists. > > Second, it might be worth having a section to explain what we mean by > "political" and "how" the politics of technologies have been articulated in > the literature. We have a section like this, but it's more like a > "conclusion" than a framework. I like for instance this characterization by > Darin Barney (following Andrew Feenberg) of the politics of technologies: > > -Technology as a *mean* of political activity : for instance, using a tool > (or protocol) to suppress freedom of expression or enhance citizenship > participation. > -Technology as an *object* of political activity or deliberation: > discussions and social process in the making of technologies : who is > making the decision about protocols? Is it democratic and legitimate? Who > is excluded in these spaces of decision about protocols/standards? Who > should be included, and why? > > -As the *setting" of political activity : what are the constraints and > possibilities of our particular technological culture ? How is the history > of this technological culture affecting our choices today? Here you could, > I think, include discussions like the previous one on the impact of > historical standardization of time in our current technological choices > (why taking Greenwich as the reference point, and not Tashkent or Nairobi?). > Stéphane > > Barney, D. (2007). One Nation Under Google. Hart Lecture. > http://darinbarneyresearch.mcgill.ca/Work/One_Nation_Under_Google.pdf > > > > Le lun. 23 sept. 2019 à 07:59, Andrew Sullivan a > écrit : > Niels, > > This post is a perfect example of one problem that I have been complaining > about. If everything that is ever touched upon by any politics is thereby > itself "political", then your point is true (though, I submit, trivially > so). But you haven't actually shown that claim, and any time anyone > objects to this point you simply trot out some authority to say, "But it is > so true." But the argument is basically over whether those authors are > right. So it's either begging the question or fallacious appeal to > authority or both. > > Best regards, > > A > -- > Andrew Sullivan > Please excuse my clumbsy thums. > > On September 23, 2019 05:44:33 Niels ten Oever wrote: > >> On 9/21/19 4:18 PM, Stephen Farrell wrote: >>> >>> Hiya, >>> >>> On 21/09/2019 15:13, Eric Rescorla wrote: >>>> Again, let's take the example of SSL, which was designed by Netscape >>>> for its own market purposes and became a de facto standard because >>>> Netscape had the dominant browser and people wanted to interoperate >>>> with it. What's poltical about that process? >>> >>> To be fair, there was a lot of IETF politics around >>> Netscape and Microsoft related to that and IIRC TLS >>> was only called that as part of an explicit compromise. >>> >>> I think Eliot's examples (and NTP, which I raised) >>> are maybe better examples of less/apolitical standards >>> and protocols than SSL/TLS. >> >> Time, and its standardization, is a very political project. Going back to >> Aristotle (Physics iv 10-14) there is the difference between Chronos and >> Kairos, where Chronos became the number to measure motion (kinesis). There >> have been many other perceptions and measurements of time, that were able >> to exist next to each other, but as part of the colonial project, the >> European concept of what time was, was made the universal standard. That is >> why Greenwich Mean Time (in Great Britain) is used as a standard for the >> whole world. >> >> There are also many stories about the development of timezones, and their >> consequences, the way in which time helped shape labor, life, and how it >> altered complete societies. >> >> I am not making a value judgment about this re-odering, but I am trying to >> show that NTP, which helps synchronize to a specific time regime, on which >> a lot of computing depends, helps promulgate a specific, and political, >> ordering. >> >> This book on the topic is quite interesting: >> https://www.amazon.com/Colonisation-Time-Studies-Imperialism/dp/0719082714 >> >> Best, >> >> Niels >> >> >> >> >> >> -- >> Niels ten Oever >> Researcher and PhD Candidate >> DATACTIVE Research Group >> University of Amsterdam >> >> PGP fingerprint 2458 0B70 5C4A FD8A 9488 >> 643A 0ED8 3F3A 468A C8B3 >> >> >> >> >> ---------- >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc ------------16d5fd0f3df218a27a23b950a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Ce= rtainly some parts of the STS literature are in agreement about this issue.= The fact that other, now less academically fashionable traditions reject t= he view, of course, does not tell us what is true. But the location of cons= ensus would certainly help. 

I _really_ like the approach of teasing out what "political" mean= s in this discussion, however. I tried to make that point much less effecti= vely the other day, so thank you for staying well and clearly what I barely= managed to suggest. I haven't thought enough to say whether I think this t= axonomy is complete, but it's certainly an excellent start. 

A


-- 
Andrew= Sullivan
Please excuse my clumbsy thums.

On September 23, 2019 12:11:47 St=C3=A9phane Couture <listes@st= ephcouture.info> wrote:

Hi,=20 This is a very interesting discussion. I wanted to jump in following this l= ast comment, to make a small contribution. Not sure if it is coherent = with IETF discussions, but I hope this helps.


First, I agree with Niels that= there is a near consensus in certain academic fields (like STS and many wo= rks in philosophy of technology) that technological forms (standards, proto= cols, machines, tools) are political. Without making it as an argument of a= uthority, I am wondering if it could be helpful to simply better describe t= he "location" of this consensus, instead of making sound like this is an ab= solute truth. This would avoid the delicate process of verifying the claims= of every authors, while also informing the community that these scholarly = work exists.


Second, it might be worth havi= ng a section to explain what we mean by "political" and "how" the politics = of technologies have been articulated in the literature. We have a section = like this, but it's more like a "conclusion" than a framework. I like for i= nstance this characterization by Darin Barney (following Andrew Feenberg) o= f the politics of technologies:


-Technology as a *mean* of= political activity : for instance, using a tool (or protocol) to suppress = freedom of expression or enhance citizenship participation. 


-Technology as an *object* of = political activity or deliberation: discussions and social process in the m= aking of technologies : who is making the decision about protocols? Is it d= emocratic and legitimate? Who is excluded in these spaces of decision about= protocols/standards? Who should be included, and why?


-As the *setting" of polit= ical activity : what are the constraints and possibilities of our particula= r technological culture ? How is the history of this technological culture = affecting our choices today? Here you could, I think, include discussions l= ike the previous one on the impact of historical standardization of time in= our current technological choices (why taking Greenwich as the reference p= oint, and not Tashkent or Nairobi?).


St=C3=A9phane


Barney, D. (2007). One Nation Under Google. Hart Lecture.&= nbsp; http://darinbarneyresearch.mcgill.ca/Work/One_Nation_Unde= r_Google.pdf



Le lun. 23 sept. 2019 =C3=A0 07:5= 9, Andrew Sullivan <ajs@anvilwalrusden.com> a =C3=A9crit :
Niels,

This post is a perfect example of one problem that I have been complaining =
about.  If everything that is ever touched upon by any politics is the= reby
itself "political", then your point is true (though, I submit, trivially so).  But you haven't actually shown that claim, and any time anyone <= br> objects to this point you simply trot out some authority to say, "But it is=
so true." But the argument is basically over whether those authors are
right. So it's either begging the question or fallacious appeal to
authority or both.

Best regards,

A
--
Andrew Sullivan
Please excuse my clumbsy thums.

On September 23, 2019 05:44:33 Niels ten Oever <mail@nielstenoever.net> wrote:
> On 9/21/19 4:18 PM, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> On 21/09/2019 15:13, Eric Rescorla wrote:
>>> Again, let's take the example of SSL, which was designed by Ne= tscape
>>> for its own market purposes and became a de facto standard bec= ause
>>> Netscape had the dominant browser and people wanted to interop= erate
>>> with it. What's poltical about that process?
>>
>> To be fair, there was a lot of IETF politics around
>> Netscape and Microsoft related to that and IIRC TLS
>> was only called that as part of an explicit compromise.
>>
>> I think Eliot's examples (and NTP, which I raised)
>> are maybe better examples of less/apolitical standards
>> and protocols than SSL/TLS.
>
> Time, and its standardization, is a very political project. Going back= to
> Aristotle (Physics iv 10-14) there is the difference between Chronos a= nd
> Kairos, where Chronos became the number to measure motion (kinesis). T= here
> have been many other perceptions and measurements of time, that were a= ble
> to exist next to each other, but as part of the colonial project, the =
> European concept of what time was, was made the universal standard. Th= at is
> why Greenwich Mean Time (in Great Britain) is used as a standard for t= he
> whole world.
>
> There are also many stories about the development of timezones, and th= eir
> consequences, the way in which time helped shape labor, life, and how = it
> altered complete societies.
>
> I am not making a value judgment about this re-odering, but I am tryin= g to
> show that NTP, which helps synchronize to a specific time regime, on w= hich
> a lot of computing depends, helps promulgate a specific, and political= ,
> ordering.
>
> This book on the topic is quite interesting:
> https://www.amazon.co= m/Colonisation-Time-Studies-Imperialism/dp/0719082714
>
> Best,
>
> Niels
>
>
>
>
>
> --
> Niels ten Oever
> Researcher and PhD Candidate
> DATACTIVE Research Group
> University of Amsterdam
>
> PGP fingerprint   2458 0B70 5C4A FD8A 9488
>                   64= 3A 0ED8 3F3A 468A C8B3
>
>
>
>
> ----------
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc



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

------------16d5fd0f3df218a27a23b950a6-- From nobody Tue Sep 24 03:49:25 2019 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 3064C12018B for ; Tue, 24 Sep 2019 03:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 LkYABiakdgL1 for ; Tue, 24 Sep 2019 03:49:21 -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 8B89F12010E for ; Tue, 24 Sep 2019 03:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8662; q=dns/txt; s=iport; t=1569322160; x=1570531760; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=RiUEsHp0eUss1pS9fh6WWZ0uDGsSikhZZQkUlD3I4Bs=; b=KMwLWeUo2ft3FMZTeb0+e+RZkYAcAhAYiRPbn52F3LqkzpkQtIWzRhLk A6Wbhs6/3tHVnZzxIiq6KMr0iFqPeURR9cYZdEvnRgOgNuBynMIz1RfRf yHH8O6i17zDQq5xJ7oYrHpisLi5VXoU09NN/CrVAYzjSPBX5bbYbf/kTB c=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAAr9Ild/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEMAgEBAQGBVQMBAQEBCwGBboFvMiqEIoh8h3oliWeJMIYLgXsCBwEBAQk?= =?us-ascii?q?DAQEvAQGEPwKDQzYHDgIDCQEBBAEBAQIBBQRthTmFSgEBAgIBI08HBQsjKgI?= =?us-ascii?q?CITYGE4MiAYFqAw4PrE9zgTKFTIJIDYIbEIE0AYFQilCBf4E4DBOBToNWggM?= =?us-ascii?q?LgycygiYElgKIIY4oQYIsA4IrgROIFYUzhAEbgjaHS4N+hnqELJg1i2mDEQI?= =?us-ascii?q?EBgUCFYFZBisqgS4zGggbFWUBgkE+EhAUkBU+AzCKX4JUAQE?= X-IronPort-AV: E=Sophos;i="5.64,543,1559520000"; d="asc'?scan'208,217";a="17217148" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2019 10:49:16 +0000 Received: from [10.61.212.69] ([10.61.212.69]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x8OAnFv9024596 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Sep 2019 10:49:16 GMT From: Eliot Lear Message-Id: <01F67955-FA6C-4191-9D5D-A9E1AB61703C@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_54BB54F9-0E23-4090-B1D6-15E619F4AB7D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Sep 2019 12:49:15 +0200 In-Reply-To: Cc: Hrpc , Niels ten Oever To: Corinne Cath References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <793367e8-7151-354e-04ca-b472760c6af7@nielstenoever.net> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.212.69, [10.61.212.69] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [hrpc] Moving forward on draft-irtf-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 10:49:24 -0000 --Apple-Mail=_54BB54F9-0E23-4090-B1D6-15E619F4AB7D Content-Type: multipart/alternative; boundary="Apple-Mail=_21A7C038-3314-4F7F-8D21-DAB09A17AA09" --Apple-Mail=_21A7C038-3314-4F7F-8D21-DAB09A17AA09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Corinne, Thanks. Please see below. > On 23 Sep 2019, at 20:47, Corinne Cath wrote: >=20 > Hi, >=20 > I think Stephane Couture made an important point: it is important to = locate consensus on the politics of protocols in its respective academic = disciplines and literatures, and have the document reflect that nuance. Agree. >=20 > Furthermore, having followed this discussion for a while now (about a = year or four) I feel part of the continued disagreement seems to stem = from the fact that people have very different understandings of the word = "political" and "politics=E2=80=9D. Although, at least for me, characterizing that as disagreement is = overstating the case, I agree that providing clarity on the terms and = the bounding of their meaning would put any thesis and argumentation on = better footing. > For some it refers to the subtle ways by which protocol design is = influenced by the values/interests/power dynamics between various folks = present in the IETF and to others it refers to capital R or D = conversations among politicians happening outside of the IETF, and yet = to others its definition lies somewhere in the middle of these two. Again, some precision is called for. I think you are talking about the = politics of development of standards versus the political ramifications = of the results. This relationship could be explored. For instance, I = think those who participated in webrtc would have found that development = process somewhat political, in terms of finding a way forward; but I = would be hard pressed to find political ramifications from the results, = in as much as broader society is impacted (again, my imagination may be = limited). On the other hand, I could imagine the reverse, where the = IETF standardized something with little if any controversy that turned = out to have profound political ramifications. Asking Avri and you now with your co-chair hats, I think it would be = helpful to pause for a moment and just reflect on the issues the have = been raised with regard to this work and how to structure discussion = going forward. For instance: is there agreement on the research question in the = document? If not, what is the point of considering anything else? Has = that question already been addressed elsewhere? If not, great. If so, = what is the contribution this work is intended to provide? As you ponder this, it may be that there are multiple points of view to = be heard. As an RG we have the possibility to publish differing = perspectives, and this has happened in the past, most notably in the = Routing RG when it was active. Regards, Eliot --Apple-Mail=_21A7C038-3314-4F7F-8D21-DAB09A17AA09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Corinne,

Thanks.  Please see below.

On 23 Sep 2019, at 20:47, = Corinne Cath <corinnecath@gmail.com> wrote:

Hi,

I think Stephane Couture made = an important point: it is important to locate consensus on the politics = of protocols in its respective academic disciplines and literatures, and = have the document reflect that = nuance.

Agree.


Furthermore, having followed = this discussion for a while now (about a year or four) I feel part of = the continued disagreement seems to stem from the fact that people have = very different understandings of the word "political" and "politics=E2=80=9D= .

Although, = at least for me, characterizing that as disagreement is overstating the = case,  I agree that providing clarity on the terms and the bounding = of their meaning would put any thesis and argumentation on better = footing.

For some it refers to the = subtle ways by which protocol design is influenced by the = values/interests/power dynamics between various folks present in the = IETF and to others it refers to capital R or D conversations among = politicians happening outside of the IETF, and yet to others its = definition lies somewhere in the middle of these = two. 

Again, = some precision is called for.  I think you are talking about the = politics of development of standards versus the political ramifications = of the results.  This relationship could be explored.  For = instance, I think those who participated in webrtc would have found that = development process somewhat political, in terms of finding a way = forward; but I would be hard pressed to find political ramifications = from the results, in as much as broader society is impacted (again, my = imagination may be limited).  On the other hand, I could imagine = the reverse, where the IETF standardized something with little if any = controversy that turned out to have profound political = ramifications.

Asking Avri and you now with your co-chair hats, I think it = would be helpful to pause for a moment and just reflect on the issues = the have been raised with regard to this work and how to structure = discussion going forward.

For instance: is there agreement on the research question in = the document?  If not, what is the point of considering anything = else?  Has that question already been addressed elsewhere?  If = not, great.  If so, what is the contribution this work is intended = to provide?

As = you ponder this, it may be that there are multiple points of view to be = heard.  As an RG we have the possibility to publish differing = perspectives, and this has happened in the past, most notably in the = Routing RG when it was active.

Regards,

Eliot
= --Apple-Mail=_21A7C038-3314-4F7F-8D21-DAB09A17AA09-- --Apple-Mail=_54BB54F9-0E23-4090-B1D6-15E619F4AB7D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2J9KsACgkQh7ZrRtnS ejOufQf/ct0gnG9/zqBGflY+XYiikElBEPl6UYxvDdTg/eHLjBQWrNqaPLbu9wl0 FdGAjry3ZNmLUaAwbIn33+0HJslfs01fNtGD/GCVYxORSfPsdXZcxsbWy9uJTy/4 Y4IlT6pB/sg/Vk2mIsXjeDsgmQ30EAsdshdst+JqFICboGR67f8VKpQbFlrISd3Q FrJ1G+caQ7PPTkg4siliCHWt80G7w5+4L1xLWVJvvAHuAxdNhTeUdPXX+iBL6qaZ HP1JCLxZrtdbZ1S9ptUJYKdmPe1OJ65k16qoF+XoXIUAxGGoRvM7GRuIDQKBShYc +4gaaTPLtgHbIVHFm+vKDjuyAy2tUA== =O3PQ -----END PGP SIGNATURE----- --Apple-Mail=_54BB54F9-0E23-4090-B1D6-15E619F4AB7D-- From nobody Tue Sep 24 04:14:18 2019 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 AF02D120106 for ; Tue, 24 Sep 2019 04:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD7mSPzy_RjC for ; Tue, 24 Sep 2019 04:14:13 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8026120118 for ; Tue, 24 Sep 2019 04:14:12 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id u40so1582054qth.11 for ; Tue, 24 Sep 2019 04:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2lt9Rr9t453GsbZTTtjQ7mD7HD/fs+jbGcadHl4OM38=; b=vD56zRlz++YV6CP1CQiFiFOT6qJf14ywKsCN6pRjAYQ/jF/pE+ys5QdX5GX4XNz5qs aW2ddhesi64TxJTGamVidLQ2CMKxCARfdSu6TRMETg1d4eQv31IFjD5Dt2digk7D9gDb +QO5EzMlBOxsWtP3PLahKGG5osnS4Fqd+AxOj4Ba5FVB0UEB9wndjRvW+99/3AR8avnq m4533O/nINigzI4oNwqIHie0qpQJIg58t2VtDKFhHf/rdKqfsKlijhghcznywiWU3hTW An0I8lGF2zBNmoZvnrjJitnoo6F8M/QZTipSDrwW7sjsktcDkd3TpCzWYhufzbOml/GQ 1ssw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2lt9Rr9t453GsbZTTtjQ7mD7HD/fs+jbGcadHl4OM38=; b=KYkTSNZYBxWi/12syOp60rchdhzwrn/mspvbDr/gUKTyecsDViwx4g+bXarYCikOnc 5m6QEpn3Zu4BoZtoKPWcBcu2Tkqdagjm1oMS3LppUFNoUzOnlUfyZYaMMF6tWBe77Wne 2tBwG0DfU8dD+3rOo41VcO+KypWzWH72UeUaQo41ZniIgmGYDLUPbYjrbOZXZPIzuJdg l5e7n4Ykv7zzuSqD6tUAiP76Nnw0wUVlB9+Fo06q4dVbFNgB8KzFI4Yo9jOPidoun8LU oqaCx4jLrvSyEdrwBFmWaxgYOT2ID/f5W/+G51xoACR2n+fY/utb7sFCUEKBmDRB5INB O5kQ== X-Gm-Message-State: APjAAAX1YViyNOGlVWFQ87B8uBnYR68xrTut09O3xRM33588Pgujhdr8 ZybA06jWhau19GLKW2UrY3Q4jk9FPTXSDBPy5Mg= X-Google-Smtp-Source: APXvYqyy+s5/9+03B2Hogo/flNfcojlwcn651kRjeWjKb8QnrKRErDnEIieST9PZtE56UBCT1guEGuQuDwOiPf4hTJs= X-Received: by 2002:a0c:abcd:: with SMTP id k13mr1924575qvb.69.1569323651667; Tue, 24 Sep 2019 04:14:11 -0700 (PDT) MIME-Version: 1.0 References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <793367e8-7151-354e-04ca-b472760c6af7@nielstenoever.net> <01F67955-FA6C-4191-9D5D-A9E1AB61703C@cisco.com> In-Reply-To: <01F67955-FA6C-4191-9D5D-A9E1AB61703C@cisco.com> From: Corinne Cath Date: Tue, 24 Sep 2019 14:13:35 +0300 Message-ID: To: Eliot Lear Cc: Hrpc , Niels ten Oever Content-Type: multipart/alternative; boundary="000000000000cb995a05934aa274" Archived-At: Subject: Re: [hrpc] Moving forward on draft-irtf-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 11:14:16 -0000 --000000000000cb995a05934aa274 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Eliot, Some quick comments in-line: On Tue, Sep 24, 2019 at 1:49 PM Eliot Lear wrote: > Corinne, > > Thanks. Please see below. > > On 23 Sep 2019, at 20:47, Corinne Cath wrote: > > Hi, > > I think Stephane Couture made an important point: it is important to > locate consensus on the politics of protocols in its respective academic > disciplines and literatures, and have the document reflect that nuance. > > > Agree. > > > Furthermore, having followed this discussion for a while now (about a yea= r > or four) I feel part of the continued disagreement seems to stem from the > fact that people have very different understandings of the word "politica= l" > and "politics=E2=80=9D. > > > Although, at least for me, characterizing that as disagreement is > overstating the case, I agree that providing clarity on the terms and th= e > bounding of their meaning would put any thesis and argumentation on bette= r > footing. > Great - not sure how this is overstating the case though. > > For some it refers to the subtle ways by which protocol design is > influenced by the values/interests/power dynamics between various folks > present in the IETF and to others it refers to capital R or D conversatio= ns > among politicians happening outside of the IETF, and yet to others its > definition lies somewhere in the middle of these two. > > > Again, some precision is called for. I think you are talking about the > politics of development of standards versus the political ramifications o= f > the results. > I think you might have misunderstood what I was trying to say here. I am not talking about the politics of development versus its effects. My statement was meant to be specific to the politics inherent to design processes, whether of legal or running code. I see this discussion as separate from the discussion about their potential political ramifications. > This relationship could be explored. For instance, I think those who > participated in webrtc would have found that development process somewhat > political, in terms of finding a way forward; but I would be hard pressed > to find political ramifications from the results, in as much as broader > society is impacted (again, my imagination may be limited). > I think some folks at netblocks might disagree with you here. But I will leave it to them to say so. > On the other hand, I could imagine the reverse, where the IETF > standardized something with little if any controversy that turned out to > have profound political ramifications. > > Asking Avri and you now with your co-chair hats, I think it would be > helpful to pause for a moment and just reflect on the issues the have bee= n > raised with regard to this work and how to structure discussion going > forward. > I think you might be confusing me with Mallory of ARTICLE19 - who is the second co-chair of HRPC. > For instance: is there agreement on the research question in the > document? If not, what is the point of considering anything else? Has > that question already been addressed elsewhere? If not, great. If so, > what is the contribution this work is intended to provide? > > As you ponder this, it may be that there are multiple points of view to b= e > heard. As an RG we have the possibility to publish differing perspective= s, > and this has happened in the past, most notably in the Routing RG when it > was active. > > Regards, > Cheers, CCS > > Eliot > --=20 Corinne Cath - Speth Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute Web: www.oii.ox.ac.uk/people/corinne-cath Email: ccath@turing.ac.uk & corinnecath@gmail.com Twitter: @C_CS --000000000000cb995a05934aa274 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI=C2=A0Eliot,

Some quick comments in-lin= e:=C2=A0

On Tue, Sep 24, 2019 at 1:49 PM Eliot Lear <lear@cisco.com> wrote:
Corinne,

Thanks.=C2=A0 Please see below.

=
On 23 Sep 2019, at 20:47, Co= rinne Cath <c= orinnecath@gmail.com> wrote:

Hi,

I think Step= hane Couture made an important point: it is important to locate consensus o= n the politics of protocols in its respective academic disciplines and lite= ratures, and have the document reflect that nuance.

Agree.

<= div dir=3D"ltr">

Furthermore, having followed thi= s discussion for a while now (about a year or four) I feel part of the cont= inued disagreement seems to stem from the fact that people have very differ= ent understandings of the word "political" and "politics=E2= =80=9D.

Although, at lea= st for me, characterizing that as disagreement is overstating the case, =C2= =A0I agree that providing clarity on the terms and the bounding of their me= aning would put any thesis and argumentation on better footing.
=

Great - not sure how this is overs= tating the case though.

For some it refers to the subtle ways by which protocol design is= influenced by the values/interests/power dynamics between various folks pr= esent in the IETF and to others it refers to capital R or D conversations a= mong politicians happening outside of the IETF, and yet to others its defin= ition lies somewhere in the middle of these two.=C2=A0

Again, some precision is called for.=C2=A0 I think= you are talking about the politics of development of standards versus the = political ramifications of the results.

I think you might have misunderstood what I was trying to say h= ere. I am not talking about the politics of development versus its effects.= My statement was meant to be specific to the politics inherent to design p= rocesses, whether of legal or running code. I see this discussion as separa= te from the discussion about their potential political ramifications.
=
=C2=A0This relationship could be explored.= =C2=A0 For instance, I think those who participated in webrtc would have fo= und that development process somewhat political, in terms of finding a way = forward; but I would be hard pressed to find political ramifications from t= he results, in as much as broader society is impacted (again, my imaginatio= n may be limited). =C2=A0

I think some folks at netblocks might disagree with you here. But I will = leave it to them to say so.

=C2=A0
I think you might be confusing me = with Mallory of ARTICLE19 - who is the second co-chair of HRPC.
=


For instance: is there = agreement on the research question in the document?=C2=A0 If not, what is t= he point of considering anything else?=C2=A0 Has that question already been= addressed elsewhere?=C2=A0 If not, great.=C2=A0 If so, what is the contrib= ution this work is intended to provide?

As you pon= der this, it may be that there are multiple points of view to be heard.=C2= =A0 As an RG we have the possibility to publish differing perspectives, and= this has happened in the past, most notably in the Routing RG when it was = active.

Regards,

=
Cheers,

CCS

Eliot


--
Corinne Cath - Speth
Ph.D. Candidate, Oxford Inter= net Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: ccath@turing.ac.uk &am= p; corinnecath@g= mail.com
Twitter: @C_CS
--000000000000cb995a05934aa274-- From nobody Tue Sep 24 04:44:47 2019 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 2F9EF120143 for ; Tue, 24 Sep 2019 04:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 09H29TzI5zH7 for ; Tue, 24 Sep 2019 04:44:44 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C59120108 for ; Tue, 24 Sep 2019 04:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3348; q=dns/txt; s=iport; t=1569325484; x=1570535084; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=FrFdwYx/K9xhW8KLPXKixGd6meI6n27Wdg/abyAg1cI=; b=QBhzL8D4n7p3m8i09yQwPjpjOa9oZ8qWHF15Dn5sL417XHib4xVwvATH JLSoOqdKk/AXMA4a+/aHzAyaVFxkjHBxrAhH1g2Mn5Dm9FyAdvvks6KQ3 Wx/5QWu1taZsubhHB890GW8RJjKEAZcqXCiSnhJbucV+7TCrNnzHhGmaM 8=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAD+AIpd/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBUwQBAQEBAQsBgRuCQjIqhCKIHGCHeiWHRIIjiTCGC4F?= =?us-ascii?q?7AgcBAQEJAwEBLwEBhD8Cg0Q0CQ4CAwkBAQQBAQECAQUEbYU5hUoBAQEBAgE?= =?us-ascii?q?jVgULCwQUKgICITYGE4MiAYFqAw4PrHBzgTKFTIJIDYIbEIE0AYFQilCBf4E?= =?us-ascii?q?RJwwTgkw+ghqFNTKCJgSWApZJQYIsgi6BE41IhAEUB41/iyaYNYtpgxECBAY?= =?us-ascii?q?FAhWBUjiBWDMaCBsVZQGCQT4SEBSQFT4DMI0zAQE?= X-IronPort-AV: E=Sophos;i="5.64,543,1559520000"; d="asc'?scan'208,217";a="17218248" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2019 11:44:42 +0000 Received: from [10.61.212.69] ([10.61.212.69]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8OBifSC029411 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Sep 2019 11:44:42 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_40ECEC9E-750D-426D-8875-E28B0B971D3E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Sep 2019 13:44:40 +0200 In-Reply-To: Cc: Hrpc , Niels ten Oever To: Corinne Cath References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net> <793367e8-7151-354e-04ca-b472760c6af7@nielstenoever.net> <01F67955-FA6C-4191-9D5D-A9E1AB61703C@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.212.69, [10.61.212.69] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [hrpc] Moving forward on draft-irtf-political X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 11:44:47 -0000 --Apple-Mail=_40ECEC9E-750D-426D-8875-E28B0B971D3E Content-Type: multipart/alternative; boundary="Apple-Mail=_54B23510-67E0-4A01-9016-8E13E6163EDC" --Apple-Mail=_54B23510-67E0-4A01-9016-8E13E6163EDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Sep 2019, at 13:13, Corinne Cath wrote: >=20 > I think you might be confusing me with Mallory of ARTICLE19 - who is = the second co-chair of HRPC. My apologies, you=E2=80=99re correct. Eliot --Apple-Mail=_54B23510-67E0-4A01-9016-8E13E6163EDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24 Sep 2019, at 13:13, Corinne Cath <corinnecath@gmail.com> wrote:


I think you might be = confusing me with Mallory of ARTICLE19 - who is the second co-chair of = HRPC.

My apologies, you=E2=80=99re correct.

Eliot

= --Apple-Mail=_54B23510-67E0-4A01-9016-8E13E6163EDC-- --Apple-Mail=_40ECEC9E-750D-426D-8875-E28B0B971D3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2KAagACgkQh7ZrRtnS ejNIsAf9EXdGSs0h98NAqepZfPLUzD3KODaYwfzIG5gm1Y2k7eqAgxrVvOnQ643b t73TxSg7ygjjetZRqYCbxZFZOM5Fuz49klMvqZvLCoekk+v8xVxkU0/bptyVLW2a Jq+jrn/aoC8cXCVMhvTdEP6izwrEyB1TFXMVs+jT9xRA3kYyaAe6WyUDR7E1pkiF 0OdNMBt8944vis5Qkpbss41Dn+KqOlx38oTJxq8mSJoqCEpeeCrRaiIKJwOzmySR y694rW5FRzeYGcw1p7aEF62h8VlxDAtDAkc0T1P9BunW0GRUmeXnUFcVGrToreOo cUydtg/Z+5SGScvXmCEv1e+02jYuDw== =pMMn -----END PGP SIGNATURE----- --Apple-Mail=_40ECEC9E-750D-426D-8875-E28B0B971D3E-- From nobody Thu Sep 26 00:20:07 2019 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 1A01E120816 for ; Thu, 26 Sep 2019 00:20:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_nGrZtJaQeL for ; Thu, 26 Sep 2019 00:20:04 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 04692120815 for ; Thu, 26 Sep 2019 00:20:03 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iDO3n-0007D4-51 for hrpc@irtf.org; Thu, 26 Sep 2019 09:20:01 +0200 To: hrpc@irtf.org From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= mQENBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAG0Jk1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QGFydGljbGUxOS5vcmc+iQFWBBMBCABAAhsD BwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AWIQTj62PgZaOyQLzZsHEMMqJxvTzHgAUCXH1h mgUJEepHrwAKCRAMMqJxvTzHgH3DCAC1sjJmg4+/VcESEzNkiF3KHEDCAssEaQl2FWfuXVvJ /mPliFtjpVv6EhdgUG5lbOcu12TCUWg42wHkE2kbDWXLE3f7HL+Nq0pEPVdMRXLxEfaOs2oR KGx8lh4k1UgYEpnARI486TklOAONKWdJKstEPrtt9LtysnjvhZvYCTzLKJC98c5wUvC46QYy +NdK6GB+uyVzW5kP2uUUBYxiCyHivGBbv77jcJAFVAk96ut1GFpeCCZM2WyYzer95b9n9a1B UGdJgEEVVbbBIQw7yMbMPqEwa8rpfig7QG72GieYItQjllHXGbOECiBcOHrGtrFWsHWxOxJV bZSoVq6sn1UUuQENBEx0TWcBCADiak/YuMW4BbaWL0U9sNg4zO3Qy1OFeye8fJjR8O/wWVSq cqA+sxjzRUee2fHCp6kVLedy6dVfiKmr59p21r4selOdslKaWmEGtz2oYnGpyPB/jKjfleE5 cIkXCdqgDAhfbfuVdF7heHpfhUy4m3yOJl2+CluT/CG9AfaCtyrwqMJzLWK4vmkGXxnBgb92 mGK0WFB2oRydz+SsiobgpCAqJSLcr8ZHQ54SbD9yxxYPv8IsSjt4eJoZCFI7INBsz4i7aj/q 4xcxQ+xiUwyqCZUvrzMxpw7c8TXuPHStDyhnsKkFjxhlY5avNeu0VPwk72C64I+y93gpPrL3 vL0tEmU9ABEBAAGJATwEGAECACYCGwwWIQTj62PgZaOyQLzZsHEMMqJxvTzHgAUCXH1hmgUJ EepHswAKCRAMMqJxvTzHgEDZCACcTamfNdBACpPHsmsJL1hbWertwYZg7h2rZtgmZQ9C2PMT OgkPPSsfi+xZ6PaXlvm2RI/TX51LbJsCJ9Fd2/WxKdtC0s6o7+0Cl3P57AORf3BRfl3zfXuy VhzjLvM9WhDiQM6JBqDuYxiYnjO56l+gozEuBAtUJaPIxGyggyS5eT8kKv8Szpc4g7/skZXq ccVOHj05KCOaFQ774rsIzcwppqJqGjh9X6nX6m2DONuBIYNXjH9U6FxHSJ6gRRxZkiz2/dDZ YqsHYlkKigH82r9gORhIGZkCd7xnRhyLOHnjjeKtIy5pvGwxUohy+y5l8i1155JEPNB7pphY xFxjMOQU Message-ID: <32a13ebb-96b5-41d0-ab11-7765d6416dbb@article19.org> Date: Thu, 26 Sep 2019 10:19:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 1fac81774939798d1cdb19633eb460de Archived-At: Subject: [hrpc] Call for presentations at IETF 106 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 07:20:06 -0000 Hi all, Please if you would like to speak or have ideas for speakers at the Singapore meeting, or Vancouver, please reach out. For Singapore, we are inviting Jed Crandall from ASU to give a talk: Title: Borders and Gateways: Measuring and Analyzing National AS Chokepoints Internet topology reflects economic and political constraints that change over time. National boundaries are natural points of control for surveillance, censorship, tariffs and data localization. I'll present a measure, national chokepoint potential (NCP), that my collaborators and I proposed to characterize how a country's AS topology is organized in terms of BGP paths that can carry traffic across international borders. We developed an open source tool to calculate this measure, and applied it to tracking AS topology changes over a ten year span. We found interesting per-country trends, which I'll discuss, as well as an overall trend on the Internet of increasing NCP. When compared to independent measures of Internet freedom, we find statistically significant relationships between NCP and Internet freedom. The talk is based on the following paper: https://forrest.biodesign.asu.edu/data/publications/2019-compass-chokepoints.pdf Kirtus G. Leyba, Benjamin Edwards, Cynthia Freeman, Jedidiah R. Crandall, and Stephanie Forrest. Borders and Gateways: Measuring and Analyzing National AS Chokepoints. To appear in the Proceedings of the second annual ACM SIGCAS Conference on Computing and Sustainable Societies (COMPASS 2019). Accra, Ghana. July 2019. Jedidiah R. Crandall is a Professor in the Department of Computer Science at the University of New Mexico, and will join Arizona State University's Biodesign Center for Biocomputation, Security and Society in June, 2020. Prof. Crandall's research interests are in applications of Internet measurement, reverse engineering, and digital forensics to Internet freedom. Some of his other research includes assessing side channels and other weaknesses in core TCP/IP protocols and implementations, which can lead to threats to at-risk users (e.g., activists and journalists) who rely on tools such as VPNs. -- Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Sat Sep 28 06:01:50 2019 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 8E05F12011E; Sat, 28 Sep 2019 06:01:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hrpc@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.103.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hrpc@irtf.org Message-ID: <156967570845.7150.9935817232000748626@ietfa.amsl.com> Date: Sat, 28 Sep 2019 06:01:48 -0700 Archived-At: Subject: [hrpc] I-D Action: draft-irtf-hrpc-political-07.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2019 13:01:49 -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 RG of the IRTF. Title : Notes on networking standards and politics Author : Niels ten Oever Filename : draft-irtf-hrpc-political-07.txt Pages : 14 Date : 2019-09-28 Abstract: The IETF cannot ordain what standards or protocols are to be used on networks, but the standards development process in the IETF does have an impact on society through its normative standards setting process. This document aims to bring about a better understanding on the political nature of standards and protocols. Among other things, the IETF's work affects what is perceived as technologically possible and useful where networking technologies are being deployed, and its standards reflect what is considered by the technical community to be feasible and good practice. Whereas there might not be agreement among the Internet protocol community on the specific political nature of the technological development process and its outputs, it is generally agreed that standards and protocols are both products of a political process, and they can also be used for political means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-hrpc-political-07 https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-07 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 Sat Sep 28 06:05:57 2019 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 4A22D12011E for ; Sat, 28 Sep 2019 06:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3OF0T0Otp08 for ; Sat, 28 Sep 2019 06:05:54 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 1BA18120115 for ; Sat, 28 Sep 2019 06:05:54 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iECQ3-0003e7-6N for hrpc@irtf.org; Sat, 28 Sep 2019 15:05:52 +0200 To: "hrpc@irtf.org" References: <156967570845.7150.9935817232000748626@ietfa.amsl.com> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <817a0e52-19ed-0e5d-d298-d60221fc3827@nielstenoever.net> Date: Sat, 28 Sep 2019 15:05:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <156967570845.7150.9935817232000748626@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4868b52b90b9144be14ceb212c82ef23 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-07.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2019 13:05:56 -0000 Hi all, Change log: - further qualified the conclusion and the discussion to reflect the differences in opinion, - integrated the suggestions made by Stephane. Hope this helps! Best, Niels On 9/28/19 3:01 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Human Rights Protocol Considerations RG of the IRTF. > > Title : Notes on networking standards and politics > Author : Niels ten Oever > Filename : draft-irtf-hrpc-political-07.txt > Pages : 14 > Date : 2019-09-28 > > Abstract: > The IETF cannot ordain what standards or protocols are to be used on > networks, but the standards development process in the IETF does have > an impact on society through its normative standards setting process. > This document aims to bring about a better understanding on the > political nature of standards and protocols. Among other things, the > IETF's work affects what is perceived as technologically possible and > useful where networking technologies are being deployed, and its > standards reflect what is considered by the technical community to be > feasible and good practice. Whereas there might not be agreement > among the Internet protocol community on the specific political > nature of the technological development process and its outputs, it > is generally agreed that standards and protocols are both products of > a political process, and they can also be used for political means. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-hrpc-political-07 > https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Sat Sep 28 14:09:46 2019 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 7F7A01200A3 for ; Sat, 28 Sep 2019 14:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9olx10m4ZHn for ; Sat, 28 Sep 2019 14:09:43 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29709120019 for ; Sat, 28 Sep 2019 14:09:43 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id w6so4328767lfl.2 for ; Sat, 28 Sep 2019 14:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SY7k94T8bXFyu6bTXJXUfqluF9ypLRM1w2AdOWYOWDc=; b=guuRBb39PW+z9eL3oUgWy/CJVOxMQfAnzB+4DXL2ZVY1l0uugvKlsjW/pT4QeKFI4I qE+PIjwpOp8A9BXEsspQNJrhd3S+MtglRxTIw4i1aILpE2ptXNFB8H0qKPt6AoGIU8or yXRiEY42Zty5hnBhr8uXENYBdZVGiQLEjJyIzItXeUYw1S6015Kmgmd+QaNMOz77rKwn AyiGem6WRl4nKBFDkK3ngBIdqMV1EXZT92qKP1wAscz4ZJwcpm2JqZ9uVE8vNjvlqsG2 b4UeJmjCrsEo/4v9VT9ptKsFw7nti82n9RA7bSSEMFAM0TJXRVz6YWgMQi8nhA+wP9c5 6UYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SY7k94T8bXFyu6bTXJXUfqluF9ypLRM1w2AdOWYOWDc=; b=oeKnAcm8gKlojO+u1vwKaaJRHC530s83PuVfVAR09qv6ldLpJEV5H/7i4R/QmZxYpT jJaieMsJKcA0+1jtP3vPmsmJwgkyvspQUMyncTRjTHRPraFLIFYcGKuG3UQOsd8Ltvpz VVN2aadTerlzEvWwB5U2hatTBsghzp0fSQg5Uzg27jlSlbSwBy/ijyXhCawdKO7O6qu7 uEdm0GNlAeIPRUBTy7PAsreD8JgGg1W31bWsXeK2yE/uAXNYylZwfSbkNJEVSadPES0W yg1CAa/5wvY4zj9al6jOHmqGch8HT6nBwOz7fPZekyEgmRJHhW08yTMkzjxR+rSVmkL/ 3O0A== X-Gm-Message-State: APjAAAUPDvT4nYXG8eWL6f3K2eeNYlaMETBKdJSNHA9bGpJ1y9EtKeUw 66AAz8Iaouaejwf8xx4lnXck8Rlfrex7yhCKtu01vq9/ X-Google-Smtp-Source: APXvYqyutp+/2gUSmkz4pGKMKiaCWlCYSka6xb+uT5yaNmZ+jcNJzU2zlsB54Y+/Mo6CmR63iFb7lo+oeaLhVAGRsWY= X-Received: by 2002:ac2:5a19:: with SMTP id q25mr6822103lfn.178.1569704981280; Sat, 28 Sep 2019 14:09:41 -0700 (PDT) MIME-Version: 1.0 References: <156967570845.7150.9935817232000748626@ietfa.amsl.com> <817a0e52-19ed-0e5d-d298-d60221fc3827@nielstenoever.net> In-Reply-To: <817a0e52-19ed-0e5d-d298-d60221fc3827@nielstenoever.net> From: Eric Rescorla Date: Sat, 28 Sep 2019 14:09:05 -0700 Message-ID: To: Niels ten Oever Cc: "hrpc@irtf.org" Content-Type: multipart/alternative; boundary="000000000000cfca2d0593a36b56" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-07.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2019 21:09:46 -0000 --000000000000cfca2d0593a36b56 Content-Type: text/plain; charset="UTF-8" Niels, Thanks for posting this. I don't however, think that it addresses my primary concerns. It seems to me that the major change is that you now make explicit claims about the consensus of Science and Technology scholars and then some softer set of claims about what the IETF thinks. Neither of these claims of consensus seems to be supported by any real evidence, however, and reading S 4, it seems like that describes some perspectives that don't match the claims of general agreement in S 1. It seems to me that this document has fallen into the not uncommon situation where people object that fundamental changes are needed but instead you try to make minor textual changes in order to address some specific comments. ISTM that what's needed here is to go back to the beginning and state what the intended purpose of this document is and then we can discuss whether (1) that is a useful purpose and (2) whether it achieves it. Until then, I don';t think new revisions or textual changes are helpful. -Ekr -Ekr On Sat, Sep 28, 2019 at 6:06 AM Niels ten Oever wrote: > Hi all, > > Change log: > > - further qualified the conclusion and the discussion to reflect the > differences in opinion, > - integrated the suggestions made by Stephane. > > Hope this helps! > > Best, > > Niels > > On 9/28/19 3:01 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Human Rights Protocol Considerations RG > of the IRTF. > > > > Title : Notes on networking standards and politics > > Author : Niels ten Oever > > Filename : draft-irtf-hrpc-political-07.txt > > Pages : 14 > > Date : 2019-09-28 > > > > Abstract: > > The IETF cannot ordain what standards or protocols are to be used on > > networks, but the standards development process in the IETF does have > > an impact on society through its normative standards setting process. > > This document aims to bring about a better understanding on the > > political nature of standards and protocols. Among other things, the > > IETF's work affects what is perceived as technologically possible and > > useful where networking technologies are being deployed, and its > > standards reflect what is considered by the technical community to be > > feasible and good practice. Whereas there might not be agreement > > among the Internet protocol community on the specific political > > nature of the technological development process and its outputs, it > > is generally agreed that standards and protocols are both products of > > a political process, and they can also be used for political means. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-irtf-hrpc-political-07 > > https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-07 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-07 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > -- > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000cfca2d0593a36b56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Niels,

Thanks for posting th= is.

I don't however, think that it addresses m= y primary concerns. It seems to me that the major change is that you now ma= ke explicit claims about the consensus of Science and Technology scholars a= nd then some softer set of claims about what the IETF thinks. Neither of th= ese claims of consensus seems to be supported by any real evidence, however= , and reading S 4, it seems like that describes some perspectives that don&= #39;t match the claims of general agreement in S 1.

It seems to me that this document has fallen into the not uncommon situat= ion where people object that fundamental changes are needed but instead you= try to make minor textual changes in order to address some specific commen= ts. ISTM that what's needed here is to go back to the beginning and sta= te what the intended purpose of this document is and then we can discuss wh= ether (1) that is a useful purpose and (2) whether it achieves it. Until th= en, I don';t think new revisions or textual changes are helpful.

-Ekr


-Ekr


On Sat, Sep 28, 2019 at 6:06 AM Niels ten Oever <mail@nielstenoever.net> wrote:<= br>
Hi all,

Change log:

- further qualified the conclusion and the discussion to reflect the differ= ences in opinion,
- integrated the suggestions made by Stephane.

Hope this helps!

Best,

Niels

On 9/28/19 3:01 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Human Rights Protocol Considerations = RG of the IRTF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Notes on networking standards and politics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Niels ten Oever
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= irtf-hrpc-political-07.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 14
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-09-28
>
> Abstract:
>=C2=A0 =C2=A0 The IETF cannot ordain what standards or protocols are to= be used on
>=C2=A0 =C2=A0 networks, but the standards development process in the IE= TF does have
>=C2=A0 =C2=A0 an impact on society through its normative standards sett= ing process.
>=C2=A0 =C2=A0 This document aims to bring about a better understanding = on the
>=C2=A0 =C2=A0 political nature of standards and protocols.=C2=A0 Among = other things, the
>=C2=A0 =C2=A0 IETF's work affects what is perceived as technologica= lly possible and
>=C2=A0 =C2=A0 useful where networking technologies are being deployed, = and its
>=C2=A0 =C2=A0 standards reflect what is considered by the technical com= munity to be
>=C2=A0 =C2=A0 feasible and good practice.=C2=A0 Whereas there might not= be agreement
>=C2=A0 =C2=A0 among the Internet protocol community on the specific pol= itical
>=C2=A0 =C2=A0 nature of the technological development process and its o= utputs, it
>=C2=A0 =C2=A0 is generally agreed that standards and protocols are both= products of
>=C2=A0 =C2=A0 a political process, and they can also be used for politi= cal means.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dra= ft-irtf-hrpc-political/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-= hrpc-political-07
> https://datatracker.ietf.org/= doc/html/draft-irtf-hrpc-political-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-irtf-hrpc-political-07
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc
>

--
Niels ten Oever
Researcher and PhD Candidate
DATACTIVE Research Group
University of Amsterdam

PGP fingerprint=C2=A0 =C2=A0 2458 0B70 5C4A FD8A 9488=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0643A 0= ED8 3F3A 468A C8B3

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000cfca2d0593a36b56-- From nobody Sat Sep 28 15:48:15 2019 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 5C0701200B2 for ; Sat, 28 Sep 2019 15:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsLedLHu54HV for ; Sat, 28 Sep 2019 15:48:10 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 E5EB312009E for ; Sat, 28 Sep 2019 15:48:09 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iELVU-0007UX-QH; Sun, 29 Sep 2019 00:48:05 +0200 To: Eric Rescorla Cc: "hrpc@irtf.org" References: <156967570845.7150.9935817232000748626@ietfa.amsl.com> <817a0e52-19ed-0e5d-d298-d60221fc3827@nielstenoever.net> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <22b9b397-75e3-0f9e-5d6e-af78a737259e@nielstenoever.net> Date: Sun, 29 Sep 2019 00:48:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 05f4b5ff5716d86a3de6e4c92c1b0ccd Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-07.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2019 22:48:14 -0000 Dear Eric, On 9/28/19 11:09 PM, Eric Rescorla wrote: > Niels, > > Thanks for posting this. > > I don't however, think that it addresses my primary concerns. It seems to me that the major change is that you now make explicit claims about the consensus of Science and Technology scholars and then some softer set of claims about what the IETF thinks. Exactly, this follows my discussion with you and Eliot in which you both mentioned that these conclusions seemed obvious. > Neither of these claims of consensus seems to be supported by any real evidence, I think we have different ideas of what constitutes evidence. This work resulted, as stated in the doc, from participant observation, interviews and exchanges on mailinglist and during research group sessions. The work is further structured by contextualizing it with a the literature review. You don't seem to appreciate this, or see this as valid research methods, which is fine of course, but then it will be hard for us to agree. Furthermore, it is also not stated that this documents provides evidence. But again, if you want to give an historical account to illustrate a specific point, I would be more than happy to integrate it into the document. > however, and reading S 4, it seems like that describes some perspectives that don't match the claims of general agreement in S 1. I agree that abstract and the intro should be made more consistent with the discussion and conclusion. If we can agree on the latter, I will be more than happy to do that. Best, Niels > > It seems to me that this document has fallen into the not uncommon situation where people object that fundamental changes are needed but instead you try to make minor textual changes in order to address some specific comments. ISTM that what's needed here is to go back to the beginning and state what the intended purpose of this document is and then we can discuss whether (1) that is a useful purpose and (2) whether it achieves it. Until then, I don';t think new revisions or textual changes are helpful. > > -Ekr > > > -Ekr > > > On Sat, Sep 28, 2019 at 6:06 AM Niels ten Oever > wrote: > > Hi all, > > Change log: > > - further qualified the conclusion and the discussion to reflect the differences in opinion, > - integrated the suggestions made by Stephane. > > Hope this helps! > > Best, > > Niels > > On 9/28/19 3:01 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Human Rights Protocol Considerations RG of the IRTF. > > > >         Title           : Notes on networking standards and politics > >         Author          : Niels ten Oever > >       Filename        : draft-irtf-hrpc-political-07.txt > >       Pages           : 14 > >       Date            : 2019-09-28 > > > > Abstract: > >    The IETF cannot ordain what standards or protocols are to be used on > >    networks, but the standards development process in the IETF does have > >    an impact on society through its normative standards setting process. > >    This document aims to bring about a better understanding on the > >    political nature of standards and protocols.  Among other things, the > >    IETF's work affects what is perceived as technologically possible and > >    useful where networking technologies are being deployed, and its > >    standards reflect what is considered by the technical community to be > >    feasible and good practice.  Whereas there might not be agreement > >    among the Internet protocol community on the specific political > >    nature of the technological development process and its outputs, it > >    is generally agreed that standards and protocols are both products of > >    a political process, and they can also be used for political means. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-irtf-hrpc-political-07 > > https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-07 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-07 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org . > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > -- > Niels ten Oever > Researcher and PhD Candidate > DATACTIVE Research Group > University of Amsterdam > > PGP fingerprint    2458 0B70 5C4A FD8A 9488  >                    643A 0ED8 3F3A 468A C8B3 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Sat Sep 28 16:20:25 2019 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 A1F8A1200F9 for ; Sat, 28 Sep 2019 16:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKefHRDsg0b5 for ; Sat, 28 Sep 2019 16:20:22 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268311200C3 for ; Sat, 28 Sep 2019 16:20:22 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id n14so5799438ljj.10 for ; Sat, 28 Sep 2019 16:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9FaJ5kaUywiF7JpOJZH4XZgqOx92ZGgh4bmsGPR5MAg=; b=NcPWV8w/Vkid9M/aFqyhZ6gko7FkteVrq/Xxp80QCsXaoCA+yNi3C+inIxxVNLPRyA 3mZV36TBMimA2EjyDavO/d8Qylz2/PyElu5nifxNfogIUAUdceM+FYRp8mdVh5ukhcoG lnlXlYJW4R3SANdxS70z69+aEL8nxCXAg67LPKPcoThPy0H0tyCF8KuBLmIVTPkgMKAG rwwDnsggPSJUSzcRddSxd2BX6ZdtsqxZGShKg54+0kbsHLntL/75/syPfruoKbMB3iF4 EU970S8/N7BFDw5CN9QCsqRr3nLyg0akxmIHHlQZIRcjw5MmxiWPfdGEfNHBHbzqUXZp Diuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9FaJ5kaUywiF7JpOJZH4XZgqOx92ZGgh4bmsGPR5MAg=; b=TT4Ejdz1J+ElWtIiUPGyvZKzv/X49CGu5YtwMKbidtYEaKfrUw+tz+UZfdFpZv1J13 XKUxhn/XPX1v7hzDWXj8t9aqPIiq+Drvqf/o78meea7OOZEKNjDaM7U7v3UZEfz6S0o6 MAD24CrO/BrbD+T9Pv7e3vQKwwQSQMfqopd+PiidxMxh7OMf3S3lZ610+0EONyhVbRGr WhTjYC6vAq7wLuu92sdWGpCQyLLuabAidar4MHFWvtaIy7HWAxWamHh414gDjfb4hMug Nwz7dhh9hDzBqsW/UQyvv1RlMWPJWNe/fQwAuGT9O8z8KpAjN0SSseeIMR8fWT3V25ia rC0w== X-Gm-Message-State: APjAAAWha/heD17I1+F8VnHPyYPb89vDjGcH73NlBGPLNZzt+vD1enOV ITmlRgij8mS/db+HEcNY2/j5tDufEtT8n2eB9PjdXNLO X-Google-Smtp-Source: APXvYqz0713c8QLlTamvTIeaM0f5IUz+D2aBsmfrNAwbX9yFHvFaZK2S0b29g+8rPx84t9aEK0HYYqkp5JMi/g5gUf8= X-Received: by 2002:a2e:878b:: with SMTP id n11mr7503597lji.13.1569712820288; Sat, 28 Sep 2019 16:20:20 -0700 (PDT) MIME-Version: 1.0 References: <156967570845.7150.9935817232000748626@ietfa.amsl.com> <817a0e52-19ed-0e5d-d298-d60221fc3827@nielstenoever.net> <22b9b397-75e3-0f9e-5d6e-af78a737259e@nielstenoever.net> In-Reply-To: <22b9b397-75e3-0f9e-5d6e-af78a737259e@nielstenoever.net> From: Eric Rescorla Date: Sat, 28 Sep 2019 16:19:43 -0700 Message-ID: To: Niels ten Oever Cc: "hrpc@irtf.org" Content-Type: multipart/alternative; boundary="0000000000000d96190593a53f5d" Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-07.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2019 23:20:25 -0000 --0000000000000d96190593a53f5d Content-Type: text/plain; charset="UTF-8" First, let me say that I think that this discussion of consensus is a distraction. The fundamental problem with this document is that it's not clear why it exists at all. That is what needs to be resolved. With that said, my specific objection to this new text is the claims of what is consensus in the STS community or in the IETF, because this document doesn't present any evidence that would suffice to support a claim of "consensus" or "general agreement". More detailed response below: On Sat, Sep 28, 2019 at 3:48 PM Niels ten Oever wrote: > Dear Eric, > > On 9/28/19 11:09 PM, Eric Rescorla wrote: > > Niels, > > > > Thanks for posting this. > > > > I don't however, think that it addresses my primary concerns. It seems > to me that the major change is that you now make explicit claims about the > consensus of Science and Technology scholars and then some softer set of > claims about what the IETF thinks. > > Exactly, this follows my discussion with you and Eliot in which you both > mentioned that these conclusions seemed obvious. > I agree that they are obvious, but what does that have to do with consensus or lack thereof? > Neither of these claims of consensus seems to be supported by any real > evidence, > > I think we have different ideas of what constitutes evidence. This work > resulted, as stated in the doc, from participant observation, interviews > and exchanges on mailinglist and during research group sessions. The work > is further structured by contextualizing it with a the literature review. > You don't seem to appreciate this, or see this as valid research methods, > which is fine of course, but then it will be hard for us to agree. > You seem to be putting words in my mouth here because I never said anything about not seeing this as valid research methods. Consensus and general agreement are properties of a group and particular of some large fraction of a group holding a particular opinion. I don't see you presenting any evidence along those lines at all. Note that it's not impossible to do this (see, for instance surveys of the scientific or economic community on specific points, or large-scale literature reviews that count up the papers with a certain view). However, this document does not seem to contain any of that. > Furthermore, it is also not stated that this documents provides evidence. Well, then it shouldn't make claims like this. -Ekr --0000000000000d96190593a53f5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
First, let me say that I think that this discussion o= f consensus is a distraction. The fundamental problem with this document is= that it's not clear why it exists at all. That is what needs to be res= olved.

With that said, my specific objection to th= is new text is the claims of what is consensus in the STS community or in t= he IETF, because this document doesn't present any evidence that would = suffice to support a claim of "consensus" or "general agreem= ent".

More detailed response below:


On Sat, Sep 28, 2019 at 3:48 PM Niels ten Oever <mail@nielstenoever.net> wrote:
Dear Eric,

On 9/28/19 11:09 PM, Eric Rescorla wrote:
> Niels,
>
> Thanks for posting this.
>
> I don't however, think that it addresses my primary concerns. It s= eems to me that the major change is that you now make explicit claims about= the consensus of Science and Technology scholars and then some softer set = of claims about what the IETF thinks.

Exactly, this follows my discussion with you and Eliot in which you both me= ntioned that these conclusions seemed obvious.

I agree that they are obvious, but what does that have to do with = consensus or lack thereof?


> Neither of these claims of consensus seems to be supported by any real= evidence,

I think we have different ideas of what constitutes evidence. This work res= ulted, as stated in the doc, from participant observation, interviews and e= xchanges on mailinglist and during research group sessions.=C2=A0 The work = is further structured by contextualizing it with a the literature review. Y= ou don't seem to appreciate this, or see this as valid research methods= , which is fine of course, but then it will be hard for us to agree.

You seem to be putting words in my mouth here= because I never said anything about not seeing this as valid research meth= ods.

Consensus and general agreement are propertie= s of a group and particular of some large fraction of a group holding a par= ticular opinion. I don't see you presenting any evidence along those li= nes at all. Note that it's not impossible to do this (see, for instance= surveys of the scientific or economic community on specific points, or lar= ge-scale literature reviews that count up the papers with a certain view). = However, this document does not seem to contain any of that.

=
=C2=A0
Furthermore, it is also not stated that this documents provides evidence.

Well, then it shouldn't make claims like= this.

-Ekr

<= /div> --0000000000000d96190593a53f5d--