ietf
[Top] [All Lists]

Re: future of identifiers

2013-10-29 14:42:01
On 30/10/2013 05:30, Patrik Fältström wrote:
On 29 okt 2013, at 12:23, Eliot Lear <lear(_at_)cisco(_dot_)com> wrote:

On 10/29/13 5:16 PM, Paul Hoffman wrote:
On Oct 29, 2013, at 9:03 AM, Patrik Fältström <paf(_at_)frobbit(_dot_)se> 
wrote:

I think it is important to not restart discussions already held regarding 
different requirements on identifiers, requirements that in turn lead to 
various alternatives on how they are allocated, managed and resolved. I do 
not think one can have one identifier that fits all. Instead multiple kind 
of identifiers are needed. Because of requirements on uniqueness 
(absolute, low risk of collisions or not needed at all), persistence, 
human readable/understandable, whether allocation and resolution should be 
designed for read (lookups) or write (allocation), what the identifier is 
to be used for (see id/loc discussions).
Having sat through many of those discussions with Patrik 15 years ago: +1
And having chaired NSRG, + 1/2.  That is- it's always fair to look at
new developments, but let's at least be aware of what was covered by
others and build on their success (or avoid their failures).

Just to make my point clear. I absolutely do believe more thinking is needed. 
What was done 15 years ago never finished. I claim partly because we did not 
know the answers to all questions.

Indeed. I have some half-baked thoughts about some aspects at
http://www.cs.auckland.ac.nz/~brian/IPAddressesConsideredHarmful.pdf

   Brian


My only point is that I think it would be sad to restart the discussion from 
zero. We both good and bad experience if we look back in history. We made 
mistakes then, but we also have successes. I here talk about URI-related 
discussions, whois++ (etc), Dublin Core, OID and what not.

Same with the 10+(?) years of ID/Loc split discussions. Lots and lots of 
experience. 

And of course the experience enterprises like Facebook, Twitter etc have from 
their what I would call private namespaces.

   Patrik



<Prev in Thread] Current Thread [Next in Thread>