Re: [stir] current draft charter

[Hadriel Kaplan <[e-mail]>]

On Jun 12, 2013, at 6:02 PM, Brian Rosen <[e-mail]> wrote:

> 1. the "global root" problem - who owns and manages e164.arpa, and what are the rules?

We're not talking about e164.arpa per se, but let's assume cid.arpa: the owner of cid.arpa in theory should be the ITU, and they should delegate the country-code subdomains to the respective country number admin authorities (a list that is relatively small and very static).  In practice, however, we might be able to get away with having IANA just do it directly to the country admin authorities.  The actual *work* of administration and running servers wouldn't be done by them, but rather contracted out.


> 2. It took action by the regulator before anything happened.  Because many regulators didn't understand what this thing was, and still don't, they didn't act
> 3. It took a level of cooperation between service providers who owned parts of the hierarchy that could not be gained

The reason for both those above issues is the same: because there was nothing to gain by the stakeholders.  A Public ENUM wouldn't do anything new for carriers, just cause headaches.  It wouldn't even benefit consumers.  It was a solution looking for a problem.

If, on the other hand, we think caller-id validation is a real problem for service providers themselves, that either they themselves recognize and want to fix or the regulators force them to recognize and fix, then that's a very different ballgame.  As long as the solution doesn't disrupt their business models and operations overhead.


> 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

Agreed, the above are real problems.  But it's not clear if they apply to E.164 signature keys.  #4 and #5 are easy to avoid... #6 not so much.  I can't quite figure out how to avoid #6.  :(


(I'll skip #7 and move it to later)
> 8. Delegation of numbers don't fit a tree model any more

Agreed, but we don't need to delegate anything out to anyone.  The subdomain authority could remain with the country number admins for ALL their numbers.  For example, all country-code-44 number certs in the DNS records could be issued by OFCOM as the CA, not by the UK carriers.  The UK carriers would do the signing, because OFCOM would give them the priv keys for their numbers.


> 9. URIs and other things you put in the DNS were insufficient for the problem

Actually people have fit a crap-load of stuff into ENUM NAPTR URIs, but we're not talking about NAPTR nor URIs for this new thing anyway.


> 10. Other databases for the problems existed, and it was easier to use them, mostly because they existed.  These are non-public databases

Yup, existing deployment invariably trumps something new if the something new doesn't provide new capabilities/features/revenue/cost-savings.  But I don't know of an existing caller-id verification database.  There are existing caller-name databases of course, but that's different.
And the ENUM ones are non-public because the data itself is (1) private and (2) not usable in a public context.  The entries in the database (the results of the lookup) aren't meaningful to anyone but the carrier asking the query.  That doesn't apply for caller-id keys.


> 7. The DNS query was a poor fit for the problem - what evolved was a SIP redirect interface because no vendors liked the DNS interface
> 
> As Rich Shockey notes, there is a fair amount of "ENUM" deployment inside carriers, although it's a SIP redirect interface.  The underlying data structures are the same as ENUM.  Actually, it's only the interfaces for provisioning that are the same.  No one ever does a DNS query.

I think you and I live in different worlds.  Perhaps you never see ENUM being used because maybe it doesn't reach Neustar's services?  In my world, ENUM gets used a LOT.  If you run Wireshark inside the carrier on the right links/subnets, you'll see constant DNS queries for NAPTRs using reverse-number-dotted domain-name format for the query key.  It's not SIP Redirect, it's actual DNS over UDP packets.  But it never leaves the carrier's private network.  It's generated by proxies, gateways, and SBCs as clients, to databases.  And speaking for one vendor, we like it way more than SIP Redirect (which we also support); and apparently so do some of our big customers.  It has some real benefits.


> If we want this deployed soon, it's my considered opinion you can't have a public per-TN database.


Of course, it's always faster/easier to deploy something in private contexts at the start.  If we go with a Public-Internet DNS-based model as the ultimate goal/solution, for example: one could start earlier with the data for some subset of numbers, on servers run by Neustar or whomever, only accessible by members "in-the-club".  I.e., similar to a private or carrier ENUM model.

-hadriel