[Asterisk-Dev] DUNDi (Was: A crazy idea... Skype channel in Asterisk)

[Otmar Lendl]

On 2004/10/20 21:10, "Kevin P. Fleming" <kpfleming at starnetworks.us> wrote:
> Wolfgang S. Rupprecht wrote:
> 
> >My gut reaction is that this seems like an awful lot of new code just
> >to do something that an open ENUM-like DB would do.  If the problem is
> >that none of the current ENUM administrators will delegate, then
> >*that* is the problem that needs fixing.  Creating a new protocol
> >simply to get around the delegations problems is a bit over the top.
> 
> But that is _not_ the entire problem, have you read the DUNDi whitepaper?
> 
> Here is a simple example where ENUM breaks: I am an ITSP, and I support 
> LNP. That means customers can bring numbers to my system. So, I get a 
> new customer, and they bring over +1-555-555-1212 to my service. Note 
> that I do not currently service _ANY_ other numbers in +1-555-555.
> 
> How, and who, would delegate to me the control I would need to manage 
> the NAPTR record for this number? How many levels of delegation would 
> there be, and who would be those "registrars"? What if the +1-555-555 
> number block was originally assigned to the ILEC in my area, and they 
> are also the registrar for all of +1-555-555 in e164.arpa? I then have 
> to convince them to let me manage this _ONE_ record in the zone that 
> they otherwise control?

Austria will start production ENUM services in a few weeks and the
setup here will not replicate the number-block assignment hierarchy
in the ENUM domain. E.g. while +43664 is owned by Mobilkom Austria, 
they will not get a delegation for 4.6.6.3.4.e164.arpa.

Delegations from 3.4.e164.arpa will always be to full numbers.
(The only exception could be DDI blocks, but they are handled completely
different that in the US, as we have an open number plan under +43 where
the lenght of a number can vary.)

Thus you never have to go to a competitor to get an ENUM domain for 
a single number. You always go to enum.at which will run 3.4.e164.arpa.

> Yes, this the same problem that exists for LNP on the PSTN in the United 
> States, but that is solved by having a single, government-authorized 
> authority to manage the database (although it's still a major amount of 
> work to port numbers, and it takes forever). What DUNDi wants to avoid 
> is that situation occurring again in E.164/VOIP space.

Basically, here in .at the backend DB driving the ENUM domain for
Austria fulfills the same role as your government-authorized database.
(Well, enum.at *does* have a contract with the regulatory authority
to run this service, so the comparison is quite apt.)

We've put in a lot of thought into the design of the actual process
of ENUM delegation. We hope that we found a model which is a lot more
efficient than the processes used for LNP or MNP.

> DNS does not lend itself to lots of little delegations (for individual 
> NAPTR records), and it doesn't have any reasonable way to be extended to 
> support that. It's a pain the in rear just to get a delegation to handle 
> the reverse DNS for a /27 (or smaller) IP address block, just imagine 
> what it would be like for a _single record_, and when the authority 
> controlling the upper level zone is a direct competitor of yours.

As others mentioned before: that's not an issue of the DNS protocol, but
one of the current DNS server implemenations. If you drive you
DNS servers from a suitable DB (e.g. have a look at PowerDNS) then
you don't have a problems dealing with a huge number of zones
on a nameserver.

ENUM is domain business. As most ISPs and webhosters have shown: the
problem of getting and handling a domain per customer is solvable.

/ol
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >