Subject: [drinks] FW: New Proposal for Telephone-Related Queries

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 6 Mar 2012 14:05:54 -0700

For those not subscribed to the DISPATCH mailing list...

- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Monday, March 05, 2012 3:05 PM
To: [email-masked]'
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Oops, sorry, my mailer did not like the URL I submitted. The correct URL for the draft is:

https://datatracker.ietf.org/doc/draft-peterson-terq/

<snip>

 -----Original Message-----
From: 	Peterson, Jon [mailto:[email-masked]]
Sent:	Monday, March 05, 2012 04:51 PM Eastern Standard Time
To:	[email-masked]
Subject:	[dispatch] New Proposal for Telephone-Related Queries

I have a proposal to bounce off the group. Basically, this is a re-examination of some of the problems we've previously considered in the telephony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past couple years, it's become clear that we would need to significantly extend ENUM to get it to handle all of the sorts of sources, subjects, and attributes that people want to factor into queries about telephone number routing and administration. Most of these discussions have gotten wrapped around the axle on questions of the underlying syntax and semantics of the DNS, which were a good match for the original vision of a public, user-driven ENUM, but don't seem to be such a good match for the uses people actually want to make of these protocols, in federated, service-provider-driven environments like those envisioned in SPEERMINT and provisioned in DRINKS. While the discussion may have died down a bit, the requirements that motivated th  e discussion definitely aren't going away.

Rather than continue to debate the applicability of the DNS and the probity of various extensions to it, we might make more progress if we work towards agreement on the semantics of queries for telephone-related data independently of any underlying protocols. In other words, focus on what kinds of questions about telephone numbers we want to be able to ask, and what kinds of information needs to go into the answers, and incorporate all this into an abstract data model. So for example, we know that we want to be able to express the source of a request in a query. What do we mean by source? I can think of a bunch of different kinds of source: the logical originator of the query (the administrative entity asking), the logical identity of any intermediary or aggregator forwarding the query, or even the point at the network from which the call originates (the originating trunk group, SBC or what have you). All three of those concepts of source seem important when it comes to answe  ring questions about telephone numbers, so a data model would treat those as separate elements which can vary independently - then we can then try to figure out what's mandatory or optional, etc. We follow this same method for all the elements of queries and responses. Figure out what the attributes are of telephone numbers that we care about, sort them into buckets of routing data and administrative data, and so on.

Once we have an agreement on the data model, then people can map the model to whatever underlying protocol they'd like - or just build it into a web API, or what have you. Those proposals could advance as separate documents. Having that flexibility would make it a lot easier to figure out what we really want the questions and answers to be, rather than thinking about what they realistically can be within the constraints of some existing underlying protocol.

That's the idea. I'm not going to present a proposed charter for work or anything like that in Paris, but I am interested in hearing if people think this is a promising approach, and if so, perhaps we'd put a charter on the agenda for Vancouver. I have however submitted a -00 draft for this time which gives a high-level proposal for a data model and at least enumerates what some of the elements might be that would be populated in queries and responses. This is a pretty broad sketch, but it should convey the basic idea. You can check it out here:
https://exchcas.va.neustar.com/owa/thoughts about the direction or the specifics of the data model are welcome. Thanks!

Jon Peterson
NeuStar, Inc.