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

Richard Shockey <richard@shockey.us> Wed, 25 March 2015 15:14 UTC

Return-Path: <richard@shockey.us>
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 106D31B2A0F for <modern@ietfa.amsl.com>; Wed, 25 Mar 2015 08:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 2joxqQTmES4g for <modern@ietfa.amsl.com>; Wed, 25 Mar 2015 08:14:03 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 286421A1B76 for <modern@ietf.org>; Wed, 25 Mar 2015 08:14:03 -0700 (PDT)
Received: (qmail 2189 invoked by uid 0); 25 Mar 2015 15:14:03 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 25 Mar 2015 15:14:03 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 7qtv1q00B1MNPNq01qtyvV; Wed, 25 Mar 2015 08:54:01 -0600
X-Authority-Analysis: v=2.1 cv=OYILUHjY c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=cChd4gCxB1EA:10 a=emO1SXQWCLwA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=Lfi0IGIEAAAA:8 a=48vgC7mUAAAA:8 a=PMrpXCa_rzsbkn4Y6t8A:9 a=U4JkOGW8pe6udeDR:21 a=dSw20BE7GwQ05Ojk:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=4Y+OsffiyYu/BjHsJdeANO3at66mBvtXUp2tPrFXUMs=; b=U/i8gXGq8eSF5/QCp8LZWHs/H674/Yj3iJiPsSEHkEGxA1KCu4bzAwDDq52yJa4dtWz1LRsdeQHZmVb1sfdZW9Shx55j4JfWXBjWQmRf2lstG/jWLRiROUKqa/WMxS85;
Received: from [38.96.210.190] (port=50156 helo=[10.1.212.65]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from <richard@shockey.us>) id 1Yamgu-0006Ko-PM; Wed, 25 Mar 2015 08:53:57 -0600
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Wed, 25 Mar 2015 09:53:51 -0500
From: Richard Shockey <richard@shockey.us>
To: Eric Burger <eburger@standardstrack.com>, modern@ietf.org
Message-ID: <D1377F41.228A8%richard@shockey.us>
Thread-Topic: [Modern] Questions on draft-peterson-modern-problems-00: Utility and Motivation
References: <2BFD36D0-254B-4157-8A49-BDFC3BB9ED88@standardstrack.com>
In-Reply-To: <2BFD36D0-254B-4157-8A49-BDFC3BB9ED88@standardstrack.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 38.96.210.190 authed with richard+shockey.us}
Archived-At: <http://mailarchive.ietf.org/arch/msg/modern/ahxZAKvI3WenrVeo5oxTQQadTwA>
Subject: Re: [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 15:14:06 -0000

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" <eburger@standardstrack.com> 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
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern