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

John C Klensin <> Tue, 08 July 2008 09:14 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id EC50A3A6A3B; Tue, 8 Jul 2008 02:14:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CBD23A6A3B for <>; Tue, 8 Jul 2008 02:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x-imFZ5Q9pmR for <>; Tue, 8 Jul 2008 02:14:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB8D43A6875 for <>; Tue, 8 Jul 2008 02:14:15 -0700 (PDT)
Received: from [] (helo=p3.JCK.COM) by with esmtp (Exim 4.34) id 1KG9HD-000BNU-H3; Tue, 08 Jul 2008 05:14:23 -0400
Date: Tue, 08 Jul 2008 05:14:22 -0400
From: John C Klensin <>
To: Dave Crocker <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Message-ID: <7B4710B3D2BD1FC9D02CC020@p3.JCK.COM>
In-Reply-To: <>
References: Your message of <> <BLU137-W18376D2DBA85C8F712C06F93980@phx.gbl> <> <> <18BA25DED8BFD9F794A10E84@p3.JCK.COM> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: IETF Discussion <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

--On Monday, 07 July, 2008 18:14 -0700 Dave Crocker
<> wrote:

> John C Klensin wrote:
>>      What do
>> you think would happen to that recommendation, and the
>> benefits it affords, if the size of the root zone increased
>> by an order of magnitude or so?  
> 2 orders?  20K?
> No, sorry.  Think 3-4 orders of magnitude.
> Really.

Yes.  I choose the smaller number because various folks around
ICANN seem to be expecting a thousand applications or so.
Unless the application fee turns into much more of a deterrent
than I expect, I agree that this is likely to open the
floodgates and that your estimate is more likely.  While INAL
and this is certainly not my area of expertise, a possible issue
in the requirement to defend trademarks might act as a strong
accelerator once one starts seeing individual enterprise TLDs
(or even the suspicion of applications for them).

> Let me explain: I'm not against more TLDs.  Quite the
> opposite.  (I appointed by Postel to participate in the
> pre-ICANN committee tasked with increasing the number.)
> But there is a paradigmatic difference between a TLD defined
> and operated to mediate on behalf of a general and diverse
> population, versus one constrained to a narrow and controlled
> constituency, such as a single company.

Indeed, although ICANN has already opened that door by
allocating "sponsored" gTLDs to a few entities which have
restricted membership that is smaller than the interest group
associated with some larger companies.

> The number of the latter is quite large.  And by that I mean
> *really* large.
> And all of the questions I asked 10 years ago said that TLDs
> on that latter scale would be problematic to the root.

Yes.  And, for large scale, our more complicated root
environment (e.g., Anycast* and more local caching of root
copies in the presence of a root that might, worst case, end up
on the same order of magnitude in size, and with similar
volatility, to .COM) may actually make that situation worse than
it would have been in estimates of a decade ago.


* I am assuming that, while Anycast reduces the load on
individual servers by making more of them, it does not reduce
the total query load on the network and increases the amount of
bandwidth used in distributing updates.  The latter is
presumably trivial as long as the refresh time for the root zone
is fairly long and updates are infrequent (or incremental "push"
update is used), but could get interesting if magnitudes evolved
toward the current .COM situation.  But that is clearly not an
analysis based on actual data.

Ietf mailing list