Re: [hrpc] HRPC recharter

Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 14 April 2023 17:52 UTC

Return-Path: <ajs@anvilwalrusden.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 CE520C14F74A for <hrpc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b="C2eWZWbh"; dkim=pass (1024-bit key) header.d=yitter.info header.b="edumiGtq"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwWIWd9ZFGNz for <hrpc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:52:10 -0700 (PDT)
Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DB9C14F738 for <hrpc@irtf.org>; Fri, 14 Apr 2023 10:52:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 0A888BD534 for <hrpc@irtf.org>; Fri, 14 Apr 2023 17:51:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1681494699; bh=7OBQurfbpJioexJVDUhgoXorf5Wz8k16FpKon48JvqQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=C2eWZWbhVyyZM/t0cDwyvpMjPgD3uc4vK7wGvTdMnx7VpnpfOnzEUyI56Tfb9Ql23 EBSZWyMp+uHiTLc1r9d8Ug011J0b0mqB0yF2udY4BBtVMPE0iLIWUMH4FaS15vsf9N ZIcJ4VT9RffEnSJVTAdetkVpkJvrPzallg7TVMRs=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyJloEyC0-hN for <hrpc@irtf.org>; Fri, 14 Apr 2023 17:51:37 +0000 (UTC)
Date: Fri, 14 Apr 2023 13:51:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1681494697; bh=7OBQurfbpJioexJVDUhgoXorf5Wz8k16FpKon48JvqQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=edumiGtq4sV/Ruh62/H+USfi5zlIDr1kbpCbWrTK8EOkrB2Ulp6RsvKc5ajkw4QOa TuRronfyBTY0TxLtfx6qbaDIkwyXSpfU3FsBLH2XR6mLNpj1g0oDc/sD2TUHRmrUsw 7X14WDgqu5xWAapOj6ZlLTR7d3ddA+j+vv47Pw6A=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: hrpc@irtf.org
Message-ID: <hkmdydfdj3gb5inh6yazg7dxe26bppwwditzp2mfj4gszqbgxt@eocak2d42plx>
Mail-Followup-To: hrpc@irtf.org
References: <6ddd480d-76ed-a05e-066d-d740fee61441@cdt.org> <2e18e418-dfde-e23f-9639-1ca0ea6ad7f1@cdt.org> <CABcZeBMSvWk4MOvv88dfuWtRwy_KBji6YgQG8zmVKcnyNDaqaA@mail.gmail.com> <1717379803.9766.1681364750928@appsuite-gw1.open-xchange.com> <20230413174921.iofttsu3h3gued7u@crankycanuck.ca> <1096362655.14319.1681466701602@fidget.co-bxl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <1096362655.14319.1681466701602@fidget.co-bxl>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/6bJcHUvzsX3qTxY9bpsTS0RuVd0>
Subject: Re: [hrpc] HRPC recharter
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.39
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, 14 Apr 2023 17:52:16 -0000

Dear colleagues,

Previous disclaimer still in effect.

On Fri, Apr 14, 2023 at 12:05:01PM +0200, Jens Finkhaeuser wrote:

>Since the topic is on the intersection between human rights and protocol design, it is clear enough as well that the purpose is to provide a bridge between two otherwise distinct worlds that influence each other. That implies that there are two kinds of output to be expected from the group: one detailing human rights impacts to protocol designers. And the other detailing protocol design impacts to human rights folk.
>

That was indeed part of the hope, at least as I understood it, when the RG was chartered.  I am not too convinced that hope has been realized, and it appears in particular that an awful lot of people with real protocol engineering experience aren't participating too heavily.  My own experience at attempting to get some language that I felt better comported with the experience of designing protocols was discouraging enough that I'd mostly given up; then I got my current job and I thought it was totally inappropriate for me to propose anything but the most trivial suggestions.  Others might have had a different experience, but a quick survey of the mailing list archives doesn't leave me too hopeful.

>Rhetoric on RFCs aside, there is no requirement for protocol designers to adhere to the documents aimed at them.
>

But if policy-makers are having this forum advertised to them as a way to influence "the IETF" or a way to inject policy considerations into IETF procedures, that _is_ an issue (and is also politics by other means, I suppose, since that's been such a theme).

>As for the second class of documents, the main use case is of course to influence policy in such a way that there is ideally no conflict between the two separate concerns. I'm not sure I'd characterize this as partial policy development, however. It's better categorized as expert advice, which policy makers would otherwise each have to solicit independently, probably with less consensus. Again, however, policy makers are under no obligation to consider these outputs.
>

I'd be interested in any examples you have of such advice that came from this RG.  In my actual job, of course, we provide such advice to policy-makers all the time, but we generally don't use RFCs to do so.  Frankly, even the format of RFCs is sufficiently strange as to be fairly useless for such persuasion.  And the "rough consensus of the RG" rule is kind of impossible to explain (it's possible, though not easy, for protocols.  But nobody I've tried to talk to about it has any understanding of what it means for a RG to have consensus on a research output.  This might be my fault, since _I_ don't understand it so have a hard time giving an account).

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com