From nobody Mon Jan 26 18:47:53 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1CF1A1B77 for ; Mon, 26 Jan 2015 18:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.388 X-Spam-Level: ** X-Spam-Status: No, score=2.388 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgWsvDMtnGPo for ; Mon, 26 Jan 2015 18:47:50 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 921281A1B78 for ; Mon, 26 Jan 2015 18:47:50 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "Holmes, David W [CTO]" , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGsgAP8KoCABP4I64AAWXOAgI72jyM= Date: Tue, 27 Jan 2015 02:47:48 +0000 References: , , <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> In-Reply-To: <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 02:47:52 -0000 David,=0A= =0A= picking up an old discussion thread. Do you have any pointers to relevant d= ocuments that we can collect? I'm particularly looking for documents that d= escribe information associated with phone numbers. The domain name world is= reasonably well documented (see, for example, Section 3 of https://www.ica= nn.org/resources/pages/approved-with-specs-2013-09-17-en#information)=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Holmes, David W [CTO] [David.Holmes@sprint.com]=0A= Sent: Monday, October 27, 2014 7:18 PM=0A= To: Henning Schulzrinne; McGarry, Tom; modern@ietf.org=0A= Subject: RE: [Modern] Services=0A= =0A= This is a great discussion & continues to follow the common IETF principles= of proposing a solution & then finding what patches it needs to meet some = implicit requirement(s).=0A= =0A= However, in this case, given the huge legacy coming in from both the IP & P= STN worlds, I suspect that perhaps we should consider modifying the process= somewhat, & first generate some kind of statement of requirements / proble= m statement. A large amount of the required information has already been a= ired, as we see below, so potentially this could be done without the expend= iture of much effort.=0A= =0A= Maybe what we need to start the process is an informational RFC that list o= ut all the identifiers in common use in this field, & how they are used, tr= anslated for routing, etc.? Based on that it should be easy to rationally = derive a set of requirements & (hopefully) figure which identifier(s) & sup= porting mechanisms can be minimally modified to produce a reasonable soluti= on.=0A= =0A= David Holmes=0A= Sprint=0A= =0A= From nobody Wed Jan 28 09:12:32 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239C21A8757 for ; Wed, 28 Jan 2015 09:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHJgwnDqk0uG for ; Wed, 28 Jan 2015 09:12:28 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4B61A87E1 for ; Wed, 28 Jan 2015 09:12:28 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id b7819c45.0.3896227.00-1998.10886074.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 28 Jan 2015 17:12:28 +0000 (UTC) X-MXL-Hash: 54c9187c3e0ee90e-b3cda8f1fc2d74571a1700ddb351b3d27bec52d4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0SHCRYj010358 for ; Wed, 28 Jan 2015 12:12:27 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0SHCKs7010218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 28 Jan 2015 12:12:23 -0500 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Wed, 28 Jan 2015 17:12:03 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.63]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 12:12:03 -0500 From: "PFAUTZ, PENN L" To: "modern@ietf.org" Thread-Topic: protocols for number management? Thread-Index: AdA7HfdFgw8QrcWbTt2oVjEiLzc30g== Date: Wed, 28 Jan 2015 17:12:03 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] Content-Type: multipart/alternative; boundary="_000_38726EDA2109264987B45E29E758C4D605789DEAMISOUT7MSGUSRDD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=L/KqtZv8 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=XklW-5pq2GQ5klmwvdsA:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10 a=iE9YWIBck50A:10 a=VfjYWiVxyVZZDfBM:21 a=S1] X-AnalysisOut: [8qLi7UJSB7Yjyv:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2] X-AnalysisOut: [Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg] X-AnalysisOut: [-hUA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: [Modern] protocols for number management? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 17:12:30 -0000 --_000_38726EDA2109264987B45E29E758C4D605789DEAMISOUT7MSGUSRDD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ATIS has a landscape testbed activity assembling various use cases that mig= ht be examined in a testbed. One of them involves inventory-less just-in-time number assignment within t= he framework of the kind of unfied numbering lifecycle management platform = discussed at the FCC Numbering Testbed Workshop back in March of 2014. The question came up as to what sort of protocols might be appropriate for = service providers to interact with the registry provider(s), to find availa= ble resources, request assignments, and provision appropriate information f= or distribution to other SPs once the assignment is made. Mechanisms to acc= ommodate this a distributed registry architecture are also of interest (how= to make sure the same number isn't assigned by two different registry pro= viders in a race condition) It occurred to me folks on this list might have some suggestions. Thanks, Penn Pfautz AT&T Global Connection Management +1-732-420-4962 --_000_38726EDA2109264987B45E29E758C4D605789DEAMISOUT7MSGUSRDD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ATIS has a landscape testbed activity assembling var= ious use cases that might be examined in a testbed.

One of them involves inventory-less just-in-time num= ber assignment within the framework of the kind of unfied numbering lifecyc= le management platform discussed at the FCC Numbering Testbed Workshop back= in March of 2014.

 

The question came up as to what sort of protocols mi= ght be appropriate for service providers to interact with the registry prov= ider(s), to find available resources, request assignments, and provision ap= propriate information for distribution to other SPs once the assignment is made. Mechanisms to accommodate this a= distributed registry architecture are also of interest (how to make sure t= he same number isn’t assigned by two different  registry provide= rs in a race condition)

 

It occurred to me folks on this list might have some= suggestions.

 

Thanks,

Penn Pfautz

AT&T Global Connection Management

+1-732-420-4962

--_000_38726EDA2109264987B45E29E758C4D605789DEAMISOUT7MSGUSRDD_-- From nobody Wed Jan 28 10:53:58 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3689F1A1AFF for ; Wed, 28 Jan 2015 10:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.997 X-Spam-Level: * X-Spam-Status: No, score=1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Nwndnr55zx for ; Wed, 28 Jan 2015 10:53:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF751A1AC6 for ; Wed, 28 Jan 2015 10:53:54 -0800 (PST) Received: from BY2FFO11FD002.protection.gbl (10.1.14.32) by BY2FFO11HUB061.protection.gbl (10.1.15.236) with Microsoft SMTP Server (TLS) id 15.1.75.11; Wed, 28 Jan 2015 18:53:53 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Wed, 28 Jan 2015 18:53:52 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t0SIro2h027532 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2015 12:53:50 -0600 Received: from PLSWE13M07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t0SIrnBp021065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Jan 2015 12:53:49 -0600 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 28 Jan 2015 12:53:48 -0600 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.0995.028; Wed, 28 Jan 2015 12:53:48 -0600 From: "Holmes, David W [CTO]" To: Henning Schulzrinne , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7OopwzhHMAgAA62ICAANOHAIAAECQAgABedoCAAFw5AIABixeAgAGUfICAAN2CAIAAAc6AgAAD1oCAAOByAIAA7LGAgAAG+ACAABMaAIAAo2qAgAP6NACABP8hgP//uzgggI+pWQCAAjIAQA== Date: Wed, 28 Jan 2015 18:53:47 +0000 Message-ID: References: , , <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.91.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=David.Holmes@sprint.com; fcc.gov; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(47776003)(33646002)(106466001)(46406003)(106116001)(2501002)(19580405001)(93886004)(108616004)(77156002)(54356999)(62966003)(2950100001)(50986999)(97756001)(46102003)(2656002)(15975445007)(2900100001)(6806004)(23726002)(19580395003)(50466002)(87936001)(86362001)(92726002)(102836002)(92566002)(76176999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB061; H:pdaasdm2.corp.sprint.com; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB061; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BY2FFO11HUB061; X-Forefront-PRVS: 047001DADA X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB061; X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2015 18:53:52.2852 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.229.32.57] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB061 Archived-At: Cc: "Gorman, Pierce A \[NTK\]" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 18:53:57 -0000 Hi Henning, I suspect that "information associated with E.164 phone numbers" is highly = inconsistent in nature, as, once the "country"-level information is allocat= ed to the per-"country" administrators, I do not believe that there is any = requirement to have a standard set of information collected for the entitie= s to whom those administrators allocate numbers; I suspect we can only pres= ume entity name & potentially business address; & similar for the end custo= mers to whom the carriers allocate individual numbers from the blocks they = are given by their national number administrators. So while we may have lo= cal stores of more associated data sets (like LIDB), these are not universa= l. What is your interest in the information associated with a particular ident= ifier type? I was suggesting that a first step would be to generate a list= of identifiers & their technical characteristics. BR/David -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Monday, January 26, 2015 9:48 PM To: Holmes, David W [CTO]; McGarry, Tom; modern@ietf.org Subject: RE: [Modern] Services David, picking up an old discussion thread. Do you have any pointers to relevant d= ocuments that we can collect? I'm particularly looking for documents that d= escribe information associated with phone numbers. The domain name world is= reasonably well documented (see, for example, Section 3 of https://www.ica= nn.org/resources/pages/approved-with-specs-2013-09-17-en#information) Henning ________________________________________ From: Holmes, David W [CTO] [David.Holmes@sprint.com] Sent: Monday, October 27, 2014 7:18 PM To: Henning Schulzrinne; McGarry, Tom; modern@ietf.org Subject: RE: [Modern] Services This is a great discussion & continues to follow the common IETF principles= of proposing a solution & then finding what patches it needs to meet some = implicit requirement(s). However, in this case, given the huge legacy coming in from both the IP & P= STN worlds, I suspect that perhaps we should consider modifying the process= somewhat, & first generate some kind of statement of requirements / proble= m statement. A large amount of the required information has already been a= ired, as we see below, so potentially this could be done without the expend= iture of much effort. Maybe what we need to start the process is an informational RFC that list o= ut all the identifiers in common use in this field, & how they are used, tr= anslated for routing, etc.? Based on that it should be easy to rationally = derive a set of requirements & (hopefully) figure which identifier(s) & sup= porting mechanisms can be minimally modified to produce a reasonable soluti= on. David Holmes Sprint ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Jan 28 12:44:12 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11701A023E for ; Wed, 28 Jan 2015 12:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spr-TJd83m8v for ; Wed, 28 Jan 2015 12:44:08 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 357A21A005C for ; Wed, 28 Jan 2015 12:44:07 -0800 (PST) Message-ID: From: Henning Schulzrinne To: 'Ken Pogran' Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGsgAP8KoCABP4I64AAWXOAgI72jyOAAvV7gP//zRmw Date: Wed, 28 Jan 2015 20:44:06 +0000 References: <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D05BE0CDFFp2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: Cc: "Holmes, David W \[CTO\]" , "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 20:44:11 -0000 --_000_E6A16181E5FD2F46B962315BB05962D05BE0CDFFp2pxmb13fccnetw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVtaW5kZXIgYW5kIHBvaW50ZXIuIEhlcmXigJlzIHRoZSBsaXN0IGZv ciBjb252ZW5pZW5jZToNCg0KVE4gb3duZXJzaGlwOw0K74K3IEF1dGhvcml0YXRpdmUgQ2FsbGlu ZyBOYW1lIChDTkFNKTsgIFsxNiBjaGFyYWN0ZXIgdGV4dCBub3c7IG1vcmUgZWxhYm9yYXRlIGZv ciBDTkFNKytdDQrvgrcgQmlsbCBOdW1iZXIgU2NyZWVuaW5nLCBmb3IgY29sbGVjdCBjYWxsaW5n IGFuZCBjYWxscyBiaWxsZWQgdG8gdGhpcmQgcGFydGllczsgW2Jvb2xlYW5dDQrvgrcgT3JpZ2lu YXRpbmcgTGluZSBOdW1iZXIgU2NyZWVuaW5nIGZvciBwcmlzb24gbGluZXMgKGFscmVhZHkgdGhl IHN1YmplY3Qgb2YNCmFub3RoZXIgRkNDIHByb2NlZWRpbmcpIGFuZCBob3RlbCByb29tcywgYXMg d2VsbCBhcyBmb3Igb3B0aW9uYWwgc2VydmljZXMNCmJpbGxlZCB0byB0aGUgb3JpZ2luYXRpbmcg bGluZTsgW0Jvb2xlYW5dDQrvgrcgU2VydmljZSBhbmQgRXF1aXBtZW50IEluZGljYXRvciwgdXNl ZCB0byBkZXRlcm1pbmUgdHJlYXRtZW50IG9mIGNhbGxzDQpvcmlnaW5hdGVkIGJ5IHRoZSBUTjsg Wz9dDQrvgrcgWklQKzQsIHVzZWQgaW4g4oCcMzEx4oCdIGluZm9ybWF0aW9uIHNlcnZpY2VzIHJv dXRpbmc7IFs5IGRpZ2l0c10NCu+CtyBMaW5lLWJhc2VkIGNhbGxpbmcgY2FyZCBQSU5zLCAodG8g dGhlIGV4dGVudCB0aGVzZSBhcmUgcmV0YWluZWQgaW4gdGhlIGFsbC1JUA0KbmV0d29yayk7IGFu ZCBbc2VlbXMgbGlrZWx5IHRvIGRpc2FwcGVhciwgYnV0IHBvc3NpYmx5IGEgaGFzaF0NCu+CtyBQ SUMgYW5kIExQSUMsIGludGVyZXhjaGFuZ2UgY2FycmllciBkZXNpZ25hdGlvbnMgKHRvIHRoZSBl eHRlbnQgdGhlc2UgYXJlDQpyZXRhaW5lZCBpbiB0aGUgYWxsLUlQIG5ldHdvcmspLiBbaW50ZWdl cnNdDQoNCkkgc3VzcGVjdCB3ZeKAmWxsIHdhbnQgYSBzeXN0ZW0gdGhhdCBtYWtlcyBpdCByZWxh dGl2ZWx5IGVhc3kgdG8gYWRkIGZpZWxkcyB0byBlYWNoIG51bWJlciByZWNvcmQsIHdpdGhvdXQg bW9yZSB0aGFuIGEgcmVnaXN0cmF0aW9uIChJQU5BLXN0eWxlKSBtZWNoYW5pc20sIGJ1dCBJIHdh bnQgdG8gZ2V0IGEgc2Vuc2Ugb2YgdGhlIHJhbmdlIG9mIGRhdGEgdHlwZXMgd2UgbWF5IGZpbmQu IEkgW2Fubm90YXRlZF0gdGhlIGxpc3QgYWJvdmUgd2l0aCBteSBndWVzcyBhbmQgd2VsY29tZSBj b3JyZWN0aW9ucy4NCg0KRnJvbTogS2VuIFBvZ3JhbiBbbWFpbHRvOmtlbkBlZ2guY29tXQ0KU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDE6NDEgUE0NClRvOiBIZW5uaW5nIFNjaHVs enJpbm5lDQpDYzogSG9sbWVzLCBEYXZpZCBXIFtDVE9dOyBtb2Rlcm5AaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbTW9kZXJuXSBTZXJ2aWNlcw0KDQpIZW5uaW5nLA0KDQpXaGVuIHRoaXMgdGhyZWFk IHdhcyBhY3RpdmUgYmFjayBpbiBPY3RvYmVyLCBJIHNlbnQgYW4gZW1haWwgKFNlZSBodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbW9kZXJuL2N1cnJlbnQvbXNnMDAwNzcuaHRt bCkgdGhhdCBtYXkgaGF2ZSBiZWVuIG1pc3NlZCwgYXMgaXQgc29tZWhvdyBnb3QgbWFya2VkICJT UEFNIiAoYXQgbGVhc3QsIGluIHRoZSBBcmNoaXZlKS4gICBJbiB0aGF0IGVtYWlsIEkgY29tbWVu dGVkIG9uICJpbmZvcm1hdGlvbiBhc3NvY2lhdGVkIHdpdGggcGhvbmUgbnVtYmVycyIgaW4gdGhl IFBTVE4gTGluZSBJbmZvcm1hdGlvbiBEYXRhYmFzZSAoTElEQiksIGFuZCBwb2ludGVkIHRvIGNv bW1lbnRzIG15IGNvbXBhbnkgc3VibWl0dGVkIHRvIHRoZSBGQ0MgaW4gdGhlIDEzLTUgcHJvY2Vl ZGluZywgYW5kIGVhcmxpZXIsIGRpc2N1c3NpbmcgdGhlIHJhbmdlIG9mIFROIGRhdGEgZWxlbWVu dHMgaW4gTElEQiBhbmQgdGhlIHBvc3QtdHJhbnNpdGlvbiByZWxldmFuY2Ugb2YgYSBzdWJzZXQg b2YgdGhlbSAoc3VjaCBhcyBDYWxsaW5nIE5hbWUpLg0KDQpPbmUgcXVlc3Rpb24gaXMgd2hlcmUg dGhvc2Ugc3Vydml2aW5nIFROIGRhdGEgZWxlbWVudHMgd2lsbCBiZSBzdG9yZWQsIHBvc3QtdHJh bnNpdGlvbiwgYW5kIGhvdyB0aGV5IHdpbGwgYmUgcHJvdmlzaW9uZWQuIFNpbmNlIG1vc3QgTElE QiBkYXRhIGVsZW1lbnRzIGFyZSBQU1ROLXNwZWNpZmljLCBvciBwZXJ0YWluIHRvIHN1YnNjcmli ZXIgc2VydmljZXMgdGhhdCBhcmUgbGlrZWx5IHRvIGJlIGRpc2NvbnRpbnVlZCwgaXQgaXMgdW5s aWtlbHkgdGhhdCBMSURCIGl0c2VsZiB3aWxsIGNvbnRpbnVlIHRvIGV4aXN0LCBvbmNlIHRoZSBQ U1ROIHRyYW5zaXRpb24gaXMgY29tcGxldGUuDQoNClByb3Zpc2lvbmluZyBzeXN0ZW1zIHVzZWQg dG9kYXksIHRoYXQgc2l0IGJldHdlZW4gYnVzaW5lc3Mvb3JkZXJpbmcgc3lzdGVtcyBhbmQgTElE QiwgdHlwaWNhbGx5IGhvbGQgYSBjb21wbGV0ZSByZWNvcmQgb2YgVE4gZGF0YSBlbGVtZW50cy4g VGhleSBhcmUgd2VsbCBwb3NpdGlvbmVkIHRvIHByb3ZpZGUgYSBjb252ZW5pZW50IHBvaW50IG9m IGxldmVyYWdlLCBhcyBuZXcgbmV0d29yayBkYXRhYmFzZXMgYXJlIGludHJvZHVjZWQgYW5kIG9s ZCBvbmVzIHJldGlyZWQuDQoNCktlbiBQb2dyYW4NCg0KDQo= --_000_E6A16181E5FD2F46B962315BB05962D05BE0CDFFp2pxmb13fccnetw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRo ZSByZW1pbmRlciBhbmQgcG9pbnRlci4gSGVyZeKAmXMgdGhlIGxpc3QgZm9yIGNvbnZlbmllbmNl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VE4gb3duZXJzaGlwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7v grcgQXV0aG9yaXRhdGl2ZSBDYWxsaW5nIE5hbWUgKENOQU0pOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlsxNiBjaGFyYWN0ZXIgdGV4dCBub3c7 IG1vcmUgZWxhYm9yYXRlIGZvciBDTkFNJiM0MzsmIzQzO108bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+74K3IEJpbGwgTnVtYmVyIFNjcmVlbmluZywgZm9yIGNvbGxlY3QgY2FsbGluZyBh bmQgY2FsbHMgYmlsbGVkIHRvIHRoaXJkIHBhcnRpZXM7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+W2Jvb2xlYW5dPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ 74K3IE9yaWdpbmF0aW5nIExpbmUgTnVtYmVyIFNjcmVlbmluZyBmb3IgcHJpc29uIGxpbmVzIChh bHJlYWR5IHRoZSBzdWJqZWN0IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFub3Ro ZXIgRkNDIHByb2NlZWRpbmcpIGFuZCBob3RlbCByb29tcywgYXMgd2VsbCBhcyBmb3Igb3B0aW9u YWwgc2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YmlsbGVkIHRvIHRoZSBv cmlnaW5hdGluZyBsaW5lOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpyZWQiPltCb29sZWFuXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7vgrcgU2Vydmlj ZSBhbmQgRXF1aXBtZW50IEluZGljYXRvciwgdXNlZCB0byBkZXRlcm1pbmUgdHJlYXRtZW50IG9m IGNhbGxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm9yaWdpbmF0ZWQgYnkgdGhlIFRO PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPjsgWz9dPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPu+CtyBaSVAmIzQzOzQsIHVzZWQgaW4g4oCcMzEx4oCd IGluZm9ybWF0aW9uIHNlcnZpY2VzIHJvdXRpbmc7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOnJlZCI+WzkgZGlnaXRzXTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPu+C tyBMaW5lLWJhc2VkIGNhbGxpbmcgY2FyZCBQSU5zLCAodG8gdGhlIGV4dGVudCB0aGVzZSBhcmUg cmV0YWluZWQgaW4gdGhlIGFsbC1JUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5uZXR3 b3JrKTsgYW5kIFtzZWVtcyBsaWtlbHkgdG8gZGlzYXBwZWFyLCBidXQgcG9zc2libHkgYSBoYXNo XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7vgrcgUElDIGFuZCBMUElDLCBpbnRlcmV4 Y2hhbmdlIGNhcnJpZXIgZGVzaWduYXRpb25zICh0byB0aGUgZXh0ZW50IHRoZXNlIGFyZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5yZXRhaW5lZCBpbiB0aGUgYWxsLUlQIG5ldHdvcmsp Lg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPltpbnRlZ2Vy c108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgc3VzcGVjdCB3ZeKAmWxsIHdhbnQgYSBzeXN0ZW0gdGhhdCBtYWtlcyBp dCByZWxhdGl2ZWx5IGVhc3kgdG8gYWRkIGZpZWxkcyB0byBlYWNoIG51bWJlciByZWNvcmQsIHdp dGhvdXQgbW9yZSB0aGFuIGEgcmVnaXN0cmF0aW9uIChJQU5BLXN0eWxlKSBtZWNoYW5pc20sIGJ1 dA0KIEkgd2FudCB0byBnZXQgYSBzZW5zZSBvZiB0aGUgcmFuZ2Ugb2YgZGF0YSB0eXBlcyB3ZSBt YXkgZmluZC4gSSBbYW5ub3RhdGVkXSB0aGUgbGlzdCBhYm92ZSB3aXRoIG15IGd1ZXNzIGFuZCB3 ZWxjb21lIGNvcnJlY3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEtlbiBQb2dyYW4gW21haWx0 bzprZW5AZWdoLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjgs IDIwMTUgMTo0MSBQTTxicj4NCjxiPlRvOjwvYj4gSGVubmluZyBTY2h1bHpyaW5uZTxicj4NCjxi PkNjOjwvYj4gSG9sbWVzLCBEYXZpZCBXIFtDVE9dOyBtb2Rlcm5AaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtNb2Rlcm5dIFNlcnZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+SGVubmluZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+V2hlbiB0aGlzIHRocmVhZCB3YXMgYWN0aXZlIGJhY2sgaW4gT2N0b2JlciwgSSBzZW50IGFu IGVtYWlsIChTZWUmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbW9kZXJuL2N1cnJlbnQvbXNnMDAwNzcuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL21vZGVybi9jdXJyZW50L21zZzAwMDc3Lmh0bWw8L2E+KQ0KIHRoYXQg bWF5IGhhdmUgYmVlbiBtaXNzZWQsIGFzIGl0IHNvbWVob3cgZ290IG1hcmtlZCAmcXVvdDtTUEFN JnF1b3Q7IChhdCBsZWFzdCwgaW4gdGhlIEFyY2hpdmUpLiAmbmJzcDsgSW4gdGhhdCBlbWFpbCBJ IGNvbW1lbnRlZCBvbiAmcXVvdDtpbmZvcm1hdGlvbiBhc3NvY2lhdGVkIHdpdGggcGhvbmUgbnVt YmVycyZxdW90OyBpbiB0aGUgUFNUTiBMaW5lIEluZm9ybWF0aW9uIERhdGFiYXNlIChMSURCKSwg YW5kIHBvaW50ZWQgdG8gY29tbWVudHMgbXkgY29tcGFueSBzdWJtaXR0ZWQgdG8NCiB0aGUgRkND IGluIHRoZSAxMy01IHByb2NlZWRpbmcsIGFuZCBlYXJsaWVyLCBkaXNjdXNzaW5nIHRoZSByYW5n ZSBvZiBUTiBkYXRhIGVsZW1lbnRzIGluIExJREIgYW5kIHRoZSBwb3N0LXRyYW5zaXRpb24gcmVs ZXZhbmNlIG9mIGEgc3Vic2V0IG9mIHRoZW0gKHN1Y2ggYXMgQ2FsbGluZyBOYW1lKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T25lIHF1ZXN0aW9uIGlzIHdoZXJlIHRob3Nl IHN1cnZpdmluZyBUTiBkYXRhIGVsZW1lbnRzIHdpbGwgYmUgc3RvcmVkLCBwb3N0LXRyYW5zaXRp b24sIGFuZCBob3cgdGhleSB3aWxsIGJlIHByb3Zpc2lvbmVkLiBTaW5jZSBtb3N0IExJREIgZGF0 YSBlbGVtZW50cyBhcmUgUFNUTi1zcGVjaWZpYywNCiBvciBwZXJ0YWluIHRvIHN1YnNjcmliZXIg c2VydmljZXMgdGhhdCBhcmUgbGlrZWx5IHRvIGJlIGRpc2NvbnRpbnVlZCwgaXQgaXMgdW5saWtl bHkgdGhhdCBMSURCIGl0c2VsZiB3aWxsIGNvbnRpbnVlIHRvIGV4aXN0LCBvbmNlIHRoZSBQU1RO IHRyYW5zaXRpb24gaXMgY29tcGxldGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlByb3Zpc2lvbmluZyBzeXN0ZW1zIHVzZWQgdG9kYXksIHRoYXQgc2l0IGJldHdlZW4gYnVz aW5lc3Mvb3JkZXJpbmcgc3lzdGVtcyBhbmQgTElEQiwgdHlwaWNhbGx5IGhvbGQgYSBjb21wbGV0 ZSByZWNvcmQgb2YgVE4gZGF0YSBlbGVtZW50cy4gVGhleSBhcmUgd2VsbCBwb3NpdGlvbmVkDQog dG8gcHJvdmlkZSBhIGNvbnZlbmllbnQgcG9pbnQgb2YgbGV2ZXJhZ2UsIGFzIG5ldyBuZXR3b3Jr IGRhdGFiYXNlcyBhcmUgaW50cm9kdWNlZCBhbmQgb2xkIG9uZXMgcmV0aXJlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+S2VuIFBvZ3JhbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E6A16181E5FD2F46B962315BB05962D05BE0CDFFp2pxmb13fccnetw_-- From nobody Wed Jan 28 12:58:36 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D171A1A94 for ; Wed, 28 Jan 2015 12:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru5NFVxoH5J3 for ; Wed, 28 Jan 2015 12:58:32 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88C1A1A50 for ; Wed, 28 Jan 2015 12:58:31 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "Holmes, David W [CTO]" , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGsgAP8KoCABP4I64AAWXOAgI72jyOAAvj0gP//zr1s Date: Wed, 28 Jan 2015 20:58:30 +0000 References: , , <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Gorman, Pierce A \[NTK\]" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 20:58:35 -0000 I agree that we'll see a fair amount of variation.=0A= =0A= But I'm confused by your last paragraph: What kind of identifiers did you h= ave in mind? I thought we'd be talking about E.164 numbers?=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Holmes, David W [CTO] [= David.Holmes@sprint.com]=0A= Sent: Wednesday, January 28, 2015 1:53 PM=0A= To: Henning Schulzrinne; McGarry, Tom; modern@ietf.org=0A= Cc: Gorman, Pierce A [NTK]=0A= Subject: Re: [Modern] Services=0A= =0A= Hi Henning,=0A= =0A= I suspect that "information associated with E.164 phone numbers" is highly = inconsistent in nature, as, once the "country"-level information is allocat= ed to the per-"country" administrators, I do not believe that there is any = requirement to have a standard set of information collected for the entitie= s to whom those administrators allocate numbers; I suspect we can only pres= ume entity name & potentially business address; & similar for the end custo= mers to whom the carriers allocate individual numbers from the blocks they = are given by their national number administrators. So while we may have lo= cal stores of more associated data sets (like LIDB), these are not universa= l.=0A= =0A= What is your interest in the information associated with a particular ident= ifier type? I was suggesting that a first step would be to generate a list= of identifiers & their technical characteristics.=0A= From nobody Wed Jan 28 14:37:05 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C481A1A51 for ; Wed, 28 Jan 2015 14:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFOPZPsQA4xX for ; Wed, 28 Jan 2015 14:36:59 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37221A1A34 for ; Wed, 28 Jan 2015 14:36:59 -0800 (PST) Received: from BL2FFO11HUB062.protection.gbl (10.173.161.162) by BL2FFO11HUB050.protection.gbl (10.173.161.126) with Microsoft SMTP Server (TLS) id 15.1.75.11; Wed, 28 Jan 2015 22:36:58 +0000 Received: from BL2FFO11FD006.protection.gbl (10.173.160.31) by BL2FFO11HUB062.protection.gbl (10.173.161.162) with Microsoft SMTP Server (TLS) id 15.1.75.11; Wed, 28 Jan 2015 22:36:57 +0000 Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Wed, 28 Jan 2015 22:36:56 +0000 Received: from pdaasen1.corp.sprint.com (mailhost.it.sprintspectrum.com [144.226.111.128]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t0SMatZn001464 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2015 16:36:55 -0600 Received: from PREWE13M07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by pdaasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t0SMas1I024490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Jan 2015 16:36:55 -0600 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 28 Jan 2015 17:36:54 -0500 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.0995.028; Wed, 28 Jan 2015 16:36:53 -0600 From: "Holmes, David W [CTO]" To: Henning Schulzrinne , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7OopwzhHMAgAA62ICAANOHAIAAECQAgABedoCAAFw5AIABixeAgAGUfICAAN2CAIAAAc6AgAAD1oCAAOByAIAA7LGAgAAG+ACAABMaAIAAo2qAgAP6NACABP8hgP//uzgggI+pWQCAAjIAQIAAkRIA//+qWcA= Date: Wed, 28 Jan 2015 22:36:52 +0000 Message-ID: <598688ae92e5439fa1bc5a69aee12e06@PLSWE13M01.ad.sprint.com> References: , , <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.91.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.56 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.56; helo=pdaasdm1.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.56) smtp.mailfrom=David.Holmes@sprint.com; fcc.gov; dkim=none (message not signed) header.d=none;fcc.gov; dmarc=permerror action=none header.from=sprint.com; X-Forefront-Antispam-Report: CIP:144.229.32.56; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(50986999)(106466001)(76176999)(106116001)(2950100001)(92566002)(23726002)(54356999)(33646002)(46406003)(46102003)(2501002)(6806004)(86362001)(19580405001)(102836002)(92726002)(77156002)(93886004)(2656002)(15975445007)(62966003)(2900100001)(87936001)(19580395003)(50466002)(108616004)(47776003)(97756001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB062; H:pdaasdm1.corp.sprint.com; FPR:; SPF:None; MLV:sfv; LANG:en; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BL2FFO11HUB062; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BL2FFO11HUB062; X-Forefront-PRVS: 047001DADA X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB062; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2015 22:36:56.9618 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.229.32.56] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB062 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB050; X-OriginatorOrg: sprint.com Archived-At: Cc: "Gorman, Pierce A \[NTK\]" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 22:37:03 -0000 Hi Henning, Going back to my mail from last October, my strong suggestion was that if t= he desire is to create some kind of optimum solution for service delivery i= dentifiers, requirements should be defined first (i.e. both optimum behavio= r & issues with current solutions) & use that as a basis for defining/selec= ting solutions, per (e.g.) the techniques described in ITU I.130. The emai= l threads from that period contain many of the needed requirements, but I s= uggested that a good starting point would be to look at the properties of a= few of the current options, maybe focusing on E.164; properties like who a= llocates them, how they are allocated, how they are used for routing, how t= hey are discovered, etc. BR/David -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: Wednesday, January 28, 2015 3:59 PM To: Holmes, David W [CTO]; McGarry, Tom; modern@ietf.org Cc: Gorman, Pierce A [NTK] Subject: Re: [Modern] Services I agree that we'll see a fair amount of variation. But I'm confused by your last paragraph: What kind of identifiers did you h= ave in mind? I thought we'd be talking about E.164 numbers? ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Holmes, David W [CTO] [= David.Holmes@sprint.com] Sent: Wednesday, January 28, 2015 1:53 PM To: Henning Schulzrinne; McGarry, Tom; modern@ietf.org Cc: Gorman, Pierce A [NTK] Subject: Re: [Modern] Services Hi Henning, I suspect that "information associated with E.164 phone numbers" is highly = inconsistent in nature, as, once the "country"-level information is allocat= ed to the per-"country" administrators, I do not believe that there is any = requirement to have a standard set of information collected for the entitie= s to whom those administrators allocate numbers; I suspect we can only pres= ume entity name & potentially business address; & similar for the end custo= mers to whom the carriers allocate individual numbers from the blocks they = are given by their national number administrators. So while we may have lo= cal stores of more associated data sets (like LIDB), these are not universa= l. What is your interest in the information associated with a particular ident= ifier type? I was suggesting that a first step would be to generate a list= of identifiers & their technical characteristics. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Jan 28 20:02:42 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9671A1B55 for ; Wed, 28 Jan 2015 20:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBDo4BWdkLdB for ; Wed, 28 Jan 2015 20:02:32 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 344381A1B67 for ; Wed, 28 Jan 2015 20:02:31 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "Holmes, David W [CTO]" , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGsgAP8KoCABP4I64AAWXOAgI72jyOAAvj0gP//zr1sAA3y+wAAAHHjSA== Date: Thu, 29 Jan 2015 04:01:48 +0000 References: , , <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> , , <598688ae92e5439fa1bc5a69aee12e06@PLSWE13M01.ad.sprint.com> In-Reply-To: <598688ae92e5439fa1bc5a69aee12e06@PLSWE13M01.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Gorman, Pierce A \[NTK\]" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 04:02:37 -0000 I suspect we may be talking about two different problems. My sense is that = MODERN is discussing allocation of E.164 identifiers, probably within a nat= ional or similar (+1) scope. Service identifiers may be added as a feature = (facet, field, ...) of the database, possibly including as a (part of the) = primary key, as in =0A= =0A= +12025551234/telephony =0A= =0A= (to follow I.240)=0A= =0A= One generic model is to allow for a two-part primary key consisting of an E= .164 number and a modifier (opaque string) that is then defined by (say) AT= IS or other, more operationally-oriented, bodies.=0A= =0A= I wonder if others have a different perception.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Holmes, David W [CTO] [David.Holmes@sprint.com]=0A= Sent: Wednesday, January 28, 2015 5:36 PM=0A= To: Henning Schulzrinne; McGarry, Tom; modern@ietf.org=0A= Cc: Gorman, Pierce A [NTK]=0A= Subject: RE: [Modern] Services=0A= =0A= Hi Henning,=0A= =0A= Going back to my mail from last October, my strong suggestion was that if t= he desire is to create some kind of optimum solution for service delivery i= dentifiers, requirements should be defined first (i.e. both optimum behavio= r & issues with current solutions) & use that as a basis for defining/selec= ting solutions, per (e.g.) the techniques described in ITU I.130. The emai= l threads from that period contain many of the needed requirements, but I s= uggested that a good starting point would be to look at the properties of a= few of the current options, maybe focusing on E.164; properties like who a= llocates them, how they are allocated, how they are used for routing, how t= hey are discovered, etc.=0A= =0A= BR/David=0A= =0A= -----Original Message-----=0A= From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne=0A= Sent: Wednesday, January 28, 2015 3:59 PM=0A= To: Holmes, David W [CTO]; McGarry, Tom; modern@ietf.org=0A= Cc: Gorman, Pierce A [NTK]=0A= Subject: Re: [Modern] Services=0A= =0A= I agree that we'll see a fair amount of variation.=0A= =0A= But I'm confused by your last paragraph: What kind of identifiers did you h= ave in mind? I thought we'd be talking about E.164 numbers?=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Holmes, David W [CTO] [= David.Holmes@sprint.com]=0A= Sent: Wednesday, January 28, 2015 1:53 PM=0A= To: Henning Schulzrinne; McGarry, Tom; modern@ietf.org=0A= Cc: Gorman, Pierce A [NTK]=0A= Subject: Re: [Modern] Services=0A= =0A= Hi Henning,=0A= =0A= I suspect that "information associated with E.164 phone numbers" is highly = inconsistent in nature, as, once the "country"-level information is allocat= ed to the per-"country" administrators, I do not believe that there is any = requirement to have a standard set of information collected for the entitie= s to whom those administrators allocate numbers; I suspect we can only pres= ume entity name & potentially business address; & similar for the end custo= mers to whom the carriers allocate individual numbers from the blocks they = are given by their national number administrators. So while we may have lo= cal stores of more associated data sets (like LIDB), these are not universa= l.=0A= =0A= What is your interest in the information associated with a particular ident= ifier type? I was suggesting that a first step would be to generate a list= of identifiers & their technical characteristics.=0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= =0A= From nobody Thu Jan 29 07:32:18 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8161A1AAD for ; Thu, 29 Jan 2015 07:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.608 X-Spam-Level: X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzFRunaDlkon for ; Thu, 29 Jan 2015 07:32:08 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8750D1A1A39 for ; Thu, 29 Jan 2015 07:32:08 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-e5-54c9f3567dac Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C7.83.25146.653F9C45; Thu, 29 Jan 2015 09:46:14 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 10:32:05 -0500 From: Erik Chuss To: "PFAUTZ, PENN L" , "modern@ietf.org" Thread-Topic: protocols for number management? Thread-Index: AdA7HfdFgw8QrcWbTt2oVjEiLzc30gAtjUvg Date: Thu, 29 Jan 2015 15:32:05 +0000 Message-ID: <7DDE171004B40E49BC418D2229EC06533923F422@eusaamb105.ericsson.se> References: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7DDE171004B40E49BC418D2229EC06533923F422eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPuG7Y55MhBq/fSlpc2s9kce/rGhYH Jo+X/XMYPZYs+ckUwBTFZZOSmpNZllqkb5fAlfFp6kfmgq/+FafvHGdvYLzv0sXIySEhYCKx +MR1JghbTOLCvfVsXYxcHEICRxgl+h+dZIZwljNKTJ47jxGkik1AS6Ll1zxmEFtEwEti0amv QB0cHMwCGhI/5hmBhIUFdCXe/9/EClGiJ/Hi3iIWCNtIYvHN9ewgNouAqsSa5y1gcV4BX4nO 6ZPBxgsJRErc2dgL1sspECWx8dRXsOMYgY77fmoNmM0sIC5x68l8qKMFJJbsOc8MYYtKvHz8 jxXCVpTY1z+dHaI+X+LP3z/MELsEJU7OfMIygVF0FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzh a2YY+8yBx0zI4gsY2VcxcpQWp5blphsZbmIExtQxCTbHHYwLPlkeYhTgYFTi4d1geDJEiDWx rLgy9xCjNAeLkjhv2ZWDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYd+o29DJnx7b9WRuk /e/KgXsPdipqBZ/sOPv/dvHRyM2Oz4t+XnK9lv2x5bya7by7D9dLndLt2WDOfj9aofeWo1+R bu4lwQ69V15qG04+qthsO+G/0dwvz0v1WQIOLL1jEOJaXPbua+gELiGDKaH3/2gaVH6v85ts HnT3VHP0J//PGiv4pWd9UmIpzkg01GIuKk4EAM5OE82KAgAA Archived-At: Cc: Erik Chuss Subject: Re: [Modern] protocols for number management? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:32:16 -0000 --_000_7DDE171004B40E49BC418D2229EC06533923F422eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Penn, In thinking about this, in order to help facilitate the discussion and iden= tify potential test bed solutions, what do you envision the appropriate pro= visioning information to be used for? As you know the Toll Free system has= supported, what we have called 'line-level number allocation', since the e= arly 1900's. The number administration of the system piece allows for cent= ralized access to numbering resources and equal access to the resources on = a 'first in/first out' basis. It keeps track of the numbering lifecycle by = storing the status of each number (Spare, Reserved, Working, Transitional, = Disconnect, etc.). It is also used to identify the Responsible Organizatio= n (Resp Org) of a number and ensures only updates to provisioning be made b= y the Resp Org of the number (i.e. provisioning security). There are, of c= ourse, more functions of the number admin piece but I just wanted to mentio= n a few high-level topics. A distributed solution may present special chal= lenges for these items that would need to be addressed. The key piece thou= gh is the provisioning piece. How do you or the others foresee the system = be used for in terms of provisioning appropriate information in the network= ? Would it just be used for validation on a 'push' basis where the informa= tion is distributed to the service providers automatically who can then use= it as they see fit or opening the system up for query on an as needed basi= s? Is there some other functionality that could be included? I hope this helps with the initial discussion and facilities expanded discu= ssion. Erik J. Chuss North America Toll Free Number Administrator DSMI/Ericsson, Inc. RRC-4A1142 1 Ericsson Drive Piscataway, NJ 08854 Phone: 1-732-699-3422 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, January 28, 2015 12:12 PM To: modern@ietf.org Subject: [Modern] protocols for number management? ATIS has a landscape testbed activity assembling various use cases that mig= ht be examined in a testbed. One of them involves inventory-less just-in-time number assignment within t= he framework of the kind of unfied numbering lifecycle management platform = discussed at the FCC Numbering Testbed Workshop back in March of 2014. The question came up as to what sort of protocols might be appropriate for = service providers to interact with the registry provider(s), to find availa= ble resources, request assignments, and provision appropriate information f= or distribution to other SPs once the assignment is made. Mechanisms to acc= ommodate this a distributed registry architecture are also of interest (how= to make sure the same number isn't assigned by two different registry pro= viders in a race condition) It occurred to me folks on this list might have some suggestions. Thanks, Penn Pfautz AT&T Global Connection Management +1-732-420-4962 --_000_7DDE171004B40E49BC418D2229EC06533923F422eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Penn,

 

In thinking about this= , in order to help facilitate the discussion and identify potential test be= d solutions, what do you envision the appropriate provisioning information = to be used for?  As you know the Toll Free system has supported, what we have called ‘line-level number al= location’, since the early 1900’s.  The number administrat= ion of the system piece allows for centralized access to numbering resource= s and equal access to the resources on a ‘first in/first out’ basis. It keeps track of the numbering lifecycle by storing the= status of each number (Spare, Reserved, Working, Transitional, Disconnect,= etc.).  It is also used to identify the Responsible Organization (Res= p Org) of a number and ensures only updates to provisioning be made by the Resp Org of the number (i.e. provisioning s= ecurity).  There are, of course, more functions of the number admin pi= ece but I just wanted to mention a few high-level topics.  A distribut= ed solution may present special challenges for these items that would need to be addressed.  The key piece thoug= h is the provisioning piece.  How do you or the others foresee the sys= tem be used for in terms of provisioning appropriate information in the net= work?  Would it just be used for validation on a ‘push’ basis where the information is distributed to the = service providers automatically who can then use it as they see fit or open= ing the system up for query on an as needed basis?  Is there some othe= r functionality that could be included?

 

I hope this helps with= the initial discussion and facilities expanded discussion.

 

Erik J. Chuss

North America Toll Fre= e Number Administrator

DSMI/Ericsson, Inc.

RRC-4A1142<= /span>

1 Ericsson Drive<= /o:p>

Piscataway, NJ 08854

Phone: 1-732-699-3422<= /span>

 

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L
Sent: Wednesday, January 28, 2015 12:12 PM
To: modern@ietf.org
Subject: [Modern] protocols for number management?=

 

ATIS has a landscape testbed activity assembling var= ious use cases that might be examined in a testbed.

One of them involves inventory-less just-in-time num= ber assignment within the framework of the kind of unfied numbering lifecyc= le management platform discussed at the FCC Numbering Testbed Workshop back= in March of 2014.

 

The question came up as to what sort of protocols mi= ght be appropriate for service providers to interact with the registry prov= ider(s), to find available resources, request assignments, and provision ap= propriate information for distribution to other SPs once the assignment is made. Mechanisms to accommodate this a= distributed registry architecture are also of interest (how to make sure t= he same number isn’t assigned by two different  registry provide= rs in a race condition)

 

It occurred to me folks on this list might have some= suggestions.

 

Thanks,

Penn Pfautz

AT&T Global Connection Management

+1-732-420-4962

--_000_7DDE171004B40E49BC418D2229EC06533923F422eusaamb105erics_-- From nobody Thu Jan 29 07:47:02 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D351A1B5F for ; Thu, 29 Jan 2015 07:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu1h0nZZaErz for ; Thu, 29 Jan 2015 07:46:58 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC551A1BF2 for ; Thu, 29 Jan 2015 07:46:44 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) with ESMTP id 5e55ac45.2b29e2e6a940.6571209.00-2436.18366914.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 29 Jan 2015 15:46:45 +0000 (UTC) X-MXL-Hash: 54ca55e5213cf42e-0700b6685c6e9e05bfaa01e772fe2817a52219f9 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id bd55ac45.0.6571039.00-2254.18366405.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 29 Jan 2015 15:46:39 +0000 (UTC) X-MXL-Hash: 54ca55df69e3f51a-b1c33f006c6b73f3209769e31abb95884a3166e3 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0TFkX4d020433; Thu, 29 Jan 2015 10:46:35 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0TFkQUh020151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jan 2015 10:46:28 -0500 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 29 Jan 2015 15:46:09 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.63]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 10:46:09 -0500 From: "PFAUTZ, PENN L" To: Erik Chuss , "modern@ietf.org" Thread-Topic: protocols for number management? Thread-Index: AdA7HfdFgw8QrcWbTt2oVjEiLzc30gAtjUvgAAGXA3A= Date: Thu, 29 Jan 2015 15:46:09 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60578A513@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com> <7DDE171004B40E49BC418D2229EC06533923F422@eusaamb105.ericsson.se> In-Reply-To: <7DDE171004B40E49BC418D2229EC06533923F422@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] Content-Type: multipart/alternative; boundary="_000_38726EDA2109264987B45E29E758C4D60578A513MISOUT7MSGUSRDD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=I+DSsqcg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=0FD05c-RAAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=KNvMrXTunjaAM-fJ298A:9 a=CjuIK1q_8ugA:10 a=GCaqL0eA] X-AnalysisOut: [ZMYA:10 a=iE9YWIBck50A:10 a=iwMj6UG405-5qpYn:21 a=41QbLS60] X-AnalysisOut: [XjDMlIxV:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ZnpHeQkz7f] X-AnalysisOut: [a62VG-g8IA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Y] X-AnalysisOut: [k6K0A:10 a=frz4AuCg-hUA:10 a=s4nh0trX65Mqzxak:21 a=cTsacTb] X-AnalysisOut: [alb5eZR04:21 a=-YUtlUaQpF3h7SYG:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Modern] protocols for number management? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:47:01 -0000 --_000_38726EDA2109264987B45E29E758C4D60578A513MISOUT7MSGUSRDD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Erik: I would expect much of the functionality to be similar to SMS/800 with some= tweaks The numbering space would be more segmented, e.g. by geography and assignme= nt rules would differ. The users would be SPs not RespOrgs. Don't know whether direct query would be supported or not but the info pro= vided in either case would not include service logic. I would expect the protocol to differ just because technology has become mo= re sophisticated Thanks, Penn From: Erik Chuss [mailto:erik.chuss@ericsson.com] Sent: Thursday, January 29, 2015 10:32 AM To: PFAUTZ, PENN L; modern@ietf.org Cc: Erik Chuss Subject: RE: protocols for number management? Penn, In thinking about this, in order to help facilitate the discussion and iden= tify potential test bed solutions, what do you envision the appropriate pro= visioning information to be used for? As you know the Toll Free system has= supported, what we have called 'line-level number allocation', since the e= arly 1900's. The number administration of the system piece allows for cent= ralized access to numbering resources and equal access to the resources on = a 'first in/first out' basis. It keeps track of the numbering lifecycle by = storing the status of each number (Spare, Reserved, Working, Transitional, = Disconnect, etc.). It is also used to identify the Responsible Organizatio= n (Resp Org) of a number and ensures only updates to provisioning be made b= y the Resp Org of the number (i.e. provisioning security). There are, of c= ourse, more functions of the number admin piece but I just wanted to mentio= n a few high-level topics. A distributed solution may present special chal= lenges for these items that would need to be addressed. The key piece thou= gh is the provisioning piece. How do you or the others foresee the system = be used for in terms of provisioning appropriate information in the network= ? Would it just be used for validation on a 'push' basis where the informa= tion is distributed to the service providers automatically who can then use= it as they see fit or opening the system up for query on an as needed basi= s? Is there some other functionality that could be included? I hope this helps with the initial discussion and facilities expanded discu= ssion. Erik J. Chuss North America Toll Free Number Administrator DSMI/Ericsson, Inc. RRC-4A1142 1 Ericsson Drive Piscataway, NJ 08854 Phone: 1-732-699-3422 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, January 28, 2015 12:12 PM To: modern@ietf.org Subject: [Modern] protocols for number management? ATIS has a landscape testbed activity assembling various use cases that mig= ht be examined in a testbed. One of them involves inventory-less just-in-time number assignment within t= he framework of the kind of unfied numbering lifecycle management platform = discussed at the FCC Numbering Testbed Workshop back in March of 2014. The question came up as to what sort of protocols might be appropriate for = service providers to interact with the registry provider(s), to find availa= ble resources, request assignments, and provision appropriate information f= or distribution to other SPs once the assignment is made. Mechanisms to acc= ommodate this a distributed registry architecture are also of interest (how= to make sure the same number isn't assigned by two different registry pro= viders in a race condition) It occurred to me folks on this list might have some suggestions. Thanks, Penn Pfautz AT&T Global Connection Management +1-732-420-4962 --_000_38726EDA2109264987B45E29E758C4D60578A513MISOUT7MSGUSRDD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Erik:

I would expect much of= the functionality to be similar to SMS/800 with some tweaks

The numbering space wo= uld be more segmented, e.g. by geography and assignment rules would differ.= The users would be SPs not RespOrgs.

Don’t know wheth= er direct query would be supported or not  but the info provided in ei= ther case would not include service logic.

I would expect the pro= tocol to differ just because technology has become more sophisticated<= /o:p>

 

Thanks,

Penn=

 

From: Erik Chu= ss [mailto:erik.chuss@ericsson.com]
Sent: Thursday, January 29, 2015 10:32 AM
To: PFAUTZ, PENN L; modern@ietf.org
Cc: Erik Chuss
Subject: RE: protocols for number management?

 

Penn,

 

In thinking about this= , in order to help facilitate the discussion and identify potential test be= d solutions, what do you envision the appropriate provisioning information = to be used for?  As you know the Toll Free system has supported, what we have called ‘line-level number al= location’, since the early 1900’s.  The number administrat= ion of the system piece allows for centralized access to numbering resource= s and equal access to the resources on a ‘first in/first out’ basis. It keeps track of the numbering lifecycle by storing the= status of each number (Spare, Reserved, Working, Transitional, Disconnect,= etc.).  It is also used to identify the Responsible Organization (Res= p Org) of a number and ensures only updates to provisioning be made by the Resp Org of the number (i.e. provisioning s= ecurity).  There are, of course, more functions of the number admin pi= ece but I just wanted to mention a few high-level topics.  A distribut= ed solution may present special challenges for these items that would need to be addressed.  The key piece thoug= h is the provisioning piece.  How do you or the others foresee the sys= tem be used for in terms of provisioning appropriate information in the net= work?  Would it just be used for validation on a ‘push’ basis where the information is distributed to the = service providers automatically who can then use it as they see fit or open= ing the system up for query on an as needed basis?  Is there some othe= r functionality that could be included?

 

I hope this helps with= the initial discussion and facilities expanded discussion.

 

Erik J. Chuss

North America Toll Fre= e Number Administrator

DSMI/Ericsson, Inc.

RRC-4A1142<= /span>

1 Ericsson Drive<= /o:p>

Piscataway, NJ 08854

Phone: 1-732-699-3422<= o:p>

 

 

ATIS has a landscape testbed activity assembling var= ious use cases that might be examined in a testbed.

One of them involves inventory-less just-in-time num= ber assignment within the framework of the kind of unfied numbering lifecyc= le management platform discussed at the FCC Numbering Testbed Workshop back= in March of 2014.

 

The question came up as to what sort of protocols mi= ght be appropriate for service providers to interact with the registry prov= ider(s), to find available resources, request assignments, and provision ap= propriate information for distribution to other SPs once the assignment is made. Mechanisms to accommodate this a= distributed registry architecture are also of interest (how to make sure t= he same number isn’t assigned by two different  registry provide= rs in a race condition)

 

It occurred to me folks on this list might have some= suggestions.

 

Thanks,

Penn Pfautz

AT&T Global Connection Management

+1-732-420-4962

--_000_38726EDA2109264987B45E29E758C4D60578A513MISOUT7MSGUSRDD_-- From nobody Thu Jan 29 09:01:02 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6CA1A7023 for ; Thu, 29 Jan 2015 09:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.28 X-Spam-Level: * X-Spam-Status: No, score=1.28 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FRT_PENIS1=3.592, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1K7tm-bG0VU for ; Thu, 29 Jan 2015 09:00:59 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 734C71A0105 for ; Thu, 29 Jan 2015 09:00:58 -0800 (PST) Message-ID: From: Henning Schulzrinne To: Erik Chuss , "PFAUTZ, PENN L" , "modern@ietf.org" Thread-Topic: protocols for number management? Thread-Index: AdA7HfdFgw8QrcWbTt2oVjEiLzc30gAtjUvgAAQwoXw= Date: Thu, 29 Jan 2015 17:00:57 +0000 References: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com>, <7DDE171004B40E49BC418D2229EC06533923F422@eusaamb105.ericsson.se> In-Reply-To: <7DDE171004B40E49BC418D2229EC06533923F422@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] protocols for number management? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 17:01:01 -0000 I'm curious to hear more about the likely numbering states. I'm comparing E= PP (domain name) and 800 states, but a good reference to the formal definit= ions and transitions for 800# would be helpful. (Some of it can be deduced = from the CFR rules, but they were obviously not written by protocol designe= rs.) ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Erik Chuss [erik.chuss@= ericsson.com] Sent: Thursday, January 29, 2015 10:32 AM To: PFAUTZ, PENN L; modern@ietf.org Cc: Erik Chuss Subject: Re: [Modern] protocols for number management? Penn, In thinking about this, in order to help facilitate the discussion and iden= tify potential test bed solutions, what do you envision the appropriate pro= visioning information to be used for? As you know the Toll Free system has= supported, what we have called =91line-level number allocation=92, since t= he early 1900=92s. The number administration of the system piece allows fo= r centralized access to numbering resources and equal access to the resourc= es on a =91first in/first out=92 basis. It keeps track of the numbering lif= ecycle by storing the status of each number (Spare, Reserved, Working, Tran= sitional, Disconnect, etc.). It is also used to identify the Responsible O= rganization (Resp Org) of a number and ensures only updates to provisioning= be made by the Resp Org of the number (i.e. provisioning security). There= are, of course, more functions of the number admin piece but I just wanted= to mention a few high-level topics. A distributed solution may present sp= ecial challenges for these items that would need to be addressed. The key = piece though is the provisioning piece. How do you or the others foresee t= he system be used for in terms of provisioning appropriate information in t= he network? Would it just be used for validation on a =91push=92 basis whe= re the information is distributed to the service providers automatically wh= o can then use it as they see fit or opening the system up for query on an = as needed basis? Is there some other functionality that could be included? I hope this helps with the initial discussion and facilities expanded discu= ssion. Erik J. Chuss North America Toll Free Number Administrator DSMI/Ericsson, Inc. RRC-4A1142 1 Ericsson Drive Piscataway, NJ 08854 Phone: 1-732-699-3422 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, January 28, 2015 12:12 PM To: modern@ietf.org Subject: [Modern] protocols for number management? ATIS has a landscape testbed activity assembling various use cases that mig= ht be examined in a testbed. One of them involves inventory-less just-in-time number assignment within t= he framework of the kind of unfied numbering lifecycle management platform = discussed at the FCC Numbering Testbed Workshop back in March of 2014. The question came up as to what sort of protocols might be appropriate for = service providers to interact with the registry provider(s), to find availa= ble resources, request assignments, and provision appropriate information f= or distribution to other SPs once the assignment is made. Mechanisms to acc= ommodate this a distributed registry architecture are also of interest (how= to make sure the same number isn=92t assigned by two different registry p= roviders in a race condition) It occurred to me folks on this list might have some suggestions. Thanks, Penn Pfautz AT&T Global Connection Management +1-732-420-4962 From nobody Thu Jan 29 09:01:27 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4960A1A8758 for ; Thu, 29 Jan 2015 09:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StA0XbHnM1QO for ; Thu, 29 Jan 2015 09:01:23 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id ABD691A0105 for ; Thu, 29 Jan 2015 09:01:22 -0800 (PST) Message-ID: From: Henning Schulzrinne To: Henning Schulzrinne , 'Ken Pogran' Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGsgAP8KoCABP4I64AAWXOAgI72jyOAAvV7gP//zRmwAAAw1uA= Date: Thu, 29 Jan 2015 17:01:21 +0000 References: <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Holmes, David W \[CTO\]" , "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 17:01:25 -0000 Forgot one. TN ownership; [OCN today; some reference to an entity record in the future] From nobody Thu Jan 29 10:07:40 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4791A1B1F for ; Thu, 29 Jan 2015 10:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5j43PC0PTiS for ; Thu, 29 Jan 2015 10:07:36 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6989B1A1AAA for ; Thu, 29 Jan 2015 10:07:36 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) with ESMTP id 8e67ac45.2b5509027940.4541935.00-2417.12711732.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 Jan 2015 18:07:36 +0000 (UTC) X-MXL-Hash: 54ca76e808761f38-09c7c3ba1dc48193eb8f98343d1b3d27fc3b65c0 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 2e67ac45.0.4541859.00-2362.12711483.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 Jan 2015 18:07:35 +0000 (UTC) X-MXL-Hash: 54ca76e72110d1f8-db6b260054e45d1d77f289d67d6ad4082c8ac552 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0TI7TCW006149; Thu, 29 Jan 2015 13:07:30 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0TI7Jl5005990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jan 2015 13:07:23 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 29 Jan 2015 18:07:04 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.63]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 13:07:03 -0500 From: "PFAUTZ, PENN L" To: Henning Schulzrinne , Erik Chuss , "modern@ietf.org" Thread-Topic: protocols for number management? Thread-Index: AdA7HfdFgw8QrcWbTt2oVjEiLzc30gAtjUvgAAQwoXwAAnIz8A== Date: Thu, 29 Jan 2015 18:07:03 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60578A602@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com>, <7DDE171004B40E49BC418D2229EC06533923F422@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=L/KqtZv8 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YNv0rlydsVwA:10 a=3b9m31fsA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=KNvMrXTunjaAM-fJ] X-AnalysisOut: [298A:9 a=CjuIK1q_8ugA:10 a=GCaqL0eAZMYA:10 a=iE9YWIBck50A:] X-AnalysisOut: [10 a=Jj9MN_NJFiIeAyJU:21 a=HWu4SH6UL8lBidgO:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Modern] protocols for number management? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:07:38 -0000 Here's a link to the CFR 47 part defining states for toll free numbers: http://www.gpo.gov/fdsys/pkg/CFR-2013-title47-vol3/pdf/CFR-2013-title47-vol= 3-part52-subpartD.pdf -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Thursday, January 29, 2015 12:01 PM To: Erik Chuss; PFAUTZ, PENN L; modern@ietf.org Subject: RE: protocols for number management? I'm curious to hear more about the likely numbering states. I'm comparing E= PP (domain name) and 800 states, but a good reference to the formal definit= ions and transitions for 800# would be helpful. (Some of it can be deduced = from the CFR rules, but they were obviously not written by protocol designe= rs.) ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Erik Chuss [erik.chuss@= ericsson.com] Sent: Thursday, January 29, 2015 10:32 AM To: PFAUTZ, PENN L; modern@ietf.org Cc: Erik Chuss Subject: Re: [Modern] protocols for number management? Penn, In thinking about this, in order to help facilitate the discussion and iden= tify potential test bed solutions, what do you envision the appropriate pro= visioning information to be used for? As you know the Toll Free system has= supported, what we have called 'line-level number allocation', since the e= arly 1900's. The number administration of the system piece allows for cent= ralized access to numbering resources and equal access to the resources on = a 'first in/first out' basis. It keeps track of the numbering lifecycle by = storing the status of each number (Spare, Reserved, Working, Transitional, = Disconnect, etc.). It is also used to identify the Responsible Organizatio= n (Resp Org) of a number and ensures only updates to provisioning be made b= y the Resp Org of the number (i.e. provisioning security). There are, of c= ourse, more functions of the number admin piece but I just wanted to mentio= n a few high-level topics. A distributed solution may present special chal= lenges for these items that would need to be addressed. The key piece thou= gh is the provisioning piece. How do you or the others foresee the system = be used for in terms of provisioning appropriate information in the network= ? Would it just be used for validation on a 'push' basis where the informa= tion is distributed to the service providers automatically who can then use= it as they see fit or opening the system up for query on an as needed basi= s? Is there some other functionality that could be included? I hope this helps with the initial discussion and facilities expanded discu= ssion. Erik J. Chuss North America Toll Free Number Administrator DSMI/Ericsson, Inc. RRC-4A1142 1 Ericsson Drive Piscataway, NJ 08854 Phone: 1-732-699-3422 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, January 28, 2015 12:12 PM To: modern@ietf.org Subject: [Modern] protocols for number management? ATIS has a landscape testbed activity assembling various use cases that mig= ht be examined in a testbed. One of them involves inventory-less just-in-time number assignment within t= he framework of the kind of unfied numbering lifecycle management platform = discussed at the FCC Numbering Testbed Workshop back in March of 2014. The question came up as to what sort of protocols might be appropriate for = service providers to interact with the registry provider(s), to find availa= ble resources, request assignments, and provision appropriate information f= or distribution to other SPs once the assignment is made. Mechanisms to acc= ommodate this a distributed registry architecture are also of interest (how= to make sure the same number isn't assigned by two different registry pro= viders in a race condition) It occurred to me folks on this list might have some suggestions. Thanks, Penn Pfautz AT&T Global Connection Management +1-732-420-4962 From nobody Thu Jan 29 10:29:57 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76F21A1B06 for ; Thu, 29 Jan 2015 10:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVoG8Y3afmgY for ; Thu, 29 Jan 2015 10:29:51 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7407B1A1AF1 for ; Thu, 29 Jan 2015 10:29:51 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id z60so32190612qgd.6 for ; Thu, 29 Jan 2015 10:29:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1EMPT9EmK70twJDXlts8XfGin4vRzMKk00JJ6YkMkzM=; b=VSN8iOMAg/nlG3xS9YoP19ILLIK9NDuOAow6sTxM8aSefiZxF3w5z7qMkB2YMf1pr7 oJZTYymROshhP+DZzmOc6FFRijXjeTLVC0kOKp2kTPxYgfpP2+H6Y4YOB+4b87ASOflV Ncar/HMHjMvBARSThsU7iUM/7BBB334XKChroCFuOMoRtUHAPh1/Q24kXhgIMbvPfZmy KGnBs0+zMf7Yg7ogupoRXaJzC380/DB2eFdPjk3va7A811VccW3f1GdjfX+16Tfo93Ag XuLOxLNbcGN8zZNBB8V3PEgjJUifZuMm3R6dGUe4n4WFCqqWCcZREqnUqkQ1xAf7R/9j +xAA== X-Gm-Message-State: ALoCoQlfEyqAm67neEBefiAnnZyc7VYV67eDeQFyGubfh/ES6oMdDhBWKvIOikF2dnHqDKl4/J9h X-Received: by 10.229.50.135 with SMTP id z7mr3891983qcf.21.1422556190564; Thu, 29 Jan 2015 10:29:50 -0800 (PST) Received: from sshiatis-ltx1.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id r9sm7736490qak.2.2015.01.29.10.29.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 10:29:49 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F25F5E1C-5405-4392-BA21-EFA2BA1946C9" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Rosen In-Reply-To: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Thu, 29 Jan 2015 13:29:47 -0500 Message-Id: <6D9CD9F5-CAFA-440F-BDD0-63E014D6D1F8@brianrosen.net> References: <38726EDA2109264987B45E29E758C4D605789DEA@MISOUT7MSGUSRDD.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] protocols for number management? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:29:55 -0000 --Apple-Mail=_F25F5E1C-5405-4392-BA21-EFA2BA1946C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Penn Suppose there was an entity that more or less appeared to be a carrier = or authorized holder of numbers. All unallocated numbers appear in the database and are marked as being = held by that entity (SPID). Then any other authorized entity could =E2=80=9Cport=E2=80=9D a number = from that entity to themselves, using the porting mechanism. This = effectively means the entire inventory is held by that entity and = numbers are =E2=80=9Callocated=E2=80=9D out one at a time (or a short = range, when that=E2=80=99s what is allocated to a customer). Since we expect ports to be able to be completed in seconds, that would = be a suitable mechanism. Brian > On Jan 28, 2015, at 12:12 PM, PFAUTZ, PENN L wrote: >=20 > ATIS has a landscape testbed activity assembling various use cases = that might be examined in a testbed. > One of them involves inventory-less just-in-time number assignment = within the framework of the kind of unfied numbering lifecycle = management platform discussed at the FCC Numbering Testbed Workshop back = in March of 2014. > =20 > The question came up as to what sort of protocols might be appropriate = for service providers to interact with the registry provider(s), to find = available resources, request assignments, and provision appropriate = information for distribution to other SPs once the assignment is made. = Mechanisms to accommodate this a distributed registry architecture are = also of interest (how to make sure the same number isn=E2=80=99t = assigned by two different registry providers in a race condition) > =20 > It occurred to me folks on this list might have some suggestions. > =20 > Thanks, > Penn Pfautz > AT&T Global Connection Management > +1-732-420-4962 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern = --Apple-Mail=_F25F5E1C-5405-4392-BA21-EFA2BA1946C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Penn

Suppose there was an entity that more or less appeared to be = a carrier or authorized holder of numbers.

All unallocated numbers appear in the = database and are marked as being held by that entity (SPID).

Then any other = authorized entity could =E2=80=9Cport=E2=80=9D a number from that entity = to themselves, using the porting mechanism.   This effectively = means the entire inventory is held by that entity and numbers are = =E2=80=9Callocated=E2=80=9D out one at a time (or a short range, when = that=E2=80=99s what is allocated to a customer).

Since we expect ports to be able to be = completed in seconds, that would be a suitable mechanism.

Brian

On Jan 28, 2015, at 12:12 PM, = PFAUTZ, PENN L <pp3129@att.com> wrote:

ATIS has = a landscape testbed activity assembling various use cases that might be = examined in a testbed.
One of them involves inventory-less just-in-time number = assignment within the framework of the kind of unfied numbering = lifecycle management platform discussed at the FCC Numbering Testbed = Workshop back in March of 2014.
 
The question came up as to what sort of = protocols might be appropriate for service providers to interact with = the registry provider(s), to find available resources, request = assignments, and provision appropriate information for distribution to = other SPs once the assignment is made. Mechanisms to accommodate this a = distributed registry architecture are also of interest (how to make sure = the same number isn=E2=80=99t assigned by two different  registry = providers in a race condition)
 
It occurred to me folks on this list = might have some suggestions.
 
Thanks,
Penn Pfautz
AT&T = Global Connection Management
+1-732-420-4962
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

= --Apple-Mail=_F25F5E1C-5405-4392-BA21-EFA2BA1946C9-- From nobody Thu Jan 29 10:38:10 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662371A1A78 for ; Thu, 29 Jan 2015 10:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.674 X-Spam-Level: X-Spam-Status: No, score=-98.674 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNRgvbgYMTig for ; Thu, 29 Jan 2015 10:38:05 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 5D6BD1A1A51 for ; Thu, 29 Jan 2015 10:38:05 -0800 (PST) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t0TIZC80002132; Thu, 29 Jan 2015 13:37:59 -0500 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1s7rym85m1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Jan 2015 13:37:59 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 13:37:57 -0500 From: "Peterson, Jon" To: "PFAUTZ, PENN L" , Erik Chuss , "modern@ietf.org" Thread-Topic: [Modern] protocols for number management? Thread-Index: AQHQO/Kygw8QrcWbTt2oVjEiLzc30g== Date: Thu, 29 Jan 2015 18:37:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.195] Content-Type: multipart/alternative; boundary="_000_D0EF9AFF146D01jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7696 signatures=670622 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=2.02798965953654e-08 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999510175003986 urlsuspect_oldscore=0.999510175003986 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.999510175003986 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501290180 Archived-At: Subject: Re: [Modern] protocols for number management? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:38:07 -0000 --_000_D0EF9AFF146D01jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The key questions that motivated the creation of this mailing list, anyway,= were about how numbering functions might look in the post-transition world= , especially when we imagine how a diverse, Internet-based set of applicati= ons and services would interface with numbering functions in ways that simp= ly have no precedent in the PSTN. As such, I don't think we're seeking protocol sophistication for its own sa= ke. We're looking to create tools that could support future ecosystems that= enable different trade-offs in how we determine authority, how we provide = security, and what sorts of attributes we want to associate with numbering = resources in that world. These sorts of principles would lead us to create = information models for numbering resources that could be encoded in a varie= ty of ways and extended to support operating environments we only understan= d imperfectly today. Not coincidentally, these were, in effect, the motivations behind the TeRQ = proposal. Jon Peterson Neustar, Inc. From: , PENN L > Date: Thursday, January 29, 2015 at 7:46 AM To: Erik Chuss >, "= modern@ietf.org" > Subject: Re: [Modern] protocols for number management? Erik: I would expect much of the functionality to be similar to SMS/800 with some= tweaks The numbering space would be more segmented, e.g. by geography and assignme= nt rules would differ. The users would be SPs not RespOrgs. Don=92t know whether direct query would be supported or not but the info p= rovided in either case would not include service logic. I would expect the protocol to differ just because technology has become mo= re sophisticated Thanks, Penn From: Erik Chuss [mailto:erik.chuss@ericsson.com] Sent: Thursday, January 29, 2015 10:32 AM To: PFAUTZ, PENN L; modern@ietf.org Cc: Erik Chuss Subject: RE: protocols for number management? Penn, In thinking about this, in order to help facilitate the discussion and iden= tify potential test bed solutions, what do you envision the appropriate pro= visioning information to be used for? As you know the Toll Free system has= supported, what we have called =91line-level number allocation=92, since t= he early 1900=92s. The number administration of the system piece allows fo= r centralized access to numbering resources and equal access to the resourc= es on a =91first in/first out=92 basis. It keeps track of the numbering lif= ecycle by storing the status of each number (Spare, Reserved, Working, Tran= sitional, Disconnect, etc.). It is also used to identify the Responsible O= rganization (Resp Org) of a number and ensures only updates to provisioning= be made by the Resp Org of the number (i.e. provisioning security). There= are, of course, more functions of the number admin piece but I just wanted= to mention a few high-level topics. A distributed solution may present sp= ecial challenges for these items that would need to be addressed. The key = piece though is the provisioning piece. How do you or the others foresee t= he system be used for in terms of provisioning appropriate information in t= he network? Would it just be used for validation on a =91push=92 basis whe= re the information is distributed to the service providers automatically wh= o can then use it as they see fit or opening the system up for query on an = as needed basis? Is there some other functionality that could be included? I hope this helps with the initial discussion and facilities expanded discu= ssion. Erik J. Chuss North America Toll Free Number Administrator DSMI/Ericsson, Inc. RRC-4A1142 1 Ericsson Drive Piscataway, NJ 08854 Phone: 1-732-699-3422 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, January 28, 2015 12:12 PM To: modern@ietf.org Subject: [Modern] protocols for number management? ATIS has a landscape testbed activity assembling various use cases that mig= ht be examined in a testbed. One of them involves inventory-less just-in-time number assignment within t= he framework of the kind of unfied numbering lifecycle management platform = discussed at the FCC Numbering Testbed Workshop back in March of 2014. The question came up as to what sort of protocols might be appropriate for = service providers to interact with the registry provider(s), to find availa= ble resources, request assignments, and provision appropriate information f= or distribution to other SPs once the assignment is made. Mechanisms to acc= ommodate this a distributed registry architecture are also of interest (how= to make sure the same number isn=92t assigned by two different registry p= roviders in a race condition) It occurred to me folks on this list might have some suggestions. Thanks, Penn Pfautz AT&T Global Connection Management +1-732-420-4962 --_000_D0EF9AFF146D01jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

The key questions that motivated the creation of this mailing list, an= yway, were about how numbering functions might look in the post-transition = world, especially when we imagine how a diverse, Internet-based set of appl= ications and services would interface with numbering functions in ways that simply have no precedent in the PSTN= .

As such, I don't think we're seeking protocol sophistication for its o= wn sake. We're looking to create tools that could support future ecosystems= that enable different trade-offs in how we determine authority, how we pro= vide security, and what sorts of attributes we want to associate with numbering resources in that world. Th= ese sorts of principles would lead us to create information models for numb= ering resources that could be encoded in a variety of ways and extended to = support operating environments we only understand imperfectly today. 

Not coincidentally, these were, in effect, the motivations behind the = TeRQ proposal.

Jon Peterson
Neustar, Inc.

From: <PFAUTZ>, PENN L <pp3129@att.com>
Date: Thursday, January 29, 2015 at= 7:46 AM
To: Erik Chuss <erik.chuss@ericsson.com>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] protocols for= number management?

Erik:

I would expect much of= the functionality to be similar to SMS/800 with some tweaks

The numbering space wo= uld be more segmented, e.g. by geography and assignment rules would differ.= The users would be SPs not RespOrgs.

Don=92t know whether d= irect query would be supported or not  but the info provided in either= case would not include service logic.

I would expect the pro= tocol to differ just because technology has become more sophisticated<= /o:p>

 

Thanks,

Penn=

 

From: Erik Chuss [mailto:erik.chuss@ericsson.com]
Sent: Thursday, January 29, 2015 10:32 AM
To: PFAUTZ, PENN L; modern@ietf.o= rg
Cc: Erik Chuss
Subject: RE: protocols for number management?

 

Penn,

 

In thinking about this= , in order to help facilitate the discussion and identify potential test be= d solutions, what do you envision the appropriate provisioning information = to be used for?  As you know the Toll Free system has supported, what we have called =91line-level number alloca= tion=92, since the early 1900=92s.  The number administration of the s= ystem piece allows for centralized access to numbering resources and equal = access to the resources on a =91first in/first out=92 basis. It keeps track of the numbering lifecycle by storing the sta= tus of each number (Spare, Reserved, Working, Transitional, Disconnect, etc= .).  It is also used to identify the Responsible Organization (Resp Or= g) of a number and ensures only updates to provisioning be made by the Resp Org of the number (i.e. provisioning s= ecurity).  There are, of course, more functions of the number admin pi= ece but I just wanted to mention a few high-level topics.  A distribut= ed solution may present special challenges for these items that would need to be addressed.  The key piece thoug= h is the provisioning piece.  How do you or the others foresee the sys= tem be used for in terms of provisioning appropriate information in the net= work?  Would it just be used for validation on a =91push=92 basis where the information is distributed to the service = providers automatically who can then use it as they see fit or opening the = system up for query on an as needed basis?  Is there some other functi= onality that could be included?

 

I hope this helps with= the initial discussion and facilities expanded discussion.

 

Erik J. Chuss

North America Toll Fre= e Number Administrator

DSMI/Ericsson, Inc.

RRC-4A1142<= /span>

1 Ericsson Drive<= /o:p>

Piscataway, NJ 08854

Phone: 1-732-699-3422<= o:p>

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L
Sent: Wednesday, January 28, 2015 12:12 PM
To: modern@ietf.org
Subject: [Modern] protocols for number management?=

 

ATIS has a landscape testbed activity assembling var= ious use cases that might be examined in a testbed.

One of them involves inventory-less just-in-time num= ber assignment within the framework of the kind of unfied numbering lifecyc= le management platform discussed at the FCC Numbering Testbed Workshop back= in March of 2014.

 

The question came up as to what sort of protocols mi= ght be appropriate for service providers to interact with the registry prov= ider(s), to find available resources, request assignments, and provision ap= propriate information for distribution to other SPs once the assignment is made. Mechanisms to accommodate this a= distributed registry architecture are also of interest (how to make sure t= he same number isn=92t assigned by two different  registry providers i= n a race condition)

 

It occurred to me folks on this list might have some= suggestions.

 

Thanks,

Penn Pfautz

AT&T Global Connection Management

+1-732-420-4962

 --_000_D0EF9AFF146D01jonpetersonneustarbiz_--