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

From: "Yu, James" <[email-masked]>
Date: Tue, 15 Jun 2004 09:48:35 -0400

Access control is a way to limited access to the service info. in carrier
ENUM if the carrier community does not want the general public to access
that info.    Whether and how to do it are implementation issues.  This
subject is certainly not one we need to discuss here.

Also retrieving the service info. for a TN from Carrier ENUM does not mean
the call/message/transaction processing may continue.  One example is the
inter-carrier Multimedia Messaging Service (MMS).   Carrier ENUM can be used
by the Originating Multimedia Messaging Service Center (MMSC) to retrieve
the Terminating MMSC host info. (the MMSC that serves the phone number that
is shown as the destination address of a to-be-delivered multimedia
message).   After retrieving the MMSC host info., the Originating MMSC can
check if there is a business relationship with the termiating carrier.  If
not, it can drop the message.

Carrier ENUM is no different from End User ENUM in term of DNS queries and
retrieved NAPTR RRs (although Carrier ENUM may define some "enumservice"
values that are not used by End User ENUM and vice versa).   But the
provisioning/administrative processes between the two may be different.
Carriers are involved in the provisioning process in Carrier ENUM while end
users typically are involved in the provisioning process in End User EUNM
due to end user opt-in requirement (I heard that in some countries they plan
to have the carriers provisioning End User ENUM; don't know if that should
be called Carrier ENUM or End User ENUM in that case).

We see interests in Carrier ENUM within the wireless community and within
the VoIP community (including cable).  IETF discusses technical issues.
Carrier ENUM does not use any new technology.   The carriers or the
associations/organizations the carriers participate are the ones to address
Carrier ENUM issues.    The carrier community should jointly agree on one
common tree to be used by Carrier ENUM. 

James

-----Original Message-----
From: James Seng [mailto:jseng at pobox.org.sg]
Sent: Monday, June 14, 2004 1:35 AM
To: Yu, James
Cc: 'richard.stastny at oefeg.at'; 'sdlind at att.com'; 'richard at shockey.us';
'enum at ietf.org'; 'mah at eunet.at'; 'paf at cisco.com'
Subject: Re: [Enum] User ENUM vs Operator ENUM

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:

> 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: Tue, 15 Jun 2004 10:07:02 -0400

> subject is certainly not one we need to discuss here.

why not? ops have always been discussed in ietf.

> the call/message/transaction processing may continue.  

of cos. but *that is* outside the scope of ENUM  if we crawl higher and look 
at other interoperability issues.

james