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

Andrew Sullivan <> Sat, 04 February 2017 02:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B78F129464 for <>; Fri, 3 Feb 2017 18:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W2OiohFTz-dK for <>; Fri, 3 Feb 2017 18:07:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0D0E1127735 for <>; Fri, 3 Feb 2017 18:07:13 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9154011649 for <>; Sat, 4 Feb 2017 02:07:18 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2Z6LO7PME9H0 for <>; Sat, 4 Feb 2017 02:07:17 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id AE2321162D for <>; Sat, 4 Feb 2017 02:07:17 +0000 (UTC)
Date: Fri, 03 Feb 2017 21:07:11 -0500
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Feb 2017 02:07:15 -0000


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

Best regards,


Andrew Sullivan