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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 5 Mar 2012 17:04:59 -0500

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:[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.
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Mar 2012 12:08:13 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Peterson, Jon
Sent: Monday, March 05, 2012 5: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:

Jon Peterson
Neustar, Inc.

 -----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.

---

From: David Schwartz <[email-masked]>
Date: Wed, 7 Mar 2012 05:13:41 +0200

Hi Jon

Imho, it is critical to come up with a set of use cases prior to defining a data model. Data models come to answer a need and while we all know there is a need for this, I think it will be easier to discuss in the context of a high level use case doc. With that said, here are a few quick comments (more in Paris :))

1. The text for a Query Intermediary currently states... "This field is provided in the source for those deployments in which the service makes an authorization decision based on the identity of the intermediary rather than a query source". I can think of use cases where the intermediary is authenticated but the authorization is based on the source.

2. Query Source has as one of its types a domain name - not sure I understand this use case (I like the TN and URI)

3. You split Attributes into "administrative" and "routing". I think this will require lots of discussion in Paris (and again - use cases would be helpful here) as I see different types of attribute classes. The "administrative" ones are more "flag" like (not name-value) and kind of define the "application" or "service". These guys are the part of the query that tell the service what kind of resolution is required. For example, CNAM would indicate that I am not looking for a RouteGroup in DRINKS terminology - but rather "ownership" or even "assignment rights" at the level of the TN or identifier, while "ROUTE" could indicate a typical routing resolution. While I agree that these serve to limit or filter the resolution set - I still think that they are in a separate class. These may have to be registered in an IANA type registry, but again, this is to be discussed.  In addition, the Routing attributes are also just a subclass of a more generic type of attributes that can included other types of non routing based attributes. Again, Use cases are your friend and as we are rethinking this problem in 2012 and not when ENUM was created we need to be much more generic. I will save examples of this for Paris, but I am sure we can all come up with non routing based lookups that we may want to associate with the subject.

4. Following up on the last comment in your examples of attributes, I would differentiate between flag type attributes (e.g. "CarrierOfRecord") and name=value type attributes (e.g. service=voip or service=sms)

5. I would consider a "supported" type indication in the response to inform the querying party which attributes are allowed

6. I would think of adding a mechanism to limit number of responses a querying party wishes to get so that if the resolution set is large, the querying party can define how many responses he/she is interested in getting

7. TBD in Paris - but do we want to provide state (e.g. "cookie") for query so that service can provide different information in a followup query by same party (use-case)

Overall, I think this is a fantastic idea and long overdue. We have been "patching" existing protocols for so long that the code has become quite cumbersome at this point.

I will support this effort.

Thanks,

:D

 If a Query Intermediary is used

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 6 Mar 2012 22:59:21 -0500

Hi David,

Thanks for giving this a detailed read and noodling it over, and glad you support the effort!

At this stage of the dispatch process, really the question for the group will be whether or not there's sufficient interest in the direction and so on to justify chartering, and even that discussion isn't going to be resolved in Paris given this started up pretty late in this cycle. Definitely I am as eager as you to delve into some of the technical details, but bear in mind that my -00 is really intended more to illustrate the potential space rather than to solve the problem at the outset. Use cases as you say will be crucial to nailing this down when we get to that stage. Still, a couple quick notes on some of your comments below...

1. I'm sure there are cases where the Server wants to know both who originated the query and who intermediated, and might make authorization decisions based on both or either, definitely. The idea is to supply as much of that intelligence as we can.

2. att.com? comcast.net? Things like that. The logical identity of the administrative domain that is sending the request seems like something that just a domain name can represent, in some cases. Wouldn't want to rule it out.

3. I'm not sure the two categories I proposed here are the end-all-be-all, sure. Ultimately, given how generic the framework is, I can imagine even defining different profiles with packages of relevant attributes for different use cases. That's a ways down the pike though. Ultimately I do envision that attributes and virtually all other parts of the data model will be extensible in IANA registries.

4. This is a pretty low-level question about syntax, really, but I suppose I wouldn't rule out attributes that have no values in responses, sure. I don't think (to your previous point) that necessarily all "administrative" attributes lack values.

5. There will definitely need to be some kind of capability negotiation mechanism - again, I suspect it might be something closer to profiles at the end of the day, but we'll see.

6. The chunking characteristics of certain underlying protocol have been a problem here in the past, yes. In the general framework as I've laid it out anyway, this question would be deferred to the underlying protocols to solve. A lightweight binary mechanisms would do this differently than a web service.

7. That too might end up being something deferred to the encoding protocol. Some protocols will have persistent sockets and others just datagrams. There will in the data model need to be enough transaction identification to correlate requests and responses at the application layer, however, and it might be the case that we need something closer to a session than just a transaction to capture the semantics here. That is indeed exactly the sort of discussion we'd be having if we chartered this work.

Thanks again,

Jon Peterson
NeuStar, Inc.
________________________________________
From: David Schwartz [[email-masked]]
Sent: Tuesday, March 06, 2012 7:13 PM
To: Peterson, Jon
Cc: [email-masked]
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Hi Jon

Thanks,

:D

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 13 Mar 2012 15:11:01 +0000

I think this is an interesting activity and would not want to derail it, but let me play devil's advocate for a moment...

- if we were just starting out, as opposed to having lots of (at least internal and some external) deployments, I would be more optimistic
- although I know that the proposal responds to many concerns that have been raised with enum, I personally don't see the protocol issues or even the semantics of the of what the protocol can address as ever having been the major thing that has held enum back from full potential. It's always been lack of consensus on administrative arrangements driven by business and -dare I say- political concerns.

Good luck!

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Monday, March 05, 2012 5:05 PM
To: [email-masked]'
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Jon Peterson
Neustar, Inc.

 -----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

Jon Peterson
NeuStar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Mar 2012 14:54:39 -0400

Hi Penn,

Glad to hear this is of interest, at least. Certainly agreed that there is ENUM deployment out there - in fact, my own company does a bit of it. When protocols become successful and see deployment, people do start using them in unexpected ways which sometimes require significant modifications, and eventually you can reach a tipping point where it makes sense to reconsider the fundamentals. I think we've reached that point with ENUM, where we have seen proposals to extend ENUM (and the DNS) that warrant taking a step back and exploring whether or not we can get a better overall framework in place - at least a framework in which we can standardize features that have been proposed for ENUM but which fall outside the ways we can responsibly extend the DNS.

Also agreed, by the by, that administrative and political factors have held ENUM back from being all that it can be. You'll note that the TeRQ proposal does not prescribe any administrative framework like e164.arpa - it's really just a query/response protocol. The irony of e164.arpa is that it applied well to the original, public vision of ENUM, but has sometimes ended up hampering attempts to get the carrier-driven, more infrastructural deployments off the ground.

No one is expecting that the TeRQ proposal will snuff out ENUM deployment overnight. I'm sure ENUM will continue to serve a segment of the market for the foreseeable future. But ENUM was standardized twelve years ago now - a pretty good life cycle for any protocol. All I'm really proposing is that we see how much we could gain from starting on a different foundation. If we end up with something better, it will eventually phase into the market and get traction. All a standards activity can do is create that opportunity.

Jon Peterson
NeuStar, Inc.
________________________________________
From: PFAUTZ, PENN L [[email-masked]]
Sent: Tuesday, March 13, 2012 8:11 AM
To: Peterson, Jon; [email-masked]'
Subject: RE: [dispatch] New Proposal for Telephone-Related Queries

Good luck!

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Monday, March 05, 2012 5:05 PM
To: [email-masked]'
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Jon Peterson
Neustar, Inc.

 -----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

Jon Peterson
NeuStar, Inc.

---

From: Daryl Malas <[email-masked]>
Date: Wed, 14 Mar 2012 11:16:24 -0600

I think we should be careful in being presumptuous of what we will do or
the effects we will impose on any protocol at this point.

As part of this proposal, I think we should do some basic analysis of the
suite of protocols (and extensions) existing today related to this.  We
may or may not find that some could be used or further extended.

Of course, I'm open to creating a new mechanism as a result of this work,
if necessary.

--Daryl

On 3/13/12 2:54 PM, "Peterson, Jon" <[email-masked]> wrote:

>
>Hi Penn,
>
>Glad to hear this is of interest, at least. Certainly agreed that there
>is ENUM deployment out there - in fact, my own company does a bit of it.
>When protocols become successful and see deployment, people do start
>using them in unexpected ways which sometimes require significant
>modifications, and eventually you can reach a tipping point where it
>makes sense to reconsider the fundamentals. I think we've reached that
>point with ENUM, where we have seen proposals to extend ENUM (and the
>DNS) that warrant taking a step back and exploring whether or not we can
>get a better overall framework in place - at least a framework in which
>we can standardize features that have been proposed for ENUM but which
>fall outside the ways we can responsibly extend the DNS.
>
>Also agreed, by the by, that administrative and political factors have
>held ENUM back from being all that it can be. You'll note that the TeRQ
>proposal does not prescribe any administrative framework like e164.arpa -
>it's really just a query/response protocol. The irony of e164.arpa is
>that it applied well to the original, public vision of ENUM, but has
>sometimes ended up hampering attempts to get the carrier-driven, more
>infrastructural deployments off the ground.
>
>No one is expecting that the TeRQ proposal will snuff out ENUM deployment
>overnight. I'm sure ENUM will continue to serve a segment of the market
>for the foreseeable future. But ENUM was standardized twelve years ago
>now - a pretty good life cycle for any protocol. All I'm really proposing
>is that we see how much we could gain from starting on a different
>foundation. If we end up with something better, it will eventually phase
>into the market and get traction. All a standards activity can do is
>create that opportunity.
>
>Jon Peterson
>NeuStar, Inc.
>I think this is an interesting activity and would not want to derail it,
>but let me play devil's advocate for a moment...
>
>- if we were just starting out, as opposed to having lots of (at least
>internal and some external) deployments, I would be more optimistic
>- although I know that the proposal responds to many concerns that have
>been raised with enum, I personally don't see the protocol issues or even
>the semantics of the of what the protocol can address as ever having been
>the major thing that has held enum back from full potential. It's always
>been lack of consensus on administrative arrangements driven by business
>and -dare I say- political concerns.
>
>Good luck!
>
>Penn Pfautz
>AT&T Access Management
>+1-732-420-4962
>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
>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.
>
>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:

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Mar 2012 15:39:41 -0400

Obviously yes, I don't mean to suggest that any existing protocol is off the table as a potential underlying binding for TeRQ, but the whole point of approaching this from the semantics rather than the transport or encoding is to defer those latter questions so we can focus on what we want queries and responses to say. I think the analysis you recommend of how existing protocols could map to TeRQ would be part of the bindings development process - this is situation where we will want to let a thousand flowers bloom, and I'm sure there will be existing proposals that would be good bindings for TeRQ. 

However, let's not sweep the obvious under the rug - we wouldn't be having this TeRQ discussion at all if we had a clear path to extend the ENUM and DNS standards to handle the semantics that the use cases seem to require. That doesn't mean that a DNS binding is off the table, just that it would seem to face challenges.

Jon Peterson
NeuStar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 14 Mar 2012 16:20:08 -0400

"Challenges" is a understatement. We had a clear path to extend 6116 to
"other data types" aka E2MD in private instantiations among others but, for
reasons I still do not clearly understand, that was blocked by you and
others.

I completely concur with Daryl here. That said its certainly worth taking a
fresh look at things in light of recent regulatory moves in North America
toward the End of POTS. There has to be a solution to Number Translations in
converged networks. 

If I had a clean sheet of paper today ..sure JSON over SHTTP. Solves lots of
problems with Security ,AA and determinate response.  A hierarchical
structure may not be completely necessary in core carrier SIP/IMS networks. 

The problems you cite were with e164.arpa, however other uses have performed
very well in the field. Including the Federal Communications Commission
I-TRS system run by you know who. 

IMHO this is still NOT helpful to the discussion. 
 
http://www.ietf.org/internet-drafts/draft-iab-dns-applications-04.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peterson, Jon
Sent: Wednesday, March 14, 2012 3:40 PM
To: Daryl Malas
Cc: [email-masked]
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Obviously yes, I don't mean to suggest that any existing protocol is off the
table as a potential underlying binding for TeRQ, but the whole point of
approaching this from the semantics rather than the transport or encoding is
to defer those latter questions so we can focus on what we want queries and
responses to say. I think the analysis you recommend of how existing
protocols could map to TeRQ would be part of the bindings development
process - this is situation where we will want to let a thousand flowers
bloom, and I'm sure there will be existing proposals that would be good
bindings for TeRQ. 

However, let's not sweep the obvious under the rug - we wouldn't be having
this TeRQ discussion at all if we had a clear path to extend the ENUM and
DNS standards to handle the semantics that the use cases seem to require.
That doesn't mean that a DNS binding is off the table, just that it would
seem to face challenges.

Jon Peterson
NeuStar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Mar 2012 18:40:18 -0400

I know that the criticisms of E2MD will remain a sore point, but the idea here is to set those issues aside and focus on the data model in a protocol-neutral venue. In order to get at the converged network solution for after the end of POTS (aPOTScalypse now?), we need to consider requirements beyond the handful of things we debated in E2MD, anyway: the technical and operational issues that have faced ENUM deployments, the questions surrounding session establishment data in DRINKS, even the requirements of web-based services like those now considered in RTCWeb should be in play. 

If there is, for example, a use case where we want to resolve things other than telephone numbers (like SPIDs for LRF, say), then that might call for a slightly different applicability than ENUM (which is really about the resolution of telephone numbers). If the use cases really do support disentangling the original source of a query from a query intermediary, and distinguishing both of those from the "route source," that will require significant syntactic complexity in query. If we do want to be able to communicate in responses which authority provisioned the records, that too takes us into pretty uncharted territory. 

I wouldn't say it would be impossible to do these sorts of things with the DNS as an underlying transport - it would require some work in other areas of the IETF, I suspect, but it's not impossible - however, by the time we did, I'm not sure we'd be calling the end result "ENUM" anymore. What I don't want is to start off by limiting the semantics of queries and responses to meet the constraints of a particular potential transport.

Jon Peterson
NeuStar, Inc.

---

From: Daryl Malas <[email-masked]>
Date: Thu, 15 Mar 2012 11:15:31 -0600

I think we are in agreement. Thanks -- Daryl

On 3/14/12 1:39 PM, "Peterson, Jon" <[email-masked]> wrote:

>
>Obviously yes, I don't mean to suggest that any existing protocol is off
>the table as a potential underlying binding for TeRQ, but the whole point
>of approaching this from the semantics rather than the transport or
>encoding is to defer those latter questions so we can focus on what we
>want queries and responses to say. I think the analysis you recommend of
>how existing protocols could map to TeRQ would be part of the bindings
>development process - this is situation where we will want to let a
>thousand flowers bloom, and I'm sure there will be existing proposals
>that would be good bindings for TeRQ.
>
>However, let's not sweep the obvious under the rug - we wouldn't be
>having this TeRQ discussion at all if we had a clear path to extend the
>ENUM and DNS standards to handle the semantics that the use cases seem to
>require. That doesn't mean that a DNS binding is off the table, just that
>it would seem to face challenges.
>
>Jon Peterson
>NeuStar, Inc.
>
>>> Oops, sorry, my mailer did not like the URL I submitted. The correct
>>>URL
>>> for the draft is:
>>>

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 17 Mar 2012 12:20:20 -0400

Oh wow .. Oh Hadriel ... Hadriel we need a new insipid WG name :-) 

Seriously though. My patience with 6116 bashing is growing thin. The
requirements here are the issue. E.164 numbers are names that have to be
translated into useful things and there are multiple types of Session
Establishment Data  necessary to make common real-time communications (SIP)
work properly across domain boundaries. The problem has NOT been adequately
solved and collectively we are facing an serious issue since it is clear
that some National Regulatory Authorities want to end POTS and it is equally
clear we do not have a full protocol solution in place.

I just don't think this as complex as you suggest, since there is ample
evidence from the field that ENUM deployments DO work and work well, though
as I have said before, knowing what we know now based on the current state
of technology its worth a new look. 

This is complicated since it is fairly clear that you among others are
hinting that that 6116 should be rendered Historic.  If it is clear that
what you propose can NEVER be used over private DNS instantiations then at
least be up front about it.  

If it is also clear that you fundamentally object to the G-SPID draft than
please let us know since some of us need to think about Plan B. 

My next question is are we seeing new requirements or concerns coming from
3GPP for instance ( Keith ?) that would help move this work along in a
expedited manner? 

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2012 6:40 PM
To: Richard Shockey
Cc: [email-masked]; Daryl Malas; Peterson, Jon
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

I know that the criticisms of E2MD will remain a sore point, but the idea
here is to set those issues aside and focus on the data model in a
protocol-neutral venue. In order to get at the converged network solution
for after the end of POTS (aPOTScalypse now?), we need to consider
requirements beyond the handful of things we debated in E2MD, anyway: the
technical and operational issues that have faced ENUM deployments, the
questions surrounding session establishment data in DRINKS, even the
requirements of web-based services like those now considered in RTCWeb
should be in play. 

If there is, for example, a use case where we want to resolve things other
than telephone numbers (like SPIDs for LRF, say), then that might call for a
slightly different applicability than ENUM (which is really about the
resolution of telephone numbers). If the use cases really do support
disentangling the original source of a query from a query intermediary, and
distinguishing both of those from the "route source," that will require
significant syntactic complexity in query. If we do want to be able to
communicate in responses which authority provisioned the records, that too
takes us into pretty uncharted territory. 

I wouldn't say it would be impossible to do these sorts of things with the
DNS as an underlying transport - it would require some work in other areas
of the IETF, I suspect, but it's not impossible - however, by the time we
did, I'm not sure we'd be calling the end result "ENUM" anymore. What I
don't want is to start off by limiting the semantics of queries and
responses to meet the constraints of a particular potential transport.

Jon Peterson
NeuStar, Inc.

> Obviously yes, I don't mean to suggest that any existing protocol is off
the

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 18 Mar 2012 19:52:49 +0000

> However, let's not sweep the obvious under the rug - we wouldn't be having this TeRQ discussion at all if we had a clear path to extend the ENUM and DNS standards to handle the semantics that the u…

It faces challenges because the IAB does not distinguish between the *Protocol* of DNS, the *database structure* defined by DNS RFCs, and the *database instance* used for public Domain Name name resolution rooted in IANA roots.

Imagine if someone had defined SQL the language, a specific SQL database schema, and a specific instance of a MySQL database; and then said "Sorry the SQL language or schema cannot be extended because our particular MySQL database wasn't meant to have these new fields".  Despite that no one cares about using that person's particular MySQL database for the extended schema, and even if a client (erroneously) used the extended language/schema on that person's particular database it would just be ignored.

I get that the IANA-rooted instance of DNS the database will not handle new fields/semantics.  But to restrict the DNS *protocol* to only be able to do what the IANA-rooted instance does is bizarre - either the IAB believes the IANA-rooted DNS database is so brittle that receiving some unknown fields in a DNS query from erroneous clients would crash it, in which case US-CERT should be immediately notified, or the IAB believes that no distinction can be made between the protocol, port 53, and the deployed IANA-rooted Domain resolution databases.

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 19 Mar 2012 05:25:05 +0000

Hadriel Kaplan:

"I get that the IANA-rooted instance of DNS the database will not handle new fields/semantics.  But to restrict the DNS *protocol* to only be able to do what the IANA-rooted instance does is bizarre - either the IAB believes the IANA-rooted DNS database is so brittle that receiving some unknown fields in a DNS query from erroneous clients would crash it, in which case US-CERT should be immediately notified, or the IAB believes that no distinction can be made between the protocol, port 53, and the deployed IANA-rooted Domain resolution databases."

+1

Matthew Kaufman

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Mar 2012 13:49:42 -0400

I do apologize if that came across as "bashing" ENUM, that really wasn't my intention.  You and I agree completely that the requirements going forward is where we should be focusing, and indeed the whole point of the TeRQ proposal is to try to collect t a broader set of requirements and semantics than we did with ENUM in the past. When I said, for example, that ENUM resolves telephone numbers, and there might be identifiers other than telephone numbers (like SPIDs) that we might want to resolve, I'm not trying to knock RFC6116, I'm just trying to motivate exactly the requirements survey you're advocating. I have from the start said that ENUM deployments serve a useful purpose today, up to and including providing revenue for companies I am aware of, and the point of TeRQ is not to turn that off. We both know that some of the techniques that are used in ENUM deployments today face a tough path to becoming standards, though, and that was the only point I was trying to make.

I wouldn't say that the TeRQ data model (in rough the form I've sketched it) could never be applied to private DNS instantiations, no. I wouldn't rule out the DNS as a potential underlying protocol for TeRQ. I do speculate, though, that the results of doing so would like a bit different from RFC6116 - taking the example in my last paragraph, resolving SPIDs or other identifiers as the Subject of a Query would look a bit different from the First Well Known Rule.

Regarding GSPID, I think that work is somewhat orthogonal to the question here - should there be IETF consensus around GSPID, obviously it's an identifier that TeRQ would include in the data model.

Jon Peterson
NeuStar, Inc.
________________________________________
From: Richard Shockey [[email-masked]]
Sent: Saturday, March 17, 2012 9:20 AM
To: Peterson, Jon
Cc: [email-masked]; 'Daryl Malas'
Subject: RE: [dispatch] New Proposal for Telephone-Related Queries

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Wednesday, March 14, 2012 6:40 PM
To: Richard Shockey
Cc: [email-masked]; Daryl Malas; Peterson, Jon
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Jon Peterson
NeuStar, Inc.

the

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Mar 2012 14:50:49 -0400

I hear you, but I'd argue that the protocol mechanisms built in to the DNS reflect its intended deployment, and that when we decouple the protocol from that deployment we can run into problems. To give one example from a private ENUM deployment I'm familiar with - there was a use case for multiple administrative entities to be able to provision different records associated with a given telephone number. However, people furthermore wanted to client to be able to see which of the administrative entities providing records was authoritative for the number in question, effectively which was the carrier-of-record vs. inter-exchange carriers or other entities who happened to be able to offer a route to that number. Sounds like a reasonable requirement, but it's clear why the DNS doesn't have any existing mechanism to support it: because the DNS assumes a "golden root" where there is one authority per name rather than a pluralist environment where different authorities provide different resolutions for the same name. That universality of the "golden root" data is also the reason why the DNS doesn't have mechanisms for authenticating clients, as all data is public, and so on. The design of the DNS protocols was defined by the intended deployment.

But your point is a bit different: if people in the real world are using the DNS protocols outside the "golden root," why can't we update the standard protocols to provide the tools that we actually need in these private environments? Broadly, there might be a case to be made that we should, and not just because of ENUM deployments, but a growing set of non-ENUM private DNS usages. It may be that there is enough mindshare behind these deployments to get IETF consensus to extend the DNS protocols in these directions. To get this to become a standard, though, I think the discussion would need to happen in the right venue (not the RAI area) and at the right level. These would be important architectural changes to the DNS protocols, not small, incremental additions to the edges. Going back to my example above, there was a proposal in that private ENUM deployment to overload some of the existing authority flags in the DNS to express that the carrier-of-record provided the record in question. I think this is a good example of an approach the IETF should not standardize, even though the requirement does seem reasonable within that private DNS deployment. I would feel similarly about overloading the transport-negotiation functions of EDNS0 to apply to matters outside of its scope. If we want to extend the DNS to have these capabilities, I don't think we can do in the margins - we need to do it out in the open, in a frank discussion. I think proposals along these lines would face challenges, but I wouldn't rule them out. 

The point of the TeRQ proposal is to get past the questions of encoding these things into the DNS so we can really understand the core semantics. If anything, limiting the requirements to what we can squeeze out of the syntactic margins of the DNS protocols has only made it harder to understand what the real needs are. TeRQ currently proposes, for example, building Authority into the Records that appear in Responses, as deployment experience supports this use case. Maybe having a TeRQ-like model in mind might even make it easier to articulate how the DNS needs to change to support private applications.

Jon Peterson
NeuStar, Inc.
________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Sunday, March 18, 2012 12:52 PM
To: Peterson, Jon
Cc: Daryl Malas; [email-masked]
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

-hadriel

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 20 Mar 2012 01:07:54 +0000

> It faces challenges because the IAB does not distinguish between the *Protocol* of DNS, the *database structure* defined by DNS RFCs, and the *database instance* used for public Domain Name name re…

To which I reply:

Hi Hadriel, Jon, Folks,
 Hadriel, Richard, what are your expected deployment timescales?
IIUC, you need this already, you have a hammer that works, and whilst the data structure is going to be different from ENUM, it surely will blend.

From experience of other sterling work on abstracted task & data models in the IETF, do you believe that TERQ (or any other rigorous analysis) could complete, AND a protocol be selected (or designed from scratch), AND be implemented, AND the distributed data architecture be rolled out within the timescales that your customers are considering?

If it can't, I can't see how this discussion improves on silence.

Either you go ahead with the syntax definitions -- in TXT records (if the way forth for any other RR is blocked) so no need for further standardisation -- or you go ahead with the syntax definitions after a hiatus to consider what those should be, and into what protocol it should be rammed. You get to choose.

all the best,
  Lawrence

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Mar 2012 04:33:31 +0000

If I could answer your second question I'd be retired or earning money with my crystal-ball services.  I generally just use a magic-8-ball to make decisions. :)

The hard part with these things is it's just not as easy as deciding "let's start from scratch".  Most engineers like the opportunity to re-factor code, but we also have to earn a living, and it's always easier to extend existing code so we can make the next opportunity or deadline. (this is not exactly news to anyone here, obviously, and plenty has been written on the topic that extending existing protocols almost always beats out new ones in the marketplace, but just makin' the point)  But who knows - sometimes these things get people excited and enable stuff that couldn't be done before.

So anyway... to answer your first question: in practice we use ENUM/DNS quite a bit, but yes we end up putting stuff in TXT or NAPTRs that should have their own record types for, and for query keys we usually just play games with DNS domain names.  It's ugly as hell in Wireshark, but it generally works. :)  It's not for every use-case, because it doesn't solve world-hunger.  It's meant to address the most common use-cases, with the least-overhead/highest-performance.

But beyond ENUM the only other real player/commonality for "database" access is DIAMETER, afaict, since it's the other hammer for which everything is a nail - at least for large service-providers.  For Enterprises its database protocol soup: from LDAP/ActiveDirectory to Web-APIs to Excel files.

It's definitely true that for real interop the actual attributes/fields/syntax have to be spec'ed, since saying "DIAMETER" is like saying "XML" - without the schema it's meaningless text.  The hard part's gonna be deciding what things are really so important and wide-spread that they need to be spec'ed, vs. what can be ignored or left up to some other SDO/association to define for themselves.

Like for example Jon's carrier-of-record vs. routes authority use-case: I've only ever seen that authority issue/need in one inter-carrier exchange coalition (trying to keep their name anonymous :)  It's probably the one he's referring to.  It's a huge group, of course, but it's really just one "use-case".  Would it be worth it for the IETF to define the syntax+semantics+behavior for DIAMETER AVPs (or whatever) for just their use-case, or could we just let them define whatever they need themselves for their members?  I ask because from a "creating a WG" perspective usually you want some idea the thing can be accomplished and its scope.

The use-case he's referring to isn't crazy, it's just fairly unique I think; but I'm always amazed how crazy some of the information is people want to make routing decisions on.  I mean there's a reason some routing databases use SIP itself as the database lookup protocol (ie, sending them the INVITE and getting back 3xx with routes) - it's because when we ask them what info/fields they need, they say "ALL of them".

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 20 Mar 2012 00:46:41 -0400

If you didn't need all of them, sounds like a candidate for historic
status.  :)

Mike

On Tue, Mar 20, 2012 at 12:33 AM, Hadriel Kaplan <[email-masked]>wrote:

> If I could answer your second question I'd be retired or earning money
> with my crystal-ball services.  I generally just use a magic-8-ball to make
> decisions. :)
>
> The hard part with these things is it's just not as easy as deciding
> "let's start from scratch".  Most engineers like the opportunity to
> re-factor code, but we also have to earn a living, and it's always easier
> to extend existing code so we can make the next opportunity or deadline.
> (this is not exactly news to anyone here, obviously, and plenty has been
> written on the topic that extending existing protocols almost always beats
> out new ones in the marketplace, but just makin' the point)  But who knows
> - sometimes these things get people excited and enable stuff that couldn't
> be done before.
>
> So anyway... to answer your first question: in practice we use ENUM/DNS
> quite a bit, but yes we end up putting stuff in TXT or NAPTRs that should
> have their own record types for, and for query keys we usually just play
> games with DNS domain names.  It's ugly as hell in Wireshark, but it
> generally works. :)  It's not for every use-case, because it doesn't solve
> world-hunger.  It's meant to address the most common use-cases, with the
> least-overhead/highest-performance.
>
> But beyond ENUM the only other real player/commonality for "database"
> access is DIAMETER, afaict, since it's the other hammer for which
> everything is a nail - at least for large service-providers.  For
> Enterprises its database protocol soup: from LDAP/ActiveDirectory to
> Web-APIs to Excel files.
>
> It's definitely true that for real interop the actual
> attributes/fields/syntax have to be spec'ed, since saying "DIAMETER" is
> like saying "XML" - without the schema it's meaningless text.  The hard
> part's gonna be deciding what things are really so important and
> wide-spread that they need to be spec'ed, vs. what can be ignored or left
> up to some other SDO/association to define for themselves.
>
> Like for example Jon's carrier-of-record vs. routes authority use-case:
> I've only ever seen that authority issue/need in one inter-carrier exchange
> coalition (trying to keep their name anonymous :)  It's probably the one
> he's referring to.  It's a huge group, of course, but it's really just one
> "use-case".  Would it be worth it for the IETF to define the
> syntax+semantics+behavior for DIAMETER AVPs (or whatever) for just their
> use-case, or could we just let them define whatever they need themselves
> for their members?  I ask because from a "creating a WG" perspective
> usually you want some idea the thing can be accomplished and its scope.
>
> The use-case he's referring to isn't crazy, it's just fairly unique I
> think; but I'm always amazed how crazy some of the information is people
> want to make routing decisions on.  I mean there's a reason some routing
> databases use SIP itself as the database lookup protocol (ie, sending them
> the INVITE and getting back 3xx with routes) - it's because when we ask
> them what info/fields they need, they say "ALL of them".
>
> -hadriel
>
>
> >> It faces challenges because the IAB does not distinguish between the
> *Protocol* of DNS, the *database structure* defined by DNS RFCs, and the
> *database instance* used for public Domain Name name resolution rooted in
> IANA roots.
> >
> > To which I reply:
> >
> > Hi Hadriel, Jon, Folks,
> > IIUC, you need this already, you have a hammer that works, and whilst
> the data structure is going to be different from ENUM, it surely will blend.
> >
> > From experience of other sterling work on abstracted task & data models
> in the IETF, do you believe that TERQ (or any other rigorous analysis)
> could complete, AND a protocol be selected (or designed from scratch), AND
> be implemented, AND the distributed data architecture be rolled out within
> the timescales that your customers are considering?
> >
> > Either you go ahead with the syntax definitions -- in TXT records (if
> the way forth for any other RR is blocked) so no need for further
> standardisation -- or you go ahead with the syntax definitions after a
> hiatus to consider what those should be, and into what protocol it should
> be rammed. You get to choose.
> >
> > all the best,
> >  Lawrence
> >
> >
> >
> >
> >
>

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 20 Mar 2012 11:30:01 +0000

Hi Mike, folks,
 Hmm ... like RFC2397? No one needs that, so we're told.
They're only using that because they don't understand, or ... "she only does it to annoy, because she knows it teases"
Lawrence

On 20 Mar 2012, at 04:46, Michael Hammer wrote:
> If you didn't need all of them, sounds like a candidate for historic status.  :)
> 
> Mike

<snip>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 20 Mar 2012 16:16:11 -0400

Historic? Hmm. Probably not. I hear of plenty of things people do out in the field with RFC2397. I remember in the early days of Apple's iOS, people were encoding PDFs (even multi-megabyte ones) as data URLs in order to pass them to Safari, since there weren't any PDF readers yet and the iOS URL handler automatically would hand the whole shebang over to Safari. The data URL serves a useful purpose as a hack when your syntax requires a URI but you don't actually want to indicate or locate a resource, you just want to give it as a literal.  That much said, I understand iOS eventually defined some better ways to pass objects between its applications; the data URL hack, while useful, didn't end up being the standard there. I guess I feel similarly about the data URL forming the basis for a standard way to give a literal, rather than indicating or locating a resource, in a NAPTR record. If we want a way to give literals in the DNS, we should adopt something with a crisp enough syntax and semantics that interoperability will be more than just a pipe dream. It is possible that data URLs or derivatives thereof could play a role in that sort of solution, but I suspect that there are superior alternatives.

Anyway, I do share your concerns about timeliness and relevance. These are always concerns whenever we consider a large undertaking. The good news about timeliness is that, as Rich Shockey reminds us, RFC6116 is deployed, and in its deployments it is serving a large market, with a mix of standard and non-standard capabilities. Hopefully that status quo can buy us enough time to take a step back. Relevance-wise, I do think we have a good community in the IETF that is knowledgeable about the needs of the marketplace and would be positioned to jump-start new standards in this space if we manage to come up with something good. We have a reasonable chance of that, provided that when it comes time to do the work, we can avoid rehashing the E2MD arguments (as we are a bit in this thread, I fear) and instead focus on what the semantics of telephone-related queries and responses really should look like.

Jon Peterson
NeuStar, Inc.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lawrence Conroy [[email-masked]]
Sent: Tuesday, March 20, 2012 4:30 AM
To: Michael Hammer
Cc: [email-masked] list
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Hi Mike, folks,

<snip>

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Mar 2012 16:10:40 +0200

I think if we had a working group for Jon's number- routing service that
Plain Old Telephone Service Porting And Numbering, or POTSPAN, might make a
good name.

--
Dean