Re: [hrpc] HRPC recharter

Eliot Lear <lear@lear.ch> Fri, 06 January 2023 12:34 UTC

Return-Path: <lear@lear.ch>
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 28928C14CE45 for <hrpc@ietfa.amsl.com>; Fri, 6 Jan 2023 04:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.089
X-Spam-Level:
X-Spam-Status: No, score=-7.089 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, 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=lear.ch
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 7iQc4e7ucAYh for <hrpc@ietfa.amsl.com>; Fri, 6 Jan 2023 04:34:11 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (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 56A29C14CE3E for <hrpc@irtf.org>; Fri, 6 Jan 2023 04:34:09 -0800 (PST)
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1673008438; bh=AIkNeuuC0Q4NDf4oOzRJ8eiEguHq51CxoXSVjtgOyPU=; h=Date:To:References:From:Subject:In-Reply-To:From; b=ilWH5lVMJGnLqvKEigejFdb0vPORZf23FHtrPKlC5Ml9+35ocL2nCoCp9G0iYbYqc 74IXoyqOY2WWKwhlbGri5rCQQ9beC3O3sGg0jEDO8p4umFwTTTMaRAUAjcqGBO/J8B QF9XikcXlcNkGwMaPbIU7K76JaJOBMWvVGf2V5jc=
Received: from [192.168.0.222] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 306CXv56820076 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 6 Jan 2023 13:33:57 +0100
Message-ID: <134c16a8-8660-def4-d24a-3da1b5ea9953@lear.ch>
Date: Fri, 06 Jan 2023 13:33:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
To: Jens Finkhaeuser <jens@interpeer.io>, "hrpc@irtf.org" <hrpc@irtf.org>
References: <6ddd480d-76ed-a05e-066d-d740fee61441@cdt.org> <20230104215936.5exwsmtztk2shnzb@crankycanuck.ca> <63464538-4d40-a946-bcbe-570a6a3b49f9@lear.ch> <bTrwmE0TLN4PwdQNwJzzFmzPZPIjXrO6ld6loBlNBDBrluGDos9kftE0EzKxQMFhzhoE6LJewu0jGGFet5PqoYFj8gJaHRguKWDYFmp0fJ4=@interpeer.io>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <bTrwmE0TLN4PwdQNwJzzFmzPZPIjXrO6ld6loBlNBDBrluGDos9kftE0EzKxQMFhzhoE6LJewu0jGGFet5PqoYFj8gJaHRguKWDYFmp0fJ4=@interpeer.io>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------O9qAPCGQd0DPJuOzEuKpalmU"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/ok9x_L5EUUQ94sq_xM5J7jcctwg>
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:34:16 -0000

Hi Jens,

On 06.01.23 13:01, Jens Finkhaeuser wrote:
> 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.

Nobody disputes that human rights concerns are a problem now. What many 
of us have concerns about is how to balance the different and often 
conflicting rights and interests at the time of protocol design.

Eliot