[LINK] Enum musings

[Chirgwin, Richard]

With permission, I'd like to deal with the three responses in one message.

Ian - you're right about the lack of objective info; and thanks for the
links.

James writes:
>As far as I can tell, ENUM was originally designed simply to allow VoIP
>databases to interconnect easily. The actual software/standard was
described
>to me as "ridiculously simple". However, the concept allows a whole lot of
>other things to be done, which means that the regulators have to get their
>act together.

Interconnecting VoIP databases doesn't per se require Enum. Any database can
be mapped to any other database if you know the metadata. Enum is explicitly
about expressing non-DNS numbers in a DNS hierarchy. 

Software is always described as ridiculously simple, unless the vendor is
trying to justify a vast price (a la SAP) in which case they say "this is
very complex stuff that needs squillions of dollars in configuration".

About "regulators having to get their act together", I have a really radical
question: why? What is being inhibited by regulators not having their act
together? and apart from industry-push, what's the evidence that regulators
don't have their act together?

>I don't think users will be charged to have an ENUM, I think they will
>automatically have it if they use a VoIP service.

I don't see anything to suggest that it would be automatic. It's clearly
positioned as a value-add. For eg, in a recent ACA presentation (quoting
from the PowerPoint), it's about new services - and no telco intros a new
service unless it's billable.

Glen Turner's remarks:
>The flip-side of this is that users can implement intelligent
>telephony services, not just SS7-speaking telcos.
Yes, but it's easy to imagine downsides. Not just that users may do it
badly; but also:

- wherever 'user empowerment' has been the catchcry, users end up paying for
services that used to be free. Look at banking, for example. Transactions
were once considered sunk costs; then, they were charged for but you could
do it free on the Internet (you get empowerment, but you have to do your own
data entry); then, the Internet transaction became billable.
- freedom to 'do it your way' always looks a lot more attractive to the geek
(sorry Glen!) than to the punter. Some people are employed to build stuff,
and they like having more stuff to build (fair enough).
- it's an odd direction for the industry, frankly: would anyone suggest that
users are better off replacing any other utility service with their own
implementation? In some specific cases, perhaps; but broadly, no. 

>DNS is a distributed database, so a DoS attack against the
>DNS isn't simple.  There's plenty of room for telcos to engineer
>in additional robustness -- for example, by taking slave copies of
>each other's DNS zone files.  Also, rolling out DNS is a lot
>easier than rolling out SS7.  So each switching core could
>hold a DNS server, very unlike SS7.

Of course that's so. But while rolling out DNS is easier than rolling out
SS7, is it a complete analogy? 

The slowest part of rolling out an SS7 database is configuring the numbering
plan - the database itself is simple enough. But every country has its own
numbering plan, and the SS7 database has to be configured to reflect that. 

Telephone numbers are more fluid than the DNS - a company doesn't change its
DNS entry as frequently as an individual may change telephone numbers.
Synchronising and maintaining a highly distributed database gets harder in
proportion to its decay. Are there technical solutions? Partly, but they
don't solve database quality (junk whois data as an example, or fraudulent
domain entries).

In response to:
>> There are things that Enum can't do - for just one example, I don't see
any
>> provision in the standard for one physical line servicing multiple
numbers
>> (eg, a PABX).

Glen notes:
>They'd buy a DNS delegation of a ENUM number range, just like
>buying a SS7 number range now.

That takes care of the ownership of the number range, but does it completely
address assignment? What about administrative overhead? - With VoIP (in
theory) you can move your staff without calling a technician (instead, you
call an MCSE who is, in no way, a technician). But add an external
delegation authority, and you introduce new admin overhead; the company is
uncontactable for hours because someone typed foo.baa.com instead of
foo.bar.com ...

The overhead may be justifiable in terms of benefit received; but (speaking
as a journalist now) this tradeoff is >not< in the public debate yet - it's
all upsides. Optimists don't build robust systems...

Now to the vexed question of regulation. A simple question: is ICANN, as a
body, fit to stand as the international root for phone numbers? At the
moment, telephony numbering systems are national - ie, Australia administers
Australia's phone number plan.

My understanding - subject to correction! - is that the DNS hierarchy is
ultimately tributary to the highest-level directory. So Enum says two
things:
a) create a database in which an individual is identifiable by a DNS
registration; and
b) centralise administration of the hierarchy to ICANN. 
I'm not comfortable with that idea...to adopt it merely because Enum enables
technical solutions is close to the cargo-cult mentality of trading rights
for trinkets.

Richard
----------
For Link list information see http://sunsite.anu.edu.au/link/