If you have a single centralised root for your new class, you will probably
either recreate the problems of ICANN, or create one or more of the problems
that ICANN has very consciously tried to avoid.
If you have a system of name resolution that avoids the need for a centralised
root, you probably don’t need a new class to implement it.
The few marginal cases that need to interact with the one root but not be ICANN
controlled are why we have the RFC 6761 process.
I agree a taxa of needs that do not fit within those three cases would have
On 5 Jul 2017, at 10:47 am, Randy Bush <randy(_at_)psg(_dot_)com> wrote:
i think avoiding icann is a red herring. if the draft in question had
done a decent job of exploring the taxa of needs for name resolution
outside of the 'normal' topology, we would have the start of a base on
which to discuss this.
DNSOP mailing list