Re: [DNSOP] new DNS classes

Paul Vixie <paul@redbarn.org> Tue, 04 July 2017 18:39 UTC

Return-Path: <paul@redbarn.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 BCC8A132763; Tue, 4 Jul 2017 11:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qdCOjBB0_E_V; Tue, 4 Jul 2017 11:39:21 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B20D132762; Tue, 4 Jul 2017 11:39:21 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8B68C61FF3; Tue, 4 Jul 2017 18:39:20 +0000 (UTC)
Message-ID: <595BE0D5.5000106@redbarn.org>
Date: Tue, 04 Jul 2017 11:39:17 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.15 (Windows/20170609)
MIME-Version: 1.0
To: dnsop <dnsop@ietf.org>
CC: IETF Rinse Repeat <ietf@ietf.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: <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Fnvq9iyPb6p6mOLwJwcnK87QaTA>
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:39:23 -0000


John C Klensin wrote:
>
> --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".

half of the foundational specification of the dns protocol assumes that 
classes are inside rrsets. the other half assumes that zones are inside 
classes. when i started on bind in 1990 or so it tried to do both. by 
1995 i had disambiguated in favour of zones-in-classes, and all others 
since then have done likewise. qtype=any was a casualty of that work.

separately, i agree that using class to avoid icann would be useless, if 
by useless you mean "there's no way to create a competitor to IN". 
however, the chaos and hesiod classes did get used at varying times, and 
i can easily imagine something like bluetooth or appletalk or lopan 
(each of which has its own naming system, so, these aren't practical 
examples but rather theoretical ones) using the dns protocol on a 
different class, and passing ICANN like ships in the night.

> Having enough of the world get aggravated enough at ICANN ...

for those keeping score, i have been aggravated at ICANN, but am not 
now. i consider the recent transition away from NTIA, and the corporate 
governance changes made to enable that transition, to have been well 
considered and well executed, and to have benefited from almost two 
decades of experience and evolution. if i were designing a replacement 
for the dns protocol today, i would do all in my power to keep the "one 
internet, one namespace" element reflected by ICANN's current role. so, 
please don't misunderstand my participation in this thread as agitation 
for further evolutionary change. i think we're in a good place now.

-- 
P Vixie