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

Sam Sun <sam.sun.ietf@gmail.com> Wed, 11 October 2017 21:36 UTC

Return-Path: <sam.sun.ietf@gmail.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06D1321A0; Wed, 11 Oct 2017 14:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Di42W4ki31QK; Wed, 11 Oct 2017 14:36:43 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA2C1320D9; Wed, 11 Oct 2017 14:36:43 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id n61so9568827qte.10; Wed, 11 Oct 2017 14:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=m67DVlXkmYZNL09akbjqNN/n7ud8h5DWL2zZJB3GBnQ=; b=NQ06ngWhzeX1oWG7ltvvQZrRkEF0xGCCi4xXc8fXx791qt7G8K7FqkotWNyboOLvBJ mnSRloJMq6ou6+Pkvr1VsdRSHf3V5v5/j5f6mvt7u+MeJOJe1SfqOFeugV3bwWmsakQf 5leip3kI9LtTVseDsJKwT00rJteVw/eHA7rbygnrjsQVhmvHkbQXhk0LsjNC30FCmd7C YegYQmUsFFCVLv5NttemPsUOaqR7a1cdFUXM1MdL9QByukOTBDqf/6MYIXNdCfIs3FaV AjRXwhvuqBcX7/iR9Jt+si66e05CX0baQ/xDFYBclpaK4Z5jT59NI41xgQFSM5BtMqok sChw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=m67DVlXkmYZNL09akbjqNN/n7ud8h5DWL2zZJB3GBnQ=; b=qazDgDNZ71JsSGYBN7OVwQ1bpMS1rBIqFOkKX2Ryg2nLdLF/l8VabRN5sfDzvgO6GY YYZP7QO/RYy8lH9swW+q5BFKrd0la7Fia4T1vNzBjZT95z2bSSfU7ourRfyACxDywPXp CsEgSElBtQ4gRyXQ6GAz+fa3rcbJJBajbPruq1j0Kfm8jKgIJTa0Rkr6JVgUKd/QJD2/ xSjzhgMPhD3arfEkcehg24B36/lqG1HsV/yG78UbfHW4aE0N2KOVLS8nmG8fwoU9wOIP Cxvp6V8XzcK+9Cy4xtoX96aAalXKS0yMBHuWBecRQ/FD6C0vm1otoNpSRp05/3GLHXyf KokQ==
X-Gm-Message-State: AMCzsaWglv3HGLnKjF/uVnaZaKFIYuDEuL+hcQaKtlSudWHODPZf55Eq Kgqx8n5byeF0wOAXPXL2KvE=
X-Google-Smtp-Source: ABhQp+S4wr5iD/UhFbLix6d9QSsZreGk2nM0qt9EzcSLjpIsxeg02JJOSdkNBmEUFGoclTMQ2MeNyQ==
X-Received: by 10.55.22.146 with SMTP id 18mr576777qkw.281.1507757802350; Wed, 11 Oct 2017 14:36:42 -0700 (PDT)
Received: from host-4-159.cnri.reston.va.us (cnri-7-77.cnri.reston.va.us. [132.151.7.77]) by smtp.gmail.com with ESMTPSA id f64sm8514760qka.6.2017.10.11.14.36.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 14:36:41 -0700 (PDT)
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, ideas@ietf.org, ideas-chairs@ietf.org, aretana.ietf@gmail.com
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <b4f10efb-a3d7-fa75-6cef-f891fdb5d002@gmail.com> <19E6AAF8-4A05-4D72-A48E-A6D7BEEEF8AE@cooperw.in>
From: Sam Sun <sam.sun.ietf@gmail.com>
Message-ID: <f2dfc306-d869-430d-3965-189a39c0fdbc@gmail.com>
Date: Wed, 11 Oct 2017 17:36:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <19E6AAF8-4A05-4D72-A48E-A6D7BEEEF8AE@cooperw.in>
Content-Type: multipart/alternative; boundary="------------F52B1A742766373B1C76A731"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/l7gYDuH_GU4BXoOWWHx1MPECtHU>
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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 21:36:46 -0000


On 10/11/17 4:58 PM, Alissa Cooper wrote:
>
>> On Oct 11, 2017, at 4:38 PM, Sam Sun <sam.sun.ietf@gmail.com 
>> <mailto:sam.sun.ietf@gmail.com>> wrote:
>>
>> My recall from the last BoF meeting is that we got quite a large 
>> number of hums on the issues reflected in the current charter. I 
>> believe there are sufficient motivations here.
>>
> I don’t see this clearly reflected in the minutes or on the list 
> discussion. From the minutes it sounds like there was general interest 
> in the work, but also acknowledgment that folks with deployments are 
> not engaged, and many folks present who hadn’t read the problem 
> statement or felt that the problem was not well defined. From the list 
> discussion, at least for the identity management piece I see only the 
> proponents defending the proposal (but happy to be corrected — I’m 
> looking at this for the first time this week so may have missed some 
> messages).
>>
>>
>> The disputes on privacy protection and discoverability in the mailing 
>> list only shows the interests from the community looking for a better 
>> solution. Having disputes about different approaches, or even 
>> question whether or not there’s any feasible solution, is exactly why 
>> we need to form a WG to work on this, IMHO.
>>
> This seems backwards to me. We don’t typically form working groups in 
> order to determine whether there is work to be done and whether there 
> is any way that work can be designed in alignment with our BCPs and 
> principles about things like privacy. That is what the chartering 
> process is for.
>
This is good clarification.

The proposed charter did state the exact works to be done, including 
"security analysis of the complete system". Intrinsic impact on user 
privacy could be covered here. Whether the infrastructure envisioned 
opens up obvious attacks on privacy depends how the system is finally 
defined. With proper access control and protection on data 
confidentiality, it may or may not.


Sam



> Alissa
>>
>>
>> Sam
>>
>>
>> On 10/11/17 10:53 AM, Alissa Cooper wrote:
>>> 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:
>>> https://datatracker.ietf.org/doc/charter-ietf-ideas/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> BLOCK:
>>> ----------------------------------------------------------------------
>>>
>>> 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
>>> deployments.
>>>
>>> (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.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ideas mailing list
>>> Ideas@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ideas
>>
>