Re: [hrpc] HRPC recharter

Niels ten Oever <mail@nielstenoever.net> Mon, 17 April 2023 12:15 UTC

Return-Path: <mail@nielstenoever.net>
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 6462CC14CE4F for <hrpc@ietfa.amsl.com>; Mon, 17 Apr 2023 05:15:13 -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, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=nielstenoever.net
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 t0cO9gZJipin for <hrpc@ietfa.amsl.com>; Mon, 17 Apr 2023 05:15:08 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E8CC14CF17 for <hrpc@irtf.org>; Mon, 17 Apr 2023 05:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nielstenoever.net; s=mail; h=Content-Type:In-Reply-To:From:References:To: Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TDmOG6RZJxax5fS8Z6N7FPDzVhxVU5MqJ8v4XUilWJY=; b=W/cL4+ISCEvMr6/AEYIVsc97o NUDLD4OUkHB1W86KOsOkkXHLNvhVpM8GXxll5uNsS8iS5wCUzMIS1ZOlkf9L9cxs60UFoD5i/A4LM mWdfiAdNRSxBji5a27nc9r/EST5jbt/3/BtbBaQMpiB5vgg0jBlolKbczANv+xLYGQGmY=;
Message-ID: <1a7c0475-61a7-e3f3-eda8-1e8245bbbf71@nielstenoever.net>
Date: Mon, 17 Apr 2023 14:15:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0
Content-Language: en-US
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> <hkmdydfdj3gb5inh6yazg7dxe26bppwwditzp2mfj4gszqbgxt@eocak2d42plx>
From: Niels ten Oever <mail@nielstenoever.net>
In-Reply-To: <hkmdydfdj3gb5inh6yazg7dxe26bppwwditzp2mfj4gszqbgxt@eocak2d42plx>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------G8buSJT02Sm0cFstHf94264i"
X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Scan-Signature: 27c1264e312f7e45ec0349526d776c80
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/coaureuFTbcO3qJvayMJkjKdzHs>
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: Mon, 17 Apr 2023 12:15:13 -0000

Hi all,

On 14-04-2023 19:51, Andrew Sullivan wrote:
> 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.  

Interesting - the IAB seems to think differently about this:

https://www.iab.org/wp-content/IAB-uploads/2023/03/IAB-Response-to-OHCHR-consultation.pdf

and so do the people that have actually tested the guidelines.

> 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.

Would be very welcome if you could substantiate your claims, including the ones you made in your previous emails.

> 
>> 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 

This, again, seems to be unsupported claim that is not based in concrete text or data. It would be great that if people speculate they indicate they do so, it is a research group after all.

> (and is also politics by other means, I suppose, since that's been such a theme).

I don't think any part of any discussion has been to inject politics, but trace them and map different positions on it [0].


Best,

Niels

[0] https://datatracker.ietf.org/doc/html/draft-tenoever-hrpc-political-01

> 
>> 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
> 

-- 
Niels ten Oever, PhD
Co-Principal Investigator - critical infrastructure lab - University of Amsterdam
Assistant Professor - Department of European Studies - University of Amsterdam

W: https://criticalinfralab.net
W: https://nielstenoever.net
PGP: 4254 ECD5 D4CF F6AF 8B91 0D9F EFAD 2E49 CC90 C10C