Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

["Stastny Richard" <[e-mail]>]

Tim,
 
thanx for your reply, you are raising some important issues. 
Since it is already midnight here, I will reply to it in detail tomorrow
 
I am also working on a more detailed analysis and a draft which
will require even some more time.
 
Just a quick one:
 
>In some parts of the world the function provided by "option 2" usage of
>Infrastructure ENUM could be achieved in other ways (e.g., the LERG and NPDB
>in North America) so in those cases Infrastructure ENUM might be a
>superfluous concept;  but if that's the right technical answer so be it.
 
Yes and no ;-)
You are mixing up here the Registry and the ENUM DNS.
The Registry is the LERG and NPDB (or is derived from), the
ENUM DNS is the equivalent on IP of the SCP in the PSTN
where the date is downloaded to.
 
Richard
 

________________________________

Von: Tim Dwight [mailto:[e-mail]]
Gesendet: Mi 24.05.2006 23:00
An: Stastny Richard; [e-mail]; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [e-mail]
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF



Richard,

Thank you for the clarification.  I understand the distinction you are
making.

My objective is to be able to translate a destination identifier (E.164
number of alphanumeric AoR) into the address of a Layer 5 entity designated
by the organization providing service to the called party.  With
infrastructure/carrier ENUM I could do this (as described in your Option 1),
but because ENUM is specific to E.164 numbers it would only work for E.164
-formatted destination identifiers.

In pictures, your Option 2 seems to me to imply the following:

               +----------------+                 +----------+
E.164          | infrastructure |     serving     | identify |     network
ingress
destination -->| ENUM           |---> carrier --->| ingress  |---> point
specified
identifier     | (option 2)     |     identity    | point    |     by
serving carrier
               +----------------+        ^        +----------+
                                         |
               +----------------+        |
non-E.164      | map domain in  |        |
Destination -->| URI to carrier |--------+
Identifier     | identity       |
               +----------------+

In some parts of the world the function provided by "option 2" usage of
Infrastructure ENUM could be achieved in other ways (e.g., the LERG and NPDB
in North America) so in those cases Infrastructure ENUM might be a
superfluous concept;  but if that's the right technical answer so be it.

The "identify ingress point" function would need to be defined.  I would
like it to consider the specified destination (in addition to the carrier
providing service to that destination); and I would like the procedures to
be such that the serving carrier controls (in a reasonably dynamic way) the
point at which traffic destined to a particular destination, enters his
network.  If those requirements can be met, I think this approach is
workable.

Its biggest drawback is that it precludes a solution ("option 1" usage of
Infrastructure ENUM) that is sufficient for the majority of today's needs.
It optimizes for a problem that will exist in the future at the expense of
solving problems that exist today.  I realize that solving today's problems
may not be SPEERMINT's focus, or (arguably) even within its charter, but I
would hate to see recommendations from SPEERMINT preclude or significantly
delay solving them.

Suppose we did something like this:

               +----------+     [pseudo     +----------------+
non-E.164      | identify |     or real]    | infrastructure |     network
ingress
destination -->| "pseudo" |---> E.164   --->| ENUM           |---> point
specified
identifier     | E.164    |     number      | (option 1)     |     by
serving carrier
               +----------+                 +----------------+

We could let the ENUM working group define Infrastructure ENUM as described
in your Option 1 (which is as you know already commercially available from a
few sources) and SPEERMINT could define the "identify pseudo E.164" function
that in my diagram feeds into it.  This function might be as simple as
mapping the domain part of the URI to an E.164 number uniquely associated
with the network providing service to the specified destination.  Unless
this is a lot harder than it seems, this shouldn't keep us busy too long :-)


Tim


-----Original Message-----
From: Stastny Richard [mailto:[e-mail]]
Sent: Wednesday, May 24, 2006 11:16 AM
To: [e-mail]; Michael Hammer (mhammer); Brian Rosen;
Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; [e-mail]
Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

Tim,

>> ... the basic idea of Infrastructure ENUM (which will be used for
>> service providers is to provide a domain name in a SIP URI = a
>> service provider ID
>(SPID)

>At the risk of asking an off-topic question (realizing that ENUM is not
>within scope for SPEERMINT), can I ask where the idea that
>Infrastructure ENUM queries return SPIDs, comes from?  It is my intent
>to provide a point of interconnection to be used by the requesting
>entity to hand to me a call to the specified number.  I do not intend
>that the only meaningful part of the URI returned from the ENUM query, be
the domain name.

thank you for raising this important point. I tried to raise this some time
ago, but got no clear answer

Currently there exist two lines of thought about the usage of Infrastructure
(and also Carrier ENUM in private trees)

1. Put in ENUM the ingress point(s) e.g. sip:[e-mail] 2.
Put in ENUM the AoR only: e.g. sip:[e-mail] (provider.net is what
I meant with SPID)

Most currently prefer option 1, especially in private ENUM trees.

IMHO this is the wrong approach:

There should be a clear separation (and it is in the charter) between ENUM
and SPEERMINT SPEERMINT peering MUST be able to work standalone and without
ENUM.

Option 1 assumes also that the user is entering ALWAYS an E.164 number as
identifier.

But what if he is entering an AoR?

SPEEMINT peering MUST be able to resolve this too so you need to find the
ingress point independant of ENUM e.g. via RFC3263.

If this MUST be possible, why not enter in (any) ENUM just the AoR, if you
must be able to resolve the AoR anyway?

Otherwise you need to manage two mappings separate 1. the E.164 to ingress
point 2. the AoR mapping to ingress point

this is not a good idea

This is the reason why I would prefer to enter in ENUM AoRs only the user
part in ENUM is always the E.164 number (for privacy reasons) the domain
part is the SPID, which is mapped later to find the ingress point

the calling user may then also use an alis AoR such as sip:[e-mail]

regards

Richard



________________________________

Von: Tim Dwight [mailto:[e-mail]]
Gesendet: Mi 24.05.2006 16:46
An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D.
Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [e-mail]
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF



Stastny, Richard said:

> ... the basic idea of Infrastructure ENUM (which will be used for
> service providers is to provide a domain name in a SIP URI = a service
> provider ID
(SPID)

At the risk of asking an off-topic question (realizing that ENUM is not
within scope for SPEERMINT), can I ask where the idea that Infrastructure
ENUM queries return SPIDs, comes from?  It is my intent to provide a point
of interconnection to be used by the requesting entity to hand to me a call
to the specified number.  I do not intend that the only meaningful part of
the URI returned from the ENUM query, be the domain name.

tim




_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint




_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint