interesting-people message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [IP] more on ITU or ICANN - a case story from Denmark

  • From: David Farber <>
  • To: Ip <>
  • Date: Thu, 13 Jan 2005 04:57:17 -0500

------ Forwarded Message
From: Bob Frankston <>
Date: Thu, 13 Jan 2005 00:51:31 -0500
To: <>, 'Ip' <>
Subject: RE: [IP] more on ITU or ICANN - a case story from Denmark

The reason for wanting to put numbers under ENUM is for bridging between the
PSTN and the Internet. Otherwise, as Skype has shown, why bother with any of
this numeric dialing.

ENUM represents a simple collision between worlds and cultures.  It's also a
reminder of the bad idea of splitting area codes instead of overlaying
because of the misguided notion that a split is "simpler" when, in reality,
it is very disruptive because it changes the meaning of half the phone
numbers in an arbitrary manner.

While the ITU can make some arguments about the need to maintain control and
ownership that's not a justification for not creating an unregulated branch
of the ENUM space -- after all, it's just the DNS and we can simply delegate
subzones to any party that wants one even if it means dialing a long prefix
like +87810 (which is supposed to map into the Free World Dialup numbers)
(011-87810 for American phones without a + capability). It might seem
strange to your neighbor but it should work. Since I can forward my own 800#
to Australia for an additional penny a minute, I can simply give out an 800
number that maps into such an ENUM and avoid the confusion.

This would allow me to manage a zone file for my numbers. Sure I can make a
mistake with the entries but any system must deal with errors anyway so
that's not a problem.

The real problem is that it forces the ITU world to face up to a "learn by
doing world" and the distance insensitive pricing of the Internet. Having
87810 also means creating a complex, albeit artificial, pricing structure
for the new virtual countries, AKA zone files.

Mapping the artificial complexities of the existing numbers into ENUM is
difficult because without reality as an anchor it's all arbitrary. The
numbers do have meaning both geographic and emotional. And they also have to
authoritative in some sense. A compromise would be to allow people to simply
forward their PSTN to the experimental ENUM space if they choose.

But I don't expect that to happen since it would make it too easy to simply
bypass a PSTN billing engine.

-----Original Message-----
From: [] On Behalf Of
David Farber
Sent: Wednesday, January 12, 2005 16:04
To: Ip
Subject: [IP] more on ITU or ICANN - a case story from Denmark

------ Forwarded Message
From: Karl Auerbach <>
Reply-To: Karl Auerbach <>
Date: Wed, 12 Jan 2005 12:51:41 -0800 (PST)
To: David Farber <>
Subject: Re: [IP] more on ITU or ICANN - a case story from Denmark

On Wed, 12 Jan 2005, David Farber wrote:

> ------ Forwarded Message
> From: Dave Crocker <>
> Subject: Re: [IP] ITU or ICANN - a case story from Denmark

> The problem, here, is thinking that a top-level domain is necessary.  The
> right-hand portion of the domain name merely needs to be a constant.
> ANY initial domain name will suffice, as long as there is agreement to use
> it.

I often disagree with Dave Crocker, but on this point we are in absolute
agreement.  The push for any particular top level domain is rarely
necessary on technical grounds.  Rather the applicant is usually more
concerned with the marketing cachet that comes from having a "dedicated"
top level domain.

We do, however, want enough top level domains so that there is a nice
fan-out of DNS queries and servers at all levels of the DNS hierarchy.
The current situation has so few top level domains that the amount of
root-to-top level domain information is so small that we could actually
replace it with a widespread P2P distribution of compressed root zone
files of about 15K bytes, i.e. smaller than the typical web page icon.

Unfortunately ICANN has created a regime in which ICANN controls entry
into the domain name marketplace based on incumbent-protective examination
of business plans of applicants.  Entry into the marketplace should only
require that the applicant adhere to internet standards, refrain from
using its position to violate the end-to-end principle, and to practice
business record preservation practices so that a sucessor could pick up
the pieces of a business failure and resume operations.

As for ENUM - it's an interesting and highly flexible technology.  But I
have concerns about what happens when typical system administrators get
the ability to put regular expressions into DNS records.  Regular
expressions are sufficiently complex that there are entire books dedicated
to them.  And even experts get 'em wrong.

I see no reason for a single ENUM root.  In fact it's my feeling that the
better use of ENUM is for local VOIP operators to establish their own Enum
roots for call processing and call routing.  That way the operators, or an
innovator, might be able to offer customized, SLA controlled bypass
networks for their VOIP calls.

As for DNS in general - There are a lot of things that are trending to
greatly increase the load on the existing DNS hierarchy.  One is the
continuing attacks on DNS servers and the growth of spam.

But there is also the fact that with the introduction of new information
into DNS the number of packet exchanges needed can grow, often
explosively.  For example, I ran a simple test and discovered that a query
that used to take 4 packets now required 46 packets (the difference was
due to the fact that the resolver I was watching went forth and obtained
IPv6 AAAA *and* A4 records of name servers even though that resolver had
no IPv6 connectivity beyond its local LAN.)

There is no evidence to indate that ICANN is actually monitoring the
increasing load on DNS and the causes.


------ End of Forwarded Message

You are subscribed as
To manage your subscription, go to

Archives at:

------ End of Forwarded Message

You are subscribed as
To manage your subscription, go to

Archives at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC