Re: Update of RFC 2606 based on the recent ICANN changes ?

Mark Andrews <> Thu, 03 July 2008 04:48 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B10D23A6A0E; Wed, 2 Jul 2008 21:48:25 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 915A63A6993 for <>; Wed, 2 Jul 2008 21:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.539
X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, GB_I_LETTER=-2, WEIRD_PORT=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zhvl6wCgUoZd for <>; Wed, 2 Jul 2008 21:48:23 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by (Postfix) with ESMTP id 99A123A6A0E for <>; Wed, 2 Jul 2008 21:48:22 -0700 (PDT)
Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id m634mP2l037171; Thu, 3 Jul 2008 14:48:26 +1000 (EST) (envelope-from
Message-Id: <>
To: SM <>
From: Mark Andrews <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-reply-to: Your message of "Wed, 02 Jul 2008 17:21:56 MST." <>
Date: Thu, 03 Jul 2008 14:48:25 +1000
Cc: The IETF <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> At 15:40 02-07-2008, John C Klensin wrote:
> >Now, for example, I happen to believe that "one-off typing error
> >is guaranteed to yield a false positive", is a more than
> >sufficient _technical_ basis to ban single-alphabetic-letter
> >domains at either the top or second levels and to advise
> >lower-level domains against their use.  Those are technical
> >grounds based on human interface design and information
> >retrieval principles, not "the network will break if that is
> >done".  But few of the recommendations or reservations we might
> Some people may question a technical recommendation that is not based 
> on "the network will break".
> >make fall into that network-breaking latter category.  Even some
> >of those that fall closest to the line involve cases that we
> >could "fix" by modifying our applications protocols to lexically
> >distinguish between domain names and address literals
> >(http://[]/ anyone?).
> Or wait for http://[2001:1890:1112:1::20]/ to catch up.
> >But, should those of us who believe that single-letter domains
> >are bad news refrain from advocating for that rule because those
> >who oppose it could use it to discredit other IETF
> >recommendations that might be more important?    I don't know
> That's a question to consider before getting into any rule-making.
> >The rather odd phrasing there has been the source of a lot of
> >discussion in the past in both selected IETF and ICANN circles.
> >Some of us read it as "TLDs will be alphabetic only -- no
> >digits", not just "cannot be all digits".  The former was
> >certainly the IANA intent when we were discussing RFC 1591.
> >But does it apply today?  Can ICANN override it?  I can assure
> >you that there are groups within ICANN who believe that they can.
> RFC 1591 has been swept away by the changes that have taken placed 
> since then.  By making a few changes to RFC 5241, we could have a 
> document relevant to this topic. :-)
> At 16:23 02-07-2008, Mark Andrews wrote:
> >         No sane TLD operator can expect "http://tld" or "user@tld"
> >         to work reliably.  I suspect there are still mail configuations
> >         around that will re-write "user@tld" to "user@tld.ARPA"ARPA".
> http://museum/

	The key word word is "reliably".  http://museum/ can never
	be guarenteed to work.

	I can have with a search list containing  Which one would you expect to match?  Note
	changing the search order to try single labels "as is" first
	is not safe from a security perpective (see RFC 1535 for why
	not) as the introduction of a new TLD will break things.  

	Getting rid of search lists is also a show stopper.
> >         Should we be writting a RFC which states that MX and address
> >         records SHOULD NOT be added to the apex of a TLD zone?
> The above TLD has an address record.

	It still does not make it a good thing.
> >         Should we be writting a RFC which states that single label
> >         hostnames/mail domains SHOULD NOT be looked up "as is" in
> >         the DNS?
> There was a ccTLD operator who expressed the wish for such mail domains.

	And I can wish for a million dollars to be added to my
	savings account.  It doesn't mean I'll get it or that the
	ccTLD operator should get it.

> Regards,
> -sm 
> _______________________________________________
> Ietf mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET:
Ietf mailing list