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

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

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