A recent posting to the IETF-ENUM working group from Christian Huitema, a former
chair of the IAB, clearly articulates the need for competition to address the complexities
of the "e164.arpa" implementation of ENUM services:Christian Huitema:
"If we
have a single tree, we will end up with a set of regional monopolies deciding what
goes in the mapping. At the top, we will indeed find the ITU, then the various local
authorities, then the various phone providers. At each level, there will be confusion
and power struggles. For example, look at "1.e164.arpa." Who has authority? The area
is actually shared between several North American countries; even within the US,
the delegation to the ITU is managed by the State Department while the regulation
of telephony is managed by the FCC. If you go down to the area code level, the matter
is not any clearer. Who has authority over "2.1.2.1.e164.arpa"? Is this the New York
State public utilities commission, Bell Atlantic, or a third party? The matter only
becomes kind of clearer at the lower level of the hierarchy, where "x.x.x.2.1.2.1.e164.arpa"
corresponds to a bloc of addresses, the current unit of management for assignment
of numbers to local competitive carriers, and also for LNP. (The most likely result
is that each PUC will hire a contractor that manages the listing.) But then, a potential
use of ENUM is to bypass the local carrier, for example to send documents as e-mail
instead of faxes; this means, potentially, a loss of revenues. So, while the users
of phone numbers have an interest in listing their numbers, the phone companies are
conflicted. Expect some interesting developments."
Full quote: Per Christian’s
request:
I support the use of DNAME in ENUM. I believe ENUM faces a major deployment
problem, that of finding the authoritative publisher of an information. There are
basically two solutions to this problem, bureaucratic management and competition.
DNAME enables competition.
If we have a single tree, we will end up with a set
of regional monopolies deciding what goes in the mapping. At the top, we will indeed
find the ITU, then the various local authorities, then the various phone providers.
At each level, there will be confusion and power struggles. For example, look at
"1.e164.arpa." Who has authority? The area is actually shared between several North
American countries; even within the US, the delegation to the ITU is managed by the
State Department while the regulation of telephony is managed by the FCC. If you
go down to the area code level, the matter is not any clearer. Who has authority
over "2.1.2.1.e164.arpa"? Is this the New York State public utilities commission,
Bell Atlantic, or a third party? The matter only becomes kind of clearer at the lower
level of the hierarchy, where "x.x.x.2.1.2.1.e164.arpa" corresponds to a bloc of
addresses, the current unit of management for assignment of numbers to local competitive
carriers, and also for LNP. (The most likely result is that each PUC will hire a
contractor that manages the listing.) But then, a potential use of
ENUM is to
bypass the local carrier, for example to send documents as e-mail instead of faxes;
this means, potentially, a loss of revenues. So, while the users of phone numbers
have an interest in listing their numbers, the phone companies are conflicted. Expect
some interesting developments.
IMHO, the only way out is to allow a competition,
have a forest instead of a tree, so that we could get alternative services such as
"2.1.2.1.joe-s-listings.com." The clients that decide to use Joe's listings know
what they get: Joe's idea of who owns what number; they can trade bureaucratic certainty
and pace for rapid updates and potential mistakes. DNAME allows us to build
forests instead of tree; Joe's listing may use the DNAME technology to point at branches
managed by other servers, maybe even to point back to the main tree for some countries.
Another
interesting case is that of enterprises, who manage a local dial plan. If an enterprise
uses 4 digits extensions, then it is much more natural to resolve "x1234" through
"4.3.2.1.local-lan.example.com" than to go back all the way to the e164.arpa root.
But then, it is also useful to store any piece of data only once, so there is no
point in replicating the records of the local plan under "4.3.2.1.a.b.c.d.e.f.g.e164.arpa."
This is a case where DNAME are very interesting. By the way, this works both ways.
If the enterprise's dial plan has an escape code for international codes, say "00",
and if it contracts with Joe's Listing company for the ENUM service, then it can
enter a DNAME pointing "0.0.local-plan.example.com" to "joe-s-listings.com."
In
short, DNAME allow for a forest instead of a tree. A forest looks scary for bureaucrats,
but it enables competition. And it also enables local management of resources without
replication of records, smooth transitions between local dial plans and global registries.
In any case, the tool is in the box, so the debate is a little bit futile...
--
Christian Huitema