Subject: Re: [hrpc] hrpc Digest, Vol 71, Issue 7

From: Sandra Braman <[email-masked]>
Date: Tue, 2 Feb 2021 04:38:50 -0600

I don't know what makes something officially a "last call," but it sounds
as if the discussion needs to be reopened.  There is a range of reasons why
individuals may have been silent -- I mentioned one that affected me a few
days ago -- but reopening it with active encouragement for those who have
been silent to engage might bring additional others into the conversation
in order to determine whether or not there is an actual consensus and, if
not, where this should go.

One of the problems with determining a "consensus," of course, is the
question of who decides whether or not one has been achieved.  Humming is a
lovely cultural tradition but not necessarily reflective of genuine
consensus among all those involved, for all of the reasons affecting who
even gets into that room in the first place and differences in how loudly
people hum.  Beyond that problem, there is the question of control over the
consensus frame itself for a particular conversation.  The question of
whether or not there is actually a consensus here is clearly significantly
contested.

On Tue, Feb 2, 2021 at 4:07 AM <[email-masked]> wrote:

> Send hrpc mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hrpc digest..."
> Today's Topics:
>
>    1. Re: Comment on draft-guidelines for RG Last Call (Mark Perkins)
>
>
>
> ---------- Forwarded message ----------
> From: Mark Perkins <[email-masked]>
> To: [email-masked]
> Cc:
> Bcc:
> Date: Tue, 2 Feb 2021 21:06:27 +1100
> Subject: Re: [hrpc] Comment on draft-guidelines for RG Last Call
>
> Not sure that Farzaneh is in the rough, I came out clearly against
> attribution a while ago (start of the discussion?).  Not sure how many
> others are also opposed, as not many have spoken - perhaps a straw poll is
> needed? My impression is that there is no consensus on this issue, more
> like a clear division.
>
> Mark P.
> Le 02/02/2021 à 18:57, Niels ten Oever a écrit :
>
> Dear Farzaneh,
>
> In the extensive discussion between you, John, Amelia, Pranesh and others
> you were the only one who said attribution has no role in this document
> whatsoever. You reiterate this position.  But that might mean that you are
> in the rough.
>
> Best,
>
> Niels
> On Feb 2, 2021, at 02:06, farzaneh badii <[email-masked]>
> wrote:
>>
>> Niels,
>>
>> I don't know how you come to consensus. I thought you as one of the
>> drafters need to make changes that capture the consensus. Seems like you
>> have had “many discussions” and all the points I have raised been resolved
>> satisfactorily in this group in my absence. Then the only thing I can do is
>> to record my objection to paragraph 3.3.20: Attribution.
>>
>> I don't think the paragraph as is in that document is human rights
>> enabling and frankly it has the potential to do the opposite. It is a
>> mistake to bring court and law enforcement to the discussion when the scope
>> of this group is "enabling human rights". It is a mistake to make a
>> distinction between natural and legal persons in this case and assume that
>> natural persons may not be harmed in the process because the distinction
>> “may” protect them.
>>
>> I brought reasons and they don't seem to be convincing to you or
>> something you want to work with and it seems to me it is too late now. So I
>> get out of your way and just record my objection to the paragraph.
>>
>> Just to disclose: I have worked on cyber attack attribution processes
>> academically, and believe that attribution is one way to hold cyber
>> attackers accountable. I just don’t think we need the protocol developer
>> think about ways of attribution to make it easier to attribute cyber
>> attacks in court for legal remedy and include this in the guidelines for
>> human rights protection document as a “access to legal remedy”. Anonymity
>> makes attribution harder but still not impossible. Many John Doe’s have had
>> cases against them which provided the plaintiffs with the appropriate
>> remedies.
>>
>>
>>
>>
>>
>> On Mon, Feb 1, 2021 at 5:19 PM Niels ten Oever < [email-masked]>
>> wrote:
>>
>>> Dear Farzaneh,
>>>
>>> Do your alterations reflect the content of the discussion, or mere your
>>> opinion?
>>>
>>> I hope we're seeking to reach a consensus during last call, not
>>> reopening the discussion.
>>>
>>> Best,
>>>
>>> Niels
>>>
>>> On Feb 1, 2021, at 22:22, farzaneh badii < [email-masked]>
>>> wrote:
>>>>
>>>> Here we go:
>>>>
>>>>
>>>> Question(s): Can your protocol facilitate a negatively impacted
>>>>
>>>>    party's right to the appropriate  legal remedy without
>>>> disproportionately impacting
>>>>
>>>>    other parties' human rights, especially their right to privacy?
>>>>
>>>>
>>>>    Explanation: Access to legal remedy is a human right that ensures
>>>>
>>>>    that individuals whose rights have been violated can seek remedies
>>>>
>>>>
>>>>
>>>>
>>>>    through a judicial authority.   Attribution (i.e. mechanisms in
>>>>
>>>>    protocols or architectures that are designed to make communications
>>>>
>>>>    or artifacts attributable might help with seeking the appropriate
>>>> remedy.)  to a certain computer or individual) can be
>>>>
>>>>    a part of this, since it may allow law enforcement agencies to
>>>>
>>>>    identify a possible violator .  However, attribution mechanisms may
>>>>
>>>    impede the exercise of the right to privacy.  The Special Rapporteur
>>>>
>>>>    for Freedom of Expression has also argued that anonymity is an
>>>>
>>>>    inherent part of freedom of expression.  [Kaye] Considering the
>>>>
>>>>    adverse impact of attribution on the right to privacy and freedom of
>>>>
>>>>    expression, attribution on an individual level may  is not be
>>>> consistent
>>>>
>>>>    with human rights.  However, attribution to corporate entities,
>>>>
>>>>    associations, and/or countries may not directly negatively impact
>>>>
>>>>    human rights.
>>>>
>>>>
>>>>    Impacts:
>>>>
>>>>
>>>>    -   Right to legal remedy
>>>>
>>>>
>>>>    -  Right to security
>>>>
>>> Farzaneh
>>>>
>>>>
>>>> On Mon, Feb 1, 2021 at 2:38 PM Niels ten Oever < [email-masked]>
>>>> wrote:
>>>>
>>>>> Hi Farzaneh,
>>>>>
>>>>> On 31-01-2021 19:16, farzaneh badii wrote:
>>>>> > Hello Niels.
>>>>> >
>>>>> >
>>>>> > I don't know how we measure consensus here. But I remember weighing
>>>>> in back then as well(When Mr. Curran weighed in back in 2019). Here is the
>>>>> thread:  https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution
>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmlLt_T_4$>
>>>>> < https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution
>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmlLt_T_4$>>
>>>>>
>>>>> >
>>>>> > I can see that unfortunately I missed the discussion on this topic
>>>>> during the past year, and that's my fault, but I can bring reasons not to
>>>>> add "attribution and legal remedy" to this document at all.
>>>>> >
>>>>> > 1. Access to legal remedy is something that the States are
>>>>> supposedly in charge of bringing to their citizens.Which should (in theory)
>>>>> ensure that human rights are enforced. I don't think there was an intention
>>>>> to  provide  mechanisms for "enforcement" of human rights in various legal
>>>>> systems through Internet protocols. As mentioned in the beginning of your
>>>>> document:
>>>>> > "Human rights threats on the Internet come in a myriad of
>>>>> forms.* **P**rotocols and standards can harm or enable* the right to
>>>>> freedom of expression, right to non-discrimination, right to equal
>>>>> protection, right to participate in cultural life, arts and science, right
>>>>> to freedom of assembly and association, and the right to security."
>>>>> >
>>>>> > So we are not in the business of enforcing but providing an enabling
>>>>> environment. Because if we want to help law enforcement and the judicial
>>>>> authorities enforce human rights through Internet protocols we should bear
>>>>> in mind that that they are not always staunch advocates of human rights. So
>>>>> what I assume we are trying to do here is to help Internet protocol not to
>>>>> facilitate harm and "enable" human rights.
>>>>> >
>>>>>
>>>>> The text in the draft seeks to address this risk. I have sought to
>>>>> address all points made in that discussion, and I would not like to re-open
>>>>> that debate. If you feel the text is unbalanced, could you perhaps provide
>>>>> text suggestions?
>>>>>
>>>>> > 2. Attribution, section 3.3.20  of the Guideline, the authors assert
>>>>> that: "However, attribution to corporate entities, associations, and/or
>>>>> countries may not directly negatively impact human rights." I think this is
>>>>> not a very well backed up claim. Because in some cases some associations
>>>>> might be political or they might be human rights associations dealing with
>>>>> a dictatorship. Attribution to those associations certainly can impact
>>>>> their human rights negatively. Even when it comes to corporations, some
>>>>> CEOs of digital companies are put in jail because of the materials posted
>>>>> on their websites. I don't think we can argue that attribution to corporate
>>>>> entities might not adversely impact human rights.
>>>>> >
>>>>>
>>>>> Again, the keyword in that sentence is 'may', so there is no strong
>>>>> claim made.
>>>>>
>>>>> > All in all I think section 3.3.20 does not help Internet Protocols
>>>>> enable human rights and it can be misinterpreted.
>>>>>
>>>>> I think the text in there is not strong and shows different
>>>>> perspectives and potential consequences. But again, happy to receive text
>>>>> suggestions.
>>>>>
>>>>> >
>>>>> > And in my previous email I talked about the problems with threat
>>>>> intelligence agencies and some of their conducts and the use of WHOIS for
>>>>> attribution (which was actually not designed to "identify" actors but
>>>>> unfortunately was used for that) so I will not reiterate here.
>>>>>
>>>>> From exactly that discussion we got the idea to remove individuals,
>>>>> and leave non-natural persons in.
>>>>>
>>>>> Best,
>>>>>
>>>>> Niels
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sun, Jan 31, 2021 at 5:52 AM Niels ten Oever <
>>>>> [email-masked] <mailto: [email-masked]>> wrote:
>>>>> >
>>>>> >     Hi Farzaneh,
>>>>> >
>>>>> >     Thanks a lot for the review!
>>>>> >
>>>>> >     On 30-01-2021 23:00, farzaneh badii wrote:
>>>>> >     > Hello
>>>>> >     >
>>>>> >     > Adding my comments on this document:
>>>>> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmcgv0BsM$>
>>>>> < https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmcgv0BsM$>>
>>>>> < https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmcgv0BsM$>
>>>>> < https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmcgv0BsM$>>
>>>>> >
>>>>> >     >
>>>>> >     > 1. One major issue that I see here and you might be able to
>>>>> easily solve it is that there is no distinction between user facing
>>>>> protocols and other protocols. For example, you ask for accessibility and
>>>>> consideration of culture etc. Are you asking all the protocols to be
>>>>> provided in multiple languages, even those that only developers and
>>>>> implementers use and not the actual users? You might want to clarify that.
>>>>> >     >
>>>>> >
>>>>> >     We had a quite extensive discussion about this in relation to
>>>>> the presentation by Ramsey Nasr who create Qalb, an Arabic programming
>>>>> language. Programmers are the most frequent 'users' of protocols - if we
>>>>> continue using only latin characters and English documentation in protocols
>>>>> we are likely to reproduce the existing lack of diversity in protocol
>>>>> developers communities. But we can make the text on this clearer as well!
>>>>> >
>>>>> >     > 2.section 3.3.1 on connectivity, you mention that "considering
>>>>> the fact that network quality and conditions vary across geography and time
>>>>> it is also important to design protocols such that they are reliable even
>>>>> on low bandwidth ...". Then in your example you say: Middleboxes (including
>>>>> NAT).... can create potential for abuse. NAT is a Network Address
>>>>> Translation protocol. I don't think it has anything to do with bandwidth.
>>>>> In this example you also mention CDNs. Are you suggesting that the
>>>>> developer should not consider "Middleboxes" protocols? I think you need to
>>>>> work on the example of section 3.3.1 some more to make it clearer.
>>>>> >     >
>>>>> >
>>>>> >     Excellent point - we'll address this in a future version.
>>>>> >
>>>>> >     > 3. section 3.3.20 remedy and attribution
>>>>> >     > This section worries me. As a  scholar I have worked on cyber
>>>>> attribution to some extent and believe in general when we have the right
>>>>> processes in place, attribution is very important and can hold
>>>>> cyber-attackers accountable. I am aware of some of the attribution
>>>>> processes and unfortunately some threat intelligence firms and open source
>>>>> intelligence organizations can violate the privacy of individuals by
>>>>> profiling them. Also, uncontrolled attribution mechanisms can lead to
>>>>> frivolous intellectual property claims. Both some threat intelligence firms
>>>>> and IP firms have used WHOIS extensively in their favor to attribute
>>>>> cybersecurity attacks and bring forward IP claims. WHOIS protocol did not
>>>>> have the intention to actually identify organizations and individuals, but
>>>>> to make them "contactable".and it was still used and mined for so many
>>>>> years and those who have abused WHOIS have not been held accountable.When
>>>>> you suggest they consider "attribution" when developing protocols it
>>>>> >     > concerns me because it is not enough that you limit
>>>>> attribution to organizations and states. These kinds of attributions can be
>>>>> used against individuals and until we do not have the right preserving
>>>>> processes to put in place for those who want to be in the attribution
>>>>> business, rights of the individual can be at risk. there are very privacy
>>>>> conscious cybersecurity researchers out there but unfortunately that does
>>>>> not ensure a systematic practice of attribution in a fair manner. And you
>>>>> mention attribution to associations is fine and may not directly negatively
>>>>> impact human rights. Associations can themselves be at risk of
>>>>> frivolous attacks and frivolous attribution. I am concerned about this
>>>>> paragraph. I think we should have a conversation about it.
>>>>> >     >
>>>>> >
>>>>> >     In the proposed text I tried to capture the consensus that
>>>>> emerged from the extensive discussion that was had on this list. Do you
>>>>> have concrete suggestions on how to better capture that conensensus? I am
>>>>> afraid we would go back and repeat the same discussion.
>>>>> >
>>>>> >     > 4. Nice to see that you mention DoH. It's a great privacy
>>>>> preserving protocol.
>>>>> >     >
>>>>> >     >
>>>>> >
>>>>> >     Thanks!
>>>>> >
>>>>> >     Niels
>>>>> >
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     > Farzaneh
>>>>> >     >
>>>>> >     >
>>>>> >     > On Sat, Jan 30, 2021 at 10:35 AM Corinne Cath <
>>>>> [email-masked] <mailto: [email-masked]> <mailto:
>>>>> [email-masked] <mailto: [email-masked]>>> wrote:
>>>>> >     >
>>>>> >     >     Hi all,
>>>>> >     >
>>>>> >     >     I trust this email finds you well. I did a review of the
>>>>> draft, from my perspective as an academic. Take it as you please. My main
>>>>> concern is that some of the language reads a bit deterministic (as, I know
>>>>> so does RFC 8280). It means that a lot of onus is put on the impact of a
>>>>> protocol, as opposed the role of the individuals that write them.
>>>>> >     >
>>>>> >     >     I think through out the document, it would be interesting
>>>>> (especially in section 1 through 3.2.5) to see if you can rewrite such that
>>>>> you speak more directly to the protocol developers. I think that section
>>>>> 3.3 does that well, in terms of the tone it takes. As it clearly connects
>>>>> the actions of protocol developers to their potential outcomes.
>>>>> >     >
>>>>> >     >     Hope this is helpful!
>>>>> >     >
>>>>> >     >     Kind regards,
>>>>> >     >
>>>>> >     >     Corinne
>>>>> >     >
>>>>> >     >     ----------------------------- ----
>>>>> >     >
>>>>> >     >     *1. Introduction*
>>>>> >     >
>>>>> >     >     "It provides questions engineers should ask
>>>>> >     >
>>>>> >     >        themselves when developing or improving protocols if
>>>>> they want to
>>>>> >     >        understand their potential human rights impact."
>>>>> >     >
>>>>> >     >
>>>>> >     >     >> maybe if they want to understand potential human rights
>>>>> concerns? Impact seems a little deterministic, as you also mention in the
>>>>> next sentence, I wonder if you can prove such direct impact between
>>>>> protocol development in the IETF and impact on human rights.
>>>>> >     >
>>>>> >     >     "The research establishes
>>>>> >     >
>>>>> >     >        that human rights relate to standards and protocols,
>>>>> and offers a
>>>>> >     >        common vocabulary of technical concepts that impact
>>>>> human rights and
>>>>> >     >        how these technical concepts can be combined to ensure
>>>>> that the
>>>>> >     >        Internet remains an enabling environment for human
>>>>> rights."
>>>>> >     >
>>>>> >     >
>>>>> >     >     >> same comment for the word impact, perhaps shape?
>>>>> influence? etc.
>>>>> >     >
>>>>> >     >
>>>>> >     >           3.1 <
>>>>> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05*section-3.1__;Iw!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmqu9haL4$>
>>>>> <
>>>>> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05*section-3.1__;Iw!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmqu9haL4$>>>.
>>>>> Human rights threats
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >      "Protocols and standards can harm or enable the right to
>>>>> freedom of
>>>>> >     >        expression, right to non-discrimination, right to equal
>>>>> protection,
>>>>> >     >        right to participate in cultural life, arts and
>>>>> science, right to
>>>>> >     >
>>>>> >     >     freedom of assembly and association, and the right to
>>>>> security. "
>>>>> >     >
>>>>> >     >
>>>>> >     >     >> again, deterministic language. Perhaps soften or add
>>>>> more concrete examples for context, that draw from current IETF
>>>>> discussions/standards.
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >           3.3 <
>>>>> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05*section-3.3__;Iw!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmYPOkf-A$>
>>>>> <
>>>>> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3
>>>>> <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05*section-3.3__;Iw!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmYPOkf-A$>>>.
>>>>> Guidelines for human rights considerations
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >     again, use of the word impact in the introduction.
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >
>>>>> >     >     --
>>>>> >     >     Corinne Cath - Speth
>>>>> >     >     Ph.D. Candidate, Oxford Internet Institute & Alan Turing
>>>>> Institute
>>>>> >     >
>>>>> >     >     Web: www.oii.ox.ac.uk/people/corinne-cath
>>>>> <https://urldefense.com/v3/__http://www.oii.ox.ac.uk/people/corinne-cath__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmGORuL8k$>
>>>>> < http://www.oii.ox.ac.uk/people/corinne-cath
>>>>> <https://urldefense.com/v3/__http://www.oii.ox.ac.uk/people/corinne-cath__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmGORuL8k$>>
>>>>> < http://www.oii.ox.ac.uk/people/corinne-cath
>>>>> <https://urldefense.com/v3/__http://www.oii.ox.ac.uk/people/corinne-cath__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmGORuL8k$>
>>>>> < http://www.oii.ox.ac.uk/people/corinne-cath
>>>>> <https://urldefense.com/v3/__http://www.oii.ox.ac.uk/people/corinne-cath__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmGORuL8k$>>>
>>>>>
>>>>> >     >     Email: [email-masked] <mailto: [email-masked]>
>>>>> <mailto: [email-masked] <mailto: [email-masked]>> &
>>>>> [email-masked] <mailto: [email-masked]> <mailto:
>>>>> [email-masked] <mailto: [email-masked]>>
>>>>> >     >     Twitter: @C_CS
>>>>> >     >     _____________________________ __________________
>>>>> >     >     hrpc mailing list
>>>>> >     >      [email-masked] <mailto: [email-masked]> <mailto:
>>>>> [email-masked] <mailto: [email-masked]>>
>>>>> >     >      https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>
>>>>> < https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>>
>>>>> < https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>
>>>>> < https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>>>
>>>>>
>>>>> >     >
>>>>> >     >
>>>>> >     > ______________________________ _________________
>>>>> >     > hrpc mailing list
>>>>> >     > [email-masked] <mailto: [email-masked]>
>>>>> >     > https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>
>>>>> < https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>>
>>>>>
>>>>> >     >
>>>>> >
>>>>> >     --
>>>>> >     Niels ten Oever, PhD
>>>>> >     Postdoctoral Researcher - Media Studies Department - University
>>>>> of Amsterdam
>>>>> >     Postdoctoral Research Fellow - Communications Department - Texas
>>>>> A&M University
>>>>> >     Research Fellow - Centre for Internet and Human Rights -
>>>>> European University Viadrina
>>>>> >     Associated Scholar - Centro de Tecnologia e Sociedade - Fundação
>>>>> Getúlio Vargas
>>>>> >
>>>>> >     W: https://nielstenoever.net
>>>>> <https://urldefense.com/v3/__https://nielstenoever.net__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmZWdheys$>
>>>>> < https://nielstenoever.net
>>>>> <https://urldefense.com/v3/__https://nielstenoever.net__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmZWdheys$>>
>>>>>
>>>>> >     E: [email-masked] <mailto: [email-masked]>
>>>>> >     T: @nielstenoever
>>>>> >     P/S/WA: +31629051853
>>>>> >     PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
>>>>> >
>>>>> >     Read my dissertation 'Wired Norms' here:
>>>>> https://pure.uva.nl/ws/files/50781961/Thesis.pdf
>>>>> <https://urldefense.com/v3/__https://pure.uva.nl/ws/files/50781961/Thesis.pdf__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmJOAMClE$>
>>>>> < https://pure.uva.nl/ws/files/50781961/Thesis.pdf
>>>>> <https://urldefense.com/v3/__https://pure.uva.nl/ws/files/50781961/Thesis.pdf__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmJOAMClE$>>
>>>>>
>>>>> >     _____________________________ __________________
>>>>> >     hrpc mailing list
>>>>> >      [email-masked] <mailto: [email-masked]>
>>>>> >      https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>
>>>>> < https://www.irtf.org/mailman/listinfo/hrpc
>>>>> <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>>
>>>>>
>>>>> >
>>>>>
>>>>> --
>>>>> Niels ten Oever, PhD
>>>>> Postdoctoral Researcher - Media Studies Department - University of
>>>>> Amsterdam
>>>>> Postdoctoral Research Fellow - Communications Department - Texas A&M
>>>>> University
>>>>> Research Fellow - Centre for Internet and Human Rights - European
>>>>> University Viadrina
>>>>> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação
>>>>> Getúlio Vargas
>>>>>
>>>>> W: https://nielstenoever.net
>>>>> <https://urldefense.com/v3/__https://nielstenoever.net__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmZWdheys$>
>>>>> E: [email-masked]
>>>>> T: @nielstenoever
>>>>> P/S/WA: +31629051853
>>>>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
>>>>>
>>>>> Read my dissertation 'Wired Norms' here:
>>>>> https://pure.uva.nl/ws/files/50781961/Thesis.pdf
>>>>> <https://urldefense.com/v3/__https://pure.uva.nl/ws/files/50781961/Thesis.pdf__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmJOAMClE$>
>>>>>
>>>>
>>
>> --
>> Farzaneh
>>
>>
> _______________________________________________
> hrpc mailing [email-masked]://www.irtf.org/mailman/listinfo/hrpc <https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$>
>
>
>
> <https://urldefense.com/v3/__https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmdWjSL3Q$> Garanti
> sans virus. www.avast.com
> <https://urldefense.com/v3/__https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmdWjSL3Q$>
> <#m_-3487738066469627961_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> hrpc mailing list
> [email-masked]
>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!URgHL-MGkV0X0jyCjjSElE0P1rq-lw91NOgEgyZXjmpA9gGCELNgpD3MPnzmNdA9cSg$
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Feb 2021 09:15:25 -0500

(Still work for ISOC, this is still just my own opinion.)

On Tue, Feb 02, 2021 at 04:38:50AM -0600, Sandra Braman wrote:

>question of who decides whether or not one has been achieved.

There is an RFC about this that was an IETF product, so at least there
is something to work on from the IETF context:
https://tools.ietf.org/html/rfc7282.  Of course, this RG isn't a part
of the IETF and has its own rules, but I understood the Chairs
previously to have said that they were following IETF process as
closely as possible for a RG to do.  I have previously expressed my
doubts about how well that could work, so I will refrain from
repeating myself.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 2 Feb 2021 11:49:08 -0500

> doubts about how well that could work, so I will refrain from

Only to clarify that as co-chair I am not in favour of a blanket rule 
for all HRPC drafts to reach consensus before publication. I think it 
makes sense in some cases but not in others. And to set the bar so high 
for research can disincentivise good, exploratory work. (I've said all 
of this many times before, nothing new just reminding folks of my position).

That said I do feel that draft-guidelines, because it's based on RFC 
8280 and meant to be usefully applied to IETF documents, should be at 
the end of the spectrum of *more* consensus than, say, draft-political 
or draft-feminism.

I also think that so far Gurshabad and Niels have done a stellar job of 
building this draft upon a strong foundation of group consensus. It was 
written with input from multiple people, notably those who have 
attempted to use it and they've been responsive to any and all feedback 
so far. It's a very strong document because of it.

Looking forward to the next version,

-Mallory

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

---

From: avri doria <[email-masked]>
Date: Wed, 3 Feb 2021 01:35:19 -0500

Hi,

I believe that any RFC published by the HRPC RG should have rough
consensus for publication. That does not mean that all points in the
draft are consensus points, but there should be consensus for
publication as a complete document, though there may be some who do not
agree (the proverbial, in the rough).  This is the same criteria we used
for RFC8280.  When both co-chairs believe there is such consensus my
intention is that we confirm that with the RG and if confirmed, then
proceed to IESG review.

At this point I do not think we are there yet.

According to my understanding of the IRSG guidelines, we will need to
add a sentence or two indicating the process we went through and the
degree to which there is consensus.  We will also need to add a line to
the abstract indicating that it is an IRTF RG product. I will provide
text for these at the appropriate time.

I appreciate the efforts the author/editors are going through to try and
resolve the issues that people are bringing up. I also appreciate the
fact that there have been serious reviews with extended comments and
that there is a discussion on remaining issues.

Thanks

avri

(acting as shepherd for the document)

On 2/2/2021 11:49 AM, Mallory Knodel wrote:
> makes sense in some cases but not in others. And to set the bar so
> high for research can disincentivise good, exploratory work. (I've
> said all of this many times before, nothing new just reminding folks
> of my position).
>
> I also think that so far Gurshabad and Niels have done a stellar job
> of building this draft upon a strong foundation of group consensus. It
> was written with input from multiple people, notably those who have
> attempted to use it and they've been responsive to any and all
> feedback so far. It's a very strong document because of it.
>