Re: [e2md] Problem statement, Requirements and Use Cases
"PFAUTZ, PENN L (ATTCORP)" <pp3129@att.com> Wed, 19 May 2010 19:55 UTC
Return-Path: <pp3129@att.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 75F063A6A17; Wed, 19 May 2010 12:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.608
X-Spam-Level:
X-Spam-Status: No, score=-105.608 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 5f8suG0pzZmn; Wed, 19 May 2010 12:55:12 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 1C2773A6A8E; Wed, 19 May 2010 12:53:59 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: pp3129@att.com
X-Msg-Ref: server-11.tower-120.messagelabs.com!1274298830!48138065!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 3665 invoked from network); 19 May 2010 19:53:51 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2010 19:53:51 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4JJrWtS008749; Wed, 19 May 2010 15:53:32 -0400
Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4JJrRn1008641; Wed, 19 May 2010 15:53:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 19 May 2010 15:53:44 -0400
Message-ID: <35FE871E2B085542A35726420E29DA6B040146B8@gaalpa1msgusr7a.ugd.att.com>
In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [e2md] Problem statement, Requirements and Use Cases
Thread-Index: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCgAAK1GJAAAPeMcA==
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>
From: "PFAUTZ, PENN L (ATTCORP)" <pp3129@att.com>
To: Sumanth Channabasappa <sumanth@cablelabs.com>, "Cartwright, Kenneth" <kcartwright@tnsi.com>, trutkowski@netmagic.com
Cc: 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
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 19:55:15 -0000
Aye, that's the question! I know of at least a couple of bodies looking for SPN that would just like to use the terminal element - not the rest of the OID string. Whether that ultimately makes sense or the overhead of using the whole thing proves in I don't know. One could even imagine different local conventions. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] Sent: Wednesday, May 19, 2010 3:45 PM To: Cartwright, Kenneth; trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: RE: [e2md] Problem statement, Requirements and Use Cases 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? - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Wednesday, May 19, 2010 12:39 PM To: trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases As Penn wisely points out, this can be discussed in detail in the appropriate forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requirements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need not have a known, or the same known, meaning to all parties that may use/see them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree. IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is standardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number). But it is not clear to me whether in practice, given our use case, if they will ever be as long as they can theoretically be. The spec for our usage would just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of that E.164 > to a globally defined identifier, specifically an IANA Enterprise > Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks
- [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