Subject: RE: [Enum] Portable unique identifiers

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 2 Mar 2000 14:52:52 -0500

1. An authority that manages globally unique IDs of a geographically "flat"
address space exists already: the IEEE. I think that they could manage
portable IDs as they manage MAC addresses. It's a similar problem, and no
one seems to attribute partisanship there.

2. A name-to-number mapping would work too. I proposed such a scheme to the
ATMF (atmf 98-0383) a couple of years ago. Any number of schemes could be
adopted to do such a thing.

Bert
[email-masked]

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Thursday, March 02, 2000 2:05 PM
> To: Manfredi, Albert E; [email-masked]
> Cc: ION Group (E-mail)
> Subject: RE: [Enum] Portable unique identifiers
> 
> 
> 
> Two points:
> 
> 1) I enter domain addresses with some regularity on the 6-key 
> pad of my
> Glenayre pager and the somewhat larger keypads of my Nokia 
> cellphone and the
> (CLASSIFIED) sipphone on my desk at home. Seems to work OK.
> 
> 2) Attempts to define the "One True Name" tend to be fraught 
> with peril.
> Joke: Why not just make everyone in the world a US Taxpayer 
> and use their
> Taxpayer ID Number (also called Social Security Number) as 
> their Universal
> ID? But this points out the real problem -- Who will be the 
> root source of
> Universal Identity? ICANN? Will any choice be acceptable to 
> the great mass
> of users? We've even seen the single-root fight going on in 
> DNS regularly .
> . .
> 
> RFC 2486 seems to recognize that the answer to #2 is "no" -- 
> there will be
> many sources of identity (domains) and many users or devices 
> will demand
> multiple identities. I think that to make it really operable 
> requires a
> single-root registry of domains, like DNS.
> 
> I seem to remember proposals a while back to do a 
> name-to-number mapping,
> such that any DNS name could be represented numerically using 
> a "tumbler"
> (as coined by Ted Nelson) notation, dotted number sequences. This was
> proposed as a way to simplify twelve-key entry for analog 
> phones. Perhaps
> some revival of that approach might be feasible for our needs as well?
> 
> --
> Dean
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Manfredi, Albert E
> > Sent: Tuesday, February 29, 2000 4:04 PM
> > To: [email-masked]'
> > Cc: ION Group (E-mail)
> > Subject: [Enum] Portable unique identifiers
> >
> >
> > A short time ago, the topic of how to formulate portable identifiers
> > relating to E.164 numbers was broached, and someone mentioned
> > using RFC 2486
> > for this purpose. RFC 2486 seems appropriate at first 
> glance, because it
> > addresses a similar problem, for roaming terminals. But I don't
> > think it is
> > the right approach for this application.
> >
> > RFC 2486 defines something called Network Access Identifier
> > (NAI), which is
> > a location-independent unique ID for a user. And the NAI 
> makes use of the
> > same naming convention used in e-mail addressing: 
> username@realm. This is
> > nice because it's a familiar and user-friendly format, but 
> it has two
> > drawbacks for our purposes:
> >
> > 1. It is next to impossible to use such a scheme from a 
> small appliance,
> > provided with keypad entry only (e.g. cell phone), and
> >
> > 2. The realm part of the unique ID ties the user to some 
> service provider,
> > making the scheme less than totally portable.
> >
> > Instead, I propose that a number, perhaps 15 digits long, 
> identified by a
> > unique prefix, would be about right. This would work with 
> the enum scheme
> > already scoped out. It could even more easily work with the
> > existing ATM End
> > System Identifier (AESA) scheme defined in ATM.
> >
> > In the enum world, one might use a domain other than e164.int.
> > This is not,
> > after all, an E.164 number.
> >
> > In the AESA world, one could either define a specific 
> Address and Format
> > Identifier (AFI) prefix for these AESAs, _or_ one can use 
> the AFI for the
> > existing embedded E.164 format, and then make use of parts 
> of that 20-byte
> > frame that are currently unused (the HO-DSP and ESI, for example).
> >
> > It seems possible to give these portable numbers some sort of
> > hierarchy that
> > is not geographically based, so as to even the load among 
> several servers.
> > Not unlike what happens now with E.164. As you go down the 
> digits, the
> > search is sent off to different servers.
> >
> > For fancy IP appliances that have a keyboard, RFC 2486 
> would still be
> > usable, of course. But there must also be a solution for the smaller
> > appliance, I think.
> >
> > Bert
> > [email-masked]
> >
> > _______________________________________________
> > enum mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/enum
> >
> 

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Paul Koning <[email-masked]>
Date: Thu, 2 Mar 2000 15:07:55 -0500

I get the feeling I dropped into the middle of a long discussion (did
it only just recently get redirected to include the ion list?).

If the goal is to get unique identifiers that are easily administered
and have no geographic significance, I agree with Bert that solutions
to this have been around for a long time.

IEEE, of course, assigns OUIs, which can be used to form MAC
addresses.  They can also be used to form new things, all you have to
do is define that they start with the OUI as administered by IEEE.

There are others.  Object identifiers are globally unique,
non-geographic, and hierarchically administered.  They are variable
length, which may be the wrong thing here.

Several AESA choices are also suitable.  DCD format AESAs are at least 
as flexible as IEEE OUI based IDs.  In spite of what you might think,
they do NOT have geographic significance.  (The fact that a DCD starts 
with country code 840 means it was assigned by ANSI, but it says
nothing whatsoever about the location of the entity identified by that 
number).

So while I don't believe the issue of a single root is a real problem
(the DNS "single root fight" claim doesn't sound like it is real), you 
in fact have several places to pick from already.

	paul