Re: 2606bis

Frank Ellermann <> Wed, 19 October 2005 19:12 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1ESJMn-0001Iq-Ns; Wed, 19 Oct 2005 15:12:49 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1ESJMj-0001Gc-7q for; Wed, 19 Oct 2005 15:12:47 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id PAA07542 for <>; Wed, 19 Oct 2005 15:12:35 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.43) id 1ESJYV-0005bK-SY for; Wed, 19 Oct 2005 15:24:56 -0400
Received: from list by with local (Exim 4.43) id 1ESJJV-0002lu-Uu for; Wed, 19 Oct 2005 21:09:26 +0200
Received: from ([]) by with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Wed, 19 Oct 2005 21:09:25 +0200
Received: from nobody by with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Wed, 19 Oct 2005 21:09:25 +0200
From: Frank Ellermann <>
Date: Wed, 19 Oct 2005 21:01:10 +0200
Organization: <URL:>
Lines: 60
Message-ID: <>
References: <> <p0620074fbf5509dd070a@[]> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Subject: Re: 2606bis
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

John C Klensin wrote:

> there are a collection of RFCs that were issued by the IANA
> that are, indeed, normative.  They aren't IETF Standards
> because they weren't produced or ratified by the IETF.

No problem with that, quite the contrary, but 2606bis would be
an IETF BCP.  "You" drilled me to see a big red blinking WAIT
for each normative reference to an informational RfC.

One potential problem with this draft, it mixes some technical
issues (like xn-- or SLD nic) with legal issues (like label
"iab" anywhere) with oddities (like the two-character SLDs).

> If you want to think about it that way, what makes it
> normative is that the operator of every TLD allocated in the
> pre-ICANN period agreed to its provisions

The "public whois server" idea unfortunately escaped some of
them (okay, it's not directly in 1591 ;-).  I'd really welcome
it if ICANN gets a proper RfC number for its ICP-1, apparently
some kind of 1591bis, and similar ICP-? documents.

But that's then still an ICANN document, not an IETF BCP.  The
wild mixture in the -00 draft confuses me.  And reserving the
string "iab" as label everywhere worldwide strikes me as plain
wrong.  Like all the other labels in 3.1 including "example".

There is an, no idea what it is, but probably nothing
related to "the" IAB.  If I'd start a today
that's my legal problem, it shouldn't affect any IETF BCP.

The pseudo country codes on the ISO 3166 web page with obscure
organizations like EM, EP, EV, etc. are bad enough, let's not
imitate this style for all DNS labels worldwide in an IETF BCP.

Chapter 3.1 in the draft could be moved to an RfC published
by ICANN - and I won't miss it for a second if that ICANN RfC
about reserved labels worldwide is never published.

 [short SLDs]
> If one has several characters in a string, the odds are (or
> were) presumed to be reasonable that a typing mistake (or
> something equivalent) would yield a "no domain" answer.

Okay, that's a technical reason, I buy.   So let's say that all
labels (not only SLDs & TLDs) must be at least two characters,
that's a clear and simple rule.

But the stuff about two characters in chapter 3.2 is dubious:

Whatever the governments of AC and CO might think, they can't
dictate which TLDs are allowed to adopt "Commonwealth style"
(my terminology) with SLDs ac and co.  Nothing is wrong with, it's no business of Columbia, and nothing is wrong with, it's no business of (AC -> SH ->) the UK.  Above all
the ISO 3166 MA has nothing to "allow" about SLDs worldwide.

                       Bye, Frank

Ietf mailing list