Re: [hrpc] status on draft-irtf-hrpc-political

Eliot Lear <lear@cisco.com> Tue, 10 September 2019 06:26 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 3BFC8120882 for <hrpc@ietfa.amsl.com>; Mon, 9 Sep 2019 23:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-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, URIBL_BLOCKED=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 skCH3Ufo1iKx for <hrpc@ietfa.amsl.com>; Mon, 9 Sep 2019 23:26:09 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC20B120875 for <hrpc@irtf.org>; Mon, 9 Sep 2019 23:26:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36752; q=dns/txt; s=iport; t=1568096769; x=1569306369; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=BkooFqAC/WRdQtz+ZIW/avPo9a1v24XIjxfoKhFVTk4=; b=MYFJWL7TkGMChS/Dg0HtCPYQO6gCwqoqaZXz6XTOncLN1/pQ/To12PVU nasa5RdTxXQ6bTjVP7SAphJlXNNiHthqD1aG1cNwe0PNpzL22ApH8wrFd m3wCSAmQ1UETCZdjqiqdQ0WvgedAI+MkdwsL6QMcY062wGGpVcOKNAI3U Y=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DnAADhQHdd/xbLJq1lGQEBAQEBAQEBAQEBAQcBAQEBAQGBZwKBFIFvUyASKoQhiHyFYIIdJYdDjUmGCwICBwEBAQkDAQElCgEBhD8Cgls4EwIDCQEBBAEBAQIBBgRthS4MQgEQAYR2AQEBAQEBASNWBQsLGCABCQICVwYTFIMOATSBRw8PA6YvgTKENgFRA0CEagoGgTQBgVCIBgSCNYF/gREnDBOBTn4+gXloAQIBgT8BAYMpMoImBJR/XogVjlGCK4IsgRGIT4hoG4I0hz6DeieGR4QqjzeUI4MRAgQGBQIVgWkhKoEaDAgzGggbFTsqAYJBPoIQF4hjhUE+AzABCQmEDIlEgkUBAQ
X-IronPort-AV: E=Sophos;i="5.64,487,1559520000"; d="asc'?scan'208,217";a="16539382"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Sep 2019 06:26:05 +0000
Received: from [10.61.225.239] ([10.61.225.239]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8A6Q3QY007681 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Sep 2019 06:26:04 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F5EA76FF-85AC-42ED-A517-ED073A772862"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 10 Sep 2019 08:26:00 +0200
In-Reply-To: <20190909105043.GC26052@mir>
Cc: avri@apc.org, hrpc@irtf.org
To: Niels ten Oever <mail@nielstenoever.net>
References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> <20190909105043.GC26052@mir>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.225.239, [10.61.225.239]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/rwa2nQfNKodd8ZYQ3DqRD5kg3sU>
Subject: Re: [hrpc] status on draft-irtf-hrpc-political
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, 10 Sep 2019 06:26:12 -0000

Hi Niels,

I will look for your update.  I understand your enthusiasm and impatience to publish (I share with you both of those traits myself after a certain point).

Now please see below.

> On 9 Sep 2019, at 12:50, Niels ten Oever <mail@nielstenoever.net> wrote:
> 
> Hi Eliot,
> 
> Thank you very for you review.
> 
> On Mon, Sep 02, 2019 at 08:11:37PM +0200, Eliot Lear wrote:
>> Hi Avri,
>> 
>>> On 2 Sep 2019, at 15:29, avri doria <avri@apc.org> wrote:
>>> 
>>> Hi,
>>> 
>>> Recently there has been an ongoing discussion about taking this draft to
>>> Research group last call and then toward RFC using the IRTF process.
>>> Mallory and I have also been discussing it for a bit.   We are trying to
>>> determine whether its time for the last call.
>>> 
>>> During the Montreal session, from my remote perspective it seemed that
>>> there was a willingness for it move to last call, or at least no
>>> objection.  At least one person indicated they would do a review. Are
>>> there reviews in progress that are on their way?
>>> 
>>> At this point I wanted to ask the list, is it ready for a last call and
>>> are there people who have read it who either agree or who do not agree
>>> with taking it a step toward RFC. Does anyone object to taking it to
>>> last call. If you have read it and have a opinion/analysis, please do tell.
>> 
>> 
>> I do not think this work is ready.  There are several major issues:
>> 
>> The abstract does not clearly state what the paper attempts to address, and thus it is not clear whether the goal has been achieved.
> 
> I have added the following sentence to the abstract:
> 
> This document aims to bring about a better understanding on the political nature of standards and protocols.

I think there’s more to be said.  Please read down.

> 
>> Section 3 states a thesis (in exactly one sentence).
> 
> As you know this part expanded and then got boiled down again to exactly show what this draft is about.
> 
>> Section 4 addresses the thesis.
> 
> This section addresses what opinions on the question exist within the community, and seeks to locate them within academic debates on this topic.

Again, think about it from the reader’s perspective.  How many papers have you read that has a single sentence section?  My suggestion is simply to state the question in Section 1 and eliminate Section 3.  In fact, it might make for a good first sentence.  It’s bold and invites exploration.

> 
>> And then there’s a Section 5 which has nothing to do with the thesis.
> 
> Section 5 documents the political nature of standard setting processes in general, so it does related to the question.


Ok, on closer reading I think you’re right, and I was wrong on that point.

I still think your exploration should go a bit further.  While I like that you talk about interference in order to promote de facto standards, one can also show examples of interference to disrupt de facto standards.  In fact, the entire de jure standardization process is a form of that disruption.

In addition, one can find a great many examples of where purported de jure standards are never implemented, even absent interference.  One need only look at certain international standards bodies’ work to see it littered with science experiments (that includes the IETF), and the sad state of affairs with regard to network security.  A simple imprimatur does not guarantee implementation – thus the notion of “voluntary”.  There has to be something more: there has to be an economic need for the standard (de jure or de facto).  Professor Rebecca Henderson @ Harvard has done a lot of work on this subject, and on technology in general (I’m a big fan).  May be worth adding to your literature review, but it goes beyond the bounds of Section 4, which is really focused on a single question.

Putting that previous paragraph more simply, it would be useful to bound the effects you are attempting to characterize.  You might even show a few examples.  To name a few, we can borrow a bit from the ITAT workshop report in RFC 7305 and RFC 5218, looking at Bitcoin (see Böhme[1]), DNSSEC (see Eklund Löwinder[2]), and of course our two favorites, IPv6 and HTTP.  In fact, such a correlation would be, I think, a great addition, even if it is follow-on work.

If you want to go even further in terms of formal analysis, you may wish to review Greenstein and Stango.[3]. The nice thing about that book is that it gets well beyond the IETF or even Internet technology, but also includes some.  Its examples are a bit dated, tho.


> 
>> The use of the terms “normative” and “de facto” requires clarity.  The author is essentially saying that standards are in effect normative, even if we claim them to be voluntary.
> 
> Exactly, that is what emerges from the research.


Then isn’t that a far stronger thesis?  The question you are asking in Section 3 is trivially true, IMHO.  It boils down to the old maxim, that politics exists in a room of more than one person.  Which brings me to my next point.


> 
>> I am left with a major question: So what?  What are the implications of the answer to this question and why is it important to ask.
> 
> As you know, previous versions of this document came up with recommendations. But it was then brought up that a research cannot make recommendations for the IETF. Therefore this document serves as a platform for further discussion, and thus ensuring we don't need to repeat all the discussions we've had.


I fear you may have taken away the wrong conclusion from those discussions.  It is perfectly fine to make recommendations to the IETF.  Indeed I would say that the IRTF is at its best when it can make recommendations.  You just cannot do so in a normative fashion from the IRTF.  More importantly, showing some example of societal benefit/harm will ground the work.  Just be sure to ground your analysis in your recommendations.

> 
>> 
>> In addition, I have some questions about the supporting material.
>> 
>> Regarding this text in Section 4.5:
>> 
>> The process that led to [RFC6973] is similar: the Snowden disclosures, which occured[sic] in the political space, engendered the IETF to act.
>> 
>> I believe the author is actually referring to RFC 7258 (6973 was in the RFC Editor queue when Snowden hit, and is the product of the IAB), but even here, some additional support is necessary.  7258 was indeed motivated by Snowden.  But it addresses what is viewed as a technical problem.  That technical problem itself has political ramifications, but this isn’t really teased out well.  Keep in mind that people supported the publication of that document for reasons of their own, and we cannot really ascribe motivations.
> 
> The argument that is made is that is was a technical argument, which was also a political position. It does not say what the position it, but it foregrounds the socio-political nature of a technical statement.

Yes- but your statement could be read to infer political motivations on the part of the IETF.  And that is what I would be cautious about.  I think this is editorial.

Regards,

Eliot

[1] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_5.docx
[2] https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_17.pdf
[3] https://www.cambridge.org/core/books/standards-and-public-policy/9439DB66D660C8131578652F547A9E82