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

Andrew Sullivan <ajs@anvilwalrusden.com> Sun, 05 February 2017 16:32 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 94769129441 for <dnsop@ietfa.amsl.com>; Sun, 5 Feb 2017 08:32:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=nV4TGuwF; dkim=pass (1024-bit key) header.d=yitter.info header.b=NFRGxO3+
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 dYh8dQUnZGDx for <dnsop@ietfa.amsl.com>; Sun, 5 Feb 2017 08:32:07 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6AF129418 for <dnsop@ietf.org>; Sun, 5 Feb 2017 08:32:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A3495BD554 for <dnsop@ietf.org>; Sun, 5 Feb 2017 16:31:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486312296; bh=9n+iQjuq1iTLR9qBoLN2kK2neFh03VVkdqnW6xla67M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nV4TGuwFhhg7RubjuUqsv/pkntagDr3EcmMpCTSWD6hregduWt1ZKKJfDyYwfciRL /yJNdpdxpTrYoYxP7tSq9WW7X6aimPSSAroUbPofAwxflUoZA8qZyWm2FfxNhJD3Ng Z4vANkZTUHoKdvRTpVxCCV823ALN+LE23HrKpzkg=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xIhryMY5S9W for <dnsop@ietf.org>; Sun, 5 Feb 2017 16:31:35 +0000 (UTC)
Date: Sun, 05 Feb 2017 11:31:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486312295; bh=9n+iQjuq1iTLR9qBoLN2kK2neFh03VVkdqnW6xla67M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NFRGxO3+VQ8M6I7vVVkAqH9yAmYhg2cMm5quOEyoyDOxwucpN1vbP/9UDLbwrafhg kEkIQbOP+vXVy9WHOpKinEP+agOuXyF7Qvi/FWflF2LLf/280rGvAt3eHtIegbxEWZ buQxjnnaHVUPXhdP3as0m1SbpQOsAp22GgZKzLc8=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20170205163133.GB75503@mx4.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> <20170204020711.GD67739@mx2.yitter.info> <20170204132608.49806618F0F5@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170204132608.49806618F0F5@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kdlMptv2_391i09z-hES4hHpa_Q>
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: Sun, 05 Feb 2017 16:32:08 -0000

On Sun, Feb 05, 2017 at 12:26:08AM +1100, Mark Andrews wrote:
> 
> Given there are no rules for this type of namespace

Which "type of namespace" do you mean?

I think there are three possible namespaces you're talking about:

    1.  Domain names.  There are rules for these, though they're
    possibly underspecified.  The IETF now has change control over the
    namespace definition documents (though the creation of said
    namespace predates the IETF).  For this reason, the IETF was in a
    position to create the 6761 registry and thereby establish that
    there are some domain names that are treated specially.

    2.  Domain names that are candidates for some DNS
    zone.  There is a policy authority for these, and it's the
    operator of the zone in question.  Its rules for that zone apply.
    In the case of the DNS root zone, the policy authority for that
    zone is the names community as expressed through ICANN.
    (Similarly, I am the policy authority for the crankycanuck.ca
    zone, and if you want a delegation in there you can talk to me.)

    3.  Domain names that are _not_ for use in the DNS.  This is one
    of the purposes of 6761, though perhaps not the only one.  So far,
    the rules for these have been mostly underspecified, though I
    think 6761 gives pretty compelling reasons why it's a good idea at
    least to register the use there.

The trouble we seem to be having is that we want something that is in
(2) but with no single policy authority for the zone.  It is not clear
that we have a way to do that if we start from the root.  We _might_
have a way to do it if we start from arpa, since the IAB is in charge
of arpa and doesn't have the policy problems that ICANN does.

The alt draft that Warren and I worked on was really intended to carve
out a place for (3).

> respect the reasons for the other rules which I did but you choose
> to completely cut out of the reply.

I cut them out because I don't believe the IETF is the unambiguous
source of those reasons.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com