Subject: RE: [Enum] Agenda items for IETF Paris

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 07 Jul 2005 18:12:15 -0400

Richard,

So in User ENUM you provide an end-user URI and get an E.164 number back?  I don't think so.

First, don't both types of ENUM start with an E.164 and return a URI?

Second, in which RFC does it say that the URI returned MUST be an end-user URI?
(I'll confess I haven't read them all.)

Third, in both cases, isn't the intent to be able to route a call (initiate communication) toward the owner of the E.164 number?  The concept of peering partners is beside the point.  I find the idea of disconnected islands of closed clubs to be counter-productive.  A key requirement MUST be that a dialed E.164 number enables a call to go through.  If ENUM becomes the stumbling block preventing call completion, that will invite unnecessary regulation.

Fourth, isn't one of the principles of the Internet to provide generally useful mechanisms?  Bifurcating this into User versus Carrier "orthogonal and independent" implementations is a recipe for non-interoperability and "Walled ENUM".

I hope I have totally misunderstood your words below.

Mike

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Stastny Richard
> Sent: Thursday, July 07, 2005 5:44 PM
> To: Patrik Faltstrom (pfaltstr); Livingood, Jason
> Cc: enum at ietf.org; Richard Shockey
> Subject: Re: [Enum] Agenda items for IETF Paris
> 
> Hi all,
>  
> >For example, I know Stasny have said several times "this is 
> not ENUM" 
> >and personally, I do agree with him. But, to be able to have that 
> >discussion, we first need the meta-discussion...
>  
> I agree that there seems to be a discussion necessary
>  
> to clarify this, as I tried to state in the definitions I posted:
>  
> The purpose of User ENUM is for mapping end-user URIs to 
> E.164 numbers.
> basically a service for end-users. The basic requirement for 
> end-users is to find other end.users. The second requirement 
> is that orig end-user must be able to reach the destination 
> user, because the Internet is end-to-end. User ENUM is 
> conformant to the Internet principles
>  
> The purpose of Carrier ENUM is to help carriers finding 
> peering partners using E.164 numbers to map to URIs, 
> basically find the destination networks from an origination 
> network. The basic requirement for carriers is to find other 
> carriers. Here it is NOT required that every carrier must be 
> able to reach any other carrier, this is depandant on peering 
> agreements.
>  
> These two implementations are orthogonal and independant.
>  
> If there is an efficient way to use the same nfrastructure 
> for these differnt purposes, fine.
>  
> IMHO the VoIP peering requirements necessary to do so are out 
> of scope of ENUM WG. I leave it to the discussion if they are 
> within the scope of the IETF.
> On the other hand, many IETF protocols are used on IP-based 
> networks separated from the Internet (e.g. SIP within 3GPP).
>  
>  
> -richard
> 
> ________________________________
> 
> Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström
> Gesendet: Do 07.07.2005 22:53
> An: Livingood, Jason
> Cc: enum at ietf.org; Richard Shockey
> Betreff: Re: [Enum] Agenda items for IETF Paris
> 
> 
> 
> What I hope we can do is to first discuss what requirements 
> we have on "user" and "carrier" ENUM, what is in-scope and 
> out of scope. This discussion will give a list of 
> requirements that I hope we can use to measure the proposals against.
> 
> For example, I know Stasny have said several times "this is not ENUM" 
> and personally, I do agree with him. But, to be able to have 
> that discussion, we first need the meta-discussion... So we 
> know what we agree on and not.
> 
>     paf
> 
> On Jul 7, 2005, at 20:41, Livingood, Jason wrote:
> 
> >
> >
> >> 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ?
> >>
> >
> > (Agenda addition)
> >
> > There is a new, alternate Carrier ENUM proposal making its 
> way to the 
> > WG, draft-haberler-carrier-enum-00.  Perhaps this I-D can 
> be discussed 
> > immediately after the Pfautz et al. draft?  Discussion of 
> both drafts 
> > could follow, which I expect to be lively.
> >
> > Regards
> > Jason Livingood
> >
> > _______________________________________________
> > enum mailing list
> > enum at ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum
> >
> 
> 
> 
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 

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

---

From: Richard Shockey <[email-masked]>
Date: Thu, 07 Jul 2005 21:08:32 -0400

At 06:11 PM 7/7/2005, Michael Hammer \(mhammer\) wrote:
Richard,
So in User ENUM you provide an end-user URI and get an E.164 number 
back?  I don't think so.

First, don't both types of ENUM start with an E.164 and return a URI?
yes ..but end user ENUM as it has been interpreted by most regulatory 
authorities is OPT-IN which requires the proactive consent of the end point 
user to register a FQDN in e164.arpa and that in most cases the URI is a 
SIP AOR

Carrier enum presumes that the URI returned is NOT a AOR but a  border 
element in a service providers network that provides admission control and 
interconnection between service providers. Carrier ENUM presumes that 
registrations are for all TN under the service providers control and 
therefore there is no need to OPT IN since the endpoints are never actually 
exposed.

Second, in which RFC does it say that the URI returned MUST be an end-user 
URI?
none of them.
(I'll confess I haven't read them all.)
Third, in both cases, isn't the intent to be able to route a call 
(initiate communication) toward the owner of the E.164 number?
not necessiarily .. initiate communication towards the owner may not be the 
end point but a point of interconnection.

The concept of peering partners is beside the point.  I find the idea of 
disconnected islands of closed clubs to be counter-productive.
tell that to the wireless industry.
 A key requirement MUST be that a dialed E.164 number enables a call to 
go through.
not necessarily ..in carrier enum that means you find the point of 
interconnection and it is the up to that point of egress to apply policy as 
to whether to permit admission or not.

 If ENUM becomes the stumbling block preventing call completion, that 
will invite unnecessary regulation.

Fourth, isn't one of the principles of the Internet to provide generally 
useful mechanisms?  Bifurcating this into User versus Carrier "orthogonal 
and independent" implementations is a recipe for non-interoperability and 
"Walled ENUM".
Most of us dont agree since one of the objectives of Carrier ENUM is to 
assist service providers in their well known and highly publicized 
statement of directions for collapsing their internal networks on to IP. 
Carriers cannot collapse their networks on to IP unless they can also 
collapse the underlying signalling networks that enable carrier 
interconnection.

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Haberler <[email-masked]>
Date: Thu, 07 Jul 2005 21:14:18 -0400

Michael,
At 00:11 08.07.2005, Michael Hammer \(mhammer\) wrote:
..
Second, in which RFC does it say that the URI returned MUST be an end-user 
URI?
(I'll confess I haven't read them all.)
Let's call a "non end-user URI" a Point of Interconnect" (POI), which is an 
attribute of the carrier-of-record of a number.

An end user opting in to User ENUM does not care about and cannot influence 
his carrier's POI, but his own URI(s).

A carrier does care about his POI(s), but cannot enter them into User ENUM 
because latter is opt-in by and the zone is owned by his user.

Having a carrier *and* his user cohabitate the same zone  is like you and 
me owning foo.com - we might run into problems about which records go into 
in the foo.com zone. You change my RR's, I might get nasty.

Third, in both cases, isn't the intent to be able to route a call 
(initiate communication) toward the owner of the E.164 number?
yes, and User ENUM is great for that. It just happens to cover a 
homoeopathic number of call setups now and for a long time to come, the 
rest of the call setups work  by virtue of - in some way - shared POI 
information. Both do work, but this isnt a question wether you can call me 
or not.

The concept of peering partners is beside the point.
I dont think so, that's just a posh name for "interconnect agreement" and 
the concept is bound to be with us for a while, like 10 years or more. I 
havent made any, but they are there.

 I find the idea of disconnected islands of closed clubs to be 
counter-productive.  A key requirement MUST be that a dialed E.164 number 
enables a call to go through.  If ENUM becomes the stumbling block 
preventing call completion, that will invite unnecessary regulation.

Fourth, isn't one of the principles of the Internet to provide generally 
useful mechanisms?  Bifurcating this into User versus Carrier "orthogonal 
and independent" implementations is a recipe for non-interoperability and 
"Walled ENUM".
Let's assume we insist on User ENUM being the method of choice for call 
setup in IP land, and other call setup scenarios are undesirable/should go 
elsewhere, whatever the supporting mechanisms are.

The consequence of assuming that a dialed number goes through User ENUM 
exclusively is part of the cause for the very bifurcation you are 
deploring. This is happing right now, into e164.something trees or private 
trees altogether, or staying on the PSTN by default.

Now, do I care? Can I call you and you can call me ?  yes, so that fulfills 
your requirement.

Does it make sense? I believe, not really  - because the cannibalization 
into different trees kills cross-tree resolution. Resolution rates are 
already ridiculous due to the pathetic per-country code opt-in to process.

Will it help the User ENUM vision (which I share)? no, actually it will 
kill it - and the reason is that it might not be viable to run a 
User-ENUM-only service on a per-country basis, and get still get a critical 
mass of users. We might end up with something like "No, we dont do HTTP 
over here in France." - this isnt my idea of a horizontal technology.

I might be questioning belief systems here:
a) the basic value proposition of ENUM-like technology is in call 
resolution rates - more calls on IP equals better.
b) call resolution is a market - laws of demand and suppy apply. Offer 
doesnt meet demand - demand goes elsewhere.
c) User ENUM is dead in the water if cost of running it and end user value 
dont add up eventually. End user value is in resolution rates, too.
d) finding a scheme which fulfills carrier needs and at the same time 
supports User ENUM, like a combined tree proposal, will keep options for 
User ENUM open longer - so it can achieve reasonable resolution rates 
eventually to keep it viable.
d) one is more likely to find somebody in jurisdiction X to run a combined 
tree than just User ENUM, and governments will see more demand as local IP 
interconnect is an issue - and that helps footprint of both.

see http://www.enum.at/ietf/draft-haberler-carrier-enum-00.txt and 
http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html for Richard's 
and my I-D based on this view - the I-D is still making it through the queue

- Michael