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

Andrew Sullivan <ajs@anvilwalrusden.com> Sat, 04 February 2017 02:07 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 0B78F129464 for <dnsop@ietfa.amsl.com>; Fri, 3 Feb 2017 18:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 W2OiohFTz-dK for <dnsop@ietfa.amsl.com>; Fri, 3 Feb 2017 18:07:14 -0800 (PST)
Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0E1127735 for <dnsop@ietf.org>; Fri, 3 Feb 2017 18:07:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 9154011649 for <dnsop@ietf.org>; Sat, 4 Feb 2017 02:07:18 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z6LO7PME9H0 for <dnsop@ietf.org>; Sat, 4 Feb 2017 02:07:17 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id AE2321162D for <dnsop@ietf.org>; Sat, 4 Feb 2017 02:07:17 +0000 (UTC)
Date: Fri, 3 Feb 2017 21:07:11 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20170204020711.GD67739@mx2.yitter.info>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170203224708.A0EE061891C7@rock.dv.isc.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8xgi8L2qVI3hX0t0XOXUUbKpr9c>
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 02:07:15 -0000

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.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com