Re: [stir] current draft charter

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

<sigh>  Since it seems folks want some authoritative history of 6116 I
suppose I should oblige.  I only co-chaired the ENUM WG for nearly 8 years.
Brother Pfautz can also relate the issues.

There were multiple reasons e164.arpa failed though 6116 technology has
worked very well imbedded in carrier networks as a TCAP replacement where
the CSCF or SIP proxy needs to perform some form of number translation for
some data or metadata, typically for the call routing function. On a
localized, distributed and fully cached basis ENUM  essentially becomes a
Central Routing Server. One of the big holes in IMS BTW.   Essentially an IP
Service Control Point in old TDM/SS7 terms.  

ENUM did not fail .. e164.arpa failed.  Like lots of IETF protocols they
sometimes get use for things not originally intended. MIME immediately comes
to mind. 

If I recall ENUM still baked into the IMS architecture.  SIP Redirect also
works well for number translation functions and modern database technology
has made the difference in query response time negligible.  It's now only a
question of network preference on which protocol to use. There is a lot of
real 6116 technology out there.   Hadriel is right and Brian is simply wrong
6116 IS everywhere and it's baked into every SIP Session Border Controller
sold on the Planet. 

There is no question you could develop some HTTPS like methodology that
would equally well for number translations but as a practical matter it's
simply a matter of taste.  Provisioning is the larger problem and DRINKS is
still at it after 4 years. 

Dan and Brian correctly points out one of the issues with a public tree was
privacy. The idea that since the tree was public on the global Internet an
enterprising Voice Spammer could scrape the tree to identify all active
E.164 numbers.   Brian's issue #6 is a not true since any US carrier for
instance can actually see the underlying carrier number for any NANP number
in the system.  For other jurisdictions carrier identification in the
underlying numbering databases is different. 

Obviously the #1 problem e164.arpa was the delegation model which required
endless fights with the ITU which no one, I assume wants to repeat.

Second the DNS is what it is, so you were left with no methodology for
Authentication or Authorization of the query itself. In private
instantiations this was solved by requiring VPN access even down to a
limited set of IP addresses.  It works if the application using 6116 was
limited enough.    IN the US this was done for the MMS mobile picture
routing application and the FCC's own I-TRS database for the hearing
impaired. 

Third ... one answer.  In SIP call routing this posed a problem generally
referred to Determinate Response.  The target URI for the terminating
Carrier SBC might be different based on who was asking the question and
ultimately where.  Obviously we got nowhere with Kaplan source URI though I
understand it has been implemented in private ENUM instantiations. Private
firms like Akamai munge DNS all the time in CDN networks to optimize the
source of content to the location of the query. 

Fourth was the obvious political problem of having carriers agree to allow
user control of routing data and that was a nonstarter.  However if the tree
was actually in control of the service providers ... gee  GSMA Pathfinder..
well then that was NOOOOOO problem. But Pathfinder had its own set of
issues.  There were at least 2 other well-funded ENUM initiatives driven by
carriers in the US alone, but in my judgment they have not deployed since
the market conditions and requirements were not ready.  In addition there
are at least a dozen private ENUM services in existence. 

"Money is the answer what is the question?"  Shockey's Law.   

http://www.gsma.com/technicalprojects/pathfinder

That said the proposed requirements here are actually different and the
market conditions have demonstrably changed so certainly 6116 technology
COULD work but you would have to revisit a lot of  issues like the E2MD
problem etc Source URI and the provisioning issues.  The interest of the
carriers and the regulators are in actual alignment here. 

6116 is a reasonable option that should be left on the table for
consideration as the STIR process moves forward and the full requirements
are actually understood. One of those is the structure for E.164 numbers
controlled by Public Safety and Government authorities themselves. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dan
York
Sent: Thursday, June 13, 2013 8:52 AM
To: Hadriel Kaplan
Cc: [e-mail]; Stephen Farrell; Dave Crocker; Peterson, Jon; Henning
Schulzrinne
Subject: Re: [stir] current draft charter

Hadriel,

On 6/12/13 5:38 PM, "Hadriel Kaplan" <[e-mail]> wrote:

>That begs the question of what issues you think made Public ENUM fail, 
>and why we won't hit the same issues in whatever model we choose.

Since you addressed this question to me, I feel compelled to answer... but
in the meantime both Brian and Jon have given much more detailed answers
with which I mostly agree.

I saw security/privacy issues as the main issues that made Public ENUM not
work, i.e. Brian's points 4, 5 and 6:

> 4. Any public database that was able to show any information about a 
>telephone number was considered a privacy issue, requiring a lot of 
>"sign off", which never happened.
> 5. Everyone objected to being able to determine what numbers were "live"
> 6. Carriers objected to a public database that told competitors what 
>numbers they controlled


The potential for spam was also high.  Five or six years ago there was at
least one tool circulating around that would walk an ENUM tree, generate a
list of all potential phone numbers and then send SIP INVITEs to all of
those numbers.  I remember either seeing a video or reading about how
someone did this with all the public ENUM numbers published for Germany (at
that time). So using Public ENUM could be a fantastic way to potentially get
yourself on the calling lists for telemarketers.

Ideally, I think a public service *would* be a useful way to enable
ubiquitous usage. I'm just not sure how to get there without also opening a
solution up to these same kind of security/privacy issues.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[e-mail] <mailto:[e-mail]>   [phone]
Jabber: [e-mail] <mailto:[e-mail]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir