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
