Re: [hrpc] HRPC recharter

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 04 January 2023 21:59 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 D072AC151555 for <hrpc@ietfa.amsl.com>; Wed, 4 Jan 2023 13:59:48 -0800 (PST)
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=F6FMtI0N; dkim=pass (1024-bit key) header.d=yitter.info header.b=cUz/DiD2
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 WV2EdaFRnm8T for <hrpc@ietfa.amsl.com>; Wed, 4 Jan 2023 13:59:43 -0800 (PST)
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 E0542C151556 for <hrpc@irtf.org>; Wed, 4 Jan 2023 13:59:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 70D5CBD534 for <hrpc@irtf.org>; Wed, 4 Jan 2023 21:59:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1672869580; bh=1Jl1PXm2tudKb+BmhAb9nBq160sIttvglLW2kk1S/BI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=F6FMtI0N7vNEYVVCu7dNNE2X//iHG8UKRIAUXZoHnYB3kU4OxnrU1J8hkVZ/qvkwO 1IC8k2K4GjnmB9k1pm3eKX2KlJBtPU+XwnsTP/imR4QqaAyBnOvk2lcrj/7QPOOjuN xwuX+PJCTZaQgDPBDd26nKj2TWfi5qUMRwWKE6ko=
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 FT4UOWTNehxx for <hrpc@irtf.org>; Wed, 4 Jan 2023 21:59:38 +0000 (UTC)
Date: Wed, 04 Jan 2023 16:59:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1672869578; bh=1Jl1PXm2tudKb+BmhAb9nBq160sIttvglLW2kk1S/BI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cUz/DiD2ibD6tX1x01JxS1GAY3wVMEiqEWhOYygiD2yuSTE0zC7dSVnDCUo8fOkwO mMDBet9moJg4NJKKmrUtwEaAIrJCw3voD230ZGYL6m5QBPpOWaHGabHhDzaPfq4TT+ 9pyFJj1px82t9K1jYZHR5Cpcnf8HFXbqom1HIuwc=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: hrpc@irtf.org
Message-ID: <20230104215936.5exwsmtztk2shnzb@crankycanuck.ca>
Mail-Followup-To: hrpc@irtf.org
References: <6ddd480d-76ed-a05e-066d-d740fee61441@cdt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <6ddd480d-76ed-a05e-066d-d740fee61441@cdt.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/dsU7oMxizy8IlH7P2V1JOPUGx0s>
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: Wed, 04 Jan 2023 21:59:48 -0000

Dear colleagues,

I work for the Internet Society, but this is only my opinion.

On Thu, Dec 22, 2022 at 12:30:39PM -0500, Mallory Knodel wrote:

>The recharter text is available in GitHub [1] where you can view a 
>diff [2]. It is also in a plaintext format with more visual 
>indications of where the changes have been made [3].

I had a look at this.  I have some thoughts.

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.

My worry about that is perhaps illustrated by this proposed addition to the charter:

	Moreover it is widely accepted that technical design decisions
	about the Internet are not value neutral [RFC3935] and can have
	lasting impacts on public policy and individual rights.

First of all, I doubt that reading is actually supported by the plain text of RFC 3935.  Second, I don't know whether that claim is in fact widely accepted (BCPs represent at best IETF consensus at their publication, not consensus of the world).  Third, even if it were, that might be a reason to treat it as a research question rather than anything else.  After all, in some quarters the distinctions among the Internet, the web, and Facebook are at least obscure, but I should hope we don't think that shows the identity of Facebook and the Internet.

But perhaps what makes me most uneasy is this research question:

	How are human rights and public interest policy considered in the
	development of the Internet?

The objective in the original charter, however large (and regardless of how well the RG constrained itself to that objective), seemed to me to be at least bounded.  But in the above question, we have several terms that strike me as so large in scope as to give the RG the scope to talk about essentially anything at all.

For instance, I have no idea where "public interest policy" begins or ends in relation to the development of the Internet.  Some have argued, only recently, that there is a public interest in ensuring the ability of governments to intervene in what they regard as harmful content traversing networks within their jurisdictions, for instance, and that therefore a set of identity mechanisms entirely foreign to TCP/IP needs to be built into the core protocols the Internet uses.  Is that in scope under this charter proposal?  I think it is, but I think that would be weird.

There is, moreover, the very question of "how…is considered" works.  That strikes me as a rather large research project alone, involving anthropological, ethnographic, and maybe even psychological study of virtually any "development" (more on this below) of the Internet, whether that happens in open or closed fora and whether it is related to strictly technical, or strictly political, or other questions.

Finally, there is the question of what "development of the Internet" means.  I think it is plain that (say) Twitter was and is in at least some sense a "development of the Internet".  So are policies specifically related to so-called "online harms".  So is the hooking up of a vast number of largely unmanaged and mostly unsecured sensors and actuators, possibly without any effort at management.  So is the burgeoning centralization of services that is related at least in part to the preference of http(s) over other protocols and at least in part to industrial policy trends that took hold (especially in so-called developed economies) starting around 1980.  So is the emergence of TLS 1.3 into an environment where nightly builds and frequent updates were the norm.  So is the development of QUIC as a standards effort brought to a standards development organization after a period of incubation in a single firm.  And so, of course, is the development of techniques to secure DNS queries and responses from the eyes of (some set of) third parties to the protocol operation.  That seems like a pretty large scope, and it makes me uncomfortable to suggest that a single RG could really have such a scope.

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.  In many cases, I may even agree with those positions.  But it is obscure to me what the research question is in such cases.  I often felt that such advocacy discussions were not really within the scope of the RG, and I felt these things often enough that even if other duties had not absorbed me I imagine I would have drifted away from interest in this RG.  Widening the scope as I have outlined above might have the desired effect of placing such advocacy activities within the RG scope.  But as I said at the outset, I am not too convinced that such activities properly belong in the IRTF.

>the group was chartered the first time. Additionally I think there is 
>value in the group name and its charter text being written so as to 
>explicitly attract researchers and research that discuss policy, as a 
>"place to land" in the IETF/IRTF.

I think there is pretty grave danger, if the "P" is to be recycled to mean "policy", in blurring the distinction between the IETF and IRTF the way the above does.  There are really very good reasons why policy as such is often regarded as out of place in IETF discussions.  This RG has argued I think (though not to my mind always persuasively) that in at least some cases some policy choices are unavoidable.  But in a standards development organization, it is still correct for the standards development to select the policy space in which a protocol will operate, and then leave to operators and so forth the decisions about "how the knobs will be set".  This is why the RFC 2119 "SHOULD" isn't supposed to be morally hortatory, but technically so.  That is, it is supposed to be used not as, "This is a good thing to do," but instead that there are quite possibly interoperation harms from failing to do the thing so specified and so an implementation had better understand that.  Now, it might well be appropriate for the Internet Protocol Ethics Research Group to come up with the moral imperatives for how a protocol ought to be deployed, but I don't think a technical standards development organization can properly tackle that job.  Therefore, I'd urge those rechartering to avoid thinking of this as implicating the IETF in any sense at all.  The IRTF doesn't have that power.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com