If the repository is active, rather than passive this is of course possible.
For example we might map out a DNS spec within the .arpa TLD and use it to
distribute machine readable descriptions of the code points. Something of the
sort could be done for EUI-48 and -64 space as well of course.
It does increase leverage and the ability to enforce assignments to a degree
but only to the extent that running code actually refers to the registry and
only if there is no possibility of setting up a rival registry.
At the end of the day it is impossible to prevent a fork here, there is no
magic token in the Internet architecture that says 'mine'.
I suspect that if we ever get to the point where the DNS root is signed that
there will be multiple signature authorities and multiple signing keys
involved.
-----Original Message-----
From: Paul Hoffman [mailto:paul(_dot_)hoffman(_at_)vpnc(_dot_)org]
Sent: Wednesday, June 13, 2007 11:25 AM
To: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
Subject: RE: IANA registration constraints
At 5:51 AM -0700 6/13/07, Hallam-Baker, Phillip wrote:
I have spent quite a bit of time thinking what the consequences of a
default by a registry of the IANA, ISBN, EUI (aka MAC address) type.
My conclusion is: virtually nil.
That kinda depends on what is part of that "default". I would
absolutely want every codepoint to have the best possible
reference to a document that shows how the codepoint is used.
An RFC is best (as long as the registry is updated when the
RFC is); an Internet Draft is OK; a reference to an online
non-IETF document is reasonable; an email address is barely
acceptable. But there has to be some way for a developer who
needs to know what to do when faced with the use of the
codepoint to get some information.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf