Fwd: [dispatch] New Proposal for Telephone-Related Queries

--===============1020194510249478767==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_"

--_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This proposal may be of interest to the remnants of this working group.

Jon Peterson
NeuStar, Inc.

Begin forwarded message:

From: "Peterson, Jon" <[email protected]<mailto:jon.peterson@neustar=
.biz>>
Date: March 5, 2012 1:51:00 PM PST
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto=
:[email protected]>>
Subject: [dispatch] New Proposal for Telephone-Related Queries


I have a proposal to bounce off the group. Basically, this is a re-examinat=
ion of some of the problems we've previously considered in the telephony-sp=
ecific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through disc=
ussions in the past couple years, it's become clear that we would need to s=
ignificantly extend ENUM to get it to handle all of the sorts of sources, s=
ubjects, and attributes that people want to factor into queries about telep=
hone number routing and administration. Most of these discussions have gott=
en wrapped around the axle on questions of the underlying syntax and semant=
ics 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 peo=
ple actually want to make of these protocols, in federated, service-provide=
r-driven environments like those envisioned in SPEERMINT and provisioned in=
 DRINKS. While the discussion may have died down a bit, the requirements th=
at 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 toward=
s agreement on the semantics of queries for telephone-related data independ=
ently of any underlying protocols. In other words, focus on what kinds of q=
uestions 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 ca=
n think of a bunch of different kinds of source: the logical originator of =
the query (the administrative entity asking), the logical identity of any i=
ntermediary or aggregator forwarding the query, or even the point at the ne=
twork from which the call originates (the originating trunk group, SBC or w=
hat 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 a=
s 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 fo=
r 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 rou=
ting 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 A=
PI, 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 re=
ally want the questions and answers to be, rather than thinking about what =
they realistically can be within the constraints of some existing underlyin=
g protocol.

That's the idea. I'm not going to present a proposed charter for work or an=
ything like that in Paris, but I am interested in hearing if people think t=
his is a promising approach, and if so, perhaps we'd put a charter on the a=
genda for Vancouver. I have however submitted a -00 draft for this time whi=
ch gives a high-level proposal for a data model and at least enumerates wha=
t some of the elements might be that would be populated in queries and resp=
onses. This is a pretty broad sketch, but it should convey the basic idea. =
You can check it out here:

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

Any thoughts about the direction or the specifics of the data model are wel=
come. Thanks!

Jon Peterson
NeuStar, Inc.
_______________________________________________
dispatch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dispatch


--_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
 space; -webkit-line-break: after-white-space; "><div><br></div>This propos=
al may be of interest to the remnants of this working group.<div><br></div>=
<div>Jon Peterson</div><div>NeuStar, Inc.<br><div><br><div>Begin forwarded =
message:</div><br class=3D"Apple-interchange-newline"><blockquote type=3D"c=
ite"><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; font-size:medium=
; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span style=3D"font-family:'=
Helvetica'; font-size:medium;">"Peterson, Jon" &lt;<a href=3D"mailto:jon.pe=
[email protected]">[email protected]</a>&gt;<br></span></div><div s=
tyle=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left=
: 0px;"><span style=3D"font-family:'Helvetica'; font-size:medium; color:rgb=
a(0, 0, 0, 1);"><b>Date: </b></span><span style=3D"font-family:'Helvetica';=
 font-size:medium;">March 5, 2012 1:51:00 PM PST<br></span></div><div style=
=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0p=
x;"><span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0,=
 0, 0, 1);"><b>To: </b></span><span style=3D"font-family:'Helvetica'; font-=
size:medium;">"<a href=3D"mailto:[email protected]">[email protected]</a>" =
&lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;<br></spa=
n></div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0p=
x; margin-left: 0px;"><span style=3D"font-family:'Helvetica'; font-size:med=
ium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span style=3D"font-fa=
mily:'Helvetica'; font-size:medium;"><b>[dispatch] New Proposal for Telepho=
ne-Related Queries</b><br></span></div><br><div><br>I have a proposal to bo=
unce off the group. Basically, this is a re-examination of some of the prob=
lems we've previously considered in the telephony-specific cluster of work =
surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past cou=
ple years, it's become clear that we would need to significantly extend ENU=
M 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 a=
xle on questions of the underlying syntax and semantics of the DNS, which w=
ere 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 ma=
ke of these protocols, in federated, service-provider-driven environments l=
ike those envisioned in SPEERMINT and provisioned in DRINKS. While the disc=
ussion may have died down a bit, the requirements that motivated th<br> e d=
iscussion definitely aren't going away.<br><br>Rather than continue to deba=
te 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 prot=
ocols. In other words, focus on what kinds of questions about telephone num=
bers we want to be able to ask, and what kinds of information needs to go i=
nto the answers, and incorporate all this into an abstract data model. So f=
or example, we know that we want to be able to express the source of a requ=
est in a query. What do we mean by source? I can think of a bunch of differ=
ent kinds of source: the logical originator of the query (the administrativ=
e entity asking), the logical identity of any intermediary or aggregator fo=
rwarding the query, or even the point at the network from which the call or=
iginates (the originating trunk group, SBC or what have you). All three of =
those concepts of source seem important when it comes to answe<br> ring que=
stions about telephone numbers, so a data model would treat those as separa=
te elements which can vary independently - then we can then try to figure o=
ut what's mandatory or optional, etc. We follow this same method for all th=
e elements of queries and responses. Figure out what the attributes are of =
telephone numbers that we care about, sort them into buckets of routing dat=
a and administrative data, and so on.<br><br>Once we have an agreement on t=
he data model, then people can map the model to whatever underlying protoco=
l they'd like - or just build it into a web API, or what have you. Those pr=
oposals could advance as separate documents. Having that flexibility would =
make it a lot easier to figure out what we really want the questions and an=
swers to be, rather than thinking about what they realistically can be with=
in the constraints of some existing underlying protocol.<br><br>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 pr=
omising approach, and if so, perhaps we'd put a charter on the agenda for V=
ancouver. 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 t=
he 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 che=
ck it out here:<br></div></blockquote><br><a href=3D"https://datatracker.ie=
tf.org/doc/draft-peterson-terq/">https://datatracker.ietf.org/doc/draft-pet=
erson-terq/</a></div><div><br><blockquote type=3D"cite"><div>Any thoughts a=
bout the direction or the specifics of the data model are welcome. Thanks!<=
br><br>Jon Peterson<br>NeuStar, Inc.<br>___________________________________=
____________<br>dispatch mailing list<br><a href=3D"mailto:[email protected]=
g">[email protected]</a><br>https://www.ietf.org/mailman/listinfo/dispatch<=
br></div></blockquote></div><br></div></body></html>=

--_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_--

--===============1020194510249478767==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
enum mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/enum

--===============1020194510249478767==--