--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".
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.
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