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

Eric Burger <eburger@standardstrack.com> Wed, 25 March 2015 01:15 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9D1A1BF3 for <modern@ietfa.amsl.com>; Tue, 24 Mar 2015 18:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g8kDLsNPcgc for <modern@ietfa.amsl.com>; Tue, 24 Mar 2015 18:15:38 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53831A1C02 for <modern@ietf.org>; Tue, 24 Mar 2015 18:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=+dhTwci4j7n6znDnHIR78QWRh79vMK1NeS/3hZ0+2Ug=; b=HCWJoxNF/7k7SMRuTtBOrxyWxmi7g7OPOm3KlP2QqhLaQKfBgQ8Tz01AxgybvKD4Qti7KsUpamEUnXwW7TSGHTVvs1HjXp9gsk14AB1i0Pj5sW4OptmbQqmPxHrzxbBUImSrXIEkZ1095kLx27v47f2JtNcGD8cw1I9Tl7xfTxc=;
Received: from ip68-100-197-30.dc.dc.cox.net ([68.100.197.30]:63311 helo=[192.168.15.138]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from <eburger@standardstrack.com>) id 1YaZus-0005Zd-NM for modern@ietf.org; Tue, 24 Mar 2015 18:15:33 -0700
From: Eric Burger <eburger@standardstrack.com>
X-Pgp-Agent: GPGMail 2.5b6
Content-Type: multipart/signed; boundary="Apple-Mail=_C4DEB09D-F192-48CE-AB8F-107499814A1F"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Date: Tue, 24 Mar 2015 21:15:19 -0400
Message-Id: <2BFD36D0-254B-4157-8A49-BDFC3BB9ED88@standardstrack.com>
To: modern@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
X-OutGoing-Spam-Status: No, score=-1.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/modern/pNRiyYx2r7kimshYSnpZt125NYc>
Subject: [Modern] Questions on draft-peterson-modern-problems-00: Utility and Motivation
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" <modern.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/modern>, <mailto:modern-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/modern/>
List-Post: <mailto:modern@ietf.org>
List-Help: <mailto:modern-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/modern>, <mailto:modern-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 01:15:40 -0000

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