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

"Peterson, Jon" <jon.peterson@neustar.biz> Mon, 05 March 2012 23:34 UTC

Return-Path: <jon.peterson@neustar.biz>
X-Original-To: enum@ietfa.amsl.com
Delivered-To: enum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC7821E8045 for <enum@ietfa.amsl.com>; Mon, 5 Mar 2012 15:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.043
X-Spam-Level:
X-Spam-Status: No, score=-106.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdhG8y1vgtbN for <enum@ietfa.amsl.com>; Mon, 5 Mar 2012 15:34:35 -0800 (PST)
Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DC78D21F8517 for <enum@ietf.org>; Mon, 5 Mar 2012 15:34:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330990502; x=1646346262; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=LN6Q4MIvtT8P1i7kL7fQAMj1b4iKWQ+4nQDFZIycNa0=; b=WoMwAETsNDeQh6DjqkdZPtOCym4kAHcAoM8HrJ4KMsclYKs0T6TzQeRealji3F 3Kv7Zglt9BZ1/b6uMVuNRGUw==
Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.5313396; Mon, 05 Mar 2012 18:35:01 -0500
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 5 Mar 2012 18:34:31 -0500
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "enum@ietf.org" <enum@ietf.org>
Date: Mon, 05 Mar 2012 18:34:28 -0500
Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries
Thread-Index: Acz7KIM0barbWfHgT5+aMYrRMzALnw==
Message-ID: <0127682F-7383-4E94-A6EB-EC91DAA87934@neustar.biz>
References: <55A5A9A87506CB4BA580BF9D531957DA239D6332@STNTEXCH01.cis.neustar.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed:
x-ems-stamp: ibyQrCOmhESolL0FF1Yksg==
Content-Type: multipart/alternative; boundary="_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_"
MIME-Version: 1.0
Subject: [Enum] Fwd: [dispatch] New Proposal for Telephone-Related Queries
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/enum>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2012 23:34:36 -0000

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

Jon Peterson
NeuStar, Inc.

Begin forwarded message:

From: "Peterson, Jon" <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>
Date: March 5, 2012 1:51:00 PM PST
To: "dispatch@ietf.org<mailto:dispatch@ietf.org>" <dispatch@ietf.org<mailto:dispatch@ietf.org>>
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://datatracker.ietf.org/doc/draft-peterson-terq/

Any thoughts about the direction or the specifics of the data model are welcome. Thanks!

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