Re: [stir] current draft charter

1. the "global root" problem - who owns and manages e164.arpa, and what are the rules?
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
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
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
8. Delegation of numbers don't fit a tree model any more
9. URIs and other things you put in the DNS were insufficient for the problem
10. Other databases for the problems existed, and it was easier to use them, mostly because they existed.  These are non-public databases

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.

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

We learned in ENUM that DNS is not a good fit for a telephone number.  We understand it looks attractive, but it doesn't fit, primarily because the tree doesn't reflect the delegation model, and a complete tree out to each individual TN is not really a practical solution.  Delegations are ranges.  DNS doesn't do ranges.  Delegations have port-out issues, which DNS doesn't do unless you populate the whole tree.  It's a bad fit.

The DNS guys, at the time, kept asking us "do the limitations of DNS work for you"?  We kept believing, and saying yes.  I now understand why they kept asking the same damn question over and over.  The limitations do not work for us.

My company has built ENUM based systems.  We continuously trip over the mismatch between the DNS model and the problem.  We fix it by ignoring the DNS model, building a database that matches the actual delegation model and treating the DNS query as an awkward, but solvable interface issue.  And it still bites us on things like UDP (very bad for DDoS security) and the restrictions on what a NAPTR can do.

Brian
On Jun 12, 2013, at 5:42 PM, Dave Crocker <dcrocker@bbiw.net> wrote:

> On 6/12/2013 2:38 PM, Hadriel Kaplan wrote:
>> On Jun 12, 2013, at 4:40 PM, Dan York <york@isoc.org> wrote:
>>> ... I think this issue will get in the way right now.  As much as I would
>>> love to see this as a good example of where DANE can help, I still haven't
>>> been able to wrap my brain around how we could use DNS for telephone
>>> numbers without running into all the exact same issues that made public
>>> ENUM non-deployable.  :-(
>> 
>> 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.
> 
> 
> +1
> 
> 
> d/
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir