Subject: Re: [Enum] User ENUM vs Operator ENUM

From: "Yu, James" <[email-masked]>
Date: Sat, 12 Jun 2004 10:31:08 -0400

One example/use of carrier ENUM is to retrieve the routing number/prefix for
a ported phone number.  End User ENUM will not have this NAPTR RR (end user
will not have the knowledge to put in the info.). 

As Richard mentioned, carriers use carrier ENUM for inter-carrier
communication/routing (e.g., identify the MMSC for a mobile phone number or
the SIP URI for receing incoming INVITEs).  So carrier ENUM contains NAPTR
RRs for the phone numbers served by the carriers.  A carrier can put in the
service info. only for the phone numbers it serves.  In end user ENUM, an
end user can put service info. associated with many carriers and/or
non-carrier service providers (e.g., those who don't assign phone numbers to
their subscribers).

General public may not access NAPTR RRs in carrier ENUM.  Access control can
be applied to carrier ENUM to block unauthored access.  Also the access can
be retricted to private-IP networks if the carrier community decide so
(e.g., carrier ENUM's DNS servers can only be accessed via private-IP
networks such as the GRX in GSM/GPRS and the CRX that is discussed among the
CDMA carriers. 

James 
--------------------------
Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: Stastny Richard <Richard.Stastny at oefeg.at>
To: Lind, Steven D, ALABS <sdlind at att.com>; Richard Shockey
<richard at shockey.us>; enum at ietf.org <enum at ietf.org>
CC: jseng at pobox.org.sg <jseng at pobox.org.sg>; mah at eunet.at <mah at eunet.at>;
paf at cisco.com <paf at cisco.com>
Sent: Sat Jun 12 05:45:05 2004
Subject: [Enum] User ENUM vs Operator ENUM

Steve wrote:

>As to your proposed agenda item 1, I believe that the direct should be:

>1a: What are the issues/problems that need to be addressed?
>1b: What are the reasons that "Public" ENUM can't solve them?

>I've never gotten any answers on those questions from my European
colleagues that seem to be more involved in the >"Carrier" ENUM activities
on that side of the pond.

You are correct insofar that your  "European colleagues" are more involved
in "Carrier" (infrastructure, operator)
ENUM activities, because ETSI is trying to write a TS on this issue.
 
Sorry for answering a bit late, but I was yesterday at a meeting on this
issue hosted by a Telco operator,
which implies that one is incommunicado Internet-wise ;-)
 
A short recap of  the status:
 
On one side you have User ENUM, which means this is End-user to End-user on
the 
Internet. This implies that the calling user has direct access to the data
in the DNS and 
also can do something with the retrieved data. It also implies that the
called user
has direct or indirect managing access to the data in the DNS, especially he
is provided
by his VoIP SP with a public accessible URI. It also means that you may use
the information
provided in DNS for establishing communication, but if you know the URI you
also
be able to establish the communication without using ENUM. ENUM is only
necessary
to establish communication form the PSTN because you cannot enter a URI. It
also
implies that there is zero termination charge to reach the called party.
User ENUM
should be implemented in e164.arpa, but could also be implemented in other
trees.
If in all trees the rule is obeyed that only the entity having the right to
use
the E.164 number in the first place is the domain name holder, a later 
merging of the trees is not a problem.

On the other side you have operator ENUM: Operator ENUM is used to route
calls between operators - as the name implies, and NOT end-user. So operator
ENUM is all about linking controlled VoIP islands together. Other buzzword
coming into my
mind is walled-garden, termination charges, hiding of end-user
information, session border controllers, NGN, cable-networks, IMS, 3GPP, MMS
routing
etc..
 
User ENUM and operator ENUM are orthogonal to each other regarding opt-in
numbers, because operator ENUM can really be considered as part ot the PSTN.
For opt-in ENUM entries, one looks first in User ENUM, and if no entry is
found, he looks in a (or more) Operator ENUM trees, and finally as a last
resort
he dumps the call to the "real" PSTN.  Done correctly, he should find the
information
in operator ENUM finally always, especially if no conventional PSTN exists
in 5-10 years.
 
On hack in this is the now created ENUM-enabled number ranges which can only
be resolved in User ENUM.
 
For operator ENUM the same applies as for User ENUM: 
If in all trees the rule is obeyed that only the entity having the right to
use
the E.164 number in the first place is the domain name holder, a later 
merging of the trees is not a problem (but see high-jacking below). 
The only difference here is that
the domain name holder in this case is the operator, because there
is nor opt-in from the user, which also implies that either the information
is not in a public DNS, not in a public accessible DNS, or if in a public
accessible DNS, the information does not disclose any "privacy" information.
 
This means you may find in a domain related to a number e.g. 
+4319793321 only NAPTRs in the form e.g. 
sip:+4319793321 at provider.net,  which is in essencey
all what operator ENUM is about:
finding the operator or service provider hosting the number.
 
One word about high-jacking of numbers: in User ENUM high-jacking
is an issue because the number exists on the PSTN and on the Internet,
at least for opt-in numbers (not for ENUM-enabled numbers).
 
In operator ENUM high-jacking of numbers would not be a problem,
if zero-termination would apply and also if calls would only be routed 
to the destination network (no transit function).
 
This means, if everybody would put in operater ENUM only the numbers
he is hosting (and why should he put in other numbers, because he cannot
terminate it), as said above, the whole could start out with 10 differnt
trees,
but merging trees would not be a problem, because there would be
no "domain name disputes".
 
There is only one problem with this: operator ENUM created by
con-federations
will also be used for transit routing:
 
Take the following (virtual) example: US-cable operators aggree to use
a common "private" database to route calls between numbers hosted by
these cable operators directly between also privatly agreed upon IP-based
Point of interconnect. All other calls will be routed to the "PSTN".
 
Now one  UK-cable operator joins the club. The easiest thing to do is to
route
ALL calls to +44 to this cable operator via the PoI of this UK operator. So
ENUM
is used to find the terminating network (for the numbers the UK operator is 
hosting himself, and as a transit (bypass) network for all other UK-numbers.
One could call this legal high-jacking ;-)
 
The problem only starts here of another UK operator is joining the club
or if two trees are merged.
 
To summarize: 
 
-User ENUM and operator ENUM are in principle
orthogonal and may co-exists. 
 
-Starting with more than one tree in both of them is not optimal, but
causes problems later when merging only if number or number-ranges 
are high-jacked (legally or illegally). So having a parking tree besides
e164.arpa for user ENUM is NOT a problem if some minum rules 
are obeyed
 
If  User ENUM or Operator ENUM finally survives is not decided
by ENUM, it will be decided in the battle between NGN vs Internet
(or Zero termination vs Termination charges)
 
best regards
Richard

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

---

From: James Seng <[email-masked]>
Date: Mon, 14 Jun 2004 01:41:26 -0400

yes, i seeing trends that people wants to restrict their enum dns to 
only certain parties whom they have established relationship.

we can debate whether that is a good thing or not, but suppose they want 
to, i am not sure we can do it using enum/dns at all...

james
Yu, James wrote:

James 

-----Original Message-----

 

 

 

 

 

To summarize: 

 
 
best regards
Richard