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:[EMAIL PROTECTED] > Sent: Wednesday, June 13, 2007 11:25 AM > To: [email protected]; [EMAIL PROTECTED] > 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 > [email protected] > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
