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

David Conrad <> Thu, 13 February 2014 01:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7EA4C1A00AB for <>; Wed, 12 Feb 2014 17:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rXxx-dE0wHwF for <>; Wed, 12 Feb 2014 17:48:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 083701A0091 for <>; Wed, 12 Feb 2014 17:48:11 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3EC684CEE; Wed, 12 Feb 2014 20:48:09 -0500 (EST)
Received: from ([]) by localhost ( []) (maiad, port 10024) with ESMTP id 35141-08; Wed, 12 Feb 2014 20:48:09 -0500 (EST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id E09BB84B43; Wed, 12 Feb 2014 20:48:08 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AAEF8AEC-4921-4852-B85C-B21200B1BAC7"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: David Conrad <>
In-Reply-To: <>
Date: Wed, 12 Feb 2014 20:48:01 -0500
Message-Id: <>
References: <> <> <> <>
To: George Michaelson <>
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: Thu, 13 Feb 2014 01:48:16 -0000

On Feb 12, 2014, at 6:38 PM, George Michaelson <> wrote:
> 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 dissent from this view. I strongly disagree with any characterisation of the problem of code replacement in service being intractable, and I think it is a false premise.


> I realize I am probably a lone voice on this, but at *no* time have I felt the "there are too many already" argument has merit, and it has materially impeded several outcomes we now face, because of failure to accept the necessary transition pain. The future is always bigger. 

I once heard a story about the author of make(1) realizing that perhaps having the tab character be significant in makefiles might not have been the best choice, but deciding against fixing it because the installed base of systems using make(1) at the time -- all 200 of them -- was too large.

> 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.
> And as a consequence I disagree with this too. An orderly migration from .ONION to another namespace is both feasible and capable of being planned for.

While I agree, pragmatically, I'm unsure there is incentive for the maintainers to move (which I think where Joe was going). As such, we're in the increasingly common quandary of figuring out how to document reality despite violation of policy or ignoring reality to ensure purity of policy.

Has anyone asked the folks coding .ONION (or others) if they're willing to migrate, pointing out the downsides if they choose not to?