Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

["Peterson, Jon" <[e-mail]>]

It feels like maybe we’re making progress.

Well, to me it feels like we're regressing into unnecessarily fine questions of definition, but, I'm willing to do that a bit if it helps to move the work forward.


You agreed the MODERN problem statement “needs to better reflect the motivations here”.

You’ve asserted, “the problem is the lack of protocol tools that support allocation, management, and resolution of telephone numbers in the all-IP environments within our scope.”

Some questions about “the problem“ statement you’ve offered.

What are “the motivations here”?

As I'm sure you recall, the discussions that led to this effort were inspired by an FCC workshop which explored some questions about the future of number administration, related to industry trends that the participants perceived. Some of its issues were protocol questions, others weren't. The IETF created a mailing list about it to discuss those protocol questions, and left other questions to other parties to address.


Which protocol “protocol tools” are missing?

Above, you quote me saying the tools that are missing were the ones that support allocation, management and resolution of telephone numbers. I can say it louder if that would help.

Shifting briefly to envisioned solutions, I imagine that these three functions will be accomplished by web services in most cases, in which case what is largely missing to standardize these functions is the information model. If you look at the TeRI draft, you'll at least get a sense of what I think the direction for developing an informational model would be.

I don't think this information is a revelation to anyone reading this list.


What do you mean by “resolution of telephone numbers”?

A successor to ENUM as a protocol, effectively, though one with a richer syntax and semantics, something better aligned with the needs of communications services for both service data and administrative data. Something where you can ask questions about telephone numbers of some sort of service, and receive answers from potentially diverse authorities who authorize you to see responses. More extensible, more like an Internet service.

This is discussed at some length in the problem statement draft, and I don't think it is a particularly confusing concept.


What are “the all-IP environments within our scope”?

The ones I articulated: they run the gamut from traditional Internet telephony services for PSTN replacement, to over-the-top providers, to IP PBXs deployed by enterprises, to services like Google voice, to text-only services and related mobility functions, and the emerging services that we imagine constitute this "IP transition" we're all talking about. It includes some relatively novel approaches that were discussed at the original FCC workshop, like distributed registries. But ultimately, the environment is wherever we use telephone numbers on the Internet, as a communications endpoint identifier or alias.


What is “our scope”?

Is this a repeat from the last question above? Are your next two questions, "What is 'our'?" and "What is 'scope'?"

At a high level, the overall scope is the charter. I understand that you don't support the charter, but I mostly just hear misunderstanding in those conversations, where to me this charter is a simple and crisp protocol development exercise, but people are going out of their way to read it like we're taking on a set of responsibilities for solutions the IETF would never willingly address.


Asserting that protocol tools for ” allocation, management, and resolution of telephone numbers” do not need to be developed with consideration for efficient accountable number space allocation is disingenuous.

The only consideration that the tools need to give in this regard is the necessary security apparatus to enforce policies. What the tools do not need to do is to bake in policy decisions: nothing about the development of a tool that performs the protocol-level authentication of an allocation request needs to understand how or why that request is authorized. This is how the IETF operates. We've developed many tools that support the allocation and assignment of domain names, say, including authorizing how people request and modify domain names, but the tools that perform those functions have nothing to do with how much you get charged for a domain name by whom, or how one makes decisions about who gets which names, or anything like that.

Again, where is the consideration for efficient accountable number space allocation in Google voice? Well, in Google's policy decisions. Not in the web service, or the database interactions - not in the protocol guts that turned into bits on the wire as you requested and received your number allocation. We're doing the protocols, not the policies. That's what the IETF does.

If you see the work here for what it really is, it does not warrant the level of shock and indignation that it mysteriously inspires. It's much less radical than, say, ENUM was when that was chartered.

Jon Peterson
Neustar, Inc.


________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.