Re: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases

Alexander Clemm <alexander.clemm@huawei.com> Tue, 17 October 2017 20:58 UTC

Return-Path: <alexander.clemm@huawei.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5330213219F for <ideas@ietfa.amsl.com>; Tue, 17 Oct 2017 13:58:58 -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, 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 Yi8zOD142llS for <ideas@ietfa.amsl.com>; Tue, 17 Oct 2017 13:58:57 -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 8C5781320B5 for <ideas@ietf.org>; Tue, 17 Oct 2017 13:58:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXY08443; Tue, 17 Oct 2017 20:58:55 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 21:58:54 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Tue, 17 Oct 2017 13:58:51 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Tom Herbert <tom@herbertland.com>
CC: "ideas@ietf.org" <ideas@ietf.org>
Thread-Topic: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
Thread-Index: AdNCJ759WLnyNEFUS8OQ3qb/AaAdvwEO/iGAABpkCnAAN+T9AAAIyVOQ
Date: Tue, 17 Oct 2017 20:58:50 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6CC8@sjceml521-mbx.china.huawei.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5@sjceml521-mbx.china.huawei.com> <CALx6S37C2pKKbVUYj2VN1G6A=DqFd_WPMT9ykowaErBsQrr_hQ@mail.gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB67C5@sjceml521-mbx.china.huawei.com> <CALx6S34R-MWoQ-UATnJvsJB3Qspd9jax-hOFuAT9Ma3eF-eTKQ@mail.gmail.com>
In-Reply-To: <CALx6S34R-MWoQ-UATnJvsJB3Qspd9jax-hOFuAT9Ma3eF-eTKQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.110]
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.0A0B0207.59E66F0F.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: afa5e0de417254cf2e08e7fc38f7ab7a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/uGmhcpmTBTGFyIaZhlryX3hYV4U>
Subject: Re: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2017 20:58:58 -0000

Hi Tom,
One response at the bottom, below
Thanks
--- Alex

> -----Original Message-----
> From: Tom Herbert [mailto:tom@herbertland.com]
> Sent: Tuesday, October 17, 2017 11:03 AM
> To: Alexander Clemm <alexander.clemm@huawei.com>
> Cc: ideas@ietf.org
> Subject: Re: [Ideas] New revision posted on draft-ccm-ideas-identity-use-
> cases
> 
> On Mon, Oct 16, 2017 at 3:38 PM, Alexander Clemm
> <alexander.clemm@huawei.com> wrote:
> > Hello Tom,
> >
> > Thank you for your comments.  Some brief replies, inline, <ALEX>
> >
> > --- Alex
> >
> >> -----Original Message-----
> >> From: Tom Herbert [mailto:tom@herbertland.com]
> >
> >
> > ...
> >
> >> By my count this is at least the fifth definition of identity that
> >> has been proposed either in drafts or on the list, and this one is no
> >> more enlightening than any of the previous definitions. First of all,
> >> this says identity is an "identifier". Does this mean that identity
> >> is a type of identifier per the definition of identifier above?
> >> Secondly, this says identity is used to identify a communication
> >> entity, however above it says an identifier "denotes information to
> >> unambiguously identify a communications entity"-- so both of them
> "identify a communications entity"... I don't see the difference.
> >
> > <ALEX> Well, the definitions are evolving as we hope to get them more
> concise.
> >
> > For that definition: yes, the IDy is an identifier.  However, it is a "special"
> identifier in that it is never revealed in packet header, nor revealed to
> another communications entity - unlike an IDf.
> >
> > Another aspect that is mentioned in the draft, but not in the definitions
> (and we need to revisit this) concerns the distinction between a "second-
> order" (IDf) and a "first-order" identifier (IDy) - the second-order potentially
> be rooted / anchored in the first-order identifier, respectively the first-order
> identifier really denoting a collection / grouping of "second-order" identifiers.
> As mentioned below, perhaps  we should add an articulation such as "" An
> IDy serves as a collection of identifiers that are associated with the same
> endpoint"
> >
> > </ALEX>
> >
> >>
> >> The rest of the draft, including the picture of the relationship
> >> between identifiers, identify, and locators, seems to imply a
> >> potentially more useful and crisp definition of identity. As stated
> >> in the introduction: "An IDy serves as a collection of identifiers
> >> that are associated with the same endpoint". This could be rephrased
> >> to define identity as "a group of identifiers that share some common
> >> properties". Given this "group" definition of identity, then it
> >> becomes natural to consider group policy and group operations over sets
> of identifiers.
> >>
> >
> > <ALEX> I am glad that you find that things are getting crisper - I
> > take it to mean that we are on the right path!  Yes, this is what we
> > need to reflect / incorporate.  However, I think we need to be more
> > specific than just saying IDy refers to a grouping in the general
> > sense - it refers to a grouping of identifiers that refer to the same
> > communications entity  (that is the property they have in common, I
> > guess) </ALEX>
> >
> Alex,
> 
> In my design for ILA I have defined "identifier group" as "a set of identifiers
> or other identifier groups that share some common properties". This is
> derived from the traditional idea of groups of objects that is seen in other
> areas of networking and computer science. Identifier groups can be created
> for ad hoc purposes and is distinct from identity. Being a member of group
> does not imply that an identity is derived from the group. The analogy is that
> you and I may have subscribed to IDEAS mailing list which is a group, but I
> don't think that the mailing list gives me an identity nor that you and I now
> share an identity by virtue of subscribing to the same list.
> Identity might be a possible property of an identifier group I suppose, but I
> would need to think that through and have a better understanding of exactly
> what identity is.
> 
> Anyway, I have a draft on the concept of identifier groups and some
> examples of their use if anyone is interested.
> 
> Tom

Sure, there are uses for grouping services.   But just to be clear, what we had in mind with regards to IDy, while it serves as a special purpose "group" (or really, a collection) there are a few differences compared to a general-purpose group.  Specifically, with general groups, you could have many-to-many relationships - the same entity could be part of many groups.  In this case, the same IDf would generally contained in one, and only one group.  
--- Alex