how about if the rules of sub-delegation under ALT are that 1) you only get an OID 2) the OID has to be registered with IANA in the normal way 3) the OID registry identifies the external namespace, which is being bound into the system.
Then, it becomes clear this is a mapping space for functions like gethostbyname() to have as a context specific search string, and are significantly less likely to collide with GTLD since they are simply digit strings. On Fri, Feb 13, 2015 at 3:45 PM, Paul Vixie <p...@redbarn.org> wrote: > > > David Conrad <d...@virtualized.org> > Thursday, February 12, 2015 5:38 PM > > George, > > > The politics response is really simple: "this idea is doomed." -I wish I felt > otherwise, but I think given the context of the debate over ICANN, who 'owns' > names, $180,000 application fees, IAB directions to IANA, NTIA role, this is > mired. I don't want to be a prophet of doom, but this is my honest > perspecive. > > As with most "really simple" answers, the reality is a bit more complicated. > My impression of this draft is that it creates a space that would avoid some > of the risks associated with RFC 6761. Politically, I suspect this is > desirable, even to all the parties you mention. As for the fee, ICANN already > defers to the IETF in protocol-related matters, so I don't see why a new gTLD > fee would be applicable. With my ICANN hat on, I'll look into this and > report what I hear back. > > > can we sit back and ponder what it will mean if .ALT becomes an implicit > extra search list for many end users, and then xyzzy.alt is created, and > later, .xyzzy is created. i expect this eventuality to spur considerable > interest from icann, perhaps coming in the form of "since we can't control > what the ietf does with implicit search list behaviour, we're skittish > about allowing something like .ALT to come into existence that would, when > combined with implicit search lists, lead to complete and utter chaos." > > this is not in other words simply a protocol-related matter. > > -- > Paul Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
