Subject: [hrpc] draft-association doc shepherd

From: Mallory Knodel <[email-masked]>
Date: Mon, 7 Mar 2022 10:18:51 -0500

Hi folks,

Hope your week is starting off well.

Wanted to thank Nick Doty for agreeing to be the doc shepherd for 
draft-association. It's been 1 month shy of a year since we started 
looking! This will help us progress the draft into last call, but first 
we'll look forward to Nick's review followed by, if needed, any updates 
to the group's draft.

Thanks!

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Nick Doty <[email-masked]>
Date: Mon, 7 Mar 2022 12:39:07 -0500

Hi HRPC-ers and document editors,

I've read through draft-association in preparation for shepherding.
Initial review comments below. I'm also catching up on the other
reviews over the history of this draft; apologies where I may have
duplicated comments or questions already raised by others.

Cheers,
Nick

-- 
Nick Doty | https://npdoty.name
Senior Fellow, Internet Architecture
Center for Democracy & Technology | https://cdt.org
--

could we get a clearer thesis rather than just discussing freedom of
association and the internet?

abstract should summarize the conclusions, not just what the document will do

formatting issues in the introduction?

do we need a section on vocabulary used? if these terms have
definitions or specific citations, can't we just cite them when
they're referred to?

> The research question of this document is: what are the protocol development considerations for freedom of assembly and association?

should the methodology section refer so deeply to the 8280 process?
I'm more interested in the methodology for this document

some small grammatical issues throughout ("Such as Article 5")

there are acceptable restrictions to freedom of association by states,
are there also acceptable (or unacceptable) limitations by private
actors?

rights are indivisible, interrelated, multually reinforcing -- this is
such a valuable way of thinking about this. worth reading in more
detail the Vienna Declaration for my own work, W3C projects on ethical
principles and privacy.

> The report mentions the
>    following use cases

these aren't use cases, but examples or case studies

"avoid protester violence" is ambiguous/confusing

>  Use of VPNs (Virtual Private Networks) to the TOR network to

is this "or" or "and" the Tor network? and Tor is not all caps, I think?

>    recommendations on which the following could be relevant to our
>   discussion here:

just "recommendations which could be relevant, including:" ?

>    Online association and assembly are the starting point of group to
>   mobilization in modern democracies, and even more so where physical

"starting point of group to mobilization"? can't parse this

>       registrars, on the other hand could gTLDs also enable communities

is this a question? or maybe "gTLDs could also enable"

>    -  The impact of middleboxes on the ability of users to connect to

paragraph needs edits for grammar and clarity

questions raised from literature review: these are super interesting!
maybe better not to phrase them as yes/no, but rather look for the
conditions or reasons

Section 6 could use a copyedit.

"whether they" -- rather than whether it does or doesn't, maybe how it
facilitates and how it inhibits?

I'm confused by the structure of 6.1, and how these subsections are related

"more and more commercial" -> "more commercial"? also, is it
commercialism that's the relevant change, or wideness of adoption?

"next to that countries" ??

spam and ddos are definitely interesting and relevant illustrations.
but what are the conclusions here for protocol design? how does this
help us with the question of where in the stack, or how to balance
interests of pbulic order, public health and the rights of others?

mailing lists and spam: again, very relevant, but isn't speaking to
the protocol-specific design decisions

"typically too many for ." incomplete

webrtc section has a very long quotation, that should be
paraphrased/cited, or maybe blockquoted and then provided with more
context and analysis

"One the one hand"

> The risk of surveillance is also true in an offline space, but this
>   is generally easy to analyze for the end-user.

I'm not sure surveillance is so clear offline either, but the
comprehensibility of implications is certainly an important
consideration.

I'm not clear that "peer production" and "peer-to-peer networking" are
the same or similar concepts.

more copyediting and corrections to grammar and punctuation needed here.

not clear the segue between W3C accessibility and IETF issues around
internationalization

the Arabic programming language name is not rendered correctly on the
datatracker html version of the draft. it's an excellent illustration
of part of the problem! I don't think we should publish this RFC
unless we can include that text.

> Despite long significant efforts, it is
>   still largely impossible to register an email address in a language
>   such as Devanagari, Arabic, or Chinese

wow! this is amazing. (also, this isn't specific to the example of
protocol designs being in English but i18n happening in the use --
this is i18n being mostly unsuccessful in one of the most fundamental
applications on the internet) I'm kind of blown away by this. can we
cite a summary of the status and the problem? can we include email
addresses with non-ascii characters in the correspondence list for
this draft?

> Some IRC servers support SSL/TLS
>    connections for security purposes [RFC7194] which helps stop the use
>   of packet sniffer programs to obtain the passwords of IRC users, but
>   has little use beyond this scope due to the public nature of IRC
>   channels.

I don't think this is a full description of the security guarantees of
TLS. this could protect knowing which channel the user connected to,
or maybe even that they're using IRC on that server, or protect the
user's IRC identity (not just the password), and provide authenticity
about the server that they believe they're connecting to. but use, TLS
doesn't provide much confidentiality as to the contents of the
channel's conversation in publicly accessible channels.

> different technical designs come with
   different properties and characteristics.  These properties and
   characteristics on the one hand enable people to assemble and
   associate, but on the other hand also add limiting, or even
   potentially endangering, characteristics

this is an important conclusion, and the kind of conclusion that I've
most been looking for in this draft, but probably needs to be
described in more depth.

security considerations: would it maybe be more relevant to describe
here how faa is related to security?

iana considerations: can this section just be removed?

where is feedback requested for this document? is the work happening
on github, and if so, can we include a link to that in the draft?

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 7 Mar 2022 20:27:58 +0100

Dear Nick,

Thanks a lot for coming on board as document shepherd. I am greatly looking forward to working with you. I have tried to address some of your comments below and in a new version.

https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-association-09

On 07-03-2022 18:39, Nick Doty wrote:
> Subject:
> Re: [hrpc] draft-association doc shepherd
> From:
> Nick Doty <[email-masked]>
> Date:
> 07-03-2022 18:39
> 
> To:
> Mallory Knodel <[email-masked]>, Niels ten Oever <[email-masked]>
> CC:
> Hrpc <[email-masked]>
> 
> 
> -- Nick Doty | https://npdoty.name Senior Fellow, Internet Architecture Center for Democracy & Technology | https://cdt.org -- 

> could we get a clearer thesis rather than just discussing freedom of association and the internet? 

This comes straight from the charter of hrpc, since it tries to execute the research plan formulated there : https://datatracker.ietf.org/doc/charter-irtf-hrpc/

But I have sought to make it more clear by adding the research question.

> abstract should summarize the conclusions, not just what the document will do formatting issues in the introduction? 

Added

> do we need a section on vocabulary used? if these terms have definitions or specific citations, can't we just cite them when they're referred to?

Since this is interdisciplinary work, we thought that is would be good to establish the main concepts, also to prevent discussing the again and again.

> should the methodology section refer so deeply to the 8280 process?

It explains why we work on this draft and it establishes the relationship to other documents of the RG and how these documents fit together. This seems to be a regular point for discussion in this group. That is why it is there. But I removed it for the next version.

> I'm more interested in the methodology for this document

OK, removed the para about RFC8280

> some small grammatical issues throughout ("Such as Article 5")

s/Such as Article 5/An example of this is Article 5

> are there also acceptable (or unacceptable) limitations by private

I will need to do some research on this.

> detail the Vienna Declaration for my own work, W3C projects on ethical

Good to hear!

> these aren't use cases, but examples or case studies

s/use case/examples

> is ambiguous/confusing
s/avoid protester violence/ prevent potential property destruction by protesters

> is this "or" or "and" the Tor network? 

and

> and Tor is not all caps, I think?
> 

fixed

> just "recommendations which could be relevant, including:" ?

done.

> "starting point of group to mobilization"? can't parse this

s/group mobilization/civic mass-mobilization

> is this a question? or maybe "gTLDs could also enable"

fixed

> paragraph needs edits for grammar and clarity

fixed.

* The impact of middleboxes on the ability of users to connect to the Internet and therefore their ability to exercise their right to freedom of association and assembly. Lack of connectivity can significantly impact freedom of assembly and association of a user. Especially if the user cannot retrieve the reason for their inability to connect, and if there thus is no possibility to for the user to have access to due process to dispute the lack of (secure or private) connectivity in general or to a specific service.

> maybe better not to phrase them as yes/no, but rather look for the

The questions are particularly narrow so that they can be answered in the analysis below.

> facilitates and how it inhibits?

Fixed

> I'm confused by the structure of 6.1, and how these subsections are related

These subsections organize the different cases per topic.

> commercialism that's the relevant change, or wideness of adoption?

s/more and more commercial/more widely adopted
> "next to that countries" ??

Next to that, countries are increasingly adopting regulatory opt-in regimes for mailing lists and commercial e-mail, with a possibility of serious fines in case of violation.
> interests of pbulic order, public health and the rights of others?

This is a significant conclusion I would say:

Because of the interrelation of technologies, it cannot be said that there is one point in the technical stack where one can locate the characteristics of “peaceful” or “non-peaceful” association visible to protocol developers. In the cases of spam blocking and DDoS mitigation, “peaceful or non-peaceful” is not a meaningful heuristic, or even characteristic, of problematic content. If anything, their commonality is their unrequested and nature, next to scale and volume.
  This allows us to draw the conclusion that DDoS and spam are not examples of freedom of association or assembly.

> the protocol-specific design decisions
The section seeks to answer the questions that arose from the literature review, based on typical cases.

The ability to configure an emaillist to receive mail for everyone or only selected addressed is a protocol function I would say, no?

> "typically too many for ." incomplete

fixed

> paraphrased/cited, or maybe blockquoted and then provided with more

Fixed

> "One the one hand"

Fixed

> comprehensibility of implications is certainly an important

weakened the statement

The risk of surveillance is also exists in an offline space, but this is generally slight easier to analyze for the end-user. Security and privacy expectations of the end-user could be either improved or made explicit.

> the same or similar concepts.

Peer-to-peer networking, according to Benkler is an example of peer production.

> not clear the segue between W3C accessibility and IETF issues around

Fixed

> unless we can include that text.

Maybe something we can ask the xml2rfc list?

> addresses with non-ascii characters in the correspondence list for

ahahaaha, if we find an email server offering this.

> here how faa is related to security?

Not sure whether this is relevant. We can discuss this in the hrpc session.

> iana considerations: can this section just be removed?

Afaik it is obligatory

> on github, and if so, can we include a link to that in the draft?

https://github.com/IRTF-HRPC/draft-association - if you think it is useful I can add it to the draft.

Thanks very much, and looking forward to continue working on this.

Best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Affiliated Faculty - Digital Democracy Institute - Simon Fraser University
Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
Research Fellow - Centre for Internet and Human Rights - European University Viadrina

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my latest article on Internet infrastructure governance in Globalizations here: https://www.tandfonline.com/doi/full/10.1080/14747731.2021.1953221

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 7 Mar 2022 14:36:43 -0500

And you can check out the current version, its recent changes and open 
issues and pull requests here: 
https://github.com/IRTF-HRPC/draft-association/

-M

On 3/7/22 2:27 PM, Niels ten Oever wrote:
> Dear Nick,
>
> Thanks a lot for coming on board as document shepherd. I am greatly 
> looking forward to working with you. I have tried to address some of 
> your comments below and in a new version.
>
>> -- Nick Doty | https://npdoty.name Senior Fellow, Internet 
>> Architecture Center for Democracy & Technology | https://cdt.org -- 
>
>
> This comes straight from the charter of hrpc, since it tries to 
> execute the research plan formulated there : 
> https://datatracker.ietf.org/doc/charter-irtf-hrpc/
>
>> abstract should summarize the conclusions, not just what the document 
>> will do formatting issues in the introduction? 
>
> Added
>
> Since this is interdisciplinary work, we thought that is would be good 
> to establish the main concepts, also to prevent discussing the again 
> and again.
>
>>> The research question of this document is: what are the protocol 
>>> development considerations for freedom of assembly and association?
> It explains why we work on this draft and it establishes the 
> relationship to other documents of the RG and how these documents fit 
> together. This seems to be a regular point for discussion in this 
> group. That is why it is there. But I removed it for the next version.
>
> * The impact of middleboxes on the ability of users to connect to the 
> Internet and therefore their ability to exercise their right to 
> freedom of association and assembly. Lack of connectivity can 
> significantly impact freedom of assembly and association of a user. 
> Especially if the user cannot retrieve the reason for their inability 
> to connect, and if there thus is no possibility to for the user to 
> have access to due process to dispute the lack of (secure or private) 
> connectivity in general or to a specific service.
>
> Next to that, countries are increasingly adopting regulatory opt-in 
> regimes for mailing lists and commercial e-mail, with a possibility of 
> serious fines in case of violation.
>>
> Because of the interrelation of technologies, it cannot be said that 
> there is one point in the technical stack where one can locate the 
> characteristics of “peaceful” or “non-peaceful” association visible to 
> protocol developers. In the cases of spam blocking and DDoS 
> mitigation, “peaceful or non-peaceful” is not a meaningful heuristic, 
> or even characteristic, of problematic content. If anything, their 
> commonality is their unrequested and nature, next to scale and volume.
>  This allows us to draw the conclusion that DDoS and spam are not 
> examples of freedom of association or assembly.
>
>>
> The section seeks to answer the questions that arose from the 
> literature review, based on typical cases.
>
> The ability to configure an emaillist to receive mail for everyone or 
> only selected addressed is a protocol function I would say, no?
>
>
> The risk of surveillance is also exists in an offline space, but this 
> is generally slight easier to analyze for the end-user. Security and 
> privacy expectations of the end-user could be either improved or made 
> explicit.
>