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

[Henning Schulzrinne <[e-mail]>]

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


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

_______________________________________________
Modern mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/modern