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

Niels ten Oever <mail@nielstenoever.net> Mon, 09 September 2019 19:52 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 E33351200F5 for <hrpc@ietfa.amsl.com>; Mon, 9 Sep 2019 12:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level:
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sVyXWWhJmeiQ for <hrpc@ietfa.amsl.com>; Mon, 9 Sep 2019 12:52:14 -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 B9E941200C7 for <hrpc@irtf.org>; Mon, 9 Sep 2019 12:52:14 -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 1i7Phl-0005cM-Ox; Mon, 09 Sep 2019 21:52:06 +0200
Date: Mon, 09 Sep 2019 12:50:43 +0200
From: Niels ten Oever <mail@nielstenoever.net>
To: Eliot Lear <lear@cisco.com>
Cc: avri@apc.org, hrpc@irtf.org
Message-ID: <20190909105043.GC26052@mir>
References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org> <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="eqp4TxRxnD4KrmFZ"
Content-Disposition: inline
In-Reply-To: <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@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: d10d7cb89ab8138c693deac6b6dd4d63
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/MdDYczVKUqn8SGQBieZA_Z19-8k>
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: Mon, 09 Sep 2019 19:52:17 -0000

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.

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

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

> I presume the correction is to combine section 3 and 4, but it leaves open what questions are meant to be answered in this document, and to what end.

I think it is quite clear that the political nature of protocols has been extensively discussed both on ietf@ietf, on this list, in plenary sessions and in the hallways. Documenting those discussions in a structured manner, and providing a framework to understand them will hopefully help us to progress in this discussion.

> There is not a clear delineation between protocols and standards.  Why are they viewed separately?

Not all standards are protocols. 

> Section 6 makes the following statement: 
> 
> it is undisputed that standards and protocols are both products of a political process, and they can also be used for political means.
> 
> If it’s not disputed, then what were the earlier sections meant to answer?

Because it shows a qualified and nuanced answer to the research question.

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

> That should be stated more explicitly, because seems central.  

Does section 5 not do this sufficiently?

> People differ on what constitutes “de facto” vs. “de jure”.  In some people’s view, IETF standards are de facto (I don’t hold that view myself, but some government types certainly do).> Most importantly, 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 doscussions we've had.

> 
> 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 psotion it, but it foregrounds the socio-political nature of a technical statement.

> 
> Section 1 of the document references RFC 49 with regard to privacy and security.  I understand the mention of security in that document, but not privacy.  Perhaps the author can clarify?
> 

I have added a semicolon to make sure it is understood that that reference is only understood to link to security, and not privacy AND security.

Thanks again for the review. I'll push a new version based on the changes.

Best,

Niels


> I have not checked the other references, but I suggest that they be checked.
> 
> Eliot
> 
> 



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