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

From: "Stastny Richard" <[email-masked]>
Date: Tue, 23 May 2006 23:08:51 +0200

Folks,
 
One general statement in advance:
Coming from the VON Europe last week with discussions
about walled garden and IMS,
my overall expression is that this draft in IMS in text-mode.
 
I have another question for clarification to this draft,
because I am confused:
 
I do not understand that the LF is discovering the OF

   o  Location Function (LF):  Purpose is to enable discovery of the OF 
      peering point. 

   o  Operation Function (OF):  Purpose is to enable discovery and 
      exchange of policy and parameters to be used in with the SF 
      peering point. 

   o  Signaling Function (SF):  Purpose is to enable the discovery of 
      endpoints and assist in discovery and exchange of parameters to be 
      used with the MF peering point. 

I always had the naive idea (also triggered by the SPEERMINT chartert 
that e.g. ENUM is a LF and discovering the SIP URIs uses in the SF

How is now OF coming in between thsi, especially what is listed
in the draft, especially CALEA, Accounting and Applications?

"Operational data mediation:  TBD 

   o  CALEA implementation:  TBD 

   o  Accounting:  Call Detail Record's (CDR's) MAY be collected to be 
      utilized by the peering operators.  Based on the application, the 
      format should be an open standard for common consumption of 
      billing systems.  Operators may use this data for a number of 
      reasons, including billing in the event the peering relationship 
      becomes asymmetric (unbalanced traffic flow) or there is a Tier 1 
      to Tier 2 relationship.  In order to limit the potential for 
      billing systems to impact the OF, a separate server should be 
      created to maintain all records collected from a single 
      interconnection to any number of OF's. 
    An OF can also be a special function that contains bi-laterally 
   disclosed information about the application servers and databases of 
   each IP service provider. An example of this function is to allow a 
   session to select a better suited application server from a set of 
   application servers located inside both service providers' network.  "
 
Richard

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 23 May 2006 20:26:42 -0400

Richard,

Let me turn this around to you.

How much policy data do you stuff into ENUM?

How general a database do you expect DNS to become?

Do you expect that all peers will be pointed to the same entry point
into the network?

The thought was that before you blast the SF with INVITEs, it might be
useful to learn something about the nature of the interface
expectations.  For the most part these are bins into which things can be
organized while this group gets started.  If later it is concluded a bin
isn't needed, then it can be removed and whatever was collected handled
by some other bin.

Mike

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Tuesday, May 23, 2006 5:09 PM
> To: Michael Hammer (mhammer); Brian Rosen; Francois D. 
> Menard; Khan, Sohel Q [CTO]; David Meyer; [email-masked]
> Subject: SPEERMINT Peering Architecture - LF - OF - SF
> 
> Folks,
>  
> Coming from the VON Europe last week with discussions about 
> walled garden and IMS, my overall expression is that this 
> draft in IMS in text-mode.
>  
> I always had the naive idea (also triggered by the SPEERMINT 
> chartert that e.g. ENUM is a LF and discovering the SIP URIs 
> uses in the SF
> 
> How is now OF coming in between thsi, especially what is 
> listed in the draft, especially CALEA, Accounting and Applications?
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 24 May 2006 10:37:23 +0200

Michael,
> Let me turn this around to you.

Good policy, answering a questing with another question ;-)
> How much policy data do you stuff into ENUM?

None, 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)

> How general a database do you expect DNS to become?

Good question. The DNS is reliable, scalable and fast
and it is available. So IMHO if some information
is needed in some kind of database, DNS is the first
choice (public and/or private DNS)

> Do you expect that all peers will be pointed to the same entry point

I assume with network you mean the destination "network"?
The answer is no,
 
> expectations.  

Agreed,

I would suggest to rename OF to PF (Policy detection Function)
IMHO the short description is ok
Operation Function (OF):  Purpose is to enable discovery and
> >       exchange of policy and parameters to be used in with the SF

the long description mentioning CALEA and Accounting
is a bit misleading an needs rewording. Especially
the negotiation of application servers is a bit
early at this time.

>For the most part these are bins into which things can be

Ok

Richard

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 24 May 2006 11:01:35 -0400

Hey, it worked for Socrates. :)

While not adverse to calling it a PF versus OF, I am not certain that
policy is all that is there, or whether to sort the other stuff out into
other bins.  I was hoping to do some grouping over the list provided by
Bob Natale in:  draft-natale-sip-voip-requirements-00.txt but haven't
gotten to that yet.

Mike

> Sent: Wednesday, May 24, 2006 4:37 AM
> Subject: RE: SPEERMINT Peering Architecture - LF - OF - SF
> 
> Michael,
> > 
> None, 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)
> 
> > 
> Good question. The DNS is reliable, scalable and fast and it 
> is available. So IMHO if some information is needed in some 
> kind of database, DNS is the first choice (public and/or private DNS)
> 
> > 
> I would suggest to rename OF to PF (Policy detection 
> Function) IMHO the short description is ok Operation Function 
> (OF):  Purpose is to enable discovery and
> the long description mentioning CALEA and Accounting is a bit 
> misleading an needs rewording. Especially the negotiation of 
> application servers is a bit early at this time.
> 
> 
> >For the most part these are bins into which things can be  organized 
> >while this group gets started.  If later it is concluded a
> bin
> about walled 
> > > garden and IMS, my overall expression is that this draft 
> in IMS in 
> > > text-mode.
> > >
> because I 
> > > am confused:
> > >    o  Location Function (LF):  Purpose is to enable 
> discovery of the 
> > > OF
> > >       peering point.
> > >
> > >       endpoints and assist in discovery and exchange of 
> parameters 
> > > to be
> > > chartert that e.g. ENUM is a LF and discovering the SIP 
> URIs uses in 
> > > the SF
> > >
> listed in 
> > > the draft, especially CALEA, Accounting and Applications?
> > >
> > >    o  Accounting:  Call Detail Record's (CDR's) MAY be 
> collected to 
> > > be
> > >       utilized by the peering operators.  Based on the 
> application, 
> > > the
> > >    disclosed information about the application servers 
> and databases 
> > > of
> > >    each IP service provider. An example of this function 
> is to allow 
> > > a

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 24 May 2006 18:16:20 +0200

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:[email-masked]
2. Put in ENUM the AoR only: e.g. sip:[email-masked]
(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:[email-masked]

regards

Richard

________________________________

Von: Tim Dwight [mailto:[email-masked]]
Gesendet: Mi 24.05.2006 16:46
An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [email-masked]
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

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 24 May 2006 23:38:14 +0200

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:[email-masked]]
Gesendet: Mi 24.05.2006 23:00
An: Stastny Richard; [email-masked]; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [email-masked]
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:[email-masked]]
Sent: Wednesday, May 24, 2006 11:16 AM
To: [email-masked]; Michael Hammer (mhammer); Brian Rosen;
Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; [email-masked]
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)

>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.

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

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.

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

regards

Richard

Von: Tim Dwight [mailto:[email-masked]]
Gesendet: Mi 24.05.2006 16:46
An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D.
Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [email-masked]
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)

tim

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 May 2006 00:44:26 +0200

Tim,
 
another short reply:

b) you can provide a LRN, with the pstn Enumservice
and if you can explain to me how a plain sip-proxy accesses 
e.g the OpenSER accesses the LERG and the LNP database
especially from e.g. Austria, fine

With Infrastructure ENUM this is a no-brainer
 
Richard

Von: Tim Dwight [mailto:[email-masked]]
Gesendet: Do 25.05.2006 00:19
An: Stastny Richard; [email-masked]; [email-masked]; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [email-masked]
Betreff: 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:[email-masked]]
Sent: Wednesday, May 24, 2006 4:38 PM
To: [email-masked]; [email-masked]; Michael Hammer
(mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David
Meyer; [email-masked]
Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

Tim,

I am also working on a more detailed analysis and a draft which will require
even some more time.

Just a quick one:

>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

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:[email-masked]]
Gesendet: Mi 24.05.2006 23:00
An: Stastny Richard; [email-masked]; 'Michael Hammer (mhammer)';
'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';
[email-masked]
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

Richard,

Tim

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Wednesday, May 24, 2006 11:16 AM
To: [email-masked]; Michael Hammer (mhammer); Brian Rosen;

Tim,

the domain name.

this is not a good idea

regards

Richard

(SPID)

tim

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 25 May 2006 10:25:31 -0400

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

> From: Tim Dwight [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 6:19 PM
> To: 'Stastny Richard'; [email-masked]; 
> [email-masked]; Michael Hammer (mhammer); 'Brian 
> Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David 
> Meyer'; [email-masked]
> 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
> 
> 
> To: [email-masked]; [email-masked]; 
> Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; 
> Khan, Sohel Q [CTO]; David Meyer; [email-masked]
> I am also working on a more detailed analysis and a draft 
> which will require even some more time.
>  
> Just a quick one:
>  
> ENUM DNS is the equivalent on IP of the SCP in the PSTN where 
> the date is downloaded to.
>  
> Richard
>  
> 
> An: Stastny Richard; [email-masked]; 'Michael 
> Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 
> 'Khan, Sohel Q [CTO]'; 'David Meyer'; [email-masked]
> 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 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.
> 
> 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
> 
> 
> To: [email-masked]; Michael Hammer (mhammer); 
> Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David 
> >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)
> 
> Put in ENUM the AoR only: e.g. sip:[email-masked] 
> 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.
> 
> 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
> 
> 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
> 
> 
> 
>