In message <7DCA3DAF1993A2E66915D0DD(_at_)JcK-HP5(_dot_)jck(_dot_)com>, John C
Klensin writes:
--On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid
<jim(_at_)rfc1035(_dot_)com> wrote:
On 4 Jul 2017, at 18:49, Paul Vixie <paul(_at_)redbarn(_dot_)org> 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(_at_)isc(_dot_)org