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

Jim,
 
I fully agree what you said about "private" (intranet) trees and that ONE public "silver" tree makes
sense (and this is BTW also what ETSI is after) - but I just cannot believe that it will happen.
At least not at the beginning, considering the mistrust between operators - maybe later
when they have learned a lesson - and then it may be too late.
 
I also agree with Lawrence in the other e-mail that an end-user device will never be able to
query the carrier ENUM trees, and if then they will not be able to use the information they get,
you just need to point to a border element requiring authentication.
 
-richard

________________________________

Von: Jim Reid [mailto:jim at rfc1035.com]
Gesendet: Di 14.12.2004 11:15
An: Stastny Richard
Cc: Marco bernardi; Richard Shockey; Andrzej Bartosiewicz; Carsten Schiefner; enum-wg at ripe.net
Betreff: Re: AW: [enum-wg] COCOM & ENUM ... 



>>>>> "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. [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.

What *is* important is that there's a single domain name and a single,
consistent name space. 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...

    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. A centralised database could well mean telcos expose
their customer and call routing data to each other. Which is unlikely
to get much acceptance.