Re: [DNSOP] ALT-TLD and (insecure) delgations.

Mark Andrews <marka@isc.org> Sat, 04 February 2017 13:26 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 032B5129A65 for <dnsop@ietfa.amsl.com>; Sat, 4 Feb 2017 05:26:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[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 DdD-pEN8totC for <dnsop@ietfa.amsl.com>; Sat, 4 Feb 2017 05:26:18 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C77129A61 for <dnsop@ietf.org>; Sat, 4 Feb 2017 05:26:18 -0800 (PST)
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 A23DC1FCAB6; Sat, 4 Feb 2017 13:26:13 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6B029160043; Sat, 4 Feb 2017 13:26:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5103116006E; Sat, 4 Feb 2017 13:26:12 +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 7HwqiZU0AzRd; Sat, 4 Feb 2017 13:26:12 +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 9F84D160043; Sat, 4 Feb 2017 13:26:11 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 49806618F0F5; Sun, 5 Feb 2017 00:26:08 +1100 (EST)
To: Andrew Sullivan <ajs@anvilwalrusden.com>
From: Mark Andrews <marka@isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <20170204020711.GD67739@mx2.yitter.info>
In-reply-to: Your message of "Fri, 03 Feb 2017 21:07:11 -0500." <20170204020711.GD67739@mx2.yitter.info>
Date: Sun, 05 Feb 2017 00:26:08 +1100
Message-Id: <20170204132608.49806618F0F5@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9TKpqmfUsq8uOAX_cKlZppiABtg>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 04 Feb 2017 13:26:20 -0000

In message <20170204020711.GD67739@mx2.yitter.info>, Andrew Sullivan writes:
> Hi,
> 
> On Sat, Feb 04, 2017 at 09:47:08AM +1100, Mark Andrews wrote:
> > 
> > Also the ICANN's rule for signed TLD delegation for new gTLD is so
> > that delegations from those zones can be signed.
> 
> I don't think that it is up to this WG or even the IETF to make any
> determinations about why the names community decides the policies it
> does for the root zone.  But in any case, there are two relevant
> policy issues here:
> 
>     1.  We are not the authority for delegations -- signed, unsigned,
>     emtpy or otherwise -- from the root zone, and if we are going to
>     seek any kind of entry in the actual DNS root zone then we are
>     talking about that in entirely the wrong forum.  We maybe should
>     complete the alt draft saying what we want from it, and then
>     insert that into the correctly-shaped receptical at ICANN. 
> 
>     2.  Unfortunately for us, right now, there _is_ no such receptical
>     at ICANN.  For there does not appear to be an ICANN policy for
>     delegations from the root for special uses.  There is a policy for
>     ccTLD additions, but we are not a country.  There is no current
>     policy for new gTLDs -- the previous round closed, and there has
>     been no determination of whether a new round will happen nor what
>     that round might entail if it happens.  If you want to shape those
>     rules, I believe there are some discussions going on within some
>     constituencies at ICANN.
> 
> > signed.  There is no reason for ICANN to object other than religious
> > arguments.  Technically they don't have a leg to stand on.
>  
> I'm sorry, but it's not religious.  Other communities have rules for
> establishing their IANA functions.  If we want them to respect our
> rules for the IANA registries for which we set the policy, then we
> need to respect theirs for the registries for which they set the
> policy.

Given there are no rules for this type of namespace we need to
respect the reasons for the other rules which I did but you choose
to completely cut out of the reply.  This isn't a registry.  It's
a non-registry.  It is different.

Mark

> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> ajs@anvilwalrusden.com
> 
> _______________________________________________
> 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