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

From: Eric Burger <[email-masked]>
Date: Tue, 24 Mar 2015 21:15:19 -0400

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

---

From: Richard Shockey <[email-masked]>
Date: Wed, 25 Mar 2015 09:53:51 -0500

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 +1 703-593-2683

On 3/24/15, 8:15 PM, "Eric Burger" <[email-masked]> wrote:

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

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Wed, 25 Mar 2015 15:20:20 +0000

+1

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 25 Mar 2015 15:48:54 +0000

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.

---

From: Eric Burger <[email-masked]>
Date: Thu, 26 Mar 2015 07:05:02 -0500

Why bother with a Work Group or even Last Call:

> On Mar 25, 2015, at 10:48 AM, Peterson, Jon <[email-masked]> wrote:
> 
> Do bear in mind, we did already put TeRQ through the DISPATCH

Let us examine the logic here. DISPATCH gave it a positive readout. So, we should have a Work Group. Since we have a Work Group, the (expired) draft should be adopted. Since we have an adopted draft, let’s put it into Last Call. No point in taking comments in Last Call, because the Work Group did not object, so let’s just publish.

Such a process would streamline the IETF, reducing the 3+ years it takes to take a draft from -00 to RFC to a matter of weeks.

So, why is it we have these checkpoints in the system (DISPATCH, BOF, Work Group, adopted draft, WGLC, IESG review, and LC)? The point of each of these checkpoints is not everybody follows every activity in the IETF. Not all of us are professional standards professionals. Each checkpoint brings in more diverse viewpoints. For that matter, we have BOFs at the IETF meeting, where the point is to get people from well outside the Area to look at the problem. If all one needs is for DISPATCH to not say No (which, by the way, is far from Yes), why do we bother with cross-area IETF meetings?

Here is the reality: DISPATCH has an incredibly high noise-to-signal ratio. The point of a BOF is so people outside of the echo chamber can find out what made it past the DISPATCH filter to see if the work makes sense for the IETF. One may be shocked to learn that sometimes the answer is No. Sometimes, the answer is Yes. Sometimes, the answer is Sounds interesting, but not for us.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 26 Mar 2015 08:53:21 -0500

A couple comments below [MB].

Regards,
Mary.

On Thu, Mar 26, 2015 at 7:05 AM, Eric Burger <[email-masked]>
wrote:

> Let us examine the logic here. DISPATCH gave it a positive readout. So, we
> should have a Work Group. Since we have a Work Group, the (expired) draft
> should be adopted. Since we have an adopted draft, let’s put it into Last
> Call. No point in taking comments in Last Call, because the Work Group did
> not object, so let’s just publish.
>
> Such a process would streamline the IETF, reducing the 3+ years it takes
> to take a draft from -00 to RFC to a matter of weeks.
>
> So, why is it we have these checkpoints in the system (DISPATCH, BOF, Work
> Group, adopted draft, WGLC, IESG review, and LC)? The point of each of
> these checkpoints is not everybody follows every activity in the IETF. Not
> all of us are professional standards professionals. Each checkpoint brings
> in more diverse viewpoints. For that matter, we have BOFs at the IETF
> meeting, where the point is to get people from well outside the Area to
> look at the problem. If all one needs is for DISPATCH to not say No (which,
> by the way, is far from Yes), why do we bother with cross-area IETF
> meetings?
>
> Here is the reality: DISPATCH has an incredibly high noise-to-signal
> ratio. The point of a BOF is so people outside of the echo chamber can find
> out what made it past the DISPATCH filter to see if the work makes sense
> for the IETF. One may be shocked to learn that sometimes the answer is No.
> Sometimes, the answer is Yes. Sometimes, the answer is Sounds interesting,
> but not for us.
>
[MB] Actually DISPATCH does not have a particularly high noise-to-signal
ratio per the archives:
http://www.ietf.org/mail-archive/web/dispatch/current/maillist.html
However, I totally agree that the chartering of this WG should not be
considered a slam dunk. [/MB]