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

Eliot Lear <lear@cisco.com> Sat, 21 September 2019 14:09 UTC

Return-Path: <lear@cisco.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 7E77B12003F for <hrpc@ietfa.amsl.com>; Sat, 21 Sep 2019 07:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PuVeuS0GpIDs for <hrpc@ietfa.amsl.com>; Sat, 21 Sep 2019 07:09:53 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D07C120033 for <hrpc@irtf.org>; Sat, 21 Sep 2019 07:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23179; q=dns/txt; s=iport; t=1569074993; x=1570284593; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=HW8dfSmOPaK1k6C8k6oKYRLKFoK5TaOFbzkakKp5ooI=; b=fpQ6JK8E0Q37M760YkD6UQEWU3Ei+gyTNudrYadlAmvbv6a94HPwXy4j BzDFi9qaABEvAJO0frPh7KtObPE67TGLVlztyJjO0xlvEgbCh/2U/OhBh KwXLmAkT6k0DKhfyXxFbM4L2WvEj+id6wzGj6qoIe0frbc+LJtCNRMaZI 4=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BAAACcLoZd/xbLJq1kGQEBAQEBAQEBAQEBAQwBAQEBAQGBZ4MLUyASKoQiiHyHeiWTF4gGAgcBAQEJAwEBGAEMCgEBgUuCdAKDLDgTAgMJAQEEAQEBAgEFBG2FLQyFSgEBAQEBAQEBASFLCwULCxgnAwICJx8RBhMUgw4BgXsPD6d7c4EyhEoCOwQBQIRnEIE0gVGKKSeBf4ERJwwTgkw+gkgZAQKBQAEBVIJVMoImBIxUiS6XCoIsgi6BE4xvBYIdgjgbgjaHS4N+iyakHoMRAgQGBQIVgWkhKoEuMxoIGxU7KgGCQQk1EhAUgVoXhQ2DVoVBPgMwAY0ogkUBAQ
X-IronPort-AV: E=Sophos;i="5.64,532,1559520000"; d="asc'?scan'208,217";a="17099395"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Sep 2019 14:09:50 +0000
Received: from [10.61.161.140] ([10.61.161.140]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8LE9nlM019223 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Sep 2019 14:09:50 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <AB573AA3-E776-4053-B52A-960786B2C83B@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E9E0C8C8-B06B-41D6-94CE-DBEA0299C3A9"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 21 Sep 2019 16:09:49 +0200
In-Reply-To: <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net>
Cc: hrpc@irtf.org
To: Niels ten Oever <mail@nielstenoever.net>
References: <156882005427.4606.6393818361687491816@ietfa.amsl.com> <a5361cda-994c-27ad-adf7-0aa06d61a8a2@nielstenoever.net> <20190920183918.d7mpxb4jyulfqqwj@anvilwalrusden.com> <CABcZeBPK8h8Bn-vhr6vq9_K9jUAE-ry5iZhLLiwjd15gpEuwHQ@mail.gmail.com> <28d4faab-cb89-34bd-d8bc-525aab96ab66@nielstenoever.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.161.140, [10.61.161.140]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/zT3PY0wG1UhIYaydJ_hDJCrwUMY>
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-political-05.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: Sat, 21 Sep 2019 14:09:57 -0000

Hi again, Niels,


> On 21 Sep 2019, at 15:09, Niels ten Oever <mail@nielstenoever.net> wrote:
> 
> Aren't proprietary standards, and the way they make it possible and impossible to do certain things, a prime example of a political process and political impact?


Let’s take a good example of a de facto standard that probably had very little to do with politics: the vt100 terminal.  It was never intended to be a standard.  It was a terminal, and a darned good one[*].  Most terminal emulators emulated the vt100 which is precisely how it became a standard, to the point where it was probably the first really well known example of “bug-for-bug compatibility”.  Was it a proprietary standard?  Digital specified the terminal design.  Was there political impact?  I don’t think so, but it’s hard to say.

The same was largely true for the IOS CLI for a good long while.  Others would emulate it as a good jumping off point.  Political impact?  I wouldn’t think so, but perhaps I lack appropriate imagination in this space.

Right now the NTIA is looking at Software Bill of Materials (SBoM).  One of the challenges they face is uniquely identifying software packages.  This naming requires some sort of source of authority for the names in use.  Anything having to do with naming is bound to have political implications.

Another example of a de facto standard that at best has very minor political implications is the simple key bindings in your mail editor.  There is a good chance that they line up with EMACS, just because that is what a lot of people have gotten used to.  Political impact?  I’d be hard pressed to find one, though maybe someone with a non-latin keyboard would disagree.

Eliot
*(though I was a weirdo and preferred a Data Media 1520 or the later Visual 55).

> 
>> I certainly agree that they "can be used"
>> for political means, though any "can" statement is pretty weak.
>> 
> 
> If we can document *that*, we would have made a lot of progress in the IETF imho.
> 
>> This is even true at some level for many standards, especially
>> because your definition of "standard" is so expansive:
>> 
>>    Standards  'A standard is an agreed-upon way of doing something or
>>       measuring something.'  [Sisson]
>> 
>> By this definition I think it would be pretty hard to argue that
>> SSLv2,  and SSLv3 weren't standards given their wide use, even
>> though they were just designed by people at one company.
> 
> I don't see how that definition would make that impossible.
> 
>> Another
>> example would be the Philips screwdriver head. What's the political
>> process that produced these?
>> 
>> 
> 
> The patenting of process by Henry F. Philips, the regimes under which is was patented, its competition with other screw heads (torx, etc). There is an enormous amount of politics, and societal ordering connected with screws.
> 
> Maybe this text by Bruno Latour might help further illustrate that:
> 
> http://www.bruno-latour.fr/sites/default/files/46-TECHNOLOGY-DURABLE-GBpdf.pdf
> 
> 
>> More generally, it seems like depending on how one interprets the
>> major claims in this document, they are either too strong (all
>> protocol and standards development is political)
> 
> Why is that too strong?
> 
>> or trivial (some
>> protocol and standards development is political). The first is too
>> strong for the reasons I indicate above,
> 
> I don't think so, but I am happy to discuss.
> 
> and the second seems pretty
>> obvious and doesn't really need much theorizing;
> 
> As said, I think it would be very useful if we would document this, so we don't need to repeat the discussion.
> 
>> one needs just point
>> to the development of some protocol which was a political process, and
>> it seems like that's been pretty amply documented for a number of
>> protocols/standards (e.g., HTTP/2 or TLS 1.0).
>> 
>> As I noted above, the claim that protocols can be used for political
>> means also seems relatively obvious (cf. Tor).
> 
> I am happy to conclude that we agree on the two statements:
> 
> - some protocol and standards development is political
> 
> and
> 
> - protocols can be used for political means
> 
> That's progress for me in this discussion. Now let's see if we can further flesh out:
> 
> - all protocol and standards development is political
> 
> Best,
> 
> Niels
> 
> 
> 
> 
> 
>> 
>> In short, I don't think this document should be published as an RFC
>> without major revision, which would presumably start with fleshing
>> out some more interesting claims.
>> 
>> -Ekr
>> 
>> 
>> 
>> 
>> 
>> On Fri, Sep 20, 2019 at 11:40 AM Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
>> 
>>    Hi,
>> 
>>    Apparently I haven't taken my OCD medications, and therefore I'm
>>    looking at this and responding.  I mostly looked at diffs between -04
>>    and -06.  Still speaking just for me.
>> 
>>    On Wed, Sep 18, 2019 at 05:27:53PM +0200, Niels ten Oever wrote:
>>> I am curious to hear whether you think these adaptations help address some of your issues.
>>> 
>>> Suggestion, comments, discussion, and pull requests are always welcome:
>> 
>>    In §1, I do not find economic impacts described in RFC 613.  I find
>>    RFC 3271 to be a bizarre reference, and very hard to justify given the
>>    way cited here.  I am totally mystified about how RFC 101 illustrates
>>    early community members making political decisions.  I'm having a hard
>>    time hooking up most of these other RFCs with this claim, too, and I
>>    wonder if it isn't the same question-begging I've raised before: just
>>    because a thing has somehow been the implication of a political
>>    process does not actually show that the thing is _itself_ political.
>>    If the entire approach is simply to take BramanII thesis as proven,
>>    then state that and get rid of all the other supposed support here,
>>    which is inadequate to prove the point and is obscure enough that the
>>    reader needs to do the work of chasing the references anyway.
>> 
>>    The reliance on the definition of Internet Standards in §2 is going to
>>    yield a rather underwhelming conclusion, since an awful lot of the
>>    Internet runs on stuff that isn't Internet Standard.  This includes
>>    HTTP 1.0, 1.1, and 2, so it's not like it's a little gap.
>> 
>>    In §5, the claim of "general agreement" is empirical and has nowhere
>>    been demonstrated that I can see.  And this discussion is _prima
>>    facie_ evidence against the claim.
>> 
>>    In §6, again things that are presented as "conclusions" are really
>>    just positions that are not actually argued for in the text.  This
>>    conclusion basically says that if you accept Russell, then the
>>    use-context counts.  But unstated here is the acceptance that Russell
>>    is right and also that therefore the use-context counts.  That's
>>    literally what's at stake in the discussion, and the I-D has not
>>    proven any of this at all.  The entire section continues to beg the
>>    question.  Either make an argument somewhere for this conclusion, or
>>    just take it out.
>> 
>>    I'm unlikely to have another train ride soon where I get to look at
>>    this again, so please don't take my future silence as agreement (or
>>    disagreement).  It's just silence.
>> 
>>    Best regards,
>> 
>>    A
>> 
>>    --
>>    Andrew Sullivan
>>    ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>
>> 
>>    _______________________________________________
>>    hrpc mailing list
>>    hrpc@irtf.org <mailto:hrpc@irtf.org>
>>    https://www.irtf.org/mailman/listinfo/hrpc
>> 
>> 
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>> 
> 
> --
> Niels ten Oever
> Researcher and PhD Candidate
> DATACTIVE Research Group
> University of Amsterdam
> 
> PGP fingerprint	   2458 0B70 5C4A FD8A 9488
>                   643A 0ED8 3F3A 468A C8B3
> 
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc