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

["Michael Hammer \(mhammer\)" <[e-mail]>]

Tim,

The LERG and LNP databases are intrinsically tied to the operation of
the TDM infrastructure.  Any design that perpatuates these systems when
their reason for being (TDM) goes away is a faulty design.

DNS and ENUM provides the equivalent information and mechanisms to do
what is needed in the IP domain.  As such, a design that makes
dependencies on legacy systems is deficient.  I wouldn't support such a
kludge.

That said, if there are backward compatibilities during the transition,
where some information just happens to be known by external systems,
such as you suggest below, I don't see that as a problem.  I am just
wary of ending up with two systems in the end when one would do.

Mike


> -----Original Message-----
> From: Tim Dwight [mailto:[e-mail]] 
> Sent: Wednesday, May 24, 2006 6:19 PM
> To: 'Stastny Richard'; [e-mail]; 
> [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
> 
> Richard,
> 
> Yes I know I was mixing data and mechanism-to-access-data.  
> Still I believe the major point to be correct.  In many parts 
> of the world there are already mechanisms (associated with 
> Local Number Portability) to determine ownership of an E.164 
> number, hence use of ENUM for this purpose alone, will be 
> unnecessary.  
> 
> To be clear, I believe that providing access via 
> Infrastructure ENUM to LNP information may be very helpful;  
> but only if Infrastructure ENUM provides more than just this. 
>  If an Infrastructure ENUM query can combine (a) 
> determination of the entity providing service to the 
> destination, (b) determination of the corresponding LRN, if 
> one exists, and (c) mapping of the routable number (either 
> the number originally indicated, or the LRN) to a Layer 5 
> "point of ingress" specified by the entity providing service 
> to the destination;  then Infrastructure ENUM is quite a 
> handy mechanism.  If all it does is (a) then I don't need it.
> 
> But in the end this is neither here nor there.  I am not 
> wedded to any specific technology, I just need workable 
> solutions to real business problems.
> 
> Tim
> 
> 
> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2006 4:38 PM
> To: [e-mail]; [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,
>  
> 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
> 

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