Re: [Modern] Questions on draft-peterson-modern-problems-00: Utility and Motivation

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

I seem to recall all three of us attended the FCC workshop on the future
of telephone number administration that inspired this mailing list, and
ultimately, this draft, so I am a little surprised at the confusion about
the scope of the proposed work.

The core idea here is to build tools that could support alternative number
administration models in a post-PSTN transition environment. We're not
going to dictate future policies that any governments will adopt, but we
are going to try to build tools that can apply to a set of likely models
we imagine could be put in place. At the MODERN BoF, I understand Henning
will be giving some of his perspective on that. If we're out of step with
the likely models, then yes, we need some course correction. And if we
think a model inspired by ideas in the USA will not be applicable
elsewhere, that's good feedback, though we'd need to explore that further.
But to be clear, those points would be the work of the proposed group, not
the decision we make of whether or not a group with this mandate should be
chartered. 

So yes, modern-problems is a very brief sketch document submitted pretty
much at the last minute to help kickstart discussion, not finish it.
Discussion is good. It's an individual -00, its contents are subject to
change. Many of the sections you point to Eric would certainly evolve if
we went forward.

To the question of "ENUM bashing," I think the TeRQ effort has always been
about creating a query response mechanism that can address the known
problems with our existing mechanisms which you both acknowledge below.
Just because our existing mechanisms have problems does not mean that they
are not deployed, nor that they don't address a market need. No one is
claiming otherwise, really, and yes the authors of the draft seem to be
ENUM providers themselves. But addressing those limitations does seem
necessary for the kind of future number administration models we propose
to consider, and it seemed best to pursue that work in this broader
context. Do bear in mind, we did already put TeRQ through the DISPATCH
process, and it got a positive readout - we've just deferred chartering a
group to contain it until now.

Jon Peterson
Neustar, Inc.

On 3/25/15, 7:53 AM, "Richard Shockey" <[e-mail]> wrote:

>
>Thank you Eric ..thank you very much.
>
>I¹ve been holding my fingers back on this draft because in many ways it
>was not worth the effort.
>
>I¹ll never support this draft if it continues to engage in gratuitous and
>often 6116 bashing that has no relevance to the Problem
>Statement that Modern attempts to address.  Everyone knows the limitations
>6116 placed on the query response model and some of us are very aware of
>the duct tape and bailing wire and non standard DNS query mechanic hams
>necessary to make the protocols work  ..see source Kaplan URI for
>determinate response etc.
>Security is terible non extensible since certain members of the IETF
>community killed off any attempts to allow for extensibility etc.
>Authentication and authorization non existent etc.  The provisioning
>systems for ENUM were primitive at best which is why DRINKS was started
>but that had its own problem.
>
>As any global SIP service provider can tell you carrier ENUM is very very
>widely deployed and is the basis for a substantial number of SIP/IMS inter
>carrier connection interconnection agreements and in part represents a
>view of carrier SIP interconnection represented in the ATIS SIP Forum NNI
>developed for North American Service providers that is now going into
>ballot.
>
>That said technology marches on and revisiting the generalized
>provisioning/query system for identifiers merits some thought.
>
>Note I did 
>not say phone numbers.  This has been a problem for the IETF for some
>time. I submit that the entire PROVREG construct in the IETF was a failure
>since it ended up as a special purpose suite of protocols to satisfy the
>requirements of a single regulatory authority ICANN instead of a general
>purpose registry/registrar/registrant system.  We are perilously close to
>that point here. IMHO the three elements here are Acquisition Provisioning
>(not management) and retrievial.
>
>As the draft should have pointed out telephone numbers as potential
>identifiers are unique in that the authority to issue them and manage the
>system surrounding them is the total and exclusive right of nation states
>both by international treaty and national statute. ( I have a collection
>of some of them BTW)
>
>The role of MODERN here is to offer tools. Instead of saying the
>³mechanism will do foo² it is more appropriate to say the ³proposed
>mechanism may do foo if national policy so permits².
>
>Beyond that ..and I could rant but I certainly do not have any objection
>to people working on the basic concept.
>
>
>‹ 
>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 3/24/15, 8:15 PM, "Eric Burger" <[e-mail]> wrote:
>
>>Here are some comments for discussion based on the the recent draft.
>>
>>
>>One thing that I am curious of is the assertion that ENUM failed because
>>it "tried to preserve the features and architecture familiar from the
>>PSTN numbering environment² [Section 1, p. 2] and that ENUM did not
>>support "transitioning away from a provider-centric model towards a
>>user-centric model."
>>
>>My understanding was that ENUM failed because it tried to be user
>>centric. I thought the authorities (mostly governmental) were not willing
>>to let users edit their own ENUM data. The fact the same protocol could
>>be used in walled gardens for private inter-carrier routing information
>>was gravy. An example of this is Neustar¹s GSMA PathFinder product [1],
>>which is a Private ENUM-based routing database, optimized for local
>>number portability.
>>
>>This comes from the statement:
>>   Ideally the user would have full control of their TN and
>>   would drive the porting process on their own rather than rely on
>>   complex and time consuming back office processes among multiple
>>   service providers.			[Section 1, p. 3]
>>
>>Is this something desired or supported by those who control numbering
>>resources? Has something changed in the market to convince governments or
>>dominant service providers to release their chokehold on number
>>resources? I personally think there may be some thawing in the United
>>States. However, I wonder if is this a U.S. issue driving a U.S.-centric
>>(or North America, as NANP has mostly common governance) solution? Will
>>we be able to come up with something acceptable on a global basis? It is
>>easy to say we will come up with a global technology. However, unlike IP
>>in 1981 where Jon¹s notebook was the authoritative data base and no
>>government could care what your IP address is, governments have been in
>>the middle of telephone number assignments for over a century. Do we have
>>any indication that a solution we develop will be acceptable on a global
>>basis?
>>
>>We can do what we want to resources we invent, like keeping IPv4 and IPv6
>>not geographic based. However, I am leery to say the IETF can tell
>>governments that we will replace their 100+ year old numbering regulatory
>>regimes.
>>
>>What I hope to avoid is the fate of Public ENUM. We created a technology
>>that would allow users to have full control of their TN, and no one came
>>out to play. I would hate to spin up a ton of work in the IETF for
>>something that would have the same fate as Public ENUM.
>>
>>This issue comes out again later in the section:
>>   It
>>   will be important to acknowledge that there are various international
>>   and national policies and processes related to TNs, and any solution
>>   needs to be flexible enough to account for these variations.
>>						[Section 1, p. 3]
>>
>>I would offer that if Œacknowledge¹ means we say that we know there is
>>this policy thing out there that tends to be country-specific, we have
>>done the second step. The third step is making sure the solution is
>>flexible to account for these variations. What is missing is the first
>>step: will nation-states be willing to rally around an IETF protocol to
>>make our effort an Internet (global) solution? If not, do we at least
>>have the North American governments' and carriers¹ backing? If not, we
>>have a really interesting academic exercise here, but if no one wants it
>>or is going to use it, why are we spinning cycles on it? Conversely, if
>>governments, carriers, and users want this, PLEASE say so.
>>
>>Nit: This paragraph starts out mostly correct:
>>   Most TNs today are assigned to specific geographies, at both an
>>   international level and within national numbering plans.  This has
>>   shaped the way that service providers interconnect, as well as how
>>   telephone numbers are routed and administered: the PSTN was carefully
>>   designed to delegate switching intelligence geographically.
>>
>>But then the paragraph says:
>>   In
>>   interexchange carrier routing in North America, for example, calls to
>>   a particular TN are often handed off to the terminating service
>>   provider close to the geography where that TN is assigned.  But the
>>   overwhelming success of mobile telephones has increasing eroded the
>>   connection between numbers and regions.  Furthermore, the topology of
>>   IP networks is not anchored to geography in the same way that the
>>   telephone network is.  In an Internet environment, establishing a
>>   network architecture for routing telephone numbers would depend
>>   little on geography.		[Section 1, p. 3]
>>
>>Specifically, I think the U.S. government would go apoplectic if anyone
>>could route +1 202 224 XXXX numbers however they liked. Likewise, I think
>>the Russian Federation might get a little antsy if someone wanted to
>>route +7 numbers.
>>
>>Is there something more here? For example, is this the real issue?
>>   The industry also came to realize that there were
>>   limitations in the DNS protocol and it may not be a good fit for a
>>   communications protocol that would need more security, richer
>>   datasets and more complex query and response capabilities.
>>						[Section 1, p. 3]
>>
>>We all know DNS has a bunch of security issues that even DNSSEC does not
>>fix. If this is the driver, let us say so. I have no problem supporting
>>an effort to create a data base lookup mechanism that is not DNS-based.
>>However, I am not sure I want to support an effort if no one wants or
>>needs it. Do we have a ton of service providers, governments, or users
>>saying they would use ENUM if only it was not DNS-based? I thought the
>>barriers to adoption were more about politics and governance (who runs
>>the root) than about technology.
>>
>>
>>I sense in the document a premise that geographic numbering or
>>administration may be on its way out. My concern pops up in Section 3:
>>   It is not the purpose of this framework to dictate
>>   number policy, but instead to provide tools that will work with
>>   policies as they evolve going forward.
>>						[Section 3, p. 4]
>>
>>Do we have any idea what governments, users, or service providers need or
>>want? Is the idea that if we create a global, IP-based numbering regime,
>>most governments, service providers, and users will sign on? Do we have
>>any sense of how likely this will be? It would be great if they would,
>>but my gut is we would need more involvement and input from global
>>regulators before that would happen. For example, do we have input from
>>the FCC (U.S.), CRTC (Canada), OUR (Jamaica), etc. as to what would and
>>would not be acceptable? We are, after all, proposing to change the way
>>they allocate and manage numbers. I think what is being proposed here is
>>for the better, but we should know beforehand that as we dip into the
>>policy world, we will not get bitten.
>>
>>
>>
>>[1] http://www.gsma.com/technicalprojects/pathfinder
>>_______________________________________________
>>Modern mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/modern
>
>
>_______________________________________________
>Modern mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/modern