Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

John C Klensin <john-ietf@jck.com> Sun, 26 July 2015 15:36 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418BD1AC3E2 for <ietf@ietfa.amsl.com>; Sun, 26 Jul 2015 08:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.501
X-Spam-Level: **
X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=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 CS4Qpdnj-aOF for <ietf@ietfa.amsl.com>; Sun, 26 Jul 2015 08:36:36 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060511AC3D4 for <ietf@ietf.org>; Sun, 26 Jul 2015 08:36:36 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZJNyc-000Hdg-FV; Sun, 26 Jul 2015 11:36:34 -0400
Date: Sun, 26 Jul 2015 11:36:29 -0400
From: John C Klensin <john-ietf@jck.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>, ietf@ietf.org
Subject: Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>
Message-ID: <03222C66CACC094758E7D4E3@JcK-HP5.jck.com>
In-Reply-To: <20150726072936.GB5857@mx2.yitter.info>
References: <20150725165829.76805.qmail@ary.lan> <413CD2A31E4AFF293091DD05@JcK-HP5.jck.com> <DM2PR0301MB065582F1A4F6854EF86D4C8AA8800@DM2PR0301MB0655.namprd03.prod.outlook.com> <A005522A947794D54E141DEC@JcK-HP5.jck.com> <20150726072936.GB5857@mx2.yitter.info>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/RiyLPCofVWRR_QGOEon5aQxQbYs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2015 15:36:37 -0000


--On Sunday, July 26, 2015 9:29 AM +0200 Andrew Sullivan
<ajs@anvilwalrusden.com> wrote:

> On Sat, Jul 25, 2015 at 04:12:01PM -0400, John C Klensin wrote:
>> Christian, as I have told others, there was, between
>> approximately when the DNS came into use and when ICANN
>> decided to ignore it, a firm rule about such names.  The rule
>> was that there would never been names (labels with delegation
>> records) in the DNS root longer than four characters, so one
>> was free to improvise with ".local", ".localhost", etc.  No
>> special rules (or additional special rules) needed.
> 
> Given what I know of operations at the time (and bearing in
> mind that I was not directly involved in TLD operations until
> the time ICANN was changing the rule), I believe the above to
> have been true. But it hasn't been true since 2001, and it
> seems to me that is long enough for us to say that the policy
> clearly changed.

Absolutely.  The point was only that this is a problem of the
community's making, one with a partially-unanticipated
consequence with which we now have to deal.   In part because
the boundaries were seen as a bit more clear than we seem to see
them today, the IETF/IAB decided to not intervene in 2000-2001
when applications were being accepted and considered.  And,
again, the issue was called to ICANN's attention at the time and
the decision was that ignoring it (and not warning applicants of
the possible consequences) was justified by the need to build
competition, etc.

> Anyway, it's not clear to me that this rule was ever actually
> written down, so it's hard to see how firm it was.  RFC 1123
> has some rules about the top level, but thost rules do not
> include the 4-character limit.  RFC 1123 _does_ note that the
> DNS ought to work in a network not connected to the Internet,
> and talks about "local names", so it is clear there was an
> expectation that there would be some.  RFC 1591 outlines the
> top-level domains, and it is silent on the 4-character rule.

Both mostly deliberate decisions, coming from the same thinking
that produced the "will be alphabetic" statement about TLD names
in RFC 1123.   Pre-ICANN, decisions about specific TLD
allocation was an IANA responsibility, not an IETF one, so it
was more appropriate to tell the IETF what was happening and
going to happen, not to, e.g., make statements about IETF
decisions.

> Anyway, it's quite clear that ICANN's new delegation decisions
> circa 2001 rendered 1591 obsolete (though why ICANN never
> published updates to 1591 is a mystery to me).  

Given that ICANN, and a number of ICANN-related entities
(notably some ccTLDs and regional ccTLD organizations) continue
to cite 1591, "rendered obsolete" may be a little strong even
though some of its comments are certainly OBE at this point.
And ICANN did publish an update to 1591 in the form of something
called ICP-1 [1].  It didn't say much and, IIR, was not
well-received and has sort of vanished from everyone's radar.  I
would suppose that the "update" for 1591 is the combination of
the ccTLD fast track procedure and the Applicant Handbook, with
1591 and/or ICP-1 still applying to 3166-1-based ccTLDs and
redelegations.

    john



[1]
https://www.icann.org/resources/pages/delegation-2012-02-25-en
as of today.