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

Eliot Lear <lear@cisco.com> Mon, 02 September 2019 18:11 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 5D43D12004E for <hrpc@ietfa.amsl.com>; Mon, 2 Sep 2019 11:11:45 -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 V39V_QpFGl-w for <hrpc@ietfa.amsl.com>; Mon, 2 Sep 2019 11:11:43 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD05120047 for <hrpc@irtf.org>; Mon, 2 Sep 2019 11:11:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10851; q=dns/txt; s=iport; t=1567447902; x=1568657502; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=KWGhoCYurwqTwCdKEVRLUPngrN36vMl1v5bVcdXHOTM=; b=mith4iAFPL5sxwOqyMYh6C5JiN6hLyejeYGH0EuIJ4Jv6eWZplsbtTU6 lp7Os/578HAIV0kvkgxb5AYAfL0pu3fIPNI60HyWqd1BWEXUhxfaiGpOa qxoXxoUTD+3fkhbRqRY6NG7X1buT+4SmP0OuXIPXxiWZsfByG7MqWuU69 g=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AcAAAZWm1d/xbLJq1lGQEBAQEBAQEBAQEBAQcBAQEBAQGBVgEBAQEBAQsBgRWBfkQgEiqEIYh8h3olhz+LUYgFAgcBAQEJAwEBLwEBhD8Cgw83Bg4CAwECAgMBAQQBAQECAQYEbYU6hUoBAQEDASNWBQsLGCoCAlcZgyIBgXsPqgCBMoVKhHIQgTQBgVCKP4F/gREnDBOCTD6HTzKCJgSMbIhcllGCKYIngRGRIxuCM4c2g3YnimCjMIMPAgQGBQIVgWYiKoEuMxoIGxU7KgGCQT4SEBSQFT4DMJAGAQE
X-IronPort-AV: E=Sophos;i="5.64,460,1559520000"; d="asc'?scan'208,217";a="16207949"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Sep 2019 18:11:39 +0000
Received: from [10.61.200.200] ([10.61.200.200]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x82IBbQZ006480 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Sep 2019 18:11:38 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <54EFA587-4015-4A8B-BF7D-4C65FF7AB6BD@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_824FBA4F-44D6-4DA7-90D5-87F72CF2DBD2"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 02 Sep 2019 20:11:37 +0200
In-Reply-To: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org>
Cc: hrpc@irtf.org
To: avri@apc.org
References: <3690f332-0d45-9ad4-658d-e6c97bdd6b79@apc.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.200.200, [10.61.200.200]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/-xElO8gj60xohCwipoXPRvXPMkc>
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, 02 Sep 2019 18:11:46 -0000

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.
Section 3 states a thesis (in exactly one sentence).  Section 4 addresses the thesis.  And then there’s a Section 5 which has nothing to do with the thesis.  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.
There is not a clear delineation between protocols and standards.  Why are they viewed separately?
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?
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.  That should be stated more explicitly, because seems central.  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.

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.

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 not checked the other references, but I suggest that they be checked.

Eliot