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

["Conroy, Lawrence (SMTP)" <]

Hi Jim, Richard, folks,
  I beg to differ with my esteemed colleague Jim. I would be very 
surprised
if an end user's terminal queried carrier anything, and would be even 
more
surprised if it received a response. This is akin to suggesting that if 
my
phone fired off an INAP query it would receive a response. With SCTP it 
might
be theoretically possible, but I don't expect anyone would be listening.

In the "new wine in old skins" world of NGNs, the infrastructure might 
make
queries as part of a routing process, and one service provider would 
almost
certainly get a different answer from the one responsible for the target
resource (i.e. the "destination" service provider will probably be 
running
a split horizon system), but would my SIP phone get ANY such 
information?

Private and Public are the wrong terms - if service providers share some
information to facilitate routing of communications sessions, this does 
not
make that information public (e.g. available to anyone anywhere on the
Internet). It's shared between carriers.

I sure hope that their infrastructure doesn't roam - the bean counters
would not be happy.

all the best,
  Lawrence

On 14 Dec 2004, at 10:15, Jim Reid wrote:
> > > > > > "Richard" == Stastny Richard <Richard.Stastny@localhost 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.