Re: [hrpc] Possible options for a HRPC research publication

Mallory Knodel <mknodel@cdt.org> Fri, 10 April 2020 18:55 UTC

Return-Path: <mknodel@cdt.org>
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 75BFE3A0D4B for <hrpc@ietfa.amsl.com>; Fri, 10 Apr 2020 11:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTfWPAvStmbK for <hrpc@ietfa.amsl.com>; Fri, 10 Apr 2020 11:54:59 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B93D3A0D4A for <hrpc@irtf.org>; Fri, 10 Apr 2020 11:54:59 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id r26so3653118wmh.0 for <hrpc@irtf.org>; Fri, 10 Apr 2020 11:54:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rqwWfgBert9B7u0kKBUpVHz4pZkxN4sRP8GYRmnEjg4=; b=hI8D9hXO19Sy5+jl1h9ZMzs46eeJZHHpOOP42EWCNLPOjy4c/hOaXCiYyKNXPmZ3gs tLMgyIwmhO9fgAzk6Wkh2Gi4sS5zZ9Leffu/H1P5IkEvWkJN3dXLK8jqCRI+Ly8Ium9u MqZDWbPL4nAWKjoMP6DJ7r+hZf6v+bTGa8Ujs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rqwWfgBert9B7u0kKBUpVHz4pZkxN4sRP8GYRmnEjg4=; b=oEEZ/5JyQNUAPOheFo84Yusc12aVFYnSCromVURpy6U91RV57ROA3Nkg6bIRUS1eof PFPaJpjFDB4NS1zSjDJEXXkWIQtfaXqoc4ucwchr6rP6zGxZqtWRTYUfNFEQcOb7pXYZ SRdQCw8/atGxaq4qcGcMe/imvQ+anHuT6VGsuF0rHAdOO/yJJp+SziAaISN00Yu72SmP PcWWzgRXRsTXd0BONTBn92tlWSr8c36e2v6NPF61GR/MAPHl+5O8WndpGUubhAXbOVHF q09z916Af9o4Dy2Jicp5VBGJwLeLgFLI4n8mZEzllEpQzRmVvKJT/JTDtwWCmjkqXtO1 tfBw==
X-Gm-Message-State: AGi0Puab8m8rtDCzz/NyUc5P2JOSOo5brV15LfS0Ge1GJ3FyrzM+E3i7 daCl6PczpOGjjai/LtUsjdRpHRZpxhrEbvd74HBv7g==
X-Google-Smtp-Source: APiQypKqY7kY/LjMkxEqMNqnEK7Yzr4H9kqrdWaa+yF/EFfILtY3VuD4ZK4xBqPU0XBg3nCP3hrwd4xkXHOwz6xEMZE=
X-Received: by 2002:a1c:5502:: with SMTP id j2mr6197897wmb.71.1586544897969; Fri, 10 Apr 2020 11:54:57 -0700 (PDT)
MIME-Version: 1.0
References: <de0ba70d-f2e8-93cb-d2a9-ee6b73b67f18@doria.org> <27c5e9d9-7c8a-985e-2fb1-99ccb50af9a7@cs.tcd.ie> <PR1PR07MB4891B933546D7D221A808694F3C00@PR1PR07MB4891.eurprd07.prod.outlook.com> <68b733e9-4053-60d9-b65d-f8dac2712f00@nielstenoever.net> <alpine.LRH.2.21.2004091526060.21348@bofh.nohats.ca> <CAN1qJvA5n=U5ENj7E+Y+yuM+F=EynMq1swCtcKVYHjx9NPtyzA@mail.gmail.com> <CAGVFjM+Asv_aq1nNsxTeSt8MhLBnN6ZW3EtbNDk1iAEwmxEeOQ@mail.gmail.com> <CAN1qJvBQ0LuXHXNMba28cT28-tTB7WxwDL-4W-FCYtsh1y7AUg@mail.gmail.com> <CANZrNV-8EhTJTzXCnNrg7uGTaztPHi4Rj+SytTcg_jP=PZ84Bg@mail.gmail.com>
In-Reply-To: <CANZrNV-8EhTJTzXCnNrg7uGTaztPHi4Rj+SytTcg_jP=PZ84Bg@mail.gmail.com>
From: Mallory Knodel <mknodel@cdt.org>
Date: Fri, 10 Apr 2020 14:54:47 -0400
Message-ID: <CAGVFjM+bJW6b6t+k2EGnhYHgg_1fq5DRSMXcfW+-_-uovbVL5A@mail.gmail.com>
To: Stéphane Couture <listes@stephcouture.info>
Cc: farzaneh badii <farzaneh.badii@gmail.com>, Paul Wouters <paul@nohats.ca>, Hrpc <hrpc@irtf.org>, Niels ten Oever <mail@nielstenoever.net>
Content-Type: multipart/alternative; boundary="00000000000010611105a2f445b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/3OsWrx-0iFJxq3hlRoN79Z3nCYI>
Subject: Re: [hrpc] Possible options for a HRPC research publication
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: hrpc discussion list <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 18:55:02 -0000

Hi all,

Just a bit of history and context, the hrpc.io website is, or should soon
be, a flat HTML site without a CRM. It was getting one update per year,
maximum, and to me that doesn't justify (vulnerable) software running on a
server. If it hasn't been done already, we could interrupt this, so that
hrpc.io could become a publishing platform (again). But historically it
hasn't been used. When it was actively publishing fresh content it wasn't
that much visited.

-M

On Fri, Apr 10, 2020 at 2:08 PM Stéphane Couture <listes@stephcouture.info>
wrote:

> Hi all,
>
> That is a good discussion. However, I suggest that you keep it open a bit
> more as it is currently (this long weekend) a holiday for many people, and
> others might want to jump in later.
>
> Here are some inputs :
>
> - I agree with the perspective that RFC writing should be at the core of
> this research group. It is,I think, the way to go to engage with IETF
> technical community and enhance the discussion about human rights and
> internet protocols.
>
> - However, if we keep a consensus-base approach, I think there is work to
> be done to clarify or at least do some pedagogy about what exactly
> “consensus” means in the case of HRTF. It’s one thing to get consensus from
> 200 people on every words of a document, and another thing to have a
> consensus that the document respects our common standard of quality by
> going through different editorial steps. We could decide for instance, that
> if three people support the document and no one express strong opposition,
> that the document is considered to reach consensus. But this is just an
> example.
>
> - However (again), if we are interested to get more involvement from
> academic researchers, it is important to recognize that RFC is a weird
> document, especially from a social science perspective. First, it is a
> steep learning curve to ask people to use github and Markdown language to
> start writing.  Second, it is difficult to categorize this research output
> in our CV: while the process of RFC writing – as it is now – does require
> multiple reviews and is quite demanding, it is still difficult to qualify
> this document as “double blind peer reviewed article”. Personally, I
> justify my contribution to RFC, not as a research output, but foremost as a
> way to engage with the community which is also important, but not the same
> as publishing an article.
>
> - With all this said, I think we should also consider HRPC as a space that
> has more generative potential than just RFC writing. This is already the
> case : there is the hrpc website (https://hrpc.io) which includes, among
> other things the short documentary “A net of rights” which is not an RFC
> (and by the way, my student made a French translation of the subtitles,
> which I need to share). An idea I would propose would be to make have a
> blog - on this website or elsewhere - that would allows sharing less
> demanding individual texts that could, in turn contribute back to RFC
> writing (a kind of circularity). We could also use this site – and HRPC RG
> - to promote other related projects/publications, and facilitate
> collaboration.
>
> Anyway, that’s my view based on my observations and my experience with
> draft-association.
>
> Best,
>
> Stéphane Couture
>
>
>
>
> Le ven. 10 avr. 2020, à 13 h 55, farzaneh badii <farzaneh.badii@gmail.com>
> a écrit :
>
>> Hi Mallory
>>
>> By document I didn't really mean anything in specific just meant the
>> submissions to the group.
>> Thank you for the offer to send our work to the group for review, the
>> reason we haven't asked the group for comments is that we are yet to
>> develop it further..
>>
>> We received great constructive comments during the session in Prague,
>> last year and thank you for the opportunity. I don't think we submitted it
>> as an Internet draft. And it was beneficial for us and I think the
>> attendees enjoyed the conversation too. I characterize the conversation as
>> a more collegial conversation than the community trying to prove us wrong.
>>
>> I was not saying that RG functions like that (rushing to publish). The
>> fact that you are looking for a solution to keep submissions published but
>> also not characterize all of them as RFCs  or look into other kinds of RFCs
>> and streams attest to it. I was just trying to relay what I think the risks
>> are based on my very limited knowledge about the processes.
>>
>> On Fri, Apr 10, 2020 at 9:45 AM Mallory Knodel <mknodel@cdt.org> wrote:
>>
>>> Hi Farzaneh,
>>>
>>> By "the document" I assume you mean draft-political, to which you
>>> yourself wrote and presented a differing view in response. Is your document
>>> still something you think this group should attend to and work on? Was it
>>> revised after the latest rounds of feedback in Prague and on the list? Or
>>> perhaps it's been published elsewhere (please share link)? I'd suggest you
>>> start a separate thread on this.
>>>
>>> "without the rush to creating an RFC out of every opinion and
>>> manifesto."
>>>
>>> Anyone actively participating in this group would know there has been no
>>> rushing to anything on behalf of this research group; nor is this at all a
>>> fair characterisation of our RG's current work items.
>>>
>>> -Mallory
>>>
>>> On Thu, Apr 9, 2020 at 4:09 PM farzaneh badii <farzaneh.badii@gmail.com>
>>> wrote:
>>>
>>>> Sure but not every enthusiastic academic piece qualifies as an RFC.
>>>> Half baked conceptual ideas that need years of development and their
>>>> implementation is doubtful too and there is no consensus around them should
>>>> not just be pushed through unless there are fundamental and clear
>>>> substantive changes in the document. The evolution of concepts must be
>>>> clear with strong empirical analysis. Or it has to be narrower without
>>>> grand theoretical and philosophical claims.  Otherwise publishing a piece
>>>> as RFC is merely giving lip service to human rights. I don't know how this
>>>> process is going to play out but maybe academics can layout their  concepts
>>>> and ideas in the non-RFC track and  RG can consider what needs to be
>>>> transferred to the RFC track. I think academics are in need of good
>>>> feedback to build on what they have, and the non-RFC track should include
>>>> ways to receive feedback from the IETF community so that they can improve
>>>> their pieces and be published without the rush to creating an RFC out of
>>>> every opinion and manifesto.
>>>>
>>>> Farzaneh
>>>>
>>>>
>>>> On Thu, Apr 9, 2020 at 3:36 PM Paul Wouters <paul@nohats.ca> wrote:
>>>>
>>>>> On Wed, 8 Apr 2020, Niels ten Oever wrote:
>>>>>
>>>>> > The publication in the RFC-series and the connected exposure to, and
>>>>> interaction with, the technical community in the IRTF and IETF is for me
>>>>> the main reason to work and publish here.
>>>>>
>>>>> I agree with Niels. Publishing an RFC is needed so that the IETF
>>>>> community takes human rights considerations more seriously.
>>>>>
>>>>> Paul
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>> --
>>> Mallory Knodel
>>> CTO, Center for Democracy and Technology
>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>>
>>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>

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