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

[Richard Shockey <[e-mail]>]

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 [phone]








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

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


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


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. 

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


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


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 . 



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


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. 



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