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 been useful. David > On 5 Jul 2017, at 10:47 am, Randy Bush <ra...@psg.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. > > randy > > _______________________________________________ > 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
