Re: [Enum] [dispatch] New Proposal for Telephone-Related Queries

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

I think this a perfectly reasonable proposal.  I'd like to see it move
forward.

It would be useful not to get into any Layer 10 issues of what people have
used 6116 for. The simple fact is that its there, it scales, its fully
deployed in private instantiations in major carrier networks and is baked
into multiple NNI profiles. 

That said we know two things.  6116 has limitations due to its use of
underlying DNS technology. Jon is right that the problem of determinate
response based on source of the query in DNS has forced us to look at some
duct tape and wire solutions that may be sub optimal. Though source-URI does
work. 

Speaking of Layer 9, the other issue is phone numbers are not going away and
any transition from POTS to FOO is going to have to deal with multiple types
of data associated with those identifiers.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Peterson, Jon
Sent: Monday, March 05, 2012 5:05 PM
To: '[e-mail]'
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/

Jon Peterson
Neustar, Inc.



 -----Original Message-----
From: 	Peterson, Jon [mailto:[e-mail]]
Sent:	Monday, March 05, 2012 04:51 PM Eastern Standard Time
To:	[e-mail]
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.
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch