Re: [hrpc] HRPC recharter

Jens Finkhaeuser <jens@interpeer.io> Fri, 06 January 2023 12:01 UTC

Return-Path: <jens@interpeer.io>
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 440A9C14F738 for <hrpc@ietfa.amsl.com>; Fri, 6 Jan 2023 04:01:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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=interpeer.io
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 6ojBTzpe6XTo for <hrpc@ietfa.amsl.com>; Fri, 6 Jan 2023 04:01:34 -0800 (PST)
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (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 06A91C14F720 for <hrpc@irtf.org>; Fri, 6 Jan 2023 04:01:32 -0800 (PST)
Date: Fri, 06 Jan 2023 12:01:20 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interpeer.io; s=protonmail; t=1673006489; x=1673265689; bh=7S3yigT+lgfTcna4bgYpRP4vDaz1yp/T6YZJWZJeXk8=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=eEMX8K8wwJ/Av9EJS6mKmmC2pipMnyZQ86maK3bSttw6o41bVQBWyVh7VeWsWlQaI Tsh2LWcNlmUVnSs87OXkwcTbd9h6k4/SChkx1eAmEOTntSL1zGQMXrB0qei9DpFOwX k9UzeQWoB49yIPc2mz5QbM6CWXMMxCq5vEotlBvc=
To: "hrpc@irtf.org" <hrpc@irtf.org>
From: Jens Finkhaeuser <jens@interpeer.io>
Message-ID: <bTrwmE0TLN4PwdQNwJzzFmzPZPIjXrO6ld6loBlNBDBrluGDos9kftE0EzKxQMFhzhoE6LJewu0jGGFet5PqoYFj8gJaHRguKWDYFmp0fJ4=@interpeer.io>
In-Reply-To: <63464538-4d40-a946-bcbe-570a6a3b49f9@lear.ch>
References: <6ddd480d-76ed-a05e-066d-d740fee61441@cdt.org> <20230104215936.5exwsmtztk2shnzb@crankycanuck.ca> <63464538-4d40-a946-bcbe-570a6a3b49f9@lear.ch>
Feedback-ID: 18725731:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------a522a79e9bd8b60fc5b987471f98c661d0e56345c353c0cd9b175758f2786b16"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/1ZKnCYVHSiCCEP7_49bhsUHbM4I>
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, 06 Jan 2023 12:01:39 -0000

Hi all,

I'm relatively new to the IRTF/IETF, so my understanding here may be a little spotty. Very broadly speaking, I understand the IETF to work on what is, what the IRTF is focused on what may be. That's the difference between engineering questions and research questions in a nutshell.

The point of an RG, then, is to eventually provide inputs for IETF - if and when the "what may be" becomes "what is/should be". With Human Rights, we're pretty much by definition already at the point where such inputs are required and desired, because human rights concerns aren't a future problem.

It's also been made clearer to me that RGs aren't really places to conduct research, but to collect research. That is, human rights groups should publish their results to the RG, which may turn them into guidelines for engineering. That is how I saw the work to date progress. Again, I'm painting with broad brushstrokes here.

The issue with this is that the information flow is then unidirectional from the outside in. I understand the charter change to intend to turn this into something more bidirectional.

It's a common engineering problem to get conflicting requirements, and then having to start a difficult conversation pushing engineering concepts upstream, to resolve those conflicts. Having a place where information material for policy makers is created that consider engineering issues in the context of human rights is IMHO invaluable. I, for one, do not know of a single place that does this - rather each HR advocacy group does that to the best of their abilities, but not necessarily with a global, internet-wide focus.

Is this the job of an RG? Possibly. I'm not sure that IRTF should influence policy directly. But rather than each individual advocacy group commissioning a position paper on some overlap of technical and HR issues, it'd be useful to have a reliable source for such information in the IRTF. If the advocacy group then cites such documents or does not, that's pretty much up to them in much the same way as it is up to engineers to implement one standard over another.

As I understand this discussion, that is what the charter change is aiming for. People are concerned it should move to influencing policy directly, which I do not see here.

Given this understanding, I would very much welcome more bidirectional communications in this area.

Jens
------- Original Message -------
On Friday, January 6th, 2023 at 09:49, Eliot Lear <lear@lear.ch> wrote:


> Hi Andrew,
> 

> As you may recall, I've had similar concerns to the ones you have previously raised. I do think the current draft charter makes things better, not worse. Please see below.
> 

> On 04.01.23 22:59, Andrew Sullivan wrote:
> 

> > 

> > First, while I initially thought I understood the purpose of the change, I guess I wonder whether the expansion of the scope keeps the RG properly inside an IRTF area of work. RFC 2014 says, "The IRTF focuses on longer term research issues related to the Internet," and also, "These groups work on topics related to Internet protocols, applications, architecture and technology." It seems to me at least possible that "policy" is not actually included in that scope, and that attempting to include it has a faint air of circularity about it: drawing (or at least implying) a conclusion about the purported subject of the research rather than doing research necessary to show the conclusion.
> 

> Certainly an open ended discussion of human rights policy outside the scope of Internet protocol and service development is not what RFC 2014 had in mind. However, there is, at least in my mind, no doubt that protocols and policies can be highly intertwined (cf SHAKEN and STIR). Clearly this must have been what you folk on the IAB had in mind when you created this group in the first place, no?
> 

> > Finally, there is some discussion within the thread that I think may explain where some of this tension is coming from. I believe that the RG has often functioned as much as a rallying point for a rough set of positions about the Internet, and the advocacy of those positions.
> 

> This is my perception as well, and it was the basis for my earlier suggestion about using the word "explore". Also, I have, as you have seen, been concerned about this group addressing only some human rights and not all human rights. Certainly we have seen detail on only some human rights, such as freedom of association. The tension between human rights is one that is the hardest aspect of all of this, to me as an engineer. The limitation of scope in the previous charter all but assured advocating and assumed positions. That is why I view the proposed new charter as a vast improvement.
> 

> Nevertheless, if I understand the lay of the land correctly, nobody is arguing that this group should have a political advocacy function. Therefore, perhaps some guardrails seem in order to insure that is the case. One or two more suggestions to avoid that here:
> 

> OLD:
> 

> > -   Policy and academic papers, for in-depth analysis and discussion of the values embedded in the Internet architecture.
> 

> NEW:
> 

> > -   Academic papers, for in-depth analysis and discussion of the values embedded in the Internet architecture and their policy implications, as well as the impact of policy on protocol development.
> 

> "Policy papers" is often used for papers that are shills for advocacy. Let's not invite those here. But both input and output need to consider policy implications.
> 

> One could also imagine a blanket statement that "Advocacy of particular positions is out of scope for this RG." Any of that should go on elsewhere, like in your $dayjob organization. It's also important that the group always keep a focus on what question is being explored. Some formality there might help. That brings us to this:
> 

> 

> 

> > But it is obscure to me what the research question is in such cases.
> 

> Strictly speaking, the RG charter needn't define a research question; it can leave that up to the individual researchers themselves. I would argue that is the way RGs should generally operate. Thus the breadth over which you express concern is something I view as a feature and not a bug, and indeed the limited scope caused me problems, as I mentioned above. The charter needs to provide a focal area of interest, and researchers need to be willing to show up and participate.
> 

> This having been said, changing the name of the group without changing the acronym would probably cause confusion among those who thought they knew what the acronym meant. We should be careful about that.
> 

> Regards,
> 

> Eliot