Re: [e2md] Problem statement, Requirements and Use Cases

Tony Rutkowski <trutkowski@netmagic.com> Wed, 19 May 2010 17:18 UTC

Return-Path: <trutkowski@netmagic.com>
X-Original-To: e2md@core3.amsl.com
Delivered-To: e2md@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7AB3A6C7B for <e2md@core3.amsl.com>; Wed, 19 May 2010 10:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.68
X-Spam-Level:
X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmNTLDsimNAQ for <e2md@core3.amsl.com>; Wed, 19 May 2010 10:18:31 -0700 (PDT)
Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by core3.amsl.com (Postfix) with ESMTP id 254A328C0DC for <e2md@ietf.org>; Wed, 19 May 2010 10:17:34 -0700 (PDT)
Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2O0071AG09QH90@vms173013.mailsrvcs.net> for e2md@ietf.org; Wed, 19 May 2010 12:16:57 -0500 (CDT)
Message-id: <4BF41D09.8080604@netmagic.com>
Date: Wed, 19 May 2010 13:16:57 -0400
From: Tony Rutkowski <trutkowski@netmagic.com>
Organization: Netmagic Associates
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4
MIME-version: 1.0
To: "PFAUTZ, PENN L (ATTCORP)" <pp3129@att.com>
References: <alpine.DEB.2.00.1005161433580.31324@softronics.hoeneisen.ch><32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <alpine.DEB.2.00.1005171404110.16091@softronics.hoeneisen.ch> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <35FE871E2B085542A35726420E29DA6B0401450B@gaalpa1msgusr7a.ugd.att.com>
In-reply-to: <35FE871E2B085542A35726420E29DA6B0401450B@gaalpa1msgusr7a.ugd.att.com>
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Cc: "E.164 To MetaData BOF discussion list" <e2md@ietf.org>
Subject: Re: [e2md] Problem statement, Requirements and Use Cases
X-BeenThere: e2md@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: trutkowski@netmagic.com
List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" <e2md.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/e2md>, <mailto:e2md-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/e2md>
List-Post: <mailto:e2md@ietf.org>
List-Help: <mailto:e2md-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e2md>, <mailto:e2md-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 17:18:32 -0000

On 5/19/2010 12:45 PM, PFAUTZ, PENN L (ATTCORP) wrote:
> This is an area that will need more discussion which I hope will ensue,
> if not necessarily under e2md then in the IETF, ITU, i3 and national
> SDOs. At least some bodies are looking for a single integer (SPN), e.g.
> the value under the OID 1.3.6.1.4 arc, for AT&T 74. There have also been
> some requests to support hierarchy subtending an SPN.
>    

Agreed.

Another international carrier identifier choice is
ITU-ICCs pursuant to the M.1400 standard.  However,
their six alphanumeric character structure doesn't
scale, and the uptake has been minimal.

Almost every country has one or more national
identifiers for carriers, but those differ structurally
and are not global by definition.

Then there is the new NeuStar proposal for a five digit
number issued by either the ITU equivalent of IANA (the
TSB) or by national telephone managers like NeuStar.
However, these don't scale, would have significant
regulatory burdens and costs, and seem unlikely to be
accepted as a new global SPID.

OIDs on the other hand were created in the 1980s as a
universal, simple, extensible identifier for all
entities, explicitly including service providers.  They
are hierarchical and can be recursively resolved.  They
are widely used as SPIDs.  The assignment identity
proofing and maintenance leaves something to be
improved, but this is being addressed with the use of
X.509 or EVcerts or other assurance overlays.

Anyhow, those seem like the SPID alternatives.

--tony