[Internetgovtech] off topic: labels (was Re: Documents from the ICG Meeting Last Week are Available)

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 21 July 2014 20:08 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0DF5E1A03C6 for <internetgovtech@ietfa.amsl.com>; Mon, 21 Jul 2014 13:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.259
X-Spam-Level: *
X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id C7nCjTE2HFOz for <internetgovtech@ietfa.amsl.com>; Mon, 21 Jul 2014 13:08:27 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net []) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611CC1A02EF for <internetgovtech@iab.org>; Mon, 21 Jul 2014 13:08:27 -0700 (PDT)
Received: from mx1.yitter.info (dhcp-ab55.meeting.ietf.org []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 916CD8A031 for <internetgovtech@iab.org>; Mon, 21 Jul 2014 20:08:25 +0000 (UTC)
Date: Mon, 21 Jul 2014 16:08:24 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: internetgovtech@iab.org
Message-ID: <20140721200823.GG17453@mx1.yitter.info>
References: <A193D048-2B67-469A-93BA-C61BB362DA75@vigilsec.com> <53CD1E8A.1060804@acm.org> <FA4238C4-ADDC-435F-9591-E3B074C2F6F6@vigilsec.com> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> <20140721174703.GB17107@mx1.yitter.info> <53CD6CBC.40804@abenaki.wabanaki.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <53CD6CBC.40804@abenaki.wabanaki.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Ob1q17gpVkpTJGbwpjOepze_bJo
Subject: [Internetgovtech] off topic: labels (was Re: Documents from the ICG Meeting Last Week are Available)
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 20:08:30 -0000

Since you asked on list, I'll reply, but I don't think this is the
right list to pursue this discussion and if we're going to have to do
that I suggest perhaps DNSOP or the dns-operations OARC list or
perhaps dnsext@ietf.org (which is still open), depending on whether
you want to talk about protocol or operations.

On Mon, Jul 21, 2014 at 12:40:44PM -0700, Eric Brunner-Williams wrote:

> P.S. Exactly what is wrong with 5 octet labels? With 4 octet labels?
> With 3 octet labels? And finally, with 2 octet labels?

Nothing, in principle.  In practice, it depends.  You might want to
have a look at RFC 6912.  Even though it was particularly about
Unicode code points for U-labels, the general principles outlined
there are useful in other ways too.

> P.P.S. Exactly what is wrong with a terminal label consisting only
> of characters in the 0-9 range, that is not completely cured by a
> requirement that the next subordinate label contain one or more
> characters from the range g-z?

Well, the actual terminal label cannot contain any characters at all,
but I think you knew that and meant the second-to-last label
(conventionally called a TLD).  So, first, there's actually no
technical way to require what you're saying, really.  That's what
"delegation" means.  You could do it with contracts, though.  

But what you're really saying is that the heuristic implied in RFC
1123 might break.  That seems like an extremely incautious thing to
do, and therefore a responsible operator of the root zone wouldn't do
it.  Technology is not infinitely plastic: once you have deployed
something, it affects the world.  In the case of the DNS, the way it
has affected the world is partly based in the assumptions people have
about what their software may depend on.

Best regards,


Andrew Sullivan