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

Mark Perkins <marknoumea@yahoo.com> Wed, 18 September 2019 03:32 UTC

Return-Path: <marknoumea@yahoo.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 AC3B4120073 for <hrpc@ietfa.amsl.com>; Tue, 17 Sep 2019 20:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=yahoo.com
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 2_pO-lCsFZAk for <hrpc@ietfa.amsl.com>; Tue, 17 Sep 2019 20:32:21 -0700 (PDT)
Received: from sonic304-56.consmr.mail.bf2.yahoo.com (sonic304-56.consmr.mail.bf2.yahoo.com [74.6.128.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4A4120096 for <hrpc@irtf.org>; Tue, 17 Sep 2019 20:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1568777539; bh=7gdJ+DEyBly/PP+CSFTpbIXqXZEw/hT4byUQ3Yug50Y=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=M12bk48dA/xOA6+1+KFn7xGKKE8CRTtwdK7dmz/UZ70B/mEoDBxd2Qn4Bg+tFiwmx5aqXYTxto1/nO8wcGzBWsJvbyK3JbqvXw1owtx8ilBbWbWGM/kIOhD5Nf5RqZXeJWNE4AFDJSSdnpipzIsyXd4ywSflLZKBPYrcOg3EoD0Go+qKnY0Ve7ZZ8Z02Yb0cpASWUlTnyg0xuErdPCLhIt/tgPlTI93owsjPRyvZ4eYgA4e+0kCE/5Wh7EWJT0zf5JsMCjzptjbTgwvfftbYGKXzu/TMGPYkroHvqGcmUIhYad77StlZuJnI9HNJER3bd+rbw9mI17LFqVrPybHG2g==
X-YMail-OSG: 7jHLcb0VM1lWDJJGU7QFLhzko7AcosAFV7T.2AnOJWmwES_72OGYZqpMx_K0yW_ 6OZ8HV3xMF4D6ckTAN5tEtST9dvjEGFLTfBdAr1OGAPLslUBY0K4vDTzRMPuSFq5ruQD9qMJzxFx yqiIBFhWc5L7iVZN7W3EHEYomtqpSd3YCa.tXezwrlUkC6qvlnaLrMXLUIe1iPcGKFGZvnmGbfRw zyPzsq8N7k7yiveo1t7IQYb39h5WkZJq3bNrpt.wms6Gqcs9cuGIAGSF6LSZk6v2KhhG0WD5Wm95 h4L91ag7pOr0e2YJ6TDUNwGcuIbxhJBGnpoj4ksLxO0.zmsqn7BTscBp5M71rLzB8ycbu68W7OG4 7L5YSiWY1Yr6CFh.en84o92ZE1Q356jeNUGvylIHpULEDD2m1NzKWoGQZCMDU_kCdzqkJvIGcN1a xrgzIOetDcDP8q0MZH.OYdSp6BxGhtrCf0Do_8KEB1aiP9Lk7H1VpsxH8yveoV9H_NnZP1DAqYtl GhA0TBkAcai1VOEOgcBwZAl_1p35sxj3Ab356088pgm.fQAbMVVoSC89Vzqo.DiGW6zLhCWnfagj MoRTlFPbyWHfX2ZQVanU8j0onoWU7_0fVKl6X9pVHYMuxu9Pe6si9xhf48mwUWKS.wAVV_ZrffMm nxsZSt9ySwP6jvTzzu78iUEDHW4SI0N2SCskoqwjgz_swGWx4vxKN9MoSx3b3ubdJmQWQhCS_wyI 4CeOOK2QxdANjdftPz5r1cRemggyJW9XLCfiuhWWauFtl1iMbqeingDBbydkwpQ7v38g5J829_mb 0aZY4lvA0NXU6ofIjnrTWr9AA.hgabzQS6usNHeDf5GTeKttarc6Idyx3RFVl5Mw6dyXT39Q32Pd OrQYSAD2lZBvR7rYUqBYrgK3_dQ_1NolgFnL6RrwXg4QYxa3t93Ke1VZ3AtMMwrTZuT94WJmG1F6 DSmBFZUMu_ttSPJ_wAv4F01hoJMLGINsV2bWuwRr5clSkcXuPjbfSN1ur3114zAp9F.8Oa43I6yy hcpEdVj7WIhsn9G3sJ3U18NRW4Bsdj2KuD8rTWj9DTGOgr2NGkFROgXB9P3T5AExf4Y2PmdCVVRE MkK8cE_xLc_mgNHsv5B5Ib7PfbZ4b0ajJCD7_EstZSawGZiQQpz7iZCKFUmdHf4_K5vVDb4avDa8 169cT39Gwu1apoo5hZtVIFXmGqryrxHUEEnxYBDtDcAR33DrHlgz7yMXRqBWh5p52D9o9CE5jQ1d jvMdeZ1PUDcmNKtg2LVMlq8.XCa31b.mDEkyXzvlzW1jP_lfgId7_eLxiY0fraOkhTp1WLpCKrQ- -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 18 Sep 2019 03:32:19 +0000
Date: Wed, 18 Sep 2019 03:32:17 +0000
From: Mark Perkins <marknoumea@yahoo.com>
To: hrpc@irtf.org, Andrew Sullivan <ajs@anvilwalrusden.com>
Message-ID: <296695201.6028595.1568777537962@mail.yahoo.com>
In-Reply-To: <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> <20190918013932.eurns5h63oljz2pl@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_6028594_1763590850.1568777537959"
X-Mailer: WebService/1.1.14303 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/_zDWz47BdGT2dZk1k8TfJhHRF-M>
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 03:32:24 -0000

 Thanks Andrew
I think that you are reiterating, in a more detailed form, why it is essential that the vocabulary section distinguises between protocols & standards, and that the following text clearly applies that distinction.
I would argue that standards are inherently political, and that protocols that become standards thus also become political.
Protocols can be developed in a myriad of ways; while it COULD be argued that since an individual is a product of a social/political process, his protocols, for the purposes of this document, I think that would be unecessary sociology. However, some protocols are developed by groups of people (commercial, academic, non-profit, etc), which are clearly embedded in a political context which constrains/directs their development of protocols; in this case, the protocols can clearly be seen as 'political' as well as 'technical', some more so than others.
While standards come in a variety of flavors, with a variety of coercive mechanisms (market, legal, technical, etc), their very development as standards is political. Whether they are used or not can change over time, as can be the extent of their use (individual, local, international, etc.) and is a reflection not only of their technical nature, but also of their political nature - which can also change over time.
For me, the document does show that protocol and, especially, standard development / work is political, BUT I come from a political rather than techie background ;) I am glad that Andrew (& others) are pointing out weaknesses that need to be addressed in the argumentation, and hopefully (along with clear citations & examples) we can address those weaknesses so that he (& others) agree that document has shown its assertions to be true
Mark Perkins

    On Wednesday, September 18, 2019, 12:40:20 PM GMT+11, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:  
 
 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

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc