AW: [enum-wg] COCOM & ENUM ...
Richard Shockey richard at shockey.us
Tue Dec 14 19:48:05 CET 2004
At 05:15 AM 12/14/2004, Jim Reid wrote: > >>>>> "Richard" == Stastny Richard <Richard.Stastny at oefeg.at> writes: > > Richard> I fully agree and this is one of the problems I see by > Richard> introducing carrier E**M via a backdoor in e164.arpa. If > Richard> I am a carrier, especially a carrier acting on an > Richard> international basis, I want to implement routing > Richard> mechanisms within my network and with other networks > Richard> (peers) without having to go to a NRA begging first to > Richard> opt-in in e164.arpa and second to behave according to > Richard> various and different national rules. > >Richard, these points are undoubtedly true. However they have nothing >whatsoever to do with the choice of domain name for carrier ENUM. So >far, nobody has presented any compelling reason why another domain >name is needed for carrier ENUM. HUH are you kidding ... its is because of the basic and orthogonal conflict between what carriers need and want and what end users need and want. The problem is administrative how do two occasionally diametrically opposed entities share a single name space. I perfectly understand the technical dilemma service providers have but if you look a what it will take to actually implement such a policy you are left with 3 basic options. Either bifurcate the tree at Tier one into two non terminal NAPTR records (public & carrier)..which BTW will break SIP applications since there is no standards any where on how to deal with this. Two merge T1 and T2 into the national registry which makes the registry operator the central repository for ALL SIP routing data for both the carriers and end users...which at least preserves the existing model of the DNS responds with an "answer" ..the carriers can still use non terminal records but normal SIP CUA's would simply ignore them. Three have two entirely separate trees ..e164.arpa for number holders e164.int for carriers. The .int tree could be designed to look into apra for answers it is not authoritative for. Problem solved. >[Perhaps that discussion is going on >behind closed doors at ETSI or somewhere like that.] Sure, carrier >ENUM shouldn't be in the public e164.arpa tree. This doesn't stop an >operator from creating their own private e164.arpa tree, populating >that with whatever it likes and then making sure the applications on >the operator's net queries the private tree rather than the public >one. This setup is known as split DNS and is very common. Most large >companies do this. What we see on the internet for bt.com (say) will >be very different from what someone inside the BT network sees. oh no we're not going down that rat hole of split DNS >What *is* important is that there's a single domain name and a single, >consistent name space. I dont agree the applications are sufficiently orthogonal enough to argue that the administrative policies and procedures are different enough to justify two separated trees. > Many of the applications and services -- eg >VoIP and SIP -- that will be used by telcos will also be used on the >public internet. Suppose I'm developing or selling and supporting some >ENUM-aware SIP application. I don't want to have the complexity and >expense of needing to configure it to do ENUM-like lookups in >foobar.at if the box lives in Telekom Austria's net today or >vf.enum.egpp.net if that's where Vodafone's chosen to anchor its >carrier ENUM tree this week. And as for an ENUM-aware SIP client in a >mobile phone that roams between operators... Or flips between 802.11 >and GPRS nets... you forget the basic consumer or PBX edge ENUM resolver has no need to see the carrier data. > Richard> A carrier E**M implementation does not need a tier 0 and > Richard> tier 1, and it is questionable if it needs a tier 2. It > Richard> needs a centralisized database operated by someone, and > Richard> who this is will be decided by the community as will be > Richard> the other rules. > >The Tier-N jargon is probably inappropriate. However the roles might >not be. And I'm not sure a centralised database for carrier ENUM is >viable. It has obvious attractions: carriers sharing a common >infrastructure for example. OTOH, it brings problems too. Figuring out >who operates that infrastructure and how it gets paid for will be >entertaining. Oh that is real simple ... the carrier of record of the TN will immediately know how to fund and manage that namesapce for their respective portions of the .int tree for instance or they will use totall out of band methods of exchanging TN to URI data like LNP data bases that push the data into carrier networks. And BTW most all the carriers I talk to these days want the data presented to them via SIP redirect/location servers not DNS. >A centralised database could well mean telcos expose >their customer and call routing data to each other. Which is unlikely >to get much acceptance. Well then you have argued that LNP databases dont work and I have it on good authority that they do :-) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[ enum-wg Archives ]