From nobody Fri Apr 7 18:31:48 2017 Return-Path: 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 C472A126DFB for ; Fri, 7 Apr 2017 18:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 7ofY5zimBy_r for ; Fri, 7 Apr 2017 18:31:45 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE869127978 for ; Fri, 7 Apr 2017 18:31:44 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D352958C4AE; Sat, 8 Apr 2017 03:31:40 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B5A36B0BC41; Sat, 8 Apr 2017 03:31:40 +0200 (CEST) Date: Sat, 8 Apr 2017 03:31:40 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Robert Moskowitz , Hesham Elbakoury , Padma Pillay-Esnault , alexander.clemm@huawei.com, ideas@ietf.org, Axel.Nennker@telekom.de Message-ID: <20170408013140.GA6386@faui40p.informatik.uni-erlangen.de> References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF8E814@SJCEML701-CHM.china.huawei.com> <28a19ae6-bf14-a848-ba17-6b0d0bb2b887@htt-consult.com> <68650443-E3C6-4810-AD0E-B0EBC336BB1F@gmail.com> <52460b04-55a6-1ade-31f6-d27f814ccd06@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 01:31:48 -0000 Inline On Wed, Mar 29, 2017 at 09:08:32AM -0700, Dino Farinacci wrote: > > For some there is seems to be no distinction between Identifier and Identity, but when you get to registration and services, Identity starts going into policy decisions. > > But an Identifier identifies an entity, so when the entity is registered it is described by an Identifier value. When an identity is described in a policy statement, it is described by an Identifier value. > > It is hard to disagree with my statement above because it is such a fundamental and basic definition. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well... https://en.wikipedia.org/wiki/Digital_identity ISO/IEC 24760-1 defines identity as "set of attributes related to an entity" So lets say GRIDS stores for an entity one or more identifier entries. Each identifier entry has data like locators associated as well as some authenticator like a cert owned by the entity. Entity connects to grids, "asserts its identity" by a cryptographic proof of ownership operation for the authenticator (eg: cert) and then it can change the data, eg: locators associated with the identifier entry of the entity. In this example, i guess (identifier, authenticator) is one identity of the the entity. Maybe someone wants to spend 118 CHF on that ISO standard to get the IDEAS terminology in compliance with it ? ;-)) How many disagreement points do i score ? Cheers Toerless > Dino > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Sat Apr 8 13:49:32 2017 Return-Path: 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 5A7AF12706D for ; Sat, 8 Apr 2017 13:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fWxVj48GAGcv for ; Sat, 8 Apr 2017 13:49:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6C6126C7B for ; Sat, 8 Apr 2017 13:49:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKN61952; Sat, 08 Apr 2017 20:49:23 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 8 Apr 2017 21:49:22 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML702-CHM.china.huawei.com ([169.254.4.233]) with mapi id 14.03.0235.001; Sat, 8 Apr 2017 13:49:11 -0700 From: Hesham ElBakoury To: Toerless Eckert , Dino Farinacci CC: Robert Moskowitz , Padma Pillay-Esnault , Alexander Clemm , "ideas@ietf.org" , "Axel.Nennker@telekom.de" Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp916jXsqyqVhJkKB5Db3/L5LNaGrQVOA//+WETaAAL3IgP//iy7ggACz3ACAAIH3AIAAFGSAgAAHhoCAAADyAIAOwlIAgAATruA= Date: Sat, 8 Apr 2017 20:49:10 +0000 Message-ID: References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF8E814@SJCEML701-CHM.china.huawei.com> <28a19ae6-bf14-a848-ba17-6b0d0bb2b887@htt-consult.com> <68650443-E3C6-4810-AD0E-B0EBC336BB1F@gmail.com> <52460b04-55a6-1ade-31f6-d27f814ccd06@htt-consult.com> <20170408013140.GA6386@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170408013140.GA6386@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: M7Ai RwzI jXff jnfT pFYd qQWp sPpo uEYW zhTm 04KQ 73DH 8oQf 817B 9Ugl 9tOk AAtzpQ==; 6; YQB4AGUAbAAuAG4AZQBuAG4AawBlAHIAQAB0AGUAbABlAGsAbwBtAC4AZABlADsAZgBhAHIAaQBuAGEAYwBjAGkAQABnAG0AYQBpAGwALgBjAG8AbQA7AGkAZABlAGEAcwBAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQBkAG0AYQAuAGkAZQB0AGYAQABnAG0AYQBpAGwALgBjAG8AbQA7AHIAZwBtAC0AaQBlAHQAZgBAAGgAdAB0AC0AYwBvAG4AcwB1AGwAdAAuAGMAbwBtADsAdAB0AGUAQABjAHMALgBmAGEAdQAuAGQAZQA=; Sosha1_v1; 7; {049AC071-3E44-48CA-B199-FB2D6E12C95C}; aABlAHMAaABhAG0ALgBlAGwAYgBhAGsAbwB1AHIAeQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Sat, 08 Apr 2017 20:48:42 GMT; UgBFADoAIABbAEkAZABlAGEAcwBdACAARABpAGEAcwBhAG0AYgB1AGcAYQB0AGkAbgBnACAASQBkAGUAbgB0AGkAZgBpAGUAcgAgAGEAbgBkACAASQBkAGUAbgB0AGkAdAB5AA== x-cr-puzzleid: {049AC071-3E44-48CA-B199-FB2D6E12C95C} x-originating-ip: [10.46.110.214] Content-Type: multipart/alternative; boundary="_000_C3855D43D6701846AD1151A536E7A058240DAB2FSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58E94CD3.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5271462e6ccc4de9b0f102f77736dfd Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 20:49:30 -0000 --_000_C3855D43D6701846AD1151A536E7A058240DAB2FSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that Identity is a hot topic nowadays. For example, there are two = identity conferences this year that might be of interest: * Digital Identity Summit: https://digitalidentitysummit.com/ * Know Identity - Defragmented Identity Conference : https://onewor= ldidentity.com/dc-conference-know-identity-2017/?gclid=3DCMmotYXIlNMCFYS3wA= odpTkHhA Few years ago Microsoft had the Geneva claim based access platform, where s= ervices and applications are accessed based on the claims provided by the u= ser. Hesham -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de] Sent: Friday, April 07, 2017 6:32 PM To: Dino Farinacci Cc: Robert Moskowitz; Hesham ElBakoury; Padma Pillay-Esnault; Alexander Cle= mm; ideas@ietf.org; Axel.Nennker@telekom.de Subject: Re: [Ideas] Diasambugating Identifier and Identity Inline On Wed, Mar 29, 2017 at 09:08:32AM -0700, Dino Farinacci wrote: > > For some there is seems to be no distinction between Identifier and Ide= ntity, but when you get to registration and services, Identity starts going= into policy decisions. > > But an Identifier identifies an entity, so when the entity is registered = it is described by an Identifier value. When an identity is described in a = policy statement, it is described by an Identifier value. > > It is hard to disagree with my statement above because it is such a funda= mental and basic definition. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well... https://en.wikipedia.org/wiki/Digital_identity ISO/IEC 24760-1 defines identity as "set of attributes related to an enti= ty" So lets say GRIDS stores for an entity one or more identifier entries. Each= identifier entry has data like locators associated as well as some authenticator like = a cert owned by the entity. Entity connects to grids, "asserts its identity" by a cryptographic proof o= f ownership operation for the authenticator (eg: cert) and then it can change the data,= eg: locators associated with the identifier entry of the entity. In this example, i guess (identifier, authenticator) is one identity of the= the entity. Maybe someone wants to spend 118 CHF on that ISO standard to get the IDEAS = terminology in compliance with it ? ;-)) How many disagreement points do i score ? Cheers Toerless > Dino > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas --_000_C3855D43D6701846AD1151A536E7A058240DAB2FSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems that Identity is a hot topic nowadays. F= or example, there are two identity conferences this year that might be of i= nterest:

 

·         Digital Identity Summit: https://digitalidentitysummit.com/

·         Know Identity - Defragmented Identity Confer= ence : https://oneworldidentity.com/dc-conference-know-identity-2017/?gclid=3DCMmo= tYXIlNMCFYS3wAodpTkHhA

 

Few years ago Microsoft had the Geneva claim base= d access platform, where services and applications are accessed based on th= e claims provided by the user.

 

Hesham

 

 

-----Original Message-----
From: Toerless Eckert [mailto:tte@cs.fau.de]
Sent: Friday, April 07, 2017 6:32 PM
To: Dino Farinacci
Cc: Robert Moskowitz; Hesham ElBakoury; Padma Pillay-Esnault; Alexander Cle= mm; ideas@ietf.org; Axel.Nennker@telekom.de
Subject: Re: [Ideas] Diasambugating Identifier and Identity

 

Inline

 

On Wed, Mar 29, 2017 at 09:08:32AM -0700, Dino Fa= rinacci wrote:

> > For some there is seems to be no distin= ction between Identifier and Identity, but when you get to registration and= services, Identity starts going into policy decisions.

>

> But an Identifier identifies an entity, so w= hen the entity is registered it is described by an Identifier value. When a= n identity is described in a policy statement, it is described by an Identi= fier value.

>

> It is hard to disagree with my statement abo= ve because it is such a fundamental and basic definition.

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 

Well...

 

https://en.wikipedia.org/wiki/Digital_identity

  ISO/IEC 24760-1 defines identity as "= set of attributes related to an entity"

 

So lets say GRIDS stores for an entity one or mor= e identifier entries. Each identifier

entry has data like locators associated as well a= s some authenticator like a cert owned

by the entity.

 

Entity connects to grids, "asserts its ident= ity" by a cryptographic proof of ownership

operation for the authenticator (eg: cert) and th= en it can change the data, eg: locators

associated with the identifier entry of the entit= y.

 

In this example, i guess (identifier, authenticat= or) is one identity of the the entity.

Maybe someone wants to spend 118 CHF on that ISO = standard to get the IDEAS terminology

in compliance with it ? ;-))

 

How many disagreement points do i score ?

 

Cheers

    Toerless

 

> Dino

>

> ____________________________________________= ___

> Ideas mailing list

> Ideas@ietf= .org

> https://www.ietf.org/mailman/listinfo/ideas

--_000_C3855D43D6701846AD1151A536E7A058240DAB2FSJCEML701CHMchi_-- From nobody Thu Apr 13 00:01:30 2017 Return-Path: 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 BFE46127B73; Thu, 13 Apr 2017 00:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 QRhvcAHdGUCB; Thu, 13 Apr 2017 00:01:25 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 45CDE128768; Thu, 13 Apr 2017 00:01:25 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id o21so29778064wrb.2; Thu, 13 Apr 2017 00:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jgpvPMcxukrxb1L3i/n2q8i1FwoDtUpL3g7t6hm2CVY=; b=hnr/7p4n8j1Q7sr8hQzwTuq3lcIDEEv0+sLC1h/9kFW0UBp9rcxYl/rFM/aigRAySB bf1IhkZUdfz/HKj9O3b08+2R/PgqWDC4pWxcyvD+QvH8voyligZDg8GZr3okDSGJVkQG MhSKPIPP0nUvhJevpToTI3gnogAooBrzXC9yQP6XN0f4UTm9lHmYiedJtBfwRzc++nS4 6dV+K56P0iKfJ0phZgzyqvghLrkJjgWVzRiTCwJQPMeyNiVD9jmJZ7YCvKEX1+7DVcpP 6jAiquEV620wgE7FKp/Toz/yA/JEL0GYzsJankqU/HUlvDU48zzQ4UYa2EyNx8x2zZsy GnCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jgpvPMcxukrxb1L3i/n2q8i1FwoDtUpL3g7t6hm2CVY=; b=lU7G8KB9UDUCfo7/JIQMU5yMa9Gjunwc+djD5bO04YRmoWuGe7sgRBBFfq8VlXTsDO 7wI6C7a/T4I+bjTAy7aKqmdAqp5bYdJN+io4ZYc3ug7aY5u/6Y2+KxRRBP7Cb8P6gxe6 k7OL2SpXTfqGzVE7md/5BXGuzVKRDGFFcXIofiWU0FjFT0xJuBnUQpWfCWrGEpZ1qiaG KIxfN1AQb/dDWuXkw8scWseTc3LF8wLHu/SmlXDFM/1FRkkG+I7ZBq8kAcHgjbzSurJC BsznDB9X2VKMu+8OtCfzCfLOswwkDzliGx2MPfi6W4NZb8/QeZ91rCO1puCtTrzJL+HU c5Uw== X-Gm-Message-State: AN3rC/4z/HyM0Uy88SJDfVFECvXw1sobkTfhqu5D+u5v29wVDfDOQ9P4 QxFhigxbeYkBsAq6iLJYg8UjVulQdg== X-Received: by 10.223.164.141 with SMTP id g13mr1328695wrb.82.1492066883436; Thu, 13 Apr 2017 00:01:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.170.76 with HTTP; Thu, 13 Apr 2017 00:01:23 -0700 (PDT) From: Padma Pillay-Esnault Date: Thu, 13 Apr 2017 00:01:23 -0700 Message-ID: To: ideas@ietf.org, LISP mailing list list , NVO3 , routing-discussion@ietf.org Content-Type: multipart/alternative; boundary=f403045f1638918848054d06e45a Archived-At: Subject: [Ideas] IDEAS @IETF98 Minutes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 07:01:29 -0000 --f403045f1638918848054d06e45a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please find below the minutes of the meeting. Many thanks to our two scribes: Toerless Eckert and Uma Chunduri. If you have any comments/corrections please let us know. Thanks Padma IDEAS Side Meeting Minutes 1. Slides Please find below a pointer to the slides https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=3Ds= haring 2. Agenda 2.1. Introduction and Problem Statement for IDEAS - Padma Pillay-Esnault https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-01= .txt IDEAS Introduction IDEAS aims to be the forum where common issues across all ID Enabled Networks can be discussed. Goals: - to create awareness - to present the work proposed in IDEAS - A generic architecture that is scalable, extensible, robust, secure, and flexible for future ID enabled networks - to sollicit comments and feedback from the community on the drafts - to call for new contributions Problem Statement Motivation: Why Now? ID solutions can address diverse areas IOT, M2M communication, Discovery, privacy, Latency, Virtualization Beneficial to have standardized common infra across ID protocols Key Issues Identified Lack of common Infrastructure cause harder to deploy a common solution E2E - No Common Management due to disjoint nature - No Common/consistent policy framework - Risk of fragmented communication Identifier Lifecycle - No guidance or allocation scheme for public IDs - Agreed upon ID format and scope in cross-domain communication - Recycling IDs - Better address merging of networks Security of Mapping Systems - Secured access to the MS - data integrity, Confidentiality, Anonymity, Access control - DDOS attack prone Proposal - To investigate the opportunity of a new specification effort to address some specific problems from an ID Enabled Networks perspective. - To find a common solution and infrastructure that can be shared by current protocols and facilitate the introduction of new ID-based services while avoiding rehashing the same problems again each time a new service pops up - Generic Resilient ID Services (GRIDS) infrastructure with standardized access and multiple services. The services include - secured registration - discovery - updates with data integrity, - mapping and resolution capabilities, - define relationships between IDs or group of IDs - access control policy and security - Other Related Work/ Groups - LISP (ALT, DDT) - HIP uses DNS - NVO3 WG Questions: Eric Nordmark: What=E2=80=99s unclear is what is out of scope re. Identifie= r. Are you considering "what is an identifier", clearly this is not about URI, how about IP in IP with IPsec ? Is one of them an identifier the other one a locator. Even LISP was not clear cut between locator/identifier as one could be routed locally. Padma Pillay-Esnault: Regarding scope, the way we thinking about this, there can be multiple scopes with multiple allocation systems. The range of solutions is so vast that it may not be appropriate to only have one solution. Plenty options of where to put it and how to put. GRIDS can be used as local, proximity, global instance just as possible to have Private ID. Bob Moskovitz: Concept of Identity and Identifier is important and I have been involved and saw some form of this for the last 20 years may be more. It really does to be discussed in the list. Definitely it needs to be fleshed out a lot more about what identifiers are, should be part of the work, tough problem with lots of opinions. 2.2. Requirements for Generic Resilient Identity Services (GRIDS) in IDEAS - Alex Clemm https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt - This is the core infrastructure document which captures all requirements - Talked on Core components of GRIDS - GRIDS-MS, GRIDS-IS are covered - Grouping and Meta data are not described yet - Identity and Identifier definitions elaborated - Talked in details about mapping services - Identity related services are detailed - Structured and unstructured identifiers - Grouping related services - Requirement (Distribution, Redundancy, Performance and Scale..) - Key performance requirements - Security requirements - GRIDS should be able to be deployed in private space as well as in public domain - The naming evolved from mapping system, which was too functionally constrained. Questions: Ravi Ravindran: Trying to understand scope: trying to expand LISP ? What is the scope ? Alex Clemm: No, not planning to just "expand lisp", that should be done in LISP WG. Some of those questions are better answered in the use cases, clear which ones are not resolved by LISP. Benjamin Damm: How is this different from Multicast DNS ? Bob Moskovitz: I can totally implement everything in GRIDS in DNS but that would not be a great idea but there would be a lot of problems, DDoS, etc.. Think that metadata is not optional but must be called mandatory. Determined by use case. Alex Clemm: Note taken Dino Farinacci: rfc8060 defines multiple RLOC types, eg: LISP can support those. Does this look like multicast DNS ? No, this is network layer mapping information mapping addresses to addresses. Eric Nordmark: Multicast DNS is a local service, this is meant to be global= . 2.3. A Blockchain-based Mapping System - Jordi Paillisse - Blockchain is decentralized and secured - Add blocks of data one after other - Blockchain work flow - Transaction with a data, Senders Signature and Senders Public Key to a P2P network - Properties - Decentralized, No prior trust is required Data can be added but not modifiable - Basic Idea - Store mappings in blockchain - EID prefixes are distributed to all participants - Pros and Cons - Infrastructure less, Decentralized, fast lookup, secure, no prior trust, simple rekeying - Cons - Slow updates, costly boot strapping - Comparison with LISP DDT - No Infra, easy management - Issues with RPKI - Anonymity (prefix linked to owner name) - Revocation issues (block chain doesn=E2=80=99t use certificates) - Scalability - Growth similar to BGP Churn - Prefix delegation + Mappings - Design considerations - Bitcoin is too restrictive - New technologies - More scalable and more contracts - Dedicated chains.. Questions: Toerless Eckert: what is the incentive model for participants to deploy the necessary infrastructure for this system ? In bitcoin, the security is achieved through tremendous amount of calculation, the cost for that hardware is financed by handing out bitcoins for successful calculations. Do we need to hand out IPv4 addresses to pay for IDEAS bitchain calculations ? Jordi Paillisee: Good question, there are some new blockchain methods with other incentive structures. See references on last slide of the slide deck. Regarding incentive it is about security. Dino Farinacci: When a new registration added (Say Jordi first and then 100000 more records added. Now the entry moved to the end. This solution will have complete history of movements. Q1: can the really old stuff be chopped off. Q2: if RLOCs change etc. is it not really slow when you need to look through a lot of other newer mappings ? Jordi Paillisee : Q1 Answer: It can be mitigated through implementation Q2 answer: implementation detail. Database should have latest data for all entities, not in sequential order of evens. Manu Sporny: Blockchain developer. Referring to blockchain group (w3c-blockain group) met in the morning, sees overlap with that work, how could we create alignment. Whom to talk to coordinate ? Padma Pillay-Esnault: Let=E2=80=99s discuss this offline. 2.4. Use Cases for IDEAS - Tom Herbert https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt - Mapping essentially a distributed key/value store - Key is fixed size per mapping DB - Maps "virtual address" to "physical address" - Mapping table is assumed to be distributed and possibly shared for load - Rate of entry is important characteristic - Use Cases: - Common Control plane - Mobility - Network Virtualization (for network simplification) - Heterogeneous Multi-Access (hetnet) - Security - Device Discovery - Mobility - Map entity to its current location for forwarding - Variants - Encap: IP Mobility, IPIP, GTP etc.. - ID/LOC: LISP, ILA - Properties - Mobility sub-cases - Within a single mobile network - Mobility between mobile networks - Multi-homed devices - Hetnet environments - Whole networks are mobile (WIFI in bus) - Network Virtualization - Variants - Encap: Map virtual IP address to Physical address - ID/LOC split - Properties - Mostly in DC - Address resolution static tunnels - Could be used as alternative means to resolve L2/L3 - Host Routes - A network could implement virtualization simply by creating a host route Questions: Bob Moskovitz: We have been mobile since 1993. We need to start looking at mobility as baseline. Would almost challenge in discussion the starting point. Take rate of mobility (how fast it can move) as distinguishing attribute. Tom Herbert: Agree. How quickly is my "device" going from one network to another. With higher rate, updates become a problem. Also get more and more use cases where latency becomes an issue. Hope we could avoid relying on a distributed system. Control path is critical system, keeping everything in sync with low latency and secure, reliable, available. Can we design this system with applicability across different use cases. Mike McBride: There are applications like AR/VR that have strict requirements hopefully, that is also included in use cases. Tom Herbert: Yes this has been discussed in the draft. Padma Pillay-Esnault: Yes there different strict requirements depending on the different use cases. Earlier there was a question regarding IOT use cases. The requirements may vary for example depending if the type of IOT device. If it battery operated (supposed to last 10 years) then it may have only one way communication (such as a pet tracker or sensor) and may even be on non-IP. In some cases proximity and context may be important too= . 2.5. Mobility First and Global Name Resolution Service - Parishad Karimi https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt -Name based communications - Name based Architectures IP =3D=3D> LISP, HIP at IETF MF and NDN (i= n academia) - MF - Mobility First Background - MF started in 2010 under NSF, FIA - MF Protocol Layers - GUID (global Unique Identifiers) - We seek to use global name resolution system for resolution - Name Resolution Requirements - Low propagation and response Latency - Storage and load scalability - Security and reliability - Extensibility and flexibility - Structure of mapping should not be limited - Why can=E2=80=99t DNS can be supported (DNS Deficiencies) - TTL based caching - High Mobility makes caching ineffective - Static Placement of AUTH Servers - Reliance on hierarchal (relating root) - For MF we have looked into DMAP and GMAP and Auspice - Comparison of all three systems - Conclusion - We need a global mapping system with MF project 2.6 Conclusion & Next steps - Padma Pillay-Esnault Where do we want to go from here ? Next Steps Slide: - We need more collaboration from the community and looking forward for more participation on topics such as Blockchain and distributed trust, Late binding, Fast Caching, Security, DDOS protection .... - Let=E2=80=99s take discussions to the alias - Discuss the scope of work 3. Other Info Mailing list: IDEAS List address: ideas@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dideas To subscribe: https://www.ietf.org/mailman/listinfo/ideas --f403045f1638918848054d06e45a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2= =A0

Please find below the minutes of the meeting.

Many thanks to our two = scribes: Toerless Eckert and Uma Chunduri.


= If you have any comments/cor= rections please let us know.

Thanks
=

= Padma


IDEAS=C2=A0Side Meeting Minutes=C2=A0

=C2=A0

1. Slides

Please find below a pointer to the slides

https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp= =3Dsharing

=C2=A0

=C2=A0

2. Agenda=C2=A0

2.1. Introduction and Problem Statement for=C2=A0IDEAS=C2=A0 - Padma Pillay-Esna= ult

=C2=A0

https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-= 01.txt=C2=A0=C2=A0=C2=A0=C2= =A0

=C2=A0

IDEAS=C2=A0Intro= duction

=C2=A0

IDEAS aims to be the forum where common issues across all ID Enabled Networks can= be discussed.

=C2=A0Goals:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 to create aware= ness

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 to present the = work proposed in IDEAS

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 A generic archi= tecture that is scalable, extensible, robust, secure, and flexible for future ID enabled networks

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0to sollic= it comments and feedback from the community on the drafts

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 to call for new co= ntributions

=C2=A0=C2=A0

Problem Statement

Motivation: Why Now?

ID solutions can address diverse areas

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IOT, M2M communication,= Discovery, privacy, Latency, Virtualization

Beneficial to have standardized common infra across ID protocols

=C2=A0

Key Issues Identified

Lack of common Infrastructure cause harder to deploy a common solution E2E

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No Common Management due to disjoint nature

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>No Common/consistent=C2=A0policy framework

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Risk of f= ragmented communication

=C2=A0Identifier Lifecycle

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = No guidance or allocation scheme for public IDs

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Agreed upon ID format and s= cope in cross-domain communication

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Recycling IDs

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Better address merging of networks

=C2=A0Security of Mapping Systems

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Secured access to the MS

=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data integrity, Confidentiality, Anonymity, Access control

=C2=A0 -=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 DDOS a= ttack prone

=C2=A0

Proposal<= /p>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To investigate the opport= unity of a new specification effort to address some specific problems from an ID Enabled Networks perspective.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To find a common solution= and infrastructure that can be shared by current protocols and facilitate the introduction of new ID-based servic= es while avoiding rehashing the same problems again each time a new service po= ps up

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Generic Resilient ID Serv= ices (GRIDS) infrastructure with standardized access and multiple services.=C2=A0 The services include

=C2=A0 =C2=A0 =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 secured regi= stration

=C2=A0 =C2=A0 =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>discovery

=C2=A0 =C2=A0 =C2=A0 -= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 updates with data integrity,

=C2=A0 =C2=A0 =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mapping and resolution capabilities,

=C2=A0 =C2=A0 =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 define relationships = between IDs or group of IDs

=C2=A0 =C2=A0 =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 access control = policy and security

- Other Related Work/ Groups

=C2=A0 =C2=A0 = =C2=A0 =C2=A0- LISP (ALT, DDT)

=C2=A0 =C2=A0 = =C2=A0 =C2=A0- HIP uses DNS

=C2=A0 =C2=A0 = =C2=A0 =C2=A0- NVO3 WG

=C2=A0

Questions:=

Eric Nordmark: What=E2=80=99s unclear is what is out of scope re. Identifier. Ar= e you considering "what is an identifier", clearly this is not about UR= I, how about IP in IP with IPsec ? Is one of them an identifier the other one = a locator. Even LISP was not clear cut between locator/identifier as one coul= d be routed locally.

=C2=A0

Padma Pillay-Esnault: Regarding scope, the way we thinking about this, there can = be multiple scopes with multiple allocation systems. The range of solutions is= so vast that it may not be appropriate to only have one solution. Plenty optio= ns of where to put it and how to put. GRIDS can be used as local, proximity, global instance just as possible to have Private ID.

=C2=A0

Bob Moskovitz: Concept of Identity and Identifier is important and=C2=A0 I have been involved and saw some form of this for the last 20 years may be more. = It really does to be discussed in the list. Definitely it needs to be fleshed = out a lot more about

what identifiers are, should be part of the work, tough problem with lots of opinions.

=C2=A0

=C2=A0

2.2. Requirements for Generic Resilient Identity Services (GRIDS) in=C2=A0IDEAS=C2=A0=C2=A0- Alex Clemm

=C2=A0

https:= //www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt

=C2=A0

- This is the core infrastructure document which captures all requirements

=C2=A0=C2=A0=C2= =A0=C2=A0 - Talked on Core components of GRIDS

=C2=A0=C2=A0=C2= =A0=C2=A0 - GRIDS-MS, GRIDS-IS are covered

=C2=A0=C2=A0=C2= =A0 =C2=A0- Grouping and Meta data are not described yet

=C2=A0=C2=A0=C2= =A0=C2=A0 - Identity and Identifier definitions elaborated

=C2=A0=C2=A0=C2= =A0=C2=A0 - Talked in details about mapping services

=C2=A0=C2=A0=C2= =A0=C2=A0 - Identity related services are detailed

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Structured and unstructured identifiers

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0- Grouping related services

=C2=A0=C2=A0=C2= =A0=C2=A0 - Requirement (Distribution, Redundancy, Performance and Scale..)

=C2=A0=C2=A0=C2= =A0=C2=A0 - Key performance requirements

=C2=A0=C2=A0=C2= =A0=C2=A0 - Security requirements

=C2=A0=C2=A0=C2= =A0=C2=A0 - GRIDS should be able to be deployed in private space as well as in public domain

=C2=A0

- The naming evolved from mapping system, which was too functionally constrai= ned.

=C2=A0

Questions:=C2=A0=

Ravi Ravindran: Trying to understand scope: trying to expand LISP ?=

What is the scope ?=C2=A0

=C2=A0

Alex Clemm: No, not planning to just "expand lisp", that should be don= e in LISP WG. Some of those questions are better answered in the use cases, clea= r which ones are not resolved by LISP.

=C2=A0

Benjamin Damm: How is this different from Multicast DNS ?

=C2=A0

Bob Moskovitz: I can totally implement everything in GRIDS in DNS but that woul= d not be a great=C2=A0idea=C2=A0but there would be a lot of

problems, DDoS, etc.. Think that metadata is not optional but must be called mandator= y. Determined by use case.

=C2=A0

Alex Clemm: Note taken

=C2=A0

Dino Farinacci:=C2=A0 rfc8060 defines multiple RLOC types, eg: LISP can support = those. Does this look like multicast DNS ? No, this is network layer mapping information mapping addresses to addresses.

=C2=A0

Eric Nordmark: Multicast DNS is a local service, this is meant to be global.

=C2=A0

=C2=A0

2.3. A Blockchain-based Mapping System - Jordi Paillisse=C2=A0

- Blockchain is decentralized and secured

=C2=A0 =C2=A0 = =C2=A0- Add blocks of data one after other

=C2=A0=C2=A0=C2= =A0=C2=A0 - Blockchain work flow

=C2=A0=C2=A0=C2= =A0=C2=A0 - Transaction with a data, Senders Signature and Senders Public Key to a P2= P network

=C2=A0=C2=A0=C2= =A0=C2=A0 - Properties

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 - Decentralized, No prior trust is required

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Data can be added but not modifiable

=C2=A0=C2=A0=C2= =A0=C2=A0 - Basic=C2=A0Idea

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 - Store mappings in blockchain

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 - EID prefixes are distributed to all participants

=C2=A0=C2=A0=C2= =A0=C2=A0 - Pros and Cons

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 - Infrastructure less, Decentralized, fast lookup, secure, no prior trust, simple rekeying

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 - Cons

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Slow updates, costly boot strapping

=C2=A0=C2=A0=C2= =A0=C2=A0 - Comparison with LISP DDT

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 - No Infra, easy management

=C2=A0 =C2=A0=C2=A0=C2=A0- Issues with RPKI

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Anonymity (prefix linked to owner name)

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Revocation issues (block chain doesn=E2=80=99t use certificates)

=C2=A0=C2=A0=C2= =A0=C2=A0 - Scalability

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Growth similar to BGP Churn

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Prefix delegation + Mappings

=C2=A0=C2=A0=C2= =A0=C2=A0 - Design considerations

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Bitcoin is too restrictive

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - New technologies - More scalable and more contracts

=C2=A0=C2=A0=C2= =A0=C2=A0 - Dedicated chains..

=C2=A0

Questions:=

Toerless Eckert: what is the incentive model for participants to deploy the necessar= y infrastructure for this system ? In bitcoin, the security is achieved=C2=A0 through tremendous amount of calculation, the cost for that hardware is financed by handing out bitcoins for successful calculations. Do we need to hand out IPv4 addresses to pay for=C2=A0IDEAS=C2=A0bitchain calculations ?<= span>

=C2=A0

Jordi Paillisee: Good question, there are some new blockchain methods with other incentive structures. See references on last slide of the slide deck.=

Regarding incentive it is about security.

=C2=A0

Dino Farinacci:=C2=A0

When a new registration added (Say Jordi first and then 100000 more records adde= d. Now the entry moved to the end. This solution will have=

complete history of movements. Q1: can the really old stuff be chopped off. Q2: if R= LOCs change etc. is it not really slow when you need to look through a lot of ot= her newer mappings ?

Jordi Paillisee : Q1 Answer: It can be mitigated through implementation

Q2 answer: implementation detail. Database should have latest data for all entities, not in sequential order of evens.

=C2=A0

Manu Sporny: Blockchain developer. Referring to blockchain group (w3c-blockain group) met in the morning, sees overlap with that work, how could we create alignment. Whom to talk to coordinate ?=C2=A0

Padma Pillay-Esnault: Let=E2=80=99s discuss this offline.

=C2=A0

2.4. Use Cases for=C2=A0IDEAS=C2=A0- Tom Herbert

https:= //www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt

=C2=A0

- Mapping essentially a distributed key/value store

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Key is fixed size per mapping DB

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0- Maps "virtual address" to "physical address"

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Mapping table is assumed to be distributed and possibly shared for load

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Rate of entry is important characteristic

=C2=A0

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Use Cases:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Common Control plane

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0- Mobility

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Network Virtualization (for network simplification)

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Heterogeneous Multi-Access (hetnet)

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Security

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Device Discovery

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Mobility

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Map entity to its current location for forwarding

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Variants=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Encap: IP Mobility, IPIP, GTP etc..

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - ID/LOC: LISP, ILA

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Properties

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Mobility sub-cases

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Within a single mobile network

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Mobility between mobile networks

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Multi-homed devices

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Hetnet environments

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Whole networks are mobile (WIFI in bus)

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Network Virtualization

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Variants

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Encap: Map virtual IP address to Physical address

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- ID/LOC split

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Properties

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Mostly in DC

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Address resolution static tunnels

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Could be used as alternative means to resolve L2/L3

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Host Routes

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - A network could implement virtualization simply by creating a host route<= span>

=C2=A0

Questions:=

Bob Moskovitz: We have been mobile since 1993. We need to start looking at mobi= lity as baseline. Would almost challenge in discussion the starting point. Take = rate of mobility (how fast it can move) as distinguishing attribute.

=C2=A0

Tom Herbert: Agree. How quickly is my "device" going from one network= to another. With higher rate, updates become a problem. Also get more and more= use cases where latency becomes an issue. Hope we could avoid relying on a distributed system. Control path is critical system, keeping everything in = sync with low latency and secure, reliable, available. Can we design this system with applicability across different use cases.

=C2=A0

Mike McBride: There are applications like AR/VR that have strict requirements hopefully, that is also included in use cases.

=C2=A0

Tom Herbert: Yes this has been discussed in the draft.

=C2=A0

Padma Pillay-Esnault: Yes there different strict requirements depending on the different use cases. Earlier there was a question regarding IOT use cases. = The requirements may vary for example depending if the type of IOT device. If i= t battery =C2=A0operated (supposed to last 10 years) then it may have only on= e way communication (such as a pet tracker or sensor) and may even be on non-= IP. In some cases proximity and context may be important too.

=C2=A0

2.5. Mobility First and Global Name Resolution Service - Parishad Karimi

https://www.ietf.org/id= /draft-karimi-ideas-gnrs-00.txt

=C2=A0

-Name based communications

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0- Name based Architectures IP =3D=3D> LISP, HIP = at IETF MF and NDN (in academia)

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - MF - Mobility First Background

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - MF started in 2010 under NSF, FIA

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - MF Protocol Layers

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - GUID (global Unique Identifiers)

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - We seek to use global name resolution system for resolution<= /span>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - Name Resolution Requirements

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Low propagation and response Latency

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Storage and load scalability

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Security and reliability

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Extensibility and flexibility

=C2=A0=C2=A0=C2= =A0=C2=A0 - Structure of mapping should not be limited

=C2=A0=C2=A0=C2= =A0=C2=A0 - Why can=E2=80=99t DNS can be supported (DNS Deficiencies)

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - TTL based caching

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - High Mobility makes caching ineffective

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Static Placement of AUTH Servers

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Reliance on hierarchal (relating root)

=C2=A0=C2=A0=C2= =A0=C2=A0 - For MF we have looked into DMAP and GMAP and Auspice<= /p>

=C2=A0=C2=A0=C2= =A0=C2=A0 - Comparison of all three systems

=C2=A0=C2=A0=C2= =A0=C2=A0 - Conclusion - We need a global mapping system with MF project=

=C2=A0

=C2=A0

2.6 Conclusion & Next steps - Padma Pillay-Esnault

Where do we want to go from here ?

Next Steps Slide:

- We need more collaboration from the community and looking forward for more participation on topics such as Blockchain and distributed trust, Late bind= ing, Fast Caching, Security, DDOS protection ....

=C2=A0

- Let=E2=80=99s take discussions to the alias

- Discuss the scope of work=C2=A0

=C2=A0

3. Other Info

Mailing list:=C2=A0IDEAS

List address:=C2=A0ideas@ietf.org

Archive:=C2=A0https://mailarchive.ietf.org/arch/s= earch/?email_list=3Dideas

To subscribe:=C2=A0https://www.ietf.org/mailman/listi= nfo/ideas

=C2=A0

--f403045f1638918848054d06e45a-- From nobody Thu Apr 13 02:35:33 2017 Return-Path: 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 38A7312EB88 for ; Thu, 13 Apr 2017 02:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jaf1N2442oVV for ; Thu, 13 Apr 2017 02:35:28 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2737129BC4 for ; Thu, 13 Apr 2017 02:35:26 -0700 (PDT) Received: from [134.2.11.131] (chaos.informatik.uni-tuebingen.de [134.2.11.131]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 21CFFBD41 for ; Thu, 13 Apr 2017 11:35:25 +0200 (CEST) To: ideas@ietf.org References: From: Michael Menth Message-ID: Date: Thu, 13 Apr 2017 11:35:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] IDEAS @IETF98 Minutes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:35:31 -0000 Thanks a lot for the minutes - very informative. Regards, Michael Am 13.04.2017 um 09:01 schrieb Padma Pillay-Esnault: > > > __ > > Please find below the minutes of the meeting.__ > > Many thanks to our two scribes: Toerless Eckert and Uma Chunduri.____ > > > If you have any comments/corrections please let us know. > > Thanks > > Padma____ > > > IDEAS Side Meeting Minutes > > > > 1. Slides > > Please find below a pointer to the slides > > https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=sharing > > > > > > 2. Agenda > > 2.1. Introduction and Problem Statement for IDEAS - Padma Pillay-Esnault > > > > https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-01.txt > > > > > IDEAS Introduction > > > > IDEAS aims to be the forum where common issues across all ID Enabled > Networks can be discussed. > > Goals: > > - to create awareness > > - to present the work proposed in IDEAS > > - A generic architecture that is scalable, extensible, robust, > secure, and flexible for future ID enabled networks > > - to sollicit comments and feedback from the community on the drafts > > - to call for new contributions > > > > Problem Statement > > Motivation: Why Now? > > ID solutions can address diverse areas > > IOT, M2M communication, Discovery, privacy, Latency, > Virtualization > > Beneficial to have standardized common infra across ID protocols > > > > Key Issues Identified > > Lack of common Infrastructure cause harder to deploy a common solution E2E > > - No Common Management due to disjoint nature > > - No Common/consistent policy framework > > - Risk of fragmented communication > > Identifier Lifecycle > > - No guidance or allocation scheme for public IDs > > - Agreed upon ID format and scope in cross-domain communication > > - Recycling IDs > > - Better address merging of networks > > Security of Mapping Systems > > - Secured access to the MS > > - data integrity, Confidentiality, Anonymity, Access control > > - DDOS attack prone > > > > Proposal > > - To investigate the opportunity of a new specification effort to > address some specific problems from an ID Enabled Networks perspective. > > - To find a common solution and infrastructure that can be shared > by current protocols and facilitate the introduction of new ID-based > services while avoiding rehashing the same problems again each time a > new service pops up > > - Generic Resilient ID Services (GRIDS) infrastructure with > standardized access and multiple services. The services include > > - secured registration > > - discovery > > - updates with data integrity, > > - mapping and resolution capabilities, > > - define relationships between IDs or group of IDs > > - access control policy and security > > - Other Related Work/ Groups > > - LISP (ALT, DDT) > > - HIP uses DNS > > - NVO3 WG > > > > Questions: > > Eric Nordmark: Whats unclear is what is out of scope re. Identifier. > Are you considering "what is an identifier", clearly this is not about > URI, how about IP in IP with IPsec ? Is one of them an identifier the > other one a locator. Even LISP was not clear cut between > locator/identifier as one could be routed locally. > > > > Padma Pillay-Esnault: Regarding scope, the way we thinking about this, > there can be multiple scopes with multiple allocation systems. The range > of solutions is so vast that it may not be appropriate to only have one > solution. Plenty options of where to put it and how to put. GRIDS can be > used as local, proximity, global instance just as possible to have > Private ID. > > > > Bob Moskovitz: Concept of Identity and Identifier is important and I > have been involved and saw some form of this for the last 20 years may > be more. It really does to be discussed in the list. Definitely it needs > to be fleshed out a lot more about > > what identifiers are, should be part of the work, tough problem with > lots of opinions. > > > > > > 2.2. Requirements for Generic Resilient Identity Services (GRIDS) > in IDEAS - Alex Clemm > > > > https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt > > > > - This is the core infrastructure document which captures all requirements > > - Talked on Core components of GRIDS > > - GRIDS-MS, GRIDS-IS are covered > > - Grouping and Meta data are not described yet > > - Identity and Identifier definitions elaborated > > - Talked in details about mapping services > > - Identity related services are detailed > > - Structured and unstructured identifiers > > - Grouping related services > > - Requirement (Distribution, Redundancy, Performance and Scale..) > > - Key performance requirements > > - Security requirements > > - GRIDS should be able to be deployed in private space as well as > in public domain > > > > - The naming evolved from mapping system, which was too functionally > constrained. > > > > Questions: > > Ravi Ravindran: Trying to understand scope: trying to expand LISP ? > > What is the scope ? > > > > Alex Clemm: No, not planning to just "expand lisp", that should be done > in LISP WG. Some of those questions are better answered in the use > cases, clear which ones are not resolved by LISP. > > > > Benjamin Damm: How is this different from Multicast DNS ? > > > > Bob Moskovitz: I can totally implement everything in GRIDS in DNS but > that would not be a great idea but there would be a lot of > > problems, DDoS, etc.. Think that metadata is not optional but must be > called mandatory. Determined by use case. > > > > Alex Clemm: Note taken > > > > Dino Farinacci: rfc8060 defines multiple RLOC types, eg: LISP can > support those. Does this look like multicast DNS ? No, this is network > layer mapping information mapping addresses to addresses. > > > > Eric Nordmark: Multicast DNS is a local service, this is meant to be global. > > > > > > 2.3. A Blockchain-based Mapping System - Jordi Paillisse > > - Blockchain is decentralized and secured > > - Add blocks of data one after other > > - Blockchain work flow > > - Transaction with a data, Senders Signature and Senders Public Key > to a P2P network > > - Properties > > - Decentralized, No prior trust is required > > Data can be added but not modifiable > > - Basic Idea > > - Store mappings in blockchain > > - EID prefixes are distributed to all participants > > - Pros and Cons > > - Infrastructure less, Decentralized, fast lookup, secure, no > prior trust, simple rekeying > > - Cons > > - Slow updates, costly boot strapping > > - Comparison with LISP DDT > > - No Infra, easy management > > - Issues with RPKI > > - Anonymity (prefix linked to owner name) > > - Revocation issues (block chain doesnt use certificates) > > - Scalability > > - Growth similar to BGP Churn > > - Prefix delegation + Mappings > > - Design considerations > > - Bitcoin is too restrictive > > - New technologies - More scalable and more contracts > > - Dedicated chains.. > > > > Questions: > > Toerless Eckert: what is the incentive model for participants to deploy > the necessary infrastructure for this system ? In bitcoin, the security > is achieved through tremendous amount of calculation, the cost for that > hardware is financed by handing out bitcoins for successful > calculations. Do we need to hand out IPv4 addresses to pay > for IDEAS bitchain calculations ? > > > > Jordi Paillisee: Good question, there are some new blockchain methods > with other incentive structures. See references on last slide of the > slide deck. > > Regarding incentive it is about security. > > > > Dino Farinacci: > > When a new registration added (Say Jordi first and then 100000 more > records added. Now the entry moved to the end. This solution will have > > complete history of movements. Q1: can the really old stuff be chopped > off. Q2: if RLOCs change etc. is it not really slow when you need to > look through a lot of other newer mappings ? > > Jordi Paillisee : Q1 Answer: It can be mitigated through implementation > > Q2 answer: implementation detail. Database should have latest data for > all entities, not in sequential order of evens. > > > > Manu Sporny: Blockchain developer. Referring to blockchain group > (w3c-blockain group) met in the morning, sees overlap with that work, > how could we create alignment. Whom to talk to coordinate ? > > Padma Pillay-Esnault: Lets discuss this offline. > > > > 2.4. Use Cases for IDEAS - Tom Herbert > > https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt > > > > - Mapping essentially a distributed key/value store > > - Key is fixed size per mapping DB > > - Maps "virtual address" to "physical address" > > - Mapping table is assumed to be distributed and possibly shared > for load > > - Rate of entry is important characteristic > > > > - Use Cases: > > - Common Control plane > > - Mobility > > - Network Virtualization (for network simplification) > > - Heterogeneous Multi-Access (hetnet) > > - Security > > - Device Discovery > > - Mobility > > - Map entity to its current location for forwarding > > - Variants > > - Encap: IP Mobility, IPIP, GTP etc.. > > - ID/LOC: LISP, ILA > > - Properties > > - Mobility sub-cases > > - Within a single mobile network > > - Mobility between mobile networks > > - Multi-homed devices > > - Hetnet environments > > - Whole networks are mobile (WIFI in bus) > > - Network Virtualization > > - Variants > > - Encap: Map virtual IP address to Physical address > > - ID/LOC split > > - Properties > > - Mostly in DC > > - Address resolution static tunnels > > - Could be used as alternative means to resolve L2/L3 > > - Host Routes > > - A network could implement virtualization simply by creating > a host route > > > > Questions: > > Bob Moskovitz: We have been mobile since 1993. We need to start looking > at mobility as baseline. Would almost challenge in discussion the > starting point. Take rate of mobility (how fast it can move) as > distinguishing attribute. > > > > Tom Herbert: Agree. How quickly is my "device" going from one network to > another. With higher rate, updates become a problem. Also get more and > more use cases where latency becomes an issue. Hope we could avoid > relying on a distributed system. Control path is critical system, > keeping everything in sync with low latency and secure, reliable, > available. Can we design this system with applicability across different > use cases. > > > > Mike McBride: There are applications like AR/VR that have strict > requirements hopefully, that is also included in use cases. > > > > Tom Herbert: Yes this has been discussed in the draft. > > > > Padma Pillay-Esnault: Yes there different strict requirements depending > on the different use cases. Earlier there was a question regarding IOT > use cases. The requirements may vary for example depending if the type > of IOT device. If it battery operated (supposed to last 10 years) then > it may have only one way communication (such as a pet tracker or sensor) > and may even be on non-IP. In some cases proximity and context may be > important too. > > > > 2.5. Mobility First and Global Name Resolution Service - Parishad Karimi > > https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt > > > > -Name based communications > > - Name based Architectures IP ==> LISP, HIP at IETF MF and NDN (in > academia) > > - MF - Mobility First Background > > - MF started in 2010 under NSF, FIA > > - MF Protocol Layers > > - GUID (global Unique Identifiers) > > - We seek to use global name resolution system for resolution > > - Name Resolution Requirements > > - Low propagation and response Latency > > - Storage and load scalability > > - Security and reliability > > - Extensibility and flexibility > > - Structure of mapping should not be limited > > - Why cant DNS can be supported (DNS Deficiencies) > > - TTL based caching > > - High Mobility makes caching ineffective > > - Static Placement of AUTH Servers > > - Reliance on hierarchal (relating root) > > - For MF we have looked into DMAP and GMAP and Auspice > > - Comparison of all three systems > > - Conclusion - We need a global mapping system with MF project > > > > > > 2.6 Conclusion & Next steps - Padma Pillay-Esnault > > Where do we want to go from here ? > > Next Steps Slide: > > - We need more collaboration from the community and looking forward for > more participation on topics such as Blockchain and distributed trust, > Late binding, Fast Caching, Security, DDOS protection .... > > > > - Lets take discussions to the alias > > - Discuss the scope of work > > > > 3. Other Info > > Mailing list: IDEAS > > List address: ideas@ietf.org > > Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas > > To subscribe: https://www.ietf.org/mailman/listinfo/ideas > > > > > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Apr 13 16:58:20 2017 Return-Path: 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 763F91276AF for ; Thu, 13 Apr 2017 16:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VSiB7P0z_ZfN for ; Thu, 13 Apr 2017 16:58:16 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FC2126579 for ; Thu, 13 Apr 2017 16:58:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BEA366239C for ; Thu, 13 Apr 2017 19:58:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t3eWe2AtH+Je for ; Thu, 13 Apr 2017 19:58:11 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id AB0926239B for ; Thu, 13 Apr 2017 19:58:08 -0400 (EDT) To: ideas@ietf.org References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Thu, 13 Apr 2017 19:58:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 23:58:18 -0000 I am finally getting back to this subject. On 03/28/2017 12:07 PM, Robert Moskowitz wrote: > The Identifier/Identity definitions in > draft-padma-ideas-problem-statement-01.txt is a good start, it fails > in the appreviations used. (There is NO abbreviation for Identity!) > > ID should NOT be the appreviation of Identitfier. People will default > to thinking 'Identity' when they see it. Think about people outside > our discussion group. > > I propose 'IDf' for Identifier. 'ID' is too owned by Identity. > > I will be working on proposed wording to improve these definitions. I have worked up definitions, sent it out to a few reviewers, got some comments and questions. First my current draft, then a few questions: Replacement text for: draft-padma-ideas-problem-statement Identity (Abbr: IDT or IDt): A collection of information that is unique to an object and differentiates it from all other objects. An identity consists of information that is stated about the object by itself or a governing authority. It consists of a set of attributes and/or actions the object can take. An Identity may be assigned a lifetime (e.g., a time period), which is determined by either the object or the governing authority responsible for defining the identity of the object, or a designated third party. An object can have multiple Identities and can create and discard Identities at will. An Identity may be indestructible. That is, it is so unique and non replicatible that no other object could ever duplicate it, nor can the object discard it within its lifetime without being a clone object. Identity is used in authentication registration and policy ownership proofs. Identifier (Abbr: IDF or IDf): A label that is unique for an object a particular scope. The label follows strict construction rules for the objects and the context that the label is applied to. For a particular context, an Identifier is used to reference an Identity for the object. In most cases, an Identifier is bound to an Identity through some trusted mechanism. An Identity can have different Identifiers, potentially following different construction rules, for different contexts and/or domains of applicability. ========== Now onto a few questions: Per: "An object can have multiple Identities" clause, I am challenged with "This is VERY dangerous. In most software systems, it is the responsibility of the management system to assign a single identity to an object when it is created. If an object has multiple identities, it could suffer from 'multiple personality syndrome'. More importantly, if the object is allowed to create and discard identities at will, how do other objects know that the object is who it attests to be?" I think it is very important for some situations for support of multiple Identities. No all. There are domains as indicated above where it causes big problems. Per: "An Identity may be indestructible." clause, I am challenged with "This doesnt make any sense. Why would anyone care if the identity is indestructible or not?" I can think of examples of such Identities, or claim of such Identities, like DNA. And finally, Per: "Identity is used in authentication registration and policy ownership proofs." clause, I am challenged with "What does this mean?" I will have to work on this some more, or perhaps it does not belong in the definition section. Comments please From nobody Thu Apr 13 23:29:21 2017 Return-Path: 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 9DA9E1293E3 for ; Thu, 13 Apr 2017 23:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 HWxvdFSkkB2B for ; Thu, 13 Apr 2017 23:29:17 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 005DF127011 for ; Thu, 13 Apr 2017 23:29:16 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id t189so60122202wmt.1 for ; Thu, 13 Apr 2017 23:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uNwriZMZbmIiaBlgNl3iHwk/WhPxq7fd8v7xVzJnFsY=; b=OOF50gt91/QJHKM4HtGU6O/VT0hMSFI0AilZdFsg6ZZg5cRchnWdbujEl7l0vsaZfZ wHMTT1x++JsYq23HTRPhFbLmGbgiPGW1K0uof0pYmhs23/+hcJEByWjV54EFFeA5aA9p lIk25cetVzXEikht4viBqdG0Rg7HDy9eaUnJ0uFllWesXvrOf1G1vcYpMgt1MGL1ZPBP 3gJWlslC7jfsFy7Xpzwb25lqe8hbXdZSc8aWwYrDIYJlxKUmXwYsGT3nXvopGfbwBbRf WdZjxSMOtxY3KZuX0EJFm0pznP+qEfmldwrgt5Wtyoxm9k2597mzcYtAtiBIiWkJDrab Gl9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uNwriZMZbmIiaBlgNl3iHwk/WhPxq7fd8v7xVzJnFsY=; b=ugs+941dB4pwWRuK7PR73pcZ+qRHQxyVvnXVRB5eMPRph82M3d67nIm4m4/pVcX8w+ x6r8Nki9F8kxHJ2Gd+GaZiLv8/aqi5DGuArBMVe6l6DmU7eAuaePk+8Df6F6ZrLsU5Kx OdfaYwQfkFCPU8NfxGzwECZHkUIjQbzBqafjpA8+2GPLicD2ztl3DFZNmp15gKe4RlsH pm4aOM44ckkTLZt0AWPCOzO9QCiZ2jgFVe6DhXu89xPUc1DgVRIifPoHobOq1KkNgplI hzO3gmPuxFBk7GpGxzQ+/V6ilaYPzUkuWHKXUElZY8Le+MQI31TlUg/38psZg/1/RT8+ q09g== X-Gm-Message-State: AN3rC/7nS4JMAVp8u3vdM/MgCQ0s9RsPa0WD3v8seiydC7Vu9CEtYk/g QCLKdqQxvoyGBGCNay/xXKsYEhPzTA== X-Received: by 10.28.157.84 with SMTP id g81mr22679180wme.120.1492151355199; Thu, 13 Apr 2017 23:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.167.67 with HTTP; Thu, 13 Apr 2017 23:29:14 -0700 (PDT) In-Reply-To: References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> From: Padma Pillay-Esnault Date: Thu, 13 Apr 2017 23:29:14 -0700 Message-ID: To: Robert Moskowitz Cc: ideas@ietf.org, Padma Pillay-Esnault Content-Type: multipart/alternative; boundary=001a114ba0227a57d3054d1a8f9c Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 06:29:20 -0000 --001a114ba0227a57d3054d1a8f9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Robert I have a few comments See below On Thu, Apr 13, 2017 at 4:58 PM, Robert Moskowitz wrote: > I am finally getting back to this subject. > > > On 03/28/2017 12:07 PM, Robert Moskowitz wrote: > >> The Identifier/Identity definitions in draft-padma-ideas-problem-stateme= nt-01.txt >> is a good start, it fails in the appreviations used. (There is NO >> abbreviation for Identity!) >> >> ID should NOT be the appreviation of Identitfier. People will default t= o >> thinking 'Identity' when they see it. Think about people outside our >> discussion group. >> >> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >> >> I will be working on proposed wording to improve these definitions. >> > > I have worked up definitions, sent it out to a few reviewers, got some > comments and questions. First my current draft, then a few questions: > > Replacement text for: draft-padma-ideas-problem-statement > > Identity (Abbr: IDT or IDt): A collection of information that is uniqu= e > to an object and differentiates it from all other objects. > Would prefer entity to object in keeping of the definition in the draft. > > An identity consists of information that is stated about the object by > itself or a governing authority. It consists of a set of attributes and/o= r > actions the object can take. An Identity may be assigned a lifetime (e.g= ., > a time period), which is determined by either the object or the governing > authority responsible for defining the identity of the object, or a > designated third party. An object can have multiple Identities and can > create and discard Identities at will. An Identity may be > =E2=80=98indestructible=E2=80=99. That is, it is so unique and non replic= atible that no > other object could ever duplicate it, nor can the object discard it withi= n > its lifetime without being a =E2=80=98clone=E2=80=99 object. Identity is= used in > authentication registration and policy ownership proofs. > > Can we infer than an identity may apply to a group of entities? I think this is an important aspect not sure the text above reflects that. > > Identifier (Abbr: IDF or IDf): A label that is unique for an object a > particular scope. > > The label follows strict construction rules for the objects and the > context that the label is applied to. For a particular context, an > Identifier is used to reference an Identity for the object. In most case= s, > an Identifier is bound to an Identity through some trusted mechanism. An > Identity can have different Identifiers, potentially following different > construction rules, for different contexts and/or domains of applicabilit= y. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Now onto a few questions: > > Per: "An object can have multiple Identities" clause, I am challenged wit= h > > "This is VERY dangerous. In most software systems, it is the > responsibility of the management system to assign a single identity to an > object when it is created. If an object has multiple identities, it could > suffer from 'multiple personality syndrome'. > > I tend to agree with you I would prefer one identity but multiple identifiers. > More importantly, if the object is allowed to create and discard > identities at will, how do other objects know that the object is who it > attests to be?" > > this is where I think there should always be a Permanent identity which sticks but it can take aliases but those are bound to the permanent one. > I think it is very important for some situations for support of multiple > Identities. No all. There are domains as indicated above where it cause= s > big problems. > > Per: "An Identity may be =E2=80=98indestructible=E2=80=99." clause, I am = challenged with > Reading the definition above I felt we should be very careful how to implement this and in what circumstance. My read is that this is a permanent identity. > > "This doesn=E2=80=99t make any sense. Why would anyone care if the identi= ty is > indestructible or not?" > > I can think of examples of such Identities, or claim of such Identities, > like DNA. > > And finally, Per: "Identity is used in authentication registration and > policy ownership proofs." clause, I am challenged with > > "What does this mean?" > > the objective here to have a mechanism where an entity has a means to prove that it is what it is supposed to be and prevent hijacking of its identity. > I will have to work on this some more, or perhaps it does not belong in > the definition section. > > Comments please > > There are important definitions and thanks for taking a stab at this Padma > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > --001a114ba0227a57d3054d1a8f9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert=C2=A0

I have a few comments= =C2=A0

See below <PPE>

On Thu, Apr 13, 2017 at 4:58 PM, = Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
I am finally getting back to this subject.<= span class=3D"">


On 03/28/2017 12:07 PM, Robert Moskowitz wrote:
The Identifier/Identity definitions in draft-padma-ideas-problem-state= ment-01.txt is a good start, it fails in the appreviations used. (There is = NO abbreviation for Identity!)

ID should NOT be the appreviation of Identitfier.=C2=A0 People will default= to thinking 'Identity' when they see it.=C2=A0 Think about people = outside our discussion group.

I propose 'IDf' for Identifier.=C2=A0 'ID' is too owned by = Identity.

I will be working on proposed wording to improve these definitions.

I have worked up definitions, sent it out to a few reviewers, got some comm= ents and questions.=C2=A0 First my current draft, then a few questions:

Replacement text for:=C2=A0 =C2=A0 draft-padma-ideas-problem-statement=

Identity (Abbr: IDT or IDt):=C2=A0 =C2=A0 A collection of information that = is unique to an object and differentiates it from all other objects.

<PPE> Would prefer entity to object in = keeping of the definition in the draft.=C2=A0

An identity consists of information that is stated about the object by itse= lf or a governing authority. It consists of a set of attributes and/or acti= ons the object can take.=C2=A0 An Identity may be assigned a lifetime (e.g.= , a time period), which is determined by either the object or the governing= authority responsible for defining the identity of the object, or a design= ated third party. An object can have multiple Identities and can create and= discard Identities at will.=C2=A0 An Identity may be =E2=80=98indestructib= le=E2=80=99. That is, it is so unique and non replicatible that no other ob= ject could ever duplicate it, nor can the object discard it within its life= time without being a =E2=80=98clone=E2=80=99 object.=C2=A0 Identity is used= in authentication registration and policy ownership proofs.

<PPE> Can we infer than an identity may apply t= o a group of entities? I think this is an important aspect not sure the tex= t above reflects that.
=C2=A0

Identifier (Abbr: IDF or IDf):=C2=A0 =C2=A0 A label that is unique for an o= bject a particular scope.

The label follows strict construction rules for the objects and the context= that the label is applied to.=C2=A0 For a particular context, an Identifie= r is used to reference an Identity for the object.=C2=A0 In most cases, an = Identifier is bound to an Identity through some trusted mechanism.=C2=A0 An= Identity can have different Identifiers, potentially following different c= onstruction rules, for different contexts and/or domains of applicability.<= br>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Now onto a few questions:

Per: "An object can have multiple Identities" clause, I am challe= nged with

"This is VERY dangerous. In most software systems, it is the responsib= ility of the management system to assign a single identity to an object whe= n it is created. If an object has multiple identities, it could suffer from= 'multiple personality syndrome'.

<PPE> I tend to agree with you I would prefer o= ne identity but multiple identifiers.
=C2=A0
More importantly, if the object is allowed to create and discard identities= at will, how do other objects know that the object is who it attests to be= ?"

<PPE> this is where I think there should always= be a Permanent identity which sticks but it can take aliases but those are= bound to the permanent one.
=C2=A0
I think it is very important for some situations for support of multiple Id= entities.=C2=A0 No all.=C2=A0 There are domains as indicated above where it= causes big problems.

Per: "An Identity may be =E2=80=98indestructible=E2=80=99." claus= e, I am challenged with

<PPE> =C2= =A0Reading the definition above I felt we should be very careful how to imp= lement this and in what circumstance. My read is that this is a permanent i= dentity.

"This doesn=E2=80=99t make any sense. Why would anyone care if the ide= ntity is indestructible or not?"

I can think of examples of such Identities, or claim of such Identities, li= ke DNA.

And finally, Per: "Identity is used in authentication registration and= policy ownership proofs." clause, I am challenged with

"What does this mean?"

<PPE> the objective here to have a mechanism wh= ere an entity has a means to prove that it is what it is supposed to be and= prevent hijacking of its identity.
=C2=A0
I will have to work on this some more, or perhaps it does not belong in the= definition section.

Comments please


<PPE> There are important definitions an= d thanks for taking a stab at this

Padma=C2=A0

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas

--001a114ba0227a57d3054d1a8f9c-- From nobody Thu Apr 13 23:46:27 2017 Return-Path: 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 C171912786A for ; Thu, 13 Apr 2017 23:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Hbfv1Fs60q4L for ; Thu, 13 Apr 2017 23:46:22 -0700 (PDT) Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.5.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617E3127BA3 for ; Thu, 13 Apr 2017 23:46:20 -0700 (PDT) Received: from [192.168.1.101] (hsi-kbw-5-56-217-255.hsi17.kabel-badenwuerttemberg.de [5.56.217.255]) by mx03.uni-tuebingen.de (Postfix) with ESMTPSA id 722F983C9E for ; Fri, 14 Apr 2017 08:46:18 +0200 (CEST) To: ideas@ietf.org References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> From: Michael Menth Message-ID: <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> Date: Fri, 14 Apr 2017 08:45:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 06:46:26 -0000 Hi Robert, hi all, thanks for your thought-provoking mail. Reading the definitions gave me the impression that identities can have very different properties depending on their domains. I feel the text is stimulating but too long for a definition. What about: An identity (Idy) is a distinguishable entity within its domain. An identifier (Idf) is a label for an Idy. An Idy may have multiple Idfs. Anything beyond this definition are valid observations that show the diverse properties of domain-specific Idys. A discussion including examples for entities and domains is helpful for illustration. This also pertains to the relation between objects and Idys. Regards, Michael Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: > I am finally getting back to this subject. > > > On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >> The Identifier/Identity definitions in >> draft-padma-ideas-problem-statement-01.txt is a good start, it fails >> in the appreviations used. (There is NO abbreviation for Identity!) >> >> ID should NOT be the appreviation of Identitfier. People will default >> to thinking 'Identity' when they see it. Think about people outside >> our discussion group. >> >> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >> >> I will be working on proposed wording to improve these definitions. > > I have worked up definitions, sent it out to a few reviewers, got some > comments and questions. First my current draft, then a few questions: > > Replacement text for: draft-padma-ideas-problem-statement > > Identity (Abbr: IDT or IDt): A collection of information that is > unique to an object and differentiates it from all other objects. > > An identity consists of information that is stated about the object by > itself or a governing authority. It consists of a set of attributes > and/or actions the object can take. An Identity may be assigned a > lifetime (e.g., a time period), which is determined by either the object > or the governing authority responsible for defining the identity of the > object, or a designated third party. An object can have multiple > Identities and can create and discard Identities at will. An Identity > may be indestructible. That is, it is so unique and non replicatible > that no other object could ever duplicate it, nor can the object discard > it within its lifetime without being a clone object. Identity is used > in authentication registration and policy ownership proofs. > > > Identifier (Abbr: IDF or IDf): A label that is unique for an object a > particular scope. > > The label follows strict construction rules for the objects and the > context that the label is applied to. For a particular context, an > Identifier is used to reference an Identity for the object. In most > cases, an Identifier is bound to an Identity through some trusted > mechanism. An Identity can have different Identifiers, potentially > following different construction rules, for different contexts and/or > domains of applicability. > > > ========== > > Now onto a few questions: > > Per: "An object can have multiple Identities" clause, I am challenged with > > "This is VERY dangerous. In most software systems, it is the > responsibility of the management system to assign a single identity to > an object when it is created. If an object has multiple identities, it > could suffer from 'multiple personality syndrome'. > > More importantly, if the object is allowed to create and discard > identities at will, how do other objects know that the object is who it > attests to be?" > > I think it is very important for some situations for support of multiple > Identities. No all. There are domains as indicated above where it > causes big problems. > > Per: "An Identity may be indestructible." clause, I am challenged with > > "This doesnt make any sense. Why would anyone care if the identity is > indestructible or not?" > > I can think of examples of such Identities, or claim of such Identities, > like DNA. > > And finally, Per: "Identity is used in authentication registration and > policy ownership proofs." clause, I am challenged with > > "What does this mean?" > > I will have to work on this some more, or perhaps it does not belong in > the definition section. > > Comments please > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Fri Apr 14 05:40:35 2017 Return-Path: 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 E162712EC3D for ; Fri, 14 Apr 2017 05:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gKkualiVOoiP for ; Fri, 14 Apr 2017 05:40:31 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2378612EC3A for ; Fri, 14 Apr 2017 05:40:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 417E762394; Fri, 14 Apr 2017 08:40:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2Sv2vQFWD6iM; Fri, 14 Apr 2017 08:40:23 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A797B62391; Fri, 14 Apr 2017 08:40:23 -0400 (EDT) To: Michael Menth , ideas@ietf.org References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> From: Robert Moskowitz Message-ID: Date: Fri, 14 Apr 2017 08:40:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 12:40:34 -0000 On 04/14/2017 02:45 AM, Michael Menth wrote: > Hi Robert, hi all, > > thanks for your thought-provoking mail. Reading the definitions gave me > the impression that identities can have very different properties > depending on their domains. I feel the text is stimulating but too long > for a definition. Good point. After 20+ years of working on Identity vs Identifier, it is hard for me to reduce the discussion down to a concise paragraph. I have seen too many domains of applicabilty to say, "this can't be so." Plus as the originator of self-proving ownership of an Identity with domain-specific statistically unique Identifiers, I have argued all sides of this subject. > What about: > > An identity (Idy) is a distinguishable entity within its domain. > > An identifier (Idf) is a label for an Idy. An Idy may have multiple > Idfs. > > Anything beyond this definition are valid observations that show the > diverse properties of domain-specific Idys. A discussion including > examples for entities and domains is helpful for illustration. This also > pertains to the relation between objects and Idys. And then have a section that goes a little in depth on Identity and Identifier. A can work with that. > > Regards, > > Michael > > Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: >> I am finally getting back to this subject. >> >> >> On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >>> The Identifier/Identity definitions in >>> draft-padma-ideas-problem-statement-01.txt is a good start, it fails >>> in the appreviations used. (There is NO abbreviation for Identity!) >>> >>> ID should NOT be the appreviation of Identitfier. People will default >>> to thinking 'Identity' when they see it. Think about people outside >>> our discussion group. >>> >>> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >>> >>> I will be working on proposed wording to improve these definitions. >> I have worked up definitions, sent it out to a few reviewers, got some >> comments and questions. First my current draft, then a few questions: >> >> Replacement text for: draft-padma-ideas-problem-statement >> >> Identity (Abbr: IDT or IDt): A collection of information that is >> unique to an object and differentiates it from all other objects. >> >> An identity consists of information that is stated about the object by >> itself or a governing authority. It consists of a set of attributes >> and/or actions the object can take. An Identity may be assigned a >> lifetime (e.g., a time period), which is determined by either the object >> or the governing authority responsible for defining the identity of the >> object, or a designated third party. An object can have multiple >> Identities and can create and discard Identities at will. An Identity >> may be indestructible. That is, it is so unique and non replicatible >> that no other object could ever duplicate it, nor can the object discard >> it within its lifetime without being a clone object. Identity is used >> in authentication registration and policy ownership proofs. >> >> >> Identifier (Abbr: IDF or IDf): A label that is unique for an object a >> particular scope. >> >> The label follows strict construction rules for the objects and the >> context that the label is applied to. For a particular context, an >> Identifier is used to reference an Identity for the object. In most >> cases, an Identifier is bound to an Identity through some trusted >> mechanism. An Identity can have different Identifiers, potentially >> following different construction rules, for different contexts and/or >> domains of applicability. >> >> >> ========== >> >> Now onto a few questions: >> >> Per: "An object can have multiple Identities" clause, I am challenged with >> >> "This is VERY dangerous. In most software systems, it is the >> responsibility of the management system to assign a single identity to >> an object when it is created. If an object has multiple identities, it >> could suffer from 'multiple personality syndrome'. >> >> More importantly, if the object is allowed to create and discard >> identities at will, how do other objects know that the object is who it >> attests to be?" >> >> I think it is very important for some situations for support of multiple >> Identities. No all. There are domains as indicated above where it >> causes big problems. >> >> Per: "An Identity may be indestructible." clause, I am challenged with >> >> "This doesnt make any sense. Why would anyone care if the identity is >> indestructible or not?" >> >> I can think of examples of such Identities, or claim of such Identities, >> like DNA. >> >> And finally, Per: "Identity is used in authentication registration and >> policy ownership proofs." clause, I am challenged with >> >> "What does this mean?" >> >> I will have to work on this some more, or perhaps it does not belong in >> the definition section. >> >> Comments please >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas From nobody Fri Apr 14 11:27:09 2017 Return-Path: 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 7EE431294AC for ; Fri, 14 Apr 2017 11:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 S9ul7GRGKYra for ; Fri, 14 Apr 2017 11:27:04 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C273F12785F for ; Fri, 14 Apr 2017 11:27:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id F157062401; Fri, 14 Apr 2017 14:27:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fbzVgmjnOiMA; Fri, 14 Apr 2017 14:26:57 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1BF4762369; Fri, 14 Apr 2017 14:26:57 -0400 (EDT) To: Michael Menth , ideas@ietf.org References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> From: Robert Moskowitz Message-ID: Date: Fri, 14 Apr 2017 14:26:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:27:08 -0000 On 04/14/2017 02:45 AM, Michael Menth wrote: > Hi Robert, hi all, > > thanks for your thought-provoking mail. Reading the definitions gave me > the impression that identities can have very different properties > depending on their domains. I feel the text is stimulating but too long > for a definition. > > What about: > > An identity (Idy) is a distinguishable entity within its domain. > > An identifier (Idf) is a label for an Idy. An Idy may have multiple > Idfs. An identity (Idy) is a collection of data that distinguishes an entity within its domain. An entity may have different Idy for different domains. An identifier (Idf) is a label for an Idy, often following construction rules. An Idy may have multiple Idfs. > > Anything beyond this definition are valid observations that show the > diverse properties of domain-specific Idys. A discussion including > examples for entities and domains is helpful for illustration. This also > pertains to the relation between objects and Idys. > > Regards, > > Michael > > Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: >> I am finally getting back to this subject. >> >> >> On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >>> The Identifier/Identity definitions in >>> draft-padma-ideas-problem-statement-01.txt is a good start, it fails >>> in the appreviations used. (There is NO abbreviation for Identity!) >>> >>> ID should NOT be the appreviation of Identitfier. People will default >>> to thinking 'Identity' when they see it. Think about people outside >>> our discussion group. >>> >>> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >>> >>> I will be working on proposed wording to improve these definitions. >> I have worked up definitions, sent it out to a few reviewers, got some >> comments and questions. First my current draft, then a few questions: >> >> Replacement text for: draft-padma-ideas-problem-statement >> >> Identity (Abbr: IDT or IDt): A collection of information that is >> unique to an object and differentiates it from all other objects. >> >> An identity consists of information that is stated about the object by >> itself or a governing authority. It consists of a set of attributes >> and/or actions the object can take. An Identity may be assigned a >> lifetime (e.g., a time period), which is determined by either the object >> or the governing authority responsible for defining the identity of the >> object, or a designated third party. An object can have multiple >> Identities and can create and discard Identities at will. An Identity >> may be indestructible. That is, it is so unique and non replicatible >> that no other object could ever duplicate it, nor can the object discard >> it within its lifetime without being a clone object. Identity is used >> in authentication registration and policy ownership proofs. >> >> >> Identifier (Abbr: IDF or IDf): A label that is unique for an object a >> particular scope. >> >> The label follows strict construction rules for the objects and the >> context that the label is applied to. For a particular context, an >> Identifier is used to reference an Identity for the object. In most >> cases, an Identifier is bound to an Identity through some trusted >> mechanism. An Identity can have different Identifiers, potentially >> following different construction rules, for different contexts and/or >> domains of applicability. >> >> >> ========== >> >> Now onto a few questions: >> >> Per: "An object can have multiple Identities" clause, I am challenged with >> >> "This is VERY dangerous. In most software systems, it is the >> responsibility of the management system to assign a single identity to >> an object when it is created. If an object has multiple identities, it >> could suffer from 'multiple personality syndrome'. >> >> More importantly, if the object is allowed to create and discard >> identities at will, how do other objects know that the object is who it >> attests to be?" >> >> I think it is very important for some situations for support of multiple >> Identities. No all. There are domains as indicated above where it >> causes big problems. >> >> Per: "An Identity may be indestructible." clause, I am challenged with >> >> "This doesnt make any sense. Why would anyone care if the identity is >> indestructible or not?" >> >> I can think of examples of such Identities, or claim of such Identities, >> like DNA. >> >> And finally, Per: "Identity is used in authentication registration and >> policy ownership proofs." clause, I am challenged with >> >> "What does this mean?" >> >> I will have to work on this some more, or perhaps it does not belong in >> the definition section. >> >> Comments please >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas From nobody Fri Apr 14 11:35:20 2017 Return-Path: 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 3932112953E for ; Fri, 14 Apr 2017 11:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EogdP5eyWx_I for ; Fri, 14 Apr 2017 11:35:16 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AF5129535 for ; Fri, 14 Apr 2017 11:35:16 -0700 (PDT) Received: from [192.168.1.101] (hsi-kbw-5-56-217-255.hsi17.kabel-badenwuerttemberg.de [5.56.217.255]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id DBE7D57C33; Fri, 14 Apr 2017 20:35:14 +0200 (CEST) To: Robert Moskowitz , ideas@ietf.org References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> From: Michael Menth Message-ID: Date: Fri, 14 Apr 2017 20:34:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:35:19 -0000 Looks good to me. Michael Am 14.04.2017 um 20:26 schrieb Robert Moskowitz: > > > On 04/14/2017 02:45 AM, Michael Menth wrote: >> Hi Robert, hi all, >> >> thanks for your thought-provoking mail. Reading the definitions gave me >> the impression that identities can have very different properties >> depending on their domains. I feel the text is stimulating but too long >> for a definition. >> >> What about: >> >> An identity (Idy) is a distinguishable entity within its domain. >> >> An identifier (Idf) is a label for an Idy. An Idy may have multiple >> Idfs. > > An identity (Idy) is a collection of data that distinguishes an entity > within its domain. An entity may have different Idy for different domains. > > An identifier (Idf) is a label for an Idy, often following construction > rules. An Idy may have multiple Idfs. > > >> >> Anything beyond this definition are valid observations that show the >> diverse properties of domain-specific Idys. A discussion including >> examples for entities and domains is helpful for illustration. This also >> pertains to the relation between objects and Idys. >> >> Regards, >> >> Michael >> >> Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: >>> I am finally getting back to this subject. >>> >>> >>> On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >>>> The Identifier/Identity definitions in >>>> draft-padma-ideas-problem-statement-01.txt is a good start, it fails >>>> in the appreviations used. (There is NO abbreviation for Identity!) >>>> >>>> ID should NOT be the appreviation of Identitfier. People will default >>>> to thinking 'Identity' when they see it. Think about people outside >>>> our discussion group. >>>> >>>> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >>>> >>>> I will be working on proposed wording to improve these definitions. >>> I have worked up definitions, sent it out to a few reviewers, got some >>> comments and questions. First my current draft, then a few questions: >>> >>> Replacement text for: draft-padma-ideas-problem-statement >>> >>> Identity (Abbr: IDT or IDt): A collection of information that is >>> unique to an object and differentiates it from all other objects. >>> >>> An identity consists of information that is stated about the object by >>> itself or a governing authority. It consists of a set of attributes >>> and/or actions the object can take. An Identity may be assigned a >>> lifetime (e.g., a time period), which is determined by either the object >>> or the governing authority responsible for defining the identity of the >>> object, or a designated third party. An object can have multiple >>> Identities and can create and discard Identities at will. An Identity >>> may be indestructible. That is, it is so unique and non replicatible >>> that no other object could ever duplicate it, nor can the object discard >>> it within its lifetime without being a clone object. Identity is used >>> in authentication registration and policy ownership proofs. >>> >>> >>> Identifier (Abbr: IDF or IDf): A label that is unique for an object a >>> particular scope. >>> >>> The label follows strict construction rules for the objects and the >>> context that the label is applied to. For a particular context, an >>> Identifier is used to reference an Identity for the object. In most >>> cases, an Identifier is bound to an Identity through some trusted >>> mechanism. An Identity can have different Identifiers, potentially >>> following different construction rules, for different contexts and/or >>> domains of applicability. >>> >>> >>> ========== >>> >>> Now onto a few questions: >>> >>> Per: "An object can have multiple Identities" clause, I am challenged >>> with >>> >>> "This is VERY dangerous. In most software systems, it is the >>> responsibility of the management system to assign a single identity to >>> an object when it is created. If an object has multiple identities, it >>> could suffer from 'multiple personality syndrome'. >>> >>> More importantly, if the object is allowed to create and discard >>> identities at will, how do other objects know that the object is who it >>> attests to be?" >>> >>> I think it is very important for some situations for support of multiple >>> Identities. No all. There are domains as indicated above where it >>> causes big problems. >>> >>> Per: "An Identity may be indestructible." clause, I am challenged with >>> >>> "This doesnt make any sense. Why would anyone care if the identity is >>> indestructible or not?" >>> >>> I can think of examples of such Identities, or claim of such Identities, >>> like DNA. >>> >>> And finally, Per: "Identity is used in authentication registration and >>> policy ownership proofs." clause, I am challenged with >>> >>> "What does this mean?" >>> >>> I will have to work on this some more, or perhaps it does not belong in >>> the definition section. >>> >>> Comments please >>> >>> _______________________________________________ >>> Ideas mailing list >>> Ideas@ietf.org >>> https://www.ietf.org/mailman/listinfo/ideas > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Mon Apr 24 17:49:16 2017 Return-Path: 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 A28C3131987 for ; Mon, 24 Apr 2017 17:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1CbSyHOOI31u for ; Mon, 24 Apr 2017 17:49:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F50131986 for ; Mon, 24 Apr 2017 17:49:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLR50238; Tue, 25 Apr 2017 00:49:04 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Apr 2017 01:49:01 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Mon, 24 Apr 2017 17:48:53 -0700 From: Alexander Clemm To: Michael Menth , Robert Moskowitz , "ideas@ietf.org" Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp916fQ6Ay+5HYEmqQas6XmYXz6HEiTEAgABx9QCAAMPZAIAAAjuAgA+nLqA= Date: Tue, 25 Apr 2017 00:48:51 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.12] 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.0A020206.58FE9D01.011F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5271462e6ccc4de9b0f102f77736dfd Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 00:49:15 -0000 Coming back to this thread... I do agree with the notion of identifier. Ho= wever, I am not sure I agree with the notion of identity as discussed below= . When you state "An identity (Idy) is a collection of data that distinguishe= s an entity within its domain. An entity may have different Idy for differ= ent domains.", I see several issues: - For one I don't think an identity is merely a collection of data. That w= ould be a data record. Also, if you change any of the data, you don't auto= matically change the identity - while some metadata may indeed be an insepa= rable characteristic of an identity, other may not. So, at a minimum there= needs to be some distinction about that, which is not captured in the defi= nition. =20 - Why do we need to bring a notion of "domain" into this definition. I don= 't think this is necessary. Identifiers can be relative to a domain, but i= dentity? At a minimum, this requires clarification. Maybe there is a noti= on of "also known as" by which the same entity is identified differently in= different domains. If we do bring "domain" into the picture, this needs t= o be clearly explained as well. In that case, the question also arises wha= t it means for the same "object" to be part of two "domains" - is there som= ething that links the "identities" across those domains "together" - this c= ould be considered the very identity; if not, something is missing and a th= ird concept (for "entity" or the real "self") may be needed, which we shoul= d really avoid. =20 - I am not sure that a single entity should have multiple identities. In t= his case, identity really means not much else than yet-another-identifier. = =20 --- Alex -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Michael Menth Sent: Friday, April 14, 2017 11:35 AM To: Robert Moskowitz ; ideas@ietf.org Subject: Re: [Ideas] Diasambugating Identifier and Identity Looks good to me. Michael Am 14.04.2017 um 20:26 schrieb Robert Moskowitz: >=20 >=20 > On 04/14/2017 02:45 AM, Michael Menth wrote: >> Hi Robert, hi all, >> >> thanks for your thought-provoking mail. Reading the definitions gave=20 >> me the impression that identities can have very different properties=20 >> depending on their domains. I feel the text is stimulating but too=20 >> long for a definition. >> >> What about: >> >> An identity (Idy) is a distinguishable entity within its domain. >> >> An identifier (Idf) is a label for an Idy. An Idy may have multiple=20 >> Idfs. >=20 > An identity (Idy) is a collection of data that distinguishes an entity=20 > within its domain. An entity may have different Idy for different domains= . >=20 > An identifier (Idf) is a label for an Idy, often following=20 > construction rules. An Idy may have multiple Idfs. >=20 >=20 >> >> Anything beyond this definition are valid observations that show the=20 >> diverse properties of domain-specific Idys. A discussion including=20 >> examples for entities and domains is helpful for illustration. This=20 >> also pertains to the relation between objects and Idys. >> >> Regards, >> >> Michael >> >> Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: >>> I am finally getting back to this subject. >>> >>> >>> On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >>>> The Identifier/Identity definitions in=20 >>>> draft-padma-ideas-problem-statement-01.txt is a good start, it=20 >>>> fails in the appreviations used. (There is NO abbreviation for=20 >>>> Identity!) >>>> >>>> ID should NOT be the appreviation of Identitfier. People will=20 >>>> default to thinking 'Identity' when they see it. Think about=20 >>>> people outside our discussion group. >>>> >>>> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >>>> >>>> I will be working on proposed wording to improve these definitions. >>> I have worked up definitions, sent it out to a few reviewers, got=20 >>> some comments and questions. First my current draft, then a few questi= ons: >>> >>> Replacement text for: draft-padma-ideas-problem-statement >>> >>> Identity (Abbr: IDT or IDt): A collection of information that is >>> unique to an object and differentiates it from all other objects. >>> >>> An identity consists of information that is stated about the object=20 >>> by itself or a governing authority. It consists of a set of=20 >>> attributes and/or actions the object can take. An Identity may be=20 >>> assigned a lifetime (e.g., a time period), which is determined by=20 >>> either the object or the governing authority responsible for=20 >>> defining the identity of the object, or a designated third party. An=20 >>> object can have multiple Identities and can create and discard=20 >>> Identities at will. An Identity may be 'indestructible'. That is,=20 >>> it is so unique and non replicatible that no other object could ever=20 >>> duplicate it, nor can the object discard it within its lifetime=20 >>> without being a 'clone' object. Identity is used in authentication reg= istration and policy ownership proofs. >>> >>> >>> Identifier (Abbr: IDF or IDf): A label that is unique for an object = a >>> particular scope. >>> >>> The label follows strict construction rules for the objects and the=20 >>> context that the label is applied to. For a particular context, an=20 >>> Identifier is used to reference an Identity for the object. In most=20 >>> cases, an Identifier is bound to an Identity through some trusted=20 >>> mechanism. An Identity can have different Identifiers, potentially=20 >>> following different construction rules, for different contexts=20 >>> and/or domains of applicability. >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Now onto a few questions: >>> >>> Per: "An object can have multiple Identities" clause, I am=20 >>> challenged with >>> >>> "This is VERY dangerous. In most software systems, it is the=20 >>> responsibility of the management system to assign a single identity=20 >>> to an object when it is created. If an object has multiple=20 >>> identities, it could suffer from 'multiple personality syndrome'. >>> >>> More importantly, if the object is allowed to create and discard=20 >>> identities at will, how do other objects know that the object is who=20 >>> it attests to be?" >>> >>> I think it is very important for some situations for support of=20 >>> multiple Identities. No all. There are domains as indicated above=20 >>> where it causes big problems. >>> >>> Per: "An Identity may be 'indestructible'." clause, I am challenged=20 >>> with >>> >>> "This doesn't make any sense. Why would anyone care if the identity=20 >>> is indestructible or not?" >>> >>> I can think of examples of such Identities, or claim of such=20 >>> Identities, like DNA. >>> >>> And finally, Per: "Identity is used in authentication registration=20 >>> and policy ownership proofs." clause, I am challenged with >>> >>> "What does this mean?" >>> >>> I will have to work on this some more, or perhaps it does not belong=20 >>> in the definition section. >>> >>> Comments please >>> >>> _______________________________________________ >>> Ideas mailing list >>> Ideas@ietf.org >>> https://www.ietf.org/mailman/listinfo/ideas >=20 -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Tue Apr 25 14:57:27 2017 Return-Path: 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 B09AE128CDB for ; Tue, 25 Apr 2017 14:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LEGkTDPw5qHk for ; Tue, 25 Apr 2017 14:57:22 -0700 (PDT) Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.5.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609051275AB for ; Tue, 25 Apr 2017 14:57:22 -0700 (PDT) Received: from [192.168.1.101] (hsi-kbw-5-56-217-255.hsi17.kabel-badenwuerttemberg.de [5.56.217.255]) by mx03.uni-tuebingen.de (Postfix) with ESMTPSA id BEB8B83C7C; Tue, 25 Apr 2017 23:57:19 +0200 (CEST) To: Alexander Clemm , Robert Moskowitz , "ideas@ietf.org" References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> From: Michael Menth Message-ID: <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> Date: Tue, 25 Apr 2017 23:57:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:57:26 -0000 Hi Alex, thanks for your comments. I see your points. We possibly should avoid specifying what exactly constitutes the identity as anything but its identifier may change. We said, one identity may have several identifiers, e.g., after a merging identities, but different identities certainly have different identifiers. When I think about an entitiy having multiple identities, a human being with multiple email addresses comes to my mind. An email address may be an identity to some extent, but we know that several of them may belong to the same person. I don't think we need to consider that because that is beyond the considered context of email addresses. We could just live with different identities that are different in a certain context. Another try: An identity (Idy) is a distiguishable entity within a context. An identifier (Idf) is a unique label. An Idy may have multiple Idfs but different Idys have different Idys so that Idys can be distinguished by their Idfs. Idfs often follow construction rules. Is that closer to a core definition or are mort important aspects missing? Regards, Michael Am 25.04.2017 um 02:48 schrieb Alexander Clemm: > Coming back to this thread... I do agree with the notion of identifier. However, I am not sure I agree with the notion of identity as discussed below. > > When you state "An identity (Idy) is a collection of data that distinguishes an entity within its domain. An entity may have different Idy for different domains.", I see several issues: > - For one I don't think an identity is merely a collection of data. That would be a data record. Also, if you change any of the data, you don't automatically change the identity - while some metadata may indeed be an inseparable characteristic of an identity, other may not. So, at a minimum there needs to be some distinction about that, which is not captured in the definition. > - Why do we need to bring a notion of "domain" into this definition. I don't think this is necessary. Identifiers can be relative to a domain, but identity? At a minimum, this requires clarification. Maybe there is a notion of "also known as" by which the same entity is identified differently in different domains. If we do bring "domain" into the picture, this needs to be clearly explained as well. In that case, the question also arises what it means for the same "object" to be part of two "domains" - is there something that links the "identities" across those domains "together" - this could be considered the very identity; if not, something is missing and a third concept (for "entity" or the real "self") may be needed, which we should really avoid. > - I am not sure that a single entity should have multiple identities. In this case, identity really means not much else than yet-another-identifier. > > --- Alex > > -----Original Message----- > From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Michael Menth > Sent: Friday, April 14, 2017 11:35 AM > To: Robert Moskowitz ; ideas@ietf.org > Subject: Re: [Ideas] Diasambugating Identifier and Identity > > Looks good to me. > > Michael > > Am 14.04.2017 um 20:26 schrieb Robert Moskowitz: >> >> >> On 04/14/2017 02:45 AM, Michael Menth wrote: >>> Hi Robert, hi all, >>> >>> thanks for your thought-provoking mail. Reading the definitions gave >>> me the impression that identities can have very different properties >>> depending on their domains. I feel the text is stimulating but too >>> long for a definition. >>> >>> What about: >>> >>> An identity (Idy) is a distinguishable entity within its domain. >>> >>> An identifier (Idf) is a label for an Idy. An Idy may have multiple >>> Idfs. >> >> An identity (Idy) is a collection of data that distinguishes an entity >> within its domain. An entity may have different Idy for different domains. >> >> An identifier (Idf) is a label for an Idy, often following >> construction rules. An Idy may have multiple Idfs. >> >> >>> >>> Anything beyond this definition are valid observations that show the >>> diverse properties of domain-specific Idys. A discussion including >>> examples for entities and domains is helpful for illustration. This >>> also pertains to the relation between objects and Idys. >>> >>> Regards, >>> >>> Michael >>> >>> Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: >>>> I am finally getting back to this subject. >>>> >>>> >>>> On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >>>>> The Identifier/Identity definitions in >>>>> draft-padma-ideas-problem-statement-01.txt is a good start, it >>>>> fails in the appreviations used. (There is NO abbreviation for >>>>> Identity!) >>>>> >>>>> ID should NOT be the appreviation of Identitfier. People will >>>>> default to thinking 'Identity' when they see it. Think about >>>>> people outside our discussion group. >>>>> >>>>> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >>>>> >>>>> I will be working on proposed wording to improve these definitions. >>>> I have worked up definitions, sent it out to a few reviewers, got >>>> some comments and questions. First my current draft, then a few questions: >>>> >>>> Replacement text for: draft-padma-ideas-problem-statement >>>> >>>> Identity (Abbr: IDT or IDt): A collection of information that is >>>> unique to an object and differentiates it from all other objects. >>>> >>>> An identity consists of information that is stated about the object >>>> by itself or a governing authority. It consists of a set of >>>> attributes and/or actions the object can take. An Identity may be >>>> assigned a lifetime (e.g., a time period), which is determined by >>>> either the object or the governing authority responsible for >>>> defining the identity of the object, or a designated third party. An >>>> object can have multiple Identities and can create and discard >>>> Identities at will. An Identity may be 'indestructible'. That is, >>>> it is so unique and non replicatible that no other object could ever >>>> duplicate it, nor can the object discard it within its lifetime >>>> without being a 'clone' object. Identity is used in authentication registration and policy ownership proofs. >>>> >>>> >>>> Identifier (Abbr: IDF or IDf): A label that is unique for an object a >>>> particular scope. >>>> >>>> The label follows strict construction rules for the objects and the >>>> context that the label is applied to. For a particular context, an >>>> Identifier is used to reference an Identity for the object. In most >>>> cases, an Identifier is bound to an Identity through some trusted >>>> mechanism. An Identity can have different Identifiers, potentially >>>> following different construction rules, for different contexts >>>> and/or domains of applicability. >>>> >>>> >>>> ========== >>>> >>>> Now onto a few questions: >>>> >>>> Per: "An object can have multiple Identities" clause, I am >>>> challenged with >>>> >>>> "This is VERY dangerous. In most software systems, it is the >>>> responsibility of the management system to assign a single identity >>>> to an object when it is created. If an object has multiple >>>> identities, it could suffer from 'multiple personality syndrome'. >>>> >>>> More importantly, if the object is allowed to create and discard >>>> identities at will, how do other objects know that the object is who >>>> it attests to be?" >>>> >>>> I think it is very important for some situations for support of >>>> multiple Identities. No all. There are domains as indicated above >>>> where it causes big problems. >>>> >>>> Per: "An Identity may be 'indestructible'." clause, I am challenged >>>> with >>>> >>>> "This doesn't make any sense. Why would anyone care if the identity >>>> is indestructible or not?" >>>> >>>> I can think of examples of such Identities, or claim of such >>>> Identities, like DNA. >>>> >>>> And finally, Per: "Identity is used in authentication registration >>>> and policy ownership proofs." clause, I am challenged with >>>> >>>> "What does this mean?" >>>> >>>> I will have to work on this some more, or perhaps it does not belong >>>> in the definition section. >>>> >>>> Comments please >>>> >>>> _______________________________________________ >>>> Ideas mailing list >>>> Ideas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ideas >> > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://kn.inf.uni-tuebingen.de > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Wed Apr 26 03:05:07 2017 Return-Path: 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 7348B129AA4 for ; Wed, 26 Apr 2017 03:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JhSoEKytdlJO for ; Wed, 26 Apr 2017 03:05:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95140129510 for ; Wed, 26 Apr 2017 03:05:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLU08570; Wed, 26 Apr 2017 10:04:57 +0000 (GMT) Received: from SZXEMI414-HUB.china.huawei.com (10.86.210.49) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Apr 2017 11:04:56 +0100 Received: from SZXEMI508-MBS.china.huawei.com ([169.254.10.152]) by SZXEMI414-HUB.china.huawei.com ([10.86.210.49]) with mapi id 14.03.0235.001; Wed, 26 Apr 2017 18:04:46 +0800 From: "Liubingyang (Bryan)" To: Michael Menth , Alexander Clemm , Robert Moskowitz , "ideas@ietf.org" Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp914j5eOmWLOQkutGf2RD5x5MqHDjbwAgABx9QCAAMPZAIAAAjuAgBAfzYCAAWJVgIABSuQw Date: Wed, 26 Apr 2017 10:04:46 +0000 Message-ID: References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> In-Reply-To: <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.168.116] 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.0A020203.590070CA.0274, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.10.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5271462e6ccc4de9b0f102f77736dfd Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 10:05:06 -0000 It seems that there are a thousand Hamlets in a thousand people's eyes :p I think the real reason for the disagreements on the definitions is that we= have not got a consensus on what they are used for yet. Or the even deeper= question is what functions we need for IDEAS. If we can agree on the funct= ions we need, then we can define a term that we use to provide the function= .=20 For example, (one of) the real reason we want identifiers is that we want s= omething that does not change with topology locations to identify mobile co= mmunication end point, which functions that cannot be carried by IP address= es. Since (I believe) we all have consensus on this function, we can at lea= st agree that identifier is topology-independent label that identifies a co= mmunication end point.=20 For identities, I suggest we first discuss what new functions, which cannot= be carried by identifiers, we want to bring into IDEAS. If we have consens= us on the functionalities, we can easily make a definition.=20 Dino said that we could move on to bigger fish to fry. I think new function= are big thing.=20 Bingyang (Bryan)=20 -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Michael Menth Sent: Wednesday, April 26, 2017 5:57 AM To: Alexander Clemm ; Robert Moskowitz ; ideas@ietf.org Subject: Re: [Ideas] Diasambugating Identifier and Identity Hi Alex, thanks for your comments. I see your points. We possibly should avoid speci= fying what exactly constitutes the identity as anything but its identifier = may change. We said, one identity may have several identifiers, e.g., after= a merging identities, but different identities certainly have different id= entifiers. When I think about an entitiy having multiple identities, a human being wit= h multiple email addresses comes to my mind. An email address may be an ide= ntity to some extent, but we know that several of them may belong to the sa= me person. I don't think we need to consider that because that is beyond th= e considered context of email addresses. We could just live with different = identities that are different in a certain context. Another try: An identity (Idy) is a distiguishable entity within a context. An identifier (Idf) is a unique label. An Idy may have multiple Idfs but different Idys have different Idys so tha= t Idys can be distinguished by their Idfs. Idfs often follow construction r= ules. Is that closer to a core definition or are mort important aspects missing? Regards, Michael Am 25.04.2017 um 02:48 schrieb Alexander Clemm: > Coming back to this thread... I do agree with the notion of identifier. = However, I am not sure I agree with the notion of identity as discussed bel= ow. >=20 > When you state "An identity (Idy) is a collection of data that distinguis= hes an entity within its domain. An entity may have different Idy for diff= erent domains.", I see several issues: > - For one I don't think an identity is merely a collection of data. That= would be a data record. Also, if you change any of the data, you don't au= tomatically change the identity - while some metadata may indeed be an inse= parable characteristic of an identity, other may not. So, at a minimum the= re needs to be some distinction about that, which is not captured in the de= finition. =20 > - Why do we need to bring a notion of "domain" into this definition. I d= on't think this is necessary. Identifiers can be relative to a domain, but= identity? At a minimum, this requires clarification. Maybe there is a no= tion of "also known as" by which the same entity is identified differently = in different domains. If we do bring "domain" into the picture, this needs= to be clearly explained as well. In that case, the question also arises w= hat it means for the same "object" to be part of two "domains" - is there s= omething that links the "identities" across those domains "together" - this= could be considered the very identity; if not, something is missing and a = third concept (for "entity" or the real "self") may be needed, which we sho= uld really avoid. =20 > - I am not sure that a single entity should have multiple identities. In= this case, identity really means not much else than yet-another-identifier= . =20 >=20 > --- Alex >=20 > -----Original Message----- > From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Michael Menth > Sent: Friday, April 14, 2017 11:35 AM > To: Robert Moskowitz ; ideas@ietf.org > Subject: Re: [Ideas] Diasambugating Identifier and Identity >=20 > Looks good to me. >=20 > Michael >=20 > Am 14.04.2017 um 20:26 schrieb Robert Moskowitz: >> >> >> On 04/14/2017 02:45 AM, Michael Menth wrote: >>> Hi Robert, hi all, >>> >>> thanks for your thought-provoking mail. Reading the definitions gave=20 >>> me the impression that identities can have very different properties=20 >>> depending on their domains. I feel the text is stimulating but too=20 >>> long for a definition. >>> >>> What about: >>> >>> An identity (Idy) is a distinguishable entity within its domain. >>> >>> An identifier (Idf) is a label for an Idy. An Idy may have multiple=20 >>> Idfs. >> >> An identity (Idy) is a collection of data that distinguishes an=20 >> entity within its domain. An entity may have different Idy for different= domains. >> >> An identifier (Idf) is a label for an Idy, often following=20 >> construction rules. An Idy may have multiple Idfs. >> >> >>> >>> Anything beyond this definition are valid observations that show the=20 >>> diverse properties of domain-specific Idys. A discussion including=20 >>> examples for entities and domains is helpful for illustration. This=20 >>> also pertains to the relation between objects and Idys. >>> >>> Regards, >>> >>> Michael >>> >>> Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: >>>> I am finally getting back to this subject. >>>> >>>> >>>> On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >>>>> The Identifier/Identity definitions in=20 >>>>> draft-padma-ideas-problem-statement-01.txt is a good start, it=20 >>>>> fails in the appreviations used. (There is NO abbreviation for >>>>> Identity!) >>>>> >>>>> ID should NOT be the appreviation of Identitfier. People will=20 >>>>> default to thinking 'Identity' when they see it. Think about=20 >>>>> people outside our discussion group. >>>>> >>>>> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >>>>> >>>>> I will be working on proposed wording to improve these definitions. >>>> I have worked up definitions, sent it out to a few reviewers, got=20 >>>> some comments and questions. First my current draft, then a few quest= ions: >>>> >>>> Replacement text for: draft-padma-ideas-problem-statement >>>> >>>> Identity (Abbr: IDT or IDt): A collection of information that is >>>> unique to an object and differentiates it from all other objects. >>>> >>>> An identity consists of information that is stated about the object=20 >>>> by itself or a governing authority. It consists of a set of=20 >>>> attributes and/or actions the object can take. An Identity may be=20 >>>> assigned a lifetime (e.g., a time period), which is determined by=20 >>>> either the object or the governing authority responsible for=20 >>>> defining the identity of the object, or a designated third party.=20 >>>> An object can have multiple Identities and can create and discard=20 >>>> Identities at will. An Identity may be 'indestructible'. That is,=20 >>>> it is so unique and non replicatible that no other object could=20 >>>> ever duplicate it, nor can the object discard it within its=20 >>>> lifetime without being a 'clone' object. Identity is used in authenti= cation registration and policy ownership proofs. >>>> >>>> >>>> Identifier (Abbr: IDF or IDf): A label that is unique for an object= a >>>> particular scope. >>>> >>>> The label follows strict construction rules for the objects and the=20 >>>> context that the label is applied to. For a particular context, an=20 >>>> Identifier is used to reference an Identity for the object. In=20 >>>> most cases, an Identifier is bound to an Identity through some=20 >>>> trusted mechanism. An Identity can have different Identifiers,=20 >>>> potentially following different construction rules, for different=20 >>>> contexts and/or domains of applicability. >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> Now onto a few questions: >>>> >>>> Per: "An object can have multiple Identities" clause, I am=20 >>>> challenged with >>>> >>>> "This is VERY dangerous. In most software systems, it is the=20 >>>> responsibility of the management system to assign a single identity=20 >>>> to an object when it is created. If an object has multiple=20 >>>> identities, it could suffer from 'multiple personality syndrome'. >>>> >>>> More importantly, if the object is allowed to create and discard=20 >>>> identities at will, how do other objects know that the object is=20 >>>> who it attests to be?" >>>> >>>> I think it is very important for some situations for support of=20 >>>> multiple Identities. No all. There are domains as indicated above=20 >>>> where it causes big problems. >>>> >>>> Per: "An Identity may be 'indestructible'." clause, I am challenged=20 >>>> with >>>> >>>> "This doesn't make any sense. Why would anyone care if the identity=20 >>>> is indestructible or not?" >>>> >>>> I can think of examples of such Identities, or claim of such=20 >>>> Identities, like DNA. >>>> >>>> And finally, Per: "Identity is used in authentication registration=20 >>>> and policy ownership proofs." clause, I am challenged with >>>> >>>> "What does this mean?" >>>> >>>> I will have to work on this some more, or perhaps it does not=20 >>>> belong in the definition section. >>>> >>>> Comments please >>>> >>>> _______________________________________________ >>>> Ideas mailing list >>>> Ideas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ideas >> >=20 > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://kn.inf.uni-tuebingen.de >=20 > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas >=20 > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas >=20 -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Wed Apr 26 07:20:55 2017 Return-Path: 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 C49A012EC67 for ; Wed, 26 Apr 2017 07:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 YLeMpVCc8_M4 for ; Wed, 26 Apr 2017 07:20:50 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F8012EB27 for ; Wed, 26 Apr 2017 07:13:44 -0700 (PDT) Received: from [134.2.82.60] (u-082-c060.eap.uni-tuebingen.de [134.2.82.60]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 25C833442; Wed, 26 Apr 2017 16:13:42 +0200 (CEST) To: "Liubingyang (Bryan)" , Alexander Clemm , Robert Moskowitz , "ideas@ietf.org" References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> From: Michael Menth Message-ID: <4abc17ba-5fbf-6382-30ac-df5d37b20812@uni-tuebingen.de> Date: Wed, 26 Apr 2017 16:13:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:20:54 -0000 Hi all, I see that we leverage a mapping system to map identifiers to some information (locators, service information, priorities, whatever). The identity seems most useful to me for authenticated registration of the mapping information. What else are identities good for? Regards, Michael Am 26.04.2017 um 12:04 schrieb Liubingyang (Bryan): > It seems that there are a thousand Hamlets in a thousand people's eyes :p > > I think the real reason for the disagreements on the definitions is that we have not got a consensus on what they are used for yet. Or the even deeper question is what functions we need for IDEAS. If we can agree on the functions we need, then we can define a term that we use to provide the function. > > For example, (one of) the real reason we want identifiers is that we want something that does not change with topology locations to identify mobile communication end point, which functions that cannot be carried by IP addresses. Since (I believe) we all have consensus on this function, we can at least agree that identifier is topology-independent label that identifies a communication end point. > > For identities, I suggest we first discuss what new functions, which cannot be carried by identifiers, we want to bring into IDEAS. If we have consensus on the functionalities, we can easily make a definition. > > Dino said that we could move on to bigger fish to fry. I think new function are big thing. > > Bingyang (Bryan) > > -----Original Message----- > From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Michael Menth > Sent: Wednesday, April 26, 2017 5:57 AM > To: Alexander Clemm ; Robert Moskowitz ; ideas@ietf.org > Subject: Re: [Ideas] Diasambugating Identifier and Identity > > Hi Alex, > > thanks for your comments. I see your points. We possibly should avoid specifying what exactly constitutes the identity as anything but its identifier may change. We said, one identity may have several identifiers, e.g., after a merging identities, but different identities certainly have different identifiers. > > When I think about an entitiy having multiple identities, a human being with multiple email addresses comes to my mind. An email address may be an identity to some extent, but we know that several of them may belong to the same person. I don't think we need to consider that because that is beyond the considered context of email addresses. We could just live with different identities that are different in a certain context. > > Another try: > > An identity (Idy) is a distiguishable entity within a context. > > An identifier (Idf) is a unique label. > > An Idy may have multiple Idfs but different Idys have different Idys so that Idys can be distinguished by their Idfs. Idfs often follow construction rules. > > Is that closer to a core definition or are mort important aspects missing? > > Regards, > > Michael > > > > Am 25.04.2017 um 02:48 schrieb Alexander Clemm: >> Coming back to this thread... I do agree with the notion of identifier. However, I am not sure I agree with the notion of identity as discussed below. >> >> When you state "An identity (Idy) is a collection of data that distinguishes an entity within its domain. An entity may have different Idy for different domains.", I see several issues: >> - For one I don't think an identity is merely a collection of data. That would be a data record. Also, if you change any of the data, you don't automatically change the identity - while some metadata may indeed be an inseparable characteristic of an identity, other may not. So, at a minimum there needs to be some distinction about that, which is not captured in the definition. >> - Why do we need to bring a notion of "domain" into this definition. I don't think this is necessary. Identifiers can be relative to a domain, but identity? At a minimum, this requires clarification. Maybe there is a notion of "also known as" by which the same entity is identified differently in different domains. If we do bring "domain" into the picture, this needs to be clearly explained as well. In that case, the question also arises what it means for the same "object" to be part of two "domains" - is there something that links the "identities" across those domains "together" - this could be considered the very identity; if not, something is missing and a third concept (for "entity" or the real "self") may be needed, which we should really avoid. >> - I am not sure that a single entity should have multiple identities. In this case, identity really means not much else than yet-another-identifier. >> >> --- Alex >> >> -----Original Message----- >> From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Michael Menth >> Sent: Friday, April 14, 2017 11:35 AM >> To: Robert Moskowitz ; ideas@ietf.org >> Subject: Re: [Ideas] Diasambugating Identifier and Identity >> >> Looks good to me. >> >> Michael >> >> Am 14.04.2017 um 20:26 schrieb Robert Moskowitz: >>> >>> >>> On 04/14/2017 02:45 AM, Michael Menth wrote: >>>> Hi Robert, hi all, >>>> >>>> thanks for your thought-provoking mail. Reading the definitions gave >>>> me the impression that identities can have very different properties >>>> depending on their domains. I feel the text is stimulating but too >>>> long for a definition. >>>> >>>> What about: >>>> >>>> An identity (Idy) is a distinguishable entity within its domain. >>>> >>>> An identifier (Idf) is a label for an Idy. An Idy may have multiple >>>> Idfs. >>> >>> An identity (Idy) is a collection of data that distinguishes an >>> entity within its domain. An entity may have different Idy for different domains. >>> >>> An identifier (Idf) is a label for an Idy, often following >>> construction rules. An Idy may have multiple Idfs. >>> >>> >>>> >>>> Anything beyond this definition are valid observations that show the >>>> diverse properties of domain-specific Idys. A discussion including >>>> examples for entities and domains is helpful for illustration. This >>>> also pertains to the relation between objects and Idys. >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>> Am 14.04.2017 um 01:58 schrieb Robert Moskowitz: >>>>> I am finally getting back to this subject. >>>>> >>>>> >>>>> On 03/28/2017 12:07 PM, Robert Moskowitz wrote: >>>>>> The Identifier/Identity definitions in >>>>>> draft-padma-ideas-problem-statement-01.txt is a good start, it >>>>>> fails in the appreviations used. (There is NO abbreviation for >>>>>> Identity!) >>>>>> >>>>>> ID should NOT be the appreviation of Identitfier. People will >>>>>> default to thinking 'Identity' when they see it. Think about >>>>>> people outside our discussion group. >>>>>> >>>>>> I propose 'IDf' for Identifier. 'ID' is too owned by Identity. >>>>>> >>>>>> I will be working on proposed wording to improve these definitions. >>>>> I have worked up definitions, sent it out to a few reviewers, got >>>>> some comments and questions. First my current draft, then a few questions: >>>>> >>>>> Replacement text for: draft-padma-ideas-problem-statement >>>>> >>>>> Identity (Abbr: IDT or IDt): A collection of information that is >>>>> unique to an object and differentiates it from all other objects. >>>>> >>>>> An identity consists of information that is stated about the object >>>>> by itself or a governing authority. It consists of a set of >>>>> attributes and/or actions the object can take. An Identity may be >>>>> assigned a lifetime (e.g., a time period), which is determined by >>>>> either the object or the governing authority responsible for >>>>> defining the identity of the object, or a designated third party. >>>>> An object can have multiple Identities and can create and discard >>>>> Identities at will. An Identity may be 'indestructible'. That is, >>>>> it is so unique and non replicatible that no other object could >>>>> ever duplicate it, nor can the object discard it within its >>>>> lifetime without being a 'clone' object. Identity is used in authentication registration and policy ownership proofs. >>>>> >>>>> >>>>> Identifier (Abbr: IDF or IDf): A label that is unique for an object a >>>>> particular scope. >>>>> >>>>> The label follows strict construction rules for the objects and the >>>>> context that the label is applied to. For a particular context, an >>>>> Identifier is used to reference an Identity for the object. In >>>>> most cases, an Identifier is bound to an Identity through some >>>>> trusted mechanism. An Identity can have different Identifiers, >>>>> potentially following different construction rules, for different >>>>> contexts and/or domains of applicability. >>>>> >>>>> >>>>> ========== >>>>> >>>>> Now onto a few questions: >>>>> >>>>> Per: "An object can have multiple Identities" clause, I am >>>>> challenged with >>>>> >>>>> "This is VERY dangerous. In most software systems, it is the >>>>> responsibility of the management system to assign a single identity >>>>> to an object when it is created. If an object has multiple >>>>> identities, it could suffer from 'multiple personality syndrome'. >>>>> >>>>> More importantly, if the object is allowed to create and discard >>>>> identities at will, how do other objects know that the object is >>>>> who it attests to be?" >>>>> >>>>> I think it is very important for some situations for support of >>>>> multiple Identities. No all. There are domains as indicated above >>>>> where it causes big problems. >>>>> >>>>> Per: "An Identity may be 'indestructible'." clause, I am challenged >>>>> with >>>>> >>>>> "This doesn't make any sense. Why would anyone care if the identity >>>>> is indestructible or not?" >>>>> >>>>> I can think of examples of such Identities, or claim of such >>>>> Identities, like DNA. >>>>> >>>>> And finally, Per: "Identity is used in authentication registration >>>>> and policy ownership proofs." clause, I am challenged with >>>>> >>>>> "What does this mean?" >>>>> >>>>> I will have to work on this some more, or perhaps it does not >>>>> belong in the definition section. >>>>> >>>>> Comments please >>>>> >>>>> _______________________________________________ >>>>> Ideas mailing list >>>>> Ideas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ideas >>> >> >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Faculty of Science >> Department of Computer Science >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505 >> fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de >> http://kn.inf.uni-tuebingen.de >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas >> > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://kn.inf.uni-tuebingen.de > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Wed Apr 26 10:36:22 2017 Return-Path: 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 3C821129489 for ; Wed, 26 Apr 2017 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 YohJvRxwyQT9 for ; Wed, 26 Apr 2017 10:36:19 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 27AE5120454 for ; Wed, 26 Apr 2017 10:36:19 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id v1so1576085pgv.3 for ; Wed, 26 Apr 2017 10:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zlz/W4+lKSo1wFc89DbKzAyHS3g7SvmkUN1l/KE0B8A=; b=gn60YCctwgNKpKT8ClZKvj8O65Tr1Y98IzKI/tmxARIvTaYdYFDKhKbIWpfL4SSaHr LIGEIae7bn70O3MjWX21b40oOmZxrNkgHPsjfM2qYMkrvuUDSumgW8fqpQRwukxcZO4y BPJqORNLR2U30CwaS3VU7uoGBzmp8Txv7sxG2GalcLp+Oy6mAnJVAukPzwhRXx/fGzLC V+q/BNQ3S9L5N65/2a+OeUhcM/IFq4YKd/lTF+S2byN5H6du6nSL/QM9+KzaPz5pCnu2 obq5W6Hyaf0zZlSapycS33f9zdfDnnyJt2rz11bGoWMkyXIJnLWeLY/donBWPdgnqYNg pG/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zlz/W4+lKSo1wFc89DbKzAyHS3g7SvmkUN1l/KE0B8A=; b=oMTaPVPyubQvXfNi8OcGsWLePUVDLuP7NHIL5yRBadPh4RLYxE0n5eJ8y0EnhLHHlW Oxe9i1MtMlHLy5iGn4+SKUXy23Ln4pn//E5DuLXphlJP/+vToFHx/Vw9+go/n9S6JbDV uijEgigefw0JBmVt0T5U3bMblm/Ax+OrE+Stz3wqyTw/a/Px3JdUnrmwXM1sP+Q4tHoy iybr0caVy54vGLmvvKVG0lT4xqppGzNqtvXQclXeefN84JavqSThOnRyy/qCjxIvfICK SolhdtMEnqLrpCUKmL5LRbqrYh2PjUqJiH89Oa85u2lMVeXKeI5FOXWVMuBBt/JN0U94 82zw== X-Gm-Message-State: AN3rC/7ydq2GoDt0ycyHKEEPrHP5dke9jkKe+iOCunpAs5qnjNduRZmE j6+R6DQPw4kotw== X-Received: by 10.98.192.78 with SMTP id x75mr1020264pff.1.1493227581730; Wed, 26 Apr 2017 10:26:21 -0700 (PDT) Received: from [10.131.63.38] ([205.154.255.166]) by smtp.gmail.com with ESMTPSA id a190sm1285731pgc.60.2017.04.26.10.26.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 10:26:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dino Farinacci In-Reply-To: Date: Wed, 26 Apr 2017 10:26:20 -0700 Cc: Michael Menth , Alexander Clemm , Robert Moskowitz , "ideas@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> To: "Liubingyang (Bryan)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:36:20 -0000 > For example, (one of) the real reason we want identifiers is that we = want something that does not change with topology locations to identify = mobile communication end point, which functions that cannot be carried = by IP addresses. Since (I believe) we all have consensus on this = function, we can at least agree that identifier is topology-independent = label that identifies a communication end point.=20 Exactly. So to extend the definition to be specific. The identifier is used for a = host stack transport connection. Its the =E2=80=9Cthing=E2=80=9D (the = arguments) you pass to connect(), bind(), sendto(), etc, socket API = calls. And what you =E2=80=9Cget back=E2=80=9D from gethostbyname(). Dino From nobody Wed Apr 26 12:38:55 2017 Return-Path: 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 9CEEB129450 for ; Wed, 26 Apr 2017 12:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iU6bmNao6EmX for ; Wed, 26 Apr 2017 12:38:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742F41314B1 for ; Wed, 26 Apr 2017 12:38:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFO45205; Wed, 26 Apr 2017 19:38:48 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Apr 2017 20:38:46 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML702-CHM.china.huawei.com ([169.254.4.233]) with mapi id 14.03.0235.001; Wed, 26 Apr 2017 12:38:37 -0700 From: Alexander Clemm To: Dino Farinacci , "Liubingyang (Bryan)" CC: Michael Menth , Robert Moskowitz , "ideas@ietf.org" Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp916fQ6Ay+5HYEmqQas6XmYXz6HEiTEAgABx9QCAAMPZAIAAAjuAgA+nLqCAAdr0gIAAy1IAgAB7XwD//60WgA== Date: Wed, 26 Apr 2017 19:38:35 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> In-Reply-To: <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.180] 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.0A020201.5900F748.0352, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9bbd9fb42d3f22b96b673e9c96398629 Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:38:55 -0000 WWVzLCBJIHRoaW5rIHdlIGFncmVlIG9uIHRoZSBub3Rpb24gb2YgaWRlbnRpZmllci4gIA0KDQpP ZiBjb3Vyc2UsIHRoaXMgaXMgbm90IGp1c3QgYWJvdXQgaWRlbnRpZmllci0gYnV0IGlkZW50aXR5 LWVuYWJsZWQgbmV0d29ya2luZywgc28gdGhlcmUgaXMgc3RpbGwgdGhhdCBvdGhlciBhc3BlY3Qg bmVlZGluZyB0byBiZSBmbGVzaGVkIG91dC4gUmU6IE1pY2hhZWwncyBxdWVzdGlvbiwgYXV0aGVu dGljYXRpb24gaXMgb25lIG9mIGl0cyBhcHBsaWNhdGlvbnMsIGJ1dCBJIHRoaW5rIHRoZXJlIGFy ZSBvdGhlcnMsIGZvciBleGFtcGxlIHJlbGF0ZWQgdG8gbWV0YWRhdGEgKGJhY2sgdG8gdGhlIGVh cmxpZXIgcG9pbnQgb2Ygd2hldGhlciBpZGVudGl0eSBpcyBhIGRhdGEgcmVjb3JkKSAtIGFuIGV4 YW1wbGUgd291bGQgYmUgdGhlICJ0eXBlIiBvZiBlbmRwb2ludCB3aGljaCBhcHBsaWVzIHJlZ2Fy ZGxlc3Mgd2hldGhlciBvbmUgb3IgbWFueSBpZGVudGlmaWVycyBhcmUgYmVpbmcgdXNlZC4gIFJl bGF0ZWQgdG8gbWV0YWRhdGEsIHlvdSBjb3VsZCBoYXZlIHBvbGljaWVzIHRoYXQgYXJlIGFwcGxp ZWQgYmFzZWQgb24gaWRlbnRpdHkgKGUuZy4gYW4gZW50aXR5IHdpdGggYSBwYWlkIGNvbnRyYWN0 KSwgbm90IGJhc2VkIG9uIHdoaWNoIG9uZSBvZiBzZXZlcmFsIGlkZW50aWZpZXJzIGFuIGVudGl0 eSBoYXBwZW5zIHRvIHVzZS4gICANCg0KLS0gQWxleA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogRGlubyBGYXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tXSAN ClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjYsIDIwMTcgMTA6MjYgQU0NClRvOiBMaXViaW5neWFu ZyAoQnJ5YW4pIDxsaXViaW5neWFuZ0BodWF3ZWkuY29tPg0KQ2M6IE1pY2hhZWwgTWVudGggPG1l bnRoQHVuaS10dWViaW5nZW4uZGU+OyBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBo dWF3ZWkuY29tPjsgUm9iZXJ0IE1vc2tvd2l0eiA8cmdtLWlldGZAaHR0LWNvbnN1bHQuY29tPjsg aWRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRlYXNdIERpYXNhbWJ1Z2F0aW5nIElkZW50 aWZpZXIgYW5kIElkZW50aXR5DQoNCj4gRm9yIGV4YW1wbGUsIChvbmUgb2YpIHRoZSByZWFsIHJl YXNvbiB3ZSB3YW50IGlkZW50aWZpZXJzIGlzIHRoYXQgd2Ugd2FudCBzb21ldGhpbmcgdGhhdCBk b2VzIG5vdCBjaGFuZ2Ugd2l0aCB0b3BvbG9neSBsb2NhdGlvbnMgdG8gaWRlbnRpZnkgbW9iaWxl IGNvbW11bmljYXRpb24gZW5kIHBvaW50LCB3aGljaCBmdW5jdGlvbnMgdGhhdCBjYW5ub3QgYmUg Y2FycmllZCBieSBJUCBhZGRyZXNzZXMuIFNpbmNlIChJIGJlbGlldmUpIHdlIGFsbCBoYXZlIGNv bnNlbnN1cyBvbiB0aGlzIGZ1bmN0aW9uLCB3ZSBjYW4gYXQgbGVhc3QgYWdyZWUgdGhhdCBpZGVu dGlmaWVyIGlzIHRvcG9sb2d5LWluZGVwZW5kZW50IGxhYmVsIHRoYXQgaWRlbnRpZmllcyBhIGNv bW11bmljYXRpb24gZW5kIHBvaW50LiANCg0KRXhhY3RseS4NCg0KU28gdG8gZXh0ZW5kIHRoZSBk ZWZpbml0aW9uIHRvIGJlIHNwZWNpZmljLiBUaGUgaWRlbnRpZmllciBpcyB1c2VkIGZvciBhIGhv c3Qgc3RhY2sgdHJhbnNwb3J0IGNvbm5lY3Rpb24uIEl0cyB0aGUg4oCcdGhpbmfigJ0gKHRoZSBh cmd1bWVudHMpIHlvdSBwYXNzIHRvIGNvbm5lY3QoKSwgYmluZCgpLCBzZW5kdG8oKSwgZXRjLCBz b2NrZXQgQVBJIGNhbGxzLiBBbmQgd2hhdCB5b3Ug4oCcZ2V0IGJhY2vigJ0gZnJvbSBnZXRob3N0 YnluYW1lKCkuDQoNCkRpbm8NCg0K From nobody Wed Apr 26 12:56:09 2017 Return-Path: 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 D4F37126DED for ; Wed, 26 Apr 2017 12:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 J9rvxV9JrKIR for ; Wed, 26 Apr 2017 12:56:05 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D7F12878D for ; Wed, 26 Apr 2017 12:56:04 -0700 (PDT) Received: from [134.2.11.131] (chaos.informatik.uni-tuebingen.de [134.2.11.131]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 956703E4FC; Wed, 26 Apr 2017 21:56:02 +0200 (CEST) To: Alexander Clemm , Dino Farinacci , "Liubingyang (Bryan)" References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> Cc: Robert Moskowitz , "ideas@ietf.org" From: Michael Menth Message-ID: Date: Wed, 26 Apr 2017 21:55:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:56:08 -0000 Hi Alex, can't a contract be represented by a contract identifier (cidX) to which several networking identifiers (nidn) are mapped? nid0 -> cidX nid1 -> cidX nid2 -> cidX cidX -> someProperty This contract identifier may be mapped to some property yielding a kind of hierarchical mapping. What I want to say is, I don't see the gain of an identity concept in this example. I ask again: what's the value of identities beyond authentication for registration purposes? Regards, Michael Am 26.04.2017 um 21:38 schrieb Alexander Clemm: > Yes, I think we agree on the notion of identifier. > > Of course, this is not just about identifier- but identity-enabled networking, so there is still that other aspect needing to be fleshed out. Re: Michael's question, authentication is one of its applications, but I think there are others, for example related to metadata (back to the earlier point of whether identity is a data record) - an example would be the "type" of endpoint which applies regardless whether one or many identifiers are being used. Related to metadata, you could have policies that are applied based on identity (e.g. an entity with a paid contract), not based on which one of several identifiers an entity happens to use. > > -- Alex > > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Wednesday, April 26, 2017 10:26 AM > To: Liubingyang (Bryan) > Cc: Michael Menth ; Alexander Clemm ; Robert Moskowitz ; ideas@ietf.org > Subject: Re: [Ideas] Diasambugating Identifier and Identity > >> For example, (one of) the real reason we want identifiers is that we want something that does not change with topology locations to identify mobile communication end point, which functions that cannot be carried by IP addresses. Since (I believe) we all have consensus on this function, we can at least agree that identifier is topology-independent label that identifies a communication end point. > > Exactly. > > So to extend the definition to be specific. The identifier is used for a host stack transport connection. Its the “thing” (the arguments) you pass to connect(), bind(), sendto(), etc, socket API calls. And what you “get back” from gethostbyname(). > > Dino > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Wed Apr 26 18:30:51 2017 Return-Path: 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 8BF8812441E for ; Wed, 26 Apr 2017 18:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0gG0ahZi0djo for ; Wed, 26 Apr 2017 18:30:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454FF124281 for ; Wed, 26 Apr 2017 18:30:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLV18851; Thu, 27 Apr 2017 01:30:45 +0000 (GMT) Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Apr 2017 02:30:43 +0100 Received: from SZXEMI508-MBS.china.huawei.com ([169.254.10.152]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Thu, 27 Apr 2017 09:30:35 +0800 From: "Liubingyang (Bryan)" To: Michael Menth , Alexander Clemm , Dino Farinacci CC: Robert Moskowitz , "ideas@ietf.org" Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp914j5eOmWLOQkutGf2RD5x5MqHDjbwAgABx9QCAAMPZAIAAAjuAgBAfzYCAAWJVgIABSuQw///7zQCAACT0gIAABM6AgADigCA= Date: Thu, 27 Apr 2017 01:30:34 +0000 Message-ID: References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.168.116] 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.0A090201.590149C5.0078, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.10.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5271462e6ccc4de9b0f102f77736dfd Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 01:30:50 -0000 SGkgTWljaGFlbCwgDQoNCldoYXQgZG8geW91IG1lYW4gYnkgYXV0aGVudGljYXRpb24/IA0KSXMg aXQgdXNlZCBieSBtYXBwaW5nIHN5c3RlbSB0byBhdXRoZW50aWNhdGUgd2hldGhlciBhbiBlbnRp dHkgY2FuIHVwZGF0ZSBwcm9wZXJ0aWVzIG9mIGFuIGlkZW50aWZpZXIsIG9yIHVzZWQgYnkgdGhl IGNvcnJlc3BvbmRpbmcgbm9kZSB0byBhdXRoZW50aWNhdGUgd2hldGhlciB0aGUgZW50aXR5IGlu ZGVlZCBvd25zIHRoZSBpZGVudGlmaWVyPyANCg0KQmluZ3lhbmcgKEJyeWFuKQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBNZW50aCBbbWFpbHRvOm1lbnRoQHVu aS10dWViaW5nZW4uZGVdIA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDI3LCAyMDE3IDM6NTYgQU0N ClRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPjsgRGlubyBG YXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5jb20+OyBMaXViaW5neWFuZyAoQnJ5YW4pIDxsaXVi aW5neWFuZ0BodWF3ZWkuY29tPg0KQ2M6IFJvYmVydCBNb3Nrb3dpdHogPHJnbS1pZXRmQGh0dC1j b25zdWx0LmNvbT47IGlkZWFzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkZWFzXSBEaWFzYW1i dWdhdGluZyBJZGVudGlmaWVyIGFuZCBJZGVudGl0eQ0KDQpIaSBBbGV4LA0KDQpjYW4ndCBhIGNv bnRyYWN0IGJlIHJlcHJlc2VudGVkIGJ5IGEgY29udHJhY3QgaWRlbnRpZmllciAoY2lkWCkgdG8g d2hpY2ggc2V2ZXJhbCBuZXR3b3JraW5nIGlkZW50aWZpZXJzIChuaWRuKSBhcmUgbWFwcGVkPw0K DQpuaWQwIC0+IGNpZFgNCm5pZDEgLT4gY2lkWA0KbmlkMiAtPiBjaWRYDQpjaWRYIC0+IHNvbWVQ cm9wZXJ0eQ0KDQpUaGlzIGNvbnRyYWN0IGlkZW50aWZpZXIgbWF5IGJlIG1hcHBlZCB0byBzb21l IHByb3BlcnR5IHlpZWxkaW5nIGEga2luZCBvZiBoaWVyYXJjaGljYWwgbWFwcGluZy4gV2hhdCBJ IHdhbnQgdG8gc2F5IGlzLCBJIGRvbid0IHNlZSB0aGUgZ2FpbiBvZiBhbiBpZGVudGl0eSBjb25j ZXB0IGluIHRoaXMgZXhhbXBsZS4NCg0KSSBhc2sgYWdhaW46IHdoYXQncyB0aGUgdmFsdWUgb2Yg aWRlbnRpdGllcyBiZXlvbmQgYXV0aGVudGljYXRpb24gZm9yIHJlZ2lzdHJhdGlvbiBwdXJwb3Nl cz8NCg0KUmVnYXJkcywNCg0KTWljaGFlbA0KDQoNCkFtIDI2LjA0LjIwMTcgdW0gMjE6Mzggc2No cmllYiBBbGV4YW5kZXIgQ2xlbW06DQo+IFllcywgSSB0aGluayB3ZSBhZ3JlZSBvbiB0aGUgbm90 aW9uIG9mIGlkZW50aWZpZXIuICANCj4gDQo+IE9mIGNvdXJzZSwgdGhpcyBpcyBub3QganVzdCBh Ym91dCBpZGVudGlmaWVyLSBidXQgaWRlbnRpdHktZW5hYmxlZCBuZXR3b3JraW5nLCBzbyB0aGVy ZSBpcyBzdGlsbCB0aGF0IG90aGVyIGFzcGVjdCBuZWVkaW5nIHRvIGJlIGZsZXNoZWQgb3V0LiBS ZTogTWljaGFlbCdzIHF1ZXN0aW9uLCBhdXRoZW50aWNhdGlvbiBpcyBvbmUgb2YgaXRzIGFwcGxp Y2F0aW9ucywgYnV0IEkgdGhpbmsgdGhlcmUgYXJlIG90aGVycywgZm9yIGV4YW1wbGUgcmVsYXRl ZCB0byBtZXRhZGF0YSAoYmFjayB0byB0aGUgZWFybGllciBwb2ludCBvZiB3aGV0aGVyIGlkZW50 aXR5IGlzIGEgZGF0YSByZWNvcmQpIC0gYW4gZXhhbXBsZSB3b3VsZCBiZSB0aGUgInR5cGUiIG9m IGVuZHBvaW50IHdoaWNoIGFwcGxpZXMgcmVnYXJkbGVzcyB3aGV0aGVyIG9uZSBvciBtYW55IGlk ZW50aWZpZXJzIGFyZSBiZWluZyB1c2VkLiAgUmVsYXRlZCB0byBtZXRhZGF0YSwgeW91IGNvdWxk IGhhdmUgcG9saWNpZXMgdGhhdCBhcmUgYXBwbGllZCBiYXNlZCBvbiBpZGVudGl0eSAoZS5nLiBh biBlbnRpdHkgd2l0aCBhIHBhaWQgY29udHJhY3QpLCBub3QgYmFzZWQgb24gd2hpY2ggb25lIG9m IHNldmVyYWwgaWRlbnRpZmllcnMgYW4gZW50aXR5IGhhcHBlbnMgdG8gdXNlLiAgIA0KPiANCj4g LS0gQWxleA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGlubyBG YXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXks IEFwcmlsIDI2LCAyMDE3IDEwOjI2IEFNDQo+IFRvOiBMaXViaW5neWFuZyAoQnJ5YW4pIDxsaXVi aW5neWFuZ0BodWF3ZWkuY29tPg0KPiBDYzogTWljaGFlbCBNZW50aCA8bWVudGhAdW5pLXR1ZWJp bmdlbi5kZT47IEFsZXhhbmRlciBDbGVtbSANCj4gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29t PjsgUm9iZXJ0IE1vc2tvd2l0eiANCj4gPHJnbS1pZXRmQGh0dC1jb25zdWx0LmNvbT47IGlkZWFz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSWRlYXNdIERpYXNhbWJ1Z2F0aW5nIElkZW50aWZp ZXIgYW5kIElkZW50aXR5DQo+IA0KPj4gRm9yIGV4YW1wbGUsIChvbmUgb2YpIHRoZSByZWFsIHJl YXNvbiB3ZSB3YW50IGlkZW50aWZpZXJzIGlzIHRoYXQgd2Ugd2FudCBzb21ldGhpbmcgdGhhdCBk b2VzIG5vdCBjaGFuZ2Ugd2l0aCB0b3BvbG9neSBsb2NhdGlvbnMgdG8gaWRlbnRpZnkgbW9iaWxl IGNvbW11bmljYXRpb24gZW5kIHBvaW50LCB3aGljaCBmdW5jdGlvbnMgdGhhdCBjYW5ub3QgYmUg Y2FycmllZCBieSBJUCBhZGRyZXNzZXMuIFNpbmNlIChJIGJlbGlldmUpIHdlIGFsbCBoYXZlIGNv bnNlbnN1cyBvbiB0aGlzIGZ1bmN0aW9uLCB3ZSBjYW4gYXQgbGVhc3QgYWdyZWUgdGhhdCBpZGVu dGlmaWVyIGlzIHRvcG9sb2d5LWluZGVwZW5kZW50IGxhYmVsIHRoYXQgaWRlbnRpZmllcyBhIGNv bW11bmljYXRpb24gZW5kIHBvaW50LiANCj4gDQo+IEV4YWN0bHkuDQo+IA0KPiBTbyB0byBleHRl bmQgdGhlIGRlZmluaXRpb24gdG8gYmUgc3BlY2lmaWMuIFRoZSBpZGVudGlmaWVyIGlzIHVzZWQg Zm9yIGEgaG9zdCBzdGFjayB0cmFuc3BvcnQgY29ubmVjdGlvbi4gSXRzIHRoZSDigJx0aGluZ+KA nSAodGhlIGFyZ3VtZW50cykgeW91IHBhc3MgdG8gY29ubmVjdCgpLCBiaW5kKCksIHNlbmR0bygp LCBldGMsIHNvY2tldCBBUEkgY2FsbHMuIEFuZCB3aGF0IHlvdSDigJxnZXQgYmFja+KAnSBmcm9t IGdldGhvc3RieW5hbWUoKS4NCj4gDQo+IERpbm8NCj4gDQoNCi0tDQpQcm9mLiBEci4gaGFiaWwu IE1pY2hhZWwgTWVudGgNClVuaXZlcnNpdHkgb2YgVHVlYmluZ2VuDQpGYWN1bHR5IG9mIFNjaWVu Y2UNCkRlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZQ0KQ2hhaXIgb2YgQ29tbXVuaWNhdGlv biBOZXR3b3Jrcw0KU2FuZCAxMywgNzIwNzYgVHVlYmluZ2VuLCBHZXJtYW55DQpwaG9uZTogKCs0 OSktNzA3MS8yOS03MDUwNQ0KZmF4OiAoKzQ5KS03MDcxLzI5LTUyMjANCm1haWx0bzptZW50aEB1 bmktdHVlYmluZ2VuLmRlDQpodHRwOi8va24uaW5mLnVuaS10dWViaW5nZW4uZGUNCg== From nobody Wed Apr 26 19:00:32 2017 Return-Path: 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 338D6127078 for ; Wed, 26 Apr 2017 19:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9qhzZW0Kvh0L for ; Wed, 26 Apr 2017 19:00:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B731205D3 for ; Wed, 26 Apr 2017 19:00:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLV21434; Thu, 27 Apr 2017 02:00:23 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Apr 2017 03:00:22 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Wed, 26 Apr 2017 19:00:10 -0700 From: Alexander Clemm To: Michael Menth , Dino Farinacci , "Liubingyang (Bryan)" CC: Robert Moskowitz , "ideas@ietf.org" Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp916fQ6Ay+5HYEmqQas6XmYXz6HEiTEAgABx9QCAAMPZAIAAAjuAgA+nLqCAAdr0gIAAy1IAgAB7XwD//60WgIAAfKyA///s+2A= Date: Thu, 27 Apr 2017 02:00:08 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93894@SJCEML701-CHM.china.huawei.com> References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.180] 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.0A090204.590150B8.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5271462e6ccc4de9b0f102f77736dfd Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 02:00:28 -0000 SGkgTWljaGFlbCwNCg0KRm9yIHlvdXIgZXhhbXBsZTogeWVzLCB5b3UgY2FuIGRvIHdoYXQgeW91 IGRlc2NyaWJlLiAgT2YgY291cnNlLCB5b3UgbmVlZCB0byBoYXZlIHRoZSBzYW1lIG1ldGFkYXRh IHJlcGxpY2F0ZWQgZm9yIGVhY2ggaWRlbnRpZmllci4gIFdoZW4gdGhlIGVudGl0eSBkZWNpZGVz IHRvIHVzZSBhbm90aGVyIGlkZW50aWZpZXIsIGl0cyBtZXRhZGF0YSBuZWVkcyB0byBiZSBjb3Bp ZWQgYXMgd2VsbC4gIFdoZW4geW91IGNoYW5nZSB0aGUgbWV0YWRhdGEsIHlvdSBuZWVkIHRvIGNo YW5nZSBpdCBpbiBhbGwgcmVjb3Jkcy4gIEFuZCB0aGVyZSBtYXkgYmUgbW9yZSB0aGFuIG9uZSBw aWVjZSBvZiBtZXRhZGF0YTsgZm9yIGV4YW1wbGUsIEkgbWF5IGJlIGFuIGVudGl0eSBvZiBhIGNl cnRhaW4gdHlwZS4gIFdpdGggYSBmbGF0IGlkZW50aWZpZXItb25seSBzY2hlbWUsIHRoZSBkYXRh IG11c3QgYmUgbWFpbnRhaW5lZCByZWR1bmRhbnRseS4gIA0KDQotLS0gQWxleA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBNZW50aCBbbWFpbHRvOm1lbnRoQHVu aS10dWViaW5nZW4uZGVdIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNiwgMjAxNyAxMjo1NiBQ TQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+OyBEaW5v IEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT47IExpdWJpbmd5YW5nIChCcnlhbikgPGxp dWJpbmd5YW5nQGh1YXdlaS5jb20+DQpDYzogUm9iZXJ0IE1vc2tvd2l0eiA8cmdtLWlldGZAaHR0 LWNvbnN1bHQuY29tPjsgaWRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRlYXNdIERpYXNh bWJ1Z2F0aW5nIElkZW50aWZpZXIgYW5kIElkZW50aXR5DQoNCkhpIEFsZXgsDQoNCmNhbid0IGEg Y29udHJhY3QgYmUgcmVwcmVzZW50ZWQgYnkgYSBjb250cmFjdCBpZGVudGlmaWVyIChjaWRYKSB0 byB3aGljaCBzZXZlcmFsIG5ldHdvcmtpbmcgaWRlbnRpZmllcnMgKG5pZG4pIGFyZSBtYXBwZWQ/ DQoNCm5pZDAgLT4gY2lkWA0KbmlkMSAtPiBjaWRYDQpuaWQyIC0+IGNpZFgNCmNpZFggLT4gc29t ZVByb3BlcnR5DQoNClRoaXMgY29udHJhY3QgaWRlbnRpZmllciBtYXkgYmUgbWFwcGVkIHRvIHNv bWUgcHJvcGVydHkgeWllbGRpbmcgYSBraW5kIG9mIGhpZXJhcmNoaWNhbCBtYXBwaW5nLiBXaGF0 IEkgd2FudCB0byBzYXkgaXMsIEkgZG9uJ3Qgc2VlIHRoZSBnYWluIG9mIGFuIGlkZW50aXR5IGNv bmNlcHQgaW4gdGhpcyBleGFtcGxlLg0KDQpJIGFzayBhZ2Fpbjogd2hhdCdzIHRoZSB2YWx1ZSBv ZiBpZGVudGl0aWVzIGJleW9uZCBhdXRoZW50aWNhdGlvbiBmb3IgcmVnaXN0cmF0aW9uIHB1cnBv c2VzPw0KDQpSZWdhcmRzLA0KDQpNaWNoYWVsDQoNCg0KQW0gMjYuMDQuMjAxNyB1bSAyMTozOCBz Y2hyaWViIEFsZXhhbmRlciBDbGVtbToNCj4gWWVzLCBJIHRoaW5rIHdlIGFncmVlIG9uIHRoZSBu b3Rpb24gb2YgaWRlbnRpZmllci4gIA0KPiANCj4gT2YgY291cnNlLCB0aGlzIGlzIG5vdCBqdXN0 IGFib3V0IGlkZW50aWZpZXItIGJ1dCBpZGVudGl0eS1lbmFibGVkIG5ldHdvcmtpbmcsIHNvIHRo ZXJlIGlzIHN0aWxsIHRoYXQgb3RoZXIgYXNwZWN0IG5lZWRpbmcgdG8gYmUgZmxlc2hlZCBvdXQu IFJlOiBNaWNoYWVsJ3MgcXVlc3Rpb24sIGF1dGhlbnRpY2F0aW9uIGlzIG9uZSBvZiBpdHMgYXBw bGljYXRpb25zLCBidXQgSSB0aGluayB0aGVyZSBhcmUgb3RoZXJzLCBmb3IgZXhhbXBsZSByZWxh dGVkIHRvIG1ldGFkYXRhIChiYWNrIHRvIHRoZSBlYXJsaWVyIHBvaW50IG9mIHdoZXRoZXIgaWRl bnRpdHkgaXMgYSBkYXRhIHJlY29yZCkgLSBhbiBleGFtcGxlIHdvdWxkIGJlIHRoZSAidHlwZSIg b2YgZW5kcG9pbnQgd2hpY2ggYXBwbGllcyByZWdhcmRsZXNzIHdoZXRoZXIgb25lIG9yIG1hbnkg aWRlbnRpZmllcnMgYXJlIGJlaW5nIHVzZWQuICBSZWxhdGVkIHRvIG1ldGFkYXRhLCB5b3UgY291 bGQgaGF2ZSBwb2xpY2llcyB0aGF0IGFyZSBhcHBsaWVkIGJhc2VkIG9uIGlkZW50aXR5IChlLmcu IGFuIGVudGl0eSB3aXRoIGEgcGFpZCBjb250cmFjdCksIG5vdCBiYXNlZCBvbiB3aGljaCBvbmUg b2Ygc2V2ZXJhbCBpZGVudGlmaWVycyBhbiBlbnRpdHkgaGFwcGVucyB0byB1c2UuICAgDQo+IA0K PiAtLSBBbGV4DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEaW5v IEZhcmluYWNjaSBbbWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgQXByaWwgMjYsIDIwMTcgMTA6MjYgQU0NCj4gVG86IExpdWJpbmd5YW5nIChCcnlhbikgPGxp dWJpbmd5YW5nQGh1YXdlaS5jb20+DQo+IENjOiBNaWNoYWVsIE1lbnRoIDxtZW50aEB1bmktdHVl YmluZ2VuLmRlPjsgQWxleGFuZGVyIENsZW1tIA0KPiA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5j b20+OyBSb2JlcnQgTW9za293aXR6IA0KPiA8cmdtLWlldGZAaHR0LWNvbnN1bHQuY29tPjsgaWRl YXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJZGVhc10gRGlhc2FtYnVnYXRpbmcgSWRlbnRp ZmllciBhbmQgSWRlbnRpdHkNCj4gDQo+PiBGb3IgZXhhbXBsZSwgKG9uZSBvZikgdGhlIHJlYWwg cmVhc29uIHdlIHdhbnQgaWRlbnRpZmllcnMgaXMgdGhhdCB3ZSB3YW50IHNvbWV0aGluZyB0aGF0 IGRvZXMgbm90IGNoYW5nZSB3aXRoIHRvcG9sb2d5IGxvY2F0aW9ucyB0byBpZGVudGlmeSBtb2Jp bGUgY29tbXVuaWNhdGlvbiBlbmQgcG9pbnQsIHdoaWNoIGZ1bmN0aW9ucyB0aGF0IGNhbm5vdCBi ZSBjYXJyaWVkIGJ5IElQIGFkZHJlc3Nlcy4gU2luY2UgKEkgYmVsaWV2ZSkgd2UgYWxsIGhhdmUg Y29uc2Vuc3VzIG9uIHRoaXMgZnVuY3Rpb24sIHdlIGNhbiBhdCBsZWFzdCBhZ3JlZSB0aGF0IGlk ZW50aWZpZXIgaXMgdG9wb2xvZ3ktaW5kZXBlbmRlbnQgbGFiZWwgdGhhdCBpZGVudGlmaWVzIGEg Y29tbXVuaWNhdGlvbiBlbmQgcG9pbnQuIA0KPiANCj4gRXhhY3RseS4NCj4gDQo+IFNvIHRvIGV4 dGVuZCB0aGUgZGVmaW5pdGlvbiB0byBiZSBzcGVjaWZpYy4gVGhlIGlkZW50aWZpZXIgaXMgdXNl ZCBmb3IgYSBob3N0IHN0YWNrIHRyYW5zcG9ydCBjb25uZWN0aW9uLiBJdHMgdGhlIOKAnHRoaW5n 4oCdICh0aGUgYXJndW1lbnRzKSB5b3UgcGFzcyB0byBjb25uZWN0KCksIGJpbmQoKSwgc2VuZHRv KCksIGV0Yywgc29ja2V0IEFQSSBjYWxscy4gQW5kIHdoYXQgeW91IOKAnGdldCBiYWNr4oCdIGZy b20gZ2V0aG9zdGJ5bmFtZSgpLg0KPiANCj4gRGlubw0KPiANCg0KLS0NClByb2YuIERyLiBoYWJp bC4gTWljaGFlbCBNZW50aA0KVW5pdmVyc2l0eSBvZiBUdWViaW5nZW4NCkZhY3VsdHkgb2YgU2Np ZW5jZQ0KRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlDQpDaGFpciBvZiBDb21tdW5pY2F0 aW9uIE5ldHdvcmtzDQpTYW5kIDEzLCA3MjA3NiBUdWViaW5nZW4sIEdlcm1hbnkNCnBob25lOiAo KzQ5KS03MDcxLzI5LTcwNTA1DQpmYXg6ICgrNDkpLTcwNzEvMjktNTIyMA0KbWFpbHRvOm1lbnRo QHVuaS10dWViaW5nZW4uZGUNCmh0dHA6Ly9rbi5pbmYudW5pLXR1ZWJpbmdlbi5kZQ0K From nobody Thu Apr 27 07:07:14 2017 Return-Path: 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 E29FF12704B for ; Thu, 27 Apr 2017 07:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TjVvosK1TpoC for ; Thu, 27 Apr 2017 07:07:10 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A361294E9 for ; Thu, 27 Apr 2017 07:07:09 -0700 (PDT) Received: from [134.2.11.131] (chaos.informatik.uni-tuebingen.de [134.2.11.131]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 7A7113451; Thu, 27 Apr 2017 16:07:08 +0200 (CEST) To: "Liubingyang (Bryan)" , Alexander Clemm , Dino Farinacci References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> Cc: "ideas@ietf.org" , Robert Moskowitz From: Michael Menth Message-ID: <140d036b-fed3-3156-6ba8-5c76dd973358@uni-tuebingen.de> Date: Thu, 27 Apr 2017 16:06:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:07:13 -0000 Am 27.04.2017 um 03:30 schrieb Liubingyang (Bryan): > Hi Michael, > > What do you mean by authentication? > Is it used by mapping system to authenticate whether an entity can update properties of an identifier, Yes. Regards, Michael or used by the corresponding node to authenticate whether the entity indeed owns the identifier? > > Bingyang (Bryan) > > -----Original Message----- > From: Michael Menth [mailto:menth@uni-tuebingen.de] > Sent: Thursday, April 27, 2017 3:56 AM > To: Alexander Clemm ; Dino Farinacci ; Liubingyang (Bryan) > Cc: Robert Moskowitz ; ideas@ietf.org > Subject: Re: [Ideas] Diasambugating Identifier and Identity > > Hi Alex, > > can't a contract be represented by a contract identifier (cidX) to which several networking identifiers (nidn) are mapped? > > nid0 -> cidX > nid1 -> cidX > nid2 -> cidX > cidX -> someProperty > > This contract identifier may be mapped to some property yielding a kind of hierarchical mapping. What I want to say is, I don't see the gain of an identity concept in this example. > > I ask again: what's the value of identities beyond authentication for registration purposes? > > Regards, > > Michael > > > Am 26.04.2017 um 21:38 schrieb Alexander Clemm: >> Yes, I think we agree on the notion of identifier. >> >> Of course, this is not just about identifier- but identity-enabled networking, so there is still that other aspect needing to be fleshed out. Re: Michael's question, authentication is one of its applications, but I think there are others, for example related to metadata (back to the earlier point of whether identity is a data record) - an example would be the "type" of endpoint which applies regardless whether one or many identifiers are being used. Related to metadata, you could have policies that are applied based on identity (e.g. an entity with a paid contract), not based on which one of several identifiers an entity happens to use. >> >> -- Alex >> >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, April 26, 2017 10:26 AM >> To: Liubingyang (Bryan) >> Cc: Michael Menth ; Alexander Clemm >> ; Robert Moskowitz >> ; ideas@ietf.org >> Subject: Re: [Ideas] Diasambugating Identifier and Identity >> >>> For example, (one of) the real reason we want identifiers is that we want something that does not change with topology locations to identify mobile communication end point, which functions that cannot be carried by IP addresses. Since (I believe) we all have consensus on this function, we can at least agree that identifier is topology-independent label that identifies a communication end point. >> >> Exactly. >> >> So to extend the definition to be specific. The identifier is used for a host stack transport connection. Its the “thing” (the arguments) you pass to connect(), bind(), sendto(), etc, socket API calls. And what you “get back” from gethostbyname(). >> >> Dino >> > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://kn.inf.uni-tuebingen.de > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Apr 27 07:16:22 2017 Return-Path: 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 DDC571294F3 for ; Thu, 27 Apr 2017 07:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EePIl_F3u0mx for ; Thu, 27 Apr 2017 07:16:13 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5654128E19 for ; Thu, 27 Apr 2017 07:16:12 -0700 (PDT) Received: from [134.2.11.131] (chaos.informatik.uni-tuebingen.de [134.2.11.131]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 3F9A33448; Thu, 27 Apr 2017 16:16:11 +0200 (CEST) To: Alexander Clemm , Dino Farinacci , "Liubingyang (Bryan)" References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93894@SJCEML701-CHM.china.huawei.com> Cc: "ideas@ietf.org" , Robert Moskowitz From: Michael Menth Message-ID: <1ae6eac8-3d56-d838-14dc-94a6abccd47f@uni-tuebingen.de> Date: Thu, 27 Apr 2017 16:15:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93894@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:16:15 -0000 Hi Alex, Am 27.04.2017 um 04:00 schrieb Alexander Clemm: > Hi Michael, > > For your example: yes, you can do what you describe. Of course, you need to have the same metadata replicated for each identifier. No, the metadate is mapped only to the single "cidX". But multiplce nidn are mapped to this single contract id. When the entity decides to use another identifier, its metadata needs to be copied as well. No, we just need another mapping nid3 -> cidX When you change the metadata, you need to change it in all records. No, we just need to change the metadata associated to the single "cidX". And there may be more than one piece of metadata; for example, I may be an entity of a certain type. With a flat identifier-only scheme, the data must be maintained redundantly. Hm, not sure what you mean. Regards, Michael > > --- Alex > > -----Original Message----- > From: Michael Menth [mailto:menth@uni-tuebingen.de] > Sent: Wednesday, April 26, 2017 12:56 PM > To: Alexander Clemm ; Dino Farinacci ; Liubingyang (Bryan) > Cc: Robert Moskowitz ; ideas@ietf.org > Subject: Re: [Ideas] Diasambugating Identifier and Identity > > Hi Alex, > > can't a contract be represented by a contract identifier (cidX) to which several networking identifiers (nidn) are mapped? > > nid0 -> cidX > nid1 -> cidX > nid2 -> cidX > cidX -> someProperty > > This contract identifier may be mapped to some property yielding a kind of hierarchical mapping. What I want to say is, I don't see the gain of an identity concept in this example. > > I ask again: what's the value of identities beyond authentication for registration purposes? > > Regards, > > Michael > > > Am 26.04.2017 um 21:38 schrieb Alexander Clemm: >> Yes, I think we agree on the notion of identifier. >> >> Of course, this is not just about identifier- but identity-enabled networking, so there is still that other aspect needing to be fleshed out. Re: Michael's question, authentication is one of its applications, but I think there are others, for example related to metadata (back to the earlier point of whether identity is a data record) - an example would be the "type" of endpoint which applies regardless whether one or many identifiers are being used. Related to metadata, you could have policies that are applied based on identity (e.g. an entity with a paid contract), not based on which one of several identifiers an entity happens to use. >> >> -- Alex >> >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, April 26, 2017 10:26 AM >> To: Liubingyang (Bryan) >> Cc: Michael Menth ; Alexander Clemm >> ; Robert Moskowitz >> ; ideas@ietf.org >> Subject: Re: [Ideas] Diasambugating Identifier and Identity >> >>> For example, (one of) the real reason we want identifiers is that we want something that does not change with topology locations to identify mobile communication end point, which functions that cannot be carried by IP addresses. Since (I believe) we all have consensus on this function, we can at least agree that identifier is topology-independent label that identifies a communication end point. >> >> Exactly. >> >> So to extend the definition to be specific. The identifier is used for a host stack transport connection. Its the “thing” (the arguments) you pass to connect(), bind(), sendto(), etc, socket API calls. And what you “get back” from gethostbyname(). >> >> Dino >> > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://kn.inf.uni-tuebingen.de > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Apr 27 13:07:49 2017 Return-Path: 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 95C4E129AB2 for ; Thu, 27 Apr 2017 13:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iATjqCJV85JG for ; Thu, 27 Apr 2017 13:07:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E5D129B84 for ; Thu, 27 Apr 2017 13:04:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLW65898; Thu, 27 Apr 2017 20:04:20 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Apr 2017 21:04:19 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML702-CHM.china.huawei.com ([169.254.4.233]) with mapi id 14.03.0235.001; Thu, 27 Apr 2017 13:04:11 -0700 From: Alexander Clemm To: Michael Menth , Dino Farinacci , "Liubingyang (Bryan)" CC: "ideas@ietf.org" , Robert Moskowitz Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp916fQ6Ay+5HYEmqQas6XmYXz6HEiTEAgABx9QCAAMPZAIAAAjuAgA+nLqCAAdr0gIAAy1IAgAB7XwD//60WgIAAfKyA///s+2CAAUZkgP//5sOw Date: Thu, 27 Apr 2017 20:04:10 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93AFB@SJCEML701-CHM.china.huawei.com> References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93894@SJCEML701-CHM.china.huawei.com> <1ae6eac8-3d56-d838-14dc-94a6abccd47f@uni-tuebingen.de> In-Reply-To: <1ae6eac8-3d56-d838-14dc-94a6abccd47f@uni-tuebingen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.56] 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.0A020205.59024EC5.0097, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5271462e6ccc4de9b0f102f77736dfd Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 20:07:47 -0000 SGkgTWljaGFlbCwNCg0KSW4geW91ciBleGFtcGxlLCBpdCBzb3VuZHMgYXMgaWYgeW91IGFyZSBl ZmZlY3RpdmVseSBoYXZpbmcgdGhlIGNpZFggdGFrZSBvbiBhIHNpbWlsYXIgcm9sZSBvZiBhbiBp ZGVudGl0eSAtIHZhcmlvdXMgaWRlbnRpZmllcnMgYXJlIGdyb3VwZWQgdG9nZXRoZXIgdW5kZXIg dGhlIHVtYnJlbGxhIG9mIHRoZWlyIHVuaWZ5aW5nIGNpZFgsIHdoaWNoIGlzIG5vdyB1c2VkIGlu IGxpZXUgb2YgLSBidXQgc2ltaWxhciByb2xlIGFzIChtaW51cyB0aGUgYXV0aGVudGljYXRpb24p IC0gYW4gaWRlbnRpdHkuICBZb3UgY2FuIGRvIHRoYXQsIGJ1dCB3aGF0IHlvdSBhcmUgYXJndWlu ZywgdGhlbiwgaXMgaW4gZWZmZWN0IHRvIHJlc3RyaWN0IHRoZSBkaXNjdXNzaW9uIHRvIGlkZW50 aWZpZXJzIGFuZCBpZGVudGlmaWVyLWVuYWJsZWQgbmV0d29ya3M7IGlkZW50aXR5IGFuZCBpZGVu dGl0eS1lbmFibGVkIG5ldHdvcmtzIHdvdWxkIGJlIGEgbWlzbm9tZXIgdW5sZXNzIHVzZWQgYXMg YSBzeW5vbnltLiAgVGhlIHRocmVhZCBzdGFydGVkIHdpdGggZGlzYW1iaWd1YXRpbmcgaWRlbnRp ZmllciBhbmQgaWRlbnRpdHk7IGlmIHdlIGRlY2lkZWQgdGhhdCB3ZSB3YW50IHRvIGhhdmUgYXMg c2NvcGUgZm9yIHRoZSB3b3JrIGlkZW50aWZpZXItZW5hYmxlZCBuZXR3b3JrcyAod2l0aG91dCBu ZWVkIGZvciB0aGUgbm90aW9uIG9mIGlkZW50aXR5IGRpc3RpbmN0IGZyb20gYW4gaWRlbnRpZmll ciksIHRoZSBkaXNhbWJpZ3VhdGlvbiB3b3VsZCBubyBsb25nZXIgbWF0dGVyLiAgDQoNCk9uZSBv dGhlciBjbGFyaWZpY2F0aW9uIGlubGluZSwgPEFMRVg+DQoNCkNoZWVycw0KLS0tIEFsZXgNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgTWVudGggW21haWx0bzpt ZW50aEB1bmktdHVlYmluZ2VuLmRlXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNywgMjAxNyA3 OjE2IEFNDQpUbzogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT47 IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPjsgTGl1YmluZ3lhbmcgKEJyeWFu KSA8bGl1YmluZ3lhbmdAaHVhd2VpLmNvbT4NCkNjOiBpZGVhc0BpZXRmLm9yZzsgUm9iZXJ0IE1v c2tvd2l0eiA8cmdtLWlldGZAaHR0LWNvbnN1bHQuY29tPg0KU3ViamVjdDogUmU6IFtJZGVhc10g RGlhc2FtYnVnYXRpbmcgSWRlbnRpZmllciBhbmQgSWRlbnRpdHkNCg0KSGkgQWxleCwNCg0KQW0g MjcuMDQuMjAxNyB1bSAwNDowMCBzY2hyaWViIEFsZXhhbmRlciBDbGVtbToNCj4gSGkgTWljaGFl bCwNCj4gDQo+IEZvciB5b3VyIGV4YW1wbGU6IHllcywgeW91IGNhbiBkbyB3aGF0IHlvdSBkZXNj cmliZS4gIE9mIGNvdXJzZSwgeW91IG5lZWQgdG8gaGF2ZSB0aGUgc2FtZSBtZXRhZGF0YSByZXBs aWNhdGVkIGZvciBlYWNoIGlkZW50aWZpZXIuICANCk5vLCB0aGUgbWV0YWRhdGUgaXMgbWFwcGVk IG9ubHkgdG8gdGhlIHNpbmdsZSAiY2lkWCIuIEJ1dCBtdWx0aXBsY2UgbmlkbiBhcmUgbWFwcGVk IHRvIHRoaXMgc2luZ2xlIGNvbnRyYWN0IGlkLg0KDQpXaGVuIHRoZSBlbnRpdHkgZGVjaWRlcyB0 byB1c2UgYW5vdGhlciBpZGVudGlmaWVyLCBpdHMgbWV0YWRhdGEgbmVlZHMgdG8gYmUgY29waWVk IGFzIHdlbGwuDQpObywgd2UganVzdCBuZWVkIGFub3RoZXIgbWFwcGluZyBuaWQzIC0+IGNpZFgN Cg0KV2hlbiB5b3UgY2hhbmdlIHRoZSBtZXRhZGF0YSwgeW91IG5lZWQgdG8gY2hhbmdlIGl0IGlu IGFsbCByZWNvcmRzLg0KTm8sIHdlIGp1c3QgbmVlZCB0byBjaGFuZ2UgdGhlIG1ldGFkYXRhIGFz c29jaWF0ZWQgdG8gdGhlIHNpbmdsZSAiY2lkWCIuDQoNCkFuZCB0aGVyZSBtYXkgYmUgbW9yZSB0 aGFuIG9uZSBwaWVjZSBvZiBtZXRhZGF0YTsgZm9yIGV4YW1wbGUsIEkgbWF5IGJlIGFuIGVudGl0 eSBvZiBhIGNlcnRhaW4gdHlwZS4gIFdpdGggYSBmbGF0IGlkZW50aWZpZXItb25seSBzY2hlbWUs IHRoZSBkYXRhIG11c3QgYmUgbWFpbnRhaW5lZCByZWR1bmRhbnRseS4NCkhtLCBub3Qgc3VyZSB3 aGF0IHlvdSBtZWFuLg0KDQo8QUxFWD4gIFdoYXQgSSBtZWFudCBoZXJlIGlzIHRoZXJlIGNhbiBi ZSBvdGhlciBtZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggYW4gZW50aXR5LCBub3QganVzdCB0aGUg Y29udHJhY3QsIGJ1dCBmb3IgZXhhbXBsZSBpbmZvcm1hdGlvbiBvZiB3aGljaCB0eXBlIGEgY2Vy dGFpbiBlbmRwb2ludCBpcyAtIGZvciBleGFtcGxlLCBpZiBpdCBpcyBhIGNvbm5lY3RlZCB2ZWhp Y2xlLCBhIHNlcnZlciwgYSBtb2JpbGUgQ1BFLiAgSWYgYW4gZW50aXR5IGhhcyBzZXZlcmFsIGlk ZW50aWZpZXJzLCBhbmQgdGhlIHNhbWUgbWV0YWRhdGEgYXBwbGllcyB0byBlYWNoLCBpdCBuZWVk cyB0byBiZSBtYWludGFpbmVkIHJlZHVuZGFudGx5ICh1bmxlc3MgeW91IHB1dCBpdCB1bmRlciBz b21lIGNvbW1vbiB1bWJyZWxsYSB0aGF0ICJ1bml0ZXMiIHRoZSBpZGVudGlmaWVycywgc3VjaCBh cyBhbiBpZGVudGl0eSkuICANCjwvQUxFWD4NCiAgDQpSZWdhcmRzLCBNaWNoYWVsDQoNCg0KPiAN Cj4gLS0tIEFsZXgNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1p Y2hhZWwgTWVudGggW21haWx0bzptZW50aEB1bmktdHVlYmluZ2VuLmRlXQ0KPiBTZW50OiBXZWRu ZXNkYXksIEFwcmlsIDI2LCAyMDE3IDEyOjU2IFBNDQo+IFRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFs ZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPjsgRGlubyBGYXJpbmFjY2kgDQo+IDxmYXJpbmFjY2lA Z21haWwuY29tPjsgTGl1YmluZ3lhbmcgKEJyeWFuKSA8bGl1YmluZ3lhbmdAaHVhd2VpLmNvbT4N Cj4gQ2M6IFJvYmVydCBNb3Nrb3dpdHogPHJnbS1pZXRmQGh0dC1jb25zdWx0LmNvbT47IGlkZWFz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSWRlYXNdIERpYXNhbWJ1Z2F0aW5nIElkZW50aWZp ZXIgYW5kIElkZW50aXR5DQo+IA0KPiBIaSBBbGV4LA0KPiANCj4gY2FuJ3QgYSBjb250cmFjdCBi ZSByZXByZXNlbnRlZCBieSBhIGNvbnRyYWN0IGlkZW50aWZpZXIgKGNpZFgpIHRvIHdoaWNoIHNl dmVyYWwgbmV0d29ya2luZyBpZGVudGlmaWVycyAobmlkbikgYXJlIG1hcHBlZD8NCj4gDQo+IG5p ZDAgLT4gY2lkWA0KPiBuaWQxIC0+IGNpZFgNCj4gbmlkMiAtPiBjaWRYDQo+IGNpZFggLT4gc29t ZVByb3BlcnR5DQo+IA0KPiBUaGlzIGNvbnRyYWN0IGlkZW50aWZpZXIgbWF5IGJlIG1hcHBlZCB0 byBzb21lIHByb3BlcnR5IHlpZWxkaW5nIGEga2luZCBvZiBoaWVyYXJjaGljYWwgbWFwcGluZy4g V2hhdCBJIHdhbnQgdG8gc2F5IGlzLCBJIGRvbid0IHNlZSB0aGUgZ2FpbiBvZiBhbiBpZGVudGl0 eSBjb25jZXB0IGluIHRoaXMgZXhhbXBsZS4NCj4gDQo+IEkgYXNrIGFnYWluOiB3aGF0J3MgdGhl IHZhbHVlIG9mIGlkZW50aXRpZXMgYmV5b25kIGF1dGhlbnRpY2F0aW9uIGZvciByZWdpc3RyYXRp b24gcHVycG9zZXM/DQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gTWljaGFlbA0KPiANCj4gDQo+IEFt IDI2LjA0LjIwMTcgdW0gMjE6Mzggc2NocmllYiBBbGV4YW5kZXIgQ2xlbW06DQo+PiBZZXMsIEkg dGhpbmsgd2UgYWdyZWUgb24gdGhlIG5vdGlvbiBvZiBpZGVudGlmaWVyLiAgDQo+Pg0KPj4gT2Yg Y291cnNlLCB0aGlzIGlzIG5vdCBqdXN0IGFib3V0IGlkZW50aWZpZXItIGJ1dCBpZGVudGl0eS1l bmFibGVkIG5ldHdvcmtpbmcsIHNvIHRoZXJlIGlzIHN0aWxsIHRoYXQgb3RoZXIgYXNwZWN0IG5l ZWRpbmcgdG8gYmUgZmxlc2hlZCBvdXQuIFJlOiBNaWNoYWVsJ3MgcXVlc3Rpb24sIGF1dGhlbnRp Y2F0aW9uIGlzIG9uZSBvZiBpdHMgYXBwbGljYXRpb25zLCBidXQgSSB0aGluayB0aGVyZSBhcmUg b3RoZXJzLCBmb3IgZXhhbXBsZSByZWxhdGVkIHRvIG1ldGFkYXRhIChiYWNrIHRvIHRoZSBlYXJs aWVyIHBvaW50IG9mIHdoZXRoZXIgaWRlbnRpdHkgaXMgYSBkYXRhIHJlY29yZCkgLSBhbiBleGFt cGxlIHdvdWxkIGJlIHRoZSAidHlwZSIgb2YgZW5kcG9pbnQgd2hpY2ggYXBwbGllcyByZWdhcmRs ZXNzIHdoZXRoZXIgb25lIG9yIG1hbnkgaWRlbnRpZmllcnMgYXJlIGJlaW5nIHVzZWQuICBSZWxh dGVkIHRvIG1ldGFkYXRhLCB5b3UgY291bGQgaGF2ZSBwb2xpY2llcyB0aGF0IGFyZSBhcHBsaWVk IGJhc2VkIG9uIGlkZW50aXR5IChlLmcuIGFuIGVudGl0eSB3aXRoIGEgcGFpZCBjb250cmFjdCks IG5vdCBiYXNlZCBvbiB3aGljaCBvbmUgb2Ygc2V2ZXJhbCBpZGVudGlmaWVycyBhbiBlbnRpdHkg aGFwcGVucyB0byB1c2UuICAgDQo+Pg0KPj4gLS0gQWxleA0KPj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmluYWNjaUBn bWFpbC5jb21dDQo+PiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI2LCAyMDE3IDEwOjI2IEFNDQo+ PiBUbzogTGl1YmluZ3lhbmcgKEJyeWFuKSA8bGl1YmluZ3lhbmdAaHVhd2VpLmNvbT4NCj4+IENj OiBNaWNoYWVsIE1lbnRoIDxtZW50aEB1bmktdHVlYmluZ2VuLmRlPjsgQWxleGFuZGVyIENsZW1t IA0KPj4gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPjsgUm9iZXJ0IE1vc2tvd2l0eiANCj4+ IDxyZ20taWV0ZkBodHQtY29uc3VsdC5jb20+OyBpZGVhc0BpZXRmLm9yZw0KPj4gU3ViamVjdDog UmU6IFtJZGVhc10gRGlhc2FtYnVnYXRpbmcgSWRlbnRpZmllciBhbmQgSWRlbnRpdHkNCj4+DQo+ Pj4gRm9yIGV4YW1wbGUsIChvbmUgb2YpIHRoZSByZWFsIHJlYXNvbiB3ZSB3YW50IGlkZW50aWZp ZXJzIGlzIHRoYXQgd2Ugd2FudCBzb21ldGhpbmcgdGhhdCBkb2VzIG5vdCBjaGFuZ2Ugd2l0aCB0 b3BvbG9neSBsb2NhdGlvbnMgdG8gaWRlbnRpZnkgbW9iaWxlIGNvbW11bmljYXRpb24gZW5kIHBv aW50LCB3aGljaCBmdW5jdGlvbnMgdGhhdCBjYW5ub3QgYmUgY2FycmllZCBieSBJUCBhZGRyZXNz ZXMuIFNpbmNlIChJIGJlbGlldmUpIHdlIGFsbCBoYXZlIGNvbnNlbnN1cyBvbiB0aGlzIGZ1bmN0 aW9uLCB3ZSBjYW4gYXQgbGVhc3QgYWdyZWUgdGhhdCBpZGVudGlmaWVyIGlzIHRvcG9sb2d5LWlu ZGVwZW5kZW50IGxhYmVsIHRoYXQgaWRlbnRpZmllcyBhIGNvbW11bmljYXRpb24gZW5kIHBvaW50 LiANCj4+DQo+PiBFeGFjdGx5Lg0KPj4NCj4+IFNvIHRvIGV4dGVuZCB0aGUgZGVmaW5pdGlvbiB0 byBiZSBzcGVjaWZpYy4gVGhlIGlkZW50aWZpZXIgaXMgdXNlZCBmb3IgYSBob3N0IHN0YWNrIHRy YW5zcG9ydCBjb25uZWN0aW9uLiBJdHMgdGhlIOKAnHRoaW5n4oCdICh0aGUgYXJndW1lbnRzKSB5 b3UgcGFzcyB0byBjb25uZWN0KCksIGJpbmQoKSwgc2VuZHRvKCksIGV0Yywgc29ja2V0IEFQSSBj YWxscy4gQW5kIHdoYXQgeW91IOKAnGdldCBiYWNr4oCdIGZyb20gZ2V0aG9zdGJ5bmFtZSgpLg0K Pj4NCj4+IERpbm8NCj4+DQo+IA0KPiAtLQ0KPiBQcm9mLiBEci4gaGFiaWwuIE1pY2hhZWwgTWVu dGgNCj4gVW5pdmVyc2l0eSBvZiBUdWViaW5nZW4NCj4gRmFjdWx0eSBvZiBTY2llbmNlDQo+IERl cGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZQ0KPiBDaGFpciBvZiBDb21tdW5pY2F0aW9uIE5l dHdvcmtzDQo+IFNhbmQgMTMsIDcyMDc2IFR1ZWJpbmdlbiwgR2VybWFueQ0KPiBwaG9uZTogKCs0 OSktNzA3MS8yOS03MDUwNQ0KPiBmYXg6ICgrNDkpLTcwNzEvMjktNTIyMA0KPiBtYWlsdG86bWVu dGhAdW5pLXR1ZWJpbmdlbi5kZQ0KPiBodHRwOi8va24uaW5mLnVuaS10dWViaW5nZW4uZGUNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRlYXMg bWFpbGluZyBsaXN0DQo+IElkZWFzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWRlYXMNCj4gDQoNCi0tDQpQcm9mLiBEci4gaGFiaWwuIE1pY2hhZWwg TWVudGgNClVuaXZlcnNpdHkgb2YgVHVlYmluZ2VuDQpGYWN1bHR5IG9mIFNjaWVuY2UNCkRlcGFy dG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZQ0KQ2hhaXIgb2YgQ29tbXVuaWNhdGlvbiBOZXR3b3Jr cw0KU2FuZCAxMywgNzIwNzYgVHVlYmluZ2VuLCBHZXJtYW55DQpwaG9uZTogKCs0OSktNzA3MS8y OS03MDUwNQ0KZmF4OiAoKzQ5KS03MDcxLzI5LTUyMjANCm1haWx0bzptZW50aEB1bmktdHVlYmlu Z2VuLmRlDQpodHRwOi8va24uaW5mLnVuaS10dWViaW5nZW4uZGUNCg== From nobody Thu Apr 27 15:15:11 2017 Return-Path: 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 1525912947A for ; Thu, 27 Apr 2017 15:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 e_l46N-RQMue for ; Thu, 27 Apr 2017 15:15:08 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0805E1270A0 for ; Thu, 27 Apr 2017 15:12:27 -0700 (PDT) Received: from [192.168.1.101] (hsi-kbw-5-56-217-255.hsi17.kabel-badenwuerttemberg.de [5.56.217.255]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 5B09A3E3C8; Fri, 28 Apr 2017 00:12:25 +0200 (CEST) To: Alexander Clemm , Dino Farinacci , "Liubingyang (Bryan)" References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93894@SJCEML701-CHM.china.huawei.com> <1ae6eac8-3d56-d838-14dc-94a6abccd47f@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93AFB@SJCEML701-CHM.china.huawei.com> Cc: "ideas@ietf.org" , Robert Moskowitz From: Michael Menth Message-ID: <54c3d757-bcd6-051e-7785-3941bb41c5c4@uni-tuebingen.de> Date: Fri, 28 Apr 2017 00:12:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93AFB@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:15:11 -0000 Hi Alex, Am 27.04.2017 um 22:04 schrieb Alexander Clemm: > Hi Michael, > > In your example, it sounds as if you are effectively having the cidX take on a similar role of an identity - various identifiers are grouped together under the umbrella of their unifying cidX, which is now used in lieu of - but similar role as (minus the authentication) - an identity. Right. I just want to say that an identity is not necessarily needed to provide joint information for a set of identifiers. You can do that, but what you are arguing, then, is in effect to restrict the discussion to identifiers and identifier-enabled networks; identity and identity-enabled networks would be a misnomer unless used as a synonym. The thread started with disambiguating identifier and identity; if we decided that we want to have as scope for the work identifier-enabled networks (without need for the notion of identity distinct from an identifier), the disambiguation would no longer matter. I don't want to get rid of the term identity, I'd rather like to filter out the very essence of an identity. Is it just the authentication part or something else? Certainly not - because we may have a "cidX" whithout authentication features which is still able to bind several identifiers together. Is an identity just a "collection of data"? No, because if we have another identical collection of data, then we don't know which is which. Can we say it is a distinguishable entity? It may have a collection of data and may also have some means for authentication. If we have equal products without a serial number, we probably wouldn't talk about identities. But with a serial number, they can be distinguished, so that we can talk about identities. However, it's not the serial number or identifier that makes them an identity, it rather the distinguishability which could alternatively be achieved through a collection of data. Hm, too philosophical? Regards, Michael > > One other clarification inline, > > Cheers > --- Alex > > -----Original Message----- > From: Michael Menth [mailto:menth@uni-tuebingen.de] > Sent: Thursday, April 27, 2017 7:16 AM > To: Alexander Clemm ; Dino Farinacci ; Liubingyang (Bryan) > Cc: ideas@ietf.org; Robert Moskowitz > Subject: Re: [Ideas] Diasambugating Identifier and Identity > > Hi Alex, > > Am 27.04.2017 um 04:00 schrieb Alexander Clemm: >> Hi Michael, >> >> For your example: yes, you can do what you describe. Of course, you need to have the same metadata replicated for each identifier. > No, the metadate is mapped only to the single "cidX". But multiplce nidn are mapped to this single contract id. > > When the entity decides to use another identifier, its metadata needs to be copied as well. > No, we just need another mapping nid3 -> cidX > > When you change the metadata, you need to change it in all records. > No, we just need to change the metadata associated to the single "cidX". > > And there may be more than one piece of metadata; for example, I may be an entity of a certain type. With a flat identifier-only scheme, the data must be maintained redundantly. > Hm, not sure what you mean. > > What I meant here is there can be other metadata associated with an entity, not just the contract, but for example information of which type a certain endpoint is - for example, if it is a connected vehicle, a server, a mobile CPE. If an entity has several identifiers, and the same metadata applies to each, it needs to be maintained redundantly (unless you put it under some common umbrella that "unites" the identifiers, such as an identity). > > > Regards, Michael > > >> >> --- Alex >> >> -----Original Message----- >> From: Michael Menth [mailto:menth@uni-tuebingen.de] >> Sent: Wednesday, April 26, 2017 12:56 PM >> To: Alexander Clemm ; Dino Farinacci >> ; Liubingyang (Bryan) >> Cc: Robert Moskowitz ; ideas@ietf.org >> Subject: Re: [Ideas] Diasambugating Identifier and Identity >> >> Hi Alex, >> >> can't a contract be represented by a contract identifier (cidX) to which several networking identifiers (nidn) are mapped? >> >> nid0 -> cidX >> nid1 -> cidX >> nid2 -> cidX >> cidX -> someProperty >> >> This contract identifier may be mapped to some property yielding a kind of hierarchical mapping. What I want to say is, I don't see the gain of an identity concept in this example. >> >> I ask again: what's the value of identities beyond authentication for registration purposes? >> >> Regards, >> >> Michael >> >> >> Am 26.04.2017 um 21:38 schrieb Alexander Clemm: >>> Yes, I think we agree on the notion of identifier. >>> >>> Of course, this is not just about identifier- but identity-enabled networking, so there is still that other aspect needing to be fleshed out. Re: Michael's question, authentication is one of its applications, but I think there are others, for example related to metadata (back to the earlier point of whether identity is a data record) - an example would be the "type" of endpoint which applies regardless whether one or many identifiers are being used. Related to metadata, you could have policies that are applied based on identity (e.g. an entity with a paid contract), not based on which one of several identifiers an entity happens to use. >>> >>> -- Alex >>> >>> -----Original Message----- >>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>> Sent: Wednesday, April 26, 2017 10:26 AM >>> To: Liubingyang (Bryan) >>> Cc: Michael Menth ; Alexander Clemm >>> ; Robert Moskowitz >>> ; ideas@ietf.org >>> Subject: Re: [Ideas] Diasambugating Identifier and Identity >>> >>>> For example, (one of) the real reason we want identifiers is that we want something that does not change with topology locations to identify mobile communication end point, which functions that cannot be carried by IP addresses. Since (I believe) we all have consensus on this function, we can at least agree that identifier is topology-independent label that identifies a communication end point. >>> >>> Exactly. >>> >>> So to extend the definition to be specific. The identifier is used for a host stack transport connection. Its the “thing” (the arguments) you pass to connect(), bind(), sendto(), etc, socket API calls. And what you “get back” from gethostbyname(). >>> >>> Dino >>> >> >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Faculty of Science >> Department of Computer Science >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505 >> fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de >> http://kn.inf.uni-tuebingen.de >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas >> > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://kn.inf.uni-tuebingen.de > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Apr 27 19:06:44 2017 Return-Path: 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 D8E6912953D for ; Thu, 27 Apr 2017 19:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1I4P2Ctx2cum for ; Thu, 27 Apr 2017 19:06:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91895124282 for ; Thu, 27 Apr 2017 19:04:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFQ34095; Fri, 28 Apr 2017 02:04:03 +0000 (GMT) Received: from SZXEMI403-HUB.china.huawei.com (10.82.75.35) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Apr 2017 03:04:02 +0100 Received: from SZXEMI508-MBS.china.huawei.com ([169.254.10.152]) by SZXEMI403-HUB.china.huawei.com ([10.83.65.55]) with mapi id 14.03.0235.001; Fri, 28 Apr 2017 10:03:52 +0800 From: "Liubingyang (Bryan)" To: Michael Menth , Alexander Clemm , Dino Farinacci CC: "ideas@ietf.org" , Robert Moskowitz Thread-Topic: [Ideas] Diasambugating Identifier and Identity Thread-Index: AQHSp914j5eOmWLOQkutGf2RD5x5MqHDjbwAgABx9QCAAMPZAIAAAjuAgBAfzYCAAWJVgIABSuQw///7zQCAACT0gIAABM6AgABlzACAAM2TgIAAYU0AgAAjwwCAALtiQA== Date: Fri, 28 Apr 2017 02:03:51 +0000 Message-ID: References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93894@SJCEML701-CHM.china.huawei.com> <1ae6eac8-3d56-d838-14dc-94a6abccd47f@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93AFB@SJCEML701-CHM.china.huawei.com> <54c3d757-bcd6-051e-7785-3941bb41c5c4@uni-tuebingen.de> In-Reply-To: <54c3d757-bcd6-051e-7785-3941bb41c5c4@uni-tuebingen.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.168.116] 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.0A020205.5902A313.0132, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.10.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9bbd9fb42d3f22b96b673e9c96398629 Archived-At: Subject: Re: [Ideas] Diasambugating Identifier and Identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 02:06:42 -0000 U2VlIGlubGluZSBbQnJ5YW5dDQpJIGhpZ2hseSBzdWdnZXN0IHRoYXQgd2UgY2FuIGxlYXZlIHRo ZSB0ZXJtIGRlZmluaXRpb24gYXNpZGUsIGFuZCB0YWxrIGFib3V0IHdoYXQgZnVuY3Rpb25hbGl0 aWVzIHdlIG5lZWQgaW4gSURFQVMuIElmIHRoZSBmdW5jdGlvbnMgYXJlIGRlY2lkZWQsIHdlIGNh biBnaXZlIHdoYXRldmVyIHRlcm1zIGV2ZXJ5b25lIGlzIGNvbWZvcnRhYmxlIHdpdGguIFRoZSBm dW5jdGlvbnMgYXJlIHJlYWxseSBpbXBvcnRhbnQgdGhpbmdzLCB0aGVuIHRoZSB0ZXJtcy4NCg0K QmVzdA0KQmluZ3lhbmcgKEJyeWFuKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTWljaGFlbCBNZW50aCBbbWFpbHRvOm1lbnRoQHVuaS10dWViaW5nZW4uZGVdIA0KU2VudDog RnJpZGF5LCBBcHJpbCAyOCwgMjAxNyA2OjEyIEFNDQpUbzogQWxleGFuZGVyIENsZW1tIDxhbGV4 YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT47IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwu Y29tPjsgTGl1YmluZ3lhbmcgKEJyeWFuKSA8bGl1YmluZ3lhbmdAaHVhd2VpLmNvbT4NCkNjOiBp ZGVhc0BpZXRmLm9yZzsgUm9iZXJ0IE1vc2tvd2l0eiA8cmdtLWlldGZAaHR0LWNvbnN1bHQuY29t Pg0KU3ViamVjdDogUmU6IFtJZGVhc10gRGlhc2FtYnVnYXRpbmcgSWRlbnRpZmllciBhbmQgSWRl bnRpdHkNCg0KSGkgQWxleCwNCg0KQW0gMjcuMDQuMjAxNyB1bSAyMjowNCBzY2hyaWViIEFsZXhh bmRlciBDbGVtbToNCj4gSGkgTWljaGFlbCwNCj4gDQo+IEluIHlvdXIgZXhhbXBsZSwgaXQgc291 bmRzIGFzIGlmIHlvdSBhcmUgZWZmZWN0aXZlbHkgaGF2aW5nIHRoZSBjaWRYIHRha2Ugb24gYSBz aW1pbGFyIHJvbGUgb2YgYW4gaWRlbnRpdHkgLSB2YXJpb3VzIGlkZW50aWZpZXJzIGFyZSBncm91 cGVkIHRvZ2V0aGVyIHVuZGVyIHRoZSB1bWJyZWxsYSBvZiB0aGVpciB1bmlmeWluZyBjaWRYLCB3 aGljaCBpcyBub3cgdXNlZCBpbiBsaWV1IG9mIC0gYnV0IHNpbWlsYXIgcm9sZSBhcyAobWludXMg dGhlIGF1dGhlbnRpY2F0aW9uKSAtIGFuIGlkZW50aXR5Lg0KUmlnaHQuIEkganVzdCB3YW50IHRv IHNheSB0aGF0IGFuIGlkZW50aXR5IGlzIG5vdCBuZWNlc3NhcmlseSBuZWVkZWQgdG8gcHJvdmlk ZSBqb2ludCBpbmZvcm1hdGlvbiBmb3IgYSBzZXQgb2YgaWRlbnRpZmllcnMuDQoNCiAgWW91IGNh biBkbyB0aGF0LCBidXQgd2hhdCB5b3UgYXJlIGFyZ3VpbmcsIHRoZW4sIGlzIGluIGVmZmVjdCB0 byByZXN0cmljdCB0aGUgZGlzY3Vzc2lvbiB0byBpZGVudGlmaWVycyBhbmQgaWRlbnRpZmllci1l bmFibGVkIG5ldHdvcmtzOyBpZGVudGl0eSBhbmQgaWRlbnRpdHktZW5hYmxlZCBuZXR3b3JrcyB3 b3VsZCBiZSBhIG1pc25vbWVyIHVubGVzcyB1c2VkIGFzIGEgc3lub255bS4gIFRoZSB0aHJlYWQg c3RhcnRlZCB3aXRoIGRpc2FtYmlndWF0aW5nIGlkZW50aWZpZXIgYW5kIGlkZW50aXR5OyBpZiB3 ZSBkZWNpZGVkIHRoYXQgd2Ugd2FudCB0byBoYXZlIGFzIHNjb3BlIGZvciB0aGUgd29yayBpZGVu dGlmaWVyLWVuYWJsZWQgbmV0d29ya3MgKHdpdGhvdXQgbmVlZCBmb3IgdGhlIG5vdGlvbiBvZiBp ZGVudGl0eSBkaXN0aW5jdCBmcm9tIGFuIGlkZW50aWZpZXIpLCB0aGUgZGlzYW1iaWd1YXRpb24g d291bGQgbm8gbG9uZ2VyIG1hdHRlci4NCkkgZG9uJ3Qgd2FudCB0byBnZXQgcmlkIG9mIHRoZSB0 ZXJtIGlkZW50aXR5LCBJJ2QgcmF0aGVyIGxpa2UgdG8gZmlsdGVyIG91dCB0aGUgdmVyeSBlc3Nl bmNlIG9mIGFuIGlkZW50aXR5Lg0KSXMgaXQganVzdCB0aGUgYXV0aGVudGljYXRpb24gcGFydCBv ciBzb21ldGhpbmcgZWxzZT8NCiAgW0JyeWFuXSBBZ3JlZWQgd2l0aCBhbGwgdGhlIGFib3ZlLiBC dHcsIGFuIGlkZW50aXR5IGJ5IGl0c2VsZiBtYXkgbm90IGJlIHN1ZmZpY2llbnQgdG8gcHJvdmlk ZSBhdXRoZW50aWNhdGlvbiB1bmxlc3MgYWNjb21wYW5pZWQgd2l0aCBzb21lIGtleXMsIHRva2Vu cywgZXRjLiBBbmQgaXQgaXMgbm90IG5lY2Vzc2FyeSBuZWl0aGVyIHNpbmNlIG9uZSBjYW4gZG8g YXV0aGVudGljYXRpb24gd2l0aG91dCB0aGUgZGVmaW5pdGlvbiBvZiBpZGVudGl0eS4gDQoNCkNl cnRhaW5seSBub3QgLSBiZWNhdXNlIHdlIG1heSBoYXZlIGEgImNpZFgiIHdoaXRob3V0IGF1dGhl bnRpY2F0aW9uIGZlYXR1cmVzIHdoaWNoIGlzIHN0aWxsIGFibGUgdG8gYmluZCBzZXZlcmFsIGlk ZW50aWZpZXJzIHRvZ2V0aGVyLg0KSXMgYW4gaWRlbnRpdHkganVzdCBhICJjb2xsZWN0aW9uIG9m IGRhdGEiPyBObywgYmVjYXVzZSBpZiB3ZSBoYXZlIGFub3RoZXIgaWRlbnRpY2FsIGNvbGxlY3Rp b24gb2YgZGF0YSwgdGhlbiB3ZSBkb24ndCBrbm93IHdoaWNoIGlzIHdoaWNoLg0KICBbQnJ5YW5d IGlmIHdlIHdhbnQgdG8gYmluZCBzb21lIGlkZW50aWZpZXJzIHRvZ2V0aGVyLCB3ZSBqdXN0IG5l ZWQgYSBzZXQuIElmIHdlIG5lZWQgdG8gZ2l2ZSB0aGUgc2V0IGEgdW5pcXVlIHJlZmVyZW5jZSwg dGhhdCBjb3VsZCBqdXN0IGJlIGEgc2V0IElELCB3aGljaCBjYW4gYmUganVzdCBhbiBpbmRleCBp biBkYXRhYmFzZSBpbnRlcm5hbCBpbXBsZW1lbnRhdGlvbiBhbmQgZG9lc24ndCBoYXZlIHRvIGJl IGdpdmVuIGFuIGV4cGxpY2l0IG1lYW5pbmcuIA0KICBIb3dldmVyLCBpZiB0aGUgc2V0IElEIGl0 c2VsZiBoYXMgc29tZSBwcm9wZXJ0aWVzLCB0aGUgc2V0IElEIGNhbiBoYXZlIHNvbWUgbWVhbmlu Zy4gV2UgY2FuIHVzZSB0aGUgcHJvcGVydGllcyB0byBpbmRpY2F0ZSwgZS5nLiwgdGhpcyBzZXQg bWFwcyB0byBhIHJlYWwgZW50aXR5IGluIHRoZSByZWFsIHdvcmxkLiANCg0KQ2FuIHdlIHNheSBp dCBpcyBhIGRpc3Rpbmd1aXNoYWJsZSBlbnRpdHk/IEl0IG1heSBoYXZlIGEgY29sbGVjdGlvbiBv ZiBkYXRhIGFuZCBtYXkgYWxzbyBoYXZlIHNvbWUgbWVhbnMgZm9yIGF1dGhlbnRpY2F0aW9uLiBJ ZiB3ZSBoYXZlIGVxdWFsIHByb2R1Y3RzIHdpdGhvdXQgYSBzZXJpYWwgbnVtYmVyLCB3ZSBwcm9i YWJseSB3b3VsZG4ndCB0YWxrIGFib3V0IGlkZW50aXRpZXMuIEJ1dCB3aXRoIGEgc2VyaWFsIG51 bWJlciwgdGhleSBjYW4gYmUgZGlzdGluZ3Vpc2hlZCwgc28gdGhhdCB3ZSBjYW4gdGFsayBhYm91 dCBpZGVudGl0aWVzLiBIb3dldmVyLCBpdCdzIG5vdCB0aGUgc2VyaWFsIG51bWJlciBvciBpZGVu dGlmaWVyIHRoYXQgbWFrZXMgdGhlbSBhbiBpZGVudGl0eSwgaXQgcmF0aGVyIHRoZSBkaXN0aW5n dWlzaGFiaWxpdHkgd2hpY2ggY291bGQgYWx0ZXJuYXRpdmVseSBiZSBhY2hpZXZlZCB0aHJvdWdo IGEgY29sbGVjdGlvbiBvZiBkYXRhLiBIbSwgdG9vIHBoaWxvc29waGljYWw/DQogIFtCcnlhbl0g VG8gbXkgdW5kZXJzdGFuZGluZywgcGVvcGxlIGhhdmUgc28gZGlmZmVyZW50IHVuZGVyc3RhbmRp bmcgb2YgdGhlIHRlcm0gImlkZW50aXR5Ii4gU29tZSBtYXkgdGhpbmsgaXQgaXMganVzdCBmb3Ig YXV0aGVudGljYXRpb24gb2Ygb3duZXJzaGlwIG9mIGlkZW50aWZpZXJzLCBsaWtlIEhJIGZvciBI SVQuIFNvbWUgbWF5IHRoaW5rIGl0IGlzIGFuIGF2YXRhciBvZiBhIHJlYWwgd29ybGQgZW50aXR5 LiANCiAgSSBoaWdobHkgc3VnZ2VzdCB0aGF0IHdlIGNhbiBsZWF2ZSB0aGUgdGVybSBkZWZpbml0 aW9uIGFzaWRlLCBhbmQgdGFsayBhYm91dCB3aGF0IGZ1bmN0aW9uYWxpdGllcyB3ZSBuZWVkIGlu IElERUFTLiBJZiB0aGUgZnVuY3Rpb25zIGFyZSBkZWNpZGVkLCB3ZSBjYW4gZ2l2ZSB3aGF0ZXZl ciB0ZXJtcyBldmVyeW9uZSBpcyBjb21mb3J0YWJsZSB3aXRoLiBUaGUgZnVuY3Rpb25zIGFyZSBy ZWFsbHkgaW1wb3J0YW50IHRoaW5ncywgdGhlbiB0aGUgdGVybXMuIA0KDQpSZWdhcmRzLA0KDQpN aWNoYWVsDQoNCg0KPiANCj4gT25lIG90aGVyIGNsYXJpZmljYXRpb24gaW5saW5lLCA8QUxFWD4N Cj4gDQo+IENoZWVycw0KPiAtLS0gQWxleA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogTWljaGFlbCBNZW50aCBbbWFpbHRvOm1lbnRoQHVuaS10dWViaW5nZW4uZGVd DQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNywgMjAxNyA3OjE2IEFNDQo+IFRvOiBBbGV4YW5k ZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPjsgRGlubyBGYXJpbmFjY2kgDQo+ IDxmYXJpbmFjY2lAZ21haWwuY29tPjsgTGl1YmluZ3lhbmcgKEJyeWFuKSA8bGl1YmluZ3lhbmdA aHVhd2VpLmNvbT4NCj4gQ2M6IGlkZWFzQGlldGYub3JnOyBSb2JlcnQgTW9za293aXR6IDxyZ20t aWV0ZkBodHQtY29uc3VsdC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbSWRlYXNdIERpYXNhbWJ1Z2F0 aW5nIElkZW50aWZpZXIgYW5kIElkZW50aXR5DQo+IA0KPiBIaSBBbGV4LA0KPiANCj4gQW0gMjcu MDQuMjAxNyB1bSAwNDowMCBzY2hyaWViIEFsZXhhbmRlciBDbGVtbToNCj4+IEhpIE1pY2hhZWws DQo+Pg0KPj4gRm9yIHlvdXIgZXhhbXBsZTogeWVzLCB5b3UgY2FuIGRvIHdoYXQgeW91IGRlc2Ny aWJlLiAgT2YgY291cnNlLCB5b3UgbmVlZCB0byBoYXZlIHRoZSBzYW1lIG1ldGFkYXRhIHJlcGxp Y2F0ZWQgZm9yIGVhY2ggaWRlbnRpZmllci4gIA0KPiBObywgdGhlIG1ldGFkYXRlIGlzIG1hcHBl ZCBvbmx5IHRvIHRoZSBzaW5nbGUgImNpZFgiLiBCdXQgbXVsdGlwbGNlIG5pZG4gYXJlIG1hcHBl ZCB0byB0aGlzIHNpbmdsZSBjb250cmFjdCBpZC4NCj4gDQo+IFdoZW4gdGhlIGVudGl0eSBkZWNp ZGVzIHRvIHVzZSBhbm90aGVyIGlkZW50aWZpZXIsIGl0cyBtZXRhZGF0YSBuZWVkcyB0byBiZSBj b3BpZWQgYXMgd2VsbC4NCj4gTm8sIHdlIGp1c3QgbmVlZCBhbm90aGVyIG1hcHBpbmcgbmlkMyAt PiBjaWRYDQo+IA0KPiBXaGVuIHlvdSBjaGFuZ2UgdGhlIG1ldGFkYXRhLCB5b3UgbmVlZCB0byBj aGFuZ2UgaXQgaW4gYWxsIHJlY29yZHMuDQo+IE5vLCB3ZSBqdXN0IG5lZWQgdG8gY2hhbmdlIHRo ZSBtZXRhZGF0YSBhc3NvY2lhdGVkIHRvIHRoZSBzaW5nbGUgImNpZFgiLg0KPiANCj4gQW5kIHRo ZXJlIG1heSBiZSBtb3JlIHRoYW4gb25lIHBpZWNlIG9mIG1ldGFkYXRhOyBmb3IgZXhhbXBsZSwg SSBtYXkgYmUgYW4gZW50aXR5IG9mIGEgY2VydGFpbiB0eXBlLiAgV2l0aCBhIGZsYXQgaWRlbnRp Zmllci1vbmx5IHNjaGVtZSwgdGhlIGRhdGEgbXVzdCBiZSBtYWludGFpbmVkIHJlZHVuZGFudGx5 Lg0KPiBIbSwgbm90IHN1cmUgd2hhdCB5b3UgbWVhbi4NCj4gDQo+IDxBTEVYPiAgV2hhdCBJIG1l YW50IGhlcmUgaXMgdGhlcmUgY2FuIGJlIG90aGVyIG1ldGFkYXRhIGFzc29jaWF0ZWQgd2l0aCBh biBlbnRpdHksIG5vdCBqdXN0IHRoZSBjb250cmFjdCwgYnV0IGZvciBleGFtcGxlIGluZm9ybWF0 aW9uIG9mIHdoaWNoIHR5cGUgYSBjZXJ0YWluIGVuZHBvaW50IGlzIC0gZm9yIGV4YW1wbGUsIGlm IGl0IGlzIGEgY29ubmVjdGVkIHZlaGljbGUsIGEgc2VydmVyLCBhIG1vYmlsZSBDUEUuICBJZiBh biBlbnRpdHkgaGFzIHNldmVyYWwgaWRlbnRpZmllcnMsIGFuZCB0aGUgc2FtZSBtZXRhZGF0YSBh cHBsaWVzIHRvIGVhY2gsIGl0IG5lZWRzIHRvIGJlIG1haW50YWluZWQgcmVkdW5kYW50bHkgKHVu bGVzcyB5b3UgcHV0IGl0IHVuZGVyIHNvbWUgY29tbW9uIHVtYnJlbGxhIHRoYXQgInVuaXRlcyIg dGhlIGlkZW50aWZpZXJzLCBzdWNoIGFzIGFuIGlkZW50aXR5KS4gIA0KPiA8L0FMRVg+DQo+ICAg DQo+IFJlZ2FyZHMsIE1pY2hhZWwNCj4gDQo+IA0KPj4NCj4+IC0tLSBBbGV4DQo+Pg0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IE1pY2hhZWwgTWVudGggW21haWx0bzpt ZW50aEB1bmktdHVlYmluZ2VuLmRlXQ0KPj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNiwgMjAx NyAxMjo1NiBQTQ0KPj4gVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdl aS5jb20+OyBEaW5vIEZhcmluYWNjaSANCj4+IDxmYXJpbmFjY2lAZ21haWwuY29tPjsgTGl1Ymlu Z3lhbmcgKEJyeWFuKSA8bGl1YmluZ3lhbmdAaHVhd2VpLmNvbT4NCj4+IENjOiBSb2JlcnQgTW9z a293aXR6IDxyZ20taWV0ZkBodHQtY29uc3VsdC5jb20+OyBpZGVhc0BpZXRmLm9yZw0KPj4gU3Vi amVjdDogUmU6IFtJZGVhc10gRGlhc2FtYnVnYXRpbmcgSWRlbnRpZmllciBhbmQgSWRlbnRpdHkN Cj4+DQo+PiBIaSBBbGV4LA0KPj4NCj4+IGNhbid0IGEgY29udHJhY3QgYmUgcmVwcmVzZW50ZWQg YnkgYSBjb250cmFjdCBpZGVudGlmaWVyIChjaWRYKSB0byB3aGljaCBzZXZlcmFsIG5ldHdvcmtp bmcgaWRlbnRpZmllcnMgKG5pZG4pIGFyZSBtYXBwZWQ/DQo+Pg0KPj4gbmlkMCAtPiBjaWRYDQo+ PiBuaWQxIC0+IGNpZFgNCj4+IG5pZDIgLT4gY2lkWA0KPj4gY2lkWCAtPiBzb21lUHJvcGVydHkN Cj4+DQo+PiBUaGlzIGNvbnRyYWN0IGlkZW50aWZpZXIgbWF5IGJlIG1hcHBlZCB0byBzb21lIHBy b3BlcnR5IHlpZWxkaW5nIGEga2luZCBvZiBoaWVyYXJjaGljYWwgbWFwcGluZy4gV2hhdCBJIHdh bnQgdG8gc2F5IGlzLCBJIGRvbid0IHNlZSB0aGUgZ2FpbiBvZiBhbiBpZGVudGl0eSBjb25jZXB0 IGluIHRoaXMgZXhhbXBsZS4NCj4+DQo+PiBJIGFzayBhZ2Fpbjogd2hhdCdzIHRoZSB2YWx1ZSBv ZiBpZGVudGl0aWVzIGJleW9uZCBhdXRoZW50aWNhdGlvbiBmb3IgcmVnaXN0cmF0aW9uIHB1cnBv c2VzPw0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gTWljaGFlbA0KPj4NCj4+DQo+PiBBbSAyNi4w NC4yMDE3IHVtIDIxOjM4IHNjaHJpZWIgQWxleGFuZGVyIENsZW1tOg0KPj4+IFllcywgSSB0aGlu ayB3ZSBhZ3JlZSBvbiB0aGUgbm90aW9uIG9mIGlkZW50aWZpZXIuICANCj4+Pg0KPj4+IE9mIGNv dXJzZSwgdGhpcyBpcyBub3QganVzdCBhYm91dCBpZGVudGlmaWVyLSBidXQgaWRlbnRpdHktZW5h YmxlZCBuZXR3b3JraW5nLCBzbyB0aGVyZSBpcyBzdGlsbCB0aGF0IG90aGVyIGFzcGVjdCBuZWVk aW5nIHRvIGJlIGZsZXNoZWQgb3V0LiBSZTogTWljaGFlbCdzIHF1ZXN0aW9uLCBhdXRoZW50aWNh dGlvbiBpcyBvbmUgb2YgaXRzIGFwcGxpY2F0aW9ucywgYnV0IEkgdGhpbmsgdGhlcmUgYXJlIG90 aGVycywgZm9yIGV4YW1wbGUgcmVsYXRlZCB0byBtZXRhZGF0YSAoYmFjayB0byB0aGUgZWFybGll ciBwb2ludCBvZiB3aGV0aGVyIGlkZW50aXR5IGlzIGEgZGF0YSByZWNvcmQpIC0gYW4gZXhhbXBs ZSB3b3VsZCBiZSB0aGUgInR5cGUiIG9mIGVuZHBvaW50IHdoaWNoIGFwcGxpZXMgcmVnYXJkbGVz cyB3aGV0aGVyIG9uZSBvciBtYW55IGlkZW50aWZpZXJzIGFyZSBiZWluZyB1c2VkLiAgUmVsYXRl ZCB0byBtZXRhZGF0YSwgeW91IGNvdWxkIGhhdmUgcG9saWNpZXMgdGhhdCBhcmUgYXBwbGllZCBi YXNlZCBvbiBpZGVudGl0eSAoZS5nLiBhbiBlbnRpdHkgd2l0aCBhIHBhaWQgY29udHJhY3QpLCBu b3QgYmFzZWQgb24gd2hpY2ggb25lIG9mIHNldmVyYWwgaWRlbnRpZmllcnMgYW4gZW50aXR5IGhh cHBlbnMgdG8gdXNlLiAgIA0KPj4+DQo+Pj4gLS0gQWxleA0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmluYWNj aUBnbWFpbC5jb21dDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNiwgMjAxNyAxMDoyNiBB TQ0KPj4+IFRvOiBMaXViaW5neWFuZyAoQnJ5YW4pIDxsaXViaW5neWFuZ0BodWF3ZWkuY29tPg0K Pj4+IENjOiBNaWNoYWVsIE1lbnRoIDxtZW50aEB1bmktdHVlYmluZ2VuLmRlPjsgQWxleGFuZGVy IENsZW1tIA0KPj4+IDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT47IFJvYmVydCBNb3Nrb3dp dHogDQo+Pj4gPHJnbS1pZXRmQGh0dC1jb25zdWx0LmNvbT47IGlkZWFzQGlldGYub3JnDQo+Pj4g U3ViamVjdDogUmU6IFtJZGVhc10gRGlhc2FtYnVnYXRpbmcgSWRlbnRpZmllciBhbmQgSWRlbnRp dHkNCj4+Pg0KPj4+PiBGb3IgZXhhbXBsZSwgKG9uZSBvZikgdGhlIHJlYWwgcmVhc29uIHdlIHdh bnQgaWRlbnRpZmllcnMgaXMgdGhhdCB3ZSB3YW50IHNvbWV0aGluZyB0aGF0IGRvZXMgbm90IGNo YW5nZSB3aXRoIHRvcG9sb2d5IGxvY2F0aW9ucyB0byBpZGVudGlmeSBtb2JpbGUgY29tbXVuaWNh dGlvbiBlbmQgcG9pbnQsIHdoaWNoIGZ1bmN0aW9ucyB0aGF0IGNhbm5vdCBiZSBjYXJyaWVkIGJ5 IElQIGFkZHJlc3Nlcy4gU2luY2UgKEkgYmVsaWV2ZSkgd2UgYWxsIGhhdmUgY29uc2Vuc3VzIG9u IHRoaXMgZnVuY3Rpb24sIHdlIGNhbiBhdCBsZWFzdCBhZ3JlZSB0aGF0IGlkZW50aWZpZXIgaXMg dG9wb2xvZ3ktaW5kZXBlbmRlbnQgbGFiZWwgdGhhdCBpZGVudGlmaWVzIGEgY29tbXVuaWNhdGlv biBlbmQgcG9pbnQuIA0KPj4+DQo+Pj4gRXhhY3RseS4NCj4+Pg0KPj4+IFNvIHRvIGV4dGVuZCB0 aGUgZGVmaW5pdGlvbiB0byBiZSBzcGVjaWZpYy4gVGhlIGlkZW50aWZpZXIgaXMgdXNlZCBmb3Ig YSBob3N0IHN0YWNrIHRyYW5zcG9ydCBjb25uZWN0aW9uLiBJdHMgdGhlIOKAnHRoaW5n4oCdICh0 aGUgYXJndW1lbnRzKSB5b3UgcGFzcyB0byBjb25uZWN0KCksIGJpbmQoKSwgc2VuZHRvKCksIGV0 Yywgc29ja2V0IEFQSSBjYWxscy4gQW5kIHdoYXQgeW91IOKAnGdldCBiYWNr4oCdIGZyb20gZ2V0 aG9zdGJ5bmFtZSgpLg0KPj4+DQo+Pj4gRGlubw0KPj4+DQo+Pg0KPj4gLS0NCj4+IFByb2YuIERy LiBoYWJpbC4gTWljaGFlbCBNZW50aA0KPj4gVW5pdmVyc2l0eSBvZiBUdWViaW5nZW4NCj4+IEZh Y3VsdHkgb2YgU2NpZW5jZQ0KPj4gRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlDQo+PiBD aGFpciBvZiBDb21tdW5pY2F0aW9uIE5ldHdvcmtzDQo+PiBTYW5kIDEzLCA3MjA3NiBUdWViaW5n ZW4sIEdlcm1hbnkNCj4+IHBob25lOiAoKzQ5KS03MDcxLzI5LTcwNTA1DQo+PiBmYXg6ICgrNDkp LTcwNzEvMjktNTIyMA0KPj4gbWFpbHRvOm1lbnRoQHVuaS10dWViaW5nZW4uZGUNCj4+IGh0dHA6 Ly9rbi5pbmYudW5pLXR1ZWJpbmdlbi5kZQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IElkZWFzIG1haWxpbmcgbGlzdA0KPj4gSWRlYXNAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRlYXMNCj4+ DQo+IA0KPiAtLQ0KPiBQcm9mLiBEci4gaGFiaWwuIE1pY2hhZWwgTWVudGgNCj4gVW5pdmVyc2l0 eSBvZiBUdWViaW5nZW4NCj4gRmFjdWx0eSBvZiBTY2llbmNlDQo+IERlcGFydG1lbnQgb2YgQ29t cHV0ZXIgU2NpZW5jZQ0KPiBDaGFpciBvZiBDb21tdW5pY2F0aW9uIE5ldHdvcmtzDQo+IFNhbmQg MTMsIDcyMDc2IFR1ZWJpbmdlbiwgR2VybWFueQ0KPiBwaG9uZTogKCs0OSktNzA3MS8yOS03MDUw NQ0KPiBmYXg6ICgrNDkpLTcwNzEvMjktNTIyMA0KPiBtYWlsdG86bWVudGhAdW5pLXR1ZWJpbmdl bi5kZQ0KPiBodHRwOi8va24uaW5mLnVuaS10dWViaW5nZW4uZGUNCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRlYXMgbWFpbGluZyBsaXN0DQo+ IElkZWFzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWRlYXMNCj4gDQoNCi0tDQpQcm9mLiBEci4gaGFiaWwuIE1pY2hhZWwgTWVudGgNClVuaXZlcnNp dHkgb2YgVHVlYmluZ2VuDQpGYWN1bHR5IG9mIFNjaWVuY2UNCkRlcGFydG1lbnQgb2YgQ29tcHV0 ZXIgU2NpZW5jZQ0KQ2hhaXIgb2YgQ29tbXVuaWNhdGlvbiBOZXR3b3Jrcw0KU2FuZCAxMywgNzIw NzYgVHVlYmluZ2VuLCBHZXJtYW55DQpwaG9uZTogKCs0OSktNzA3MS8yOS03MDUwNQ0KZmF4OiAo KzQ5KS03MDcxLzI5LTUyMjANCm1haWx0bzptZW50aEB1bmktdHVlYmluZ2VuLmRlDQpodHRwOi8v a24uaW5mLnVuaS10dWViaW5nZW4uZGUNCg==