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

From: "McGarry, Tom" <[email-masked]>
Date: Thu, 25 Feb 2016 01:18:15 +0000

http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 25 Feb 2016 10:25:35 +0100

The abstract states “While this  focuses on an effort occurring in the USA
the concepts are  applicable to any country.”

I think that it would be better to change that to “This focuses on an effort
occurring in the USA; but the concepts may be applicable to other
countries.”

I say this because non-geographic numbers have already been implemented in
other countries, on the PSTN, without the use of IP-networks, whereas the
Introduction of the draft states that non-geographic numbers “would be
hosted on an all-IP network  of switches called non-geographic gateways
(NGGW), rather than the  existing TDM tandems operated by the incumbent
local exchange  carriers (ILECs).”

Separately, I still wonder whether it is appropriate for the IETF, which is
supposed to be a global entity, to develop a protocol that is apparently of
interest to the USA only.

Best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: jeudi, 25. février 2016 02:18
To: Modern List
Subject: [Modern] Nationwide Number Portability MODERN Use Case Draft

---

From: "McGarry, Tom" <[email-masked]>
Date: Thu, 25 Feb 2016 14:42:23 +0000

The point is, it is a green field numbering space within a country.  These concepts would apply to any green field numbering space.  And it is a use case, it just so happens to be based on a proposal in the USA, it could have been proposed anywhere and it would still be a use case.

From: Richard Hill <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 25, 2016 4:25 AM
To: Tom Mcgarry <[email-masked]<mailto:[email-masked]>>, Modern List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft

The abstract states “While this  focuses on an effort occurring in the USA the concepts are  applicable to any country.”

I think that it would be better to change that to “This focuses on an effort occurring in the USA; but the concepts may be applicable to other countries.”

I say this because non-geographic numbers have already been implemented in other countries, on the PSTN, without the use of IP-networks, whereas the Introduction of the draft states that non-geographic numbers “would be hosted on an all-IP network  of switches called non-geographic gateways (NGGW), rather than the  existing TDM tandems operated by the incumbent local exchange  carriers (ILECs).”

Separately, I still wonder whether it is appropriate for the IETF, which is supposed to be a global entity, to develop a protocol that is apparently of interest to the USA only.

Best,
Richard

http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_id_draft-2Dmcgarry-2Dnnp-2Duse-2Dcase-2D00.txt&d=CwMFAw&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=C87ojdd5_hUQWfib8xKlU0FXTkmHX0tCNueH9vVqeZU&s=lBzvMQsa87DdteOHArI9qLes76icn1SgFe2B7FS4wQE&e=>

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 25 Feb 2016 15:44:59 +0100

Yes, but such a green field space can, and has been, implemented on the
PSTN, so the use of an all IP solution is  not a requirement.  Whereas your
draft implies that it is, unless I misunderstood something.

Best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: jeudi, 25. février 2016 15:42
To: 'Modern List'
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

The point is, it is a green field numbering space within a country.  These
concepts would apply to any green field numbering space.  And it is a use
case, it just so happens to be based on a proposal in the USA, it could have
been proposed anywhere and it would still be a use case.  

From: Richard Hill <[email-masked]>
Date: Thursday, February 25, 2016 4:25 AM
To: Tom Mcgarry <[email-masked]>, Modern List <[email-masked]>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft

Best,

Richard

http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_id_draft-2
Dmcgarry-2Dnnp-2Duse-2Dcase-2D00.txt&d=CwMFAw&c=MOptNlVtIETeDALC_lULrw&r=4Kl
m32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=C87ojdd5_hUQWfib8xKlU0FXTkmHX0tCN
ueH9vVqeZU&s=lBzvMQsa87DdteOHArI9qLes76icn1SgFe2B7FS4wQE&e=>

---

From: "McGarry, Tom" <[email-masked]>
Date: Thu, 25 Feb 2016 14:56:56 +0000

No, it is just one "proposed" solution.

From: Richard Hill <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 25, 2016 9:44 AM
To: Tom Mcgarry <[email-masked]<mailto:[email-masked]>>, Modern List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft

Yes, but such a green field space can, and has been, implemented on the PSTN, so the use of an all IP solution is  not a requirement.  Whereas your draft implies that it is, unless I misunderstood something.

Best,
Richard

Best,
Richard

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 25 Feb 2016 16:27:52 +0000

"One way to enable NNP is to remove the NPAC edit and allow the TN and RN to be in different geographic areas...

It's been reported that a call of this type in certain older technology switches will fail.  If so, then new software would have to be developed for these switches to implement this solution."

I feel like I've been transported back in time to read e-mails offering "technical" reasons why number portability is challenging or impossible.

Can the claim starting, "It's been reported.." be substantiated with a reference?

As an editorial comment, I'll offer I was confused by references to "NXX-NXX".  From the context, I assume you actually meant NPA-NXX.  Do I assume correctly?

I agree with those who question whether the transition to IP drives a need for new number management solutions.

>From my last response to the MODERN "problem statement"...

"The MODERN problem statement is in fact a TN management solution framework.  i.e., a solution looking for a problem.

If there is a problem that MODERN addresses, it is the inability of end users to directly (through a protocol) manage requisition and release of TNs and manage their associated metadata.  This is not a protocol problem.  It is a policy problem (if it is a problem at all).  And the only provisioning protocol I remember seeing referenced in the solution statement is a SIP REGISTER.  In this, MODERN is hardly any different then TRIP and equally useful.

My main recommendation is to scrap the so-called problem statement and start over.  Do not introduce any text that even resembles a solution framework.  The problems can then be easily identified and discussed.  And I encourage discussion of policy as part of the problem so that in the end you can hopefully clearly differentiate between issues that are political and issues which are technical and therefore appropriate for the MODERN WG."

Pierce
From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: February 25, 2016 8:57 AM
To: 'Modern List' <[email-masked]>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Best,
Richard

The abstract states "While this  focuses on an effort occurring in the USA the concepts are  applicable to any country."

I think that it would be better to change that to "This focuses on an effort occurring in the USA; but the concepts may be applicable to other countries."

I say this because non-geographic numbers have already been implemented in other countries, on the PSTN, without the use of IP-networks, whereas the Introduction of the draft states that non-geographic numbers "would be hosted on an all-IP network  of switches called non-geographic gateways (NGGW), rather than the  existing TDM tandems operated by the incumbent local exchange  carriers (ILECs)."

Best,
Richard

________________________________

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.

---

From: "Holmes, David W [CTO]" <[email-masked]>
Date: Thu, 25 Feb 2016 16:45:58 +0000

And that , to quote Mr. Dolly, would require "digging up the graveyards around Indian Hill".  In other words, ain't going to happen.

What we need is an "official" statement from ALU Nokia et al that this is not practical.  But would they make such a statement, effectively to the FCC?

In terms of what is driving this, I'm similarly confused.  Unlike in the case of other work we are doing in PTSC that impacts backwards compatibility (e.g. caller ID spoofing), I don't see a massive public push for this, it would be more of a convenience.  Are there any current issues with interconnection rating for VoIP providers generally, who operate number blocks that they use on a NG basis, but are charged for some kind of LD interconnect when these numbers call others in their geo but which are in another LATA?

From: Modern [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Thursday, February 25, 2016 8:28 AM
To: McGarry, Tom <[email-masked]>; 'Modern List' <[email-masked]>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Pierce
From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: February 25, 2016 8:57 AM
To: 'Modern List' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Best,
Richard

Best,
Richard

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Feb 2016 17:33:10 +0000

<first principles>
While many of the people on this list are concerned exclusively with managing carrier numbering resources, a lot of the inspiration for this effort came from the increasing diversity of players who seem to be allocating and managing numbers outside of the traditional carrier case. That would include enterprises, and OTT VoIP providers, and Internet texting system, things that don't tend to have lots of installed traditional PSTN infrastructure. While I wouldn't go so far as to call it a "massive public push," there are lots of systems today that let users acquire and managing telephone numbers as resources for basically Internet applications. In some cases, even entities we'd recognize as traditional carriers are fielding services that let users allocate and manage multiple telephone numbers as aliases for different household members on one line, or similar functions.

And moreover, we keep hearing that there is some kind of IP transition underway, and that many carrier networks will move permanently to systems that look at least somewhat more like Internet applications. How much they will resemble them, and how quickly we will get there, are matters of debate, sure. But having some protocol tools to perform these functions isn't a particularly far-fetched goal, nor is it particularly a question about policy, nor will it force anyone to adopt anything any faster. It will just enable the services that want these capabilities to deploy them. It is literally only a protocol problem.
</first principles>

>From my perspective, the NNP use case isn't an outlier in terms of what it would require from those protocol mechanisms. I do imagine that a lot of the "native" Internet applications that use telephone numbers benefit from portability, and would benefit more if portability were more flexible: the geographical limitations on portability are an obvious anachronism in our age of mobile phones. If we're going to build these protocol tools, ideally they should be able to handle the range of policy outcomes that we anticipate are coming down the pike. I'm not sure I'd be defining a solution here any differently because of NNP's specific requirements; depending on exactly how it is realized, the information model might admit of a different field here and there, but the information model needs that extensibility anyway. So... the protocol tools will basically accommodate it, if industry and regulators wanted to use them.

Jon Peterson
Neustar, Inc.

From: Modern <[email-masked]<mailto:[email-masked]>> on behalf of "Holmes, David W [CTO]" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 25, 2016 at 8:45 AM
To: "Gorman, Pierce A [CTO]" <[email-masked]<mailto:[email-masked]>>, "McGarry, Tom" <[email-masked]<mailto:[email-masked]>>, 'Modern List' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

And that , to quote Mr. Dolly, would require “digging up the graveyards around Indian Hill”.  In other words, ain’t going to happen.

What we need is an “official” statement from ALU Nokia et al that this is not practical.  But would they make such a statement, effectively to the FCC?

In terms of what is driving this, I’m similarly confused.  Unlike in the case of other work we are doing in PTSC that impacts backwards compatibility (e.g. caller ID spoofing), I don’t see a massive public push for this, it would be more of a convenience.  Are there any current issues with interconnection rating for VoIP providers generally, who operate number blocks that they use on a NG basis, but are charged for some kind of LD interconnect when these numbers call others in their geo but which are in another LATA?

From: Modern [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Thursday, February 25, 2016 8:28 AM
To: McGarry, Tom <[email-masked]<mailto:[email-masked]>>; 'Modern List' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

“One way to enable NNP is to remove the NPAC edit and allow the TN and RN to be in different geographic areas…

It's been reported that a call of this type in certain older technology switches will fail.  If so, then new software would have to be developed for these switches to implement this solution.”

I feel like I’ve been transported back in time to read e-mails offering “technical” reasons why number portability is challenging or impossible.

Can the claim starting, “It’s been reported..” be substantiated with a reference?

As an editorial comment, I’ll offer I was confused by references to “NXX-NXX”.  From the context, I assume you actually meant NPA-NXX.  Do I assume correctly?

>From my last response to the MODERN “problem statement”…

“The MODERN problem statement is in fact a TN management solution framework.  i.e., a solution looking for a problem.

My main recommendation is to scrap the so-called problem statement and start over.  Do not introduce any text that even resembles a solution framework.  The problems can then be easily identified and discussed.  And I encourage discussion of policy as part of the problem so that in the end you can hopefully clearly differentiate between issues that are political and issues which are technical and therefore appropriate for the MODERN WG.”

Pierce

Best,
Richard

Best,
Richard

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 25 Feb 2016 18:01:37 +0000

I didn't say there was no problem for MODERN to solve.  I said that the MODERN "problem statement" was not a problem statement, but instead a solution framework for an undefined problem.

Telephone numbers are owned and assigned first and foremost by national numbering authorities.

The number authorities delegate number blocks to licensed regulated entities which both make individual assignments and further delegate block assignments.  (Very much like RIRs not surprisingly.)

At some point of distribution, delegation presents serious problems for efficient management of address space.  (Anybody remember RFC 1918 and NATs from Hell?)

Any solution framework with proposes non-traditional management of telephone numbers MUST address efficient and accountable assignment.  How is this not a policy issue?

From: Peterson, Jon [mailto:[email-masked]]
Sent: February 25, 2016 11:33 AM
To: Holmes, David W [CTO] <[email-masked]>; Gorman, Pierce A [CTO] <[email-masked]>; McGarry, Tom <[email-masked]>; 'Modern List' <[email-masked]>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

<first principles>

Jon Peterson
Neustar, Inc.

Pierce

Best,
Richard

Best,
Richard

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Feb 2016 18:29:37 +0000

Sure, I'm not saying the problem statement is perfect - it needs to better reflect the motivations here, and hopefully the next iteration of it will do so. But it does in fact identify a problem: 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.

Naturally, delegation begins with the numbering authorities, and nothing we say here suggests otherwise.

We have lots of pretty pictures of number blocks passing from regulators, through carriers, potentially to resellers, and ultimately to end users, and the use cases in the modern-problems document show flows just like that. That is the common case.

However, we wouldn't all be here today if there was not interest, from both regulators and from some companies, in tweaking what sorts of creatures are "licensed regulated entities." The IETF doesn't drive or even influence that decision. In some nationalities, regulators have already issued rulings that qualify entities other than ones we'd traditionally deem "carriers" to be first-class citizens in numbering, to receive their own number blocks allocations. So, we also show that as a use case, because it is, apparently, a reality on the ground. Not the only reality, but something to show as a use case.

Creating protocol tools to support allocating, managing, and resolving telephone numbers on the Internet is not synonymous with a free-for-all that will exhaust the numbering space because I can get a new telephone number every time I send a packet to a web service. If it was, then the first iteration of Google voice (or any number of similar systems that let you log in to a web page and, you know allocate yourself a number) would have destroyed the PSTN, right? The tools have to have foundational security and authorization capabilities that will let authorities at various points in that chain of delegation. Our use cases will elucidate what those requirements are.

I do remember RFC1918, it is one of the IETF's most successful technologies. We aren't suggesting private numbering spaces as a MODERN use case - though now that you mention it, I could imagine one. ..

You mean something different by a "framework" than a protocol framework, and probably something different by "solution" than an RFC. Other bodies will make administrative decisions about how numbering blocks, at a national or carrier or corporate level, will get divvied up and used efficiently. The tools we are generating here are protocol tools that only serve those policy decisions.

Jon Peterson
Neustar, Inc.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 25 Feb 2016 19:08:06 +0000

It feels like maybe we're making progress.

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

Which protocol "protocol tools" are missing?

What do you mean by "resolution of telephone numbers"?

What are "the all-IP environments within our scope"?

What is "our scope"?

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.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Feb 2016 19:48:14 +0000

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.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 25 Feb 2016 15:37:48 -0600

Pierce,  there is a political agenda here that is unclear and very very inappropriate for the IETF to pursue, but Jon doesn’t care.  The IETF does not do policy and all of these requirements are clearly policy driven not to mention North American specific.

I’ve given up trying to explain that National Numbering policy is a Nation State specific task under national law.  Its seems to make no difference to Jon and company that there is no request or requirements from a authoritative NRA for this work. There does seem to be a requirement to disrupt the existing number allocation policy and or reverse the current direction the FCC has taken regarding Local Number Portability Adminstration. They will not take NO for an answer and will pursue their political agenda with all the zeal of a Tea Party convert.  So be it.  They have their sandbox let them play in it.

As we know the realities of the situation may radically change in 9 months. 

We all believe that in the future we could use better tools to manage naming and addressing resources and better tools for the distribution of SIP interconnection data but in the current scheme of things and policy priorities that I’m aware of these issues are far far beyond the radar screen. 

From:  Modern <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date:  Thursday, February 25, 2016 at 12:01 PM
To:  "Peterson, Jon" <[email-masked]>, "Holmes, David W [CTO]" <[email-masked]>, "McGarry, Tom" <[email-masked]>, 'Modern List' <[email-masked]>
Subject:  Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

I didn’t say there was no problem for MODERN to solve.  I said that the MODERN “problem statement” was not a problem statement, but instead a solution framework for an undefined problem.

<first principles>

</first principles>

Jon Peterson

Neustar, Inc.

From: Modern <[email-masked]> on behalf of "Holmes, David W [CTO]" <[email-masked]>
Date: Thursday, February 25, 2016 at 8:45 AM
To: "Gorman, Pierce A [CTO]" <[email-masked]>, "McGarry, Tom" <[email-masked]>, 'Modern List' <[email-masked]>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Pierce

Best,

Richard

Best,

Richard

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Feb 2016 22:10:03 +0000

I think I was very straightforward in my last mail in stating that the discussions leading to this work did begin at a US government meeting. But I don't think the actual problem carved out here is in any sense North American specific, or is in any sense specific to use cases where government policies factor in. The use cases here include examples like, say, Google voice, or like an IP PBX that distributed telephones numbers to its phones, which at least to my understanding aren't laden with policy implications. The work may also have applicability to carriers who might want to manage numbers the ways we're studying, but nothing about the way the IETF approaches standards development could render that anything but a carrier's option.

The suggestion that the IETF is somehow driving policy, or that there is some covert political agenda in the work items that have been proposed, simply isn't consistent with the IETF's powers or scope or ambitions. Far from it.

To the original title and point of this thread, sure, the NNP use case would be a pretty US-specific one. I only chimed in here (originally, anyway) to say I don't think it would cause much course correction to the path laid out by the baseline use cases to include NNP, so I didn't see any harm in it.

We can in fact just skip directly to building better tools to manage naming and addressing resources, if we can get past the contention that this work is something other than what it actually is.

Jon Peterson
Neustar, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 18:01:02 -0500

On 2/25/16 1:01 PM, Gorman, Pierce A [CTO] wrote:

> The number authorities delegate number blocks to licensed regulated
> entities which both make individual assignments and further delegate
> block assignments.  (Very much like RIRs not surprisingly.)

[Disclaimer: I am just a kibitzer here. I have no skin in the game.]

Certainly what you say is the reality. And I am sure that the licensed 
and regulated entities do regard these numbers as *theirs*.

But us end users regard the numbers as *ours*. The fact that we must go, 
hat in hand, to our carrier and beg for any sort of administration of 
that number is a *problem*, not a feature. Anything that will give us 
more control over *our* numbers is a *good* thing!

I have no illusions that the carriers share this opinion. I do hope that 
the FCC does.

	Thanks,
	Paul

---

From: Richard Shockey <[email-masked]>
Date: Fri, 26 Feb 2016 12:47:21 -0500

>and regulated entities do regard these numbers as *theirs*.

RS> Because “they” are forced into a series of extensive regulations on what they can and cannot do with numbers. Bashing traditional carriers is good sport but ignores the reality of how the system was created.  

>I have no illusions that the carriers share this opinion. I do hope that 

RS> There is progress. Non traditional carriers now have access to the numbering plan ( yes even Google voice) directly but even the simplest reform ..National Geographic Number Portability for instance creates a hornets nest of orthogonal issues (rate centers LATA) that have to be resolved before it can be implemented and the rules have to change ( that is a FCC Notice of Proposed Rule Making BTW) and that is a political problem not a issue for the IETF to resolve. Contrary to what Tom says the existing technology can work reasonably well for NG-NP without imposing unreasonable costs on traditional telephony service providers.  Yours truly is living through that little fustercluck right now. 

My contention is still that MODERN is putting the cart before the horse and looks way way to US specific. The proposed use cases are unimplementable given the current set of regulations, the structure of the industry and does not actually solve a real problem.  There is no business case here which I suspect something else is going on.  The real problem is IP interconnection data ( aka NG ENUM) a system distributed synchronized registries is desperately needed NOW and could be widely implemented quickly as a greenfield technology. Once you build on success you can add some of these other use cases as the regulatory structures evolve, which usually takes a decade and endless ex parte filings in the public record.

As it stands now MODERN is trying to build something that no one wants and no carrier will ever implement ( gee sounds like 6116 ). 

This is the exact opposite of the STIR proposition.  STIR is actually addressing a serious international problem where there is ample evidence the regulators and the legislators are desperate for a solution.

Call SpoofingBipartisan Anti-Spoofing Bill Introduced
Sens. Deb Fischer (R-Neb.) and Bill Nelson (D-Fla.) introduced 

http://www.fischer.senate.gov/public/index.cfm/news?ID=F135ABD9-C427-464F-853D-E95509AFA93F

Legislation 

https://prodnet.www.neca.org/publicationsdocs/wwpdf/22216bill.pdf

>
>	Thanks,
>	Paul
>
>_______________________________________________
>Modern mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/modern

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Feb 2016 18:42:42 +0000

>My contention is still that MODERN is putting the cart before the horse
>and looks way way to US specific. The proposed use cases are
>unimplementable given the current set of regulations, the structure of
>the industry and does not actually solve a real problem.  There is no
>business case here which I suspect something else is going on.  The real
>problem is IP interconnection data ( aka NG ENUM) a system distributed
>synchronized registries is desperately needed NOW and could be widely
>implemented quickly as a greenfield technology. Once you build on success
>you can add some of these other use cases as the regulatory structures
>evolve, which usually takes a decade and endless ex parte filings in the
>public record.

A use case where, say, an IP PBX doles out telephone numbers to its phones
is implementable given the current set of regulations and the structure of
the industry. I understand there are some use cases in MODERN's scope for
which that might not be true. But I don't think that poses any actual
difficulties to the industry, to governments, or to specification efforts.
I gather a lot of the drama on this list is people getting spun up about
one or two use cases among many that are inputs to the protocol design. We
need to get some agreement around that, and we should probably spend some
time discussing on the call next week.

That much said, I'm happy to promote use cases more strongly related to IP
interconnection data - we do have a whole retrieval interface for CSP to
CSP call routing. But I still think we need to start with an information
model for the number lifecycle, rather than starting with that retrieval
protocol, because of the historical problems I recall trying to align ENUM
with subsequent provisioning efforts like DRINKS - I want to understand
the way that numbers enter the IP infrastructure so that we know how to
create, provision, and query for numbers based on a common set of data,
rather than defining a narrow set of data for queries, and only later
realizing it isn't aligned with the data we want to provision against
numbers, say.

>As it stands now MODERN is trying to build something that no one wants
>and no carrier will ever implement ( gee sounds like 6116 ).

Even if no "carrier" ever implements MODERN, it could still be a success
within its scope. Its scope is indeed the question of what sorts of tools
people who aren't traditional owners of numbering resources might need, or
what the needs will be after the much-vaunted IP transition.

I understand that grouping things like number portability in with MODERN
use cases gives it the appearance of being a play towards the carrier
market. But from my perspective, number portability, and the emerging
directions of numbering portability, are things MODERN has to support -
"solving" those questions about number portability isn't in the scope of
the group, but a system for managing number life cycles has to be able to
use numbers that are portable, in the sense they are portable now and in
the sense they are likely to be portable in the future.

> 
>This is the exact opposite of the STIR proposition.  STIR is actually
>addressing a serious international problem where there is ample evidence
>the regulators and the legislators are desperate for a solution.

But STIR builds on a lot of work we've been doing over the past decade,
not all of which we anticipated would fit into this problem space.
Sometimes at the IETF, we work in directions that we think the industry is
going, building protocol infrastructure that looks like the right set of
foundational tools to address problems that are necessarily moving
targets. MODERN has been, from the FCC discussion on, intentionally a
forward-looking venture, trying to get ahead of changes we see playing
out. It's okay if our predictions don't exactly agree, and even if we
don't turn out to be exactly right. As long as we focus on building
general tools that we think will be useful in the future environments we
think are likely to emerge, it will have been worth the effort.

Jon Peterson
Neustar, Inc.

---

From: Eric Burger <[email-masked]>
Date: Mon, 29 Feb 2016 12:53:51 -0500

With humor and horror I’ve been reading the “Nationwide Number Portability MODERN Use Case” email thread.

My interpretation is there are a bunch of people who say there is a real problem with real stakeholders with real solutions. There is another bunch of people who say there is no problem, no one cares, and even if you had a solution it would be illegal to use in most jurisdictions.

How about this: I know it is a bit backwards, but can we pause the Problem Statement work, as we have a bunch of people saying that whatever anyone writes about as a Problem is “not a problem”? Instead, perhaps if someone who says there is a Problem and it can have an IETF-relevant solution can present the Problem and Solution?

People who think there is no Problem: PLEASE don’t jump up and down asking for requirements - just please sit back and read the Problem and Solution. Expand your mind and see if there is something for the IETF to work on here.

People who think there is a Problem: PLEASE listen to the folks on the “other side” and try to tease out what they are saying and, taking that into account, determine if there is something that the IETF (or ATIS or ETSI or the ITU-T) should be working on.

Thanks.

P.S., thanks for scheduling the interim for when I will be on an airplane heading towards middle America :-( Not.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 29 Feb 2016 18:42:41 +0000

I at least am guilty of providing both a problem and a solution already:
the problem is the problem statement (now in -03! Available in fine I-D
repositories everywhere!) and a solution, in the form of
draft-peterson-modern-teri-00. Which should remind us a bit of how the
solution came about: from TeRQ, which was a homeless proposal that became
a topic of interest in the much-storied FCC workshop that inspired this
working group. TeRQ was just an attempt to isolate and identify the
information model we'd want to have to send queries about numbers on the
Internet, though upon closer examination, that endeavor was too tangled up
in questions of what information model we'd need for provisioning or
acquisition numbers for it to be considered in isolation. All of the
MODERN problems and frameworks fell out of that, and that's the problem I
for one am trying to solve.

We'll miss you tomorrow, Eric - well, given the call is at 8AM my time, I
won't be awake enough to do much missing.

Jon Peterson
Neustar, Inc.

On 2/29/16, 9:53 AM, "Modern on behalf of Eric Burger"
<[email-masked] on behalf of [email-masked]> wrote:

>With humor and horror I¹ve been reading the ³Nationwide Number
>Portability MODERN Use Case² email thread.
>
>My interpretation is there are a bunch of people who say there is a real
>problem with real stakeholders with real solutions. There is another
>bunch of people who say there is no problem, no one cares, and even if
>you had a solution it would be illegal to use in most jurisdictions.
>
>How about this: I know it is a bit backwards, but can we pause the
>Problem Statement work, as we have a bunch of people saying that whatever
>anyone writes about as a Problem is ³not a problem²? Instead, perhaps if
>someone who says there is a Problem and it can have an IETF-relevant
>solution can present the Problem and Solution?
>
>People who think there is no Problem: PLEASE don¹t jump up and down
>asking for requirements - just please sit back and read the Problem and
>Solution. Expand your mind and see if there is something for the IETF to
>work on here.
>
>People who think there is a Problem: PLEASE listen to the folks on the
>³other side² and try to tease out what they are saying and, taking that
>into account, determine if there is something that the IETF (or ATIS or
>ETSI or the ITU-T) should be working on.
>
>Thanks.
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 29 Feb 2016 19:31:47 +0000

Paul,

As an employee of a carrier it dismays me to read that you feel you have to beg "hat in hand" for a telephone number from a carrier.  Speaking for myself, my feeling is my colleagues and I do the best we know how for our customers and strive to always keep their needs uppermost in our concerns.  (Not kidding.)

My experience has been few people inside a telephone company actually think telephone numbers are valuable.  The folks I can tell who do clearly see a value in telephone numbers are the operators of the number management systems such as LERG and NPAC who literally have millions of reasons to think so.   :-)

The point I apparently failed to make was that managing finite addressing data such as IP addresses and telephone numbers requires the ability to meaningfully audit their usage to make sure they're not "wasted" (or not wasted too much).  The more distributed the delegation of that name space, the more difficult it is in the real-world to successfully manage that finite address information.

I don't have heartburn with individuals getting telephone numbers.  How could I?  I do have heartburn with the idea of administrators having little to no control over how individuals got those numbers, whether they're using them, and recovering them if they are not.  In the case of registered Internet addresses, the "hat in hand" situation exists too for the very same reasons I'm concerned about.

The proponents of the MODERN solution framework seem to want to ignore these very real practical issues and give vague hand waves that these questions are "a matter of policy" beyond the scope of the MODERN protocol tool development.  Having been a call routing information database developer at one point, my inclination is to call BS on that response.

I have challenged myself to see the problems the proponents of MODERN do, but it has been difficult.  The only thing I can clearly see that has been proposed that is materially different from what our current solutions for telephone number management provide is the individual "agent" assignment, and as I mentioned above this scares me as I feel this is a very slippery slope decending into chaos.  And I've struggled to understand how not having that ability harms the public or individuals.  There don't seem to be obvious use cases which scream, "Give individuals the ability to make assignments, or give me death!"

So I've wondered, who are we harming?  If we are harming someone, how can we help them while also acknowledging that delegating telephone number name space assignment to hundreds of millions or billions of individuals means certain loss of credible ability to manage the finite resource?

I can't claim to have had an epiphany but it does occur to me that perhaps there is a solution based on SIP user@host URIs and domain names of the form "first-last.name" which does not require a new set of telephone number management protocol tools (yet?).  There are no restrictions on the ".name" top-level domain and it was specifically created to permit assignment of domains for individuals but also permits domains for groups of individuals such as kyzivat.name.

Wireless and cable carriers are moving inexhorably towards the IP Multimedia Subsystem (IMS) developed by 3GPP (and enhanced/modified by ETSI, Cable Labs, et al).  The 3GPP IMS specs embrace the idea of both public and private identities.  The ETSI enhancements have been particularly focused on wireline convergence on an IMS signaling and media architecture.

It seems reasonable that an IMS public user identity might be paul-kyzivat.name and which could be used as a user@host format in a SIP URI either as [email-masked] (where Paul Kyzivat has presumably created his own individual private "carrier" so to speak) or as [email-masked] where the paul-kyzivat.name user name is associated with a hosted SIP service through carrier-name.com.

I won't try to write much more beyond this other than to say that if the core of the MODERN "problem statement" is individual assignment, then there may be solutions or solution frameworks which are superior to the MODERN solution framework variations so far advanced.

Make sense?

Pierce

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: February 25, 2016 5:01 PM
To: [email-masked]
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Certainly what you say is the reality. And I am sure that the licensed and regulated entities do regard these numbers as *theirs*.

But us end users regard the numbers as *ours*. The fact that we must go, hat in hand, to our carrier and beg for any sort of administration of that number is a *problem*, not a feature. Anything that will give us more control over *our* numbers is a *good* thing!

I have no illusions that the carriers share this opinion. I do hope that the FCC does.

Thanks,
Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 29 Feb 2016 21:24:14 +0000

Slightly reordering some points here...

>I have challenged myself to see the problems the proponents of MODERN do,
>but it has been difficult.  The only thing I can clearly see that has
>been proposed that is materially different from what our current
>solutions for telephone number management provide is the individual
>"agent" assignment, and as I mentioned above this scares me as I feel
>this is a very slippery slope decending into chaos.  And I've struggled
>to understand how not having that ability harms the public or
>individuals.  There don't seem to be obvious use cases which scream,
>"Give individuals the ability to make assignments, or give me death!"

If you want to look at this the way the proponents of MODERN do, then you
need to see it as if the problem is that the on-the-wire protocols that
exist for current solutions are inadequate - which is literally the only
type of problem that the IETF can or should solve. You say that (apart
from one use case) nothing proposed here is "materially different from
what our current solutions for telephone number management provide," but I
see things very differently. What is materially different is that we
propose to use a different information model and different accessor
protocols to handle the data associated with these solutions. That's the
change that MODERN proposes and the work the charter sets for us.

The idea here is to take particular protocols used in the solutions -
like, say, ENUM - and replace them with new protocols that we think are
better aligned with the actually needs of those solutions - like, for
example, TeRQ, now a component of TeRI. Sure, I mean, those two protocols
solve the same problem from a bird's eye view, but in depth they're
actually really different. The IETF's responsibility begins and ends with
such protocol design questions.

We proposed MODERN in part because of some of the other protocol
approaches we've tried that didn't work as well as we thought, on the
retrieval and management side. And additionally, in part we want to enable
some new functionality with these more flexible information models and
mechanisms. When I look at the problem statement, I see sixteen different
use cases. One of them, 4.1.5, shows a user getting their own telephone
numbers from a registry. But there are other "new functionality" problems
being addressed here: like say how an enterprise distributed numbers to IP
phones. You can't say there's no problem here just because you object to
one of the sixteen use cases.
 
>I don't have heartburn with individuals getting telephone numbers.  How
>could I?  I do have heartburn with the idea of administrators having
>little to no control over how individuals got those numbers, whether
>they're using them, and recovering them if they are not.  In the case of
>registered Internet addresses, the "hat in hand" situation exists too for
>the very same reasons I'm concerned about.

I get that your objection to this use case isn't to the fundamental idea
that individuals could get their own numbers, but instead to what you see
as the lack of control that administrators might have over those
allocations. You see this as analogous to the first-come first-serve IP
address block allocations that led to scarcity.

But again, no one thinks the IETF should be responsible for the policies
that decide who gets a /16, and who has to get their IP addresses from an
ISP. Instead, we design protocols that use IP addresses. If the IETF could
not design a protocol like DHCP, say, without specifying under what
circumstances you acquire address space and grant IPv4 addresses leases,
well, the industry would simply ignore our guidance and do what business
incentives lead them to do anyway. It's our job to provide the protocol
tools necessary to enforce those policies, not set the policies themselves.

>The proponents of the MODERN solution framework seem to want to ignore
>these very real practical issues and give vague hand waves that these
>questions are "a matter of policy" beyond the scope of the MODERN
>protocol tool development.  Having been a call routing information
>database developer at one point, my inclination is to call BS on that
>response.

A protocol design is not where policy resides. The protocol instead needs
to have hooks that will enable policy to be enforced. Those are security
mechanisms, largely, and MODERN will have them. There will be a way for
the various entities that assign or delegate telephone numbers to
authenticate who is asking, to get contact and administrative data, to
manage service data even. But the protocol is not the place to say under
what conditions an assignment should take place or when it should be
revoked - that's up to the assigner, as it should be. (And again,
assignment is only one of the things under consideration here.)

A couple times now in this thread I have mentioned that Google has a
service that lets users visit a web page and get telephone numbers for
find-me-follow-me sorts of services and control logic. There are numerous
other examples I could give of Internet services that let you sign up and
get telephone numbers today. Are those all systems where administrators
"have little to no control over how individuals got those numbers?" Have
they resulted in telephone number scarcity because they just let
individuals get their own numbers? No.

To understand your perspective better, I'd need to grasp why such deployed
systems don't prove your concerns here to be nothing more than FUD. Of
course, Google could have implemented this service in an insane,
first-come first-serve basis where someone with an automated tool exhausts
their entire telephone number allocation instantly. They don't need any
help the IETF to do so. Our protocol tools will be neutral to
administrative choices. As with any other resource, someone outside the
IETF, at a business or regulatory level, will be making decisions about
assignment and delegation, and we are not the protocol police out to boss
them around, we just assume they are generally sane and that the things we
build might help them.

>I can't claim to have had an epiphany but it does occur to me that
>perhaps there is a solution based on SIP user@host URIs and domain names
>of the form "first-last.name" which does not require a new set of
>telephone number management protocol tools (yet?).  There are no
>restrictions on the ".name" top-level domain and it was specifically
>created to permit assignment of domains for individuals but also permits
>domains for groups of individuals such as kyzivat.name.

Back when we wrote SIP, in the early 2000s, we didn't anticipate we'd
still be talking about telephone numbers more than decade later. I think
we all expected that we were beginning a transition to greenfield
identifiers of roughly the form you propose here. It never happened. It
would solve a lot of our problems if it did. But as long as telephone
numbers remain a pervasive communications identifier, we need to address
their acquisition, management, and retrieval on the Internet.

Jon Peterson
Neustar, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 16:50:32 -0500

Pierce,

> As an employee of a carrier it dismays me to read that you feel you have to beg "hat in hand" for a telephone number from a carrier.  Speaking for myself, my feeling is my colleagues and I do the b…

It isn't that I have to beg for a number. I have choices of carriers who 
are happy to *rent* one to me. But the cost to rent the *number* is 
conflated with purchasing services tied to that number. If I won't need 
services for awhile I still have to pay for them to hold on to the 
number until later when I will need it again.

This all would make sense if the number was an opaque key that nobody 
gets attached to. (Like an IP address.) But it isn't.

I thought that public ENUM would be a great thing for end users. 
Unfortunately it didn't end up that way.

> My experience has been few people inside a telephone company actually think telephone numbers are valuable.  The folks I can tell who do clearly see a value in telephone numbers are the operators o…

As an end user I don't have visibility into that distinction. I only see 
the carrier.

> The point I apparently failed to make was that managing finite addressing data such as IP addresses and telephone numbers requires the ability to meaningfully audit their usage to make sure they're…

Well, a traditional answer to scarce resources is to put a price on 
them. If people rented numbers independently of services, then the price 
of numbers could float with demand.

That might also motivate migrating to variable length numbers in order 
to alleviate the shortage, with shorter numbers being more valuable.

> I don't have heartburn with individuals getting telephone numbers.  How could I?  I do have heartburn with the idea of administrators having little to no control over how individuals got those numb…

An enterprise might have good reason to want a block of numbers, even 
though it doesn't have an immediate need for them all. Why should the 
carrier be the one to decide if that is appropriate usage or not?

> I have challenged myself to see the problems the proponents of MODERN do, but it has been difficult.  The only thing I can clearly see that has been proposed that is materially different from what…

Note that I don't purport to be consistent with what the active 
proponents of this work do.

> It seems reasonable that an IMS public user identity might be paul-kyzivat.name and which could be used as a user@host format in a SIP URI either as [email-masked] (where Paul Kyzivat has presumabl…

All you need to do is look to the design of sip, which fits much better 
with email-style URLs than phone numbers, to see that this was a vision 
from way back. It hasn't happened yet. It may yet happen. But your 
specific suggestion works a lot better for paul-kyzivat than it does for 
john-smith. :-) At the end of the day friendly names are also a scarce 
resource. So *somebody* still needs to ration them in some way. But 
frankly I would rather it not be my carrier who does it.

Why can't I attach any sip URL I "own" (my preference being 
sip:[email-masked]) to my phone number and have calls to it 
routed through the carriers to my phone?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Feb 2016 21:53:05 +0000

Like Jon, I continue to be a bit perplexed by the focus on "individuals getting numbers like .com domain names" case as if that was the motivating use case. To add one more example:

For DNS, we have TLDs that are extremely restrictive and others that, by policy choice, only require a credit card number. (For example, the new .bank gTLD apparently is restricted to financial institutions.) All of them presumably use EPP, without EPP having to worry (or even talk about) whether this is .com or .bank.

Even within the same numbering space, policies differ - assigning numbers from a block within an enterprise vs. to an enterprise.

Number assignment to individual entities exists today, more or less, in the 800# space, and I suspect it could teach everyone valuable lessons, but on the policy side, not the protocol side.

If there are protocol features that can help ensure traceability, I think this is a useful discussion to have.

Henning

________________________________________
From: Modern <[email-masked]> on behalf of Peterson, Jon <[email-masked]>
Sent: Monday, February 29, 2016 4:24 PM
To: Gorman, Pierce A [CTO]; Paul Kyzivat; [email-masked]
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Jon Peterson
Neustar, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Feb 2016 22:14:22 +0000

I would have thought that the discussion about the LNP contract, foreshadowing in its acrimony and cost the current presidential contest (you pick the party...), would provide carriers with some incentive for more flexibility.

I'm not sure why you consider the effort "US centric". I suspect almost all countries will be faced with the IP transition and, in particular, with upgrading the existing number portability system, if they have one, or creating one. The current number portability (whether or not it's geographic) leaves much to be desired, as recent events (https://www.fcc.gov/document/fcc-plans-296-million-fine-slamming-cramming-and-obstruction-0 makes a good read) illustrate.

Collectively, we don't do well with tech predictions. (Speaking from some experience, none of the VoIP protocols were on anybody's "gap list.") Sometimes protocols that everybody thought we needed fail to find use, sometimes they make unexpected experiences (RSVP-TE comes to mind). But having an open protocol is invariably better than winging it or letting lawyers design it. 

One important test case is whether the MODERN proposals can implement the current industry structure, in both the geographic and 800# space. If not, there's clearly a gap. Thus, maybe you can help point out the specific features that would need to be supported to implement a version of today's policies, possibly with more formal down-delegation to facilitate tracking, and possibly multiple "registrars", as exists today in the 800# space. (As you know, today we often don't have a good idea of who is actually using a number, given informal "delegation" and reselling-that-doesn't-dare-call-itself-that.)

Henning

________________________________________
From: Modern <[email-masked]> on behalf of Richard Shockey <[email-masked]>
Sent: Friday, February 26, 2016 12:47 PM
To: Paul Kyzivat; 'Modern List'
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Legislation

---

From: Richard Shockey <[email-masked]>
Date: Mon, 29 Feb 2016 17:50:38 -0500

In line. 
— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

On 2/26/16, 1:42 PM, "Modern on behalf of Peterson, Jon" <[email-masked] on behalf of [email-masked]> wrote:

>which that might not be true. 

RS> Oh Jon .. Interesting use case but I do not want to go into the appalling lack of interest among Unified Communications vendors for anything that looked like SIP user agent config.  Been there done that. The SIP Forum tried endless times to construct a profile for UC config based on TFTP based on IR (something something)  and it went no where.  Mary Barnes knows the sad tale here better than I. First the vendors want lock in to their platforms second the market has already shifted to a SIP hosted model vs PBX. I’m very happy with my Broadsoft stock. Carriers win once again. I couldn’t even get the UC vendors to look into point to point video calling using E.164 even with large scale carrier interest in North America. 

>But I don't think that poses any actual

RS> Well what did you expect?  If this WG becomes the SIP/IMS Service Provider Bashing Task Force. ( where is Hadriel when I need him) what did you think would happen. 

>CSP call routing. 

RS> Well I knew we had to agree on something sometime. The use case here is very very real because the current system in the US Canada is simply insane and everyone knows it.

http://www.sipforum.org/content/view/427/171/

Look very carefully at the IP interconnection routing report we produced. The industry agreed to disagree because the tools are just not there and I’m the first one to admit 6116 ENUM is simply not up to the task.  Technology changes.  

>But I still think we need to start with an information

RS> I’m still not convinced the approach to the problem is correct.  You have done a superb job obfuscating the core problem from the path to a solution.  How phone numbers allocated in the first place is not a problem and neither is NG-NP.  Those are political issues and if you want to solve those I can give you a list of highly motivated telecom lawyers here in DC that would be happy to assist in a decade long struggle to change the system and put their kids through college and finance multiple european vacations, boats, vacation homes etc.  Introducing a new technology for number administration is a good idea but tactically and financially the number allocation issue is not the one that would gain industry traction in the short term . 

>what the needs will be after the much-vaunted IP transition.

RS> Fair enough. My ultimate point is that the work should focus on building on the concept of distributed synchronized registries begun in PAWS to extend the concept to metadata as the business case arises.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 29 Feb 2016 23:10:01 +0000

I'm amazed how much my e-mail responding to Paul inspired you to write so much.  You shouldn't have.  Really.

Pierce
-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: February 29, 2016 3:24 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

>I have challenged myself to see the problems the proponents of MODERN
>do, but it has been difficult.  The only thing I can clearly see that
>has been proposed that is materially different from what our current

If you want to look at this the way the proponents of MODERN do, then you need to see it as if the problem is that the on-the-wire protocols that exist for current solutions are inadequate - which is literally the only type of problem that the IETF can or should solve. You say that (apart from one use case) nothing proposed here is "materially different from what our current solutions for telephone number management provide," but I see things very differently. What is materially different is that we propose to use a different information model and different accessor protocols to handle the data associated with these solutions. That's the change that MODERN proposes and the work the charter sets for us.

The idea here is to take particular protocols used in the solutions - like, say, ENUM - and replace them with new protocols that we think are better aligned with the actually needs of those solutions - like, for example, TeRQ, now a component of TeRI. Sure, I mean, those two protocols solve the same problem from a bird's eye view, but in depth they're actually really different. The IETF's responsibility begins and ends with such protocol design questions.

We proposed MODERN in part because of some of the other protocol approaches we've tried that didn't work as well as we thought, on the retrieval and management side. And additionally, in part we want to enable some new functionality with these more flexible information models and mechanisms. When I look at the problem statement, I see sixteen different use cases. One of them, 4.1.5, shows a user getting their own telephone numbers from a registry. But there are other "new functionality" problems being addressed here: like say how an enterprise distributed numbers to IP phones. You can't say there's no problem here just because you object to one of the sixteen use cases.

>they're using them, and recovering them if they are not.  In the case
>of registered Internet addresses, the "hat in hand" situation exists
>too for the very same reasons I'm concerned about.

I get that your objection to this use case isn't to the fundamental idea that individuals could get their own numbers, but instead to what you see as the lack of control that administrators might have over those allocations. You see this as analogous to the first-come first-serve IP address block allocations that led to scarcity.

But again, no one thinks the IETF should be responsible for the policies that decide who gets a /16, and who has to get their IP addresses from an ISP. Instead, we design protocols that use IP addresses. If the IETF could not design a protocol like DHCP, say, without specifying under what circumstances you acquire address space and grant IPv4 addresses leases, well, the industry would simply ignore our guidance and do what business incentives lead them to do anyway. It's our job to provide the protocol tools necessary to enforce those policies, not set the policies themselves.

>database developer at one point, my inclination is to call BS on that

A protocol design is not where policy resides. The protocol instead needs to have hooks that will enable policy to be enforced. Those are security mechanisms, largely, and MODERN will have them. There will be a way for the various entities that assign or delegate telephone numbers to authenticate who is asking, to get contact and administrative data, to manage service data even. But the protocol is not the place to say under what conditions an assignment should take place or when it should be revoked - that's up to the assigner, as it should be. (And again, assignment is only one of the things under consideration here.)

A couple times now in this thread I have mentioned that Google has a service that lets users visit a web page and get telephone numbers for find-me-follow-me sorts of services and control logic. There are numerous other examples I could give of Internet services that let you sign up and get telephone numbers today. Are those all systems where administrators "have little to no control over how individuals got those numbers?" Have they resulted in telephone number scarcity because they just let individuals get their own numbers? No.

To understand your perspective better, I'd need to grasp why such deployed systems don't prove your concerns here to be nothing more than FUD. Of course, Google could have implemented this service in an insane, first-come first-serve basis where someone with an automated tool exhausts their entire telephone number allocation instantly. They don't need any help the IETF to do so. Our protocol tools will be neutral to administrative choices. As with any other resource, someone outside the IETF, at a business or regulatory level, will be making decisions about assignment and delegation, and we are not the protocol police out to boss them around, we just assume they are generally sane and that the things we build might help them.

>perhaps there is a solution based on SIP user@host URIs and domain
>names of the form "first-last.name" which does not require a new set of
>created to permit assignment of domains for individuals but also
>permits domains for groups of individuals such as kyzivat.name.

Back when we wrote SIP, in the early 2000s, we didn't anticipate we'd still be talking about telephone numbers more than decade later. I think we all expected that we were beginning a transition to greenfield identifiers of roughly the form you propose here. It never happened. It would solve a lot of our problems if it did. But as long as telephone numbers remain a pervasive communications identifier, we need to address their acquisition, management, and retrieval on the Internet.

Jon Peterson
Neustar, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Feb 2016 23:15:24 +0000

I'll only address the horse-cart comment: From my experience, in telecom, the horse and cart roles are often hard to predict. My experience has been that technology availability drives policy choices. To pick something outside the MODERN realm, availability of GPS and base station triangulation (even if early and in need of refinement at the time) made it possible for the FCC and others to consider 911 location mandates.

The most common (and justifiable) objection of entities to any regulatory initiative is that the technology isn't available. Plus, the timelines of many decision, including such things as contracts, are sufficiently short compared to the typical IETF timelines (I suspect the average term of FCC chairmen is below that of many IETF BOF-to-RFC cycles...) that you can't just start standards work just-in-time when the need arises. (Richard is well familiar with the VRS birthing pains in this area, despite being a very small industry exclusively funded by ratepayer dollars.)

Not to put too fine a point on this: The current LNP cycle is five years. It would be nice to be able to offer plausible technical alternatives to relevant parties before we re-enact the same play, with different actors, but the same sword fighting scenes. And this assumes that *nothing* changes as to who can get numbers. We may still end up in replay mode  (well above my pay-grade), but it's really hard to do this kind of technical work if an RFP is on the street or an active rule making is in progress.  (You really don't want to worry about having to file an ex-parte for every Internet Draft...) 

Same for any attempt to reform the 800# allocation process or to add more accountability to CNAM.

The range of policy options, in broad outline, are reasonably well-known, with NANC FON, ATIS and others having explored them at length in the past decade. We wouldn't want to model a particular national set of rules anyway, for all the reasons Richard has mentioned. If there's a plausible broad policy option that can't be met by a proposal, that's a useful discussion to have, but that discussion is best had, in my view, with as much specific detail as possible, rather than general philosophy statements. Thus, "proposal X can't support model Y" is useful; "I don't like model Y" seems less so.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Feb 2016 23:30:35 +0000

My understanding (and the use cases draft may need clarity on that) is that the two facets are largely independent. In other words, you should be able to run a TDM network with step switches and allocate numbers via an IP-based process, even if you may have to use a dial-up modem to get your IP packets. (As far as I know, the current US-specific number management and porting process is based, in part, on Internet protocols, just a bit on the dated side.)

I think suggestions on removing US-specific language are useful. As discussed in this thread, I do see six broad challenges that apply, in combinations in many jurisdictions:

(1) IP transition

(2) porting (either newly-introduced or with new capabilities, e.g., between different modes or geographies), possibly with mechanisms other than voice-based validation of porting intent

(3) automation for multiple levels of delegation, whether for PBX or some IOT applications

(4) accountability of both holdership and "meta" data (CNAM)

(5) improved number utilization, with more "just-in-time" processes

(6) more flexibility in the number and structure of registrars/registries (including, for small countries, outsourcing to third parties rather than creating technology specific to Liechtenstein)

My sense is that the US is facing more of these challenges than many countries at this point, but they don't seem US-specific. This is not new - TV whitespaces and emergency caller location for wireless were initially largely US problems, too.

Henning
________________________________
From: Modern <[email-masked]> on behalf of Richard Hill <[email-masked]>
Sent: Thursday, February 25, 2016 9:44 AM
To: 'McGarry, Tom'; 'Modern List'
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Best,

Richard

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 29 Feb 2016 23:38:08 +0000

Henning

Please expand on (3)

Thank you

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: [email-masked]<mailto:[email-masked]>

On Feb 29, 2016, at 6:30 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

(1) IP transition

Henning
From: Modern <[email-masked]<mailto:[email-masked]>> on behalf of Richard Hill <[email-masked]<mailto:[email-masked]>>

Best,

Richard

_______________________________________________
Modern mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/modern

---

From: Richard Shockey <[email-masked]>
Date: Mon, 29 Feb 2016 18:32:59 -0500

>I would have thought that the discussion about the LNP contract, foreshadowing in its acrimony and cost the current presidential contest (you pick the party...), would provide carriers with some inc…

RS> It may be but it has to be balanced with the realities of the cost issue.  Shockey’s law “Money is the answer ..what is the question?”  TN allocation and management systems are deeply intrenched in the service activation systems within carriers. These OSS/BSS systems are terribly expensive and modifying them is an even more expensive proposition.  The general industry view is “If it aint broke, why do we need to fix it” given the overall CAPEX issues telecom carriers face in a era of rapidly declining over voice revenues. 

“What does this buy us?” 

Which is again the opposite of the STIR use case.. The trust model for calls is definitely broken and there is consensus that a solution is desperately needed now. Which is my point on IP interconnection data. The current system is insane and everyone knows has to be fixed. I certainly think there is progress there and the protocol could be wrapped up this year if Jon can make his drafts legible and we can see some actual examples how the INVITE’s actually look in practice. 

I just don’t see any support in the numbering community right on the allocation or NP use case especially among the industry advisory committees. Its just not a problem that needs fixing.  NG-NP is a problem now for perfectly ligitmate competitive issues that Congress has identified and informed the Commission of in no uncertain terms. The Chairman has made his views perfectly clear and the NANC, among others will work the issue in the usual manner. It may take 5-7 years but that is the reality but we can increase the size of the NANP by 20% as you well know.  

The last piece of the puzzle is one we are starting to debate in our NNI TF which is how validation data would displayed on user agents.  There are multiple approaches to the problem and multiple means of transport. What works for VoLTE, or enterprises is not what would work for cable. And there is not very much we can do for TDM networks. The issue is where can the carrier stuff the data into the INVITE as it touches the UA.   My preference is for some extension to the CALL-INFO header but in any event 3GPP is starting to look at that in SA-3 and I think we need to see where that work is going first. 

>I'm not sure why you consider the effort "US centric". I suspect almost all countries will be faced with the IP transition and, in particular, with upgrading the existing number portability system,…

RS> Well the US system for NP, is not perfect its a heck of a lot better that what I see globally, I grant that. Take the case of the UK. First the last time they had to revise the numbering plan for +44 it took out a Minister or two and every time the subject of LNP comes up our mutual friends on the Embankment run for the hills. I still have problems undertaking work where the actual user community has not weighed in on requirements. I’d feel a lot better if there was some input from BEREC for instance.

http://berec.europa.eu/

>Collectively, we don't do well with tech predictions. (Speaking from some experience, none of the VoIP protocols were on anybody's "gap list.") Sometimes protocols that everybody thought we needed f…

RS> MIME? :-) 

>One important test case is whether the MODERN proposals can implement the current industry structure, in both the geographic and 800# space. If not, there's clearly a gap. Thus, maybe you can help p…

RS> Well you will get NO argument from me about the 800 toll free numbering problem.  That has been a festering sore in North America for eons.  If MODERN would focus on that application alone it would be worth the effort and again be a useful means to insert the technology into the industry.  My concerns are at cost to the industry first and tactically second.   My point is that MODERN would be a wasted effort if the focus centered on a use case on one wants and no one would implement driven by some political desire to undercut the structure of telephone naming and addressing in order to beat up on the carriers or promote some companies existing or future business models.  I have enough arrows in my back from the ENUM wars to speak with some authority here.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Feb 2016 23:53:54 +0000

NRA delegates to registry (LNP, NANPA, etc.); registry delegates to carrier; carrier loans/assigns/delegates (whatever the legal arrangement is; substitute your favorite term) to some value-added service provider; VASP assigns to GM and GM assigns number to car. This is the IOT case.

Or GM  assigns numbers from its "supply" to factory in Kokomo, IN; Delco plant assigns to PBX extensions.

All of this should happen without having to employ a number manager to log into a web site, submit a file via ftp or send a fax.

Does that make sense?

Henning

________________________________
From: DOLLY, MARTIN C <[email-masked]>
Sent: Monday, February 29, 2016 6:38 PM
To: Henning Schulzrinne
Cc: Richard Hill; McGarry, Tom; Modern List
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

Henning

Please expand on (3)

Thank you

Martin C Dolly

(1) IP transition

Henning

Best,

Richard

---

From: Richard Shockey <[email-masked]>
Date: Mon, 29 Feb 2016 18:52:47 -0500

If I had 5 dollars for every time I've heard “phone numbers are stupid”  “We need to use SIP URI’s". I would not be on this list but enjoying the sun at my retirement home on St. Barts or some other charming estate with my own private distillery making craft gin or calvados. I have yet to see a SIP URI on any Pizza Delivery vehicle.

http://time.com/4170936/facebook-messenger-2016/