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

Uma Chunduri <> Mon, 09 October 2017 17:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F88F1344F0; Mon, 9 Oct 2017 10:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IfUGAkQP8G81; Mon, 9 Oct 2017 10:15:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE20913471B; Mon, 9 Oct 2017 10:14:44 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DXF27456; Mon, 09 Oct 2017 17:14:26 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 18:14:24 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:14:19 -0700
From: Uma Chunduri <>
To: S Moonesamy <>
CC: "" <>, "" <>, Padma Pillay-Esnault <>, "" <>
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTOT4HqNfbNA2TZ0OR3IdlIasmsqLZOf7KgAESvb+AAHpWAP//jtG5gAF2ZkA=
Date: Mon, 9 Oct 2017 17:14:18 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59DBAE83.00A0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8
Archived-At: <>
Subject: Re: [Ideas] 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: Mon, 09 Oct 2017 17:15:03 -0000


Some reponses in-line [Uma]:


		>>- Analysis of the concepts of identity-identifier split and dynamic 
		>>identifier changes, including their implications on anonymity and 
		>>privacy. Explicitly, the framework must define privacy requirements and 
		>>how potential extensions/solutions should meet them.

	>Why is privacy requirements being redefined?  The IAB already has a RFC about that.  I have not done a search; there are probably IETF RFCs about that subject.

[Uma]: I am not sure what do you mean by "Privacy requirements redefined".  Today in mapping systems LOC information is not private, meaning anybody can access this information. 
               This won't work (or fatal w.r.t security) for lot of applications who are seeking to use ID/LOC protocols.
               AUTH into the system (with mutual authentication, if we can) can help restrict who can access the LOC information.
               This also entails LOC updates with encryption.
                These are essential for ID/LOC protocol deployments (for the applications described  in IDEAS).
                Privacy requirements in the charter are mostly around these items...            

		>>Can you clarify what you mean here by maintenance work on IPv4 
		>>technical specification? Again the context here is a mapping system 
		>>infrastructure to be used by Id/Loc protocols.

	>There is currently an IETF thread about that [1].

	>S. Moonesamy


[Uma]: What's  the relevance of the same here.  IDEAS is not seeking to change any type of LOC information used in ID/LOC protocols... this is governed by ID/LOC protocol in use. It could be IPv4 or (mostly) IPv6.
               IDEAS doesn't alter or won't come into picture  outside of ID/LOC protocol context.

Uma C.