From nobody Tue Feb 4 10:26:37 2020 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 68C95120856; Tue, 4 Feb 2020 10:26:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" , "IRTF-Announce" Cc: hrpc@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158084077528.15685.419463045858710861@ietfa.amsl.com> Date: Tue, 04 Feb 2020 10:26:15 -0800 Archived-At: Subject: [hrpc] Human Rights Protocol Considerations (hrpc) RG Virtual Meeting: 2020-02-25 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: Tue, 04 Feb 2020 18:26:15 -0000 The Human Rights Protocol Considerations (hrpc) Research Group will hold a virtual interim meeting on 2020-02-25 from 16:00 to 18:00 GMT. Agenda: Discuss rework of draft-irtf-hrpc-association. Specific to be provided. Information about remote participation: Zoom info to be provided From nobody Fri Feb 14 13:54:17 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497C51200C1 for ; Fri, 14 Feb 2020 13:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 rtTU3tDLGHTw for ; Fri, 14 Feb 2020 13:54:13 -0800 (PST) Received: from homere.koumbit.net (homere.koumbit.net [199.58.80.81]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0EB120013 for ; Fri, 14 Feb 2020 13:54:06 -0800 (PST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: steph@stephcouture.info) by homere.koumbit.net (Postfix) with ESMTPSA id 4C44D1E40E4D for ; Fri, 14 Feb 2020 16:54:04 -0500 (EST) Received: by mail-wm1-f46.google.com with SMTP id t23so11500409wmi.1 for ; Fri, 14 Feb 2020 13:54:04 -0800 (PST) X-Gm-Message-State: APjAAAXP8A8qj7ulU1wHrojpg9xR4amLpoK0nPaDz6u2/nA5Lp+kxRro Fu6lmy/HqUY0CHWVsPU3aknHy0k0n6VHJNYSMtY= X-Google-Smtp-Source: APXvYqxTNAHz+hCXMheLGHJX5bsEqcutTOiRnuUGkmIQnqZfH2LCBY2vO0//6knLyI02T4wat9TSm23iBjK8qU/MFD0= X-Received: by 2002:a7b:ce0b:: with SMTP id m11mr6852217wmc.4.1581717243484; Fri, 14 Feb 2020 13:54:03 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?St=C3=A9phane_Couture?= Date: Fri, 14 Feb 2020 16:53:47 -0500 X-Gmail-Original-Message-ID: Message-ID: To: hrpc@irtf.org Content-Type: multipart/alternative; boundary="0000000000006ee029059e903e9a" Archived-At: Subject: [hrpc] Draft-association : report from last meeting 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 Feb 2020 21:54:16 -0000 --0000000000006ee029059e903e9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Sorry for the delays, but here is a report I made from our last Zoom meeting about draft-association, that we held two weeks ago. Sorry also for the typos. As stated in this report and announced previously, the next meeting will be on February 25th from 16:00 to 18:00 GMT, and will be an interim meeting (Avri or Mallory could say more on this). 0. Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D St=C3=A9phane, Niels, Avri, Mallory (for the first part), Juliana 1. Editorial team =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Since Joe doesn=E2=80=99t have much time, Niels is still participating and = Juliana wants to participate more, but doesn=E2=80=99t know to what extent. We have= decided to make an =C2=AB open =C2=BB editorial committee for now, and we will deci= de later on the order of authors, based on who has contributed the more (overall, not just in terms of commits on the git hub). St=C3=A9phane is ok to follow= up on coordination until the next IETF but we will need a co-editor after. 2. Report from first seminar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D St=C3=A9phane presented some of the stuff we discussed in the first seminar= . See the slides : https://framadrop.org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VFv0jK= AmU=3D For the goals, it was suggested that we reframe the goal to =E2=80=9Cexplor= e and map the relationships.=E2=80=9D As for the goals: Niels mentioned that the goal is to explore the relationships, before making some recommendations. For instance, you have to study =E2=80=93 and establish =E2=80=93 the relationships between drinki= ng and driving, before making decision related to this. This might raise (again) the point of the theoretical framework we use to =E2=80=9Cexplore=E2=80=9D these rela= tionships. If our aim is to establish some kind of causality =E2=80=93 as we would do for drinking and driving =E2=80=93 an interpretative framework might not be the= best for this. 3. Work since the last seminar: literature review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D St=C3=A9phane presented his work on enhancing literature review. A few more documents addressing explicitly the relations between =E2=80=9Cfreedom of association and assembly=E2=80=9D and =E2=80=9Cthe digital=E2=80=9D were fo= und. In particular, a draft document from the European Council that was not known to us, presented some social cases (slide 12), that could be re-used in the research. We still had debates about the relevance of starting with social cases rather than technological cases (as it is right now in draft-association). It was agreed that these references should be briefly added to the draft-association. Niels mentioned that all the cases identified in this document have already been discussed on the list and that it would be important to look at how it plays out in =E2=80=9Carchitectural=E2=80=9D la= yers relevant to IETF. For instance, the design of encryption is an inherent part of protocols, or using source routing. If we can show that these choices can make association or joining easier or more difficult, it would be good. Note about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use here =E2= =80=9Cinfrastructure=E2=80=9D in a general sense to refer to the =E2=80=9Cbehind the scenes=E2=80=9D of norm= al internet usages, especially protocols. Infrastructural is thus opposed here to =E2=80=9Cpolicy=E2=80=9D or =E2=80=9Ceconomic=E2=80=9D dimensions. What we = are interested in here is the broad scope of IETF work, not the specific realm of how =E2=80=9Cinfrastruc= ture=E2=80=9D is used within IETF. To avoid confusion, it was proposed that we talk about the =E2=80=9Carchitecture of the Internet=E2=80=9D, instead of the =E2=80= =9Cinfrastructure of the Internet.=E2=80=9D We also presented a summary of an encyclopedia article about =E2=80=9Cfreed= om of association=E2=80=9D, where they present a nuanced version of freedom of association. It was mentioned that in an earlier version, Gisela made a similar work, but it was considered too =E2=80=9Clegal=E2=80=9D. We might w= ant to look at this previous version of the draft 4. The cases =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We still had some discussions about the current cases, and especially the way in which they inhibit association. We went through the difference case studies, and discussing their enabling or disabling capacity. This part of the discussion was fully transcribed. It is proposed that we create a table to address each of these cases, which will help in turn clarifying the argument. See the table here : https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUd= Mu80/edit?usp=3Dsharing 4. What=E2=80=99s next =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The next meeting will be an =E2=80=98interim meeting=E2=80=9D, so we will b= e able to have formal decisions. 1. By the next meeting, we should have a table that analyzes the way in which protocols mentioned in the paper inhibit or enable association. This table should be done collaboratively.: https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUd= Mu80/edit?usp=3Dsharing 2. In the next meeting we should decide if we analyze more thoroughly social cases, or we stick to the cases currently in the paper. If we go and analyze social cases, it might make the paper stronger, but it would probably take much more time. 3. A =E2=80=9Cdiff=E2=80=9D should be presented in the next meeting, so it = is approved. 4. Make sure we resubmit the draft (by March 8th, 2020). --0000000000006ee029059e903e9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=09 =09

Hi all,

Sorry for the delays, but here is a rep= ort I made from our last Zoom meeting about draft-association, that we held= two weeks ago. Sorry also for the typos.

As stated in this report and announced previously, the = next meeting will be on February 25th=C2=A0=C2=A0from 16:00 to 18:00 GMT, a= nd will be an interim meeting (Avri or Mallory could say more on this).=C2= =A0

0. Participants=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane, Niels, Avri, Mallory (for the first part), Juli= ana

1. Editorial team
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Since Joe doesn=E2=80=99t have much time, Niels is still participating and Juliana wants to participate more, but doesn=E2=80=99t know to what extent. We have decided to make an =C2=AB=C2=A0open=C2=A0=C2=BB editorial committee for now, and we will decide later on the order of authors, based on who has contributed the more (overall, not just in terms of commits on the git hub). St=C3=A9phane is ok to follow up on coordination until the next IETF but we will need a co-editor after.

2. Report from first seminar=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane presented some of the stuff we discussed in the first seminar. See the slides=C2=A0:
https://framadrop.org/r/jgvRpOZUq6#= VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VFv0jKAmU=3D

For the goals, it was suggested that we reframe the goal to =E2=80=9Cexplore and map the relationships.=E2=80=9D

As for the goals: Niels mentioned that the goal is to explore the relationships, before making some recommendations. For instance, you have to study =E2=80=93 and establish =E2=80=93 the relationships between drinking and driving, before making decision related to this. This might raise (again) the point of the theoretical framework we use to =E2=80=9Cexplore=E2=80=9D these relationships. If our aim is to establish some kind of causality =E2=80=93 as we would do for drinking and driving =E2=80=93 an interpretative framework might not be the best for this.=20

3. Work since the last seminar: literature review
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane presented his work on enhancing literature review. A few more documents addressing explicitly the relations between =E2=80=9Cfreedom of association and assembly=E2=80=9D and =E2=80=9Cthe digital=E2=80=9D were fo= und. In particular, a draft document from the European Council that was not known to us, presented some social cases (slide 12), that could be re-used in the research. We still had debates about the relevance of starting with social cases rather than technological cases (as it is right now in draft-association).=20

It was agreed that these references should be briefly added to the draft-association. Niels mentioned that all the cases identified in this document have already been discussed on the list and that it would be important to look at how it plays out in =E2=80=9Carchitectural=E2=80=9D layers relevant= to IETF. For instance, the design of encryption is an inherent part of protocols, or using source routing. If we can show that these choices can make association or joining easier or more difficult, it would be good.=20

Note about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use here =E2=80=9Cinfrastru= cture=E2=80=9D in a general sense to refer to the =E2=80=9Cbehind the scenes=E2=80=9D of norm= al internet usages, especially protocols. Infrastructural is thus opposed here to =E2=80=9Cpolicy=E2=80=9D or =E2=80=9Ceconomic=E2=80=9D dime= nsions. What we are interested in here is the broad scope of IETF work, not the specific realm of how =E2=80=9Cinfrastructure=E2=80=9D is used within IETF.= To avoid confusion, it was proposed that we talk about the =E2=80=9Carchitectu= re of the Internet=E2=80=9D, instead of the =E2=80=9Cinfrastructure of the Internet.=E2=80=9D=20

We also presented a summary of an encyclopedia article about =E2=80=9Cfreedom of association=E2=80=9D, where they present a nuanced version of freedom of association. It was mentioned that in an earlier version, Gisela made a similar work, but it was considered too =E2=80=9Clegal=E2=80=9D. We might= want to look at this previous version of the draft

4. The cases
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We still had some discussions about the current cases, and especially the way in which they inhibit association. We went through the difference case studies, and discussing their enabling or disabling capacity. This part of the discussion was fully transcribed.=C2=A0 It is proposed that we create a table to address each of these cases, which will help in turn clarifying the argument. See the table here :
https://docs.go= ogle.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp= =3Dsharing

4. What=E2=80=99s next
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The next meeting will be an =E2=80=98interim meeting=E2=80=9D, so we will be able to have fo= rmal decisions.

1. By the next meeting, we should have a table that analyzes the way in which protocols mentioned in the paper inhibit or enable association. This table should be done collaboratively.:
https://docs.go= ogle.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp= =3Dsharing

2. In the next meeting we should decide if we analyze more thoroughly social cases, or we stick to the cases currently in the paper. If we go and analyze social cases, it might make the paper stronger, but it would probably take much more time.

3. A =E2=80=9Cdiff=E2=80= =9D should be presented in the next meeting, so it is approved.

4. Make sure we resubmit the draft (by March 8th, 2020).

--0000000000006ee029059e903e9a-- From nobody Sat Feb 15 11:24:20 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FBB1200F1 for ; Sat, 15 Feb 2020 11:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CEX3CD6A8K8 for ; Sat, 15 Feb 2020 11:24:15 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351131200E3 for ; Sat, 15 Feb 2020 11:24:14 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 92C681800F5B9 for ; Sat, 15 Feb 2020 19:24:13 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:2:41:152:355:379:800:854:877:966:967:973:988:989:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1513:1515:1516:1518:1521:1535:1593:1594:1605:1719:1730:1747:1777:1792:2194:2196:2198:2199:2200:2201:2393:2525:2553:2568:2627:2682:2685:2693:2731:2741:2859:2910:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4120:4184:4250:4321:4362:4385:4425:4560:4860:5007:6117:6119:7652:7875:7903:8784:8957:9010:9025:9108:9164:10004:10848:11232:11658:11783:11914:12043:12050:12058:12291:12297:12379:12438:12555:12679:12683:12740:12895:12903:12986:13053:13158:13228:13845:13846:13972:14095:14877:21060:21063:21080:21324:21433:21450:21451:21483:21627:21652:21740:21881:21939:30003:30034:30054:30060:30080:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none X-HE-Tag: kite32_5f05b2e74dd62 X-Filterd-Recvd-Size: 9985 Received: from [192.168.0.16] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf15.hostedemail.com (Postfix) with ESMTPA for ; Sat, 15 Feb 2020 19:24:12 +0000 (UTC) To: hrpc@irtf.org References: From: avri@doria.org Autocrypt: addr=avri@doria.org; prefer-encrypt=mutual; keydata= mQENBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAG0G2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPokBPAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEda5AQ0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAYkCPgQYAQIACQIbLgUCWb5voAEpwF0gBBkB AgAGBQJSV4Z7AAoJEOo+L8tCe36HTvYH/RXrGi8imCvHou7US+pua51wTQrWghz6nEaavtFR +k5wHrf7WdjxEdDaJnb0YZki5IiEyqhHEq9Tb0JMCye4rzgWpvd1Z8JJ2FXmY8EjuRZg1sP3 3bvxm1hM7qsPCTWXzn1eHY3i5zAdtEEk0h+isLmEuuFWhGNwzyb0BC/h84YHylqv7/bMrHUz CtkUKdO2Vx0W8e/EWUDfLJnHtvTFTT1E/koOnWErJfmKhq2G6rMv13XsU7vr9AWZ6vDA3z2o sCHWkA2gkhU7TwHqPkY9HPoekUXlR/n11jBS9Jwx4Dnsyd7pqaRHxoyRqfEWTi8JF+N+XzC3 buf3G3buW3BDmNcJENWp6aLJ/w+n+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2E= Message-ID: <0c4b56f6-9d4b-4d22-ef3b-10059e1c9fb7@doria.org> Date: Sat, 15 Feb 2020 14:24:11 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Antivirus: Avast (VPS 200214-0, 02/14/2020), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] Interim meeting - 25 Feb 16 UTC X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 19:24:18 -0000 Hi, Thanks St=C3=A9phane for the report. This interim has been registered with the secretariat and been announced on list and elsewhere. Hope people saw the announcement. It is scheduled for: 25 Feb 1600 - 1800 UTC St=C3=A9phane is providing the zoom room for the meeting: 1. Zoom : https://yorku.zoom.us/j/234314123 Meeting ID: 234 314 123 Find your local number: https://yorku.zoom.us/u/avFFYbR4w Draft Agenda - Single issue: draft-association - Welcome & Agenda review - Summary of discussion/work since last HRPC mtg - Discussion on next steps for draft - Discussion of cases to be included in draft - Recruit someone, or more, to work with St=C3=A9phane on completing the = draft - AOB Thanks avri On 14-Feb-20 16:53, St=C3=A9phane Couture wrote: > > Hi all, > > Sorry for the delays, but here is a report I made from our last Zoom > meeting about draft-association, that we held two weeks ago. Sorry > also for the typos. > > As stated in this report and announced previously, the next meeting > will be on February 25th=C2=A0=C2=A0from 16:00 to 18:00 GMT, and will b= e an > interim meeting (Avri or Mallory could say more on this).=C2=A0 > > 0. Participants > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > St=C3=A9phane, Niels, Avri, Mallory (for the first part), Juliana > > 1. Editorial team > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Since Joe doesn=E2=80=99t have much time, Niels is still participating = and > Juliana wants to participate more, but doesn=E2=80=99t know to what ext= ent. We > have decided to make an =C2=AB=C2=A0open=C2=A0=C2=BB editorial committe= e for now, and we > will decide later on the order of authors, based on who has > contributed the more (overall, not just in terms of commits on the git > hub). St=C3=A9phane is ok to follow up on coordination until the next I= ETF > but we will need a co-editor after. > > 2. Report from first seminar=C2=A0 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > St=C3=A9phane presented some of the stuff we discussed in the first > seminar. See the slides=C2=A0: > https://framadrop.org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VF= v0jKAmU=3D > > For the goals, it was suggested that we reframe the goal to =E2=80=9Cex= plore > and map the relationships.=E2=80=9D > > As for the goals: Niels mentioned that the goal is to explore the > relationships, before making some recommendations. For instance, you > have to study =E2=80=93 and establish =E2=80=93 the relationships betwe= en drinking and > driving, before making decision related to this. This might raise > (again) the point of the theoretical framework we use to =E2=80=9Cexplo= re=E2=80=9D > these relationships. If our aim is to establish some kind of causality > =E2=80=93 as we would do for drinking and driving =E2=80=93 an interpre= tative > framework might not be the best for this. > > 3. Work since the last seminar: literature review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > St=C3=A9phane presented his work on enhancing literature review. A few = more > documents addressing explicitly the relations between =E2=80=9Cfreedom = of > association and assembly=E2=80=9D and =E2=80=9Cthe digital=E2=80=9D wer= e found. In particular, > a draft document from the European Council that was not known to us, > presented some social cases (slide 12), that could be re-used in the > research. We still had debates about the relevance of starting with > social cases rather than technological cases (as it is right now in > draft-association). > > It was agreed that these references should be briefly added to the > draft-association. Niels mentioned that all the cases identified in > this document have already been discussed on the list and that it > would be important to look at how it plays out in =E2=80=9Carchitectura= l=E2=80=9D > layers relevant to IETF. For instance, the design of encryption is an > inherent part of protocols, or using source routing. If we can show > that these choices can make association or joining easier or more > difficult, it would be good. > > Note about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use here= > =E2=80=9Cinfrastructure=E2=80=9D in a general sense to refer to the =E2= =80=9Cbehind the > scenes=E2=80=9D of normal internet usages, especially protocols. > Infrastructural is thus opposed here to =E2=80=9Cpolicy=E2=80=9D or =E2= =80=9Ceconomic=E2=80=9D > dimensions. What we are interested in here is the broad scope of IETF > work, not the specific realm of how =E2=80=9Cinfrastructure=E2=80=9D is= used within > IETF. To avoid confusion, it was proposed that we talk about the > =E2=80=9Carchitecture of the Internet=E2=80=9D, instead of the =E2=80=9C= infrastructure of the > Internet.=E2=80=9D > > We also presented a summary of an encyclopedia article about =E2=80=9Cf= reedom > of association=E2=80=9D, where they present a nuanced version of freedo= m of > association. It was mentioned that in an earlier version, Gisela made > a similar work, but it was considered too =E2=80=9Clegal=E2=80=9D. We m= ight want to > look at this previous version of the draft > > 4. The cases > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We still had some discussions about the current cases, and especially > the way in which they inhibit association. We went through the > difference case studies, and discussing their enabling or disabling > capacity. This part of the discussion was fully transcribed.=C2=A0 It i= s > proposed that we create a table to address each of these cases, which > will help in turn clarifying the argument. See the table here : > https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAW= puUdMu80/edit?usp=3Dsharing > > 4. What=E2=80=99s next > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The next meeting will be an =E2=80=98interim meeting=E2=80=9D, so we wi= ll be able to > have formal decisions. > > 1. By the next meeting, we should have a table that analyzes the way > in which protocols mentioned in the paper inhibit or enable > association. This table should be done collaboratively.: > https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAW= puUdMu80/edit?usp=3Dsharing > > 2. In the next meeting we should decide if we analyze more thoroughly > social cases, or we stick to the cases currently in the paper. If we > go and analyze social cases, it might make the paper stronger, but it > would probably take much more time. > > 3. A =E2=80=9Cdiff=E2=80=9D should be presented in the next meeting, so= it is approved. > > 4. Make sure we resubmit the draft (by March 8^th , 2020). > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Sat Feb 15 21:17:06 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AF4120018 for ; Sat, 15 Feb 2020 21:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evAx9sdIG0Ab for ; Sat, 15 Feb 2020 21:17:01 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A16B120013 for ; Sat, 15 Feb 2020 21:17:01 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 5082918029121 for ; Sun, 16 Feb 2020 05:17:00 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:2:41:152:355:379:800:854:877:966:967:973:988:989:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1535:1593:1594:1605:1719:1730:1747:1777:1792:2194:2196:2198:2199:2200:2201:2393:2525:2553:2568:2627:2682:2685:2693:2731:2741:2859:2910:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4118:4184:4250:4321:4362:4385:4425:4560:4860:5007:6117:6119:7652:7875:7903:8784:8957:9010:9025:9108:9164:10004:10848:11232:11658:11783:11914:12043:12050:12058:12291:12379:12438:12555:12679:12683:12740:12895:12903:12986:13053:13158:13228:13845:13846:13894:13972:14095:14877:21060:21063:21080:21324:21433:21450:21451:21483:21627:21652:21740:21881:21939:30003:30034:30054:30060:30080:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rule X-HE-Tag: gate59_1ffd73fa25f27 X-Filterd-Recvd-Size: 7278 Received: from [192.168.0.2] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf01.hostedemail.com (Postfix) with ESMTPA for ; Sun, 16 Feb 2020 05:16:59 +0000 (UTC) From: avri doria To: hrpc@irtf.org References: Reply-To: avri@acm.org Message-ID: Date: Sun, 16 Feb 2020 00:16:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 200215-0, 02/15/2020), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] Interim meeting - 25 Feb 16 UTC 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, 16 Feb 2020 05:17:04 -0000 Hi, Thanks Stéphane for the report. This interim has been registered with the secretariat and been announced on list and elsewhere. Hope people saw the announcement. It is scheduled for: 25 Feb 1600 - 1800 UTC Stéphane is providing the zoom room for the meeting: 1. Zoom : https://yorku.zoom.us/j/234314123 Meeting ID: 234 314 123 Find your local number: https://yorku.zoom.us/u/avFFYbR4w Draft Agenda - Single issue: draft-association - Welcome & Agenda review - Summary of discussion/work since last HRPC mtg - Discussion on next steps for draft - Discussion of cases to be included in draft - Recruit someone, or more, to work with Stéphane on completing the draft - AOB Thanks avri On 14-Feb-20 16:53, Stéphane Couture wrote: > Hi all, > > Sorry for the delays, but here is a report I made from our last Zoom > meeting about draft-association, that we held two weeks ago. Sorry > also for the typos. > > As stated in this report and announced previously, the next meeting > will be on February 25th  from 16:00 to 18:00 GMT, and will be an > interim meeting (Avri or Mallory could say more on this).  > > 0. Participants > =========== > > Stéphane, Niels, Avri, Mallory (for the first part), Juliana > > 1. Editorial team > ============= > > Since Joe doesn’t have much time, Niels is still participating and > Juliana wants to participate more, but doesn’t know to what extent. We > have decided to make an « open » editorial committee for now, and we > will decide later on the order of authors, based on who has > contributed the more (overall, not just in terms of commits on the git > hub). Stéphane is ok to follow up on coordination until the next IETF > but we will need a co-editor after. > > 2. Report from first seminar  > ===================== > > Stéphane presented some of the stuff we discussed in the first > seminar. See the slides : > https://framadrop.org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VFv0jKAmU= > > For the goals, it was suggested that we reframe the goal to “explore > and map the relationships.” > > As for the goals: Niels mentioned that the goal is to explore the > relationships, before making some recommendations. For instance, you > have to study – and establish – the relationships between drinking and > driving, before making decision related to this. This might raise > (again) the point of the theoretical framework we use to “explore” > these relationships. If our aim is to establish some kind of causality > – as we would do for drinking and driving – an interpretative > framework might not be the best for this. > > 3. Work since the last seminar: literature review > ==================================== > > Stéphane presented his work on enhancing literature review. A few more > documents addressing explicitly the relations between “freedom of > association and assembly” and “the digital” were found. In particular, > a draft document from the European Council that was not known to us, > presented some social cases (slide 12), that could be re-used in the > research. We still had debates about the relevance of starting with > social cases rather than technological cases (as it is right now in > draft-association). > > It was agreed that these references should be briefly added to the > draft-association. Niels mentioned that all the cases identified in > this document have already been discussed on the list and that it > would be important to look at how it plays out in “architectural” > layers relevant to IETF. For instance, the design of encryption is an > inherent part of protocols, or using source routing. If we can show > that these choices can make association or joining easier or more > difficult, it would be good. > > Note about the notion of “infrastructural”: We use here > “infrastructure” in a general sense to refer to the “behind the > scenes” of normal internet usages, especially protocols. > Infrastructural is thus opposed here to “policy” or “economic” > dimensions. What we are interested in here is the broad scope of IETF > work, not the specific realm of how “infrastructure” is used within > IETF. To avoid confusion, it was proposed that we talk about the > “architecture of the Internet”, instead of the “infrastructure of the > Internet.” > > We also presented a summary of an encyclopedia article about “freedom > of association”, where they present a nuanced version of freedom of > association. It was mentioned that in an earlier version, Gisela made > a similar work, but it was considered too “legal”. We might want to > look at this previous version of the draft > > 4. The cases > =========== > > We still had some discussions about the current cases, and especially > the way in which they inhibit association. We went through the > difference case studies, and discussing their enabling or disabling > capacity. This part of the discussion was fully transcribed.  It is > proposed that we create a table to address each of these cases, which > will help in turn clarifying the argument. See the table here : > https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=sharing > > 4. What’s next > =========== > > The next meeting will be an ‘interim meeting”, so we will be able to > have formal decisions. > > 1. By the next meeting, we should have a table that analyzes the way > in which protocols mentioned in the paper inhibit or enable > association. This table should be done collaboratively.: > https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=sharing > > 2. In the next meeting we should decide if we analyze more thoroughly > social cases, or we stick to the cases currently in the paper. If we > go and analyze social cases, it might make the paper stronger, but it > would probably take much more time. > > 3. A “diff” should be presented in the next meeting, so it is approved. > > 4. Make sure we resubmit the draft (by March 8^th , 2020). > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Sun Feb 16 02:44:34 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284F212008C for ; Sun, 16 Feb 2020 02:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnzYZyL2T8-s for ; Sun, 16 Feb 2020 02:44:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6269120013 for ; Sun, 16 Feb 2020 02:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20706; q=dns/txt; s=iport; t=1581849869; x=1583059469; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=dbZ1tJ0OUyarJt2QSF2cdXLajp3YPRVTMasc5zaFlBY=; b=alwNu361m0q92I1y7fsfDePFaKM5Fb1DNPF38LjiJYED85c85r6/2P5+ 613/qjuy4gumV//lT4RZuGaVInfTPm6836mngUzmdypWjPGUeK1xaJRv2 mnJHQfyk95AeQ4thuham3GPOlTE7PP/W+bfAj0ez1MsdWhpdjOKBhxxXt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuCQADHEle/4kNJK1mFggBCxyDczF?= =?us-ascii?q?sVAEyKoQUjxGCEZMwiAoJAQEBDAEBGAEMCgQBAYRAAoIBJDgTAgMNAQEFAQE?= =?us-ascii?q?BAgEFBG2FNwyFZgEBAQEBAQEBASFLBAcFCwsSBioCAiciDgYTFIMSAYJbIA+?= =?us-ascii?q?rA3WBMoQ1ARNBQIUVgTiMFQ8aggCBEScggkw+aYFiGQEBAQEahFkygiwEjUB?= =?us-ascii?q?RiFWZGIJEgk+EfoVJhCsGhQwcg0SLPowYiiaNM48QgzECBAYFAhWBPyoiN4E?= =?us-ascii?q?hMxoIGxU7KgGCQQk1EhgNkhBqhCqFPgJAAzACjkkBAQ?= X-IronPort-AV: E=Sophos;i="5.70,448,1574121600"; d="scan'208,217";a="723034387" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Feb 2020 10:44:27 +0000 Received: from [10.82.183.244] ([10.82.183.244]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 01GAiPlu016912 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Feb 2020 10:44:26 GMT From: Eliot Lear Message-Id: <3C9A47B3-C7CB-4A3C-874D-F7475D72E71E@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_37D3C2BF-E9A1-4BA5-925C-8C07C647D6E2" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Sun, 16 Feb 2020 11:44:25 +0100 In-Reply-To: Cc: hrpc@irtf.org To: =?utf-8?Q?St=C3=A9phane_Couture?= References: X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Outbound-SMTP-Client: 10.82.183.244, [10.82.183.244] X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [hrpc] Draft-association : report from last meeting 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, 16 Feb 2020 10:44:32 -0000 --Apple-Mail=_37D3C2BF-E9A1-4BA5-925C-8C07C647D6E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi St=C3=A9phane Thanks for this. The CoE draft report is particularly interesting. One = aspect you may wish to explore is this notion of preventing the right to = peaceably assemble, versus conspiracy to commit mayhem. The same = technology can be used in each case, which is why the BART example seems = the most interesting to me. This also ties to prior restraint, and what = sort of judgments we make about its use versus evidence collection after = the fact. This leads to several lines of exploration: Can blocking be warranted in the name of public safety when there is a = demonstrable imminent threat? In the aftermath of a riot (let=E2=80=99s say), what tools should = government have to hold people accountable? I am taking it as a given that governments and others will exploit any = capability this ties to in our infrastructure. A question then arises: = how do we as a community assess those risks? If we add mechanisms at = all, how will Bad people (governments or criminals) make use of them? If these concepts seem a bit broader than freedom of association, I=E2=80=99= ll cop to that. But I think it helps us to think just slightly more = broadly in order to tie back to mechanisms. Also related, here was an interesting white paper put out by the = Carnegie Endowment in September.[1]. While it is slightly US-centric, = Figure 1 is universal. I want to point out that the CS folk I know view = this as a starting point for research without necessarily there being an = ending point that would work. That paper in turn references Stefan = Savage=E2=80=99s work on LI [2]. What is most interesting is that the = work forecloses, as a starting point, LI for data in motion. And that = brings us back to prior restraint and its use/abuse. Eliot [1] = https://carnegieendowment.org/2019/09/10/moving-encryption-policy-conversa= tion-forward-pub-79573 [2] http://cseweb.ucsd.edu/~savage/papers/lawful.pdf = > On 14 Feb 2020, at 22:53, St=C3=A9phane Couture = wrote: >=20 > Hi all, >=20 > Sorry for the delays, but here is a report I made from our last Zoom = meeting about draft-association, that we held two weeks ago. Sorry also = for the typos. >=20 > As stated in this report and announced previously, the next meeting = will be on February 25th from 16:00 to 18:00 GMT, and will be an = interim meeting (Avri or Mallory could say more on this).=20 >=20 > 0. Participants > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > St=C3=A9phane, Niels, Avri, Mallory (for the first part), Juliana >=20 > 1. Editorial team > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Since Joe doesn=E2=80=99t have much time, Niels is still participating = and Juliana wants to participate more, but doesn=E2=80=99t know to what = extent. We have decided to make an =C2=AB open =C2=BB editorial = committee for now, and we will decide later on the order of authors, = based on who has contributed the more (overall, not just in terms of = commits on the git hub). St=C3=A9phane is ok to follow up on = coordination until the next IETF but we will need a co-editor after. >=20 > 2. Report from first seminar=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > St=C3=A9phane presented some of the stuff we discussed in the first = seminar. See the slides : > = https://framadrop.org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VFv0j= KAmU=3D = >=20 > For the goals, it was suggested that we reframe the goal to =E2=80=9Cexp= lore and map the relationships.=E2=80=9D >=20 > As for the goals: Niels mentioned that the goal is to explore the = relationships, before making some recommendations. For instance, you = have to study =E2=80=93 and establish =E2=80=93 the relationships = between drinking and driving, before making decision related to this. = This might raise (again) the point of the theoretical framework we use = to =E2=80=9Cexplore=E2=80=9D these relationships. If our aim is to = establish some kind of causality =E2=80=93 as we would do for drinking = and driving =E2=80=93 an interpretative framework might not be the best = for this. >=20 > 3. Work since the last seminar: literature review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > St=C3=A9phane presented his work on enhancing literature review. A few = more documents addressing explicitly the relations between =E2=80=9Cfreedo= m of association and assembly=E2=80=9D and =E2=80=9Cthe digital=E2=80=9D = were found. In particular, a draft document from the European Council = that was not known to us, presented some social cases (slide 12), that = could be re-used in the research. We still had debates about the = relevance of starting with social cases rather than technological cases = (as it is right now in draft-association). >=20 > It was agreed that these references should be briefly added to the = draft-association. Niels mentioned that all the cases identified in this = document have already been discussed on the list and that it would be = important to look at how it plays out in =E2=80=9Carchitectural=E2=80=9D = layers relevant to IETF. For instance, the design of encryption is an = inherent part of protocols, or using source routing. If we can show that = these choices can make association or joining easier or more difficult, = it would be good. >=20 > Note about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use = here =E2=80=9Cinfrastructure=E2=80=9D in a general sense to refer to the = =E2=80=9Cbehind the scenes=E2=80=9D of normal internet usages, = especially protocols. Infrastructural is thus opposed here to = =E2=80=9Cpolicy=E2=80=9D or =E2=80=9Ceconomic=E2=80=9D dimensions. What = we are interested in here is the broad scope of IETF work, not the = specific realm of how =E2=80=9Cinfrastructure=E2=80=9D is used within = IETF. To avoid confusion, it was proposed that we talk about the = =E2=80=9Carchitecture of the Internet=E2=80=9D, instead of the = =E2=80=9Cinfrastructure of the Internet.=E2=80=9D >=20 > We also presented a summary of an encyclopedia article about = =E2=80=9Cfreedom of association=E2=80=9D, where they present a nuanced = version of freedom of association. It was mentioned that in an earlier = version, Gisela made a similar work, but it was considered too = =E2=80=9Clegal=E2=80=9D. We might want to look at this previous version = of the draft >=20 > 4. The cases > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > We still had some discussions about the current cases, and especially = the way in which they inhibit association. We went through the = difference case studies, and discussing their enabling or disabling = capacity. This part of the discussion was fully transcribed. It is = proposed that we create a table to address each of these cases, which = will help in turn clarifying the argument. See the table here : > = https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuU= dMu80/edit?usp=3Dsharing = > 4. What=E2=80=99s next > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The next meeting will be an =E2=80=98interim meeting=E2=80=9D, so we = will be able to have formal decisions. >=20 > 1. By the next meeting, we should have a table that analyzes the way = in which protocols mentioned in the paper inhibit or enable association. = This table should be done collaboratively.: > = https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuU= dMu80/edit?usp=3Dsharing = > 2. In the next meeting we should decide if we analyze more thoroughly = social cases, or we stick to the cases currently in the paper. If we go = and analyze social cases, it might make the paper stronger, but it would = probably take much more time. >=20 > 3. A =E2=80=9Cdiff=E2=80=9D should be presented in the next meeting, = so it is approved. >=20 > 4. Make sure we resubmit the draft (by March 8th, 2020). >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --Apple-Mail=_37D3C2BF-E9A1-4BA5-925C-8C07C647D6E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = St=C3=A9phane

Thanks = for this.  The CoE draft report is particularly interesting. =  One aspect you may wish to explore is this notion of preventing = the right to peaceably assemble, versus conspiracy to = commit mayhem.  The same technology can be used in each case, which = is why the BART example seems the most interesting to me.  This = also ties to prior restraint, and what sort of judgments we make about = its use versus evidence collection after the fact.  This leads to = several lines of exploration:

  • Can blocking be warranted in the name of public safety when = there is a demonstrable imminent threat?
  • In the = aftermath of a riot (let=E2=80=99s say), what tools should government = have to hold people accountable?

I am taking it as a given that = governments and others will exploit any = capability this ties to in our infrastructure.  A question then = arises: how do we as a community assess those risks?  If we add = mechanisms at all, how will Bad people (governments or criminals) make = use of them?

If = these concepts seem a bit broader than freedom of association, I=E2=80=99l= l cop to that.  But I think it helps us to think just slightly more = broadly in order to tie back to mechanisms.

Also related, here was an interesting = white paper put out by the Carnegie Endowment in September.[1]. While it = is slightly US-centric, Figure 1 is universal.  I want to point out = that the CS folk I know view this as a starting point for research = without necessarily there being an ending point that would work. =  That paper in turn references Stefan Savage=E2=80=99s work on LI = [2].  What is most interesting is that the work forecloses, as a = starting point, LI for data in motion.  And that brings us back to = prior restraint and its use/abuse.

Eliot

[1] https://carnegieendowment.org/2019/09/10/moving-encryption-poli= cy-conversation-forward-pub-79573
[2] http://cseweb.ucsd.edu/~savage/papers/lawful.pdf


On 14 Feb 2020, at 22:53, St=C3=A9phane = Couture <listes@stephcouture.info> wrote:

Hi all,

Sorry for the = delays, but here is a report I made from our last Zoom meeting about = draft-association, that we held two weeks ago. Sorry also for the = typos.

As = stated in this report and announced previously, the next meeting will be = on February 25th  from 16:00 to 18:00 GMT, and will be an = interim meeting (Avri or Mallory could say more on this). 

0. = Participants
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane, = Niels, Avri, Mallory (for the first part), Juliana

1. Editorial team
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Since Joe = doesn=E2=80=99t have much time, Niels is still participating and Juliana wants to participate more, but doesn=E2=80=99t know to what extent. We have = decided to make an =C2=AB open =C2=BB editorial committee for now, and = we will decide later on the order of authors, based on who has contributed the more (overall, not just in terms of commits on the git hub). St=C3=A9phane is ok to follow up on coordination until the = next IETF but we will need a co-editor after.

2. Report from first seminar 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane presented some of the stuff we discussed in the first seminar. See the slides :
https://framadrop.org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra= 01Vr98VFv0jKAmU=3D

For the goals, it was suggested that we reframe the goal to =E2=80=9Cexplore and map the relationships.=E2=80=9D

As for the = goals: Niels mentioned that the goal is to explore the relationships, before making some recommendations. For instance, you have to study =E2=80=93 = and establish =E2=80=93 the relationships between drinking and driving, = before making decision related to this. This might raise (again) the point of the theoretical framework we use to =E2=80=9Cexplore=E2=80=9D these relationships. If our aim is to establish some kind of causality =E2=80=93= as we would do for drinking and driving =E2=80=93 an interpretative framework might not be the best for this.=20

3. Work = since the last seminar: literature review
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane presented his work on enhancing literature review. A few more documents addressing explicitly the relations between =E2=80=9Cfreedom = of association and assembly=E2=80=9D and =E2=80=9Cthe digital=E2=80=9D were = found. In particular, a draft document from the European Council that was not known to us, presented some social cases (slide 12), that could be re-used in the research. We still had debates about the relevance of starting with social cases rather than technological cases (as it is right now in draft-association).=20

It was = agreed that these references should be briefly added to the draft-association. Niels mentioned that all the cases identified in this document have already been discussed on the list and that it would be important to look at how it plays out in =E2=80=9Carchitectural=E2=80=9D layers = relevant to IETF. For instance, the design of encryption is an inherent part of protocols, or using source routing. If we can show that these choices can make association or joining easier or more difficult, it would be good.=20

Note = about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use here = =E2=80=9Cinfrastructure=E2=80=9D in a general sense to refer to the =E2=80=9Cbehind the scenes=E2=80=9D of = normal internet usages, especially protocols. Infrastructural is thus opposed here to =E2=80=9Cpolicy=E2=80=9D or =E2=80=9Ceconomic=E2=80=9D = dimensions. What we are interested in here is the broad scope of IETF work, not the specific realm of how =E2=80=9Cinfrastructure=E2=80=9D is used within = IETF. To avoid confusion, it was proposed that we talk about the =E2=80=9Carchitect= ure of the Internet=E2=80=9D, instead of the =E2=80=9Cinfrastructure of the Internet.=E2=80=9D=20

We also = presented a summary of an encyclopedia article about =E2=80=9Cfreedom of association=E2=80=9D, where they present a nuanced version of freedom of association. It was mentioned that in an earlier version, Gisela made a similar work, but it was considered too =E2=80=9Clegal=E2=80=9D. We = might want to look at this previous version of the draft

4. The cases
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We still had some discussions about the current cases, and especially the way in which they inhibit association. We went through the difference case studies, and discussing their enabling or disabling capacity. This part of the discussion was fully transcribed.  It is proposed that we create a table to address each of these cases, which will help in turn clarifying the argument. See the table here :
https://docs.google.com/document/d/1r88I= nF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=3Dsharing

<= p style=3D"margin-bottom:0.5cm;line-height:100%" class=3D"">4. What=E2=80=99= s next
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The next = meeting will be an =E2=80=98interim meeting=E2=80=9D, so we will be able to have = formal decisions.

1. By the next meeting, we should have a table that analyzes the way in which protocols mentioned in the paper inhibit or enable association. This table should be done collaboratively.:
https://docs.google.com/document/d/1r88I= nF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=3Dsharing

<= p style=3D"margin-bottom:0.5cm;line-height:100%" class=3D"">2. In the = next meeting we should decide if we analyze more thoroughly social cases, or we stick to the cases currently in the paper. If we go and analyze social cases, it might make the paper stronger, but it would probably take much more time.

3. A =E2=80=9Cdiff=E2=80=9D should be presented in the next meeting, so it is approved.

4. Make sure = we resubmit the draft (by March 8th, 2020).

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

= --Apple-Mail=_37D3C2BF-E9A1-4BA5-925C-8C07C647D6E2-- From nobody Wed Feb 19 06:56:04 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760AC1200B5 for ; Wed, 19 Feb 2020 06:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZSO0pEqj02E for ; Wed, 19 Feb 2020 06:55:50 -0800 (PST) Received: from homere.koumbit.net (homere.koumbit.net [199.58.80.81]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE15120120 for ; Wed, 19 Feb 2020 06:55:50 -0800 (PST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: steph@stephcouture.info) by homere.koumbit.net (Postfix) with ESMTPSA id 369FF1E40C38 for ; Wed, 19 Feb 2020 09:55:48 -0500 (EST) Received: by mail-wr1-f49.google.com with SMTP id z7so837039wrl.13 for ; Wed, 19 Feb 2020 06:55:48 -0800 (PST) X-Gm-Message-State: APjAAAUd7s1UT5RJQi9gfbnqoSFCDPld25cqi/pMZT/aYfW/QWbxtB60 u0BhzYNFlAn+0GU0MIllBPQansywAFxeofjTmHw= X-Google-Smtp-Source: APXvYqwPtWxf9ozrR/H5HGBR0qdY5Ud7rrsUZTY8wdpsZqCJbMCU43koFh0S4N8h6IaL2AH9lsJvqhwhRdUyUR56Ajo= X-Received: by 2002:a05:6000:118d:: with SMTP id g13mr34849852wrx.141.1582124147604; Wed, 19 Feb 2020 06:55:47 -0800 (PST) MIME-Version: 1.0 References: <3C9A47B3-C7CB-4A3C-874D-F7475D72E71E@cisco.com> In-Reply-To: <3C9A47B3-C7CB-4A3C-874D-F7475D72E71E@cisco.com> From: =?UTF-8?Q?St=C3=A9phane_Couture?= Date: Wed, 19 Feb 2020 09:55:36 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eliot Lear Cc: =?UTF-8?Q?St=C3=A9phane_Couture?= , hrpc@irtf.org Content-Type: multipart/alternative; boundary="000000000000cf1acb059eeefb13" Archived-At: Subject: Re: [hrpc] Draft-association : report from last meeting 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, 19 Feb 2020 14:55:56 -0000 --000000000000cf1acb059eeefb13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Thanks Eliot for those comments. Following this, I wanted to mention two things that we have been discussing in our little meetings about draft-association. It might be interesting to have the perspective of the group on this. First, to what extent should we talk about "social cases" such as "Bart" in our draft-association paper? This is an issue different people (including me) have been raising multiple times. Some think we should start with "social cases" such as the Bart or others mentioned in the Council of Europe Report, and analyze their "protocol considerations". In an ideal world, and in terms of methodology, this is how I would frame the paper : start from a literature review, extract documented cases and analyze the issues they raise (or not) in terms of protocol design. But this would mean significant and probably time consuming changes. But is it sufficient to keep the current structure of the paper which restricts itself to "technological cases", without going too deeply into social uses? I think this should be decided soon (like in the interim meeting). Second, how will our paper be helpful for IETF? If we take the Bart example, what can we learn from this case, that can help IETF make better "a priori" risk or benefit assessments, or do a better job broadly speaking ? What about the cases already presented in the draft? I must admit that despite the many discussions we have had - and I'd like to thank Niels for his patience in explaining to me his view - I still have difficulties to get a grip on the line of the argument of the paper as it is now, and what it is trying to demonstrate or contribute exactly. So, if our goal is to make only minor changes to the document, I feel I might not be the best person to act as "lead editor". In all cases, as Joe seems to have stepped down due to his time constraints, I would need another person partnering with me on this. Finally, to documents worthy to share 1. The final report of the Council of Europe, which is here : https://mk0rofifiqa2w3u89nud.kinstacdn.com/wp-content/uploads/COE-report-on= -FOAA-rights-on-the-internet-.pdf And also this 2019 report - which I still need to read - by of the Special Rapporteur on the rights to freedom of peaceful assembly and of association which "focuses on the opportunities and challenges facing the rights to freedom of peaceful assembly and of association in the digital age": https://documents-dds-ny.un.org/doc/UNDOC/GEN/G19/141/02/PDF/G1914102.pdf Again, my view would be to look at documents like these (and other I started to identify) and analyze what implications the cases they mentions can have in terms of IETF work. Thank you, St=C3=A9phane Le dim. 16 f=C3=A9vr. 2020 =C3=A0 05:44, Eliot Lear a =C3= =A9crit : > Hi St=C3=A9phane > > Thanks for this. The CoE draft report is particularly interesting. One > aspect you may wish to explore is this notion of preventing the right to > *peaceably* assemble, versus conspiracy to commit mayhem. The same > technology can be used in each case, which is why the BART example seems > the most interesting to me. This also ties to prior restraint, and what > sort of judgments we make about its use versus evidence collection after > the fact. This leads to several lines of exploration: > > > - Can blocking be warranted in the name of public safety when there is > a demonstrable imminent threat? > - In the aftermath of a riot (let=E2=80=99s say), what tools should go= vernment > have to hold people accountable? > > > I am taking it as a given that governments *and others* will exploit any > capability this ties to in our infrastructure. A question then arises: h= ow > do we as a community assess those risks? If we add mechanisms at all, ho= w > will Bad people (governments or criminals) make use of them? > > If these concepts seem a bit broader than freedom of association, I=E2=80= =99ll cop > to that. But I think it helps us to think just slightly more broadly in > order to tie back to mechanisms. > > Also related, here was an interesting white paper put out by the Carnegie > Endowment in September.[1]. While it is slightly US-centric, Figure 1 is > universal. I want to point out that the CS folk I know view this as a > starting point for research without necessarily there being an ending poi= nt > that would work. That paper in turn references Stefan Savage=E2=80=99s w= ork on LI > [2]. What is most interesting is that the work forecloses, as a starting > point, LI for data in motion. And that brings us back to prior restraint > and its use/abuse. > > Eliot > > [1] > https://carnegieendowment.org/2019/09/10/moving-encryption-policy-convers= ation-forward-pub-79573 > [2] http://cseweb.ucsd.edu/~savage/papers/lawful.pdf > > > On 14 Feb 2020, at 22:53, St=C3=A9phane Couture > wrote: > > Hi all, > > Sorry for the delays, but here is a report I made from our last Zoom > meeting about draft-association, that we held two weeks ago. Sorry also f= or > the typos. > > As stated in this report and announced previously, the next meeting will > be on February 25th from 16:00 to 18:00 GMT, and will be an interim > meeting (Avri or Mallory could say more on this). > > 0. Participants > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > St=C3=A9phane, Niels, Avri, Mallory (for the first part), Juliana > > 1. Editorial team > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Since Joe doesn=E2=80=99t have much time, Niels is still participating an= d Juliana > wants to participate more, but doesn=E2=80=99t know to what extent. We ha= ve decided > to make an =C2=AB open =C2=BB editorial committee for now, and we will de= cide later > on the order of authors, based on who has contributed the more (overall, > not just in terms of commits on the git hub). St=C3=A9phane is ok to foll= ow up > on coordination until the next IETF but we will need a co-editor after. > > 2. Report from first seminar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > St=C3=A9phane presented some of the stuff we discussed in the first semin= ar. > See the slides : > > https://framadrop.org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VFv0= jKAmU=3D > > For the goals, it was suggested that we reframe the goal to =E2=80=9Cexpl= ore and > map the relationships.=E2=80=9D > > As for the goals: Niels mentioned that the goal is to explore the > relationships, before making some recommendations. For instance, you have > to study =E2=80=93 and establish =E2=80=93 the relationships between drin= king and driving, > before making decision related to this. This might raise (again) the poin= t > of the theoretical framework we use to =E2=80=9Cexplore=E2=80=9D these re= lationships. If > our aim is to establish some kind of causality =E2=80=93 as we would do f= or > drinking and driving =E2=80=93 an interpretative framework might not be t= he best > for this. > > 3. Work since the last seminar: literature review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > St=C3=A9phane presented his work on enhancing literature review. A few mo= re > documents addressing explicitly the relations between =E2=80=9Cfreedom of > association and assembly=E2=80=9D and =E2=80=9Cthe digital=E2=80=9D were = found. In particular, a > draft document from the European Council that was not known to us, > presented some social cases (slide 12), that could be re-used in the > research. We still had debates about the relevance of starting with socia= l > cases rather than technological cases (as it is right now in > draft-association). > > It was agreed that these references should be briefly added to the > draft-association. Niels mentioned that all the cases identified in this > document have already been discussed on the list and that it would be > important to look at how it plays out in =E2=80=9Carchitectural=E2=80=9D = layers relevant to > IETF. For instance, the design of encryption is an inherent part of > protocols, or using source routing. If we can show that these choices can > make association or joining easier or more difficult, it would be good. > > Note about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use here = =E2=80=9Cinfrastructure=E2=80=9D > in a general sense to refer to the =E2=80=9Cbehind the scenes=E2=80=9D of= normal internet > usages, especially protocols. Infrastructural is thus opposed here to > =E2=80=9Cpolicy=E2=80=9D or =E2=80=9Ceconomic=E2=80=9D dimensions. What w= e are interested in here is the > broad scope of IETF work, not the specific realm of how =E2=80=9Cinfrastr= ucture=E2=80=9D is > used within IETF. To avoid confusion, it was proposed that we talk about > the =E2=80=9Carchitecture of the Internet=E2=80=9D, instead of the =E2=80= =9Cinfrastructure of the > Internet.=E2=80=9D > > We also presented a summary of an encyclopedia article about =E2=80=9Cfre= edom of > association=E2=80=9D, where they present a nuanced version of freedom of > association. It was mentioned that in an earlier version, Gisela made a > similar work, but it was considered too =E2=80=9Clegal=E2=80=9D. We might= want to look at > this previous version of the draft > > 4. The cases > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We still had some discussions about the current cases, and especially the > way in which they inhibit association. We went through the difference cas= e > studies, and discussing their enabling or disabling capacity. This part o= f > the discussion was fully transcribed. It is proposed that we create a > table to address each of these cases, which will help in turn clarifying > the argument. See the table here : > > https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpu= UdMu80/edit?usp=3Dsharing > > 4. What=E2=80=99s next > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The next meeting will be an =E2=80=98interim meeting=E2=80=9D, so we will= be able to have > formal decisions. > > 1. By the next meeting, we should have a table that analyzes the way in > which protocols mentioned in the paper inhibit or enable association. Thi= s > table should be done collaboratively.: > > https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpu= UdMu80/edit?usp=3Dsharing > > 2. In the next meeting we should decide if we analyze more thoroughly > social cases, or we stick to the cases currently in the paper. If we go a= nd > analyze social cases, it might make the paper stronger, but it would > probably take much more time. > > 3. A =E2=80=9Cdiff=E2=80=9D should be presented in the next meeting, so i= t is approved. > > 4. Make sure we resubmit the draft (by March 8th, 2020). > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000cf1acb059eeefb13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all,


Thanks Eliot for those comments. Following this, I wa= nted to mention two things that we have been discussing in our little meeti= ngs about draft-association. It might be interesting to have the perspectiv= e of the group on this.


First, to what extent should we talk about "soci= al cases" such as "Bart" in our draft-association paper? Thi= s is an issue different people (including me) have been raising multiple ti= mes. Some think we should start with "social cases" such as the B= art or others mentioned in the Council of Europe Report, and analyze their = "protocol considerations". In an ideal world, and in terms of met= hodology, this is how I would frame the paper : start from a literature rev= iew, extract documented cases and analyze the issues they raise (or not) in= terms of protocol design. But this would mean significant and probably tim= e consuming changes. But is it sufficient to keep the current structure of = the paper which restricts itself to "technological cases", withou= t going too deeply into social uses? I think this should be decided soon (l= ike in the interim meeting).


Second, how will our paper be helpful for IETF? If we= take the Bart example, what can we learn from this case, that can help IET= F make better "a priori" risk or benefit assessments, or do a bet= ter job broadly speaking ? What about the cases already presented in the dr= aft?


I must admit that despite the many discussions we hav= e had - and I'd like to thank Niels for his patience in explaining to m= e his view - I still have difficulties to get a grip on the line of the arg= ument of the paper as it is now, and what it is trying to demonstrate or co= ntribute exactly. So, if our goal is to make only minor changes to the docu= ment, I feel I might not be the best person to act as "lead editor&quo= t;. In all cases, as Joe seems to have stepped down due to his time constra= ints, I would need another person partnering with me on this.


Finally, to documents worthy to share=C2=A0

1. The final report of the Council of Europe, which i= s here :

And also = this 2019 report - which I still need to read - by of the Special Rapporteu= r on the rights to freedom of peaceful assembly and of association which "focuses on the opportunities and challenges facing the rights to freedom of peaceful assembly and of associa= tion in the digital age":
https://docu= ments-dds-ny.un.org/doc/UNDOC/GEN/G19/141/02/PDF/G1914102.pdf

Again, my view would be to look at documents like these (an= d other I started to identify) and analyze what implications the cases they= mentions can have in terms of IETF work.

Thank yo= u,

St=C3=A9phane

<= br>
Le=C2= =A0dim. 16 f=C3=A9vr. 2020 =C3=A0=C2=A005:44, Eliot Lear <lear@cisco.com> a =C3=A9crit= =C2=A0:
Hi = St=C3=A9phane

Thanks for this.=C2=A0 The CoE draft repor= t is particularly interesting.=C2=A0 One aspect you may wish to explore is = this notion of preventing the right to peaceably assemble, versus co= nspiracy to commit mayhem.=C2=A0 The same technology can be used in each ca= se, which is why the BART example seems the most interesting to me.=C2=A0 T= his also ties to prior restraint, and what sort of judgments we make about = its use versus evidence collection after the fact.=C2=A0 This leads to seve= ral lines of exploration:

  • Can blocking be = warranted in the name of public safety when there is a demonstrable imminen= t threat?
  • In the aftermath of a riot (let=E2=80=99s say), what tool= s should government have to hold people accountable?

I am taking it as a given that governments and others= =C2=A0will exploit any capability this ties to in our infrastructure.=C2=A0= A question then arises: how do we as a community assess those risks?=C2=A0= If we add mechanisms at all, how will Bad people (governments or criminals= ) make use of them?

If these concepts seem a bit b= roader than freedom of association, I=E2=80=99ll cop to that.=C2=A0 But I t= hink it helps us to think just slightly more broadly in order to tie back t= o mechanisms.

Also related, here was an interestin= g white paper put out by the Carnegie Endowment in September.[1]. While it = is slightly US-centric, Figure 1 is universal.=C2=A0 I want to point out th= at the CS folk I know view this as a starting point for research without ne= cessarily there being an ending point that would work.=C2=A0 That paper in = turn references Stefan Savage=E2=80=99s work on LI [2].=C2=A0 What is most = interesting is that the work forecloses, as a starting point, LI for data i= n motion.=C2=A0 And that brings us back to prior restraint and its use/abus= e.

Eliot

[2]=C2=A0http://cseweb.ucsd.edu/~savage/papers/lawful.pdf


On 14 Feb 2020, at 22:53, St= =C3=A9phane Couture <listes@stephcouture.info> wrote:

Hi all,

Sorry for the delays, but here= is a report I made from our last Zoom meeting about draft-association, tha= t we held two weeks ago. Sorry also for the typos.

As stated in this report and announced previou= sly, the next meeting will be on February 25th=C2=A0=C2=A0from 16:00 to 18:= 00 GMT, and will be an interim meeting (Avri or Mallory could say more on t= his).=C2=A0

0. Partici= pants
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane, Niels, Avri, Mallory (for the first par= t), Juliana

1. Editori= al team
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Since Joe doesn=E2=80=99t have much time, Niels is still participating and Juliana wants to participate more, but doesn=E2=80=99t know to what extent. We have decided to make an =C2=AB=C2=A0open=C2=A0=C2=BB editorial committee for now, and we will decide later on the order of authors, based on who has contributed the more (overall, not just in terms of commits on the git hub). St=C3=A9phane is ok to follow up on coordination until the next IETF but we will need a co-editor after.

2. Report from first seminar=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane presented some of the stuff we discussed in the first seminar. See the slides=C2=A0:
https://framadrop= .org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VFv0jKAmU=3D
For the goals, it was suggested that we reframe the goal to =E2=80=9Cexplore and map the relationships.=E2=80=9D

As for the goals: Niels mentioned that the goal is to explore the relationships, before making some recommendations. For instance, you have to study =E2=80=93 and establish =E2=80=93 the relationships between drinking and driving, before making decision related to this. This might raise (again) the point of the theoretical framework we use to =E2=80=9Cexplore=E2=80=9D these relationships. If our aim is to establish some kind of causality =E2=80=93 as we would do for drinking and driving =E2=80=93 an interpretative framework might not be the best for this.=20

3. Work since the last seminar: literature review
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

St=C3=A9phane presented his work on enhancing literature review. A few more documents addressing explicitly the relations between =E2=80=9Cfreedom of association and assembly=E2=80=9D and =E2=80=9Cthe digital=E2=80=9D were fo= und. In particular, a draft document from the European Council that was not known to us, presented some social cases (slide 12), that could be re-used in the research. We still had debates about the relevance of starting with social cases rather than technological cases (as it is right now in draft-association).=20

It was agreed that these references should be briefly added to the draft-association. Niels mentioned that all the cases identified in this document have already been discussed on the list and that it would be important to look at how it plays out in =E2=80=9Carchitectural=E2=80=9D layers relevant= to IETF. For instance, the design of encryption is an inherent part of protocols, or using source routing. If we can show that these choices can make association or joining easier or more difficult, it would be good.=20

Note about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use here =E2=80=9Cinfrastru= cture=E2=80=9D in a general sense to refer to the =E2=80=9Cbehind the scenes=E2=80=9D of norm= al internet usages, especially protocols. Infrastructural is thus opposed here to =E2=80=9Cpolicy=E2=80=9D or =E2=80=9Ceconomic=E2=80=9D dime= nsions. What we are interested in here is the broad scope of IETF work, not the specific realm of how =E2=80=9Cinfrastructure=E2=80=9D is used within IETF.= To avoid confusion, it was proposed that we talk about the =E2=80=9Carchitectu= re of the Internet=E2=80=9D, instead of the =E2=80=9Cinfrastructure of the Internet.=E2=80=9D=20

We also presented a summary of an encyclopedia article about =E2=80=9Cfreedom of association=E2=80=9D, where they present a nuanced version of freedom of association. It was mentioned that in an earlier version, Gisela made a similar work, but it was considered too =E2=80=9Clegal=E2=80=9D. We might= want to look at this previous version of the draft

4. The cases
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We still had some discussions about the current cases, and especially the way in which they inhibit association. We went through the difference case studies, and discussing their enabling or disabling capacity. This part of the discussion was fully transcribed.=C2=A0 It is proposed that we create a table to address each of these cases, which will help in turn clarifying the argument. See the table here :
https://docs.google.c= om/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=3Dshari= ng

4. What= =E2=80=99s next
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The next meeting will be an =E2=80=98interim meeting=E2=80=9D, so we will be able to have fo= rmal decisions.

1. By the next meeting, we should have a table that analyzes the way in which protocols mentioned in the paper inhibit or enable association. This table should be done collaboratively.:
https://docs.google.c= om/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=3Dshari= ng

2. In th= e next meeting we should decide if we analyze more thoroughly social cases, or we stick to the cases currently in the paper. If we go and analyze social cases, it might make the paper stronger, but it would probably take much more time.

3= . A =E2=80=9Cdiff=E2=80=9D should be presented in the next meeting, so it is approved.

4. Make sure we resubmit the draft (by March 8th, 2020).

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

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000cf1acb059eeefb13-- From nobody Thu Feb 20 02:33:52 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443D1120024 for ; Thu, 20 Feb 2020 02:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59AQNWBlif5D for ; Thu, 20 Feb 2020 02:33:47 -0800 (PST) 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 CBEB312001A for ; Thu, 20 Feb 2020 02:33:46 -0800 (PST) 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 1j4j9H-0008EX-QL; Thu, 20 Feb 2020 11:33:41 +0100 To: =?UTF-8?Q?St=c3=a9phane_Couture?= , Eliot Lear Cc: hrpc@irtf.org References: <3C9A47B3-C7CB-4A3C-874D-F7475D72E71E@cisco.com> From: Mallory Knodel Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwK8EEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlx9 YZYFCRHqR68AIQkQDDKicb08x4AWIQTj62PgZaOyQLzZsHEMMqJxvTzHgJBaCACC0Mrss3Wl fxm7s2IEwPA1qmKjVJs/1MNWWXBUQnCdzgi3N1nXBZ1UzmIfuB1a9P4Mm9CmoLhUUSSra/9/ eczTb6vHOgLKwVS6cN7Zd8aico9Q5eQ02FGHUe2qmrVbGuicJWelGakCdbJ7q4fAMVVBRnc5 glCX8zDoo3M6exUroaiMofDmnR2tXPIr2E21WiCjRkcpAInV+VRYAdW1JuU4pDf6d5iAjmJZ 51XmqU7uXHrQy3btH5IfTUn14N7HJn6Z3n/uCeVoTpoOb7bRxhtnLuyGM0aVeVNbafpAxxwt Y6csR+/7/pz+ze214LjPZubK1gehfgCOsy1y8SZgiANUzsBNBEx0TWcBCADiak/YuMW4BbaW L0U9sNg4zO3Qy1OFeye8fJjR8O/wWVSqcqA+sxjzRUee2fHCp6kVLedy6dVfiKmr59p21r4s elOdslKaWmEGtz2oYnGpyPB/jKjfleE5cIkXCdqgDAhfbfuVdF7heHpfhUy4m3yOJl2+CluT /CG9AfaCtyrwqMJzLWK4vmkGXxnBgb92mGK0WFB2oRydz+SsiobgpCAqJSLcr8ZHQ54SbD9y xxYPv8IsSjt4eJoZCFI7INBsz4i7aj/q4xcxQ+xiUwyqCZUvrzMxpw7c8TXuPHStDyhnsKkF jxhlY5avNeu0VPwk72C64I+y93gpPrL3vL0tEmU9ABEBAAHCwJMEGAECACYCGwwWIQTj62Pg ZaOyQLzZsHEMMqJxvTzHgAUCXH1hmgUJEepHswAhCRAMMqJxvTzHgBYhBOPrY+Blo7JAvNmw cQwyonG9PMeAQNkIAJxNqZ810EAKk8eyawkvWFtZ6u3BhmDuHatm2CZlD0LY8xM6CQ89Kx+L 7Fno9peW+bZEj9NfnUtsmwIn0V3b9bEp20LSzqjv7QKXc/nsA5F/cFF+XfN9e7JWHOMu8z1a EOJAzokGoO5jGJieM7nqX6CjMS4EC1Qlo8jEbKCDJLl5PyQq/xLOlziDv+yRlepxxU4ePTko I5oVDvviuwjNzCmmomoaOH1fqdfqbYM424Ehg1eMf1ToXEdInqBFHFmSLPb90NliqwdiWQqK Afzav2A5GEgZmQJ3vGdGHIs4eeON4q0jLmm8bDFSiHL7LmXyLXXnkkQ80HummFjEXGMw5BQ= Message-ID: <15ae053d-5fac-52d9-3b50-8cafa4aee230@article19.org> Date: Thu, 20 Feb 2020 13:33:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: 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: 62760e359e69894f1ebb2c55fa62ac8c Archived-At: Subject: Re: [hrpc] Draft-association : report from last meeting 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, 20 Feb 2020 10:33:50 -0000 Hi St=C3=A9phane, Thanks for raising these important questions. I wanted to add my thoughts, which unfortunately don't directly answer these open questions. First, if you read Cl=C3=A9ment Voule's report, in paragraph 24 he explai= ns to the Human Rights Council that, "Encryption technologies, pseudonymity and other security features have enabled individuals belonging to minority groups to find one another and create community." He goes on for about one paragraph. I think that an activity of HRPC drafts should be to take these core concepts and expand them in two directions: 1) To provide exhaustive analysis on the connection between a technology, like encryption, that is used in internet standards and human rights. 2) To provide specific evidence from the human rights community that a indeed a technology is considered enabling or restricting, and how. Some other themes that deserve a mention in this draft, but perhaps not full on treatment. The considerations when looking at: * access and association. * gender and access, and therefore association. * consolidation and civic space. And of course I think the meta-theme of open standards building, free software, etc /as/ association is too obvious to miss. I'll end with saying I don't think whether or not we should be using "social cases" is the right question. I think we need to figure out what themes should be treated, find cases that illustrate those themes, and then be explicit about what is helpful to know about those cases/themes. -Mallory On 19/02/2020 17:55, St=C3=A9phane Couture wrote: > Hi all, >=20 >=20 > Thanks Eliot for those comments. Following this, I wanted to mention tw= o > things that we have been discussing in our little meetings about > draft-association. It might be interesting to have the perspective of > the group on this. >=20 >=20 > First, to what extent should we talk about "social cases" such as "Bart= " > in our draft-association paper? This is an issue different people > (including me) have been raising multiple times. Some think we should > start with "social cases" such as the Bart or others mentioned in the > Council of Europe Report, and analyze their "protocol considerations". > In an ideal world, and in terms of methodology, this is how I would > frame the paper : start from a literature review, extract documented > cases and analyze the issues they raise (or not) in terms of protocol > design. But this would mean significant and probably time consuming > changes. But is it sufficient to keep the current structure of the pape= r > which restricts itself to "technological cases", without going too > deeply into social uses? I think this should be decided soon (like in > the interim meeting). >=20 >=20 > Second, how will our paper be helpful for IETF? If we take the Bart > example, what can we learn from this case, that can help IETF make > better "a priori" risk or benefit assessments, or do a better job > broadly speaking ? What about the cases already presented in the draft? >=20 >=20 > I must admit that despite the many discussions we have had - and I'd > like to thank Niels for his patience in explaining to me his view - I > still have difficulties to get a grip on the line of the argument of th= e > paper as it is now, and what it is trying to demonstrate or contribute > exactly. So, if our goal is to make only minor changes to the document, > I feel I might not be the best person to act as "lead editor". In all > cases, as Joe seems to have stepped down due to his time constraints, I > would need another person partnering with me on this. >=20 >=20 > Finally, to documents worthy to share=C2=A0 >=20 > 1. The final report of the Council of Europe, which is here : > https://mk0rofifiqa2w3u89nud.kinstacdn.com/wp-content/uploads/COE-repor= t-on-FOAA-rights-on-the-internet-.pdf > >=20 > And also this 2019 report - which I still need to read - by of the > Special Rapporteur on the rights to freedom of peaceful assembly and of > association which "focuses on the opportunities and challenges facing > the rights to freedom of peaceful assembly and of association in the > digital age": > https://documents-dds-ny.un.org/doc/UNDOC/GEN/G19/141/02/PDF/G1914102.p= df >=20 > Again, my view would be to look at documents like these (and other I > started to identify) and analyze what implications the cases they > mentions can have in terms of IETF work. >=20 > Thank you, >=20 > St=C3=A9phane >=20 >=20 > Le=C2=A0dim. 16 f=C3=A9vr. 2020 =C3=A0=C2=A005:44, Eliot Lear > a =C3=A9crit=C2=A0: >=20 > Hi St=C3=A9phane >=20 > Thanks for this.=C2=A0 The CoE draft report is particularly interes= ting.=C2=A0 > One aspect you may wish to explore is this notion of preventing the > right to *peaceably* assemble, versus conspiracy to commit mayhem.=C2= =A0 > The same technology can be used in each case, which is why the BART > example seems the most interesting to me.=C2=A0 This also ties to p= rior > restraint, and what sort of judgments we make about its use versus > evidence collection after the fact.=C2=A0 This leads to several lin= es of > exploration: >=20 > * Can blocking be warranted in the name of public safety when > there is a demonstrable imminent threat? > * In the aftermath of a riot (let=E2=80=99s say), what tools shou= ld > government have to hold people accountable? >=20 >=20 > I am taking it as a given that governments *and others*=C2=A0will e= xploit > any capability this ties to in our infrastructure.=C2=A0 A question= then > arises: how do we as a community assess those risks?=C2=A0 If we ad= d > mechanisms at all, how will Bad people (governments or criminals) > make use of them? >=20 > If these concepts seem a bit broader than freedom of association, > I=E2=80=99ll cop to that.=C2=A0 But I think it helps us to think ju= st slightly > more broadly in order to tie back to mechanisms. >=20 > Also related, here was an interesting white paper put out by the > Carnegie Endowment in September.[1]. While it is slightly > US-centric, Figure 1 is universal.=C2=A0 I want to point out that t= he CS > folk I know view this as a starting point for research without > necessarily there being an ending point that would work.=C2=A0 That= paper > in turn references Stefan Savage=E2=80=99s work on LI [2].=C2=A0 Wh= at is most > interesting is that the work forecloses, as a starting point, LI fo= r > data in motion.=C2=A0 And that brings us back to prior restraint an= d its > use/abuse. >=20 > Eliot >=20 > [1] > https://carnegieendowment.org/2019/09/10/moving-encryption-policy-c= onversation-forward-pub-79573 > [2]=C2=A0http://cseweb.ucsd.edu/~savage/papers/lawful.pdf >=20 >=20 >> On 14 Feb 2020, at 22:53, St=C3=A9phane Couture >> > wrote= : >> >> Hi all, >> >> Sorry for the delays, but here is a report I made from our last >> Zoom meeting about draft-association, that we held two weeks ago. >> Sorry also for the typos. >> >> As stated in this report and announced previously, the next >> meeting will be on February 25th=C2=A0=C2=A0from 16:00 to 18:00 GM= T, and >> will be an interim meeting (Avri or Mallory could say more on this= ).=C2=A0 >> >> 0. Participants >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> St=C3=A9phane, Niels, Avri, Mallory (for the first part), Juliana >> >> 1. Editorial team >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Since Joe doesn=E2=80=99t have much time, Niels is still participa= ting and >> Juliana wants to participate more, but doesn=E2=80=99t know to wha= t >> extent. We have decided to make an =C2=AB=C2=A0open=C2=A0=C2=BB ed= itorial committee >> for now, and we will decide later on the order of authors, based >> on who has contributed the more (overall, not just in terms of >> commits on the git hub). St=C3=A9phane is ok to follow up on >> coordination until the next IETF but we will need a co-editor afte= r. >> >> 2. Report from first seminar=C2=A0 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> St=C3=A9phane presented some of the stuff we discussed in the firs= t >> seminar. See the slides=C2=A0: >> https://framadrop..org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01= Vr98VFv0jKAmU=3D >> >> >> For the goals, it was suggested that we reframe the goal to >> =E2=80=9Cexplore and map the relationships.=E2=80=9D >> >> As for the goals: Niels mentioned that the goal is to explore the >> relationships, before making some recommendations. For instance, >> you have to study =E2=80=93 and establish =E2=80=93 the relationsh= ips between >> drinking and driving, before making decision related to this. This >> might raise (again) the point of the theoretical framework we use >> to =E2=80=9Cexplore=E2=80=9D these relationships. If our aim is to= establish some >> kind of causality =E2=80=93 as we would do for drinking and drivin= g =E2=80=93 an >> interpretative framework might not be the best for this. >> >> 3. Work since the last seminar: literature review >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> St=C3=A9phane presented his work on enhancing literature review. A= few >> more documents addressing explicitly the relations between >> =E2=80=9Cfreedom of association and assembly=E2=80=9D and =E2=80=9C= the digital=E2=80=9D were >> found. In particular, a draft document from the European Council >> that was not known to us, presented some social cases (slide 12), >> that could be re-used in the research. We still had debates about >> the relevance of starting with social cases rather than >> technological cases (as it is right now in draft-association). >> >> It was agreed that these references should be briefly added to the >> draft-association. Niels mentioned that all the cases identified >> in this document have already been discussed on the list and that >> it would be important to look at how it plays out in >> =E2=80=9Carchitectural=E2=80=9D layers relevant to IETF. For insta= nce, the design >> of encryption is an inherent part of protocols, or using source >> routing. If we can show that these choices can make association or >> joining easier or more difficult, it would be good. >> >> Note about the notion of =E2=80=9Cinfrastructural=E2=80=9D: We use= here >> =E2=80=9Cinfrastructure=E2=80=9D in a general sense to refer to th= e =E2=80=9Cbehind the >> scenes=E2=80=9D of normal internet usages, especially protocols. >> Infrastructural is thus opposed here to =E2=80=9Cpolicy=E2=80=9D o= r =E2=80=9Ceconomic=E2=80=9D >> dimensions. What we are interested in here is the broad scope of >> IETF work, not the specific realm of how =E2=80=9Cinfrastructure=E2= =80=9D is used >> within IETF. To avoid confusion, it was proposed that we talk >> about the =E2=80=9Carchitecture of the Internet=E2=80=9D, instead = of the >> =E2=80=9Cinfrastructure of the Internet.=E2=80=9D >> >> We also presented a summary of an encyclopedia article about >> =E2=80=9Cfreedom of association=E2=80=9D, where they present a nua= nced version of >> freedom of association. It was mentioned that in an earlier >> version, Gisela made a similar work, but it was considered too >> =E2=80=9Clegal=E2=80=9D. We might want to look at this previous ve= rsion of the draft >> >> 4. The cases >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> We still had some discussions about the current cases, and >> especially the way in which they inhibit association. We went >> through the difference case studies, and discussing their enabling >> or disabling capacity. This part of the discussion was fully >> transcribed.=C2=A0 It is proposed that we create a table to addres= s >> each of these cases, which will help in turn clarifying the >> argument. See the table here : >> https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dD= T2TAWpuUdMu80/edit?usp=3Dsharing >> >> 4. What=E2=80=99s next >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The next meeting will be an =E2=80=98interim meeting=E2=80=9D, so = we will be able >> to have formal decisions. >> >> 1. By the next meeting, we should have a table that analyzes the >> way in which protocols mentioned in the paper inhibit or enable >> association. This table should be done collaboratively.: >> https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dD= T2TAWpuUdMu80/edit?usp=3Dsharing >> >> 2. In the next meeting we should decide if we analyze more >> thoroughly social cases, or we stick to the cases currently in the >> paper. If we go and analyze social cases, it might make the paper >> stronger, but it would probably take much more time. >> >> 3.. A =E2=80=9Cdiff=E2=80=9D should be presented in the next meeti= ng, so it is >> approved. >> >> 4. Make sure we resubmit the draft (by March 8^th , 2020). >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Thu Feb 20 06:42:41 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E131208A4 for ; Thu, 20 Feb 2020 06:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_oCH10KHe1o for ; Thu, 20 Feb 2020 06:42:37 -0800 (PST) Received: from homere.koumbit.net (homere.koumbit.net [199.58.80.81]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08302120877 for ; Thu, 20 Feb 2020 06:42:37 -0800 (PST) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: steph@stephcouture.info) by homere.koumbit.net (Postfix) with ESMTPSA id 088D91E410B2 for ; Thu, 20 Feb 2020 09:42:35 -0500 (EST) Received: by mail-wm1-f42.google.com with SMTP id a6so2306832wme.2 for ; Thu, 20 Feb 2020 06:42:35 -0800 (PST) X-Gm-Message-State: APjAAAWvAHAHH3VYROZJVAljigKhN+/82xECjRMwSakwEV6HS3m65Oii VS6ZeN42u9btpxVoQfgREb1MZ9Ds6wu8keB8mr4= X-Google-Smtp-Source: APXvYqyMn+zS87dyMDjE1kC/7Q533sxoI6FN8vB1HBlfxVwVa3zDpjGz+LpFEYBvFpcXTmWD8mxhaNUghJ7aWj0XqzA= X-Received: by 2002:a7b:ce0b:: with SMTP id m11mr5058707wmc.4.1582209754697; Thu, 20 Feb 2020 06:42:34 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?St=C3=A9phane_Couture?= Date: Thu, 20 Feb 2020 09:42:23 -0500 X-Gmail-Original-Message-ID: Message-ID: To: hrpc@irtf.org Content-Type: multipart/alternative; boundary="0000000000006394df059f02eacb" Archived-At: Subject: [hrpc] Dummy question on editing draft on github 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, 20 Feb 2020 14:42:40 -0000 --0000000000006394df059f02eacb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I have a dummy question related to edition of drafts. So, I am trying to edit the draft-association on the github: https://github.com/IRTF-HRPC/drafts/compare/master...stephcouture:master One thing I face is that each line is ending with a line break. So, if I add some words or change a sentence, I have to manually insert line breaks for each of the following lines to keep format. At least if I edit it directly on github or in a text file. Is there a way to rewrite whole paragraphs, without have to reformat the line breaks? Like an editor I should use in particular? Thank you, St=C3=A9phane . --0000000000006394df059f02eacb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have a dummy question related= to edition of drafts. So, I am trying to edit the draft-association on the= github:
https://github.com/IRTF-HRPC/drafts/compare/master...= stephcouture:master

One thing I face is that e= ach line is ending with a line break. So, if I add some words or change a s= entence, I have to manually insert line breaks for each of the following li= nes to keep format. At least if I edit it directly on github or in a text f= ile.

Is there a way to rewrite whole paragraphs, w= ithout have to reformat the line breaks? Like an editor I should use in par= ticular?

Thank you,

St=C3= =A9phane=C2=A0
.=C2=A0


--0000000000006394df059f02eacb-- From nobody Thu Feb 20 07:04:01 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BDB120024 for ; Thu, 20 Feb 2020 07:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKuqaDP2K012 for ; Thu, 20 Feb 2020 07:03:53 -0800 (PST) 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 8F19112003E for ; Thu, 20 Feb 2020 07:03:52 -0800 (PST) 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 1j4nME-0007Aw-2R for hrpc@irtf.org; Thu, 20 Feb 2020 16:03:51 +0100 To: hrpc@irtf.org References: From: Niels ten Oever 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: <61110b0f-eecf-cec7-30d3-f0c46a1719e4@nielstenoever.net> Date: Thu, 20 Feb 2020 16:03:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.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: a2d32f98be707cbcda8602d5fffa976a Archived-At: Subject: Re: [hrpc] Dummy question on editing draft on github 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, 20 Feb 2020 15:03:56 -0000 Hi Stephane, On 2/20/20 3:42 PM, Stéphane Couture wrote: > Hi all, > > I have a dummy question related to edition of drafts. So, I am trying to edit the draft-association on the github: > https://github.com/IRTF-HRPC/drafts/compare/master...stephcouture:master That's a broke link due to .... > > One thing I face is that each line is ending with a line break. So, if I add some words or change a sentence, I have to manually insert line breaks for each of the following lines to keep format. At least if I edit it directly on github or in a text file. Are you editing the .md files? I don't use linebreaks generally. I edit in nano and gedit. Cheers, Niels > > Is there a way to rewrite whole paragraphs, without have to reformat the line breaks? Like an editor I should use in particular? > > Thank you, > > Stéphane  > .  > > > > _______________________________________________ > 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 Feb 25 08:06:05 2020 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98AC3A0F8C for ; Tue, 25 Feb 2020 08:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRrjBrjttEwq for ; Tue, 25 Feb 2020 08:06:01 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0184.hostedemail.com [216.40.44.184]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5143A0F8B for ; Tue, 25 Feb 2020 08:06:01 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 3E9CC8384366 for ; Tue, 25 Feb 2020 16:06:00 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, , RULES_HIT:1:2:41:152:355:379:599:800:854:877:966:967:973:988:989:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1593:1594:1605:1719:1730:1747:1777:1792:2110:2194:2196:2198:2199:2200:2201:2393:2525:2553:2568:2627:2682:2685:2693:2731:2741:2859:2910:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4184:4250:4321:4385:4425:4560:4860:5007:6117:6119:7652:7875:7903:8957:9010:9025:9036:9108:9164:10004:10848:11232:11658:11783:11914:12043:12050:12058:12291:12379:12438:12555:12683:12740:12895:12903:12926:12986:13158:13228:13846:13894:13972:14095:14877:21060:21063:21080:21324:21433:21450:21451:21483:21627:21652:21740:21881:21939:30003:30034:30054:30060:30080:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, X-HE-Tag: girl20_6e8bedacd5156 X-Filterd-Recvd-Size: 10219 Received: from [10.8.2.12] (unknown [5.181.234.228]) (Authenticated sender: avri@doria.org) by omf12.hostedemail.com (Postfix) with ESMTPA for ; Tue, 25 Feb 2020 16:05:59 +0000 (UTC) From: avri doria To: hrpc@irtf.org Reply-To: avri@acm.org, avri@acm.org References: Autocrypt: addr=avri@acm.org; prefer-encrypt=mutual; keydata= mQENBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAG0GWF2cmkgZG9yaWEgPGF2cmlAYWNtLm9yZz6JATkEEwEIACMCGy8HCwkIBwMCAQYVCAIJ CgsEFgIDAQIeAQIXgAUCWb5voAAKCRDVqemiyf8Pp+Y4CACxIMU9jYjjKRvaHxAzyfxk5OfV OG8a2KxI+FvtiRPTxPZ/fNZ8ipVxSjoKqEchZIyMOnkEmmfY2DUmQMM00SYSNAdJywr8fXX6 ra0TGkrBrN6JwxUuk1xWUTCer4GqXVIfSkEd/gHHbnFBu0rt/1U8HHNAKACg67UuZryTrTwm YBbTeKKO3CyP2936l7ZCl+2ZT+z+uc25G9+JCCO2CwvIvWTYybe8+PJ1q7ZojlfT47lnbxv6 nGhHgzcrXY5Dwt8lN0wBDHaWbHc11NRpKbL3U0mMTt3l+atdiDorJ3CofosnL2fdtD4LZTJq johASlNoLdQ/sbQvXo559B1e0JP5tE9BdnJpIERvcmlhIChyZWFsbHkgd2FudCB0byB1c2Ug YW5kIG9sZGVyIGtleSBidXQgaGF2aW5nIHRyb3VibGUpIDxhdnJpQGFjbS5vcmc+iQE4BBMB AgAiAhsvBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCWb5voAAKCRDVqemiyf8Pp+2XB/96 wE/GPWeJzCullmBzorHedTgH0PvDeSx53Ms6XgQouDjOwu+fTU1d9wocSp7tv4KpN8tXzYez dbSh0PAIhuZ3sVhstp2+wKPZmsLzhvjyhpsDKj5eXcu52GGHjxKDCSn2j7pwYVG+rcQHFA4v Z+BwpZRUjD+1PA4OOcwRhgb8IgQbSlDP/PNdsbSeRPq2nlgxF+qdSU7fM2IZeLUhxk0uQP09 fklrSix/qMBZj+PaSu6w2x6LD8Cz01aShUDD0LcY/MiUFsna5qnBAtn8tEccR0fZT6f+0D+l aCoihgoJeojfLezCgyjRBXKpgbZBaxTTYljEpsC25tu5cbuWjEg3uQENBFJXhnsBCAC9oZ7Y 7fdMQOI/cnhbxTAJhKhv6yI9MN131d20LAwVFHR+K1Zd0kj6e6wTYXu3axjfkoED9pSeoXIp EcX2RI/Q509P/REazDKju0mFEwek8fLyKKpsv0+J6h6VZZwk8oscSQ2qIVB7U5DdwRInv/z5 TJyAtrV7fSUTF0kwKt5a1Kdpkcw1wVmS4T1VKselKNzDB9ZmoKvPPKYjSQEHX/z/r0rmso1c D8rhuhxBHRvuUNNOkHmUCnwGYp2qtyAhMoplmWy1mUQuW8Nuj2TisSAlCjQNYQGiIcODiqxr CkQkzo+HDeU+q6/8I868MLMcqcVIhGnP+21cIBL+Tv/k4qQJABEBAAGJAj4EGAECAAkCGy4F Alm+b6ABKcBdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1Evqbmud cE0K1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfC SdhV5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv 4fOGB8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d1 7FO76/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aM kanxFk4vCRfjfl8wt27n9xt27ltwQ5jXCRDVqemiyf8Pp/vMB/9HUlA3G5LPeX7VmrSFhV3b aHzk3sS749d3R/QVmksuzkAymtTfN/LU7EVSzjKRdwJm5KjVg6nRd+x3Fkk/Wjvz4vL0hRrS G1Rw++GhVBtz5TTgbJWXmvhtlFFdlkl2T4k3IvCC9phfIa7fdi3BP+AGml4d+XfJ4KY8dwqi JBaDFB1RANYsnuWC/ho6hUd0dgDC4cCvzbvbsPnEiUKnmac5BrpT3eBnHMY/GDC0CImcDEzy EXloEhE6IUZs8ktOGeskONsXL6FG0OpS11tH4zTUwXA/d4Z5TpNcX/nfbcd374oDK5MW1Rjc fzm/dqERsM+t555z4A6GaJLWV5shyIdh Message-ID: Date: Tue, 25 Feb 2020 11:05:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 200224-2, 02/24/2020), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Interim meeting - 25 Feb 16 UTC 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, 25 Feb 2020 16:06:04 -0000 Hi, This is going on now. cheers, avri On 16-Feb-20 00:16, avri doria wrote: > Hi, > > Thanks Stéphane for the report. > > This interim has been registered with the secretariat and been announced > on list and elsewhere. > > Hope people saw the announcement. > > It is scheduled for: 25 Feb 1600 - 1800 UTC > > Stéphane is providing the zoom room for the meeting: > > 1. Zoom : > > https://yorku.zoom.us/j/234314123 > Meeting ID: 234 314 123 > Find your local number: https://yorku.zoom.us/u/avFFYbR4w > > Draft Agenda - > > Single issue: draft-association > > - Welcome & Agenda review > > - Summary of discussion/work since last HRPC mtg > > - Discussion on next steps for draft > > - Discussion of cases to be included in draft > > - Recruit someone, or more, to work with Stéphane on completing the draft > > - AOB > > Thanks > > avri > > > On 14-Feb-20 16:53, Stéphane Couture wrote: >> Hi all, >> >> Sorry for the delays, but here is a report I made from our last Zoom >> meeting about draft-association, that we held two weeks ago. Sorry >> also for the typos. >> >> As stated in this report and announced previously, the next meeting >> will be on February 25th  from 16:00 to 18:00 GMT, and will be an >> interim meeting (Avri or Mallory could say more on this).  >> >> 0. Participants >> =========== >> >> Stéphane, Niels, Avri, Mallory (for the first part), Juliana >> >> 1. Editorial team >> ============= >> >> Since Joe doesn’t have much time, Niels is still participating and >> Juliana wants to participate more, but doesn’t know to what extent. We >> have decided to make an « open » editorial committee for now, and we >> will decide later on the order of authors, based on who has >> contributed the more (overall, not just in terms of commits on the git >> hub). Stéphane is ok to follow up on coordination until the next IETF >> but we will need a co-editor after. >> >> 2. Report from first seminar  >> ===================== >> >> Stéphane presented some of the stuff we discussed in the first >> seminar. See the slides : >> https://framadrop.org/r/jgvRpOZUq6#VZ8mgyiCF/fDgIeYUFfhS+JkaJra01Vr98VFv0jKAmU= >> >> For the goals, it was suggested that we reframe the goal to “explore >> and map the relationships.” >> >> As for the goals: Niels mentioned that the goal is to explore the >> relationships, before making some recommendations. For instance, you >> have to study – and establish – the relationships between drinking and >> driving, before making decision related to this. This might raise >> (again) the point of the theoretical framework we use to “explore” >> these relationships. If our aim is to establish some kind of causality >> – as we would do for drinking and driving – an interpretative >> framework might not be the best for this. >> >> 3. Work since the last seminar: literature review >> ==================================== >> >> Stéphane presented his work on enhancing literature review. A few more >> documents addressing explicitly the relations between “freedom of >> association and assembly” and “the digital” were found. In particular, >> a draft document from the European Council that was not known to us, >> presented some social cases (slide 12), that could be re-used in the >> research. We still had debates about the relevance of starting with >> social cases rather than technological cases (as it is right now in >> draft-association). >> >> It was agreed that these references should be briefly added to the >> draft-association. Niels mentioned that all the cases identified in >> this document have already been discussed on the list and that it >> would be important to look at how it plays out in “architectural” >> layers relevant to IETF. For instance, the design of encryption is an >> inherent part of protocols, or using source routing. If we can show >> that these choices can make association or joining easier or more >> difficult, it would be good. >> >> Note about the notion of “infrastructural”: We use here >> “infrastructure” in a general sense to refer to the “behind the >> scenes” of normal internet usages, especially protocols. >> Infrastructural is thus opposed here to “policy” or “economic” >> dimensions. What we are interested in here is the broad scope of IETF >> work, not the specific realm of how “infrastructure” is used within >> IETF. To avoid confusion, it was proposed that we talk about the >> “architecture of the Internet”, instead of the “infrastructure of the >> Internet.” >> >> We also presented a summary of an encyclopedia article about “freedom >> of association”, where they present a nuanced version of freedom of >> association. It was mentioned that in an earlier version, Gisela made >> a similar work, but it was considered too “legal”. We might want to >> look at this previous version of the draft >> >> 4. The cases >> =========== >> >> We still had some discussions about the current cases, and especially >> the way in which they inhibit association. We went through the >> difference case studies, and discussing their enabling or disabling >> capacity. This part of the discussion was fully transcribed.  It is >> proposed that we create a table to address each of these cases, which >> will help in turn clarifying the argument. See the table here : >> https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=sharing >> >> 4. What’s next >> =========== >> >> The next meeting will be an ‘interim meeting”, so we will be able to >> have formal decisions. >> >> 1. By the next meeting, we should have a table that analyzes the way >> in which protocols mentioned in the paper inhibit or enable >> association. This table should be done collaboratively.: >> https://docs.google.com/document/d/1r88InF_YejQHmcmHIgtVY1gEXPa1dDT2TAWpuUdMu80/edit?usp=sharing >> >> 2. In the next meeting we should decide if we analyze more thoroughly >> social cases, or we stick to the cases currently in the paper. If we >> go and analyze social cases, it might make the paper stronger, but it >> would probably take much more time. >> >> 3. A “diff” should be presented in the next meeting, so it is approved. >> >> 4. Make sure we resubmit the draft (by March 8^th , 2020). >> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc > From nobody Fri Feb 28 14:40:47 2020 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 DFB343A1F44; Fri, 28 Feb 2020 14:35:30 -0800 (PST) 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.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292933089.19931.18241110843682537534@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:30 -0800 Archived-At: Subject: [hrpc] hrpc - Requested session has been scheduled for IETF 107 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 List-Id: hrpc discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:39 -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 (1:30 requested) Tuesday, 24 March 2020, Afternoon Session II 1550-1720 Room Name: Regency E size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/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): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: wpack gaia irtfopen pearg Key Participant Conflict: capport dnsop dprive doh regext mls People who must be present: Avri Doria Mallory Knodel Resources Requested: Special Requests: Monday-Wednesday if possible. ---------------------------------------------------------