Subject: [Enum] Horizontal vs Vertical

From: "Stastny Richard" <[email-masked]>
Date: Fri, 08 Jul 2005 17:22:25 -0400

>I know you (and myself) reject some of the proposals and thinking 
>that have been passed around on this list. To be able to *REALLY* 
>reject those, I want to know the requirements that are behind the 
>proposals.

>I.e. enough so that the requirements can be attacked instead of the 
>solutions that claim to respond to all of them.

Yes and no, I think the current discussion on which Carrier ENUM
proposal is valid or not is only a side battle.

The real battle currently going on is between the "Internet" model
(the horizontal layered model) and the vertical stovepipes of
the PSTN model. 

The Internet model is the end-to-end model originally intended
by SIP according to e-mail. If you have a sip URI you
may use this URI to contact at least the proxy hosting the AoR.
The media-stream is then transferred end-to-end directly between
the end-points.

In the PSTN model only "networks" may exchange both signalling
and medai streams. To do so, they need peering agreements, pretending
to guarantee QoS, in reality to be able to charge per minute.

This model is mainly supported by mobile and cable operators to
keep up the current accounting regime, supported also by the
fixed network operators eaten up by the former, and also by
some VoIP getting greedy and also wanting to get their share.

As Henry already stated the problem is surfacing by the
question: "Do you get a public SIP URI for your VoIP service"
If not, you may use IP-based Telephony, but you are behind 
a walled garden.

Back to ENUM:

One is only able to use User ENUM if he has a Public
SIP URI, and he may then link this SIP URI with an
E.164 number in e164.arpa

If he doesn't, the only "Public" identifier he has is an E.164 number.
If his provider decides to use SIP within his walled garden network,
he need some kind of addressing. Since this is SIP, a SIP URI
is useful, but the "domain" names used here cannot be resolved
on the public Internet. So the provider needs some private DNS
to resolve even his own users. If one of this users wants to contact
users of other providers, he may either use SIP URI, but this is
problematic because his provider may not be able to resolve
this URIs. So they stick to E.164 numbers. Here you still
have as default the PSTN to interconnect.

But providers of course also want to interconnect via IP, so
the Carreir may now use ENUM technology to map the
E.164 numbers to - ok this is now the question:

The answer to this question is depending on what kind
of ENUM he is useing:

In the worst case he may use private ENUM in his own
network to find the egress SBC into an "extranet" shared between
providers, the egress SBC connect to the proper extranet
and is querying an "ENUM" in this extranet to find the ingress SBC
of the provider hosting the number and this ingress SBC is finally
querying the ENUM in the destination network to find the proxy
hosting the subscriber.

But there are other models.

So to answer your questions for the requirements we need
first to discuss all potential peering models and ENUM configurations.

We did this at ETSI for two years and included the only major models
in ETSI TS 102 055.

The whole issue will finally not be decided by a standards body.
it will be decided by the end-user, because he
will finally have the choice to use both models in parallel at his
mobile device. He may chose either to query User ENUM ar let
the call be set-up by his IMS provider.

-richard

PS: you may compete with everybody, but not with your customer
(Clay Shirky on fax-mail)

.

________________________________

Von: Patrik Fältström [mailto:paf at cisco.com]
Gesendet: Fr 08.07.2005 21:44
An: Stastny Richard
Cc: Richard Shockey; enum at ietf.org
Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris)

On Jul 8, 2005, at 19:25, Stastny Richard wrote:

> Rich Shockey wrote:
>
>> as some here might postulate the exposure of the URI of the ALG 
>> may or may
>> not be visible to A. all parties as in the use 
>> of .carrier.e164.arpa B.
>> just visible to the club as in 3GPP.NET or e164MSO.ORG and the 
>> visibility
>> of the ALG URI does not necessarily imply a formal peering agreement
>> between party A and party B.
>>
>
> I question for clarification, especially to Patrik:
>
> Are we talking here about requirements for carrier ENUM
> -in private enterprise trees?
> -in carrier trees within their network to find egress ALGs (or SBCs 
> or GWs)?
> -in shared walled garden trees such as GSMA 
> (whatchamanameitcurrently) to find ingress ALGs?
> -in (partially or wholely) public other trees such as e174.info?
> -or in carrier.c.c.164.arpa or c.c.carrier.e164.arpa?
>
> or altogether?
>
> If it is last, I will come back in two years and look how far you are
> with the requirements and I do not think I will have missed a lot

I want at least SOME requirements. At least enough to be able to see 
the difference between the various proposals.

I know you (and myself) reject some of the proposals and thinking 
that have been passed around on this list. To be able to *REALLY* 
reject those, I want to know the requirements that are behind the 
proposals.

I.e. enough so that the requirements can be attacked instead of the 
solutions that claim to respond to all of them.

But not more.

     paf

>
> -richard
>
>
>
>
>
> ________________________________
>
> Von: enum-bounces at ietf.org im Auftrag von Richard Shockey
> Gesendet: Fr 08.07.2005 19:06
> An: Patrik Fältström; Richard Shockey
> Cc: enum at ietf.org
> Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items 
> forIETF Paris)
>
>
>
> At 12:48 PM 7/8/2005, Patrik Fältström wrote:
>
>
>
>> On Jul 8, 2005, at 16:44, Richard Shockey wrote:
>>
>>
>>> ...there is a requirement among service providers for some form of
>>> database technology that, based on a E164 number, can provide
>>> information on how to route a service to a point of carrier
>>> interconnection or ALG as expressed as a URI.
>>>
>>
>> Ok, this is for me one requirement. Sorry for maybe not being clear.
>>
>>
>>> For privacy reasons this information needs to be restricted to
>>> service providers and not generally available to end users.
>>>
>>
>> Is the requirement that this information (the mapping from E.164 to
>> URI) is only to be visible for the party that need to know, or "any
>> service provider being part of the same club"?
>>
>
> oh fine distinction can you elaborate a bit ?...what is the 
> difference been
> 'party that needs to know' or 'service provider being part of the same
> club' .. what is the distinction?
>
> as some here might postulate the exposure of the URI of the ALG may 
> or may
> not be visible to A. all parties as in the use 
> of .carrier.e164.arpa B.
> just visible to the club as in 3GPP.NET or e164MSO.ORG and the 
> visibility
> of the ALG URI does not necessarily imply a formal peering agreement
> between party A and party B.
>
> What the egress ALG does once it gets in INVITE is a matter between
> consenting capitalists.
>
> Does that help?
>
>
>
>>    paf
>>
>>
>>
>>
>
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 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
>
>

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

---

From: "Peter Williams" <[email-masked]>
Date: Sat, 09 Jul 2005 02:03:43 -0400

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
> Stastny Richard
> Sent: Friday, July 08, 2005 2:26 PM
> To: Patrik Fältström
> Cc: enum at ietf.org; Richard Shockey
> Subject: [Enum] Horizontal vs Vertical
> 

Ill stay out of the religious discussion, 'case I get chastised again for
pointing out how we attempted to avoid the same old issue set whilst
thinking like Internet people, last time round!

On the point introduced, there is much more to the *needs* behind a whole
class of Carrier ENUM requirements than the billing and resource sharing
issues.

The providers are also providing a *regulated* security service, addressing
user data privacy expectations (a type of QOS), and realtime interception
capability - as authorized on a per-called/calling party basis. To satisfy
these licensing obligations, peer providers must very cooperate closely in
practice, often in the form of joining groups of providers who sharing a
common key management provider.

I cant remember whether it was at a public or private event, that someone at
at Company X explained how the company runs rooms and rooms of outsourced
CMIP responders for the various telcos, managing crypto keys that are used
and shared pursuant to thousands of peering agreements, and addressing the
security rules laid down by governments for each specific interconnect
arrangement.

In reality, an ENUM-enhanced DNS supporting name management, listing
services, and discovery service has to be matched with a framework for
interconnect arrangements that address the backroom handling of crypto keys,
which must be configured on a provider-provider level, and possibly  per
switch path/route. Very very very fast key translation crypto hardware
augments today's company Y's switches - making all this work totally
invisible to users, while satisfying realtime data access rules set by
licensing authorities at switching points. While such hardware deployment is
just a fixed capital outlay, the pain is in managing the translation tables:
for this, the entire existing system of key update and sharing, which is
linked to name registration/portability/listing/routing (in a CMIP database,
as it happens, today), will have to be also be addressed in future Carrier
ENUM standards.

------

Hopefully, I identified clearly a need - and thus a class of requirement -
that would allow one to distinguish Carrier ENUM convergence models -
without saying anything at all about how it should be accomplished in an
ENUM-based infrastructure.

..

> the call be set-up by his IMS provider.

Increasingly, the mobile device phone will using chips that impose the
providers security obligations on an end-end basis, even in the User Enum
model. Your ability to complete the call will depend not only on transaprt
and a lookup, but on whether the chip authorized the connection - much as
the provider-side enforcement system works today.

Sorry to keep throwing security and keys into stuff folks prefer to discuss:
numbers, administrative portability, routes, management domains and
different types of managed access points. But, this security issue imposed
by the regulators is what is must drive us towards Carrier ENUM, and it will
eventually spill over into public ENUM. There is just no choice here, folks.