[secdir] [new-work] Comment on WG modern

"Richard Hill" <rhill@hill-a.ch> Thu, 25 June 2015 08:57 UTC

Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB71B3360; Thu, 25 Jun 2015 01:57:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1435222631; bh=E0Y0bLmfQ+UXLllolMb0NOHDEp4IltTtwNjEIEFKhTQ=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=WDrW4Ut7NY7rs+hcPZJ3t8/JHRmxlrtrulnC3MO/Y7kdYRD6A3ARLlnCDxL6ly3Ye A/lgwYwZlold9woWTW6UeiTWQ9olRn5/ySmKUsfNX9tK+Y8p3LwmKlIjMlBfEW/ddl 07+aML1f3k6Pw/f/r3ZD6KIgKc0aPc9AAteYl5Gw=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7E26B1B3360 for <new-work@ietfa.amsl.com>; Thu, 25 Jun 2015 01:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id T1lJUjD7vb2F for <new-work@ietfa.amsl.com>; Thu, 25 Jun 2015 01:57:07 -0700 (PDT)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BF91B335D for <new-work@ietf.org>; Thu, 25 Jun 2015 01:57:06 -0700 (PDT)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch []) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5P8v4a2014421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <new-work@ietf.org>; Thu, 25 Jun 2015 10:57:04 +0200
Received: from RHillNew (adsl-178-38-12-166.adslplus.ch []) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5P8v3Yg011718 for <new-work@ietf.org>; Thu, 25 Jun 2015 10:57:04 +0200
From: Richard Hill <rhill@hill-a.ch>
To: new-work@ietf.org
Date: Thu, 25 Jun 2015 10:57:04 +0200
Message-ID: <004001d0af24$e89d70e0$b9d852a0$@ch>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdCvJOg5Dlbkvi9rSgCEkL6kWmG8Uw==
Content-Language: en-us
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.
X-Antivirus-Code: 0x100000
Archived-At: <http://mailarchive.ietf.org/arch/msg/new-work/hAvUOha39xzSolWyrI3cjtk2eEU>
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: new-work <new-work-bounces@ietf.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/7BNGTLKw8cFMJ-B7Bee5iTTy_wI>
X-Mailman-Approved-At: Sat, 27 Jun 2015 09:23:53 -0700
Subject: [secdir] [new-work] Comment on WG modern
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 08:57:11 -0000

I refer to:


As I understand it, this is a proposal to create new working group that will
consider managing, ordering, distributing, and registering telephone

In my view, the proposed work clearly falls within the remit of ITU-T Study
Group 2 and I don't think that it would be a good idea for the IETF to
create a group whose mandate squarely overlaps with the mandate of ITU-T.  A
more detailed explanation follows.

I presume that "telephone numbers" refers to E.164 numbers, that is, numbers
that are standardized and administered in accordance with ITU-T
Recommendations E.164, E.164.1, E.190, and related ITU-T Recommendations.

In accordance with those recommendations, and related ITU Plenipotentiary
Resolutions, the management and administration of those numbers is done at
the international level by the Telecommunications Standardization Bureau
(TSB) which assigned country codes (such as 41 for Switzerland) and by
national authorities at the country level.

Countries can have more than one country code, or less than one country
code: that is, several countries can share one country code. The best-known
example of this situation is country code 1, which is shared by the USA,
Canada, and a number of other countries.

The administration of the numbers under country code 1 is performed by the
North American Numbering Plan Administration, which is a private entity to
which the US Federal Communication Commission delegates the administration.
At present that entity is Neustar.  The policies that the Administration
implements are developed by the North American Numbering Plan which, if I
understand correctly, is comprised of operators that use numbers under
country code 1.

The US arrangements for the management of telephone numbers are, I believe,
unusual. In other countries the management is performed directly by the
national regulatory authority, which sets the policies and assigns blocks of
numbers to operators.

Thus, in general, decisions about managing, ordering, distributing and
registering telephone numbers are made by national regulatory authorities.

I now refer to one of the presentations that was made during early
discussions regarding this working group:


Slide 2 states that phone numbers are "opaque". I don't know what is meant
by that, but it is true that it is not obvious whether a particular phone
number is fixed or mobile, or, if fixed, what geography it corresponds to.
But that is because phone numbers do not have significance: you have to look
up the code in a database to find out what meaning, if any, is attached to
it (e.g. that 41 corresponds to Switzerland and that 4179 corresponds to
mobile phones in Switzerland). (By the way, many countries now have full
number portability within the fixed and mobile numbering plans, so it is no
longer possible to tell which mobile operator is service a particular mobile
number, or what geographical area corresponds to a particular fixed number.
For example, 4122 was the geographic code for Geneva, Switzerland, but now,
with number portability, it could correspond to a fixed telephone in Zurich,

Slide 2 states that phone numbers are "still anchored in the PSTN". Of
course: they were designed for the PSTN and have been adapted and upgraded
to meet the needs of the current telephony system, including mobile

Slide 3 says: "What if you could get numbers the way you get domain names?
Or what if you could get numbers like you get IP addresses?" Those are
rhetorical questions, because it would require changes in the ITU-T
Recommendations, and national regulations, to be able to do that. 

Slide 5 says that the proposed working group will not set telephone number
policies. Obviously, since those policies are set by the ITU-T and by
national regulatory authorities. So I don't understand what the proposed
working group would do that would help to achieve the objectives set forth
in slide 3, other than to develop standards that would facilitate the
exchange of information related to the administration of numbers (that's my
understanding of what slides 9 to 17 are presenting).

For sure standards to facilitate exchange of information are very useful,
and there are some ITU-T Recommendations relating to that (in particular for
providing information on national numbering plans).  But it seems to me that
development of such standards falls squarely within the remit of ITU-T Study
Group 2, so it does not appear appropriate to me to create an IETF working
group whose mandate would clearly overlap with the ITU-T's mandate.

I was heavily involved in the ENUM discussions that arose when the IETF made
some decisions without first liaising with ITU-T Study Group 2. That created
a difficult atmosphere and it took a lot of effort to find a solution that
satisfied both the IETF folks that designed ENUM and national regulators.

I would urge the IETF not to repeat that mistake. If somebody thinks that
some additional standards are needed regarding telephone numbers, then I
would recommend that the requirements be submitted to ITU-T Study Group 2,
and that the folks who are interested in the issue participate in the
discussions in ITU-T Study Group 2.

Otherwise you will likely wind up with the same contentious situation that
arose back in 2001 regarding ENUM.

Slide 5 says "Numbering inventory is a scarce asset, not like the DNS".
There may be some scarcity under code 1, because the North American
Numbering Plan has not expanded the number of digits in a very long time. In
most other countries, the number of digits has been increased and there is
no scarcity.  

Slide 10 refers to Skype. Skype actually applied to ITU-T to obtain an
international code (country codes need not be geographic, there are
non-geographic country codes; sub-codes of those non-geographic codes are
assigned to operators that provide services in more than one country). Skype
was refused the code because they refused to certify that they operate
physical infrastructure in at least two countries (that's one of the
conditions for obtaining a non-geographic code). As I understood the
discussion at the time, Skype did not wish to certify that because they did
not wish to be subject to telephony regulations. So any assignments to Skype
would presumably have to comply with applicable regulations.

Since the people who know and understand the applicable regulations
participate in the work of ITU-T Study Group 2, it seems to me that
discussions of these topics should take place there, and not in the IETF.

Richard Hill

new-work mailing list