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

"Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <laurent.ciavaglia@nokia.com> Fri, 10 April 2020 08:03 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 2E0E33A196B for <hrpc@ietfa.amsl.com>; Fri, 10 Apr 2020 01:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.067
X-Spam-Level:
X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 EVIavVFArhTR for <hrpc@ietfa.amsl.com>; Fri, 10 Apr 2020 01:03:05 -0700 (PDT)
Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120127.outbound.protection.outlook.com [40.107.12.127]) (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 C62093A1969 for <hrpc@irtf.org>; Fri, 10 Apr 2020 01:03:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=evR7pK0hKj/Dtvpeu8PxhxghPl1Ov/xAzBF3yeJJw0GkNOlsoEVl3mqKYbeTSgwKiJnhpDvn5FUqGsQyGvJKdAoRKAAzJ57eVPIjw2QVm/t8Y5FPtWBd6TAXMJeYGfoy5byPFhDf6/Ci/GSISE+65KF9fhuizqEbh/hf5ROei3JmIH3Iqq6U464RFZap0u1RXqlW4JFsvrGnRna7+KcDNhVBl/InynEBVC8FA4JeQu43dfD142wD3qKsHDh3aEtx2lctUnAf3pvqt198UijZieEwMHp3qYa9Aa3xALQzUcJ8E0LFAoQ4TFYfcGc6aJ9fHiVY1bU4Kjp2QFuD4+GqVw==
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=KtPfIA/mPQREGs3VSHzUTxxFxQo/REqGWplre7pp7cQ=; b=LGLHIVcE1wpzt1IBU92i5QpiyMwkHo9Nr5QmgUu4oRiv5hNTvNHyQJaVLkecxrFt7hwzAUagCNtM6YHiqPQEcdTi8VveGyoOT6R8g0qb3CQVH70yuaen57BVFKGRKZ7Nkm9i8C1MboIKKcI5opEaX6W+M0z8X3D2KzK8FZ/YXzmJW2NBvNV6TmwXtZhJ4RFK3L5OCqmfrmyBg4hCCIk9PwICj4cQys6ssKf21j32T6xkDJodFhoOiVyiAJAfQSIOybEDoQEaTPBSJyWNCEr/NQEdtcJ9yUeEk9df0JrY3cLJpIyj2LoeojPDk9ftW4zNEtXqTXUPAe4WWNMZHINn5g==
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=KtPfIA/mPQREGs3VSHzUTxxFxQo/REqGWplre7pp7cQ=; b=u80VstE5xBNOjbOgxmg4SYBGO9h20pulgUejX7D0DOXBbJL5p7T9EMRRgu+iNk4vMxfFgzHBgBxELZo+g8DP4J/xjqonwMf3uJiPu8AKpOq4t3XaSXIybITZ6oGXcsfAVD2GD54DnNwvIZ0LG1HhvwB2xdo82rk/07dfXHhyQ94=
Received: from PR1PR07MB4891.eurprd07.prod.outlook.com (20.177.208.146) by PR1PR07MB4907.eurprd07.prod.outlook.com (20.177.212.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Fri, 10 Apr 2020 08:03:01 +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; Fri, 10 Apr 2020 08:03:01 +0000
From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <laurent.ciavaglia@nokia.com>
To: Niels ten Oever <mail@nielstenoever.net>, farzaneh badii <farzaneh.badii@gmail.com>
CC: Paul Wouters <paul@nohats.ca>, "hrpc@irtf.org" <hrpc@irtf.org>
Thread-Topic: Re: [hrpc] Possible options for a HRPC research publication
Thread-Index: AQHWDVVSbexx2oRbZUiFt3EJLdnkyahu840AgAAIEGCAAG7XAIABxJYAgAALxYCAAAoKgIAAuLZg
Date: Fri, 10 Apr 2020 08:03:00 +0000
Message-ID: <PR1PR07MB489191B151F021DB97155504F3DE0@PR1PR07MB4891.eurprd07.prod.outlook.com>
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> <ad991a4c-5e6b-4d54-a3c1-12a38a76a41a@nielstenoever.net>
In-Reply-To: <ad991a4c-5e6b-4d54-a3c1-12a38a76a41a@nielstenoever.net>
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: 4b7e7264-150c-4b55-b9f0-08d7dd2596e2
x-ms-traffictypediagnostic: PR1PR07MB4907:
x-microsoft-antispam-prvs: <PR1PR07MB4907D83D6BD904F3691007B8F3DE0@PR1PR07MB4907.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0369E8196C
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)(39860400002)(366004)(346002)(136003)(376002)(396003)(33656002)(9326002)(7696005)(71200400001)(66574012)(8936002)(81156014)(8676002)(9686003)(478600001)(966005)(26005)(64756008)(54906003)(66476007)(110136005)(2906002)(52536014)(66556008)(86362001)(53546011)(66946007)(5660300002)(66446008)(76116006)(4326008)(316002)(6506007)(186003)(55016002); 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: 3RaTGLlHzBzkNIh5eZ/uwu0x37POwyu9+MXYR2FxzCgyutD7EX2XNUZ2gREpn5odBg+dyrO+go45uM3fUIFwxnoJ9EZmEM5miVR21YYjaMk7yfbSkOjjNzLKEI7e0OUrmYHebfG0L5fgCmxccWyEGWtq5gRaZBiJfl07Ree6ZjxUpGaY4UJdWVtUGAiY0ra+araCKADbivMVN9pj2OVWvx2fRaSKiQOKxlzhFjTe7Yj6l8vWSBp0UGgZMAMhnV8RIhNWQBT0XeuPZs2bP6XCqzMYMFFzFTBGtSetAAOO60HE/+mlgsMr067H+jOMF1SrNmueQKEypTdwITIsXTY9plOv3UWSrP09NyTjZzG0uNtnUJG0BTjtmlNWOkvIa+R6ORHtwn1xbGJPHSICbQH0ontkzCTK+coUzfRg8L8Jp/Rzh9I4VbU5K+yZfczA+CMbwwkOstoS3nZVLu9hRCvclkqJC0ScnjJ/Izml6Pm8xe41/ySkCtMhH+A1Zd8TiKikikniDK8SgL/EWRtaKUcJqA==
x-ms-exchange-antispam-messagedata: anfer0g3xxIuHYd4hfZQOhi7AzsYBAUzkgCmI+0YmClyTWcj04Er1fj1GERObeT/7UUz3xrlFnHsUp/BsWe7mt0bxtYXZZM3dBqRQqsr/+F34U/2sg1VXS1fnDZtC+z1Wk30nkEf5G0d3J2+qSKNCg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PR1PR07MB489191B151F021DB97155504F3DE0PR1PR07MB4891eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b7e7264-150c-4b55-b9f0-08d7dd2596e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2020 08:03:01.0300 (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: 7MS7E1dVjzxdc/xSyVyytcHJNnvYlNAPmYNZ30PD/KfG8j5Z9mg1m1iNPTF7V1DnYpL8GPc0uaH/rPNnAtquD3dpuWx8OnskQSEenaDLNUA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB4907
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/2YPaVaGXmoss5X827d9TGwYYKpQ>
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 08:03:07 -0000

Hello,

Publishing RG outcome as a RFC is undoubtedly of great value – and we should be and make clear that different RFC "types" exists.
An (informational or experimental) RFC from the IRTF Stream, with all the good value it can have in it, is quite different from a (Standard Tracks) RFC from the IETF Stream.
An issue is that this distinction is not always known, or explicit, or obvious for non-expert.

I think the IRTF is quite clear about the RFCs published in the IRTF stream are: (extract from IRTF RFC header)
   "This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Network
   Management Research Group of the Internet Research Task Force (IRTF).
   Documents approved for publication by the IRSG are not a candidate
   for any level of Internet Standard; see Section 2 of RFC 5741<https://tools.ietf.org/html/rfc5741#section-2>."

Therefore, I think we should distinguish the goal and purpose of publishing RG results as an IRTF RFC, from other cases (i.e. IETF stream). The two documents are called RFCs but they don't bear the same significance and don't serve the same purpose.

Best regards, Laurent.


From: hrpc <hrpc-bounces@irtf.org> On Behalf Of Niels ten Oever
Sent: Thursday, April 9, 2020 22:45
To: farzaneh badii <farzaneh.badii@gmail.com>
Cc: Paul Wouters <paul@nohats.ca>; hrpc@irtf.org
Subject: Re: [hrpc] Possible options for a HRPC research publication

I actually hope many people will write Internet-Drafts about this topic. I have no problem with it if these I-Ds and RFCs would criticize each other and build on each other. I'd very much welcome an ID from Dr. Badii on the topic. Academics have sufficient venues to talk among each other on this topic, such as Giganet.
On Apr 9, 2020, at 22:09, farzaneh badii <farzaneh.badii@gmail.com<mailto: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<mailto: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<mailto:hrpc@irtf.org>
https://www.irtf.org/mailman/listinfo/hrpc