Subject: Re: [dispatch] terq charter revision

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 11 Mar 2013 14:43:38 +0000

Thanks for these notes - to your points below:

1. TeRQ serves the use cases described in the document. It can indeed help today's carriers, but it certainly is not limited to that use case. It is based on the idea that Authorities can provision data, but that Authorities can be any entities trusted by Sources. One of the limitations of the ENUM model historically was its monolithic initial trust model rooted in e164.arpa, which turned out to map poorly to the realities of number management. That legacy ended up inspiring many kludges to get ENUM working in any practical environment. TeRQ is trying to improve on that.

2. I'd say the situation is no different for TeRQ. ENUM built on the DNS, it's true, but you would have had a hard time finding a NAPTR parser when ENUM came out, let alone one that understood ENUMs interpretation of order and preference, for example. TeRQ is not out to build any new protocols, and whether it gets bound to HTTP or DIAMETER or what have you, the amount of new work you'll need to do to parse the objects it encodes won't compare too unfavorably to the ENUM precedent. 

3. The security model is certainly the main way that TeRQ is richer, but that's not just a matter of source identification. It's also about Authorities, and potentially multiple Authorities, as I noted. But the full on inventory search by capability, the ability to operate on number ranges, to narrow searches through attributes, all of these are what I man by richness. They are described in the use cases.

4. The charter wants to make sure that we don't neglect the work done in DRINKS and elsewhere in the iETF. I don't think TeRQ should be restricted to that set of provisioned data, but it should be able to query for the data that DRINKS determined how to provision. It is a bit of question whether ENUM can do that, for example, because the LUF/LRF distinction implies an ability to map SPIDs to URIs, where ENUM is explicitly scoped to mapping from just telephone numbers. The ability to translate identifiers like SPIDs is, incidentally, another respect in which the TeRQ model exhibits richness.

5. It's hard for me to defend any charter dates we propose in the IETF with a straight face, but I think the information model could be in worse shape. The main thing it needs now is the IANA work to fill in how you extend elements and the exact process for specifying a binding. We're not going to define every possible element or attribute in the base information model. If we can get the registration process down, I don't think there's a ton more to do on this document. 

Hope that helps,

Jon Peterson
NeuStar, Inc.

Sent with Good (www.good.com)

 -----Original Message-----
From: 	PFAUTZ, PENN L [mailto:[email-masked]]
Sent:	Monday, March 11, 2013 08:50 AM Eastern Standard Time
To:	Peterson, Jon; [email-masked]
Subject:	RE: terq charter revision

Jon:
I still have some questions about this enterprise:
1. What will be the basis for the information model to be developed? Will it address the needs of the service providers and regulators that currently control the E.164 space or is it end user/webRTC focused? Or both?
2. What was attractive about ENUM was the way in which it leveraged an existing protocol and ecosystem to make telephone numbers fit into IP. I'm not quite sure how to think of the current effort in those terms.
3. w/r/t to "richer queries and responses" and " more sophisticated application logic", the only thing that richer seems to mean is source-based. Do we really need a new framework for that? And people have already found ways to apply more sophisticated application logic by putting an ENUM front end on a relational database.
4. The statement about making sure the information model conforms to the needs of the provisioning systems concerns me in that, if we're taking the trouble to define an information model de novo, the dictates of the model ought to take precedence over the provisioning system rather than be restricted by it.
5. If we're serious about defining an encompassing information model I think a framework by August 2013 is way optimistic, unless there's something waiting in the wings.

Penn Pfautz
AT&T
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Thursday, March 07, 2013 6:27 PM
To: [email-masked]
Subject: [dispatch] terq charter revision

Based on the comments previously received, this is a slight revision to the TeRQ charter. The fundamentals here though are pretty much unchanged: the plan is to do the framework and information model document and one binding document, rechartering if there is interest in doing any further binding documents.

Jon Peterson
NeuStar, Inc.

---

Title: Telephony-Related Queries
Acronym: terq
Area: Real-time Applications and Infrastructure
Area Director: TBD
Chair(s): TBD
Mailing address: TBD (currently [email-masked])

Description of Working Group

Several IETF efforts have studied the handling of telephone numbers on the Internet. For example, the ENUM working group specified a DNS-based approach to transforming telephone numbers into URIs; the DRINKS working group produced a provisioning system suitable for populating Internet directories of telephone numbers. The overall goal of this work has been to migrate the routing and directory functions of the telephone network onto the Internet, in order to simplify the implementation of Internet telephony and reduce the Internet's reliance on the infrastructure of the public switched telephone network. Ultimately, the requirements for this project diverged significantly from the original architecture and applicability of ENUM. Moreover, in the twelve years since ENUM was first chartered, Internet telephony has changed a great deal. As one example, today web-based applications are becoming more significant to Internet telephony, as are intelligent mobile devices. In these env
 ironments, there exists a capacity for richer queries and responses, as well as more sophisticated application logic to process requests, but also tougher security requirements. As such, this working group reconsiders the migration of routing and directory functions from the telephone network to the Internet by generalizing the base semantics of queries and responses in an abstract framework, and then defining possible transports and encodings for these messages.

The components of the chartered work include:

1. A framework and information model for the construction queries and responses. The information model will provide an abstract description of the semantics of the various elements and attributes that make up TeRQ messages. The framework will further establish the semantics of TeRQ transactions, describe how responses are matched with queries, and give an overview of the operation of the protocol. It will furthermore describe the overall security model of TeRQ, including confidentiality and access control measures necessary to preserve privacy.

2. A process for specifying bindings for the information model, which comprise transports and encodings. Transports specify the underlying protocols that will encapsulate TeRQ queries and responses. This working group is not chartered to define new underlying protocols, but will specify how the transaction model of TeRQ maps onto these underlying protocols. Potential underlying protocols include HTTP and DIAMETER. The encoding determines how TeRQ elements and attributes will be rendered in the object format carried by the transport; potential object formats would include JSON and XML and well as lower-layer encodings. Binding specifications must detail their implementation of the security and privacy requirements defined in the framework.

3. A set of one or more bindings compliant with the process described in (2), which provide a concrete instantiation of the protocol. This group will be initially chartered to create a single binding, though other may be a potential subject for ongoing work after a rechart. These bindings may accompany profiles that detail particular sets of attributes or elements relevant to a given deployment.

The TeRQ working group will coordinate with ongoing work in the DRINKS space in order to make sure that the TeRQ information model conforms with the needs of provisioning systems. Whenever possible, TeRQ will reuse existing IETF work. The syntax and semantics of telephone numbers, for example, have been the subject of a great deal of previous IETF work (notably RFC 3966), and the TeRQ working group will rely on this and related prior work.

Goals and Deliverables:

Aug 2013        Submit Framework for Telephony Related Queries as Proposed Standard
Nov 2013        Submit one TeRQ Binding as Proposed Standard
Feb 2013        Recharter if additional bindings are required
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch