Re: [DNSOP] new DNS classes

Mark Andrews <marka@isc.org> Tue, 04 July 2017 23:33 UTC

Return-Path: <marka@isc.org>
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 A7FDE13154E; Tue, 4 Jul 2017 16:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 Mjaw9-PC69rs; Tue, 4 Jul 2017 16:33:24 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90EA13013C; Tue, 4 Jul 2017 16:33:23 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id C4C3E24AE08; Tue, 4 Jul 2017 23:33:14 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5D141160045; Tue, 4 Jul 2017 23:33:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 295FB160098; Tue, 4 Jul 2017 23:33:18 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 93qHIB75g40v; Tue, 4 Jul 2017 23:33:18 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 82C42160045; Tue, 4 Jul 2017 23:33:17 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AAA7D7D84127; Wed, 5 Jul 2017 09:33:15 +1000 (AEST)
To: John C Klensin <john@jck.com>
Cc: Jim Reid <jim@rfc1035.com>, Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>, william manning <chinese.apricot@gmail.com>
From: Mark Andrews <marka@isc.org>
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> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com>
In-reply-to: Your message of "Tue, 04 Jul 2017 14:21:35 -0400." <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com>
Date: Wed, 05 Jul 2017 09:33:15 +1000
Message-Id: <20170704233315.AAA7D7D84127@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MVqDpZ5KGGLfUUepuVP7zMaIxg4>
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 23:33:26 -0000

In message <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com>;, John C Klensin writes:
> 
> 
> --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".

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@isc.org