Re: 2606bis (was: .local)

"JFC (Jefsey) Morfin" <> Wed, 19 October 2005 14:15 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1ESEjR-0007fn-CG; Wed, 19 Oct 2005 10:15:53 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1ESEjO-0007f8-W8 for; Wed, 19 Oct 2005 10:15:51 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id KAA19903 for <>; Wed, 19 Oct 2005 10:15:42 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1ESEv8-0004yk-5b for; Wed, 19 Oct 2005 10:27:59 -0400
Received: from ([] by with esmtpa (Exim 4.44) id 1ESEjC-0005a1-J6; Wed, 19 Oct 2005 07:15:38 -0700
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 19 Oct 2005 16:10:44 +0200
To: John C Klensin <>, Frank Ellermann <>
From: "JFC (Jefsey) Morfin" <>
In-Reply-To: <>
References: <> <p0620074fbf5509dd070a@[]> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: Re: 2606bis (was: .local)
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

John, Frank,
this draft is dead-ended. But it can seriously hurt the Internet.
I questioned Donald about it, obtaining an incomplete response, about 
the 01.txt version having to take obtained responses in consideration.

The management of the IANA name/number issues are out of the IETF 
reponsibility (RFC 2860, not quoted by Donald's Draft). This issue is 
extermely sensible a few weeks from the Tunis meeting. If it is a 
temptative of an individual to interfere in the Internet Governance 
debate through a confusion over the Government sovereignty, it would 
be a serious mistake.

I suggest we either drop this issue, or we definitly rename ourself 
UNTF and be embarked in another IETF DoS. I find there are too many 
of them nowadays, all related to the IANA.

  12:07 19/10/2005, John C Klensin wrote:
>Frank, I'm going to comment on two of your remarks.  My not
>commenting on the others does not imply that I agree with you
>about them either.
>--On Wednesday, 19 October, 2005 08:33 +0200 Frank Ellermann
><> wrote:
> >...
> > This draft references the informational RfC 1591 as normative.
> > So far I thought that 1591 in essence says that the internal
> > business of a TLD is, well, its internal business.
>First of all, 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.
>It wasn't considered appropriate to ask the IETF to ratify them.
>And they aren't BCPs or the equivalent, first because they
>weren't IETF documents and second because there was no such
>thing at the time.  RFC 1591 is one of those documents.  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, including both the "trustee rule" (see
>below) and the obligation to insist that any subdomains it
>registered accept the same rules.
>The "internal business" of a TLD is subject to an obligation to
>act as a trustee for the global Internet community and to act in
>the best interests of that community.  In that context,
>agreements about naming conventions and protocols that are
>reached through a plausible consensus process really are binding
>on all TLDs and, indeed, on all domains.  Whether the relevant
>authority is willing or able to enforce those norms and
>agreements is a separate issue: at worst, the norms and
>agreements constitute a guideline about good practices.
> >...
> > 3.2 prohibits single characters as SLD.  What's the technical
> > purpose of this prohibition ?  It also prohibits two characters
> > as SLD unless the government of the corresponding ccTLD, or if
> > that doesn't exist the ISO 3166 MA allow it.
> >...
>The technical purpose for this long-standing restriction is the
>avoidance (or minimization) of false positives.  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.  If only one character in a
>domain name label is permitted, the assumption was that all such
>labels would swiftly be taken and the likelihood would be very
>high that a single-character typing error would yield a false
>positive. That was considered a problem to be avoided a dozen
>years ago.  It seems to be that in today's more rapacious
>Internet, where "traffic concentration" (i.e., registering
>domain names with the express purpose of capturing false
>positives for a profit) represents the most profitable activity
>in the "names market", it is even more important.
>       john
>Ietf mailing list

Ietf mailing list