From nobody Fri Jun 7 01:30:32 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 F00AC120136; Fri, 7 Jun 2019 01:30:30 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hrpc@irtf.org Message-ID: <155989623088.20255.12181969220178709616@ietfa.amsl.com> Date: Fri, 07 Jun 2019 01:30:30 -0700 Archived-At: Subject: [hrpc] I-D Action: draft-irtf-hrpc-guidelines-03.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, 07 Jun 2019 08:30:31 -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 : Guidelines for Human Rights Protocol and Architecture Considerations Authors : University of Amsterdam Gurshabad Grover Filename : draft-irtf-hrpc-guidelines-03.txt Pages : 28 Date : 2019-06-07 Abstract: This document sets guidelines for human rights considerations in networking protocols, similar to the work done on the guidelines for privacy considerations [RFC6973]. This is an updated version of the guidelines for human rights considerations in [RFC8280]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-hrpc-guidelines/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-03 https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-guidelines-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-guidelines-03 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 Jun 7 01:48: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 9C8D112001A for ; Fri, 7 Jun 2019 01:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 F1_EfQ0EXKzg for ; Fri, 7 Jun 2019 01:48: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 DBEED12010D for ; Fri, 7 Jun 2019 01:48:18 -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 1hZAXJ-0003a8-QO; Fri, 07 Jun 2019 10:48:16 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org 45CDF5813CBCA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1559897196; bh=+mAEwRhtKI9o6W+Rd8z7Xx4lwoul2VP9JFE/vsY564k=; h=From:To:Message-ID:Date:MIME-Version; b=QcRuj1mWQiI0FNpk5bsalf9P0dypQYkgukdHV3RsXwpCuDvRZvq/nsFCF6a+6xVKH QjRXS9B9QSjdRsUp+8gmYgwbZGZQMHJyMfcSaok1Wf84kRIjZyxDY0kSNs0HyXBSc1 qsSOzBx/97K8yN/oQXpXqc11YdIw7iJ1JiVN+bwW8v9iij+vUcr1L0Uuc6YKrLT2Ec KmCRT/a7MkPvb35YI3RnLNSxQK6QYjAgGxNYXUI5mqBubZacQRqwfis43axRQX5u/N gul2RCV7ftte+yugelu1LVqAUETIqqXms1ft6bI6mpXLZSe8ceoidzsO58mGJd0wre NBR0tsjgc7QAQ== From: Gurshabad Grover To: Joseph Lorenzo Hall Cc: Hrpc References: <155230481684.16918.12310340882529699964@ietfa.amsl.com> 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: <37d57588-1ed1-6001-8df4-c83b25d95a7a@cis-india.org> Date: Fri, 7 Jun 2019 14:17:42 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: 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: 27c1264e312f7e45ec0349526d776c80 Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-guidelines-02.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, 07 Jun 2019 08:48:21 -0000 Thanks a lot for the review! I think the new version incorporates all the suggestions. If you'd like to track something specific, please find in-line comments below. On 28/03/19 1:15 PM, Joseph Lorenzo Hall wrote: > o > 3.2: "Currently three five methods" Fixed. > o > 3.2.2, could be clearer: "seeking to understand how it might > provide a different ordering of the network or society." Rephrased to "When reviewing an Internet-Draft, specific human rights impacts might become apparent by doing a close reading of the draft and seeking to understand how it might affect networks or society." > o > 3.3.5, internet doesn't want anything: "If the Internet wants to > be a global network of networks, the protocols should work with > languages apart from English and character sets apart from Latin > characters." Changed to "If IETF wants the Internet to be a global network of networks" > o > 3.3.6, double reference: "[RFC4941] This is why Privacy > Extensions for Stateless Address Autoconfiguration in IPv6 have > been introduced. [RFC4941]" Removed the first instance of the reference. > o > 3.3.6, I would reorder those questions Done, hope it reads better now. > o > 3.3.8, the example seems unfinished? That particular line is from RFC1958. It does feel a bit awkward. Not sure what the original intent was in RFC1958, but have changed it to "most complex such as commit protocols for distributed databases." Hope that works. > o > 3.3.10, talks about "the internet" like "hip hop" (throughout > the document, but especially apparent here) Fixed by rephrasing to "The Internet should be designed [...]" > o > 3.3.14, is this referring to encrypted intermediate storage? "or > the implementation uses an encrypted store" Seems like it. This particular line is from RFC7624. > o > 3.3.15, how is the difference here between accuracy and > consistency being thought out? Does consistency have a > temporal/stateful aspect? "Does your protocol maintain, assure > and/or verify the accuracy of payload data? Does your protocol > maintain and assure the consistency of data?" Removed the second question; changed to "integrity" in each instance. > o > 3.3.15, the MITM description should probably be improved and > bulleted? Should it hint at inactive MITM and should we call it > something other than "man"? Right, thanks. Changed it to "on-path attacker" as draft-knodel-terminology-01 suggests. > o > 3.3.16, "man-in-the-middle-attacks" -> "man-in-the-middle > attacks" Removed that phrase. > o > 3.3.16, "Bob can see the data did not come from Alice but from > Corinne." remove "but by Corinne" as that may not be true. Fixed. > o > 3.3.16, what about non-authenticity or knowing when to not ask > for evidence of authenticity? E.g., attestation of hardware > security devices like yubikeys may lock out people who use a > different brand (Vanguard or Fidelity does this now). Good point. Have added this to the Explanation: "At the same time, authentication should not be used as a way to prevent heterogeneity support, as is often done for vendor lock-in or digital rights management." Please let me know if you would like any changes here, or know papers/documents that act as good references to read about this problem (great if in the IETF context). > o > 3.3.18, impacts bullet list broken Fixed. > o > 3.3.19, typo "Does you protocol" Fixed. > o > 5, looks like this should be a bullet list? > Fixed. Thank you. -GG. From nobody Fri Jun 7 01:52: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 47F4412010D for ; Fri, 7 Jun 2019 01:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 qUc5N1dugR21 for ; Fri, 7 Jun 2019 01:52:56 -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 ECB63120100 for ; Fri, 7 Jun 2019 01:52:55 -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 1hZAbm-0004sV-PJ; Fri, 07 Jun 2019 10:52:53 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org A0FFE5813CBCA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1559897472; bh=oWVOmxLtyETRN76YDkiS68VYP2sOWHNcfjUo4hIolOM=; h=From:To:Message-ID:Date:MIME-Version; b=Ea/F+39jfePFDRZ9kD/Bhz4Vl1Ue1rEG6oNildBdIlVn1hP8n64euHUU7Px8Q7pXF A1aioWUk3ZKDwmn+mVTsl8TRslbSLNzT+PaH1FfFpBF+eZwiH5OH3iRzpX7Xf6+XNa 8nf3rDr0QMxh7/SU6ddUAHwa5Tv1X+8r+J7pTCLXohLNqiFKjQXickZUBlSBevvJkB KulWwOJsGkxg5GJDB+KwJz6bA/bpzQuPz+eZLUYtCHmGdgHv+HRp7wwULy4naA8Zxa hS/g1g59P808vsR9mIFOar488/sEO0kKYHPz0nBrQ11J3QPABBsMdRqdDBdbVaMxQE W45AWA/B7SF9g== From: Gurshabad Grover To: Avri , Hrpc References: <5953ec1b-990a-457f-bc12-1c3fe159304a@avris-iPad> 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: Date: Fri, 7 Jun 2019 14:22:20 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5953ec1b-990a-457f-bc12-1c3fe159304a@avris-iPad> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4a4e1dd80dce9ac0d9378b25a0c059e8 Archived-At: Subject: Re: [hrpc] Draft-HRPC-guidelines 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, 07 Jun 2019 08:52:57 -0000 Thanks a lot for the review! The new version incorporates some suggestions. Please find specific changes/comments below. On 28/03/19 3:33 PM, Avri wrote: > - I think that perhaps in the abstract or the intro, it should mention > that these are considerations are still under test. =A0You indicate tha= t > they are being still being developed but not that they still need test > for usefulness and validity. This is an activity I think we still need > to develop a methodology for - some rigorous manner of testing and > documenting the testing. Added to the introduction: "The methods for conducting human rights reviews (Section 3.2), and guidelines for human rights considerations (Section 3.3) in this document are being tested for relevance, accuracy and validity." I agree that we still need to develop a method to evaluate the usefulness of these guidelines. Open to suggestion on a more formal method to do that (currently, we rely on feedback from individuals writing HR reviews/considerations sections). > - in 3.2.1 & 3.2.2 It seems to indicate that the considerations are not > useful for doing an impact analaysis. =A0I think that when done in a la= st > call review, they do contribute to doing an impact analysis. I think > that might be a use we need to verify and test for, but I think it migh= t > be worth mentioning. =A0Though one distinction probably worth making is > that use of the considerations while the protocol is in development is = a > process best done by those involved in the protocol development itself, > while an impact analysis done as part of a last call is probably best > done by an external observer. =A0So while I think it should be possible= to > use the same considerations in both processes, the way it is done and b= y > whom probably varies. >=20 [discussed off-list, no changes made right now] > - in 3.3 you mention that we do not discuss the issue of whether a HR > considerations section should be added. =A0I do not think that is an IR= TF > task. We should be be developing the considerations and testing them fo= r > their use and reasonableness. =A0Any proposal to make them part of an I= ETF > process should probably be left to some future IETF process. =A0One of = the > things we have had an issue with, and some pointed comments on, is > crossing into the actual IETF engineering process. >=20 Removed "the addition of a human rights considerations section has also not yet been proposed." > - in 3.3.x, I think it would be good to point to where the HR that are > impacted by by the consideration are discussed and explained. =A0I know > this may creates cross references to work that is not yet done, but it > seems to just be left unexplained in the current draft. =A0I think that= if > the doc says a consideration is useful for, e.g., for the right of > political participation or for participation in cultural life ... we > should explain why somewhere - not in this doc but in a doc specificall= y > related to the right and considerations pertinent to that right. Also > might be worth listing the UDHR =A0and para reference for each so that > they can be looked up by readers. >=20 While the new version doesn't contain any edits to this effect, we will spend some time thinking about how this can be done here or in other documents. Thank you. -GG. From nobody Fri Jun 7 02:11: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 AE8DA12010D for ; Fri, 7 Jun 2019 02:11:12 -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, 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 7KkD4x-nRMKu for ; Fri, 7 Jun 2019 02:11: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 7426412000E for ; Fri, 7 Jun 2019 02:11: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 1hZAtQ-0000Qh-NE for hrpc@irtf.org; Fri, 07 Jun 2019 11:11:08 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org CED0B5813CBCA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1559898566; bh=UjNuk3nxjcNEhy/enFTc+3I+0b74cWDlP3t2vSVJ9ck=; h=To:From:Message-ID:Date:MIME-Version; b=bqIeB8i3hJWQWGqbs0N+svFL4vURPKccS63kNkx85I/OzgqzN0gfxt/r2tLcCSuBH dFxssB/9i1s1hkjjgoGg3e04u1kmfHSKHz8oZ7b/mm6CohqQClq1QKFzNxpzikqq/C dHR8AyHRp6CptZoIb57n3bgPCW5DGoGLpK3UDh0y1r/C3e1lG5GNjwo46PhVEFrzpU OwuP8fMZC2GmgePqpfTsEkWuXm7dUUJ2lvxohuVcn0oYxTRBkCHRt9pG98GvybLAfW rnCBJCUuWIAj41BJQh8N86fVeBBOt4G44wmRNWFZ+y/R7hzpiB+/mUF0g/HhiLdh3n 7udJsdauf9fJA== To: hrpc@irtf.org References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> 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: <784e5261-c589-73d8-0001-5e4cf67b4db6@cis-india.org> Date: Fri, 7 Jun 2019 14:40:34 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <155989623088.20255.12181969220178709616@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 4cc6a862e0a753e674eb374334b394fd Archived-At: Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-guidelines-03.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, 07 Jun 2019 09:11:13 -0000 Hi! -03 of the guidelines draft is now up. The changes are mostly based on Joe's [0] and Avri's [1] reviews. Look forward to your feedback. Thank you. -GG. [0] https://mailarchive.ietf.org/arch/msg/hrpc/CIwpPOw7R-C8E7kT9omFv_B5qz= Y [1] https://mailarchive.ietf.org/arch/msg/hrpc/CMZNwYxubKupeCKsNy6wO_AAlq= A On 07/06/19 2:00 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Human Rights Protocol Considerations R= G of the IRTF. >=20 > Title : Guidelines for Human Rights Protocol and Arch= itecture Considerations > Authors : University of Amsterdam > Gurshabad Grover > Filename : draft-irtf-hrpc-guidelines-03.txt > Pages : 28 > Date : 2019-06-07 >=20 > Abstract: > This document sets guidelines for human rights considerations in > networking protocols, similar to the work done on the guidelines for > privacy considerations [RFC6973]. This is an updated version of the > guidelines for human rights considerations in [RFC8280]. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-hrpc-guidelines/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-03 > https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-guidelines-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-hrpc-guidelines-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 From nobody Sun Jun 9 12:36:51 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 39E1D12002F for ; Sun, 9 Jun 2019 12:36:49 -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, 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=outbound.mailhop.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 O6kLqfa5E6w0 for ; Sun, 9 Jun 2019 12:36:46 -0700 (PDT) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 A6E8612009E for ; Sun, 9 Jun 2019 12:36:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560109005; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=tAZc3N3e2OONJ2Be5kO0G/+i0jc/Rn8XTSMZiGEHkRPZZjDg6AaoPT2FAl+Ao13DnKfLQ+tQPi7vX iQDMybKvj2gnqsGHn6T6gAsv9J6gXkITNXFZO9dTnD6MmOLyHnvZWKO95iR7FTdy9b5922dEOGknkY WuYMdPOcKD+6/MkzEYQFYpmsEtKRh6liIWG3q0V1Oe0MgSfYOGguC3NkErCNvpywAbYfhWIBiO4IYw 443fw82Rfm83pu4mMMmvRZ9pZlM+MyTCMJd99hKtD+MnCPYtHr5PYB68dE9c0Wku9g/68ah38QemWA uK+Mywpojbfnt1D+hVrugj0H/IvkVRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=message-id:in-reply-to:to:references:date:subject:mime-version: content-transfer-encoding:content-type:from:dkim-signature:from; bh=BnsKH3YgmYH/JiEYeWqHrFYZfcUd7KMR4cQQnLcl9hs=; b=tJeEETxX+HTRvem9W4YVCwcREGpuQXJWtUY0G2apxMJDsJolgbYA1rHc1evlkN6R7+HYBeqtmVjXn gGpDqSGSpo4WJvftpdoEY8ON/V6Ge34mdGXYAQmjUr2/qXDgZVUU2FvTN2u/m/1HQgKkm0ulvEU3/h Yx9aHK+zrOvptm4R7eGgEPcP3Ki8VFca/xNu9oVPVq8IO5mXg85t7W7fQzTSFxLCLUDdHzVCrKkoFq w/TFzwoaaa/Yk/XVWy2GXV0VjAO6ypDtGsQgWynOfWIRYGnjwCH5XTVyATM6ijjWwzxPWp33saHyxz strDtxwAxRHNI8mKQMD+BlRjCUMZr3Q== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=istaff.org smtp.remote-ip=96.241.220.148; dmarc=none header.from=istaff.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=message-id:in-reply-to:to:references:date:subject:mime-version: content-transfer-encoding:content-type:from:from; bh=BnsKH3YgmYH/JiEYeWqHrFYZfcUd7KMR4cQQnLcl9hs=; b=Y9i+bHTKQhZMsLQzZMnwKEZQGtwuoPstvHKgdMsUglENj6Fwm45cFY6+xAirQMSdgdGMmLCItKNgv Xl+d2C8fa7PRsp/MpMhRbs2F2NNEg3s6gINbOHN2IDP2sLA6DJdCCjV09JGJDspJtVh4Z5JZ4nrJnl 64bV9ZKLCSZ3wrz+jCqym/1U+UrCsEwrTX8cX5u/KOtVJcgdK9j/jAifmSj3Wl9FNr1k/cjcucW9Vu 3/zA3dNNQsLYjZvdsV2JiWItTZOxddeTqgAcljAjkDkZExyatbw4tU3eqx5idTHam0Diphs4NWEMSq 5O/Afd7RtAFrz+HklDekAqghiQDQOcg== X-MHO-RoutePath: amN1cnJhbg== X-MHO-User: e8ca397c-8aed-11e9-ba65-db796b3fb7af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 96.241.220.148 X-Mail-Handler: DuoCircle Outbound SMTP Received: from geode.istaff.org (unknown [96.241.220.148]) by outbound3.ore.mailhop.org (Halon) with ESMTPA id e8ca397c-8aed-11e9-ba65-db796b3fb7af; Sun, 09 Jun 2019 19:36:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id A4C8A3BBFE60 for ; Sun, 9 Jun 2019 15:36:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at istaff.org Received: from geode.istaff.org ([127.0.0.1]) by localhost (geode.istaff.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrKwYQkvIIRe for ; Sun, 9 Jun 2019 15:36:40 -0400 (EDT) Received: from [192.168.200.108] (c-69-255-129-19.hsd1.de.comcast.net [69.255.129.19]) by geode.istaff.org (Postfix) with ESMTPSA id 9205F3BBFE4B for ; Sun, 9 Jun 2019 15:36:40 -0400 (EDT) From: John Curran Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 9 Jun 2019 15:36:39 -0400 References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> To: hrpc@irtf.org In-Reply-To: <155989623088.20255.12181969220178709616@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 09 Jun 2019 19:36:49 -0000 On 7 Jun 2019, at 4:30 AM, internet-drafts@ietf.org wrote: > This document sets guidelines for human rights considerations in > networking protocols, similar to the work done on the guidelines for > privacy considerations [RFC6973]. This is an updated version of the > guidelines for human rights considerations in [RFC8280]. Folks -=20 The draft notes that the human right of legal remedy (recourse before = competent tribunal for violations of other fundamental rights) may be = relevant when evaluating impacts of a protocol/architecture, but does = not presently show any example of a relationship within the various = consideration sections. =20 I would note that, encouraged by the operator community, the IETF has = previously considered possible impacts that various architecture & = protocols can have on this human right =E2=80=93 as effective legal = remedy often requires attribution in order to determine applicable law = and jurisdiction and protocols/archictures can significantly preclude = attribution. For an example of IETF consideration of one such = consideration, see BCP162/RFC6302 ("Logging Recommendations for = Internet-Facing Servers=E2=80=9D) that provides logging recommendations = to facilitate better endpoint attribution during abuse and public safety = queries. It is not necessary for draft-irtf-hrpc-guidelines to reflect the = potential for protocols/architectures to impact the human right of legal = remedy, but I believe that omitting an any reference will result in a = guide for conducting HR reviews which is incomplete, and not reflect the = understanding already present in the community that that there are = indeed tradeoffs in human right tradeoffs being made in protocol design = =E2=80=93 hopefully tradeoffs that consider the overall intent of the = IETF to have an Internet which supports effective exercise of the rights = of freedom of expression and association. To that end, I=E2=80=99d suggest adding the following section on = "Attribution to present list of considerations used during protocol = assessment. Thanks! /John =3D=3D=3D 3.3.n Attribution Question(s): Does your protocol/architecture prevent attribution of = those parties=20 involved in communication, and can the protocol readily be used for = communication which harm the security of recipient? What, if any, mechanisms = within the protocol=20 or architecture are provided for a recipient of communications to = obtain redress from communication which causes harm? If no such mechanisms = available, does=20 the protocol/architecture provide sufficient information attributing = the source of=20 communication to facilitate a recipient exercising their right to = legal remedy?=20 Explanation: While anonymity and pseudonymity are very important = attributes=20 for protecting several human rights (e.g. those related to freedom of = expression=20 and association), it is also possible for parties to use = communication capabilities to harm others. Protocols/architectures should consider the = potential for harm in their use, the architectural mechanisms available to mitigate this = risk of harm, the=20 protocol properties that might impact persons exercising their right = of legal remedy, and the resulting impact to individuals right of security of person = when using the=20 protocol.=20 Impacts: - Right to security=20 - Right to legal remedy =3D=3D=3D Disclaimer: my views alone (and no intention to harm the security of = others thru this communication)=20 From nobody Mon Jun 10 07:46: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 A2B2A120199 for ; Mon, 10 Jun 2019 07:46:43 -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, 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 5V-IpaC24Jkw for ; Mon, 10 Jun 2019 07:46:41 -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 E471B12006A for ; Mon, 10 Jun 2019 07:46: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 1haLYl-0001OD-Cj for hrpc@irtf.org; Mon, 10 Jun 2019 16:46:37 +0200 To: hrpc@irtf.org References: <155989623088.20255.12181969220178709616@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: <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> Date: Mon, 10 Jun 2019 16:46:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.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: d40e2d9e04d28df092fb73f3743f8c9c Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 10 Jun 2019 14:46:44 -0000 On 6/9/19 9:36 PM, John Curran wrote: > On 7 Jun 2019, at 4:30 AM, internet-drafts@ietf.org wrote: >> This document sets guidelines for human rights considerations in >> networking protocols, similar to the work done on the guidelines for >> privacy considerations [RFC6973]. This is an updated version of the >> guidelines for human rights considerations in [RFC8280]. > > Folks - > > The draft notes that the human right of legal remedy (recourse before competent tribunal for violations of other fundamental rights) may be relevant when evaluating impacts of a protocol/architecture, but does not presently show any example of a relationship within the various consideration sections. > > I would note that, encouraged by the operator community, the IETF has previously considered possible impacts that various architecture & protocols can have on this human right – as effective legal remedy often requires attribution in order to determine applicable law and jurisdiction and protocols/archictures can significantly preclude attribution. For an example of IETF consideration of one such consideration, see BCP162/RFC6302 ("Logging Recommendations for Internet-Facing Servers”) that provides logging recommendations to facilitate better endpoint attribution during abuse and public safety queries. > > It is not necessary for draft-irtf-hrpc-guidelines to reflect the potential for protocols/architectures to impact the human right of legal remedy, but I believe that omitting an any reference will result in a guide for conducting HR reviews which is incomplete, and not reflect the understanding already present in the community that that there are indeed tradeoffs in human right tradeoffs being made in protocol design – hopefully tradeoffs that consider the overall intent of the IETF to have an Internet which supports effective exercise of the rights of freedom of expression and association. > > To that end, I’d suggest adding the following section on "Attribution to present list of considerations used during protocol assessment. > > Thanks! > /John > > === > > 3.3.n Attribution > > Question(s): Does your protocol/architecture prevent attribution of those parties > involved in communication, and can the protocol readily be used for communication > which harm the security of recipient? What, if any, mechanisms within the protocol > or architecture are provided for a recipient of communications to obtain redress > from communication which causes harm? If no such mechanisms available, does > the protocol/architecture provide sufficient information attributing the source of > communication to facilitate a recipient exercising their right to legal remedy? > > Explanation: While anonymity and pseudonymity are very important attributes > for protecting several human rights (e.g. those related to freedom of expression > and association), it is also possible for parties to use communication capabilities > to harm others. Protocols/architectures should consider the potential for harm in > their use, the architectural mechanisms available to mitigate this risk of harm, the > protocol properties that might impact persons exercising their right of legal remedy, > and the resulting impact to individuals right of security of person when using the > protocol. > > Impacts: > > - Right to security > > - Right to legal remedy This is quite an interesting proposal, and one that I would not oppose. But maybe I could suggestion some granularity that is inspired by the current WHOIS discussions. Perhaps we can seek to provide attribution vis a vis responsible legal entities, and protection vis a vis natural persons? This would for instance provide LEAs with a point of contact that they can approach with a warrant (for instance AS contact), but protect natural persons. Would this make sense? Cheers, Niels > > === > > Disclaimer: my views alone (and no intention to harm the security of others thru this communication) > > > _______________________________________________ > 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 Jun 11 08:44:00 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 02395120025 for ; Tue, 11 Jun 2019 08:43:58 -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=outbound.mailhop.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 0hxlqvlS2tjk for ; Tue, 11 Jun 2019 08:43:54 -0700 (PDT) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 31B2D12013D for ; Tue, 11 Jun 2019 08:43:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560267833; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FGj7/HctMIbppqohrDsCIBKQWWI7CkU9OxqPGFPfTGaG3EDG+vOZjdm2BVmNiz4/+uT7rzdwZJtl4 +k4gdO357jsi6HKgVk85PXp2RTfnJmZMANNhx07xElNP9YmqOBwXm59Zl+V/e/8Vp4CYBT2mKPDOJ2 WQg10uyoKLmeeFBIwPX6LMsU4+eu/VqfC6accMJRwgRQRWz6poVTA1cX7QsExIaB31dXGhq6XKiRyS Hq/Va4rVnNNBj0+rc8RZ0cZxkCImeDAL02VrdBv4vGahz+4Z3Btthp5m+im7auIiIvp2yNRCLybrhQ 6sMCPG1YcWkdGW3pAgX+Ap8aY5CpSoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:dkim-signature:from; bh=E71eA4yL1/TE6BRhY+pfYEbNziar5d2R+aFI3XtvK50=; b=lysGZQTagpHEnhseL0lwOMtbXRAFDnOA2hCZ3xfvjIKXqFkEN7spvQkKnfbTliUnSgd80uSLeYs10 veEtxHv5bCOlluD6RsfhmTNVtiyaur9eKxgGI9wgCo571GGot/7Vcps9IdplxJYpv1xtM6x7/y+6LF +dGujwp5KRnECiIBJrERGOae8cZS8kqvIbSs6eE5Y5Z6of5D5/f6LqA+xZiNPelrFJf2Kd876DbVIJ E07Gwp4rZEf0m4DAzrVQjuUBCZdsyOOUa36FNiwH8YLS6oxm8ACwp6nTAahFRXpaavvMBvXkjavlYL QlbCny0+sS/Bfoq60vbCx68yZ+UiMlg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=istaff.org smtp.remote-ip=96.241.220.148; dmarc=none header.from=istaff.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:from; bh=E71eA4yL1/TE6BRhY+pfYEbNziar5d2R+aFI3XtvK50=; b=dBM59FNOcYPNkB66HsgQGUuQLeeD5BMpzBG7Uqraub1qN2QqsCNGVty1T/9OhfQN7ofs8r6UD6a7p j+cEIE8MWFEhepFywhfY+UiQJrwpNbY2A6XYItqu3eI15TF6kTCsf3H16iB8uOq7Tr66yEZZYdO1Pd oS2S5ydE+8s8pZ2GaDW/ufacEn+7QEJJOp1AoitoGVsY/bRPV3JdToPOVfyKt1OzHsVjmGGu0GwcU6 fMOK6CyKa9HLxX0P9D/CHng1Vn0o+zp4P/yZSXH29u8Wv96xImGt2az6naYRCVPbZPSDXPg02CpoWx ygobjNYuHq4uwW2zn8N16ciOlGaOn3w== X-MHO-RoutePath: amN1cnJhbg== X-MHO-User: b491bb1f-8c5f-11e9-b39a-9d2c53d3dedb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 96.241.220.148 X-Mail-Handler: DuoCircle Outbound SMTP Received: from geode.istaff.org (unknown [96.241.220.148]) by outbound4.ore.mailhop.org (Halon) with ESMTPA id b491bb1f-8c5f-11e9-b39a-9d2c53d3dedb; Tue, 11 Jun 2019 15:43:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id D48733BD95DD; Tue, 11 Jun 2019 11:43:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at istaff.org Received: from geode.istaff.org ([127.0.0.1]) by localhost (geode.istaff.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uATxNhoRLKk6; Tue, 11 Jun 2019 11:43:47 -0400 (EDT) Received: from [172.20.0.75] (unknown [65.216.233.162]) by geode.istaff.org (Postfix) with ESMTPSA id BFE423BD95BE; Tue, 11 Jun 2019 11:43:46 -0400 (EDT) From: John Curran Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_651CB97F-03D8-4807-98CC-2E02B94F61ED" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Jun 2019 11:43:45 -0400 In-Reply-To: <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> Cc: hrpc@irtf.org To: Niels ten Oever References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 11 Jun 2019 15:43:58 -0000 --Apple-Mail=_651CB97F-03D8-4807-98CC-2E02B94F61ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10 Jun 2019, at 10:46 AM, Niels ten Oever = wrote: >> ... >> 3.3.n Attribution >>=20 >> Question(s): Does your protocol/architecture prevent attribution of = those parties=20 >> involved in communication, and can the protocol readily be used for = communication >> which harm the security of recipient? What, if any, mechanisms = within the protocol=20 >> or architecture are provided for a recipient of communications to = obtain redress >> from communication which causes harm? If no such mechanisms = available, does=20 >> the protocol/architecture provide sufficient information = attributing the source of=20 >> communication to facilitate a recipient exercising their right to = legal remedy?=20 >>=20 >> Explanation: While anonymity and pseudonymity are very important = attributes=20 >> for protecting several human rights (e.g. those related to freedom = of expression=20 >> and association), it is also possible for parties to use = communication capabilities >> to harm others. Protocols/architectures should consider the = potential for harm in >> their use, the architectural mechanisms available to mitigate this = risk of harm, the=20 >> protocol properties that might impact persons exercising their = right of legal remedy, >> and the resulting impact to individuals right of security of person = when using the=20 >> protocol.=20 >>=20 >> Impacts: >>=20 >> - Right to security=20 >>=20 >> - Right to legal remedy >=20 > This is quite an interesting proposal, and one that I would not = oppose. But maybe I could suggestion some granularity that is inspired = by the current WHOIS discussions. Perhaps we can seek to provide = attribution vis a vis responsible legal entities, and protection vis a = vis natural persons? >=20 > This would for instance provide LEAs with a point of contact that they = can approach with a warrant (for instance AS contact), but protect = natural persons. >=20 > Would this make sense? Neils -=20 A very interesting question=E2=80=A6 I was not so much advocating for a = particular set of norms regarding attribution, but simply some = recognition that protocol/architecture design decisions can impact the = ability to attribute communications and thus can hinder exercise of = rights (such as legal remedy) when attribution is necessary for exercise = of same.=20 While I think that much more dialogue would be necessary to understand = if there is indeed an widely-accepted set of norm that should be used = for protocol assessment in this area, your point regarding legal entity = attribution vs natural persons is well taken, and might be raised in the = mind of a potential protocol designer (or reviewer) by the addition of = an additional question, as follows: Question(s): Does your protocol/architecture prevent attribution of = those parties=20 involved in communication, and can the protocol readily be used for = communication which harm the security of recipient? What, if any, mechanisms within = the protocol=20 or architecture are provided for a recipient of communications to = obtain redress from communication which causes harm? If no such mechanisms = available, does=20 the protocol/architecture provide sufficient information attributing = the source of=20 communication to facilitate a recipient exercising their right to = legal remedy?=20 If attribution to a natural person is not available, does the = protocol/architecture provide any mechanisms for obtaining contact information for a legal = entity=20 responsible (or representing those responsible) for the communication? This raises the very pragmatic point that attribution to natural persons = is not necessarily a=20 desirable outcome, but that some consideration of alternative mechanisms = for attribution=20 may still facilitate exercise of the "legal remedy" human right. Thoughts? /John p.s. (Disclaimer: my views alone - no one else is foolish enough to = claim them! ;-)=20 --Apple-Mail=_651CB97F-03D8-4807-98CC-2E02B94F61ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 10 Jun 2019, at 10:46 AM, Niels ten Oever <mail@nielstenoever.net> wrote:
...
3.3.n  Attribution

  Question(s): Does your = protocol/architecture prevent attribution of those parties
=   involved in communication, and can the protocol readily be = used for communication
  which harm the = security of recipient?  What, if any, mechanisms within the = protocol
  or architecture are provided for a = recipient of communications to obtain redress
=   from communication which causes harm?  If no such = mechanisms available, does
  the = protocol/architecture provide sufficient information attributing the = source of
  communication to facilitate a = recipient exercising their right to legal remedy?

  Explanation: While anonymity and pseudonymity = are very important attributes
  for protecting = several human rights (e.g. those related to freedom of expression
  and association),  it is also possible for = parties to use communication capabilities
  to = harm others.  Protocols/architectures should consider the potential = for harm in
  their use, the architectural = mechanisms available to mitigate this risk of harm, the
=   protocol properties that might impact persons exercising = their right of legal remedy,
  and the = resulting impact to individuals right of security of person when using = the
  protocol.

=   Impacts:

  - =  Right to security

  - =  Right to legal remedy

This= is quite an interesting proposal, and one that I would not oppose. But = maybe I could suggestion some granularity that is inspired by the = current WHOIS discussions. Perhaps we can seek to provide attribution = vis a vis responsible legal entities, and protection vis a vis natural = persons?

This would for instance provide = LEAs with a point of contact that they can approach with a warrant (for = instance AS contact), but protect natural persons.

Would this make sense?

Neils - 

A = very interesting question=E2=80=A6  I was not so much advocating = for a particular set of norms regarding attribution, but simply some = recognition that protocol/architecture design decisions can impact the = ability to attribute communications and thus can hinder exercise of = rights (such as legal remedy) when attribution is necessary for exercise = of same. 

While I think that = much more dialogue would be necessary to understand if there is indeed = an widely-accepted set of norm that should be used for protocol = assessment in this area, your point regarding legal entity attribution = vs natural persons is well taken, and might be raised in the mind of a = potential protocol designer (or reviewer) by the addition of an = additional question, as follows:

  Question(s): Does your = protocol/architecture prevent attribution of those = parties 
  involved in communication, and can the = protocol readily be used for communication
  which harm = the security of recipient?  What, if any, mechanisms within the = protocol 
  or architecture are provided for a = recipient of communications to obtain redress
  from = communication which causes harm?  If no such mechanisms available, = does 
  the protocol/architecture provide sufficient = information attributing the source of 
  = communication to facilitate a recipient exercising their right to legal = remedy? 
  If = attribution to a natural person is not available, does the = protocol/architecture
 = provide any mechanisms for obtaining = contact information for a legal entity 
  = responsible (or representing those responsible) for the communication?

This raises the very pragmatic point that = attribution to natural persons is not necessarily = a 
desirable outcome, but that some consideration of = alternative mechanisms for attribution 
may still = facilitate exercise of the "legal remedy" human right.

Thoughts?
/John

p.s. (Disclaimer: my views alone - no one else is = foolish enough to claim them! ;-) 




= --Apple-Mail=_651CB97F-03D8-4807-98CC-2E02B94F61ED-- From nobody Wed Jun 12 03:14:21 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 72C9D120137 for ; Wed, 12 Jun 2019 03:14:19 -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, 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 WVizJPQj1cDF for ; Wed, 12 Jun 2019 03:14:17 -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 5B5D21200FA for ; Wed, 12 Jun 2019 03:14: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 1hb0GE-0007AB-ND; Wed, 12 Jun 2019 12:14:13 +0200 To: John Curran , Niels ten Oever Cc: hrpc@irtf.org References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> From: Amelia Andersdotter Openpgp: preference=signencrypt Autocrypt: addr=amelia@article19.org; prefer-encrypt=mutual; keydata= mQINBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABtEFBbWVsaWEgQW5k ZXJzZG90dGVyIChUZWNobmljYWwgY29uc3VsdGFudCkgPGFtZWxpYUBhcnRpY2xlMTkub3Jn PokCVAQTAQgAPhYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJZbJ97AhsjBQkJZgGABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEP7xwpS06AtVgrcQAJYg+mhDhui+9xNb9PuRJbelOI7J WlCjSycfaMi+rTJ9FjVKYIE9aug2VV486BZaeqMoOh5wjl61oeRTDHYG6HvhK4w8O/BVPsL0 8MEfYfpFevZmBsInEJypg0r7VJ/SeO9UyaFKUffgvLyiYwk7zJIgx5dHF5Vch0kTtRNc/Wbe 9MGfhl//1Ztl8GjGqzra7MwzaO12ctTDo7LIvXGqrpYm5g7+hRv3+KYVOJvlh4T4deAzNlX1 F/jj4cOYvJJxP2OMPZxoleQZSf63h0hWnKlQWX3UiUZY/M296V6niGDCQHX1q7oz9YWxwUun mNPltaPnTdvE51N98Q+hhrw39XowN0vYhfphaFNrf/crNKTB5Iqx62aAzYwqXQKlh6EtWAri 2rVB9vXxPv+1eL9t/Kga2JyCjmJVtYJxlZWceyW3EKjK+E7qjr1LHDFjV8ZbvN7QRTdjsuzR Ggz3ECba80Ij2/tASE8IXpT/Zb68NeSx3/nDXkIG13inSvGy8yNovzEADXsGO16GSx5Rool/ ECFhTYksMyM73FkvcpvXo6J+neyGEVKDx1Oy213KgTrAOrA+p2hMI2nX9sI5tvWms8XspwQ5 wtmzDribnZNQzpdrb45Chv56LjrKVer9tmraRq8Qe3mL6jXhMPWLim1OeAx6m3qBzKr3QxuG PdADCLHsuQINBFjWlnsBEADFjusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67T M7yBqsv5COPVgAV+xp+axor5oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrH NUn73/rfeBD9KhKAXcNKKPoccLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+C yYS7xfGolsZXXoBOKcyhfj/ckPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2d Rl3omI/e2t3Vq33hFUUSAdxrFF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8y Bdadw7CM08Uw8wqH7n9BA3oq//QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L9 1vobt8bM/Jbhl9h+X2Yq9oBCiTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVO PASdv9FRUYH1Va7QWQifoha0B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUO xiYKBA4fppJt/LJF4jsaCEyI/CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+ j+/WhzaVT1oVYp6eQXh0bBtqqH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABiQI8BBgB CAAmFiEEPV22yrhSuYgFWmpv/vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1Xn Rw//W4lzE8FddceKXGRwO/T1u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vI AJXM9/HI1FZ09EUdJr5X/+YREErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtk sn/H4USdJL53ZPt10SVNK7H3w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcP YmiU1GQi9QWkGxWRxk0YQXBwhekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAn EV3EqaGnf0PknXp3vNHAZWrfM+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmws Pt8VffbEXlf7qZqRBKaYeKt0qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOA UWRSnDRyT6rv/vXxrbkL4uxWax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB /ntv0DiMuh+fmLGk3zrxs4Xd30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8f Lk17AK7Q1ZTgcZ+8XLRFnavdPrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8R Eiawo+FvVt9j0fKdNEBeaJ3WY5hlhNPcUXr4q1U= Organization: ARTICLE19 Message-ID: Date: Wed, 12 Jun 2019 12:13:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US-large X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 7cd323abaa3d0c03d168080f9b069a49 Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 10:14:20 -0000 On 2019-06-11 17:43, John Curran wrote: > > A very interesting question=E2=80=A6 =C2=A0I was not so much advocating= for a > particular set of norms regarding attribution, but simply some > recognition that protocol/architecture design decisions can impact the > ability to attribute communications and thus can hinder exercise of > rights (such as legal remedy) when attribution is necessary for > exercise of same.=C2=A0 > The conflict is, I guess, even weedier. Anonymity is a human right, and can be crucial for freedom of expression, whistleblowing or criticism. So we might have to do a deeper dive into the attribution vs anonymity. Normally, human rights are obligations on governments and duties on companies to respect individuals. The attribution problem, however, seems to me to arise when governments or companies find that individuals have not respected their rights, or when individuals have not respected other individuals. Because the attribution problem in this sense occurs in a "reverse setting" (individual -> individual or individual -> government/company settings rather than government/company -> individual settings), I'd be cautious to include it in RFC8280. best regards, Amelia > While I think that much more dialogue would be necessary to understand > if there is indeed an widely-accepted set of norm that should be used > for protocol assessment in this area, your point regarding legal > entity attribution vs natural persons is well taken, and might be > raised in the mind of a potential protocol designer (or reviewer) by > the addition of an additional question, as follows: > > =C2=A0 Question(s): Does your protocol/architecture prevent attribu= tion > of those parties=C2=A0 > =C2=A0 involved in communication, and can the protocol readily be u= sed > for communication > =C2=A0 which harm the security of recipient? =C2=A0What, if any, me= chanisms > within the protocol=C2=A0 > =C2=A0 or architecture are provided for a recipient of communicatio= ns > to obtain redress > =C2=A0 from communication which causes harm? =C2=A0If no such mecha= nisms > available, does=C2=A0 > =C2=A0 the protocol/architecture provide sufficient information > attributing the source of=C2=A0 > =C2=A0 communication to facilitate a recipient exercising their rig= ht > to legal remedy?=C2=A0 > =C2=A0/*If attribution to a natural person is not available, does t= he > protocol/architecture*/ > /*=C2=A0 provide any mechanisms*//*=C2=A0for=C2=A0*//*obtaining con= tact > information for a legal entity*/*/=C2=A0/* > */=C2=A0 responsible=C2=A0/**/(or=C2=A0/**/representing=C2=A0/**/th= ose responsible) > for the=C2=A0/*/*communication?*/ > > > This raises the very pragmatic point that attribution to natural > persons is not necessarily a=C2=A0 > desirable outcome, but that some consideration of alternative > mechanisms for attribution=C2=A0 > may still facilitate exercise of the "legal remedy" human right. > > Thoughts? > /John > > p.s. (Disclaimer: my views alone - no one else is foolish enough to > claim them! ;-)=C2=A0 > > > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --=20 Amelia Andersdotter Technical Consultant, Digital Programme Chair, RCM TIG, IEEE 802.11 ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 From nobody Wed Jun 12 03:39: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 1A24B12008D for ; Wed, 12 Jun 2019 03:39:12 -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, 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 mLXzAoIc1Wd6 for ; Wed, 12 Jun 2019 03:39:09 -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 281CC12007A for ; Wed, 12 Jun 2019 03:39:08 -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 1hb0eI-0003Kw-WC; Wed, 12 Jun 2019 12:39:05 +0200 To: Amelia Andersdotter , John Curran Cc: hrpc@irtf.org References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@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: Date: Wed, 12 Jun 2019 12:38:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.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: 01ccc3eb840dc35651f50b798cb06ae8 Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 10:39:12 -0000 On 6/12/19 12:13 PM, Amelia Andersdotter wrote: > On 2019-06-11 17:43, John Curran wrote: >> >> A very interesting question…  I was not so much advocating for a >> particular set of norms regarding attribution, but simply some >> recognition that protocol/architecture design decisions can impact the >> ability to attribute communications and thus can hinder exercise of >> rights (such as legal remedy) when attribution is necessary for >> exercise of same.  >> > The conflict is, I guess, even weedier. Anonymity is a human right, and > can be crucial for freedom of expression, whistleblowing or criticism. > So we might have to do a deeper dive into the attribution vs anonymity. > I don't think anonymity is a human right in itself; the UDHR and ICCPR do not address it, but anonymity can be an important precondition for people to exercise their freedom of expression. https://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/CallForSubmission.aspx > Normally, human rights are obligations on governments and duties on > companies to respect individuals. The attribution problem, however, > seems to me to arise when governments or companies find that individuals > have not respected their rights, or when individuals have not respected > other individuals. Because the attribution problem in this sense occurs > in a "reverse setting" (individual -> individual or individual -> > government/company settings rather than government/company -> individual > settings), I'd be cautious to include it in RFC8280. > This is why I thought it might make sense to institute attribution vis a vis corporate actors, which could subsequently be the vocal point for legal action. This could work as: accountability for the powerful, and protection for the individual. Happy to discuss! Best, Niels > best regards, > > Amelia > > >> While I think that much more dialogue would be necessary to understand >> if there is indeed an widely-accepted set of norm that should be used >> for protocol assessment in this area, your point regarding legal >> entity attribution vs natural persons is well taken, and might be >> raised in the mind of a potential protocol designer (or reviewer) by >> the addition of an additional question, as follows: >> >>   Question(s): Does your protocol/architecture prevent attribution >> of those parties  >>   involved in communication, and can the protocol readily be used >> for communication >>   which harm the security of recipient?  What, if any, mechanisms >> within the protocol  >>   or architecture are provided for a recipient of communications >> to obtain redress >>   from communication which causes harm?  If no such mechanisms >> available, does  >>   the protocol/architecture provide sufficient information >> attributing the source of  >>   communication to facilitate a recipient exercising their right >> to legal remedy?  >>  /*If attribution to a natural person is not available, does the >> protocol/architecture*/ >> /*  provide any mechanisms*//* for *//*obtaining contact >> information for a legal entity*/*/ /* >> */  responsible /**/(or /**/representing /**/those responsible) >> for the /*/*communication?*/ >> >> >> This raises the very pragmatic point that attribution to natural >> persons is not necessarily a  >> desirable outcome, but that some consideration of alternative >> mechanisms for attribution  >> may still facilitate exercise of the "legal remedy" human right. >> >> Thoughts? >> /John >> >> p.s. (Disclaimer: my views alone - no one else is foolish enough to >> claim them! ;-)  >> >> >> >> >> >> _______________________________________________ >> 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 Jun 12 04:06: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 463EA120150 for ; Wed, 12 Jun 2019 04:06: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=outbound.mailhop.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 gbG4rGgaRr71 for ; Wed, 12 Jun 2019 04:06:04 -0700 (PDT) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 1A075120124 for ; Wed, 12 Jun 2019 04:06:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560337563; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=B5DcFUM9BYe0D4Frm9jP4mXpW5VfsmCHPfal77nLFKZJwQzOJJWB693zGxUPJPJKsY3+jmDlNBo69 mhuDLrePZAlQcOWGc11wYcitoGpDFoQ3lveccfT2VNqkk7ZEGHHVZmoPahVX1yoSYXgXbwB7WELDNX AdNAZYkA7TonM8jF4uT7MXG+b+vfyhPh8cvS9eTXKKOHPOn5mZz/OsDFW8EM9MeQX8L8zm0poxxSd9 uqtqKrfV4lCj9TN5pDWgMP7oQ+K1ag8jco/MEPtCwarqR3wRqfsl9jTLxlLf3d56/GLFNNvRYoU2IJ K+XX1TM0HDvELPTWHPc/bx13mv1PoVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=to:references:message-id:content-transfer-encoding:cc:date:in-reply-to:from: subject:mime-version:content-type:dkim-signature:from; bh=DscFfi0hNUHV+WKemL4DfllKv24zVzq+Q7eJN1C8BR4=; b=rN8QxQBsenwEWcTTOUgfjuQAy97VRfgAFqnYjmuNwWffwpEypoFx21Ufndsv3jPv3QCrpvoxU+MxY XSllVmhnlo6gx5Q3MX4eW4/v0gb4anzkO75usnf0U5V2z5EoFCUUUv3M43ecD4ZFDdVFNbTnBz2GvG YZZRtOGX5ca21+/2dnNTgfCJkFw3w41N9nI3ynGFb+/zoj5tIWJjIQwRXG8vlQMjya6RasiTT6XCtu ogCW8nAr1oMFxFoOHoAx2hjCapO57veNIXBofzAtN6yhzZyxxDPQX/zbDUrOygOMTlon1Epw4xIcFX rKmcPOgIQKDOsaMNnCeBPlRcWEmM0QQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=istaff.org smtp.remote-ip=96.241.220.148; dmarc=none header.from=istaff.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=to:references:message-id:content-transfer-encoding:cc:date:in-reply-to:from: subject:mime-version:content-type:from; bh=DscFfi0hNUHV+WKemL4DfllKv24zVzq+Q7eJN1C8BR4=; b=Bx0eW9oTUZJvn4rmy9YWfSdpSCmHZMIw+EQrzm+UiaUmx8V35mTtkG9EGN5xzon+rU6KrCYYZQZcM bl9EphF3rrgrbt0amwxeNnWe3PdtJrk76Bhd083WIH+LYoYo1CCCnsqXF8DJzAUJUZzZDBJhp1l6Ie AxoJFM42T9DYS89+RIGWe3wXql0EsNOQ900fCtJUldvokU5EYVjKpzCZxugrSnozXj2QbA9h/IKOAt j14xltr8EBbcxn/jaThmsQS1DtbONsVxIu8Dc7l9sNR5I4aGdFQoSCIkmc7HJLDqU/tTCuAEPqcnQM BA0PI5dAj2GV9lnULvDPhu+4e8oqDFg== X-MHO-RoutePath: amN1cnJhbg== X-MHO-User: 0db3196d-8d02-11e9-ba65-db796b3fb7af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 96.241.220.148 X-Mail-Handler: DuoCircle Outbound SMTP Received: from geode.istaff.org (unknown [96.241.220.148]) by outbound3.ore.mailhop.org (Halon) with ESMTPA id 0db3196d-8d02-11e9-ba65-db796b3fb7af; Wed, 12 Jun 2019 11:06:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id D741E3BE4977; Wed, 12 Jun 2019 07:05:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at istaff.org Received: from geode.istaff.org ([127.0.0.1]) by localhost (geode.istaff.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_HlMo2bj42B; Wed, 12 Jun 2019 07:05:55 -0400 (EDT) Received: from [172.20.0.75] (unknown [65.216.233.162]) by geode.istaff.org (Postfix) with ESMTPSA id A7E363BE4969; Wed, 12 Jun 2019 07:05:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: John Curran In-Reply-To: Date: Wed, 12 Jun 2019 07:05:54 -0400 Cc: Niels ten Oever , hrpc@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> To: Amelia Andersdotter X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 11:06:06 -0000 On 12 Jun 2019, at 6:13 AM, Amelia Andersdotter = wrote: > ... > Normally, human rights are obligations on governments and duties on > companies to respect individuals. You use the term =E2=80=9Cnormally=E2=80=9D, where perhaps you meant = =E2=80=9Ctypically=E2=80=9D? All human rights are normal, but I concur = that the typical considerations regarding human rights implementation = involve preventing otherwise impacting government or business activity.=20= > The attribution problem, however, > seems to me to arise when governments or companies find that = individuals > have not respected their rights, or when individuals have not = respected > other individuals. Correct.=20 > Because the attribution problem in this sense occurs > in a "reverse setting" (individual -> individual or individual -> > government/company settings rather than government/company -> = individual > settings), I'd be cautious to include it in RFC8280. I don=E2=80=99t following how the atypical nature of the "legal = remedy=E2=80=9D human right makes it any less important than other human = rights or warrants its exclusion from aspects that need to be considered = by protocol/architecture designers. In fact, the less obvious = relationship between attribution and ability to support the legal remedy = human right would argue that it=E2=80=99s likely more important that it = be included, less it be readily overlooked by designers when striving to = strike an appropriate balance in these areas.=20 Thanks!=20 /John p.s. Disclaimer: my views alone - this message composed of 100% = recycled electrons.=20 From nobody Wed Jun 12 10:49:28 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 4DDA9120159 for ; Wed, 12 Jun 2019 10:49:26 -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 RRb51Iober3j for ; Wed, 12 Jun 2019 10:49:23 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 AF84D12016F for ; Wed, 12 Jun 2019 10:49:16 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id n11so17298987qtl.5 for ; Wed, 12 Jun 2019 10:49:16 -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=mcHSpDkq3b2uKEe3XfPsCrMOftPo5uOuPqzLxJ2rkHM=; b=j7ArSO82/Q7cCnIInSE6L2r14aJFj2unwgLZJEcll3umkpgY/C8OMLPwR4Wu3W5eiV f44zWfNVcjCWTj5CieKb+sxte0NeFOAUt6n0wpy8D2dHrHNVGXP943+ovtDh/H/4hJP+ 5dHhF33UH0l2GhAtCv+mPaduBTUBtF0pT12efMkvBqIoWkXBKL4BItgRaWryEc5ylnij xIk9c2gRCgRfjjJv6DlhViNJXNMLWsTxPDoZHdjPSrwFEHcHbpymGYpKqmQ4Zafz2XiI UlwUmE1Jdt+Ju8nsptoQuV4c15te8fQLF1LBlWqulHx8sm8v4VoNvaf3s8a4fCxyDoTx 8OGg== 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=mcHSpDkq3b2uKEe3XfPsCrMOftPo5uOuPqzLxJ2rkHM=; b=i1RqWuHPsYGpjw43GG0SD228Q1get0iBwnD7G49gvWcifJnqPoAHnhnBtdTJ7M86Gb r4S0uNYLMpyo5rlDEuffH2AzA+BSK7IG7vi/KIQwhwMIdz9yW0a8uJ2IWg0sw4vpXKFq uh8Jb6Hnl41GGuShOi+puxrby6iiLaBeBvfy+6uagdyJ1Ha0sGWfqdXo0zyveAZ1R2Fv FakCesrxQUy+4JPN8OTALcCiLRurVZkVpw0ftt5rGAwIocwUTmovjYl6a3ejBmRwjOvB e/HFjN+o2yHm9JXiwZrPFaEUQ7du42TTW4e1NI1urXUYa72FS87+bd/WK42csItZWgrR WqZg== X-Gm-Message-State: APjAAAUV9ReKpQrGd/mvT4hbjb2CZ39jOzQd+xWR2GI0IqVWy1BNrgRD UybRB6XJ0mH/K95XZiSz/pbp7WibByw170FuwpQ= X-Google-Smtp-Source: APXvYqx7NnAiP7KTCQ72F8+1B81SoG3PvEFEn6KiMl+gsfvy2Mm0shNxNks19u/NFgPxB9eUFo2EFmmOJrl38p2370Y= X-Received: by 2002:ac8:24b8:: with SMTP id s53mr2985751qts.276.1560361755718; Wed, 12 Jun 2019 10:49:15 -0700 (PDT) MIME-Version: 1.0 References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> In-Reply-To: <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> From: farzaneh badii Date: Wed, 12 Jun 2019 13:48:49 -0400 Message-ID: To: John Curran Cc: Amelia Andersdotter , hrpc@irtf.org, Niels ten Oever Content-Type: multipart/alternative; boundary="0000000000002bb716058b2408d9" Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 17:49:26 -0000 --0000000000002bb716058b2408d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Frankly, John, what you are suggesting is outrageous. You don't have to always attribute the wrongdoing to a "person" or even a "location" to be able to establish jurisdiction and have access to a legal remedy and even preserve security. What you are suggesting will do more harm than good for human rights. Farzaneh On Wed, Jun 12, 2019 at 7:06 AM John Curran wrote: > On 12 Jun 2019, at 6:13 AM, Amelia Andersdotter > wrote: > > ... > > Normally, human rights are obligations on governments and duties on > > companies to respect individuals. > > You use the term =E2=80=9Cnormally=E2=80=9D, where perhaps you meant =E2= =80=9Ctypically=E2=80=9D? All > human rights are normal, but I concur that the typical considerations > regarding human rights implementation involve preventing otherwise > impacting government or business activity. > > > The attribution problem, however, > > seems to me to arise when governments or companies find that individual= s > > have not respected their rights, or when individuals have not respected > > other individuals. > > Correct. > > > Because the attribution problem in this sense occurs > > in a "reverse setting" (individual -> individual or individual -> > > government/company settings rather than government/company -> individua= l > > settings), I'd be cautious to include it in RFC8280. > > I don=E2=80=99t following how the atypical nature of the "legal remedy=E2= =80=9D human > right makes it any less important than other human rights or warrants its > exclusion from aspects that need to be considered by protocol/architectur= e > designers. In fact, the less obvious relationship between attribution an= d > ability to support the legal remedy human right would argue that it=E2=80= =99s > likely more important that it be included, less it be readily overlooked = by > designers when striving to strike an appropriate balance in these areas. > > Thanks! > /John > > p.s. Disclaimer: my views alone - this message composed of 100% recycled > electrons. > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --0000000000002bb716058b2408d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Frankly, John, what you are suggesting is outrageous.=C2=A0
You don't have to always attribute the wrongdoing to a "person&q= uot; or even a "location" to be able to establish jurisdiction an= d have access to a legal remedy and even preserve security. What you are su= ggesting will do more harm than good for human rights.=C2=A0


Farzaneh =


On Wed, Jun 12, 2019 at 7:06 AM John Cur= ran <jcurran@istaff.org> wr= ote:
On 12 Jun 2= 019, at 6:13 AM, Amelia Andersdotter <amelia@article19.org> wrote:
> ...
> Normally, human rights are obligations on governments and duties on > companies to respect individuals.

You use the term =E2=80=9Cnormally=E2=80=9D, where perhaps you meant =E2=80= =9Ctypically=E2=80=9D?=C2=A0 All human rights are normal, but I concur that= the typical considerations regarding human rights implementation involve p= reventing otherwise impacting government or business activity.

> The attribution problem, however,
> seems to me to arise when governments or companies find that individua= ls
> have not respected their rights, or when individuals have not respecte= d
> other individuals.

Correct.

> Because the attribution problem in this sense occurs
> in a "reverse setting" (individual -> individual or indiv= idual ->
> government/company settings rather than government/company -> indiv= idual
> settings), I'd be cautious to include it in RFC8280.

I don=E2=80=99t following how the atypical nature of the "legal remedy= =E2=80=9D human right makes it any less important than other human rights o= r warrants its exclusion from aspects that need to be considered by protoco= l/architecture designers.=C2=A0 In fact, the less obvious relationship betw= een attribution and ability to support the legal remedy human right would a= rgue that it=E2=80=99s likely more important that it be included, less it b= e readily overlooked by designers when striving to strike an appropriate ba= lance in these areas.

Thanks!
/John

p.s. Disclaimer:=C2=A0 my views alone - this message composed of 100% recyc= led electrons.


_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--0000000000002bb716058b2408d9-- From nobody Wed Jun 12 11:05: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 7EBBC1200A1 for ; Wed, 12 Jun 2019 11:05:40 -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=outbound.mailhop.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 XxeIZ0lpvYNR for ; Wed, 12 Jun 2019 11:05:38 -0700 (PDT) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 E04ED1201E8 for ; Wed, 12 Jun 2019 11:05:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560362737; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=c1FPY8w66rzxZ0fZsSlUOqqj2DVR1g/bIqn0ngTtBhGE+xDJoLY8DsXV7wQC+6DiSxUsWZmmJ84Im FUcZnHRJd5dP9HE9mMPfVFONWrjgBGZ5aK+XTOvRkaf7dzuXOvpJZ5u3P9/I/yFAR0fEup5heZtd/6 2IIqfcIOoJ5sivKcNTXd3StlgO1Tatw+gve2L3nQovLLq3ysEm1gSUn7CSBaQCVHlvPOVtDKYHzYYW iXYk/n4vkT2krBxYXn/KgPYgavKc1RVQQJz8i5X9rWg6xyCEFffVst3xAUoOKnMA8R/MGZA++FTi1G ypXN/fOGL8v6u0RA4dD/MLndQ3xxSeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:dkim-signature:from; bh=uSY/TJg9MwcGrV9w1XOaho/7i0I8l1JvTsXmQ/n/O7o=; b=R3TayIG9Gu9QDPuyiZuMk920y9kNqQb4ElNc3Ni7nmCl47ZiN5QNbFBMFbkhA18Nz6k+ONbHroJpN DyckHv3i4+BCjQsVmoR/cscdS6xKP2DT7M2ciR8ZSTSZuCJIGJKYyiUmexOu0czEV5u7wKgsmdYuBf 6Y8ZcfYp/wGDgOZS27RgdweoN8sZdNRDcDqiNH37ZupLTYxCUpdrMGnwv7yBipQlYP3OgXGBv4MXsC AXuBXmJ36eVPV3b81l9CebUAp8w6WgerbQtnnsnjsLV9O301JvTErMgRU9ubIfRIlYIdMSNRGGxSqR DlBG9a0CuWMxHdRxWM6/Os5rARQMeXA== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=istaff.org smtp.remote-ip=96.241.220.148; dmarc=none header.from=istaff.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:from; bh=uSY/TJg9MwcGrV9w1XOaho/7i0I8l1JvTsXmQ/n/O7o=; b=sceqWCf8BYUHCYjUBSQ7ok2zoXBdMparLaahXjLjmZbHNJjOl0qDfWFzt9KrEI1ilyj8ZhgI5+ra3 JBmzr13dU0AUZugEnNRT039b9vVL856exlr5jD+/WDdJZLKYD99z8smw3KUEpmklYaCYnyWENWfW+G /+3GQ7MJyzY7CMNiObUSaLSO4q5WWvXns6oWjFTp927sXqYlnGshecdOgevut1yhRnTUugrJfODSea 0OpnM/61f8dRcdWLYNu0s443TycCy3ontJEistCr9yNs5/L7Yvsc7gHs3MX83ShW2Rtd9pLxzWsIxk D1tyJ09VG9HRMRfceECgWDj1kq074kA== X-MHO-RoutePath: amN1cnJhbg== X-MHO-User: ab45d319-8d3c-11e9-ba65-db796b3fb7af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 96.241.220.148 X-Mail-Handler: DuoCircle Outbound SMTP Received: from geode.istaff.org (unknown [96.241.220.148]) by outbound3.ore.mailhop.org (Halon) with ESMTPA id ab45d319-8d3c-11e9-ba65-db796b3fb7af; Wed, 12 Jun 2019 18:05:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id 116B03BE9177; Wed, 12 Jun 2019 14:05:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at istaff.org Received: from geode.istaff.org ([127.0.0.1]) by localhost (geode.istaff.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5smPUl70CBq; Wed, 12 Jun 2019 14:05:31 -0400 (EDT) Received: from static-219-167.meetings.nanog.org (unknown [199.187.219.167]) by geode.istaff.org (Postfix) with ESMTPSA id 383313BE915C; Wed, 12 Jun 2019 14:05:31 -0400 (EDT) From: John Curran Message-Id: <992B79C0-5B80-4710-B8CF-D87BC80FA2C3@istaff.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_F3F02F33-FE1E-4AAB-9F3F-A2A85BF4E0CE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 12 Jun 2019 14:05:30 -0400 In-Reply-To: Cc: Amelia Andersdotter , hrpc@irtf.org, Niels ten Oever To: farzaneh badii References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 18:05:41 -0000 --Apple-Mail=_F3F02F33-FE1E-4AAB-9F3F-A2A85BF4E0CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 12 Jun 2019, at 1:48 PM, farzaneh badii = wrote: >=20 > Frankly, John, what you are suggesting is outrageous.=20 >=20 > You don't have to always attribute the wrongdoing to a "person" or = even a "location" to be able to establish jurisdiction and have access = to a legal remedy and even preserve security. What you are suggesting = will do more harm than good for human rights.=20 Farzaneh -=20 I=E2=80=99m not certain if you read what I wrote, but I certainly did = _not_ advocate that protocols/architectures have to always attribute to = a person or location =E2=80=93 the proposed text provides questions for = protocol designers to consider in their design activities, not mandates = or architectural norms to be followed.=20 If you are correct in that there are cases where attribution isn=E2=80=99t= necessary to provide access to a legal remedy, then it=E2=80=99s simply = a matter of documenting (for a given protocol/architecture under = assessment) why that is the case, since that=E2=80=99s one of the first = questions asked in the proposed text:=20 "What, if any, mechanisms within the protocol or architecture = are provided for a recipient of communications to obtain redress from = communication which causes harm? =E2=80=9C If redress is readily available, then it is indeed true that attribution = is a non-issue. It might be good to document an example of such a = protocol, since most protocols recourse from =E2=80=9Cbad behavior=E2=80=9D= is disconnection, and that=E2=80=99s obviously not the same as legal = remedy/redress.=20 Thanks! /John John Curran President and CEO American Registry for Internet Numbers --Apple-Mail=_F3F02F33-FE1E-4AAB-9F3F-A2A85BF4E0CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 12 Jun 2019, at 1:48 PM, farzaneh badii <farzaneh.badii@gmail.com> wrote:

Frankly, John, what you are = suggesting is outrageous. 

You = don't have to always attribute the wrongdoing to a "person" or even a = "location" to be able to establish jurisdiction and have access to a = legal remedy and even preserve security. What you are suggesting will do = more harm than good for human = rights. 

Farzaneh - 

I=E2=80=99m not certain if you read what I wrote, = but I certainly did _not_ advocate that protocols/architectures have to = always attribute to a person or location =E2=80=93 the proposed text = provides questions for protocol designers to consider in their design = activities, not mandates or architectural norms to be = followed. 

If you are correct = in that there are cases where attribution isn=E2=80=99t necessary to = provide access to a legal remedy, then it=E2=80=99s simply a matter of = documenting (for a given protocol/architecture under assessment) why = that is the case, since that=E2=80=99s one of the first questions asked = in the proposed text: 

"What, if any, mechanisms within the protocol = or architecture are provided for a recipient of communications to obtain = redress from communication which causes harm? =  =E2=80=9C

If redress = is readily available, then it is indeed true that attribution is a = non-issue.  It might be good to document an example of such a = protocol, since most protocols recourse from =E2=80=9Cbad behavior=E2=80=9D= is disconnection, and that=E2=80=99s obviously not the same as legal = remedy/redress. 

Thanks!
/John

John Curran
President and = CEO
American Registry for Internet Numbers



= --Apple-Mail=_F3F02F33-FE1E-4AAB-9F3F-A2A85BF4E0CE-- From nobody Wed Jun 12 11:06: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 110E31200B6 for ; Wed, 12 Jun 2019 11:06:05 -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 msmBXBHk1QxK for ; Wed, 12 Jun 2019 11:06:03 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 1BC74120075 for ; Wed, 12 Jun 2019 11:06:03 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id n2so10850719vso.6 for ; Wed, 12 Jun 2019 11:06:03 -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=/nPKw1NjsrOdr4IXL/vp239ZFeOR+q4SCJJe8ynCaro=; b=Uv10hqlRg3GPP79gs+XFADxW0Xa2diKAAJOeYYmwmHMBtg43yIlMXD+GZO+H8kggkE KzzxR0qxLO0TvE2ZcB7YmNfSF3yD6OoERKJfnGRv6uBX/ImxyfiGUtCgL9FqJE04TBkM 58BHd9OCOI/4vrMSEOmVAQvi6SkCDXTEgoUAnOte/D33EBsX7+6uEdLTWRagdNFzGGDG oy5Ibp/YrvsyPZ0dPbWceFbgfzM98WopF6xWdXcUwSdeUGtA+ufIHIaaKG6gquyzqkVw 6k/qpj4Z/IvcEZ6kGNU253Kte4E3LFDmQVxlH7kMTiqj0PTKlmc251qeF8+U3o1RtPBU Wsxg== 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=/nPKw1NjsrOdr4IXL/vp239ZFeOR+q4SCJJe8ynCaro=; b=a4UVmuTr9RAMROiJ8UKKmd0WTfAEYuozrsI9uuPdoqWsAA9SlEBjTEoUsJkAILsPzq 9TFQD9N8V5hJUwMIhuONNrCCYi/v/3xlYTFxCqUrej0gUk9HytP4py3n60lJw/LZ5AWz NYuXP9H/oVxOe/FaEm/ISVgL1ZhLiMssrLWsOiHplFplAh8wToythLDfqMkdgrtaBz7T WsN+1vtbBDbH8ZNRrlBKH4VmsHK76j2TsiL2x2qAlcekYGw+ffbiM1Wi0LBRbAcq7rTb jUe6v8evj0XV3H1khL3ZycYzjY+is1BWyWr9Gi/kcWgvNQsy6bypmiu+HcHtLhxnHgRG OG1w== X-Gm-Message-State: APjAAAWUOp6wTzI/v+IOobrNKGjR3YTn6Izpayrl6OeEQzE2/fARLPm2 fzc8x/DpboaElUaUwqL6ZQ2PNQ== X-Google-Smtp-Source: APXvYqyuEuGqy317XHJwFCN9tsS3F30Lrpne2ZQMApO6wWSzwFYbaguTT7edUrdevN3BM8KMrCViGg== X-Received: by 2002:a67:ecd6:: with SMTP id i22mr33245552vsp.64.1560362762205; Wed, 12 Jun 2019 11:06:02 -0700 (PDT) Received: from [192.168.8.100] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id q77sm102067vke.13.2019.06.12.11.06.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jun 2019 11:06:01 -0700 (PDT) From: Ted Lemon Message-Id: <2347EC29-4F1B-4A67-9C96-632006CD2311@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_96B04542-4D42-4936-B86D-D8B67970A4B7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 12 Jun 2019 14:05:59 -0400 In-Reply-To: Cc: John Curran , Niels ten Oever , hrpc@irtf.org, Amelia Andersdotter To: farzaneh badii References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 18:06:05 -0000 --Apple-Mail=_96B04542-4D42-4936-B86D-D8B67970A4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 12, 2019, at 1:48 PM, farzaneh badii = wrote: > Frankly, John, what you are suggesting is outrageous.=20 I=E2=80=99m having trouble seeing what John has said that=E2=80=99s = outrageous. Rather than simply saying it=E2=80=99s outrageous and = hoping that we will see what you mean, could you please tell us what you = think he has said that is outrageous, and what about it is outrageous? = I say =E2=80=9Cthink he has said=E2=80=9D because it=E2=80=99s also = possible that there is a misunderstanding here, and that=E2=80=99s why = I=E2=80=99m not seeing it. --Apple-Mail=_96B04542-4D42-4936-B86D-D8B67970A4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jun 12, 2019, at 1:48 PM, farzaneh badii <farzaneh.badii@gmail.com> wrote:
Frankly, John, = what you are suggesting is outrageous. 

I=E2=80=99m having trouble seeing what John has = said that=E2=80=99s outrageous.   Rather than simply saying it=E2=80=99= s outrageous and hoping that we will see what you mean, could you please = tell us what you think he has said that is outrageous, and what about it = is outrageous?   I say =E2=80=9Cthink he has said=E2=80=9D because = it=E2=80=99s also possible that there is a misunderstanding here, and = that=E2=80=99s why I=E2=80=99m not seeing it.


= --Apple-Mail=_96B04542-4D42-4936-B86D-D8B67970A4B7-- From nobody Wed Jun 12 11:50: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 27063120148 for ; Wed, 12 Jun 2019 11:50:35 -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 8JU2T7MAUXVF for ; Wed, 12 Jun 2019 11:50:33 -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 EE41D120199 for ; Wed, 12 Jun 2019 11:50:17 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id m29so19666861qtu.1 for ; Wed, 12 Jun 2019 11:50:17 -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=kX8nBduck0RN3voD7OvblZkxatn0mY+QU/6WXNstc+E=; b=AyY933fc3eywFlkf1dgr2km1XSePxJubQ8Xc5JNCOjLv7TX1xD1IpjxQXApzRDLrbx /+60sPXhAfkHL10FH5k+ACamaBl8NLJLhkIrx9UusozdrJMDgnxSAZGOWl1rayxlwG2s 9HLFY1Y50/l9a/+FP3E+UM/4dLylD0S2ULUJoxzSIc1tHpZLQzOtUKPdVo5ctUPqnOvo xWyn4pKqeaTXHo0l+f8wo1U9cypo9W9Q6R7DYOvpHJoZi8hOAm07NG+qp2ooCnFwnGQN 8Q4bIKZaJTNG51d9C2m5p6U90b+ymXvWEyCsYqcZD/10znErTZVNOA2Ke8xC8D75yA4N b7yg== 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=kX8nBduck0RN3voD7OvblZkxatn0mY+QU/6WXNstc+E=; b=O/IoXy40Ax61moKAruSPw7ZVR7YCBmDlzN80exzi4a+3FXrR7pzjXnLZ7yWs8szJV6 uGBnKwpdoGWbc1PnOMKxVUZJ6u+bPl5r6r1VR5N0e1+OCbgHPIOst6epYA3HlY/ETL5D CSo9imxykQHM/ejZFHXQif1784FNq+uvQHFv5PSTqfxKpg1LmUb4C6M8bqIcxfR+7I2m dA6fF0N4OmqpHOMG853gXO61QN6Qx++lCbssbgU0KNKN4COtQFBeqyPXcFnnI/DkAgWw NLjaei8pmy19q5+ptgS1sSiDXRNXKOYj/IT8En2TqQ17qJhs4vc5+agBH/N9JB4bLn1x jAvw== X-Gm-Message-State: APjAAAVFT8BVTyUPaHiOgxOts7hXuwXtQM/MX/onoaze2753yhjpj6pW /9pj+WS4QfXirVnMd/GKQRlwsS4Hek9tQOZPoCe+RA== X-Google-Smtp-Source: APXvYqxm9a4Rr3Y+9VOV0jiyof9XIcAwFUfwH+X+6ibUJa2kOSWt8qHGlXdGJucw6yqOMhGaHfwNx7iaJRrIsdJpMaM= X-Received: by 2002:ac8:24b8:: with SMTP id s53mr3123355qts.276.1560365416995; Wed, 12 Jun 2019 11:50:16 -0700 (PDT) MIME-Version: 1.0 References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> <992B79C0-5B80-4710-B8CF-D87BC80FA2C3@istaff.org> In-Reply-To: <992B79C0-5B80-4710-B8CF-D87BC80FA2C3@istaff.org> From: farzaneh badii Date: Wed, 12 Jun 2019 14:49:50 -0400 Message-ID: To: John Curran Cc: Amelia Andersdotter , hrpc@irtf.org, Niels ten Oever Content-Type: multipart/alternative; boundary="000000000000665e0e058b24e256" Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 18:50:35 -0000 --000000000000665e0e058b24e256 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks John. That now makes better sense to me. We can discuss whether it should be documented and how it should be documented. But we need to consider many more aspects of it. We need to understand what "security" and "legal remedy" means in IP. What is "harm"? Harm is a very controversial term which can be interpreted in various ways. I suggest we have more discussion about the nuances before arguing about the inclusion of your text. Farzaneh On Wed, Jun 12, 2019 at 2:05 PM John Curran wrote: > On 12 Jun 2019, at 1:48 PM, farzaneh badii > wrote: > > > Frankly, John, what you are suggesting is outrageous. > > You don't have to always attribute the wrongdoing to a "person" or even a > "location" to be able to establish jurisdiction and have access to a lega= l > remedy and even preserve security. What you are suggesting will do more > harm than good for human rights. > > > Farzaneh - > > I=E2=80=99m not certain if you read what I wrote, but I certainly did _no= t_ > advocate that protocols/architectures have to always attribute to a perso= n > or location =E2=80=93 the proposed text provides questions for protocol d= esigners > to consider in their design activities, not mandates or architectural nor= ms > to be followed. > > If you are correct in that there are cases where attribution isn=E2=80=99= t > necessary to provide access to a legal remedy, then it=E2=80=99s simply a= matter of > documenting (for a given protocol/architecture under assessment) why that > is the case, since that=E2=80=99s one of the first questions asked in the= proposed > text: > > *"What, if any, mechanisms within the protocol or architecture are > provided for a recipient of communications to obtain redress from > communication which causes harm? =E2=80=9C* > > If redress is readily available, then it is indeed true that attribution > is a non-issue. It might be good to document an example of such a > protocol, since most protocols recourse from =E2=80=9Cbad behavior=E2=80= =9D is > disconnection, and that=E2=80=99s obviously not the same as legal remedy/= redress. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > --000000000000665e0e058b24e256 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks John. That now makes better sense to me. We can discuss = whether it should be documented and how it should be documented. But we nee= d to consider many more aspects of it.=C2=A0
We need to understand what=C2= =A0 "security" and "legal remedy"=C2=A0 means in IP. Wh= at is "harm"? Harm is a very controversial term which can be inte= rpreted in various ways.

I suggest we have more discussion about the n= uances before arguing about the inclusion of your text.=C2=A0



Farzaneh


On Wed, Jun 12, 2019 at 2:05= PM John Curran <jcurran@istaff.or= g> wrote:
On 12 Jun 2019, at 1:48 PM, farz= aneh badii <farzaneh.badii@gmail.com> wrote:

<= div dir=3D"ltr">
Frankly, John, what you are suggesting is outrageous.=C2=A0

=
You don't have to always attribute the wrongdoing to a "person&qu= ot; or even a "location" to be able to establish jurisdiction and= have access to a legal remedy and even preserve security. What you are sug= gesting will do more harm than good for human rights.=C2=A0

Farzaneh -=C2=A0

I= =E2=80=99m not certain if you read what I wrote, but I certainly did _not_ = advocate that protocols/architectures have to always attribute to a person = or location =E2=80=93 the proposed text provides questions for protocol des= igners to consider in their design activities, not mandates or architectura= l norms to be followed.=C2=A0

If you are correct i= n that there are cases where attribution isn=E2=80=99t necessary to provide= access to a legal remedy, then it=E2=80=99s simply a matter of documenting= (for a given protocol/architecture under assessment) why that is the case,= since that=E2=80=99s one of the first questions asked in the proposed text= :=C2=A0

"What, i= f any, mechanisms within the protocol or architecture are provided for a re= cipient of communications to obtain redress from communication which causes= harm? =C2=A0=E2=80=9C

If redress is readi= ly available, then it is indeed true that attribution is a non-issue.=C2=A0= It might be good to document an example of such a protocol, since most pro= tocols recourse from =E2=80=9Cbad behavior=E2=80=9D is disconnection, and t= hat=E2=80=99s obviously not the same as legal remedy/redress.=C2=A0

Thanks!
/John

Joh= n Curran
President and CEO
American Registry for Intern= et Numbers



= --000000000000665e0e058b24e256-- From nobody Wed Jun 12 12:42: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 BCC24120158 for ; Wed, 12 Jun 2019 12:42:56 -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 dy7RTfs7O1WR for ; Wed, 12 Jun 2019 12:42:53 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 87F46120159 for ; Wed, 12 Jun 2019 12:42:39 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id h21so19798461qtn.13 for ; Wed, 12 Jun 2019 12:42:39 -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=zML6VnmWx0qF6Vdh/WFTLc5z0tGMThtx1OPqQDVz3h8=; b=jNmonJ4bRaIvvoL0dh3juqC74wIQi+NQCnYVODCg5bZ/BQ4HB5RJgVUY8NWnRmKQhj 6ZamL7BK0ENN2ro4QCBYkvsQ7gpPtSkyeEvaPOXqoC6gXDh91lbxxvJ+n8fnfJ8L6pqp KIsqGAYb1fOtYhcraMq0jhWqe0F35GVrKuocMLHv1aagGC6JY5Yj8ZSiDPTsmM7kNtZk XPwDYIKLft6bfX4LBLPtbd5xFAg2DT1ySHHuN5CBCO78E8PkvT3cKOcDT3XFBW8fh5Qf JmUnM85LCAIQ2MRNcWwbiGLTJwSqDO7TgTZ8Q/wjUY45Abx0cSY4pG5KTC7tUE7a4En8 1U3A== 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=zML6VnmWx0qF6Vdh/WFTLc5z0tGMThtx1OPqQDVz3h8=; b=CeVThrYq40tNdGQNPIHiM0jBMusX6LnvEdEaIR/I6ZI2BGi0Nv7bt1wcelRt12VbE2 U6MBNpfnvdIQEeqfmawV0t3HqpezDtvZSNfzve5/xXRTJqVURaqggcRaBdMBWbPWeuT8 epUJhS82w8fjZoDxq12lA0i07/fvZEzZ+VSvExSvvRuQaZf3A7Jmr2g140XHg1IRtg4X juOY9dPvk68pT46LI91iIiRLg6jsFp66uYajJtC+bQt9SwMv5BoFb8mZ5LCv+mKzSf/J EylHW9cGAE3IAxtKXUWVMHhNS+HSkmovRpeQ+O6a5Wrg6K2lYk0UK7zdpMtTctFnO1fx ouwQ== X-Gm-Message-State: APjAAAXqA5fiqKn9LVEaRb6fIBb9IB95HlQZg1qp2F7zLT18zpIkFfgF c84Nsl7XOLmhU4c1BCTs4Gv0hTg37rxUAj3S6H0= X-Google-Smtp-Source: APXvYqwVApwsYEsPYcBB5gh9nvQ8jj53d5NlgJc2JlFJDNN4p1SXKESmdWHjEawv6/G3cTuHZL5HQchiYn/bo0pHn7w= X-Received: by 2002:a0c:b659:: with SMTP id q25mr249576qvf.29.1560368558495; Wed, 12 Jun 2019 12:42:38 -0700 (PDT) MIME-Version: 1.0 References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> <2347EC29-4F1B-4A67-9C96-632006CD2311@fugue.com> In-Reply-To: <2347EC29-4F1B-4A67-9C96-632006CD2311@fugue.com> From: farzaneh badii Date: Wed, 12 Jun 2019 15:42:12 -0400 Message-ID: To: Ted Lemon Cc: John Curran , Niels ten Oever , hrpc@irtf.org, Amelia Andersdotter Content-Type: multipart/alternative; boundary="000000000000a5e071058b259db7" Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 19:42:57 -0000 --000000000000a5e071058b259db7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So since John has not criticized me yet over the use of the word outrageous I hold back apologizing for using it, seems like he doesn't get offended quickly which I am thankful for. If the community wants me to apologize for the usage of this outrageous word, please let me know so that I send in my apology. Explanation: John's suggestions (including it as is) will have (in my opinion)many negative consequences. it is not clear what we mean by "harm".is it a cybersecurity issue? Or is it physical harm on others? it is not clear what is meant by "attribution". Is it about identification of a person? A network? what do we mean by legal remedy and access to legal remedy? The document John points to about attribution (the BCP) has been criticized before. https://tools.ietf.org/html/draft-andersdotter-intarea-update-to-rfc6302-00= so there are controversies surrounding this issue, and we have not discussed whether what John is arguing is a human right issue that we should consider in HRPC. And usage of the term "public safety" (which is not in John's suggested text but in RFC 6302) is ambiguous. By public safety, do we mean law enforcement queries? what sort of queries? fighting with cybercrime? or street crime? consumer protection? This is actually an interesting case to look at and see how RFC 6302 been implemented and how it has helped "public safety" queries. Maybe it will lead us to revisit RFC 6302 :) Farzaneh On Wed, Jun 12, 2019 at 2:06 PM Ted Lemon wrote: > On Jun 12, 2019, at 1:48 PM, farzaneh badii > wrote: > > Frankly, John, what you are suggesting is outrageous. > > > I=E2=80=99m having trouble seeing what John has said that=E2=80=99s outra= geous. Rather > than simply saying it=E2=80=99s outrageous and hoping that we will see wh= at you > mean, could you please tell us what you think he has said that is > outrageous, and what about it is outrageous? I say =E2=80=9Cthink he ha= s said=E2=80=9D > because it=E2=80=99s also possible that there is a misunderstanding here,= and > that=E2=80=99s why I=E2=80=99m not seeing it. > > > --000000000000a5e071058b259db7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So since John has not criticized me yet over the use of the wor= d outrageous I hold back apologizing for using it, seems like he doesn'= t get offended quickly which I am thankful for. If the community wants me t= o apologize for the usage of this outrageous word, please let me know so th= at I send in my apology.=C2=A0

Explanation: John's suggestions (in= cluding it as is) will have (in my opinion)many negative consequences.=C2= =A0 it is not clear what we mean by "harm".is it a cybersecurity = issue? Or is it physical harm on others?=C2=A0 =C2=A0it is not clear what i= s meant by "attribution". Is it about identification of a person?= A network?=C2=A0 =C2=A0what do we mean by legal remedy and access to legal= remedy? The document John points to about attribution (the BCP) has been c= riticized before.=C2=A0https://tools.ietf.org/html/draft-andersdotter-intarea-update-to-= rfc6302-00=C2=A0so there are controversies surrounding this issue, and = we have not discussed whether what John is arguing is a human right issue t= hat we should consider in HRPC. And usage of the term "public safety&q= uot; (which is not in John's suggested text but in RFC 6302) is ambiguo= us. By public safety, do we mean law enforcement queries? what sort of quer= ies? fighting with cybercrime? or street crime? consumer protection?=C2=A0<= br>

=C2=A0This is actually an interesting case to look at and see how = RFC 6302 been implemented and how it has helped "public safety" q= ueries. Maybe it will lead us to revisit RFC 6302 :)=C2=A0


=

<= /div>
=


Farzaneh


On Wed, Jun 12, 2019= at 2:06 PM Ted Lemon <mellon@fugue.= com> wrote:
On Jun 12, 2019, at 1:48 PM, f= arzaneh badii <farzaneh.badii@gmail.com> wrote:
=
Frankly, John, w= hat you are suggesting is outrageous.=C2=A0

I=E2=80=99m having trouble seeing what John has said that=E2=80=99s= outrageous. =C2=A0 Rather than simply saying it=E2=80=99s outrageous and h= oping that we will see what you mean, could you please tell us what you thi= nk he has said that is outrageous, and what about it is outrageous? =C2=A0 = I say =E2=80=9Cthink he has said=E2=80=9D because it=E2=80=99s also possibl= e that there is a misunderstanding here, and that=E2=80=99s why I=E2=80=99m= not seeing it.


--000000000000a5e071058b259db7-- From nobody Wed Jun 12 13:00: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 5DE66120114 for ; Wed, 12 Jun 2019 13:00:45 -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=outbound.mailhop.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 lmKRXnsjLQXs for ; Wed, 12 Jun 2019 13:00:41 -0700 (PDT) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 0D246120179 for ; Wed, 12 Jun 2019 12:59:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560369577; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=e1rBbWScQNUfFoBnKs6oVyRNn05FUQkZm/zC5rGaD7BNFO2nXyxc4Ce/xYLplhau5Rr3S1UItKbqL mQuV52HMKc6nYDg+rEY5FoWtnHn05WkSjy82wTWcwbjOVEjStq2Az3XB4LhmG3VFMUDB8+7VVnxEge 6l7LNQFY55h7i/n2/tkk2m4yAPDHZAesHCJHQeslaU6x+LMZQxZ4eF/V2lbjnxRaMH9CuWDgvQBoL6 DSMgo3DWcuFy1qVsdMgZAxQFiifhle/47depkjCpgq1GeI+N9SHKpx5kQbwGN8UTKmPUHWgMheqcJ7 VMDclZIc/dHgO+jvEbkUXNimXYtNiaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:dkim-signature:from; bh=o486k4iy8aZkQB1eoLTlO/v7eVP8nAPVO+YN2/0iqrs=; b=cnMMw9zhuJuGjOMRqqngYhmhb0Y7QOW6wK8Yhj1JRVoz5AMfno/Vg9jee7vg7T3FhKep8VqhqODe0 y90liAOtRsr3+hCowFP/HZG7I2SzeDq5MIQM87cT60PnP3EjsiB1yMwp8w44sNq/fpyr0RGf5bKAHW X5ScqVlp77srLwZ4PYt13AeIU7QcrjzMgKvEIlUzAQfDKX+oxi3mIdunEhsDG9bYQWSRgDADcD4w1j zYd+B5i8nxAJ9/VG2c66MPJH9g7E5RKTwrHMtcXqo0SebQz48IAT5s5+p6CE3PmHkcOwH7Om/hcG0q b/bSqw1e7yjDNdIpkp7hi3lpFt3teQg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=istaff.org smtp.remote-ip=96.241.220.148; dmarc=none header.from=istaff.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:from; bh=o486k4iy8aZkQB1eoLTlO/v7eVP8nAPVO+YN2/0iqrs=; b=PIyQgdnTDbeYQpqPv1i794/6tnd5SAMyCkcpb0oTAYdCQnFTeM0Xx3LhNaFIWD19tL1JiIldmBpW1 x/QMycEsZO3RHQyXee+XYFCNZz5ug8ox3+BaCE733dlxuA9HCZXeOXq+gsFmHwyo7N4+WEn8smd6fT 6M69R4CJ8XLfy3603SGxRNkpWODpdggAhdUwKUmfeC4Kxf6TXfMp/7w0e1U04IgozO+PxDRr3x+UhF 1B4hY7YA1txC+2UtG1OgiqeVmGVGdLw1H/uqj0AX5CEwLMEx5VrhEHX40PhGS7Vj7tvrGPUiOJnLQT xvlFdw/k08Jxd1xHml/jnzjKO7ACHfg== X-MHO-RoutePath: amN1cnJhbg== X-MHO-User: 980cdb24-8d4c-11e9-b39b-9d2c53d3dedb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 96.241.220.148 X-Mail-Handler: DuoCircle Outbound SMTP Received: from geode.istaff.org (unknown [96.241.220.148]) by outbound4.ore.mailhop.org (Halon) with ESMTPA id 980cdb24-8d4c-11e9-b39b-9d2c53d3dedb; Wed, 12 Jun 2019 19:59:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id A4CC03BEA745; Wed, 12 Jun 2019 15:59:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at istaff.org Received: from geode.istaff.org ([127.0.0.1]) by localhost (geode.istaff.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bsNHBz6AxaM; Wed, 12 Jun 2019 15:59:30 -0400 (EDT) Received: from [172.20.0.75] (unknown [65.216.233.162]) by geode.istaff.org (Postfix) with ESMTPSA id CE98B3BEA72C; Wed, 12 Jun 2019 15:59:29 -0400 (EDT) From: John Curran Message-Id: <75BFC93D-8C5A-45C3-A68B-B3BBEF65390F@istaff.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_91C349A4-8840-41D0-BCB7-C03B385C1D8B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 12 Jun 2019 15:59:28 -0400 In-Reply-To: Cc: Amelia Andersdotter , hrpc@irtf.org, Niels ten Oever To: farzaneh badii References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> <992B79C0-5B80-4710-B8CF-D87BC80FA2C3@istaff.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 20:00:46 -0000 --Apple-Mail=_91C349A4-8840-41D0-BCB7-C03B385C1D8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 12 Jun 2019, at 2:49 PM, farzaneh badii = wrote: >=20 > Thanks John. That now makes better sense to me. We can discuss whether = it should be documented and how it should be documented. Agreed.=20 > But we need to consider many more aspects of it.=20 > We need to understand what "security" and "legal remedy" means in = IP. What is "harm"? Harm is a very controversial term which can be = interpreted in various ways. Even if we had perfect and globally recognized political norms for harms = from communications, we couldn=E2=80=99t ignore the potential need for = attribution to support legal remedy.=20 For example, protection of whistleblowers is widely recognized as an = important element necessary to underpin the right of freedom of = expression (and access to information), yet it often results in loss of = personal privacy and/or security for the individuals involve =E2=80=93 = most would agree that using communication technology to disclosure an = officials embezzlement of public funds is reasonable and yet disclosing = their spouse's serious medical condition is not appropriate. The = communication protocols are agnostic on content, and so we need to be = intellectually honest and document if a protocol=E2=80=99s attributes = preclude support for legal remedy. It doesn=E2=80=99t mean that such a = protocol is =E2=80=9Cbad=E2=80=9D but simply means that there=E2=80=99s = a conscious tradeoff that=E2=80=99s been made on prioritization of = functionality in favor of certain human rights (in that case freedom of = expression over legal remedy.)=20 > I suggest we have more discussion about the nuances before arguing = about the inclusion of your text.=20 I actually don=E2=80=99t feel particularly strongly about the inclusion = or omission of the =E2=80=9Cattribution=E2=80=9D attribute text, but = would prefer not having the final document characterized as guidelines = for assessment of =E2=80=9Cselect" human rights =E2=80=93 the offered = text is simply the best I=E2=80=99ve come up with in order "round out" = the overall effort.=20 Best wishes, /John p.s. Disclaimer: my views alone, and produced under the influence of = excessive caffeine - no warranty assumed or implied.=20 --Apple-Mail=_91C349A4-8840-41D0-BCB7-C03B385C1D8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 12 Jun 2019, at 2:49 PM, farzaneh badii <farzaneh.badii@gmail.com> wrote:

Thanks John. That now makes = better sense to me. We can discuss whether it should be documented and = how it should be documented.

Agreed. 

But we = need to consider many more aspects of it. 
We need = to understand what  "security" and "legal remedy"  means in = IP. What is "harm"? Harm is a very controversial term which can be = interpreted in various ways.

Even if we had perfect and globally = recognized political norms for harms from communications, we couldn=E2=80=99= t ignore the potential need for attribution to support legal = remedy. 

For example, = protection of whistleblowers is widely recognized as an important = element necessary to underpin the right of freedom of expression (and = access to information), yet it often results in loss of personal privacy = and/or security for the individuals involve =E2=80=93 most would agree = that using communication technology to disclosure an officials = embezzlement of public funds is reasonable and yet disclosing their = spouse's serious medical condition is not appropriate.  The = communication protocols are agnostic on content, and so we need to be = intellectually honest and document if a protocol=E2=80=99s attributes = preclude support for legal remedy.   It doesn=E2=80=99t mean that = such a protocol is =E2=80=9Cbad=E2=80=9D but simply means that there=E2=80= =99s a conscious tradeoff that=E2=80=99s been made on prioritization of = functionality in favor of certain human rights (in that case freedom of = expression over legal remedy.) 

I suggest we have more = discussion about the nuances before arguing about the inclusion of your = text. 

I = actually don=E2=80=99t feel particularly strongly about the inclusion or = omission of the =E2=80=9Cattribution=E2=80=9D attribute text, but would = prefer not having the final document characterized as guidelines for = assessment of =E2=80=9Cselect" human rights =E2=80=93 the offered text is simply the best = I=E2=80=99ve come up with in order "round out" the overall = effort. 

Best wishes,
/John

p.s.  Disclaimer: my views = alone, and produced under the influence of excessive caffeine - no = warranty assumed or implied. 

= --Apple-Mail=_91C349A4-8840-41D0-BCB7-C03B385C1D8B-- From nobody Wed Jun 12 13:13: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 D1175120105 for ; Wed, 12 Jun 2019 13:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.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 urrLQE3xocMz for ; Wed, 12 Jun 2019 13:13:55 -0700 (PDT) Received: from outbound1f.eu.mailhop.org (outbound1f.eu.mailhop.org [52.28.59.28]) (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 6C8DF120091 for ; Wed, 12 Jun 2019 13:13:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560370432; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=mtDPVRwAbDHEl1SBbaCYCO79TX3Hzz0PKuaMINXE8NR3zujt8P80Y2iTwWTuiWtpf1xzvaAUI4FPd mK5uwuGoqDUmVc3Q/lAstIKLkzKaYAmQqw87Xjm5U8ayU3ZPcchmtHJeHWOyuEqFGKXSZHGiIstCCs 9pg8Nr8k4XdCdhh+8Zbb0bEacEHY2BnjOgVH6nuG53ww/73RkIFLAZMUsP7d8i/gfI+aNuaLMHQLly k26kh4MvAd5i6YQT5trrFdPOybpgM82PSILrLdO7HWRx+t1DuS2WiTD4sosDAMKnuAxfX5q12XSxiv FcmFkB6u7UwSWv7/GUto1Yo56Vlpdkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:dkim-signature:from; bh=SAwaDj4m8U4PMVbDb6v9V46mBfXH1j6wxQjpe+AyaeQ=; b=RM9ZpZlDy7/P8kpj8DxQWIQWYqcy2R8cmyqFHhrykXJKdnoHXZvsYozFNVtrputC6Gj9ig5+7zI+e Dx2+mCnA4EMAd04+MIO0xggDoQLW7M+2+O6uW/HptQ4PF8iA14KSHmgXXCZFkT2/goFdkm3ZNetmXI 73tjLw4ao+Po+p/8iZBvT+beD4oKCmX1Bh+DHs0NJStfxbDXfa1GJgJ1u0NgzgmVqwwBXKzxd0AKgj sxS4I3nC2duuL8ebux3+iFb2T17a+bvpQHZYCyGPKmdf3oOotnM0Tzq0wPyQFXHqLVqGHuhwERMSmh JESglGUuo1QJEtKnoiBtP1z1m+E+unQ== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=pass smtp.mailfrom=istaff.org smtp.remote-ip=96.241.220.148; dmarc=none header.from=istaff.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:from; bh=SAwaDj4m8U4PMVbDb6v9V46mBfXH1j6wxQjpe+AyaeQ=; b=B6SORDTWeUM8X6XZMnouJKDzCb2mrG8KdvCiHVgqAVoqPiw7x4HIoHvgaEWh6WoWT1TVJwez17NyL IEsIL+atduC+5MAn8pY/Y4WdhfXJXQpAs2ykXpk8AHbIRqqYaB4FQaVciL2QKayEefWl49MM7chIA2 iX/vQcBOo5IbN1F2gKG+3Zj+JayWKt+N497XFlC63yvWIaAfIxtP18RBYoLk2rf9vv2J2YrypVVR3Z UGKoUW0LVVMo1RV11GI1DgI1rX7OGFm5n7rM2+rAWG0IulqLGKbqlXKWJa1fEW9vVV8XlajW9NdKNN ipWjuZzCslzfX0mXfkxWQWtay5/YJ8w== X-MHO-RoutePath: amN1cnJhbg== X-MHO-User: 959d93a7-8d4e-11e9-85c6-c97e5c048ed3 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 96.241.220.148 X-Mail-Handler: DuoCircle Outbound SMTP Received: from geode.istaff.org (unknown [96.241.220.148]) by outbound2.eu.mailhop.org (Halon) with ESMTPA id 959d93a7-8d4e-11e9-85c6-c97e5c048ed3; Wed, 12 Jun 2019 20:13:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id 997683BEAA4C; Wed, 12 Jun 2019 16:13:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at istaff.org Received: from geode.istaff.org ([127.0.0.1]) by localhost (geode.istaff.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZL1d2Y9e5hT; Wed, 12 Jun 2019 16:13:45 -0400 (EDT) Received: from [172.20.0.75] (unknown [65.216.233.162]) by geode.istaff.org (Postfix) with ESMTPSA id C6C9E3BEAA2B; Wed, 12 Jun 2019 16:13:45 -0400 (EDT) From: John Curran Message-Id: <28845DAD-58D6-4BF8-BF96-AEEE53228E79@istaff.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_B694E951-5904-47DC-9FF0-364C6FECFCF6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 12 Jun 2019 16:13:45 -0400 In-Reply-To: Cc: Ted Lemon , Niels ten Oever , hrpc@irtf.org, Amelia Andersdotter To: farzaneh badii References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> <2347EC29-4F1B-4A67-9C96-632006CD2311@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 12 Jun 2019 20:13:58 -0000 --Apple-Mail=_B694E951-5904-47DC-9FF0-364C6FECFCF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 12 Jun 2019, at 3:42 PM, farzaneh badii = wrote: >=20 > So since John has not criticized me yet over the use of the word = outrageous I hold back apologizing for using it, seems like he doesn't = get offended quickly which I am thankful for. If the community wants me = to apologize for the usage of this outrageous word, please let me know = so that I send in my apology.=20 I think it would be outrageous to seek such an apology, as your remarks = were made in good faith and did not intend any harm. =20 > Explanation: John's suggestions (including it as is) will have (in my = opinion)many negative consequences.=20 It might be helpful to elaborate somewhat on the negative consequences = that you foresee =E2=80=93 I=E2=80=99ll admit that the worst consequence = that I've envisioned is that those protocols which intentionally = preclude attribution will end up with a sentence in their HR assessment = to the effect that anonymity provided by the protocol also means that = parties who are harmed (via communications taking place over it) should = be aware that it may be challenging to seek legal recourse against the = perpetrator.=20 This isn=E2=80=99t exactly surprising, and reflects many of the Internet = protocols that we use today.=20 Thanks, /John=20 p.s. Disclaimer: my views alone, in individual serving size and not = packaged for any resale.=20 --Apple-Mail=_B694E951-5904-47DC-9FF0-364C6FECFCF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 12 Jun 2019, at 3:42 PM, farzaneh badii <farzaneh.badii@gmail.com> wrote:

So since John has not = criticized me yet over the use of the word outrageous I hold back = apologizing for using it, seems like he doesn't get offended quickly = which I am thankful for. If the community wants me to apologize for the = usage of this outrageous word, please let me know so that I send in my = apology. 

I = think it would be outrageous to seek such an apology, as your remarks = were made in good faith and did not intend any harm.  

Explanation: John's suggestions = (including it as is) will have (in my opinion)many negative = consequences. 

It might be helpful to elaborate somewhat on the = negative consequences that you foresee =E2=80=93 I=E2=80=99ll admit that = the worst consequence that I've envisioned is that those protocols which = intentionally preclude attribution will end up with a sentence in their = HR assessment to the effect that anonymity provided by the protocol also = means that parties who are harmed (via communications taking place over = it) should be aware that it may be challenging to seek legal recourse = against the perpetrator. 

This = isn=E2=80=99t exactly surprising, and reflects many of the Internet = protocols that we use today. 

Thanks,
/John 

p.s. Disclaimer:  my views alone, in = individual serving size and not packaged for any = resale. 

= --Apple-Mail=_B694E951-5904-47DC-9FF0-364C6FECFCF6-- From nobody Thu Jun 13 10:39: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 BBDB61201A3 for ; Thu, 13 Jun 2019 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 E0p-nllfVBMv for ; Thu, 13 Jun 2019 10:39:15 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) (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 2E386120046 for ; Thu, 13 Jun 2019 10:39:15 -0700 (PDT) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id x5DHcjXO015507; Thu, 13 Jun 2019 13:38:47 -0400 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id x5DHcdwS007658; Thu, 13 Jun 2019 13:38:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23810.35359.59791.395355@gargle.gargle.HOWL> Date: Thu, 13 Jun 2019 13:38:39 -0400 From: bzs@theworld.com To: John Curran Cc: farzaneh badii , Niels ten Oever , hrpc@irtf.org, Amelia Andersdotter In-Reply-To: <75BFC93D-8C5A-45C3-A68B-B3BBEF65390F@istaff.org> References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> <992B79C0-5B80-4710-B8CF-D87BC80FA2C3@istaff.org> <75BFC93D-8C5A-45C3-A68B-B3BBEF65390F@istaff.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.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, 13 Jun 2019 17:39:17 -0000 When something like this comes up I tend to wait for someone with legal training to chime in but it rarely happens. I guess such a person needs a retainer first. I have my doubts that a right to legal remedy, which is reasonable, implies any particular set of a priori evidence capture rights. My sense is this falls more in the regulatory arena, if anywhere. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Fri Jun 14 03:09: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 015541201E8 for ; Fri, 14 Jun 2019 03:09: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, 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 Rf2TUR6UBcHr for ; Fri, 14 Jun 2019 03:08: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 B5B1E120221 for ; Fri, 14 Jun 2019 03:08: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 1hbj8D-0007N8-6J for hrpc@irtf.org; Fri, 14 Jun 2019 12:08:55 +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: Date: Fri, 14 Jun 2019 11:08:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 919fae14bc17c74543a025539baad412 Archived-At: Subject: [hrpc] Agenda for IETF 105 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, 14 Jun 2019 10:09:01 -0000 Hi everyone, I'd like to start a thread about the agenda for discussion on the list. * JC de Martin would like to talk about Ethical and Socially Aware Data Labels, as per this research project: https://nexa.polito.it/node/1515 * Discussion on draft Political, and if it is ready for publication. * Discussion on draft Association, led by the new editors Joe and St=C3=A9= phane. * Discussion on recent updates to drafts Feminism and Guidelines. * Moving from the Guidelines draft into short presentations on any learnings gleaned from recent reviews informed by RFC 8280. * AOB. Are there any other items you would like to add to the agenda? Any other thoughts or ideas are also welcomed. Thanks, -Mallory --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Fri Jun 28 16:07:39 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 90BE812095A; Fri, 28 Jun 2019 15:58:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: hrpc@irtf.org, irtf-chair@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176269158.11015.13001191297529145693.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:11 -0700 Archived-At: Subject: [hrpc] hrpc - Requested session has been scheduled for IETF 105 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, 28 Jun 2019 23:07:17 -0000 Dear Mallory Knodel, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. hrpc Session 1 (2:00 requested) Tuesday, 23 July 2019, Morning Session I 1000-1200 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/hrpc.ics Request Information: --------------------------------------------------------- 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: First Priority: dprive gaia irtfopen pearg Second Priority: mls doh regext Third Priority: capport dnsop People who must be present: Avri Doria Mallory Knodel Resources Requested: Special Requests: Please try to schedule for Tuesday if possible so that co-chair Avri Doria can be present. Thank you! ---------------------------------------------------------