[Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)

Alissa Cooper <alissa@cooperw.in> Wed, 11 October 2017 14:53 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: ideas@ietf.org
Delivered-To: ideas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19913318B; Wed, 11 Oct 2017 07:53:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: "The IESG" <iesg@ietf.org>
Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
Date: Wed, 11 Oct 2017 07:53:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/cbMBbGIbcrhVzHGggJZdXvMfsAg>
Subject: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 14:53:55 -0000

Alissa Cooper has entered the following ballot position for
charter-ietf-ideas-00-06: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:


I do not think this group is ready to be chartered at this time given the
significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for the
mapping system and the identity management system envisioned here do not appear
to be backed up by those who have developed and deployed ID/LOC separation
protocols. Nor do there seem to be compelling arguments that the framework that
this proposed WG would produce would be the motivator for further interoperable

(2) The work proposed here seems as if it would have a substantial intrinsic
impact on user privacy if widely deployed. In cases like these, I don't believe
it's sufficient to say that the WG will analyze the situation and propose
mitigations; the work proposal itself needs to explain how the design of the
infrastructure envisioned is going to mitigate what seem like obvious attacks
on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a bar in
Singapore, or at a potential future BoF) would need to resolve both of the
above issues in order to address concerns raised by the community.