Re: [e2md] Problem statement, Requirements and Use Cases
Tony Rutkowski <trutkowski@netmagic.com> Wed, 19 May 2010 20:13 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 6C2BC3A63D3; Wed, 19 May 2010 13:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Level:
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-0.511, 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 QECWDo-OIvNr; Wed, 19 May 2010 13:12:58 -0700 (PDT)
Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id C10653A689D; Wed, 19 May 2010 13:12:53 -0700 (PDT)
Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2O00JP9O1YEK70@vms173001.mailsrvcs.net>; Wed, 19 May 2010 15:10:52 -0500 (CDT)
Message-id: <4BF445C6.1020308@netmagic.com>
Date: Wed, 19 May 2010 16:10:46 -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: Sumanth Channabasappa <sumanth@cablelabs.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> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg>
In-reply-to: <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg>
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Cc: "drinks@ietf.org" <drinks@ietf.org>, "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 20:13:01 -0000
On 5/19/2010 3:44 PM, Sumanth Channabasappa wrote: > When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no? > You could do this. However, you lose the ability to have other SPID OID constructs, including those with localizations. Different countries and carriers have chosen different OID arcs they are using. Like it or not, E.164 numbers are under the control of sovereign States and provider assignees, and they might just want to specify and control their own namespaces for Carriers of Record. It seems wise to provide that latitude for any spec you are devising. --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