Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)

Sam Sun <> Wed, 11 October 2017 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94AD0132D17; Wed, 11 Oct 2017 13:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o35aUECmX9hN; Wed, 11 Oct 2017 13:50:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED9BA126B6D; Wed, 11 Oct 2017 13:50:24 -0700 (PDT)
Received: by with SMTP id a43so9299895qta.0; Wed, 11 Oct 2017 13:50:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0v3LrLj4qwxfgbExL4EK1rgIV7nlwYP6jIIphvkOzeU=; b=oUFwFs6ETJiWi//Qpt1ttG+sSXwZPpTSyO2dkjE4dA1wW4pw0kXEH701Aw18iQ2LEQ SUiD0rGIMEevOvEA2J8GuOkJqi6gEIHL2H9z0LHms6hqx2BzS7bgvBbBjKRsQraPxkT4 SUWoGUfUT311++6UNHO3Rv7VB7kLh0JsteDLa5uVHXG2cGO2tqSHd0PBSyZl9Eu5A/ZO rCAPLKAS1MV2MOjbFGwDfg1oW2DyWr4a7oKJDEewT4DT3P1/kc/VkBJ6tsVRHwInCcf5 QL+p18BR5TmVwE2fir8xh2sADPu+trP18TXQIKAshqzR/yPY0vQhgzjglXzrU65NwF2h aNKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=0v3LrLj4qwxfgbExL4EK1rgIV7nlwYP6jIIphvkOzeU=; b=c1XGfREaflFKNcU5f9waxj23xoeMIWYVbI1LGI2YjdIk8c85GiMTtWHaUW42lHjTks r89wH1nWqa7Mwchi+YcfgCbNutQLJvlM7de0Rol/iu170MmokS4ME5+jePVRYGhWiefz 7kRiLo7HdGkaShIbd70osRKZP0p2rkq9WpG8WuxfMaNh/KyJtgM9Qpbs1BdfJiYn/+4f RT23c1dTQXM6941cZOYYnn7sXGZNMWw/TNQNg1hM6mxiOlPzuNGg8lcnwqX6aaZr+rmb LM5ZMtd1hkMGqvpUaNTvDxBUv4rf13HNCGocdb5A4IvAoxQLppMT1OWgNVKvjsR1mKKE GNrw==
X-Gm-Message-State: AMCzsaXLEYq6GMFGQpcza5MoCiSmooGyqy3SFZJPcmotmldX6C8ILU8f jaF68/Ap65jSt1SOR+sZbuIJwQKzQqQ=
X-Google-Smtp-Source: AOwi7QDhZn5V0OoX9l6wLZ2tIhQgY25OzDuBrEjKSco+OUCkeBOyz8C/U2vcmL/wtkqp+H3Ic3awGA==
X-Received: by with SMTP id z33mr485762qtc.258.1507755023621; Wed, 11 Oct 2017 13:50:23 -0700 (PDT)
Received: from ( []) by with ESMTPSA id i92sm8545239qtb.65.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 13:50:22 -0700 (PDT)
To: Padma Pillay-Esnault <>, Christian Huitema <>
Cc: "" <>, " list" <>, Dino Farinacci <>, Robert Moskowitz <>, Brian E Carpenter <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Sam Sun <>
Message-ID: <>
Date: Wed, 11 Oct 2017 16:50:21 -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: <>
Content-Type: multipart/alternative; boundary="------------45BDC75F3D1A7FC31FD7423D"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Oct 2017 20:50:27 -0000

I second Padma on this!

I suggest we all work more constructively in refining our charter here, 
and be more focused on the tasks listed in the charter. It's probably 
too early to fight on the exact meaning of any particular word (e.g. 
'identity'). Features like privacy protection and discoverability can 
also be left for discussion when we work on the details of the 
framework, instead of being used to kill the whole proposal.

By the way, statements like "someone else failed before" should never be 
a reason to stop working on something of such importance.


On 10/11/17 1:32 PM, Padma Pillay-Esnault wrote:
> On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema 
> < <>> wrote:
>     On 10/11/2017 7:56 AM, Robert Moskowitz wrote:
>>>     and 'identity' is a red flag.
>>     Whow there!  You were part of the Namespace Research Group?  I
>>     think?  I was and we we worked a lot on this and came to the
>>     conclusion that there could be no conclusion.  Not even a rough
>>     concensus, it seemed.
>>     I have been using 'identity' to apply to things for 20 years.
>>     Pretty much ever since I started working with things.  Anyone
>>     that holds the position that 'identity' means we are talking only
>>     about people are allowing their thinking to be clouded. 
>     I am concerned that the current proponents of the IDEAS work are
>     mainly resisting the feedback, treating it as some roadblock put
>     in the path of their work by misguided privacy purists, and
>     attempting to remove the roadblocks by adding some weasel words to
>     the charter. I would feel much more confident if these proponents
>     acknowledged the tension between privacy and stable identifiers of
>     any sort, if that tension was clearly noted in the charter, and if
>     privacy goals were clearly stated.
> As one of the proponents, I feel I need to speak up because blanket 
> statements are just not helping.
> Speaking on behalf of my fellow proponents, we have always welcomed 
> constructive feedback from people who want/can contribute and make the 
> technology better. We have been willing to clarify the charter 
> (clarification does not mean weaseling).
> If it is helpful to  move forward, I am willing to volunteer for this 
> work and discuss with anyone to ensure constructive feedback and 
> comments are addressed.
>     Specifically, I think there is a contradiction between some of
>     documents. For example, draft-padma-ideas-problem-statement-01
>     states that:
>         o  A single entity may have multiple IDs, and IDs of the same entity
>            may have different life spans that are different from the lifespan
>            of the entity.  Furthermore, it is understood that IDs may have
>            different lifecycles, which may be permanent or ephemeral by
>            choice or design.
>         o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
>            for a permanent ID to protect the privacy of the related entity.
>     But then, draft-ccm-ideas-identity-use-cases-01 states that:
>         a.  Unique and Permanent Identity representing the entity enables
>             authentication (AUTH) with the mapping and Identity services
>             infrastructure.  While it is possible to do AUTH on Identifiers
>             those are not permanently associated to the entity.  Moreover,
>             AUTH operation is a relatively an expensive and inefficient
>             procedure (compared to LOC resolution for example) and can cause
>             excessive startup delays for lot of applications.
> As said earlier this draft was not updated by the authors and a new 
> version was posted yesterday.
>     The tension is obvious. On one hand, the ephemeral identifiers
>     envisaged in the problem statement would pretty much align the
>     privacy properties of the ID to those of IPv6 privacy addresses,
>     and that's good. On the other hand, the requirement to perform
>     authentication on identities completely negates that property.
>     I would be fine if the support for "Unique and Permanent Identity"
>     was explicitly excluded from the charter.
> AFAIK, none of the proponents resisted that.
>     There is obviously a need to support some form of access control
>     to a mapping database,
> Agreed.
>     but you do not need a reference to a permanent identity for that
>     -- systems similar to CGA would work just fine.
> The identity of the device is just adding a lever of identifier which 
> effectively allows authentication to modify the identifiers used by 
> that device but also what the users of these identifiers can look up. 
> If we had used "user of identifier" it would have been misconstrued 
> for humans. So damn if you do and damn if you don't ...
> We are open for discussions anytime.
> Padma
>     -- 
>     Christian Huitema
>     _______________________________________________
>     lisp mailing list
> <>
>     <>
> _______________________________________________
> Ideas mailing list