IETF Logo Mail Archive

Re: [DNSOP] new DNS classes

David Cake <dave@davecake.net> Fri, 07 July 2017 13:32 UTC

Return-Path: <dave@davecake.net>
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 E4C88127B73; Fri, 7 Jul 2017 06:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, URIBL_BLOCKED=0.001] autolearn=no 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 GQLYnXr00x1M; Fri, 7 Jul 2017 06:32:34 -0700 (PDT)
Received: from agwe.difference.com.au (unknown [103.4.235.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFD8129B10; Fri, 7 Jul 2017 06:32:34 -0700 (PDT)
Received: from [192.168.0.195] (unknown [1.126.11.186]) by agwe.difference.com.au (Postfix) with ESMTPSA id E03DD154058; Fri, 7 Jul 2017 23:32:30 +1000 (AEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: David Cake <dave@davecake.net>
In-Reply-To: <m2mv8jw9qq.wl-randy@psg.com>
Date: Fri, 07 Jul 2017 15:32:21 +0200
Cc: Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <33235E8D-147D-4178-BC45-DFC1E1C27B99@davecake.net>
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> <595BE0D5.5000106@redbarn.org> <m2mv8jw9qq.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cLYWSu_k5vbsgj88osoFaEZ0rj8>
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: Fri, 07 Jul 2017 13:32:37 -0000

If you have a single centralised root for your new class, you will probably either recreate the problems of ICANN, or create one or more of the problems that ICANN has very consciously tried to avoid.
If you have a system of name resolution that avoids the need for a centralised root, you probably don’t need a new class to implement it. 
The few marginal cases that need to interact with the one root but not be ICANN controlled are why we have the RFC 6761 process. 

I agree a taxa of needs that do not fit within those three cases would have been useful. 

David


> On 5 Jul 2017, at 10:47 am, Randy Bush <randy@psg.com> wrote:
> 
> i think avoiding icann is a red herring.  if the draft in question had
> done a decent job of exploring the taxa of needs for name resolution
> outside of the 'normal' topology, we would have the start of a base on
> which to discuss this.
> 
> randy
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

v2.26.15 | Report a Bug | By Email | System Status