Return to tldapps Forum - Message Thread - FAQ

Username: ITAB
Date/Time: Sat, November 4, 2000 at 5:32 PM GMT
Browser: Microsoft Internet Explorer V5.0 using Windows 98
Score: 5
Subject: A view from the IETF ENUM WG

Message:
 

 
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


       
     
     

 


Message Thread:


Privacy Policy | Terms of Service | Cookies Policy