Re: [hrpc] Draft association : Extended literature review

Eliot Lear <lear@cisco.com> Wed, 24 June 2020 14:38 UTC

Return-Path: <lear@cisco.com>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B2D3A0E81 for <hrpc@ietfa.amsl.com>; Wed, 24 Jun 2020 07:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQF8PN0_M_Tu for <hrpc@ietfa.amsl.com>; Wed, 24 Jun 2020 07:38:32 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A2C3A0E73 for <hrpc@irtf.org>; Wed, 24 Jun 2020 07:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23417; q=dns/txt; s=iport; t=1593009512; x=1594219112; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=jM5sVpc5VeiqzCW/7ZJcPR6P4fKzL5O/AtLYOoKdja4=; b=h9BjUrptcc/g68OZVL4rBUpJMMIBN8m7rqjaGxG+u1dabFNfZntupjc1 P6XuDogbmLU+WvHNR9rnPC27Kc5UJg81MKYQcD4xel97hbymBP06/NeKG hOJCfS+7ToSE9nV5/VrdP+KuiT1034XIle/t+JML4eR3iuMI/Cj8gIk/B g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BfAADIZPNe/xbLJq1mGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQGCCgKBIQGBdVQBIBIshCSJAYgKmhmBaAsBAQEMAQEYAQoMBAEBhEcCghYlOBMCAwEBCwEBBQEBAQIBBgRthVsMQgEMAYUiAQEBAQIBAQEhSwsFCwsOAwEDAQEBIAcDAgInHwMGCAYTgyYBglwgD7YXdoEyhVGEawaBOAGMfIIAgTgcgk0+gkUXAYEmEjAugl4zgi0Ej0qlHYJkgwOLZoJUh3IDHZENjXaMH6AWg08CBAYFAhWBaiKBVjMaCBsVGiEqAYI+PhIZDY4qF4hihUEDPwMwNwIGAQcBAQMJhiaIbYJFAQE
X-IronPort-AV: E=Sophos; i="5.75,275,1589241600"; d="scan'208,217"; a="27408320"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 14:38:27 +0000
Received: from [10.61.241.223] ([10.61.241.223]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 05OEcQMZ024362 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 14:38:27 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <11E5C6E1-1CA2-4AD7-8E72-7E82B12EB876@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F961AF9D-F1EA-49AB-A7A8-3974FA780D38"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 24 Jun 2020 16:38:26 +0200
In-Reply-To: <c16314c5-5e71-fcd1-e14f-574a4c5ed84d@cdt.org>
Cc: Stéphane Couture <listes@stephcouture.info>, Hrpc <hrpc@irtf.org>
To: Mallory Knodel <mknodel@cdt.org>
References: <CANZrNV_RW4aGK+cJS+_DP5j=yG7QDF2gsjzkMgvuqUCRTuqUhQ@mail.gmail.com> <BY5PR06MB6451F9CDCB6EA6BA2A731DA7B1940@BY5PR06MB6451.namprd06.prod.outlook.com> <c16314c5-5e71-fcd1-e14f-574a4c5ed84d@cdt.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.241.223, [10.61.241.223]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/f3NcgnokSbKt6L7gjMLALLTX0KE>
Subject: Re: [hrpc] Draft association : Extended literature review
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: hrpc discussion list <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 14:38:43 -0000

That’s a nice piece of work, Stéphane.  Your questions are good ones.

A caution: as we discussed before, there are other rights involved, and the intersection of those rights also has to be considered by protocol developers.

Eliot

> On 24 Jun 2020, at 16:01, Mallory Knodel <mknodel@cdt.org> wrote:
> 
> I find them fascinating, too.
> 
> Co-chair hat: I wonder if we can agree that the way forward with this draft is to try to answer those questions in the form of specific case studies. This means that we will likely use some of the case studies that are already there, but not all, and there would be quite a bit of writing to do.
> 
> The second part of agreeing on a way forward is recognising Stéphane's heroic work on this and thinking about replacing his capacity as well as adding research and writing capacity back onto the "team" with this new direction.
> 
> Joe, are you still able to work on this as an editor?
> 
> Anyone able to step in to help me write?
> 
> -Mallory
> 
> On 6/23/20 6:55 PM, Joseph Lorenzo Hall wrote:
>> Thank you for this, Stéphane... the list of questions from the literature review are fascinating (so is the literature review!).
>> From: hrpc <hrpc-bounces@irtf.org> <mailto:hrpc-bounces@irtf.org> on behalf of Stéphane Couture <listes@stephcouture.info> <mailto:listes@stephcouture.info>
>> Sent: Monday, June 22, 2020 23:04
>> To: Hrpc <hrpc@irtf.org> <mailto:hrpc@irtf.org>
>> Subject: [hrpc] Draft association : Extended litterature review
>>  
>> Dear all,
>> 
>> I'd like to finally send you - in odt format, not on github (sorry for this) - the work I did in expanding the literature review on draft association. Thank you  Mallory for a the few working sessions we had in the last weeks on this, and to Melinda Shore for converting the document in Word and all other who discussed with me before (Niels and Avri, notably)
>> 
>> At this point, I'd like to pass the responsibility of the draft to someone else as I have difficulties bringing this draft to another step, both because of lack of time and lack of vision on how to proceed from there while keeping the "spirit" of the initial draft. 
>> 
>> In this document, I am only sending you the first part of the draft (literature review), which is the part I worked. My approach was to start with what exists in the literature review, and then raise questions that are relevant to IETF and protocol development more broadly. The section on "Cases and examples" is not included in this document, as I did not work on it, and still don't know what to do with it. In particular, I feel it is not aligned with the questions raised by the literature. 
>> 
>> One important thing in this document is that we tried (again) to change the central question. It is now : "What are the considerations of the right to freedom of assembly and association for protocol development?", which seems more aligned to the research group title. The original question was "How does the architecture of the internet enable and/or inhibit the right to freedom of assembly and association?". I think these two questions do not orient us exactly to the same analysis, something that I feel might be important to note.
>> 
>> And here are other questions I felt were raised from the literature review. Maybe just raising the questions could be a good contribution in itself... 
>> 
>> 1. As a general matter, what are the features of protocols that enable freedom of association and assembly? Can protocols facilitate agency of membership in associations, assemblies and interactions? Where in the stack do we care for FAA?
>> 
>> 2. Does protocol development sufficiently consider the enabling of freedom of association without discrimination as to race, colour, national, ethnic origin?
>> 
>> 3.  Does protocol development sufficiently consider usable and accessible formats and technologies appropriate for persons with different kinds of disabilities?
>> 
>> 4.  Is it possible to distinguish “peaceful” and “non-peaceful” association from the perspective of protocol development? If yes, can and should protocols be designed to limit “non-peaceful” association?
>> 
>> 5. In particular, should protocols be designed to enable legitimate limitations on association in the interests of “national security or public safety, public order, the protection of public health or morals or the protection of the rights and freedoms of others”, as stated in the ICCPR article 21?  
>> 
>> 6. Can a protocol be designed to legitimately exclude someone from an association?
>> 
>> 7. In general, what kind of human rights impact assessments should be made to incorporate the rights to freedom of peaceful assembly and of association when developing protocols, as recommended by SpecialRapporteur on the rights to freedom of peaceful assembly and of association.
>> 
>> I hope this would be helpful,
>> 
>> Best,
>> 
>> Stéphane
>> 
>> 
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org <mailto:hrpc@irtf.org>
>> https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>
> -- 
> Mallory Knodel
> CTO, Center for Democracy and Technology
> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org <mailto:hrpc@irtf.org>
> https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>