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
- [e2md] RFC 5507 & RFC 5395 Bernie Hoeneisen
- Re: [e2md] RFC 5507 & RFC 5395 Jim Reid
- [e2md] Problem statement, Requirements and Use Ca… Bernie Hoeneisen
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Ray Bellis
- Re: [e2md] Problem statement, Requirements and Us… Dean Willis
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- [e2md] the RFC5935 process Jim Reid
- Re: [e2md] Problem statement, Requirements and Us… Dean Willis
- Re: [e2md] the RFC5935 process Ray Bellis
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- Re: [e2md] Problem statement, Requirements and Us… Richard Shockey
- [e2md] Problem statement, Requirements and Use Ca… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… Sumanth Channabasappa
- Re: [e2md] Problem statement, Requirements and Us… Richard Shockey
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- [e2md] Shall we go this way? (was Re: Problem sta… Bernie Hoeneisen
- Re: [e2md] Shall we go this way? (was Re: Problem… Dave CROCKER