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

Uma Chunduri <> Wed, 11 October 2017 10:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F4B2133226; Wed, 11 Oct 2017 03:56:22 -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 1qc4sza0FHnF; Wed, 11 Oct 2017 03:56:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A675133053; Wed, 11 Oct 2017 03:56:19 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DXI64017; Wed, 11 Oct 2017 10:56:16 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Oct 2017 11:56:15 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Wed, 11 Oct 2017 03:56:06 -0700
From: Uma Chunduri <>
To: Stephen Farrell <>, Robert Moskowitz <>, "" <>
CC: "" <>
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTOT4HqNfbNA2TZ0OR3IdlIasmsqLMpUwAgBFbboCAAA2BgIAAdv4w
Date: Wed, 11 Oct 2017 10:56:05 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59DDF8D1.002C, 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: Wed, 11 Oct 2017 10:56:22 -0000

Hi Stephen -

I would let Bob to respond the questions you asked - but If I may for the below question 

		>> This is about machines, and processes, have ID/Loc through some 
		>> underlying technology (e.g. HIP, ILA, LISP) to have a common ID 
		>> discovery and Loc back to ID (for things like HTTP redirects).

	>If that's the case, then there appears to be serious confusion in the use-cases draft at least. And "identity" seems a fairly mad term to pick if one means processes or devices, as it pretty much guarantees raised hackles and confusion.


1. IDEAS only intended deal with aspects for control/mapping plane of ID/LOC protocols. 
      How  and what kind of Identifier's used in the data packets are governed by the  respective ID/LOC protocol in use.  Just give some examples -
      It could be HIT in case of HIP with security properties, EID/Anonymous EID's in case of LISP with encapsulation.
     This has been explicitly updated in the use-case draft and can be further updated in the charter. But, I would note  this is the intention for the  following in the current charter text -
      "The IDEAS WG will closely coordinate with the LISP and HIP WGs (and with
	others as needed) in order to keep them well-informed of the progress."

2.  And regarding the usage of the term "identity" - not sure what's the confusion and why this has been associated with humans to start with. This has been further clarified in the discussions past few days and also been updated in the document. 
      Now the term,  we felt appropriate as the intent is in the context  of AUTH (examples of identifies thought through IPV4_ADDR, FQDN, RFC822_ADDR, IPV6_ADDR, DER_ASN1_DN, DER_ASN1_GN, KEY_IDs etc) , 
       which is consistent with any of the authentication mechanism we use today* as defined by IETF. 

Uma C.

   Or one of the 20/30+ EAP AUTH methods with mutual authentication properties (depending the low power/high power mobile/industrial/vehicular IoT device in question)