Subject: [Enum] Re: Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful)

From: "Stastny Richard" <[email-masked]>
Date: Thu, 23 Jun 2005 10:17:51 -0400

Jim,
 
you are completely missing the point:
 
First you say
 
>Therefore each telco will want to set up and run their own Carrier ENUM
>infrastructure according to their own rules and populate that with
>whatever they want. Which is fine. 
 
Agreed, they may do this any time, but it does not help to
INTERCONNECT
as you say: yourself a bit later:
 
>Now telcos could probably share a single, private tree for
>Infrastructure ENUM. 
 
emphasis on SHARE
 
and you say:
 
>Unless I've missed
>something, a telco is likely (amongst other things) to use
>Infrastructure ENUM to figure out which SIP server to use for
>terminating VoIP traffic for a given telephone number.
 
Not only for telephone numbers:
Now we are at the point: How are the SIP URIs resolved:?
 
And how are the PUBLIC User Identities in IMS
resolved?

How is sonera.fi resolved, not to speak about
sip:richard at stastny.com, which I may have according
to IR.65 ?
 
Again, please read IR.65 and come up with a workable solution
for their problem.
 
Richard

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Thu, 23 Jun 2005 12:59:02 -0400

On Jun 23, 2005, at 15:21, Stastny Richard wrote:
Jim,
you are completely missing the point:
First you say
Therefore each telco will want to set up and run their own Carrier 
ENUM
infrastructure according to their own rules and populate that with
whatever they want. Which is fine.
Agreed, they may do this any time, but it does not help to INTERCONNECT
Yes, it does. There are a number of ways this can be achieved. BT could 
come to an agreement with Telekom Austria (say) along the lines of "you 
can get access to my copy of 4.4.e16.arpa if I can get access to your 
copy of 3.4.e164.arpa". Or Telekom Austria's Infrastructure ENUM could 
just have entries which say "throw all calls to the UK at the SIP 
gateways provided by whoever is our UK based 
telecoms-partner-of-the-month".

Now telcos could probably share a single, private tree for
Infrastructure ENUM.
emphasis on SHARE and you say:
Please remember I said that the telcos were very unlikely to share a 
common infrastructure. Aside from the problems of agreeing the 
requirements and a way of paying from it, no telco is going to rely on 
infrastructure outwith its control for the core operational job of 
routing phone calls.

Unless I've missed
something, a telco is likely (amongst other things) to use
Infrastructure ENUM to figure out which SIP server to use for
terminating VoIP traffic for a given telephone number.
Not only for telephone numbers:
Now we are at the point: How are the SIP URIs resolved:?
In the same way as anything is resolved. You just look it up in the 
DNS! If my internal DNS setup has a private instance of e164.arpa which 
I use for my own purposes, that does not prevent my name servers seeing 
and resolving anything under the public root on the internet. Apart 
from stuff under e164.arpa of course: instead of the public ENUM name 
space (the User ENUM tree), my world sees my private, internal copy. 
But that's OK because that's what I want everything in my world to see 
for that part of the name space.

FYI, I'm doing something like that right now and it works perfectly. My 
wireless net at home uses RFC1918 addressing, 10.0.1/24. Reverse 
lookups of these addresses can't work on the internet as the range has 
been set aside for private use. So my name servers have their own 
private version of 10.in-addr.arpa containing PTR records for the stuff 
on my wireless net. Local clients get these names back from the DNS 
when they do reverse lookups. If they tried resolving them on the 
internet, they'd get an NXDOMAIN response from the AS112 name servers 
which serve up the public version of the 10.in-addr.arpa zone.

And how are the PUBLIC User Identities in IMS resolved?
If those names don't live under e164.arpa, see above.
How is sonera.fi resolved, not to speak about
sip:richard at stastny.com, which I may have according
to IR.65 ?
I refer you to my previous answer. ;-)
Again, please read IR.65 and come up with a workable solution
for their problem.
I will read this document later today. However given some of the 
"interesting" DNS architectures the GSM has come up with in the past -- 
.gprs anyone? -- it may be hard to find solutions for them.

I think there's still a very big disconnect between bell-heads and 
net-heads. Few of the former seem to know how the DNS works (or can be 
made to work). Few of the latter understand SS7 signalling or how calls 
get routed in the telco world. Sigh.

---

From: Michael Haberler <[email-masked]>
Date: Thu, 23 Jun 2005 13:15:41 -0400

At 18:58 23.06.2005, you wrote:
Agreed, they may do this any time, but it does not help to INTERCONNECT
Yes, it does. There are a number of ways this can be achieved. BT could 
come to an agreement with Telekom Austria (say) along the lines of "you 
can get access to my copy of 4.4.e16.arpa if I can get access to your copy 
of 3.4.e164.arpa". Or Telekom Austria's Infrastructure ENUM could just 
have entries which say "throw all calls to the UK at the SIP gateways 
provided by whoever is our UK based telecoms-partner-of-the-month".
IMO the value add of an unvisible identifier visavis a visible, but 
unreachble identifier is moderate to nonexistent, especially if the 
associated downside is private tree bartering. Management cost is an issue 
and I cant see revenues going up in telco space.

Plus, in business terms split DNS is a good way to kill user ENUM long 
term. When you get critical mass in a tree, however that mass gets used, 
cost per entry goes down  and operation becomes sustainable.

Tom Kershaw's right in a sense - whoever gets 30 million entries wins the 
game - not necessarily as a company but as an approach.

I'd add - if that is the barrier I wouldnt bother too much how the entries 
are used - carrier or user. Plus, there will be no "migration" from tree 
swapping to user ENUM if that eventually takes off.

-Michael