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

Niels ten Oever <mail@nielstenoever.net> Tue, 10 September 2019 13:01 UTC

Return-Path: <mail@nielstenoever.net>
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 0618E12011C for <hrpc@ietfa.amsl.com>; Tue, 10 Sep 2019 06:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 HIv9I8K0dgRk for <hrpc@ietfa.amsl.com>; Tue, 10 Sep 2019 06:01:54 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 3819412011E for <hrpc@irtf.org>; Tue, 10 Sep 2019 06:01:53 -0700 (PDT)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mail@nielstenoever.net>) id 1i7flb-0003mU-U8; Tue, 10 Sep 2019 15:01:48 +0200
Date: Tue, 10 Sep 2019 15:01:03 +0200
From: Niels ten Oever <mail@nielstenoever.net>
To: Eliot Lear <lear@cisco.com>
Cc: avri@apc.org, hrpc@irtf.org
Message-ID: <20190910130103.GB4318@mir>
References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com> <20190909105043.GC26052@mir> <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13"
Content-Disposition: inline
In-Reply-To: <7D0CA831-B326-4893-9A70-328454D57BB5@cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Authenticated-As-Hash: 54a52893e10ae071b73780542c02a8d9e3f33e6f
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 7969115219f8fafc5e1233f7e15217de
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/FZ19oJp03NuG_HvvPo3Tecget88>
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 13:01:58 -0000

On Tue, Sep 10, 2019 at 08:26:00AM +0200, Eliot Lear wrote:
> 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).
> 

It's been over two years since the publication of the first version, so I think I am doing relativley OK on the impatience part ;)

BTW, anyone ever seen this make error for xml2rfc? Am a bit at a loss:

$ make
xml2rfc draft-political.xml --html
Traceback (most recent call last):
  File "/usr/bin/xml2rfc", line 11, in <module>
    load_entry_point('xml2rfc==2.25.0', 'console_scripts', 'xml2rfc')()
  File "/usr/lib/python3/dist-packages/xml2rfc/run.py", line 482, in main
    htmlwriter.write(filename)
  File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1430, in write
    self._build_document()
  File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1376, in _build_document
    self.write_reference_list(references[0])
  File "/usr/lib/python3/dist-packages/xml2rfc/writers/legacy_html.py", line 569, in write_reference_list
    initials, surname = short_author_name_parts(author)
  File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 26, in short_author_name_parts
    initials = get_initials(a)
  File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 22, in get_initials
    initials = initials.split('.')[0]
AttributeError: 'NoneType' object has no attribute 'split'
make: *** [Makefile:12: draft-political.html] Error 1


More inline:

> 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.


Thanks a lot for these suggestion Eliot, really appreciated. I would really like to build on this draft by studying adoption and non-adoption and the complex of economic, political, and technical reasons of adoption and implementation, but I don't think it should take place in this draft. This draft is meant to be a platform for those discussions and analyses, and thus for for a iterative, or if you will layered, approach.

> 
> 
> > 
> >> 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.

These discussions come back again and again, and this makes it very hard to have a deeper discussion on the topic. That is why I think this document is important, because sometimes I feel we are spinning our wheels. I hope this draft will give us a platform on which we can continue the work, without repeating older discussions.

Best,

Niels 

> 
> 
> > 
> >> 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



-- 

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