Re: future of identifiers

"Fred Baker (fred)" <fred@cisco.com> Fri, 01 November 2013 19:48 UTC

Return-Path: <fred@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDAC11E8179 for <ietf@ietfa.amsl.com>; Fri, 1 Nov 2013 12:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.519
X-Spam-Level:
X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUxoHVmdaLVf for <ietf@ietfa.amsl.com>; Fri, 1 Nov 2013 12:48:32 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 13A7111E811D for <ietf@ietf.org>; Fri, 1 Nov 2013 12:48:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3163; q=dns/txt; s=iport; t=1383335312; x=1384544912; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3bOVboyY9jdoJzIsnMXJwfvo3GcLQp+fv8j6etg4YL8=; b=OdYGrNXHgXoLc9B2R5xbb3END+O3hWHcpA/OH5lnrwJ/SDooriAfG7Ox C9hKAwAQnxHhs29i/CTfCHD9ekZKW8cy5vZ4cZLxKHgF+Lgp1BIYdYzlF LXyAvFbV8+ML7qxLhkilvRgew0PFkFv3FzDTwNqpGcwKyDlug1UVreIgZ g=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAMoEdFKtJV2b/2dsb2JhbABPCoMHOFO/ZIEfFnSCJQEBAQMBeQULAgEIIiQyJQIEDgUIAQUNh2YGDb00jhUKgQgxB4MggQ4DkC6BMJg1gyaBcTk
X-IronPort-AV: E=Sophos; i="4.93,618,1378857600"; d="asc'?scan'208"; a="279610612"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 01 Nov 2013 19:48:31 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA1JmVmb022972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 19:48:31 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 1 Nov 2013 14:48:30 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: future of identifiers
Thread-Topic: future of identifiers
Thread-Index: AQHO1LTRdqeJ7pMTBkGukKPpV2N3gpoRIRKA
Date: Fri, 01 Nov 2013 19:48:30 +0000
Message-ID: <8C48B86A895913448548E6D15DA7553BA85458@xmb-rcd-x09.cisco.com>
References: <9F02AA5D-4146-4F8D-B635-DE5B44A9DA9A@piuha.net>
In-Reply-To: <9F02AA5D-4146-4F8D-B635-DE5B44A9DA9A@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.120]
Content-Type: multipart/signed; boundary="Apple-Mail=_2164A4DE-3423-402D-ADB6-EB0F8C1ACCDB"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "ietf@ietf.org Discussion" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2013 19:48:37 -0000

Just a suggestion, but...

it might be a good thing if we were to first identify what needs to be identified.

I think RFC 1992's model of an identifier (a string of some kind that identifies an application API, and moves with the API) makes a lot of sense. Such a thing would, for example, simplify VM motion in data centers. Taking that model into information-centric/name-based networking, one could imagine it being a string that an application uses to identify itself when it expresses interest in a class of data.

If it's something along those lines, I doubt that it's in any character set, and by the way, while it might have a current-set-of-ip-addresses, it's not an IP address or the EID component of one. I could imagine it being almost anything that can be built into a string, and then signed using an 802.1AR certificate or one from another source.

I could imagine law enforcement "expressing interest" in an interesting party's communications. Or the mafia, or the person's spouse. There might be some interesting security angles.

But seriously, I'd suggest we start from first principles before thinking about solutions here. What needs to be identified, and what characteristics does it have?

On Oct 29, 2013, at 7:38 AM, Jari Arkko <jari.arkko@piuha.net> wrote:

> For background, when I visited the ICANN meeting last summer, they were about to launch a set of panels to advice themselves about key topics in coming years. I promised to join one of them, on identifier technology innovation (along with a few other IETFers). The topic for this effort is future evolution of DNS and other identifiers, including relevant security and management aspects. The viewpoint is primarily to look at this from ICANN’s angle, but of course the matter is interesting to us others as well. 
> 
> And perhaps we at the IETF should also understand the same things. Hence this e-mail.
> 
> I have some ideas on what some of these trends might be. But what do the rest of you think? Where is identifier technology going, and what new things are on the horizon? What do we need to do with IDNs? DNSSEC? What will DANE lead to, and how will id-locator split techniques evolve & be deployed? How will applications or users think about identifiers in the future?
> 
> More information at http://www.ietf.org/blog/2013/10/future-identifiers/
> 
> Jari
>