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

"Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <laurent.ciavaglia@nokia.com> Wed, 08 April 2020 10:09 UTC

Return-Path: <laurent.ciavaglia@nokia.com>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B633A10A1 for <hrpc@ietfa.amsl.com>; Wed, 8 Apr 2020 03:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.068
X-Spam-Level:
X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nokia.onmicrosoft.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 uUDwNprQZ5Ez for <hrpc@ietfa.amsl.com>; Wed, 8 Apr 2020 03:09:02 -0700 (PDT)
Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90101.outbound.protection.outlook.com [40.107.9.101]) (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 239113A10D3 for <hrpc@irtf.org>; Wed, 8 Apr 2020 03:08:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eiiGG/p4AhDNqaHIEa3GONFUTbcssfisfwvtioO+bN2xCC2xpdYPNeu9s4xdJEDM7cLA+9a1seiRA/lMJfKHE/URojl4FkPxC59+a/TZ8218UKwBd3fdCgi8ObKnwxR2SdVoXFozVwbcTXm83C4lTSq2QEJilRrKQV+6xssykCopXjmszb9gq5Nm8KfgNBdD7VIRhBICgFRKuA/NdfeJecOAC954eBysJgU50TmzG7nMyNiq+6TRogh+ginzMA++zdYg31v1hGZso0yEe4jZWgLLLcLkRJ65x0PyX9TPbNt0BLgPYXPwKlp7go9/+nYgUSSgkPjD4AUecZ7nzxNPpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QP4aJP2y2WggzWhvG04o4scLHdT0hCr2CjVTF0GN5nY=; b=FX7JN2cd2TOsK3bHh0Xli6v+tyCrTwTc3+Z4HVlsak3BbRzDwA/aTBQuo+54VedYjgbVcdUKO/iGOS90pVuC2RDsTUEDrfn/DlzdCDRXQVtODi/eP3miIYINfNPbO2VLbwkYDOhXHUznfAkjUeb+6gNg7hHl/4YzdvD5tvj9jwen+hHWQIs980GfsHNE4JlR0mTKrG1f0G5Zu5lKfHy2ahQ/jpN5J6G037qfzIRkB6kem3GUkUAUQLbZwSIxPk2uLUm//Fo+GFjBJLlXSYP0HPd8pNTFB/zhJJS6bbPDcmpXTQ4zd5cDAV68EtPjVn+BgG7ajp/jeVYQXbvVskP2nw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QP4aJP2y2WggzWhvG04o4scLHdT0hCr2CjVTF0GN5nY=; b=SlQ4Kj0cIGETvU+6L4uc5R0ko7RjEJSE3vYuxb19K3q1q9kKmfT+gP9snU/tWiQsQQsHvovrq8Pief/lL1jivoBcgxUIXjRg5Ze/ByK632RKr+X3yFd8ZnEVBFuZKcG3wUzhGr+50tepBqJPWOnoocah8GIeDP7gsY32i0Sod6Y=
Received: from PR1PR07MB4891.eurprd07.prod.outlook.com (20.177.208.146) by PR1PR07MB4858.eurprd07.prod.outlook.com (20.177.210.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.14; Wed, 8 Apr 2020 10:08:52 +0000
Received: from PR1PR07MB4891.eurprd07.prod.outlook.com ([fe80::c61:7804:6733:8e5e]) by PR1PR07MB4891.eurprd07.prod.outlook.com ([fe80::c61:7804:6733:8e5e%3]) with mapi id 15.20.2900.012; Wed, 8 Apr 2020 10:08:51 +0000
From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <laurent.ciavaglia@nokia.com>
To: "hrpc@irtf.org" <hrpc@irtf.org>
Thread-Topic: [hrpc] Possible options for a HRPC research publication
Thread-Index: AQHWDVVSbexx2oRbZUiFt3EJLdnkyahu840AgAAIEGA=
Date: Wed, 08 Apr 2020 10:08:51 +0000
Message-ID: <PR1PR07MB4891B933546D7D221A808694F3C00@PR1PR07MB4891.eurprd07.prod.outlook.com>
References: <de0ba70d-f2e8-93cb-d2a9-ee6b73b67f18@doria.org> <27c5e9d9-7c8a-985e-2fb1-99ccb50af9a7@cs.tcd.ie>
In-Reply-To: <27c5e9d9-7c8a-985e-2fb1-99ccb50af9a7@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia.com;
x-originating-ip: [176.130.37.253]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b1da3577-3e02-4bef-4c90-08d7dba4d6b9
x-ms-traffictypediagnostic: PR1PR07MB4858:
x-microsoft-antispam-prvs: <PR1PR07MB48585F9DEBF58D8996967CC7F3C00@PR1PR07MB4858.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR1PR07MB4891.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(376002)(136003)(39860400002)(366004)(396003)(346002)(186003)(8676002)(71200400001)(66574012)(81156014)(8936002)(33656002)(26005)(55016002)(9686003)(316002)(6916009)(6506007)(53546011)(478600001)(81166007)(966005)(7696005)(66556008)(66476007)(64756008)(66446008)(66946007)(86362001)(2906002)(76116006)(52536014)(5660300002); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: N2YqFh9+d4rG3zwp9ea9bh+HgNnTj6hOa4764c/B5JvQEAlUZqW4xbjB/dEJ3Z8OOdS59pcuUOLo7o7D+h3iaRckbxVSK/xdSxgWGUjbKWSGAKemyfWH7zQ8MOoNbY1i8AgagOzPMRm6SiRzkuw8ZDTXy0ExeMUtTZsHPGHNbGY2AXDjYV5x9hqodJQ38lDCjGAT3k4bPfyx0kpDNBT8XnrxtjYALugB8D4GQTxqZ61j/XTElUf5xYHgwItCKA5BkOHz4KtkP3L8ZRFK8zvoUFhFZHhd4iusrnZUDQvYuwDK7vhnaorFAoFCBf/6mcqCtf8O1t8glz+WvyAK2gAI7suI/5jS23q/8Ep8YVwmuLeA1BCwPyb679Qn+2V3HWhbhSgKc+L7n6VWDy3wWoP58qeeYEYUwc7V/nwY+6Xv2Z2H9IbK0BjBoMjg5Oe+Tfwl+d7RwZZZSTfrVy4qjLbP5xdz3IxjEin9vyA8DK+xbN52ZBsDbcXs0oi9RoMfb1coCKOt9Lj56nYd2aznZ4aVjg==
x-ms-exchange-antispam-messagedata: UZtyGlJD8A7RsJIVB5GFKJJuz8J02M5rs8Xel9jL+IAUTJwkjIcLcGRwypy45cQ4cnBFL1OOv/AO/XqQm16gx0D81jUAQfguvGgN/AegVdiqNkkcUllDVGDdDsywnOi+w9OId85Wdvd4XCXCrRSsIA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b1da3577-3e02-4bef-4c90-08d7dba4d6b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 10:08:51.8090 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: D5RivqxURISSMcJQTFsW6OfWhG4+Q2jzmtUZ2wHflG3KlVfsIS6gG2z/fh7cLaRgBLKJ+681HMQpqLDB+WI+yUbpKFqsIurjnJIVMc3sF00=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB4858
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/xv672NtE-lVD6bTpgc4g53piC1U>
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: Wed, 08 Apr 2020 10:09:10 -0000

Hello,

This is an interesting approach.
I'm not commenting on the choice for the HRPC topical content, but am supportive of the idea.

We had/have similar discussion in NMRG (esp. among the chairs) about (the types of) publication of the RG collective outcome.
The IRTF RFC stream is not always the most appropriate channel (for various reasons: delay, process, or other limitations).
We don't have recent past examples, but we are aiming to publish a "paper" on Research Challenges for AI in Network Management in a journal based on the work from the RG, involving a group of authors.
For me, this would clearly be a collective outcome of the RG work.
In parallel, we will initiate a draft on the same topic, and this is part of the RG milestones.
I know this is not exactly the solution/approach you describe below, but wanted to share another, similar, possible outcome when it comes to publication of RG work.
Some scientific societies also offers special issues, editorials, and conferences/workshops reports in their proceedings.
We have done that for a NMRG workshop and conference session jointly organized with an IEEE conference, with peer-reviewed papers on the research topic of NMRG. The proceeding gathers all materials (the conference report acting as the collective outcome of the work, analysis and discussion), and the peer-reviewed publications are indexed in IEEEXplore (which is a useful incentive for academic researchers). The format was found useful and not so complicated to put in place for a good result. Such an approach offer the advantage of flexibility in topics and timely publication/availability of results.

HTH, best regards, Laurent.
p.s.: might be worth to open the discussion to the IRSG? And/or as a topic for a future IRTF Open meeting.

> -----Original Message-----
> From: hrpc <hrpc-bounces@irtf.org> On Behalf Of Stephen Farrell
> Sent: Wednesday, April 8, 2020 11:22
> To: avri@doria.org; hrpc@irtf.org
> Subject: Re: [hrpc] Possible options for a HRPC research publication
> 
> 
> Hiya,
> 
> I like the idea of trying an "annual" (or "occasional")
> publication of people's works-in-progress. Sounds a bit
> like the proceedings of a workshop maybe? But however
> it's cast, I'd say, yes do try it.
> 
> One other point, maybe a nit: for me, the RG can be
> happy that a document is ready for publication even
> if there is not consensus on all of the content of
> the document. I think HRPC could do more to publish
> documents in that kind of state via inclusion of some
> well-written caveats/disclaimers.
> 
> Cheers,
> S.
> 
> On 08/04/2020 04:24, avri@doria.org wrote:
> > Hi,
> >
> > **
> >
> > *Recently it has felt to me as though the HRPC RG was spinning its
> > wheels. Our documents aren't moving along the path to RFC very easily
> > and except for interesting presentations at meetings, well worth while
> > in themselves, we have not been making great progress with our
> research.*
> >
> > *
> >
> > Part of this comes from a disagreement about the use of RFC publishing.
> > While I know it is not a requirement for the IRTF, I strongly believe
> > that research published as a RG RFC should have RG agreement for
> > publication. This does not mean that there must be agreement on all the
> > ideas and statements in the doc, but on the finished product. This was
> > the process we followed with RFC 8280 and I believe it works. A bit
> > cumbersome and slow at times, but it led to what I believe was a better
> > document.
> >
> >
> > Not everyone, including my co-chair, agrees with this approach. To many,
> > the RFC series is the publication method used by the IRTF and not
> > everything needs to be a rough consensus document. In addition to
> > individual submissions, IRTF submissions are not bound by IETF rules.
> > They rightly ask why HRPC should be so strict when there is no
> > requirement to be. This question in one way or another has been asked by
> > several people in the RG over the last few years. The recent difficulty
> > has also been named as a reason for why researchers have seemed a bit
> > less willing to work on documents lately; what is the point if they
> > won't get published.
> >
> >
> > I can see this point of view, and yet, I still find myself unable to
> > support sending a RG document to the IRSG  that the RG does not think is
> > ready for publication. Of course individual submissions would be a
> > different matter as those do not need to be shepherded by the RG chair
> > in the same way.
> >
> >
> > Mallory and I have been discussing this impasse on and off for the last
> > two years. The last time we talked we both felt, I believe, that it was
> > time to try something different to break the impasse.  I made a
> > suggestion for working with two tracks, one the RFC track where RG
> > internet drafts need RG support for publication as RFCs, and the other,
> > the production of a yearly publication that is an edited volume that
> > does not require RG approval. Mallory suggested that I bring this to the
> > RG for discussion.
> >
> >
> > What I am suggesting for the non RFC track is that we pick a topic per
> > year and publish a collection of research, essays, and commentary on
> > that topic. How we would publish this remains to be discovered; could be
> > anything from a wiki site to an ebook or even finding a journal to do a
> > special release, if such a thing is possible. Mallory and I would act as
> > lead editors, but we would need to enlist help from members of the RG in
> > terms of putting such an effort together, as it does take work and
> > contributions.
> >
> >
> > In terms of topics for a first year, I have thought of two, but am not
> > wed to either of them at all. We would need to find a subject that
> > members of the RG, and hopefully others, would be willing to contribute
> > their writing to.
> >
> >
> > 1 - Take the draft-politics as the seed and build the edition around the
> > various aspects of that discussion and the issues it raises.
> >
> >
> > 2 - Take the HRPC core question on “whether standards and protocols can
> > enable, strengthen or threaten human rights” and explore the various
> > viewpoints on that question, including the pros, the cons and anything
> > in between.
> >
> >
> > This topic is on our upcoming meeting agenda, and I hope to gather some
> > viewpoints that will guide how we can move forward, or not as the case
> > may be, with the idea. Also interested in opinions on the list.
> >
> > Thanks
> >
> > avri
> >
> >
> > *
> >
> >
> > _______________________________________________
> > hrpc mailing list
> > hrpc@irtf.org
> > https://www.irtf.org/mailman/listinfo/hrpc
> >