In message <7DCA3DAF1993A2E66915D0DD@xxxxxxxxxxxxxxx>, John C Klensin writes: > > > --On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid > <jim@xxxxxxxxxxx> wrote: > > >> On 4 Jul 2017, at 18:49, Paul Vixie <paul@xxxxxxxxxxx> wrote: > >> > >> while IETF governs the protocol, ICANN only governs the IN > >> class. i expect that there will be other classes some day, in > >> order to avoid some aspect of ICANN. > > > > Attempts have already been made to do just that. It would be > > nice not to have to put out those fires all over again. > > Jim, Paul, > > First of all, if only because "QCLASS=ANY" is supposed to do > something sensible, one really cannot have different, per-Class, > roots (more of that argument and the difficulties for many of > the things people have wanted to use CLASSes for in recent years > appears in draft-sullivan-dns-class-useless). While I don't > believe "useless", I don't see any hope for using the CLASS > mechanism to "avoid ... ICANN". draft-sullivan-dns-class-useless has lots provably invalid assumptions in it that it is worthless in determining if new classes could be deployed. The only thing useful in it is the warning not to make all new type allocations class independent as it chews through the <type,class> tuple space too fast. We should be updating the instructions to IANA to allocate types as class dependent unless it can be show that they should be class independent. Note we can always type X class A is identical to type X class B in the future. As to whether a class has a parallel heirachy or not depends on how we define the use of the class. > More important, given historical difficulties with adoption and > broad deployment of new features, I suggest that anyone who sees > ICANN avoidance as am important goal would find establishing an > alternate root and building support for it far easily and more > plausible than anything that could be done with CLASSes, if only > because an ICANN-free class mechanism would, AFAICT, require a > root (even for Class=IN) that was not controlled by ICANN > anyway. Getting new features support into name servers hasn't actually been hard. All STD 13 compliant name servers and resolvers *already* support new classes. What's hard to do is to get GoDaddy and ilk to update their web interfaces. > Having enough of the world get aggravated enough at ICANN (or > some other entity of one's choice) to make general adoption of > an alternate root plausible is another matter and I don't think > we are there, at least yet. The level of confusion and global > inconsistencies that would accompany any transition to a > different root and root management structure would be bad enough > that I hope the day at which that aggravation threshold is > reached does not come even if, ICANN seems to be trying some > days. > > Those who are contemplating that sort of adventure might find at > least parts of draft-klensin-dns-function-considerations amusing > reading. In particular, Section 3.6 briefly addresses the topic > of different CLASSes as a mechanism for doing new and different > things (technical or administrative). > > best, > john -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx