I'm advocating for a model more like Internet domain names. Let consumers get their own telephone numbers from an entity similar to a domain name registry. Here's how it could work: the registry maintains an inventory of telephone numbers. It provides credentials to the consumer so that he can prove he owns the telephone number. The consumer then brings the telephone number and credential to their chosen service provider to activate their service. The service provider also uses the credential to update the registry with any relevant information. If the consumer wants to change service providers he brings the credential to the new service provider.

The registry could be funded by fees to either the service providers or directly to the consumer.

There are a number of benefits to this approach. First by allowing service providers to get telephone numbers on behalf of their customer, but not to carry an inventory, it conserves telephone numbers. Second, activation of telephone numbers will be immediate through the registry. Third, the registry will make all relevant information readily available to all. And finally, rather than taking something away from service providers this process actually frees them up from something they don't need to do. Why manage a vast nationwide inventory of telephone numbers requiring a significant investment in systems, processes and people? Let the consumers do it. The telephone number is simply an attribute of their service. It's a win-win situation for all.

Another simple thing to do is to activate all 792 central office codes in each existing geographic area code. Doing so will increase the available inventory of telephone numbers from 1.4B to 2.8B and would provide more consumer choice. (There are about 350 area codes, each with about 8M telephone numbers; 350 x 8M = 2.8B.) If done right, we would never need to implement a new area code because of exhaust. (There are 300M people in the US using an average of 2.5 telephone numbers each for a total of 750M assigned telephone numbers. Double 2.5 to 5 and we're still well below 2.8B assigned telephone numbers.) However if an area code needs to be implemented the registry would manage that process.

We should also do away with rate centers. Rate centers are irrelevant to the vast majority of billing plans and should not be relevant in a post-PSTN world. People no longer look for a central office code that is close to their home, e.g., PYramid 1 and Valley Stream. There's no need to let rate centers hold unused telephone numbers hostage.

I'm not naïve, I know that there will be significant issues to work out. We need to address current inventory, legacy systems and networks — how to implement the new regime; and how to transition to it — to name just a few issues. We need to ensure that speculation and squatting don't have a negative effect on conservation and consumers' desires. How do we manage highly desirable area codes (e.g., 212, 321, 777) and telephone numbers (e.g., repeating digits)? Should there be a link between a person's geography and the telephone numbers they can register? How do we maintain the important services for law enforcement and public safety? This will have far reaching effects and will take many years to plan and implement. There is a lot of work to do.

It is 2011 and the pace of change is constantly accelerating. It was about 80 years between TN 1.0 and TN 2.0. It's been about 20 years since TN 2.0. Service providers are evolving their networks to advanced IP platforms. All communication is rapidly moving to the Internet. The time to start planning TN 3.0 is now.

Written by Tom McGarry, VP of Research at Neustar Labs

Acceptance takes more than paying the application fee or even hiring an expert to help you fill out the form. And if ICANN says no, expect your application investment to vanish.

Do your homework and you won't apply for unprofitable TLDs. Lose and at least you will have done your best. The victor will have overbid and/or they will have a better TLD value forecast because of a superior forecasting methodology or a better vision for the use of the TLD. .

New gTLD revenue is driven by the size of the market for the TLD, your market share of registrations, and the price you charge for registrations under your gTLD. Revenue can be estimated by using prediction markets and/or statistical methods.

No matter what estimation method you use, the risks include uncertainty about demand. Thus, depending on your risk tolerance and budget, you might consider applying for multiple TLDs or join an investment fund that pools together interested investors.

You should keep in mind that some of the new gTLDs can compete with .com and that you should seriously consider differentiations by being socially responsible. A list of proposed TLDs can be found at AboutDomains.

In conclusion, you must analyze gTLD revenue and the associated risks before you apply for a new gTLD.

Written by Alex Tajirian, CEO at DomainMart

Unfortunately, this revolution that had occurred in the domain market was not followed by other markets. Note, for instance, the telephony market. We still use phone numbers in order to identify in an univocal way a single addressee. The use of number as access key in telephony was established by its technical convenience, since we have already used rotary dials. This choice, besides the technical convenience, is a terrible one from the user's perspective, and created a great range of mechanisms to help users maintain, recover and remember the useful numbers to them, such as: organizers, phonebook aid systems, yellow pages and etc..

Due to the growth of the smartphones market, a new horizon is coming. Why, instead of using telephone numbers to make our phone calls, don't we use a domain name as access key? This concept has been followed by some initiatives that has been having difficulties to be adopted by the mass market, since they force the registration of domains in other extensions that will not be the company main domain, and in the users' head, the domains .COM are already known as the main domain of the institutions. Additionally, it makes no sense to force companies to register auxiliary domains in other extensions; the companies and users are interested in using the main domain of their company or organization.

A new app for iPhone, BlackBerry and Android has been showed as an alternative much closer to companies and users interests, the Siter.com

In the event the user wants to call Apple, he/she dials Apple.com, he/she dials the domain that Apple discloses and that users already know. In the event the user wants to call Voge Magazine, he/she dials Vogue.com. This mechanism is named domain dialing.

Siter.com breaks this paradigm of using telephone numbers as univocal identifiers of the other part, nevertheless, without losing sight of what users and companies want: they want to use their business main domain. The domain that is already disclosed. The domain that is already known. Companies and users do not want to register their auxiliary domains to be found — they want to use their main domain instead!

The domain dialing (patent pending) has countless secondary benefits, for instance: A company may register multiple telephones under a single domain. This benefit, for instance, reduces the mandatory disclosure of long lists of branches and chain stores. Besides, the company main domain disclosure allows the branding of the company, since usually its brand is intimately associated to its domain name.

The domain dialing also allows mobile phone users to easily guess the desired domain to be dialed, reducing the phonebook aid, organizers, yellow pages reliance, and all kinds of things created to solve a technical issue.

The only way of replacing the culture of using phone numbers as access keys to the other part is taking into account how easily these initiatives would be accepted. It does no matter how many initiatives are done to associate the domain registers market to the telephony market. These initiatives need to consider what is easier and more logical from the mass market and users perspective.

Written by Ricardo Vaz Monteiro, COO of Siter.com

It was announced today that VeriSign is proposing to allow telephone numbers and other numeric identifiers in the .NAME top-level domain.

This could be the Killer App that ENUM has been waiting for.

VeriSign's proposal says domains will be allocated on a first-come, first-served basis. If true, I wonder if this is missing a larger opportunity?

Why not require that the registrant demonstrate that the telephone number they are requesting is actually under their control?

For example, EnCirca has had the same business land-line telephone number for over 12 years now. Shouldn't we be the only one eligible to register it as a .NAME?

For this to work, there would need to be a validation check during the registration process that the registrant of the numeric .NAME domain was in control of the corresponding telephone number. This is a fairly simply call-back technology that is already in wide commercial use.

ENUM is a set of protocols designed to unify the telephone system with the internet. The Internet Engineering Task Force (IETF) standards body has been working on it for over ten years.

EnCirca was one of the participants of an ENUM trial a few years ago. ENUM domain names are not pretty. For example, during the trial, ".arpa" was used as the testbed TLD. Our business telephone number +1 (781) 942-9975 corresponded to the following domain name: 9975.942.781.1.arpa. Now that is a domain that only a computer protocol could love!

But with .NAME, there is the opportunity to add a more user-friendly layer on top of the ENUM naming convention. For example, EnCirca's business telephone number could have the domain 1-781-942-9975.NAME (The hyphen after the country code is necessary for it to work globally). It is then trivial to map this to the ENUM-based domain of 9975.942.781.1.arpa.

With this type of marriage between the telephone system protocols and the DNS, the numeric .NAME domain has the potential of much more than a mere domain name. For many individuals and businesses, the telephone number is the one constant identifier versus to postal address or email address. Imagine if Skype had its own TLD and you start to understand even more possibilities.

Of course, I imagine there will be those who are purists or feel threatened with this type of innovation. They might balk at the thought of private companies doing this instead of regulatory agencies. Some will say that TLD's should not be allowed to evolve from their original charter. And some will oppose anything that VeriSign tries to do.

But this seems like it could be an innovation that consumers and businesses alike would embrace. And that is all that really matters, right? ... right?

Now tell me why you disagree.

Written by Thomas Barrett, President - EnCirca, Inc

Today we have two widely deployed global identifiers for reaching people. One is delegated address out of DNS and the other is phone numbers. So I consider an address like email: carol@johnson.com or xmpp:john@gmail.com to roughly be out of the DNS namespace and phone number to be out of the E.164 name space.

Phone numbers have lots of parts that are not cool, but they also have some cool parts: they are widely understood including social conventions of giving out someone else's phone number to a third part, they are easy to enter on devices with highly contained user interfaces, humans can almost remember them, they are easy for a human to give to another human. The biggest problem with phone numbers is, well, the only thing you can do with them is make a phone call. Say I wanted to have a Skype video call with you, or view your twitter feed, or send you an email and all I knew was the phone number. In many cases it would be nice to use a phone number to reach some internet service for user. Fundamental, this vipr technology solves the problem of securely mapping a phone number to URL.

Clearly there have been other attempts at mapping phone numbers to internet resources. Public ENUM is one example. However, most of the previous ones have failed because the economic incentives to make the technology deploy did not line up right. The vipr technology makes sure that every player that has to do something to make the technology deploy has an economic incentive to go do whatever they need to do. It heavily relies on peer to peer technologies.

How does it work? Imagine two enterprises, A and B that both have devices that can do voice and video over IP using SIP or something like that. First of all everyone using this systems forms one large Distributed Hash Table (DHT) using peer to peer techniques. Think of this like a database in the cloud.

Enterprise B publishes it's phone numbers to the DHT along with a pointer to B services on the internet. When A dials a phone number, it looks up the phone number in the DHT and notices that there is a pointer from this phone number to B. However, A has no reasons to believe this information so it more or less ignores it for now. Anyone could have published a link claiming that phone number was theirs and pointing to themselves. Now A call B over the normal PSTN and it's a normal phone call. After the phone call ends, both A and B know a common shared secret.

They know who called who and the start and stop time of the call. At this point, A can lookup the person in the DHT that claims to have the phone number (B in this case), then initiates some crypto magic (related to zero knowledge proofs) and B proves to A it knows the start and stop time of the call that happened over the PSTN. At this point A has validated that B really is the "owner" of the phone number and at any future point that A wants to communicate with that phone number, the services that B published into the DHT can be directly contacted. So the next time A calls that number, instead of going over the PSNT, the call goes over the Internet and A and B suddenly get video as well voice. The details are a bit more complicated (over a hundred pages of IETF specification) but that is the gist of it.

The enterprises need to run the vipr technology but will both get more features by doing this as well as a potential reduction in PSTN toll charges. Today lots of people have video phones running over SIP yet when they call another person that also has one, the call is forced over the lowest common denominator of the PSTN. This takes a very useful set of globally deployed address (namely E.164 phone numbers) and makes them useful for all the services on the internet not just making a phone call.

Written by Paul Budde, Managing Director of Paul Budde Communication

At the heart of the matter is the stark reality that network operators don't want to be dumb pipes. More specifically, they dread the idea that outfits like Google may generate rich service fees from subscribers, while they are left with relatively paltry access fees. Especially after spending billions of dollars to lay fiber, buy frequencies, build cell towers, etc. Yet, the proliferation of OTT services, of which Google Voice is just one example, indicates that this is direction things are headed.

So what will the network operators of the world do? The immediate answer is that they will fight tooth and nail. They will give precedence to their own services using all available means for as long as they possibly can. They will lobby congress (or the relevant governing bodies in other countries) against open access in an effort to maintain the world they know (witness the 700Mhz auctions of 2007). Along the way, innovative services like Google Voice will continue to be suffocated, if not killed outright.

But does it really have to be this way? The answer is a definitive 'No'. Not if network operators started to view the OTT application providers as potential customers instead of competitors. That doesn't mean that application providers should pay "extra" for priority over the last mile, as some network operators have suggested. Rather, it means that network operators should ask themselves "how can we provide value to OTT applications?" rather than fighting them off in congress and the courts (especially the court of public opinion).

When viewed in this way, there is actually quite a bit about network access that need not be dumb:

Payments - The bane of all digital content providers is collecting payment. Without a physical address to which goods may be delivered, digital merchants are constantly battling fraud and chargebacks. Even Paypal, the 800 pound gorilla in the area of online payments, must battle fraud when no physical delivery takes place. A network provider could very easily fill this void. They know where the customer lives, and they have a tangible physical connection to them. Much like NTTDoCoMo has been doing for years with iMode, they could act as a trusted intermediary and OTT application providers would happily pay them for this service.

Presence - Many of the promising applications just over the horizon will depend on the concept of presence. Are you in your car, or at your desk? Is your preferred method of communication a video call or an instant message? Does your device of choice have the capability to support MP3 or AAC as a file format? All of these questions can be answered by presence, and as the entity with a direct connection to your gadget, the pipe provider is in an optimal position to mediate it.

Directory Services - Closely related to the idea of presence are directory services. The ability to reproduce the good old phone book has proven to be one of the most vexing issues of the post-Ma Bell era. Just try to look-up the phone number of a mobile phone or VoIP user and you will understand the dilema. The lack of a trusted repository has caused ambitious attempts at creating online directory information, such as ENUM, to falter. Rather than evolving into online resources, however, the Bells have been steadily shedding their directory services ever since divestiture.

Location - As with presence, the network operator can best determine the actual physical location of the mobile subscriber. The current generation of location-based applications require that the application be 'turned-on' in order to transmit location information to the application provider (hogging precious CPU, battery and screen real estate in the process). A much saner approach would be for the network operator to maintain location information and then provide it to interested applications (with the subscriber's assent or course) upon request. Application providers would be willing to pay for this knowledge.

Marketing Intelligence - Since the pipe is the only common denominator between the subscriber and the many different providers of content the subscriber might access, the pipe owner is in an optimal position to provide marketing intelligence to the content owners. An astute pipe provider could build a comprehensive profile of its subscribers and offer this as a service to content providers. A Neilsen for the mobile age.

I can think of more, much more. But the above list should suffice to make the point.

Of course, there are some rough patches to be navigated. Chief among them is that all of the these services would entail drastic changes for the typical network operator (in terms of culture as much as business model). Further, a payment suitable model would have to be developed. The Internet is at odds with the traditional 'pay for access' model that network operators adhere to. A 'pay for play' model, where the network operator takes a chunk of the application providers paid-for transactions would work much better (again a'la iMode).

Yes, it's still early days. But it is evident to me that network operators must change their way of doing business in order to remain relevant. The question is which network operator will be the first to seize the mantle? Somehow, I don't think it will be AT&T.

Written by Eric Hernaez, Chief Executive Officer of Netmobo

I'm going to cover the potential of ENUM in the telecoms industry and what it could mean to you, along with how it is currently being used and what potential security issues surround ENUM.

Lets get started with a short primer. ENUM is a way of storing & supplying information about an entity using DNS like storage and retrieval. DNS is the technology that allows domain names to be used for things such as web site and email addresses. For now, consider ENUM to be a way to catalogue and retrieve potentially dynamic properties attached to a single 'number' or URL.

Up to now most applications have centred around telephony but other services such as email, IM and web could be accessed via ENUM. So a simple example would be that I have a URL of jonfarmer@mydomain.org and, using this one single piece of information, I could make available any data relating to me that I wanted to. This might be my phone or mobile number or an IM contact. Instead of having to remember and hand out my mobile number, landline number, IM address, email address or even my twitter URL I could let my ENUM retain that information.

The major excitement around this technology is in the telecoms world at the moment. At the telco level ENUM allows different telcos to learn how to route calls between themselves. This becomes most valuable when those calls are routed over IP networks.

For example, if an ENUM lookup is done on telephone number 01234567890 it might return sip:+4401234567890@telco2.co.uk as the preferred destination. As IP routing of voice calls is generally regarded as a cheaper method than TDM the advantages are evident — the potential to route calls at a lower cost for telcos and reduce cost for the consumer. Enterprising businesses and home users could potentially make use of ENUM to learn how to route calls over IP rather than the PSTN. This could leave telco's looking for ways to maintain revenue streams.

However there are potential issues inherent in this approach. Aside from any reliability issues that occur with any complex technical service, there are serious security concerns to address.

In order for a call to be routed over the IP network the receiving device has to accept and "trust" the incoming connection. Why is this is a major issue? Consider email. One of the major blights on email is Spam. Spam exists in part because in order for the email systems to work each email server has to accept and "trust" incoming connections from any other email server. This fact is used by the spammers to great effect. Most spam avoidance techniques work on spotting or blocking known or suspect emails or servers. We have all experienced spam issues at one time or another and IT professionals know all to well how much work has to be done to combat it.

Let's return to the issue of using IP to route calls using ENUM. If each receiving IP device has to accept and "trust" the incoming call it doesn't take a genius to spot the opportunity for the spammers. In the world of ENUM we may have to contend with SPIT (Spam over Internet Telephony). SPIT can take the form of auto-dialled pre-recorded phone calls. It doesn't take much imagination to see where spammers could go with this. To compound matters, in the IP world there is no "friendly" telco to "generally" shield us from the bad guys.

Another issue exists around the validity of the data in an ENUM database. For instance a few months back I ran an experiment and did ENUM lookups with a couple of well known public ENUM servers for all the telephone numbers dialled from our office PBX. The results were surprising. A number of other telcos claimed to be the route for numbers that belong to another major telco. This is potentially a problem as a rogue user could publish ENUM data about a telephone number that didn't belong to them for mischievous or even criminal reasons. They could proxy the call through their own server, recording it along the way, and then pass it on to the legitimate receiver unbeknown to the caller. Now while there may be an innocent reason why this happens it perfectly illustrates the potential issues relating to privacy and corporate secrecy. Unless PBX administrators are aware of this issue and how to guard against it then their systems could be vulnerable to this type of attack.

As I mentioned at the start of this article, Nominet the UK Top-Level Domain (TLD) registrar has recently been awarded the contract to administer the UK 4.4.e164.arpa delegation. It has put in place a system of Validation Agencies which will authenticate publishers of ENUM data and approve the validity of the data they publish. So in theory this new ENUM service should stop the problem previously mentioned (in the UK at least). However it does nothing to stop spammers using VoIP as any PBX wanting to be contactable via ENUM has to be by definition open to the IP world. I made this point to a Nominet representative at a recent event and his response was that in time technology would overcome this issue. Well we are still waiting for a credible email spam solution, so what hope is there for viable SPIT solutions and when they arrive will they be effective?

That being said, great strides are being made to use ENUM securely by telcos all around the world to route calls over IP. In time ENUM seems set to replace the existing routing technologies of the TDM world and that opens up all kinds of possibilities.

Will we see a day when individuals can reliably lookup the ENUM information of anyone around the world?

Written by Jon Farmer, Voice Technical Lead, Entanet International Ltd

In addition to the cost savings, other value-added features that ENUM is expected to provide for corporate communications include 'follow me' type function that will allow an individual to choose how (voice, fax, mobile, email, text messaging, location-based services and websites), and when they would like to be contacted throughout the day.

Other sources: (UPDATED Mar 13, 2009 2:48 PM PDT)
U.K. VoIP users to get better connected Network World, Mar.13.2009

What has made .tel stand out from the rest of the newly launched top-level domains is that it uses the domain name system (DNS) to function as a repository for all a company's or individual's contact details. According to Khashayar Mahdavi, CEO of Telnic, .tel has some similarities to the ENUM projects that aimed at binding numbers and email addresses into a unified contact system. However, Mahdavi says that the flaw with ENUM is that it requires users to be on the web where as .tel works on multiple platforms such as mobile devices.

Read full story: External Source

Supported by Bharti, Lleida.net, mobilkom austria, SMART, Telekom Austria, Telecom Italia and Telenor, the PathFinder service pilot achieved an industry first by successfully exchanging international packet voice and MMS traffic enabled via a global, fully-interoperable deployment of Carrier ENUM, validating ENUM as an effective solution to IP-based routing and interconnection. The service automatically translates a phone number into an IP-based address, making it simple and transparent for users to initiate a wide range of IP-based communications via their existing phone numbers and handset address books.

"We found this trial tremendously useful in familiarizing ourselves with the practicalities involved in using ENUM. Cooperation between operators is crucial in establishing how to make the telephone number a universal means to link up with IP-based applications. A simple, standardized process will benefit everyone," said Napoleon L. Nazareno, President and CEO of Smart Communications, Inc. (SMART) and GSMA board member.

By providing mobile and fixed-line operators with a single routing mechanism, PathFinder simplifies and reduces the cost of delivery of a wide range of IP-based services to end-users. It will serve as a central 'directory' for all operators, and enables them to rapidly launch new IP services including packet voice, Instant Messaging (IM), MMS, email, and video, by facilitating the linking of an IP address to a phone number for mobile devices, fixed-line phones and IP devices.

"The successful testing of ENUM on Telekom Austria's next generation environment demonstrates yet again that the infrastructure is ready for commercial customer pilots. With the ongoing improvement in capabilities of our global GRX/IPX platform, recently enhanced by the Carrier ENUM functionality, we are able to provide best-in-class interworking solutions for mobile network operators," commented Boris Nemsic, CEO of Telekom Austria Group and GSMA board member.

Alex Sinclair, Chief Technology Officer of the GSMA added: "PathFinder will accelerate the rollout of innovative IP-based services that will be the key to ensuring profitability in tomorrow's industry. PathFinder provides a one-stop solution for operators to overcome the complexity of delivering IP-based services to communications devices. Furthermore, it helps mobile operators to cut costs and leverage their greatest asset: subscriber phone numbers."

GSMA and NeuStar also announced that Acme Packet and iXLink, a business unit of Telarix, have become the first vendors to successfully complete the PathFinder vendor certification programme, launched as part of the GSMA Industry Partner Programme earlier this year. The Partner Programme initiative is designed to foster working relationships with companies offering products and services complimentary to the PathFinder service, and provides certification of technology vendors, ensuring that PathFinder interoperability testing is available industry-wide.

Further Operator Support for PathFinder

"Bharti Airtel's participation in the carrier ENUM pilot programme paves the way for leveraging Carrier ENUM to create a collaborative ecosystem to route voice and data freely amongst operators. The GSMA PathFinder service will enable a far richer variety of applications and establish the telephone number as a universal means to link up IP-based applications on different networks globally," said Dr Jai Menon, Director, Technology & Customer Service, Bharti Airtel and Group CIO, Bharti Enterprises.

Sisco Sapena, Executive Director at Lleida.net, added: "This new service enables, for the first time, real convergence of services on a worldwide level. The GSMA Pathfinder Service minimizes the existing national barriers to real number portability. With this service, query methods will be much faster and more efficient, providing a better service for everyone."

Communications innovation has been stagnant, in my opinion, for nearly a decade. Telecommunications and Internet communications both seem to be at somewhat of an impasse. The communications industry needs a forum to help break through the stagnancy and highlight the huge opportunity space that is emerging.

The stagnancy has been strikingly more so in telecommunications. For all the talk about IP based next-generation networks (NGNs), there have been no proposed services with any shed of credibility of garnering lucrative customer traction.

The best that the industry has been able to muster up is either triple-play, which has been happily delivered without IP for over a decade and is more a marketing construct than an innovation; fixed-mobile convergence (FMC), although the desire to provide services regardless of network access has merit, the services are again undefined; "user" Telephone Number Mapping (ENUM) is dead in the water already not least because the anticipated success of consumer based SIP phones did not materialize; Voice over IP (VoIP), it's not a new service but just a change of transmission. The operator future roadmap shows little if anything else.

Such telecommunications stagnancy should set alarm bells ringing because the two core products which support the industry are clearly non-existent medium to long term. The two core products are telephony and short messaging service (SMS). The cost of voice transmission will reach near-zero although this is not the only telephony service killer. Voice will become just another mode within a multi-modal offering. The multi-modal offering (be it device/client/site) will itself be integrated with content sharing, commerce, search, discovery and possibly most prized of all — "relationships" (what we call "contacts" today). It makes no sense then to imagine much of future for standalone discrete audio streams known as telephone calls, rather voice will become a supplement. SMS will be replaced by instant messaging long term.

In the Internet communications space there has been a decade long obsession with transmitting voice over IP. The desire was to re-create telephony over IP or for the more visionary, a multi-modal communications client. Re-creating an existing service but changing the means of transmission may be interesting from the technology point of view, but the consumer couldn't care less. The decade long planned protocol basis for delivering a multi-modal client into consumer play (SIP/SIMPLE) has shown little traction; it should be noted that this is the same protocol basis that operators are now hinging their future services around. Instead four years ago a single private company (Skype) delivered a multi-modal client which was architecturally novel (peer-to-peer based), using their own proprietary protocol and which has went on to be the most downloaded program in Internet history. So the SIP/SIMPLE vision to "re-engineer the telephone system from the ground up" is off course at best. Furthermore the World Wide Web (WWW) has largely failed to integrate communications aside from website based messaging. Of course there are plenty of website bolt-ons so that you can click to call or convey a presence status but it's anything from integrated or with appeal. Part of the problem seems to be that the Web development community has focused on pages and content rather than relationships and communications. The last few years have shown the wide recognition of relationships (under the "Web 2.0" banner) so it's most likely a question of time. With the mist clearing up on the opportunity space (recall the telecoms industry is cited as being 1.4 trillion) an exciting race has begun but only for those who understand the communications industry has been asleep at the wheel.

Disclaimer: The above views are solely my own personal views and do not necessarily reflect the views of conference speakers.

Written by Lee S Dryburgh, Founder of eComm Media, Inc

Background

To recap, DNSSEC is an approach to adding some "security" into the DNS. The underlying motivation here is that the DNS represents a rather obvious gaping hole in the overall security picture of the Internet, although it is by no means the only rather significant vulnerability in the entire system. One of the more effective methods of a convert attack in this space is to attack at the level of the DNS by inserting fake responses in place of the actual DNS response. The outcome can be quite insidious. You may think that you have pointed your browser at some web site, but if I can execute this attack on your DNS query then it would be possible to direct your browser to any address whatsoever, or even none at all! And nothing is obviously "wrong". There are no viruses on your computer, no failure of your firewall, no insidious subversion of your NAT. Nothing is changed at your end and everything is working just as intended. But the wrong outcome happened. And of course the DNS is used as the universal rendezvous medium, so pretty much every application starts by firing off a DNS request and then commencing a packet handshake with whatever IP address the DNS has told it. With DNS as it stands today such attacks on the integrity of the DNS, particularly by quite simple man-in-the-middle substitution attacks, are virtually impossible to detect.

DNSSEC is a digital signature framework that is intended to allow anyone to check the integrity and completeness of a response to a DNS query. The approach used by DNSSEC is a relatively conventional application of public key cryptography, where DNS Resource Records (RRs) are digitally signed. This digital signature can be added as additional information to a DNS response, and DNSSEC-aware resolvers can request that additional DNSSEC validation material be provided in addition to any DNS query, and the resolver may then use this material to verify that the response is genuine, and has not been altered in any way whatsoever. For a description of the DNSEEC design you may find a previous article on DNSSEC helpful, namely "DNSSEC: The Theory".

DNSSEC deliberately avoids the use of X.509 public key certificates and the use of an associated Public Key Infrastructure (PKI) by embedding a key hierarchy within the DNS itself. Each zone parent is given the role of signing over every delegated child's zone key, so that a zone's signing key can be verified by confirming the parent zone's signature over that key, which, in turn, can be verified by that zone parent's signature over this key, and so on until you reach a Trust Anchor or the root of the DNS, or, preferably both at once. All this results in the observation that the theoretical trust model of DNSSEC can be reduced to a reliance on trust in only one key, that key being at the top of this delegation hierarchy. In other words, DNSSEC was originally designed with a single trust anchor in mind, that being the public key used to sign the root zone of the DNS, and the deployment model was one of universal adoption across the entire public DNS.

So where are we on this DNSSEC deployment agenda? Within reach? Or a bit of a stretch goal, but still plausible? Or maybe its so far out there that the manned mission to Pluto will happen first!

Root Signing

Some tasks appear to be quite challenging, yet turn out to be really quite simple, while other tasks look simple, but turn out to expose all kinds of daunting problems. In the case of DNSSEC this task of generating a public/private key pair, signing the root zone with the private key and publishing the public key as the material that "anchors" the DNSSEC signing hierarchy is evidently an example of this latter class of tasks, where the seemingly simple becomes the intractably wedged. The root zone of the DNS is quite small, and generating a key pair and creating a digital signature of the root zone is not actually the problem. Indeed, it's a mechanical task at one level and existing DNSSEC tools can achieve this outcome quite easily. An example of what such a signed zone might look like can be found at https://ns.iana.org/dnssec/status.html.

If the mechanics of actually signing the root are so trivial, and we know what the outcome will look like, and you can probably even use the DNS to test your resolver against it tomorrow, then why hasn't it happened already on the actual DNS root? What's the problem here?

Obviously its not technical. So if its not technical, then it must be back to yet another instantiation of the those endless political debates about the DNS, IANA, ICANN and the roles and desires of various governments, political factions of all persuasions and their various retinues and cheer squads. What appears to have got so many folk worked up into a lather in the case of DNSSEC is the consideration of who generates the key pair for the DNS root. Actually that's not quite correct — the observed general paranoia levels start to go stratospheric over the consideration of who has effective control of the private key of the DNS root zone, as this is evidently equated to the well rehearsed public debate that has a paranoia level that could best be described as astronomical in elevation over who exercises actual control over the DNS root zone itself, and somehow this gets even further inflated into the fascinating debate of who has control over the entire universe or something similarly grand.

Descending back to the boringly mundane for a second, there has been a proliferation in number of folk who believe that they have some legitimacy in their claim to have a say over control of their little part of the DNS root zone and perhaps an equally large number of folk who are interested in disputing the comparable claims of others. So who gets to hold this magical key of the DNS root appears to be a Deep and Meaningful Question for many.

I must admit that for me the most obvious response to such DNSSEC root zone signing concerns goes along the lines of: "What's the issue here? The IANA maintains the DNS root zone file, so the IANA should sign the root zone and the IANA should control the zone keys for the DNS root."

While such a response may appear obvious to me, for many that response is totally naive politically and just plain unacceptable. We've seen a number of proposals in recent times that attempt to justify the employment of a cast of agencies drawn from many countries and many international organizations, each of whom are proposed to derive their rasion d'être in being vested the control a tiny part of one bit of the DNS root key, and all of whom are required to provide their consent in order to assemble the actual key value to sign any changes to the DNS root zone. Somehow the mechanical process of signing parts of the DNS root, which is a task that is required for every change to any part of the root zone, so we are talking of an operation that entails a number of signing operations per day, appears to have been confounded with the political process of an endless debate about the process of making changes to the DNS root. I gather that there is the impression in some circles here that there is the endorsement of a cause that a functional outcome can be achieved when every single party here in this somewhat bewildering cast of players has the right of veto over anyone else. The key that would allow others to bootstrap the validation hierarchy in a simple manner is now regarded as the key to define which parties need to provide their permission before permitting any changes whatsoever to the DNS root zone itself. For as long as the evident desire on the part of some to ensure that this political process of DNS determinism is non-terminating holds prominence in the public debate over the governance of the DNS, then the prospects of ever seeing a signed root zone in the DNS also appear to be highly unlikely.

But if one were to dismiss most of this debate of who gets to say which bit of the root zone key should be a 1 or a 0 as a simple exercise in political posturing, and look at this merely as a technical problem within the DNS query and response protocol, the more relevant question is whether adding a DNSSEC signature to the root zone of the DNS would cause any major, or even minor, catastrophe to the Internet at large, or the working of the DNS in particular.

The general consideration when contemplating changes to the root zone of the DNS is whether the basic UDP response to a root zone priming query will be able to be transmitted back to the query party. When a priming query is passed towards a root server with the DNSSEC OK bit set in the EDNS header of the DNS the query should also use the ENDS "sender's UDP payload" mechanism, as the inclusion of the DNSSEC information in the priming response will lift the size of the responding DNS packet to over 576 bytes. So as long as everything between the DNSSEC and EDNS-aware DNS entity performing the query who is asking the root zone the priming query with DNSSEC enabled is capable of doing the right thing with large UDP packets, then all will work. And if the packet is mangled by some reprehensible middleware that mangles DNS UDP packets in bizarre ways, then the query has to drop back out of DNSSEC and perform a non-DNSSEC priming query. It seems that the operational modes do not cause complete breakage here. So as long as the key is correctly handled and the signatures are well formed then from a technical perspective signing the root does not appear to present risks to the operation of the DNS.

Signing the DNS root appears to remain a political question rather than a technical question. For as long as there are folk who equate their unwavering desire to express their interest in the politics of the administration of the DNS with an undeniable conviction that they or others deserve a right of veto in the administration of the root zone of the DNS via their interest in a share of the control of the DNS root key, then this may well remain an intractable political problem. Sigh.

Signing Everything Else

There is one arguably positive aspect of this longstanding political stalemate over signing the root zone of the DNS, namely that the other rather improbable aspect of DNSSEC deployment can be conveniently ignored.

DNSSEC relies on the DNS structure itself to create the interlocking relationships that remove the need for additional verification mechanisms. For a DNS RR to be verified by a DNSSEC-aware resolver it is necessary to both verify the digital signature of the RR and confirm the validity of the signing key that generated the RRSIG resource record. In DNSSEC the parent signs across the child's public key, so the child's key can be verified by verifying the parent's digital signature of this key. This signature can be verified by confirming the digital signature and verifying the parent's public key. This key is verified by its parent, and so on. If the root zone key is the trust anchor of this verification chain then every zone between the root zone and the zone of the DNS RR being verified must be DNSSEC signed. With DNSSEC it's a case that life is far simpler for clients of DNSSEC if over on the signing side of DNSSEC it's a case of one in, all in!

Such a perspective poses the question of just how likely is universal DNSSEC deployment? The story is not yet very convincing, unfortunately. In many cases it appears that the marginal additional overhead of adding DNSSEC to a zone, in terms of the additional zone administrative procedures, the introduction of DNSSEC key management functions, larger DNS zone files, interactions with delegated zone administrators and parent zone administrators, and the possibility of more potential points of service failure, are all borne by the zone administrator ands the zone publisher, while the direct benefits, such as there is direct benefit here, accrue to the DNS client. If we've learned anything about the business of networking over the years it would be good to think that we've learned that in those situations where a large set of folk bear the costs and another, potentially smaller number of folk stand to gain the benefit, and there is no compensatory flow of money to even the scorecard, then the entire proposition is not generally considered overly attractive from a business perspective. Worse still is the picture where the sum of the costs far exceeds the accumulated value of the benefit. Signing everything in the DNS just doesn't seem to represent a natural outcome from the point of looking at each DNS zone administrator as an independent entity who is trying to optimise their own individual position on the cost and benefit account.

Universal DNSSEC deployment, even with a signed root, has prospects that are even more dismal than the signed root proposition. Sigh

The Great Key Hunt

So we haven't yet managed to sign the root, and we haven't yet managed to achieve universal buy-in below the root, and the prospects for achieving both these objectives look dim at the moment.

Are we ready to give up on DNSSEC yet? Of course not!

The design of secure systems often represents a set of design trade-offs, or, in other words, a set of compromises between security, scalability and feasibility. If it is the case that the total cost of deployment and the resultant accumulated benefit are not well aligned, then can DNSSEC take some convenient shortcuts to ease this imbalance, even at the expense of some level of integrity of the security model? Is there any leeway here? Is universal DNSSEC adoption a strict precursor to any realistic level of DNSSEC utility?

In the absence of universal DNSSEC adoption then we might continue along the current path of partial adaptation for some time to come. But what does this mean for DNSSEC? Is partial deployment of DNSSEC something that we could live with in the long term? Or is it more broken than no DNSSEC at all?

Partial deployment of DNSSEC implies that only some zones are signed. A signed zone might have no DNSSEC parent, but may have DNSSEC children. These parent-less DNSSEC "orphans" become the apex of a local DNSSEC hierarchy. For a DNSSEC resolver to be able to verify as much as it possibly can it has to load up all the zone keys that are at the apex of a local DNSSEC hierarchy. Unfortunately there is no automated way to perform such a sweep of the DNS to expose these DNSSEC zones, so the process appears to be one that you perform by hand. Yes, that's manual. And even then you need to derive some form of trust in the authenticity in the key in this undefined process of DNSSEC zone key retrieval and maintenance.

Another way for the resolver to gather these zone keys up is to pick them up one by one on as as-required basis using the DNS itself. This gets rid of the entire process of trying to sweep the DNS for these DNSSEC local hierarchies just in case you might want to pose a query against these zones that you wanted to validate with DNSSEC. So it looks promising. But hang on — wasn't the entire DNSSEC effort directed at providing some means of verifying DNS responses? If you use the DNS itself to deliver these keys that you are going to use as the basis of your trusted verification, then haven't you just introduced a fatal circularity of dependence? How can you trust the DNS to deliver you the correct key that you are then going to trust to validate DNS responses? So this won't work either.

So we are back once more to the basic problem of DNS integrity that DNSSEC was intended to solve. How can you pick up these local DNSSEC apex keys in a reliable and trusted manner without resorting to the DNS? Unfortunately DNSSEC has no direct answer here. How do you know that a DNS zone has been legitimately signed and that the DNS response can be validated? In an environment of partial DNSSEC deployment DNSSEC does not appear to be overly helpful.

Another response has been to contemplate DNSSEC Lookaside Vectors (DLV), which attempt to aggregate a number of apex zone keys of local DNSSEC zone hierarchies into a synthesised DNSSEC zone that allows a single DLV zone key to substitute for the set of stored apex zone keys. If you change the DNSSEC-aware resolver to follow the lookaside vector you can replace the collection of local apex keys with the single key of the lookaside vector zone, as long as all these DNSSEC orphans are prepared to live as the DNSSEC Lookaside Orphage. But in this DLV model we've broken out of the interlocking DNS delegation model, and the question then arises as to the authenticity of the zone keys stored in this DLV zone. While DLV can fly technically, the validity of the outcome is no longer based on the elegant structure of interlocking DNSSEC keys that are precisely aligned to DNS zone delegation. Instead, the strength of the outcome is no stronger than the integrity and accuracy of the admission procedures that are undertaken by the DLV operator. Its hard to see how the DLV approach offers anything more secure than the current haphazard collection of DNS name certificates and the haphazard collection of certificate authorities who issue certificates for DNS names, while at the same time sit outside the name delegation hierarchy.

So the alternatives for the DNSSEC client in a world of partial DNSSEC deployment is to hunt down and maintain a set of trust keys using undefined processes that presumably involve a considerable amount of human direction, or to outsource the problem to a DLV operator in whom you are placing trust that they operate their DLV business with suitable integrity.

Neither alternative sounds overly attractive if you are after the substance of security rather than the optimistically inclined veneer of security theatre. Sigh.

No Such Domain

But even if we were in a world of universal DNSSEC deployment the story still is not overly convincing. If DNSSEC means signing every response that the DNS can offer, then the DNS response of "no such domain" must also be signed, and this too has opened up some further twisted DNS byways.

The DNSSEC mechanism of signing such negative responses appears to be both simultaneously ingenious and flawed. Its ingenious in that the approach of generating pseudo DNS RRs of all the "gaps" in the zone file and signing these "gap" DNS RRs provides the appropriate assurance that there is indeed no such domain in the zone in a manner that allows verification of this absence of requested information. Its flawed in that the approach not only provides information that the particular domain name does not exist, but also provides extraneous information about a potentially large set of other names that also do not exist in the zone file.

In any other domain (if you'll pardon the pun!) any side effects of this DNSSEC signed NSEC resource record would be innocuous, but in the strange and twisted world of the name selling business information about what names do not exist appears to be a highly valued asset. NSEC is just too revealing a response for many players in the domain name industry. What NSEC does is to place an additional RR in the zone and for each name in the zone the RR contains the next name in order, using a standard ASCII ordering of the names in the zone. The obvious inference is that all the names that lie between the two names don't exist, and the result is an indirect method of zone enumeration.

So its been a case back to the drawing board to devise an alternate approach of signing these gaps in the zone file. From this comes the still-being-cooked approach of NSEC3, which uses a far more complex ordering of the records in the zone than simple ASCII ordering. NSEC3, which is still not yet signed off as a stable specification, does not appear to have made DNSSEC any easier or simpler. Indeed quite the opposite. Forbidding and incomprehensible appear to relate to both the design goals of NSEC3 and the outcome! I suppose top marks are in order to the NSEC3 designers for having achieved their objective. What is not so clear is whether this has succeeded in making DNSSEC forbiddingly complex. Sigh.

The DNSSEC Burden

DNSSEC is not free. The DNSSEC burden is spread across the zone administration, primary zone servers, secondary servers and resolvers and the end clients of the DNS. Way back — way way back in the late 1980's the DNS traffic on the NSFNET contribute 20% of all packets on the network of the day. Obviously things have improved considerably since then (we hope!) and its not anticipated that DNSSEC deployment is going to break either the DNS or the Internet at large, but, even so, DNSSEC is not free.

For the zone administrator there's the additional tasks of key management, record signing and managing zone updates. For the primary and secondary zone servers there's the need to support incremental updates to the zone, the advisability of using a trusted channel for zone updates from the primary server to the secondaries, such as TSIG, the larger zone sizes, the larger response sizes and the corresponding increments in processor, memory and bandwidth requirements for the servers. This, in turn, triggers reconfiguration of platform and network capacity for the server side of the DNS.

For resolvers there is the issue of the larger response sizes, the need to ensure that resolvers and the local network infrastructure of firewalls, NAT boxes and other inventive pieces of middleware can cope with EDNS0 and larger DNS response packets that are potentially fragmented, the additional query overhead associated with validation of responses, and that tricky question of what DNSSEC outcomes to cache and for how long.

One major consideration here is that the DNS is already relatively fragile and is the constant target of attack. One way to disrupt a service is to subject its name servers to a constant very high intensity load. In amongst all this noise traffic genuine queries are lost and the servers effectively disappear off the network. For providers this is a balancing act. While the DNS is essentially unfunded, if you are out of action then the outage is highly visible. Given that the attack has been one of loading the DNS server with correctly formatted queries there is no visible clue to the server as to what queries are genuine and what constitute the attack. The common mitigation to this attack is firstly one of segmentation of the server domain through anycast of the DNS servers, and an effort to increase the capacity of the server to absorb the query load associated with an attack without falling over. In this environment we are now seeing implementations of customised DNS servers and recursive servers that are engineered for very high capacity. In this environment DNSSEC applies more pressure through larger responses. A DNS server that is engineered for resiliency in a non-DNSSEC world may not necessarily be able to manage the increased load is all queries in a concentrated attack had the DNSSEC bit included and the zones being used as the target of the query were DNSSEC signed. From the perspective of a large heavily used DNS zone, DNSSEC represents a likely requirement to reinvest in server infrastructure as a consequence of DNSSEC signing the zone. This is not exactly delivering on the generic promise of all this technology as being better, faster and cheaper. Sigh.

What's the meaning of "failure", and who cares anyway?

What should a resolver do in the event of a DNSSEC verification failure?

Let's look at this in a little more detail. If the DNS response is a RR and the associated DNSEC RR signature fails to verify then what should the DNS resolver present to its client? "Server Failure" is just such a pathetic way of backing away from the problem without taking a stance! But if a DNSSEC aware resolver doesn't want to appear to be such a pathetic indecisive wimp, then should the resolver synthesise a NXDOMAIN response in place of the suspect RR response, on the basis that passing on a response that has failed verification is probably worse than a "no such domain" response? What if the NSEC (or NSEC3 for that matter) response has a DNSSEC RR signature that cannot be verified? Here the "server failure" response is still relatively unhelpful and but a more assertive NXDOMAIN, or "no such domain" response is possibly an incorrect response, but, equally there is no better information at hand to substitute in its place. There is nothing quite like the quandary you are p[aced in when trying to do the "right" thing when you know that the answer you are about to give to your client is shonky, but being completely unable to do anything about it!

But what is failure anyway? And, more particularly, what is "failure" in a partially deployed DNSSEC world? A digital signature that cannot be verified is a clear failure. The lack of an upward chain of parent signatures that leads to a trust anchor is also a failure, but of a different type. It could well be that in this case the DNS RR provided as the answer to the original query is perfectly good in every respect, including the DNSSEC RR signature and it's the resolver's efforts to hunt down all of the apex zone keys for each and every local DNSSEC hierarchy. Or the resolver could be the victim of a DNS attack. How can a resolver tell the difference? Is this a benign failure, or an instance of a failure that points to a directed attack via the DNS.

Of course undermining all this is human behaviour. When the screen presents you with the message: "I cannot validate this certificate, do you want to proceed anyway: Yes or No?" we are all pretty much the same when we move the mouse to hover over that "yes" button. DNSSEC might be as paranoid as it wants, but we humans are all risk takers of one sort or another, and even when presented with a dire warning of the risks involved, there's a certain air of digital bravado that creeps up upon your clicking finger when given the opportunity to take a risk! So all this security infrastructure can be undermined by an all too typical user behaviour mode. Sigh.

So tell me again ...

It still seems somewhat bizarre to me that much of the public consideration of DNSSEC has been on the topic of the number and composition of the group of people who must have their trembling fingers touching the pen that signs the root zone of the DNS. The politicization of this question of "who signs the root?" appears to ensure that the root remains unsigned, and as a consequence any hope of universal deployment of DNSSEC flies out the window. It appears that without a signed root partial deployment of DNSSEC is the best one can hope for, and partial deployment of DNSSEC is, on the whole, an instance of negative progress.

Without a signed root DNS resolvers need to do the impossible and perform minor miracles in terms of trust key discovery and management. The impossible happens only with considerable pain and effort, and even then it happens rarely. The question is then raised as to why should zone administrators and DNS operators incur additional costs to locally deploy DNSSEC given that there are a vanishingly small number of DNSSEC queries to be answered from these few bold and adventurous DNSSEC-aware resolvers? From this perspective it appears to be counter-productive to be fixating on the issue of how many potential signatories should be dancing on the head of this root zone pin .

Surely the answer to signing the DNS root is one that has been staring us in the face since the start of this entire DNSEC effort. As with all zones, it the role of the zone administrator to generate the keys and sign the zone file. In the case of the root zone of the DNS its back to the IANA to just do the job and let the rest of us move on.

But "moving on" is not the same as solving all the issues of Internet insecurity though the scribbling of just one signature over a block of bits with a digital pen. It is apparent that the lack of a signed DNS root has become a convenient way to paper over the other issue of the lack of DNSSEC deployment across the remainder of the DNS and the poor prospects for ever changing that situation. Its still a very hard problem to work out how to swing the balance around in the DNSSEC cost and benefit equation so that the benefits of deploying DNSSEC on the server side can motivate its deployment such that the client side benefits of a more robust DNS can be realised.

And even if we address that and move into a DNSSEC world, there is the observation that most of the technology failures we encounter in this area are outcomes of benign rather than hostile actions, and that failures is a product of incompetence rather than malice, and this is no doubt going to continue. We have become habituated as seeing "failure" as an accidental and unintended outcome, rather than a dire warning of potential danger. We have grown so trusting in the technology that when the technology offers us choices then we believe that it really is a choice between equally viable options and that both options are equally 'safe' from the point of view of the underlying technical machinery. Otherwise why would this machine be asking us for guidance in the first place?

The substantive issues for DNSSEC are much further down in the DNS hierarchy than at the root, but we're never even going to have the opportunity to address them as anything more than hypothetical issues to be considered in the abstract for as long as the unsigned DNS root remains in our way.

Written by Geoff Huston, Author & Chief Scientist at APNIC

Jay Daley, technology director at Nominet, said the directory would be populated with numbers for the UK's voice over IP (voip) networks that route telephone calls through the net. "It's going to change the business model for communication providers quite seriously," said Daley. Germany, Australia and Ireland, have already started work on their national Enum directories. 

Read full story: BBC

Suppose you were a university campus and when you looked at your phone bill, you noticed that a lot of calls were to other universities. You've got a VoIP telephone system; they've all got VoIP telephone systems. You might wonder "isn't there some way to route these calls over the Internet and save some serious money?"

The answer, of course is "yes" but making it usable is a little harder than simply routing packets. The problem is all about identifiers and addresses. In this case, identifiers that are addresses.

Traditional phone numbers are tightly controlled by the telcos, unlike the world of Internet addresses. The simple answer would be to use something like SIP URLs, but we run into a usability problem: most people's phones have a regular, standard-issue DTFM 12-key dial pad. Using that to enter SIP URLs is a non-starter for anyone but the most hard-core.

ENUM could provide some help. ENUM is method for providing DNS-like services for phone numbers that piggybacks on DNS. The problem is that it's not very DNS-like. In DNS, control of a subdomain can be delegated (the zone file), but with ENUM, it's hard to delegate responsibility for zones to the right entity. This is because ENUM is based on traditional telephone numbers and so the zones don't necessarily match with entities who care. For example, who should responsible for the "3" zone inside the 801 area code?

Todd discusses an alternative approach called ISNs. ISNs rely on a new number, administered by IANA called an ITAD or Internet Telephony Administrative Domain. Like a domain, anyone can get an ITAD. Once you have one, you control the naming inside that number, just like you control the email addresses inside your domain.

ITADs are combined with an internally assigned number (called the subscriber number) to create an ISN. So, suppose that BYU's ITAD was "256" (it's not). My extension is "26465" so my ISN would be "26465*256". Someone at another entity with a SIP phone could call me, from a regular keypad, by calling that number.

It seems that my i-name registrar ought to be able to apply for an ITAD and then assign a number to be that resolves to by i-name and then use the information in my XRDS file to route the call for me-even to my cell phone if that's where I've pointed xri://=windley(+phone). That's a service I'd like to see. 

Written by Phillip J. Windley, Author & Consultant

"We are very pleased to add NetNumber as a key partner in the Alliance," said Jeff Ganek, NeuStar Chairman and CEO. "The value of the Industry Alliance Program is the sum of its interconnected partner members, and NetNumber's TITAN and SPIDER technologies will bring strategic merit to our suite of interoperability solutions."

"We believe that collaboration between our companies and our technologies will help speed the adoption of direct network peering between key communications industry participants," said Glenn Marschel, NetNumber CEO.

The NetNumber TITAN platform is a highly flexible, carrier-grade, multi-protocol addressing infrastructure used by service providers to support multiple IP and SS7/C7 address resolution services. The Service Provider Interconnect Data Exchange Resource (SPIDER) is a specialized registry data distribution platform developed by NetNumber that is used by registry solution providers to enable the efficient exchange of interconnect address information between trusted communications service providers and VoIP communities.

NeuStar's SIP-IX is the first comprehensive suite of services designed to enable direct network-to-network peering between trading partners for voice, video and content services using Session Initiation Protocol (SIP)-based technologies such as IP multimedia (IMS) and VoIP. Derived from NeuStar's private ENUM infrastructure, SIP-IX is a comprehensive service that integrates NeuStar's policy-enabled shared directory services into the peering fabric of major Internet Exchange Providers around the world.