I agree with Kevin. The issue of LNP becomes a problem when you have say 10,000 numbers and all of a sudden one gets transported off to another provider. Then the fun begins.
I want to break from the Telco portion for a second and comment on your remark that ENUM is a domain business. That for me is a problem as well. DNS is DNS , its not the DOMAIN business. Domains are Domains, ENUM is ENUM. I noticed the .CA people in Canada seem to have designs on ENUM as well. To me that is nothing more than a revenue issue. ENUM folks like e164.org have done excellent work but many of us are looking for something that operates a bit different. DUNDi looks like a solution to many problems plus, I don't need to be concerned about another ICANN like creation in my technical travels. Not that ENUM is ICANN - ! Brandon > On 2004/10/20 21:10, "Kevin P. Fleming" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) | nic.at Systems Engineer > > _______________________________________________ > Asterisk-Dev mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-dev > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
