Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

Mark Andrews <marka@isc.org> Wed, 05 July 2017 00:03 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 0D82D13154E; Tue, 4 Jul 2017 17:03:54 -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 Bt5DK5KuQBpR; Tue, 4 Jul 2017 17:03:52 -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 2D85512EC71; Tue, 4 Jul 2017 17:03:52 -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 0E3F324AE08; Wed, 5 Jul 2017 00:02:28 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B8910160045; Wed, 5 Jul 2017 00:02:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8506F160098; Wed, 5 Jul 2017 00:02:31 +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 D-MTbki4BCqF; Wed, 5 Jul 2017 00:02:31 +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 293A1160045; Wed, 5 Jul 2017 00:02:31 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5918D7D8457F; Wed, 5 Jul 2017 10:02:29 +1000 (AEST)
To: Ted Lemon <mellon@fugue.com>
Cc: william manning <chinese.apricot@gmail.com>, Randy Bush <randy@psg.com>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
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>
In-reply-to: Your message of "Tue, 04 Jul 2017 13:39:53 -0400." <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com>
Date: Wed, 05 Jul 2017 10:02:29 +1000
Message-Id: <20170705000229.5918D7D8457F@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pzeZHP8EXaDQ98JX-4p-c9qtv_U>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
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: Wed, 05 Jul 2017 00:03:54 -0000

In message <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com>, Ted Lemon writes:
> On Jul 4, 2017, at 1:32 PM, william manning <chinese.apricot@gmail.com>
> wrote:
> > I find Randys line of discussion mirroring my own thoughts.
> > And to answer your question above, technically, the TLD  org.  is a
> > member of the IN class, so in the OF class, it is credible to posit the
> > existence of  a org. TLD.   TLDs are per class... :)
>
> Technically, yes. Would ICANN object?  Id be astonished if they did not.
> Is there any practical value in an alternative class hierarchy?  No. So
> its moot.

Actually there is practical value in an alternative classes if only
to make the type space effectively 32 bits and implicit with that
is a alternative class hierarchy (delegation may exist in one that
do not exist in the other and they may point to other servers).

Who owns a name is a different question to what machines serve the
<name,type,class> tuple and how do you reach those machines.  There
is absolutely no reason why the zones <name,IN> and <name,CLASS56>
need to be served by the same machines.  There is a argument for
them both being under control of the same people.

Mark

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org