Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt

Paul Wouters <paul@nohats.ca> Tue, 17 September 2019 15:46 UTC

Return-Path: <paul@nohats.ca>
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 818C4120894 for <hrpc@ietfa.amsl.com>; Tue, 17 Sep 2019 08:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts321wuYTXp1 for <hrpc@ietfa.amsl.com>; Tue, 17 Sep 2019 08:46:02 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58C112087C for <hrpc@irtf.org>; Tue, 17 Sep 2019 08:46:01 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46XnWm1zTmzDJv; Tue, 17 Sep 2019 17:45:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1568735156; bh=uqpUAxwvNWW2oxPG+AKBvFiyVYncRNJOjWIKhk4ZmD0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sJDRuSmIAk6blZCJ+jdrVFWI2n+K0Y58trfFs8O3i2zGlm1uZ19pjjd2MZz5dxW6R MWhMvbwB8c5DIODqZxes6MV1TxSrDYT7NIJh3MtBd3I4kD7O17uToHi/N8+bCy44LO e5a0CyPt+LwYa5YDH3neAxshYJBqHleTfZ9CCtKg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5KUErrBNW4Iv; Tue, 17 Sep 2019 17:45:53 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Sep 2019 17:45:52 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 78773886; Tue, 17 Sep 2019 11:45:51 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 78773886
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6E40D401AF03; Tue, 17 Sep 2019 11:45:51 -0400 (EDT)
Date: Tue, 17 Sep 2019 11:45:51 -0400
From: Paul Wouters <paul@nohats.ca>
To: Ted Lemon <mellon@fugue.com>
cc: Niels ten Oever <mail@nielstenoever.net>, hrpc@irtf.org
In-Reply-To: <CE7F61F5-B11C-4DE7-853B-3CA1AA0F3167@fugue.com>
Message-ID: <alpine.LRH.2.21.1909171059280.22011@bofh.nohats.ca>
References: <156862506643.28251.9847319195246702362@ietfa.amsl.com> <2927d15d-30a2-189b-7a68-dfb11f5f5be0@nielstenoever.net> <980ffdbd-79fa-96ca-541c-09107b550531@doria.org> <5FEE04EF-307F-4A11-9ED4-E9B7394527AC@cisco.com> <35d4da40-fd0b-2ee9-3cc1-0c250ae1e93a@doria.org> <2CAFB54D-8435-45D5-8996-DEE6175B48A3@fugue.com> <d98e744e-11ee-09b9-0d38-4f5150692ff0@nielstenoever.net> <B4E48D50-5A76-4056-BBE4-39FBDB4EA155@fugue.com> <21470bee-2db1-0571-dea1-00832e01fa8f@nielstenoever.net> <CE7F61F5-B11C-4DE7-853B-3CA1AA0F3167@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/nfuKE8aVG0FqD4mB5gFfiU8wLKQ>
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "mail@nielstenoever.net" <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: Tue, 17 Sep 2019 15:46:05 -0000

On Tue, 17 Sep 2019, Ted Lemon wrote:

> It may be that you have taken on an impossible task.  But let’s assume for a moment that you have not.  If not, then when you
> are faced with a choice between readability and conformity, which do you think is the right choice to make?

I think the document is small enough that this can be handled on a case
to case basis. And that comments should be given regarding specific
sections of text that you think are not in the expected IETF style.

> While we can’t pretend that these pressures don’t exist for authors of IRTF documents, I think it’s worth actually aspiring to
> produce useful stuff, and to notice when the various pressures of academia distort the writing and make it less useful.

And I would say this applies to commenting or suggested change as well.
Your argument of "Let's step back and see" is rather vague and questions
the whole process. I think there are already enough people who agree
with the process outcome of having a useful document, and we are at a
point where we are looking for concrete input in improving the document.

Do you have any concrete OLD / NEW text suggestions?

> What is the good outcome here?

"This document aims to bring about a better understanding on the political nature of standards and protocols."

> Is it being heard, or is it being influential?

It is a bit early to say that, as the document is still in the draft
stage. The question to ask is more "can this document in the current
form, positvely influence or shape future IETF developments". I think
the answer is yes. If you have suggestions of making this document
even better, I'd love to hear those specific suggestions.

> Do we actually have something valuable to say?

I would love to have this document as a reference for document authors
to think about their specific IETF work impacts the global internet, and
via the internet, society. That is, this document would be a great
starting point for a document author to consider if their document needs
a Human Rights Consideration section. Writing such a section has as goal
to confirm (or perhaps improve) the protocol described causes no
unintentional harm to society.

In other words, the old IETF mantra of "making the internet work better"
is falling short of what we should be thinking of. Engineers like to
live in the ideology that "better" can be a purely technological issue,
but it is not.

For example, by making encryption with TLS ubiquitous, engineers feel
they have only made the internet better. Yet, some remote communities
that relied on proxy/caching servers to be able to have affordable
internet are now seeing a prohibitively expensive internet bill since
nothing can be cached anymore. Worse, some hacked up solutions now to
run the browser remotely in the cloud and only show a graphical output,
which can be strongly compressed and sometimes even largely cached,
to the client. This is resulting in a significantly reduced security
for those users, the equivalent of giving companies or nation states
administrative access to your personal laptop or mobile phone which
full surveilance powers. The opposite of what TLS was supposed to
accomplish.

With documents as RFC 1984 and RFC 7258 we have done some specific work in
the areas of non-technical awareness inside the IETF. This document does
a good job in providing an update to that old mantra. What I am mostly
afraid of, is that the "rough concensus" that works great for technical
protocol issues, is working quite poorly for IETF as an organisation
because it enforces the Status Quo. This can be painfully seen in recent
discussions where discussing how to be nicer to each other ends up in
fanatical censorship and organisational distrust arguments.

>  Who needs to hear what we have to say?   Why will it be beneficial for them to do so?

I think the answer to that is clear and obvious.

I understand and agree with the IETF's goal of reducing the political
aspects of internet engineering as much as possible. But a line must
be drawn somewhere. Just like we are seeing employees walk out of some
Silican Valley companies in protest of certain technologies they are
told ti develop that are used to suppress civil liberties and human
rights, so does the IETF need to take on some responsibility that it
is not aiding in turning internet technologies against human rights.
That requires people to sometimes step out of their engineering room,
and look at the world at large. And this document precisely tries to
do that. Make a document that engineers will read that is slightly
outside their area of expertise and comfort zone, and educate them
about things they might otherwise not think about.

In fact, I wonder if we should not have an item about this topic for
our newcomer sessions on Sunday, where we remind the engineers that
their work on internet protocols does not happen in a vacuum. Hopefully,
we can soon point those newcomers (and the old guard) at the very least
to this document.

Paul