Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 04 October 2017 21:56 UTC
Return-Path: <brian.e.carpenter@gmail.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 103D61344BB; Wed, 4 Oct 2017 14:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 dA4pQxONFVUd; Wed, 4 Oct 2017 14:56:47 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 364691323B4; Wed, 4 Oct 2017 14:56:47 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id m18so1115589pgd.13; Wed, 04 Oct 2017 14:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/o1mGaaI/C+mzDykgr1H3K1J0TNu50yE9WzF7ha9rlM=; b=lRPKpHt2JTlqTYx+W1UfRtxuH9ECbh5yj24AnINcf+qofdqustwmOHHEYSoaXvj3xS wFhxLSrhq4AdtGHKjI7eY/sq+L0NIBN0IT+o4yIBPdI4kvFcTbgU3aJpo93TS8ovWTnM ToqXmKifuYiH0VCQUzf9jImh8j6VBC18jKRLMGiMZBn+bY7JNR29Ujge70yKjJj6h6Jp 2DON4g78ZizZLPnHDq4PfSTzZl21rQ5yxDEp+ev6j9OBrxbV4sRXlezhxDOv15xkojuP 6IiaOQdGIFGBiBeJhd7gYme7qREg4qRCwyh2B68ltxSKX8UbWwxip4kjExrQ4hGtoF7B yt2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/o1mGaaI/C+mzDykgr1H3K1J0TNu50yE9WzF7ha9rlM=; b=sT4ZAiqXHRQKfcojIkxEdfFxZZhPPRKS9KZqUTjCDvINkRWcWWhFnZxVJ5MWMizN8U ScXXqm299Mj5jqwJ87oQeLxQiK+ZoLZ/ZAVwWRcqK4hnvioZlM92L9qxvVgLqolqvbxP dzCFg7GB5yzp1n51CDPjNMJkR0OysKsBP6fAgOFOfVTNF5uJJgVk6yfL/4o6jfo4QDAT rwjlYxWo4sOzbwDQs2+Mf+TmR02zfMxmHtV34xpDgbCDZQ3WheoJ2ZblL4R6zMTIcLsk /r76iwjnWgJY2miAYIszhBKqyBCNVCEITi4UKgi3elLDK6RhieHT+Ursb7R51QY7S3Vr tFYQ==
X-Gm-Message-State: AMCzsaVnwgSe7Gy7otoeAeoPIMk1lSmPG8DleD7TRrh9gRfbX/gepvkl DeZh/M7lhhpwNXJfVUDZZadzsw==
X-Google-Smtp-Source: AOwi7QARZLO4ur64GE2PoBEnSh+aN0VqqNPt8wJSNC0ceuKlEeTUjBtBtlzvmiH/yG/ExFjHrS/1Qg==
X-Received: by 10.99.52.196 with SMTP id b187mr10877726pga.222.1507154206282; Wed, 04 Oct 2017 14:56:46 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 207sm27070335pfu.0.2017.10.04.14.56.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 14:56:45 -0700 (PDT)
To: Dino Farinacci <farinacci@gmail.com>
Cc: "ideas@ietf.org" <ideas@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <CAMm+Lwg61PGrcmu=-e8ciD6Q+XmEaWWDys4g2M657VOjWmaGcg@mail.gmail.com> <CALx6S370-TuoUicWep5vV2NjLPS4d-HP1qVxW_nGrxhBLw6Eug@mail.gmail.com> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <dd2c3bd5-dd37-109b-2e81-0327db4daa09@cs.tcd.ie> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>
Date: Thu, 05 Oct 2017 10:56:48 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/6nCbZZoO8PF-1ZKvD_7eDRaVZo0>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
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: Wed, 04 Oct 2017 21:56:50 -0000
On 05/10/2017 09:35, Dino Farinacci wrote: > Adding lisp@ietf.org to cc list. > > How about creating a working group that solely focuses on deployment of a mapping system and does not specify how and where identifiers are allocated? That seems reasonable, well defined and relatively uncontentious. The current proposed charter leaves me a bit puzzled. Firstly I agree that the name 'IDEAS' is misleading, and 'GRIDS' tramples on previous work, and 'identity' is a red flag. But if we get past terminology distractions, where's the meat? All the interesting stuff is relegated to drafts or a wiki, and the output is a 'framework'. The IETF has a very mixed record with 'framework' documents. Brian > > I have made suggestions before that such a working group should be in the ops area. Some examples include and are not limited to v6ops, dnsop, and mboned. > > Cheers, > Dino > >> On Oct 4, 2017, at 12:45 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: >> >> >> Hiya, >> >> TL;DR - I am now even more convinced that this ought not >> go ahead. (Sorry;-) >> >> On 04/10/17 19:48, Alexander Clemm wrote: >>> There were a couple of things raised in the overall thread that I >>> just wanted to quickly respond to: >>> >>> Clearly privacy is an important issue and concern. The current >>> charter proposal includes a requirement for a detailed analysis of >>> this aspect. If this aspect needs to be expanded, sure, let's do >>> this. >> >> TBH, I don't think that'd help, for me at least. I don't >> see any way in which such permanent strings representing >> identity can be defined to be usable as claimed and not >> be perniciously privacy invasive. So some promises to >> ponder the problem in charter text wouldn't do it for >> me. (And tbh, I've seen that can kicked down that road >> before, so I'm skeptical of such promises in general.) >> >>> Everyone seems to be jumping up and down regarding the use of the >>> term of "identity" as if a foregone conclusion that this is a synonym >>> for "privacy invasion". However: - "Identity" does not imply >>> "personal identity". Really, this is an identifier scheme for >>> endpoints. >> >> Sorry, what I assume is the relevant draft [1] says the "identity" >> (denoted "IDy") is a "Unique and Permanent Identity" and that >> "Networks may treat traffic differently depending on the IDy of >> source or destination" and also seems to envisage a large logical >> database of everyone's IDy's: "Identity also allows to have metadata >> associated it to be applied, regardless of which IDf is used to >> refer it." (Where IDf is the identifier that'll later be mapped >> to a locator via, I assume, HIP or LISP or similar.) >> >> I think it's entirely correct to jump up and down about the >> privacy consequences of the above. (Not to mention the potential >> censorship and discriminatory aspects.) >> >> [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01 >> >>> Perhaps even "identity" is a misnomer. >> >> Well, it was presumably your choice (where your == some set of >> the proponents). If that's a mistake, then it seems a fairly >> fatal one - to get the name wrong for an effort all about mapping >> names to identifiers;-) >> >>> If you will, >>> identity as conceived in the context of IDEAS is a second level of >>> identifier that does not have to be exposed over the data plane - >>> Because of this, it may result in greater privacy than existing >>> schemes, not less. >> >> I see that argument in [1] but I'm not buying it tbh. To get >> that level of protection from such an indirection, one would >> have to have something like Tor hidden services and perhaps >> one would have to *not* standardise the mapping from human >> meaningful identifiers to those used as IDf, and esp. not the >> reverse mapping. Defining that reverse mapping cannot but be >> privacy invasive afaics. (There could maybe be ways to define >> how an already hashed human meaningful identifier could then >> be further hashed to become an IDy but I don't really see the >> point of that at all, other than to just standardise something >> for the fun of the process.) >> >>> It enables you, for example, to obfuscate >>> endpoints to outside observers as you wouldn't need to use personal >>> unique long-lived identifiers, quite the contrary. - There is also a >>> security dimension here. If I am victim of a phishing attack because >>> my network information (like today) is exposed to botnets, >> >> (Nit: that says nothing about being a victim of, only of being >> a target of, an attempted attack. Speaking of victims also >> tends not to lead to more objective analysis, so I think it's >> better to not go there unless it's relevant, which I don't >> think is the case here, because...) >> >> I don't understand what network information you mean. If you >> mean email addresses, and are proposing that the email ecosystem >> change to use some IDf or LOC values, that doesn't seem at all >> realistic to me. If you don't mean email addresses then I don't >> see how any lower layer change will affect attempted phishes. >> The routing area is probably also the entirely wrong venue for >> any real anti-phishing effort. >> >> That really wasn't a good example;-) >> >>> phishers >>> etc who can hide from me (but not I from them) and remain anonymous >>> or impersonate legitimate users, I do consider this a very serious >>> threat also to my privacy. How can IETF counteract such threats? I >>> think that IDEAS, if done right, can provide a contribution here. >> >> I don't see that at all. Unless I'm mistaken that seems like >> wishful thinking to me. >> >>> >>> One aspect that has been missing from the discussion is the question >>> whether there is a distinction between the network provider who >>> provides GRIDS services and an outside attacker / observer. I think >>> this distinction is important. The way I see it, if done right >>> (sure, big "if", and requiring detailed analysis), IDEAS as I would >>> envision it can contribute greatly to provide greater security and >>> privacy from outside attackers. At the same time, as it is currently >>> envisioned, there clearly is a trust relationship between an entity >>> and the provider of "its" GRIDS services. The mapping database will >>> have information about locator-identifier and identifier-identifier >>> mappings, so GRIDS will know which identifiers its endpoints are >>> using. Clearly, if this trust is abused because the provider cannot >>> be trusted, if you are concerned that it sells your endpoint’s >>> information to the mob or a suppressive government, there is an >>> issue. However, when concerned about this scenario, it seems to me >>> one would have equal reason to e.g. not trust your mobile service >>> provider either, who can track you, knows your location, and has your >>> customer data. >> >> ISTM that introducing that GRIDS thing makes matters worse and not >> better, because, as you yourself say, it is clear that whoever has >> access to the GRIDS information would be better able to track people >> compared to now. >> >> I would prefer to see fewer long lived identifiers in networking >> and not more, and this proposal introduces more long lived identifiers >> (erroneously calling those identities). >> >> Regardless of what one thinks of them, given that things like >> HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit >> adding this extra layer of indirection with a privacy invasive >> "Unique and Permanent" identifier which seems to be the only >> non-overlapping part of this work - in fact I only see downsides. >> >> Cheers, >> S. >> >> >>> >>> --- Alex >>> >>> >>>> -----Original Message----- From: Ideas >>>> [mailto:ideas-bounces@ietf.org] On Behalf Of >>>> stephen.farrell@cs.tcd.ie Sent: Wednesday, October 04, 2017 9:35 >>>> AM To: tom@herbertland.com Cc: ideas@ietf.org; >>>> phill@hallambaker.com; ietf@ietf.org Subject: Re: [Ideas] WG >>>> Review: IDentity Enabled Networks (ideas) >>>> >>>> >>>> >>>> On Wednesday, 4 October 2017, Tom Herbert wrote: >>>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker >>>>> <phill@hallambaker.com> wrote: >>>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell >>>>>> <stephen.farrell@cs.tcd.ie> wrote: >>>>>>> >>>>>>> >>>>>>> As currently described, I oppose creation of this working >>>>>>> group on the basis that it enables and seemingly encourages >>>>>>> embedding identifiers for humans as addresses. Doing so would >>>>>>> have significant privacy downsides, would enable new methods >>>>>>> for censorship and discrimination, and could be very hard to >>>>>>> mitigate should one wish to help protect people's privacy, as >>>>>>> I think is current IETF policy. >>>>>>> >>>>>>> If the work precluded the use of any identifiers that >>>>>>> strongly map to humans then I'd be ok with it being done as >>>>>>> it'd then only be a waste of resources. But I don't know how >>>>>>> that could be enforced so I think it'd be better to just not >>>>>>> do this work at all. >>>>>>> >>>>>>> S. >>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> I know how to restrict the work to 'meaningless' identifiers, >>>>>> require that the identifiers be the output of a cryptographic >>>>>> algorithm. >>>>>> >>>>>> Now strictly speaking, this only limits scope to identifiers >>>>>> that are indexical as opposed to rendering them meaningless but >>>>>> I think that was the sense of it. >>>>>> >>>>>> >>>>>> Nöth proposed a trichotemy of identifiers as follows >>>>>> >>>>>> * Identity, the signifier is the signified (e.g. data: URI) >>>>>> >>>>>> * Indexical, the signifier is related to the signified by a >>>>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP >>>>>> fingerprints etc.) >>>>>> >>>>>> * Names, the signifier is the related to the signified by a >>>>>> purely conventional relationship, (e.g. example.com to its >>>>>> owner) >>>>>> >>>>>> >>>>>> There is a big difference between attempting to manage >>>>>> indexical signifiers and names. Especially when the people >>>>>> trying to do so refuse to read any of the literature on >>>>>> semiotics. >>>>>> >>>>>> Names are problematic because the only way that a conventional >>>>>> relationship can be implemented is through some sort of >>>>>> registration infrastructure and we already have one of those >>>>>> and the industry that manages it has a marketcap in the tens of >>>>>> billions. >>>>>> >>>>>> Identifiers do lead to tractable solutions. But, this proposal >>>>>> looks a bit unfocused for IRTF consideration, an IETF WG? >>>>>> Really? >>>>>> >>>>> Identifiers are equivalent to addresses in that they indicate a >>>>> node in the network for the purposes of end to end >>>>> communications. The only difference between identifiers and >>>>> addresses is that identifiers are not topological. Virtual >>>>> addresses in network virtualization are also identifiers. So the >>>>> security properties are the same when considering privacy. For >>>>> instance, if applications use temporary addresses for privacy, it >>>>> would have equivalent properties using temporary identifiers. In >>>>> fact from the application POV this would be transparent. It could >>>>> get a pool of apparently random addresses to choose from as >>>>> source of communication, it shouldn't know or even care if the >>>>> addresses are identifiers. >>>>> >>>>> Identity is a completely separate concept from identifiers. Is >>>>> not required in any of the identifier/locator protocols and AFAIK >>>>> none of them even mention the term. There is no association of an >>>>> identity of user behind and identifier any more than there is an >>>>> association of identity behind IP address. The fact that the >>>>> words "identifier" and "identity" share a common prefix is an >>>>> unfortunate happenstance :-). >>>> >>>> >>>> Yes. But doesn't that mean either the name of this effort is wildly >>>> misleading or else the effort is hugely problematic from a privacy >>>> POV? Either way, istm this ought not proceed. >>>> >>>> S. >>>> >>>>> >>>>> Tom >>>>> >>>> _______________________________________________ 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 > > . >
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Tom Herbert
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Tom Herbert
- Re: [Ideas] WG Review: IDentity Enabled Networks … Dino Farinacci
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Templin, Fred L
- [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled… Christian Huitema
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Templin, Fred L
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Tom Herbert
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Templin, Fred L
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Christian Huitema
- Re: [Ideas] WG Review: IDentity Enabled Networks … Christian Huitema
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Templin, Fred L
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Robert Moskowitz
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Uma Chunduri
- Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Ena… Robert Moskowitz
- Re: [Ideas] WG Review: IDentity Enabled Networks … Stephen Farrell
- [Ideas] WG Review: IDentity Enabled Networks (ide… The IESG
- Re: [Ideas] WG Review: IDentity Enabled Networks … Phillip Hallam-Baker
- Re: [Ideas] WG Review: IDentity Enabled Networks … Tom Herbert
- Re: [Ideas] WG Review: IDentity Enabled Networks … stephen.farrell
- Re: [Ideas] WG Review: IDentity Enabled Networks … John C Klensin
- Re: [Ideas] WG Review: IDentity Enabled Networks … Tom Herbert
- Re: [Ideas] WG Review: IDentity Enabled Networks … Alexander Clemm
- Re: [Ideas] WG Review: IDentity Enabled Networks … Eggert, Lars
- Re: [Ideas] WG Review: IDentity Enabled Networks … Stephen Farrell
- Re: [Ideas] WG Review: IDentity Enabled Networks … Dino Farinacci
- Re: [Ideas] WG Review: IDentity Enabled Networks … Stephen Farrell
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padmadevi Pillay Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Jari Arkko
- Re: [Ideas] WG Review: IDentity Enabled Networks … Joel M. Halpern
- Re: [Ideas] WG Review: IDentity Enabled Networks … Brian E Carpenter
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Joel M. Halpern
- Re: [Ideas] WG Review: IDentity Enabled Networks … Alexander Clemm
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Tom Herbert
- Re: [Ideas] WG Review: IDentity Enabled Networks … Dino Farinacci
- Re: [Ideas] WG Review: IDentity Enabled Networks … Yingzhen Qu
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Joel M. Halpern
- Re: [Ideas] WG Review: IDentity Enabled Networks … Benjamin Kaduk
- Re: [Ideas] WG Review: IDentity Enabled Networks … Joel Halpern Direct
- Re: [Ideas] WG Review: IDentity Enabled Networks … Mike StJohns
- Re: [Ideas] WG Review: IDentity Enabled Networks … Phillip Hallam-Baker
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Joel M. Halpern
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] Fwd: Re: WG Review: IDentity Enabled … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Dino Farinacci
- Re: [Ideas] WG Review: IDentity Enabled Networks … Dino Farinacci
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Georgios Karagiannis
- Re: [Ideas] WG Review: IDentity Enabled Networks … Stephen Farrell
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Stephen Farrell
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … S Moonesamy
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … S Moonesamy
- Re: [Ideas] WG Review: IDentity Enabled Networks … Tom Herbert
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Tom Herbert
- Re: [Ideas] WG Review: IDentity Enabled Networks … S Moonesamy
- Re: [Ideas] WG Review: IDentity Enabled Networks … Alexander Clemm
- Re: [Ideas] WG Review: IDentity Enabled Networks … Alvaro Retana
- Re: [Ideas] WG Review: IDentity Enabled Networks … Robert Moskowitz
- Re: [Ideas] WG Review: IDentity Enabled Networks … Stephen Farrell
- Re: [Ideas] WG Review: IDentity Enabled Networks … Randy Bush
- Re: [Ideas] WG Review: IDentity Enabled Networks … Eggert, Lars
- Re: [Ideas] WG Review: IDentity Enabled Networks … Stephen Farrell
- Re: [Ideas] WG Review: IDentity Enabled Networks … Uma Chunduri
- Re: [Ideas] WG Review: IDentity Enabled Networks … Randy Bush
- Re: [Ideas] WG Review: IDentity Enabled Networks … Jeff Tantsura
- Re: [Ideas] WG Review: IDentity Enabled Networks … Randy Bush
- Re: [Ideas] WG Review: IDentity Enabled Networks … Robert Moskowitz
- Re: [Ideas] WG Review: IDentity Enabled Networks … Robert Moskowitz
- Re: [Ideas] WG Review: IDentity Enabled Networks … Christian Huitema
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Padma Pillay-Esnault
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Alexander Clemm
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Christian Huitema
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Dino Farinacci
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Eric Rescorla
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Dino Farinacci
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Eric Rescorla
- Re: [Ideas] WG Review: IDentity Enabled Networks … Padma Pillay-Esnault
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Dino Farinacci
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Eric Rescorla
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Sam Sun
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Dino Farinacci
- Re: [Ideas] WG Review: IDentity Enabled Networks … Georgios Karagiannis
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Toerless Eckert
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Tom Herbert
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Toerless Eckert
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Tom Herbert
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… John C Klensin
- Re: [Ideas] [lisp] WG Review: IDentity Enabled Ne… Toerless Eckert