AW: [enum-wg] COCOM & ENUM ...

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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<