Re: [DNSOP] new DNS classes

John C Klensin <john@jck.com> Tue, 04 July 2017 18:22 UTC

Return-Path: <john@jck.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513E512896F; Tue, 4 Jul 2017 11:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbBqrpsxPtGW; Tue, 4 Jul 2017 11:21:58 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2BB13270A; Tue, 4 Jul 2017 11:21:55 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1dSSSC-000622-Vs; Tue, 04 Jul 2017 14:21:40 -0400
Date: Tue, 04 Jul 2017 14:21:35 -0400
From: John C Klensin <john@jck.com>
To: Jim Reid <jim@rfc1035.com>, Paul Vixie <paul@redbarn.org>
cc: dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>, william manning <chinese.apricot@gmail.com>
Message-ID: <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com>
In-Reply-To: <E739C1CB-E60E-4B4B-99CF-1E6C68CB6926@rfc1035.com>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <E739C1CB-E60E-4B4B-99CF-1E6C68CB6926@rfc1035.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1vsfdJlPIg6BLBIXTfG7Ov8jQpE>
Subject: Re: [DNSOP] new DNS classes
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jul 2017 18:22:00 -0000


--On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid
<jim@rfc1035.com>; wrote:

>> On 4 Jul 2017, at 18:49, Paul Vixie <paul@redbarn.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".

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