Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

Joe Abley <> Wed, 12 February 2014 18:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 866921A0605 for <>; Wed, 12 Feb 2014 10:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1FoCgosWhUdZ for <>; Wed, 12 Feb 2014 10:24:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::236]) by (Postfix) with ESMTP id 973871A0502 for <>; Wed, 12 Feb 2014 10:24:11 -0800 (PST)
Received: by with SMTP id c9so16090740qcz.27 for <>; Wed, 12 Feb 2014 10:24:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=THFl4g2A/ouQtUBoRZI+TuhFvjmWqQU4PMmX+7b0tc0=; b=THuTKoGRTTzF75h9qQeIMvCmEqtziRIvsSqOm2UPdxGtqjMD46ghCgThKg5Pp8Yqsg QRU1oWIefQfN6xmx3dxoFG3H0i5SK6MtR1cPHkcbj9M14awWvn2tJhU3L2parEaMhXC+ QcGeI2Q6K8VHg4V09rpIfzfSqAoEGtfdv3h6E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=THFl4g2A/ouQtUBoRZI+TuhFvjmWqQU4PMmX+7b0tc0=; b=N0NEThgH3soH7P3pcs5MvvclaaMJtGAQtv8jDtutJ+MOac6RcDDFrJKaUc88NDQAwH ZojpBa62Kr+BplYIOPx2Cnij91iDUQy76bYN6lN1fNfDt+ToHTBsVvzpFGngetOzRAeB e0zm2760/Xc7lC7umECenoTfXTzrQ4dJBHkWASx0w220D6OLMw6f0lM7WvnjNOj7Ke1Y fECmGsnZQ0Y/PTOnFaNnAbgjtUwSV2K8auIwbbAYK2UGRS2X9RYyxMIJ6jaj8FjiGxJE MjvT91V+EhpjZKXEYssAiV90CprVSG8yA/L6QjlAfYXGUaCpdLjGpcPMJrxFcHbkHY8d h8WQ==
X-Gm-Message-State: ALoCoQkAksHtQsYSWca0+j/5tT4TJGUHTJDKk6sP1f8esm7HzigjxayJQ+1W1FQoqRhf32T6QxkH
X-Received: by with SMTP id s3mr33188352qga.12.1392229450583; Wed, 12 Feb 2014 10:24:10 -0800 (PST)
Received: from ( []) by with ESMTPSA id k61sm34756692qge.12.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 10:24:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C9368500-23FF-40BC-9451-15CA20D072E5"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Joe Abley <>
In-Reply-To: <>
Date: Wed, 12 Feb 2014 13:24:07 -0500
Message-Id: <>
References: <> <>
To: Marc Blanchet <>
X-Mailer: Apple Mail (2.1827)
Cc:, dnsop <>
Subject: Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2014 18:24:14 -0000

On 2014-02-12, at 11:28, Marc Blanchet <> wrote:

> - I like better that approach than the previous draft registering many tlds.

The previous draft (at least for some of the TLDs) was anchored in the reality that changing the name already in use was not practical, e.g. there's a sufficient deployed base that uses DNS-like names ending in ONION that proposals to use things like ONION.ARPA were non-starters.

I think therefore that the ALT draft addresses quite a different problem: the choice of DNS-like (but not DNS) name structure for new applications that we don't know about yet.

I suspect that there would be fewer roadblocks involved in choosing an anchor ALT.ARPA than ALT, since ARPA is under the control of an IETF family member while the root is controlled by distant cousins. If I'm right that this proposal is for future, as-yet-unknown applications, then the choice of anchor should be arbitrary; it feels in that case like the path of least resistance is the right one.

> - I would prefer an IANA registry under .alt with "expert" review policy.  A namespace with possible collisions (past or future) have very low value to me. names are leaking in various contexts, so collisions would be bad for the protocols and deployment using that .alt tld.

I think that if we are talking about DNS names, we already have mechanisms to ensure uniqueness.

If we're not talking about DNS names, then the only consideration we really need is to avoid collisions with the DNS. We can do that by reserving ALT (or ALT.ARPA, or whatever), specifying that it's a reasonable domain to sink locally (RFC 6303) and perhaps providing some kind of AS112++ sink for leaks to the wider network (draft-ietf-dnsop-as112-dname).

(An AS112++ sink for a domain is probably easier to realise for ALT.ARPA than it is for ALT, since the root zone is maintained using specific registry machinery that would require changes to support DNAME, I think, and the track record suggests such changes might take a long time to action.)

I don't see an obvious reason to insist on IETF restrictions on an ALT-like namespace if the point of the namespace is to be available for use outside the IETF. If restrictions existed (no matter how simple we imagine they were to follow) the likely outcome is that ALT would either be abused (used without registration) or ignored.