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

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 18 September 2019 01:40 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 B72B91200D6 for <hrpc@ietfa.amsl.com>; Tue, 17 Sep 2019 18:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=f6HB1R1D; dkim=pass (1024-bit key) header.d=yitter.info header.b=UhtfSSdj
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 8wxjaCR5i3mD for <hrpc@ietfa.amsl.com>; Tue, 17 Sep 2019 18:40:08 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7441E12007A for <hrpc@irtf.org>; Tue, 17 Sep 2019 18:40:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id E96BFBCC7D for <hrpc@irtf.org>; Wed, 18 Sep 2019 01:39:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568770775; bh=iuFEr6PH8zR6Mvxf67BxthI2IhZULpijWlLotcE5yeQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=f6HB1R1DpCJLeFwADvM6WtFbjlQnzGSyjQm5Rs0XsLBAff1ZVahnnSNRgd3f0ubpi 42+nSqZ1OKTkNOXL2mgovJin9ct+ostgg/+OGfUYIXt8bPHMPI8BIl0xPM0O5qgTrM F1AlQbgaC0v8mbRljCxfEQPxzB6kl/ktVLrqcsro=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liggCRGECAUs for <hrpc@irtf.org>; Wed, 18 Sep 2019 01:39:34 +0000 (UTC)
Date: Tue, 17 Sep 2019 21:39:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1568770774; bh=iuFEr6PH8zR6Mvxf67BxthI2IhZULpijWlLotcE5yeQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UhtfSSdjp2cOt7fm4+sWG7LA338Jiykm/UECE25QwFjCzI6rL7rpPayphxZbfFGVU uAMG9Alb2L++rNpspqz8tYFDr0YTnezP1txEcip10ErExMGm49km88711om/GkzWlE tgVT75D89pn46xlgdZH7gDoQZiAjeomC30YniOMw=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: hrpc@irtf.org
Message-ID: <20190918013932.eurns5h63oljz2pl@mx4.yitter.info>
References: <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> <99988D9D-B17F-4BAF-9FDB-4998D4572B1D@cisco.com> <20190917150253.m3oexerna7sdpieu@mx4.yitter.info> <caccc94b-6d60-f0fc-4544-80af0d84e377@doria.org> <bae8de5e-48c6-e221-fed8-b3ec825d356d@nomountain.net> <1138709738.5923109.1568749306948@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1138709738.5923109.1568749306948@mail.yahoo.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/qi2PbMGcn7y4wFYoHdExIuVtyYw>
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: Wed, 18 Sep 2019 01:40:12 -0000

Hi,

Speaking only for myself.

On Tue, Sep 17, 2019 at 07:41:46PM +0000, Mark Perkins wrote:
> 
> Personally, I think that many 'techies' try to pretend that their work is 'not political', whereas it is clear from the document that this is not the case.

Whether it is clear from this document is precisely what I find
contentious about the document, and asserting that it is so clear does
not make that true.

Despite not having the time for a complete review, I feel some
affection for this document because I made some early contributions to
it, so I had another look.  The assertion that the document "shows"
that protocols are in fact political is still not, in my reading,
borne out.

Section 4 attempts to outline various positions about the claim that
protocols are inherently political.  I think it mostly succeeds in
this, although I think some of the descriptions are more complete,
more charitable, or both than others.  I continue to suspect that §4.5
makes the conflation I asked about once before, but I can't really
focus on this such that I could make the case properly.

I really don't understand section 5.  I guess I understand that it is
an attempt to hook up the discussion of protocols and politics to the
function of standards.  Ironically, however, this undermines any
argument about protocols being necessarily political based on §4,
because not every protocol is a standard.  It would seem that a Venn
diagram would show this pretty clearly, but they're hard to make in
ASCII art.

But the real problem comes in §6, where claims are made that are
poorly supported by the text, and not obviously true.  For instance,

   Economics, competition, collaboration, openness, and political impact
   have been an inherent part of the work of the IETF since its early
   beginnings.

strikes me as a claim that may or may not be empirically true, but it
would need rather a lot of argument to support it.

	… but [the IETF] does set
   open standards for interoperability on the Internet, and has done so
   since the inception of the Internet.  

is at least possibly false, since many of the early standards for
Internet interoperability were set by the IAB, of which the IETF was a
subsidiary (see https://tools.ietf.org/html/rfc1120).

	Because a standard is the blue-
   print for how to accomplish a particular task, the adopted standards
   have a normative effect.  

This claim is belied by the number of IETF standards that are widely
ignored or have not been implemented, and it suggests that the IETF
has a kind of control that it does not actually have (as acknowledged
only in the previous sentence).  The best we can get is that adopted
standards _may_ have a normative effect, sometimes.  That seems hardly
surprising, but it's also a pretty weak claim on which to build a
universally-quantified claim about protocols and politics.

I'll number some propositions in the next passage for ease of
reference:

   [0] Whereas there might not be agreement among the Internet protocol
   community on the specific political nature of the technological
   development process and its outputs, [1] it is undisputed that standards
   and protocols are both products of a political process, [2] and they can
   also be used for political means.  [3] Therefore protocols and standards
   are not 'value-neutral, [4] and neither is the IETF' [RFC3935].  [5] Thus we
   can answer the research question 'are protocols political' in
   affirmative fashion.

In the above, [0] is simply an acknowledgemwnt of the differences in
§4.  [1] appears to be a claim that each of these propositions is true:

	[A] all standards are always a product of a political process
	[B] all protocols are always a product of a political process

It is entirely unclear to me that [B] is in fact true, much less that
it has been demonstrated anywhere in this draft.  And it seems trivial
to come up with an example where this is false -- for instance, the
process where some lone programmer writes v0 of some protocol for his
or her software such that others can use it (this is sometimes called
"an API", but it's often just as easily described as an immature
protocol).  At the very least, to call such a process "political" is
to render the meaning of "political" empty.  So, the truth of [1],
which depends on both [A] and [B] being true, seems suspect to me.

It seems to me that [2] is trivially true, since it is merely a claim
about both protocols and standards being possibly used for political
means, and as long as we can think of one example this proposition is
then true.

[3] is a very fast conclusion that, with liberal application of the
principle of charity, can be rendered thus

	[a] If a thing is both the product of a political process and
	possibly used for political means, then it is not value-neutral.

	[b.1] ARGUMENT FROM [1] GOES HERE
	therefore
	[b] protocols and standards are not value-neutral

	therefore

	[c] Protocols and standards are not value-neutral

(As you can see, [c] is the same as [3].)  The problem here starts
with the difficulty in accepting [1], as I outline above.  If we do
not believe that [1] is demonstrated, then the antecedent of the
conditional in [a] is not shown as [b], so the syllogism that gets us
to [c] can't proceed.  That's the first problem.  But the second
problem is in the premise [a] itself.  For the truth is that [a] is
just an _assertion_ that a political process and use for political
means entails that the result is somehow political.  That is not
actually demonstrated, however, and as a refutation of "the politics
lies entirely in the human use, not in the object itself" described in
§4.1 it is simply begging the question.  The number of seats in the
Canadian House of Commons is the product of a political process and it
is certainly used for political means.  That does not make the number
of seats "political" in itself: it might be just a contingent fact
about the current composition of the House of Commons.  In other
words, this depends very much on how one interprets "φ is political",
which was of course the very question that was open in the first
place, so the text has reasoned in a circle.

[4] does not follow from [3] at all, and I don't see how it follows
from any of the other premises either.  I don't know that it matters,
because it isn't obvious to me that the draft ever wanted to make the
claim that the IETF is or is not political.  One suspects that the
goal is to make an approving appeal to authority of RFC 3935, but it's
hard to tell.  [5] is false in case [3] does not hold, and since [3]
is in trouble [5] is too.

In case anyone wanted my recommendation, it would be for the RG to
change the focus of the document:

	In this document we aim to outline different views on the relation
   between standards and politics.

This would be enough and would be a contribution to the RFC Series
because it would document some positions (in §4).  In this case §6
could simply be removed.  I don't know what to do with §5 because I
don't understand it.  Alternatively, the author could publish this
document without it being an RG document, thereby avoiding the need to
come to consensus on a position that I believe unlikely to yield such
consensus (mostly because I believe the position to be manifestly
false).

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com