Subject: [e2md] Request for input on market need evidence for E2MD

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 8 Feb 2010 21:46:53 +0100 (CET)

Hi,

Again, welcome to the E2MD mailing list! Looking at the subscriber's list 
I am positively surprised how many people are interested in this topic.

Now the hard work starts...

I have requested a BoF for IETF-77 in Anaheim.

   http://trac.tools.ietf.org/bof/trac/wiki#RAI

If we want this BoF to be successful, some questions need to be 
addressed before Anaheim. The most important one is:

   We need clear evidence on this mailing list that there is
   a real market need for E2MD (E.164 To MetaData). (!)

So, please send your needs, use cases, requirements, implementation 
intentions, experiences or whatever helps demonstrating the market need 
for E2MD to this mailing list now!

I am looking forward to your input!

cheers,
  Bernie

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 8 Feb 2010 19:13:28 -0500

Hi Bernie,

Thanks for coordinating activities related to E2M(D).  Some examples of data elements that some organizations are provisioning and/or querying for today include (some of which are for non-CC1 numbers):

Payment Type:  PrePaid | PostPaid
Network Type:  TDMA | GSM
Region Code:  A numeric value indicating a region within a country.
Service Provider Name:  The name of the current service provider.
SPID:  A string of characters identifying the current service provider.

Not yet sure if I will be able to attend IETF, but will at least participate on-line.
Ken

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bernie Hoeneisen [[email-masked]]
Sent: Monday, February 08, 2010 3:46 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] Request for input on market need evidence for E2MD

Hi,

cheers,
  Bernie

_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Jay Daley <[email-masked]>
Date: Tue, 9 Feb 2010 23:11:00 +1300

On 9/02/2010, at 9:46 AM, Bernie Hoeneisen wrote:

> So, please send your needs, use cases, requirements, implementation intentions, experiences or whatever helps demonstrating the market need for E2MD to this mailing list now!

e2md is an absolute requirement if we are ever to achieve global carrier enum in the public DNS.

The two main reasons that carriers will not do that now are:

1.  They don't want to publish details of the endpoints publicly and have any idiot attempt to connect to them, even if those endpoints are on private networks and unreachable from the Internet.

2.  They want to have bilateral interconnection agreements that are entirely private between the two parties with others not even knowing of their existence.

The only way to achieve those two goals is for global carrier enum to be implemented as an e2md tree not an e2u tree:

- each carrier publishes e2md data for the number blocks they are assigned with e2md records that point to virtual endpoints

- carriers then enter into bilateral agreements and exchange private infrastructure plans, which map virtual endpoints to real endpoints.  Each private infrastructure plan a carrier issues bilaterally can be unique if they wish.  They can even seed them to detect leakage.  

- if a carrier wishes to allow public interconnection then they can go so far as to publish a public infrastructure plan.

To be fair there is a third reason carriers don't want global carrier enum

3.  they don't wanting people knowing what numbers they have 

but that is being eroded in other ways.  Block allocation data is readily available in many countries and ported number data is one step further away.

Another way of putting it, which I'm still not sure about but will posit anyway, is that e2u is too direct to deliver on its promise *in public carrier trees* and needs a level of indirection, as provided by e2md, to overcome this.  Or better still e2u=private, e2md=public.

kind regards
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Feb 2010 09:55:45 -0500

Can I paraphrase this as:

The PUBLIC Carriers don't want the PUBLIC to have information about 
PUBLIC phone numbers, because that information is PRIVATE.

???

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Feb 2010 10:12:52 -0500

Or you could paraphrase it as:
The NATIONAL PUBLIC Carriers don't want their and their customers' PRIVATE information to be available to the GLOBAL PUBLIC, because that information is PRIVATE.

(e.g., the IP Address:port of the Carrier's Cable/DSL-Modem's VoIP interface for your phone number is really no business of the PUBLIC)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Tuesday, February 09, 2010 9:56 AM
> To: Jay Daley
> Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list
> Subject: Re: [e2md] Request for input on market need evidence for E2MD
> 
> > 1.  They don't want to publish details of the endpoints publicly and
> have any idiot attempt to connect to them, even if those endpoints are on
> private networks and unreachable from the Internet.
> >
> > 2.  They want to have bilateral interconnection agreements that are
> entirely private between the two parties with others not even knowing of
> their existence.
> >
> >
> > The only way to achieve those two goals is for global carrier enum to be
> implemented as an e2md tree not an e2u tree:
> >
> > - each carrier publishes e2md data for the number blocks they are
> assigned with e2md records that point to virtual endpoints
> >
> > - carriers then enter into bilateral agreements and exchange private
> infrastructure plans, which map virtual endpoints to real endpoints.  Each
> private infrastructure plan a carrier issues bilaterally can be unique if
> they wish.  They can even seed them to detect leakage.
> >
> > - if a carrier wishes to allow public interconnection then they can go
> so far as to publish a public infrastructure plan.
> >
> >
> > but that is being eroded in other ways.  Block allocation data is
> readily available in many countries and ported number data is one step
> further away.
> >
> >
> > Another way of putting it, which I'm still not sure about but will posit
> anyway, is that e2u is too direct to deliver on its promise *in public
> carrier trees* and needs a level of indirection, as provided by e2md, to
> overcome this.  Or better still e2u=private, e2md=public.
> >
> > kind regards
> > Jay
> >

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 9 Feb 2010 10:13:07 -0500

But Paul this has nothing to do with Public ENUM. It has everything to do
with Private instantiations of ENUM and the use of RFC 3761 to cache phone
number data locally in carrier networks. The IP Service Control Point so to
speak.

SIP redirect is not a good vehicle for PSTN metadata and that is the market
this proposal addresses.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Tuesday, February 09, 2010 9:56 AM
To: Jay Daley
Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Request for input on market need evidence for E2MD

???

>> So, please send your needs, use cases, requirements, implementation
intentions, experiences or whatever helps demonstrating the market need for
E2MD to this mailing list now!
> 1.  They don't want to publish details of the endpoints publicly and have
any idiot attempt to connect to them, even if those endpoints are on private
networks and unreachable from the Internet.
implemented as an e2md tree not an e2u tree:
> 
> - each carrier publishes e2md data for the number blocks they are assigned
with e2md records that point to virtual endpoints
> 
> - if a carrier wishes to allow public interconnection then they can go so
far as to publish a public infrastructure plan.
> but that is being eroded in other ways.  Block allocation data is readily
available in many countries and ported number data is one step further away.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 9 Feb 2010 12:06:38 -0500

Right.  E2MD should not be viewed as a solution designed to adress some concerns about public vs private of E2U data.  imo, both E2U and E2M(D) protocols can be / are being used in either "private" or "public" installations.  iow, I do not think that the use of E2M(D) is more or less likely to be used in "public" or "private" installations than E2U.  So I do not underestand how/why E2M(D) is thought to address concerns related to private data being visible to the public.  We need to be careful to *not* have E2M(D) do the things that E2U should be doing.  iow, if some improvements in the data access/visibility controls, or improvements to the way that AORs or SBCs are identified, which is what I hear when I read Paul's email, then we are potentially doing things that should perhaps be covered within E2U instead.

Ken
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Richard Shockey [[email-masked]]
Sent: Tuesday, February 09, 2010 10:13 AM
To: 'Paul Kyzivat'; 'Jay Daley'
Cc: 'Bernie Hoeneisen'; 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] Request for input on market need evidence for E2MD

-----Original Message-----

???