From nobody Fri May 1 10:44:19 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 BB16C1A854D for ; Fri, 1 May 2015 10:44:18 -0700 (PDT) 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 6nBap58Pidut for ; Fri, 1 May 2015 10:44:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3641A6FCB for ; Fri, 1 May 2015 10:44:16 -0700 (PDT) Received: from BY2FFO11FD020.protection.gbl (10.1.14.31) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.1.160.8; Fri, 1 May 2015 17:44:13 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm1.corp.sprint.com (144.230.32.80) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Fri, 1 May 2015 17:44:13 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t41HQtC8008254; Fri, 1 May 2015 13:44:12 -0400 Received: from prewe13m02.ad.sprint.com (prewe13m02.corp.sprint.com [144.226.128.21]) by preapdm1.corp.sprint.com with ESMTP id 1u355mq98t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 01 May 2015 13:44:12 -0400 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PREWE13M02.ad.sprint.com (2002:90e2:8015::90e2:8015) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 1 May 2015 13:44:10 -0400 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.1044.021; Fri, 1 May 2015 12:44:10 -0500 From: "Holmes, David W [CTO]" To: Eric Burger , "modern@ietf.org" Thread-Topic: Conclusion on Charter? Thread-Index: AdCENVGYbpxOc7MdTlmHq4NQAeFzng== Date: Fri, 1 May 2015 17:44:09 +0000 Message-ID: <5ed4ccce11cb4502ad8e3876903bb980@PLSWE13M01.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(199003)(189002)(77156002)(62966003)(2900100001)(2501003)(6806004)(5250100002)(47776003)(102836002)(108616004)(87936001)(2656002)(92566002)(5001960100002)(5001770100001)(24736003)(107886002)(46102003)(85326001)(86362001)(229853001)(23676002)(50466002)(50986999)(54356999)(33646002)(106466001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB024; H:preapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB024; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB024; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB024; X-Forefront-PRVS: 0563F2E8B7 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2015 17:44:13.2233 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB024 Archived-At: Subject: [Modern] Conclusion on Charter? 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: Fri, 01 May 2015 17:44:18 -0000 RnJvbSB0aGUgdmFyaW91cyB0aHJlYWRzIHdlIGhhdmUgc2VlbiBvbiB0aGlzIHJlZmxlY3Rvciwg Y2FuIHdlIGNvbmNsdWRlIHRoYXQsIGlmIGl0IGlzIHRvIGJlIGNvbnN0cmljdGVkIHRvIGNvbnNp ZGVyYXRpb24gb2YgRS4xNjQsIE1PREVSTiBzaG91bGQgc2ltcGx5IHRvIGNoYXJ0ZXJlZCB0byBn ZW5lcmF0ZSBhIFByb2JsZW0gU3RhdGVtZW50IHJlZ2FyZGluZyBpc3N1ZXMgcGVyY2VpdmVkIHdp dGggY3VycmVudCBUTiBhbGxvY2F0aW9uL2Fzc2lnbm1lbnQgcHJvY2Vzc2VzPw0KDQpPYnZpb3Vz bHkgdGhpcyBhY3Rpdml0eSB3b3VsZCBiZSBjb25zdHJpY3RlZCB0byBjb25zaWRlcmF0aW9uIG9m IHRlY2huaWNhbCBpc3N1ZXM7IG5vdGluZyB0aGF0IG1vc3QgbnVtYmVyaW5nIGlzc3VlcyBhcmlz ZSBmcm9tIG9yZ2FuaXphdGlvbmFsIG9yIGJ1c2luZXNzIGNvbnNpZGVyYXRpb25zLCB3aGljaCBh cmUgb3V0c2lkZSB0aGUgcmVhY2ggb2YgSUVURi4NCg0KRGF2aWQgSG9sbWVzIC8gU3ByaW50DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250 YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0K From nobody Fri May 1 11:06:28 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 7EEE71B2B8D for ; Fri, 1 May 2015 11:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.367 X-Spam-Level: X-Spam-Status: No, score=-100.367 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 pV_esQge06x7 for ; Fri, 1 May 2015 11:06:25 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 C03041B2B8A for ; Fri, 1 May 2015 11:06:25 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t41I2r6C010974; Fri, 1 May 2015 14:06:25 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1u489wrff0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 01 May 2015 14:06:24 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Fri, 1 May 2015 14:06:23 -0400 From: "Peterson, Jon" To: Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] All-IP telecommunications network or TN identifiers Thread-Index: AQHQg4jsCENRrpCi4k6I2E+vHOabzJ1mWOwAgAADNwCAAN2HgA== Date: Fri, 1 May 2015 18:06:23 +0000 Message-ID: References: <55424844.9040700@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com> <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com> <20150430214152.GG20261@x28.adm.denic.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.89] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-05-01_07:2015-05-01,2015-05-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=9.55235890387485e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505010225 Archived-At: Subject: Re: [Modern] All-IP telecommunications network or TN identifiers 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: Fri, 01 May 2015 18:06:27 -0000 Casting the proposed work as "dictating the numbering allocation model to the world" makes it sounds very presumptuous and misguided, and certainly if you (and others) succeed in convincing people that's the purpose of MODERN, then I imagine it won't proceed. But of course that's never been the case - and if it were, I'd be adding my voice to the doubters. MODERN is about the use cases that we reviewed in the BoF: cases like a Cisco enterprise phone getting a number from a Call Manager; cases like a carrier delegating a block of numbers to a VoIP provider; and ultimately, cases based on larger scale deployments in a post-PSTN-transition environment. These are real problems, there need to be tools that support these cases, and MODERN proposes to begin work on such tools so we can get some implementation experience before the lack of such tools precipitates a crisis. That was indeed what the FCC workshop was about. So what's the motivation for casting MODERN as annexing the responsibilities of SG-2? Clearly, as was discussed at the BoF, there are some stakeholders who feel that any change to the number allocation model is harmful to their business interests. Got it. But the IETF could never have the power to change the number allocation model. Obstructing the proposed MODERN work will not make the industry pressures that inspired the FCC workshop go away. All it will do is make us unprepared for the changes when they inevitably come. The purpose of this proposed exercise is to create tools, not policies. Tools that will work in a variety of potential policy environments, for a variety of use cases. I don't think it would be worth chartering MODERN to create a "problem statement" and that's it. We need to get to work. Jon Peterson Neustar, Inc. On 4/30/15, 2:53 PM, "Eric Burger" wrote: > >> On Apr 30, 2015, at 5:41 PM, Peter Koch wrote: >>=20 >> On Thu, Apr 30, 2015 at 05:01:55PM -0400, Eric Burger wrote: >>=20 >>> My vote is a strong No. We do not have a need to reinvent number >>>allocation. From a business perspective, carriers already get numbers >>>from numbering authorities. The code is written, debugged, and works. >>>In fact, it mostly works over IP, if you want to get into the >>>particulars and feel that because something runs over IP it is >>>???better.' Until it is time for the carriers to replace their >>>provisioning systems, there is little need for a ???new??? method to >>>get what they get today. >>=20 >> my understanding is - and please take this as an attempt to rephrase >>the question >> rather than an explanation, that - in IP address parlance - "allocation" >> would be superseded by "assignment", getting rid of number blocks and >>the >> necessity for porting, as well as, at the risk of crossing the policy >> boundary, support for a thick registry (of TN holders) rather than a >>thin >> registry (of block custodians). I'm likely wrong, but I'd like to know >>where. >>=20 >> -Peter > >I do not know that you are wrong, but where is the requirement? > >Is the requirement to eliminate service providers managing TNs? >Is the requirement to eliminate the two-tier model we have today, where >national numbering authorities allocate TNs to service providers who >allocate them to users? And related, where =8Cusers=B9 are sometimes >enterprises or service bureaux who then allocate their numbers to users? >Is the requirement to eliminate the distributed model we have today in >most of the world where the national numbering authority allocates TNs in >blocks to service providers and replace it with a centralized model where >all TNs live in a single data base? >Is the requirement to eliminate the quasi-distributed model we have today >in countries such as the U.S., Canada, Argentina, India, etc. where the >national numbering authority allocates TNs in blocks to services >providers with a centralized data base for ported numbers? >Is there another requirement? > >And, if we are going to dictate the numbering allocation model to the >world, will the world accept it? > From nobody Fri May 1 11:24: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 78DE71B2B92 for ; Fri, 1 May 2015 11:24:25 -0700 (PDT) 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, 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 VCcI9Z31dzC9 for ; Fri, 1 May 2015 11:24:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB631A89B4 for ; Fri, 1 May 2015 11:24:19 -0700 (PDT) Received: from BN1BFFO11FD001.protection.gbl (10.58.144.33) by BN1BFFO11HUB047.protection.gbl (10.58.144.194) with Microsoft SMTP Server (TLS) id 15.1.160.8; Fri, 1 May 2015 18:23:59 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN1BFFO11FD001.mail.protection.outlook.com (10.58.144.64) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Fri, 1 May 2015 18:23:58 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t41HAjQM014318; Fri, 1 May 2015 14:23:58 -0400 Received: from plswe13m01.ad.sprint.com (plswe13m01.corp.sprint.com [144.229.214.20]) by preapdm3.corp.sprint.com with ESMTP id 1u363m73q6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 01 May 2015 14:23:58 -0400 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 1 May 2015 13:23:57 -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.1044.021; Fri, 1 May 2015 13:23:57 -0500 From: "Holmes, David W [CTO]" To: "Peterson, Jon" , Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] All-IP telecommunications network or TN identifiers Thread-Index: AQHQg4jsOjgkrWTLtEaYg5JpHsZkmZ1mabAAgAADNgCAAVLqgP//rV+Q Date: Fri, 1 May 2015 18:23:56 +0000 Message-ID: References: <55424844.9040700@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com> <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com> <20150430214152.GG20261@x28.adm.denic.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.93] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(13464003)(199003)(189002)(24454002)(377454003)(479174004)(51704005)(19580405001)(85326001)(19580395003)(87936001)(2656002)(2501003)(92566002)(62966003)(24736003)(2950100001)(46102003)(5250100002)(107886002)(5001960100002)(5001920100001)(5001770100001)(106116001)(106466001)(54356999)(33646002)(76176999)(50986999)(50466002)(86362001)(102836002)(108616004)(6806004)(77156002)(93886004)(47776003)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB047; H:preapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB047; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB047; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB047; X-Forefront-PRVS: 0563F2E8B7 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2015 18:23:58.6891 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB047 Archived-At: Subject: Re: [Modern] All-IP telecommunications network or TN identifiers 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: Fri, 01 May 2015 18:24:25 -0000 So, Jon, you don't think it worthwhile to generate a problem statement, but= you say of the use cases discussed that "these are real problems". So charter the group initially to list out those use cases, then if it is o= bvious that it can also do useful work in creating tools that can be used f= or number administration in support of those use cases, proceed in that dir= ection? But noting that the tools would be available for use by administra= tors, without implication that anyone was "requiring" their adoption. BR/David/Sprint -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Friday, May 01, 2015 11:06 AM To: Eric Burger; modern@ietf.org Subject: Re: [Modern] All-IP telecommunications network or TN identifiers Casting the proposed work as "dictating the numbering allocation model to t= he world" makes it sounds very presumptuous and misguided, and certainly if= you (and others) succeed in convincing people that's the purpose of MODERN= , then I imagine it won't proceed. But of course that's never been the case - and if it were, I'd be adding my= voice to the doubters. MODERN is about the use cases that we reviewed in t= he BoF: cases like a Cisco enterprise phone getting a number from a Call Ma= nager; cases like a carrier delegating a block of numbers to a VoIP provide= r; and ultimately, cases based on larger scale deployments in a post-PSTN-= transition environment. These are real problems, there need to be tools tha= t support these cases, and MODERN proposes to begin work on such tools so w= e can get some implementation experience before the lack of such tools prec= ipitates a crisis. That was indeed what the FCC workshop was about. So what's the motivation for casting MODERN as annexing the responsibilitie= s of SG-2? Clearly, as was discussed at the BoF, there are some stakeholder= s who feel that any change to the number allocation model is harmful to the= ir business interests. Got it. But the IETF could never have the power to c= hange the number allocation model. Obstructing the proposed MODERN work wil= l not make the industry pressures that inspired the FCC workshop go away. A= ll it will do is make us unprepared for the changes when they inevitably co= me. The purpose of this proposed exercise is to create tools, not policies. Tools that will work in a variety of potential policy environments, for a v= ariety of use cases. I don't think it would be worth chartering MODERN to c= reate a "problem statement" and that's it. We need to get to work. Jon Peterson Neustar, Inc. On 4/30/15, 2:53 PM, "Eric Burger" wrote: > >> On Apr 30, 2015, at 5:41 PM, Peter Koch wrote: >> >> On Thu, Apr 30, 2015 at 05:01:55PM -0400, Eric Burger wrote: >> >>> My vote is a strong No. We do not have a need to reinvent number >>>allocation. From a business perspective, carriers already get numbers >>>from numbering authorities. The code is written, debugged, and works. >>>In fact, it mostly works over IP, if you want to get into the >>>particulars and feel that because something runs over IP it is >>>???better.' Until it is time for the carriers to replace their >>>provisioning systems, there is little need for a ???new??? method to >>>get what they get today. >> >> my understanding is - and please take this as an attempt to rephrase >>the question rather than an explanation, that - in IP address >>parlance - "allocation" >> would be superseded by "assignment", getting rid of number blocks and >>the necessity for porting, as well as, at the risk of crossing the >>policy boundary, support for a thick registry (of TN holders) rather >>than a thin registry (of block custodians). I'm likely wrong, but >>I'd like to know where. >> >> -Peter > >I do not know that you are wrong, but where is the requirement? > >Is the requirement to eliminate service providers managing TNs? >Is the requirement to eliminate the two-tier model we have today, where >national numbering authorities allocate TNs to service providers who >allocate them to users? And related, where =8Cusers=B9 are sometimes >enterprises or service bureaux who then allocate their numbers to users? >Is the requirement to eliminate the distributed model we have today in >most of the world where the national numbering authority allocates TNs >in blocks to service providers and replace it with a centralized model >where all TNs live in a single data base? >Is the requirement to eliminate the quasi-distributed model we have >today in countries such as the U.S., Canada, Argentina, India, etc. >where the national numbering authority allocates TNs in blocks to >services providers with a centralized data base for ported numbers? >Is there another requirement? > >And, if we are going to dictate the numbering allocation model to the >world, will the world accept it? > _______________________________________________ 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 Fri May 1 11:38:37 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 7D8AD1A1A15 for ; Fri, 1 May 2015 11:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 TR92Ttep5ql1 for ; Fri, 1 May 2015 11:38:34 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 5990C1B2B95 for ; Fri, 1 May 2015 11:38:32 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t41IcVOQ003308; Fri, 1 May 2015 14:38:31 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1u489wrgnt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 01 May 2015 14:38:31 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Fri, 1 May 2015 14:38:30 -0400 From: "Peterson, Jon" To: "Holmes, David W [CTO]" , Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] All-IP telecommunications network or TN identifiers Thread-Index: AQHQg4jsCENRrpCi4k6I2E+vHOabzJ1mWOwAgAADNwCAAN2HgIAAekoA//+OrQA= Date: Fri, 1 May 2015 18:38:30 +0000 Message-ID: References: <55424844.9040700@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com> <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com> <20150430214152.GG20261@x28.adm.denic.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.89] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-05-01_07:2015-05-01,2015-05-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=9.55235890387485e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505010231 Archived-At: Subject: Re: [Modern] All-IP telecommunications network or TN identifiers 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: Fri, 01 May 2015 18:38:36 -0000 DQpTb3JyeSwgSSBkaWRuJ3Qgc2F5IGEgcHJvYmxlbSBzdGF0ZW1lbnQgd2FzIHVzZWxlc3MgLSBh Y3R1YWxseSwgSSBzZWVtIHRvDQpyZWNhbGwgc3VibWl0dGluZyBhIHByb2JsZW0gc3RhdGVtZW50 LCBkcmFmdC1wZXRlcnNvbi1tb2Rlcm4tcHJvYmxlbXMuIEkNCmRpZCBzYXkgSSBkaWRuJ3QgdGhp bmsgY2hhcnRlcmluZyB0aGUgZ3JvdXAgdG8gZG8gLW9ubHktIGEgcHJvYmxlbQ0Kc3RhdGVtZW50 IHdvdWxkIGJlIGFkZXF1YXRlLiBTbyB5ZXMsIHJvdWdobHkgd2hhdCB5b3UgZGVzY3JpYmUgaW4g eW91cg0Kc2Vjb25kIHBhcmFncmFwaCBpcyB3aGF0IEkgaGFkIGluIG1pbmQsIGJ1dCB3aXRob3V0 IHRoZSBnYXRpbmcuIE1vcmUgb3INCmxlc3MgYXMgdGhlIGN1cnJlbnQgZHJhZnQgY2hhcnRlciBy ZWFkcy4NCg0KSm9uIFBldGVyc29uDQpOZXVzdGFyLCBJbmMuDQoNCk9uIDUvMS8xNSwgMTE6MjMg QU0sICJIb2xtZXMsIERhdmlkIFcgW0NUT10iIDxEYXZpZC5Ib2xtZXNAc3ByaW50LmNvbT4NCndy b3RlOg0KDQo+U28sIEpvbiwgeW91IGRvbid0IHRoaW5rIGl0IHdvcnRod2hpbGUgdG8gZ2VuZXJh dGUgYSBwcm9ibGVtIHN0YXRlbWVudCwNCj5idXQgeW91IHNheSBvZiB0aGUgdXNlIGNhc2VzIGRp c2N1c3NlZCB0aGF0ICJ0aGVzZSBhcmUgcmVhbCBwcm9ibGVtcyIuDQo+DQo+U28gY2hhcnRlciB0 aGUgZ3JvdXAgaW5pdGlhbGx5IHRvIGxpc3Qgb3V0IHRob3NlIHVzZSBjYXNlcywgdGhlbiBpZiBp dCBpcw0KPm9idmlvdXMgdGhhdCBpdCBjYW4gYWxzbyBkbyB1c2VmdWwgd29yayBpbiBjcmVhdGlu ZyB0b29scyB0aGF0IGNhbiBiZQ0KPnVzZWQgZm9yIG51bWJlciBhZG1pbmlzdHJhdGlvbiBpbiBz dXBwb3J0IG9mIHRob3NlIHVzZSBjYXNlcywgcHJvY2VlZCBpbg0KPnRoYXQgZGlyZWN0aW9uPyAg QnV0IG5vdGluZyB0aGF0IHRoZSB0b29scyB3b3VsZCBiZSBhdmFpbGFibGUgZm9yIHVzZSBieQ0K PmFkbWluaXN0cmF0b3JzLCB3aXRob3V0IGltcGxpY2F0aW9uIHRoYXQgYW55b25lIHdhcyAicmVx dWlyaW5nIiB0aGVpcg0KPmFkb3B0aW9uLg0KPg0KPkJSL0RhdmlkL1NwcmludA0KPg0KPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTW9kZXJuIFttYWlsdG86bW9kZXJuLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlcnNvbiwgSm9uDQo+U2VudDogRnJpZGF5LCBN YXkgMDEsIDIwMTUgMTE6MDYgQU0NCj5UbzogRXJpYyBCdXJnZXI7IG1vZGVybkBpZXRmLm9yZw0K PlN1YmplY3Q6IFJlOiBbTW9kZXJuXSBBbGwtSVAgdGVsZWNvbW11bmljYXRpb25zIG5ldHdvcmsg b3IgVE4gaWRlbnRpZmllcnMNCj4NCj4NCj5DYXN0aW5nIHRoZSBwcm9wb3NlZCB3b3JrIGFzICJk aWN0YXRpbmcgdGhlIG51bWJlcmluZyBhbGxvY2F0aW9uIG1vZGVsIHRvDQo+dGhlIHdvcmxkIiBt YWtlcyBpdCBzb3VuZHMgdmVyeSBwcmVzdW1wdHVvdXMgYW5kIG1pc2d1aWRlZCwgYW5kIGNlcnRh aW5seQ0KPmlmIHlvdSAoYW5kIG90aGVycykgc3VjY2VlZCBpbiBjb252aW5jaW5nIHBlb3BsZSB0 aGF0J3MgdGhlIHB1cnBvc2Ugb2YNCj5NT0RFUk4sIHRoZW4gSSBpbWFnaW5lIGl0IHdvbid0IHBy b2NlZWQuDQo+DQo+QnV0IG9mIGNvdXJzZSB0aGF0J3MgbmV2ZXIgYmVlbiB0aGUgY2FzZSAtIGFu ZCBpZiBpdCB3ZXJlLCBJJ2QgYmUgYWRkaW5nDQo+bXkgdm9pY2UgdG8gdGhlIGRvdWJ0ZXJzLiBN T0RFUk4gaXMgYWJvdXQgdGhlIHVzZSBjYXNlcyB0aGF0IHdlIHJldmlld2VkDQo+aW4gdGhlIEJv RjogY2FzZXMgbGlrZSBhIENpc2NvIGVudGVycHJpc2UgcGhvbmUgZ2V0dGluZyBhIG51bWJlciBm cm9tIGENCj5DYWxsIE1hbmFnZXI7IGNhc2VzIGxpa2UgYSBjYXJyaWVyIGRlbGVnYXRpbmcgYSBi bG9jayBvZiBudW1iZXJzIHRvIGENCj5Wb0lQIHByb3ZpZGVyOyBhbmQgdWx0aW1hdGVseSwgY2Fz ZXMgYmFzZWQgb24gbGFyZ2VyIHNjYWxlIGRlcGxveW1lbnRzDQo+aW4gYSBwb3N0LVBTVE4tdHJh bnNpdGlvbiBlbnZpcm9ubWVudC4gVGhlc2UgYXJlIHJlYWwgcHJvYmxlbXMsIHRoZXJlDQo+bmVl ZCB0byBiZSB0b29scyB0aGF0IHN1cHBvcnQgdGhlc2UgY2FzZXMsIGFuZCBNT0RFUk4gcHJvcG9z ZXMgdG8gYmVnaW4NCj53b3JrIG9uIHN1Y2ggdG9vbHMgc28gd2UgY2FuIGdldCBzb21lIGltcGxl bWVudGF0aW9uIGV4cGVyaWVuY2UgYmVmb3JlDQo+dGhlIGxhY2sgb2Ygc3VjaCB0b29scyBwcmVj aXBpdGF0ZXMgYSBjcmlzaXMuIFRoYXQgd2FzIGluZGVlZCB3aGF0IHRoZQ0KPkZDQyB3b3Jrc2hv cCB3YXMgYWJvdXQuDQo+DQo+U28gd2hhdCdzIHRoZSBtb3RpdmF0aW9uIGZvciBjYXN0aW5nIE1P REVSTiBhcyBhbm5leGluZyB0aGUNCj5yZXNwb25zaWJpbGl0aWVzIG9mIFNHLTI/IENsZWFybHks IGFzIHdhcyBkaXNjdXNzZWQgYXQgdGhlIEJvRiwgdGhlcmUgYXJlDQo+c29tZSBzdGFrZWhvbGRl cnMgd2hvIGZlZWwgdGhhdCBhbnkgY2hhbmdlIHRvIHRoZSBudW1iZXIgYWxsb2NhdGlvbiBtb2Rl bA0KPmlzIGhhcm1mdWwgdG8gdGhlaXIgYnVzaW5lc3MgaW50ZXJlc3RzLiBHb3QgaXQuIEJ1dCB0 aGUgSUVURiBjb3VsZCBuZXZlcg0KPmhhdmUgdGhlIHBvd2VyIHRvIGNoYW5nZSB0aGUgbnVtYmVy IGFsbG9jYXRpb24gbW9kZWwuIE9ic3RydWN0aW5nIHRoZQ0KPnByb3Bvc2VkIE1PREVSTiB3b3Jr IHdpbGwgbm90IG1ha2UgdGhlIGluZHVzdHJ5IHByZXNzdXJlcyB0aGF0IGluc3BpcmVkDQo+dGhl IEZDQyB3b3Jrc2hvcCBnbyBhd2F5LiBBbGwgaXQgd2lsbCBkbyBpcyBtYWtlIHVzIHVucHJlcGFy ZWQgZm9yIHRoZQ0KPmNoYW5nZXMgd2hlbiB0aGV5IGluZXZpdGFibHkgY29tZS4NCj4NCj5UaGUg cHVycG9zZSBvZiB0aGlzIHByb3Bvc2VkIGV4ZXJjaXNlIGlzIHRvIGNyZWF0ZSB0b29scywgbm90 IHBvbGljaWVzLg0KPlRvb2xzIHRoYXQgd2lsbCB3b3JrIGluIGEgdmFyaWV0eSBvZiBwb3RlbnRp YWwgcG9saWN5IGVudmlyb25tZW50cywgZm9yIGENCj52YXJpZXR5IG9mIHVzZSBjYXNlcy4gSSBk b24ndCB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBjaGFydGVyaW5nIE1PREVSTg0KPnRvIGNyZWF0 ZSBhICJwcm9ibGVtIHN0YXRlbWVudCIgYW5kIHRoYXQncyBpdC4gV2UgbmVlZCB0byBnZXQgdG8g d29yay4NCj4NCj5Kb24gUGV0ZXJzb24NCj5OZXVzdGFyLCBJbmMuDQo+DQo+T24gNC8zMC8xNSwg Mjo1MyBQTSwgIkVyaWMgQnVyZ2VyIiA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+IHdyb3Rl Og0KPg0KPj4NCj4+PiBPbiBBcHIgMzAsIDIwMTUsIGF0IDU6NDEgUE0sIFBldGVyIEtvY2ggPHBr QERFTklDLkRFPiB3cm90ZToNCj4+Pg0KPj4+IE9uIFRodSwgQXByIDMwLCAyMDE1IGF0IDA1OjAx OjU1UE0gLTA0MDAsIEVyaWMgQnVyZ2VyIHdyb3RlOg0KPj4+DQo+Pj4+IE15IHZvdGUgaXMgYSBz dHJvbmcgTm8uIFdlIGRvIG5vdCBoYXZlIGEgbmVlZCB0byByZWludmVudCBudW1iZXINCj4+Pj5h bGxvY2F0aW9uLiBGcm9tIGEgYnVzaW5lc3MgcGVyc3BlY3RpdmUsIGNhcnJpZXJzIGFscmVhZHkg Z2V0IG51bWJlcnMNCj4+Pj5mcm9tIG51bWJlcmluZyBhdXRob3JpdGllcy4gVGhlIGNvZGUgaXMg d3JpdHRlbiwgZGVidWdnZWQsIGFuZCB3b3Jrcy4NCj4+Pj5JbiBmYWN0LCBpdCBtb3N0bHkgd29y a3Mgb3ZlciBJUCwgaWYgeW91IHdhbnQgdG8gZ2V0IGludG8gdGhlDQo+Pj4+cGFydGljdWxhcnMg YW5kIGZlZWwgdGhhdCBiZWNhdXNlIHNvbWV0aGluZyBydW5zIG92ZXIgSVAgaXQgaXMNCj4+Pj4/ Pz9iZXR0ZXIuJyBVbnRpbCBpdCBpcyB0aW1lIGZvciB0aGUgY2FycmllcnMgdG8gcmVwbGFjZSB0 aGVpcg0KPj4+PnByb3Zpc2lvbmluZyBzeXN0ZW1zLCB0aGVyZSBpcyBsaXR0bGUgbmVlZCBmb3Ig YSA/Pz9uZXc/Pz8gbWV0aG9kIHRvDQo+Pj4+Z2V0IHdoYXQgdGhleSBnZXQgdG9kYXkuDQo+Pj4N Cj4+PiBteSB1bmRlcnN0YW5kaW5nIGlzIC0gYW5kIHBsZWFzZSB0YWtlIHRoaXMgYXMgYW4gYXR0 ZW1wdCB0byByZXBocmFzZQ0KPj4+dGhlIHF1ZXN0aW9uICByYXRoZXIgdGhhbiBhbiBleHBsYW5h dGlvbiwgdGhhdCAtIGluIElQIGFkZHJlc3MNCj4+PnBhcmxhbmNlIC0gImFsbG9jYXRpb24iDQo+ Pj4gd291bGQgYmUgc3VwZXJzZWRlZCBieSAiYXNzaWdubWVudCIsIGdldHRpbmcgcmlkIG9mIG51 bWJlciBibG9ja3MgYW5kDQo+Pj50aGUgIG5lY2Vzc2l0eSBmb3IgcG9ydGluZywgYXMgd2VsbCBh cywgYXQgdGhlIHJpc2sgb2YgY3Jvc3NpbmcgdGhlDQo+Pj5wb2xpY3kgIGJvdW5kYXJ5LCBzdXBw b3J0IGZvciBhIHRoaWNrIHJlZ2lzdHJ5IChvZiBUTiBob2xkZXJzKSByYXRoZXINCj4+PnRoYW4g YSB0aGluICByZWdpc3RyeSAob2YgYmxvY2sgY3VzdG9kaWFucykuICBJJ20gbGlrZWx5IHdyb25n LCBidXQNCj4+PkknZCBsaWtlIHRvIGtub3cgd2hlcmUuDQo+Pj4NCj4+PiAtUGV0ZXINCj4+DQo+ PkkgZG8gbm90IGtub3cgdGhhdCB5b3UgYXJlIHdyb25nLCBidXQgd2hlcmUgaXMgdGhlIHJlcXVp cmVtZW50Pw0KPj4NCj4+SXMgdGhlIHJlcXVpcmVtZW50IHRvIGVsaW1pbmF0ZSBzZXJ2aWNlIHBy b3ZpZGVycyBtYW5hZ2luZyBUTnM/DQo+PklzIHRoZSByZXF1aXJlbWVudCB0byBlbGltaW5hdGUg dGhlIHR3by10aWVyIG1vZGVsIHdlIGhhdmUgdG9kYXksIHdoZXJlDQo+Pm5hdGlvbmFsIG51bWJl cmluZyBhdXRob3JpdGllcyBhbGxvY2F0ZSBUTnMgdG8gc2VydmljZSBwcm92aWRlcnMgd2hvDQo+ PmFsbG9jYXRlIHRoZW0gdG8gdXNlcnM/IEFuZCByZWxhdGVkLCB3aGVyZSDFknVzZXJzwrkgYXJl IHNvbWV0aW1lcw0KPj5lbnRlcnByaXNlcyBvciBzZXJ2aWNlIGJ1cmVhdXggd2hvIHRoZW4gYWxs b2NhdGUgdGhlaXIgbnVtYmVycyB0byB1c2Vycz8NCj4+SXMgdGhlIHJlcXVpcmVtZW50IHRvIGVs aW1pbmF0ZSB0aGUgZGlzdHJpYnV0ZWQgbW9kZWwgd2UgaGF2ZSB0b2RheSBpbg0KPj5tb3N0IG9m IHRoZSB3b3JsZCB3aGVyZSB0aGUgbmF0aW9uYWwgbnVtYmVyaW5nIGF1dGhvcml0eSBhbGxvY2F0 ZXMgVE5zDQo+PmluIGJsb2NrcyB0byBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgcmVwbGFjZSBpdCB3 aXRoIGEgY2VudHJhbGl6ZWQgbW9kZWwNCj4+d2hlcmUgYWxsIFROcyBsaXZlIGluIGEgc2luZ2xl IGRhdGEgYmFzZT8NCj4+SXMgdGhlIHJlcXVpcmVtZW50IHRvIGVsaW1pbmF0ZSB0aGUgcXVhc2kt ZGlzdHJpYnV0ZWQgbW9kZWwgd2UgaGF2ZQ0KPj50b2RheSBpbiBjb3VudHJpZXMgc3VjaCBhcyB0 aGUgVS5TLiwgQ2FuYWRhLCBBcmdlbnRpbmEsIEluZGlhLCBldGMuDQo+PndoZXJlIHRoZSBuYXRp b25hbCBudW1iZXJpbmcgYXV0aG9yaXR5IGFsbG9jYXRlcyBUTnMgaW4gYmxvY2tzIHRvDQo+PnNl cnZpY2VzIHByb3ZpZGVycyB3aXRoIGEgY2VudHJhbGl6ZWQgZGF0YSBiYXNlIGZvciBwb3J0ZWQg bnVtYmVycz8NCj4+SXMgdGhlcmUgYW5vdGhlciByZXF1aXJlbWVudD8NCj4+DQo+PkFuZCwgaWYg d2UgYXJlIGdvaW5nIHRvIGRpY3RhdGUgdGhlIG51bWJlcmluZyBhbGxvY2F0aW9uIG1vZGVsIHRv IHRoZQ0KPj53b3JsZCwgd2lsbCB0aGUgd29ybGQgYWNjZXB0IGl0Pw0KPj4NCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk1vZGVybiBtYWlsaW5n IGxpc3QNCj5Nb2Rlcm5AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21vZGVybg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+ VGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGlu dGVuZGVkIGZvciB0aGUNCj5zb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5 IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlDQo+bm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwNCj5jb3BpZXMg b2YgdGhlIG1lc3NhZ2UuDQoNCg== From nobody Fri May 1 12:08:51 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 808451B2DFD for ; Fri, 1 May 2015 12:08:49 -0700 (PDT) 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 l6zmttz4Xp_A for ; Fri, 1 May 2015 12:08:45 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 13CFF1B2DF5 for ; Fri, 1 May 2015 12:08:44 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Holmes, David W [CTO]" , "Peterson, Jon" , Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] All-IP telecommunications network or TN identifiers Thread-Index: AQHQg4jrCGEIAxFgu0qaCtgolyqjrJ1mWOwAgAADNwCAAVLqgIAABOcA///IMSY= Date: Fri, 1 May 2015 19:08:42 +0000 References: <55424844.9040700@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com> <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com> <20150430214152.GG20261@x28.adm.denic.de> , In-Reply-To: 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] All-IP telecommunications network or TN identifiers 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: Fri, 01 May 2015 19:08:49 -0000 For what it's worth, ATIS has already produced a uses cases document, and e= ven a very rough protocol specification, with many of the same organization= s listed that are participating in this discussion (but possibly and probab= ly different individuals). See ATIS-I-0000047.=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Holmes, David W [CTO] [= David.Holmes@sprint.com]=0A= Sent: Friday, May 01, 2015 2:23 PM=0A= To: Peterson, Jon; Eric Burger; modern@ietf.org=0A= Subject: Re: [Modern] All-IP telecommunications network or TN identifiers= =0A= =0A= So, Jon, you don't think it worthwhile to generate a problem statement, but= you say of the use cases discussed that "these are real problems".=0A= =0A= So charter the group initially to list out those use cases, then if it is o= bvious that it can also do useful work in creating tools that can be used f= or number administration in support of those use cases, proceed in that dir= ection? But noting that the tools would be available for use by administra= tors, without implication that anyone was "requiring" their adoption.=0A= =0A= BR/David/Sprint=0A= =0A= -----Original Message-----=0A= From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon=0A= Sent: Friday, May 01, 2015 11:06 AM=0A= To: Eric Burger; modern@ietf.org=0A= Subject: Re: [Modern] All-IP telecommunications network or TN identifiers= =0A= =0A= =0A= Casting the proposed work as "dictating the numbering allocation model to t= he world" makes it sounds very presumptuous and misguided, and certainly if= you (and others) succeed in convincing people that's the purpose of MODERN= , then I imagine it won't proceed.=0A= =0A= But of course that's never been the case - and if it were, I'd be adding my= voice to the doubters. MODERN is about the use cases that we reviewed in t= he BoF: cases like a Cisco enterprise phone getting a number from a Call Ma= nager; cases like a carrier delegating a block of numbers to a VoIP provide= r; and ultimately, cases based on larger scale deployments in a post-PSTN-= transition environment. These are real problems, there need to be tools tha= t support these cases, and MODERN proposes to begin work on such tools so w= e can get some implementation experience before the lack of such tools prec= ipitates a crisis. That was indeed what the FCC workshop was about.=0A= =0A= So what's the motivation for casting MODERN as annexing the responsibilitie= s of SG-2? Clearly, as was discussed at the BoF, there are some stakeholder= s who feel that any change to the number allocation model is harmful to the= ir business interests. Got it. But the IETF could never have the power to c= hange the number allocation model. Obstructing the proposed MODERN work wil= l not make the industry pressures that inspired the FCC workshop go away. A= ll it will do is make us unprepared for the changes when they inevitably co= me.=0A= =0A= The purpose of this proposed exercise is to create tools, not policies.=0A= Tools that will work in a variety of potential policy environments, for a v= ariety of use cases. I don't think it would be worth chartering MODERN to c= reate a "problem statement" and that's it. We need to get to work.=0A= =0A= Jon Peterson=0A= Neustar, Inc.=0A= =0A= On 4/30/15, 2:53 PM, "Eric Burger" wrote:=0A= =0A= >=0A= >> On Apr 30, 2015, at 5:41 PM, Peter Koch wrote:=0A= >>=0A= >> On Thu, Apr 30, 2015 at 05:01:55PM -0400, Eric Burger wrote:=0A= >>=0A= >>> My vote is a strong No. We do not have a need to reinvent number=0A= >>>allocation. From a business perspective, carriers already get numbers=0A= >>>from numbering authorities. The code is written, debugged, and works.=0A= >>>In fact, it mostly works over IP, if you want to get into the=0A= >>>particulars and feel that because something runs over IP it is=0A= >>>???better.' Until it is time for the carriers to replace their=0A= >>>provisioning systems, there is little need for a ???new??? method to=0A= >>>get what they get today.=0A= >>=0A= >> my understanding is - and please take this as an attempt to rephrase=0A= >>the question rather than an explanation, that - in IP address=0A= >>parlance - "allocation"=0A= >> would be superseded by "assignment", getting rid of number blocks and=0A= >>the necessity for porting, as well as, at the risk of crossing the=0A= >>policy boundary, support for a thick registry (of TN holders) rather=0A= >>than a thin registry (of block custodians). I'm likely wrong, but=0A= >>I'd like to know where.=0A= >>=0A= >> -Peter=0A= >=0A= >I do not know that you are wrong, but where is the requirement?=0A= >=0A= >Is the requirement to eliminate service providers managing TNs?=0A= >Is the requirement to eliminate the two-tier model we have today, where=0A= >national numbering authorities allocate TNs to service providers who=0A= >allocate them to users? And related, where =8Cusers=B9 are sometimes=0A= >enterprises or service bureaux who then allocate their numbers to users?= =0A= >Is the requirement to eliminate the distributed model we have today in=0A= >most of the world where the national numbering authority allocates TNs=0A= >in blocks to service providers and replace it with a centralized model=0A= >where all TNs live in a single data base?=0A= >Is the requirement to eliminate the quasi-distributed model we have=0A= >today in countries such as the U.S., Canada, Argentina, India, etc.=0A= >where the national numbering authority allocates TNs in blocks to=0A= >services providers with a centralized data base for ported numbers?=0A= >Is there another requirement?=0A= >=0A= >And, if we are going to dictate the numbering allocation model to the=0A= >world, will the world accept it?=0A= >=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= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= From nobody Fri May 1 12:20:59 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 402C51B2DE1 for ; Fri, 1 May 2015 12:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 Yr8TRqWhbRCH for ; Fri, 1 May 2015 12:20:56 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0014D1B2DF5 for ; Fri, 1 May 2015 12:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=vIOZgDrssgrM/xdwusIPVuXtnJoKXSr3XIJAt/GEQBU=; b=HaDvAXLocepcVWKiX71ORXpWwRYkBUFnglnEdOCWtFRgFsySzXuohxe7oR5QFxc4QBKDmOHoFaBRgpLVPGy2ZzjLnBaRtZ3ZcCg28E9xyeZz6NlwJdq66We31I6EST1UsREcI7LrYhn0dt4RRUuu2jmt0UBAwFvemFivQwOh+Uo=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:54230 helo=[192.168.15.122]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YoGUU-00086k-Hq for modern@ietf.org; Fri, 01 May 2015 12:20:53 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_DE06EB1D-FD7B-4AE5-A448-04CDD0D65A5A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: Date: Fri, 1 May 2015 15:20:49 -0400 Message-Id: <85AB55FD-62F3-4935-B9FE-6606097333C3@standardstrack.com> References: <55424844.9040700@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com> <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com> <20150430214152.GG20261@x28.adm.denic.de> To: "modern@ietf.org" X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] All-IP telecommunications network or TN identifiers 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: Fri, 01 May 2015 19:20:58 -0000 --Apple-Mail=_DE06EB1D-FD7B-4AE5-A448-04CDD0D65A5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So folks on the list have it, the document is at = https://access.atis.org/apps/group_public/download.php/21727/Testbesds_Lan= dscape_Team.pdf All of the use cases are for legacy carriers doing legacy number = routing. The use cases are around how to do ENUM and whether to use NS = records, URIs, centralized vs. distributed NPAC, and how to route 800# = (free phone) calls. What are the problems being solved? > On May 1, 2015, at 3:08 PM, Henning Schulzrinne = wrote: >=20 > For what it's worth, ATIS has already produced a uses cases document, = and even a very rough protocol specification, with many of the same = organizations listed that are participating in this discussion (but = possibly and probably different individuals). See ATIS-I-0000047. >=20 > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of Holmes, David W = [CTO] [David.Holmes@sprint.com] > Sent: Friday, May 01, 2015 2:23 PM > To: Peterson, Jon; Eric Burger; modern@ietf.org > Subject: Re: [Modern] All-IP telecommunications network or TN = identifiers >=20 > So, Jon, you don't think it worthwhile to generate a problem = statement, but you say of the use cases discussed that "these are real = problems". >=20 > So charter the group initially to list out those use cases, then if it = is obvious that it can also do useful work in creating tools that can be = used for number administration in support of those use cases, proceed in = that direction? But noting that the tools would be available for use by = administrators, without implication that anyone was "requiring" their = adoption. >=20 > BR/David/Sprint >=20 > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, = Jon > Sent: Friday, May 01, 2015 11:06 AM > To: Eric Burger; modern@ietf.org > Subject: Re: [Modern] All-IP telecommunications network or TN = identifiers >=20 >=20 > Casting the proposed work as "dictating the numbering allocation model = to the world" makes it sounds very presumptuous and misguided, and = certainly if you (and others) succeed in convincing people that's the = purpose of MODERN, then I imagine it won't proceed. >=20 > But of course that's never been the case - and if it were, I'd be = adding my voice to the doubters. MODERN is about the use cases that we = reviewed in the BoF: cases like a Cisco enterprise phone getting a = number from a Call Manager; cases like a carrier delegating a block of = numbers to a VoIP provider; and ultimately, cases based on larger scale = deployments in a post-PSTN-transition environment. These are real = problems, there need to be tools that support these cases, and MODERN = proposes to begin work on such tools so we can get some implementation = experience before the lack of such tools precipitates a crisis. That was = indeed what the FCC workshop was about. >=20 > So what's the motivation for casting MODERN as annexing the = responsibilities of SG-2? Clearly, as was discussed at the BoF, there = are some stakeholders who feel that any change to the number allocation = model is harmful to their business interests. Got it. But the IETF could = never have the power to change the number allocation model. Obstructing = the proposed MODERN work will not make the industry pressures that = inspired the FCC workshop go away. All it will do is make us unprepared = for the changes when they inevitably come. >=20 > The purpose of this proposed exercise is to create tools, not = policies. > Tools that will work in a variety of potential policy environments, = for a variety of use cases. I don't think it would be worth chartering = MODERN to create a "problem statement" and that's it. We need to get to = work. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 4/30/15, 2:53 PM, "Eric Burger" wrote: >=20 >>=20 >>> On Apr 30, 2015, at 5:41 PM, Peter Koch wrote: >>>=20 >>> On Thu, Apr 30, 2015 at 05:01:55PM -0400, Eric Burger wrote: >>>=20 >>>> My vote is a strong No. We do not have a need to reinvent number >>>> allocation. =46rom a business perspective, carriers already get = numbers >>>> from numbering authorities. The code is written, debugged, and = works. >>>> In fact, it mostly works over IP, if you want to get into the >>>> particulars and feel that because something runs over IP it is >>>> ???better.' Until it is time for the carriers to replace their >>>> provisioning systems, there is little need for a ???new??? method = to >>>> get what they get today. >>>=20 >>> my understanding is - and please take this as an attempt to rephrase >>> the question rather than an explanation, that - in IP address >>> parlance - "allocation" >>> would be superseded by "assignment", getting rid of number blocks = and >>> the necessity for porting, as well as, at the risk of crossing the >>> policy boundary, support for a thick registry (of TN holders) = rather >>> than a thin registry (of block custodians). I'm likely wrong, but >>> I'd like to know where. >>>=20 >>> -Peter >>=20 >> I do not know that you are wrong, but where is the requirement? >>=20 >> Is the requirement to eliminate service providers managing TNs? >> Is the requirement to eliminate the two-tier model we have today, = where >> national numbering authorities allocate TNs to service providers who >> allocate them to users? And related, where =8Cusers=B9 are sometimes >> enterprises or service bureaux who then allocate their numbers to = users? >> Is the requirement to eliminate the distributed model we have today = in >> most of the world where the national numbering authority allocates = TNs >> in blocks to service providers and replace it with a centralized = model >> where all TNs live in a single data base? >> Is the requirement to eliminate the quasi-distributed model we have >> today in countries such as the U.S., Canada, Argentina, India, etc. >> where the national numbering authority allocates TNs in blocks to >> services providers with a centralized data base for ported numbers? >> Is there another requirement? >>=20 >> And, if we are going to dictate the numbering allocation model to the >> world, will the world accept it? >>=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for = the sole 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. >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_DE06EB1D-FD7B-4AE5-A448-04CDD0D65A5A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQ9IRAAoJEDY/T2tCIPW3YQwP/2TS3W3+i46LNH9ccIlBh8yf IVxE46/SBlf6jArvSN3O53NojfkZYPoVenJCjeR8SctPONPEr4To6aYbjd8Ap9LP evo+wlzTuLBP3pSokKHbRqrcmFhacnfGXqUbV3T63LiHiOZ52YglIWyqgSxsjye9 NBVZgmcZqsZwGWrvGWiMFImUsE2ir/YVlmlN7jQa81dHbgt8gReAzyoFvMTUg1RN PAuOsSUa0QrxuUuuqYlTYIX+9xuwD2zsDHhPv5unnEKO55N+N1JyP/lKUMZAvBs/ 8f6ev55BPb+NJfOxXVPr29RjGI0azmy0mLY2/MGo20LQoVm4w/Ed/sEToxvEpyHc OdZBBdrhG85i++xHOadG2vmvY0wj7/R21d7rrwqVi9KSwxUt/NaeU30rA6bXtlJX d02zsLlQ5gz3OMNhfEKC8xLHFpBIycdr+eWhImrxTNn02iijcFvK/LiTCmqLpS9a 6jX9RVEe5qJi4XGhuOnVaf8T674XenlnU2yjQOyyAM8DKoE3tiY3egijNQMC6kWR sME2krehGdkrXUgIyXPsu9Yqcz5L1NkyUzgSbbKFyE3wkzpQ8c4LkB0A5j3bMUje 9epjIZ7/0yP5oOUTIgS8m8+Wx7Hwc0NqS+g3AxTjkzX0QvSzaoBzpbR5BWKZ2Td6 k2ruY3CmFZBb2roESaqM =LhjG -----END PGP SIGNATURE----- --Apple-Mail=_DE06EB1D-FD7B-4AE5-A448-04CDD0D65A5A-- From nobody Fri May 1 14:23: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 C1DEA1B2E4B for ; Fri, 1 May 2015 14:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] 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 SFyEGHkUsCnD for ; Fri, 1 May 2015 14:23:56 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 0FE201A0099 for ; Fri, 1 May 2015 14:23:56 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:64139 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YoIPa-0004a9-Or for modern@ietf.org; Fri, 01 May 2015 14:23:55 -0700 Message-ID: <5543EEEA.9090903@usdonovans.com> Date: Fri, 01 May 2015 16:23:54 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "modern@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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: Fri, 01 May 2015 21:23:56 -0000 The question of what problem(s) MODERN will address has been asked, multiple times. The short answer is that, in an of itself, MODERN will solve no problems. This isn't to say there aren't problems with existing mechanisms. It is to say that all MODERN can do is to specify protocols that can then be part of an overall solution that addresses problems that exist with those existing mechanisms. There is a brief capture of these problems in the latest version of the charter: "A sample of problems with existing mechanisms include: - lack of flexibility (for example, it can be difficult to add fields without a very elaborate and lengthy process typically spanning years) - lack of distribution (for example, it is hard or impossible to have more than one administrator for each database) - complexity (leading, for example, to a fair amount of rural call completion problems which aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms" Will MODERN solve these problems? No. Will MODERN make it possible for these problems to be addressed as part of new number management policies to be enacted by the appropriate authorities? That, I believe, is the goal. Will MODERN force any of these new number management policies to be enacted. No. The IETF is not a policy setting body. I'm ok with having a more detailed articulation of the problem statement as part of the deliverables of the MODERN working group. I don't see the benefit of making that the only deliverable and forcing rechartering after that document is finished. Let's instead agree to shut the working group down if there is consensus that it is going nowhere (which I'm sure the ADs will do anyway). Regards, Steve From nobody Mon May 4 09:33:13 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 E81791A8F3E for ; Mon, 4 May 2015 09:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 3SxkC8mS6BKo for ; Mon, 4 May 2015 09:33:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906601A8F44 for ; Mon, 4 May 2015 09:33:07 -0700 (PDT) Received: from BY2FFO11FD055.protection.gbl (10.1.14.34) by BY2FFO11HUB015.protection.gbl (10.1.15.224) with Microsoft SMTP Server (TLS) id 15.1.160.8; Mon, 4 May 2015 16:32:51 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BY2FFO11FD055.mail.protection.outlook.com (10.1.15.192) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Mon, 4 May 2015 16:32:51 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t44GOXTj002097; Mon, 4 May 2015 11:32:49 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm3.corp.sprint.com with ESMTP id 1u4uu44kav-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 04 May 2015 11:32:49 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 4 May 2015 12:32:48 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Mon, 4 May 2015 11:32:48 -0500 From: "Gorman, Pierce A [CTO]" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) Thread-Index: AQHQhFUl+QUo8MY+akuT8Kpz6DUPlJ1sAmVg Date: Mon, 4 May 2015 16:32:46 +0000 Message-ID: References: <5543EEEA.9090903@usdonovans.com> In-Reply-To: <5543EEEA.9090903@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(106116001)(2656002)(87936001)(108616004)(107886002)(47776003)(24736003)(5001960100002)(46406003)(86362001)(5250100002)(62966003)(77156002)(102836002)(15975445007)(97756001)(5001920100001)(5001770100001)(50986999)(50466002)(33646002)(2900100001)(92566002)(19580405001)(19580395003)(6806004)(2950100001)(46102003)(2501003)(23726002)(76176999)(54356999)(85326001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB015; H:plsapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB015; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB015; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB015; X-Forefront-PRVS: 05669A7924 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2015 16:32:51.3141 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB015 Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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: Mon, 04 May 2015 16:33:11 -0000 If we can agree we eliminate the charter language that implies creating a f= ramework which supplants the authority of the NANC (at least) and which ass= umes a replacement of the NPAC and LERG databases, we will have made progre= ss (IMHO). Beyond striking objectionable language, the reason for David Holmes' posts = following mine last week was to try to improve the focus of the work for MO= DERN. We do think it is a bad idea to ignore that number administration an= d routing solutions need to evolve. And we're not against the MODERN worki= ng group identifying problems. In fact we're in favor of it. Its what to = do past that where we're struggling. The thing I'm concerned about is a repeat of the e164.arpa fiasco which suc= ceeded in defining a global schema and protocol for managing numbers and re= solving them for routing and which failed utterly. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 M: 816-210-8623 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan Sent: May 01, 2015 4:24 PM To: modern@ietf.org Subject: [Modern] MODERN will solve no problems (or will the IETF take over= the world?) The question of what problem(s) MODERN will address has been asked, multipl= e times. The short answer is that, in an of itself, MODERN will solve no problems. This isn't to say there aren't problems with existing mechanisms. It is to = say that all MODERN can do is to specify protocols that can then be part of= an overall solution that addresses problems that exist with those existing= mechanisms. There is a brief capture of these problems in the latest version of the charter: "A sample of problems with existing mechanisms include: - lack of flexibility (for example, it can be difficult to add fields witho= ut a very elaborate and lengthy process typically spanning years) - lack of distribution (for example, it is hard or impossible to have more = than one administrator for each database) - complexity (leading, for example, to a fair amount of rural call completi= on problems which aren't helped by small providers struggling to keep numbe= rs straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and p= orting mechanisms" Will MODERN solve these problems? No. Will MODERN make it possible for these problems to be addressed as part of = new number management policies to be enacted by the appropriate authorities= ? That, I believe, is the goal. Will MODERN force any of these new number management policies to be enacted= . No. The IETF is not a policy setting body. I'm ok with having a more detailed articulation of the problem statement as= part of the deliverables of the MODERN working group. I don't see the bene= fit of making that the only deliverable and forcing rechartering after that= document is finished. Let's instead agree to shut the working group down = if there is consensus that it is going nowhere (which I'm sure the ADs will= do anyway). Regards, Steve _______________________________________________ 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 Mon May 4 11:11:14 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 34D2A1A875A for ; Mon, 4 May 2015 11:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ef2keXPtOW-f for ; Mon, 4 May 2015 11:11:10 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 781521A1B53 for ; Mon, 4 May 2015 11:11:10 -0700 (PDT) Received: (qmail 4235 invoked by uid 0); 4 May 2015 18:11:10 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 4 May 2015 18:11:10 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id Ptr31q00M1MNPNq01tr6jF; Mon, 04 May 2015 11:51:08 -0600 X-Authority-Analysis: v=2.1 cv=Zox+dbLG c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=HpcNlDGhtQ0A:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=h1PgugrvaO0A:10 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=izV7ms69AAAA:8 a=IS-bRu1F8lnysgcpe4EA:9 a=27C0lyJNGADMasWV:21 a=cOLhiqozaNdcn0gx:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=DzjOOp_o1eYA:10 a=J3Jr8k8s6kMA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=Mg5OFUFLPNccLkwvjLD8MjuVAnaTzdeItMFH0DlcyNs=; b=nYDHMRBPnLjSGEpOXTEMe34Si5DfAg++pZkVcpLNpkwJy5nDl0znif5IDKOC9/KjineA21PBuv9f+7kz25/yEKt5YJDDEyyeBGua0JNWAjLdGNFDpID7IhFPuRimPV0R; Received: from [108.56.131.201] (port=64486 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YpKWG-0000Wo-Ri; Mon, 04 May 2015 11:51:05 -0600 User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Mon, 04 May 2015 13:50:59 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) References: <5543EEEA.9090903@usdonovans.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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: Mon, 04 May 2015 18:11:13 -0000 Well said.=20 There were two issues here. First is E.164 number allocation, management and administration vs the second is a query response mechanism for data retrivial surrounding phone numbers specifically routing and session establishment data [SED] query & retrieval. The first issue is the generally the problem. The FCC workshop clearly identified two options. Given time frames surrounding the PSTN Transition we had to find mechanisms to use the existing databases and tools to get the job done. That work, as you correctly point out, was the focus of the ATIS/SIP Forum JV and NNI TF. We are done with Phase 1 and this week will start to look at what Phase 2 looks like. The balloting is done. We did not reach consensus on a single method for session routing but we documented enough so that service providers can begin to automate a process that was becoming unmanageable using bi-lateral exchange of spreadsheets. There are a bunch of decisions that now have to be made on how to implement those Recommendations. Those decisions will have to occur within the NANC and INC very quickly. http://www.sipforum.org/content/view/427/171/ There was some general agreement at the workshop that the existing number management system could use a fresh review but there was consensus that the time frames for accomplishing that were =B3indeterminate=B2 at best. As anyone who knows this space can tell you the numbering registrant-registrar-registry construct is ultimately national policy but the real cost structure is in the OSS/BSS systems. Any service provider will testify that modifying those systems takes a lot of zeros behind lots of dollars. Dollars that service providers are loathe to spend. This is not a North American centric problem. This is interesting work but as Brother Burger points out, beyond North America who is going to buy the product? Believe me the UK DE IT and FR could use it but OFCOM for example has enough to worry about right now and their industry consultation process is just as convoluted as the ones in the US and CA. Second was the larger issue of the query response mechanism. On that there has been nearly universal consensus. ENUM sort of sucks. I should know. You all know my background here and I can assure you that knowing what I know now I would have not supported using DNS for what became RFC 6116, but at the time it was the best and most logical choice. DNS is not a =8Cmodern=B9 protocol (pun intended) by any stretch of the imagination but it has proven to be a pretty good TCAP replacement in widespread deployment. We all know the problems, lack of authentication, security, lack of determinate response..the list is rather long. e164.arpa was a total failure as a number management scheme but rethinking the query response mechanism along the lines of TERQ could be useful and deployable. Its also useful to remind ourselves that DRINKS was essentially a failure. https://tools.ietf.org/wg/drinks/charters =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 5/4/15, 12:32 PM, "Gorman, Pierce A [CTO]" wrote: >If we can agree we eliminate the charter language that implies creating a >framework which supplants the authority of the NANC (at least) and which >assumes a replacement of the NPAC and LERG databases, we will have made >progress (IMHO). > >Beyond striking objectionable language, the reason for David Holmes' >posts following mine last week was to try to improve the focus of the >work for MODERN. We do think it is a bad idea to ignore that number >administration and routing solutions need to evolve. And we're not >against the MODERN working group identifying problems. In fact we're in >favor of it. Its what to do past that where we're struggling. > >The thing I'm concerned about is a repeat of the e164.arpa fiasco which >succeeded in defining a global schema and protocol for managing numbers >and resolving them for routing and which failed utterly. > >Best regards, > > >Pierce Gorman >Core Network Planning >O: 913-439-4368 M: 816-210-8623 >pierce.gorman@sprint.com > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan >Sent: May 01, 2015 4:24 PM >To: modern@ietf.org >Subject: [Modern] MODERN will solve no problems (or will the IETF take >over the world?) > >The question of what problem(s) MODERN will address has been asked, >multiple times. > >The short answer is that, in an of itself, MODERN will solve no problems. > >This isn't to say there aren't problems with existing mechanisms. It is >to say that all MODERN can do is to specify protocols that can then be >part of an overall solution that addresses problems that exist with those >existing mechanisms. > >There is a brief capture of these problems in the latest version of the >charter: > >"A sample of problems with existing mechanisms include: > >- lack of flexibility (for example, it can be difficult to add fields >without a very elaborate and lengthy process typically spanning years) >- lack of distribution (for example, it is hard or impossible to have >more than one administrator for each database) >- complexity (leading, for example, to a fair amount of rural call >completion problems which aren't helped by small providers struggling to >keep numbers straight) >- difficulty of adopting more modern allocation (e.g., "blocks" of 1) and >porting mechanisms" > >Will MODERN solve these problems? No. > >Will MODERN make it possible for these problems to be addressed as part >of new number management policies to be enacted by the appropriate >authorities? That, I believe, is the goal. > >Will MODERN force any of these new number management policies to be >enacted. No. The IETF is not a policy setting body. > >I'm ok with having a more detailed articulation of the problem statement >as part of the deliverables of the MODERN working group. I don't see the >benefit of making that the only deliverable and forcing rechartering >after that document is finished. Let's instead agree to shut the working >group down if there is consensus that it is going nowhere (which I'm sure >the ADs will do anyway). > >Regards, > >Steve > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole 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. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Mon May 4 11:29:38 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 F20CD1ACD31 for ; Mon, 4 May 2015 11:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 7jmeOM5k2R-r for ; Mon, 4 May 2015 11:29:36 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 24E711A87D1 for ; Mon, 4 May 2015 11:29:36 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:58129 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YpL7W-0001Hy-7E for modern@ietf.org; Mon, 04 May 2015 11:29:35 -0700 Message-ID: <5547BA8D.50706@usdonovans.com> Date: Mon, 04 May 2015 13:29:33 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <5543EEEA.9090903@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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: Mon, 04 May 2015 18:29:38 -0000 Pierce, See my comments inline. Regards, Steve On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: > If we can agree we eliminate the charter language that implies creating a framework which supplants the authority of the NANC (at least) and which assumes a replacement of the NPAC and LERG databases, we will have made progress (IMHO). SRD> This should be easy to do, as there is no intent and, even if there were intent, there is no ability for the MODERN group to take anyone's authority or replace anyone's database. SRD> Is the problem with the word framework in the second paragraph? Would calling it an "architectural framework" help? > > Beyond striking objectionable language, the reason for David Holmes' posts following mine last week was to try to improve the focus of the work for MODERN. We do think it is a bad idea to ignore that number administration and routing solutions need to evolve. And we're not against the MODERN working group identifying problems. In fact we're in favor of it. Its what to do past that where we're struggling. SRD> I share the desire to focus the work. I think the revisions of the charter have moved in this direction. > > The thing I'm concerned about is a repeat of the e164.arpa fiasco which succeeded in defining a global schema and protocol for managing numbers and resolving them for routing and which failed utterly. SRD> We fail if we don't learn from our mistakes. I'm confident we will have enough involvement in the group to keep us pointed in the right direction. > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 M: 816-210-8623 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: May 01, 2015 4:24 PM > To: modern@ietf.org > Subject: [Modern] MODERN will solve no problems (or will the IETF take over the world?) > > The question of what problem(s) MODERN will address has been asked, multiple times. > > The short answer is that, in an of itself, MODERN will solve no problems. > > This isn't to say there aren't problems with existing mechanisms. It is to say that all MODERN can do is to specify protocols that can then be part of an overall solution that addresses problems that exist with those existing mechanisms. > > There is a brief capture of these problems in the latest version of the > charter: > > "A sample of problems with existing mechanisms include: > > - lack of flexibility (for example, it can be difficult to add fields without a very elaborate and lengthy process typically spanning years) > - lack of distribution (for example, it is hard or impossible to have more than one administrator for each database) > - complexity (leading, for example, to a fair amount of rural call completion problems which aren't helped by small providers struggling to keep numbers straight) > - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms" > > Will MODERN solve these problems? No. > > Will MODERN make it possible for these problems to be addressed as part of new number management policies to be enacted by the appropriate authorities? That, I believe, is the goal. > > Will MODERN force any of these new number management policies to be enacted. No. The IETF is not a policy setting body. > > I'm ok with having a more detailed articulation of the problem statement as part of the deliverables of the MODERN working group. I don't see the benefit of making that the only deliverable and forcing rechartering after that document is finished. Let's instead agree to shut the working group down if there is consensus that it is going nowhere (which I'm sure the ADs will do anyway). > > Regards, > > Steve > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the sole 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. > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Mon May 4 13:53:34 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 0E6551B2A42 for ; Mon, 4 May 2015 13:53:33 -0700 (PDT) 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 Ll5E5Gvl98D8 for ; Mon, 4 May 2015 13:53:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09791A8888 for ; Mon, 4 May 2015 13:53:28 -0700 (PDT) Received: from BY2FFO11FD008.protection.gbl (10.1.14.32) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.1.160.8; Mon, 4 May 2015 20:53:27 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Mon, 4 May 2015 20:53:27 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t44JxLHx026987; Mon, 4 May 2015 15:53:26 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm2.corp.sprint.com with ESMTP id 1u4vc05nq5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 04 May 2015 15:53:26 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 4 May 2015 15:53:25 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Mon, 4 May 2015 15:53:25 -0500 From: "Gorman, Pierce A [CTO]" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) Thread-Index: AQHQhFUl+QUo8MY+akuT8Kpz6DUPlJ1sAmVggAB5SoD//8gtoA== Date: Mon, 4 May 2015 20:53:25 +0000 Message-ID: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> References: <5543EEEA.9090903@usdonovans.com> <5547BA8D.50706@usdonovans.com> In-Reply-To: <5547BA8D.50706@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(377454003)(479174004)(51704005)(2501003)(15975445007)(102836002)(2950100001)(46406003)(50986999)(86362001)(97756001)(62966003)(2900100001)(77156002)(24736003)(5250100002)(85326001)(107886002)(5001960100002)(46102003)(92566002)(6806004)(19580405001)(19580395003)(33646002)(5001770100001)(50466002)(87936001)(47776003)(54356999)(76176999)(23726002)(108616004)(106116001)(106466001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB027; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB027; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB027; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB027; X-Forefront-PRVS: 05669A7924 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2015 20:53:27.1864 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB027 Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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: Mon, 04 May 2015 20:53:33 -0000 Thanks Steve. I don't think wordsmithing "framework" to be "architectural = framework" in the 2nd paragraph really addresses the underlying concern. I understand the temptation to jump right in and have MODERN develop a newe= r, better, solution to the existing (North American?) framework architectur= e but it feels like a bridge too far. I'd suggest striking the 2nd paragra= ph entirely, but I suspect that is also as unappealing to you as the paragr= aph is to me. I liked Eric Burger's suggestions regarding fleshing out problems by descri= bing use cases. One use case that occurs to me that might lead in the direction I think you= 're interested in is I've not seen sufficient description of how to associa= te "services" with telephone numbers. For example, many people are members= of more than one social networking application, and some social network ap= plications offer services which overlap with traditional telecommunications= and therefore could benefit from assocation with number_user telephone num= bers. I think it would be useful to explore how those services could be defined s= yntactically, managed, and discovered. But maybe that's just me. Maybe ot= hers find that useless and/or objectionable. It does seem like the directi= on you were wanting things to go in terms of giving number_users control ov= er service provider associations with their telephone number. And it seems= directionally correct in terms of addressing the interests of users and no= n-traditional communications service providers for service provider mash-up= s associated with a telephone number. I know I haven't directly answered your question about specific suggested c= hanges to the text in the charter. I would like to hear more from others. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan Sent: May 04, 2015 1:30 PM To: modern@ietf.org Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take = over the world?) Pierce, See my comments inline. Regards, Steve On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: > If we can agree we eliminate the charter language that implies creating a= framework which supplants the authority of the NANC (at least) and which a= ssumes a replacement of the NPAC and LERG databases, we will have made prog= ress (IMHO). SRD> This should be easy to do, as there is no intent and, even if there were intent, there is no ability for the MODERN group to take anyone's auth= ority or replace anyone's database. SRD> Is the problem with the word framework in the second paragraph? Would calling it an "architectural framework" help? > > Beyond striking objectionable language, the reason for David Holmes' post= s following mine last week was to try to improve the focus of the work for = MODERN. We do think it is a bad idea to ignore that number administration = and routing solutions need to evolve. And we're not against the MODERN wor= king group identifying problems. In fact we're in favor of it. Its what t= o do past that where we're struggling. SRD> I share the desire to focus the work. I think the revisions of the charter have moved in this direction. > > The thing I'm concerned about is a repeat of the e164.arpa fiasco which s= ucceeded in defining a global schema and protocol for managing numbers and = resolving them for routing and which failed utterly. SRD> We fail if we don't learn from our mistakes. I'm confident we will have enough involvement in the group to keep us pointed in the right direct= ion. > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve > Donovan > Sent: May 01, 2015 4:24 PM > To: modern@ietf.org > Subject: [Modern] MODERN will solve no problems (or will the IETF take > over the world?) > > The question of what problem(s) MODERN will address has been asked, multi= ple times. > > The short answer is that, in an of itself, MODERN will solve no problems. > > This isn't to say there aren't problems with existing mechanisms. It is t= o say that all MODERN can do is to specify protocols that can then be part = of an overall solution that addresses problems that exist with those existi= ng mechanisms. > > There is a brief capture of these problems in the latest version of > the > charter: > > "A sample of problems with existing mechanisms include: > > - lack of flexibility (for example, it can be difficult to add fields > without a very elaborate and lengthy process typically spanning years) > - lack of distribution (for example, it is hard or impossible to have > more than one administrator for each database) > - complexity (leading, for example, to a fair amount of rural call > completion problems which aren't helped by small providers struggling > to keep numbers straight) > - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and= porting mechanisms" > > Will MODERN solve these problems? No. > > Will MODERN make it possible for these problems to be addressed as part o= f new number management policies to be enacted by the appropriate authoriti= es? That, I believe, is the goal. > > Will MODERN force any of these new number management policies to be enact= ed. No. The IETF is not a policy setting body. > > I'm ok with having a more detailed articulation of the problem statement = as part of the deliverables of the MODERN working group. I don't see the be= nefit of making that the only deliverable and forcing rechartering after th= at document is finished. Let's instead agree to shut the working group dow= n if there is consensus that it is going nowhere (which I'm sure the ADs wi= ll do anyway). > > Regards, > > Steve > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ 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 Tue May 5 07:54:17 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 D685A1B2CD4 for ; Tue, 5 May 2015 07:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 r_aKHUYsYXHQ for ; Tue, 5 May 2015 07:54:11 -0700 (PDT) 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 69B9F1B2B1B for ; Tue, 5 May 2015 07:54:11 -0700 (PDT) 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 t45EsAcH015359; Tue, 5 May 2015 10:54:11 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1u6w9a8awj-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 05 May 2015 10:54:10 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Tue, 5 May 2015 10:54:07 -0400 From: "McGarry, Tom" To: "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) Thread-Index: AQHQh0NWK+QNUdAJk02oC9kvfdc35w== Date: Tue, 5 May 2015 14:54:07 +0000 Message-ID: In-Reply-To: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.204.255] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0830D12B87E5464FB496AF4FE68D9556@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-05_04:2015-05-05,2015-05-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.44384504352502e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.992957022353465 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.992957022353465 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.992957022353465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505050176 Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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, 05 May 2015 14:54:15 -0000 "=8A define a framework for the roles and functions involved in managing an= d resolving TNs =8A" is a necessary step to create a common understanding, fo= r a WG, of the ecosystem for managing TNs. For example the WG could define a communications service user, a communications service provider, a numbering authority, a numbering administrator, etc.; describe the functions of these roles and how they may interact with each other. Both presentations at the BoF did a good job of starting this discussion. As the charter states, the work done by the WG would be flexible enough to accommodate different administrative models, therefore the framework, roles and functions would need to be flexible. There is no intent to create a single administrative model, and there is no text in the charter that would suggest otherwise. In fact the charter states this explicitly. If there are text changes you could suggest that makes this clearer for you and others, please do. On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" wrote: >Thanks Steve. I don't think wordsmithing "framework" to be >"architectural framework" in the 2nd paragraph really addresses the >underlying concern. > >I understand the temptation to jump right in and have MODERN develop a >newer, better, solution to the existing (North American?) framework >architecture but it feels like a bridge too far. I'd suggest striking >the 2nd paragraph entirely, but I suspect that is also as unappealing to >you as the paragraph is to me. > >I liked Eric Burger's suggestions regarding fleshing out problems by >describing use cases. > >One use case that occurs to me that might lead in the direction I think >you're interested in is I've not seen sufficient description of how to >associate "services" with telephone numbers. For example, many people >are members of more than one social networking application, and some >social network applications offer services which overlap with traditional >telecommunications and therefore could benefit from assocation with >number_user telephone numbers. > >I think it would be useful to explore how those services could be defined >syntactically, managed, and discovered. But maybe that's just me. Maybe >others find that useless and/or objectionable. It does seem like the >direction you were wanting things to go in terms of giving number_users >control over service provider associations with their telephone number. >And it seems directionally correct in terms of addressing the interests >of users and non-traditional communications service providers for service >provider mash-ups associated with a telephone number. > >I know I haven't directly answered your question about specific suggested >changes to the text in the charter. I would like to hear more from >others. > >Best regards, > > >Pierce Gorman >Core Network Planning >O: 913-439-4368 >pierce.gorman@sprint.com > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan >Sent: May 04, 2015 1:30 PM >To: modern@ietf.org >Subject: Re: [Modern] MODERN will solve no problems (or will the IETF >take over the world?) > >Pierce, > >See my comments inline. > >Regards, > >Steve > >On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: >> If we can agree we eliminate the charter language that implies creating >>a framework which supplants the authority of the NANC (at least) and >>which assumes a replacement of the NPAC and LERG databases, we will have >>made progress (IMHO). >SRD> This should be easy to do, as there is no intent and, even if there >were intent, there is no ability for the MODERN group to take anyone's >authority or replace anyone's database. > >SRD> Is the problem with the word framework in the second paragraph? >Would calling it an "architectural framework" help? >> >> Beyond striking objectionable language, the reason for David Holmes' >>posts following mine last week was to try to improve the focus of the >>work for MODERN. We do think it is a bad idea to ignore that number >>administration and routing solutions need to evolve. And we're not >>against the MODERN working group identifying problems. In fact we're in >>favor of it. Its what to do past that where we're struggling. >SRD> I share the desire to focus the work. I think the revisions of the >charter have moved in this direction. >> >> The thing I'm concerned about is a repeat of the e164.arpa fiasco which >>succeeded in defining a global schema and protocol for managing numbers >>and resolving them for routing and which failed utterly. >SRD> We fail if we don't learn from our mistakes. I'm confident we will >have enough involvement in the group to keep us pointed in the right >direction. >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >> Donovan >> Sent: May 01, 2015 4:24 PM >> To: modern@ietf.org >> Subject: [Modern] MODERN will solve no problems (or will the IETF take >> over the world?) >> >> The question of what problem(s) MODERN will address has been asked, >>multiple times. >> >> The short answer is that, in an of itself, MODERN will solve no >>problems. >> >> This isn't to say there aren't problems with existing mechanisms. It is >>to say that all MODERN can do is to specify protocols that can then be >>part of an overall solution that addresses problems that exist with >>those existing mechanisms. >> >> There is a brief capture of these problems in the latest version of >> the >> charter: >> >> "A sample of problems with existing mechanisms include: >> >> - lack of flexibility (for example, it can be difficult to add fields >> without a very elaborate and lengthy process typically spanning years) >> - lack of distribution (for example, it is hard or impossible to have >> more than one administrator for each database) >> - complexity (leading, for example, to a fair amount of rural call >> completion problems which aren't helped by small providers struggling >> to keep numbers straight) >> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) >>and porting mechanisms" >> >> Will MODERN solve these problems? No. >> >> Will MODERN make it possible for these problems to be addressed as part >>of new number management policies to be enacted by the appropriate >>authorities? That, I believe, is the goal. >> >> Will MODERN force any of these new number management policies to be >>enacted. No. The IETF is not a policy setting body. >> >> I'm ok with having a more detailed articulation of the problem >>statement as part of the deliverables of the MODERN working group. I >>don't see the benefit of making that the only deliverable and forcing >>rechartering after that document is finished. Let's instead agree to >>shut the working group down if there is consensus that it is going >>nowhere (which I'm sure the ADs will do anyway). >> >> Regards, >> >> Steve >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s= =3Dh >>tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the >>sole 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. >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s= =3Dh >>tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= htIM >_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole 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. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= htIM >_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D=20 From nobody Tue May 5 08:07:14 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 1147C1A037D for ; Tue, 5 May 2015 08:07:13 -0700 (PDT) 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 MdXXsi8ErZAZ for ; Tue, 5 May 2015 08:07:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3B41A0399 for ; Tue, 5 May 2015 08:06:47 -0700 (PDT) Received: from BN1BFFO11FD021.protection.gbl (10.58.144.30) by BN1BFFO11HUB008.protection.gbl (10.58.144.155) with Microsoft SMTP Server (TLS) id 15.1.160.8; Tue, 5 May 2015 15:06:46 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1BFFO11FD021.mail.protection.outlook.com (10.58.144.84) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Tue, 5 May 2015 15:06:46 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t45Ev048028969; Tue, 5 May 2015 10:06:45 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 1u4vc07xbt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 05 May 2015 10:06:45 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 5 May 2015 11:06:44 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 5 May 2015 10:06:43 -0500 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) Thread-Index: AQHQh0Nb3VTVMsdme0C3IHoGfrevXJ1tefcw Date: Tue, 5 May 2015 15:06:42 +0000 Message-ID: <90f7e39770be4118aa5ed9ca31f72b20@PLSWE13M08.ad.sprint.com> References: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.39] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(479174004)(51704005)(189002)(24454002)(199003)(377454003)(5001960100002)(108616004)(2656002)(50466002)(2950100001)(87936001)(5250100002)(2501003)(24736003)(47776003)(107886002)(2900100001)(76176999)(15975445007)(33646002)(102836002)(85326001)(50986999)(54356999)(19580395003)(46102003)(106466001)(62966003)(106116001)(6806004)(92566002)(19580405001)(77156002)(86362001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB008; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB008; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB008; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB008; X-Forefront-PRVS: 0567A15835 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2015 15:06:46.2749 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB008 Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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, 05 May 2015 15:07:13 -0000 Thanks Tom. As I said, my suggestion would be to strike the paragraph 2 te= xt. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz] Sent: May 05, 2015 9:54 AM To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take = over the world?) "=A9 define a framework for the roles and functions involved in managing an= d resolving TNs =A9" is a necessary step to create a common understanding, = for a WG, of the ecosystem for managing TNs. For example the WG could define a communications service user, a communicat= ions service provider, a numbering authority, a numbering administrator, et= c.; describe the functions of these roles and how they may interact with ea= ch other. Both presentations at the BoF did a good job of starting this di= scussion. As the charter states, the work done by the WG would be flexible enough to = accommodate different administrative models, therefore the framework, roles= and functions would need to be flexible. There is no intent to create a s= ingle administrative model, and there is no text in the charter that would = suggest otherwise. In fact the charter states this explicitly. If there are text changes you could suggest that makes this clearer for yo= u and others, please do. On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" wrote: >Thanks Steve. I don't think wordsmithing "framework" to be >"architectural framework" in the 2nd paragraph really addresses the >underlying concern. > >I understand the temptation to jump right in and have MODERN develop a >newer, better, solution to the existing (North American?) framework >architecture but it feels like a bridge too far. I'd suggest striking >the 2nd paragraph entirely, but I suspect that is also as unappealing >to you as the paragraph is to me. > >I liked Eric Burger's suggestions regarding fleshing out problems by >describing use cases. > >One use case that occurs to me that might lead in the direction I think >you're interested in is I've not seen sufficient description of how to >associate "services" with telephone numbers. For example, many people >are members of more than one social networking application, and some >social network applications offer services which overlap with >traditional telecommunications and therefore could benefit from >assocation with number_user telephone numbers. > >I think it would be useful to explore how those services could be >defined syntactically, managed, and discovered. But maybe that's just >me. Maybe others find that useless and/or objectionable. It does seem >like the direction you were wanting things to go in terms of giving >number_users control over service provider associations with their telepho= ne number. >And it seems directionally correct in terms of addressing the interests >of users and non-traditional communications service providers for >service provider mash-ups associated with a telephone number. > >I know I haven't directly answered your question about specific >suggested changes to the text in the charter. I would like to hear >more from others. > >Best regards, > > >Pierce Gorman >Core Network Planning >O: 913-439-4368 >pierce.gorman@sprint.com > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >Donovan >Sent: May 04, 2015 1:30 PM >To: modern@ietf.org >Subject: Re: [Modern] MODERN will solve no problems (or will the IETF >take over the world?) > >Pierce, > >See my comments inline. > >Regards, > >Steve > >On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: >> If we can agree we eliminate the charter language that implies >>creating a framework which supplants the authority of the NANC (at >>least) and which assumes a replacement of the NPAC and LERG databases, >>we will have made progress (IMHO). >SRD> This should be easy to do, as there is no intent and, even if >SRD> there >were intent, there is no ability for the MODERN group to take anyone's >authority or replace anyone's database. > >SRD> Is the problem with the word framework in the second paragraph? >Would calling it an "architectural framework" help? >> >> Beyond striking objectionable language, the reason for David Holmes' >>posts following mine last week was to try to improve the focus of the >>work for MODERN. We do think it is a bad idea to ignore that number >>administration and routing solutions need to evolve. And we're not >>against the MODERN working group identifying problems. In fact we're >>in favor of it. Its what to do past that where we're struggling. >SRD> I share the desire to focus the work. I think the revisions of >SRD> the >charter have moved in this direction. >> >> The thing I'm concerned about is a repeat of the e164.arpa fiasco >>which succeeded in defining a global schema and protocol for managing >>numbers and resolving them for routing and which failed utterly. >SRD> We fail if we don't learn from our mistakes. I'm confident we >SRD> will >have enough involvement in the group to keep us pointed in the right >direction. >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >> Donovan >> Sent: May 01, 2015 4:24 PM >> To: modern@ietf.org >> Subject: [Modern] MODERN will solve no problems (or will the IETF >> take over the world?) >> >> The question of what problem(s) MODERN will address has been asked, >>multiple times. >> >> The short answer is that, in an of itself, MODERN will solve no >>problems. >> >> This isn't to say there aren't problems with existing mechanisms. It >>is to say that all MODERN can do is to specify protocols that can then >>be part of an overall solution that addresses problems that exist with >>those existing mechanisms. >> >> There is a brief capture of these problems in the latest version of >> the >> charter: >> >> "A sample of problems with existing mechanisms include: >> >> - lack of flexibility (for example, it can be difficult to add fields >>without a very elaborate and lengthy process typically spanning years) >> - lack of distribution (for example, it is hard or impossible to have >>more than one administrator for each database) >> - complexity (leading, for example, to a fair amount of rural call >>completion problems which aren't helped by small providers struggling >>to keep numbers straight) >> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) >>and porting mechanisms" >> >> Will MODERN solve these problems? No. >> >> Will MODERN make it possible for these problems to be addressed as >>part of new number management policies to be enacted by the >>appropriate authorities? That, I believe, is the goal. >> >> Will MODERN force any of these new number management policies to be >>enacted. No. The IETF is not a policy setting body. >> >> I'm ok with having a more detailed articulation of the problem >>statement as part of the deliverables of the MODERN working group. I >>don't see the benefit of making that the only deliverable and forcing >>rechartering after that document is finished. Let's instead agree to >>shut the working group down if there is consensus that it is going >>nowhere (which I'm sure the ADs will do anyway). >> >> Regards, >> >> Steve >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>man >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eID >>cLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& >>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for >>the sole 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. >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>man >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eID >>cLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& >>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= h >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole 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. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= h >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D ________________________________ 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 Thu May 7 06:51: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 02D7E1A8AE2 for ; Thu, 7 May 2015 06:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] 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 2JQqkDUB7-w8 for ; Thu, 7 May 2015 06:50:51 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 4AC081A8A9A for ; Thu, 7 May 2015 06:50:51 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:56430 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YqMCP-0003CT-7S for modern@ietf.org; Thu, 07 May 2015 06:50:50 -0700 Message-ID: <554B6DB9.9010901@usdonovans.com> Date: Thu, 07 May 2015 08:50:49 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "modern@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] Proposed change to paragraph three of the charter 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, 07 May 2015 13:51:01 -0000 All, Paragraph three currently reads as follows: "The work of this group will focus on E.164 telephone numbers due to the changing telecom environment and interest expressed by telecommunications industry regulators to support more flexible regulatory models than exist today. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reuse of MODERN mechanisms are out of scope for the MODERN working group. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies." I propose changing the first sentence to the following: "The work of this group will focus on TNs -- such as E.164 numbers -- and blocks of TNs, that are used to initiate communication with another user of a service. The work is motivated by the changing telecom environment and interest expressed by telecommunications industry regulators to support more flexible regulatory models than exist today. " The remainder of the paragraph, starting with "There is an expectation..." would remain unchanged. This adds some clarity on the scope of telephony identifiers covered as well as making it clear that blocks of TNs are also covered. Regards, Steve From nobody Fri May 8 10:59:15 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 F2E421B2E18 for ; Fri, 8 May 2015 10:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 QrChg8SiVG1D for ; Fri, 8 May 2015 10:59:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F1A1B2E12 for ; Fri, 8 May 2015 10:59:03 -0700 (PDT) Received: from BN1AFFO11FD053.protection.gbl (10.58.52.31) by BN1AFFO11HUB006.protection.gbl (10.58.52.116) with Microsoft SMTP Server (TLS) id 15.1.160.8; Fri, 8 May 2015 17:58:44 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.81) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm2.corp.sprint.com (144.230.32.81) by BN1AFFO11FD053.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Fri, 8 May 2015 17:58:44 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t48HVU0I022991; Fri, 8 May 2015 13:58:43 -0400 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm2.corp.sprint.com with ESMTP id 1u4qknmvhk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 08 May 2015 13:58:43 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 8 May 2015 12:58:42 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Fri, 8 May 2015 12:58:42 -0500 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) Thread-Index: AQHQh0Uv8+KKXVduQ06DdfN8fCFs+p1yYUFQ Date: Fri, 8 May 2015 17:58:41 +0000 Message-ID: <09ec73f2cd0f4d228e9fe15ddd2b3b4b@PLSWE13M08.ad.sprint.com> References: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> <90f7e39770be4118aa5ed9ca31f72b20@PLSWE13M08.ad.sprint.com> In-Reply-To: <90f7e39770be4118aa5ed9ca31f72b20@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.94] Content-Type: multipart/alternative; boundary="_000_09ec73f2cd0f4d228e9fe15ddd2b3b4bPLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(448002)(24454002)(479174004)(13464003)(189002)(199003)(51704005)(377454003)(30436002)(5001960100002)(4546004)(85326001)(2501003)(84326002)(16236675004)(19300405004)(108616004)(5001770100001)(86362001)(5250100002)(106466001)(24736003)(15975445007)(106116001)(92566002)(107886002)(33646002)(2900100001)(2950100001)(46102003)(2656002)(87936001)(76176999)(50986999)(19617315012)(19625215002)(19580405001)(54356999)(102836002)(6806004)(19580395003)(77156002)(189998001)(62966003)(579004)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB006; H:preapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB006; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB006; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB006; X-Forefront-PRVS: 0570F1F193 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2015 17:58:44.1295 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB006 Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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: Fri, 08 May 2015 17:59:13 -0000 --_000_09ec73f2cd0f4d228e9fe15ddd2b3b4bPLSWE13M08adsprintcom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Steve, Here is a suggested set of changes to the 2nd paragraph. OLD: The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. TNs may either b= e managed in a hierarchical tree, or in a distributed peer-to-peer architec= ture. Privacy of the enrollment data and security of the resource will be = primary considerations. NEW: The working group will define a an information management framework for the= roles and functions involved in managing and resolving TNs associating SER= VICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in= an IP environment. This includes a protocol mechanism for acquiring TNs, w= hich will provide an enrollment process for the individuals and entities th= at use and manage TNs. TNs may either be managed in a hierarchical tree, or= in a distributed peer-to-peer architecture. Privacy of the enrollment man= aged data and security of the resource will be primary considerations. I would prefer if others weighed in here. I don't like being one of a few = with such influence. Because I wasn't at the BoF and am new at this sort of thing, I personally = would be happier if we took more time in e-mail or meetings to discuss the = problems the WG should address, not the solutions (at first). A specific area of concern for me is the data model of information associat= ed with telephone numbers. I care much more about what is being provision= ed then I do about how it is provisioned or shared. I think trying to identify the what first will be more valuable than the ho= w, and certainly more important than the who. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz] Sent: May 05, 2015 9:54 AM To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take = over the world?) "=A9 define a framework for the roles and functions involved in managing an= d resolving TNs =A9" is a necessary step to create a common understanding, = for a WG, of the ecosystem for managing TNs. For example the WG could define a communications service user, a communicat= ions service provider, a numbering authority, a numbering administrator, et= c.; describe the functions of these roles and how they may interact with ea= ch other. Both presentations at the BoF did a good job of starting this di= scussion. As the charter states, the work done by the WG would be flexible enough to = accommodate different administrative models, therefore the framework, roles= and functions would need to be flexible. There is no intent to create a s= ingle administrative model, and there is no text in the charter that would = suggest otherwise. In fact the charter states this explicitly. If there are text changes you could suggest that makes this clearer for you= and others, please do. On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" > wrote: >Thanks Steve. I don't think wordsmithing "framework" to be >"architectural framework" in the 2nd paragraph really addresses the >underlying concern. > >I understand the temptation to jump right in and have MODERN develop a >newer, better, solution to the existing (North American?) framework >architecture but it feels like a bridge too far. I'd suggest striking >the 2nd paragraph entirely, but I suspect that is also as unappealing >to you as the paragraph is to me. > >I liked Eric Burger's suggestions regarding fleshing out problems by >describing use cases. > >One use case that occurs to me that might lead in the direction I think >you're interested in is I've not seen sufficient description of how to >associate "services" with telephone numbers. For example, many people >are members of more than one social networking application, and some >social network applications offer services which overlap with >traditional telecommunications and therefore could benefit from >assocation with number_user telephone numbers. > >I think it would be useful to explore how those services could be >defined syntactically, managed, and discovered. But maybe that's just >me. Maybe others find that useless and/or objectionable. It does seem >like the direction you were wanting things to go in terms of giving >number_users control over service provider associations with their telepho= ne number. >And it seems directionally correct in terms of addressing the interests >of users and non-traditional communications service providers for >service provider mash-ups associated with a telephone number. > >I know I haven't directly answered your question about specific >suggested changes to the text in the charter. I would like to hear >more from others. > >Best regards, > > >Pierce Gorman >Core Network Planning >O: 913-439-4368 >pierce.gorman@sprint.com > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >Donovan >Sent: May 04, 2015 1:30 PM >To: modern@ietf.org >Subject: Re: [Modern] MODERN will solve no problems (or will the IETF >take over the world?) > >Pierce, > >See my comments inline. > >Regards, > >Steve > >On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: >> If we can agree we eliminate the charter language that implies >>creating a framework which supplants the authority of the NANC (at >>least) and which assumes a replacement of the NPAC and LERG databases, >>we will have made progress (IMHO). >SRD> This should be easy to do, as there is no intent and, even if >SRD> there >were intent, there is no ability for the MODERN group to take anyone's >authority or replace anyone's database. > >SRD> Is the problem with the word framework in the second paragraph? >Would calling it an "architectural framework" help? >> >> Beyond striking objectionable language, the reason for David Holmes' >>posts following mine last week was to try to improve the focus of the >>work for MODERN. We do think it is a bad idea to ignore that number >>administration and routing solutions need to evolve. And we're not >>against the MODERN working group identifying problems. In fact we're >>in favor of it. Its what to do past that where we're struggling. >SRD> I share the desire to focus the work. I think the revisions of >SRD> the >charter have moved in this direction. >> >> The thing I'm concerned about is a repeat of the e164.arpa fiasco >>which succeeded in defining a global schema and protocol for managing >>numbers and resolving them for routing and which failed utterly. >SRD> We fail if we don't learn from our mistakes. I'm confident we >SRD> will >have enough involvement in the group to keep us pointed in the right >direction. >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >> Donovan >> Sent: May 01, 2015 4:24 PM >> To: modern@ietf.org >> Subject: [Modern] MODERN will solve no problems (or will the IETF >> take over the world?) >> >> The question of what problem(s) MODERN will address has been asked, >>multiple times. >> >> The short answer is that, in an of itself, MODERN will solve no >>problems. >> >> This isn't to say there aren't problems with existing mechanisms. It >>is to say that all MODERN can do is to specify protocols that can then >>be part of an overall solution that addresses problems that exist with >>those existing mechanisms. >> >> There is a brief capture of these problems in the latest version of >> the >> charter: >> >> "A sample of problems with existing mechanisms include: >> >> - lack of flexibility (for example, it can be difficult to add fields >>without a very elaborate and lengthy process typically spanning years) >> - lack of distribution (for example, it is hard or impossible to have >>more than one administrator for each database) >> - complexity (leading, for example, to a fair amount of rural call >>completion problems which aren't helped by small providers struggling >>to keep numbers straight) >> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) >>and porting mechanisms" >> >> Will MODERN solve these problems? No. >> >> Will MODERN make it possible for these problems to be addressed as >>part of new number management policies to be enacted by the >>appropriate authorities? That, I believe, is the goal. >> >> Will MODERN force any of these new number management policies to be >>enacted. No. The IETF is not a policy setting body. >> >> I'm ok with having a more detailed articulation of the problem >>statement as part of the deliverables of the MODERN working group. I >>don't see the benefit of making that the only deliverable and forcing >>rechartering after that document is finished. Let's instead agree to >>shut the working group down if there is consensus that it is going >>nowhere (which I'm sure the ADs will do anyway). >> >> Regards, >> >> Steve >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>man >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eID >>cLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& >>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for >>the sole 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. >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>man >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eID >>cLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& >>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= h >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole 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. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= h >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D ________________________________ 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. _______________________________________________ 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. --_000_09ec73f2cd0f4d228e9fe15ddd2b3b4bPLSWE13M08adsprintcom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Steve,

 

Here is a suggested set of changes to the 2nd paragraph.

 

OLD:

 

The working group will define a framework for the ro= les and functions involved in managing and resolving TNs in an IP environme= nt. This includes a protocol mechanism for acquiring TNs, which will provid= e an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hiera= rchical tree, or in a distributed peer-to-peer architecture.  Privacy = of the enrollment data and security of the resource will be primary conside= rations.

 

NEW:

 

The working group will define a an information management framework fo= r the roles and functions involved in managing and resolving TNs associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one= or more TNs in an IP environment. This includes a p= rotocol mechanism for acquiring TNs, which will provide an enrollment proce= ss for the individuals and entities that use and manage TNs. TNs may either= be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of= the enrollment managed data and security of the resou= rce will be primary considerations.

 

I would prefer if others weighed in here.  I= don’t like being one of a few with such influence.

 

Because I wasn’t at the BoF and am new at t= his sort of thing, I personally would be happier if we took more time in e-= mail or meetings to discuss the problems the WG should address, not the sol= utions (at first).

 

A specific area of concern for me is the data mod= el of information associated with telephone numbers.   I care muc= h more about what is being provisioned then I do about how it is provisione= d or shared.

 

I think trying to identify the what first will be= more valuable than the how, and certainly more important than the who.&nbs= p;

 

Best regards,

 

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

 

 

-----Original Message-----

From: McGarry, Tom [mailto:= Tom.McGarry@neustar.biz]

Sent: May 05, 2015 9:54 AM

To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org

Subject: Re: [Modern] MODERN will solve no proble= ms (or will the IETF take over the world?)

 

"=A9 define a framework for the roles and fu= nctions involved in managing and resolving TNs =A9" is a necessary ste= p to create a common understanding, for a WG, of the ecosystem for managing= TNs.

 

For example the WG could define a communications = service user, a communications service provider, a numbering authority, a n= umbering administrator, etc.; describe the functions of these roles and how= they may interact with each other.  Both presentations at the BoF did a good job of starting this discussion.<= o:p>

 

As the charter states, the work done by the WG wo= uld be flexible enough to accommodate different administrative models, ther= efore the framework, roles and functions would need to be flexible.  T= here is no intent to create a single administrative model, and there is no text in the charter that would suggest otherwise.&n= bsp; In fact the charter states this explicitly.

If there are text changes you could suggest that = makes this clearer for you and others, please do.

 

 

 

On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]&q= uot; <Pierce.Gorman@sprint.com>

wrote:

 

>Thanks Steve.  I don't think wordsmithin= g "framework" to be

>"architectural framework" in the 2n= d paragraph really addresses the

>underlying concern.

> 

>I understand the temptation to jump right in = and have MODERN develop a

>newer, better, solution to the existing (Nort= h American?) framework

>architecture but it feels like a bridge too f= ar.  I'd suggest striking

>the 2nd paragraph entirely, but I suspect tha= t is also as unappealing

>to you as the paragraph is to me.<= /p>

> 

>I liked Eric Burger's suggestions regarding f= leshing out problems by

>describing use cases.

> 

>One use case that occurs to me that might lea= d in the direction I think

>you're interested in is I've not seen suffici= ent description of how to

>associate "services" with telephone= numbers.  For example, many people

>are members of more than one social networkin= g application, and some

>social network applications offer services wh= ich overlap with

>traditional telecommunications and therefore = could benefit from

>assocation with number_user telephone numbers= .

> 

>I think it would be useful to explore how tho= se services could be

>defined syntactically, managed, and discovere= d.  But maybe that's just

>me.  Maybe others find that useless and/= or objectionable.  It does seem

>like the direction you were wanting things to= go in terms of giving

>number_users control over service provider as= sociations with their telephone number.

>And it seems directionally correct in terms o= f addressing the interests

>of users and non-traditional communications s= ervice providers for

>service provider mash-ups associated with a t= elephone number.

> 

>I know I haven't directly answered your quest= ion about specific

>suggested changes to the text in the charter.=   I would like to hear

>more from others.

> 

>Best regards,

> 

> 

>Pierce Gorman

>Core Network Planning

>O: 913-439-4368

><= span style=3D"color:windowtext;text-decoration:none">pierce.gorman@sprint.c= om

> 

> 

>-----Original Message-----

>From: Modern [mailto:mo= dern-bounces@ietf.org] On Behalf Of Steve

>Donovan

>Sent: May 04, 2015 1:30 PM

>To: modern@ietf.org<= o:p>

>Subject: Re: [Modern] MODERN will solve no pr= oblems (or will the IETF

>take over the world?)

> 

>Pierce,

> 

>See my comments inline.

> 

>Regards,

> 

>Steve

> 

>On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wr= ote:

>> If we can agree we eliminate the charter= language that implies

>>creating a framework which supplants the = authority of the NANC (at

>>least) and which assumes a replacement of= the NPAC and LERG databases,

>>we will have made progress (IMHO).

>SRD> This should be easy to do, as there i= s no intent and, even if

>SRD> there

>were intent, there is no ability for the MODE= RN group to take anyone's

>authority or replace anyone's database.<= /o:p>

> 

>SRD> Is the problem with the word framewor= k in the second paragraph?

>Would calling it an "architectural frame= work" help?

>> 

>> Beyond striking objectionable language, = the reason for David Holmes'

>>posts following mine last week was to try= to improve the focus of the

>>work for MODERN.  We do think it is = a bad idea to ignore that number

>>administration and routing solutions need= to evolve.  And we're not

>>against the MODERN working group identify= ing problems.  In fact we're

>>in favor of it.  Its what to do past= that where we're struggling.

>SRD> I share the desire to focus the work.=  I think the revisions of

>SRD> the

>charter have moved in this direction.

>> 

>> The thing I'm concerned about is a repea= t of the e164.arpa fiasco

>>which succeeded in defining a global sche= ma and protocol for managing

>>numbers and resolving them for routing an= d which failed utterly.

>SRD> We fail if we don't learn from our mi= stakes.  I'm confident we

>SRD> will

>have enough involvement in the group to keep = us pointed in the right

>direction.

>> 

>> Best regards,

>> 

>> 

>> Pierce Gorman

>> Core Network Planning

>> O: 913-439-4368

>> pierce.gorman@spr= int.com

>> 

>> 

>> -----Original Message-----

>> From: Modern [mail= to:modern-bounces@ietf.org] On Behalf Of Steve

>> Donovan

>> Sent: May 01, 2015 4:24 PM

>> To: <= span style=3D"color:windowtext;text-decoration:none">modern@ietf.org=

>> Subject: [Modern] MODERN will solve no p= roblems (or will the IETF

>> take over the world?)

>> 

>> The question of what problem(s) MODERN w= ill address has been asked,

>>multiple times.

>> 

>> The short answer is that, in an of itsel= f, MODERN will solve no

>>problems.

>> 

>> This isn't to say there aren't problems = with existing mechanisms. It

>>is to say that all MODERN can do is to sp= ecify protocols that can then

>>be part of an overall solution that addre= sses problems that exist with

>>those existing mechanisms.

>> 

>> There is a brief capture of these proble= ms in the latest version of

>> the

>> charter:

>> 

>> "A sample of problems with existing= mechanisms include:

>> 

>> - lack of flexibility (for example, it c= an be difficult to add fields

>>without a very elaborate and lengthy proc= ess typically spanning years)

>> - lack of distribution (for example, it = is hard or impossible to have

>>more than one administrator for each data= base)

>> - complexity (leading, for example, to a= fair amount of rural call

>>completion problems which aren't helped b= y small providers struggling

>>to keep numbers straight)

>> - difficulty of adopting more modern all= ocation (e.g., "blocks" of 1)

>>and porting mechanisms"

>> 

>> Will MODERN solve these problems? No.

>> 

>> Will MODERN make it possible for these p= roblems to be addressed as

>>part of new number management policies to= be enacted by the

>>appropriate authorities?  That, I be= lieve, is the goal.

>> 

>> Will MODERN force any of these new numbe= r management policies to be

>>enacted.  No.  The IETF is not = a policy setting body.

>> 

>> I'm ok with having a more detailed artic= ulation of the problem

>>statement as part of the deliverables of = the MODERN working group. I

>>don't see the benefit of making that the = only deliverable and forcing

>>rechartering after that document is finis= hed.  Let's instead agree to

>>shut the working group down if there is c= onsensus that it is going

>>nowhere (which I'm sure the ADs will do a= nyway).

>> 

>> Regards,

>> 

>> Steve

>> 

>> ________________________________________= _______

>> Modern mailing list

>> Modern@ietf.org=

>> 

>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=3DAwICAg&c=3DM= OptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6B= oXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8R= PhTjGqw&e=3D

>> 

>> ________________________________

>> 

>> This e-mail may contain Sprint proprieta= ry information intended for

>>the sole use of the recipient(s). Any use= by others is prohibited. If

>>you are not the intended recipient, pleas= e contact the sender and

>>delete all copies of the message.

>> 

>> ________________________________________= _______

>> Modern mailing list

>> Modern@ietf.org=

>> 

>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=3DAwICAg&c=3DM= OptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6B= oXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8R= PhTjGqw&e=3D

>> 

> 

>_____________________________________________= __

>Modern mailing list

>Modern@ietf.org=

>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailm

>an_

>listinfo_modern&d=3DAwICAg&c=3DMOptNl= VtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDh= VxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3Dh

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&a= mp;e=3D

> 

>________________________________

> 

>This e-mail may contain Sprint proprietary in= formation intended for the

>sole use of the recipient(s). Any use by othe= rs is prohibited. If you

>are not the intended recipient, please contac= t the sender and delete

>all copies of the message.

> 

>_____________________________________________= __

>Modern mailing list

>Modern@ietf.org=

>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailm

>an_

>listinfo_modern&d=3DAwICAg&c=3DMOptNl= VtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDh= VxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3Dh

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&a= mp;e=3D

 

 

________________________________

 

This e-mail may contain Sprint proprietary inform= ation intended for the sole use of the recipient(s). Any use by others is p= rohibited. If you are not the intended recipient, please contact the sender= and delete all copies of the message.

 

_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.i= etf.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.
 --_000_09ec73f2cd0f4d228e9fe15ddd2b3b4bPLSWE13M08adsprintcom_-- From nobody Mon May 11 15:32:20 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 7896C1A9168 for ; Mon, 11 May 2015 15:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 IFesu0nTUmYo for ; Mon, 11 May 2015 15:32:16 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 650091A9166 for ; Mon, 11 May 2015 15:32:16 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E55C4427A1870; Mon, 11 May 2015 22:32:10 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t4BMWEBf030076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 00:32:14 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 12 May 2015 00:32:14 +0200 From: "DRAGE, Keith (Keith)" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Proposed change to paragraph three of the charter Thread-Index: AQHQiMzmuHm3nAXR5kuwgQJukY8piJ13YWLA Date: Mon, 11 May 2015 22:32:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> In-Reply-To: <554B6DB9.9010901@usdonovans.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Proposed change to paragraph three of the charter 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: Mon, 11 May 2015 22:32:18 -0000 I do not agree with the charter being widened to "TN" or presumably "teleph= one numbers". The reason for this is that telephone numbers has a wide and = undefined scope, possibly including alphabetic characters as well (as in th= e letters on the dialling ring). Based on the statements made by others in terms of what needs to be covered= , I would prefer a more precise definition of: "international E.164 numbers= , local special purpose numbers, and network specific numbers" using the ex= planation of these terms that can be found in ITU-T Recommendation E.164. Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Steve Donovan > Sent: 07 May 2015 14:51 > To: modern@ietf.org > Subject: [Modern] Proposed change to paragraph three of the charter >=20 > All, >=20 > Paragraph three currently reads as follows: >=20 > "The work of this group will focus on E.164 telephone numbers=20 > due to the changing telecom environment and interest=20 > expressed by telecommunications industry regulators to=20 > support more flexible regulatory models than exist today. =20 > There is an expectation that aspects of the architecture and=20 > protocols defined by the working group will be reusable for=20 > other user-focused identifiers. Any such extensions or reuse=20 > of MODERN mechanisms are out of scope for the MODERN working=20 > group. Solutions and mechanisms created by the working group=20 > will be flexible enough to accommodate different policies,=20 > e.g., by different regulatory agencies." >=20 > I propose changing the first sentence to the following: >=20 > "The work of this group will focus on TNs -- such as E.164=20 > numbers -- and blocks of TNs, that are used to initiate=20 > communication with another user of a service. The work is=20 > motivated by the changing telecom environment and interest=20 > expressed by telecommunications industry regulators to=20 > support more flexible regulatory models than exist today. " >=20 > The remainder of the paragraph, starting with "There is an=20 > expectation..." would remain unchanged. >=20 > This adds some clarity on the scope of telephony identifiers=20 > covered as well as making it clear that blocks of TNs are=20 > also covered. >=20 > Regards, >=20 > Steve >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > = From nobody Tue May 12 08:17:06 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 18BA21B2E4E for ; Tue, 12 May 2015 08:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.267 X-Spam-Level: X-Spam-Status: No, score=-104.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 d3AzRZLdx7t5 for ; Tue, 12 May 2015 08:17:02 -0700 (PDT) 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 821061A8ABF for ; Tue, 12 May 2015 08:17:02 -0700 (PDT) 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 t4CFEmU6008667; Tue, 12 May 2015 11:16:59 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1ubhhm887x-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 May 2015 11:16:59 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 12 May 2015 11:16:57 -0400 From: "Peterson, Jon" To: "DRAGE, Keith (Keith)" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Proposed change to paragraph three of the charter Thread-Index: AQHQiMzelET0HDkalUacTVQDebIAfZ13phuAgACjXgA= Date: Tue, 12 May 2015 15:16:56 +0000 Message-ID: References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.122] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-12_05:2015-05-12,2015-05-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.0083600621158e-12 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505120194 Archived-At: Subject: Re: [Modern] Proposed change to paragraph three of the charter 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, 12 May 2015 15:17:04 -0000 Again, I'd be more sympathetic to this request to invent a new IETF definition of telephone numbers if we didn't already have standards track RFCs that have done that, and by reference to the same specifications you're describing here. We don't mean anything different by telephone numbers than the abstract of RFC3966 did when it said that "the 'tel' URI describes resources identified by telephone numbers." Jon Peterson Neustar, Inc. On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" wrote: >I do not agree with the charter being widened to "TN" or presumably >"telephone numbers". The reason for this is that telephone numbers has a >wide and undefined scope, possibly including alphabetic characters as >well (as in the letters on the dialling ring). > >Based on the statements made by others in terms of what needs to be >covered, I would prefer a more precise definition of: "international >E.164 numbers, local special purpose numbers, and network specific >numbers" using the explanation of these terms that can be found in ITU-T >Recommendation E.164. > >Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Steve Donovan >> Sent: 07 May 2015 14:51 >> To: modern@ietf.org >> Subject: [Modern] Proposed change to paragraph three of the charter >>=20 >> All, >>=20 >> Paragraph three currently reads as follows: >>=20 >> "The work of this group will focus on E.164 telephone numbers >> due to the changing telecom environment and interest >> expressed by telecommunications industry regulators to >> support more flexible regulatory models than exist today. >> There is an expectation that aspects of the architecture and >> protocols defined by the working group will be reusable for >> other user-focused identifiers. Any such extensions or reuse >> of MODERN mechanisms are out of scope for the MODERN working >> group. Solutions and mechanisms created by the working group >> will be flexible enough to accommodate different policies, >> e.g., by different regulatory agencies." >>=20 >> I propose changing the first sentence to the following: >>=20 >> "The work of this group will focus on TNs -- such as E.164 >> numbers -- and blocks of TNs, that are used to initiate >> communication with another user of a service. The work is >> motivated by the changing telecom environment and interest >> expressed by telecommunications industry regulators to >> support more flexible regulatory models than exist today. " >>=20 >> The remainder of the paragraph, starting with "There is an >> expectation..." would remain unchanged. >>=20 >> This adds some clarity on the scope of telephony identifiers >> covered as well as making it clear that blocks of TNs are >> also covered. >>=20 >> Regards, >>=20 >> Steve >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Tue May 12 08:32: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 240FC1A8A3F for ; Tue, 12 May 2015 08:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 NogAOJh1wzdi for ; Tue, 12 May 2015 08:31:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 3FEC81A898F for ; Tue, 12 May 2015 08:31:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9A5EFB7CAF6F5; Tue, 12 May 2015 15:31:53 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4CFVuCg002229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 17:31:56 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 12 May 2015 17:31:56 +0200 From: "DRAGE, Keith (Keith)" To: "Peterson, Jon" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Proposed change to paragraph three of the charter Thread-Index: AQHQiMzeuHm3nAXR5kuwgQJukY8piJ13phuAgACjXgCAADWf8A== Date: Tue, 12 May 2015 15:31:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Proposed change to paragraph three of the charter 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, 12 May 2015 15:32:01 -0000 I am not doing that at all. I am proposing to remove any attempt by you and others to use the term "tel= ephone number" in a totally undefined manner, and replacing it with terms t= hat have been defined by the body that knows about these things, i.e. SG2 o= f ITU-T. You are consisting opposing telling us what you mean by the team. My proposal is not to include the term "telephone number" at all. Regards Keith=20 > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Peterson, Jon > Sent: 12 May 2015 16:17 > To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > Subject: Re: [Modern] Proposed change to paragraph three of=20 > the charter >=20 >=20 > Again, I'd be more sympathetic to this request to invent a=20 > new IETF definition of telephone numbers if we didn't already=20 > have standards track RFCs that have done that, and by=20 > reference to the same specifications you're describing here. >=20 > We don't mean anything different by telephone numbers than=20 > the abstract of > RFC3966 did when it said that "the 'tel' URI describes=20 > resources identified by telephone numbers." >=20 > Jon Peterson > Neustar, Inc. >=20 > On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" > wrote: >=20 > >I do not agree with the charter being widened to "TN" or presumably=20 > >"telephone numbers". The reason for this is that telephone=20 > numbers has=20 > >a wide and undefined scope, possibly including alphabetic=20 > characters as=20 > >well (as in the letters on the dialling ring). > > > >Based on the statements made by others in terms of what needs to be=20 > >covered, I would prefer a more precise definition of: "international > >E.164 numbers, local special purpose numbers, and network specific=20 > >numbers" using the explanation of these terms that can be found in=20 > >ITU-T Recommendation E.164. > > > >Keith > > > >> -----Original Message----- > >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve=20 > >> Donovan > >> Sent: 07 May 2015 14:51 > >> To: modern@ietf.org > >> Subject: [Modern] Proposed change to paragraph three of the charter > >>=20 > >> All, > >>=20 > >> Paragraph three currently reads as follows: > >>=20 > >> "The work of this group will focus on E.164 telephone=20 > numbers due to=20 > >> the changing telecom environment and interest expressed by=20 > >> telecommunications industry regulators to support more flexible=20 > >> regulatory models than exist today. > >> There is an expectation that aspects of the architecture and=20 > >> protocols defined by the working group will be reusable for other=20 > >> user-focused identifiers. Any such extensions or reuse of MODERN=20 > >> mechanisms are out of scope for the MODERN working group. =20 > Solutions=20 > >> and mechanisms created by the working group will be=20 > flexible enough=20 > >> to accommodate different policies, e.g., by different regulatory=20 > >> agencies." > >>=20 > >> I propose changing the first sentence to the following: > >>=20 > >> "The work of this group will focus on TNs -- such as E.164=20 > numbers --=20 > >> and blocks of TNs, that are used to initiate communication with=20 > >> another user of a service. The work is motivated by the changing=20 > >> telecom environment and interest expressed by telecommunications=20 > >> industry regulators to support more flexible regulatory=20 > models than=20 > >> exist today. " > >>=20 > >> The remainder of the paragraph, starting with "There is an=20 > >> expectation..." would remain unchanged. > >>=20 > >> This adds some clarity on the scope of telephony=20 > identifiers covered=20 > >> as well as making it clear that blocks of TNs are also covered. > >>=20 > >> Regards, > >>=20 > >> Steve > >>=20 > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> https://www.ietf.org/mailman/listinfo/modern > >>=20 > >_______________________________________________ > >Modern mailing list > >Modern@ietf.org > >https://www.ietf.org/mailman/listinfo/modern >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > = From nobody Tue May 12 09:37:33 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 B61B81A8ACF for ; Tue, 12 May 2015 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.267 X-Spam-Level: X-Spam-Status: No, score=-104.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 8Jgus4wINuTZ for ; Tue, 12 May 2015 09:37:29 -0700 (PDT) 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 0DDF71A0354 for ; Tue, 12 May 2015 09:37:13 -0700 (PDT) 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 t4CGYNiV025265; Tue, 12 May 2015 12:37:11 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1ubhhm8c7t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 May 2015 12:37:11 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Tue, 12 May 2015 12:37:09 -0400 From: "Peterson, Jon" To: "DRAGE, Keith (Keith)" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Proposed change to paragraph three of the charter Thread-Index: AQHQiMzelET0HDkalUacTVQDebIAfZ13phuAgACjXgCAAHmIgP//nOMA Date: Tue, 12 May 2015 16:37:08 +0000 Message-ID: References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <4A0E2848F7067F4DAF64314A57E7EB37@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-12_06:2015-05-12,2015-05-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.18627330181198e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505120211 Archived-At: Subject: Re: [Modern] Proposed change to paragraph three of the charter 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, 12 May 2015 16:37:31 -0000 No, what I've said consistently is that what I mean by the term is what RFC3966 meant by the term. TeRQ deferred to that specification for its formal definition of telephone number, say. I see no reason to reinvent that wheel. If we get to a place where the term "telephone number" is imprecise or toxic, then I think we've confused ourselves into a rejection of common sense and common usage. The term is used without warning labels in IETF standards track specifications already. The bar you are raising is not consistent with IETF usage. I do gather that you believe the expertise to do the MODERN work resides in SG-2 rather than in the IETF. But the proposed working group will not, say, reassign country code +44 to someone else, or do any of the things you'd need the expertise and authority of that body to do. We're not delegating authority for country codes to Internet entities as ENUM did, which necessitated an IAB liaison with SG-2, even. Those are all policy issues. We're not trying to build policy, we're trying to build tools that will work in a variety of policy environments. Jon Peterson Neustar, Inc. On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" wrote: >I am not doing that at all. > >I am proposing to remove any attempt by you and others to use the term >"telephone number" in a totally undefined manner, and replacing it with >terms that have been defined by the body that knows about these things, >i.e. SG2 of ITU-T. > >You are consisting opposing telling us what you mean by the team. > >My proposal is not to include the term "telephone number" at all. > >Regards > >Keith=20 > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Peterson, Jon >> Sent: 12 May 2015 16:17 >> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >> Subject: Re: [Modern] Proposed change to paragraph three of >> the charter >>=20 >>=20 >> Again, I'd be more sympathetic to this request to invent a >> new IETF definition of telephone numbers if we didn't already >> have standards track RFCs that have done that, and by >> reference to the same specifications you're describing here. >>=20 >> We don't mean anything different by telephone numbers than >> the abstract of >> RFC3966 did when it said that "the 'tel' URI describes >> resources identified by telephone numbers." >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >> wrote: >>=20 >> >I do not agree with the charter being widened to "TN" or presumably >> >"telephone numbers". The reason for this is that telephone >> numbers has=20 >> >a wide and undefined scope, possibly including alphabetic >> characters as=20 >> >well (as in the letters on the dialling ring). >> > >> >Based on the statements made by others in terms of what needs to be >> >covered, I would prefer a more precise definition of: "international >> >E.164 numbers, local special purpose numbers, and network specific >> >numbers" using the explanation of these terms that can be found in >> >ITU-T Recommendation E.164. >> > >> >Keith >> > >> >> -----Original Message----- >> >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >> >> Donovan >> >> Sent: 07 May 2015 14:51 >> >> To: modern@ietf.org >> >> Subject: [Modern] Proposed change to paragraph three of the charter >> >>=20 >> >> All, >> >>=20 >> >> Paragraph three currently reads as follows: >> >>=20 >> >> "The work of this group will focus on E.164 telephone >> numbers due to=20 >> >> the changing telecom environment and interest expressed by >> >> telecommunications industry regulators to support more flexible >> >> regulatory models than exist today. >> >> There is an expectation that aspects of the architecture and >> >> protocols defined by the working group will be reusable for other >> >> user-focused identifiers. Any such extensions or reuse of MODERN >> >> mechanisms are out of scope for the MODERN working group. >> Solutions=20 >> >> and mechanisms created by the working group will be >> flexible enough=20 >> >> to accommodate different policies, e.g., by different regulatory >> >> agencies." >> >>=20 >> >> I propose changing the first sentence to the following: >> >>=20 >> >> "The work of this group will focus on TNs -- such as E.164 >> numbers --=20 >> >> and blocks of TNs, that are used to initiate communication with >> >> another user of a service. The work is motivated by the changing >> >> telecom environment and interest expressed by telecommunications >> >> industry regulators to support more flexible regulatory >> models than=20 >> >> exist today. " >> >>=20 >> >> The remainder of the paragraph, starting with "There is an >> >> expectation..." would remain unchanged. >> >>=20 >> >> This adds some clarity on the scope of telephony >> identifiers covered >> >> as well as making it clear that blocks of TNs are also covered. >> >>=20 >> >> Regards, >> >>=20 >> >> Steve >> >>=20 >> >> _______________________________________________ >> >> Modern mailing list >> >> Modern@ietf.org >> >> https://www.ietf.org/mailman/listinfo/modern >> >>=20 >> >_______________________________________________ >> >Modern mailing list >> >Modern@ietf.org >> >https://www.ietf.org/mailman/listinfo/modern >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 From nobody Tue May 12 09:51:31 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 8A8DC1A9062 for ; Tue, 12 May 2015 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 xPROlAHHktqr for ; Tue, 12 May 2015 09:51:28 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 1CCD11A905F for ; Tue, 12 May 2015 09:51:20 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:52590 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YsDOj-000Byv-8R for modern@ietf.org; Tue, 12 May 2015 09:51:19 -0700 Message-ID: <55522F81.3070803@usdonovans.com> Date: Tue, 12 May 2015 11:51:13 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Proposed change to paragraph three of the charter 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, 12 May 2015 16:51:30 -0000 Would it solve the problem by referring directly to RFC3966 in the charter? Steve On 5/12/15 11:37 AM, Peterson, Jon wrote: > No, what I've said consistently is that what I mean by the term is what > RFC3966 meant by the term. TeRQ deferred to that specification for its > formal definition of telephone number, say. I see no reason to reinvent > that wheel. > > If we get to a place where the term "telephone number" is imprecise or > toxic, then I think we've confused ourselves into a rejection of common > sense and common usage. The term is used without warning labels in IETF > standards track specifications already. The bar you are raising is not > consistent with IETF usage. > > I do gather that you believe the expertise to do the MODERN work resides > in SG-2 rather than in the IETF. But the proposed working group will not, > say, reassign country code +44 to someone else, or do any of the things > you'd need the expertise and authority of that body to do. We're not > delegating authority for country codes to Internet entities as ENUM did, > which necessitated an IAB liaison with SG-2, even. Those are all policy > issues. We're not trying to build policy, we're trying to build tools that > will work in a variety of policy environments. > > Jon Peterson > Neustar, Inc. > > On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" > wrote: > >> I am not doing that at all. >> >> I am proposing to remove any attempt by you and others to use the term >> "telephone number" in a totally undefined manner, and replacing it with >> terms that have been defined by the body that knows about these things, >> i.e. SG2 of ITU-T. >> >> You are consisting opposing telling us what you mean by the team. >> >> My proposal is not to include the term "telephone number" at all. >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>> Peterson, Jon >>> Sent: 12 May 2015 16:17 >>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>> Subject: Re: [Modern] Proposed change to paragraph three of >>> the charter >>> >>> >>> Again, I'd be more sympathetic to this request to invent a >>> new IETF definition of telephone numbers if we didn't already >>> have standards track RFCs that have done that, and by >>> reference to the same specifications you're describing here. >>> >>> We don't mean anything different by telephone numbers than >>> the abstract of >>> RFC3966 did when it said that "the 'tel' URI describes >>> resources identified by telephone numbers." >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>> wrote: >>> >>>> I do not agree with the charter being widened to "TN" or presumably >>>> "telephone numbers". The reason for this is that telephone >>> numbers has >>>> a wide and undefined scope, possibly including alphabetic >>> characters as >>>> well (as in the letters on the dialling ring). >>>> >>>> Based on the statements made by others in terms of what needs to be >>>> covered, I would prefer a more precise definition of: "international >>>> E.164 numbers, local special purpose numbers, and network specific >>>> numbers" using the explanation of these terms that can be found in >>>> ITU-T Recommendation E.164. >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >>>>> Donovan >>>>> Sent: 07 May 2015 14:51 >>>>> To: modern@ietf.org >>>>> Subject: [Modern] Proposed change to paragraph three of the charter >>>>> >>>>> All, >>>>> >>>>> Paragraph three currently reads as follows: >>>>> >>>>> "The work of this group will focus on E.164 telephone >>> numbers due to >>>>> the changing telecom environment and interest expressed by >>>>> telecommunications industry regulators to support more flexible >>>>> regulatory models than exist today. >>>>> There is an expectation that aspects of the architecture and >>>>> protocols defined by the working group will be reusable for other >>>>> user-focused identifiers. Any such extensions or reuse of MODERN >>>>> mechanisms are out of scope for the MODERN working group. >>> Solutions >>>>> and mechanisms created by the working group will be >>> flexible enough >>>>> to accommodate different policies, e.g., by different regulatory >>>>> agencies." >>>>> >>>>> I propose changing the first sentence to the following: >>>>> >>>>> "The work of this group will focus on TNs -- such as E.164 >>> numbers -- >>>>> and blocks of TNs, that are used to initiate communication with >>>>> another user of a service. The work is motivated by the changing >>>>> telecom environment and interest expressed by telecommunications >>>>> industry regulators to support more flexible regulatory >>> models than >>>>> exist today. " >>>>> >>>>> The remainder of the paragraph, starting with "There is an >>>>> expectation..." would remain unchanged. >>>>> >>>>> This adds some clarity on the scope of telephony >>> identifiers covered >>>>> as well as making it clear that blocks of TNs are also covered. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/modern >>>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Tue May 12 10:07:31 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 E410A1AC437 for ; Tue, 12 May 2015 10:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 IIRafLYgD7KQ for ; Tue, 12 May 2015 10:07:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 40FC21ACD0A for ; Tue, 12 May 2015 10:07:27 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 712026765837C; Tue, 12 May 2015 17:07:22 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t4CH7NEa029871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 19:07:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 12 May 2015 19:07:24 +0200 From: "DRAGE, Keith (Keith)" To: "Peterson, Jon" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Proposed change to paragraph three of the charter Thread-Index: AQHQiMzeuHm3nAXR5kuwgQJukY8piJ13phuAgACjXgCAAHmIgP//nOMAgAA0C1A= Date: Tue, 12 May 2015 17:07:23 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Proposed change to paragraph three of the charter 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, 12 May 2015 17:07:30 -0000 Firstly the charter gives no definition of what you are using for telephone= number, e.g. by reference to RFC 3966. RFC 3966 basically defines it as any sequence of decimal digits. Other usag= es elsewhere include alphabetic characters, because this name is used both = in the context of what the user represents to other users as his number and= what actually gets used in a signalling protocol.=20 The ITU-T terms actually distinguish between those two usages, by putting t= hem in separate recommendations. The additionally problem with RFC 3966 as a definition as it does not defin= e a usage where every sequence of digits is unique, and therefore it has to= add a phone context to enable that uniqueness to exist, with a default app= lying to "global" numbers. So do you intend such digit sequences used within this group to be unique o= r will it need a phone context as a result of using the RFC 3966 definition= ? The definitions I provided would not. In regard to: > I do gather that you believe the expertise to do the MODERN=20 > work resides in SG-2 rather than in the IETF. But the=20 > proposed working group will not, say, reassign country code=20 > +44 to someone else, or do any of the things you'd need the=20 > expertise and authority of that body to do. We're not=20 > delegating authority for country codes to Internet entities=20 > as ENUM did, which necessitated an IAB liaison with SG-2,=20 > even. Those are all policy issues. We're not trying to build=20 > policy, we're trying to build tools that will work in a=20 > variety of policy environments. Then I do not believe that. I believe SG2 should define what the numbers ar= e that we use, and maybe they should define the use cases. Once it is reduc= ed to fulfilling a protocol requirement, then I anyone (including IETF) can= do the work. Regards Keith=20 > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: 12 May 2015 17:37 > To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > Subject: Re: [Modern] Proposed change to paragraph three of=20 > the charter >=20 >=20 > No, what I've said consistently is that what I mean by the=20 > term is what > RFC3966 meant by the term. TeRQ deferred to that=20 > specification for its formal definition of telephone number,=20 > say. I see no reason to reinvent that wheel. >=20 > If we get to a place where the term "telephone number" is=20 > imprecise or toxic, then I think we've confused ourselves=20 > into a rejection of common sense and common usage. The term=20 > is used without warning labels in IETF standards track=20 > specifications already. The bar you are raising is not=20 > consistent with IETF usage. >=20 > I do gather that you believe the expertise to do the MODERN=20 > work resides in SG-2 rather than in the IETF. But the=20 > proposed working group will not, say, reassign country code=20 > +44 to someone else, or do any of the things you'd need the=20 > expertise and authority of that body to do. We're not=20 > delegating authority for country codes to Internet entities=20 > as ENUM did, which necessitated an IAB liaison with SG-2,=20 > even. Those are all policy issues. We're not trying to build=20 > policy, we're trying to build tools that will work in a=20 > variety of policy environments. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" > wrote: >=20 > >I am not doing that at all. > > > >I am proposing to remove any attempt by you and others to=20 > use the term=20 > >"telephone number" in a totally undefined manner, and=20 > replacing it with=20 > >terms that have been defined by the body that knows about=20 > these things,=20 > >i.e. SG2 of ITU-T. > > > >You are consisting opposing telling us what you mean by the team. > > > >My proposal is not to include the term "telephone number" at all. > > > >Regards > > > >Keith > > > >> -----Original Message----- > >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Peterson,=20 > >> Jon > >> Sent: 12 May 2015 16:17 > >> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >> Subject: Re: [Modern] Proposed change to paragraph three of the=20 > >> charter > >>=20 > >>=20 > >> Again, I'd be more sympathetic to this request to invent a=20 > new IETF=20 > >> definition of telephone numbers if we didn't already have=20 > standards=20 > >> track RFCs that have done that, and by reference to the same=20 > >> specifications you're describing here. > >>=20 > >> We don't mean anything different by telephone numbers than the=20 > >> abstract of > >> RFC3966 did when it said that "the 'tel' URI describes resources=20 > >> identified by telephone numbers." > >>=20 > >> Jon Peterson > >> Neustar, Inc. > >>=20 > >> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" > >> wrote: > >>=20 > >> >I do not agree with the charter being widened to "TN" or=20 > presumably=20 > >> >"telephone numbers". The reason for this is that telephone > >> numbers has > >> >a wide and undefined scope, possibly including alphabetic > >> characters as > >> >well (as in the letters on the dialling ring). > >> > > >> >Based on the statements made by others in terms of what=20 > needs to be=20 > >> >covered, I would prefer a more precise definition of:=20 > "international > >> >E.164 numbers, local special purpose numbers, and network=20 > specific=20 > >> >numbers" using the explanation of these terms that can be=20 > found in=20 > >> >ITU-T Recommendation E.164. > >> > > >> >Keith > >> > > >> >> -----Original Message----- > >> >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf=20 > Of Steve=20 > >> >> Donovan > >> >> Sent: 07 May 2015 14:51 > >> >> To: modern@ietf.org > >> >> Subject: [Modern] Proposed change to paragraph three of the=20 > >> >> charter > >> >>=20 > >> >> All, > >> >>=20 > >> >> Paragraph three currently reads as follows: > >> >>=20 > >> >> "The work of this group will focus on E.164 telephone > >> numbers due to > >> >> the changing telecom environment and interest expressed by=20 > >> >> telecommunications industry regulators to support more flexible=20 > >> >> regulatory models than exist today. > >> >> There is an expectation that aspects of the architecture and=20 > >> >> protocols defined by the working group will be reusable=20 > for other=20 > >> >> user-focused identifiers. Any such extensions or reuse=20 > of MODERN=20 > >> >> mechanisms are out of scope for the MODERN working group. > >> Solutions > >> >> and mechanisms created by the working group will be > >> flexible enough > >> >> to accommodate different policies, e.g., by different=20 > regulatory=20 > >> >> agencies." > >> >>=20 > >> >> I propose changing the first sentence to the following: > >> >>=20 > >> >> "The work of this group will focus on TNs -- such as E.164 > >> numbers -- > >> >> and blocks of TNs, that are used to initiate communication with=20 > >> >> another user of a service. The work is motivated by=20 > the changing=20 > >> >> telecom environment and interest expressed by=20 > telecommunications=20 > >> >> industry regulators to support more flexible regulatory > >> models than > >> >> exist today. " > >> >>=20 > >> >> The remainder of the paragraph, starting with "There is an=20 > >> >> expectation..." would remain unchanged. > >> >>=20 > >> >> This adds some clarity on the scope of telephony > >> identifiers covered > >> >> as well as making it clear that blocks of TNs are also covered. > >> >>=20 > >> >> Regards, > >> >>=20 > >> >> Steve > >> >>=20 > >> >> _______________________________________________ > >> >> Modern mailing list > >> >> Modern@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/modern > >> >>=20 > >> >_______________________________________________ > >> >Modern mailing list > >> >Modern@ietf.org > >> >https://www.ietf.org/mailman/listinfo/modern > >>=20 > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> https://www.ietf.org/mailman/listinfo/modern > >>=20 >=20 > = From nobody Tue May 12 12:18: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 E8DF71A8958 for ; Tue, 12 May 2015 12:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 mLxmOP-d7yHD for ; Tue, 12 May 2015 12:17:57 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 27E371A8951 for ; Tue, 12 May 2015 12:17:56 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:53179 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YsFgd-000BEP-A2; Tue, 12 May 2015 12:17:54 -0700 Message-ID: <555251DF.90701@usdonovans.com> Date: Tue, 12 May 2015 14:17:51 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Gorman, Pierce A [CTO]" , "McGarry, Tom" , "modern@ietf.org" References: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> <90f7e39770be4118aa5ed9ca31f72b20@PLSWE13M08.ad.sprint.com> <09ec73f2cd0f4d228e9fe15ddd2b3b4b@PLSWE13M08.ad.sprint.com> In-Reply-To: <09ec73f2cd0f4d228e9fe15ddd2b3b4b@PLSWE13M08.ad.sprint.com> Content-Type: multipart/alternative; boundary="------------060008080208010301030102" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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, 12 May 2015 19:18:02 -0000 This is a multi-part message in MIME format. --------------060008080208010301030102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Pierce, See my comments inline. Steve On 5/8/15 12:58 PM, Gorman, Pierce A [CTO] wrote: > > Steve, > > Here is a suggested set of changes to the 2^nd paragraph. > > OLD: > > The working group will define a framework for the roles and functions > involved in managing and resolving TNs in an IP environment. This > includes a protocol mechanism for acquiring TNs, which will provide an > enrollment process for the individuals and entities that use and > manage TNs. TNs may either be managed in a hierarchical tree, or in a > distributed peer-to-peer architecture. Privacy of the enrollment data > and security of the resource will be primary considerations. > > NEW: > > The working group will define a an information management framework > for the roles and functions involved in managing and resolving TNs > associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information > with one or more TNs in an IP environment. This includes a protocol > mechanism for acquiring TNs, which will provide an enrollment process > for the individuals and entities that use and manage TNs. TNs may > either be managed in a hierarchical tree, or in a distributed > peer-to-peer architecture. Privacy of the enrollment managed data and > security of the resource will be primary considerations. > SRD> I'm mostly okay with your changes other then removing the wording on the protocol work. I believe there is enough support for doing the protocol work that this should remain in the charter. I'm not sure we need to define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles. > > I would prefer if others weighed in here. I don’t like being one of a > few with such influence. > SRD> Agreed. > > Because I wasn’t at the BoF and am new at this sort of thing, I > personally would be happier if we took more time in e-mail or meetings > to discuss the problems the WG should address, not the solutions (at > first). > SRD> Yes we need more discussion. That is what the working group is for. The charter is to define the scope of the working group effort. We don't need to have all of the answers now. > > A specific area of concern for me is the data model of information > associated with telephone numbers. I care much more about what is > being provisioned then I do about how it is provisioned or shared. > SRD> I actually don't think it is the job of the MODERN working group to define detailed data models. We clearly need to have some assumptions about what those data models might look like, but I would assume that each number management authority would determine what data is associated with a number. SRD> I also think the how is important as the resulting mechanism, be it a new one defined by the group or an existing one recommended by the group, will need to be flexible and extensible to be able to address the problems outlined by Henning. > > I think trying to identify the what first will be more valuable than > the how, and certainly more important than the who. > SRD> Agreed and the proposed deliverables are in the order listed for that very reason. > > Best regards, > > Pierce Gorman > > Core Network Planning > > O: 913-439-4368 > > pierce.gorman@sprint.com > > -----Original Message----- > > From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz] > > Sent: May 05, 2015 9:54 AM > > To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org > > > Subject: Re: [Modern] MODERN will solve no problems (or will the IETF > take over the world?) > > "Š define a framework for the roles and functions involved in managing > and resolving TNs Š" is a necessary step to create a common > understanding, for a WG, of the ecosystem for managing TNs. > > For example the WG could define a communications service user, a > communications service provider, a numbering authority, a numbering > administrator, etc.; describe the functions of these roles and how > they may interact with each other. Both presentations at the BoF did > a good job of starting this discussion. > > As the charter states, the work done by the WG would be flexible > enough to accommodate different administrative models, therefore the > framework, roles and functions would need to be flexible. There is no > intent to create a single administrative model, and there is no text > in the charter that would suggest otherwise. In fact the charter > states this explicitly. > > If there are text changes you could suggest that makes this clearer > for you and others, please do. > > On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" > > > wrote: > > >Thanks Steve. I don't think wordsmithing "framework" to be > > >"architectural framework" in the 2nd paragraph really addresses the > > >underlying concern. > > > > > >I understand the temptation to jump right in and have MODERN develop a > > >newer, better, solution to the existing (North American?) framework > > >architecture but it feels like a bridge too far. I'd suggest striking > > >the 2nd paragraph entirely, but I suspect that is also as unappealing > > >to you as the paragraph is to me. > > > > > >I liked Eric Burger's suggestions regarding fleshing out problems by > > >describing use cases. > > > > > >One use case that occurs to me that might lead in the direction I think > > >you're interested in is I've not seen sufficient description of how to > > >associate "services" with telephone numbers. For example, many people > > >are members of more than one social networking application, and some > > >social network applications offer services which overlap with > > >traditional telecommunications and therefore could benefit from > > >assocation with number_user telephone numbers. > > > > > >I think it would be useful to explore how those services could be > > >defined syntactically, managed, and discovered. But maybe that's just > > >me. Maybe others find that useless and/or objectionable. It does seem > > >like the direction you were wanting things to go in terms of giving > > >number_users control over service provider associations with their > telephone number. > > >And it seems directionally correct in terms of addressing the interests > > >of users and non-traditional communications service providers for > > >service provider mash-ups associated with a telephone number. > > > > > >I know I haven't directly answered your question about specific > > >suggested changes to the text in the charter. I would like to hear > > >more from others. > > > > > >Best regards, > > > > > > > > >Pierce Gorman > > >Core Network Planning > > >O: 913-439-4368 > > >pierce.gorman@sprint.com > > > > > > > > >-----Original Message----- > > >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve > > >Donovan > > >Sent: May 04, 2015 1:30 PM > > >To: modern@ietf.org > > >Subject: Re: [Modern] MODERN will solve no problems (or will the IETF > > >take over the world?) > > > > > >Pierce, > > > > > >See my comments inline. > > > > > >Regards, > > > > > >Steve > > > > > >On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: > > >> If we can agree we eliminate the charter language that implies > > >>creating a framework which supplants the authority of the NANC (at > > >>least) and which assumes a replacement of the NPAC and LERG databases, > > >>we will have made progress (IMHO). > > >SRD> This should be easy to do, as there is no intent and, even if > > >SRD> there > > >were intent, there is no ability for the MODERN group to take anyone's > > >authority or replace anyone's database. > > > > > >SRD> Is the problem with the word framework in the second paragraph? > > >Would calling it an "architectural framework" help? > > >> > > >> Beyond striking objectionable language, the reason for David Holmes' > > >>posts following mine last week was to try to improve the focus of the > > >>work for MODERN. We do think it is a bad idea to ignore that number > > >>administration and routing solutions need to evolve. And we're not > > >>against the MODERN working group identifying problems. In fact we're > > >>in favor of it. Its what to do past that where we're struggling. > > >SRD> I share the desire to focus the work. I think the revisions of > > >SRD> the > > >charter have moved in this direction. > > >> > > >> The thing I'm concerned about is a repeat of the e164.arpa fiasco > > >>which succeeded in defining a global schema and protocol for managing > > >>numbers and resolving them for routing and which failed utterly. > > >SRD> We fail if we don't learn from our mistakes. I'm confident we > > >SRD> will > > >have enough involvement in the group to keep us pointed in the right > > >direction. > > >> > > >> Best regards, > > >> > > >> > > >> Pierce Gorman > > >> Core Network Planning > > >> O: 913-439-4368 > > >> pierce.gorman@sprint.com > > >> > > >> > > >> -----Original Message----- > > >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve > > >> Donovan > > >> Sent: May 01, 2015 4:24 PM > > >> To: modern@ietf.org > > >> Subject: [Modern] MODERN will solve no problems (or will the IETF > > >> take over the world?) > > >> > > >> The question of what problem(s) MODERN will address has been asked, > > >>multiple times. > > >> > > >> The short answer is that, in an of itself, MODERN will solve no > > >>problems. > > >> > > >> This isn't to say there aren't problems with existing mechanisms. It > > >>is to say that all MODERN can do is to specify protocols that can then > > >>be part of an overall solution that addresses problems that exist with > > >>those existing mechanisms. > > >> > > >> There is a brief capture of these problems in the latest version of > > >> the > > >> charter: > > >> > > >> "A sample of problems with existing mechanisms include: > > >> > > >> - lack of flexibility (for example, it can be difficult to add fields > > >>without a very elaborate and lengthy process typically spanning years) > > >> - lack of distribution (for example, it is hard or impossible to have > > >>more than one administrator for each database) > > >> - complexity (leading, for example, to a fair amount of rural call > > >>completion problems which aren't helped by small providers struggling > > >>to keep numbers straight) > > >> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) > > >>and porting mechanisms" > > >> > > >> Will MODERN solve these problems? No. > > >> > > >> Will MODERN make it possible for these problems to be addressed as > > >>part of new number management policies to be enacted by the > > >>appropriate authorities? That, I believe, is the goal. > > >> > > >> Will MODERN force any of these new number management policies to be > > >>enacted. No. The IETF is not a policy setting body. > > >> > > >> I'm ok with having a more detailed articulation of the problem > > >>statement as part of the deliverables of the MODERN working group. I > > >>don't see the benefit of making that the only deliverable and forcing > > >>rechartering after that document is finished. Let's instead agree to > > >>shut the working group down if there is consensus that it is going > > >>nowhere (which I'm sure the ADs will do anyway). > > >> > > >> Regards, > > >> > > >> Steve > > >> > > >> _______________________________________________ > > >> Modern mailing list > > >> Modern@ietf.org > > >> > > >>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > >>man > > >>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID > > >>cLe > > >>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& > > >>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > >> > > >> ________________________________ > > >> > > >> This e-mail may contain Sprint proprietary information intended for > > >>the sole 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. > > >> > > >> _______________________________________________ > > >> Modern mailing list > > >> Modern@ietf.org > > >> > > >>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > >>man > > >>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID > > >>cLe > > >>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& > > >>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > >> > > > > > >_______________________________________________ > > >Modern mailing list > > >Modern@ietf.org > > >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm > > >an_ > > >listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL > > >ext > > >Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h > > >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > > > > >________________________________ > > > > > >This e-mail may contain Sprint proprietary information intended for the > > >sole 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. > > > > > >_______________________________________________ > > >Modern mailing list > > >Modern@ietf.org > > >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm > > >an_ > > >listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL > > >ext > > >Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h > > >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for > the sole 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. > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for > the sole 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. --------------060008080208010301030102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Pierce,

See my comments inline.

Steve

On 5/8/15 12:58 PM, Gorman, Pierce A [CTO] wrote:

Steve,

 

Here is a suggested set of changes to the 2nd paragraph.

 

OLD:

 

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment data and security of the resource will be primary considerations.

 

NEW:

 

The working group will define a an information management framework for the roles and functions involved in managing and resolving TNs associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment managed data and security of the resource will be primary considerations.

 

SRD> I'm mostly okay with your changes other then removing the wording on the protocol work.  I believe there is enough support for doing the protocol work that this should remain in the charter.   I'm not sure we need to define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles. 

I would prefer if others weighed in here.  I don’t like being one of a few with such influence.

 

SRD> Agreed.

Because I wasn’t at the BoF and am new at this sort of thing, I personally would be happier if we took more time in e-mail or meetings to discuss the problems the WG should address, not the solutions (at first).

SRD> Yes we need more discussion.  That is what the working group is for.  The charter is to define the scope of the working group effort.  We don't need to have all of the answers now.

 

A specific area of concern for me is the data model of information associated with telephone numbers.   I care much more about what is being provisioned then I do about how it is provisioned or shared.

SRD> I actually don't think it is the job of the MODERN working group to define detailed data models.  We clearly need to have some assumptions about what those data models might look like, but I would assume that each number management authority would determine what data is associated with a number.

SRD> I also think the how is important as the resulting mechanism, be it a new one defined by the group or an existing one recommended by the group, will need to be flexible and extensible to be able to address the problems outlined by Henning.

I think trying to identify the what first will be more valuable than the how, and certainly more important than the who.

SRD> Agreed and the proposed deliverables are in the order listed for that very reason.

 

Best regards,

 

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

 

 

-----Original Message-----

From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]

Sent: May 05, 2015 9:54 AM

To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org

Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

 

"Å  define a framework for the roles and functions involved in managing and resolving TNs Å " is a necessary step to create a common understanding, for a WG, of the ecosystem for managing TNs.

 

For example the WG could define a communications service user, a communications service provider, a numbering authority, a numbering administrator, etc.; describe the functions of these roles and how they may interact with each other.  Both presentations at the BoF did a good job of starting this discussion.

 

As the charter states, the work done by the WG would be flexible enough to accommodate different administrative models, therefore the framework, roles and functions would need to be flexible.  There is no intent to create a single administrative model, and there is no text in the charter that would suggest otherwise.  In fact the charter states this explicitly.

If there are text changes you could suggest that makes this clearer for you and others, please do.

 

 

 

On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com>

wrote:

 

>Thanks Steve.  I don't think wordsmithing "framework" to be

>"architectural framework" in the 2nd paragraph really addresses the

>underlying concern.

> 

>I understand the temptation to jump right in and have MODERN develop a

>newer, better, solution to the existing (North American?) framework

>architecture but it feels like a bridge too far.  I'd suggest striking

>the 2nd paragraph entirely, but I suspect that is also as unappealing

>to you as the paragraph is to me.

> 

>I liked Eric Burger's suggestions regarding fleshing out problems by

>describing use cases.

> 

>One use case that occurs to me that might lead in the direction I think

>you're interested in is I've not seen sufficient description of how to

>associate "services" with telephone numbers.  For example, many people

>are members of more than one social networking application, and some

>social network applications offer services which overlap with

>traditional telecommunications and therefore could benefit from

>assocation with number_user telephone numbers.

> 

>I think it would be useful to explore how those services could be

>defined syntactically, managed, and discovered.  But maybe that's just

>me.  Maybe others find that useless and/or objectionable.  It does seem

>like the direction you were wanting things to go in terms of giving

>number_users control over service provider associations with their telephone number.

>And it seems directionally correct in terms of addressing the interests

>of users and non-traditional communications service providers for

>service provider mash-ups associated with a telephone number.

> 

>I know I haven't directly answered your question about specific

>suggested changes to the text in the charter.  I would like to hear

>more from others.

> 

>Best regards,

> 

> 

>Pierce Gorman

>Core Network Planning

>O: 913-439-4368

>pierce.gorman@sprint.com

> 

> 

>-----Original Message-----

>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve

>Donovan

>Sent: May 04, 2015 1:30 PM

>To: modern@ietf.org

>Subject: Re: [Modern] MODERN will solve no problems (or will the IETF

>take over the world?)

> 

>Pierce,

> 

>See my comments inline.

> 

>Regards,

> 

>Steve

> 

>On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote:

>> If we can agree we eliminate the charter language that implies

>>creating a framework which supplants the authority of the NANC (at

>>least) and which assumes a replacement of the NPAC and LERG databases,

>>we will have made progress (IMHO).

>SRD> This should be easy to do, as there is no intent and, even if

>SRD> there

>were intent, there is no ability for the MODERN group to take anyone's

>authority or replace anyone's database.

> 

>SRD> Is the problem with the word framework in the second paragraph?

>Would calling it an "architectural framework" help?

>> 

>> Beyond striking objectionable language, the reason for David Holmes'

>>posts following mine last week was to try to improve the focus of the

>>work for MODERN.  We do think it is a bad idea to ignore that number

>>administration and routing solutions need to evolve.  And we're not

>>against the MODERN working group identifying problems.  In fact we're

>>in favor of it.  Its what to do past that where we're struggling.

>SRD> I share the desire to focus the work.  I think the revisions of

>SRD> the

>charter have moved in this direction.

>> 

>> The thing I'm concerned about is a repeat of the e164.arpa fiasco

>>which succeeded in defining a global schema and protocol for managing

>>numbers and resolving them for routing and which failed utterly.

>SRD> We fail if we don't learn from our mistakes.  I'm confident we

>SRD> will

>have enough involvement in the group to keep us pointed in the right

>direction.

>> 

>> Best regards,

>> 

>> 

>> Pierce Gorman

>> Core Network Planning

>> O: 913-439-4368

>> pierce.gorman@sprint.com

>> 

>> 

>> -----Original Message-----

>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve

>> Donovan

>> Sent: May 01, 2015 4:24 PM

>> To: modern@ietf.org

>> Subject: [Modern] MODERN will solve no problems (or will the IETF

>> take over the world?)

>> 

>> The question of what problem(s) MODERN will address has been asked,

>>multiple times.

>> 

>> The short answer is that, in an of itself, MODERN will solve no

>>problems.

>> 

>> This isn't to say there aren't problems with existing mechanisms. It

>>is to say that all MODERN can do is to specify protocols that can then

>>be part of an overall solution that addresses problems that exist with

>>those existing mechanisms.

>> 

>> There is a brief capture of these problems in the latest version of

>> the

>> charter:

>> 

>> "A sample of problems with existing mechanisms include:

>> 

>> - lack of flexibility (for example, it can be difficult to add fields

>>without a very elaborate and lengthy process typically spanning years)

>> - lack of distribution (for example, it is hard or impossible to have

>>more than one administrator for each database)

>> - complexity (leading, for example, to a fair amount of rural call

>>completion problems which aren't helped by small providers struggling

>>to keep numbers straight)

>> - difficulty of adopting more modern allocation (e.g., "blocks" of 1)

>>and porting mechanisms"

>> 

>> Will MODERN solve these problems? No.

>> 

>> Will MODERN make it possible for these problems to be addressed as

>>part of new number management policies to be enacted by the

>>appropriate authorities?  That, I believe, is the goal.

>> 

>> Will MODERN force any of these new number management policies to be

>>enacted.  No.  The IETF is not a policy setting body.

>> 

>> I'm ok with having a more detailed articulation of the problem

>>statement as part of the deliverables of the MODERN working group. I

>>don't see the benefit of making that the only deliverable and forcing

>>rechartering after that document is finished.  Let's instead agree to

>>shut the working group down if there is consensus that it is going

>>nowhere (which I'm sure the ADs will do anyway).

>> 

>> Regards,

>> 

>> Steve

>> 

>> _______________________________________________

>> Modern mailing list

>> Modern@ietf.org

>> 

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

>> 

>> ________________________________

>> 

>> This e-mail may contain Sprint proprietary information intended for

>>the sole 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.

>> 

>> _______________________________________________

>> Modern mailing list

>> Modern@ietf.org

>> 

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

>> 

> 

>_______________________________________________

>Modern mailing list

>Modern@ietf.org

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

> 

>________________________________

> 

>This e-mail may contain Sprint proprietary information intended for the

>sole 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.

> 

>_______________________________________________

>Modern mailing list

>Modern@ietf.org

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

 

 

________________________________

 

This e-mail may contain Sprint proprietary information intended for the sole 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.

 

_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.org/mailman/listinfo/modern



This e-mail may contain Sprint proprietary information intended for the sole 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.

--------------060008080208010301030102-- From nobody Tue May 12 15:11: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 7D55D1AD358 for ; Tue, 12 May 2015 15:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 CNzeLkTIY6xe for ; Tue, 12 May 2015 15:11:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF821A9066 for ; Tue, 12 May 2015 15:11:09 -0700 (PDT) Received: from BN1AFFO11FD042.protection.gbl (10.58.52.32) by BN1AFFO11HUB047.protection.gbl (10.58.52.109) with Microsoft SMTP Server (TLS) id 15.1.160.8; Tue, 12 May 2015 22:10:48 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1AFFO11FD042.mail.protection.outlook.com (10.58.52.253) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Tue, 12 May 2015 22:10:47 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t4CLwYO1018375; Tue, 12 May 2015 17:10:47 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm2.corp.sprint.com with ESMTP id 1u9g10hsbh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 May 2015 17:10:47 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 12 May 2015 17:10:46 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 12 May 2015 17:10:46 -0500 From: "Gorman, Pierce A [CTO]" To: Steve Donovan , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) Thread-Index: AQHQh0Uv8+KKXVduQ06DdfN8fCFs+p1yYUFQgAa0s4D//8sTEA== Date: Tue, 12 May 2015 22:10:45 +0000 Message-ID: <8ee344e2ec414f728337c9696a33cc4b@PLSWE13M08.ad.sprint.com> References: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> <90f7e39770be4118aa5ed9ca31f72b20@PLSWE13M08.ad.sprint.com> <09ec73f2cd0f4d228e9fe15ddd2b3b4b@PLSWE13M08.ad.sprint.com> <555251DF.90701@usdonovans.com> In-Reply-To: <555251DF.90701@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.24] Content-Type: multipart/related; boundary="_004_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD042; 1:rGhqTbn0OaXyfqr82z3Zk1T0U7hkcyePbMGO14r4h87n1NH/gvO7tMa6q3gXndTwYBlkb+Blh2PTVFsa94lIf/G1G+3re5ZmBvJdRurXIlKCncxjCbHhxsPVC2p00gnS9aHBR2cMPSAxmiJ0nt2dXSWDxjkszZJJHJBKpc8Z0SRW7uWhZn39r4Dqf3eaCq8JAVEzUfcRcMvGd06qDb9hGGymZWDE59vI4/2aK9tgwWyenIsF5cuF7GdTfBCisfwkBudmGNFPpDWEqAeTCBApdQmPcs02ufL8GLp/jRBI5CJ5OzD4aJfp20hd2v9Blo9v X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(448002)(189002)(13464003)(377454003)(24454002)(51704005)(199003)(479174004)(84326002)(2501003)(5250100002)(18206015028)(2950100001)(2900100001)(77156002)(62966003)(85326001)(15975445007)(102836002)(19300405004)(6806004)(24736003)(81156007)(107886002)(5001960100002)(19580395003)(19580405001)(92566002)(5001770100001)(189998001)(76176999)(99936001)(50986999)(54356999)(2656002)(87936001)(17760045003)(16236675004)(86362001)(106466001)(46102003)(106116001)(67866002)(108616004)(93886004)(33646002)(19617315012)(66926002)(19627595001)(19625215002)(30436002)(512874002)(7099028)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB047; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB047; 2:BOZ5ZR3EOj8/x2XEafNYUqCtDutVevBxJyyaF9Z2?= =?us-ascii?Q?MZX66PTtrWz23aEj/aKXgo5d;2:Ku+K4MfrdR1r/WLAqFw6ispCBfHJkNo1i?= =?us-ascii?Q?ttCldsYzpPFFS1qRtzcv76WNDdgF2ICcpljaoTZkXSvHzMao/4yITH4xhwWa?= =?us-ascii?Q?2sxV8QgS3Gy4HChuW1Obmdydmopm2GgwAy04MIujjCZb1uIw54zBDed5ZGzs?= =?us-ascii?Q?RPypCMiIdmT/EXA9ecjoNZm0xwhb/bg/OzRPKjl+fqzmd94fqFXl8mW58OO1?= =?us-ascii?Q?3ksQSF7EWAL3qsGMyZR7UkZVFrS4EhBiNpih0GCaQDu;6:RYDUx5UWzdFY/K?= =?us-ascii?Q?BLd0+CJfOuRD11LC84x54gNFzZ6KJld63/1+buuzumP1tl6QjZSk0IBLbVaY?= =?us-ascii?Q?JIH4FnnxGtRknCwIj+NsPXYWEd15oSWg5N89f+/SEduZHmNynnzRw6YsZEM5?= =?us-ascii?Q?D80NQ7+1PocL2wSJSmZLqSdd3u9Z5qxucAAlkvweDpzNaWn0KK/qGYA/GWgS?= =?us-ascii?Q?g51DEMo3i+P3yV/jjhxKBpimHMvXRhxwtviDSPn1lukTudJBgz8P4K7VMazf?= =?us-ascii?Q?vi;3:WxCyb25/TTlyPZn3T9Ec3CpcJavfZnzu2J+Sv9MDWf3Jr88Vyyf+FoK?= =?us-ascii?Q?tuAASZe5AYeOkT4Q542/JJY2020m5hSaIQ0hYqb28j324RPhVnbziqaOLosM?= =?us-ascii?Q?RkqejC8BIcTqEQBWWseA5mDBZjAfE4+lxpjXYwRpnlYWwI0Dr5XGIGuBpt3Y?= =?us-ascii?Q?apAI2ToamzQhwuafXgQVlo+nP/eEwQ8H5Hmb/WkiehR66GTktxoD9t9+W8kW?= =?us-ascii?Q?3ksaTSPYp9L3dShVEwMOxWyNmsUKD+TQ7EvnRbUeXQ4YUWdlp8ChvAitCKXg?= =?us-ascii?Q?o6MM=3D;9:aMOLusrxU6UkkQEPEHiiZOQf1otacRWJ9uAcVeQZV9611PFkAD?= =?us-ascii?Q?2GK9WdDZVhBK8Grbf3ouasO9kJd/IiKv=0D=0A=0D=0A=0D=0Aj1AxnYPON6?= =?us-ascii?Q?X4jWXgIkS0NmW9CCr0cmTTXFWEkgaSAS0JROIK2Ly55Ylab3V10ZxT0jt29q?= =?us-ascii?Q?1/xzxLdUQFNMou69Nje2bE93me4GCHVLGkhpB+ldgs1rV2jzgpHpUjuh1cH3?= =?us-ascii?Q?/AYbcxq1M+KebMvy5bFtQuhiIrL/HhzEPxYUIWeLxSNE2V5ZzMqTQaNFzdrQ?= =?us-ascii?Q?kWJFkHsodY9t+QLEb4RRLzYrNm6NS7+PS8Ilk+Zmi9egY0nNYMbijVQ3f8qi?= =?us-ascii?Q?rWELQKd36Sv3oH9qV2WpSJQr10oY1UbrwJikpm7hhoexAxYC2f2+9GNrgTck?= =?us-ascii?Q?S8U/OQ8BvL/gLJ84A0cSdAQSfvWWN0U29qtjmo1A67Feff7PgTspHAniQVTh?= =?us-ascii?Q?SVp/0y55Dk/Rxv1+/Fw+HSwdz1Ola+4xLv27NRmClGDlKFE302XHO7HnzdTx?= =?us-ascii?Q?ulYniy+lemYEgYW4xBScrxvdi/7RP/EYm6q7pwb7xWJUJCI6xZ9kfngfbd24?= =?us-ascii?Q?qKSAfCvwIfi467gvXHPQjdGWY5mVaq+kbnJq1rHG2Kuk6v5FtaxLfjPTNY8T?= =?us-ascii?Q?Ztq86AuQf171b8B16RuF0ogX0TU4P4Lf7fo1a5m8+tCGkehNbnYrji9W45ZS?= =?us-ascii?Q?/TMgwWPIcu54Auvl5wKqbQW1YXXh+Hf42eQv9FSKIyrtQEs5hMy9k23OfOHr?= =?us-ascii?Q?ruPdjQFcKewaAmmySyY+evIXmhzUlEePZFjxXOpPNm76+xEZOWL8fzU0zWMO?= =?us-ascii?Q?8O7QV/z8nvVfvT+3yejkDP6w//f/wGGTvNziDiGK8RyogJUYmgKT/JAnMaEM?= =?us-ascii?Q?gvO64MvnT4v6I70v0F5SWuXceRUEQVIHGq26fq1wCgXF8AZQz3KBIRdxc9lk?= =?us-ascii?Q?bhO8OVYdCHrx8+NN0zQjjSlhZN4AlOAek9Rm7b98fEh/O48RIPvrBoMv1Bsr?= =?us-ascii?Q?6HzDW0W21xiSGi2hzrasOuKxdZjB+rLGlLV9aGrub81qFx5/yMyMEFmhg9Pc?= =?us-ascii?Q?J0hkiz38C4L+K6IO=0D=0AdE=0D=0ALv=0D=0AN/HgmxvQ8S7WMLVydCafQ6?= =?us-ascii?Q?d/LZwZPAKayINaYoiP7LzeufCEsB8YT7A43PT3Y8zCrPOcKfH3kzXIVCKEmV?= =?us-ascii?Q?AqGUsq0PpyVQxemOn8FvgtKzd3k6yJagGyqt82fok4ZJ1i/L5RNNttvCOIX/?= =?us-ascii?Q?m5OI/mqd+tN+L2xumHZ1kBqoOztxU9gnbhQ9fFcDkUSIbP1kQFLBU+ZFlAVG?= =?us-ascii?Q?sp37it1g31JK+KFrcvxzKKfAC3f20jxWrED+oK1t3kNBsdzQKNvnegzY4d0v?= =?us-ascii?Q?EFQjgP+eSbjLvJFGKii/xFOgapQr7KVa3G+dcwlMa5ox50IpLMVMA=3D;3:I?= =?us-ascii?Q?LLc622eyeWZlLcBACUc2mKe1WdzqxbJWsphVIuRNjZ9ZqpugUxKKpSvQEVrZ?= =?us-ascii?Q?EMqS8AUafSlnHhHVVxnrfuGUQL/aiZyFMVtxInbQH6x/sipNhBKv3dGX5C++?= =?us-ascii?Q?wb4hMpg01j4bjCYo6izhgxjgHEFhg=3D=3D;10:LG/WDRs1K6FOKHbhlBVYN?= =?us-ascii?Q?YUW2WaIdyeZh74OnyxcJCKREkz3wg4nDz9Xy+DrO+LE5CdNtzmzNRGI+CU6O?= =?us-ascii?Q?2bertUZDWRoVTcSQT1KDSi1vg0=3D?= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB047; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB047; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB047; X-Forefront-PRVS: 0574D4712B X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2015 22:10:47.8048 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB047 Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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, 12 May 2015 22:11:22 -0000 --_004_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_" --_000_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFN0ZXZlLg0KDQrigJxTUkQ+ICAg4oCmSSdtIG5vdCBzdXJlIHdlIG5lZWQgdG8gZGVm aW5lIHRoZSBjb25jZXB0cyBvZiBTRVJWSUNFLCBTRVJWSUNFX1BST1ZJREVSIGFuZCBOVU1CRVJf VVNFUiwgYXMgdGhlIGZyYW1ld29yayBtaWdodCBjb21lIHVwIHdpdGggZGlmZmVyZW50IHRlcm1z IGFuZC9vciByb2xlcy7igJ0NCg0KSeKAmW0gbm90IHN1cmUgaG93IHlvdSB3YW50IHRvIHdvcmQg dGhpcyBhbmQgSeKAmW0gbm90IG1hcnJpZWQgdG8gd2hhdCBJIHN1Z2dlc3RlZC4gIEkgd2FzIGlt cGx5aW5nIGluZm9ybWF0aW9uIGluIGEgZGF0YSBtb2RlbC4gIEkgcGlja2VkIHRob3NlIHRocmVl IGZpZWxkcyBiZWNhdXNlIEkgdGhvdWdodCB0aGV5IGFyZSBmdW5kYW1lbnRhbGx5IHdoYXQgaGFz IGJlZW4gZGVzY3JpYmVkIHRvIGFzc29jaWF0ZSB3aXRoIG9uZSBvciBtb3JlIHRlbGVwaG9uZSBu dW1iZXJzIChhc3N1bWluZyB3ZSBjYW4gYWdyZWUgd2hhdCBhIFROIGlzKS4NCg0KSG93IGFib3V0 IHdlIHJlbW92ZSBhbnkgcmVmZXJlbmNlIHRvIHdoYXQgaW5mb3JtYXRpb24gaXMgYmVpbmcgYXNz b2NpYXRlZCB3aXRoIHRlbGVwaG9uZSBudW1iZXJzIGxpa2UgdGhpc+KApg0KDQpORVctRVIgIzA6 DQoNClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGVmaW5lIGEgYW4gaW5mb3JtYXRpb24gbWFuYWdl bWVudCBmcmFtZXdvcmsgZm9yIHRoZSByb2xlcyBhbmQgZnVuY3Rpb25zIGludm9sdmVkIGluIG1h bmFnaW5nIGFuZCByZXNvbHZpbmcgVE5zIGFzc29jaWF0aW5nIFNFUlZJQ0UsIFNFUlZJQ0VfUFJP VklERVIsIGFuZCBOVU1CRVJfVVNFUiBpbmZvcm1hdGlvbiB3aXRoIG9uZSBvciBtb3JlIFROcyBp biBhbiBJUCBlbnZpcm9ubWVudC4gVGhpcyBpbmNsdWRlcyBhIHByb3RvY29sIG1lY2hhbmlzbSBm b3IgYWNxdWlyaW5nIFROcywgd2hpY2ggd2lsbCBwcm92aWRlIGFuIGVucm9sbG1lbnQgcHJvY2Vz cyBmb3IgdGhlIGluZGl2aWR1YWxzIGFuZCBlbnRpdGllcyB0aGF0IHVzZSBhbmQgbWFuYWdlIFRO cy4gVE5zIG1heSBlaXRoZXIgYmUgbWFuYWdlZCBpbiBhIGhpZXJhcmNoaWNhbCB0cmVlLCBvciBp biBhIGRpc3RyaWJ1dGVkIHBlZXItdG8tcGVlciBhcmNoaXRlY3R1cmUuICBQcml2YWN5IG9mIHRo ZSBlbnJvbGxtZW50IG1hbmFnZWQgZGF0YSBhbmQgc2VjdXJpdHkgb2YgdGhlIHJlc291cmNlIHdp bGwgYmUgcHJpbWFyeSBjb25zaWRlcmF0aW9ucy4NCg0KDQrigJxTUkQ+IEknbSBtb3N0bHkgb2th eSB3aXRoIHlvdXIgY2hhbmdlcyBvdGhlciB0aGVuIHJlbW92aW5nIHRoZSB3b3JkaW5nIG9uIHRo ZSBwcm90b2NvbCB3b3JrLiAgSSBiZWxpZXZlIHRoZXJlIGlzIGVub3VnaCBzdXBwb3J0IGZvciBk b2luZyB0aGUgcHJvdG9jb2wgd29yayB0aGF0IHRoaXMgc2hvdWxkIHJlbWFpbiBpbiB0aGUgY2hh cnRlci7igJ0NCg0KV2VsbCwgaWYgdGhlcmXigJlzIGVub3VnaCBzdXBwb3J0IHlvdSBjYW4gaWdu b3JlIG1lLiAg4pi6ICBUaGUgaGVhcnRidXJuIEkgaGF2ZSB3aXRoIGxlYXZpbmcgdGhlIHByb3Rv Y29sIHdvcmsgaW4gdGhlcmUgaXMgSeKAmW0gbm90IGNvbnZpbmNlZCBuZXcgcHJvdG9jb2wgbWVj aGFuaXNtcyBhcmUgbmVlZGVkLg0KDQpFdmVuIGlmIGl0IHdhcyBpbmFyZ3VhYmxlIHRoYXQgbmV3 IHByb3RvY29sIG1lY2hhbmlzbXMgYXJlIG5lZWRlZCwgd29u4oCZdCB0aGlzIHN0aWxsIHBvaW50 IGJhY2sgdG8geW91ciBwb2ludCBhYm91dCwg4oCcZWFjaCBudW1iZXIgbWFuYWdlbWVudCBhdXRo b3JpdHkgd291bGQgZGV0ZXJtaW5lIHdoYXQgZGF0YSBpcyBhc3NvY2lhdGVkIHdpdGggYSBudW1i ZXLigJ0/DQoNClRvZGF5IHRob3NlIG51bWJlciBtYW5hZ2VtZW50IGF1dGhvcml0aWVzIGFsc28g ZGV0ZXJtaW5lIHRoZSBwcm90b2NvbCBtZWNoYW5pc21zIGZvciBlbnJvbGxpbmcgKGkuZS4sIGFz c2lnbmluZykgYW5kIG1hbmFnaW5nIHRlbGVwaG9uZSBudW1iZXJzLiAgV2hhdCByZWFzb24gaXMg dGhlcmUgdG8gYmVsaWV2ZSB0aGV5IHdpbGwgc3BvbnRhbmVvdXNseSBhZG9wdCB3aGF0IE1PREVS TiBkZXZlbG9wZWQ/ICBUaGlzIGlzIHN0YXJ0aW5nIHRvIGZlZWwgbGlrZSBUUklQMi4wLg0KDQpJ IHRoaW5rIHRoZSBudW1iZXIgbWFuYWdlbWVudCBhdXRob3JpdGllcyBoYXZlIHRvIHJlc3BlY3Qg dXNlcnMgYW5kIGNvbW11bmljYXRpb25zIHNlcnZpY2UgcHJvdmlkZXJzIHdhbnQgdG8gY3JlYXRl IGFzc29jaWF0aW9ucyBvZiBuZXcgbm9uLXRyYWRpdGlvbmFsIGtpbmRzIG9mIGluZm9ybWF0aW9u IHdpdGggb25lIG9yIG1vcmUgdGVsZXBob25lIG51bWJlcnMuDQoNCkkgZG9u4oCZdCB0aGluayB0 aGF0IG5lY2Vzc2FyaWx5IGltcGxpZXMgdGhleSBhbHNvIGhhdmUgdG8gcmVzcGVjdCBhbnkgc3Vn Z2VzdGVkIHByb3RvY29sIG1lY2hhbmlzbXMgZm9yIG1hbmFnaW5nIHRoZSBpbmZvcm1hdGlvbiBh c3NvY2F0aW9ucy4gIEFuZCB0aGUgbnVtYmVyIG1hbmFnZW1lbnQgYXV0aG9yaXRpZXMgd291bGQg bmVjZXNzYXJpbHkgYmUgZmFjaW5nIHRoYXQgY29udmVyc2F0aW9uIGF0IHNvbWUgcG9pbnQsIHdp bGwgdGhleSBub3Q/DQoNCuKAnFNSRD4gV2UgY2xlYXJseSBuZWVkIHRvIGhhdmUgc29tZSBhc3N1 bXB0aW9ucyBhYm91dCB3aGF0IHRob3NlIGRhdGEgbW9kZWxzIG1pZ2h0IGxvb2sgbGlrZSwgYnV0 4oCm4oCdDQoNCkFncmVlZC4gIEkgc3VnZ2VzdCBkZXZlbG9waW5nIGEgc3RhcnRlciBkYXRhIG1v ZGVsIGJhc2VkIG9uIGEgc2V0IG9mIGxlZ2FjeSByZXF1aXJlbWVudHMgYW5kIHJlcXVpcmVtZW50 cyBub3QgYmVpbmcgbWV0IGJ5IHRoZSBjdXJyZW50IGRhdGEgc2V0IHdvdWxkIGJlIHVzZWZ1bC4g IEkgdGhpbmsgZGVmaW5pbmcgYW4gZWFzaWx5IGV4dGVuc2libGUgZGF0YSBtb2RlbCBpcyBjcml0 aWNhbC4NCg0KSeKAmW0gbm90IHZlcnkgaW50ZXJlc3RlZCBpbiBkaXNjdXNzaW5nIFlBUFAgKFll dCBBbm90aGVyIFByb3Zpc2lvbmluZyBQcm90b2NvbCksIGJ1dCB2ZXJ5IGludGVyZXN0ZWQgdG8g ZGlzY3VzcyBhc3NvY2lhdGlvbiBvZiBuZXcgbm9uLXRyYWRpdGlvbmFsIHNlcnZpY2VzIGFuZCB0 aGVpciBpZGVudGlmaWVycyBhbmQgcGFyYW1ldGVycyB3aXRoIHRlbGVwaG9uZSBudW1iZXJzLg0K DQpCZXN0IHJlZ2FyZHMsDQoNCg0KUGllcmNlIEdvcm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5n DQpPOiA5MTMtNDM5LTQzNjgNCnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbQ0KW2NpZDo0MDgwMDBf MDg2ODAxNDI4NjAxMTQ1MDAxQHB2bXhlMTNnMDFdDQoNCkZyb206IFN0ZXZlIERvbm92YW4gW21h aWx0bzpzcmRvbm92YW5AdXNkb25vdmFucy5jb21dDQpTZW50OiBNYXkgMTIsIDIwMTUgMjoxOCBQ TQ0KVG86IEdvcm1hbiwgUGllcmNlIEEgW0NUT107IE1jR2FycnksIFRvbTsgbW9kZXJuQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW01vZGVybl0gTU9ERVJOIHdpbGwgc29sdmUgbm8gcHJvYmxlbXMg KG9yIHdpbGwgdGhlIElFVEYgdGFrZSBvdmVyIHRoZSB3b3JsZD8pDQoNClBpZXJjZSwNCg0KU2Vl IG15IGNvbW1lbnRzIGlubGluZS4NCg0KU3RldmUNCk9uIDUvOC8xNSAxMjo1OCBQTSwgR29ybWFu LCBQaWVyY2UgQSBbQ1RPXSB3cm90ZToNClN0ZXZlLA0KDQpIZXJlIGlzIGEgc3VnZ2VzdGVkIHNl dCBvZiBjaGFuZ2VzIHRvIHRoZSAybmQgcGFyYWdyYXBoLg0KDQpPTEQ6DQoNClRoZSB3b3JraW5n IGdyb3VwIHdpbGwgZGVmaW5lIGEgZnJhbWV3b3JrIGZvciB0aGUgcm9sZXMgYW5kIGZ1bmN0aW9u cyBpbnZvbHZlZCBpbiBtYW5hZ2luZyBhbmQgcmVzb2x2aW5nIFROcyBpbiBhbiBJUCBlbnZpcm9u bWVudC4gVGhpcyBpbmNsdWRlcyBhIHByb3RvY29sIG1lY2hhbmlzbSBmb3IgYWNxdWlyaW5nIFRO cywgd2hpY2ggd2lsbCBwcm92aWRlIGFuIGVucm9sbG1lbnQgcHJvY2VzcyBmb3IgdGhlIGluZGl2 aWR1YWxzIGFuZCBlbnRpdGllcyB0aGF0IHVzZSBhbmQgbWFuYWdlIFROcy4gVE5zIG1heSBlaXRo ZXIgYmUgbWFuYWdlZCBpbiBhIGhpZXJhcmNoaWNhbCB0cmVlLCBvciBpbiBhIGRpc3RyaWJ1dGVk IHBlZXItdG8tcGVlciBhcmNoaXRlY3R1cmUuICBQcml2YWN5IG9mIHRoZSBlbnJvbGxtZW50IGRh dGEgYW5kIHNlY3VyaXR5IG9mIHRoZSByZXNvdXJjZSB3aWxsIGJlIHByaW1hcnkgY29uc2lkZXJh dGlvbnMuDQoNCk5FVzoNCg0KVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBhbiBpbmZv cm1hdGlvbiBtYW5hZ2VtZW50IGZyYW1ld29yayBmb3IgdGhlIHJvbGVzIGFuZCBmdW5jdGlvbnMg aW52b2x2ZWQgaW4gbWFuYWdpbmcgYW5kIHJlc29sdmluZyBUTnMgYXNzb2NpYXRpbmcgU0VSVklD RSwgU0VSVklDRV9QUk9WSURFUiwgYW5kIE5VTUJFUl9VU0VSIGluZm9ybWF0aW9uIHdpdGggb25l IG9yIG1vcmUgVE5zIGluIGFuIElQIGVudmlyb25tZW50LiBUaGlzIGluY2x1ZGVzIGEgcHJvdG9j b2wgbWVjaGFuaXNtIGZvciBhY3F1aXJpbmcgVE5zLCB3aGljaCB3aWxsIHByb3ZpZGUgYW4gZW5y b2xsbWVudCBwcm9jZXNzIGZvciB0aGUgaW5kaXZpZHVhbHMgYW5kIGVudGl0aWVzIHRoYXQgdXNl IGFuZCBtYW5hZ2UgVE5zLiBUTnMgbWF5IGVpdGhlciBiZSBtYW5hZ2VkIGluIGEgaGllcmFyY2hp Y2FsIHRyZWUsIG9yIGluIGEgZGlzdHJpYnV0ZWQgcGVlci10by1wZWVyIGFyY2hpdGVjdHVyZS4g IFByaXZhY3kgb2YgdGhlIGVucm9sbG1lbnQgbWFuYWdlZCBkYXRhIGFuZCBzZWN1cml0eSBvZiB0 aGUgcmVzb3VyY2Ugd2lsbCBiZSBwcmltYXJ5IGNvbnNpZGVyYXRpb25zLg0KDQoNClNSRD4gSSdt IG1vc3RseSBva2F5IHdpdGggeW91ciBjaGFuZ2VzIG90aGVyIHRoZW4gcmVtb3ZpbmcgdGhlIHdv cmRpbmcgb24gdGhlIHByb3RvY29sIHdvcmsuICBJIGJlbGlldmUgdGhlcmUgaXMgZW5vdWdoIHN1 cHBvcnQgZm9yIGRvaW5nIHRoZSBwcm90b2NvbCB3b3JrIHRoYXQgdGhpcyBzaG91bGQgcmVtYWlu IGluIHRoZSBjaGFydGVyLiAgIEknbSBub3Qgc3VyZSB3ZSBuZWVkIHRvIGRlZmluZSB0aGUgY29u Y2VwdHMgb2YgU0VSVklDRSwgU0VSVklDRV9QUk9WSURFUiBhbmQgTlVNQkVSX1VTRVIsIGFzIHRo ZSBmcmFtZXdvcmsgbWlnaHQgY29tZSB1cCB3aXRoIGRpZmZlcmVudCB0ZXJtcyBhbmQvb3Igcm9s ZXMuDQoNCg0KSSB3b3VsZCBwcmVmZXIgaWYgb3RoZXJzIHdlaWdoZWQgaW4gaGVyZS4gIEkgZG9u 4oCZdCBsaWtlIGJlaW5nIG9uZSBvZiBhIGZldyB3aXRoIHN1Y2ggaW5mbHVlbmNlLg0KDQoNClNS RD4gQWdyZWVkLg0KDQoNCkJlY2F1c2UgSSB3YXNu4oCZdCBhdCB0aGUgQm9GIGFuZCBhbSBuZXcg YXQgdGhpcyBzb3J0IG9mIHRoaW5nLCBJIHBlcnNvbmFsbHkgd291bGQgYmUgaGFwcGllciBpZiB3 ZSB0b29rIG1vcmUgdGltZSBpbiBlLW1haWwgb3IgbWVldGluZ3MgdG8gZGlzY3VzcyB0aGUgcHJv YmxlbXMgdGhlIFdHIHNob3VsZCBhZGRyZXNzLCBub3QgdGhlIHNvbHV0aW9ucyAoYXQgZmlyc3Qp Lg0KU1JEPiBZZXMgd2UgbmVlZCBtb3JlIGRpc2N1c3Npb24uICBUaGF0IGlzIHdoYXQgdGhlIHdv cmtpbmcgZ3JvdXAgaXMgZm9yLiAgVGhlIGNoYXJ0ZXIgaXMgdG8gZGVmaW5lIHRoZSBzY29wZSBv ZiB0aGUgd29ya2luZyBncm91cCBlZmZvcnQuICBXZSBkb24ndCBuZWVkIHRvIGhhdmUgYWxsIG9m IHRoZSBhbnN3ZXJzIG5vdy4NCg0KDQoNCg0KQSBzcGVjaWZpYyBhcmVhIG9mIGNvbmNlcm4gZm9y IG1lIGlzIHRoZSBkYXRhIG1vZGVsIG9mIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0aCB0ZWxl cGhvbmUgbnVtYmVycy4gICBJIGNhcmUgbXVjaCBtb3JlIGFib3V0IHdoYXQgaXMgYmVpbmcgcHJv dmlzaW9uZWQgdGhlbiBJIGRvIGFib3V0IGhvdyBpdCBpcyBwcm92aXNpb25lZCBvciBzaGFyZWQu DQpTUkQ+IEkgYWN0dWFsbHkgZG9uJ3QgdGhpbmsgaXQgaXMgdGhlIGpvYiBvZiB0aGUgTU9ERVJO IHdvcmtpbmcgZ3JvdXAgdG8gZGVmaW5lIGRldGFpbGVkIGRhdGEgbW9kZWxzLiAgV2UgY2xlYXJs eSBuZWVkIHRvIGhhdmUgc29tZSBhc3N1bXB0aW9ucyBhYm91dCB3aGF0IHRob3NlIGRhdGEgbW9k ZWxzIG1pZ2h0IGxvb2sgbGlrZSwgYnV0IEkgd291bGQgYXNzdW1lIHRoYXQgZWFjaCBudW1iZXIg bWFuYWdlbWVudCBhdXRob3JpdHkgd291bGQgZGV0ZXJtaW5lIHdoYXQgZGF0YSBpcyBhc3NvY2lh dGVkIHdpdGggYSBudW1iZXIuDQoNClNSRD4gSSBhbHNvIHRoaW5rIHRoZSBob3cgaXMgaW1wb3J0 YW50IGFzIHRoZSByZXN1bHRpbmcgbWVjaGFuaXNtLCBiZSBpdCBhIG5ldyBvbmUgZGVmaW5lZCBi eSB0aGUgZ3JvdXAgb3IgYW4gZXhpc3Rpbmcgb25lIHJlY29tbWVuZGVkIGJ5IHRoZSBncm91cCwg d2lsbCBuZWVkIHRvIGJlIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIHRvIGJlIGFibGUgdG8gYWRk cmVzcyB0aGUgcHJvYmxlbXMgb3V0bGluZWQgYnkgSGVubmluZy4NCg0KSSB0aGluayB0cnlpbmcg dG8gaWRlbnRpZnkgdGhlIHdoYXQgZmlyc3Qgd2lsbCBiZSBtb3JlIHZhbHVhYmxlIHRoYW4gdGhl IGhvdywgYW5kIGNlcnRhaW5seSBtb3JlIGltcG9ydGFudCB0aGFuIHRoZSB3aG8uDQpTUkQ+IEFn cmVlZCBhbmQgdGhlIHByb3Bvc2VkIGRlbGl2ZXJhYmxlcyBhcmUgaW4gdGhlIG9yZGVyIGxpc3Rl ZCBmb3IgdGhhdCB2ZXJ5IHJlYXNvbi4NCg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQoNCg0KDQoN ClBpZXJjZSBHb3JtYW4NCg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQoNCk86IDkxMy00MzktNDM2 OA0KDQpwaWVyY2UuZ29ybWFuQHNwcmludC5jb208bWFpbHRvOnBpZXJjZS5nb3JtYW5Ac3ByaW50 LmNvbT4NCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBNY0dh cnJ5LCBUb20gW21haWx0bzpUb20uTWNHYXJyeUBuZXVzdGFyLmJpel0NCg0KU2VudDogTWF5IDA1 LCAyMDE1IDk6NTQgQU0NCg0KVG86IEdvcm1hbiwgUGllcmNlIEEgW0NUT107IFN0ZXZlIERvbm92 YW47IG1vZGVybkBpZXRmLm9yZzxtYWlsdG86bW9kZXJuQGlldGYub3JnPg0KDQpTdWJqZWN0OiBS ZTogW01vZGVybl0gTU9ERVJOIHdpbGwgc29sdmUgbm8gcHJvYmxlbXMgKG9yIHdpbGwgdGhlIElF VEYgdGFrZSBvdmVyIHRoZSB3b3JsZD8pDQoNCg0KDQoixaAgZGVmaW5lIGEgZnJhbWV3b3JrIGZv ciB0aGUgcm9sZXMgYW5kIGZ1bmN0aW9ucyBpbnZvbHZlZCBpbiBtYW5hZ2luZyBhbmQgcmVzb2x2 aW5nIFROcyDFoCIgaXMgYSBuZWNlc3Nhcnkgc3RlcCB0byBjcmVhdGUgYSBjb21tb24gdW5kZXJz dGFuZGluZywgZm9yIGEgV0csIG9mIHRoZSBlY29zeXN0ZW0gZm9yIG1hbmFnaW5nIFROcy4NCg0K DQoNCkZvciBleGFtcGxlIHRoZSBXRyBjb3VsZCBkZWZpbmUgYSBjb21tdW5pY2F0aW9ucyBzZXJ2 aWNlIHVzZXIsIGEgY29tbXVuaWNhdGlvbnMgc2VydmljZSBwcm92aWRlciwgYSBudW1iZXJpbmcg YXV0aG9yaXR5LCBhIG51bWJlcmluZyBhZG1pbmlzdHJhdG9yLCBldGMuOyBkZXNjcmliZSB0aGUg ZnVuY3Rpb25zIG9mIHRoZXNlIHJvbGVzIGFuZCBob3cgdGhleSBtYXkgaW50ZXJhY3Qgd2l0aCBl YWNoIG90aGVyLiAgQm90aCBwcmVzZW50YXRpb25zIGF0IHRoZSBCb0YgZGlkIGEgZ29vZCBqb2Ig b2Ygc3RhcnRpbmcgdGhpcyBkaXNjdXNzaW9uLg0KDQoNCg0KQXMgdGhlIGNoYXJ0ZXIgc3RhdGVz LCB0aGUgd29yayBkb25lIGJ5IHRoZSBXRyB3b3VsZCBiZSBmbGV4aWJsZSBlbm91Z2ggdG8gYWNj b21tb2RhdGUgZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIG1vZGVscywgdGhlcmVmb3JlIHRoZSBm cmFtZXdvcmssIHJvbGVzIGFuZCBmdW5jdGlvbnMgd291bGQgbmVlZCB0byBiZSBmbGV4aWJsZS4g IFRoZXJlIGlzIG5vIGludGVudCB0byBjcmVhdGUgYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgbW9k ZWwsIGFuZCB0aGVyZSBpcyBubyB0ZXh0IGluIHRoZSBjaGFydGVyIHRoYXQgd291bGQgc3VnZ2Vz dCBvdGhlcndpc2UuICBJbiBmYWN0IHRoZSBjaGFydGVyIHN0YXRlcyB0aGlzIGV4cGxpY2l0bHku DQoNCklmIHRoZXJlIGFyZSB0ZXh0IGNoYW5nZXMgeW91IGNvdWxkIHN1Z2dlc3QgdGhhdCBtYWtl cyB0aGlzIGNsZWFyZXIgZm9yIHlvdSBhbmQgb3RoZXJzLCBwbGVhc2UgZG8uDQoNCg0KDQoNCg0K DQoNCk9uIDUvNC8xNSA0OjUzIFBNLCAiR29ybWFuLCBQaWVyY2UgQSBbQ1RPXSIgPFBpZXJjZS5H b3JtYW5Ac3ByaW50LmNvbTxtYWlsdG86UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPj4NCg0Kd3Jv dGU6DQoNCg0KDQo+VGhhbmtzIFN0ZXZlLiAgSSBkb24ndCB0aGluayB3b3Jkc21pdGhpbmcgImZy YW1ld29yayIgdG8gYmUNCg0KPiJhcmNoaXRlY3R1cmFsIGZyYW1ld29yayIgaW4gdGhlIDJuZCBw YXJhZ3JhcGggcmVhbGx5IGFkZHJlc3NlcyB0aGUNCg0KPnVuZGVybHlpbmcgY29uY2Vybi4NCg0K Pg0KDQo+SSB1bmRlcnN0YW5kIHRoZSB0ZW1wdGF0aW9uIHRvIGp1bXAgcmlnaHQgaW4gYW5kIGhh dmUgTU9ERVJOIGRldmVsb3AgYQ0KDQo+bmV3ZXIsIGJldHRlciwgc29sdXRpb24gdG8gdGhlIGV4 aXN0aW5nIChOb3J0aCBBbWVyaWNhbj8pIGZyYW1ld29yaw0KDQo+YXJjaGl0ZWN0dXJlIGJ1dCBp dCBmZWVscyBsaWtlIGEgYnJpZGdlIHRvbyBmYXIuICBJJ2Qgc3VnZ2VzdCBzdHJpa2luZw0KDQo+ dGhlIDJuZCBwYXJhZ3JhcGggZW50aXJlbHksIGJ1dCBJIHN1c3BlY3QgdGhhdCBpcyBhbHNvIGFz IHVuYXBwZWFsaW5nDQoNCj50byB5b3UgYXMgdGhlIHBhcmFncmFwaCBpcyB0byBtZS4NCg0KPg0K DQo+SSBsaWtlZCBFcmljIEJ1cmdlcidzIHN1Z2dlc3Rpb25zIHJlZ2FyZGluZyBmbGVzaGluZyBv dXQgcHJvYmxlbXMgYnkNCg0KPmRlc2NyaWJpbmcgdXNlIGNhc2VzLg0KDQo+DQoNCj5PbmUgdXNl IGNhc2UgdGhhdCBvY2N1cnMgdG8gbWUgdGhhdCBtaWdodCBsZWFkIGluIHRoZSBkaXJlY3Rpb24g SSB0aGluaw0KDQo+eW91J3JlIGludGVyZXN0ZWQgaW4gaXMgSSd2ZSBub3Qgc2VlbiBzdWZmaWNp ZW50IGRlc2NyaXB0aW9uIG9mIGhvdyB0bw0KDQo+YXNzb2NpYXRlICJzZXJ2aWNlcyIgd2l0aCB0 ZWxlcGhvbmUgbnVtYmVycy4gIEZvciBleGFtcGxlLCBtYW55IHBlb3BsZQ0KDQo+YXJlIG1lbWJl cnMgb2YgbW9yZSB0aGFuIG9uZSBzb2NpYWwgbmV0d29ya2luZyBhcHBsaWNhdGlvbiwgYW5kIHNv bWUNCg0KPnNvY2lhbCBuZXR3b3JrIGFwcGxpY2F0aW9ucyBvZmZlciBzZXJ2aWNlcyB3aGljaCBv dmVybGFwIHdpdGgNCg0KPnRyYWRpdGlvbmFsIHRlbGVjb21tdW5pY2F0aW9ucyBhbmQgdGhlcmVm b3JlIGNvdWxkIGJlbmVmaXQgZnJvbQ0KDQo+YXNzb2NhdGlvbiB3aXRoIG51bWJlcl91c2VyIHRl bGVwaG9uZSBudW1iZXJzLg0KDQo+DQoNCj5JIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBl eHBsb3JlIGhvdyB0aG9zZSBzZXJ2aWNlcyBjb3VsZCBiZQ0KDQo+ZGVmaW5lZCBzeW50YWN0aWNh bGx5LCBtYW5hZ2VkLCBhbmQgZGlzY292ZXJlZC4gIEJ1dCBtYXliZSB0aGF0J3MganVzdA0KDQo+ bWUuICBNYXliZSBvdGhlcnMgZmluZCB0aGF0IHVzZWxlc3MgYW5kL29yIG9iamVjdGlvbmFibGUu ICBJdCBkb2VzIHNlZW0NCg0KPmxpa2UgdGhlIGRpcmVjdGlvbiB5b3Ugd2VyZSB3YW50aW5nIHRo aW5ncyB0byBnbyBpbiB0ZXJtcyBvZiBnaXZpbmcNCg0KPm51bWJlcl91c2VycyBjb250cm9sIG92 ZXIgc2VydmljZSBwcm92aWRlciBhc3NvY2lhdGlvbnMgd2l0aCB0aGVpciB0ZWxlcGhvbmUgbnVt YmVyLg0KDQo+QW5kIGl0IHNlZW1zIGRpcmVjdGlvbmFsbHkgY29ycmVjdCBpbiB0ZXJtcyBvZiBh ZGRyZXNzaW5nIHRoZSBpbnRlcmVzdHMNCg0KPm9mIHVzZXJzIGFuZCBub24tdHJhZGl0aW9uYWwg Y29tbXVuaWNhdGlvbnMgc2VydmljZSBwcm92aWRlcnMgZm9yDQoNCj5zZXJ2aWNlIHByb3ZpZGVy IG1hc2gtdXBzIGFzc29jaWF0ZWQgd2l0aCBhIHRlbGVwaG9uZSBudW1iZXIuDQoNCj4NCg0KPkkg a25vdyBJIGhhdmVuJ3QgZGlyZWN0bHkgYW5zd2VyZWQgeW91ciBxdWVzdGlvbiBhYm91dCBzcGVj aWZpYw0KDQo+c3VnZ2VzdGVkIGNoYW5nZXMgdG8gdGhlIHRleHQgaW4gdGhlIGNoYXJ0ZXIuICBJ IHdvdWxkIGxpa2UgdG8gaGVhcg0KDQo+bW9yZSBmcm9tIG90aGVycy4NCg0KPg0KDQo+QmVzdCBy ZWdhcmRzLA0KDQo+DQoNCj4NCg0KPlBpZXJjZSBHb3JtYW4NCg0KPkNvcmUgTmV0d29yayBQbGFu bmluZw0KDQo+TzogOTEzLTQzOS00MzY4DQoNCj5waWVyY2UuZ29ybWFuQHNwcmludC5jb208bWFp bHRvOnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbT4NCg0KPg0KDQo+DQoNCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KDQo+RnJvbTogTW9kZXJuIFttYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZQ0KDQo+RG9ub3Zhbg0KDQo+U2VudDogTWF5IDA0LCAy MDE1IDE6MzAgUE0NCg0KPlRvOiBtb2Rlcm5AaWV0Zi5vcmc8bWFpbHRvOm1vZGVybkBpZXRmLm9y Zz4NCg0KPlN1YmplY3Q6IFJlOiBbTW9kZXJuXSBNT0RFUk4gd2lsbCBzb2x2ZSBubyBwcm9ibGVt cyAob3Igd2lsbCB0aGUgSUVURg0KDQo+dGFrZSBvdmVyIHRoZSB3b3JsZD8pDQoNCj4NCg0KPlBp ZXJjZSwNCg0KPg0KDQo+U2VlIG15IGNvbW1lbnRzIGlubGluZS4NCg0KPg0KDQo+UmVnYXJkcywN Cg0KPg0KDQo+U3RldmUNCg0KPg0KDQo+T24gNS80LzE1IDExOjMyIEFNLCBHb3JtYW4sIFBpZXJj ZSBBIFtDVE9dIHdyb3RlOg0KDQo+PiBJZiB3ZSBjYW4gYWdyZWUgd2UgZWxpbWluYXRlIHRoZSBj aGFydGVyIGxhbmd1YWdlIHRoYXQgaW1wbGllcw0KDQo+PmNyZWF0aW5nIGEgZnJhbWV3b3JrIHdo aWNoIHN1cHBsYW50cyB0aGUgYXV0aG9yaXR5IG9mIHRoZSBOQU5DIChhdA0KDQo+PmxlYXN0KSBh bmQgd2hpY2ggYXNzdW1lcyBhIHJlcGxhY2VtZW50IG9mIHRoZSBOUEFDIGFuZCBMRVJHIGRhdGFi YXNlcywNCg0KPj53ZSB3aWxsIGhhdmUgbWFkZSBwcm9ncmVzcyAoSU1ITykuDQoNCj5TUkQ+IFRo aXMgc2hvdWxkIGJlIGVhc3kgdG8gZG8sIGFzIHRoZXJlIGlzIG5vIGludGVudCBhbmQsIGV2ZW4g aWYNCg0KPlNSRD4gdGhlcmUNCg0KPndlcmUgaW50ZW50LCB0aGVyZSBpcyBubyBhYmlsaXR5IGZv ciB0aGUgTU9ERVJOIGdyb3VwIHRvIHRha2UgYW55b25lJ3MNCg0KPmF1dGhvcml0eSBvciByZXBs YWNlIGFueW9uZSdzIGRhdGFiYXNlLg0KDQo+DQoNCj5TUkQ+IElzIHRoZSBwcm9ibGVtIHdpdGgg dGhlIHdvcmQgZnJhbWV3b3JrIGluIHRoZSBzZWNvbmQgcGFyYWdyYXBoPw0KDQo+V291bGQgY2Fs bGluZyBpdCBhbiAiYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsiIGhlbHA/DQoNCj4+DQoNCj4+IEJl eW9uZCBzdHJpa2luZyBvYmplY3Rpb25hYmxlIGxhbmd1YWdlLCB0aGUgcmVhc29uIGZvciBEYXZp ZCBIb2xtZXMnDQoNCj4+cG9zdHMgZm9sbG93aW5nIG1pbmUgbGFzdCB3ZWVrIHdhcyB0byB0cnkg dG8gaW1wcm92ZSB0aGUgZm9jdXMgb2YgdGhlDQoNCj4+d29yayBmb3IgTU9ERVJOLiAgV2UgZG8g dGhpbmsgaXQgaXMgYSBiYWQgaWRlYSB0byBpZ25vcmUgdGhhdCBudW1iZXINCg0KPj5hZG1pbmlz dHJhdGlvbiBhbmQgcm91dGluZyBzb2x1dGlvbnMgbmVlZCB0byBldm9sdmUuICBBbmQgd2UncmUg bm90DQoNCj4+YWdhaW5zdCB0aGUgTU9ERVJOIHdvcmtpbmcgZ3JvdXAgaWRlbnRpZnlpbmcgcHJv YmxlbXMuICBJbiBmYWN0IHdlJ3JlDQoNCj4+aW4gZmF2b3Igb2YgaXQuICBJdHMgd2hhdCB0byBk byBwYXN0IHRoYXQgd2hlcmUgd2UncmUgc3RydWdnbGluZy4NCg0KPlNSRD4gSSBzaGFyZSB0aGUg ZGVzaXJlIHRvIGZvY3VzIHRoZSB3b3JrLiAgSSB0aGluayB0aGUgcmV2aXNpb25zIG9mDQoNCj5T UkQ+IHRoZQ0KDQo+Y2hhcnRlciBoYXZlIG1vdmVkIGluIHRoaXMgZGlyZWN0aW9uLg0KDQo+Pg0K DQo+PiBUaGUgdGhpbmcgSSdtIGNvbmNlcm5lZCBhYm91dCBpcyBhIHJlcGVhdCBvZiB0aGUgZTE2 NC5hcnBhIGZpYXNjbw0KDQo+PndoaWNoIHN1Y2NlZWRlZCBpbiBkZWZpbmluZyBhIGdsb2JhbCBz Y2hlbWEgYW5kIHByb3RvY29sIGZvciBtYW5hZ2luZw0KDQo+Pm51bWJlcnMgYW5kIHJlc29sdmlu ZyB0aGVtIGZvciByb3V0aW5nIGFuZCB3aGljaCBmYWlsZWQgdXR0ZXJseS4NCg0KPlNSRD4gV2Ug ZmFpbCBpZiB3ZSBkb24ndCBsZWFybiBmcm9tIG91ciBtaXN0YWtlcy4gIEknbSBjb25maWRlbnQg d2UNCg0KPlNSRD4gd2lsbA0KDQo+aGF2ZSBlbm91Z2ggaW52b2x2ZW1lbnQgaW4gdGhlIGdyb3Vw IHRvIGtlZXAgdXMgcG9pbnRlZCBpbiB0aGUgcmlnaHQNCg0KPmRpcmVjdGlvbi4NCg0KPj4NCg0K Pj4gQmVzdCByZWdhcmRzLA0KDQo+Pg0KDQo+Pg0KDQo+PiBQaWVyY2UgR29ybWFuDQoNCj4+IENv cmUgTmV0d29yayBQbGFubmluZw0KDQo+PiBPOiA5MTMtNDM5LTQzNjgNCg0KPj4gcGllcmNlLmdv cm1hbkBzcHJpbnQuY29tPG1haWx0bzpwaWVyY2UuZ29ybWFuQHNwcmludC5jb20+DQoNCj4+DQoN Cj4+DQoNCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+IEZyb206IE1vZGVybiBb bWFpbHRvOm1vZGVybi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RldmUNCg0KPj4g RG9ub3Zhbg0KDQo+PiBTZW50OiBNYXkgMDEsIDIwMTUgNDoyNCBQTQ0KDQo+PiBUbzogbW9kZXJu QGlldGYub3JnPG1haWx0bzptb2Rlcm5AaWV0Zi5vcmc+DQoNCj4+IFN1YmplY3Q6IFtNb2Rlcm5d IE1PREVSTiB3aWxsIHNvbHZlIG5vIHByb2JsZW1zIChvciB3aWxsIHRoZSBJRVRGDQoNCj4+IHRh a2Ugb3ZlciB0aGUgd29ybGQ/KQ0KDQo+Pg0KDQo+PiBUaGUgcXVlc3Rpb24gb2Ygd2hhdCBwcm9i bGVtKHMpIE1PREVSTiB3aWxsIGFkZHJlc3MgaGFzIGJlZW4gYXNrZWQsDQoNCj4+bXVsdGlwbGUg dGltZXMuDQoNCj4+DQoNCj4+IFRoZSBzaG9ydCBhbnN3ZXIgaXMgdGhhdCwgaW4gYW4gb2YgaXRz ZWxmLCBNT0RFUk4gd2lsbCBzb2x2ZSBubw0KDQo+PnByb2JsZW1zLg0KDQo+Pg0KDQo+PiBUaGlz IGlzbid0IHRvIHNheSB0aGVyZSBhcmVuJ3QgcHJvYmxlbXMgd2l0aCBleGlzdGluZyBtZWNoYW5p c21zLiBJdA0KDQo+PmlzIHRvIHNheSB0aGF0IGFsbCBNT0RFUk4gY2FuIGRvIGlzIHRvIHNwZWNp ZnkgcHJvdG9jb2xzIHRoYXQgY2FuIHRoZW4NCg0KPj5iZSBwYXJ0IG9mIGFuIG92ZXJhbGwgc29s dXRpb24gdGhhdCBhZGRyZXNzZXMgcHJvYmxlbXMgdGhhdCBleGlzdCB3aXRoDQoNCj4+dGhvc2Ug ZXhpc3RpbmcgbWVjaGFuaXNtcy4NCg0KPj4NCg0KPj4gVGhlcmUgaXMgYSBicmllZiBjYXB0dXJl IG9mIHRoZXNlIHByb2JsZW1zIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZg0KDQo+PiB0aGUNCg0K Pj4gY2hhcnRlcjoNCg0KPj4NCg0KPj4gIkEgc2FtcGxlIG9mIHByb2JsZW1zIHdpdGggZXhpc3Rp bmcgbWVjaGFuaXNtcyBpbmNsdWRlOg0KDQo+Pg0KDQo+PiAtIGxhY2sgb2YgZmxleGliaWxpdHkg KGZvciBleGFtcGxlLCBpdCBjYW4gYmUgZGlmZmljdWx0IHRvIGFkZCBmaWVsZHMNCg0KPj53aXRo b3V0IGEgdmVyeSBlbGFib3JhdGUgYW5kIGxlbmd0aHkgcHJvY2VzcyB0eXBpY2FsbHkgc3Bhbm5p bmcgeWVhcnMpDQoNCj4+IC0gbGFjayBvZiBkaXN0cmlidXRpb24gKGZvciBleGFtcGxlLCBpdCBp cyBoYXJkIG9yIGltcG9zc2libGUgdG8gaGF2ZQ0KDQo+Pm1vcmUgdGhhbiBvbmUgYWRtaW5pc3Ry YXRvciBmb3IgZWFjaCBkYXRhYmFzZSkNCg0KPj4gLSBjb21wbGV4aXR5IChsZWFkaW5nLCBmb3Ig ZXhhbXBsZSwgdG8gYSBmYWlyIGFtb3VudCBvZiBydXJhbCBjYWxsDQoNCj4+Y29tcGxldGlvbiBw cm9ibGVtcyB3aGljaCBhcmVuJ3QgaGVscGVkIGJ5IHNtYWxsIHByb3ZpZGVycyBzdHJ1Z2dsaW5n DQoNCj4+dG8ga2VlcCBudW1iZXJzIHN0cmFpZ2h0KQ0KDQo+PiAtIGRpZmZpY3VsdHkgb2YgYWRv cHRpbmcgbW9yZSBtb2Rlcm4gYWxsb2NhdGlvbiAoZS5nLiwgImJsb2NrcyIgb2YgMSkNCg0KPj5h bmQgcG9ydGluZyBtZWNoYW5pc21zIg0KDQo+Pg0KDQo+PiBXaWxsIE1PREVSTiBzb2x2ZSB0aGVz ZSBwcm9ibGVtcz8gTm8uDQoNCj4+DQoNCj4+IFdpbGwgTU9ERVJOIG1ha2UgaXQgcG9zc2libGUg Zm9yIHRoZXNlIHByb2JsZW1zIHRvIGJlIGFkZHJlc3NlZCBhcw0KDQo+PnBhcnQgb2YgbmV3IG51 bWJlciBtYW5hZ2VtZW50IHBvbGljaWVzIHRvIGJlIGVuYWN0ZWQgYnkgdGhlDQoNCj4+YXBwcm9w cmlhdGUgYXV0aG9yaXRpZXM/ICBUaGF0LCBJIGJlbGlldmUsIGlzIHRoZSBnb2FsLg0KDQo+Pg0K DQo+PiBXaWxsIE1PREVSTiBmb3JjZSBhbnkgb2YgdGhlc2UgbmV3IG51bWJlciBtYW5hZ2VtZW50 IHBvbGljaWVzIHRvIGJlDQoNCj4+ZW5hY3RlZC4gIE5vLiAgVGhlIElFVEYgaXMgbm90IGEgcG9s aWN5IHNldHRpbmcgYm9keS4NCg0KPj4NCg0KPj4gSSdtIG9rIHdpdGggaGF2aW5nIGEgbW9yZSBk ZXRhaWxlZCBhcnRpY3VsYXRpb24gb2YgdGhlIHByb2JsZW0NCg0KPj5zdGF0ZW1lbnQgYXMgcGFy dCBvZiB0aGUgZGVsaXZlcmFibGVzIG9mIHRoZSBNT0RFUk4gd29ya2luZyBncm91cC4gSQ0KDQo+ PmRvbid0IHNlZSB0aGUgYmVuZWZpdCBvZiBtYWtpbmcgdGhhdCB0aGUgb25seSBkZWxpdmVyYWJs ZSBhbmQgZm9yY2luZw0KDQo+PnJlY2hhcnRlcmluZyBhZnRlciB0aGF0IGRvY3VtZW50IGlzIGZp bmlzaGVkLiAgTGV0J3MgaW5zdGVhZCBhZ3JlZSB0bw0KDQo+PnNodXQgdGhlIHdvcmtpbmcgZ3Jv dXAgZG93biBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCBpdCBpcyBnb2luZw0KDQo+Pm5vd2hl cmUgKHdoaWNoIEknbSBzdXJlIHRoZSBBRHMgd2lsbCBkbyBhbnl3YXkpLg0KDQo+Pg0KDQo+PiBS ZWdhcmRzLA0KDQo+Pg0KDQo+PiBTdGV2ZQ0KDQo+Pg0KDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+PiBNb2Rlcm4gbWFpbGluZyBsaXN0DQoN Cj4+IE1vZGVybkBpZXRmLm9yZzxtYWlsdG86TW9kZXJuQGlldGYub3JnPg0KDQo+Pg0KDQo+Pmh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWwNCg0KPj5tYW4NCg0KPj5fbGlzdGluZm9fbW9kZXJuJmQ9QXdJQ0FnJmM9TU9w dE5sVnRJRVRlREFMQ19sVUxydyZyPTRLbG0zMmlCN0h1ZnZlZUlEDQoNCj4+Y0xlDQoNCj4+eHRa MW9vTmNmcDAxSVlJYVZxc09SakkmbT1PN1RaNFlNNkJvWFh5RGhWeFQ4ajVWRzQ2WDZXbFZxdnRJ QngteFREZjd3Jg0KDQo+PnM9aCB0SU1fUWVPSTNmSE9aU0VVTm5ILTNEWXhpWU1SRWJwNVA4UlBo VGpHcXcmZT0NCg0KPj4NCg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K Pj4NCg0KPj4gVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9y bWF0aW9uIGludGVuZGVkIGZvcg0KDQo+PnRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMp LiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZg0KDQo+PnlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kDQoNCj4+ ZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQoNCj4+DQoNCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+IE1vZGVybiBtYWlsaW5n IGxpc3QNCg0KPj4gTW9kZXJuQGlldGYub3JnPG1haWx0bzpNb2Rlcm5AaWV0Zi5vcmc+DQoNCj4+ DQoNCj4+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbA0KDQo+Pm1hbg0KDQo+Pl9saXN0aW5mb19tb2Rlcm4mZD1Bd0lD QWcmYz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3JnI9NEtsbTMyaUI3SHVmdmVlSUQNCg0KPj5jTGUN Cg0KPj54dFoxb29OY2ZwMDFJWUlhVnFzT1JqSSZtPU83VFo0WU02Qm9YWHlEaFZ4VDhqNVZHNDZY NldsVnF2dElCeC14VERmN3cmDQoNCj4+cz1oIHRJTV9RZU9JM2ZIT1pTRVVObkgtM0RZeGlZTVJF YnA1UDhSUGhUakdxdyZlPQ0KDQo+Pg0KDQo+DQoNCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQo+TW9kZXJuIG1haWxpbmcgbGlzdA0KDQo+TW9kZXJu QGlldGYub3JnPG1haWx0bzpNb2Rlcm5AaWV0Zi5vcmc+DQoNCj5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbQ0KDQo+ YW5fDQoNCj5saXN0aW5mb19tb2Rlcm4mZD1Bd0lDQWcmYz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3 JnI9NEtsbTMyaUI3SHVmdmVlSURjTA0KDQo+ZXh0DQoNCj5aMW9vTmNmcDAxSVlJYVZxc09Sakkm bT1PN1RaNFlNNkJvWFh5RGhWeFQ4ajVWRzQ2WDZXbFZxdnRJQngteFREZjd3JnM9aA0KDQo+dElN IF9RZU9JM2ZIT1pTRVVObkgtM0RZeGlZTVJFYnA1UDhSUGhUakdxdyZlPQ0KDQo+DQoNCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+DQoNCj5UaGlzIGUtbWFpbCBtYXkgY29u dGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZQ0KDQo+ c29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGli aXRlZC4gSWYgeW91DQoNCj5hcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZQ0KDQo+YWxsIGNvcGllcyBvZiB0aGUgbWVzc2Fn ZS4NCg0KPg0KDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KPk1vZGVybiBtYWlsaW5nIGxpc3QNCg0KPk1vZGVybkBpZXRmLm9yZzxtYWlsdG86TW9k ZXJuQGlldGYub3JnPg0KDQo+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG0NCg0KPmFuXw0KDQo+bGlzdGluZm9fbW9k ZXJuJmQ9QXdJQ0FnJmM9TU9wdE5sVnRJRVRlREFMQ19sVUxydyZyPTRLbG0zMmlCN0h1ZnZlZUlE Y0wNCg0KPmV4dA0KDQo+WjFvb05jZnAwMUlZSWFWcXNPUmpJJm09TzdUWjRZTTZCb1hYeURoVnhU OGo1Vkc0Nlg2V2xWcXZ0SUJ4LXhURGY3dyZzPWgNCg0KPnRJTSBfUWVPSTNmSE9aU0VVTm5ILTNE WXhpWU1SRWJwNVA4UlBoVGpHcXcmZT0NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQoNCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVu dChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRl IGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpNb2Rlcm4gbWFpbGluZyBsaXN0DQoNCk1vZGVy bkBpZXRmLm9yZzxtYWlsdG86TW9kZXJuQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3Jt YXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkg dXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGll cyBvZiB0aGUgbWVzc2FnZS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24g aW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5 IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0 aGUgbWVzc2FnZS4NCg== --_000_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4 dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMDBDQzsNCglmb250LXdl aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUg bm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5UaGFua3Mg U3RldmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MDBDQyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMDBDQyI+4oCcU1JEJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyDigKZJJ20gbm90IHN1cmUgd2UgbmVlZCB0byBkZWZpbmUgdGhlIGNvbmNlcHRzIG9mIFNF UlZJQ0UsIFNFUlZJQ0VfUFJPVklERVIgYW5kIE5VTUJFUl9VU0VSLCBhcyB0aGUNCiBmcmFtZXdv cmsgbWlnaHQgY29tZSB1cCB3aXRoIGRpZmZlcmVudCB0ZXJtcyBhbmQvb3Igcm9sZXMuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDAwQ0MiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDAwQ0MiPknigJltIG5vdCBzdXJlIGhvdyB5b3Ugd2FudCB0byB3b3Jk IHRoaXMgYW5kIEnigJltIG5vdCBtYXJyaWVkIHRvIHdoYXQgSSBzdWdnZXN0ZWQuJm5ic3A7IEkg d2FzIGltcGx5aW5nIGluZm9ybWF0aW9uIGluIGEgZGF0YSBtb2RlbC4mbmJzcDsgSSBwaWNrZWQg dGhvc2UgdGhyZWUgZmllbGRzIGJlY2F1c2UgSSB0aG91Z2h0IHRoZXkNCiBhcmUgZnVuZGFtZW50 YWxseSB3aGF0IGhhcyBiZWVuIGRlc2NyaWJlZCB0byBhc3NvY2lhdGUgd2l0aCBvbmUgb3IgbW9y ZSB0ZWxlcGhvbmUgbnVtYmVycyAoYXNzdW1pbmcgd2UgY2FuIGFncmVlIHdoYXQgYSBUTiBpcyku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MDBDQyI+SG93IGFib3V0IHdlIHJlbW92ZSBhbnkgcmVmZXJlbmNlIHRvIHdoYXQgaW5mb3JtYXRp b24gaXMgYmVpbmcgYXNzb2NpYXRlZCB3aXRoIHRlbGVwaG9uZSBudW1iZXJzIGxpa2UgdGhpc+KA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0Mi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5ORVctRVIgIzA6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHdvcmtp bmcgZ3JvdXAgd2lsbCBkZWZpbmUgPHM+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+YTwvc3Bhbj48 L3M+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+YW4gaW5mb3JtYXRpb24gbWFuYWdlbWVu dDwvc3Bhbj4gZnJhbWV3b3JrIGZvciB0aGUgcm9sZXMgYW5kIGZ1bmN0aW9ucyBpbnZvbHZlZCBp bg0KPHM+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+bWFuYWdpbmcgYW5kIHJlc29sdmluZyBUTnM8 L3NwYW4+PC9zPiA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+DQphc3NvY2lhdGluZyA8L3Nw YW4+PHM+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+U0VSVklDRSwgU0VSVklDRV9QUk9WSURFUiwg YW5kIE5VTUJFUl9VU0VSPC9zcGFuPjwvcz48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+IGlu Zm9ybWF0aW9uIHdpdGggb25lIG9yIG1vcmUgVE5zDQo8L3NwYW4+aW4gYW4gSVAgZW52aXJvbm1l bnQuIDxzPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPlRoaXMgaW5jbHVkZXMgYSBwcm90b2NvbCBt ZWNoYW5pc20gZm9yIGFjcXVpcmluZyBUTnMsIHdoaWNoIHdpbGwgcHJvdmlkZSBhbiBlbnJvbGxt ZW50IHByb2Nlc3MgZm9yIHRoZSBpbmRpdmlkdWFscyBhbmQgZW50aXRpZXMgdGhhdCB1c2UgYW5k IG1hbmFnZSBUTnMuIFROcyBtYXkgZWl0aGVyIGJlIG1hbmFnZWQgaW4gYSBoaWVyYXJjaGljYWwg dHJlZSwNCiBvciBpbiBhIGRpc3RyaWJ1dGVkIHBlZXItdG8tcGVlciBhcmNoaXRlY3R1cmUuIDwv c3Bhbj48L3M+Jm5ic3A7UHJpdmFjeSBvZiB0aGUgPHM+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ ZW5yb2xsbWVudDwvc3Bhbj48L3M+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+bWFuYWdl ZCA8L3NwYW4+ZGF0YSBhbmQgc2VjdXJpdHkgb2YgdGhlIHJlc291cmNlIHdpbGwgYmUgcHJpbWFy eSBjb25zaWRlcmF0aW9ucy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj7igJxTUkQmZ3Q7IEknbSBtb3N0bHkg b2theSB3aXRoIHlvdXIgY2hhbmdlcyBvdGhlciB0aGVuIHJlbW92aW5nIHRoZSB3b3JkaW5nIG9u IHRoZSBwcm90b2NvbCB3b3JrLiZuYnNwOyBJIGJlbGlldmUgdGhlcmUgaXMgZW5vdWdoIHN1cHBv cnQgZm9yIGRvaW5nIHRoZSBwcm90b2NvbCB3b3JrIHRoYXQgdGhpcyBzaG91bGQNCiByZW1haW4g aW4gdGhlIGNoYXJ0ZXIu4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPldlbGwsIGlmIHRoZXJl 4oCZcyBlbm91Z2ggc3VwcG9ydCB5b3UgY2FuIGlnbm9yZSBtZS4mbmJzcDsNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMwMDAwQ0MiPko8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMDBDQyI+Jm5ic3A7IFRoZSBoZWFydGJ1cm4gSSBoYXZlIHdpdGggbGVhdmluZyB0aGUgcHJv dG9jb2wgd29yayBpbiB0aGVyZSBpcyBJ4oCZbSBub3QgY29udmluY2VkIG5ldyBwcm90b2NvbCBt ZWNoYW5pc21zIGFyZSBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMDBDQyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+RXZlbiBpZiBpdCB3YXMgaW5hcmd1YWJsZSB0aGF0 IG5ldyBwcm90b2NvbCBtZWNoYW5pc21zIGFyZSBuZWVkZWQsIHdvbuKAmXQgdGhpcyBzdGlsbCBw b2ludCBiYWNrIHRvIHlvdXIgcG9pbnQgYWJvdXQsIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPmVhY2gNCiBudW1iZXIgbWFuYWdlbWVudCBhdXRob3JpdHkgd291bGQgZGV0ZXJtaW5lIHdo YXQgZGF0YSBpcyBhc3NvY2lhdGVkIHdpdGggYSBudW1iZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+4oCd PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0Mi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDAwQ0MiPlRvZGF5IHRob3NlIG51bWJlciBtYW5hZ2VtZW50IGF1dGhvcml0aWVzIGFsc28gZGV0 ZXJtaW5lIHRoZSBwcm90b2NvbCBtZWNoYW5pc21zIGZvciBlbnJvbGxpbmcgKGkuZS4sIGFzc2ln bmluZykgYW5kIG1hbmFnaW5nIHRlbGVwaG9uZSBudW1iZXJzLiZuYnNwOyBXaGF0IHJlYXNvbiBp cyB0aGVyZSB0byBiZWxpZXZlDQogdGhleSB3aWxsIHNwb250YW5lb3VzbHkgYWRvcHQgd2hhdCBN T0RFUk4gZGV2ZWxvcGVkPyZuYnNwOyBUaGlzIGlzIHN0YXJ0aW5nIHRvIGZlZWwgbGlrZSBUUklQ Mi4wLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAw Q0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDAwQ0MiPkkgdGhpbmsgdGhlIG51bWJlciBtYW5hZ2VtZW50IGF1dGhvcml0aWVzIGhhdmUg dG8gcmVzcGVjdCB1c2VycyBhbmQgY29tbXVuaWNhdGlvbnMgc2VydmljZSBwcm92aWRlcnMgd2Fu dCB0byBjcmVhdGUgYXNzb2NpYXRpb25zIG9mIG5ldyBub24tdHJhZGl0aW9uYWwga2luZHMgb2Yg aW5mb3JtYXRpb24gd2l0aA0KIG9uZSBvciBtb3JlIHRlbGVwaG9uZSBudW1iZXJzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPkkg ZG9u4oCZdCB0aGluayB0aGF0IG5lY2Vzc2FyaWx5IGltcGxpZXMgdGhleSBhbHNvIGhhdmUgdG8g cmVzcGVjdCBhbnkgc3VnZ2VzdGVkIHByb3RvY29sIG1lY2hhbmlzbXMgZm9yIG1hbmFnaW5nIHRo ZSBpbmZvcm1hdGlvbiBhc3NvY2F0aW9ucy4mbmJzcDsgQW5kIHRoZSBudW1iZXIgbWFuYWdlbWVu dCBhdXRob3JpdGllcw0KIHdvdWxkIG5lY2Vzc2FyaWx5IGJlIGZhY2luZyB0aGF0IGNvbnZlcnNh dGlvbiBhdCBzb21lIHBvaW50LCB3aWxsIHRoZXkgbm90PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPuKAnDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPlNSRCZndDsgV2UgY2xlYXJseSBuZWVkIHRvIGhhdmUgc29tZSBhc3N1bXB0 aW9ucyBhYm91dCB3aGF0IHRob3NlIGRhdGEgbW9kZWxzIG1pZ2h0IGxvb2sgbGlrZSwgYnV04oCm PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDAwQ0MiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPkFncmVlZC4mbmJzcDsgSSBzdWdnZXN0IGRldmVs b3BpbmcgYSBzdGFydGVyIGRhdGEgbW9kZWwgYmFzZWQgb24gYSBzZXQgb2YgbGVnYWN5IHJlcXVp cmVtZW50cyBhbmQgcmVxdWlyZW1lbnRzIG5vdCBiZWluZyBtZXQgYnkgdGhlIGN1cnJlbnQgZGF0 YSBzZXQgd291bGQgYmUgdXNlZnVsLiZuYnNwOyBJIHRoaW5rIGRlZmluaW5nDQogYW4gZWFzaWx5 IGV4dGVuc2libGUgZGF0YSBtb2RlbCBpcyBjcml0aWNhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5J4oCZbSBub3QgdmVyeSBp bnRlcmVzdGVkIGluIGRpc2N1c3NpbmcgWUFQUCAoWWV0IEFub3RoZXIgUHJvdmlzaW9uaW5nIFBy b3RvY29sKSwgYnV0IHZlcnkgaW50ZXJlc3RlZCB0byBkaXNjdXNzIGFzc29jaWF0aW9uIG9mIG5l dyBub24tdHJhZGl0aW9uYWwgc2VydmljZXMgYW5kIHRoZWlyIGlkZW50aWZpZXJzDQogYW5kIHBh cmFtZXRlcnMgd2l0aCB0ZWxlcGhvbmUgbnVtYmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+QmVzdCByZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0Mi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDAwQ0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tcmlnaHQ6NS44cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPlBpZXJjZSBHb3JtYW48 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjUuOHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+Q29yZSBOZXR3b3JrIFBsYW5uaW5nPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAwMENDIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjUuOHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMDBDQyI+TzogOTEzLTQzOS00MzY4PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMEND Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLXJpZ2h0OjUuOHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+cGllcmNlLmdvcm1h bkBzcHJpbnQuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjUu OHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+PGltZyB3aWR0aD0iMzM1IiBoZWlnaHQ9 IjYwIiBpZD0iUGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMS5wbmdAMDFEMDhDQ0Yu QTkyMkJGNTAiIGFsdD0iY2lkOjQwODAwMF8wODY4MDE0Mjg2MDExNDUwMDFAcHZteGUxM2cwMSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+IFN0ZXZlIERvbm92YW4gW21haWx0bzpzcmRvbm92YW5AdXNkb25vdmFucy5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gTWF5IDEyLCAyMDE1IDI6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IEdvcm1h biwgUGllcmNlIEEgW0NUT107IE1jR2FycnksIFRvbTsgbW9kZXJuQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTW9kZXJuXSBNT0RFUk4gd2lsbCBzb2x2ZSBubyBwcm9ibGVtcyAo b3Igd2lsbCB0aGUgSUVURiB0YWtlIG92ZXIgdGhlIHdvcmxkPyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PlBpZXJjZSwgPGJyPg0KPGJyPg0KU2VlIG15IGNvbW1lbnRzIGlubGluZS48YnI+DQo8YnI+DQpT dGV2ZTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNS84LzE1IDEyOjU4IFBNLCBHb3JtYW4s IFBpZXJjZSBBIFtDVE9dIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlN0ZXZlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIGEgc3Vn Z2VzdGVkIHNldCBvZiBjaGFuZ2VzIHRvIHRoZSAyPHN1cD5uZDwvc3VwPiBwYXJhZ3JhcGguPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9MRDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHdv cmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBmcmFtZXdvcmsgZm9yIHRoZSByb2xlcyBhbmQgZnVu Y3Rpb25zIGludm9sdmVkIGluIG1hbmFnaW5nIGFuZCByZXNvbHZpbmcgVE5zIGluIGFuIElQIGVu dmlyb25tZW50LiBUaGlzIGluY2x1ZGVzIGEgcHJvdG9jb2wgbWVjaGFuaXNtIGZvciBhY3F1aXJp bmcgVE5zLCB3aGljaCB3aWxsIHByb3ZpZGUgYW4gZW5yb2xsbWVudCBwcm9jZXNzIGZvciB0aGUg aW5kaXZpZHVhbHMNCiBhbmQgZW50aXRpZXMgdGhhdCB1c2UgYW5kIG1hbmFnZSBUTnMuIFROcyBt YXkgZWl0aGVyIGJlIG1hbmFnZWQgaW4gYSBoaWVyYXJjaGljYWwgdHJlZSwgb3IgaW4gYSBkaXN0 cmlidXRlZCBwZWVyLXRvLXBlZXIgYXJjaGl0ZWN0dXJlLiAmbmJzcDtQcml2YWN5IG9mIHRoZSBl bnJvbGxtZW50IGRhdGEgYW5kIHNlY3VyaXR5IG9mIHRoZSByZXNvdXJjZSB3aWxsIGJlIHByaW1h cnkgY29uc2lkZXJhdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TkVXOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgd29ya2luZyBncm91cCB3aWxsIGRlZmluZSA8cz48c3BhbiBz dHlsZT0iY29sb3I6cmVkIj5hPC9zcGFuPjwvcz4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMEND Ij5hbiBpbmZvcm1hdGlvbiBtYW5hZ2VtZW50PC9zcGFuPiBmcmFtZXdvcmsgZm9yIHRoZSByb2xl cyBhbmQgZnVuY3Rpb25zIGludm9sdmVkIGluDQo8cz48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5t YW5hZ2luZyBhbmQgcmVzb2x2aW5nIFROczwvc3Bhbj48L3M+IDxzcGFuIHN0eWxlPSJjb2xvcjoj MDAwMENDIj4NCmFzc29jaWF0aW5nIFNFUlZJQ0UsIFNFUlZJQ0VfUFJPVklERVIsIGFuZCBOVU1C RVJfVVNFUiBpbmZvcm1hdGlvbiB3aXRoIG9uZSBvciBtb3JlIFROcw0KPC9zcGFuPmluIGFuIElQ IGVudmlyb25tZW50LiA8cz48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5UaGlzIGluY2x1ZGVzIGEg cHJvdG9jb2wgbWVjaGFuaXNtIGZvciBhY3F1aXJpbmcgVE5zLCB3aGljaCB3aWxsIHByb3ZpZGUg YW4gZW5yb2xsbWVudCBwcm9jZXNzIGZvciB0aGUgaW5kaXZpZHVhbHMgYW5kIGVudGl0aWVzIHRo YXQgdXNlIGFuZCBtYW5hZ2UgVE5zLiBUTnMgbWF5IGVpdGhlciBiZSBtYW5hZ2VkIGluIGEgaGll cmFyY2hpY2FsIHRyZWUsDQogb3IgaW4gYSBkaXN0cmlidXRlZCBwZWVyLXRvLXBlZXIgYXJjaGl0 ZWN0dXJlLiA8L3NwYW4+PC9zPiZuYnNwO1ByaXZhY3kgb2YgdGhlIDxzPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPmVucm9sbG1lbnQ8L3NwYW4+PC9zPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAw Q0MiPm1hbmFnZWQgPC9zcGFuPmRhdGEgYW5kIHNlY3VyaXR5IG9mIHRoZSByZXNvdXJjZSB3aWxs IGJlIHByaW1hcnkgY29uc2lkZXJhdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5TUkQmZ3Q7IEknbSBtb3N0bHkgb2th eSB3aXRoIHlvdXIgY2hhbmdlcyBvdGhlciB0aGVuIHJlbW92aW5nIHRoZSB3b3JkaW5nIG9uIHRo ZSBwcm90b2NvbCB3b3JrLiZuYnNwOyBJIGJlbGlldmUgdGhlcmUgaXMgZW5vdWdoIHN1cHBvcnQg Zm9yIGRvaW5nIHRoZSBwcm90b2NvbCB3b3JrIHRoYXQgdGhpcyBzaG91bGQNCiByZW1haW4gaW4g dGhlIGNoYXJ0ZXIuJm5ic3A7Jm5ic3A7IEknbSBub3Qgc3VyZSB3ZSBuZWVkIHRvIGRlZmluZSB0 aGUgY29uY2VwdHMgb2YgU0VSVklDRSwgU0VSVklDRV9QUk9WSURFUiBhbmQgTlVNQkVSX1VTRVIs IGFzIHRoZSBmcmFtZXdvcmsgbWlnaHQgY29tZSB1cCB3aXRoIGRpZmZlcmVudCB0ZXJtcyBhbmQv b3Igcm9sZXMuJm5ic3A7DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkkgd291bGQgcHJlZmVyIGlmIG90aGVycyB3ZWlnaGVkIGlu IGhlcmUuJm5ic3A7IEkgZG9u4oCZdCBsaWtlIGJlaW5nIG9uZSBvZiBhIGZldyB3aXRoIHN1Y2gg aW5mbHVlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPlNSRCZndDsgQWdyZWVkLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVjYXVzZSBJIHdhc27igJl0IGF0 IHRoZSBCb0YgYW5kIGFtIG5ldyBhdCB0aGlzIHNvcnQgb2YgdGhpbmcsIEkgcGVyc29uYWxseSB3 b3VsZCBiZSBoYXBwaWVyIGlmIHdlIHRvb2sgbW9yZSB0aW1lIGluIGUtbWFpbCBvciBtZWV0aW5n cyB0byBkaXNjdXNzIHRoZSBwcm9ibGVtcyB0aGUgV0cgc2hvdWxkIGFkZHJlc3MsIG5vdCB0aGUg c29sdXRpb25zIChhdCBmaXJzdCkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlNSRCZndDsgWWVzIHdlIG5lZWQg bW9yZSBkaXNjdXNzaW9uLiZuYnNwOyBUaGF0IGlzIHdoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaXMg Zm9yLiZuYnNwOyBUaGUgY2hhcnRlciBpcyB0byBkZWZpbmUgdGhlIHNjb3BlIG9mIHRoZSB3b3Jr aW5nIGdyb3VwIGVmZm9ydC4mbmJzcDsgV2UgZG9uJ3QgbmVlZCB0byBoYXZlIGFsbCBvZg0KIHRo ZSBhbnN3ZXJzIG5vdy48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+QSBzcGVjaWZpYyBhcmVhIG9mIGNvbmNlcm4gZm9yIG1lIGlzIHRoZSBkYXRhIG1v ZGVsIG9mIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0aCB0ZWxlcGhvbmUgbnVtYmVycy4mbmJz cDsgJm5ic3A7SSBjYXJlIG11Y2ggbW9yZSBhYm91dCB3aGF0IGlzIGJlaW5nIHByb3Zpc2lvbmVk IHRoZW4gSSBkbyBhYm91dCBob3cgaXQgaXMgcHJvdmlzaW9uZWQgb3Igc2hhcmVkLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj5TUkQmZ3Q7IEkgYWN0dWFsbHkgZG9uJ3QgdGhpbmsgaXQgaXMgdGhlIGpvYiBvZiB0 aGUgTU9ERVJOIHdvcmtpbmcgZ3JvdXAgdG8gZGVmaW5lIGRldGFpbGVkIGRhdGEgbW9kZWxzLiZu YnNwOyBXZSBjbGVhcmx5IG5lZWQgdG8gaGF2ZSBzb21lIGFzc3VtcHRpb25zIGFib3V0IHdoYXQg dGhvc2UgZGF0YSBtb2RlbHMNCiBtaWdodCBsb29rIGxpa2UsIGJ1dCBJIHdvdWxkIGFzc3VtZSB0 aGF0IGVhY2ggbnVtYmVyIG1hbmFnZW1lbnQgYXV0aG9yaXR5IHdvdWxkIGRldGVybWluZSB3aGF0 IGRhdGEgaXMgYXNzb2NpYXRlZCB3aXRoIGEgbnVtYmVyLjxicj4NCjxicj4NClNSRCZndDsgSSBh bHNvIHRoaW5rIHRoZSBob3cgaXMgaW1wb3J0YW50IGFzIHRoZSByZXN1bHRpbmcgbWVjaGFuaXNt LCBiZSBpdCBhIG5ldyBvbmUgZGVmaW5lZCBieSB0aGUgZ3JvdXAgb3IgYW4gZXhpc3Rpbmcgb25l IHJlY29tbWVuZGVkIGJ5IHRoZSBncm91cCwgd2lsbCBuZWVkIHRvIGJlIGZsZXhpYmxlIGFuZCBl eHRlbnNpYmxlIHRvIGJlIGFibGUgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbXMgb3V0bGluZWQgYnkg SGVubmluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SSB0aGluayB0cnlpbmcgdG8gaWRlbnRpZnkgdGhlIHdoYXQgZmlyc3Qgd2lsbCBiZSBtb3Jl IHZhbHVhYmxlIHRoYW4gdGhlIGhvdywgYW5kIGNlcnRhaW5seSBtb3JlIGltcG9ydGFudCB0aGFu IHRoZSB3aG8uDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+U1JEJmd0OyBBZ3JlZWQgYW5kIHRoZSBwcm9wb3Nl ZCBkZWxpdmVyYWJsZXMgYXJlIGluIHRoZSBvcmRlciBsaXN0ZWQgZm9yIHRoYXQgdmVyeSByZWFz b24uPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJl c3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QaWVyY2UgR29ybWFuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Db3JlIE5ldHdvcmsgUGxhbm5pbmc8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk86IDkxMy00MzktNDM2ODxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0ibWFpbHRvOnBpZXJjZS5n b3JtYW5Ac3ByaW50LmNvbSI+cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Gcm9tOiBNY0dhcnJ5LCBUb20gWzxhIGhyZWY9Im1haWx0bzpU b20uTWNHYXJyeUBuZXVzdGFyLmJpeiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpUb20uTWNHYXJyeUBuZXVzdGFyLmJpejwvc3Bhbj48 L2E+XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VudDogTWF5IDA1 LCAyMDE1IDk6NTQgQU08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRv OiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dOyBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86 bW9kZXJuQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5tb2Rlcm5AaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3ViamVjdDogUmU6IFtNb2Rlcm5dIE1PREVSTiB3aWxs IHNvbHZlIG5vIHByb2JsZW1zIChvciB3aWxsIHRoZSBJRVRGIHRha2Ugb3ZlciB0aGUgd29ybGQ/ KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mcXVvdDvFoCBkZWZpbmUgYSBmcmFtZXdv cmsgZm9yIHRoZSByb2xlcyBhbmQgZnVuY3Rpb25zIGludm9sdmVkIGluIG1hbmFnaW5nIGFuZCBy ZXNvbHZpbmcgVE5zIMWgJnF1b3Q7IGlzIGEgbmVjZXNzYXJ5IHN0ZXAgdG8gY3JlYXRlIGEgY29t bW9uIHVuZGVyc3RhbmRpbmcsIGZvciBhIFdHLCBvZiB0aGUgZWNvc3lzdGVtIGZvciBtYW5hZ2lu ZyBUTnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZvciBleGFtcGxlIHRoZSBXRyBj b3VsZCBkZWZpbmUgYSBjb21tdW5pY2F0aW9ucyBzZXJ2aWNlIHVzZXIsIGEgY29tbXVuaWNhdGlv bnMgc2VydmljZSBwcm92aWRlciwgYSBudW1iZXJpbmcgYXV0aG9yaXR5LCBhIG51bWJlcmluZyBh ZG1pbmlzdHJhdG9yLCBldGMuOyBkZXNjcmliZSB0aGUgZnVuY3Rpb25zIG9mIHRoZXNlIHJvbGVz IGFuZCBob3cgdGhleSBtYXkgaW50ZXJhY3Qgd2l0aCBlYWNoIG90aGVyLiZuYnNwOw0KIEJvdGgg cHJlc2VudGF0aW9ucyBhdCB0aGUgQm9GIGRpZCBhIGdvb2Qgam9iIG9mIHN0YXJ0aW5nIHRoaXMg ZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXMgdGhlIGNoYXJ0ZXIg c3RhdGVzLCB0aGUgd29yayBkb25lIGJ5IHRoZSBXRyB3b3VsZCBiZSBmbGV4aWJsZSBlbm91Z2gg dG8gYWNjb21tb2RhdGUgZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIG1vZGVscywgdGhlcmVmb3Jl IHRoZSBmcmFtZXdvcmssIHJvbGVzIGFuZCBmdW5jdGlvbnMgd291bGQgbmVlZCB0byBiZSBmbGV4 aWJsZS4mbmJzcDsgVGhlcmUgaXMgbm8gaW50ZW50IHRvIGNyZWF0ZSBhIHNpbmdsZSBhZG1pbmlz dHJhdGl2ZQ0KIG1vZGVsLCBhbmQgdGhlcmUgaXMgbm8gdGV4dCBpbiB0aGUgY2hhcnRlciB0aGF0 IHdvdWxkIHN1Z2dlc3Qgb3RoZXJ3aXNlLiZuYnNwOyBJbiBmYWN0IHRoZSBjaGFydGVyIHN0YXRl cyB0aGlzIGV4cGxpY2l0bHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5JZiB0aGVyZSBhcmUgdGV4dCBjaGFuZ2VzIHlvdSBjb3VsZCBzdWdnZXN0IHRoYXQgbWFrZXMg dGhpcyBjbGVhcmVyIGZvciB5b3UgYW5kIG90aGVycywgcGxlYXNlIGRvLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24g NS80LzE1IDQ6NTMgUE0sICZxdW90O0dvcm1hbiwgUGllcmNlIEEgW0NUT10mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpQaWVyY2UuR29ybWFuQHNwcmludC5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5QaWVyY2UuR29ybWFuQHNwcmludC5j b208L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pndyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7VGhhbmtzIFN0ZXZlLiZu YnNwOyBJIGRvbid0IHRoaW5rIHdvcmRzbWl0aGluZyAmcXVvdDtmcmFtZXdvcmsmcXVvdDsgdG8g YmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZxdW90O2Fy Y2hpdGVjdHVyYWwgZnJhbWV3b3JrJnF1b3Q7IGluIHRoZSAybmQgcGFyYWdyYXBoIHJlYWxseSBh ZGRyZXNzZXMgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDt1bmRlcmx5aW5nIGNvbmNlcm4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7SSB1bmRlcnN0YW5kIHRoZSB0ZW1wdGF0aW9uIHRvIGp1bXAgcmlnaHQgaW4gYW5kIGhhdmUg TU9ERVJOIGRldmVsb3AgYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7bmV3ZXIsIGJldHRlciwgc29sdXRpb24gdG8gdGhlIGV4aXN0aW5nIChOb3J0aCBBbWVy aWNhbj8pIGZyYW1ld29yaw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7YXJjaGl0ZWN0dXJlIGJ1dCBpdCBmZWVscyBsaWtlIGEgYnJpZGdlIHRvbyBmYXIuJm5i c3A7IEknZCBzdWdnZXN0IHN0cmlraW5nDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDt0aGUgMm5kIHBhcmFncmFwaCBlbnRpcmVseSwgYnV0IEkgc3VzcGVjdCB0 aGF0IGlzIGFsc28gYXMgdW5hcHBlYWxpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0O3RvIHlvdSBhcyB0aGUgcGFyYWdyYXBoIGlzIHRvIG1lLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O0kgbGlrZWQgRXJpYyBCdXJnZXIncyBzdWdn ZXN0aW9ucyByZWdhcmRpbmcgZmxlc2hpbmcgb3V0IHByb2JsZW1zIGJ5DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtkZXNjcmliaW5nIHVzZSBjYXNlcy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtPbmUgdXNlIGNhc2UgdGhhdCBvY2N1 cnMgdG8gbWUgdGhhdCBtaWdodCBsZWFkIGluIHRoZSBkaXJlY3Rpb24gSSB0aGluaw0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7eW91J3JlIGludGVyZXN0ZWQg aW4gaXMgSSd2ZSBub3Qgc2VlbiBzdWZmaWNpZW50IGRlc2NyaXB0aW9uIG9mIGhvdyB0bw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7YXNzb2NpYXRlICZxdW90 O3NlcnZpY2VzJnF1b3Q7IHdpdGggdGVsZXBob25lIG51bWJlcnMuJm5ic3A7IEZvciBleGFtcGxl LCBtYW55IHBlb3BsZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7YXJlIG1lbWJlcnMgb2YgbW9yZSB0aGFuIG9uZSBzb2NpYWwgbmV0d29ya2luZyBhcHBsaWNh dGlvbiwgYW5kIHNvbWUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0O3NvY2lhbCBuZXR3b3JrIGFwcGxpY2F0aW9ucyBvZmZlciBzZXJ2aWNlcyB3aGljaCBvdmVy bGFwIHdpdGgNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O3Ry YWRpdGlvbmFsIHRlbGVjb21tdW5pY2F0aW9ucyBhbmQgdGhlcmVmb3JlIGNvdWxkIGJlbmVmaXQg ZnJvbQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7YXNzb2Nh dGlvbiB3aXRoIG51bWJlcl91c2VyIHRlbGVwaG9uZSBudW1iZXJzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0O0kgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGV4cGxv cmUgaG93IHRob3NlIHNlcnZpY2VzIGNvdWxkIGJlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDtkZWZpbmVkIHN5bnRhY3RpY2FsbHksIG1hbmFnZWQsIGFuZCBk aXNjb3ZlcmVkLiZuYnNwOyBCdXQgbWF5YmUgdGhhdCdzIGp1c3QNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O21lLiZuYnNwOyBNYXliZSBvdGhlcnMgZmluZCB0 aGF0IHVzZWxlc3MgYW5kL29yIG9iamVjdGlvbmFibGUuJm5ic3A7IEl0IGRvZXMgc2VlbQ0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7bGlrZSB0aGUgZGlyZWN0 aW9uIHlvdSB3ZXJlIHdhbnRpbmcgdGhpbmdzIHRvIGdvIGluIHRlcm1zIG9mIGdpdmluZw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7bnVtYmVyX3VzZXJzIGNv bnRyb2wgb3ZlciBzZXJ2aWNlIHByb3ZpZGVyIGFzc29jaWF0aW9ucyB3aXRoIHRoZWlyIHRlbGVw aG9uZSBudW1iZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 QW5kIGl0IHNlZW1zIGRpcmVjdGlvbmFsbHkgY29ycmVjdCBpbiB0ZXJtcyBvZiBhZGRyZXNzaW5n IHRoZSBpbnRlcmVzdHMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0O29mIHVzZXJzIGFuZCBub24tdHJhZGl0aW9uYWwgY29tbXVuaWNhdGlvbnMgc2VydmljZSBw cm92aWRlcnMgZm9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDtzZXJ2aWNlIHByb3ZpZGVyIG1hc2gtdXBzIGFzc29jaWF0ZWQgd2l0aCBhIHRlbGVwaG9uZSBu dW1iZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7SSBrbm93IEkgaGF2 ZW4ndCBkaXJlY3RseSBhbnN3ZXJlZCB5b3VyIHF1ZXN0aW9uIGFib3V0IHNwZWNpZmljDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtzdWdnZXN0ZWQgY2hhbmdl cyB0byB0aGUgdGV4dCBpbiB0aGUgY2hhcnRlci4mbmJzcDsgSSB3b3VsZCBsaWtlIHRvIGhlYXIN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O21vcmUgZnJvbSBv dGhlcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7QmVzdCByZWdhcmRz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1BpZXJjZSBHb3JtYW48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtDb3JlIE5ldHdvcmsgUGxhbm5pbmc8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtPOiA5MTMtNDM5LTQz Njg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8YSBocmVmPSJt YWlsdG86cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDstLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O0Zyb206 IE1vZGVybiBbPGEgaHJlZj0ibWFpbHRvOm1vZGVybi1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOm1vZGVy bi1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBPZiBTdGV2ZQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7RG9ub3ZhbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1NlbnQ6IE1heSAwNCwgMjAxNSAxOjMw IFBNPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7VG86IDxhIGhy ZWY9Im1haWx0bzptb2Rlcm5AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5tb2Rlcm5AaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1N1YmplY3Q6IFJlOiBbTW9kZXJu XSBNT0RFUk4gd2lsbCBzb2x2ZSBubyBwcm9ibGVtcyAob3Igd2lsbCB0aGUgSUVURg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7dGFrZSBvdmVyIHRoZSB3b3Js ZD8pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7UGllcmNlLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1NlZSBteSBjb21tZW50cyBpbmxpbmUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7UmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtTdGV2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0O09uIDUvNC8xNSAxMTozMiBBTSwgR29ybWFuLCBQaWVyY2UgQSBbQ1RPXSB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IElm IHdlIGNhbiBhZ3JlZSB3ZSBlbGltaW5hdGUgdGhlIGNoYXJ0ZXIgbGFuZ3VhZ2UgdGhhdCBpbXBs aWVzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Y3Jl YXRpbmcgYSBmcmFtZXdvcmsgd2hpY2ggc3VwcGxhbnRzIHRoZSBhdXRob3JpdHkgb2YgdGhlIE5B TkMgKGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2xl YXN0KSBhbmQgd2hpY2ggYXNzdW1lcyBhIHJlcGxhY2VtZW50IG9mIHRoZSBOUEFDIGFuZCBMRVJH IGRhdGFiYXNlcywNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDt3ZSB3aWxsIGhhdmUgbWFkZSBwcm9ncmVzcyAoSU1ITykuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7U1JEJmd0OyBUaGlzIHNob3VsZCBiZSBlYXN5IHRv IGRvLCBhcyB0aGVyZSBpcyBubyBpbnRlbnQgYW5kLCBldmVuIGlmDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtTUkQmZ3Q7IHRoZXJlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7d2VyZSBpbnRlbnQsIHRoZXJlIGlzIG5vIGFi aWxpdHkgZm9yIHRoZSBNT0RFUk4gZ3JvdXAgdG8gdGFrZSBhbnlvbmUncw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7YXV0aG9yaXR5IG9yIHJlcGxhY2UgYW55 b25lJ3MgZGF0YWJhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7U1JE Jmd0OyBJcyB0aGUgcHJvYmxlbSB3aXRoIHRoZSB3b3JkIGZyYW1ld29yayBpbiB0aGUgc2Vjb25k IHBhcmFncmFwaD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtX b3VsZCBjYWxsaW5nIGl0IGFuICZxdW90O2FyY2hpdGVjdHVyYWwgZnJhbWV3b3JrJnF1b3Q7IGhl bHA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgQmV5b25k IHN0cmlraW5nIG9iamVjdGlvbmFibGUgbGFuZ3VhZ2UsIHRoZSByZWFzb24gZm9yIERhdmlkIEhv bG1lcyc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7cG9z dHMgZm9sbG93aW5nIG1pbmUgbGFzdCB3ZWVrIHdhcyB0byB0cnkgdG8gaW1wcm92ZSB0aGUgZm9j dXMgb2YgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7d29yayBmb3IgTU9ERVJOLiZuYnNwOyBXZSBkbyB0aGluayBpdCBpcyBhIGJhZCBpZGVhIHRv IGlnbm9yZSB0aGF0IG51bWJlcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0O2FkbWluaXN0cmF0aW9uIGFuZCByb3V0aW5nIHNvbHV0aW9ucyBuZWVkIHRv IGV2b2x2ZS4mbmJzcDsgQW5kIHdlJ3JlIG5vdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2FnYWluc3QgdGhlIE1PREVSTiB3b3JraW5nIGdyb3VwIGlk ZW50aWZ5aW5nIHByb2JsZW1zLiZuYnNwOyBJbiBmYWN0IHdlJ3JlDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7aW4gZmF2b3Igb2YgaXQuJm5ic3A7IEl0 cyB3aGF0IHRvIGRvIHBhc3QgdGhhdCB3aGVyZSB3ZSdyZSBzdHJ1Z2dsaW5nLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1NSRCZndDsgSSBzaGFyZSB0aGUgZGVz aXJlIHRvIGZvY3VzIHRoZSB3b3JrLiAmbmJzcDtJIHRoaW5rIHRoZSByZXZpc2lvbnMgb2YNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1NSRCZndDsgdGhlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Y2hhcnRlciBoYXZlIG1v dmVkIGluIHRoaXMgZGlyZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7IFRoZSB0aGluZyBJJ20gY29uY2VybmVkIGFib3V0IGlzIGEgcmVwZWF0IG9m IHRoZSBlMTY0LmFycGEgZmlhc2NvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7d2hpY2ggc3VjY2VlZGVkIGluIGRlZmluaW5nIGEgZ2xvYmFsIHNjaGVt YSBhbmQgcHJvdG9jb2wgZm9yIG1hbmFnaW5nDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7bnVtYmVycyBhbmQgcmVzb2x2aW5nIHRoZW0gZm9yIHJvdXRp bmcgYW5kIHdoaWNoIGZhaWxlZCB1dHRlcmx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0O1NSRCZndDsgV2UgZmFpbCBpZiB3ZSBkb24ndCBsZWFybiBmcm9tIG91 ciBtaXN0YWtlcy4mbmJzcDsgSSdtIGNvbmZpZGVudCB3ZQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7U1JEJmd0OyB3aWxsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7aGF2ZSBlbm91Z2ggaW52b2x2ZW1lbnQgaW4gdGhlIGdy b3VwIHRvIGtlZXAgdXMgcG9pbnRlZCBpbiB0aGUgcmlnaHQNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O2RpcmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IFBpZXJjZSBHb3JtYW48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IENvcmUgTmV0d29yayBQbGFubmluZzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgTzogOTEzLTQz OS00MzY4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cGllcmNlLmdvcm1hbkBzcHJpbnQu Y29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7IEZyb206IE1vZGVybiBbPGEgaHJlZj0ibWFpbHRvOm1vZGVy bi1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+bWFpbHRvOm1vZGVybi1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5d IE9uIEJlaGFsZiBPZiBTdGV2ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyBEb25vdmFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyBTZW50OiBNYXkgMDEsIDIwMTUgNDoyNCBQTTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzptb2Rl cm5AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5tb2Rlcm5AaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgU3ViamVjdDogW01vZGVybl0gTU9ERVJOIHdpbGwg c29sdmUgbm8gcHJvYmxlbXMgKG9yIHdpbGwgdGhlIElFVEYNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgdGFrZSBvdmVyIHRoZSB3b3JsZD8pPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgVGhlIHF1ZXN0aW9uIG9m IHdoYXQgcHJvYmxlbShzKSBNT0RFUk4gd2lsbCBhZGRyZXNzIGhhcyBiZWVuIGFza2VkLA0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O211bHRpcGxlIHRp bWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IFRoZSBz aG9ydCBhbnN3ZXIgaXMgdGhhdCwgaW4gYW4gb2YgaXRzZWxmLCBNT0RFUk4gd2lsbCBzb2x2ZSBu bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O3Byb2Js ZW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IFRoaXMg aXNuJ3QgdG8gc2F5IHRoZXJlIGFyZW4ndCBwcm9ibGVtcyB3aXRoIGV4aXN0aW5nIG1lY2hhbmlz bXMuIEl0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 aXMgdG8gc2F5IHRoYXQgYWxsIE1PREVSTiBjYW4gZG8gaXMgdG8gc3BlY2lmeSBwcm90b2NvbHMg dGhhdCBjYW4gdGhlbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0O2JlIHBhcnQgb2YgYW4gb3ZlcmFsbCBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyBwcm9i bGVtcyB0aGF0IGV4aXN0IHdpdGgNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDt0aG9zZSBleGlzdGluZyBtZWNoYW5pc21zLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IFRoZXJlIGlzIGEgYnJpZWYgY2FwdHVyZSBv ZiB0aGVzZSBwcm9ibGVtcyBpbiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgdGhlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBjaGFydGVyOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7ICZxdW90O0Egc2FtcGxlIG9mIHByb2JsZW1z IHdpdGggZXhpc3RpbmcgbWVjaGFuaXNtcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IC0gbGFjayBvZiBmbGV4aWJpbGl0eSAoZm9yIGV4YW1w bGUsIGl0IGNhbiBiZSBkaWZmaWN1bHQgdG8gYWRkIGZpZWxkcw0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O3dpdGhvdXQgYSB2ZXJ5IGVsYWJvcmF0ZSBh bmQgbGVuZ3RoeSBwcm9jZXNzIHR5cGljYWxseSBzcGFubmluZyB5ZWFycyk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IC0gbGFjayBvZiBkaXN0cmlidXRp b24gKGZvciBleGFtcGxlLCBpdCBpcyBoYXJkIG9yIGltcG9zc2libGUgdG8gaGF2ZQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O21vcmUgdGhhbiBvbmUg YWRtaW5pc3RyYXRvciBmb3IgZWFjaCBkYXRhYmFzZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IC0gY29tcGxleGl0eSAobGVhZGluZywgZm9yIGV4YW1w bGUsIHRvIGEgZmFpciBhbW91bnQgb2YgcnVyYWwgY2FsbA0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2NvbXBsZXRpb24gcHJvYmxlbXMgd2hpY2ggYXJl bid0IGhlbHBlZCBieSBzbWFsbCBwcm92aWRlcnMgc3RydWdnbGluZw0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O3RvIGtlZXAgbnVtYmVycyBzdHJhaWdo dCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IC0gZGlm ZmljdWx0eSBvZiBhZG9wdGluZyBtb3JlIG1vZGVybiBhbGxvY2F0aW9uIChlLmcuLCAmcXVvdDti bG9ja3MmcXVvdDsgb2YgMSkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDthbmQgcG9ydGluZyBtZWNoYW5pc21zJnF1b3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgV2lsbCBNT0RFUk4gc29sdmUgdGhlc2UgcHJv YmxlbXM/IE5vLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 IFdpbGwgTU9ERVJOIG1ha2UgaXQgcG9zc2libGUgZm9yIHRoZXNlIHByb2JsZW1zIHRvIGJlIGFk ZHJlc3NlZCBhcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0O3BhcnQgb2YgbmV3IG51bWJlciBtYW5hZ2VtZW50IHBvbGljaWVzIHRvIGJlIGVuYWN0ZWQg YnkgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 YXBwcm9wcmlhdGUgYXV0aG9yaXRpZXM/Jm5ic3A7IFRoYXQsIEkgYmVsaWV2ZSwgaXMgdGhlIGdv YWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgV2lsbCBN T0RFUk4gZm9yY2UgYW55IG9mIHRoZXNlIG5ldyBudW1iZXIgbWFuYWdlbWVudCBwb2xpY2llcyB0 byBiZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2Vu YWN0ZWQuJm5ic3A7IE5vLiZuYnNwOyBUaGUgSUVURiBpcyBub3QgYSBwb2xpY3kgc2V0dGluZyBi b2R5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IEknbSBv ayB3aXRoIGhhdmluZyBhIG1vcmUgZGV0YWlsZWQgYXJ0aWN1bGF0aW9uIG9mIHRoZSBwcm9ibGVt DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7c3RhdGVt ZW50IGFzIHBhcnQgb2YgdGhlIGRlbGl2ZXJhYmxlcyBvZiB0aGUgTU9ERVJOIHdvcmtpbmcgZ3Jv dXAuIEkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtk b24ndCBzZWUgdGhlIGJlbmVmaXQgb2YgbWFraW5nIHRoYXQgdGhlIG9ubHkgZGVsaXZlcmFibGUg YW5kIGZvcmNpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDtyZWNoYXJ0ZXJpbmcgYWZ0ZXIgdGhhdCBkb2N1bWVudCBpcyBmaW5pc2hlZC4mbmJzcDsg TGV0J3MgaW5zdGVhZCBhZ3JlZSB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0O3NodXQgdGhlIHdvcmtpbmcgZ3JvdXAgZG93biBpZiB0aGVyZSBpcyBj b25zZW5zdXMgdGhhdCBpdCBpcyBnb2luZw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0O25vd2hlcmUgKHdoaWNoIEknbSBzdXJlIHRoZSBBRHMgd2lsbCBk byBhbnl3YXkpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsg U3RldmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgTW9kZXJuIG1haWxpbmcgbGlzdDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOk1vZGVybkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPk1vZGVybkBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0O21hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDtfbGlzdGluZm9fbW9kZXJuJmFtcDtkPUF3SUNBZyZhbXA7Yz1NT3B0TmxWdElFVGVE QUxDX2xVTHJ3JmFtcDtyPTRLbG0zMmlCN0h1ZnZlZUlEPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2NMZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDt4dFoxb29OY2ZwMDFJWUlhVnFzT1JqSSZhbXA7bT1PN1RaNFlN NkJvWFh5RGhWeFQ4ajVWRzQ2WDZXbFZxdnRJQngteFREZjd3JmFtcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7cz1oIHRJTV9RZU9JM2ZIT1pTRVVObkgt M0RZeGlZTVJFYnA1UDhSUGhUakdxdyZhbXA7ZT08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IFRoaXMgZS1tYWlsIG1h eSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3INCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDt0aGUgc29sZSB1 c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4g SWYNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDt5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVy IGFuZA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2Rl bGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyBNb2Rlcm4gbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86TW9kZXJuQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+TW9kZXJuQGlldGYu b3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7bWFuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O19saXN0aW5mb19tb2Rlcm4mYW1wO2Q9 QXdJQ0FnJmFtcDtjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmYW1wO3I9NEtsbTMyaUI3SHVmdmVl SUQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Y0xlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O3h0WjFvb05jZnAw MUlZSWFWcXNPUmpJJmFtcDttPU83VFo0WU02Qm9YWHlEaFZ4VDhqNVZHNDZYNldsVnF2dElCeC14 VERmN3cmYW1wOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDtzPWggdElNX1FlT0kzZkhPWlNFVU5uSC0zRFl4aVlNUkVicDVQOFJQaFRqR3F3JmFtcDtlPTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0O01vZGVybiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8YSBocmVmPSJtYWlsdG86TW9kZXJuQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+TW9kZXJuQGll dGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDthbl88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtsaXN0aW5mb19tb2Rlcm4mYW1wO2Q9QXdJQ0Fn JmFtcDtjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmYW1wO3I9NEtsbTMyaUI3SHVmdmVlSURjTDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O2V4dDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1oxb29OY2ZwMDFJWUlhVnFzT1JqSSZh bXA7bT1PN1RaNFlNNkJvWFh5RGhWeFQ4ajVWRzQ2WDZXbFZxdnRJQngteFREZjd3JmFtcDtzPWg8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDt0SU0gX1FlT0kzZkhP WlNFVU5uSC0zRFl4aVlNUkVicDVQOFJQaFRqR3F3JmFtcDtlPTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7VGhpcyBlLW1haWwgbWF5IGNvbnRhaW4g U3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O3NvbGUgdXNlIG9mIHRoZSByZWNp cGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7YXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O2FsbCBjb3BpZXMgb2YgdGhl IG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtNb2Rlcm4gbWFpbGluZyBsaXN0PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PGEgaHJlZj0ibWFpbHRvOk1vZGVybkBp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPk1vZGVybkBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG0iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbTwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7YW5fPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7bGlzdGluZm9fbW9kZXJu JmFtcDtkPUF3SUNBZyZhbXA7Yz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3JmFtcDtyPTRLbG0zMmlC N0h1ZnZlZUlEY0w8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtl eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtaMW9vTmNmcDAx SVlJYVZxc09SakkmYW1wO209TzdUWjRZTTZCb1hYeURoVnhUOGo1Vkc0Nlg2V2xWcXZ0SUJ4LXhU RGY3dyZhbXA7cz1oPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 dElNIF9RZU9JM2ZIT1pTRVVObkgtM0RZeGlZTVJFYnA1UDhSUGhUakdxdyZhbXA7ZT08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBp ZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1vZGVybiBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Im1haWx0bzpNb2Rl cm5AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5Nb2Rlcm5AaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tb2Rlcm4iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybjwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwv c3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5 Ij48YnI+DQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3Jt YXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkg dXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGll cyBvZiB0aGUgbWVzc2FnZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJyPg0KPGhy Pg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpUaGlzIGUt bWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBp cyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2Fn ZS48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_-- --_004_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Tue, 12 May 2015 22:10:45 GMT"; modification-date="Tue, 12 May 2015 22:10:45 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAU8AAAA8CAYAAADmDDgpAAAT+klEQVR42uydCWyU55nHU2krVRtV mkqrXVW7ap22q12ttqvpVlXVNGldqWk4kmLCEcAcA76wx/PF5KIhJEwIBBIIDEm4CZlwXwnmCkc4 hvtwTIbLHMHGYDAYbBgwYGzAs/8/+l766t05GNsxE/tB+on53pnvnO/7zfM+z/t9fgT/AoIgCELC PBIWBEEQEuYRryAIgpAg4XBYEARBSJB2fwAEQRBEnoIgCCJPQRAEkacgCILIUxAEob3T7g+AIAiC yFMQBEHk+fC4XfGDFOBo78dBEASRZ0JQnCAAvO39WAiCIPJMVKBOEAJBkNLej4cgCCLPRASaCsK2 RJ3t/XgIgiDyTESgBUqgEoEKgiDyTEyghbZAg8ChtfuBq70fH0EQeQqxCkjltkD9WruLbd+qQM92 +R74B/AD8Cj4IXCAfwL/DH4M/hX8BPwM/AL8B/gv8EvgBP8LfgN+B34P/gBSwZ/BX0BH0Bk8C7qC bqAn6AX6gv7ABTJANsgFbuABL4CXwCtgKBgG3gAjwFtgFBgD3gXjwPtgIvgQTAZTwXQwC8wGfjAH zAcLwWKwFHwOCsFKsBp8AdaDL8EmsBlsBdvBTrAb7AVFoBjsB0FwCBwGJeAYOAFOglJwCpwGFeAs qATnQRW4CKpBDbgCQuAaqAU3wE1QB26BetAAboM74C5otAnbNLLd5o79+Xp7/jpw015urb2eq/Z6 L9vbcQlU2dtXaW9vBTht70epvV/H7f0ssff7IAjax6PYPj57wC6w0z5+Aft4bgQbwFqwBqwCK+zv YhlYAhaBBWAu+BR8Aj4GM8A0MNn+rn1gAhhvnwtj7HNjpH2uvGGfO0Ptc+kl+9zyADcYDLLBIOCy z8l0+xztYZ+zafY53Al0AE+BP4E/gifA4+C34NfgV+B/wH+D/wT/Dn4OUsC/2dfVv9jX2Y/s6+5R +zr8PvheuxdjggWksE2akqreJvIUeYo8RZ5C/PynQ3Xp9TaRp8hT5CnyFCILNKC674ZQicuIVL0i T5GnyFPkKfy9qx4CYVuQKZo8CyPkQwPAIfIUeYo8RZ7tHuY3lRg5rRWTQtpnvJpUAyJPkafIU+Qp AAjRZ4sxFfg1UaYY8lS4RJ4iT5GnyLPdow1fKlSRqE1qFHkWijxFniJPkWer8thjP0sBqcCRpLdv PqFJssAoLCkCxnw+4BB5ijxFnm1MnhBVGvCCgEah3ZbSiuJMA2GbUEuv25ayD7iaKFAv8Gt5T28s eRrvlQOnyFPkKfJsA/KERJygHIRjkNqK8iw01l3QgssOaMv1NnP40gJDniFDnj4jWlWEgEPk+eDy XPCxFVw42zrQ0vI8V5xRMeOD/NDMDz1XwTWR57cnzzWLrPnTJuWvbCvyVOIMgXAcHK0ozwJj3c4k lKcTLDDGf4YNXHrUaVCQjPJ847XsTx9//Ilw/349i7Oz0nfw9cg3cxa3tDw/merZ8t6ovP3g69Ld OcuUPMePyTv0/pi8wxPGuo+U7claR3muWmjt43aQRbOtQy0pz33r889zuYrmynP2FM9d0EiUPC8E B4axv/dge3uV56gRg7cP6P/86bYhT1MmwOyiM+JUkV9roqUP0jidZPJUAn1Sdc9VdGmQorWbeJNN nri4vVmZ6VspkezM9O3Pde1yRskTEdqLLSnPjEF9KpWwNi73rFPy1EW2daW1jfK8XNJvbb++Pa92 7tTp9oHN7l3JLE9jWY0kuMkd1ttFnm1AnpRkpO5xspGs8iSaPNMMOQbt94NR5Jmi35UEHA9bnvoF brLEb1F+bohgxPC/Za19c1j2+rFv566E4CZ5h+dsemt4zuapE/OXK3lePOCaOPFd96bR3sE7wa5Z H+Wvrz48YAYvLERfmyHmWrXsoS9nnhz3Tt4BRJ0H9XUOezXz9PxZ1v6tKz1cRtnrQ7PObl/tKSrf m7Xjg3Husg/Hu09hu46dKcos+uh99xlQsfRTq1SX59mvMkqwXVVTffkX5860LhzdnnsKXcea6ZPy LxfOsy6a8qzcP6hq5keeWnAdqYLaa8f71OjyPP/1wOsfT/bUg4bZkz23sW0NSp6MOvVlMdJc9InV iOMU1tsZfX69yX1XyZPL4LIIl4t13FDyXL3QuoFjVwduVu4feLl4g/sKt0/J8+rxPudWzLeqsT9X 5s20qvEjV055ni3OKMU+XyrZlnvSlOfkCe5zu7/wlCh5rltqleBYloNTB7fk7dXlyXQJjz+2dxN6 AyU4/pvZMyjbk7NCl2fNkf5z3x2VW7xhmbVSyRPfzap33srdze//2PbB0yLJc84Ma96IYdlfgg2f zbGmKHm+PjRzzeJPrAmmPF8eMuizT6dZI5NBnqlNyWuy0AK8NinAAQpAQMPH9kgRpUJLGxTa87g0 qXsVMdbtVG1qGTZ+4DT200uM3G5AX0+Tc58g0hhPEiPqVOIMKdlyOpnliQt4utn+9NNP16nXiA5P UZ47VntmdujQ4Zb52Y4dOtbvXZe/eNDA3ufstrggdXAJEj6upieNc5/EBfyVmu7Ro2sdI1J9HqQC LlASu9d6TnTu3OmO/t4zz3S+LzhP/oA6U57PPvtMoz6NSPw2BHqZ8oTIbprbZ0fpjbUn+tRHei8n u6/ZpgTKeRqGvDCwMdL7yA/WUZ4Fluv+vr3gcTXoETKEVMX9IdyX53s+d5uv8QNBgR7ja/yoXdHl CbmVcn7KM3QsfZ9rQK/rnM7N6XcFYqvla0jrsJIntr+aUT/bu3VLu7F/o3vDc891uf63VzLLdHlC aNv4mW925czHj+Ss3r26XeK0y9Wrotfz3S7yNbavSpenle/6mu1903uW4nus5Gv+MFOevXt3P4H1 VOjyxDEZzs8kqzy9TYje0kBQTRuEzHyl8X6aMe2KtF2x1m1Mm6Rqwg7HoxkD5wOg0CgI/VSJ0SBo itOYz/kwc57q4pwyIX8S/8eJf0wVjCCWGl2a6oTX5Vl1wPWuLk6+1qcpTkQZBylS1danT/caSOpC VkZ6lbG8EKKW0mjyjAXl2bNH1/vroETz8/rf4Ot48qQw9TZGfcVf5tfqbbi4G/VpRG13TBG+WDAo jO3nD0DYbF+7xLqLiPRurGWe2JlzXZenmV7Ad3MnMyO9AdFnheq2Q2rXIakGyhORfA33W5cnegnV PC7sto94Pfsi3z8cyN2vuu3Y13vH+tTerICSZ6eOHRuYQlHddkae/EzNkX6LlTz5HeL4UtrT0Cs5 wO93z7r8+arbjmLf55xHyXPbKs9UTiNaXa267e7c/kU8ryhP9UON+cYreTKVhO29lCzddkcEiXjZ noA84xWbymPIM2TKLiF5xh8hEGwFeRYALyjXI0v9DiSzym6I0wTtjz7W2vLEhb84XuSpT6N7N5on PLtcujxxwa7TPwfxbQZbDCnMSyTnGUuejDrZbcd2VBmRW5k+bXdfS9B1r4olz+M7BvPiPM9uu2qj wNCNbNAFi67srbFv593RxZdozlNv47KwzHouW5P2LV2efA/H4sbKBVaI28m2LSusaj3nif05x3ZE +GcQgZbx9edzPBVKnpSlHZnv4WsIvNLMeXIe33vub5Q8+QOm5zwhzc8oVKZaKM+Tu3OWcp5lc6wN lCfFicJj0Mx5Ds7ue0LJEz+yY7Afs/WcJ1NBXI7KefLHGvPsojyRfsl76qm/3MT3PDeZCka+KBGj HzhjyNP8fJomZL8ZYRryNOctUAPiE5BnxFytue5WyHmmgrGGIJ+JIk5nHHEqvMksT0QZ36iC0fK5 1nRdniPfyAnEiwrRdVzRUvLMHdwvpApGqs3u2lWo1wNdvetUwYhSiSZPRnGqYMTcoi4tJbFYJCJP 5jzjLW/MyNwGfb2Iwq6rgtFXG9zV0eZT8uT+Mgod+nLGVcpTddmPbM09QnlGm9eUJ47/MbNgxG47 u++UJ1IDR5jDVgUj+3xZE69ghB+yBThnysx1K3m+/WbOEk5jX18dNzpvFl/jhzIrmeTpMMZVmgRA ShyBUV6xIlpfVHmagk5cnua6na0sTwf4SBPfa6A8ijhdnI7PP3ZtbXnuXOPJhdACaphS17S/nuZr XCQr2HUyI08UNYabkacpT+TTzqiCEQsHiK72gn2MPFtTnuTqsfSj8SJPdoMjyRP5u7u6xCC126pg ZHOHNEeeesEI1BPmWPX1YptCpjwRvV0uWu+u4n6ASnAO4qzA/p7g/qIgc97e/0OQXA1ykDdVtZ3t jNjx3R8EQeSq9+PYFoMidttjyZMFI84/Z7q1g5EmilB7dHliXzaa8kQBsEjJE9/DQn6OxUb+AKMn 844ZeaL4NYTRJs9Bjvxgtz0p7zDS8odxc5dmt/0BotNAFHn62ZaYPOOvuxXlaT4wpBz4miNO4H9Y Oc+83P5rePK+8uKgz5U8UW19T+U8eSJr0dhlJvrNnCcqvIVqOq3LX69ePDjgAxQgVjDvaUaees5z 03LPesrTrLZDPFuaIk9VLEo058lKNsRUo+c90WWvh/zr/z6ddZtDiii7WJEnq+zo0lKeZhTPsZ93 cAzvt32x2GKVvW6INfC+VDGioD6aPDkqQMlT77az2o7RBNWstlOe6O4etyV3Tv2oKHn26N71FuVp dttxjEuRk9wbS55gAfPUKnfNaruSJ9teGjLoqCnPLl2eDSl5QoRHsf7zsbrtYDD2f6M671gwSkZ5 mpGbP0bu0hRQYZTl+B5AngXNlKc/SeSpBsEPjyJO/wOK0wccD0ueiKim4KRfhojn9VdfyliOIUSF uAg9Sp64iObqElASNavtKEhcUG0mkPI1jvNEseKQ+R7lCSFfMavtTZUnhr6U29Nxq+0mRgRci2FC V81KvCHKu5QnpGAWjbhfEavtIGbXHUWqG9HkCSqHvZpVx/3hUCXKE9X3Co97wE22qcgTHEYh5n7+ tqIo45CSJ4ZSnbKLXaevHO274/S+zF3oGZxh24PIE0O9Avws0gLf6OM82buwv6utlw65JmO7ZjDf qReMcG7tZnEIxapxlCe2xc9pU544Bq+xjZFnsj8YxBwDGjQLOjEFlLg8U5spT2+SyDMEpoKQIc4n VRU+DuUgNZlvz+QgeURMPkRdX6BifhD5wcMc54mxlUtMeWKM53h1segg93iWQ5UoTwxnuVehNeWJ i2UdixHNleem5dZJChSjBi4w54eL9RrHeSJFcDaWPDF8pt7I/dWpcZ5IN9RiRMA94ZnFHg5Vojwx VIcRpSlPVtf/nzz5eXb3+Xmz4q+GKsWSJ6rslcgj3tDn5XAlNVRJyZMFI74Hidaag+Q5PlYf6sXX aqhSPHmit7DBTrusNQfJs2DE9/QUDrvtesGIkac+eqN7967nTHnivCtgG3OeSS9PsyvfDHkG2oM8 KT1bfjsiiDP4oNFmst/bjq72aP1EhzAKKU99nCejCf0OI3TZfZDGIrAEEciUSPe2I19XyJwnKriL 9HvbAyutAHOeTX0wCIoiJfrFqwbJQy5KzLxz6lqkB4Ogkl3NnCfGd16KdIcRutcc73iLRLu3HV31 RqLf2w7B3mtDV968w4jLqge3IOi6RO8w4lAl/ggw8mzqHUYq55nIHUb4vkvT+/S4HOsOI373jDyj PRgEIww+ZM4z2h1GiK5XsdvOavt3TZ7OZsgzpH+mDcvTB6bp4zhBp3gVdTUo/rv0YBBEeVErtJQo hDUxmZ6qxAKJvo1m9x1RzWl5qlLTbs/Ej90yVTD6Np+qhO+pGjcHfPmdep5nlPGRKZEFFP/BHm1Y npmGEPPiSDMECr6rj6RDN3Yehyoh4jjJghFBt3gnCiCjk/GRdOiynmHOj7BgRDDI+wqitTJ5JF3T 5Yl85zYWjCDRhd+WPNcv9YzCSIfjHKqUjPJUuUmvLSwncNiv/WZlPFbRxhSn2WVPUnmWgxS1z00Q Z4oWYfqBL14lXR6GLM/zlOd5trGnKsUhBBwJzqPmS0kyefpb4g4jSlDLaY4FgThd9FT5MxwiT5Fn +5JnADgSmcccXJ9k8nS2kDz9IASGxLrVErjkbxiJPEWebVOeacAX5U9vOB+kkq7N7zfni/VUpUhy TfCpSqnx1hGtEGbssw94EywSBcG4GNL0Aof8ATiR5/+1d8cqbYVxGMaHikMQMthCEZR2EaSIAYvN olSXdNIShEDoYOkgLQ5aRBQlCKKIQ4sQKliEQEtQUAxiJbjoFYiX0EsIvYK+wqN8HEhOBqfkHX6L aAzf+X+PJzmR43j6BnAxZ3/tgf8UKsufuPc1fd92x9PxdDwdT+EC0YL8rRPNhzNpx9PxdDwdT8cT vBRvGE3H0/F0PB1PxxOccV43iqbj6Xg6no6n4xng3kS1uGj+u0mm7jiejqfj6XgCMVe8Ww2f46w0 c/WceNbk9hHj+UQ6OXAJ6ZIkB7VbnnKgewhpr7wIYtrPgLxiWIaI6jBRfSNphmuUuI7LBAOYkXdB YKeIbFamJccQ5yOx/RgEd5bofpE5Nsa8fI3Ed5lNtCaFIMIbsilbsh2J8TeCvMtGLcqPIMz78lMO 2NwlNvov+S1lHAaxPpYTQnF6H26cE5MLwlIl5JfEXBQeoo4rXOOKr0Pfr5/DJY9X5fEv+H3nBOyM iJ3y/E7kmOd9JASNqBE2KfEH6oD12Gd99ohckfXble9B7HZkm+BtygbRW5cC4VuVFY7fkixybOc5 1nNE8LPMMhOfIjH8IHlmKcdsZZm1yUgYM8zmhLyVsSCQaRmR10RySAaZ/QHpD2L5UvoIZo88l2fS zf5KEs4E+69TOu7jafG31qjJbTOf0ySeM5Jq97Uza2VtvwANopmSipTEITQzx7PJl+nv230dzMzx NDNzPM3MHE8zM8fTzMzxNDOzOv4DIDV//HSVjucAAAAASUVORK5CYII= --_004_8ee344e2ec414f728337c9696a33cc4bPLSWE13M08adsprintcom_-- From nobody Wed May 13 07:11: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 ECECA1B2C5D for ; Wed, 13 May 2015 07:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 h90gYb4K5rmp for ; Wed, 13 May 2015 07:11:18 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 406D31B2C55 for ; Wed, 13 May 2015 07:11:18 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:56472 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YsXNQ-0003Em-PZ for modern@ietf.org; Wed, 13 May 2015 07:11:17 -0700 Message-ID: <55535B80.1080809@usdonovans.com> Date: Wed, 13 May 2015 09:11:12 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> <90f7e39770be4118aa5ed9ca31f72b20@PLSWE13M08.ad.sprint.com> <09ec73f2cd0f4d228e9fe15ddd2b3b4b@PLSWE13M08.ad.sprint.com> <555251DF.90701@usdonovans.com> <8ee344e2ec414f728337c9696a33cc4b@PLSWE13M08.ad.sprint.com> In-Reply-To: <8ee344e2ec414f728337c9696a33cc4b@PLSWE13M08.ad.sprint.com> Content-Type: multipart/alternative; boundary="------------080203050205060405000903" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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, 13 May 2015 14:11:25 -0000 This is a multi-part message in MIME format. --------------080203050205060405000903 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Pierce, Protocol work doesn't necessarily mean new protocols will be developed. It could also result in a recommendation to use or build on existing protocols. To your question: "Today those number management authorities also determine the protocol mechanisms for enrolling (i.e., assigning) and managing telephone numbers. What reason is there to believe they will spontaneously adopt what MODERN developed?" Nothing happens spontaneously but if we do our work well then we give the authorities another option, one that addresses the shortcomings in the existing mechanisms. To your point: "I’m not very interested in discussing YAPP (Yet Another Provisioning Protocol), but very interested to discuss association of new non-traditional services and their identifiers and parameters with telephone numbers." If we end up creating a new set of protocols, hopefully it will be ABPP (A Better Provisioning Protocol) :-). I believe the latter part of your statement is one of the motivators for the proposed working group. I propose the following, which keeps the protocol work. Old (from the "revised revised" email): The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. It will also define protocol mechanisms for acquiring and resolving TNs. The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the enrollment data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS. New: The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment. The working group will also define protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs. The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the managed data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS. Regards, Steve On 5/12/15 5:10 PM, Gorman, Pierce A [CTO] wrote: > > Thanks Steve. > > “SRD> …I'm not sure we need to define the concepts of SERVICE, > SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with > different terms and/or roles.” > > I’m not sure how you want to word this and I’m not married to what I > suggested. I was implying information in a data model. I picked > those three fields because I thought they are fundamentally what has > been described to associate with one or more telephone numbers > (assuming we can agree what a TN is). > > How about we remove any reference to what information is being > associated with telephone numbers like this… > > NEW-ER #0: > > The working group will define a an information management framework > for the roles and functions involved in managing and resolving TNs > associating SERVICE, SERVICE_PROVIDER, and NUMBER_USERinformation with > one or more TNs in an IP environment. This includes a protocol > mechanism for acquiring TNs, which will provide an enrollment process > for the individuals and entities that use and manage TNs. TNs may > either be managed in a hierarchical tree, or in a distributed > peer-to-peer architecture. Privacy of the enrollment managed data and > security of the resource will be primary considerations. > > “SRD> I'm mostly okay with your changes other then removing the > wording on the protocol work. I believe there is enough support for > doing the protocol work that this should remain in the charter.” > > Well, if there’s enough support you can ignore me. J The heartburn I > have with leaving the protocol work in there is I’m not convinced new > protocol mechanisms are needed. > > Even if it was inarguable that new protocol mechanisms are needed, > won’t this still point back to your point about, “each number > management authority would determine what data is associated with a > number”? > > Today those number management authorities also determine the protocol > mechanisms for enrolling (i.e., assigning) and managing telephone > numbers. What reason is there to believe they will spontaneously > adopt what MODERN developed? This is starting to feel like TRIP2.0. > > I think the number management authorities have to respect users and > communications service providers want to create associations of new > non-traditional kinds of information with one or more telephone numbers. > > I don’t think that necessarily implies they also have to respect any > suggested protocol mechanisms for managing the information > assocations. And the number management authorities would necessarily > be facing that conversation at some point, will they not? > > “SRD> We clearly need to have some assumptions about what those data > models might look like, but…” > > Agreed. I suggest developing a starter data model based on a set of > legacy requirements and requirements not being met by the current data > set would be useful. I think defining an easily extensible data model > is critical. > > I’m not very interested in discussing YAPP (Yet Another Provisioning > Protocol), but very interested to discuss association of new > non-traditional services and their identifiers and parameters with > telephone numbers. > > Best regards, > > *Pierce Gorman* > > Core Network Planning > > O: 913-439-4368 > > pierce.gorman@sprint.com > > cid:408000_086801428601145001@pvmxe13g01 > > *From:*Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* May 12, 2015 2:18 PM > *To:* Gorman, Pierce A [CTO]; McGarry, Tom; modern@ietf.org > *Subject:* Re: [Modern] MODERN will solve no problems (or will the > IETF take over the world?) > > Pierce, > > See my comments inline. > > Steve > > On 5/8/15 12:58 PM, Gorman, Pierce A [CTO] wrote: > > Steve, > > Here is a suggested set of changes to the 2^nd paragraph. > > OLD: > > The working group will define a framework for the roles and > functions involved in managing and resolving TNs in an IP > environment. This includes a protocol mechanism for acquiring TNs, > which will provide an enrollment process for the individuals and > entities that use and manage TNs. TNs may either be managed in a > hierarchical tree, or in a distributed peer-to-peer architecture. > Privacy of the enrollment data and security of the resource will > be primary considerations. > > NEW: > > The working group will define a an information management > framework for the roles and functions involved in managing and > resolving TNs associating SERVICE, SERVICE_PROVIDER, and > NUMBER_USER information with one or more TNs in an IP environment. > This includes a protocol mechanism for acquiring TNs, which will > provide an enrollment process for the individuals and entities > that use and manage TNs. TNs may either be managed in a > hierarchical tree, or in a distributed peer-to-peer architecture. > Privacy of the enrollment managed data and security of the > resource will be primary considerations. > > SRD> I'm mostly okay with your changes other then removing the wording > on the protocol work. I believe there is enough support for doing the > protocol work that this should remain in the charter. I'm not sure > we need to define the concepts of SERVICE, SERVICE_PROVIDER and > NUMBER_USER, as the framework might come up with different terms > and/or roles. > > I would prefer if others weighed in here. I don’t like being one > of a few with such influence. > > SRD> Agreed. > > Because I wasn’t at the BoF and am new at this sort of thing, I > personally would be happier if we took more time in e-mail or > meetings to discuss the problems the WG should address, not the > solutions (at first). > > SRD> Yes we need more discussion. That is what the working group is > for. The charter is to define the scope of the working group effort. > We don't need to have all of the answers now. > > A specific area of concern for me is the data model of information > associated with telephone numbers. I care much more about what > is being provisioned then I do about how it is provisioned or shared. > > SRD> I actually don't think it is the job of the MODERN working group > to define detailed data models. We clearly need to have some > assumptions about what those data models might look like, but I would > assume that each number management authority would determine what data > is associated with a number. > > SRD> I also think the how is important as the resulting mechanism, be > it a new one defined by the group or an existing one recommended by > the group, will need to be flexible and extensible to be able to > address the problems outlined by Henning. > > I think trying to identify the what first will be more valuable > than the how, and certainly more important than the who. > > SRD> Agreed and the proposed deliverables are in the order listed for > that very reason. > > Best regards, > > Pierce Gorman > > Core Network Planning > > O: 913-439-4368 > > pierce.gorman@sprint.com > > -----Original Message----- > > From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz] > > Sent: May 05, 2015 9:54 AM > > To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org > > > Subject: Re: [Modern] MODERN will solve no problems (or will the > IETF take over the world?) > > "Š define a framework for the roles and functions involved in > managing and resolving TNs Š" is a necessary step to create a > common understanding, for a WG, of the ecosystem for managing TNs. > > For example the WG could define a communications service user, a > communications service provider, a numbering authority, a > numbering administrator, etc.; describe the functions of these > roles and how they may interact with each other. Both > presentations at the BoF did a good job of starting this discussion. > > As the charter states, the work done by the WG would be flexible > enough to accommodate different administrative models, therefore > the framework, roles and functions would need to be flexible. > There is no intent to create a single administrative model, and > there is no text in the charter that would suggest otherwise. In > fact the charter states this explicitly. > > If there are text changes you could suggest that makes this > clearer for you and others, please do. > > On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" > > > > wrote: > > >Thanks Steve. I don't think wordsmithing "framework" to be > > >"architectural framework" in the 2nd paragraph really addresses the > > >underlying concern. > > > > > >I understand the temptation to jump right in and have MODERN > develop a > > >newer, better, solution to the existing (North American?) framework > > >architecture but it feels like a bridge too far. I'd suggest > striking > > >the 2nd paragraph entirely, but I suspect that is also as > unappealing > > >to you as the paragraph is to me. > > > > > >I liked Eric Burger's suggestions regarding fleshing out problems by > > >describing use cases. > > > > > >One use case that occurs to me that might lead in the direction I > think > > >you're interested in is I've not seen sufficient description of > how to > > >associate "services" with telephone numbers. For example, many > people > > >are members of more than one social networking application, and some > > >social network applications offer services which overlap with > > >traditional telecommunications and therefore could benefit from > > >assocation with number_user telephone numbers. > > > > > >I think it would be useful to explore how those services could be > > >defined syntactically, managed, and discovered. But maybe that's > just > > >me. Maybe others find that useless and/or objectionable. It > does seem > > >like the direction you were wanting things to go in terms of giving > > >number_users control over service provider associations with > their telephone number. > > >And it seems directionally correct in terms of addressing the > interests > > >of users and non-traditional communications service providers for > > >service provider mash-ups associated with a telephone number. > > > > > >I know I haven't directly answered your question about specific > > >suggested changes to the text in the charter. I would like to hear > > >more from others. > > > > > >Best regards, > > > > > > > > >Pierce Gorman > > >Core Network Planning > > >O: 913-439-4368 > > >pierce.gorman@sprint.com > > > > > > > > >-----Original Message----- > > >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve > > >Donovan > > >Sent: May 04, 2015 1:30 PM > > >To: modern@ietf.org > > >Subject: Re: [Modern] MODERN will solve no problems (or will the > IETF > > >take over the world?) > > > > > >Pierce, > > > > > >See my comments inline. > > > > > >Regards, > > > > > >Steve > > > > > >On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: > > >> If we can agree we eliminate the charter language that implies > > >>creating a framework which supplants the authority of the NANC (at > > >>least) and which assumes a replacement of the NPAC and LERG > databases, > > >>we will have made progress (IMHO). > > >SRD> This should be easy to do, as there is no intent and, even if > > >SRD> there > > >were intent, there is no ability for the MODERN group to take > anyone's > > >authority or replace anyone's database. > > > > > >SRD> Is the problem with the word framework in the second paragraph? > > >Would calling it an "architectural framework" help? > > >> > > >> Beyond striking objectionable language, the reason for David > Holmes' > > >>posts following mine last week was to try to improve the focus > of the > > >>work for MODERN. We do think it is a bad idea to ignore that > number > > >>administration and routing solutions need to evolve. And we're not > > >>against the MODERN working group identifying problems. In fact > we're > > >>in favor of it. Its what to do past that where we're struggling. > > >SRD> I share the desire to focus the work. I think the revisions of > > >SRD> the > > >charter have moved in this direction. > > >> > > >> The thing I'm concerned about is a repeat of the e164.arpa fiasco > > >>which succeeded in defining a global schema and protocol for > managing > > >>numbers and resolving them for routing and which failed utterly. > > >SRD> We fail if we don't learn from our mistakes. I'm confident we > > >SRD> will > > >have enough involvement in the group to keep us pointed in the right > > >direction. > > >> > > >> Best regards, > > >> > > >> > > >> Pierce Gorman > > >> Core Network Planning > > >> O: 913-439-4368 > > >> pierce.gorman@sprint.com > > >> > > >> > > >> -----Original Message----- > > >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve > > >> Donovan > > >> Sent: May 01, 2015 4:24 PM > > >> To: modern@ietf.org > > >> Subject: [Modern] MODERN will solve no problems (or will the IETF > > >> take over the world?) > > >> > > >> The question of what problem(s) MODERN will address has been > asked, > > >>multiple times. > > >> > > >> The short answer is that, in an of itself, MODERN will solve no > > >>problems. > > >> > > >> This isn't to say there aren't problems with existing > mechanisms. It > > >>is to say that all MODERN can do is to specify protocols that > can then > > >>be part of an overall solution that addresses problems that > exist with > > >>those existing mechanisms. > > >> > > >> There is a brief capture of these problems in the latest > version of > > >> the > > >> charter: > > >> > > >> "A sample of problems with existing mechanisms include: > > >> > > >> - lack of flexibility (for example, it can be difficult to add > fields > > >>without a very elaborate and lengthy process typically spanning > years) > > >> - lack of distribution (for example, it is hard or impossible > to have > > >>more than one administrator for each database) > > >> - complexity (leading, for example, to a fair amount of rural call > > >>completion problems which aren't helped by small providers > struggling > > >>to keep numbers straight) > > >> - difficulty of adopting more modern allocation (e.g., "blocks" > of 1) > > >>and porting mechanisms" > > >> > > >> Will MODERN solve these problems? No. > > >> > > >> Will MODERN make it possible for these problems to be addressed as > > >>part of new number management policies to be enacted by the > > >>appropriate authorities? That, I believe, is the goal. > > >> > > >> Will MODERN force any of these new number management policies > to be > > >>enacted. No. The IETF is not a policy setting body. > > >> > > >> I'm ok with having a more detailed articulation of the problem > > >>statement as part of the deliverables of the MODERN working > group. I > > >>don't see the benefit of making that the only deliverable and > forcing > > >>rechartering after that document is finished. Let's instead > agree to > > >>shut the working group down if there is consensus that it is going > > >>nowhere (which I'm sure the ADs will do anyway). > > >> > > >> Regards, > > >> > > >> Steve > > >> > > >> _______________________________________________ > > >> Modern mailing list > > >> Modern@ietf.org > > >> > > >>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > >>man > > >>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID > > >>cLe > > >>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& > > >>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > >> > > >> ________________________________ > > >> > > >> This e-mail may contain Sprint proprietary information intended > for > > >>the sole 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. > > >> > > >> _______________________________________________ > > >> Modern mailing list > > >> Modern@ietf.org > > >> > > >>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > >>man > > >>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID > > >>cLe > > >>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w& > > >>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > >> > > > > > >_______________________________________________ > > >Modern mailing list > > >Modern@ietf.org > > >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm > > >an_ > > >listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL > > >ext > > >Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h > > >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > > > > >________________________________ > > > > > >This e-mail may contain Sprint proprietary information intended > for the > > >sole 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. > > > > > >_______________________________________________ > > >Modern mailing list > > >Modern@ietf.org > > >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm > > >an_ > > >listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL > > >ext > > >Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h > > >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e= > > ________________________________ > > This e-mail may contain Sprint proprietary information intended > for the sole 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. > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > ------------------------------------------------------------------------ > > > This e-mail may contain Sprint proprietary information intended > for the sole 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. > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for > the sole 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. > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --------------080203050205060405000903 Content-Type: multipart/related; boundary="------------050908040403020809090500" --------------050908040403020809090500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Pierce,

Protocol work doesn't necessarily mean new protocols will be developed.  It could also result in a recommendation to use or build on  existing protocols. 

To your question: "Today those number management authorities also determine the protocol mechanisms for enrolling (i.e., assigning) and managing telephone numbers.  What reason is there to believe they will spontaneously adopt what MODERN developed?"

Nothing happens spontaneously but if we do our work well then we give the authorities another option, one that addresses the shortcomings in the existing mechanisms.

To your point: "I’m not very interested in discussing YAPP (Yet Another Provisioning Protocol), but very interested to discuss association of new non-traditional services and their identifiers and parameters with telephone numbers."

If we end up creating a new set of protocols, hopefully it will be ABPP (A Better Provisioning Protocol) :-).  I believe the latter part of your statement is one of the motivators for the proposed working group.

I propose the following, which keeps the protocol work.

Old (from the "revised revised" email):

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment.  It will also define protocol mechanisms for acquiring and resolving TNs.  The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment data and security of the resource will be primary considerations.  The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time application performance, security and privacy are primary considerations.  The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS.

New:

The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment.  The working group will also define protocol mechanisms to support the interactions between the functions defined by the framework.  This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs.  The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the managed data and security of the resource will be primary considerations.  The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time application performance, security and privacy are primary considerations.  The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS.

Regards,

Steve

On 5/12/15 5:10 PM, Gorman, Pierce A [CTO] wrote:

Thanks Steve.

 

“SRD>   …I'm not sure we need to define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles.”

 

I’m not sure how you want to word this and I’m not married to what I suggested.  I was implying information in a data model.  I picked those three fields because I thought they are fundamentally what has been described to associate with one or more telephone numbers (assuming we can agree what a TN is).

 

How about we remove any reference to what information is being associated with telephone numbers like this…

 

NEW-ER #0:

 

The working group will define a an information management framework for the roles and functions involved in managing and resolving TNs associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment managed data and security of the resource will be primary considerations.

 

“SRD> I'm mostly okay with your changes other then removing the wording on the protocol work.  I believe there is enough support for doing the protocol work that this should remain in the charter.”

 

Well, if there’s enough support you can ignore me.  J  The heartburn I have with leaving the protocol work in there is I’m not convinced new protocol mechanisms are needed.

 

Even if it was inarguable that new protocol mechanisms are needed, won’t this still point back to your point about, “each number management authority would determine what data is associated with a number”?

 

Today those number management authorities also determine the protocol mechanisms for enrolling (i.e., assigning) and managing telephone numbers.  What reason is there to believe they will spontaneously adopt what MODERN developed?  This is starting to feel like TRIP2.0.

 

I think the number management authorities have to respect users and communications service providers want to create associations of new non-traditional kinds of information with one or more telephone numbers.

 

I don’t think that necessarily implies they also have to respect any suggested protocol mechanisms for managing the information assocations.  And the number management authorities would necessarily be facing that conversation at some point, will they not?

 

“SRD> We clearly need to have some assumptions about what those data models might look like, but…”

 

Agreed.  I suggest developing a starter data model based on a set of legacy requirements and requirements not being met by the current data set would be useful.  I think defining an easily extensible data model is critical.

 

I’m not very interested in discussing YAPP (Yet Another Provisioning Protocol), but very interested to discuss association of new non-traditional services and their identifiers and parameters with telephone numbers.

 

Best regards,

 

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

cid:408000_086801428601145001@pvmxe13g01

 

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: May 12, 2015 2:18 PM
To: Gorman, Pierce A [CTO]; McGarry, Tom; modern@ietf.org
Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

 

Pierce,

See my comments inline.

Steve

On 5/8/15 12:58 PM, Gorman, Pierce A [CTO] wrote:

Steve,

 

Here is a suggested set of changes to the 2nd paragraph.

 

OLD:

 

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment data and security of the resource will be primary considerations.

 

NEW:

 

The working group will define a an information management framework for the roles and functions involved in managing and resolving TNs associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment managed data and security of the resource will be primary considerations.

 

SRD> I'm mostly okay with your changes other then removing the wording on the protocol work.  I believe there is enough support for doing the protocol work that this should remain in the charter.   I'm not sure we need to define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles. 

I would prefer if others weighed in here.  I don’t like being one of a few with such influence.

 

SRD> Agreed.

Because I wasn’t at the BoF and am new at this sort of thing, I personally would be happier if we took more time in e-mail or meetings to discuss the problems the WG should address, not the solutions (at first).

SRD> Yes we need more discussion.  That is what the working group is for.  The charter is to define the scope of the working group effort.  We don't need to have all of the answers now.

 

A specific area of concern for me is the data model of information associated with telephone numbers.   I care much more about what is being provisioned then I do about how it is provisioned or shared.

SRD> I actually don't think it is the job of the MODERN working group to define detailed data models.  We clearly need to have some assumptions about what those data models might look like, but I would assume that each number management authority would determine what data is associated with a number.

SRD> I also think the how is important as the resulting mechanism, be it a new one defined by the group or an existing one recommended by the group, will need to be flexible and extensible to be able to address the problems outlined by Henning.

I think trying to identify the what first will be more valuable than the how, and certainly more important than the who.

SRD> Agreed and the proposed deliverables are in the order listed for that very reason.

 

Best regards,

 

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

 

 

-----Original Message-----

From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]

Sent: May 05, 2015 9:54 AM

To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org

Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

 

"Š define a framework for the roles and functions involved in managing and resolving TNs Š" is a necessary step to create a common understanding, for a WG, of the ecosystem for managing TNs.

 

For example the WG could define a communications service user, a communications service provider, a numbering authority, a numbering administrator, etc.; describe the functions of these roles and how they may interact with each other.  Both presentations at the BoF did a good job of starting this discussion.

 

As the charter states, the work done by the WG would be flexible enough to accommodate different administrative models, therefore the framework, roles and functions would need to be flexible.  There is no intent to create a single administrative model, and there is no text in the charter that would suggest otherwise.  In fact the charter states this explicitly.

If there are text changes you could suggest that makes this clearer for you and others, please do.

 

 

 

On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com>

wrote:

 

>Thanks Steve.  I don't think wordsmithing "framework" to be

>"architectural framework" in the 2nd paragraph really addresses the

>underlying concern.

> 

>I understand the temptation to jump right in and have MODERN develop a

>newer, better, solution to the existing (North American?) framework

>architecture but it feels like a bridge too far.  I'd suggest striking

>the 2nd paragraph entirely, but I suspect that is also as unappealing

>to you as the paragraph is to me.

> 

>I liked Eric Burger's suggestions regarding fleshing out problems by

>describing use cases.

> 

>One use case that occurs to me that might lead in the direction I think

>you're interested in is I've not seen sufficient description of how to

>associate "services" with telephone numbers.  For example, many people

>are members of more than one social networking application, and some

>social network applications offer services which overlap with

>traditional telecommunications and therefore could benefit from

>assocation with number_user telephone numbers.

> 

>I think it would be useful to explore how those services could be

>defined syntactically, managed, and discovered.  But maybe that's just

>me.  Maybe others find that useless and/or objectionable.  It does seem

>like the direction you were wanting things to go in terms of giving

>number_users control over service provider associations with their telephone number.

>And it seems directionally correct in terms of addressing the interests

>of users and non-traditional communications service providers for

>service provider mash-ups associated with a telephone number.

> 

>I know I haven't directly answered your question about specific

>suggested changes to the text in the charter.  I would like to hear

>more from others.

> 

>Best regards,

> 

> 

>Pierce Gorman

>Core Network Planning

>O: 913-439-4368

>pierce.gorman@sprint.com

> 

> 

>-----Original Message-----

>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve

>Donovan

>Sent: May 04, 2015 1:30 PM

>To: modern@ietf.org

>Subject: Re: [Modern] MODERN will solve no problems (or will the IETF

>take over the world?)

> 

>Pierce,

> 

>See my comments inline.

> 

>Regards,

> 

>Steve

> 

>On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote:

>> If we can agree we eliminate the charter language that implies

>>creating a framework which supplants the authority of the NANC (at

>>least) and which assumes a replacement of the NPAC and LERG databases,

>>we will have made progress (IMHO).

>SRD> This should be easy to do, as there is no intent and, even if

>SRD> there

>were intent, there is no ability for the MODERN group to take anyone's

>authority or replace anyone's database.

> 

>SRD> Is the problem with the word framework in the second paragraph?

>Would calling it an "architectural framework" help?

>> 

>> Beyond striking objectionable language, the reason for David Holmes'

>>posts following mine last week was to try to improve the focus of the

>>work for MODERN.  We do think it is a bad idea to ignore that number

>>administration and routing solutions need to evolve.  And we're not

>>against the MODERN working group identifying problems.  In fact we're

>>in favor of it.  Its what to do past that where we're struggling.

>SRD> I share the desire to focus the work.  I think the revisions of

>SRD> the

>charter have moved in this direction.

>> 

>> The thing I'm concerned about is a repeat of the e164.arpa fiasco

>>which succeeded in defining a global schema and protocol for managing

>>numbers and resolving them for routing and which failed utterly.

>SRD> We fail if we don't learn from our mistakes.  I'm confident we

>SRD> will

>have enough involvement in the group to keep us pointed in the right

>direction.

>> 

>> Best regards,

>> 

>> 

>> Pierce Gorman

>> Core Network Planning

>> O: 913-439-4368

>> pierce.gorman@sprint.com

>> 

>> 

>> -----Original Message-----

>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve

>> Donovan

>> Sent: May 01, 2015 4:24 PM

>> To: modern@ietf.org

>> Subject: [Modern] MODERN will solve no problems (or will the IETF

>> take over the world?)

>> 

>> The question of what problem(s) MODERN will address has been asked,

>>multiple times.

>> 

>> The short answer is that, in an of itself, MODERN will solve no

>>problems.

>> 

>> This isn't to say there aren't problems with existing mechanisms. It

>>is to say that all MODERN can do is to specify protocols that can then

>>be part of an overall solution that addresses problems that exist with

>>those existing mechanisms.

>> 

>> There is a brief capture of these problems in the latest version of

>> the

>> charter:

>> 

>> "A sample of problems with existing mechanisms include:

>> 

>> - lack of flexibility (for example, it can be difficult to add fields

>>without a very elaborate and lengthy process typically spanning years)

>> - lack of distribution (for example, it is hard or impossible to have

>>more than one administrator for each database)

>> - complexity (leading, for example, to a fair amount of rural call

>>completion problems which aren't helped by small providers struggling

>>to keep numbers straight)

>> - difficulty of adopting more modern allocation (e.g., "blocks" of 1)

>>and porting mechanisms"

>> 

>> Will MODERN solve these problems? No.

>> 

>> Will MODERN make it possible for these problems to be addressed as

>>part of new number management policies to be enacted by the

>>appropriate authorities?  That, I believe, is the goal.

>> 

>> Will MODERN force any of these new number management policies to be

>>enacted.  No.  The IETF is not a policy setting body.

>> 

>> I'm ok with having a more detailed articulation of the problem

>>statement as part of the deliverables of the MODERN working group. I

>>don't see the benefit of making that the only deliverable and forcing

>>rechartering after that document is finished.  Let's instead agree to

>>shut the working group down if there is consensus that it is going

>>nowhere (which I'm sure the ADs will do anyway).

>> 

>> Regards,

>> 

>> Steve

>> 

>> _______________________________________________

>> Modern mailing list

>> Modern@ietf.org

>> 

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

>> 

>> ________________________________

>> 

>> This e-mail may contain Sprint proprietary information intended for

>>the sole 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.

>> 

>> _______________________________________________

>> Modern mailing list

>> Modern@ietf.org

>> 

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

>> 

> 

>_______________________________________________

>Modern mailing list

>Modern@ietf.org

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

> 

>________________________________

> 

>This e-mail may contain Sprint proprietary information intended for the

>sole 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.

> 

>_______________________________________________

>Modern mailing list

>Modern@ietf.org

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

 

 

________________________________

 

This e-mail may contain Sprint proprietary information intended for the sole 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.

 

_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.org/mailman/listinfo/modern

 


This e-mail may contain Sprint proprietary information intended for the sole 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.

 



This e-mail may contain Sprint proprietary information intended for the sole 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.
 

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

--------------050908040403020809090500 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAU8AAAA8CAYAAADmDDgpAAAT+klEQVR42uydCWyU55nHU2kr VRtVmkqrXVW7ap22q12ttqvpVlXVNGldqWk4kmLCEcAcA76wx/PF5KIhJEwIBBIIDEm4CZlw XwnmCkc4hvtwTIbLHMHGYDAYbBgwYGzAs/8/+l766t05GNsxE/tB+on53pnvnO/7zfM+z/t9 fgT/AoIgCELCPBIWBEEQEuYRryAIgpAg4XBYEARBSJB2fwAEQRBEnoIgCCJPQRAEkacgCILI UxAEob3T7g+AIAiCyFMQBEHk+fC4XfGDFOBo78dBEASRZ0JQnCAAvO39WAiCIPJMVKBOEAJB kNLej4cgCCLPRASaCsK2RJ3t/XgIgiDyTESgBUqgEoEKgiDyTEyghbZAg8ChtfuBq70fH0EQ eQqxCkjltkD9WruLbd+qQM92+R74B/AD8Cj4IXCAfwL/DH4M/hX8BPwM/AL8B/gv8EvgBP8L fgN+B34P/gBSwZ/BX0BH0Bk8C7qCbqAn6AX6gv7ABTJANsgFbuABL4CXwCtgKBgG3gAjwFtg FBgD3gXjwPtgIvgQTAZTwXQwC8wGfjAHzAcLwWKwFHwOCsFKsBp8AdaDL8EmsBlsBdvBTrAb 7AVFoBjsB0FwCBwGJeAYOAFOglJwCpwGFeAsqATnQRW4CKpBDbgCQuAaqAU3wE1QB26BetAA boM74C5otAnbNLLd5o79+Xp7/jpw015urb2eq/Z6L9vbcQlU2dtXaW9vBTht70epvV/H7f0s sff7IAjax6PYPj57wC6w0z5+Aft4bgQbwFqwBqwCK+zvYhlYAhaBBWAu+BR8Aj4GM8A0MNn+ rn1gAhhvnwtj7HNjpH2uvGGfO0Ptc+kl+9zyADcYDLLBIOCyz8l0+xztYZ+zafY53Al0AE+B P4E/gifA4+C34NfgV+B/wH+D/wT/Dn4OUsC/2dfVv9jX2Y/s6+5R+zr8PvheuxdjggWksE2a kqreJvIUeYo8RZ5C/PynQ3Xp9TaRp8hT5CnyFCILNKC674ZQicuIVL0iT5GnyFPkKfy9qx4C YVuQKZo8CyPkQwPAIfIUeYo8RZ7tHuY3lRg5rRWTQtpnvJpUAyJPkafIU+QpAAjRZ4sxFfg1 UaYY8lS4RJ4iT5GnyLPdow1fKlSRqE1qFHkWijxFniJPkWer8thjP0sBqcCRpLdvPqFJssAo LCkCxnw+4BB5ijxFnm1MnhBVGvCCgEah3ZbSiuJMA2GbUEuv25ayD7iaKFAv8Gt5T28seRrv lQOnyFPkKfJsA/KERJygHIRjkNqK8iw01l3QgssOaMv1NnP40gJDniFDnj4jWlWEgEPk+eDy XPCxFVw42zrQ0vI8V5xRMeOD/NDMDz1XwTWR57cnzzWLrPnTJuWvbCvyVOIMgXAcHK0ozwJj 3c4klKcTLDDGf4YNXHrUaVCQjPJ847XsTx9//Ilw/349i7Oz0nfw9cg3cxa3tDw/merZ8t6o vP3g69LdOcuUPMePyTv0/pi8wxPGuo+U7claR3muWmjt43aQRbOtQy0pz33r889zuYrmynP2 FM9d0EiUPC8EB4axv/dge3uV56gRg7cP6P/86bYhT1MmwOyiM+JUkV9roqUP0jidZPJUAn1S dc9VdGmQorWbeJNNnri4vVmZ6VspkezM9O3Pde1yRskTEdqLLSnPjEF9KpWwNi73rFPy1EW2 daW1jfK8XNJvbb++Pa927tTp9oHN7l3JLE9jWY0kuMkd1ttFnm1AnpRkpO5xspGs8iSaPNMM OQbt94NR5Jmi35UEHA9bnvoFbrLEb1F+bohgxPC/Za19c1j2+rFv566E4CZ5h+dsemt4zuap E/OXK3lePOCaOPFd96bR3sE7wa5ZH+Wvrz48YAYvLERfmyHmWrXsoS9nnhz3Tt4BRJ0H9XUO ezXz9PxZ1v6tKz1cRtnrQ7PObl/tKSrfm7Xjg3Husg/Hu09hu46dKcos+uh99xlQsfRTq1SX 59mvMkqwXVVTffkX5860LhzdnnsKXcea6ZPyLxfOsy6a8qzcP6hq5keeWnAdqYLaa8f71Ojy PP/1wOsfT/bUg4bZkz23sW0NSp6MOvVlMdJc9InViOMU1tsZfX69yX1XyZPL4LIIl4t13FDy XL3QuoFjVwduVu4feLl4g/sKt0/J8+rxPudWzLeqsT9X5s20qvEjV055ni3OKMU+XyrZlnvS lOfkCe5zu7/wlCh5rltqleBYloNTB7fk7dXlyXQJjz+2dxN6AyU4/pvZMyjbk7NCl2fNkf5z 3x2VW7xhmbVSyRPfzap33srdze//2PbB0yLJc84Ma96IYdlfgg2fzbGmKHm+PjRzzeJPrAmm PF8eMuizT6dZI5NBnqlNyWuy0AK8NinAAQpAQMPH9kgRpUJLGxTa87g0qXsVMdbtVG1qGTZ+ 4DT200uM3G5AX0+Tc58g0hhPEiPqVOIMKdlyOpnliQt4utn+9NNP16nXiA5PUZ47VntmdujQ 4Zb52Y4dOtbvXZe/eNDA3ufstrggdXAJEj6upieNc5/EBfyVmu7Ro2sdI1J9HqQCLlASu9d6 TnTu3OmO/t4zz3S+LzhP/oA6U57PPvtMoz6NSPw2BHqZ8oTIbprbZ0fpjbUn+tRHei8nu6/Z pgTKeRqGvDCwMdL7yA/WUZ4Fluv+vr3gcTXoETKEVMX9IdyX53s+d5uv8QNBgR7ja/yoXdHl CbmVcn7KM3QsfZ9rQK/rnM7N6XcFYqvla0jrsJIntr+aUT/bu3VLu7F/o3vDc891uf63VzLL dHlCaNv4mW925czHj+Ss3r26XeK0y9Wrotfz3S7yNbavSpenle/6mu1903uW4nus5Gv+MFOe vXt3P4H1VOjyxDEZzs8kqzy9TYje0kBQTRuEzHyl8X6aMe2KtF2x1m1Mm6Rqwg7HoxkD5wOg 0CgI/VSJ0SBoitOYz/kwc57q4pwyIX8S/8eJf0wVjCCWGl2a6oTX5Vl1wPWuLk6+1qcpTkQZ BylS1danT/caSOpCVkZ6lbG8EKKW0mjyjAXl2bNH1/vroETz8/rf4Ot48qQw9TZGfcVf5tfq bbi4G/VpRG13TBG+WDAojO3nD0DYbF+7xLqLiPRurGWe2JlzXZenmV7Ad3MnMyO9AdFnheq2 Q2rXIakGyhORfA33W5cnegnVPC7sto94Pfsi3z8cyN2vuu3Y13vH+tTerICSZ6eOHRuYQlHd dkae/EzNkX6LlTz5HeL4UtrT0Cs5wO93z7r8+arbjmLf55xHyXPbKs9UTiNaXa267e7c/kU8 ryhP9UON+cYreTKVhO29lCzddkcEiXjZnoA84xWbymPIM2TKLiF5xh8hEGwFeRYALyjXI0v9 DiSzym6I0wTtjz7W2vLEhb84XuSpT6N7N5onPLtcujxxwa7TPwfxbQZbDCnMSyTnGUuejDrZ bcd2VBmRW5k+bXdfS9B1r4olz+M7BvPiPM9uu2qjwNCNbNAFi67srbFv593RxZdozlNv47Kw zHouW5P2LV2efA/H4sbKBVaI28m2LSusaj3nif05x3ZE+GcQgZbx9edzPBVKnpSlHZnv4WsI vNLMeXIe33vub5Q8+QOm5zwhzc8oVKZaKM+Tu3OWcp5lc6wNlCfFicJj0Mx5Ds7ue0LJEz+y Y7Afs/WcJ1NBXI7KefLHGvPsojyRfsl76qm/3MT3PDeZCka+KBGjHzhjyNP8fJomZL8ZYRry NOctUAPiE5BnxFytue5WyHmmgrGGIJ+JIk5nHHEqvMksT0QZ36iC0fK51nRdniPfyAnEiwrR dVzRUvLMHdwvpApGqs3u2lWo1wNdvetUwYhSiSZPRnGqYMTcoi4tJbFYJCJP5jzjLW/MyNwG fb2Iwq6rgtFXG9zV0eZT8uT+Mgod+nLGVcpTddmPbM09QnlGm9eUJ47/MbNgxG47u++UJ1ID R5jDVgUj+3xZE69ghB+yBThnysx1K3m+/WbOEk5jX18dNzpvFl/jhzIrmeTpMMZVmgRAShyB UV6xIlpfVHmagk5cnua6na0sTwf4SBPfa6A8ijhdnI7PP3ZtbXnuXOPJhdACaphS17S/nuZr XCQr2HUyI08UNYabkacpT+TTzqiCEQsHiK72gn2MPFtTnuTqsfSj8SJPdoMjyRP5u7u6xCC1 26pgZHOHNEeeesEI1BPmWPX1YptCpjwRvV0uWu+u4n6ASnAO4qzA/p7g/qIgc97e/0OQXA1y kDdVtZ3tjNjx3R8EQeSq9+PYFoMidttjyZMFI84/Z7q1g5EmilB7dHliXzaa8kQBsEjJE9/D Qn6OxUb+AKMn844ZeaL4NYTRJs9Bjvxgtz0p7zDS8odxc5dmt/0BotNAFHn62ZaYPOOvuxXl aT4wpBz4miNO4H9YOc+83P5rePK+8uKgz5U8UW19T+U8eSJr0dhlJvrNnCcqvIVqOq3LX69e PDjgAxQgVjDvaUaees5z03LPesrTrLZDPFuaIk9VLEo058lKNsRUo+c90WWvh/zr/z6ddZtD iii7WJEnq+zo0lKeZhTPsZ93cAzvt32x2GKVvW6INfC+VDGioD6aPDkqQMlT77az2o7RBNWs tlOe6O4etyV3Tv2oKHn26N71FuVpdttxjEuRk9wbS55gAfPUKnfNaruSJ9teGjLoqCnPLl2e DSl5QoRHsf7zsbrtYDD2f6M671gwSkZ5mpGbP0bu0hRQYZTl+B5AngXNlKc/SeSpBsEPjyJO /wOK0wccD0ueiKim4KRfhojn9VdfyliOIUSFuAg9Sp64iObqElASNavtKEhcUG0mkPI1jvNE seKQ+R7lCSFfMavtTZUnhr6U29Nxq+0mRgRci2FCV81KvCHKu5QnpGAWjbhfEavtIGbXHUWq G9HkCSqHvZpVx/3hUCXKE9X3Co97wE22qcgTHEYh5n7+tqIo45CSJ4ZSnbKLXaevHO274/S+ zF3oGZxh24PIE0O9Avws0gLf6OM82buwv6utlw65JmO7ZjDfqReMcG7tZnEIxapxlCe2xc9p U544Bq+xjZFnsj8YxBwDGjQLOjEFlLg8U5spT2+SyDMEpoKQIc4nVRU+DuUgNZlvz+QgeURM PkRdX6BifhD5wcMc54mxlUtMeWKM53h1segg93iWQ5UoTwxnuVehNeWJi2UdixHNleem5dZJ ChSjBi4w54eL9RrHeSJFcDaWPDF8pt7I/dWpcZ5IN9RiRMA94ZnFHg5VojwxVIcRpSlPVtf/ nzz5eXb3+Xmz4q+GKsWSJ6rslcgj3tDn5XAlNVRJyZMFI74Hidaag+Q5PlYf6sXXaqhSPHmi t7DBTrusNQfJs2DE9/QUDrvtesGIkac+eqN7967nTHnivCtgG3OeSS9PsyvfDHkG2oM8KT1b fjsiiDP4oNFmst/bjq72aP1EhzAKKU99nCejCf0OI3TZfZDGIrAEEciUSPe2I19XyJwnKriL 9HvbAyutAHOeTX0wCIoiJfrFqwbJQy5KzLxz6lqkB4Ogkl3NnCfGd16KdIcRutcc73iLRLu3 HV31RqLf2w7B3mtDV968w4jLqge3IOi6RO8w4lAl/ggw8mzqHUYq55nIHUb4vkvT+/S4HOsO I373jDyjPRgEIww+ZM4z2h1GiK5XsdvOavt3TZ7OZsgzpH+mDcvTB6bp4zhBp3gVdTUo/rv0 YBBEeVErtJQohDUxmZ6qxAKJvo1m9x1RzWl5qlLTbs/Ej90yVTD6Np+qhO+pGjcHfPmdep5n lPGRKZEFFP/BHm1YnpmGEPPiSDMECr6rj6RDN3Yehyoh4jjJghFBt3gnCiCjk/GRdOiynmHO j7BgRDDI+wqitTJ5JF3T5Yl85zYWjCDRhd+WPNcv9YzCSIfjHKqUjPJUuUmvLSwncNiv/WZl PFbRxhSn2WVPUnmWgxS1z00QZ4oWYfqBL14lXR6GLM/zlOd5trGnKsUhBBwJzqPmS0kyefpb 4g4jSlDLaY4FgThd9FT5MxwiT5Fn+5JnADgSmcccXJ9k8nS2kDz9IASGxLrVErjkbxiJPEWe bVOeacAX5U9vOB+kkq7N7zfni/VUpUhyTfCpSqnx1hGtEGbssw94EywSBcG4GNL0Aof8ATiR 5/+1d8cqbYVxGMaHikMQMthCEZR2EaSIAYvNolSXdNIShEDoYOkgLQ5aRBQlCKKIQ4sQKliE QEtQUAxiJbjoFYiX0EsIvYK+wqN8HEhOBqfkHX6LaAzf+X+PJzmR43j6BnAxZ3/tgf8UKsuf uPc1fd92x9PxdDwdT+EC0YL8rRPNhzNpx9PxdDwdT8cTvBRvGE3H0/F0PB1PxxOccV43iqbj 6Xg6no6n4xng3kS1uGj+u0mm7jiejqfj6XgCMVe8Ww2f46w0c/WceNbk9hHj+UQ6OXAJ6ZIk B7VbnnKgewhpr7wIYtrPgLxiWIaI6jBRfSNphmuUuI7LBAOYkXdBYKeIbFamJccQ5yOx/RgE d5bofpE5Nsa8fI3Ed5lNtCaFIMIbsilbsh2J8TeCvMtGLcqPIMz78lMO2NwlNvov+S1lHAax PpYTQnF6H26cE5MLwlIl5JfEXBQeoo4rXOOKr0Pfr5/DJY9X5fEv+H3nBOyMiJ3y/E7kmOd9 JASNqBE2KfEH6oD12Gd99ohckfXble9B7HZkm+BtygbRW5cC4VuVFY7fkixybOc51nNE8LPM MhOfIjH8IHlmKcdsZZm1yUgYM8zmhLyVsSCQaRmR10RySAaZ/QHpD2L5UvoIZo88l2fSzf5K Es4E+69TOu7jafG31qjJbTOf0ySeM5Jq97Uza2VtvwANopmSipTEITQzx7PJl+nv230dzMzx NDNzPM3MHE8zM8fTzMzxNDOzOv4DIDV//HSVjucAAAAASUVORK5CYII= --------------050908040403020809090500-- --------------080203050205060405000903-- From nobody Wed May 13 08:35:31 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 85E891A0193 for ; Wed, 13 May 2015 08:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.283 X-Spam-Level: X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, MIME_BASE64_BLANKS=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, 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 AGwS9Ni9Re5T for ; Wed, 13 May 2015 08:35:16 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 2172F1B2E26 for ; Wed, 13 May 2015 08:35:14 -0700 (PDT) Received: (qmail 15565 invoked by uid 0); 13 May 2015 15:35:12 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 13 May 2015 15:35:12 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id TZF71q01f1MNPNq01ZFA2Z; Wed, 13 May 2015 15:15:11 -0600 X-Authority-Analysis: v=2.1 cv=D8zUdJhj c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=yfQaRmzNqocA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=h1PgugrvaO0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=yakATiurAAAA:8 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=RpNjiQI2AAAA:8 a=E6urp57tPQb3wyjfIPUA:9 a=VI9e4UfI4WObU_Qa:21 a=yoMGYVqQAT7qPWha:21 a=jiObf9B0YAUA:10 a=DzjOOp_o1eYA:10 a=0PAkUXGpn6LyRvr1WVUA:9 a=5y_6mcAPe3vjVMAH:21 a=9H_57y5E2f9CGvTG:21 a=TQWqPyi6P2WZANoJ:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=egme4pEsFs5cgmtfQNoA:9 a=CB7KgUWFIrtp_Igg:18 a=HXjIzolwW10A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=NZiD5jIp1vRsnPt6Hq6Ous6X7UC+EohybpbW5DzlX5Y=; b=kGw+3wdHDWtDtUx8e+nRm9/cRe/FjzMnjDEP7OqZe4mzwSQNgrOUzhhgnhfYUP2TrDVChgY3Y/J21bOee5MMT7TJlpVMaDlS5nILOIX50fyS/qtGl07GeFLun1qjlifH; Received: from [108.56.131.201] (port=51046 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YsYNI-0000kA-71; Wed, 13 May 2015 09:15:08 -0600 User-Agent: Microsoft-MacOutlook/14.5.0.150423 Date: Wed, 13 May 2015 11:15:04 -0400 From: Richard Shockey To: Steve Donovan , Message-ID: Thread-Topic: [Modern] MODERN will solve no problems (or will the IETF take over the world?) References: <7e93fdbfc1bd44a7a5199f63ab96a0f0@PLSWE13M08.ad.sprint.com> <90f7e39770be4118aa5ed9ca31f72b20@PLSWE13M08.ad.sprint.com> <09ec73f2cd0f4d228e9fe15ddd2b3b4b@PLSWE13M08.ad.sprint.com> <555251DF.90701@usdonovans.com> <8ee344e2ec414f728337c9696a33cc4b@PLSWE13M08.ad.sprint.com> <55535B80.1080809@usdonovans.com> In-Reply-To: <55535B80.1080809@usdonovans.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3514360507_267731" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) 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, 13 May 2015 15:35:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3514360507_267731 Content-type: multipart/alternative; boundary="B_3514360508_296839" --B_3514360508_296839 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable From: Steve Donovan Date: Wednesday, May 13, 2015 at 10:11 AM To: Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?) =20 Pierce, =20 Protocol work doesn't necessarily mean new protocols will be developed. I= t could also result in a recommendation to use or build on existing protocols. [Been there done that] RS> That is a profile. The IETF doesn't do profiles or at least it doesn't do profiles very well. =20 To your question: "Today those number management authorities also determin= e the protocol mechanisms for enrolling (i.e., assigning) and managing telephone numbers. What reason is there to believe they will spontaneously adopt what MODERN developed?" =20 Nothing happens spontaneously but if we do our work well then we give the authorities another option, one that addresses the shortcomings in the existing mechanisms. =20 To your point: "I'm not very interested in discussing YAPP (Yet Another Provisioning Protocol), but very interested to discuss association of new non-traditional services and their identifiers and parameters with telephon= e numbers." =20 If we end up creating a new set of protocols, hopefully it will be ABPP (A Better Provisioning Protocol) :-). I believe the latter part of your statement is one of the motivators for the proposed working group. RS> Rat hole alert. The IETF does not have a good record here as well. Yo= u can make the case that the entire IETF PROVREG construct for the domain nam= e industry was a failure since it ended up being finely tailored to the requirements of ICANN and not a general purpose provisioning protocol. =20 I propose the following, which keeps the protocol work. =20 Old (from the "revised revised" email): =20 The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. It will also define protocol mechanisms for acquiring and resolving TNs. The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the enrollment data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access dat= a related to TNs, possibly including caller name data (CNAM). RS> Please take this out the CNAM issue. This is different on multiple levels. Don't mention CNAM at all. Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS. =20 New: =20 The working group will define an information management framework for the roles and functions involved in associating information with one or more TN= s in an IP environment. The working group will also define protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs. The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. RS> Please on't say anyhting about individuals that is a policy issue. Entities ..what ever they are. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the managed data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS.=20 =20 Regards, =20 Steve =20 =20 On 5/12/15 5:10 PM, Gorman, Pierce A [CTO] wrote: =20 =20 > =20 > =20 >=20 > Thanks Steve. > =20 > =20 > =20 > "SRD> ...I'm not sure we need to define the concepts of SERVICE, > SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with > different terms and/or roles." > =20 > =20 > =20 > I'm not sure how you want to word this and I'm not married to what I > suggested. I was implying information in a data model. I picked those t= hree > fields because I thought they are fundamentally what has been described t= o > associate with one or more telephone numbers (assuming we can agree what = a TN > is). > =20 > =20 > =20 > How about we remove any reference to what information is being associated= with > telephone numbers like this... > =20 > =20 > =20 > NEW-ER #0: > =20 > =20 > =20 > The working group will define a an information management framework for t= he > roles and functions involved in managing and resolving TNs associating > SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more T= Ns in > an IP environment. This includes a protocol mechanism for acquiring TNs, = which > will provide an enrollment process for the individuals and entities that = use > and manage TNs. TNs may either be managed in a hierarchical tree, or in a > distributed peer-to-peer architecture. Privacy of the enrollment managed= data > and security of the resource will be primary considerations. > =20 > =20 > =20 > "SRD> I'm mostly okay with your changes other then removing the wording o= n the > protocol work. I believe there is enough support for doing the protocol = work > that this should remain in the charter." > =20 > =20 > =20 > Well, if there's enough support you can ignore me. J The heartburn I ha= ve > with leaving the protocol work in there is I'm not convinced new protocol > mechanisms are needed. > =20 > =20 > =20 > Even if it was inarguable that new protocol mechanisms are needed, won't = this > still point back to your point about, "each number management authority w= ould > determine what data is associated with a number"? > =20 > =20 > =20 > Today those number management authorities also determine the protocol > mechanisms for enrolling (i.e., assigning) and managing telephone numbers= . > What reason is there to believe they will spontaneously adopt what MODERN > developed? This is starting to feel like TRIP2.0. > =20 > =20 > =20 > I think the number management authorities have to respect users and > communications service providers want to create associations of new > non-traditional kinds of information with one or more telephone numbers. > =20 > =20 > =20 > I don't think that necessarily implies they also have to respect any sugg= ested > protocol mechanisms for managing the information assocations. And the nu= mber > management authorities would necessarily be facing that conversation at s= ome > point, will they not? > =20 > =20 > =20 > "SRD> We clearly need to have some assumptions about what those data mode= ls > might look like, but..." > =20 > =20 > =20 > Agreed. I suggest developing a starter data model based on a set of lega= cy > requirements and requirements not being met by the current data set would= be > useful. I think defining an easily extensible data model is critical. > =20 > =20 > =20 > I'm not very interested in discussing YAPP (Yet Another Provisioning > Protocol), but very interested to discuss association of new non-traditio= nal > services and their identifiers and parameters with telephone numbers. > =20 > =20 > =20 > =20 >=20 > Best regards, > =20 > =20 > =20 > =20 > =20 > Pierce Gorman > =20 > Core Network Planning > =20 > O: 913-439-4368 > =20 > pierce.gorman@sprint.com > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: May 12, 2015 2:18 PM > To: Gorman, Pierce A [CTO]; McGarry, Tom; modern@ietf.org > Subject: Re: [Modern] MODERN will solve no problems (or will the IETF ta= ke > over the world?) > =20 > =20 > =20 > =20 > =20 > Pierce,=20 > =20 > See my comments inline. > =20 > Steve > =20 > =20 >=20 > On 5/8/15 12:58 PM, Gorman, Pierce A [CTO] wrote: > =20 > =20 >> =20 >> Steve, >> =20 >> =20 >> =20 >> Here is a suggested set of changes to the 2nd paragraph. >> =20 >> =20 >> =20 >> OLD: >> =20 >> =20 >> =20 >> The working group will define a framework for the roles and functions >> involved in managing and resolving TNs in an IP environment. This includ= es a >> protocol mechanism for acquiring TNs, which will provide an enrollment >> process for the individuals and entities that use and manage TNs. TNs ma= y >> either be managed in a hierarchical tree, or in a distributed peer-to-pe= er >> architecture. Privacy of the enrollment data and security of the resour= ce >> will be primary considerations. >> =20 >> =20 >> =20 >> NEW: >> =20 >> =20 >> =20 >> The working group will define a an information management framework for = the >> roles and functions involved in managing and resolving TNs associating >> SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more = TNs >> in an IP environment. This includes a protocol mechanism for acquiring T= Ns, >> which will provide an enrollment process for the individuals and entitie= s >> that use and manage TNs. TNs may either be managed in a hierarchical tre= e, or >> in a distributed peer-to-peer architecture. Privacy of the enrollment >> managed data and security of the resource will be primary considerations= . >> =20 >> =20 >> =20 > =20 > SRD> I'm mostly okay with your changes other then removing the wording on= the > protocol work. I believe there is enough support for doing the protocol = work > that this should remain in the charter. I'm not sure we need to define = the > concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework m= ight > come up with different terms and/or roles. > =20 > =20 > =20 >> =20 >> I would prefer if others weighed in here. I don't like being one of a f= ew >> with such influence. >> =20 >> =20 >> =20 > =20 > SRD> Agreed. > =20 > =20 > =20 >> =20 >> Because I wasn't at the BoF and am new at this sort of thing, I personal= ly >> would be happier if we took more time in e-mail or meetings to discuss t= he >> problems the WG should address, not the solutions (at first). >> =20 > =20 > SRD> Yes we need more discussion. That is what the working group is for.= The > charter is to define the scope of the working group effort. We don't nee= d to > have all of the answers now. > =20 > =20 > =20 >> =20 >> =20 >> =20 >> A specific area of concern for me is the data model of information assoc= iated >> with telephone numbers. I care much more about what is being provision= ed >> then I do about how it is provisioned or shared. >> =20 > =20 > SRD> I actually don't think it is the job of the MODERN working group to > define detailed data models. We clearly need to have some assumptions ab= out > what those data models might look like, but I would assume that each numb= er > management authority would determine what data is associated with a numbe= r. > =20 > SRD> I also think the how is important as the resulting mechanism, be it= a > new one defined by the group or an existing one recommended by the group,= will > need to be flexible and extensible to be able to address the problems out= lined > by Henning.=20 > =20 >> =20 >> I think trying to identify the what first will be more valuable than the= how, >> and certainly more important than the who. >> =20 > =20 > SRD> Agreed and the proposed deliverables are in the order listed for tha= t > very reason. > =20 > =20 > =20 >> =20 >> =20 >> =20 >> Best regards, >> =20 >> =20 >> =20 >> =20 >> =20 >> Pierce Gorman >> =20 >> Core Network Planning >> =20 >> O: 913-439-4368 >> =20 >> pierce.gorman@sprint.com >> =20 >> =20 >> =20 >> =20 >> =20 >> -----Original Message----- >> =20 >> From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz >> ] >> =20 >> Sent: May 05, 2015 9:54 AM >> =20 >> To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ietf.org >> >> =20 >> Subject: Re: [Modern] MODERN will solve no problems (or will the IETF ta= ke >> over the world?) >> =20 >> =20 >> =20 >> "=A9 define a framework for the roles and functions involved in managing a= nd >> resolving TNs =A9" is a necessary step to create a common understanding, f= or a >> WG, of the ecosystem for managing TNs. >> =20 >> =20 >> =20 >> For example the WG could define a communications service user, a >> communications service provider, a numbering authority, a numbering >> administrator, etc.; describe the functions of these roles and how they = may >> interact with each other. Both presentations at the BoF did a good job = of >> starting this discussion. >> =20 >> =20 >> =20 >> As the charter states, the work done by the WG would be flexible enough = to >> accommodate different administrative models, therefore the framework, ro= les >> and functions would need to be flexible. There is no intent to create a >> single administrative model, and there is no text in the charter that wo= uld >> suggest otherwise. In fact the charter states this explicitly. >> =20 >> If there are text changes you could suggest that makes this clearer for = you >> and others, please do. >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" > > >> =20 >> wrote: >> =20 >> =20 >> =20 >>> >Thanks Steve. I don't think wordsmithing "framework" to be >> =20 >>> >"architectural framework" in the 2nd paragraph really addresses the >> =20 >>> >underlying concern. >> =20 >>> >=20 >> =20 >>> >I understand the temptation to jump right in and have MODERN develop a >> =20 >>> >newer, better, solution to the existing (North American?) framework >> =20 >>> >architecture but it feels like a bridge too far. I'd suggest striking >> =20 >>> >the 2nd paragraph entirely, but I suspect that is also as unappealing >> =20 >>> >to you as the paragraph is to me. >> =20 >>> >=20 >> =20 >>> >I liked Eric Burger's suggestions regarding fleshing out problems by >> =20 >>> >describing use cases. >> =20 >>> >=20 >> =20 >>> >One use case that occurs to me that might lead in the direction I thin= k >> =20 >>> >you're interested in is I've not seen sufficient description of how to >> =20 >>> >associate "services" with telephone numbers. For example, many people >> =20 >>> >are members of more than one social networking application, and some >> =20 >>> >social network applications offer services which overlap with >> =20 >>> >traditional telecommunications and therefore could benefit from >> =20 >>> >assocation with number_user telephone numbers. >> =20 >>> >=20 >> =20 >>> >I think it would be useful to explore how those services could be >> =20 >>> >defined syntactically, managed, and discovered. But maybe that's just >> =20 >>> >me. Maybe others find that useless and/or objectionable. It does see= m >> =20 >>> >like the direction you were wanting things to go in terms of giving >> =20 >>> >number_users control over service provider associations with their >>> telephone number. >> =20 >>> >And it seems directionally correct in terms of addressing the interest= s >> =20 >>> >of users and non-traditional communications service providers for >> =20 >>> >service provider mash-ups associated with a telephone number. >> =20 >>> >=20 >> =20 >>> >I know I haven't directly answered your question about specific >> =20 >>> >suggested changes to the text in the charter. I would like to hear >> =20 >>> >more from others. >> =20 >>> >=20 >> =20 >>> >Best regards, >> =20 >>> >=20 >> =20 >>> >=20 >> =20 >>> >Pierce Gorman >> =20 >>> >Core Network Planning >> =20 >>> >O: 913-439-4368 >> =20 >>> >pierce.gorman@sprint.com >> =20 >>> >=20 >> =20 >>> >=20 >> =20 >>> >-----Original Message----- >> =20 >>> >From: Modern [mailto:modern-bounces@ietf.org >>> ] On Behalf Of Steve >> =20 >>> >Donovan >> =20 >>> >Sent: May 04, 2015 1:30 PM >> =20 >>> >To: modern@ietf.org >> =20 >>> >Subject: Re: [Modern] MODERN will solve no problems (or will the IETF >> =20 >>> >take over the world?) >> =20 >>> >=20 >> =20 >>> >Pierce, >> =20 >>> >=20 >> =20 >>> >See my comments inline. >> =20 >>> >=20 >> =20 >>> >Regards, >> =20 >>> >=20 >> =20 >>> >Steve >> =20 >>> >=20 >> =20 >>> >On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote: >> =20 >>>> >> If we can agree we eliminate the charter language that implies >> =20 >>>> >>creating a framework which supplants the authority of the NANC (at >> =20 >>>> >>least) and which assumes a replacement of the NPAC and LERG database= s, >> =20 >>>> >>we will have made progress (IMHO). >> =20 >>> >SRD> This should be easy to do, as there is no intent and, even if >> =20 >>> >SRD> there >> =20 >>> >were intent, there is no ability for the MODERN group to take anyone's >> =20 >>> >authority or replace anyone's database. >> =20 >>> >=20 >> =20 >>> >SRD> Is the problem with the word framework in the second paragraph? >> =20 >>> >Would calling it an "architectural framework" help? >> =20 >>>> >>=20 >> =20 >>>> >> Beyond striking objectionable language, the reason for David Holmes= ' >> =20 >>>> >>posts following mine last week was to try to improve the focus of th= e >> =20 >>>> >>work for MODERN. We do think it is a bad idea to ignore that number >> =20 >>>> >>administration and routing solutions need to evolve. And we're not >> =20 >>>> >>against the MODERN working group identifying problems. In fact we'r= e >> =20 >>>> >>in favor of it. Its what to do past that where we're struggling. >> =20 >>> >SRD> I share the desire to focus the work. I think the revisions of >> =20 >>> >SRD> the >> =20 >>> >charter have moved in this direction. >> =20 >>>> >>=20 >> =20 >>>> >> The thing I'm concerned about is a repeat of the e164.arpa fiasco >> =20 >>>> >>which succeeded in defining a global schema and protocol for managin= g >> =20 >>>> >>numbers and resolving them for routing and which failed utterly. >> =20 >>> >SRD> We fail if we don't learn from our mistakes. I'm confident we >> =20 >>> >SRD> will >> =20 >>> >have enough involvement in the group to keep us pointed in the right >> =20 >>> >direction. >> =20 >>>> >>=20 >> =20 >>>> >> Best regards, >> =20 >>>> >>=20 >> =20 >>>> >>=20 >> =20 >>>> >> Pierce Gorman >> =20 >>>> >> Core Network Planning >> =20 >>>> >> O: 913-439-4368 >> =20 >>>> >> pierce.gorman@sprint.com >> =20 >>>> >>=20 >> =20 >>>> >>=20 >> =20 >>>> >> -----Original Message----- >> =20 >>>> >> From: Modern [mailto:modern-bounces@ietf.org >>>> ] On Behalf Of Steve >> =20 >>>> >> Donovan >> =20 >>>> >> Sent: May 01, 2015 4:24 PM >> =20 >>>> >> To: modern@ietf.org >> =20 >>>> >> Subject: [Modern] MODERN will solve no problems (or will the IETF >> =20 >>>> >> take over the world?) >> =20 >>>> >>=20 >> =20 >>>> >> The question of what problem(s) MODERN will address has been asked, >> =20 >>>> >>multiple times. >> =20 >>>> >>=20 >> =20 >>>> >> The short answer is that, in an of itself, MODERN will solve no >> =20 >>>> >>problems. >> =20 >>>> >>=20 >> =20 >>>> >> This isn't to say there aren't problems with existing mechanisms. I= t >> =20 >>>> >>is to say that all MODERN can do is to specify protocols that can th= en >> =20 >>>> >>be part of an overall solution that addresses problems that exist wi= th >> =20 >>>> >>those existing mechanisms. >> =20 >>>> >>=20 >> =20 >>>> >> There is a brief capture of these problems in the latest version of >> =20 >>>> >> the >> =20 >>>> >> charter: >> =20 >>>> >>=20 >> =20 >>>> >> "A sample of problems with existing mechanisms include: >> =20 >>>> >>=20 >> =20 >>>> >> - lack of flexibility (for example, it can be difficult to add fiel= ds >> =20 >>>> >>without a very elaborate and lengthy process typically spanning year= s) >> =20 >>>> >> - lack of distribution (for example, it is hard or impossible to ha= ve >> =20 >>>> >>more than one administrator for each database) >> =20 >>>> >> - complexity (leading, for example, to a fair amount of rural call >> =20 >>>> >>completion problems which aren't helped by small providers strugglin= g >> =20 >>>> >>to keep numbers straight) >> =20 >>>> >> - difficulty of adopting more modern allocation (e.g., "blocks" of = 1) >> =20 >>>> >>and porting mechanisms" >> =20 >>>> >>=20 >> =20 >>>> >> Will MODERN solve these problems? No. >> =20 >>>> >>=20 >> =20 >>>> >> Will MODERN make it possible for these problems to be addressed as >> =20 >>>> >>part of new number management policies to be enacted by the >> =20 >>>> >>appropriate authorities? That, I believe, is the goal. >> =20 >>>> >>=20 >> =20 >>>> >> Will MODERN force any of these new number management policies to be >> =20 >>>> >>enacted. No. The IETF is not a policy setting body. >> =20 >>>> >>=20 >> =20 >>>> >> I'm ok with having a more detailed articulation of the problem >> =20 >>>> >>statement as part of the deliverables of the MODERN working group. I >> =20 >>>> >>don't see the benefit of making that the only deliverable and forcin= g >> =20 >>>> >>rechartering after that document is finished. Let's instead agree t= o >> =20 >>>> >>shut the working group down if there is consensus that it is going >> =20 >>>> >>nowhere (which I'm sure the ADs will do anyway). >> =20 >>>> >>=20 >> =20 >>>> >> Regards, >> =20 >>>> >>=20 >> =20 >>>> >> Steve >> =20 >>>> >>=20 >> =20 >>>> >> _______________________________________________ >> =20 >>>> >> Modern mailing list >> =20 >>>> >> Modern@ietf.org >> =20 >>>> >>=20 >> =20 >>>> >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il >>>> >> =20 >>>> >>man >> =20 >>>> >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee= ID >> =20 >>>> >>cLe >> =20 >>>> >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7= w& >> =20 >>>> >>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> =20 >>>> >>=20 >> =20 >>>> >> ________________________________ >> =20 >>>> >>=20 >> =20 >>>> >> This e-mail may contain Sprint proprietary information intended for >> =20 >>>> >>the sole use of the recipient(s). Any use by others is prohibited. I= f >> =20 >>>> >>you are not the intended recipient, please contact the sender and >> =20 >>>> >>delete all copies of the message. >> =20 >>>> >>=20 >> =20 >>>> >> _______________________________________________ >> =20 >>>> >> Modern mailing list >> =20 >>>> >> Modern@ietf.org >> =20 >>>> >>=20 >> =20 >>>> >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il >>>> >> =20 >>>> >>man >> =20 >>>> >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee= ID >> =20 >>>> >>cLe >> =20 >>>> >>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7= w& >> =20 >>>> >>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> =20 >>>> >>=20 >> =20 >>> >=20 >> =20 >>> >_______________________________________________ >> =20 >>> >Modern mailing list >> =20 >>> >Modern@ietf.org >> =20 >>> >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= m >>> >> =20 >>> >an_ >> =20 >>> >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDc= L >> =20 >>> >ext >> =20 >>> >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= h >> =20 >>> >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> =20 >>> >=20 >> =20 >>> >________________________________ >> =20 >>> >=20 >> =20 >>> >This e-mail may contain Sprint proprietary information intended for th= e >> =20 >>> >sole use of the recipient(s). Any use by others is prohibited. If you >> =20 >>> >are not the intended recipient, please contact the sender and delete >> =20 >>> >all copies of the message. >> =20 >>> >=20 >> =20 >>> >_______________________________________________ >> =20 >>> >Modern mailing list >> =20 >>> >Modern@ietf.org >> =20 >>> >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= m >>> >> =20 >>> >an_ >> =20 >>> >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDc= L >> =20 >>> >ext >> =20 >>> >Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3D= h >> =20 >>> >tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D >> =20 >> =20 >> =20 >> =20 >> =20 >> ________________________________ >> =20 >> =20 >> =20 >> This e-mail may contain Sprint proprietary information intended for the = sole >> 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 t= he >> message. >> =20 >> =20 >> =20 >> _______________________________________________ >> =20 >> Modern mailing list >> =20 >> Modern@ietf.org >> =20 >> https://www.ietf.org/mailman/listinfo/modern >> >> =20 >> =20 >> =20 >> =20 >>=20 >> =20 >> =20 >>=20 >>=20 >> This e-mail may contain Sprint proprietary information intended for the= sole >> 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 t= he >> message. >> =20 > =20 > =20 > =20 > =20 > =20 >=20 > =20 > This e-mail may contain Sprint proprietary information intended for the = sole > 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 th= e > message. > =20 > =20 > =20 > _______________________________________________ > Modern mailing list > Modern@ietf.orghttps://www.ietf.org/mailman/listinfo/modern > =20 =20 =20 _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3514360508_296839 Content-type: text/html; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable

= From: Steve Donovan <srdonovan@usdonovans.com>
Date: Wednesday, May 13, 2015 at 10:11 AM
To: <modern@ietf.org>
Subject: = Re: [Modern] MODERN will solve no problems (or will the IETF take over the w= orld?)

Pierce,

Protocol work doesn't necessarily mean new protocols will be developed.  It could also result in a recommendation to use or bui= ld on  existing protocols. [Been there done that]
<= div>
RS> That is a profile. The IETF doesn’t do profi= les or at least it doesn’t do profiles very well.


To your question: "Today those number management authorities also determine the protocol mechanisms for enrolling (i.e., assigning) and managing telephone numbers.  What reason is there to believe they will spontaneously adopt what MODERN developed?"

Nothing happens spontaneously but if we do our work well then we give the authorities another option, one that addresses the shortcomings in the existing mechanisms.

To your point: "I’m not very interested in discussing YAPP (Yet Another Provisioning Protocol), but very interested to discuss association of new non-traditional services and their identifiers and parameters with telephone numbers."

If we end up creating a new set of protocols, hopefully it will be ABPP (A Better Provisioning Protocol) :-).  I believe the latter part of your statement is one of the motivators for the proposed working group.


RS&= gt;  Rat hole alert.  The IETF does not have a good record here as= well. You can make the case that the entire IETF PROVREG construct for the = domain name industry was a failure since it ended up being finely tailored t= o the requirements of ICANN and not a general purpose provisioning protocol.=


I propose the following, which keeps the protocol work.

Old (from the "revised revised" email):

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment.  It will also define protocol mechanisms for acquirin= g and resolving TNs.  The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of t= he enrollment data and security of the resource will be primary considerations.  The protocol mechanism for resolving TNs will all= ow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM).

RS> Please take this o= ut the CNAM issue. This is different on multiple levels. Don’t mention= CNAM at all. 

  Maintaining reliability, real = time application performance, security and privacy are primary considerations.  The working grou= p will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS.

New:

The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment.  The working group will also= define protocol mechanisms to support the interactions between the functions defined by the framework.  This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs.  The protocol mechanism for acquiri= ng TNs will provide an enrollment process for the individuals and entities that use and manage TNs.

RS> Please on’t say anyhting about individuals that is a policy i= ssue. Entities ..what ever they are.

TNs may either be ma= naged in a hierarchical tree, or in a distributed peer-to-peer architecture. = Privacy of the managed data and security of the resource will be primary considerations.  The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time application performance, security and privacy are primary considerations.  The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS.

Regards,

Steve

On 5/12/15 5:10 PM, Gorman, Pierce A [CTO] wrote:

Thanks Steve.

 

“SRD>   …I'm not sure we need to = define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles.”

 

I’m not sure how you want to word this and I’m not married to= what I suggested.  I was implying information in a data model.  I picked those three fields because I thought they= are fundamentally what has been described to associate with one or more telephone numbers (assuming we can agree what a TN is).

 

How about we remove any reference to what information is being associated with telephone numbers like this…

 

NEW-ER #0:=

 

=

The working group will define a an information management framework for the roles and functions involved in managing and resolving TNs associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment managed data and security of the resource will be primary considerations.

 <= /p>

“SRD> I'm mostly okay with your changes other then removing the wording on the protocol work.  I believe there is enough support for doing the protocol work that this should remain in the charter.”

 

Well, if there’s enough support you can ignore me.  J=   = The heartburn I have with leaving the protocol work in there is I’m not convinced new protocol mechanisms are needed.

 

Even if it was inarguable that new protocol mechanisms are needed, won’t this still point back to your point about, = “each number management authority would determine what data is associated with a number”?

 

Today those number management authorities also determine the protocol mechanisms for enrolling (i.e., assigning) and managing telephone numbers.  What reason is there to belie= ve they will spontaneously adopt what MODERN developed?  This= is starting to feel like TRIP2.0.

 

I think the number management authorities have to respect users and communications service providers want to create associations of new non-traditional kinds of information with one or more telephone numbers.

 

I don’t think that necessarily implies they also have to respect any suggested protocol mechanisms for managing the information assocations.  And the number management authorities would necessarily be facing that conversation at some point, will they not?

 

“SRD> We clearly need to have some assumptions about what those data models might look like, but…”

 

Agreed.  I suggest developing a starter data model based on a set of legacy requirements and requirements not being met by the current data set would be useful.  I think defining an easily extensible data model is critical.

=

 

I’m not very interested in discussing YAPP (Yet Another Provisioning Protocol), but very interested to discuss association of new non-traditional services and their identifiers and parameters with telephone numbers.

 

Best regards,

 

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.go= rman@sprint.com

=

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: May 12, 2015 2:18 PM
To: Gorman, Pierce A [CTO]; McGarry, Tom; modern@ietf.org
Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)=

 

Pierce,

See my comments inline.

Steve

On 5/8/15 12:58 PM, Gorman, Pierce A [CTO] wrote:

Steve,

 

Here is a suggested set of changes to the 2nd paragraph.

 

OLD:

 

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment data and security of the resour= ce will be primary considerations.

 

NEW:

 

The working group will define a an information management framework for the roles and functions involved in managing and resolving TNs associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the = enrollment managed data and security of the resource will be primary considerations.

 

SRD> I'm mostly okay with your changes other then removing the wording on the protocol work.  I believe there is enough support for doing the protocol work that this should remain in the charter.   I'm not sur= e we need to define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles. 

I would prefer if others weighed in here.  I don’t like being one of a few with such inf= luence.

 

SRD> Agreed.

Because I wasn’t at the BoF and am = new at this sort of thing, I personally would be happier if we took more time in e-mail or meetings to discuss the problems the WG should address, not the solutions (at first).=

SRD> Yes we need more discussion.  That is what the working group is for.  The charter is to define the scope of the working group effort.  We don't ne= ed to have all of the answers now.

 

A specific area of concern for me is the data model of information associated with telephone numbers.   I care much more about what is being provi= sioned then I do about how it is provisioned or shared.

=

SRD> I actually don't think it is the job of the MODERN working group to define detailed data models.  We clearly need to have some assumptions about wh= at those data models might look like, but I would assume that each number management authority would determine what data is associated with a number.

SRD> I also think the how is important as the resulting mechanism, be it a new one defined by the group or an existing one recommended by the group, will need to be flexible and extensible to be able to address the problems outlined by Henning.

I think trying to identify the what first will be more valuable than the how, and certainly more important than the who.

SRD> Agreed and the proposed deliverables are in the order listed for that very reason.

 

Best regards,

 

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

 

 

-----Original Message-----

=

From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]

=

Sent: May 05, 2015 9:54 AM

=

To: Gorman, Pierce A [CTO]; Steve Donovan; modern@ie= tf.org

Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)<= /o:p>

 

"=A9 define a framework for the roles and functions involved in managing and resolving TNs =A9" is a necessary step to create a common understanding, for a WG, of the ecosystem for managing TNs.

 

For example the WG could define a communications service user, a communications service provider, a numbering authority, a numbering administrator, etc.; describe the functions of these roles and how they may interact with each other.  Both presentations at the BoF d= id a good job of starting this discussion.

 

As the charter states, the work done by the WG would be flexible enough to accommodate different administrative models, therefore the framework, roles and functions would need to be flexible.  There is no intent t= o create a single administrative model, and there is no text in the charter that would suggest otherwise.  In fact the charter states this explicitly.

If there are text changes you could suggest that makes this clearer for you and others, please do.

 

 

 

On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" <Pierce.Gorm= an@sprint.com>

wrote:

 

>Thanks Steve.  I don't think wordsmithing "framework" to be

>"architectural framework" in the 2nd paragraph really addresses the

>underlying concern.

> 

>I understand the temptation to jump right in and have MODERN develop a

>newer, better, solution to the existing (North American?) framework

>architecture but it feels like a bridge too far.  I'd suggest striking

>the 2nd paragraph entirely, but I suspect that is also as unappealing

>to you as the paragraph is to me.

> 

>I liked Eric Burger's suggestions regarding fleshing out problems by

>describing use cases.

> 

>One use case that occurs to me that might lead in the direction I think

>you're interested in is I've not seen sufficient description of how to

>associate "services" with telephone numbers.  For example, many people

>are members of more than one social networking application, and some

>social network applications offer services which overlap with

>traditional telecommunications and therefore could benefit from

>assocation with number_user telephone numbers.

> 

>I think it would be useful to explore how those services could be

>defined syntactically, managed, and discovered.  But maybe that's just

>me.  Maybe others find that useless and/or objectionable.  It does seem

>like the direction you were wanting things to go in terms of giving

>number_users control over service provider associations with their telephone number.

>And it seems directionally correct in terms of addressing the interests

>of users and non-traditional communications service providers for

>service provider mash-ups associated with a telephone number.

> 

>I know I haven't directly answered your question about specific

>suggested changes to the text in the charter.  I would like to hear

>more from others.

> 

>Best regards,

> 

> 

>Pierce Gorman

>Core Network Planning

>O: 913-439-4368

>pierce.gorman@sprint.com

> 

> 

>-----Original Message-----=

>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve

>Donovan

>Sent: May 04, 2015 1:30 PM=

>To: m= odern@ietf.org

>Subject: Re: [Modern] MODERN will solve no problems (or will the IETF

>take over the world?)

> 

>Pierce,

> 

>See my comments inline.

> 

>Regards,

> 

>Steve

> 

>On 5/4/15 11:32 AM, Gorman, Pierce A [CTO] wrote:

>> If we can agree we eliminate the charter language that implies

>>creating a framework which supplants the authority of the NANC (at

>>least) and which assumes a replacement of the NPAC and LERG databases,

>>we will have made progress (IMHO).

>SRD> This should be easy to do, as there is no intent and, even if

>SRD> there

>were intent, there is no ability for the MODERN group to take anyone's

>authority or replace anyone's database.

> 

>SRD> Is the problem with the word framework in the second paragraph?

>Would calling it an "architectural framework" help?

>> 

>> Beyond striking objectionable language, the reason for David Holmes'

>>posts following mine last week was to try to improve the focus of the

>>work for MODERN.  We do thin= k it is a bad idea to ignore that number

>>administration and routing solutions need to evolve.  And we're not

>>against the MODERN working group identifying problems.  In fact we're

>>in favor of it.  Its what to= do past that where we're struggling.

>SRD> I share the desire to focus the work.  I think the revisions of

>SRD> the

>charter have moved in this direction.

>> 

>> The thing I'm concerned about is a repeat of the e164.arpa fiasco

>>which succeeded in defining a global schema and protocol for managing

>>numbers and resolving them for routing and which failed utterly.

>SRD> We fail if we don't learn from our mistakes.  I'm confident we

>SRD> will

>have enough involvement in the group to keep us pointed in the right

>direction.

>> 

>> Best regards,

>> 

>> 

>> Pierce Gorman

>> Core Network Planning=

>> O: 913-439-4368

>> pierce.gorman@sprint.com

>> 

>> 

>> -----Original Message-----<= /o:p>

>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve

>> Donovan

>> Sent: May 01, 2015 4:24 PM<= /o:p>

>> To: modern@ietf.org

>> Subject: [Modern] MODERN will solve no problems (or will the IETF

>> take over the world?)=

>> 

>> The question of what problem(s) MODERN will address has been asked,

>>multiple times.

>> 

>> The short answer is that, in an of itself, MODERN will solve no

>>problems.

>> 

>> This isn't to say there aren't problems with existing mechanisms. It

>>is to say that all MODERN can do is to specify protocols that can then

>>be part of an overall solution that addresses problems that exist with

>>those existing mechanisms.

>> 

>> There is a brief capture of these problems in the latest version of

>> the

>> charter:

>> 

>> "A sample of problems with existing mechanisms include:

>> 

>> - lack of flexibility (for example, it can be difficult to add fields

>>without a very elaborate and lengthy process typically spanning years)

>> - lack of distribution (for example, it is hard or impossible to have

>>more than one administrator for each database)

>> - complexity (leading, for example, to a fair amount of rural call

>>completion problems which aren't helped by small providers struggling

>>to keep numbers straight)

>> - difficulty of adopting more modern allocation (e.g., "blocks" of 1)

>>and porting mechanisms"

>> 

>> Will MODERN solve these problems? No.

>> 

>> Will MODERN make it possible for these problems to be addressed as

>>part of new number management policies to be enacted by the

>>appropriate authorities?  That, I believe, is the goal.

>> 

>> Will MODERN force any of these new number management policies to be

>>enacted.  No.  The IETF= is not a policy setting body.

>> 

>> I'm ok with having a more detailed articulation of the problem

>>statement as part of the deliverables of the MODERN working group. I

>>don't see the benefit of making that the only deliverable and forcing

>>rechartering after that document is finished.  Let's instead agree to

>>shut the working group down if there is consensus that it is going

>>nowhere (which I'm sure the ADs will do anyway).

>> 

>> Regards,

>> 

>> Steve

>> 

>> _______________________________________________

>> Modern mailing list

>> = Modern@ietf.org

>> 

>>https://urldefense.proofpoint= .com/v2/url?u=3Dhttps-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=3DAwICAg&= ;c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7T= Z4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D

>> 

>> ________________________________

>> 

>> This e-mail may contain Sprint proprietary information intended for

>>the sole 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.

>> 

>> _______________________________________________

>> Modern mailing list

>> = Modern@ietf.org

>> 

>>https://urldefense.proofpoint= .com/v2/url?u=3Dhttps-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=3DAwICAg&= ;c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeID

>>cLe

>>xtZ1ooNcfp01IYIaVqsORjI&m=3DO7T= Z4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&

>>s=3Dh tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D

>> 

> 

>_____________________________________= __________

>Modern mailing list

>Moder= n@ietf.org

>https://urldefense.proofpoint.co= m/v2/url?u=3Dhttps-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=3DAwICAg&c=3DMO= ptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6B= oXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3Dh

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D

> 

>________________________________=

> 

>This e-mail may contain Sprint proprietary information intended for the

>sole 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.=

> 

>_____________________________________= __________

>Modern mailing list

>Moder= n@ietf.org

>https://urldefense.proofpoint.co= m/v2/url?u=3Dhttps-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=3DAwICAg&c=3DMO= ptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcL

>ext

>Z1ooNcfp01IYIaVqsORjI&m=3DO7TZ4YM6B= oXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=3Dh

>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=3D

 

 

________________________________

 

This e-mail may contain Sprint proprietary information intended for the sole 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.

 

_________________________________________= ______

Modern mailing list

Modern@ie= tf.org

https://www.ietf.org/mailman/listinfo/modern

 

<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",serif">


This e-mail may contain Sprint proprietary information intended for the sole 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.

 



This e-mail may contain Sprint proprietary information intended for the sole 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.
 

_______________________________________________
Modern mailing list
Modern@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/modern

_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3514360508_296839-- --B_3514360507_267731 Content-type: image/png; name="Preview Document"; x-mac-type="504E4766" Content-ID: Content-disposition: inline; filename="Preview Document" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAU8AAAA8CAYAAADmDDgpAAAT+klEQVR42uydCWyU55nHU2kr VRtVmkqrXVW7ap22q12ttqvpVlXVNGldqWk4kmLCEcAcA76wx/PF5KIhJEwIBBIIDEm4CZlw XwnmCkc4hvtwTIbLHMHGYDAYbBgwYGzAs/8/+l766t05GNsxE/tB+on53pnvnO/7zfM+z/t9 fgT/AoIgCELCPBIWBEEQEuYRryAIgpAg4XBYEARBSJB2fwAEQRBEnoIgCCJPQRAEkacgCILI UxAEob3T7g+AIAiCyFMQBEHk+fC4XfGDFOBo78dBEASRZ0JQnCAAvO39WAiCIPJMVKBOEAJB kNLej4cgCCLPRASaCsK2RJ3t/XgIgiDyTESgBUqgEoEKgiDyTEyghbZAg8ChtfuBq70fH0EQ eQqxCkjltkD9WruLbd+qQM92+R74B/AD8Cj4IXCAfwL/DH4M/hX8BPwM/AL8B/gv8EvgBP8L fgN+B34P/gBSwZ/BX0BH0Bk8C7qCbqAn6AX6gv7ABTJANsgFbuABL4CXwCtgKBgG3gAjwFtg FBgD3gXjwPtgIvgQTAZTwXQwC8wGfjAHzAcLwWKwFHwOCsFKsBp8AdaDL8EmsBlsBdvBTrAb 7AVFoBjsB0FwCBwGJeAYOAFOglJwCpwGFeAsqATnQRW4CKpBDbgCQuAaqAU3wE1QB26BetAA boM74C5otAnbNLLd5o79+Xp7/jpw015urb2eq/Z6L9vbcQlU2dtXaW9vBTht70epvV/H7f0s sff7IAjax6PYPj57wC6w0z5+Aft4bgQbwFqwBqwCK+zvYhlYAhaBBWAu+BR8Aj4GM8A0MNn+ rn1gAhhvnwtj7HNjpH2uvGGfO0Ptc+kl+9zyADcYDLLBIOCyz8l0+xztYZ+zafY53Al0AE+B P4E/gifA4+C34NfgV+B/wH+D/wT/Dn4OUsC/2dfVv9jX2Y/s6+5R+zr8PvheuxdjggWksE2a kqreJvIUeYo8RZ5C/PynQ3Xp9TaRp8hT5CnyFCILNKC674ZQicuIVL0iT5GnyFPkKfy9qx4C YVuQKZo8CyPkQwPAIfIUeYo8RZ7tHuY3lRg5rRWTQtpnvJpUAyJPkafIU+QpAAjRZ4sxFfg1 UaYY8lS4RJ4iT5GnyLPdow1fKlSRqE1qFHkWijxFniJPkWer8thjP0sBqcCRpLdvPqFJssAo LCkCxnw+4BB5ijxFnm1MnhBVGvCCgEah3ZbSiuJMA2GbUEuv25ayD7iaKFAv8Gt5T28seRrv lQOnyFPkKfJsA/KERJygHIRjkNqK8iw01l3QgssOaMv1NnP40gJDniFDnj4jWlWEgEPk+eDy XPCxFVw42zrQ0vI8V5xRMeOD/NDMDz1XwTWR57cnzzWLrPnTJuWvbCvyVOIMgXAcHK0ozwJj 3c4klKcTLDDGf4YNXHrUaVCQjPJ847XsTx9//Ilw/349i7Oz0nfw9cg3cxa3tDw/merZ8t6o vP3g69LdOcuUPMePyTv0/pi8wxPGuo+U7claR3muWmjt43aQRbOtQy0pz33r889zuYrmynP2 FM9d0EiUPC8EB4axv/dge3uV56gRg7cP6P/86bYhT1MmwOyiM+JUkV9roqUP0jidZPJUAn1S dc9VdGmQorWbeJNNnri4vVmZ6VspkezM9O3Pde1yRskTEdqLLSnPjEF9KpWwNi73rFPy1EW2 daW1jfK8XNJvbb++Pa927tTp9oHN7l3JLE9jWY0kuMkd1ttFnm1AnpRkpO5xspGs8iSaPNMM OQbt94NR5Jmi35UEHA9bnvoFbrLEb1F+bohgxPC/Za19c1j2+rFv566E4CZ5h+dsemt4zuap E/OXK3lePOCaOPFd96bR3sE7wa5ZH+Wvrz48YAYvLERfmyHmWrXsoS9nnhz3Tt4BRJ0H9XUO ezXz9PxZ1v6tKz1cRtnrQ7PObl/tKSrfm7Xjg3Husg/Hu09hu46dKcos+uh99xlQsfRTq1SX 59mvMkqwXVVTffkX5860LhzdnnsKXcea6ZPyLxfOsy6a8qzcP6hq5keeWnAdqYLaa8f71Ojy PP/1wOsfT/bUg4bZkz23sW0NSp6MOvVlMdJc9InViOMU1tsZfX69yX1XyZPL4LIIl4t13FDy XL3QuoFjVwduVu4feLl4g/sKt0/J8+rxPudWzLeqsT9X5s20qvEjV055ni3OKMU+XyrZlnvS lOfkCe5zu7/wlCh5rltqleBYloNTB7fk7dXlyXQJjz+2dxN6AyU4/pvZMyjbk7NCl2fNkf5z 3x2VW7xhmbVSyRPfzap33srdze//2PbB0yLJc84Ma96IYdlfgg2fzbGmKHm+PjRzzeJPrAmm PF8eMuizT6dZI5NBnqlNyWuy0AK8NinAAQpAQMPH9kgRpUJLGxTa87g0qXsVMdbtVG1qGTZ+ 4DT200uM3G5AX0+Tc58g0hhPEiPqVOIMKdlyOpnliQt4utn+9NNP16nXiA5PUZ47VntmdujQ 4Zb52Y4dOtbvXZe/eNDA3ufstrggdXAJEj6upieNc5/EBfyVmu7Ro2sdI1J9HqQCLlASu9d6 TnTu3OmO/t4zz3S+LzhP/oA6U57PPvtMoz6NSPw2BHqZ8oTIbprbZ0fpjbUn+tRHei8nu6/Z pgTKeRqGvDCwMdL7yA/WUZ4Fluv+vr3gcTXoETKEVMX9IdyX53s+d5uv8QNBgR7ja/yoXdHl CbmVcn7KM3QsfZ9rQK/rnM7N6XcFYqvla0jrsJIntr+aUT/bu3VLu7F/o3vDc891uf63VzLL dHlCaNv4mW925czHj+Ss3r26XeK0y9Wrotfz3S7yNbavSpenle/6mu1903uW4nus5Gv+MFOe vXt3P4H1VOjyxDEZzs8kqzy9TYje0kBQTRuEzHyl8X6aMe2KtF2x1m1Mm6Rqwg7HoxkD5wOg 0CgI/VSJ0SBoitOYz/kwc57q4pwyIX8S/8eJf0wVjCCWGl2a6oTX5Vl1wPWuLk6+1qcpTkQZ BylS1danT/caSOpCVkZ6lbG8EKKW0mjyjAXl2bNH1/vroETz8/rf4Ot48qQw9TZGfcVf5tfq bbi4G/VpRG13TBG+WDAojO3nD0DYbF+7xLqLiPRurGWe2JlzXZenmV7Ad3MnMyO9AdFnheq2 Q2rXIakGyhORfA33W5cnegnVPC7sto94Pfsi3z8cyN2vuu3Y13vH+tTerICSZ6eOHRuYQlHd dkae/EzNkX6LlTz5HeL4UtrT0Cs5wO93z7r8+arbjmLf55xHyXPbKs9UTiNaXa267e7c/kU8 ryhP9UON+cYreTKVhO29lCzddkcEiXjZnoA84xWbymPIM2TKLiF5xh8hEGwFeRYALyjXI0v9 DiSzym6I0wTtjz7W2vLEhb84XuSpT6N7N5onPLtcujxxwa7TPwfxbQZbDCnMSyTnGUuejDrZ bcd2VBmRW5k+bXdfS9B1r4olz+M7BvPiPM9uu2qjwNCNbNAFi67srbFv593RxZdozlNv47Kw zHouW5P2LV2efA/H4sbKBVaI28m2LSusaj3nif05x3ZE+GcQgZbx9edzPBVKnpSlHZnv4WsI vNLMeXIe33vub5Q8+QOm5zwhzc8oVKZaKM+Tu3OWcp5lc6wNlCfFicJj0Mx5Ds7ue0LJEz+y Y7Afs/WcJ1NBXI7KefLHGvPsojyRfsl76qm/3MT3PDeZCka+KBGjHzhjyNP8fJomZL8ZYRry NOctUAPiE5BnxFytue5WyHmmgrGGIJ+JIk5nHHEqvMksT0QZ36iC0fK51nRdniPfyAnEiwrR dVzRUvLMHdwvpApGqs3u2lWo1wNdvetUwYhSiSZPRnGqYMTcoi4tJbFYJCJP5jzjLW/MyNwG fb2Iwq6rgtFXG9zV0eZT8uT+Mgod+nLGVcpTddmPbM09QnlGm9eUJ47/MbNgxG47u++UJ1ID R5jDVgUj+3xZE69ghB+yBThnysx1K3m+/WbOEk5jX18dNzpvFl/jhzIrmeTpMMZVmgRAShyB UV6xIlpfVHmagk5cnua6na0sTwf4SBPfa6A8ijhdnI7PP3ZtbXnuXOPJhdACaphS17S/nuZr XCQr2HUyI08UNYabkacpT+TTzqiCEQsHiK72gn2MPFtTnuTqsfSj8SJPdoMjyRP5u7u6xCC1 26pgZHOHNEeeesEI1BPmWPX1YptCpjwRvV0uWu+u4n6ASnAO4qzA/p7g/qIgc97e/0OQXA1y kDdVtZ3tjNjx3R8EQeSq9+PYFoMidttjyZMFI84/Z7q1g5EmilB7dHliXzaa8kQBsEjJE9/D Qn6OxUb+AKMn844ZeaL4NYTRJs9Bjvxgtz0p7zDS8odxc5dmt/0BotNAFHn62ZaYPOOvuxXl aT4wpBz4miNO4H9YOc+83P5rePK+8uKgz5U8UW19T+U8eSJr0dhlJvrNnCcqvIVqOq3LX69e PDjgAxQgVjDvaUaees5z03LPesrTrLZDPFuaIk9VLEo058lKNsRUo+c90WWvh/zr/z6ddZtD iii7WJEnq+zo0lKeZhTPsZ93cAzvt32x2GKVvW6INfC+VDGioD6aPDkqQMlT77az2o7RBNWs tlOe6O4etyV3Tv2oKHn26N71FuVpdttxjEuRk9wbS55gAfPUKnfNaruSJ9teGjLoqCnPLl2e DSl5QoRHsf7zsbrtYDD2f6M671gwSkZ5mpGbP0bu0hRQYZTl+B5AngXNlKc/SeSpBsEPjyJO /wOK0wccD0ueiKim4KRfhojn9VdfyliOIUSFuAg9Sp64iObqElASNavtKEhcUG0mkPI1jvNE seKQ+R7lCSFfMavtTZUnhr6U29Nxq+0mRgRci2FCV81KvCHKu5QnpGAWjbhfEavtIGbXHUWq G9HkCSqHvZpVx/3hUCXKE9X3Co97wE22qcgTHEYh5n7+tqIo45CSJ4ZSnbKLXaevHO274/S+ zF3oGZxh24PIE0O9Avws0gLf6OM82buwv6utlw65JmO7ZjDfqReMcG7tZnEIxapxlCe2xc9p U544Bq+xjZFnsj8YxBwDGjQLOjEFlLg8U5spT2+SyDMEpoKQIc4nVRU+DuUgNZlvz+QgeURM PkRdX6BifhD5wcMc54mxlUtMeWKM53h1segg93iWQ5UoTwxnuVehNeWJi2UdixHNleem5dZJ ChSjBi4w54eL9RrHeSJFcDaWPDF8pt7I/dWpcZ5IN9RiRMA94ZnFHg5VojwxVIcRpSlPVtf/ nzz5eXb3+Xmz4q+GKsWSJ6rslcgj3tDn5XAlNVRJyZMFI74Hidaag+Q5PlYf6sXXaqhSPHmi t7DBTrusNQfJs2DE9/QUDrvtesGIkac+eqN7967nTHnivCtgG3OeSS9PsyvfDHkG2oM8KT1b fjsiiDP4oNFmst/bjq72aP1EhzAKKU99nCejCf0OI3TZfZDGIrAEEciUSPe2I19XyJwnKriL 9HvbAyutAHOeTX0wCIoiJfrFqwbJQy5KzLxz6lqkB4Ogkl3NnCfGd16KdIcRutcc73iLRLu3 HV31RqLf2w7B3mtDV968w4jLqge3IOi6RO8w4lAl/ggw8mzqHUYq55nIHUb4vkvT+/S4HOsO I373jDyjPRgEIww+ZM4z2h1GiK5XsdvOavt3TZ7OZsgzpH+mDcvTB6bp4zhBp3gVdTUo/rv0 YBBEeVErtJQohDUxmZ6qxAKJvo1m9x1RzWl5qlLTbs/Ej90yVTD6Np+qhO+pGjcHfPmdep5n lPGRKZEFFP/BHm1YnpmGEPPiSDMECr6rj6RDN3Yehyoh4jjJghFBt3gnCiCjk/GRdOiynmHO j7BgRDDI+wqitTJ5JF3T5Yl85zYWjCDRhd+WPNcv9YzCSIfjHKqUjPJUuUmvLSwncNiv/WZl PFbRxhSn2WVPUnmWgxS1z00QZ4oWYfqBL14lXR6GLM/zlOd5trGnKsUhBBwJzqPmS0kyefpb 4g4jSlDLaY4FgThd9FT5MxwiT5Fn+5JnADgSmcccXJ9k8nS2kDz9IASGxLrVErjkbxiJPEWe bVOeacAX5U9vOB+kkq7N7zfni/VUpUhyTfCpSqnx1hGtEGbssw94EywSBcG4GNL0Aof8ATiR 5/+1d8cqbYVxGMaHikMQMthCEZR2EaSIAYvNolSXdNIShEDoYOkgLQ5aRBQlCKKIQ4sQKliE QEtQUAxiJbjoFYiX0EsIvYK+wqN8HEhOBqfkHX6LaAzf+X+PJzmR43j6BnAxZ3/tgf8UKsuf uPc1fd92x9PxdDwdT+EC0YL8rRPNhzNpx9PxdDwdT8cTvBRvGE3H0/F0PB1PxxOccV43iqbj 6Xg6no6n4xng3kS1uGj+u0mm7jiejqfj6XgCMVe8Ww2f46w0c/WceNbk9hHj+UQ6OXAJ6ZIk B7VbnnKgewhpr7wIYtrPgLxiWIaI6jBRfSNphmuUuI7LBAOYkXdBYKeIbFamJccQ5yOx/RgE d5bofpE5Nsa8fI3Ed5lNtCaFIMIbsilbsh2J8TeCvMtGLcqPIMz78lMO2NwlNvov+S1lHAax PpYTQnF6H26cE5MLwlIl5JfEXBQeoo4rXOOKr0Pfr5/DJY9X5fEv+H3nBOyMiJ3y/E7kmOd9 JASNqBE2KfEH6oD12Gd99ohckfXble9B7HZkm+BtygbRW5cC4VuVFY7fkixybOc51nNE8LPM MhOfIjH8IHlmKcdsZZm1yUgYM8zmhLyVsSCQaRmR10RySAaZ/QHpD2L5UvoIZo88l2fSzf5K Es4E+69TOu7jafG31qjJbTOf0ySeM5Jq97Uza2VtvwANopmSipTEITQzx7PJl+nv230dzMzx NDNzPM3MHE8zM8fTzMzxNDOzOv4DIDV//HSVjucAAAAASUVORK5CYII= --B_3514360507_267731-- From nobody Thu May 14 05:31:28 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 148A71A8AA1 for ; Thu, 14 May 2015 05:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] 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 RtmLixZeTShs for ; Thu, 14 May 2015 05:31:26 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 427291A8A97 for ; Thu, 14 May 2015 05:30:36 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:61488 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YssHV-000CDA-SQ for modern@ietf.org; Thu, 14 May 2015 05:30:35 -0700 Message-ID: <55549564.2020705@usdonovans.com> Date: Thu, 14 May 2015 07:30:28 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "modern@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] Removing CNAM from the MODERN charter 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, 14 May 2015 12:31:27 -0000 Richard has proposed removing CNAM from the charter. I will do so in the next revision unless we hear objections. Regards, Steve From nobody Thu May 14 05:40: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 8EDF51A90D7 for ; Thu, 14 May 2015 05:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] 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 1qjTS9NGBxbH for ; Thu, 14 May 2015 05:39:59 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 8C5BE1A9096 for ; Thu, 14 May 2015 05:36:58 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:61524 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YssNl-0004Et-3m for modern@ietf.org; Thu, 14 May 2015 05:36:57 -0700 Message-ID: <555496E9.4050601@usdonovans.com> Date: Thu, 14 May 2015 07:36:57 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "modern@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] Revised paragraph 2 of MODERN charter 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, 14 May 2015 12:40:00 -0000 All, I have made one change based on Richard's feedback, removing "individuals and", leaving just entities. This recognizes that an individual can be an entity in this context if supported by the the policy regime in place. I will remove the reference to CNAM if no one objects (see separate email thread). Here's the new proposed paragraph 2: The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment. The working group will also define protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs. The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the managed data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS. Regards, Steve From nobody Thu May 14 06:07:08 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 F38FF1A9175 for ; Thu, 14 May 2015 06:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, 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 GLXA2bHT7zXf for ; Thu, 14 May 2015 06:07:02 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 2BA761A0378 for ; Thu, 14 May 2015 06:02:14 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:61676 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yssm9-0008Ln-Ia for modern@ietf.org; Thu, 14 May 2015 06:02:13 -0700 Message-ID: <55549CD1.1060904@usdonovans.com> Date: Thu, 14 May 2015 08:02:09 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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, 14 May 2015 13:07:07 -0000 The IETF has already spent time defining telephone numbers and I see little value in redefining the concept in the MODERN charter. As such, I propose that we include a reference to RFC3966 as the definition of TN. As one data point, the SCIM work references RFC3966 for telephone numbers. We might, by the way, want to add SCIM to the list of areas we look at in the charter. See my comments on Kieth's points below. Regards, Steve On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: > Firstly the charter gives no definition of what you are using for telephone number, e.g. by reference to RFC 3966. > > RFC 3966 basically defines it as any sequence of decimal digits. Other usages elsewhere include alphabetic characters, because this name is used both in the context of what the user represents to other users as his number and what actually gets used in a signalling protocol. > > The ITU-T terms actually distinguish between those two usages, by putting them in separate recommendations. SRD> RFC3966 deals with this, indicating that alphabetic characters are limited to local (non global) numbers. > > The additionally problem with RFC 3966 as a definition as it does not define a usage where every sequence of digits is unique, and therefore it has to add a phone context to enable that uniqueness to exist, with a default applying to "global" numbers. > > So do you intend such digit sequences used within this group to be unique or will it need a phone context as a result of using the RFC 3966 definition? The definitions I provided would not. SRD> I suspect we will follow RFC3966, with global numbers being the default. There is no reason to limit what MODERN does to managing global numbers. I would not, however, suggest we take on including private number resources as a use case for the initial MODERN charter. > > In regard to: > >> I do gather that you believe the expertise to do the MODERN >> work resides in SG-2 rather than in the IETF. But the >> proposed working group will not, say, reassign country code >> +44 to someone else, or do any of the things you'd need the >> expertise and authority of that body to do. We're not >> delegating authority for country codes to Internet entities >> as ENUM did, which necessitated an IAB liaison with SG-2, >> even. Those are all policy issues. We're not trying to build >> policy, we're trying to build tools that will work in a >> variety of policy environments. > Then I do not believe that. I believe SG2 should define what the numbers are that we use, and maybe they should define the use cases. Once it is reduced to fulfilling a protocol requirement, then I anyone (including IETF) can do the work. > > Regards > > Keith > >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> Sent: 12 May 2015 17:37 >> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >> Subject: Re: [Modern] Proposed change to paragraph three of >> the charter >> >> >> No, what I've said consistently is that what I mean by the >> term is what >> RFC3966 meant by the term. TeRQ deferred to that >> specification for its formal definition of telephone number, >> say. I see no reason to reinvent that wheel. >> >> If we get to a place where the term "telephone number" is >> imprecise or toxic, then I think we've confused ourselves >> into a rejection of common sense and common usage. The term >> is used without warning labels in IETF standards track >> specifications already. The bar you are raising is not >> consistent with IETF usage. >> >> I do gather that you believe the expertise to do the MODERN >> work resides in SG-2 rather than in the IETF. But the >> proposed working group will not, say, reassign country code >> +44 to someone else, or do any of the things you'd need the >> expertise and authority of that body to do. We're not >> delegating authority for country codes to Internet entities >> as ENUM did, which necessitated an IAB liaison with SG-2, >> even. Those are all policy issues. We're not trying to build >> policy, we're trying to build tools that will work in a >> variety of policy environments. >> >> Jon Peterson >> Neustar, Inc. >> >> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >> wrote: >> >>> I am not doing that at all. >>> >>> I am proposing to remove any attempt by you and others to >> use the term >>> "telephone number" in a totally undefined manner, and >> replacing it with >>> terms that have been defined by the body that knows about >> these things, >>> i.e. SG2 of ITU-T. >>> >>> You are consisting opposing telling us what you mean by the team. >>> >>> My proposal is not to include the term "telephone number" at all. >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Peterson, >>>> Jon >>>> Sent: 12 May 2015 16:17 >>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>> Subject: Re: [Modern] Proposed change to paragraph three of the >>>> charter >>>> >>>> >>>> Again, I'd be more sympathetic to this request to invent a >> new IETF >>>> definition of telephone numbers if we didn't already have >> standards >>>> track RFCs that have done that, and by reference to the same >>>> specifications you're describing here. >>>> >>>> We don't mean anything different by telephone numbers than the >>>> abstract of >>>> RFC3966 did when it said that "the 'tel' URI describes resources >>>> identified by telephone numbers." >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>>> wrote: >>>> >>>>> I do not agree with the charter being widened to "TN" or >> presumably >>>>> "telephone numbers". The reason for this is that telephone >>>> numbers has >>>>> a wide and undefined scope, possibly including alphabetic >>>> characters as >>>>> well (as in the letters on the dialling ring). >>>>> >>>>> Based on the statements made by others in terms of what >> needs to be >>>>> covered, I would prefer a more precise definition of: >> "international >>>>> E.164 numbers, local special purpose numbers, and network >> specific >>>>> numbers" using the explanation of these terms that can be >> found in >>>>> ITU-T Recommendation E.164. >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >> Of Steve >>>>>> Donovan >>>>>> Sent: 07 May 2015 14:51 >>>>>> To: modern@ietf.org >>>>>> Subject: [Modern] Proposed change to paragraph three of the >>>>>> charter >>>>>> >>>>>> All, >>>>>> >>>>>> Paragraph three currently reads as follows: >>>>>> >>>>>> "The work of this group will focus on E.164 telephone >>>> numbers due to >>>>>> the changing telecom environment and interest expressed by >>>>>> telecommunications industry regulators to support more flexible >>>>>> regulatory models than exist today. >>>>>> There is an expectation that aspects of the architecture and >>>>>> protocols defined by the working group will be reusable >> for other >>>>>> user-focused identifiers. Any such extensions or reuse >> of MODERN >>>>>> mechanisms are out of scope for the MODERN working group. >>>> Solutions >>>>>> and mechanisms created by the working group will be >>>> flexible enough >>>>>> to accommodate different policies, e.g., by different >> regulatory >>>>>> agencies." >>>>>> >>>>>> I propose changing the first sentence to the following: >>>>>> >>>>>> "The work of this group will focus on TNs -- such as E.164 >>>> numbers -- >>>>>> and blocks of TNs, that are used to initiate communication with >>>>>> another user of a service. The work is motivated by >> the changing >>>>>> telecom environment and interest expressed by >> telecommunications >>>>>> industry regulators to support more flexible regulatory >>>> models than >>>>>> exist today. " >>>>>> >>>>>> The remainder of the paragraph, starting with "There is an >>>>>> expectation..." would remain unchanged. >>>>>> >>>>>> This adds some clarity on the scope of telephony >>>> identifiers covered >>>>>> as well as making it clear that blocks of TNs are also covered. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/modern >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Thu May 14 11:35: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 74E961B2E0C for ; Thu, 14 May 2015 11:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] 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 SUfFp79HwwSH for ; Thu, 14 May 2015 11:35:30 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 87C421B2E02 for ; Thu, 14 May 2015 11:35:29 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:50171 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ysxyg-0008oi-Dj for modern@ietf.org; Thu, 14 May 2015 11:35:28 -0700 Message-ID: <5554EAEC.2070208@usdonovans.com> Date: Thu, 14 May 2015 13:35:24 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "modern@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] Third revision of MODERN charter 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, 14 May 2015 18:35:32 -0000 All, In an attempt to capture a snapshot of the discussion so far, I've included a proposed third revision of the MODERN charter. This includes reference to RFC3966 for the definition of TNs (telephone numbers). It also removes the reference to CNAM. I have also added SCIM to the set of existing IETF work to be considered by the working group. Regards, Steve ----- CHARTER TEXT: The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment. Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible. The traditional model of a TN having an association to a single service provider and a single application is breaking down. Its use as a network locator is going away, but its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. A sample of problems with existing mechanisms include: - lack of flexibility (for example, it can be difficult to add fields without a very elaborate and lengthy process typically spanning years) - lack of distribution (for example, it is hard or impossible to have more than one administrator for each database) - complexity (leading, for example, to a fair amount of rural call completion problems which aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment. The working group will also define protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the managed data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, DRINKS and SCIM. The work of this group will focus on TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate communication with another user of a service. The work is motivated by the changing telecom environment and interest expressed by telecommunications industry regulators to support more flexible regulatory models than exist today. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reuse of MODERN mechanisms are out of scope for the MODERN working group. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies. The work group will deliver the following: - An architecture overview, including high level requirements and security/privacy considerations - A description of the enrollment processes for existing and new TNs including any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information associated with enrollments - A description of mechanisms for resolving information related to TNs From nobody Thu May 14 13:07:39 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 CE3BF1A90A3 for ; Thu, 14 May 2015 13:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 HPvV9lobjtzu for ; Thu, 14 May 2015 13:07:36 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 179301A90E7 for ; Thu, 14 May 2015 13:07:36 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:50828 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YszPn-000Am7-N8 for modern@ietf.org; Thu, 14 May 2015 13:07:35 -0700 Message-ID: <55550082.9030703@usdonovans.com> Date: Thu, 14 May 2015 15:07:30 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <5554EAEC.2070208@usdonovans.com> In-Reply-To: <5554EAEC.2070208@usdonovans.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Third revision of MODERN charter 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, 14 May 2015 20:07:38 -0000 The newest revision to the charter can also be found here: https://datatracker.ietf.org/doc/charter-ietf-modern/ Steve On 5/14/15 1:35 PM, Steve Donovan wrote: > All, > > In an attempt to capture a snapshot of the discussion so far, I've > included a proposed third revision of the MODERN charter. > > This includes reference to RFC3966 for the definition of TNs > (telephone numbers). It also removes the reference to CNAM. I have > also added SCIM to the set of existing IETF work to be considered by > the working group. > > Regards, > > Steve > > ----- > > CHARTER TEXT: > > The MODERN working group will define a set of Internet-based > mechanisms for the purposes of managing and resolving telephone > numbers (TNs) in an IP environment. Existing mechanisms for these > purposes face obsolescence as the voice communications infrastructure > evolves to IP technology and new applications for TNs become > possible. The traditional model of a TN having an association to a > single service provider and a single application is breaking down. > Its use as a network locator is going away, but its use as an > identifier for an individual or an organization will remain for some > time. Devices, applications, and network tools increasingly need to > manage TNs, including requesting and acquiring TN delegations from > authorities. A sample of problems with existing mechanisms include: > > - lack of flexibility (for example, it can be difficult to add fields > without a very elaborate and lengthy process typically spanning years) > - lack of distribution (for example, it is hard or impossible to have > more than one administrator for each database) > - complexity (leading, for example, to a fair amount of rural call > completion problems which aren't helped by small providers struggling > to keep numbers straight) > - difficulty of adopting more modern allocation (e.g., "blocks" of 1) > and porting mechanisms > > The working group will define an information management framework for > the roles and functions involved in associating information with one > or more TNs in an IP environment. The working group will also define > protocol mechanisms to support the interactions between the functions > defined by the framework. This includes either recommending or > defining protocol mechanisms for acquiring, associating and resolving > TNs. The protocol mechanism for acquiring TNs will provide an > enrollment process for the entities that use and manage TNs. TNs may > either be managed in a hierarchical tree, or in a distributed > peer-to-peer architecture. Privacy of the managed data and security of > the resource will be primary considerations. The protocol mechanism > for resolving TNs will allow entities such as service providers, > devices, and applications to access data related to TNs. Maintaining > reliability, real time application performance, security and privacy > are primary considerations. The working group will take into > consideration existing IETF work including ENUM, SPEERMINT, DRINKS and > SCIM. > > The work of this group will focus on TNs, as defined in RFC3966, and > blocks of TNs, that are used to initiate communication with another > user of a service. The work is motivated by the changing telecom > environment and interest expressed by telecommunications industry > regulators to support more flexible regulatory models than exist > today. There is an expectation that aspects of the architecture and > protocols defined by the working group will be reusable for other > user-focused identifiers. Any such extensions or reuse of MODERN > mechanisms are out of scope for the MODERN working group. Solutions > and mechanisms created by the working group will be flexible enough to > accommodate different policies, e.g., by different regulatory agencies. > > The work group will deliver the following: > > - An architecture overview, including high level requirements > and security/privacy considerations > > - A description of the enrollment processes for existing and new > TNs including any modifications to metadata related to those TNs > > - A description of protocol mechanisms for accessing contact > information associated with enrollments > > - A description of mechanisms for resolving information related > to TNs > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Fri May 15 06:16:21 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 05A3E1A06FD for ; Fri, 15 May 2015 06:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 iCA_g3YyUM9l for ; Fri, 15 May 2015 06:16:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 72B3D1A0364 for ; Fri, 15 May 2015 06:16:15 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 8B95AE991A6B3; Fri, 15 May 2015 13:16:11 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4FDGCZm025862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 15:16:13 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 15 May 2015 15:16:12 +0200 From: "DRAGE, Keith (Keith)" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) Thread-Index: AQHQjkbpUuR1BJIpCkKrpn8PN3KHwp19BHJg Date: Fri, 15 May 2015 13:16:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> In-Reply-To: <55549CD1.1060904@usdonovans.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 13:16:19 -0000 The IETF has NOT defined telephone numbers. RFC 3966 defines a syntax that = can be used to carry them, and I question whether that syntax is appropriat= e for use in the scenarios so far identified. To understand what RFC 3966 m= eans one has to go to E.164 (and associated national numbering plans) and h= ope it touchs with the terminology used in those places. I am fine as far it goes in terms of a sequence of decimal digits, but when= we get to whether a phone context is required, then that is a jump into es= sentially supporting multiple numbering plans over a single interface. That= would seem to be identifying an architecture of coordinating bodies with m= ultiple numbering plans well beyond the scope of what is described so far.= =20 Within national administration, escape digits are defined within the nation= al numbering plan to clearly identity all allocations within the national a= rea. At least my assumption is that any procedures we are looking at would = be within the context of a national numbering plan. If you have ideas that = go beyond this, then perhaps you need to expand on them, because that goes = way beyond what we have discussed so far. Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Steve Donovan > Sent: 14 May 2015 14:02 > To: modern@ietf.org > Subject: [Modern] Definition of TN (was Re: Proposed change=20 > to paragraph three of the charter) >=20 > The IETF has already spent time defining telephone numbers=20 > and I see little value in redefining the concept in the=20 > MODERN charter. As such, I propose that we include a=20 > reference to RFC3966 as the definition of TN. >=20 > As one data point, the SCIM work references RFC3966 for=20 > telephone numbers. We might, by the way, want to add SCIM to=20 > the list of areas we look at in the charter. >=20 > See my comments on Kieth's points below. >=20 > Regards, >=20 > Steve >=20 > On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: > > Firstly the charter gives no definition of what you are=20 > using for telephone number, e.g. by reference to RFC 3966. > > > > RFC 3966 basically defines it as any sequence of decimal=20 > digits. Other usages elsewhere include alphabetic characters,=20 > because this name is used both in the context of what the=20 > user represents to other users as his number and what=20 > actually gets used in a signalling protocol. > > > > The ITU-T terms actually distinguish between those two=20 > usages, by putting them in separate recommendations. > SRD> RFC3966 deals with this, indicating that alphabetic=20 > characters are > limited to local (non global) numbers. > > > > The additionally problem with RFC 3966 as a definition as=20 > it does not define a usage where every sequence of digits is=20 > unique, and therefore it has to add a phone context to enable=20 > that uniqueness to exist, with a default applying to "global" numbers. > > > > So do you intend such digit sequences used within this=20 > group to be unique or will it need a phone context as a=20 > result of using the RFC 3966 definition? The definitions I=20 > provided would not. > SRD> I suspect we will follow RFC3966, with global numbers being the > default. There is no reason to limit what MODERN does to=20 > managing global numbers. I would not, however, suggest we=20 > take on including private number resources as a use case for=20 > the initial MODERN charter. > > > > In regard to: > > > >> I do gather that you believe the expertise to do the MODERN work=20 > >> resides in SG-2 rather than in the IETF. But the proposed working=20 > >> group will not, say, reassign country code > >> +44 to someone else, or do any of the things you'd need the > >> expertise and authority of that body to do. We're not delegating=20 > >> authority for country codes to Internet entities as ENUM=20 > did, which=20 > >> necessitated an IAB liaison with SG-2, even. Those are all policy=20 > >> issues. We're not trying to build policy, we're trying to=20 > build tools=20 > >> that will work in a variety of policy environments. > > Then I do not believe that. I believe SG2 should define=20 > what the numbers are that we use, and maybe they should=20 > define the use cases. Once it is reduced to fulfilling a=20 > protocol requirement, then I anyone (including IETF) can do the work. > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >> Sent: 12 May 2015 17:37 > >> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >> Subject: Re: [Modern] Proposed change to paragraph three of the=20 > >> charter > >> > >> > >> No, what I've said consistently is that what I mean by the term is=20 > >> what > >> RFC3966 meant by the term. TeRQ deferred to that specification for=20 > >> its formal definition of telephone number, say. I see no reason to=20 > >> reinvent that wheel. > >> > >> If we get to a place where the term "telephone number" is=20 > imprecise=20 > >> or toxic, then I think we've confused ourselves into a=20 > rejection of=20 > >> common sense and common usage. The term is used without warning=20 > >> labels in IETF standards track specifications already. The bar you=20 > >> are raising is not consistent with IETF usage. > >> > >> I do gather that you believe the expertise to do the MODERN work=20 > >> resides in SG-2 rather than in the IETF. But the proposed working=20 > >> group will not, say, reassign country code > >> +44 to someone else, or do any of the things you'd need the > >> expertise and authority of that body to do. We're not delegating=20 > >> authority for country codes to Internet entities as ENUM=20 > did, which=20 > >> necessitated an IAB liaison with SG-2, even. Those are all policy=20 > >> issues. We're not trying to build policy, we're trying to=20 > build tools=20 > >> that will work in a variety of policy environments. > >> > >> Jon Peterson > >> Neustar, Inc. > >> > >> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" > >> wrote: > >> > >>> I am not doing that at all. > >>> > >>> I am proposing to remove any attempt by you and others to > >> use the term > >>> "telephone number" in a totally undefined manner, and > >> replacing it with > >>> terms that have been defined by the body that knows about > >> these things, > >>> i.e. SG2 of ITU-T. > >>> > >>> You are consisting opposing telling us what you mean by the team. > >>> > >>> My proposal is not to include the term "telephone number" at all. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of > >> Peterson, > >>>> Jon > >>>> Sent: 12 May 2015 16:17 > >>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>> Subject: Re: [Modern] Proposed change to paragraph three of the=20 > >>>> charter > >>>> > >>>> > >>>> Again, I'd be more sympathetic to this request to invent a > >> new IETF > >>>> definition of telephone numbers if we didn't already have > >> standards > >>>> track RFCs that have done that, and by reference to the same=20 > >>>> specifications you're describing here. > >>>> > >>>> We don't mean anything different by telephone numbers than the=20 > >>>> abstract of > >>>> RFC3966 did when it said that "the 'tel' URI describes resources=20 > >>>> identified by telephone numbers." > >>>> > >>>> Jon Peterson > >>>> Neustar, Inc. > >>>> > >>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" > >>>> wrote: > >>>> > >>>>> I do not agree with the charter being widened to "TN" or > >> presumably > >>>>> "telephone numbers". The reason for this is that telephone > >>>> numbers has > >>>>> a wide and undefined scope, possibly including alphabetic > >>>> characters as > >>>>> well (as in the letters on the dialling ring). > >>>>> > >>>>> Based on the statements made by others in terms of what > >> needs to be > >>>>> covered, I would prefer a more precise definition of: > >> "international > >>>>> E.164 numbers, local special purpose numbers, and network > >> specific > >>>>> numbers" using the explanation of these terms that can be > >> found in > >>>>> ITU-T Recommendation E.164. > >>>>> > >>>>> Keith > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf > >> Of Steve > >>>>>> Donovan > >>>>>> Sent: 07 May 2015 14:51 > >>>>>> To: modern@ietf.org > >>>>>> Subject: [Modern] Proposed change to paragraph three of the=20 > >>>>>> charter > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> Paragraph three currently reads as follows: > >>>>>> > >>>>>> "The work of this group will focus on E.164 telephone > >>>> numbers due to > >>>>>> the changing telecom environment and interest expressed by=20 > >>>>>> telecommunications industry regulators to support more=20 > flexible=20 > >>>>>> regulatory models than exist today. > >>>>>> There is an expectation that aspects of the architecture and=20 > >>>>>> protocols defined by the working group will be reusable > >> for other > >>>>>> user-focused identifiers. Any such extensions or reuse > >> of MODERN > >>>>>> mechanisms are out of scope for the MODERN working group. > >>>> Solutions > >>>>>> and mechanisms created by the working group will be > >>>> flexible enough > >>>>>> to accommodate different policies, e.g., by different > >> regulatory > >>>>>> agencies." > >>>>>> > >>>>>> I propose changing the first sentence to the following: > >>>>>> > >>>>>> "The work of this group will focus on TNs -- such as E.164 > >>>> numbers -- > >>>>>> and blocks of TNs, that are used to initiate=20 > communication with=20 > >>>>>> another user of a service. The work is motivated by > >> the changing > >>>>>> telecom environment and interest expressed by > >> telecommunications > >>>>>> industry regulators to support more flexible regulatory > >>>> models than > >>>>>> exist today. " > >>>>>> > >>>>>> The remainder of the paragraph, starting with "There is an=20 > >>>>>> expectation..." would remain unchanged. > >>>>>> > >>>>>> This adds some clarity on the scope of telephony > >>>> identifiers covered > >>>>>> as well as making it clear that blocks of TNs are also covered. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Steve > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Modern mailing list > >>>>>> Modern@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>> > >>>>> _______________________________________________ > >>>>> Modern mailing list > >>>>> Modern@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/modern > >>>> _______________________________________________ > >>>> Modern mailing list > >>>> Modern@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/modern > >>>> > >> > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > = From nobody Fri May 15 06:43:41 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 F048F1A8994 for ; Fri, 15 May 2015 06:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 PUPdnLsSaCCq for ; Fri, 15 May 2015 06:43:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093A91A7015 for ; Fri, 15 May 2015 06:41:58 -0700 (PDT) Received: from BN1AFFO11FD023.protection.gbl (10.58.52.33) by BN1AFFO11HUB028.protection.gbl (10.58.52.138) with Microsoft SMTP Server (TLS) id 15.1.160.8; Fri, 15 May 2015 13:41:43 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1AFFO11FD023.mail.protection.outlook.com (10.58.52.83) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Fri, 15 May 2015 13:41:42 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t4FDYDug002985; Fri, 15 May 2015 08:41:42 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm3.corp.sprint.com with ESMTP id 1u9fg4u2v9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 May 2015 08:41:42 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 15 May 2015 08:41:41 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Fri, 15 May 2015 08:41:41 -0500 From: "Gorman, Pierce A [CTO]" To: "DRAGE, Keith (Keith)" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) Thread-Index: AQHQjkbnBkPlAHh+4k69d3+ylKDUcJ19WeOA//+y//A= Date: Fri, 15 May 2015 13:41:41 +0000 Message-ID: References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD023; 1:633250Q2piNg0UP6MgcYSuN3+7q69y1BSwCpvg5sQJqU/TnZGD3ErVeWz51D56FBSQHjKqpP+b06dE9oWaR65/zqt3uysPT3t4Q6JEG5R4/82ID7hRdJVZ1dVuzvuARfLqIHsMLMiFJA0HlKIG01Sch0qPhFHSiYg7XbAdZq9So88LTpZ4rCrQqXLzHU+w9v9CsWDM9/cR0b4SZRlodCZgt6pb4L9r8CFlPNcpQ71ExBw4zOtiH4vb6SVLdtqLE7Gpdb0FtM2/Ky0zH9IKXYGVIiu5lEgpcZ8FyJ7oiXIxxfwmeAIsaXUDmhTmC6W2wcoe7Ed/r+3GULPu6JUax+bw== X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(13464003)(24454002)(52034003)(199003)(377454003)(189002)(51704005)(479174004)(93886004)(106466001)(102836002)(15975445007)(33646002)(5001770100001)(108616004)(189998001)(106116001)(5001960100002)(107886002)(46406003)(50986999)(54356999)(76176999)(19580405001)(19580395003)(46102003)(2501003)(47776003)(5250100002)(86362001)(97756001)(23726002)(561944003)(87936001)(2656002)(6806004)(77156002)(62966003)(92566002)(2950100001)(50466002)(2900100001)(24736003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB028; H:plsapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB028; 2:tQHi/ho5rdHyni1ACIG3lFjQ23G+F5uSoRKwzSem?= =?us-ascii?Q?dHH7fOLxJ5mtNV4m1lAtq7fG;2:2PJWRtN1mumSZn19XlmkhEiHR3FJGmtxG?= =?us-ascii?Q?8OL2usaAfr9ay6qPM5S9LCp8c+GyiSn2cVXnftd5lf+MRYeAi5x2DxC68XK5?= =?us-ascii?Q?VPQae80UdsKOf2v8UpY4tNvVBMgGJneqNC4KA1bVtDnBquQcpGod8lJso7J7?= =?us-ascii?Q?Qwgxc3AJ3AbS3a7gINRk5qre/EXORnAvNyBYGa+FV/Bn3Y7MeiokSmoSKLzy?= =?us-ascii?Q?oNyjoxUDLF7/l5iTo09N2z/wUeO45Nlwk6L3yYLt0Td;6:QGRG4mF6o/jO66?= =?us-ascii?Q?yZ/Y+0/APzRMoWAHKUnf2jFADOebCARxEaY/4eQ0KCq31rCJHjjAEbfVzv5X?= =?us-ascii?Q?Lpk+I4fn2CH4eZCZIYs/f1HHtlw4s6Cf5zqhXNp/VPjZ3Q4NWeEBQrlhHB6f?= =?us-ascii?Q?eTd8tfAukZfdEF7bG2mBWgK5TeZPz3zeQMZwojfcFuSOsuPi7Hkkkr2OPzxA?= =?us-ascii?Q?ouNad9hcgKJbY/R6rV+eF4aZr9lR+hDP7vmz7eCfQQ4a0ghQsk24gg6oXflh?= =?us-ascii?Q?gm;3:O3YkgQ0PkEd0vytEn5b8pMMDVCW0iPiXMMRSALHVLZyuGdMHJrBaWWq?= =?us-ascii?Q?sgoNmOJjHZcBNebut7J8CR3UxBr96U7azmPvBc5i+1w9YbioxzJtWfnZZpU+?= =?us-ascii?Q?l+uv7vT36eV90OIN91s6ozmIqL3biu5JoYaF9FOKOftTV29Xlkp1ouT2172g?= =?us-ascii?Q?thM8vfbKT4nHA8WJ6r0ud1d3Emxa+TVbln/Zq9FPrcPnHsXPeackzFv2zZ2X?= =?us-ascii?Q?c3BddfgIISJG6loAv2q3HLxjoTe6TLg/q0n+p9ddCUUFkPCqUkg1AvzenFsL?= =?us-ascii?Q?+E9M=3D;9:I33bK8oJiIG7Vn/I8xuykQtLM0XoVb6Q56a5yRLP8f4stM4kbY?= =?us-ascii?Q?g8aCDkitvHskZibaPk/jYqspGxGuYWpy=0D=0A=0D=0A=0D=0AeWmDsID9QT?= =?us-ascii?Q?97Pi9N3eyL3cOqNNBjIRVLPhjzOb6mYhNe4MnI1/SlAipcnOBardg2RdRPy5?= =?us-ascii?Q?EkY14/l2pzg6KdEbVrfBspSC3JSorsSO356HPxroi87mfbs5X3zPcrMVTaMJ?= =?us-ascii?Q?9wlHXzmlYKnRpuP8Q3Dkv2vpAf7VeU5fqXtqmKSnc1ibxQ47H0ibnth+U3qC?= =?us-ascii?Q?OmgqzTM4gEClI0+jaP1hV75OB/dVJh7DX/pOtXuGAPkF5XRW15816vyCCcNt?= =?us-ascii?Q?pXbPFlwSEmoYwCTRXgmxjL2VQwuRpm+VBc8i4QlIREVFd/k4yaPTtbuNKHQx?= =?us-ascii?Q?BpWKw1K5A84P8sHhdN1QWk/AzziskI98/m1vknDT4aA8S5vKPVMf1o8FFkTN?= =?us-ascii?Q?FMvsWPXgTfsBjBf2xdXNnHe8wPzucWbMMLJd7tuBZLMjyXJrJ4I/ZyOCl+qY?= =?us-ascii?Q?MzYjgeFd3jevtQMMTdFdqVmqoR5yviU3dHfEee6CH/8SesMFR2Bdb0WVcxMe?= =?us-ascii?Q?61bvCCdEQbECrJ5kWhbl8A6Xy7/q232QmxnVqszhvY6MjDAid87Ms4CeQ442?= =?us-ascii?Q?EqHKKD1aP4vbHOB7/AuMr6nyZbCk5r0ireRPeBqgU3MROvMIu0Yi0n4Fpssp?= =?us-ascii?Q?diJrK6MA/uj9nrmMueLvwzvZiSQfNWwkw9LvZzpkTKaC3e6i/y0l441Djy4H?= =?us-ascii?Q?teqpweBmq3zXKxmrJlvigRCTI8EpKDQxnxkw5kkVGgfIxtsruGK7WzmueWrw?= =?us-ascii?Q?e7DHhY+bP9Yg8YHbFtiiovLcnfOwkVx+g6sMZDOdT+dD/zwP6Ew6XzkYemOi?= =?us-ascii?Q?tsnnxa44jvIYw3U+1+dNR0UpOYiERrLOmCJsM4VVIbzOmlc87fZa+YChgFHc?= =?us-ascii?Q?2M/E6XpZxLucCo4f//8ePHRje9Tc7eFvMqTxGsCjNVhnnIKjN/LjcinDpM4q?= =?us-ascii?Q?ouixyLkZXsVMscIUDdlg9Vux8jUbvUPWHMnSk4CMHpkuP1DK7P6fhguNmkAa?= =?us-ascii?Q?meYPyAQEehvd0SWn=0D=0AYV=0D=0AAI=0D=0AI0RDRQ3bmOqTdV3QSh9aO0?= =?us-ascii?Q?YrclkYPStz+K6yNr8/oI4XqmguSfa/ecpuDQUZuFJAkIzzzC16qibeZfbm;3?= =?us-ascii?Q?:zRoEWmgK4yDWxTkGBhYIR1XJpDiqha+52qUZbdSk+giGXmpvQRZZWM0d7Wj?= =?us-ascii?Q?CC9GTsYbZsZO+p/kduVIDiAErBaoI8Tq3xE14TbPC9Wz9vUMdpAT/7Pw3pSn?= =?us-ascii?Q?0cxa+R0rePuj/VqVdmGubDQxkiLn0jQ=3D=3D;10:PdD5MXq36SWINR1EHUB?= =?us-ascii?Q?FuAUCUkL6VaAgvT9EAv8AaZvpp6Yx9kgXRPNGRQoQx4Uh90vrlSFIuEhBTWd?= =?us-ascii?Q?ilOGqP4m6ayjTfg1xj9DxpcMxUbc=3D?= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB028; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB028; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB028; X-Forefront-PRVS: 0577AD41D6 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2015 13:41:42.9923 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB028 Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 13:43:39 -0000 Would it be inappropriate to add into the charter a work item to specify ap= propriate definitions of telephone numbers as needed per use case? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of DRAGE, Keith (Ke= ith) Sent: May 15, 2015 8:16 AM To: Steve Donovan; modern@ietf.org Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragrap= h three of the charter) The IETF has NOT defined telephone numbers. RFC 3966 defines a syntax that = can be used to carry them, and I question whether that syntax is appropriat= e for use in the scenarios so far identified. To understand what RFC 3966 m= eans one has to go to E.164 (and associated national numbering plans) and h= ope it touchs with the terminology used in those places. I am fine as far it goes in terms of a sequence of decimal digits, but when= we get to whether a phone context is required, then that is a jump into es= sentially supporting multiple numbering plans over a single interface. That= would seem to be identifying an architecture of coordinating bodies with m= ultiple numbering plans well beyond the scope of what is described so far. Within national administration, escape digits are defined within the nation= al numbering plan to clearly identity all allocations within the national a= rea. At least my assumption is that any procedures we are looking at would = be within the context of a national numbering plan. If you have ideas that = go beyond this, then perhaps you need to expand on them, because that goes = way beyond what we have discussed so far. Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve > Donovan > Sent: 14 May 2015 14:02 > To: modern@ietf.org > Subject: [Modern] Definition of TN (was Re: Proposed change to > paragraph three of the charter) > > The IETF has already spent time defining telephone numbers and I see > little value in redefining the concept in the MODERN charter. As > such, I propose that we include a reference to RFC3966 as the > definition of TN. > > As one data point, the SCIM work references RFC3966 for telephone > numbers. We might, by the way, want to add SCIM to the list of areas > we look at in the charter. > > See my comments on Kieth's points below. > > Regards, > > Steve > > On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: > > Firstly the charter gives no definition of what you are > using for telephone number, e.g. by reference to RFC 3966. > > > > RFC 3966 basically defines it as any sequence of decimal > digits. Other usages elsewhere include alphabetic characters, because > this name is used both in the context of what the user represents to > other users as his number and what actually gets used in a signalling > protocol. > > > > The ITU-T terms actually distinguish between those two > usages, by putting them in separate recommendations. > SRD> RFC3966 deals with this, indicating that alphabetic > characters are > limited to local (non global) numbers. > > > > The additionally problem with RFC 3966 as a definition as > it does not define a usage where every sequence of digits is unique, > and therefore it has to add a phone context to enable that uniqueness > to exist, with a default applying to "global" numbers. > > > > So do you intend such digit sequences used within this > group to be unique or will it need a phone context as a result of > using the RFC 3966 definition? The definitions I provided would not. > SRD> I suspect we will follow RFC3966, with global numbers being the > default. There is no reason to limit what MODERN does to managing > global numbers. I would not, however, suggest we take on including > private number resources as a use case for the initial MODERN charter. > > > > In regard to: > > > >> I do gather that you believe the expertise to do the MODERN work > >> resides in SG-2 rather than in the IETF. But the proposed working > >> group will not, say, reassign country code > >> +44 to someone else, or do any of the things you'd need the > >> expertise and authority of that body to do. We're not delegating > >> authority for country codes to Internet entities as ENUM > did, which > >> necessitated an IAB liaison with SG-2, even. Those are all policy > >> issues. We're not trying to build policy, we're trying to > build tools > >> that will work in a variety of policy environments. > > Then I do not believe that. I believe SG2 should define > what the numbers are that we use, and maybe they should define the use > cases. Once it is reduced to fulfilling a protocol requirement, then I > anyone (including IETF) can do the work. > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >> Sent: 12 May 2015 17:37 > >> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >> Subject: Re: [Modern] Proposed change to paragraph three of the > >> charter > >> > >> > >> No, what I've said consistently is that what I mean by the term is > >> what > >> RFC3966 meant by the term. TeRQ deferred to that specification for > >> its formal definition of telephone number, say. I see no reason to > >> reinvent that wheel. > >> > >> If we get to a place where the term "telephone number" is > imprecise > >> or toxic, then I think we've confused ourselves into a > rejection of > >> common sense and common usage. The term is used without warning > >> labels in IETF standards track specifications already. The bar you > >> are raising is not consistent with IETF usage. > >> > >> I do gather that you believe the expertise to do the MODERN work > >> resides in SG-2 rather than in the IETF. But the proposed working > >> group will not, say, reassign country code > >> +44 to someone else, or do any of the things you'd need the > >> expertise and authority of that body to do. We're not delegating > >> authority for country codes to Internet entities as ENUM > did, which > >> necessitated an IAB liaison with SG-2, even. Those are all policy > >> issues. We're not trying to build policy, we're trying to > build tools > >> that will work in a variety of policy environments. > >> > >> Jon Peterson > >> Neustar, Inc. > >> > >> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" > >> wrote: > >> > >>> I am not doing that at all. > >>> > >>> I am proposing to remove any attempt by you and others to > >> use the term > >>> "telephone number" in a totally undefined manner, and > >> replacing it with > >>> terms that have been defined by the body that knows about > >> these things, > >>> i.e. SG2 of ITU-T. > >>> > >>> You are consisting opposing telling us what you mean by the team. > >>> > >>> My proposal is not to include the term "telephone number" at all. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of > >> Peterson, > >>>> Jon > >>>> Sent: 12 May 2015 16:17 > >>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>> Subject: Re: [Modern] Proposed change to paragraph three of the > >>>> charter > >>>> > >>>> > >>>> Again, I'd be more sympathetic to this request to invent a > >> new IETF > >>>> definition of telephone numbers if we didn't already have > >> standards > >>>> track RFCs that have done that, and by reference to the same > >>>> specifications you're describing here. > >>>> > >>>> We don't mean anything different by telephone numbers than the > >>>> abstract of > >>>> RFC3966 did when it said that "the 'tel' URI describes resources > >>>> identified by telephone numbers." > >>>> > >>>> Jon Peterson > >>>> Neustar, Inc. > >>>> > >>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" > >>>> wrote: > >>>> > >>>>> I do not agree with the charter being widened to "TN" or > >> presumably > >>>>> "telephone numbers". The reason for this is that telephone > >>>> numbers has > >>>>> a wide and undefined scope, possibly including alphabetic > >>>> characters as > >>>>> well (as in the letters on the dialling ring). > >>>>> > >>>>> Based on the statements made by others in terms of what > >> needs to be > >>>>> covered, I would prefer a more precise definition of: > >> "international > >>>>> E.164 numbers, local special purpose numbers, and network > >> specific > >>>>> numbers" using the explanation of these terms that can be > >> found in > >>>>> ITU-T Recommendation E.164. > >>>>> > >>>>> Keith > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf > >> Of Steve > >>>>>> Donovan > >>>>>> Sent: 07 May 2015 14:51 > >>>>>> To: modern@ietf.org > >>>>>> Subject: [Modern] Proposed change to paragraph three of the > >>>>>> charter > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> Paragraph three currently reads as follows: > >>>>>> > >>>>>> "The work of this group will focus on E.164 telephone > >>>> numbers due to > >>>>>> the changing telecom environment and interest expressed by > >>>>>> telecommunications industry regulators to support more > flexible > >>>>>> regulatory models than exist today. > >>>>>> There is an expectation that aspects of the architecture and > >>>>>> protocols defined by the working group will be reusable > >> for other > >>>>>> user-focused identifiers. Any such extensions or reuse > >> of MODERN > >>>>>> mechanisms are out of scope for the MODERN working group. > >>>> Solutions > >>>>>> and mechanisms created by the working group will be > >>>> flexible enough > >>>>>> to accommodate different policies, e.g., by different > >> regulatory > >>>>>> agencies." > >>>>>> > >>>>>> I propose changing the first sentence to the following: > >>>>>> > >>>>>> "The work of this group will focus on TNs -- such as E.164 > >>>> numbers -- > >>>>>> and blocks of TNs, that are used to initiate > communication with > >>>>>> another user of a service. The work is motivated by > >> the changing > >>>>>> telecom environment and interest expressed by > >> telecommunications > >>>>>> industry regulators to support more flexible regulatory > >>>> models than > >>>>>> exist today. " > >>>>>> > >>>>>> The remainder of the paragraph, starting with "There is an > >>>>>> expectation..." would remain unchanged. > >>>>>> > >>>>>> This adds some clarity on the scope of telephony > >>>> identifiers covered > >>>>>> as well as making it clear that blocks of TNs are also covered. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Steve > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Modern mailing list > >>>>>> Modern@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>> > >>>>> _______________________________________________ > >>>>> Modern mailing list > >>>>> Modern@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/modern > >>>> _______________________________________________ > >>>> Modern mailing list > >>>> Modern@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/modern > >>>> > >> > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ 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 Fri May 15 06:59:28 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 A86B01A9119 for ; Fri, 15 May 2015 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.267 X-Spam-Level: X-Spam-Status: No, score=-4.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 NJNBrizUIFor for ; Fri, 15 May 2015 06:59:22 -0700 (PDT) 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 D66FC1A9103 for ; Fri, 15 May 2015 06:59:22 -0700 (PDT) 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 t4FDvtCb027674; Fri, 15 May 2015 09:59:20 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1ud0mps5bu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 May 2015 09:59:20 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 15 May 2015 09:59:18 -0400 From: "McGarry, Tom" To: "DRAGE, Keith (Keith)" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) Thread-Index: AQHQjkbl2YycA7wqakKp2IyYSley3p19SR+A///I+4A= Date: Fri, 15 May 2015 13:59:18 +0000 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.168.132.14] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-15_03:2015-05-15,2015-05-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=6.22890627965944e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.992957022353465 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.992957022353465 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.992957022353465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505150186 Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 13:59:26 -0000 RFC3966 didn't require coordination with international or national numbering authorities. The work at MODERN won't either. The charter says - "Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies." It's up to the WG to build that flexibility in. =20 On 5/15/15 9:16 AM, "DRAGE, Keith (Keith)" wrote: >The IETF has NOT defined telephone numbers. RFC 3966 defines a syntax >that can be used to carry them, and I question whether that syntax is >appropriate for use in the scenarios so far identified. To understand >what RFC 3966 means one has to go to E.164 (and associated national >numbering plans) and hope it touchs with the terminology used in those >places. > >I am fine as far it goes in terms of a sequence of decimal digits, but >when we get to whether a phone context is required, then that is a jump >into essentially supporting multiple numbering plans over a single >interface. That would seem to be identifying an architecture of >coordinating bodies with multiple numbering plans well beyond the scope >of what is described so far. > >Within national administration, escape digits are defined within the >national numbering plan to clearly identity all allocations within the >national area. At least my assumption is that any procedures we are >looking at would be within the context of a national numbering plan. If >you have ideas that go beyond this, then perhaps you need to expand on >them, because that goes way beyond what we have discussed so far. > >Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Steve Donovan >> Sent: 14 May 2015 14:02 >> To: modern@ietf.org >> Subject: [Modern] Definition of TN (was Re: Proposed change >> to paragraph three of the charter) >>=20 >> The IETF has already spent time defining telephone numbers >> and I see little value in redefining the concept in the >> MODERN charter. As such, I propose that we include a >> reference to RFC3966 as the definition of TN. >>=20 >> As one data point, the SCIM work references RFC3966 for >> telephone numbers. We might, by the way, want to add SCIM to >> the list of areas we look at in the charter. >>=20 >> See my comments on Kieth's points below. >>=20 >> Regards, >>=20 >> Steve >>=20 >> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: >> > Firstly the charter gives no definition of what you are >> using for telephone number, e.g. by reference to RFC 3966. >> > >> > RFC 3966 basically defines it as any sequence of decimal >> digits. Other usages elsewhere include alphabetic characters, >> because this name is used both in the context of what the >> user represents to other users as his number and what >> actually gets used in a signalling protocol. >> > >> > The ITU-T terms actually distinguish between those two >> usages, by putting them in separate recommendations. >> SRD> RFC3966 deals with this, indicating that alphabetic >> characters are >> limited to local (non global) numbers. >> > >> > The additionally problem with RFC 3966 as a definition as >> it does not define a usage where every sequence of digits is >> unique, and therefore it has to add a phone context to enable >> that uniqueness to exist, with a default applying to "global" numbers. >> > >> > So do you intend such digit sequences used within this >> group to be unique or will it need a phone context as a >> result of using the RFC 3966 definition? The definitions I >> provided would not. >> SRD> I suspect we will follow RFC3966, with global numbers being the >> default. There is no reason to limit what MODERN does to >> managing global numbers. I would not, however, suggest we >> take on including private number resources as a use case for >> the initial MODERN charter. >> > >> > In regard to: >> > >> >> I do gather that you believe the expertise to do the MODERN work >> >> resides in SG-2 rather than in the IETF. But the proposed working >> >> group will not, say, reassign country code >> >> +44 to someone else, or do any of the things you'd need the >> >> expertise and authority of that body to do. We're not delegating >> >> authority for country codes to Internet entities as ENUM >> did, which=20 >> >> necessitated an IAB liaison with SG-2, even. Those are all policy >> >> issues. We're not trying to build policy, we're trying to >> build tools=20 >> >> that will work in a variety of policy environments. >> > Then I do not believe that. I believe SG2 should define >> what the numbers are that we use, and maybe they should >> define the use cases. Once it is reduced to fulfilling a >> protocol requirement, then I anyone (including IETF) can do the work. >> > >> > Regards >> > >> > Keith >> > >> >> -----Original Message----- >> >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> >> Sent: 12 May 2015 17:37 >> >> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >> >> Subject: Re: [Modern] Proposed change to paragraph three of the >> >> charter >> >> >> >> >> >> No, what I've said consistently is that what I mean by the term is >> >> what >> >> RFC3966 meant by the term. TeRQ deferred to that specification for >> >> its formal definition of telephone number, say. I see no reason to >> >> reinvent that wheel. >> >> >> >> If we get to a place where the term "telephone number" is >> imprecise=20 >> >> or toxic, then I think we've confused ourselves into a >> rejection of=20 >> >> common sense and common usage. The term is used without warning >> >> labels in IETF standards track specifications already. The bar you >> >> are raising is not consistent with IETF usage. >> >> >> >> I do gather that you believe the expertise to do the MODERN work >> >> resides in SG-2 rather than in the IETF. But the proposed working >> >> group will not, say, reassign country code >> >> +44 to someone else, or do any of the things you'd need the >> >> expertise and authority of that body to do. We're not delegating >> >> authority for country codes to Internet entities as ENUM >> did, which=20 >> >> necessitated an IAB liaison with SG-2, even. Those are all policy >> >> issues. We're not trying to build policy, we're trying to >> build tools=20 >> >> that will work in a variety of policy environments. >> >> >> >> Jon Peterson >> >> Neustar, Inc. >> >> >> >> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >> >> wrote: >> >> >> >>> I am not doing that at all. >> >>> >> >>> I am proposing to remove any attempt by you and others to >> >> use the term >> >>> "telephone number" in a totally undefined manner, and >> >> replacing it with >> >>> terms that have been defined by the body that knows about >> >> these things, >> >>> i.e. SG2 of ITU-T. >> >>> >> >>> You are consisting opposing telling us what you mean by the team. >> >>> >> >>> My proposal is not to include the term "telephone number" at all. >> >>> >> >>> Regards >> >>> >> >>> Keith >> >>> >> >>>> -----Original Message----- >> >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> >> Peterson, >> >>>> Jon >> >>>> Sent: 12 May 2015 16:17 >> >>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >> >>>> Subject: Re: [Modern] Proposed change to paragraph three of the >> >>>> charter >> >>>> >> >>>> >> >>>> Again, I'd be more sympathetic to this request to invent a >> >> new IETF >> >>>> definition of telephone numbers if we didn't already have >> >> standards >> >>>> track RFCs that have done that, and by reference to the same >> >>>> specifications you're describing here. >> >>>> >> >>>> We don't mean anything different by telephone numbers than the >> >>>> abstract of >> >>>> RFC3966 did when it said that "the 'tel' URI describes resources >> >>>> identified by telephone numbers." >> >>>> >> >>>> Jon Peterson >> >>>> Neustar, Inc. >> >>>> >> >>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >> >>>> wrote: >> >>>> >> >>>>> I do not agree with the charter being widened to "TN" or >> >> presumably >> >>>>> "telephone numbers". The reason for this is that telephone >> >>>> numbers has >> >>>>> a wide and undefined scope, possibly including alphabetic >> >>>> characters as >> >>>>> well (as in the letters on the dialling ring). >> >>>>> >> >>>>> Based on the statements made by others in terms of what >> >> needs to be >> >>>>> covered, I would prefer a more precise definition of: >> >> "international >> >>>>> E.164 numbers, local special purpose numbers, and network >> >> specific >> >>>>> numbers" using the explanation of these terms that can be >> >> found in >> >>>>> ITU-T Recommendation E.164. >> >>>>> >> >>>>> Keith >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >> >> Of Steve >> >>>>>> Donovan >> >>>>>> Sent: 07 May 2015 14:51 >> >>>>>> To: modern@ietf.org >> >>>>>> Subject: [Modern] Proposed change to paragraph three of the >> >>>>>> charter >> >>>>>> >> >>>>>> All, >> >>>>>> >> >>>>>> Paragraph three currently reads as follows: >> >>>>>> >> >>>>>> "The work of this group will focus on E.164 telephone >> >>>> numbers due to >> >>>>>> the changing telecom environment and interest expressed by >> >>>>>> telecommunications industry regulators to support more >> flexible=20 >> >>>>>> regulatory models than exist today. >> >>>>>> There is an expectation that aspects of the architecture and >> >>>>>> protocols defined by the working group will be reusable >> >> for other >> >>>>>> user-focused identifiers. Any such extensions or reuse >> >> of MODERN >> >>>>>> mechanisms are out of scope for the MODERN working group. >> >>>> Solutions >> >>>>>> and mechanisms created by the working group will be >> >>>> flexible enough >> >>>>>> to accommodate different policies, e.g., by different >> >> regulatory >> >>>>>> agencies." >> >>>>>> >> >>>>>> I propose changing the first sentence to the following: >> >>>>>> >> >>>>>> "The work of this group will focus on TNs -- such as E.164 >> >>>> numbers -- >> >>>>>> and blocks of TNs, that are used to initiate >> communication with >> >>>>>> another user of a service. The work is motivated by >> >> the changing >> >>>>>> telecom environment and interest expressed by >> >> telecommunications >> >>>>>> industry regulators to support more flexible regulatory >> >>>> models than >> >>>>>> exist today. " >> >>>>>> >> >>>>>> The remainder of the paragraph, starting with "There is an >> >>>>>> expectation..." would remain unchanged. >> >>>>>> >> >>>>>> This adds some clarity on the scope of telephony >> >>>> identifiers covered >> >>>>>> as well as making it clear that blocks of TNs are also covered. >> >>>>>> >> >>>>>> Regards, >> >>>>>> >> >>>>>> Steve >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Modern mailing list >> >>>>>> Modern@ietf.org >> >>>>>>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s= =3Dv >>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=3D >> >>>>>> >> >>>>> _______________________________________________ >> >>>>> Modern mailing list >> >>>>> Modern@ietf.org >> >>>>>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s= =3Dv >>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=3D >> >>>> _______________________________________________ >> >>>> Modern mailing list >> >>>> Modern@ietf.org >> >>>>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s= =3Dv >>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=3D >> >>>> >> >> >> > _______________________________________________ >> > Modern mailing list >> > Modern@ietf.org >> >=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s= =3Dv >>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=3D >> > >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s= =3Dv >>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=3D >>=20 >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DFrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s=3D= vUUR >-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=3D=20 From nobody Fri May 15 07:04:04 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 1742F1A90B0 for ; Fri, 15 May 2015 07:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 PQo3rRgLug_H for ; Fri, 15 May 2015 07:03:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2AE961A8AFE for ; Fri, 15 May 2015 07:03:59 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4FE3lJE053217 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2015 09:03:57 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "DRAGE, Keith (Keith)" Date: Fri, 15 May 2015 09:03:46 -0500 Message-ID: <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Steve Donovan , "modern@ietf.org" Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 14:04:02 -0000 (I'm not picking on Keith in particular. This just seemed a good place to jump in.) I'd like to remind people that this is a charter, not a technical specification. We need guidance to the working group. It doesn't have to be perfect, and there's room for some flexibility It seems to me that the syntax is mainly what we care about, _not_ the architecture of coordinating bodies. My understanding is the whole point of this exercise is to avoid building assumptions about that architecture and related policies into the technology itself. If a national administration defines escape digits, we need to be able to handle escape digits. But that doesn't mean we have to import the whole administrative architecture. On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: > The IETF has NOT defined telephone numbers. RFC 3966 defines a syntax > that can be used to carry them, and I question whether that syntax is > appropriate for use in the scenarios so far identified. To understand > what RFC 3966 means one has to go to E.164 (and associated national > numbering plans) and hope it touchs with the terminology used in those > places. > > I am fine as far it goes in terms of a sequence of decimal digits, but > when we get to whether a phone context is required, then that is a > jump into essentially supporting multiple numbering plans over a > single interface. That would seem to be identifying an architecture of > coordinating bodies with multiple numbering plans well beyond the > scope of what is described so far. > > Within national administration, escape digits are defined within the > national numbering plan to clearly identity all allocations within the > national area. At least my assumption is that any procedures we are > looking at would be within the context of a national numbering plan. > If you have ideas that go beyond this, then perhaps you need to expand > on them, because that goes way beyond what we have discussed so far. > > Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Steve Donovan >> Sent: 14 May 2015 14:02 >> To: modern@ietf.org >> Subject: [Modern] Definition of TN (was Re: Proposed change >> to paragraph three of the charter) >> >> The IETF has already spent time defining telephone numbers >> and I see little value in redefining the concept in the >> MODERN charter. As such, I propose that we include a >> reference to RFC3966 as the definition of TN. >> >> As one data point, the SCIM work references RFC3966 for >> telephone numbers. We might, by the way, want to add SCIM to >> the list of areas we look at in the charter. >> >> See my comments on Kieth's points below. >> >> Regards, >> >> Steve >> >> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: >>> Firstly the charter gives no definition of what you are >> using for telephone number, e.g. by reference to RFC 3966. >>> >>> RFC 3966 basically defines it as any sequence of decimal >> digits. Other usages elsewhere include alphabetic characters, >> because this name is used both in the context of what the >> user represents to other users as his number and what >> actually gets used in a signalling protocol. >>> >>> The ITU-T terms actually distinguish between those two >> usages, by putting them in separate recommendations. >> SRD> RFC3966 deals with this, indicating that alphabetic >> characters are >> limited to local (non global) numbers. >>> >>> The additionally problem with RFC 3966 as a definition as >> it does not define a usage where every sequence of digits is >> unique, and therefore it has to add a phone context to enable >> that uniqueness to exist, with a default applying to "global" >> numbers. >>> >>> So do you intend such digit sequences used within this >> group to be unique or will it need a phone context as a >> result of using the RFC 3966 definition? The definitions I >> provided would not. >> SRD> I suspect we will follow RFC3966, with global numbers being the >> default. There is no reason to limit what MODERN does to >> managing global numbers. I would not, however, suggest we >> take on including private number resources as a use case for >> the initial MODERN charter. >>> >>> In regard to: >>> >>>> I do gather that you believe the expertise to do the MODERN work >>>> resides in SG-2 rather than in the IETF. But the proposed working >>>> group will not, say, reassign country code >>>> +44 to someone else, or do any of the things you'd need the >>>> expertise and authority of that body to do. We're not delegating >>>> authority for country codes to Internet entities as ENUM >> did, which >>>> necessitated an IAB liaison with SG-2, even. Those are all policy >>>> issues. We're not trying to build policy, we're trying to >> build tools >>>> that will work in a variety of policy environments. >>> Then I do not believe that. I believe SG2 should define >> what the numbers are that we use, and maybe they should >> define the use cases. Once it is reduced to fulfilling a >> protocol requirement, then I anyone (including IETF) can do the work. >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>> Sent: 12 May 2015 17:37 >>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>> Subject: Re: [Modern] Proposed change to paragraph three of the >>>> charter >>>> >>>> >>>> No, what I've said consistently is that what I mean by the term is >>>> what >>>> RFC3966 meant by the term. TeRQ deferred to that specification for >>>> its formal definition of telephone number, say. I see no reason to >>>> reinvent that wheel. >>>> >>>> If we get to a place where the term "telephone number" is >> imprecise >>>> or toxic, then I think we've confused ourselves into a >> rejection of >>>> common sense and common usage. The term is used without warning >>>> labels in IETF standards track specifications already. The bar you >>>> are raising is not consistent with IETF usage. >>>> >>>> I do gather that you believe the expertise to do the MODERN work >>>> resides in SG-2 rather than in the IETF. But the proposed working >>>> group will not, say, reassign country code >>>> +44 to someone else, or do any of the things you'd need the >>>> expertise and authority of that body to do. We're not delegating >>>> authority for country codes to Internet entities as ENUM >> did, which >>>> necessitated an IAB liaison with SG-2, even. Those are all policy >>>> issues. We're not trying to build policy, we're trying to >> build tools >>>> that will work in a variety of policy environments. >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >>>> wrote: >>>> >>>>> I am not doing that at all. >>>>> >>>>> I am proposing to remove any attempt by you and others to >>>> use the term >>>>> "telephone number" in a totally undefined manner, and >>>> replacing it with >>>>> terms that have been defined by the body that knows about >>>> these things, >>>>> i.e. SG2 of ITU-T. >>>>> >>>>> You are consisting opposing telling us what you mean by the team. >>>>> >>>>> My proposal is not to include the term "telephone number" at all. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>> Peterson, >>>>>> Jon >>>>>> Sent: 12 May 2015 16:17 >>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>> Subject: Re: [Modern] Proposed change to paragraph three of the >>>>>> charter >>>>>> >>>>>> >>>>>> Again, I'd be more sympathetic to this request to invent a >>>> new IETF >>>>>> definition of telephone numbers if we didn't already have >>>> standards >>>>>> track RFCs that have done that, and by reference to the same >>>>>> specifications you're describing here. >>>>>> >>>>>> We don't mean anything different by telephone numbers than the >>>>>> abstract of >>>>>> RFC3966 did when it said that "the 'tel' URI describes resources >>>>>> identified by telephone numbers." >>>>>> >>>>>> Jon Peterson >>>>>> Neustar, Inc. >>>>>> >>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>>>>> wrote: >>>>>> >>>>>>> I do not agree with the charter being widened to "TN" or >>>> presumably >>>>>>> "telephone numbers". The reason for this is that telephone >>>>>> numbers has >>>>>>> a wide and undefined scope, possibly including alphabetic >>>>>> characters as >>>>>>> well (as in the letters on the dialling ring). >>>>>>> >>>>>>> Based on the statements made by others in terms of what >>>> needs to be >>>>>>> covered, I would prefer a more precise definition of: >>>> "international >>>>>>> E.164 numbers, local special purpose numbers, and network >>>> specific >>>>>>> numbers" using the explanation of these terms that can be >>>> found in >>>>>>> ITU-T Recommendation E.164. >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>> Of Steve >>>>>>>> Donovan >>>>>>>> Sent: 07 May 2015 14:51 >>>>>>>> To: modern@ietf.org >>>>>>>> Subject: [Modern] Proposed change to paragraph three of the >>>>>>>> charter >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Paragraph three currently reads as follows: >>>>>>>> >>>>>>>> "The work of this group will focus on E.164 telephone >>>>>> numbers due to >>>>>>>> the changing telecom environment and interest expressed by >>>>>>>> telecommunications industry regulators to support more >> flexible >>>>>>>> regulatory models than exist today. >>>>>>>> There is an expectation that aspects of the architecture and >>>>>>>> protocols defined by the working group will be reusable >>>> for other >>>>>>>> user-focused identifiers. Any such extensions or reuse >>>> of MODERN >>>>>>>> mechanisms are out of scope for the MODERN working group. >>>>>> Solutions >>>>>>>> and mechanisms created by the working group will be >>>>>> flexible enough >>>>>>>> to accommodate different policies, e.g., by different >>>> regulatory >>>>>>>> agencies." >>>>>>>> >>>>>>>> I propose changing the first sentence to the following: >>>>>>>> >>>>>>>> "The work of this group will focus on TNs -- such as E.164 >>>>>> numbers -- >>>>>>>> and blocks of TNs, that are used to initiate >> communication with >>>>>>>> another user of a service. The work is motivated by >>>> the changing >>>>>>>> telecom environment and interest expressed by >>>> telecommunications >>>>>>>> industry regulators to support more flexible regulatory >>>>>> models than >>>>>>>> exist today. " >>>>>>>> >>>>>>>> The remainder of the paragraph, starting with "There is an >>>>>>>> expectation..." would remain unchanged. >>>>>>>> >>>>>>>> This adds some clarity on the scope of telephony >>>>>> identifiers covered >>>>>>>> as well as making it clear that blocks of TNs are also covered. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Modern mailing list >>>>>>>> Modern@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Modern mailing list >>>>>>> Modern@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> >>>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Fri May 15 07:05:45 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 8DA091A9164 for ; Fri, 15 May 2015 07:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 7ZTkdieuoXBh for ; Fri, 15 May 2015 07:05:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4DB671A8AFE for ; Fri, 15 May 2015 07:05:40 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4FE5QYC053369 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2015 09:05:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Gorman, Pierce A [CTO]" Date: Fri, 15 May 2015 09:05:26 -0500 Message-ID: In-Reply-To: References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Steve Donovan , "DRAGE, Keith \(Keith\)" , "modern@ietf.org" Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 14:05:43 -0000 On 15 May 2015, at 8:41, Gorman, Pierce A [CTO] wrote: > Would it be inappropriate to add into the charter a work item to > specify appropriate definitions of telephone numbers as needed per use > case? It would be nice to understand that going in, but if that can't happen, I don't think it would be a problem to ask the working group to define it. > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of DRAGE, > Keith (Keith) > Sent: May 15, 2015 8:16 AM > To: Steve Donovan; modern@ietf.org > Subject: Re: [Modern] Definition of TN (was Re: Proposed change to > paragraph three of the charter) > > The IETF has NOT defined telephone numbers. RFC 3966 defines a syntax > that can be used to carry them, and I question whether that syntax is > appropriate for use in the scenarios so far identified. To understand > what RFC 3966 means one has to go to E.164 (and associated national > numbering plans) and hope it touchs with the terminology used in those > places. > > I am fine as far it goes in terms of a sequence of decimal digits, but > when we get to whether a phone context is required, then that is a > jump into essentially supporting multiple numbering plans over a > single interface. That would seem to be identifying an architecture of > coordinating bodies with multiple numbering plans well beyond the > scope of what is described so far. > > Within national administration, escape digits are defined within the > national numbering plan to clearly identity all allocations within the > national area. At least my assumption is that any procedures we are > looking at would be within the context of a national numbering plan. > If you have ideas that go beyond this, then perhaps you need to expand > on them, because that goes way beyond what we have discussed so far. > > Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >> Donovan >> Sent: 14 May 2015 14:02 >> To: modern@ietf.org >> Subject: [Modern] Definition of TN (was Re: Proposed change to >> paragraph three of the charter) >> >> The IETF has already spent time defining telephone numbers and I see >> little value in redefining the concept in the MODERN charter. As >> such, I propose that we include a reference to RFC3966 as the >> definition of TN. >> >> As one data point, the SCIM work references RFC3966 for telephone >> numbers. We might, by the way, want to add SCIM to the list of areas >> we look at in the charter. >> >> See my comments on Kieth's points below. >> >> Regards, >> >> Steve >> >> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: >>> Firstly the charter gives no definition of what you are >> using for telephone number, e.g. by reference to RFC 3966. >>> >>> RFC 3966 basically defines it as any sequence of decimal >> digits. Other usages elsewhere include alphabetic characters, because >> this name is used both in the context of what the user represents to >> other users as his number and what actually gets used in a signalling >> protocol. >>> >>> The ITU-T terms actually distinguish between those two >> usages, by putting them in separate recommendations. >> SRD> RFC3966 deals with this, indicating that alphabetic >> characters are >> limited to local (non global) numbers. >>> >>> The additionally problem with RFC 3966 as a definition as >> it does not define a usage where every sequence of digits is unique, >> and therefore it has to add a phone context to enable that uniqueness >> to exist, with a default applying to "global" numbers. >>> >>> So do you intend such digit sequences used within this >> group to be unique or will it need a phone context as a result of >> using the RFC 3966 definition? The definitions I provided would not. >> SRD> I suspect we will follow RFC3966, with global numbers being the >> default. There is no reason to limit what MODERN does to managing >> global numbers. I would not, however, suggest we take on including >> private number resources as a use case for the initial MODERN >> charter. >>> >>> In regard to: >>> >>>> I do gather that you believe the expertise to do the MODERN work >>>> resides in SG-2 rather than in the IETF. But the proposed working >>>> group will not, say, reassign country code >>>> +44 to someone else, or do any of the things you'd need the >>>> expertise and authority of that body to do. We're not delegating >>>> authority for country codes to Internet entities as ENUM >> did, which >>>> necessitated an IAB liaison with SG-2, even. Those are all policy >>>> issues. We're not trying to build policy, we're trying to >> build tools >>>> that will work in a variety of policy environments. >>> Then I do not believe that. I believe SG2 should define >> what the numbers are that we use, and maybe they should define the >> use >> cases. Once it is reduced to fulfilling a protocol requirement, then >> I >> anyone (including IETF) can do the work. >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>> Sent: 12 May 2015 17:37 >>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>> Subject: Re: [Modern] Proposed change to paragraph three of the >>>> charter >>>> >>>> >>>> No, what I've said consistently is that what I mean by the term is >>>> what >>>> RFC3966 meant by the term. TeRQ deferred to that specification for >>>> its formal definition of telephone number, say. I see no reason to >>>> reinvent that wheel. >>>> >>>> If we get to a place where the term "telephone number" is >> imprecise >>>> or toxic, then I think we've confused ourselves into a >> rejection of >>>> common sense and common usage. The term is used without warning >>>> labels in IETF standards track specifications already. The bar you >>>> are raising is not consistent with IETF usage. >>>> >>>> I do gather that you believe the expertise to do the MODERN work >>>> resides in SG-2 rather than in the IETF. But the proposed working >>>> group will not, say, reassign country code >>>> +44 to someone else, or do any of the things you'd need the >>>> expertise and authority of that body to do. We're not delegating >>>> authority for country codes to Internet entities as ENUM >> did, which >>>> necessitated an IAB liaison with SG-2, even. Those are all policy >>>> issues. We're not trying to build policy, we're trying to >> build tools >>>> that will work in a variety of policy environments. >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >>>> wrote: >>>> >>>>> I am not doing that at all. >>>>> >>>>> I am proposing to remove any attempt by you and others to >>>> use the term >>>>> "telephone number" in a totally undefined manner, and >>>> replacing it with >>>>> terms that have been defined by the body that knows about >>>> these things, >>>>> i.e. SG2 of ITU-T. >>>>> >>>>> You are consisting opposing telling us what you mean by the team. >>>>> >>>>> My proposal is not to include the term "telephone number" at all. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>> Peterson, >>>>>> Jon >>>>>> Sent: 12 May 2015 16:17 >>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>> Subject: Re: [Modern] Proposed change to paragraph three of the >>>>>> charter >>>>>> >>>>>> >>>>>> Again, I'd be more sympathetic to this request to invent a >>>> new IETF >>>>>> definition of telephone numbers if we didn't already have >>>> standards >>>>>> track RFCs that have done that, and by reference to the same >>>>>> specifications you're describing here. >>>>>> >>>>>> We don't mean anything different by telephone numbers than the >>>>>> abstract of >>>>>> RFC3966 did when it said that "the 'tel' URI describes resources >>>>>> identified by telephone numbers." >>>>>> >>>>>> Jon Peterson >>>>>> Neustar, Inc. >>>>>> >>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>>>>> wrote: >>>>>> >>>>>>> I do not agree with the charter being widened to "TN" or >>>> presumably >>>>>>> "telephone numbers". The reason for this is that telephone >>>>>> numbers has >>>>>>> a wide and undefined scope, possibly including alphabetic >>>>>> characters as >>>>>>> well (as in the letters on the dialling ring). >>>>>>> >>>>>>> Based on the statements made by others in terms of what >>>> needs to be >>>>>>> covered, I would prefer a more precise definition of: >>>> "international >>>>>>> E.164 numbers, local special purpose numbers, and network >>>> specific >>>>>>> numbers" using the explanation of these terms that can be >>>> found in >>>>>>> ITU-T Recommendation E.164. >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>> Of Steve >>>>>>>> Donovan >>>>>>>> Sent: 07 May 2015 14:51 >>>>>>>> To: modern@ietf.org >>>>>>>> Subject: [Modern] Proposed change to paragraph three of the >>>>>>>> charter >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Paragraph three currently reads as follows: >>>>>>>> >>>>>>>> "The work of this group will focus on E.164 telephone >>>>>> numbers due to >>>>>>>> the changing telecom environment and interest expressed by >>>>>>>> telecommunications industry regulators to support more >> flexible >>>>>>>> regulatory models than exist today. >>>>>>>> There is an expectation that aspects of the architecture and >>>>>>>> protocols defined by the working group will be reusable >>>> for other >>>>>>>> user-focused identifiers. Any such extensions or reuse >>>> of MODERN >>>>>>>> mechanisms are out of scope for the MODERN working group. >>>>>> Solutions >>>>>>>> and mechanisms created by the working group will be >>>>>> flexible enough >>>>>>>> to accommodate different policies, e.g., by different >>>> regulatory >>>>>>>> agencies." >>>>>>>> >>>>>>>> I propose changing the first sentence to the following: >>>>>>>> >>>>>>>> "The work of this group will focus on TNs -- such as E.164 >>>>>> numbers -- >>>>>>>> and blocks of TNs, that are used to initiate >> communication with >>>>>>>> another user of a service. The work is motivated by >>>> the changing >>>>>>>> telecom environment and interest expressed by >>>> telecommunications >>>>>>>> industry regulators to support more flexible regulatory >>>>>> models than >>>>>>>> exist today. " >>>>>>>> >>>>>>>> The remainder of the paragraph, starting with "There is an >>>>>>>> expectation..." would remain unchanged. >>>>>>>> >>>>>>>> This adds some clarity on the scope of telephony >>>>>> identifiers covered >>>>>>>> as well as making it clear that blocks of TNs are also covered. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Modern mailing list >>>>>>>> Modern@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Modern mailing list >>>>>>> Modern@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> >>>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for > the sole 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. > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Fri May 15 07:36: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 753CD1A8A66 for ; Fri, 15 May 2015 07:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 WRS4WzAQIkOB for ; Fri, 15 May 2015 07:36:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 AAAA31A900A for ; Fri, 15 May 2015 07:36:37 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B520CCBA4881A; Fri, 15 May 2015 14:36:31 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4FEaWde023804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 16:36:34 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 15 May 2015 16:36:33 +0200 From: "DRAGE, Keith (Keith)" To: Ben Campbell Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) Thread-Index: AQHQjkbpUuR1BJIpCkKrpn8PN3KHwp19BHJg///tZACAAClPwA== Date: Fri, 15 May 2015 14:36:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> In-Reply-To: <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Steve Donovan , "modern@ietf.org" Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 14:36:41 -0000 You have at least missed the point I have been making. By using RFC 3966 as a syntax definition, you automatically include a requi= rement to support phone context. The point I am making is that in my understanding from the use cases so far= discussed, phone context is unnecessary, as we are dealing with protocol w= ith a single administration supporting a single national numbering space. T= he context is one only and implicit in the administration one is presumably= securely communicating with. Keith=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: 15 May 2015 15:04 > To: DRAGE, Keith (Keith) > Cc: Steve Donovan; modern@ietf.org > Subject: Re: [Modern] Definition of TN (was Re: Proposed=20 > change to paragraph three of the charter) >=20 > >=20 > (I'm not picking on Keith in particular. This just seemed a=20 > good place to jump in.) >=20 > I'd like to remind people that this is a charter, not a=20 > technical specification. We need guidance to the working=20 > group. It doesn't have to be perfect, and there's room for=20 > some flexibility >=20 > >=20 > >=20 > It seems to me that the syntax is mainly what we care about,=20 > _not_ the architecture of coordinating bodies. My=20 > understanding is the whole point of this exercise is to avoid=20 > building assumptions about that architecture and related=20 > policies into the technology itself. >=20 > If a national administration defines escape digits, we need=20 > to be able to handle escape digits. But that doesn't mean we=20 > have to import the whole administrative architecture. >=20 > >=20 >=20 > On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: >=20 > > The IETF has NOT defined telephone numbers. RFC 3966=20 > defines a syntax=20 > > that can be used to carry them, and I question whether that=20 > syntax is=20 > > appropriate for use in the scenarios so far identified. To=20 > understand=20 > > what RFC 3966 means one has to go to E.164 (and associated national=20 > > numbering plans) and hope it touchs with the terminology=20 > used in those=20 > > places. > > > > I am fine as far it goes in terms of a sequence of decimal=20 > digits, but=20 > > when we get to whether a phone context is required, then that is a=20 > > jump into essentially supporting multiple numbering plans over a=20 > > single interface. That would seem to be identifying an=20 > architecture of=20 > > coordinating bodies with multiple numbering plans well beyond the=20 > > scope of what is described so far. > > > > Within national administration, escape digits are defined=20 > within the=20 > > national numbering plan to clearly identity all allocations=20 > within the=20 > > national area. At least my assumption is that any procedures we are=20 > > looking at would be within the context of a national numbering plan. > > If you have ideas that go beyond this, then perhaps you=20 > need to expand=20 > > on them, because that goes way beyond what we have discussed so far. > > > > Keith > > > >> -----Original Message----- > >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve=20 > >> Donovan > >> Sent: 14 May 2015 14:02 > >> To: modern@ietf.org > >> Subject: [Modern] Definition of TN (was Re: Proposed change to=20 > >> paragraph three of the charter) > >> > >> The IETF has already spent time defining telephone numbers=20 > and I see=20 > >> little value in redefining the concept in the MODERN charter. As=20 > >> such, I propose that we include a reference to RFC3966 as the=20 > >> definition of TN. > >> > >> As one data point, the SCIM work references RFC3966 for telephone=20 > >> numbers. We might, by the way, want to add SCIM to the=20 > list of areas=20 > >> we look at in the charter. > >> > >> See my comments on Kieth's points below. > >> > >> Regards, > >> > >> Steve > >> > >> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: > >>> Firstly the charter gives no definition of what you are > >> using for telephone number, e.g. by reference to RFC 3966. > >>> > >>> RFC 3966 basically defines it as any sequence of decimal > >> digits. Other usages elsewhere include alphabetic=20 > characters, because=20 > >> this name is used both in the context of what the user=20 > represents to=20 > >> other users as his number and what actually gets used in a=20 > signalling=20 > >> protocol. > >>> > >>> The ITU-T terms actually distinguish between those two > >> usages, by putting them in separate recommendations. > >> SRD> RFC3966 deals with this, indicating that alphabetic > >> characters are > >> limited to local (non global) numbers. > >>> > >>> The additionally problem with RFC 3966 as a definition as > >> it does not define a usage where every sequence of digits=20 > is unique,=20 > >> and therefore it has to add a phone context to enable that=20 > uniqueness=20 > >> to exist, with a default applying to "global" > >> numbers. > >>> > >>> So do you intend such digit sequences used within this > >> group to be unique or will it need a phone context as a result of=20 > >> using the RFC 3966 definition? The definitions I provided=20 > would not. > >> SRD> I suspect we will follow RFC3966, with global numbers=20 > being the > >> default. There is no reason to limit what MODERN does to managing=20 > >> global numbers. I would not, however, suggest we take on=20 > including=20 > >> private number resources as a use case for the initial MODERN=20 > >> charter. > >>> > >>> In regard to: > >>> > >>>> I do gather that you believe the expertise to do the MODERN work=20 > >>>> resides in SG-2 rather than in the IETF. But the=20 > proposed working=20 > >>>> group will not, say, reassign country code > >>>> +44 to someone else, or do any of the things you'd need the > >>>> expertise and authority of that body to do. We're not delegating=20 > >>>> authority for country codes to Internet entities as ENUM > >> did, which > >>>> necessitated an IAB liaison with SG-2, even. Those are=20 > all policy=20 > >>>> issues. We're not trying to build policy, we're trying to > >> build tools > >>>> that will work in a variety of policy environments. > >>> Then I do not believe that. I believe SG2 should define > >> what the numbers are that we use, and maybe they should define the=20 > >> use cases. Once it is reduced to fulfilling a protocol=20 > requirement,=20 > >> then I anyone (including IETF) can do the work. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >>>> Sent: 12 May 2015 17:37 > >>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>> Subject: Re: [Modern] Proposed change to paragraph three of the=20 > >>>> charter > >>>> > >>>> > >>>> No, what I've said consistently is that what I mean by=20 > the term is=20 > >>>> what > >>>> RFC3966 meant by the term. TeRQ deferred to that=20 > specification for=20 > >>>> its formal definition of telephone number, say. I see no=20 > reason to=20 > >>>> reinvent that wheel. > >>>> > >>>> If we get to a place where the term "telephone number" is > >> imprecise > >>>> or toxic, then I think we've confused ourselves into a > >> rejection of > >>>> common sense and common usage. The term is used without warning=20 > >>>> labels in IETF standards track specifications already.=20 > The bar you=20 > >>>> are raising is not consistent with IETF usage. > >>>> > >>>> I do gather that you believe the expertise to do the MODERN work=20 > >>>> resides in SG-2 rather than in the IETF. But the=20 > proposed working=20 > >>>> group will not, say, reassign country code > >>>> +44 to someone else, or do any of the things you'd need the > >>>> expertise and authority of that body to do. We're not delegating=20 > >>>> authority for country codes to Internet entities as ENUM > >> did, which > >>>> necessitated an IAB liaison with SG-2, even. Those are=20 > all policy=20 > >>>> issues. We're not trying to build policy, we're trying to > >> build tools > >>>> that will work in a variety of policy environments. > >>>> > >>>> Jon Peterson > >>>> Neustar, Inc. > >>>> > >>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" > >>>> wrote: > >>>> > >>>>> I am not doing that at all. > >>>>> > >>>>> I am proposing to remove any attempt by you and others to > >>>> use the term > >>>>> "telephone number" in a totally undefined manner, and > >>>> replacing it with > >>>>> terms that have been defined by the body that knows about > >>>> these things, > >>>>> i.e. SG2 of ITU-T. > >>>>> > >>>>> You are consisting opposing telling us what you mean by=20 > the team. > >>>>> > >>>>> My proposal is not to include the term "telephone=20 > number" at all. > >>>>> > >>>>> Regards > >>>>> > >>>>> Keith > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of > >>>> Peterson, > >>>>>> Jon > >>>>>> Sent: 12 May 2015 16:17 > >>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>>>> Subject: Re: [Modern] Proposed change to paragraph=20 > three of the=20 > >>>>>> charter > >>>>>> > >>>>>> > >>>>>> Again, I'd be more sympathetic to this request to invent a > >>>> new IETF > >>>>>> definition of telephone numbers if we didn't already have > >>>> standards > >>>>>> track RFCs that have done that, and by reference to the same=20 > >>>>>> specifications you're describing here. > >>>>>> > >>>>>> We don't mean anything different by telephone numbers than the=20 > >>>>>> abstract of > >>>>>> RFC3966 did when it said that "the 'tel' URI describes=20 > resources=20 > >>>>>> identified by telephone numbers." > >>>>>> > >>>>>> Jon Peterson > >>>>>> Neustar, Inc. > >>>>>> > >>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" > >>>>>> wrote: > >>>>>> > >>>>>>> I do not agree with the charter being widened to "TN" or > >>>> presumably > >>>>>>> "telephone numbers". The reason for this is that telephone > >>>>>> numbers has > >>>>>>> a wide and undefined scope, possibly including alphabetic > >>>>>> characters as > >>>>>>> well (as in the letters on the dialling ring). > >>>>>>> > >>>>>>> Based on the statements made by others in terms of what > >>>> needs to be > >>>>>>> covered, I would prefer a more precise definition of: > >>>> "international > >>>>>>> E.164 numbers, local special purpose numbers, and network > >>>> specific > >>>>>>> numbers" using the explanation of these terms that can be > >>>> found in > >>>>>>> ITU-T Recommendation E.164. > >>>>>>> > >>>>>>> Keith > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf > >>>> Of Steve > >>>>>>>> Donovan > >>>>>>>> Sent: 07 May 2015 14:51 > >>>>>>>> To: modern@ietf.org > >>>>>>>> Subject: [Modern] Proposed change to paragraph three of the=20 > >>>>>>>> charter > >>>>>>>> > >>>>>>>> All, > >>>>>>>> > >>>>>>>> Paragraph three currently reads as follows: > >>>>>>>> > >>>>>>>> "The work of this group will focus on E.164 telephone > >>>>>> numbers due to > >>>>>>>> the changing telecom environment and interest expressed by=20 > >>>>>>>> telecommunications industry regulators to support more > >> flexible > >>>>>>>> regulatory models than exist today. > >>>>>>>> There is an expectation that aspects of the architecture and=20 > >>>>>>>> protocols defined by the working group will be reusable > >>>> for other > >>>>>>>> user-focused identifiers. Any such extensions or reuse > >>>> of MODERN > >>>>>>>> mechanisms are out of scope for the MODERN working group. > >>>>>> Solutions > >>>>>>>> and mechanisms created by the working group will be > >>>>>> flexible enough > >>>>>>>> to accommodate different policies, e.g., by different > >>>> regulatory > >>>>>>>> agencies." > >>>>>>>> > >>>>>>>> I propose changing the first sentence to the following: > >>>>>>>> > >>>>>>>> "The work of this group will focus on TNs -- such as E.164 > >>>>>> numbers -- > >>>>>>>> and blocks of TNs, that are used to initiate > >> communication with > >>>>>>>> another user of a service. The work is motivated by > >>>> the changing > >>>>>>>> telecom environment and interest expressed by > >>>> telecommunications > >>>>>>>> industry regulators to support more flexible regulatory > >>>>>> models than > >>>>>>>> exist today. " > >>>>>>>> > >>>>>>>> The remainder of the paragraph, starting with "There is an=20 > >>>>>>>> expectation..." would remain unchanged. > >>>>>>>> > >>>>>>>> This adds some clarity on the scope of telephony > >>>>>> identifiers covered > >>>>>>>> as well as making it clear that blocks of TNs are=20 > also covered. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Steve > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Modern mailing list > >>>>>>>> Modern@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Modern mailing list > >>>>>>> Modern@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>> _______________________________________________ > >>>>>> Modern mailing list > >>>>>> Modern@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>> > >>>> > >>> _______________________________________________ > >>> Modern mailing list > >>> Modern@ietf.org > >>> https://www.ietf.org/mailman/listinfo/modern > >>> > >> > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> https://www.ietf.org/mailman/listinfo/modern > >> > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > = From nobody Fri May 15 08:42:46 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 D95441A0067 for ; Fri, 15 May 2015 08:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, SPF_SOFTFAIL=0.665] 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 5NTiVy2A71da for ; Fri, 15 May 2015 08:42:41 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A4F1A0030 for ; Fri, 15 May 2015 08:42:39 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-09v.sys.comcast.net with comcast id UFhT1q00426dK1R01FieV5; Fri, 15 May 2015 15:42:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id UFid1q00F3Ge9ey01Fid07; Fri, 15 May 2015 15:42:38 +0000 Message-ID: <555613EC.9090909@alum.mit.edu> Date: Fri, 15 May 2015 11:42:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1431704558; bh=IygPOBL3UMgA13ov9/JqrWSOmxnd/dg03MfAMpq4oTI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WcbPAximlUc1Fk47FN8+zAKzUy34JwV5DqiwfbGqLLk/m+fHb8uea/nOQNyczdPwD jA7v+Vtfz1HkVICiUC064ZKPhRWKgfVlFR3fALWU7nhFtsOMVFggb54LGwHOOg5+8C uvN58KFohmY5WhWiB40L4WncOmXVDpolbVpvAQcc9hcEfqd3ALH7S9+EnZKEFA+/rO JwN4224VL0obqqQjxr/KAbGU0YWmV3SE3WM/LP6812HbwkY4N4fh67/OsqPoO5dLuY ngfm2EFBE7+XlMbsgiwed9B/f9OK4/sbqHHa/7Ynsk9qC2jc9W+//1uS6U62DEI665 Wtw+sbpfP2C7Q== Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 15:42:45 -0000 On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote: > You have at least missed the point I have been making. > > By using RFC 3966 as a syntax definition, you automatically include a requirement to support phone context. > > The point I am making is that in my understanding from the use cases so far discussed, phone context is unnecessary, as we are dealing with protocol with a single administration supporting a single national numbering space. The context is one only and implicit in the administration one is presumably securely communicating with. Isn't it an expectation that the numbers being discussed *can* be represented in SIP? If so, then 3966 is relevant. Thanks, Paul > Keith > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 15 May 2015 15:04 >> To: DRAGE, Keith (Keith) >> Cc: Steve Donovan; modern@ietf.org >> Subject: Re: [Modern] Definition of TN (was Re: Proposed >> change to paragraph three of the charter) >> >> >> >> (I'm not picking on Keith in particular. This just seemed a >> good place to jump in.) >> >> I'd like to remind people that this is a charter, not a >> technical specification. We need guidance to the working >> group. It doesn't have to be perfect, and there's room for >> some flexibility >> >> >> >> >> >> It seems to me that the syntax is mainly what we care about, >> _not_ the architecture of coordinating bodies. My >> understanding is the whole point of this exercise is to avoid >> building assumptions about that architecture and related >> policies into the technology itself. >> >> If a national administration defines escape digits, we need >> to be able to handle escape digits. But that doesn't mean we >> have to import the whole administrative architecture. >> >> >> >> >> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: >> >>> The IETF has NOT defined telephone numbers. RFC 3966 >> defines a syntax >>> that can be used to carry them, and I question whether that >> syntax is >>> appropriate for use in the scenarios so far identified. To >> understand >>> what RFC 3966 means one has to go to E.164 (and associated national >>> numbering plans) and hope it touchs with the terminology >> used in those >>> places. >>> >>> I am fine as far it goes in terms of a sequence of decimal >> digits, but >>> when we get to whether a phone context is required, then that is a >>> jump into essentially supporting multiple numbering plans over a >>> single interface. That would seem to be identifying an >> architecture of >>> coordinating bodies with multiple numbering plans well beyond the >>> scope of what is described so far. >>> >>> Within national administration, escape digits are defined >> within the >>> national numbering plan to clearly identity all allocations >> within the >>> national area. At least my assumption is that any procedures we are >>> looking at would be within the context of a national numbering plan. >>> If you have ideas that go beyond this, then perhaps you >> need to expand >>> on them, because that goes way beyond what we have discussed so far. >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >>>> Donovan >>>> Sent: 14 May 2015 14:02 >>>> To: modern@ietf.org >>>> Subject: [Modern] Definition of TN (was Re: Proposed change to >>>> paragraph three of the charter) >>>> >>>> The IETF has already spent time defining telephone numbers >> and I see >>>> little value in redefining the concept in the MODERN charter. As >>>> such, I propose that we include a reference to RFC3966 as the >>>> definition of TN. >>>> >>>> As one data point, the SCIM work references RFC3966 for telephone >>>> numbers. We might, by the way, want to add SCIM to the >> list of areas >>>> we look at in the charter. >>>> >>>> See my comments on Kieth's points below. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: >>>>> Firstly the charter gives no definition of what you are >>>> using for telephone number, e.g. by reference to RFC 3966. >>>>> >>>>> RFC 3966 basically defines it as any sequence of decimal >>>> digits. Other usages elsewhere include alphabetic >> characters, because >>>> this name is used both in the context of what the user >> represents to >>>> other users as his number and what actually gets used in a >> signalling >>>> protocol. >>>>> >>>>> The ITU-T terms actually distinguish between those two >>>> usages, by putting them in separate recommendations. >>>> SRD> RFC3966 deals with this, indicating that alphabetic >>>> characters are >>>> limited to local (non global) numbers. >>>>> >>>>> The additionally problem with RFC 3966 as a definition as >>>> it does not define a usage where every sequence of digits >> is unique, >>>> and therefore it has to add a phone context to enable that >> uniqueness >>>> to exist, with a default applying to "global" >>>> numbers. >>>>> >>>>> So do you intend such digit sequences used within this >>>> group to be unique or will it need a phone context as a result of >>>> using the RFC 3966 definition? The definitions I provided >> would not. >>>> SRD> I suspect we will follow RFC3966, with global numbers >> being the >>>> default. There is no reason to limit what MODERN does to managing >>>> global numbers. I would not, however, suggest we take on >> including >>>> private number resources as a use case for the initial MODERN >>>> charter. >>>>> >>>>> In regard to: >>>>> >>>>>> I do gather that you believe the expertise to do the MODERN work >>>>>> resides in SG-2 rather than in the IETF. But the >> proposed working >>>>>> group will not, say, reassign country code >>>>>> +44 to someone else, or do any of the things you'd need the >>>>>> expertise and authority of that body to do. We're not delegating >>>>>> authority for country codes to Internet entities as ENUM >>>> did, which >>>>>> necessitated an IAB liaison with SG-2, even. Those are >> all policy >>>>>> issues. We're not trying to build policy, we're trying to >>>> build tools >>>>>> that will work in a variety of policy environments. >>>>> Then I do not believe that. I believe SG2 should define >>>> what the numbers are that we use, and maybe they should define the >>>> use cases. Once it is reduced to fulfilling a protocol >> requirement, >>>> then I anyone (including IETF) can do the work. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>>>> Sent: 12 May 2015 17:37 >>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>> Subject: Re: [Modern] Proposed change to paragraph three of the >>>>>> charter >>>>>> >>>>>> >>>>>> No, what I've said consistently is that what I mean by >> the term is >>>>>> what >>>>>> RFC3966 meant by the term. TeRQ deferred to that >> specification for >>>>>> its formal definition of telephone number, say. I see no >> reason to >>>>>> reinvent that wheel. >>>>>> >>>>>> If we get to a place where the term "telephone number" is >>>> imprecise >>>>>> or toxic, then I think we've confused ourselves into a >>>> rejection of >>>>>> common sense and common usage. The term is used without warning >>>>>> labels in IETF standards track specifications already. >> The bar you >>>>>> are raising is not consistent with IETF usage. >>>>>> >>>>>> I do gather that you believe the expertise to do the MODERN work >>>>>> resides in SG-2 rather than in the IETF. But the >> proposed working >>>>>> group will not, say, reassign country code >>>>>> +44 to someone else, or do any of the things you'd need the >>>>>> expertise and authority of that body to do. We're not delegating >>>>>> authority for country codes to Internet entities as ENUM >>>> did, which >>>>>> necessitated an IAB liaison with SG-2, even. Those are >> all policy >>>>>> issues. We're not trying to build policy, we're trying to >>>> build tools >>>>>> that will work in a variety of policy environments. >>>>>> >>>>>> Jon Peterson >>>>>> Neustar, Inc. >>>>>> >>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >>>>>> wrote: >>>>>> >>>>>>> I am not doing that at all. >>>>>>> >>>>>>> I am proposing to remove any attempt by you and others to >>>>>> use the term >>>>>>> "telephone number" in a totally undefined manner, and >>>>>> replacing it with >>>>>>> terms that have been defined by the body that knows about >>>>>> these things, >>>>>>> i.e. SG2 of ITU-T. >>>>>>> >>>>>>> You are consisting opposing telling us what you mean by >> the team. >>>>>>> >>>>>>> My proposal is not to include the term "telephone >> number" at all. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>>>> Peterson, >>>>>>>> Jon >>>>>>>> Sent: 12 May 2015 16:17 >>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>>>> Subject: Re: [Modern] Proposed change to paragraph >> three of the >>>>>>>> charter >>>>>>>> >>>>>>>> >>>>>>>> Again, I'd be more sympathetic to this request to invent a >>>>>> new IETF >>>>>>>> definition of telephone numbers if we didn't already have >>>>>> standards >>>>>>>> track RFCs that have done that, and by reference to the same >>>>>>>> specifications you're describing here. >>>>>>>> >>>>>>>> We don't mean anything different by telephone numbers than the >>>>>>>> abstract of >>>>>>>> RFC3966 did when it said that "the 'tel' URI describes >> resources >>>>>>>> identified by telephone numbers." >>>>>>>> >>>>>>>> Jon Peterson >>>>>>>> Neustar, Inc. >>>>>>>> >>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I do not agree with the charter being widened to "TN" or >>>>>> presumably >>>>>>>>> "telephone numbers". The reason for this is that telephone >>>>>>>> numbers has >>>>>>>>> a wide and undefined scope, possibly including alphabetic >>>>>>>> characters as >>>>>>>>> well (as in the letters on the dialling ring). >>>>>>>>> >>>>>>>>> Based on the statements made by others in terms of what >>>>>> needs to be >>>>>>>>> covered, I would prefer a more precise definition of: >>>>>> "international >>>>>>>>> E.164 numbers, local special purpose numbers, and network >>>>>> specific >>>>>>>>> numbers" using the explanation of these terms that can be >>>>>> found in >>>>>>>>> ITU-T Recommendation E.164. >>>>>>>>> >>>>>>>>> Keith >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>>>> Of Steve >>>>>>>>>> Donovan >>>>>>>>>> Sent: 07 May 2015 14:51 >>>>>>>>>> To: modern@ietf.org >>>>>>>>>> Subject: [Modern] Proposed change to paragraph three of the >>>>>>>>>> charter >>>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> Paragraph three currently reads as follows: >>>>>>>>>> >>>>>>>>>> "The work of this group will focus on E.164 telephone >>>>>>>> numbers due to >>>>>>>>>> the changing telecom environment and interest expressed by >>>>>>>>>> telecommunications industry regulators to support more >>>> flexible >>>>>>>>>> regulatory models than exist today. >>>>>>>>>> There is an expectation that aspects of the architecture and >>>>>>>>>> protocols defined by the working group will be reusable >>>>>> for other >>>>>>>>>> user-focused identifiers. Any such extensions or reuse >>>>>> of MODERN >>>>>>>>>> mechanisms are out of scope for the MODERN working group. >>>>>>>> Solutions >>>>>>>>>> and mechanisms created by the working group will be >>>>>>>> flexible enough >>>>>>>>>> to accommodate different policies, e.g., by different >>>>>> regulatory >>>>>>>>>> agencies." >>>>>>>>>> >>>>>>>>>> I propose changing the first sentence to the following: >>>>>>>>>> >>>>>>>>>> "The work of this group will focus on TNs -- such as E.164 >>>>>>>> numbers -- >>>>>>>>>> and blocks of TNs, that are used to initiate >>>> communication with >>>>>>>>>> another user of a service. The work is motivated by >>>>>> the changing >>>>>>>>>> telecom environment and interest expressed by >>>>>> telecommunications >>>>>>>>>> industry regulators to support more flexible regulatory >>>>>>>> models than >>>>>>>>>> exist today. " >>>>>>>>>> >>>>>>>>>> The remainder of the paragraph, starting with "There is an >>>>>>>>>> expectation..." would remain unchanged. >>>>>>>>>> >>>>>>>>>> This adds some clarity on the scope of telephony >>>>>>>> identifiers covered >>>>>>>>>> as well as making it clear that blocks of TNs are >> also covered. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Steve >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Modern mailing list >>>>>>>>>> Modern@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Modern mailing list >>>>>>>>> Modern@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>> _______________________________________________ >>>>>>>> Modern mailing list >>>>>>>> Modern@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/modern >>>>> >>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Fri May 15 09:42:16 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 C7BF51A6EE2 for ; Fri, 15 May 2015 09:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.267 X-Spam-Level: X-Spam-Status: No, score=-104.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 9A8ygEGL6BOP for ; Fri, 15 May 2015 09:42:12 -0700 (PDT) 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 896AE1A3BA6 for ; Fri, 15 May 2015 09:42:12 -0700 (PDT) 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 t4FGYgPP026011; Fri, 15 May 2015 12:42:10 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1udkx5g1s3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 May 2015 12:42:10 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 15 May 2015 12:42:08 -0400 From: "Peterson, Jon" To: Paul Kyzivat , "modern@ietf.org" Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) Thread-Index: AQHQjkbl3MVV4l0UZkeopNcFxh4jfp19SR+AgAANTACAAAkoAIAAEnUA//+bOIA= Date: Fri, 15 May 2015 16:42:08 +0000 Message-ID: References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555613EC.9090909@alum.mit.edu> In-Reply-To: <555613EC.9090909@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F83CE2413FA664C98ADA5549867B706@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-15_04:2015-05-15,2015-05-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=9.62338542187524e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999510175003986 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.999510175003986 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.999510175003986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505150217 Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 16:42:16 -0000 The fundamental point here is that the MODERN working group proposes to treat telephone numbers as an existing identifier defined elsewhere, not to define them itself. If it were defining telephone numbers, then I think it would actually be infringing on the turf of SG-2. The "definition" of telephone numbers in RFC3966 is indeed just an attempt to capture the syntax of an existing identifier out there in the world in IETFese. That is clearly within the IETF's purview, and MODERN would not be breaking any new ground to simply follow that definition. TeRQ is slightly more specific about which parts of the ABNF of RFC3966 are useful to this effort, but per Ben's point, we aren't going to specify the protocol in our charter language. Jon Peterson Neustar, Inc. On 5/15/15, 8:42 AM, "Paul Kyzivat" wrote: >On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote: >> You have at least missed the point I have been making. >> >> By using RFC 3966 as a syntax definition, you automatically include a >>requirement to support phone context. >> >> The point I am making is that in my understanding from the use cases so >>far discussed, phone context is unnecessary, as we are dealing with >>protocol with a single administration supporting a single national >>numbering space. The context is one only and implicit in the >>administration one is presumably securely communicating with. > >Isn't it an expectation that the numbers being discussed *can* be >represented in SIP? If so, then 3966 is relevant. > > Thanks, > Paul > >> Keith >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: 15 May 2015 15:04 >>> To: DRAGE, Keith (Keith) >>> Cc: Steve Donovan; modern@ietf.org >>> Subject: Re: [Modern] Definition of TN (was Re: Proposed >>> change to paragraph three of the charter) >>> >>> >>> >>> (I'm not picking on Keith in particular. This just seemed a >>> good place to jump in.) >>> >>> I'd like to remind people that this is a charter, not a >>> technical specification. We need guidance to the working >>> group. It doesn't have to be perfect, and there's room for >>> some flexibility >>> >>> >>> >>> >>> >>> It seems to me that the syntax is mainly what we care about, >>> _not_ the architecture of coordinating bodies. My >>> understanding is the whole point of this exercise is to avoid >>> building assumptions about that architecture and related >>> policies into the technology itself. >>> >>> If a national administration defines escape digits, we need >>> to be able to handle escape digits. But that doesn't mean we >>> have to import the whole administrative architecture. >>> >>> >>> >>> >>> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: >>> >>>> The IETF has NOT defined telephone numbers. RFC 3966 >>> defines a syntax >>>> that can be used to carry them, and I question whether that >>> syntax is >>>> appropriate for use in the scenarios so far identified. To >>> understand >>>> what RFC 3966 means one has to go to E.164 (and associated national >>>> numbering plans) and hope it touchs with the terminology >>> used in those >>>> places. >>>> >>>> I am fine as far it goes in terms of a sequence of decimal >>> digits, but >>>> when we get to whether a phone context is required, then that is a >>>> jump into essentially supporting multiple numbering plans over a >>>> single interface. That would seem to be identifying an >>> architecture of >>>> coordinating bodies with multiple numbering plans well beyond the >>>> scope of what is described so far. >>>> >>>> Within national administration, escape digits are defined >>> within the >>>> national numbering plan to clearly identity all allocations >>> within the >>>> national area. At least my assumption is that any procedures we are >>>> looking at would be within the context of a national numbering plan. >>>> If you have ideas that go beyond this, then perhaps you >>> need to expand >>>> on them, because that goes way beyond what we have discussed so far. >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >>>>> Donovan >>>>> Sent: 14 May 2015 14:02 >>>>> To: modern@ietf.org >>>>> Subject: [Modern] Definition of TN (was Re: Proposed change to >>>>> paragraph three of the charter) >>>>> >>>>> The IETF has already spent time defining telephone numbers >>> and I see >>>>> little value in redefining the concept in the MODERN charter. As >>>>> such, I propose that we include a reference to RFC3966 as the >>>>> definition of TN. >>>>> >>>>> As one data point, the SCIM work references RFC3966 for telephone >>>>> numbers. We might, by the way, want to add SCIM to the >>> list of areas >>>>> we look at in the charter. >>>>> >>>>> See my comments on Kieth's points below. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: >>>>>> Firstly the charter gives no definition of what you are >>>>> using for telephone number, e.g. by reference to RFC 3966. >>>>>> >>>>>> RFC 3966 basically defines it as any sequence of decimal >>>>> digits. Other usages elsewhere include alphabetic >>> characters, because >>>>> this name is used both in the context of what the user >>> represents to >>>>> other users as his number and what actually gets used in a >>> signalling >>>>> protocol. >>>>>> >>>>>> The ITU-T terms actually distinguish between those two >>>>> usages, by putting them in separate recommendations. >>>>> SRD> RFC3966 deals with this, indicating that alphabetic >>>>> characters are >>>>> limited to local (non global) numbers. >>>>>> >>>>>> The additionally problem with RFC 3966 as a definition as >>>>> it does not define a usage where every sequence of digits >>> is unique, >>>>> and therefore it has to add a phone context to enable that >>> uniqueness >>>>> to exist, with a default applying to "global" >>>>> numbers. >>>>>> >>>>>> So do you intend such digit sequences used within this >>>>> group to be unique or will it need a phone context as a result of >>>>> using the RFC 3966 definition? The definitions I provided >>> would not. >>>>> SRD> I suspect we will follow RFC3966, with global numbers >>> being the >>>>> default. There is no reason to limit what MODERN does to managing >>>>> global numbers. I would not, however, suggest we take on >>> including >>>>> private number resources as a use case for the initial MODERN >>>>> charter. >>>>>> >>>>>> In regard to: >>>>>> >>>>>>> I do gather that you believe the expertise to do the MODERN work >>>>>>> resides in SG-2 rather than in the IETF. But the >>> proposed working >>>>>>> group will not, say, reassign country code >>>>>>> +44 to someone else, or do any of the things you'd need the >>>>>>> expertise and authority of that body to do. We're not delegating >>>>>>> authority for country codes to Internet entities as ENUM >>>>> did, which >>>>>>> necessitated an IAB liaison with SG-2, even. Those are >>> all policy >>>>>>> issues. We're not trying to build policy, we're trying to >>>>> build tools >>>>>>> that will work in a variety of policy environments. >>>>>> Then I do not believe that. I believe SG2 should define >>>>> what the numbers are that we use, and maybe they should define the >>>>> use cases. Once it is reduced to fulfilling a protocol >>> requirement, >>>>> then I anyone (including IETF) can do the work. >>>>>> >>>>>> Regards >>>>>> >>>>>> Keith >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>>>>> Sent: 12 May 2015 17:37 >>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>>> Subject: Re: [Modern] Proposed change to paragraph three of the >>>>>>> charter >>>>>>> >>>>>>> >>>>>>> No, what I've said consistently is that what I mean by >>> the term is >>>>>>> what >>>>>>> RFC3966 meant by the term. TeRQ deferred to that >>> specification for >>>>>>> its formal definition of telephone number, say. I see no >>> reason to >>>>>>> reinvent that wheel. >>>>>>> >>>>>>> If we get to a place where the term "telephone number" is >>>>> imprecise >>>>>>> or toxic, then I think we've confused ourselves into a >>>>> rejection of >>>>>>> common sense and common usage. The term is used without warning >>>>>>> labels in IETF standards track specifications already. >>> The bar you >>>>>>> are raising is not consistent with IETF usage. >>>>>>> >>>>>>> I do gather that you believe the expertise to do the MODERN work >>>>>>> resides in SG-2 rather than in the IETF. But the >>> proposed working >>>>>>> group will not, say, reassign country code >>>>>>> +44 to someone else, or do any of the things you'd need the >>>>>>> expertise and authority of that body to do. We're not delegating >>>>>>> authority for country codes to Internet entities as ENUM >>>>> did, which >>>>>>> necessitated an IAB liaison with SG-2, even. Those are >>> all policy >>>>>>> issues. We're not trying to build policy, we're trying to >>>>> build tools >>>>>>> that will work in a variety of policy environments. >>>>>>> >>>>>>> Jon Peterson >>>>>>> Neustar, Inc. >>>>>>> >>>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >>>>>>> wrote: >>>>>>> >>>>>>>> I am not doing that at all. >>>>>>>> >>>>>>>> I am proposing to remove any attempt by you and others to >>>>>>> use the term >>>>>>>> "telephone number" in a totally undefined manner, and >>>>>>> replacing it with >>>>>>>> terms that have been defined by the body that knows about >>>>>>> these things, >>>>>>>> i.e. SG2 of ITU-T. >>>>>>>> >>>>>>>> You are consisting opposing telling us what you mean by >>> the team. >>>>>>>> >>>>>>>> My proposal is not to include the term "telephone >>> number" at all. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>>>>> Peterson, >>>>>>>>> Jon >>>>>>>>> Sent: 12 May 2015 16:17 >>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph >>> three of the >>>>>>>>> charter >>>>>>>>> >>>>>>>>> >>>>>>>>> Again, I'd be more sympathetic to this request to invent a >>>>>>> new IETF >>>>>>>>> definition of telephone numbers if we didn't already have >>>>>>> standards >>>>>>>>> track RFCs that have done that, and by reference to the same >>>>>>>>> specifications you're describing here. >>>>>>>>> >>>>>>>>> We don't mean anything different by telephone numbers than the >>>>>>>>> abstract of >>>>>>>>> RFC3966 did when it said that "the 'tel' URI describes >>> resources >>>>>>>>> identified by telephone numbers." >>>>>>>>> >>>>>>>>> Jon Peterson >>>>>>>>> Neustar, Inc. >>>>>>>>> >>>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I do not agree with the charter being widened to "TN" or >>>>>>> presumably >>>>>>>>>> "telephone numbers". The reason for this is that telephone >>>>>>>>> numbers has >>>>>>>>>> a wide and undefined scope, possibly including alphabetic >>>>>>>>> characters as >>>>>>>>>> well (as in the letters on the dialling ring). >>>>>>>>>> >>>>>>>>>> Based on the statements made by others in terms of what >>>>>>> needs to be >>>>>>>>>> covered, I would prefer a more precise definition of: >>>>>>> "international >>>>>>>>>> E.164 numbers, local special purpose numbers, and network >>>>>>> specific >>>>>>>>>> numbers" using the explanation of these terms that can be >>>>>>> found in >>>>>>>>>> ITU-T Recommendation E.164. >>>>>>>>>> >>>>>>>>>> Keith >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>>>>> Of Steve >>>>>>>>>>> Donovan >>>>>>>>>>> Sent: 07 May 2015 14:51 >>>>>>>>>>> To: modern@ietf.org >>>>>>>>>>> Subject: [Modern] Proposed change to paragraph three of the >>>>>>>>>>> charter >>>>>>>>>>> >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>> Paragraph three currently reads as follows: >>>>>>>>>>> >>>>>>>>>>> "The work of this group will focus on E.164 telephone >>>>>>>>> numbers due to >>>>>>>>>>> the changing telecom environment and interest expressed by >>>>>>>>>>> telecommunications industry regulators to support more >>>>> flexible >>>>>>>>>>> regulatory models than exist today. >>>>>>>>>>> There is an expectation that aspects of the architecture and >>>>>>>>>>> protocols defined by the working group will be reusable >>>>>>> for other >>>>>>>>>>> user-focused identifiers. Any such extensions or reuse >>>>>>> of MODERN >>>>>>>>>>> mechanisms are out of scope for the MODERN working group. >>>>>>>>> Solutions >>>>>>>>>>> and mechanisms created by the working group will be >>>>>>>>> flexible enough >>>>>>>>>>> to accommodate different policies, e.g., by different >>>>>>> regulatory >>>>>>>>>>> agencies." >>>>>>>>>>> >>>>>>>>>>> I propose changing the first sentence to the following: >>>>>>>>>>> >>>>>>>>>>> "The work of this group will focus on TNs -- such as E.164 >>>>>>>>> numbers -- >>>>>>>>>>> and blocks of TNs, that are used to initiate >>>>> communication with >>>>>>>>>>> another user of a service. The work is motivated by >>>>>>> the changing >>>>>>>>>>> telecom environment and interest expressed by >>>>>>> telecommunications >>>>>>>>>>> industry regulators to support more flexible regulatory >>>>>>>>> models than >>>>>>>>>>> exist today. " >>>>>>>>>>> >>>>>>>>>>> The remainder of the paragraph, starting with "There is an >>>>>>>>>>> expectation..." would remain unchanged. >>>>>>>>>>> >>>>>>>>>>> This adds some clarity on the scope of telephony >>>>>>>>> identifiers covered >>>>>>>>>>> as well as making it clear that blocks of TNs are >>> also covered. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Steve >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Modern mailing list >>>>>>>>>>> Modern@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Modern mailing list >>>>>>>>>> Modern@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>> _______________________________________________ >>>>>>>>> Modern mailing list >>>>>>>>> Modern@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/modern >>>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Fri May 15 11:02:16 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 E71761A037E for ; Fri, 15 May 2015 11:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 C4agfzZSkDrE for ; Fri, 15 May 2015 11:02:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 0BBB21A0121 for ; Fri, 15 May 2015 11:02:10 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 8D94AC39F7DC6; Fri, 15 May 2015 18:02:05 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4FI28t7010262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 20:02:08 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 15 May 2015 20:02:08 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "modern@ietf.org" Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) Thread-Index: AQHQjkbpUuR1BJIpCkKrpn8PN3KHwp19Lw/vgAAmYoA= Date: Fri, 15 May 2015 18:02:07 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69715FB5@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555613EC.9090909@alum.mit.edu> In-Reply-To: <555613EC.9090909@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Fri, 15 May 2015 18:02:15 -0000 You tell me, but my expectation, that it will not happen on a per session b= asis, and any entity receiving this information will be capable of, and nee= d to be capable of, switching between the different number formats. Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Paul Kyzivat > Sent: 15 May 2015 16:43 > To: modern@ietf.org > Subject: Re: [Modern] Definition of TN (was Re: Proposed=20 > change to paragraph three of the charter) >=20 > On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote: > > You have at least missed the point I have been making. > > > > By using RFC 3966 as a syntax definition, you automatically=20 > include a requirement to support phone context. > > > > The point I am making is that in my understanding from the=20 > use cases so far discussed, phone context is unnecessary, as=20 > we are dealing with protocol with a single administration=20 > supporting a single national numbering space. The context is=20 > one only and implicit in the administration one is presumably=20 > securely communicating with. >=20 > Isn't it an expectation that the numbers being discussed=20 > *can* be represented in SIP? If so, then 3966 is relevant. >=20 > Thanks, > Paul >=20 > > Keith > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: 15 May 2015 15:04 > >> To: DRAGE, Keith (Keith) > >> Cc: Steve Donovan; modern@ietf.org > >> Subject: Re: [Modern] Definition of TN (was Re: Proposed change to=20 > >> paragraph three of the charter) > >> > >> > >> > >> (I'm not picking on Keith in particular. This just seemed a good=20 > >> place to jump in.) > >> > >> I'd like to remind people that this is a charter, not a technical=20 > >> specification. We need guidance to the working group. It=20 > doesn't have=20 > >> to be perfect, and there's room for some flexibility > >> > >> > >> > >> > >> > >> It seems to me that the syntax is mainly what we care about, _not_=20 > >> the architecture of coordinating bodies. My understanding is the=20 > >> whole point of this exercise is to avoid building=20 > assumptions about=20 > >> that architecture and related policies into the technology itself. > >> > >> If a national administration defines escape digits, we need to be=20 > >> able to handle escape digits. But that doesn't mean we=20 > have to import=20 > >> the whole administrative architecture. > >> > >> > >> > >> > >> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: > >> > >>> The IETF has NOT defined telephone numbers. RFC 3966 > >> defines a syntax > >>> that can be used to carry them, and I question whether that > >> syntax is > >>> appropriate for use in the scenarios so far identified. To > >> understand > >>> what RFC 3966 means one has to go to E.164 (and=20 > associated national=20 > >>> numbering plans) and hope it touchs with the terminology > >> used in those > >>> places. > >>> > >>> I am fine as far it goes in terms of a sequence of decimal > >> digits, but > >>> when we get to whether a phone context is required, then=20 > that is a=20 > >>> jump into essentially supporting multiple numbering plans over a=20 > >>> single interface. That would seem to be identifying an > >> architecture of > >>> coordinating bodies with multiple numbering plans well beyond the=20 > >>> scope of what is described so far. > >>> > >>> Within national administration, escape digits are defined > >> within the > >>> national numbering plan to clearly identity all allocations > >> within the > >>> national area. At least my assumption is that any=20 > procedures we are=20 > >>> looking at would be within the context of a national=20 > numbering plan. > >>> If you have ideas that go beyond this, then perhaps you > >> need to expand > >>> on them, because that goes way beyond what we have=20 > discussed so far. > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve=20 > >>>> Donovan > >>>> Sent: 14 May 2015 14:02 > >>>> To: modern@ietf.org > >>>> Subject: [Modern] Definition of TN (was Re: Proposed change to=20 > >>>> paragraph three of the charter) > >>>> > >>>> The IETF has already spent time defining telephone numbers > >> and I see > >>>> little value in redefining the concept in the MODERN=20 > charter. As=20 > >>>> such, I propose that we include a reference to RFC3966 as the=20 > >>>> definition of TN. > >>>> > >>>> As one data point, the SCIM work references RFC3966 for=20 > telephone=20 > >>>> numbers. We might, by the way, want to add SCIM to the > >> list of areas > >>>> we look at in the charter. > >>>> > >>>> See my comments on Kieth's points below. > >>>> > >>>> Regards, > >>>> > >>>> Steve > >>>> > >>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: > >>>>> Firstly the charter gives no definition of what you are > >>>> using for telephone number, e.g. by reference to RFC 3966. > >>>>> > >>>>> RFC 3966 basically defines it as any sequence of decimal > >>>> digits. Other usages elsewhere include alphabetic > >> characters, because > >>>> this name is used both in the context of what the user > >> represents to > >>>> other users as his number and what actually gets used in a > >> signalling > >>>> protocol. > >>>>> > >>>>> The ITU-T terms actually distinguish between those two > >>>> usages, by putting them in separate recommendations. > >>>> SRD> RFC3966 deals with this, indicating that alphabetic > >>>> characters are > >>>> limited to local (non global) numbers. > >>>>> > >>>>> The additionally problem with RFC 3966 as a definition as > >>>> it does not define a usage where every sequence of digits > >> is unique, > >>>> and therefore it has to add a phone context to enable that > >> uniqueness > >>>> to exist, with a default applying to "global" > >>>> numbers. > >>>>> > >>>>> So do you intend such digit sequences used within this > >>>> group to be unique or will it need a phone context as a=20 > result of=20 > >>>> using the RFC 3966 definition? The definitions I provided > >> would not. > >>>> SRD> I suspect we will follow RFC3966, with global numbers > >> being the > >>>> default. There is no reason to limit what MODERN does=20 > to managing=20 > >>>> global numbers. I would not, however, suggest we take on > >> including > >>>> private number resources as a use case for the initial MODERN=20 > >>>> charter. > >>>>> > >>>>> In regard to: > >>>>> > >>>>>> I do gather that you believe the expertise to do the=20 > MODERN work=20 > >>>>>> resides in SG-2 rather than in the IETF. But the > >> proposed working > >>>>>> group will not, say, reassign country code > >>>>>> +44 to someone else, or do any of the things you'd need the > >>>>>> expertise and authority of that body to do. We're not=20 > delegating=20 > >>>>>> authority for country codes to Internet entities as ENUM > >>>> did, which > >>>>>> necessitated an IAB liaison with SG-2, even. Those are > >> all policy > >>>>>> issues. We're not trying to build policy, we're trying to > >>>> build tools > >>>>>> that will work in a variety of policy environments. > >>>>> Then I do not believe that. I believe SG2 should define > >>>> what the numbers are that we use, and maybe they should=20 > define the=20 > >>>> use cases. Once it is reduced to fulfilling a protocol > >> requirement, > >>>> then I anyone (including IETF) can do the work. > >>>>> > >>>>> Regards > >>>>> > >>>>> Keith > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >>>>>> Sent: 12 May 2015 17:37 > >>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>>>> Subject: Re: [Modern] Proposed change to paragraph=20 > three of the=20 > >>>>>> charter > >>>>>> > >>>>>> > >>>>>> No, what I've said consistently is that what I mean by > >> the term is > >>>>>> what > >>>>>> RFC3966 meant by the term. TeRQ deferred to that > >> specification for > >>>>>> its formal definition of telephone number, say. I see no > >> reason to > >>>>>> reinvent that wheel. > >>>>>> > >>>>>> If we get to a place where the term "telephone number" is > >>>> imprecise > >>>>>> or toxic, then I think we've confused ourselves into a > >>>> rejection of > >>>>>> common sense and common usage. The term is used=20 > without warning=20 > >>>>>> labels in IETF standards track specifications already. > >> The bar you > >>>>>> are raising is not consistent with IETF usage. > >>>>>> > >>>>>> I do gather that you believe the expertise to do the=20 > MODERN work=20 > >>>>>> resides in SG-2 rather than in the IETF. But the > >> proposed working > >>>>>> group will not, say, reassign country code > >>>>>> +44 to someone else, or do any of the things you'd need the > >>>>>> expertise and authority of that body to do. We're not=20 > delegating=20 > >>>>>> authority for country codes to Internet entities as ENUM > >>>> did, which > >>>>>> necessitated an IAB liaison with SG-2, even. Those are > >> all policy > >>>>>> issues. We're not trying to build policy, we're trying to > >>>> build tools > >>>>>> that will work in a variety of policy environments. > >>>>>> > >>>>>> Jon Peterson > >>>>>> Neustar, Inc. > >>>>>> > >>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" > >>>>>> wrote: > >>>>>> > >>>>>>> I am not doing that at all. > >>>>>>> > >>>>>>> I am proposing to remove any attempt by you and others to > >>>>>> use the term > >>>>>>> "telephone number" in a totally undefined manner, and > >>>>>> replacing it with > >>>>>>> terms that have been defined by the body that knows about > >>>>>> these things, > >>>>>>> i.e. SG2 of ITU-T. > >>>>>>> > >>>>>>> You are consisting opposing telling us what you mean by > >> the team. > >>>>>>> > >>>>>>> My proposal is not to include the term "telephone > >> number" at all. > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Keith > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of > >>>>>> Peterson, > >>>>>>>> Jon > >>>>>>>> Sent: 12 May 2015 16:17 > >>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>>>>>> Subject: Re: [Modern] Proposed change to paragraph > >> three of the > >>>>>>>> charter > >>>>>>>> > >>>>>>>> > >>>>>>>> Again, I'd be more sympathetic to this request to invent a > >>>>>> new IETF > >>>>>>>> definition of telephone numbers if we didn't already have > >>>>>> standards > >>>>>>>> track RFCs that have done that, and by reference to the same=20 > >>>>>>>> specifications you're describing here. > >>>>>>>> > >>>>>>>> We don't mean anything different by telephone=20 > numbers than the=20 > >>>>>>>> abstract of > >>>>>>>> RFC3966 did when it said that "the 'tel' URI describes > >> resources > >>>>>>>> identified by telephone numbers." > >>>>>>>> > >>>>>>>> Jon Peterson > >>>>>>>> Neustar, Inc. > >>>>>>>> > >>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> I do not agree with the charter being widened to "TN" or > >>>>>> presumably > >>>>>>>>> "telephone numbers". The reason for this is that telephone > >>>>>>>> numbers has > >>>>>>>>> a wide and undefined scope, possibly including alphabetic > >>>>>>>> characters as > >>>>>>>>> well (as in the letters on the dialling ring). > >>>>>>>>> > >>>>>>>>> Based on the statements made by others in terms of what > >>>>>> needs to be > >>>>>>>>> covered, I would prefer a more precise definition of: > >>>>>> "international > >>>>>>>>> E.164 numbers, local special purpose numbers, and network > >>>>>> specific > >>>>>>>>> numbers" using the explanation of these terms that can be > >>>>>> found in > >>>>>>>>> ITU-T Recommendation E.164. > >>>>>>>>> > >>>>>>>>> Keith > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf > >>>>>> Of Steve > >>>>>>>>>> Donovan > >>>>>>>>>> Sent: 07 May 2015 14:51 > >>>>>>>>>> To: modern@ietf.org > >>>>>>>>>> Subject: [Modern] Proposed change to paragraph=20 > three of the=20 > >>>>>>>>>> charter > >>>>>>>>>> > >>>>>>>>>> All, > >>>>>>>>>> > >>>>>>>>>> Paragraph three currently reads as follows: > >>>>>>>>>> > >>>>>>>>>> "The work of this group will focus on E.164 telephone > >>>>>>>> numbers due to > >>>>>>>>>> the changing telecom environment and interest expressed by=20 > >>>>>>>>>> telecommunications industry regulators to support more > >>>> flexible > >>>>>>>>>> regulatory models than exist today. > >>>>>>>>>> There is an expectation that aspects of the=20 > architecture and=20 > >>>>>>>>>> protocols defined by the working group will be reusable > >>>>>> for other > >>>>>>>>>> user-focused identifiers. Any such extensions or reuse > >>>>>> of MODERN > >>>>>>>>>> mechanisms are out of scope for the MODERN working group. > >>>>>>>> Solutions > >>>>>>>>>> and mechanisms created by the working group will be > >>>>>>>> flexible enough > >>>>>>>>>> to accommodate different policies, e.g., by different > >>>>>> regulatory > >>>>>>>>>> agencies." > >>>>>>>>>> > >>>>>>>>>> I propose changing the first sentence to the following: > >>>>>>>>>> > >>>>>>>>>> "The work of this group will focus on TNs -- such as E.164 > >>>>>>>> numbers -- > >>>>>>>>>> and blocks of TNs, that are used to initiate > >>>> communication with > >>>>>>>>>> another user of a service. The work is motivated by > >>>>>> the changing > >>>>>>>>>> telecom environment and interest expressed by > >>>>>> telecommunications > >>>>>>>>>> industry regulators to support more flexible regulatory > >>>>>>>> models than > >>>>>>>>>> exist today. " > >>>>>>>>>> > >>>>>>>>>> The remainder of the paragraph, starting with "There is an=20 > >>>>>>>>>> expectation..." would remain unchanged. > >>>>>>>>>> > >>>>>>>>>> This adds some clarity on the scope of telephony > >>>>>>>> identifiers covered > >>>>>>>>>> as well as making it clear that blocks of TNs are > >> also covered. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Steve > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Modern mailing list > >>>>>>>>>> Modern@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Modern mailing list > >>>>>>>>> Modern@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>> _______________________________________________ > >>>>>>>> Modern mailing list > >>>>>>>> Modern@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> Modern mailing list > >>>>> Modern@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Modern mailing list > >>>> Modern@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/modern > >>>> > >>> _______________________________________________ > >>> Modern mailing list > >>> Modern@ietf.org > >>> https://www.ietf.org/mailman/listinfo/modern > >> > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > = From nobody Mon May 18 08:50:43 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 3B71E1AC3E3 for ; Mon, 18 May 2015 08:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, 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 mLv-I4GiJo2x for ; Mon, 18 May 2015 08:50:38 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 23B081AC3E0 for ; Mon, 18 May 2015 08:50:38 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:52731 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YuNJF-000ANx-1H for modern@ietf.org; Mon, 18 May 2015 08:50:36 -0700 Message-ID: <555A0A44.5070409@usdonovans.com> Date: Mon, 18 May 2015 10:50:28 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555613EC.9090909@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69715FB5@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69715FB5@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Mon, 18 May 2015 15:50:41 -0000 Keith, I think this is something that can be discussed by the working group and, to my mind, doesn't require addressing in the charter. I can "cook up" a use case where public and private number formats could be used in a single session, but I don't feel that is relevant to the charter discussion. Can we live with the charter as currently worded and address this as part of the working group effort? Steve On 5/15/15 1:02 PM, DRAGE, Keith (Keith) wrote: > You tell me, but my expectation, that it will not happen on a per session basis, and any entity receiving this information will be capable of, and need to be capable of, switching between the different number formats. > > Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: 15 May 2015 16:43 >> To: modern@ietf.org >> Subject: Re: [Modern] Definition of TN (was Re: Proposed >> change to paragraph three of the charter) >> >> On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote: >>> You have at least missed the point I have been making. >>> >>> By using RFC 3966 as a syntax definition, you automatically >> include a requirement to support phone context. >>> The point I am making is that in my understanding from the >> use cases so far discussed, phone context is unnecessary, as >> we are dealing with protocol with a single administration >> supporting a single national numbering space. The context is >> one only and implicit in the administration one is presumably >> securely communicating with. >> >> Isn't it an expectation that the numbers being discussed >> *can* be represented in SIP? If so, then 3966 is relevant. >> >> Thanks, >> Paul >> >>> Keith >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: 15 May 2015 15:04 >>>> To: DRAGE, Keith (Keith) >>>> Cc: Steve Donovan; modern@ietf.org >>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed change to >>>> paragraph three of the charter) >>>> >>>> >>>> >>>> (I'm not picking on Keith in particular. This just seemed a good >>>> place to jump in.) >>>> >>>> I'd like to remind people that this is a charter, not a technical >>>> specification. We need guidance to the working group. It >> doesn't have >>>> to be perfect, and there's room for some flexibility >>>> >>>> >>>> >>>> >>>> >>>> It seems to me that the syntax is mainly what we care about, _not_ >>>> the architecture of coordinating bodies. My understanding is the >>>> whole point of this exercise is to avoid building >> assumptions about >>>> that architecture and related policies into the technology itself. >>>> >>>> If a national administration defines escape digits, we need to be >>>> able to handle escape digits. But that doesn't mean we >> have to import >>>> the whole administrative architecture. >>>> >>>> >>>> >>>> >>>> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: >>>> >>>>> The IETF has NOT defined telephone numbers. RFC 3966 >>>> defines a syntax >>>>> that can be used to carry them, and I question whether that >>>> syntax is >>>>> appropriate for use in the scenarios so far identified. To >>>> understand >>>>> what RFC 3966 means one has to go to E.164 (and >> associated national >>>>> numbering plans) and hope it touchs with the terminology >>>> used in those >>>>> places. >>>>> >>>>> I am fine as far it goes in terms of a sequence of decimal >>>> digits, but >>>>> when we get to whether a phone context is required, then >> that is a >>>>> jump into essentially supporting multiple numbering plans over a >>>>> single interface. That would seem to be identifying an >>>> architecture of >>>>> coordinating bodies with multiple numbering plans well beyond the >>>>> scope of what is described so far. >>>>> >>>>> Within national administration, escape digits are defined >>>> within the >>>>> national numbering plan to clearly identity all allocations >>>> within the >>>>> national area. At least my assumption is that any >> procedures we are >>>>> looking at would be within the context of a national >> numbering plan. >>>>> If you have ideas that go beyond this, then perhaps you >>>> need to expand >>>>> on them, because that goes way beyond what we have >> discussed so far. >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve >>>>>> Donovan >>>>>> Sent: 14 May 2015 14:02 >>>>>> To: modern@ietf.org >>>>>> Subject: [Modern] Definition of TN (was Re: Proposed change to >>>>>> paragraph three of the charter) >>>>>> >>>>>> The IETF has already spent time defining telephone numbers >>>> and I see >>>>>> little value in redefining the concept in the MODERN >> charter. As >>>>>> such, I propose that we include a reference to RFC3966 as the >>>>>> definition of TN. >>>>>> >>>>>> As one data point, the SCIM work references RFC3966 for >> telephone >>>>>> numbers. We might, by the way, want to add SCIM to the >>>> list of areas >>>>>> we look at in the charter. >>>>>> >>>>>> See my comments on Kieth's points below. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: >>>>>>> Firstly the charter gives no definition of what you are >>>>>> using for telephone number, e.g. by reference to RFC 3966. >>>>>>> RFC 3966 basically defines it as any sequence of decimal >>>>>> digits. Other usages elsewhere include alphabetic >>>> characters, because >>>>>> this name is used both in the context of what the user >>>> represents to >>>>>> other users as his number and what actually gets used in a >>>> signalling >>>>>> protocol. >>>>>>> The ITU-T terms actually distinguish between those two >>>>>> usages, by putting them in separate recommendations. >>>>>> SRD> RFC3966 deals with this, indicating that alphabetic >>>>>> characters are >>>>>> limited to local (non global) numbers. >>>>>>> The additionally problem with RFC 3966 as a definition as >>>>>> it does not define a usage where every sequence of digits >>>> is unique, >>>>>> and therefore it has to add a phone context to enable that >>>> uniqueness >>>>>> to exist, with a default applying to "global" >>>>>> numbers. >>>>>>> So do you intend such digit sequences used within this >>>>>> group to be unique or will it need a phone context as a >> result of >>>>>> using the RFC 3966 definition? The definitions I provided >>>> would not. >>>>>> SRD> I suspect we will follow RFC3966, with global numbers >>>> being the >>>>>> default. There is no reason to limit what MODERN does >> to managing >>>>>> global numbers. I would not, however, suggest we take on >>>> including >>>>>> private number resources as a use case for the initial MODERN >>>>>> charter. >>>>>>> In regard to: >>>>>>> >>>>>>>> I do gather that you believe the expertise to do the >> MODERN work >>>>>>>> resides in SG-2 rather than in the IETF. But the >>>> proposed working >>>>>>>> group will not, say, reassign country code >>>>>>>> +44 to someone else, or do any of the things you'd need the >>>>>>>> expertise and authority of that body to do. We're not >> delegating >>>>>>>> authority for country codes to Internet entities as ENUM >>>>>> did, which >>>>>>>> necessitated an IAB liaison with SG-2, even. Those are >>>> all policy >>>>>>>> issues. We're not trying to build policy, we're trying to >>>>>> build tools >>>>>>>> that will work in a variety of policy environments. >>>>>>> Then I do not believe that. I believe SG2 should define >>>>>> what the numbers are that we use, and maybe they should >> define the >>>>>> use cases. Once it is reduced to fulfilling a protocol >>>> requirement, >>>>>> then I anyone (including IETF) can do the work. >>>>>>> Regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>>>>>> Sent: 12 May 2015 17:37 >>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>>>> Subject: Re: [Modern] Proposed change to paragraph >> three of the >>>>>>>> charter >>>>>>>> >>>>>>>> >>>>>>>> No, what I've said consistently is that what I mean by >>>> the term is >>>>>>>> what >>>>>>>> RFC3966 meant by the term. TeRQ deferred to that >>>> specification for >>>>>>>> its formal definition of telephone number, say. I see no >>>> reason to >>>>>>>> reinvent that wheel. >>>>>>>> >>>>>>>> If we get to a place where the term "telephone number" is >>>>>> imprecise >>>>>>>> or toxic, then I think we've confused ourselves into a >>>>>> rejection of >>>>>>>> common sense and common usage. The term is used >> without warning >>>>>>>> labels in IETF standards track specifications already. >>>> The bar you >>>>>>>> are raising is not consistent with IETF usage. >>>>>>>> >>>>>>>> I do gather that you believe the expertise to do the >> MODERN work >>>>>>>> resides in SG-2 rather than in the IETF. But the >>>> proposed working >>>>>>>> group will not, say, reassign country code >>>>>>>> +44 to someone else, or do any of the things you'd need the >>>>>>>> expertise and authority of that body to do. We're not >> delegating >>>>>>>> authority for country codes to Internet entities as ENUM >>>>>> did, which >>>>>>>> necessitated an IAB liaison with SG-2, even. Those are >>>> all policy >>>>>>>> issues. We're not trying to build policy, we're trying to >>>>>> build tools >>>>>>>> that will work in a variety of policy environments. >>>>>>>> >>>>>>>> Jon Peterson >>>>>>>> Neustar, Inc. >>>>>>>> >>>>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I am not doing that at all. >>>>>>>>> >>>>>>>>> I am proposing to remove any attempt by you and others to >>>>>>>> use the term >>>>>>>>> "telephone number" in a totally undefined manner, and >>>>>>>> replacing it with >>>>>>>>> terms that have been defined by the body that knows about >>>>>>>> these things, >>>>>>>>> i.e. SG2 of ITU-T. >>>>>>>>> >>>>>>>>> You are consisting opposing telling us what you mean by >>>> the team. >>>>>>>>> My proposal is not to include the term "telephone >>>> number" at all. >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Keith >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>>>>>> Peterson, >>>>>>>>>> Jon >>>>>>>>>> Sent: 12 May 2015 16:17 >>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph >>>> three of the >>>>>>>>>> charter >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Again, I'd be more sympathetic to this request to invent a >>>>>>>> new IETF >>>>>>>>>> definition of telephone numbers if we didn't already have >>>>>>>> standards >>>>>>>>>> track RFCs that have done that, and by reference to the same >>>>>>>>>> specifications you're describing here. >>>>>>>>>> >>>>>>>>>> We don't mean anything different by telephone >> numbers than the >>>>>>>>>> abstract of >>>>>>>>>> RFC3966 did when it said that "the 'tel' URI describes >>>> resources >>>>>>>>>> identified by telephone numbers." >>>>>>>>>> >>>>>>>>>> Jon Peterson >>>>>>>>>> Neustar, Inc. >>>>>>>>>> >>>>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I do not agree with the charter being widened to "TN" or >>>>>>>> presumably >>>>>>>>>>> "telephone numbers". The reason for this is that telephone >>>>>>>>>> numbers has >>>>>>>>>>> a wide and undefined scope, possibly including alphabetic >>>>>>>>>> characters as >>>>>>>>>>> well (as in the letters on the dialling ring). >>>>>>>>>>> >>>>>>>>>>> Based on the statements made by others in terms of what >>>>>>>> needs to be >>>>>>>>>>> covered, I would prefer a more precise definition of: >>>>>>>> "international >>>>>>>>>>> E.164 numbers, local special purpose numbers, and network >>>>>>>> specific >>>>>>>>>>> numbers" using the explanation of these terms that can be >>>>>>>> found in >>>>>>>>>>> ITU-T Recommendation E.164. >>>>>>>>>>> >>>>>>>>>>> Keith >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>>>>>> Of Steve >>>>>>>>>>>> Donovan >>>>>>>>>>>> Sent: 07 May 2015 14:51 >>>>>>>>>>>> To: modern@ietf.org >>>>>>>>>>>> Subject: [Modern] Proposed change to paragraph >> three of the >>>>>>>>>>>> charter >>>>>>>>>>>> >>>>>>>>>>>> All, >>>>>>>>>>>> >>>>>>>>>>>> Paragraph three currently reads as follows: >>>>>>>>>>>> >>>>>>>>>>>> "The work of this group will focus on E.164 telephone >>>>>>>>>> numbers due to >>>>>>>>>>>> the changing telecom environment and interest expressed by >>>>>>>>>>>> telecommunications industry regulators to support more >>>>>> flexible >>>>>>>>>>>> regulatory models than exist today. >>>>>>>>>>>> There is an expectation that aspects of the >> architecture and >>>>>>>>>>>> protocols defined by the working group will be reusable >>>>>>>> for other >>>>>>>>>>>> user-focused identifiers. Any such extensions or reuse >>>>>>>> of MODERN >>>>>>>>>>>> mechanisms are out of scope for the MODERN working group. >>>>>>>>>> Solutions >>>>>>>>>>>> and mechanisms created by the working group will be >>>>>>>>>> flexible enough >>>>>>>>>>>> to accommodate different policies, e.g., by different >>>>>>>> regulatory >>>>>>>>>>>> agencies." >>>>>>>>>>>> >>>>>>>>>>>> I propose changing the first sentence to the following: >>>>>>>>>>>> >>>>>>>>>>>> "The work of this group will focus on TNs -- such as E.164 >>>>>>>>>> numbers -- >>>>>>>>>>>> and blocks of TNs, that are used to initiate >>>>>> communication with >>>>>>>>>>>> another user of a service. The work is motivated by >>>>>>>> the changing >>>>>>>>>>>> telecom environment and interest expressed by >>>>>>>> telecommunications >>>>>>>>>>>> industry regulators to support more flexible regulatory >>>>>>>>>> models than >>>>>>>>>>>> exist today. " >>>>>>>>>>>> >>>>>>>>>>>> The remainder of the paragraph, starting with "There is an >>>>>>>>>>>> expectation..." would remain unchanged. >>>>>>>>>>>> >>>>>>>>>>>> This adds some clarity on the scope of telephony >>>>>>>>>> identifiers covered >>>>>>>>>>>> as well as making it clear that blocks of TNs are >>>> also covered. >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Steve >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Modern mailing list >>>>>>>>>>>> Modern@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Modern mailing list >>>>>>>>>>> Modern@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>> _______________________________________________ >>>>>>>>>> Modern mailing list >>>>>>>>>> Modern@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Modern mailing list >>>>>>> Modern@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>> >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/modern >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Mon May 18 15:14:44 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 8F27F1A86F5 for ; Mon, 18 May 2015 15:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 Z0U5GtHCeN0n for ; Mon, 18 May 2015 15:14:42 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7038B1A86EE for ; Mon, 18 May 2015 15:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=VbXmHKYnG6POEysdTRw5aRk2T0/znaeu6M34i9WKTgQ=; b=EM8vwj1slaZE9BVmWGdd4d1WEbNxYZa1ztJzFyqSFTzzCvdSGHPMU8bCShfflp+O35wqip0IzXe4dY2S3udRT1C9+ekKBs07RkfIyRSmqx8LQ7uLYDW3p7JhpzDbKgJbeY1GE0OkfS7M0LDU4BGjPnVGJU1K+xcabjGXvC9bEX8=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:58073 helo=[192.168.15.134]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YuTJ1-0006IV-Bw for modern@ietf.org; Mon, 18 May 2015 15:14:40 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_4EEC98D4-B971-43EF-9D98-08CEC7B9DA76"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: <5554EAEC.2070208@usdonovans.com> Date: Mon, 18 May 2015 18:14:37 -0400 Message-Id: References: <5554EAEC.2070208@usdonovans.com> To: "modern@ietf.org" X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] P2P (was Third revision of MODERN charter) 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: Mon, 18 May 2015 22:14:43 -0000 --Apple-Mail=_4EEC98D4-B971-43EF-9D98-08CEC7B9DA76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All of Henning=E2=80=99s slides were about number assignments in a = hierarchy. My recollection is all of the use cases were about number = assignments in a hierarchy. I am not against working on peer-to-peer = assignment technology. However, I wanted to make sure this is something = that people want to work on. What is the use case? Sorry if I missed it. When I greped the archive, = the term =E2=80=98peer=E2=80=99 does not hit, other than in the charter = drafts. > On May 14, 2015, at 2:35 PM, Steve Donovan = wrote: >=20 > TNs may either be managed in a hierarchical tree, or in a distributed = peer-to-peer architecture. --Apple-Mail=_4EEC98D4-B971-43EF-9D98-08CEC7B9DA76 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVWmRNAAoJEDY/T2tCIPW3WmMQAIhh1s1tzhgQBZy7+XHjpZO0 L25mQkb2gu8MsDjhwaGTBQC/VFWKROUDPVW4H6mMH4JQ3+tq9FDrEwxalh3o0LDU pBMhgh/FGy0ukwclGTUHt4mLbZ58lhSm0eEWBeFtd4hYPf/PJiPhF7B2+NbPU9sZ RJM1cLYegwSOMlqAJdplTBkgOrNHFXTxKjfsEbCOvPeHPRtEL11qa+qeEWAIfCfb qPm3XE76hmYtwOtelLuTL67sHVVUl5GpWkXvvvkaMFrVaUNhsMp6UhJtqKRq+xlG onSZEQOMhNGbl5H+jr0HpRAYyhlfJRVBoxNOw3qfNQDbMSQuu13VEYBeeQ72D2rk 8AL51xmk9f565kOlbkKc3rOY3QwfYoUf+Kyu0tahPOainkBxO8Q2+6ULRJDEFKBw 5/eOZcStmv/vh0Q3f8OWv2fecRi/YqT1HmVyxdsYa4hKkPTTmjTYy0y88WHugCcn 2m5PLTa4GM4nZI3fRvwLn+uOKYx+/brXpaVRk8N1TAJUHYitTaZN6gvII+yxOF45 ytFXQrkdSplgQDSgIlgNgZIJNnwXq3gMmHUfWLg/tGe7wO+LJduTjTo1vgsHF9R/ oNP5Sa/CA/0pRULlGCuyFahkJSSYy0sq8XUA2i8wlaizVf98V7sSmp2+Q2dA3gEQ 7RPTiZ0p4+zdba9Hezn/ =o/lC -----END PGP SIGNATURE----- --Apple-Mail=_4EEC98D4-B971-43EF-9D98-08CEC7B9DA76-- From nobody Mon May 18 15:23: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 23C1A1ACD58 for ; Mon, 18 May 2015 15:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 ruYfavHlW9vV for ; Mon, 18 May 2015 15:23:34 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840881ACD63 for ; Mon, 18 May 2015 15:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=whD/dr+W8wOApUFyoMKNokm8T6b8d+PhuWiTaeB6y1o=; b=OXnagROqMTYMc/lO9/b5kcYPN15DddwJdw6ksP+KYMjHgalVfpwDFYePrey3CQzJ3yiDRZJH6N4lgwPhP9IUOp2IWBVHRfR+ROrSzFRov6fqvOg65cNnVFv+tsPbzkLPjBImb3c9kQbb+LLW5Y4L62TmY17uQfofKQbOtaHSCj0=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:58378 helo=[192.168.15.134]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YuTRZ-0005EL-Es for modern@ietf.org; Mon, 18 May 2015 15:23:30 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_743B3229-D87F-43F8-AD53-BAD48B72A594"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Mon, 18 May 2015 18:23:27 -0400 Message-Id: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> To: modern@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] TN, E.164, or Something Else? 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: Mon, 18 May 2015 22:23:35 -0000 --Apple-Mail=_743B3229-D87F-43F8-AD53-BAD48B72A594 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Something I have been mulling about is the focus (and amount of list = traffic) discussing whether the scope of MODERN is E.164 numbers, = =E2=80=9Ctelephone numbers,=E2=80=9D or something else. We seem to get very emotional about E.164 numbers. Perhaps rightly so. = An E.164 number carries a lot of a=E2=80=99priori regulatory baggage. By = definition, the ITU-T assigns country codes. National numbering = authorities allocate numbers to service providers. Service providers = manage them for users. A =E2=80=9Ctelephone number=E2=80=9D spawns the debate as to whether it = is, in fact, a =E2=80=98telephone=E2=80=99 number. Given Henning=E2=80=99s= presentation, the value of the telephone number is global routing and = global understanding for 5/7ths of the world using romanized arabic = script. Given that, the people who worry that =E2=80=9Ctelephone = number=E2=80=9D is just a code word for E.164 number are most likely = correct. This spills into the whole =E2=80=9CIt is not an E.164 number, = it is the ABNF for an E.164 number (see RFC3966).=E2=80=9D I.e., it = looks, smells, and tastes like a rose. Could we agree to disagree and say that MODERN is about managing = globally unique identifiers that have a syntax of up to 15 decimal = digits that have some hierarchical authorities mixed in to lock down who = can and cannot request and assign numbers? Those authorities can be an = opaque thingbat, because that is where we get into the policy bits, and = everyone on the list swears MODERN will not touch policy. --Apple-Mail=_743B3229-D87F-43F8-AD53-BAD48B72A594 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVWmZfAAoJEDY/T2tCIPW3W1oQAJj/67xuWStpfvJAqdL/2Zsl 4ZUk8+k6AiKEFtP7D1As9xKyDGaAkhuZaxZHHzLWbBOVecTNgjLB9gNePiVk166/ RdRc8Gf80RHiK0aq0XVghq1YhzFKejzZkhbIXnS868S+PeEC4ISNP7kCBX7km4To VP4oU3oPrIkRwiFPWm6OFJ3LmDkcpupqLmh4NQdJ0iRpW9ZQ3x+JWlLqrzGIYzJI N/LDp4us6XdCcS2wvQ9QzL0tKCe52c9A5avi1RYS8EEet4cJsBkn0QrZUB//5jLX TQ5Ic3qqf9qL1O+COhmWwbd6toCfNuL+NsDtIMEnCSvGYgVkz+VJFWlkTKx4euGX Wty3nNC6paF2kbjhFFVeCwfCW/mVKwsKeLGu3CePgygqS0v0PGucPM2sMLDFnS+j s6qXdotOBR3ieCGsrUKSFc/KgJr6BjbDJhk4AOl1wE5CVAJATsR4YZ5BX2a3JXPN EbZCL8/Ay3oInvtVbg45DCUyFer6B4opKajxR+8W1+b9Ox896VMmz0GliXFRvLEu xDYBdzH3yFc9/4cmheEsunK5ZSCW3DOwZdMW7UsOoWQ/XOyA6OeNB6upobxh4JGe uGSSS5cCiXxyFClvnOssZYkytfk+a7vMQm3VXmjBS+rl4fsdQtxLAIdcR5Gd/VD1 keoslW36U4ouGsU64bw6 =Lb6d -----END PGP SIGNATURE----- --Apple-Mail=_743B3229-D87F-43F8-AD53-BAD48B72A594-- From nobody Mon May 18 16:05: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 117E61ACEC2 for ; Mon, 18 May 2015 16:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 85k0xI07fBpc for ; Mon, 18 May 2015 16:05:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 13AB51ACE6A for ; Mon, 18 May 2015 16:05:52 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1CE66C19EDE81; Mon, 18 May 2015 23:05:47 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4IN5n8U002127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 May 2015 01:05:50 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 19 May 2015 01:05:49 +0200 From: "DRAGE, Keith (Keith)" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) Thread-Index: AQHQjkbpUuR1BJIpCkKrpn8PN3KHwp19Lw/vgAAmYoCABHEzAIAAk6Zg Date: Mon, 18 May 2015 23:05:49 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6971717E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555613EC.9090909@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69715FB5@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555A0A44.5070409@usdonovans.com> In-Reply-To: <555A0A44.5070409@usdonovans.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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: Mon, 18 May 2015 23:05:57 -0000 I provided wording messages back which I think provided better definition o= f what we mean by telephone numbers that the current reference to RFC 3966,= which to me is providing a coding solution with too many options. And being able to "cook" up a use case does not mean that we need that as a= use case. Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Steve Donovan > Sent: 18 May 2015 16:50 > To: modern@ietf.org > Subject: Re: [Modern] Definition of TN (was Re: Proposed=20 > change to paragraph three of the charter) >=20 > Keith, >=20 > I think this is something that can be discussed by the=20 > working group and, to my mind, doesn't require addressing in=20 > the charter. >=20 > I can "cook up" a use case where public and private number=20 > formats could be used in a single session, but I don't feel=20 > that is relevant to the charter discussion. >=20 > Can we live with the charter as currently worded and address=20 > this as part of the working group effort? >=20 > Steve >=20 > On 5/15/15 1:02 PM, DRAGE, Keith (Keith) wrote: > > You tell me, but my expectation, that it will not happen on=20 > a per session basis, and any entity receiving this=20 > information will be capable of, and need to be capable of,=20 > switching between the different number formats. > > > > Keith > > > >> -----Original Message----- > >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Paul=20 > >> Kyzivat > >> Sent: 15 May 2015 16:43 > >> To: modern@ietf.org > >> Subject: Re: [Modern] Definition of TN (was Re: Proposed change to=20 > >> paragraph three of the charter) > >> > >> On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote: > >>> You have at least missed the point I have been making. > >>> > >>> By using RFC 3966 as a syntax definition, you automatically > >> include a requirement to support phone context. > >>> The point I am making is that in my understanding from the > >> use cases so far discussed, phone context is unnecessary,=20 > as we are=20 > >> dealing with protocol with a single administration supporting a=20 > >> single national numbering space. The context is one only=20 > and implicit=20 > >> in the administration one is presumably securely=20 > communicating with. > >> > >> Isn't it an expectation that the numbers being discussed > >> *can* be represented in SIP? If so, then 3966 is relevant. > >> > >> Thanks, > >> Paul > >> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Ben Campbell [mailto:ben@nostrum.com] > >>>> Sent: 15 May 2015 15:04 > >>>> To: DRAGE, Keith (Keith) > >>>> Cc: Steve Donovan; modern@ietf.org > >>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed=20 > change to=20 > >>>> paragraph three of the charter) > >>>> > >>>> > >>>> > >>>> (I'm not picking on Keith in particular. This just seemed a good=20 > >>>> place to jump in.) > >>>> > >>>> I'd like to remind people that this is a charter, not a=20 > technical=20 > >>>> specification. We need guidance to the working group. It > >> doesn't have > >>>> to be perfect, and there's room for some flexibility > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> It seems to me that the syntax is mainly what we care=20 > about, _not_=20 > >>>> the architecture of coordinating bodies. My understanding is the=20 > >>>> whole point of this exercise is to avoid building > >> assumptions about > >>>> that architecture and related policies into the=20 > technology itself. > >>>> > >>>> If a national administration defines escape digits, we=20 > need to be=20 > >>>> able to handle escape digits. But that doesn't mean we > >> have to import > >>>> the whole administrative architecture. > >>>> > >>>> > >>>> > >>>> > >>>> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: > >>>> > >>>>> The IETF has NOT defined telephone numbers. RFC 3966 > >>>> defines a syntax > >>>>> that can be used to carry them, and I question whether that > >>>> syntax is > >>>>> appropriate for use in the scenarios so far identified. To > >>>> understand > >>>>> what RFC 3966 means one has to go to E.164 (and > >> associated national > >>>>> numbering plans) and hope it touchs with the terminology > >>>> used in those > >>>>> places. > >>>>> > >>>>> I am fine as far it goes in terms of a sequence of decimal > >>>> digits, but > >>>>> when we get to whether a phone context is required, then > >> that is a > >>>>> jump into essentially supporting multiple numbering=20 > plans over a=20 > >>>>> single interface. That would seem to be identifying an > >>>> architecture of > >>>>> coordinating bodies with multiple numbering plans well=20 > beyond the=20 > >>>>> scope of what is described so far. > >>>>> > >>>>> Within national administration, escape digits are defined > >>>> within the > >>>>> national numbering plan to clearly identity all allocations > >>>> within the > >>>>> national area. At least my assumption is that any > >> procedures we are > >>>>> looking at would be within the context of a national > >> numbering plan. > >>>>> If you have ideas that go beyond this, then perhaps you > >>>> need to expand > >>>>> on them, because that goes way beyond what we have > >> discussed so far. > >>>>> Keith > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On=20 > Behalf Of Steve=20 > >>>>>> Donovan > >>>>>> Sent: 14 May 2015 14:02 > >>>>>> To: modern@ietf.org > >>>>>> Subject: [Modern] Definition of TN (was Re: Proposed change to=20 > >>>>>> paragraph three of the charter) > >>>>>> > >>>>>> The IETF has already spent time defining telephone numbers > >>>> and I see > >>>>>> little value in redefining the concept in the MODERN > >> charter. As > >>>>>> such, I propose that we include a reference to RFC3966 as the=20 > >>>>>> definition of TN. > >>>>>> > >>>>>> As one data point, the SCIM work references RFC3966 for > >> telephone > >>>>>> numbers. We might, by the way, want to add SCIM to the > >>>> list of areas > >>>>>> we look at in the charter. > >>>>>> > >>>>>> See my comments on Kieth's points below. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Steve > >>>>>> > >>>>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: > >>>>>>> Firstly the charter gives no definition of what you are > >>>>>> using for telephone number, e.g. by reference to RFC 3966. > >>>>>>> RFC 3966 basically defines it as any sequence of decimal > >>>>>> digits. Other usages elsewhere include alphabetic > >>>> characters, because > >>>>>> this name is used both in the context of what the user > >>>> represents to > >>>>>> other users as his number and what actually gets used in a > >>>> signalling > >>>>>> protocol. > >>>>>>> The ITU-T terms actually distinguish between those two > >>>>>> usages, by putting them in separate recommendations. > >>>>>> SRD> RFC3966 deals with this, indicating that alphabetic > >>>>>> characters are > >>>>>> limited to local (non global) numbers. > >>>>>>> The additionally problem with RFC 3966 as a definition as > >>>>>> it does not define a usage where every sequence of digits > >>>> is unique, > >>>>>> and therefore it has to add a phone context to enable that > >>>> uniqueness > >>>>>> to exist, with a default applying to "global" > >>>>>> numbers. > >>>>>>> So do you intend such digit sequences used within this > >>>>>> group to be unique or will it need a phone context as a > >> result of > >>>>>> using the RFC 3966 definition? The definitions I provided > >>>> would not. > >>>>>> SRD> I suspect we will follow RFC3966, with global numbers > >>>> being the > >>>>>> default. There is no reason to limit what MODERN does > >> to managing > >>>>>> global numbers. I would not, however, suggest we take on > >>>> including > >>>>>> private number resources as a use case for the initial MODERN=20 > >>>>>> charter. > >>>>>>> In regard to: > >>>>>>> > >>>>>>>> I do gather that you believe the expertise to do the > >> MODERN work > >>>>>>>> resides in SG-2 rather than in the IETF. But the > >>>> proposed working > >>>>>>>> group will not, say, reassign country code > >>>>>>>> +44 to someone else, or do any of the things you'd need the > >>>>>>>> expertise and authority of that body to do. We're not > >> delegating > >>>>>>>> authority for country codes to Internet entities as ENUM > >>>>>> did, which > >>>>>>>> necessitated an IAB liaison with SG-2, even. Those are > >>>> all policy > >>>>>>>> issues. We're not trying to build policy, we're trying to > >>>>>> build tools > >>>>>>>> that will work in a variety of policy environments. > >>>>>>> Then I do not believe that. I believe SG2 should define > >>>>>> what the numbers are that we use, and maybe they should > >> define the > >>>>>> use cases. Once it is reduced to fulfilling a protocol > >>>> requirement, > >>>>>> then I anyone (including IETF) can do the work. > >>>>>>> Regards > >>>>>>> > >>>>>>> Keith > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >>>>>>>> Sent: 12 May 2015 17:37 > >>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>>>>>> Subject: Re: [Modern] Proposed change to paragraph > >> three of the > >>>>>>>> charter > >>>>>>>> > >>>>>>>> > >>>>>>>> No, what I've said consistently is that what I mean by > >>>> the term is > >>>>>>>> what > >>>>>>>> RFC3966 meant by the term. TeRQ deferred to that > >>>> specification for > >>>>>>>> its formal definition of telephone number, say. I see no > >>>> reason to > >>>>>>>> reinvent that wheel. > >>>>>>>> > >>>>>>>> If we get to a place where the term "telephone number" is > >>>>>> imprecise > >>>>>>>> or toxic, then I think we've confused ourselves into a > >>>>>> rejection of > >>>>>>>> common sense and common usage. The term is used > >> without warning > >>>>>>>> labels in IETF standards track specifications already. > >>>> The bar you > >>>>>>>> are raising is not consistent with IETF usage. > >>>>>>>> > >>>>>>>> I do gather that you believe the expertise to do the > >> MODERN work > >>>>>>>> resides in SG-2 rather than in the IETF. But the > >>>> proposed working > >>>>>>>> group will not, say, reassign country code > >>>>>>>> +44 to someone else, or do any of the things you'd need the > >>>>>>>> expertise and authority of that body to do. We're not > >> delegating > >>>>>>>> authority for country codes to Internet entities as ENUM > >>>>>> did, which > >>>>>>>> necessitated an IAB liaison with SG-2, even. Those are > >>>> all policy > >>>>>>>> issues. We're not trying to build policy, we're trying to > >>>>>> build tools > >>>>>>>> that will work in a variety of policy environments. > >>>>>>>> > >>>>>>>> Jon Peterson > >>>>>>>> Neustar, Inc. > >>>>>>>> > >>>>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> I am not doing that at all. > >>>>>>>>> > >>>>>>>>> I am proposing to remove any attempt by you and others to > >>>>>>>> use the term > >>>>>>>>> "telephone number" in a totally undefined manner, and > >>>>>>>> replacing it with > >>>>>>>>> terms that have been defined by the body that knows about > >>>>>>>> these things, > >>>>>>>>> i.e. SG2 of ITU-T. > >>>>>>>>> > >>>>>>>>> You are consisting opposing telling us what you mean by > >>>> the team. > >>>>>>>>> My proposal is not to include the term "telephone > >>>> number" at all. > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Keith > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of > >>>>>>>> Peterson, > >>>>>>>>>> Jon > >>>>>>>>>> Sent: 12 May 2015 16:17 > >>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org > >>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph > >>>> three of the > >>>>>>>>>> charter > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Again, I'd be more sympathetic to this request to invent a > >>>>>>>> new IETF > >>>>>>>>>> definition of telephone numbers if we didn't already have > >>>>>>>> standards > >>>>>>>>>> track RFCs that have done that, and by reference=20 > to the same=20 > >>>>>>>>>> specifications you're describing here. > >>>>>>>>>> > >>>>>>>>>> We don't mean anything different by telephone > >> numbers than the > >>>>>>>>>> abstract of > >>>>>>>>>> RFC3966 did when it said that "the 'tel' URI describes > >>>> resources > >>>>>>>>>> identified by telephone numbers." > >>>>>>>>>> > >>>>>>>>>> Jon Peterson > >>>>>>>>>> Neustar, Inc. > >>>>>>>>>> > >>>>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> I do not agree with the charter being widened to "TN" or > >>>>>>>> presumably > >>>>>>>>>>> "telephone numbers". The reason for this is that telephone > >>>>>>>>>> numbers has > >>>>>>>>>>> a wide and undefined scope, possibly including alphabetic > >>>>>>>>>> characters as > >>>>>>>>>>> well (as in the letters on the dialling ring). > >>>>>>>>>>> > >>>>>>>>>>> Based on the statements made by others in terms of what > >>>>>>>> needs to be > >>>>>>>>>>> covered, I would prefer a more precise definition of: > >>>>>>>> "international > >>>>>>>>>>> E.164 numbers, local special purpose numbers, and network > >>>>>>>> specific > >>>>>>>>>>> numbers" using the explanation of these terms that can be > >>>>>>>> found in > >>>>>>>>>>> ITU-T Recommendation E.164. > >>>>>>>>>>> > >>>>>>>>>>> Keith > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf > >>>>>>>> Of Steve > >>>>>>>>>>>> Donovan > >>>>>>>>>>>> Sent: 07 May 2015 14:51 > >>>>>>>>>>>> To: modern@ietf.org > >>>>>>>>>>>> Subject: [Modern] Proposed change to paragraph > >> three of the > >>>>>>>>>>>> charter > >>>>>>>>>>>> > >>>>>>>>>>>> All, > >>>>>>>>>>>> > >>>>>>>>>>>> Paragraph three currently reads as follows: > >>>>>>>>>>>> > >>>>>>>>>>>> "The work of this group will focus on E.164 telephone > >>>>>>>>>> numbers due to > >>>>>>>>>>>> the changing telecom environment and interest=20 > expressed by=20 > >>>>>>>>>>>> telecommunications industry regulators to support more > >>>>>> flexible > >>>>>>>>>>>> regulatory models than exist today. > >>>>>>>>>>>> There is an expectation that aspects of the > >> architecture and > >>>>>>>>>>>> protocols defined by the working group will be reusable > >>>>>>>> for other > >>>>>>>>>>>> user-focused identifiers. Any such extensions or reuse > >>>>>>>> of MODERN > >>>>>>>>>>>> mechanisms are out of scope for the MODERN working group. > >>>>>>>>>> Solutions > >>>>>>>>>>>> and mechanisms created by the working group will be > >>>>>>>>>> flexible enough > >>>>>>>>>>>> to accommodate different policies, e.g., by different > >>>>>>>> regulatory > >>>>>>>>>>>> agencies." > >>>>>>>>>>>> > >>>>>>>>>>>> I propose changing the first sentence to the following: > >>>>>>>>>>>> > >>>>>>>>>>>> "The work of this group will focus on TNs --=20 > such as E.164 > >>>>>>>>>> numbers -- > >>>>>>>>>>>> and blocks of TNs, that are used to initiate > >>>>>> communication with > >>>>>>>>>>>> another user of a service. The work is motivated by > >>>>>>>> the changing > >>>>>>>>>>>> telecom environment and interest expressed by > >>>>>>>> telecommunications > >>>>>>>>>>>> industry regulators to support more flexible regulatory > >>>>>>>>>> models than > >>>>>>>>>>>> exist today. " > >>>>>>>>>>>> > >>>>>>>>>>>> The remainder of the paragraph, starting with=20 > "There is an=20 > >>>>>>>>>>>> expectation..." would remain unchanged. > >>>>>>>>>>>> > >>>>>>>>>>>> This adds some clarity on the scope of telephony > >>>>>>>>>> identifiers covered > >>>>>>>>>>>> as well as making it clear that blocks of TNs are > >>>> also covered. > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Steve > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Modern mailing list > >>>>>>>>>>>> Modern@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Modern mailing list > >>>>>>>>>>> Modern@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Modern mailing list > >>>>>>>>>> Modern@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Modern mailing list > >>>>>>> Modern@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Modern mailing list > >>>>>> Modern@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>> > >>>>> _______________________________________________ > >>>>> Modern mailing list > >>>>> Modern@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/modern > >>> _______________________________________________ > >>> Modern mailing list > >>> Modern@ietf.org > >>> https://www.ietf.org/mailman/listinfo/modern > >>> > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> https://www.ietf.org/mailman/listinfo/modern > >> > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > = From nobody Mon May 18 21:29:47 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 394221A003B for ; Mon, 18 May 2015 21:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 6OL49q6JJi6s for ; Mon, 18 May 2015 21:29:44 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A03A1A0052 for ; Mon, 18 May 2015 21:29:39 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so6297409pac.2 for ; Mon, 18 May 2015 21:29:39 -0700 (PDT) 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:content-transfer-encoding:message-id:references :to; bh=999kyN9Tm50l249LrCmPBrFoug2OlH7R3K8X9lpZcnw=; b=l80NurN/d7E52ALHvZkX3z1t3fOjQOHUodYWlijCnE5HWDSuQfIGm9ETBzNiUxTy4h 3aSvsvr7MsqumK+4IzMk289YUsA42RxLagyhm6KGCQ1C0PknRgnqwQQkkdruA8m0Bsh5 p5MS5VVlGi3/9V2mEsiyfxYSaJutJUoXrvi4ZtVkClsM6AJaZ0bqdhhEUkCC8qTVj2sw 7IqZipeh1uPzWMpgpCjdJbuZ/GHBQH61w+f4/1GYsfx5/Zg5vaUDLzwxdCZ5W3SUTJrM zH1JIGAMCRxVXrevcfBv2rfuhVQFdcgPAV7sjrX74P9beibVUPFVRJ/par+uFvX9EXHM jRwA== X-Gm-Message-State: ALoCoQniGVZByCyI9AyZcIKRX3+Cq36BPex78TUfgD7007/7hUz/qlMZeHv5nBylR06uFUckhWi8 X-Received: by 10.68.94.129 with SMTP id dc1mr50472160pbb.8.1432009779044; Mon, 18 May 2015 21:29:39 -0700 (PDT) Received: from [172.20.0.37] ([12.216.212.132]) by mx.google.com with ESMTPSA id dc8sm11567859pdb.23.2015.05.18.21.29.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 21:29:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Chris Wendt In-Reply-To: Date: Mon, 18 May 2015 21:29:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5554EAEC.2070208@usdonovans.com> To: Eric Burger X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] P2P (was Third revision of MODERN charter) 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, 19 May 2015 04:29:46 -0000 I think something like simply "Distributed Registry" might be a more = straight forward term to stick to. "Peer-to-peer" isn=E2=80=99t = necessarily an inappropriate way to describe the gossip based = distributed protocols Henning referred to in his presentation, but has = some historical meaning that could potentially confuse or imply = something other than what is being proposed or discussed.=20 > On May 18, 2015, at 3:14 PM, Eric Burger = wrote: >=20 > All of Henning=E2=80=99s slides were about number assignments in a = hierarchy. My recollection is all of the use cases were about number = assignments in a hierarchy. I am not against working on peer-to-peer = assignment technology. However, I wanted to make sure this is something = that people want to work on. >=20 > What is the use case? Sorry if I missed it. When I greped the archive, = the term =E2=80=98peer=E2=80=99 does not hit, other than in the charter = drafts. >=20 >> On May 14, 2015, at 2:35 PM, Steve Donovan = wrote: >>=20 >> TNs may either be managed in a hierarchical tree, or in a distributed = peer-to-peer architecture. >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Tue May 19 09:42:00 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 0A39F1A92F7 for ; Tue, 19 May 2015 09:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 qVWQKJfp5yZH for ; Tue, 19 May 2015 09:41:57 -0700 (PDT) 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 957F21A1A6B for ; Tue, 19 May 2015 09:41:57 -0700 (PDT) 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 t4JGcAA7026105; Tue, 19 May 2015 12:41:55 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1ug28a8w3x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 12:41:55 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Tue, 19 May 2015 12:41:53 -0400 From: "McGarry, Tom" To: Chris Wendt , Eric Burger Thread-Topic: [Modern] P2P (was Third revision of MODERN charter) Thread-Index: AQHQkbgPg9LW/RtZg0yUx/HQuu05o52C+HaAgACJjIA= Date: Tue, 19 May 2015 16:41:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-19_06:2015-05-19,2015-05-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.25843779841261e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.992957022353465 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.992957022353465 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.992957022353465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505190209 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] P2P (was Third revision of MODERN charter) 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, 19 May 2015 16:41:59 -0000 Good suggestion, much better. On 5/19/15 12:29 AM, "Chris Wendt" wrote: >I think something like simply "Distributed Registry" might be a more >straight forward term to stick to. "Peer-to-peer" isn=B9t necessarily an >inappropriate way to describe the gossip based distributed protocols >Henning referred to in his presentation, but has some historical meaning >that could potentially confuse or imply something other than what is >being proposed or discussed. > > >> On May 18, 2015, at 3:14 PM, Eric Burger >>wrote: >>=20 >> All of Henning=B9s slides were about number assignments in a hierarchy. >>My recollection is all of the use cases were about number assignments in >>a hierarchy. I am not against working on peer-to-peer assignment >>technology. However, I wanted to make sure this is something that people >>want to work on. >>=20 >> What is the use case? Sorry if I missed it. When I greped the archive, >>the term =8Cpeer=B9 does not hit, other than in the charter drafts. >>=20 >>> On May 14, 2015, at 2:35 PM, Steve Donovan >>>wrote: >>>=20 >>> TNs may either be managed in a hierarchical tree, or in a distributed >>>peer-to-peer architecture. >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s= =3DX >>phhxgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=3D= Xphh >xgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D=20 From nobody Tue May 19 11:28:15 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 85AE01A1BC6 for ; Tue, 19 May 2015 11:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 mJ07bT0yg47P for ; Tue, 19 May 2015 11:28:13 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1B41ACCDE for ; Tue, 19 May 2015 11:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=5tjvF5iYv4b1V5gBztoxYAhrxQuO/J0izWLRZeaVH1U=; b=i0JpUnzlyHLxWvRTb2AEgiC4xKHebNyhVP4o4dZofcu0p6U/XJHy3vtUK0ja5nHI7yQww+SDFZ5bbNkuH4aVf4eR3YUPNHCxzuWQz5szYRvmVaTd81dgsRJIG1XW2ml+3bA51OJnm1YJDcxePApemqvwnBSmXeNYL9vKlgEiHv0=; Received: from [141.161.13.82] (port=2922 helo=[10.176.0.186]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YumDM-0000fA-LV for modern@ietf.org; Tue, 19 May 2015 11:26:08 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_C2FFDA34-59E4-4BEE-AFE8-3B03D65B7283"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: Date: Tue, 19 May 2015 14:26:03 -0400 Message-Id: <285638B8-8EEB-4CA2-B1E2-AFA511C3E7D5@standardstrack.com> References: To: "modern@ietf.org" X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] P2P (was Third revision of MODERN charter) 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, 19 May 2015 18:28:14 -0000 --Apple-Mail=_C2FFDA34-59E4-4BEE-AFE8-3B03D65B7283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I like it too. A distributed yet authoritative directory can be (but not = necessarily) something distinguishable from a peer-to-peer DHT. > On May 19, 2015, at 12:41 PM, McGarry, Tom = wrote: >=20 > Good suggestion, much better. >=20 > On 5/19/15 12:29 AM, "Chris Wendt" wrote: >=20 >> I think something like simply "Distributed Registry" might be a more >> straight forward term to stick to. "Peer-to-peer" isn=C4=85t = necessarily an >> inappropriate way to describe the gossip based distributed protocols >> Henning referred to in his presentation, but has some historical = meaning >> that could potentially confuse or imply something other than what is >> being proposed or discussed. >>=20 >>=20 >>> On May 18, 2015, at 3:14 PM, Eric Burger = >>> wrote: >>>=20 >>> All of Henning=C4=85s slides were about number assignments in a = hierarchy. >>> My recollection is all of the use cases were about number = assignments in >>> a hierarchy. I am not against working on peer-to-peer assignment >>> technology. However, I wanted to make sure this is something that = people >>> want to work on. >>>=20 >>> What is the use case? Sorry if I missed it. When I greped the = archive, >>> the term =C5=9Apeer=C4=85 does not hit, other than in the charter = drafts. >>>=20 >>>> On May 14, 2015, at 2:35 PM, Steve Donovan = >>>> wrote: >>>>=20 >>>> TNs may either be managed in a hierarchical tree, or in a = distributed >>>> peer-to-peer architecture. >>>=20 >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>>=20 >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n >>> = _listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee= IDcLe >>> = xtZ1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=3D= X >>> phhxgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >> = listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >> = Z1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=3D= Xphh >> xgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D >=20 --Apple-Mail=_C2FFDA34-59E4-4BEE-AFE8-3B03D65B7283 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVW4A7AAoJEDY/T2tCIPW3UOAP/jGLVrwIzt4wxgWSZBSRjaHJ asB3vaehWqYJOtuuHNL/yKMnQJQLRTMwP1YC2uzgNt2qWta4Vhau399HdgPwYpBO vbV0mqkB+ha9FCCY+Erqpl+PqE+pzofgIzrUV6GBQtrRHDr3ClJdwDSF5sVxh+cr DNemgRCXezYVFhqtSV/8rBT3KL0OHhv1T/7O58erlhEHrQeSUU0vluURcNgxmFKL 9Z7t5+l6EfKKTaAeIbavdPh/48iE2tK+8WpgD+7rDvP7lfKVpZn2E7vG+B8VhQhd GUeXPISYnRNfXrCqwpC+S+gcxoKpTiCBwkKi2nN8VwxCpdl5mQemJckbjkUuxAQT QnMlge7whE+XSF93oGaqhXbcyjRkNbXBpYMwCtucQG3z7F3PR3Cs5Rstisx85nfl 2nGPyaIucBepavU4Cool+udXqID92zDiErXGMIweGm2/1+Bfdvf5KnB9FVzvoNct n4bTRLykzBhZREuNlzH771QaXSX8+InbhJeR4Lnd03Ee+JEvodjW85wfI7ymnSzc FDoVCDNyS2J6AVWbdsM9t7mcQCOdKD/tN8IGBeYsbvWwKH3bol1e9cMKTOTmhzc8 V8Anp2BfEfcPRsTasxfS/C2HE+sapBOO1HqBmuF/ANAddJiyTM8PP66UVtpGOkbM dk91y/qsh3laqhVbc1Ch =1WpO -----END PGP SIGNATURE----- --Apple-Mail=_C2FFDA34-59E4-4BEE-AFE8-3B03D65B7283-- From nobody Wed May 20 07:31:24 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 DC97D1A8777 for ; Wed, 20 May 2015 07:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 1hPpUwKVedBm for ; Wed, 20 May 2015 07:31:14 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 820551A876A for ; Wed, 20 May 2015 07:31:14 -0700 (PDT) Received: from 156.sub-70-196-11.myvzw.com ([70.196.11.156]:5777 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yv51b-000ABk-7R for modern@ietf.org; Wed, 20 May 2015 07:31:14 -0700 Message-ID: <555C9AAD.4080806@usdonovans.com> Date: Wed, 20 May 2015 09:31:09 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: modern@ietf.org References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> In-Reply-To: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> Content-Type: multipart/alternative; boundary="------------000705080008060101090902" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] TN, E.164, or Something Else? 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, 20 May 2015 14:31:17 -0000 This is a multi-part message in MIME format. --------------000705080008060101090902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Eric, I'm not comfortable with saying that MODERN is ONLY about managing globally unique identifiers as this rules out private numbering plans put in place by enterprises. Yes, MODERN is about globally unique identifiers that have the format of a telephone number, but it is also about private identifiers that also have the format of a telephone number. Regards, Steve On 5/18/15 5:23 PM, Eric Burger wrote: > Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else. > > We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users. > > A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose. > > Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy. > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --------------000705080008060101090902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Eric,

I'm not comfortable with saying that MODERN  is ONLY about managing globally unique identifiers as this rules out private numbering plans put in place by enterprises.

Yes, MODERN is about globally unique identifiers that have the format of a telephone number, but it is also about private identifiers that also have the format of a telephone number.

Regards,

Steve

On 5/18/15 5:23 PM, Eric Burger wrote:
Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.

A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy.



_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

--------------000705080008060101090902-- From nobody Wed May 20 07:33:47 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 2856F1A8777 for ; Wed, 20 May 2015 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, 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 hFhROkb_qd5z for ; Wed, 20 May 2015 07:33:42 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 AC32C1A8745 for ; Wed, 20 May 2015 07:33:42 -0700 (PDT) Received: from 156.sub-70-196-11.myvzw.com ([70.196.11.156]:5770 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yv53z-0000Oq-MR for modern@ietf.org; Wed, 20 May 2015 07:33:41 -0700 Message-ID: <555C9B42.3010906@usdonovans.com> Date: Wed, 20 May 2015 09:33:38 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: modern@ietf.org References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555613EC.9090909@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69715FB5@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555A0A44.5070409@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971717E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6971717E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter) 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, 20 May 2015 14:33:46 -0000 On 5/18/15 6:05 PM, DRAGE, Keith (Keith) wrote: > I provided wording messages back which I think provided better definition of what we mean by telephone numbers that the current reference to RFC 3966, which to me is providing a coding solution with too many options. Then we can pair away the options that don't apply as part of the working group effort. > > And being able to "cook" up a use case does not mean that we need that as a use case. I do think that private numbering plans should be in scope, or at least not ruled out of scope by the charter. > > Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Steve Donovan >> Sent: 18 May 2015 16:50 >> To: modern@ietf.org >> Subject: Re: [Modern] Definition of TN (was Re: Proposed >> change to paragraph three of the charter) >> >> Keith, >> >> I think this is something that can be discussed by the >> working group and, to my mind, doesn't require addressing in >> the charter. >> >> I can "cook up" a use case where public and private number >> formats could be used in a single session, but I don't feel >> that is relevant to the charter discussion. >> >> Can we live with the charter as currently worded and address >> this as part of the working group effort? >> >> Steve >> >> On 5/15/15 1:02 PM, DRAGE, Keith (Keith) wrote: >>> You tell me, but my expectation, that it will not happen on >> a per session basis, and any entity receiving this >> information will be capable of, and need to be capable of, >> switching between the different number formats. >>> Keith >>> >>>> -----Original Message----- >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Paul >>>> Kyzivat >>>> Sent: 15 May 2015 16:43 >>>> To: modern@ietf.org >>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed change to >>>> paragraph three of the charter) >>>> >>>> On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote: >>>>> You have at least missed the point I have been making. >>>>> >>>>> By using RFC 3966 as a syntax definition, you automatically >>>> include a requirement to support phone context. >>>>> The point I am making is that in my understanding from the >>>> use cases so far discussed, phone context is unnecessary, >> as we are >>>> dealing with protocol with a single administration supporting a >>>> single national numbering space. The context is one only >> and implicit >>>> in the administration one is presumably securely >> communicating with. >>>> Isn't it an expectation that the numbers being discussed >>>> *can* be represented in SIP? If so, then 3966 is relevant. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>>>> Sent: 15 May 2015 15:04 >>>>>> To: DRAGE, Keith (Keith) >>>>>> Cc: Steve Donovan; modern@ietf.org >>>>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed >> change to >>>>>> paragraph three of the charter) >>>>>> >>>>>> >>>>>> >>>>>> (I'm not picking on Keith in particular. This just seemed a good >>>>>> place to jump in.) >>>>>> >>>>>> I'd like to remind people that this is a charter, not a >> technical >>>>>> specification. We need guidance to the working group. It >>>> doesn't have >>>>>> to be perfect, and there's room for some flexibility >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It seems to me that the syntax is mainly what we care >> about, _not_ >>>>>> the architecture of coordinating bodies. My understanding is the >>>>>> whole point of this exercise is to avoid building >>>> assumptions about >>>>>> that architecture and related policies into the >> technology itself. >>>>>> If a national administration defines escape digits, we >> need to be >>>>>> able to handle escape digits. But that doesn't mean we >>>> have to import >>>>>> the whole administrative architecture. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote: >>>>>> >>>>>>> The IETF has NOT defined telephone numbers. RFC 3966 >>>>>> defines a syntax >>>>>>> that can be used to carry them, and I question whether that >>>>>> syntax is >>>>>>> appropriate for use in the scenarios so far identified. To >>>>>> understand >>>>>>> what RFC 3966 means one has to go to E.164 (and >>>> associated national >>>>>>> numbering plans) and hope it touchs with the terminology >>>>>> used in those >>>>>>> places. >>>>>>> >>>>>>> I am fine as far it goes in terms of a sequence of decimal >>>>>> digits, but >>>>>>> when we get to whether a phone context is required, then >>>> that is a >>>>>>> jump into essentially supporting multiple numbering >> plans over a >>>>>>> single interface. That would seem to be identifying an >>>>>> architecture of >>>>>>> coordinating bodies with multiple numbering plans well >> beyond the >>>>>>> scope of what is described so far. >>>>>>> >>>>>>> Within national administration, escape digits are defined >>>>>> within the >>>>>>> national numbering plan to clearly identity all allocations >>>>>> within the >>>>>>> national area. At least my assumption is that any >>>> procedures we are >>>>>>> looking at would be within the context of a national >>>> numbering plan. >>>>>>> If you have ideas that go beyond this, then perhaps you >>>>>> need to expand >>>>>>> on them, because that goes way beyond what we have >>>> discussed so far. >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On >> Behalf Of Steve >>>>>>>> Donovan >>>>>>>> Sent: 14 May 2015 14:02 >>>>>>>> To: modern@ietf.org >>>>>>>> Subject: [Modern] Definition of TN (was Re: Proposed change to >>>>>>>> paragraph three of the charter) >>>>>>>> >>>>>>>> The IETF has already spent time defining telephone numbers >>>>>> and I see >>>>>>>> little value in redefining the concept in the MODERN >>>> charter. As >>>>>>>> such, I propose that we include a reference to RFC3966 as the >>>>>>>> definition of TN. >>>>>>>> >>>>>>>> As one data point, the SCIM work references RFC3966 for >>>> telephone >>>>>>>> numbers. We might, by the way, want to add SCIM to the >>>>>> list of areas >>>>>>>> we look at in the charter. >>>>>>>> >>>>>>>> See my comments on Kieth's points below. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote: >>>>>>>>> Firstly the charter gives no definition of what you are >>>>>>>> using for telephone number, e.g. by reference to RFC 3966. >>>>>>>>> RFC 3966 basically defines it as any sequence of decimal >>>>>>>> digits. Other usages elsewhere include alphabetic >>>>>> characters, because >>>>>>>> this name is used both in the context of what the user >>>>>> represents to >>>>>>>> other users as his number and what actually gets used in a >>>>>> signalling >>>>>>>> protocol. >>>>>>>>> The ITU-T terms actually distinguish between those two >>>>>>>> usages, by putting them in separate recommendations. >>>>>>>> SRD> RFC3966 deals with this, indicating that alphabetic >>>>>>>> characters are >>>>>>>> limited to local (non global) numbers. >>>>>>>>> The additionally problem with RFC 3966 as a definition as >>>>>>>> it does not define a usage where every sequence of digits >>>>>> is unique, >>>>>>>> and therefore it has to add a phone context to enable that >>>>>> uniqueness >>>>>>>> to exist, with a default applying to "global" >>>>>>>> numbers. >>>>>>>>> So do you intend such digit sequences used within this >>>>>>>> group to be unique or will it need a phone context as a >>>> result of >>>>>>>> using the RFC 3966 definition? The definitions I provided >>>>>> would not. >>>>>>>> SRD> I suspect we will follow RFC3966, with global numbers >>>>>> being the >>>>>>>> default. There is no reason to limit what MODERN does >>>> to managing >>>>>>>> global numbers. I would not, however, suggest we take on >>>>>> including >>>>>>>> private number resources as a use case for the initial MODERN >>>>>>>> charter. >>>>>>>>> In regard to: >>>>>>>>> >>>>>>>>>> I do gather that you believe the expertise to do the >>>> MODERN work >>>>>>>>>> resides in SG-2 rather than in the IETF. But the >>>>>> proposed working >>>>>>>>>> group will not, say, reassign country code >>>>>>>>>> +44 to someone else, or do any of the things you'd need the >>>>>>>>>> expertise and authority of that body to do. We're not >>>> delegating >>>>>>>>>> authority for country codes to Internet entities as ENUM >>>>>>>> did, which >>>>>>>>>> necessitated an IAB liaison with SG-2, even. Those are >>>>>> all policy >>>>>>>>>> issues. We're not trying to build policy, we're trying to >>>>>>>> build tools >>>>>>>>>> that will work in a variety of policy environments. >>>>>>>>> Then I do not believe that. I believe SG2 should define >>>>>>>> what the numbers are that we use, and maybe they should >>>> define the >>>>>>>> use cases. Once it is reduced to fulfilling a protocol >>>>>> requirement, >>>>>>>> then I anyone (including IETF) can do the work. >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Keith >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>>>>>>>> Sent: 12 May 2015 17:37 >>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph >>>> three of the >>>>>>>>>> charter >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No, what I've said consistently is that what I mean by >>>>>> the term is >>>>>>>>>> what >>>>>>>>>> RFC3966 meant by the term. TeRQ deferred to that >>>>>> specification for >>>>>>>>>> its formal definition of telephone number, say. I see no >>>>>> reason to >>>>>>>>>> reinvent that wheel. >>>>>>>>>> >>>>>>>>>> If we get to a place where the term "telephone number" is >>>>>>>> imprecise >>>>>>>>>> or toxic, then I think we've confused ourselves into a >>>>>>>> rejection of >>>>>>>>>> common sense and common usage. The term is used >>>> without warning >>>>>>>>>> labels in IETF standards track specifications already. >>>>>> The bar you >>>>>>>>>> are raising is not consistent with IETF usage. >>>>>>>>>> >>>>>>>>>> I do gather that you believe the expertise to do the >>>> MODERN work >>>>>>>>>> resides in SG-2 rather than in the IETF. But the >>>>>> proposed working >>>>>>>>>> group will not, say, reassign country code >>>>>>>>>> +44 to someone else, or do any of the things you'd need the >>>>>>>>>> expertise and authority of that body to do. We're not >>>> delegating >>>>>>>>>> authority for country codes to Internet entities as ENUM >>>>>>>> did, which >>>>>>>>>> necessitated an IAB liaison with SG-2, even. Those are >>>>>> all policy >>>>>>>>>> issues. We're not trying to build policy, we're trying to >>>>>>>> build tools >>>>>>>>>> that will work in a variety of policy environments. >>>>>>>>>> >>>>>>>>>> Jon Peterson >>>>>>>>>> Neustar, Inc. >>>>>>>>>> >>>>>>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I am not doing that at all. >>>>>>>>>>> >>>>>>>>>>> I am proposing to remove any attempt by you and others to >>>>>>>>>> use the term >>>>>>>>>>> "telephone number" in a totally undefined manner, and >>>>>>>>>> replacing it with >>>>>>>>>>> terms that have been defined by the body that knows about >>>>>>>>>> these things, >>>>>>>>>>> i.e. SG2 of ITU-T. >>>>>>>>>>> >>>>>>>>>>> You are consisting opposing telling us what you mean by >>>>>> the team. >>>>>>>>>>> My proposal is not to include the term "telephone >>>>>> number" at all. >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Keith >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>>>>>>>> Peterson, >>>>>>>>>>>> Jon >>>>>>>>>>>> Sent: 12 May 2015 16:17 >>>>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org >>>>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph >>>>>> three of the >>>>>>>>>>>> charter >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Again, I'd be more sympathetic to this request to invent a >>>>>>>>>> new IETF >>>>>>>>>>>> definition of telephone numbers if we didn't already have >>>>>>>>>> standards >>>>>>>>>>>> track RFCs that have done that, and by reference >> to the same >>>>>>>>>>>> specifications you're describing here. >>>>>>>>>>>> >>>>>>>>>>>> We don't mean anything different by telephone >>>> numbers than the >>>>>>>>>>>> abstract of >>>>>>>>>>>> RFC3966 did when it said that "the 'tel' URI describes >>>>>> resources >>>>>>>>>>>> identified by telephone numbers." >>>>>>>>>>>> >>>>>>>>>>>> Jon Peterson >>>>>>>>>>>> Neustar, Inc. >>>>>>>>>>>> >>>>>>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)" >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I do not agree with the charter being widened to "TN" or >>>>>>>>>> presumably >>>>>>>>>>>>> "telephone numbers". The reason for this is that telephone >>>>>>>>>>>> numbers has >>>>>>>>>>>>> a wide and undefined scope, possibly including alphabetic >>>>>>>>>>>> characters as >>>>>>>>>>>>> well (as in the letters on the dialling ring). >>>>>>>>>>>>> >>>>>>>>>>>>> Based on the statements made by others in terms of what >>>>>>>>>> needs to be >>>>>>>>>>>>> covered, I would prefer a more precise definition of: >>>>>>>>>> "international >>>>>>>>>>>>> E.164 numbers, local special purpose numbers, and network >>>>>>>>>> specific >>>>>>>>>>>>> numbers" using the explanation of these terms that can be >>>>>>>>>> found in >>>>>>>>>>>>> ITU-T Recommendation E.164. >>>>>>>>>>>>> >>>>>>>>>>>>> Keith >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>>>>>>>> Of Steve >>>>>>>>>>>>>> Donovan >>>>>>>>>>>>>> Sent: 07 May 2015 14:51 >>>>>>>>>>>>>> To: modern@ietf.org >>>>>>>>>>>>>> Subject: [Modern] Proposed change to paragraph >>>> three of the >>>>>>>>>>>>>> charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Paragraph three currently reads as follows: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "The work of this group will focus on E.164 telephone >>>>>>>>>>>> numbers due to >>>>>>>>>>>>>> the changing telecom environment and interest >> expressed by >>>>>>>>>>>>>> telecommunications industry regulators to support more >>>>>>>> flexible >>>>>>>>>>>>>> regulatory models than exist today. >>>>>>>>>>>>>> There is an expectation that aspects of the >>>> architecture and >>>>>>>>>>>>>> protocols defined by the working group will be reusable >>>>>>>>>> for other >>>>>>>>>>>>>> user-focused identifiers. Any such extensions or reuse >>>>>>>>>> of MODERN >>>>>>>>>>>>>> mechanisms are out of scope for the MODERN working group. >>>>>>>>>>>> Solutions >>>>>>>>>>>>>> and mechanisms created by the working group will be >>>>>>>>>>>> flexible enough >>>>>>>>>>>>>> to accommodate different policies, e.g., by different >>>>>>>>>> regulatory >>>>>>>>>>>>>> agencies." >>>>>>>>>>>>>> >>>>>>>>>>>>>> I propose changing the first sentence to the following: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "The work of this group will focus on TNs -- >> such as E.164 >>>>>>>>>>>> numbers -- >>>>>>>>>>>>>> and blocks of TNs, that are used to initiate >>>>>>>> communication with >>>>>>>>>>>>>> another user of a service. The work is motivated by >>>>>>>>>> the changing >>>>>>>>>>>>>> telecom environment and interest expressed by >>>>>>>>>> telecommunications >>>>>>>>>>>>>> industry regulators to support more flexible regulatory >>>>>>>>>>>> models than >>>>>>>>>>>>>> exist today. " >>>>>>>>>>>>>> >>>>>>>>>>>>>> The remainder of the paragraph, starting with >> "There is an >>>>>>>>>>>>>> expectation..." would remain unchanged. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This adds some clarity on the scope of telephony >>>>>>>>>>>> identifiers covered >>>>>>>>>>>>>> as well as making it clear that blocks of TNs are >>>>>> also covered. >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Steve >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Modern mailing list >>>>>>>>>>>>>> Modern@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Modern mailing list >>>>>>>>>>>>> Modern@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Modern mailing list >>>>>>>>>>>> Modern@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Modern mailing list >>>>>>>>> Modern@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Modern mailing list >>>>>>>> Modern@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Modern mailing list >>>>>>> Modern@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/modern >>>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Wed May 20 07:47:22 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 877921A87A9 for ; Wed, 20 May 2015 07:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 iP0vqPkK3oz5 for ; Wed, 20 May 2015 07:47:18 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC4A1A87A3 for ; Wed, 20 May 2015 07:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=hheinfUKS+Ul3zObOzhdkHrQ/49G1aRCOdP0ejSB4sk=; b=eThVIn3ACbBxwNUaucn2mIin88vLEVn8EPOVNCXtcVSASaxuJiwDCfCzBaKVijVs36r2o6Txlp0tF+k0M9twY1XUIgV6S8gCRScSYdKh6TAR/0kYlKGTrRg5eQYedxhaADvmrL6IRQQr4u5MGRFVi9XuDiFxpcZT6PBlD6qPAGE=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:62723 helo=[192.168.15.119]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yv5H8-0006ol-UO for modern@ietf.org; Wed, 20 May 2015 07:47:17 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_A3C12F45-D9A1-4968-A4F9-A747B1991C7E"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <933DEC3B-6027-4C27-B5AD-38CBDB6DB18E@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Wed, 20 May 2015 10:47:05 -0400 References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> To: modern@ietf.org In-Reply-To: <555C9AAD.4080806@usdonovans.com> X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] TN, E.164, or Something Else? 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, 20 May 2015 14:47:20 -0000 --Apple-Mail=_A3C12F45-D9A1-4968-A4F9-A747B1991C7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Does this mean that private identifiers do not need to be globally = unique? Not that we are talking about phone numbers ;-), but are you thinking = PBXen with four-digit dial plans? If so, is the idea that the local = authority would only know about the four digits, in which case the = identifiers really are not global? E.g., my =911234=92 at Georgetown is = different than your =911234=92 at Oracle? Or, is the idea that the dial = plan is just a direct mapping to the globally unique E.164 number? E.g, = =911234=92 is really the number =91+12145551234=94 for Oracle and = =91+12025551234=92 for Georgetown? Such a model really does give credence to say the identifiers are *not* = E.164 numbers, because these identifiers cannot be used for things like = STIR or global routing. > On May 20, 2015, at 10:31 AM, Steve Donovan = wrote: >=20 > Eric, >=20 > I'm not comfortable with saying that MODERN is ONLY about managing = globally unique identifiers as this rules out private numbering plans = put in place by enterprises.=20 >=20 > Yes, MODERN is about globally unique identifiers that have the format = of a telephone number, but it is also about private identifiers that = also have the format of a telephone number. >=20 > Regards, >=20 > Steve >=20 > On 5/18/15 5:23 PM, Eric Burger wrote: >> Something I have been mulling about is the focus (and amount of list = traffic) discussing whether the scope of MODERN is E.164 numbers, = =93telephone numbers,=94 or something else. >>=20 >> We seem to get very emotional about E.164 numbers. Perhaps rightly = so. An E.164 number carries a lot of a=92priori regulatory baggage. By = definition, the ITU-T assigns country codes. National numbering = authorities allocate numbers to service providers. Service providers = manage them for users. >>=20 >> A =93telephone number=94 spawns the debate as to whether it is, in = fact, a =91telephone=92 number. Given Henning=92s presentation, the = value of the telephone number is global routing and global understanding = for 5/7ths of the world using romanized arabic script. Given that, the = people who worry that =93telephone number=94 is just a code word for = E.164 number are most likely correct. This spills into the whole =93It = is not an E.164 number, it is the ABNF for an E.164 number (see = RFC3966).=94 I.e., it looks, smells, and tastes like a rose. >>=20 >> Could we agree to disagree and say that MODERN is about managing = globally unique identifiers that have a syntax of up to 15 decimal = digits that have some hierarchical authorities mixed in to lock down who = can and cannot request and assign numbers? Those authorities can be an = opaque thingbat, because that is where we get into the policy bits, and = everyone on the list swears MODERN will not touch policy. >>=20 >>=20 >>=20 >> _______________________________________________ >> Modern mailing list >>=20 >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_A3C12F45-D9A1-4968-A4F9-A747B1991C7E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6 iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1 4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB 8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+ kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0 aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K +j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0 uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB 7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0 MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0 RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1 a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm 7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI 5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4 yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6 Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y 78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3 1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5 PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8 YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x NTA1MjAxNDQ3MDZaMCMGCSqGSIb3DQEJBDEWBBRTnlbYMPMqoeUTiBknsJgnybLoWjCBvgYJKwYB BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43 HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA QTC71qrNwgoh0ULUiU2RA+CyrceGWaodq1CDcvgNJWbaU1twMfvGRf0d1Ngkix2c+2Ox/HfFe8SJ tANwt4xowjr6ux5hjKOF+qjdHz4Wqwlu0Fk5OMBEFgc0K9HH5UVtDLH0ZEAlkUYFrJYrhYuN5eOz aPghjqE66a582MlmhmfBDCR/O1GwHMAXr49SVL4IjG1Nf9eOzA2N2IdYEDHpkHnifDdutp5VhAji j7pIlHm2WVvXMubpsBxfVsIXvOvVYOTTZesQiZdh0elfTqzL6AQsfLro/p4TMkUhXm4ygn6chcey 41oWdJNLHLy7oCVhMW0g5ou6rzrAxz37rPVTQwAAAAAAAA== --Apple-Mail=_A3C12F45-D9A1-4968-A4F9-A747B1991C7E-- From nobody Wed May 20 10:02:34 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 9166B1A898A for ; Wed, 20 May 2015 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 VCkq8ZawJcXd for ; Wed, 20 May 2015 10:02:31 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 021311A896B for ; Wed, 20 May 2015 10:02:27 -0700 (PDT) Received: from 156.sub-70-196-11.myvzw.com ([70.196.11.156]:5764 helo=[192.168.43.50]) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yv7No-0002J6-V9 for modern@ietf.org; Wed, 20 May 2015 10:02:26 -0700 Message-ID: <555CBE17.9030200@usdonovans.com> Date: Wed, 20 May 2015 12:02:15 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: modern@ietf.org References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> <933DEC3B-6027-4C27-B5AD-38CBDB6DB18E@standardstrack.com> In-Reply-To: <933DEC3B-6027-4C27-B5AD-38CBDB6DB18E@standardstrack.com> Content-Type: multipart/alternative; boundary="------------000804070102000109030802" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] TN, E.164, or Something Else? 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, 20 May 2015 17:02:33 -0000 This is a multi-part message in MIME format. --------------000804070102000109030802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I'm referring to private number ranges that potentially have zero correlation to E.164 numbers. I don't think we need to change the existing charter to cover this case. I just don't want to change it in a way that would preclude private numbers. In the end both types of TNs need to be supported. Steve On 5/20/15 9:47 AM, Eric Burger wrote: > Does this mean that private identifiers do not need to be globally unique? > > Not that we are talking about phone numbers ;-), but are you thinking PBXen with four-digit dial plans? If so, is the idea that the local authority would only know about the four digits, in which case the identifiers really are not global? E.g., my ‘1234’ at Georgetown is different than your ‘1234’ at Oracle? Or, is the idea that the dial plan is just a direct mapping to the globally unique E.164 number? E.g, ‘1234’ is really the number ‘+12145551234” for Oracle and ‘+12025551234’ for Georgetown? > > Such a model really does give credence to say the identifiers are *not* E.164 numbers, because these identifiers cannot be used for things like STIR or global routing. > >> On May 20, 2015, at 10:31 AM, Steve Donovan wrote: >> >> Eric, >> >> I'm not comfortable with saying that MODERN is ONLY about managing globally unique identifiers as this rules out private numbering plans put in place by enterprises. >> >> Yes, MODERN is about globally unique identifiers that have the format of a telephone number, but it is also about private identifiers that also have the format of a telephone number. >> >> Regards, >> >> Steve >> >> On 5/18/15 5:23 PM, Eric Burger wrote: >>> Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else. >>> >>> We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users. >>> >>> A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose. >>> >>> Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy. >>> >>> >>> >>> _______________________________________________ >>> Modern mailing list >>> >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --------------000804070102000109030802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I'm referring to private number ranges that potentially have zero correlation to E.164 numbers. 

I don't think we need to change the existing charter to cover this case.  I just don't want to change it in a way that would preclude private numbers.  

In the end both types of TNs need to be supported.

Steve

On 5/20/15 9:47 AM, Eric Burger wrote:
Does this mean that private identifiers do not need to be globally unique?

Not that we are talking about phone numbers ;-), but are you thinking PBXen with four-digit dial plans? If so, is the idea that the local authority would only know about the four digits, in which case the identifiers really are not global? E.g., my ‘1234’ at Georgetown is different than your ‘1234’ at Oracle? Or, is the idea that the dial plan is just a direct mapping to the globally unique E.164 number? E.g, ‘1234’ is really the number ‘+12145551234” for Oracle and ‘+12025551234’ for Georgetown?

Such a model really does give credence to say the identifiers are *not* E.164 numbers, because these identifiers cannot be used for things like STIR or global routing.


On May 20, 2015, at 10:31 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Eric,

I'm not comfortable with saying that MODERN  is ONLY about managing globally unique identifiers as this rules out private numbering plans put in place by enterprises. 

Yes, MODERN is about globally unique identifiers that have the format of a telephone number, but it is also about private identifiers that also have the format of a telephone number.

Regards,

Steve

On 5/18/15 5:23 PM, Eric Burger wrote:

Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.

A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy.



_______________________________________________
Modern mailing list

Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


      

      

      

      
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


    

    

  


--------------000804070102000109030802--


From nobody Thu May 21 11:13:26 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 174431A1A7E for ; Thu, 21 May 2015 11:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 R0iM-k-78mhA for ; Thu, 21 May 2015 11:13:23 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 B01E91A064C for ; Thu, 21 May 2015 11:13:23 -0700 (PDT)
Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:61306 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YvUy6-0009PJ-A9 for modern@ietf.org; Thu, 21 May 2015 11:13:23 -0700
Message-ID: <555E203D.2050304@usdonovans.com>
Date: Thu, 21 May 2015 13:13:17 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: modern@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080906070500030506060107"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] P2P (was Third revision of MODERN charter)
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, 21 May 2015 18:13:25 -0000

This is a multi-part message in MIME format.
--------------080906070500030506060107
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Chris,

Was your suggestion to make the following change?

From:

" TNs may either be managed in a hierarchical tree, or in a distributed 
peer-to-peer architecture. "

To:

"TNs may either be managed in a hierarchical tree, or in a distributed 
registry."

Steve

On 5/19/15 11:41 AM, McGarry, Tom wrote:
> Good suggestion, much better.
>
> On 5/19/15 12:29 AM, "Chris Wendt"  wrote:
>
>> I think something like simply "Distributed Registry" might be a more
>> straight forward term to stick to.  "Peer-to-peer" isn¹t necessarily an
>> inappropriate way to describe the gossip based distributed protocols
>> Henning referred to in his presentation, but has some historical meaning
>> that could potentially confuse or imply something other than what is
>> being proposed or discussed.
>>
>>
>>> On May 18, 2015, at 3:14 PM, Eric Burger 
>>> wrote:
>>>
>>> All of Henning¹s slides were about number assignments in a hierarchy.
>>> My recollection is all of the use cases were about number assignments in
>>> a hierarchy. I am not against working on peer-to-peer assignment
>>> technology. However, I wanted to make sure this is something that people
>>> want to work on.
>>>
>>> What is the use case? Sorry if I missed it. When I greped the archive,
>>> the term Œpeer¹ does not hit, other than in the charter drafts.
>>>
>>>> On May 14, 2015, at 2:35 PM, Steve Donovan 
>>>> wrote:
>>>>
>>>> TNs may either be managed in a hierarchical tree, or in a distributed
>>>> peer-to-peer architecture.
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>> _listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>> xtZ1ooNcfp01IYIaVqsORjI&m=TrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=X
>>> phhxgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>> listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>> Z1ooNcfp01IYIaVqsORjI&m=TrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=Xphh
>> xgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
>


--------------080906070500030506060107
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Chris,

    

    Was your suggestion to make the following change?

    

    From:

    

    "
    
    TNs may either be managed in a hierarchical tree, or in a
    distributed peer-to-peer architecture. "

    

    To:

    

    "TNs may either be managed in a hierarchical tree, or in a
    distributed registry."

    

    Steve

    

    
On 5/19/15 11:41 AM, McGarry, Tom
      wrote:

    

    

      
Good suggestion, much better.

On 5/19/15 12:29 AM, "Chris Wendt" <chris-ietf@chriswendt.net> wrote:



      

        
I think something like simply "Distributed Registry" might be a more
straight forward term to stick to.  "Peer-to-peer" isn¹t necessarily an
inappropriate way to describe the gossip based distributed protocols
Henning referred to in his presentation, but has some historical meaning
that could potentially confuse or imply something other than what is
being proposed or discussed.




        

          
On May 18, 2015, at 3:14 PM, Eric Burger <eburger@standardstrack.com>
wrote:

All of Henning¹s slides were about number assignments in a hierarchy.
My recollection is all of the use cases were about number assignments in
a hierarchy. I am not against working on peer-to-peer assignment
technology. However, I wanted to make sure this is something that people
want to work on.

What is the use case? Sorry if I missed it. When I greped the archive,
the term Œpeer¹ does not hit, other than in the charter drafts.



          

            
On May 14, 2015, at 2:35 PM, Steve Donovan <srdonovan@usdonovans.com>
wrote:

TNs may either be managed in a hierarchical tree, or in a distributed
peer-to-peer architecture.


          

          
_______________________________________________
Modern mailing list
Modern@ietf.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
_listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
xtZ1ooNcfp01IYIaVqsORjI&m=TrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=X
phhxgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=


        

        
_______________________________________________
Modern mailing list
Modern@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
Z1ooNcfp01IYIaVqsORjI&m=TrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=Xphh
xgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e= 


      

      
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern



    

    

  


--------------080906070500030506060107--


From nobody Sat May 23 22:27:46 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 0851C1A7000 for ; Sat, 23 May 2015 22:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.609
X-Spam-Level: 
X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-5, 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 zNupvyhHJFlS for ; Sat, 23 May 2015 22:27:41 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8B4CA1A6FFF for ; Sat, 23 May 2015 22:27:40 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 7A0CAC8EB4D07; Sun, 24 May 2015 05:27:37 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4O5Rc49016442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 May 2015 07:27:38 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 24 May 2015 07:27:38 +0200
From: "DRAGE, Keith (Keith)" 
To: Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] TN, E.164, or Something Else?
Thread-Index: AQHQkwmvdXbUF3uhyEqIiThZSYFR1J2KnJRg
Date: Sun, 24 May 2015 05:27:37 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com>
In-Reply-To: <555C9AAD.4080806@usdonovans.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B6971B7C1FR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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: Sun, 24 May 2015 05:27:46 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B6971B7C1FR712WXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Adding in private numbers introduces all sorts of complications.

In many cases there is a mapping between E.164 numbers and private numbers,=
 i.e. the allocation by the public administration of an E.164 number automa=
tically generates a valid private number, and vice versa. In other cases th=
ere could be no such mapping. When you apply the above to international pri=
vate networks, with DDI ranges in multiple countries belonging to the same =
private network, it gets even more complicated.

There are other complications resulting from the joint ownership of some co=
mpanies, resulting in an owned companies network forming part of the privat=
e numbering plan of both parent companies.

Unless there is a proven use case from deployers of private networks, I str=
ongly propose that we should avoid these cases altogether.

I'd note by the way that I have not been pushing for global uniqueness, onl=
y against the assumption that the numbering plans are not locally unique to=
 the particular administration. I believe we should assume local uniqueness=
, but that does not presuppose global uniqueness.

regards

Keith



________________________________
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: 20 May 2015 15:31
To: modern@ietf.org
Subject: Re: [Modern] TN, E.164, or Something Else?

Eric,

I'm not comfortable with saying that MODERN  is ONLY about managing globall=
y unique identifiers as this rules out private numbering plans put in place=
 by enterprises.

Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.

Regards,

Steve

On 5/18/15 5:23 PM, Eric Burger wrote:

Something I have been mulling about is the focus (and amount of list traffi=
c) discussing whether the scope of MODERN is E.164 numbers, "telephone numb=
ers," or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a'priori regulatory baggage. By definition, th=
e ITU-T assigns country codes. National numbering authorities allocate numb=
ers to service providers. Service providers manage them for users.

A "telephone number" spawns the debate as to whether it is, in fact, a 'tel=
ephone' number. Given Henning's presentation, the value of the telephone nu=
mber is global routing and global understanding for 5/7ths of the world usi=
ng romanized arabic script. Given that, the people who worry that "telephon=
e number" is just a code word for E.164 number are most likely correct. Thi=
s spills into the whole "It is not an E.164 number, it is the ABNF for an E=
.164 number (see RFC3966)." I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.




_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern



--_000_949EF20990823C4C85C18D59AA11AD8B6971B7C1FR712WXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Adding in private numbers introduces all sorts of complicati=
ons.


 


In many cases there is a mapping between E.164 numbers and p=
rivate numbers, i.e. the allocation by the public administration of an E.16=
4 number automatically generates a valid
 private number, and vice versa. In other cases there could be no such mapp=
ing. When you apply the above to international private networks, with DDI r=
anges in multiple countries belonging to the same private network, it gets =
even more complicated.



 


There are other complications resulting from the joint owner=
ship of some companies, resulting in an owned companies network formin=
g part of the private numbering plan of both
 parent companies.


 


Unless there is a proven use case from deployers of private =
networks, I strongly propose that we should avoid these cases altogether.


 


I'd note by the way that I have not been pushing for global =
uniqueness, only against the assumption that the numbering plans are not lo=
cally unique to the particular administration.
 I believe we should assume local uniqueness, but that does not presuppose =
global uniqueness.


 


regards


 


Keith


 


 









From: Modern [mailto:modern-bounces=
@ietf.org]
On Behalf Of Steve Donovan

Sent: 20 May 2015 15:31

To: modern@ietf.org

Subject: Re: [Modern] TN, E.164, or Something Else?







Eric,



I'm not comfortable with saying that MODERN  is ONLY about managing gl=
obally unique identifiers as this rules out private numbering plans put in =
place by enterprises.




Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.



Regards,



Steve




On 5/18/15 5:23 PM, Eric Burger wrote:






Something I have been mulling about is the focus (and amount=
 of list traffic) discussing whether the scope of MODERN is E.164 numbers, =
“telephone numbers,” or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a’priori regulatory baggage. By definiti=
on, the ITU-T assigns country codes. National numbering authorities allocat=
e numbers to service providers. Service providers manage them for users.

A “telephone number” spawns the debate as to whether it is, in =
fact, a ‘telephone’ number. Given Henning’s presentation,=
 the value of the telephone number is global routing and global understandi=
ng for 5/7ths of the world using romanized arabic script. Given that, the p=
eople who worry that “telephone number” is just a code word for=
 E.164 number are most likely correct. This spills into the whole “It=
 is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).&=
#8221; I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.





 


_______________________________________________
Modern mailing list
Moder=
n@ietf.org
https://www.ietf.org/mailman/listinfo/modern











--_000_949EF20990823C4C85C18D59AA11AD8B6971B7C1FR712WXCHMBA11z_--


From nobody Sat May 23 22:29:25 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 44E681A7000 for ; Sat, 23 May 2015 22:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.91
X-Spam-Level: 
X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 BcfOgi00Uq7x for ; Sat, 23 May 2015 22:29:20 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A99181A1A66 for ; Sat, 23 May 2015 22:29:19 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9CD8EF3AB29DD; Sun, 24 May 2015 05:29:16 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4O5TI2A017026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 May 2015 07:29:18 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 24 May 2015 07:29:18 +0200
From: "DRAGE, Keith (Keith)" 
To: Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter)
Thread-Index: AQHQkwn1UuR1BJIpCkKrpn8PN3KHwp2Knqyg
Date: Sun, 24 May 2015 05:29:17 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B6971B7D3@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555613EC.9090909@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69715FB5@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555A0A44.5070409@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971717E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555C9B42.3010906@usdonovans.com>
In-Reply-To: <555C9B42.3010906@usdonovans.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter)
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: Sun, 24 May 2015 05:29:24 -0000

I assume you mean "pare".

I was not aware that IETF defined charters of the form "Lets solve everythi=
ng including world hunger" and decided what it might work on after the char=
ter was approved.

Regards

Keith=20

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20
> Steve Donovan
> Sent: 20 May 2015 15:34
> To: modern@ietf.org
> Subject: Re: [Modern] Definition of TN (was Re: Proposed=20
> change to paragraph three of the charter)
>=20
>=20
>=20
> On 5/18/15 6:05 PM, DRAGE, Keith (Keith) wrote:
> > I provided wording messages back which I think provided=20
> better definition of what we mean by telephone numbers that=20
> the current reference to RFC 3966, which to me is providing a=20
> coding solution with too many options.
>=20
> Then we can pair away the options that don't apply as part of=20
> the working group effort.
> >
> > And being able to "cook" up a use case does not mean that=20
> we need that as a use case.
> I do think that private numbering plans should be in scope,=20
> or at least not ruled out of scope by the charter.
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve=20
> >> Donovan
> >> Sent: 18 May 2015 16:50
> >> To: modern@ietf.org
> >> Subject: Re: [Modern] Definition of TN (was Re: Proposed change to=20
> >> paragraph three of the charter)
> >>
> >> Keith,
> >>
> >> I think this is something that can be discussed by the=20
> working group=20
> >> and, to my mind, doesn't require addressing in the charter.
> >>
> >> I can "cook up" a use case where public and private number formats=20
> >> could be used in a single session, but I don't feel that=20
> is relevant=20
> >> to the charter discussion.
> >>
> >> Can we live with the charter as currently worded and=20
> address this as=20
> >> part of the working group effort?
> >>
> >> Steve
> >>
> >> On 5/15/15 1:02 PM, DRAGE, Keith (Keith) wrote:
> >>> You tell me, but my expectation, that it will not happen on
> >> a per session basis, and any entity receiving this=20
> information will=20
> >> be capable of, and need to be capable of, switching between the=20
> >> different number formats.
> >>> Keith
> >>>
> >>>> -----Original Message-----
> >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Paul=20
> >>>> Kyzivat
> >>>> Sent: 15 May 2015 16:43
> >>>> To: modern@ietf.org
> >>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed=20
> change to=20
> >>>> paragraph three of the charter)
> >>>>
> >>>> On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote:
> >>>>> You have at least missed the point I have been making.
> >>>>>
> >>>>> By using RFC 3966 as a syntax definition, you automatically
> >>>> include a requirement to support phone context.
> >>>>> The point I am making is that in my understanding from the
> >>>> use cases so far discussed, phone context is unnecessary,
> >> as we are
> >>>> dealing with protocol with a single administration supporting a=20
> >>>> single national numbering space. The context is one only
> >> and implicit
> >>>> in the administration one is presumably securely
> >> communicating with.
> >>>> Isn't it an expectation that the numbers being discussed
> >>>> *can* be represented in SIP? If so, then 3966 is relevant.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul
> >>>>
> >>>>> Keith
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ben Campbell [mailto:ben@nostrum.com]
> >>>>>> Sent: 15 May 2015 15:04
> >>>>>> To: DRAGE, Keith (Keith)
> >>>>>> Cc: Steve Donovan; modern@ietf.org
> >>>>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed
> >> change to
> >>>>>> paragraph three of the charter)
> >>>>>>
> >>>>>> 
> >>>>>>
> >>>>>> (I'm not picking on Keith in particular. This just=20
> seemed a good=20
> >>>>>> place to jump in.)
> >>>>>>
> >>>>>> I'd like to remind people that this is a charter, not a
> >> technical
> >>>>>> specification. We need guidance to the working group. It
> >>>> doesn't have
> >>>>>> to be perfect, and there's room for some flexibility
> >>>>>>
> >>>>>> 
> >>>>>>
> >>>>>> 
> >>>>>>
> >>>>>> It seems to me that the syntax is mainly what we care
> >> about, _not_
> >>>>>> the architecture of coordinating bodies. My=20
> understanding is the=20
> >>>>>> whole point of this exercise is to avoid building
> >>>> assumptions about
> >>>>>> that architecture and related policies into the
> >> technology itself.
> >>>>>> If a national administration defines escape digits, we
> >> need to be
> >>>>>> able to handle escape digits. But that doesn't mean we
> >>>> have to import
> >>>>>> the whole administrative architecture.
> >>>>>>
> >>>>>> 
> >>>>>>
> >>>>>>
> >>>>>> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote:
> >>>>>>
> >>>>>>> The IETF has NOT defined telephone numbers. RFC 3966
> >>>>>> defines a syntax
> >>>>>>> that can be used to carry them, and I question whether that
> >>>>>> syntax is
> >>>>>>> appropriate for use in the scenarios so far identified. To
> >>>>>> understand
> >>>>>>> what RFC 3966 means one has to go to E.164 (and
> >>>> associated national
> >>>>>>> numbering plans) and hope it touchs with the terminology
> >>>>>> used in those
> >>>>>>> places.
> >>>>>>>
> >>>>>>> I am fine as far it goes in terms of a sequence of decimal
> >>>>>> digits, but
> >>>>>>> when we get to whether a phone context is required, then
> >>>> that is a
> >>>>>>> jump into essentially supporting multiple numbering
> >> plans over a
> >>>>>>> single interface. That would seem to be identifying an
> >>>>>> architecture of
> >>>>>>> coordinating bodies with multiple numbering plans well
> >> beyond the
> >>>>>>> scope of what is described so far.
> >>>>>>>
> >>>>>>> Within national administration, escape digits are defined
> >>>>>> within the
> >>>>>>> national numbering plan to clearly identity all allocations
> >>>>>> within the
> >>>>>>> national area. At least my assumption is that any
> >>>> procedures we are
> >>>>>>> looking at would be within the context of a national
> >>>> numbering plan.
> >>>>>>> If you have ideas that go beyond this, then perhaps you
> >>>>>> need to expand
> >>>>>>> on them, because that goes way beyond what we have
> >>>> discussed so far.
> >>>>>>> Keith
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On
> >> Behalf Of Steve
> >>>>>>>> Donovan
> >>>>>>>> Sent: 14 May 2015 14:02
> >>>>>>>> To: modern@ietf.org
> >>>>>>>> Subject: [Modern] Definition of TN (was Re: Proposed=20
> change to=20
> >>>>>>>> paragraph three of the charter)
> >>>>>>>>
> >>>>>>>> The IETF has already spent time defining telephone numbers
> >>>>>> and I see
> >>>>>>>> little value in redefining the concept in the MODERN
> >>>> charter.  As
> >>>>>>>> such, I propose that we include a reference to=20
> RFC3966 as the=20
> >>>>>>>> definition of TN.
> >>>>>>>>
> >>>>>>>> As one data point, the SCIM work references RFC3966 for
> >>>> telephone
> >>>>>>>> numbers.  We might, by the way, want to add SCIM to the
> >>>>>> list of areas
> >>>>>>>> we look at in the charter.
> >>>>>>>>
> >>>>>>>> See my comments on Kieth's points below.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Steve
> >>>>>>>>
> >>>>>>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote:
> >>>>>>>>> Firstly the charter gives no definition of what you are
> >>>>>>>> using for telephone number, e.g. by reference to RFC 3966.
> >>>>>>>>> RFC 3966 basically defines it as any sequence of decimal
> >>>>>>>> digits. Other usages elsewhere include alphabetic
> >>>>>> characters, because
> >>>>>>>> this name is used both in the context of what the user
> >>>>>> represents to
> >>>>>>>> other users as his number and what actually gets used in a
> >>>>>> signalling
> >>>>>>>> protocol.
> >>>>>>>>> The ITU-T terms actually distinguish between those two
> >>>>>>>> usages, by putting them in separate recommendations.
> >>>>>>>> SRD> RFC3966 deals with this, indicating that alphabetic
> >>>>>>>> characters are
> >>>>>>>> limited to local (non global) numbers.
> >>>>>>>>> The additionally problem with RFC 3966 as a definition as
> >>>>>>>> it does not define a usage where every sequence of digits
> >>>>>> is unique,
> >>>>>>>> and therefore it has to add a phone context to enable that
> >>>>>> uniqueness
> >>>>>>>> to exist, with a default applying to "global"
> >>>>>>>> numbers.
> >>>>>>>>> So do you intend such digit sequences used within this
> >>>>>>>> group to be unique or will it need a phone context as a
> >>>> result of
> >>>>>>>> using the RFC 3966 definition? The definitions I provided
> >>>>>> would not.
> >>>>>>>> SRD> I suspect we will follow RFC3966, with global numbers
> >>>>>> being the
> >>>>>>>> default.  There is no reason to limit what MODERN does
> >>>> to managing
> >>>>>>>> global numbers.  I would not, however, suggest we take on
> >>>>>> including
> >>>>>>>> private number resources as a use case for the=20
> initial MODERN=20
> >>>>>>>> charter.
> >>>>>>>>> In regard to:
> >>>>>>>>>
> >>>>>>>>>> I do gather that you believe the expertise to do the
> >>>> MODERN work
> >>>>>>>>>> resides in SG-2 rather than in the IETF. But the
> >>>>>> proposed working
> >>>>>>>>>> group will not, say, reassign country code
> >>>>>>>>>> +44 to someone else, or do any of the things you'd need the
> >>>>>>>>>> expertise and authority of that body to do. We're not
> >>>> delegating
> >>>>>>>>>> authority for country codes to Internet entities as ENUM
> >>>>>>>> did, which
> >>>>>>>>>> necessitated an IAB liaison with SG-2, even. Those are
> >>>>>> all policy
> >>>>>>>>>> issues. We're not trying to build policy, we're trying to
> >>>>>>>> build tools
> >>>>>>>>>> that will work in a variety of policy environments.
> >>>>>>>>> Then I do not believe that. I believe SG2 should define
> >>>>>>>> what the numbers are that we use, and maybe they should
> >>>> define the
> >>>>>>>> use cases. Once it is reduced to fulfilling a protocol
> >>>>>> requirement,
> >>>>>>>> then I anyone (including IETF) can do the work.
> >>>>>>>>> Regards
> >>>>>>>>>
> >>>>>>>>> Keith
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> >>>>>>>>>> Sent: 12 May 2015 17:37
> >>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org
> >>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph
> >>>> three of the
> >>>>>>>>>> charter
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> No, what I've said consistently is that what I mean by
> >>>>>> the term is
> >>>>>>>>>> what
> >>>>>>>>>> RFC3966 meant by the term. TeRQ deferred to that
> >>>>>> specification for
> >>>>>>>>>> its formal definition of telephone number, say. I see no
> >>>>>> reason to
> >>>>>>>>>> reinvent that wheel.
> >>>>>>>>>>
> >>>>>>>>>> If we get to a place where the term "telephone number" is
> >>>>>>>> imprecise
> >>>>>>>>>> or toxic, then I think we've confused ourselves into a
> >>>>>>>> rejection of
> >>>>>>>>>> common sense and common usage. The term is used
> >>>> without warning
> >>>>>>>>>> labels in IETF standards track specifications already.
> >>>>>> The bar you
> >>>>>>>>>> are raising is not consistent with IETF usage.
> >>>>>>>>>>
> >>>>>>>>>> I do gather that you believe the expertise to do the
> >>>> MODERN work
> >>>>>>>>>> resides in SG-2 rather than in the IETF. But the
> >>>>>> proposed working
> >>>>>>>>>> group will not, say, reassign country code
> >>>>>>>>>> +44 to someone else, or do any of the things you'd need the
> >>>>>>>>>> expertise and authority of that body to do. We're not
> >>>> delegating
> >>>>>>>>>> authority for country codes to Internet entities as ENUM
> >>>>>>>> did, which
> >>>>>>>>>> necessitated an IAB liaison with SG-2, even. Those are
> >>>>>> all policy
> >>>>>>>>>> issues. We're not trying to build policy, we're trying to
> >>>>>>>> build tools
> >>>>>>>>>> that will work in a variety of policy environments.
> >>>>>>>>>>
> >>>>>>>>>> Jon Peterson
> >>>>>>>>>> Neustar, Inc.
> >>>>>>>>>>
> >>>>>>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)"
> >>>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I am not doing that at all.
> >>>>>>>>>>>
> >>>>>>>>>>> I am proposing to remove any attempt by you and others to
> >>>>>>>>>> use the term
> >>>>>>>>>>> "telephone number" in a totally undefined manner, and
> >>>>>>>>>> replacing it with
> >>>>>>>>>>> terms that have been defined by the body that knows about
> >>>>>>>>>> these things,
> >>>>>>>>>>> i.e. SG2 of ITU-T.
> >>>>>>>>>>>
> >>>>>>>>>>> You are consisting opposing telling us what you mean by
> >>>>>> the team.
> >>>>>>>>>>> My proposal is not to include the term "telephone
> >>>>>> number" at all.
> >>>>>>>>>>> Regards
> >>>>>>>>>>>
> >>>>>>>>>>> Keith
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On=20
> Behalf Of
> >>>>>>>>>> Peterson,
> >>>>>>>>>>>> Jon
> >>>>>>>>>>>> Sent: 12 May 2015 16:17
> >>>>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org
> >>>>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph
> >>>>>> three of the
> >>>>>>>>>>>> charter
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Again, I'd be more sympathetic to this request=20
> to invent a
> >>>>>>>>>> new IETF
> >>>>>>>>>>>> definition of telephone numbers if we didn't already have
> >>>>>>>>>> standards
> >>>>>>>>>>>> track RFCs that have done that, and by reference
> >> to the same
> >>>>>>>>>>>> specifications you're describing here.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We don't mean anything different by telephone
> >>>> numbers than the
> >>>>>>>>>>>> abstract of
> >>>>>>>>>>>> RFC3966 did when it said that "the 'tel' URI describes
> >>>>>> resources
> >>>>>>>>>>>> identified by telephone numbers."
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jon Peterson
> >>>>>>>>>>>> Neustar, Inc.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)"
> >>>>>>>>>>>>  wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I do not agree with the charter being widened to "TN" or
> >>>>>>>>>> presumably
> >>>>>>>>>>>>> "telephone numbers". The reason for this is=20
> that telephone
> >>>>>>>>>>>> numbers has
> >>>>>>>>>>>>> a wide and undefined scope, possibly including=20
> alphabetic
> >>>>>>>>>>>> characters as
> >>>>>>>>>>>>> well (as in the letters on the dialling ring).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Based on the statements made by others in terms of what
> >>>>>>>>>> needs to be
> >>>>>>>>>>>>> covered, I would prefer a more precise definition of:
> >>>>>>>>>> "international
> >>>>>>>>>>>>> E.164 numbers, local special purpose numbers,=20
> and network
> >>>>>>>>>> specific
> >>>>>>>>>>>>> numbers" using the explanation of these terms=20
> that can be
> >>>>>>>>>> found in
> >>>>>>>>>>>>> ITU-T Recommendation E.164.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Keith
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf
> >>>>>>>>>> Of Steve
> >>>>>>>>>>>>>> Donovan
> >>>>>>>>>>>>>> Sent: 07 May 2015 14:51
> >>>>>>>>>>>>>> To: modern@ietf.org
> >>>>>>>>>>>>>> Subject: [Modern] Proposed change to paragraph
> >>>> three of the
> >>>>>>>>>>>>>> charter
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> All,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Paragraph three currently reads as follows:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> "The work of this group will focus on E.164 telephone
> >>>>>>>>>>>> numbers due to
> >>>>>>>>>>>>>> the changing telecom environment and interest
> >> expressed by
> >>>>>>>>>>>>>> telecommunications industry regulators to support more
> >>>>>>>> flexible
> >>>>>>>>>>>>>> regulatory models than exist today.
> >>>>>>>>>>>>>> There is an expectation that aspects of the
> >>>> architecture and
> >>>>>>>>>>>>>> protocols defined by the working group will be reusable
> >>>>>>>>>> for other
> >>>>>>>>>>>>>> user-focused identifiers.  Any such extensions or reuse
> >>>>>>>>>> of MODERN
> >>>>>>>>>>>>>> mechanisms are out of scope for the MODERN=20
> working group.
> >>>>>>>>>>>> Solutions
> >>>>>>>>>>>>>> and mechanisms created by the working group will be
> >>>>>>>>>>>> flexible enough
> >>>>>>>>>>>>>> to accommodate different policies, e.g., by different
> >>>>>>>>>> regulatory
> >>>>>>>>>>>>>> agencies."
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I propose changing the first sentence to the following:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> "The work of this group will focus on TNs --
> >> such as E.164
> >>>>>>>>>>>> numbers --
> >>>>>>>>>>>>>> and blocks of TNs, that are used to initiate
> >>>>>>>> communication with
> >>>>>>>>>>>>>> another user of a service.  The work is motivated by
> >>>>>>>>>> the changing
> >>>>>>>>>>>>>> telecom environment and interest expressed by
> >>>>>>>>>> telecommunications
> >>>>>>>>>>>>>> industry regulators to support more flexible regulatory
> >>>>>>>>>>>> models than
> >>>>>>>>>>>>>> exist today. "
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The remainder of the paragraph, starting with
> >> "There is an
> >>>>>>>>>>>>>> expectation..." would remain unchanged.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This adds some clarity on the scope of telephony
> >>>>>>>>>>>> identifiers covered
> >>>>>>>>>>>>>> as well as making it clear that blocks of TNs are
> >>>>>> also covered.
> >>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Steve
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>> Modern mailing list
> >>>>>>>>>>>>>> Modern@ietf.org
> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> Modern mailing list
> >>>>>>>>>>>>> Modern@ietf.org
> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> Modern mailing list
> >>>>>>>>>>>> Modern@ietf.org
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Modern mailing list
> >>>>>>>>> Modern@ietf.org
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Modern mailing list
> >>>>>>>> Modern@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Modern mailing list
> >>>>>>> Modern@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>> _______________________________________________
> >>>>> Modern mailing list
> >>>>> Modern@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>>
> >>>> _______________________________________________
> >>>> Modern mailing list
> >>>> Modern@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/modern
> >>>>
> >>> _______________________________________________
> >>> Modern mailing list
> >>> Modern@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/modern
> >>>
> >> _______________________________________________
> >> Modern mailing list
> >> Modern@ietf.org
> >> https://www.ietf.org/mailman/listinfo/modern
> >>
> > _______________________________________________
> > Modern mailing list
> > Modern@ietf.org
> > https://www.ietf.org/mailman/listinfo/modern
> >
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
> =


From nobody Mon May 25 08:52: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 E2E7E1A912C for ; Mon, 25 May 2015 08:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.689
X-Spam-Level: *
X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 POtLDt8Vx_cB for ; Mon, 25 May 2015 08:52:07 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E3C1A9131 for ; Mon, 25 May 2015 08:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Em9iqzqhpBPCFmVYv/9oMdk6ip38uWGjy4K1adJuf9k=;  b=bpg6g7aIIr820nCHCSEyo0aXH8q4ORtIKjzfGof0paXjEagCu8MKehpbQ6sqCzbLoZbM3JgL2R7tuKRWzD9jFProwg0wwdT/zOUfy5zdgrqDY5NoIiuGNPaJukHj+Jn7EF8IDtOGOPFwuYN5r46jzYQuB8WVVdGtk9V3573GzYM=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:49520 helo=[192.168.15.120]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ywufa-0006Mp-R1 for modern@ietf.org; Mon, 25 May 2015 08:52:04 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_893B1101-1D98-451F-BF59-747932BD3256"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Burger 
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Mon, 25 May 2015 11:52:00 -0400
Message-Id: <12180B6D-426A-49DA-9D65-FAC676587E8D@standardstrack.com>
References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com>
To: "modern@ietf.org" 
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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: Mon, 25 May 2015 15:52:11 -0000

--Apple-Mail=_893B1101-1D98-451F-BF59-747932BD3256
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7509B8EB-0152-4046-9408-056067625162"


--Apple-Mail=_7509B8EB-0152-4046-9408-056067625162
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Now I am confused.

I was thinking we are building something more complex than just a =
registry of strings of digits to services and maybe routing. IANA (and a =
host of others) can do that today.

I thought the thing that needed solving, which Henning described at the =
BOF, was a how to provision and interface with a registry that maps =
strings of digits to services and maybe routing, where there was a clear =
need for some sort of (outside of scope) policy that needs to be =
enforced.

Am I wrong in thinking the entire point of MODERN is the mechanisms for =
policy enforcement?

By policy enforcement, I mean that, depending on jurisdiction, policies =
may be that only the national numbering authority can delegate the =
authority to allocate numbers to registered service providers. Or, a =
policy may be that only the national numbering authority can allocate =
numbers to users. Or, a policy may be that only the user can assign =
which services or service providers are allowed to service the number. =
What the policies are is out of scope for the work group. However, that =
there are policies I was under the impression is the whole point of the =
work group.

I am very leery of a policy that says that some part of the name space =
lives with the ITU-T and national numbering authorities, but another =
part of the name space is a free-for-all. What is to stop me from =
declaring =E2=80=9C+1 214-555-1000=E2=80=9D to be just a private number?

If the proposal is that private numbers are not in the numbering (E.164? =
TN?) name space, then say so. Then Keith=E2=80=99s question becomes =
relevant: what is the use case? Cullen, is this in the Cisco world? =
Steven, is this in the Oracle world?

Thanks,
Eric


> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) =
 wrote:
>=20
> Adding in private numbers introduces all sorts of complications.
>=20
> In many cases there is a mapping between E.164 numbers and private =
numbers, i.e. the allocation by the public administration of an E.164 =
number automatically generates a valid private number, and vice versa. =
In other cases there could be no such mapping. When you apply the above =
to international private networks, with DDI ranges in multiple countries =
belonging to the same private network, it gets even more complicated.
>=20
> There are other complications resulting from the joint ownership of =
some companies, resulting in an owned companies network forming part of =
the private numbering plan of both parent companies.
>=20
> Unless there is a proven use case from deployers of private networks, =
I strongly propose that we should avoid these cases altogether.
>=20
> I'd note by the way that I have not been pushing for global =
uniqueness, only against the assumption that the numbering plans are not =
locally unique to the particular administration. I believe we should =
assume local uniqueness, but that does not presuppose global uniqueness.
>=20
> regards
>=20
> Keith
>=20
>=20
>=20
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve =
Donovan
> Sent: 20 May 2015 15:31
> To: modern@ietf.org
> Subject: Re: [Modern] TN, E.164, or Something Else?
>=20
> Eric,
>=20
> I'm not comfortable with saying that MODERN  is ONLY about managing =
globally unique identifiers as this rules out private numbering plans =
put in place by enterprises.
>=20
> Yes, MODERN is about globally unique identifiers that have the format =
of a telephone number, but it is also about private identifiers that =
also have the format of a telephone number.
>=20
> Regards,
>=20
> Steve
>=20
> On 5/18/15 5:23 PM, Eric Burger wrote:
>> Something I have been mulling about is the focus (and amount of list =
traffic) discussing whether the scope of MODERN is E.164 numbers, =
=E2=80=9Ctelephone numbers,=E2=80=9D or something else.
>>=20
>> We seem to get very emotional about E.164 numbers. Perhaps rightly =
so. An E.164 number carries a lot of a=E2=80=99priori regulatory =
baggage. By definition, the ITU-T assigns country codes. National =
numbering authorities allocate numbers to service providers. Service =
providers manage them for users.
>>=20
>> A =E2=80=9Ctelephone number=E2=80=9D spawns the debate as to whether =
it is, in fact, a =E2=80=98telephone=E2=80=99 number. Given Henning=E2=80=99=
s presentation, the value of the telephone number is global routing and =
global understanding for 5/7ths of the world using romanized arabic =
script. Given that, the people who worry that =E2=80=9Ctelephone =
number=E2=80=9D is just a code word for E.164 number are most likely =
correct. This spills into the whole =E2=80=9CIt is not an E.164 number, =
it is the ABNF for an E.164 number (see RFC3966).=E2=80=9D I.e., it =
looks, smells, and tastes like a rose.
>>=20
>> Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.
>>=20
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org 
>> https://www.ietf.org/mailman/listinfo/modern =

>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


--Apple-Mail=_7509B8EB-0152-4046-9408-056067625162
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Now I am confused.

I was thinking we are building =
something more complex than just a registry of strings of digits to =
services and maybe routing. IANA (and a host of others) can do that =
today.

I =
thought the thing that needed solving, which Henning described at the =
BOF, was a how to provision and interface with a registry that maps =
strings of digits to services and maybe routing, where =
there was a clear need for some sort of (outside of scope) policy that =
needs to be enforced.

Am I wrong in thinking the entire =
point of MODERN is the mechanisms for policy enforcement?

By policy enforcement, I =
mean that, depending on jurisdiction, policies may be that only the =
national numbering authority can delegate the authority to allocate =
numbers to registered service providers. Or, a policy may be that only =
the national numbering authority can allocate numbers to users. Or, a =
policy may be that only the user can assign which services or service =
providers are allowed to service the number. What the policies are is =
out of scope for the work group. However, that there are policies I was =
under the impression is the whole point of the work group.

I am very leery of a =
policy that says that some part of the name space lives with the ITU-T =
and national numbering authorities, but another part of the name space =
is a free-for-all. What is to stop me from declaring =E2=80=9C+1 =
214-555-1000=E2=80=9D to be just a private number?

If the proposal is that =
private numbers are not in the numbering (E.164? TN?) name space, then =
say so. Then Keith=E2=80=99s question becomes relevant: what is the use =
case? Cullen, is this in the Cisco world? Steven, is this in the Oracle =
world?

Thanks,
Eric


On May 24, 2015, at 1:27 AM, DRAGE, Keith =
(Keith) <keith.drage@alcatel-lucent.com> wrote:










Adding in private numbers =
introduces all sorts of complications.


 


In many cases there is a mapping =
between E.164 numbers and private numbers, i.e. the allocation by the =
public administration of an E.164 number automatically generates a valid
 private number, and vice versa. In other cases there could be no such =
mapping. When you apply the above to international private networks, =
with DDI ranges in multiple countries belonging to the same private =
network, it gets even more complicated.



 


There are other complications =
resulting from the joint ownership of some companies, resulting in an =
owned companies network forming part of the private numbering plan =
of both
 parent companies.


 


Unless there is a proven use =
case from deployers of private networks, I strongly propose that we =
should avoid these cases altogether.


 


I'd note by the way that I have =
not been pushing for global uniqueness, only against the assumption that =
the numbering plans are not locally unique to the particular =
administration.
 I believe we should assume local uniqueness, but that does not =
presuppose global uniqueness.


 


regards


 


Keith


 


 









From: =
Modern [mailto:modern-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: 20 May 2015 15:31

To: modern@ietf.org

Subject: Re: [Modern] TN, E.164, or Something Else?







Eric,



I'm not comfortable with saying that MODERN  is ONLY about managing =
globally unique identifiers as this rules out private numbering plans =
put in place by enterprises.




Yes, MODERN is about globally unique identifiers that have the format of =
a telephone number, but it is also about private identifiers that also =
have the format of a telephone number.



Regards,



Steve




On 5/18/15 5:23 PM, Eric Burger wrote:






Something I have been mulling about is the =
focus (and amount of list traffic) discussing whether the scope of =
MODERN is E.164 numbers, =E2=80=9Ctelephone numbers,=E2=80=9D or =
something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. =
An E.164 number carries a lot of a=E2=80=99priori regulatory baggage. By =
definition, the ITU-T assigns country codes. National numbering =
authorities allocate numbers to service providers. Service providers =
manage them for users.

A =E2=80=9Ctelephone number=E2=80=9D spawns the debate as to whether it =
is, in fact, a =E2=80=98telephone=E2=80=99 number. Given Henning=E2=80=99s=
 presentation, the value of the telephone number is global routing and =
global understanding for 5/7ths of the world using romanized arabic =
script. Given that, the people who worry that =E2=80=9Ctelephone =
number=E2=80=9D is just a code word for E.164 number are most likely =
correct. This spills into the whole =E2=80=9CIt is not an E.164 number, =
it is the ABNF for an E.164 number (see RFC3966).=E2=80=9D I.e., it =
looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.





 


_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org=
/mailman/listinfo/modern











_______________________________________________
Modern =
mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

=

--Apple-Mail=_7509B8EB-0152-4046-9408-056067625162--

--Apple-Mail=_893B1101-1D98-451F-BF59-747932BD3256
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVY0UhAAoJEDY/T2tCIPW3CC8P/3uPYUcQzdRewW7WhctfCv3+
7R5z74OYIA6RMnJ7vx7fjAtGYrDEWF0PftFQbQWowmPKmbStnww00GH1W+8CvglD
lm+uef4AaUC4O5gZwUs6k1Ah2/aaVEHLgXsm4o3k81pEm2iSQsLkSJNoGJ2yuOeU
y9rJXjiRzCt4tbDtbiyO7lcxu8FcGyUQoPYbSZV3s/3TElJXlYiYa7NxIEsh76B9
ImPsIhp+L3zA+e9e0AfggN/yleWiibiaGuz3evnxX3R1s03sfQQKdbWuZE7GqTlS
7wiUb/nJtyRIbqnFKU4EYKiPCrvLwti1ydgW5+iTmUT+XXHlpCiO0lDZK5/a8KZ8
A/AHZ3zkpk47LfQwjygkUkU0pmW4uAc8bjomjWnS2A5/eC9qP0NKXD1AGr15W5JJ
zpHBiCjZcr8cLLaoX1gp52vqAbkqkAAURANQdQO3kWq2+6Crn6pAeaBBF4rCyspv
ri0dWI5XZ6wlxwgo3BPWLFhEeHGC3cQxkiYxAHwt0Coi1CjJSskP2uMZ3cYSsJ7B
7hUN8J6qQHadLk9+JKvByjrhlI4zQRmg5DhNwZtyohjjT2gmLFEAPMvBIrDJuoBd
v31ycF6NxyrRGYTSVVXfeW0Daor37hRFDIlhIvYmDG6Xrjmk/bi92Yqt1MHzncfb
UYVe7v89TVEw8GGCtEXM
=vEZk
-----END PGP SIGNATURE-----

--Apple-Mail=_893B1101-1D98-451F-BF59-747932BD3256--


From nobody Mon May 25 19:14:29 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 5374A1AD1EE for ; Mon, 25 May 2015 19:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.421
X-Spam-Level: 
X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, 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 hhZBdu6T2Wvh for ; Mon, 25 May 2015 19:14:24 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 AA8FD1AD1D5 for ; Mon, 25 May 2015 19:14:24 -0700 (PDT)
Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:62580 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yx4No-000869-H0 for modern@ietf.org; Mon, 25 May 2015 19:14:23 -0700
Message-ID: <5563D6FB.2060002@usdonovans.com>
Date: Mon, 25 May 2015 21:14:19 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: modern@ietf.org
References: <554B6DB9.9010901@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971360F@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B69713D26@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B69713E2A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55549CD1.1060904@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B69715C8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <387AE8AB-0619-4028-8E9E-8BD886F813B3@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69715DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555613EC.9090909@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69715FB5@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555A0A44.5070409@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971717E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <555C9B42.3010906@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971B7D3@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6971B7D3@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter)
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, 26 May 2015 02:14:28 -0000

On 5/24/15 12:29 AM, DRAGE, Keith (Keith) wrote:
> I assume you mean "pare".
SRD> Yes.
>
> I was not aware that IETF defined charters of the form "Lets solve everything including world hunger" and decided what it might work on after the charter was approved.
SRD> What in the charter, RFC3966 or my email talks about solving world 
hunger?  My email was in reference to RFC3966, which, to my 
understanding, solves a much simpler problem than world hunger.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of
>> Steve Donovan
>> Sent: 20 May 2015 15:34
>> To: modern@ietf.org
>> Subject: Re: [Modern] Definition of TN (was Re: Proposed
>> change to paragraph three of the charter)
>>
>>
>>
>> On 5/18/15 6:05 PM, DRAGE, Keith (Keith) wrote:
>>> I provided wording messages back which I think provided
>> better definition of what we mean by telephone numbers that
>> the current reference to RFC 3966, which to me is providing a
>> coding solution with too many options.
>>
>> Then we can pair away the options that don't apply as part of
>> the working group effort.
>>> And being able to "cook" up a use case does not mean that
>> we need that as a use case.
>> I do think that private numbering plans should be in scope,
>> or at least not ruled out of scope by the charter.
>>> Keith
>>>
>>>> -----Original Message-----
>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve
>>>> Donovan
>>>> Sent: 18 May 2015 16:50
>>>> To: modern@ietf.org
>>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed change to
>>>> paragraph three of the charter)
>>>>
>>>> Keith,
>>>>
>>>> I think this is something that can be discussed by the
>> working group
>>>> and, to my mind, doesn't require addressing in the charter.
>>>>
>>>> I can "cook up" a use case where public and private number formats
>>>> could be used in a single session, but I don't feel that
>> is relevant
>>>> to the charter discussion.
>>>>
>>>> Can we live with the charter as currently worded and
>> address this as
>>>> part of the working group effort?
>>>>
>>>> Steve
>>>>
>>>> On 5/15/15 1:02 PM, DRAGE, Keith (Keith) wrote:
>>>>> You tell me, but my expectation, that it will not happen on
>>>> a per session basis, and any entity receiving this
>> information will
>>>> be capable of, and need to be capable of, switching between the
>>>> different number formats.
>>>>> Keith
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Paul
>>>>>> Kyzivat
>>>>>> Sent: 15 May 2015 16:43
>>>>>> To: modern@ietf.org
>>>>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed
>> change to
>>>>>> paragraph three of the charter)
>>>>>>
>>>>>> On 5/15/15 10:36 AM, DRAGE, Keith (Keith) wrote:
>>>>>>> You have at least missed the point I have been making.
>>>>>>>
>>>>>>> By using RFC 3966 as a syntax definition, you automatically
>>>>>> include a requirement to support phone context.
>>>>>>> The point I am making is that in my understanding from the
>>>>>> use cases so far discussed, phone context is unnecessary,
>>>> as we are
>>>>>> dealing with protocol with a single administration supporting a
>>>>>> single national numbering space. The context is one only
>>>> and implicit
>>>>>> in the administration one is presumably securely
>>>> communicating with.
>>>>>> Isn't it an expectation that the numbers being discussed
>>>>>> *can* be represented in SIP? If so, then 3966 is relevant.
>>>>>>
>>>>>> 	Thanks,
>>>>>> 	Paul
>>>>>>
>>>>>>> Keith
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ben Campbell [mailto:ben@nostrum.com]
>>>>>>>> Sent: 15 May 2015 15:04
>>>>>>>> To: DRAGE, Keith (Keith)
>>>>>>>> Cc: Steve Donovan; modern@ietf.org
>>>>>>>> Subject: Re: [Modern] Definition of TN (was Re: Proposed
>>>> change to
>>>>>>>> paragraph three of the charter)
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>> (I'm not picking on Keith in particular. This just
>> seemed a good
>>>>>>>> place to jump in.)
>>>>>>>>
>>>>>>>> I'd like to remind people that this is a charter, not a
>>>> technical
>>>>>>>> specification. We need guidance to the working group. It
>>>>>> doesn't have
>>>>>>>> to be perfect, and there's room for some flexibility
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>> It seems to me that the syntax is mainly what we care
>>>> about, _not_
>>>>>>>> the architecture of coordinating bodies. My
>> understanding is the
>>>>>>>> whole point of this exercise is to avoid building
>>>>>> assumptions about
>>>>>>>> that architecture and related policies into the
>>>> technology itself.
>>>>>>>> If a national administration defines escape digits, we
>>>> need to be
>>>>>>>> able to handle escape digits. But that doesn't mean we
>>>>>> have to import
>>>>>>>> the whole administrative architecture.
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote:
>>>>>>>>
>>>>>>>>> The IETF has NOT defined telephone numbers. RFC 3966
>>>>>>>> defines a syntax
>>>>>>>>> that can be used to carry them, and I question whether that
>>>>>>>> syntax is
>>>>>>>>> appropriate for use in the scenarios so far identified. To
>>>>>>>> understand
>>>>>>>>> what RFC 3966 means one has to go to E.164 (and
>>>>>> associated national
>>>>>>>>> numbering plans) and hope it touchs with the terminology
>>>>>>>> used in those
>>>>>>>>> places.
>>>>>>>>>
>>>>>>>>> I am fine as far it goes in terms of a sequence of decimal
>>>>>>>> digits, but
>>>>>>>>> when we get to whether a phone context is required, then
>>>>>> that is a
>>>>>>>>> jump into essentially supporting multiple numbering
>>>> plans over a
>>>>>>>>> single interface. That would seem to be identifying an
>>>>>>>> architecture of
>>>>>>>>> coordinating bodies with multiple numbering plans well
>>>> beyond the
>>>>>>>>> scope of what is described so far.
>>>>>>>>>
>>>>>>>>> Within national administration, escape digits are defined
>>>>>>>> within the
>>>>>>>>> national numbering plan to clearly identity all allocations
>>>>>>>> within the
>>>>>>>>> national area. At least my assumption is that any
>>>>>> procedures we are
>>>>>>>>> looking at would be within the context of a national
>>>>>> numbering plan.
>>>>>>>>> If you have ideas that go beyond this, then perhaps you
>>>>>>>> need to expand
>>>>>>>>> on them, because that goes way beyond what we have
>>>>>> discussed so far.
>>>>>>>>> Keith
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On
>>>> Behalf Of Steve
>>>>>>>>>> Donovan
>>>>>>>>>> Sent: 14 May 2015 14:02
>>>>>>>>>> To: modern@ietf.org
>>>>>>>>>> Subject: [Modern] Definition of TN (was Re: Proposed
>> change to
>>>>>>>>>> paragraph three of the charter)
>>>>>>>>>>
>>>>>>>>>> The IETF has already spent time defining telephone numbers
>>>>>>>> and I see
>>>>>>>>>> little value in redefining the concept in the MODERN
>>>>>> charter.  As
>>>>>>>>>> such, I propose that we include a reference to
>> RFC3966 as the
>>>>>>>>>> definition of TN.
>>>>>>>>>>
>>>>>>>>>> As one data point, the SCIM work references RFC3966 for
>>>>>> telephone
>>>>>>>>>> numbers.  We might, by the way, want to add SCIM to the
>>>>>>>> list of areas
>>>>>>>>>> we look at in the charter.
>>>>>>>>>>
>>>>>>>>>> See my comments on Kieth's points below.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Steve
>>>>>>>>>>
>>>>>>>>>> On 5/12/15 12:07 PM, DRAGE, Keith (Keith) wrote:
>>>>>>>>>>> Firstly the charter gives no definition of what you are
>>>>>>>>>> using for telephone number, e.g. by reference to RFC 3966.
>>>>>>>>>>> RFC 3966 basically defines it as any sequence of decimal
>>>>>>>>>> digits. Other usages elsewhere include alphabetic
>>>>>>>> characters, because
>>>>>>>>>> this name is used both in the context of what the user
>>>>>>>> represents to
>>>>>>>>>> other users as his number and what actually gets used in a
>>>>>>>> signalling
>>>>>>>>>> protocol.
>>>>>>>>>>> The ITU-T terms actually distinguish between those two
>>>>>>>>>> usages, by putting them in separate recommendations.
>>>>>>>>>> SRD> RFC3966 deals with this, indicating that alphabetic
>>>>>>>>>> characters are
>>>>>>>>>> limited to local (non global) numbers.
>>>>>>>>>>> The additionally problem with RFC 3966 as a definition as
>>>>>>>>>> it does not define a usage where every sequence of digits
>>>>>>>> is unique,
>>>>>>>>>> and therefore it has to add a phone context to enable that
>>>>>>>> uniqueness
>>>>>>>>>> to exist, with a default applying to "global"
>>>>>>>>>> numbers.
>>>>>>>>>>> So do you intend such digit sequences used within this
>>>>>>>>>> group to be unique or will it need a phone context as a
>>>>>> result of
>>>>>>>>>> using the RFC 3966 definition? The definitions I provided
>>>>>>>> would not.
>>>>>>>>>> SRD> I suspect we will follow RFC3966, with global numbers
>>>>>>>> being the
>>>>>>>>>> default.  There is no reason to limit what MODERN does
>>>>>> to managing
>>>>>>>>>> global numbers.  I would not, however, suggest we take on
>>>>>>>> including
>>>>>>>>>> private number resources as a use case for the
>> initial MODERN
>>>>>>>>>> charter.
>>>>>>>>>>> In regard to:
>>>>>>>>>>>
>>>>>>>>>>>> I do gather that you believe the expertise to do the
>>>>>> MODERN work
>>>>>>>>>>>> resides in SG-2 rather than in the IETF. But the
>>>>>>>> proposed working
>>>>>>>>>>>> group will not, say, reassign country code
>>>>>>>>>>>> +44 to someone else, or do any of the things you'd need the
>>>>>>>>>>>> expertise and authority of that body to do. We're not
>>>>>> delegating
>>>>>>>>>>>> authority for country codes to Internet entities as ENUM
>>>>>>>>>> did, which
>>>>>>>>>>>> necessitated an IAB liaison with SG-2, even. Those are
>>>>>>>> all policy
>>>>>>>>>>>> issues. We're not trying to build policy, we're trying to
>>>>>>>>>> build tools
>>>>>>>>>>>> that will work in a variety of policy environments.
>>>>>>>>>>> Then I do not believe that. I believe SG2 should define
>>>>>>>>>> what the numbers are that we use, and maybe they should
>>>>>> define the
>>>>>>>>>> use cases. Once it is reduced to fulfilling a protocol
>>>>>>>> requirement,
>>>>>>>>>> then I anyone (including IETF) can do the work.
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> Keith
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
>>>>>>>>>>>> Sent: 12 May 2015 17:37
>>>>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org
>>>>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph
>>>>>> three of the
>>>>>>>>>>>> charter
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, what I've said consistently is that what I mean by
>>>>>>>> the term is
>>>>>>>>>>>> what
>>>>>>>>>>>> RFC3966 meant by the term. TeRQ deferred to that
>>>>>>>> specification for
>>>>>>>>>>>> its formal definition of telephone number, say. I see no
>>>>>>>> reason to
>>>>>>>>>>>> reinvent that wheel.
>>>>>>>>>>>>
>>>>>>>>>>>> If we get to a place where the term "telephone number" is
>>>>>>>>>> imprecise
>>>>>>>>>>>> or toxic, then I think we've confused ourselves into a
>>>>>>>>>> rejection of
>>>>>>>>>>>> common sense and common usage. The term is used
>>>>>> without warning
>>>>>>>>>>>> labels in IETF standards track specifications already.
>>>>>>>> The bar you
>>>>>>>>>>>> are raising is not consistent with IETF usage.
>>>>>>>>>>>>
>>>>>>>>>>>> I do gather that you believe the expertise to do the
>>>>>> MODERN work
>>>>>>>>>>>> resides in SG-2 rather than in the IETF. But the
>>>>>>>> proposed working
>>>>>>>>>>>> group will not, say, reassign country code
>>>>>>>>>>>> +44 to someone else, or do any of the things you'd need the
>>>>>>>>>>>> expertise and authority of that body to do. We're not
>>>>>> delegating
>>>>>>>>>>>> authority for country codes to Internet entities as ENUM
>>>>>>>>>> did, which
>>>>>>>>>>>> necessitated an IAB liaison with SG-2, even. Those are
>>>>>>>> all policy
>>>>>>>>>>>> issues. We're not trying to build policy, we're trying to
>>>>>>>>>> build tools
>>>>>>>>>>>> that will work in a variety of policy environments.
>>>>>>>>>>>>
>>>>>>>>>>>> Jon Peterson
>>>>>>>>>>>> Neustar, Inc.
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)"
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I am not doing that at all.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am proposing to remove any attempt by you and others to
>>>>>>>>>>>> use the term
>>>>>>>>>>>>> "telephone number" in a totally undefined manner, and
>>>>>>>>>>>> replacing it with
>>>>>>>>>>>>> terms that have been defined by the body that knows about
>>>>>>>>>>>> these things,
>>>>>>>>>>>>> i.e. SG2 of ITU-T.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are consisting opposing telling us what you mean by
>>>>>>>> the team.
>>>>>>>>>>>>> My proposal is not to include the term "telephone
>>>>>>>> number" at all.
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>
>>>>>>>>>>>>> Keith
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On
>> Behalf Of
>>>>>>>>>>>> Peterson,
>>>>>>>>>>>>>> Jon
>>>>>>>>>>>>>> Sent: 12 May 2015 16:17
>>>>>>>>>>>>>> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org
>>>>>>>>>>>>>> Subject: Re: [Modern] Proposed change to paragraph
>>>>>>>> three of the
>>>>>>>>>>>>>> charter
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again, I'd be more sympathetic to this request
>> to invent a
>>>>>>>>>>>> new IETF
>>>>>>>>>>>>>> definition of telephone numbers if we didn't already have
>>>>>>>>>>>> standards
>>>>>>>>>>>>>> track RFCs that have done that, and by reference
>>>> to the same
>>>>>>>>>>>>>> specifications you're describing here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We don't mean anything different by telephone
>>>>>> numbers than the
>>>>>>>>>>>>>> abstract of
>>>>>>>>>>>>>> RFC3966 did when it said that "the 'tel' URI describes
>>>>>>>> resources
>>>>>>>>>>>>>> identified by telephone numbers."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jon Peterson
>>>>>>>>>>>>>> Neustar, Inc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)"
>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do not agree with the charter being widened to "TN" or
>>>>>>>>>>>> presumably
>>>>>>>>>>>>>>> "telephone numbers". The reason for this is
>> that telephone
>>>>>>>>>>>>>> numbers has
>>>>>>>>>>>>>>> a wide and undefined scope, possibly including
>> alphabetic
>>>>>>>>>>>>>> characters as
>>>>>>>>>>>>>>> well (as in the letters on the dialling ring).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Based on the statements made by others in terms of what
>>>>>>>>>>>> needs to be
>>>>>>>>>>>>>>> covered, I would prefer a more precise definition of:
>>>>>>>>>>>> "international
>>>>>>>>>>>>>>> E.164 numbers, local special purpose numbers,
>> and network
>>>>>>>>>>>> specific
>>>>>>>>>>>>>>> numbers" using the explanation of these terms
>> that can be
>>>>>>>>>>>> found in
>>>>>>>>>>>>>>> ITU-T Recommendation E.164.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Keith
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf
>>>>>>>>>>>> Of Steve
>>>>>>>>>>>>>>>> Donovan
>>>>>>>>>>>>>>>> Sent: 07 May 2015 14:51
>>>>>>>>>>>>>>>> To: modern@ietf.org
>>>>>>>>>>>>>>>> Subject: [Modern] Proposed change to paragraph
>>>>>> three of the
>>>>>>>>>>>>>>>> charter
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Paragraph three currently reads as follows:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "The work of this group will focus on E.164 telephone
>>>>>>>>>>>>>> numbers due to
>>>>>>>>>>>>>>>> the changing telecom environment and interest
>>>> expressed by
>>>>>>>>>>>>>>>> telecommunications industry regulators to support more
>>>>>>>>>> flexible
>>>>>>>>>>>>>>>> regulatory models than exist today.
>>>>>>>>>>>>>>>> There is an expectation that aspects of the
>>>>>> architecture and
>>>>>>>>>>>>>>>> protocols defined by the working group will be reusable
>>>>>>>>>>>> for other
>>>>>>>>>>>>>>>> user-focused identifiers.  Any such extensions or reuse
>>>>>>>>>>>> of MODERN
>>>>>>>>>>>>>>>> mechanisms are out of scope for the MODERN
>> working group.
>>>>>>>>>>>>>> Solutions
>>>>>>>>>>>>>>>> and mechanisms created by the working group will be
>>>>>>>>>>>>>> flexible enough
>>>>>>>>>>>>>>>> to accommodate different policies, e.g., by different
>>>>>>>>>>>> regulatory
>>>>>>>>>>>>>>>> agencies."
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I propose changing the first sentence to the following:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "The work of this group will focus on TNs --
>>>> such as E.164
>>>>>>>>>>>>>> numbers --
>>>>>>>>>>>>>>>> and blocks of TNs, that are used to initiate
>>>>>>>>>> communication with
>>>>>>>>>>>>>>>> another user of a service.  The work is motivated by
>>>>>>>>>>>> the changing
>>>>>>>>>>>>>>>> telecom environment and interest expressed by
>>>>>>>>>>>> telecommunications
>>>>>>>>>>>>>>>> industry regulators to support more flexible regulatory
>>>>>>>>>>>>>> models than
>>>>>>>>>>>>>>>> exist today. "
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The remainder of the paragraph, starting with
>>>> "There is an
>>>>>>>>>>>>>>>> expectation..." would remain unchanged.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This adds some clarity on the scope of telephony
>>>>>>>>>>>>>> identifiers covered
>>>>>>>>>>>>>>>> as well as making it clear that blocks of TNs are
>>>>>>>> also covered.
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Steve
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Modern mailing list
>>>>>>>>>>>>>>>> Modern@ietf.org
>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Modern mailing list
>>>>>>>>>>>>>>> Modern@ietf.org
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Modern mailing list
>>>>>>>>>>>>>> Modern@ietf.org
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Modern mailing list
>>>>>>>>>>> Modern@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Modern mailing list
>>>>>>>>>> Modern@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Modern mailing list
>>>>>>>>> Modern@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>> _______________________________________________
>>>>>>> Modern mailing list
>>>>>>> Modern@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Modern mailing list
>>>>>> Modern@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>> Modern@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
>


From nobody Mon May 25 19:21:39 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 3715B1A8885 for ; Mon, 25 May 2015 19:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 HRYczkiFNqKj for ; Mon, 25 May 2015 19:21:34 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 C42041A8884 for ; Mon, 25 May 2015 19:21:34 -0700 (PDT)
Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:62628 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yx4Um-0001lo-DI for modern@ietf.org; Mon, 25 May 2015 19:21:34 -0700
Message-ID: <5563D8AB.5090407@usdonovans.com>
Date: Mon, 25 May 2015 21:21:31 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: modern@ietf.org
References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <12180B6D-426A-49DA-9D65-FAC676587E8D@standardstrack.com>
In-Reply-To: <12180B6D-426A-49DA-9D65-FAC676587E8D@standardstrack.com>
Content-Type: multipart/alternative; boundary="------------070604090703030105070901"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 02:21:37 -0000

This is a multi-part message in MIME format.
--------------070604090703030105070901
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Private number spaces cannot be part of the publicly managed numbers.  
They can and generally are mapped to public numbers but that is very 
different from me declaring that "+1 214 555 0000" is a private number.  
Private numbers only work in the context of devices used in the "domain" 
that is administering the private number space.

I thought I had already said that private numbers are not a part of 
E.164.  They are, however, still TNs by the definition currently in the 
charter: "TNs, as defined in RFC3966, and blocks of TNs, that are used 
to initiate communication with another user of a service. "

Steve

On 5/25/15 10:52 AM, Eric Burger wrote:
> Now I am confused.
>
> I was thinking we are building something more complex than just a 
> registry of strings of digits to services and maybe routing. IANA (and 
> a host of others) can do that today.
>
> I thought the thing that needed solving, which Henning described at 
> the BOF, was a how to provision and interface with a registry that 
> maps strings of digits to services and maybe routing, *where there was 
> a clear need for some sort of (outside of scope) policy that needs to 
> be enforced.*
> *
> *
> Am I wrong in thinking the entire point of MODERN is the mechanisms 
> for policy enforcement?
>
> By policy enforcement, I mean that, depending on jurisdiction, 
> policies may be that only the national numbering authority can 
> delegate the authority to allocate numbers to registered service 
> providers. Or, a policy may be that only the national numbering 
> authority can allocate numbers to users. Or, a policy may be that only 
> the user can assign which services or service providers are allowed to 
> service the number. What the policies are is out of scope for the work 
> group. However, that there are policies I was under the impression is 
> the whole point of the work group.
>
> I am very leery of a policy that says that some part of the name space 
> lives with the ITU-T and national numbering authorities, but another 
> part of the name space is a free-for-all. What is to stop me from 
> declaring “+1 214-555-1000” to be just a private number?
>
> If the proposal is that private numbers are not in the numbering 
> (E.164? TN?) name space, then say so. Then Keith’s question becomes 
> relevant: what is the use case? Cullen, is this in the Cisco world? 
> Steven, is this in the Oracle world?
>
> Thanks,
> Eric
>
>
>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) 
>> > > wrote:
>>
>> Adding in private numbers introduces all sorts of complications.
>> In many cases there is a mapping between E.164 numbers and private 
>> numbers, i.e. the allocation by the public administration of an E.164 
>> number automatically generates a valid private number, and vice 
>> versa. In other cases there could be no such mapping. When you apply 
>> the above to international private networks, with DDI ranges in 
>> multiple countries belonging to the same private network, it gets 
>> even more complicated.
>> There are other complications resulting from the joint ownership of 
>> some companies, resulting in an owned companies network forming part 
>> of the private numbering plan of both parent companies.
>> Unless there is a proven use case from deployers of private networks, 
>> I strongly propose that we should avoid these cases altogether.
>> I'd note by the way that I have not been pushing for global 
>> uniqueness, only against the assumption that the numbering plans are 
>> not locally unique to the particular administration. I believe we 
>> should assume local uniqueness, but that does not presuppose global 
>> uniqueness.
>> regards
>> Keith
>>
>>     ------------------------------------------------------------------------
>>     *From:* Modern [mailto:modern-bounces@ietf.org] *On Behalf Of
>>     *Steve Donovan
>>     *Sent:* 20 May 2015 15:31
>>     *To:* modern@ietf.org 
>>     *Subject:* Re: [Modern] TN, E.164, or Something Else?
>>
>>     Eric,
>>
>>     I'm not comfortable with saying that MODERN  is ONLY about
>>     managing globally unique identifiers as this rules out private
>>     numbering plans put in place by enterprises.
>>
>>     Yes, MODERN is about globally unique identifiers that have the
>>     format of a telephone number, but it is also about private
>>     identifiers that also have the format of a telephone number.
>>
>>     Regards,
>>
>>     Steve
>>
>>     On 5/18/15 5:23 PM, Eric Burger wrote:
>>>     Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else.
>>>
>>>     We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.
>>>
>>>     A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose.
>>>
>>>     Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy.
>>>
>>>
>>>     _______________________________________________
>>>     Modern mailing list
>>>     Modern@ietf.org
>>>     https://www.ietf.org/mailman/listinfo/modern
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org 
>> https://www.ietf.org/mailman/listinfo/modern
>
>
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


--------------070604090703030105070901
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Private number spaces cannot be part of the publicly managed
    numbers.  They can and generally are mapped to public numbers but
    that is very different from me declaring that "+1 214 555 0000" is a
    private number.  Private numbers only work in the context of devices
    used in the "domain" that is administering the private number space.

    

    I thought I had already said that private numbers are not a part of
    E.164.  They are, however, still TNs by the definition currently in
    the charter: "TNs, as defined in RFC3966, and blocks of TNs, that
    are used to initiate communication with another user of a service. "

    

    Steve

    

    
On 5/25/15 10:52 AM, Eric Burger wrote:

    

    

      
      
Now I am confused.

      


      

      
I was thinking we are building something more
        complex than just a registry of strings of digits to services
        and maybe routing. IANA (and a host of others) can do that
        today.

      


      

      
I thought the thing that needed solving, which
        Henning described at the BOF, was a how to provision and
        interface with a registry that maps strings of digits to
        services and maybe routing, where there was a clear
          need for some sort of (outside of scope) policy that needs to
          be enforced.

      


        

      
Am I wrong in thinking the entire point of MODERN is
        the mechanisms for policy enforcement?

      


      

      
By policy enforcement, I mean that, depending on
        jurisdiction, policies may be that only the national numbering
        authority can delegate the authority to allocate numbers to
        registered service providers. Or, a policy may be that only the
        national numbering authority can allocate numbers to users. Or,
        a policy may be that only the user can assign which services or
        service providers are allowed to service the number. What the
        policies are is out of scope for the work group. However, that
        there are policies I was under the impression is the whole point
        of the work group.

      


      

      
I am very leery of a policy that says that some part
        of the name space lives with the ITU-T and national numbering
        authorities, but another part of the name space is a
        free-for-all. What is to stop me from declaring “+1
        214-555-1000” to be just a private number?

      


      

      
If the proposal is that private numbers are not in
        the numbering (E.164? TN?) name space, then say so. Then Keith’s
        question becomes relevant: what is the use case? Cullen, is this
        in the Cisco world? Steven, is this in the Oracle world?

      


      

      
Thanks,

      
Eric

      


      

      

      

        

          
On May 24, 2015, at 1:27 AM, DRAGE, Keith
            (Keith) <keith.drage@alcatel-lucent.com>
            wrote:

          

          

            
            
            

              
Adding
                    in private numbers introduces all sorts of
                    complications.

              
 

              
In
                    many cases there is a mapping between E.164 numbers
                    and private numbers, i.e. the allocation by the
                    public administration of an E.164 number
                    automatically generates a valid private number, and
                    vice versa. In other cases there could be no such
                    mapping. When you apply the above to international
                    private networks, with DDI ranges in multiple
                    countries belonging to the same private network, it
                    gets even more complicated.
                  

              
 

              
There
                    are other complications resulting from the joint
                    ownership of some companies, resulting in an owned
                    companies network forming part of the private
                    numbering plan of both parent companies.

              
 

              
Unless
                    there is a proven use case from deployers of private
                    networks, I strongly propose that we should avoid
                    these cases altogether.

              
 

              
I'd
                    note by the way that I have not been pushing for
                    global uniqueness, only against the assumption that
                    the numbering plans are not locally unique to the
                    particular administration. I believe we should
                    assume local uniqueness, but that does not
                    presuppose global uniqueness.

              
 

              
regards

              
 

              
Keith

              
 

              
 

              

              

                

                  

                  From:
                    Modern [mailto:modern-bounces@ietf.org]
                    On Behalf Of Steve Donovan

                    Sent: 20 May 2015 15:31

                    To: modern@ietf.org

                    Subject: Re: [Modern] TN, E.164, or
                    Something Else?

                  

                

                Eric,

                

                I'm not comfortable with saying that MODERN  is ONLY
                about managing globally unique identifiers as this rules
                out private numbering plans put in place by enterprises.
                

                

                Yes, MODERN is about globally unique identifiers that
                have the format of a telephone number, but it is also
                about private identifiers that also have the format of a
                telephone number.

                

                Regards,

                

                Steve

                

                
On 5/18/15 5:23 PM, Eric
                  Burger wrote:

                

                

                  
Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.

A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy.


                  

                  

                  

                  
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


                

                

              

            

            _______________________________________________

            Modern mailing list

            Modern@ietf.org

            https://www.ietf.org/mailman/listinfo/modern

          

        

      

      

      

      

      

      
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


    

    

  


--------------070604090703030105070901--


From nobody Tue May 26 07:26:54 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 1BAEA1B2F1F for ; Tue, 26 May 2015 07:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 tVEqeR-Z3SEN for ; Tue, 26 May 2015 07:26:48 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C30A1B2F19 for ; Tue, 26 May 2015 07:26:47 -0700 (PDT)
Received: by qgfa63 with SMTP id a63so62651732qgf.0 for ; Tue, 26 May 2015 07:26:45 -0700 (PDT)
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=fkRiCx1RgCA7xvf0WCcz/dUyf+Ha739sNUf1fvu23SY=; b=jC1vxfY+zzdjG5VFDll/yKdKs6GXr4smD5hM+TxwTLv+umdjovEPZbF8zqJFsluXP0 YH7gdpa5Q6lkspH47hGIN/IXGPfFnVMuR3JKC4ku6C+TsHLkASMiPH/YCfHtEHkniW38 ZUShonGmbsZxlwAUCevcfpwMfTmgjDsbyEtO1yAdPrwchwDlE8OZb1RhEor4xf3hkkcn 6IkOF7kqWaIZcoVLXTOpa7f9en2Zc4UXzwnmKnCHlXVoKeTrkYp1scfDj6rS1wskzrGY ePmbXXfXyX0GjUDHWEaF2c5EKSKX85t36T+rNH0H4Hm4DrFCkd8Zra1el4KQRNy94cs5 vuXg==
X-Gm-Message-State: ALoCoQm0K+rc/Z/Ub63zNDlAHDtUvT+gEA5LnGFELkNGDyDLIroNQlZ9RihUoKHzlF7owx0gU6GP
X-Received: by 10.55.40.42 with SMTP id o42mr56359098qkh.73.1432650405780; Tue, 26 May 2015 07:26:45 -0700 (PDT)
Received: from [10.0.2.133] (c-69-247-98-164.hsd1.pa.comcast.net. [69.247.98.164]) by mx.google.com with ESMTPSA id x66sm4149940qha.8.2015.05.26.07.26.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 May 2015 07:26:44 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F50B01E-DFB2-4BF8-A8E0-A4C61E824D9C"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Chris Wendt 
In-Reply-To: <555E203D.2050304@usdonovans.com>
Date: Tue, 26 May 2015 10:26:47 -0400
Message-Id: <8EA6AF50-2A11-4D77-B606-87980D417E03@chriswendt.net>
References:  <555E203D.2050304@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: modern@ietf.org
Subject: Re: [Modern] P2P (was Third revision of MODERN charter)
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, 26 May 2015 14:26:53 -0000

--Apple-Mail=_0F50B01E-DFB2-4BF8-A8E0-A4C61E824D9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Yes, would be interested in other perspectives, but Eric in his response =
said =93peer-to-peer assignment technology=94.  Maybe it=92s a subtle =
difference and a minor point, but the general term "peer-to-peer" has =
some implied techniques that i don=92t think are being proposed here.

Distributed i think captures things a bit better in the context of a =
multi-node distributed datastore, as is fairly commonly implemented in =
many popular open solutions.

> On May 21, 2015, at 2:13 PM, Steve Donovan  =
wrote:
>=20
> Chris,
>=20
> Was your suggestion to make the following change?
>=20
> From:
>=20
> " TNs may either be managed in a hierarchical tree, or in a =
distributed peer-to-peer architecture. "
>=20
> To:
>=20
> "TNs may either be managed in a hierarchical tree, or in a distributed =
registry."
>=20
> Steve
>=20
> On 5/19/15 11:41 AM, McGarry, Tom wrote:
>> Good suggestion, much better.
>>=20
>> On 5/19/15 12:29 AM, "Chris Wendt"  =
 wrote:
>>=20
>>> I think something like simply "Distributed Registry" might be a more
>>> straight forward term to stick to.  "Peer-to-peer" isn=B9t =
necessarily an
>>> inappropriate way to describe the gossip based distributed protocols
>>> Henning referred to in his presentation, but has some historical =
meaning
>>> that could potentially confuse or imply something other than what is
>>> being proposed or discussed.
>>>=20
>>>=20
>>>> On May 18, 2015, at 3:14 PM, Eric Burger =
 
>>>> wrote:
>>>>=20
>>>> All of Henning=B9s slides were about number assignments in a =
hierarchy.
>>>> My recollection is all of the use cases were about number =
assignments in
>>>> a hierarchy. I am not against working on peer-to-peer assignment
>>>> technology. However, I wanted to make sure this is something that =
people
>>>> want to work on.
>>>>=20
>>>> What is the use case? Sorry if I missed it. When I greped the =
archive,
>>>> the term =8Cpeer=B9 does not hit, other than in the charter drafts.
>>>>=20
>>>>> On May 14, 2015, at 2:35 PM, Steve Donovan =
 
>>>>> wrote:
>>>>>=20
>>>>> TNs may either be managed in a hierarchical tree, or in a =
distributed
>>>>> peer-to-peer architecture.
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org 
>>>>=20
>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n =

>>>> =
_listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
IDcLe
>>>> =
xtZ1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=3D=
X
>>>> phhxgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org 
>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_ =

>>> =
listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcLext
>>> =
Z1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=3D=
Xphh
>>> xgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org 
>> https://www.ietf.org/mailman/listinfo/modern =

>>=20
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org 
> https://www.ietf.org/mailman/listinfo/modern =



--Apple-Mail=_0F50B01E-DFB2-4BF8-A8E0-A4C61E824D9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Yes, would be interested in other perspectives, but Eric in =
his response said =93peer-to-peer assignment technology=94.  Maybe =
it=92s a subtle difference and a minor point, but the general term =
"peer-to-peer" has some implied techniques that i don=92t think are =
being proposed here.

Distributed i think captures things a bit better in the =
context of a multi-node distributed datastore, as is fairly commonly =
implemented in many popular open solutions.

On May 21, 2015, at 2:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Chris,

Was your suggestion to make the following =
change?

From:

" TNs may =
either be managed in a hierarchical tree, or in a distributed =
peer-to-peer architecture. "

To:

"TNs may either be managed in a hierarchical =
tree, or in a distributed registry."

Steve
On 5/19/15 11:41 AM, McGarry, Tom =
wrote:
Good suggestion, much =
better.

On 5/19/15 12:29 AM, "Chris Wendt" <chris-ietf@chriswendt.net>=
; wrote:


I =
think something like simply "Distributed Registry" might be a more
straight forward term to stick to.  "Peer-to-peer" isn=B9t necessarily =
an
inappropriate way to describe the gossip based distributed protocols
Henning referred to in his presentation, but has some historical meaning
that could potentially confuse or imply something other than what is
being proposed or discussed.



On =
May 18, 2015, at 3:14 PM, Eric Burger <eburger@standardstrack.com&=
gt;
wrote:

All of Henning=B9s slides were about number assignments in a hierarchy.
My recollection is all of the use cases were about number assignments in
a hierarchy. I am not against working on peer-to-peer assignment
technology. However, I wanted to make sure this is something that people
want to work on.

What is the use case? Sorry if I missed it. When I greped the archive,
the term =8Cpeer=B9 does not hit, other than in the charter drafts.


On =
May 14, 2015, at 2:35 PM, Steve Donovan <srdonovan@usdonovans.com><=
/a>
wrote:

TNs may either be managed in a hierarchical tree, or in a distributed
peer-to-peer architecture.

_______________________________________________
Modern mailing list
Modern@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman
=
_listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Kl=
m32iB7HufveeIDcLe
=
xtZ1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZ=
M&s=3DX
phhxgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D

_______________________________________________
Modern mailing list
Modern@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet=
f.org_mailman_
=
listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm=
32iB7HufveeIDcLext
=
Z1ooNcfp01IYIaVqsORjI&m=3DTrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&=
amp;s=3DXphh
xgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=3D=20

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org=
/mailman/listinfo/modern



_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

=

--Apple-Mail=_0F50B01E-DFB2-4BF8-A8E0-A4C61E824D9C--


From nobody Tue May 26 07:27:22 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 8E0571B2F1F for ; Tue, 26 May 2015 07:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ljXw3CNqSdkf for ; Tue, 26 May 2015 07:27:14 -0700 (PDT)
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FC91B2F19 for ; Tue, 26 May 2015 07:27:13 -0700 (PDT)
Received: by qkx62 with SMTP id 62so90004645qkx.3 for ; Tue, 26 May 2015 07:27:13 -0700 (PDT)
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=G+yCB+s3rOBRktyT+BUFHAiWSeC29+1QKBxSenPHnVE=; b=CQteCkvXhCx6yx2kYlS8+4j3mr9+X/deKGGAJRNAol3Ta4AtZOUhXyEoM6Ai4iljyx HNqzEKOtODQ1J70hT4X5haYunZBYDrWWvZ/a7E1RG8k9o8Z9O1b/NlJaNnfdidXdz5eZ UHqY06ncBX0vmCW5bjS9zE6DNraXi7kxJpoC8uCpPxain8mFuN77ahT+TqC4R6T9xkpg q/e/+VfwzE0TsVQz1L4JwyJNcfQkCjXUdBVr7LvGMwdXR8n7oRW+JM1F0M5fNH6i2+9d tQOtsHCLdyGX9jXDCTZQX61OhGgq8ravCIxzeNM9dVsoUcJU+iE/1wlELcdzZLJL98cB dNCw==
X-Gm-Message-State: ALoCoQnem4Dfo4U+DWAm9SbfLnjLVTcuJ1k6Q62GSsTzFcJQla6SiUz8j02uaWxKu10+0g0lcXCp
X-Received: by 10.55.33.158 with SMTP id f30mr50009091qki.104.1432650432942; Tue, 26 May 2015 07:27:12 -0700 (PDT)
Received: from [10.0.2.133] (c-69-247-98-164.hsd1.pa.comcast.net. [69.247.98.164]) by mx.google.com with ESMTPSA id x66sm4149940qha.8.2015.05.26.07.27.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 May 2015 07:27:11 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADDAFB98-9576-40C8-9401-2B4D300EFC6F"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Chris Wendt 
In-Reply-To: <5563D8AB.5090407@usdonovans.com>
Date: Tue, 26 May 2015 10:26:54 -0400
Message-Id: <7C3520CB-016D-4030-96E7-67A0FF504EA9@chriswendt.net>
References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <12180B6D-426A-49DA-9D65-FAC676587E8D@standardstrack.com> <5563D8AB.5090407@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: modern@ietf.org
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 14:27:18 -0000

--Apple-Mail=_ADDAFB98-9576-40C8-9401-2B4D300EFC6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I=92d like to reiterate my higher level struggle with this, to add a bit =
to Eric=92s more policy oriented questions.

To me, provisioning interfaces are dime a dozen.

To the new world providers that are looking at this new telecom =
environment where there are private numbers and we have a nice easy to =
use provisioning interface (assuming policy allows) the preference would =
be something that would be a few weeks work to integrate a number =
provisioning interface.  Much in the same style you would integrate =
Facebook or twitter interfaces for auth, etc.

To a traditional telecom service provider, they would likely look at =
this world as pain and headache, but that=92s the world we live in =
currently, hopefully that is slowly changing for the better.

Correlating the concepts of =93easy to use provisioning for new web =
oriented service providers=94 and building a new set of IETF protocols =
for provisioning does not compute in my head.

Ask any typical web oriented application provider, would they want to =
use DNS style protocols in their web applications to provision numbers =
for their customer??  Absolutely not, most would request an HTTP based =
interface.

So, i feel like there is a convoluted discussion going on that placates =
both new and old worlds with the opposite arguments.

If the policy side allows, the representatives of whatever private =
numbering space folks want to conform to should just build a simple =
straight forward RESTful interface to allow for number provisioning and =
call it a day.  I see no reason why this isn=92t a completely valid =
easily adoptable path for all parties for private numbering. =20

This would support adaptation between a number of worlds quite easily as =
well:
You could easily support multiple public and private numbering spaces =
within a single customer facing service and a new world begins, happy =
days.
This could be a business or product opportuntity that easily adapts new =
and old worlds with interface adaptors from and to old world =
provisioning systems.
Eventually, old world provisioning systems could be scrapped and =
overhauled into the new world.

To me, trying to do anything beyond the keep-it-simple approach is =
almost a guarantee for a repeat of history for these efforts.  Primarily =
because it=92s the most painful for everyone option, new world has to =
use protocols they aren=92t used to, old world needs to adapt protocols =
anyway.

-Chris

Comcast


> On May 25, 2015, at 10:21 PM, Steve Donovan  =
wrote:
>=20
> Private number spaces cannot be part of the publicly managed numbers.  =
They can and generally are mapped to public numbers but that is very =
different from me declaring that "+1 214 555 0000" is a private number.  =
Private numbers only work in the context of devices used in the "domain" =
that is administering the private number space.
>=20
> I thought I had already said that private numbers are not a part of =
E.164.  They are, however, still TNs by the definition currently in the =
charter: "TNs, as defined in RFC3966, and blocks of TNs, that are used =
to initiate communication with another user of a service. "
>=20
> Steve
>=20
> On 5/25/15 10:52 AM, Eric Burger wrote:
>> Now I am confused.
>>=20
>> I was thinking we are building something more complex than just a =
registry of strings of digits to services and maybe routing. IANA (and a =
host of others) can do that today.
>>=20
>> I thought the thing that needed solving, which Henning described at =
the BOF, was a how to provision and interface with a registry that maps =
strings of digits to services and maybe routing, where there was a clear =
need for some sort of (outside of scope) policy that needs to be =
enforced.
>>=20
>> Am I wrong in thinking the entire point of MODERN is the mechanisms =
for policy enforcement?
>>=20
>> By policy enforcement, I mean that, depending on jurisdiction, =
policies may be that only the national numbering authority can delegate =
the authority to allocate numbers to registered service providers. Or, a =
policy may be that only the national numbering authority can allocate =
numbers to users. Or, a policy may be that only the user can assign =
which services or service providers are allowed to service the number. =
What the policies are is out of scope for the work group. However, that =
there are policies I was under the impression is the whole point of the =
work group.
>>=20
>> I am very leery of a policy that says that some part of the name =
space lives with the ITU-T and national numbering authorities, but =
another part of the name space is a free-for-all. What is to stop me =
from declaring =93+1 214-555-1000=94 to be just a private number?
>>=20
>> If the proposal is that private numbers are not in the numbering =
(E.164? TN?) name space, then say so. Then Keith=92s question becomes =
relevant: what is the use case? Cullen, is this in the Cisco world? =
Steven, is this in the Oracle world?
>>=20
>> Thanks,
>> Eric
>>=20
>>=20
>>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) =
> =
wrote:
>>>=20
>>> Adding in private numbers introduces all sorts of complications.
>>> =20
>>> In many cases there is a mapping between E.164 numbers and private =
numbers, i.e. the allocation by the public administration of an E.164 =
number automatically generates a valid private number, and vice versa. =
In other cases there could be no such mapping. When you apply the above =
to international private networks, with DDI ranges in multiple countries =
belonging to the same private network, it gets even more complicated.
>>> =20
>>> There are other complications resulting from the joint ownership of =
some companies, resulting in an owned companies network forming part of =
the private numbering plan of both parent companies.
>>> =20
>>> Unless there is a proven use case from deployers of private =
networks, I strongly propose that we should avoid these cases =
altogether.
>>> =20
>>> I'd note by the way that I have not been pushing for global =
uniqueness, only against the assumption that the numbering plans are not =
locally unique to the particular administration. I believe we should =
assume local uniqueness, but that does not presuppose global uniqueness.
>>> =20
>>> regards
>>> =20
>>> Keith
>>> =20
>>> =20
>>>=20
>>> From: Modern [mailto:modern-bounces@ietf.org =
] On Behalf Of Steve Donovan
>>> Sent: 20 May 2015 15:31
>>> To: modern@ietf.org 
>>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>>=20
>>> Eric,
>>>=20
>>> I'm not comfortable with saying that MODERN  is ONLY about managing =
globally unique identifiers as this rules out private numbering plans =
put in place by enterprises.=20
>>>=20
>>> Yes, MODERN is about globally unique identifiers that have the =
format of a telephone number, but it is also about private identifiers =
that also have the format of a telephone number.
>>>=20
>>> Regards,
>>>=20
>>> Steve
>>>=20
>>> On 5/18/15 5:23 PM, Eric Burger wrote:
>>>> Something I have been mulling about is the focus (and amount of =
list traffic) discussing whether the scope of MODERN is E.164 numbers, =
=93telephone numbers,=94 or something else.
>>>>=20
>>>> We seem to get very emotional about E.164 numbers. Perhaps rightly =
so. An E.164 number carries a lot of a=92priori regulatory baggage. By =
definition, the ITU-T assigns country codes. National numbering =
authorities allocate numbers to service providers. Service providers =
manage them for users.
>>>>=20
>>>> A =93telephone number=94 spawns the debate as to whether it is, in =
fact, a =91telephone=92 number. Given Henning=92s presentation, the =
value of the telephone number is global routing and global understanding =
for 5/7ths of the world using romanized arabic script. Given that, the =
people who worry that =93telephone number=94 is just a code word for =
E.164 number are most likely correct. This spills into the whole =93It =
is not an E.164 number, it is the ABNF for an E.164 number (see =
RFC3966).=94 I.e., it looks, smells, and tastes like a rose.
>>>>=20
>>>> Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/modern =

>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/modern =

>>=20
>>=20
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org 
>> https://www.ietf.org/mailman/listinfo/modern =

>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


--Apple-Mail=_ADDAFB98-9576-40C8-9401-2B4D300EFC6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I=92d like to reiterate my higher level struggle with this, =
to add a bit to Eric=92s more policy oriented questions.

To me, provisioning =
interfaces are dime a dozen.

To the new world providers that are =
looking at this new telecom environment where there are private numbers =
and we have a nice easy to use provisioning interface (assuming policy =
allows) the preference would be something that would be a few weeks work =
to integrate a number provisioning interface.  Much in the same =
style you would integrate Facebook or twitter interfaces for auth, =
etc.

To a =
traditional telecom service provider, they would likely look at this =
world as pain and headache, but that=92s the world we live in currently, =
hopefully that is slowly changing for the better.
Correlating the concepts of =93easy to =
use provisioning for new web oriented service providers=94 and building =
a new set of IETF protocols for provisioning does not compute in my =
head.

Ask any =
typical web oriented application provider, would they want to use DNS =
style protocols in their web applications to provision numbers for their =
customer??  Absolutely not, most would request an HTTP based =
interface.

So, =
i feel like there is a convoluted discussion going on that placates both =
new and old worlds with the opposite arguments.

If the policy side allows, the =
representatives of whatever private numbering space folks want to =
conform to should just build a simple straight forward RESTful interface =
to allow for number provisioning and call it a day.  I see no =
reason why this isn=92t a completely valid easily adoptable path for all =
parties for private numbering.  

This would support adaptation between a =
number of worlds quite easily as well:
You could =
easily support multiple public and private numbering spaces within a =
single customer facing service and a new world begins, happy =
days.
This could be a business or product =
opportuntity that easily adapts new and old worlds with interface =
adaptors from and to old world provisioning systems.
Eventually, old world provisioning systems could be scrapped =
and overhauled into the new world.

To me, trying to do anything beyond the =
keep-it-simple approach is almost a guarantee for a repeat of history =
for these efforts.  Primarily because it=92s the most painful for =
everyone option, new world has to use protocols they aren=92t used to, =
old world needs to adapt protocols anyway.

-Chris

Comcast


On May 25, 2015, at 10:21 PM, =
Steve Donovan <srdonovan@usdonovans.com> wrote:


 =20
    
 =20
  

    Private number spaces cannot be part of the publicly managed
    numbers.  They can and generally are mapped to public numbers =
but
    that is very different from me declaring that "+1 214 555 0000" is a
    private number.  Private numbers only work in the context of =
devices
    used in the "domain" that is administering the private number =
space.

    

    I thought I had already said that private numbers are not a part of
    E.164.  They are, however, still TNs by the definition =
currently in
    the charter: "TNs, as defined in RFC3966, and blocks of TNs, that
    are used to initiate communication with another user of a service. =
"

    

    Steve

    

    
On 5/25/15 10:52 AM, Eric Burger =
wrote:

    

    

      
      
Now I am confused.

      


      

      
I was thinking we are building something more
        complex than just a registry of strings of digits to services
        and maybe routing. IANA (and a host of others) can do that
        today.

      


      

      
I thought the thing that needed solving, which
        Henning described at the BOF, was a how to provision and
        interface with a registry that maps strings of digits to
        services and maybe routing, where there was a =
clear
          need for some sort of (outside of scope) policy that needs to
          be enforced.

      


        

      
Am I wrong in thinking the entire point of MODERN =
is
        the mechanisms for policy enforcement?

      


      

      
By policy enforcement, I mean that, depending on
        jurisdiction, policies may be that only the national numbering
        authority can delegate the authority to allocate numbers to
        registered service providers. Or, a policy may be that only the
        national numbering authority can allocate numbers to users. Or,
        a policy may be that only the user can assign which services or
        service providers are allowed to service the number. What the
        policies are is out of scope for the work group. However, that
        there are policies I was under the impression is the whole point
        of the work group.

      


      

      
I am very leery of a policy that says that some =
part
        of the name space lives with the ITU-T and national numbering
        authorities, but another part of the name space is a
        free-for-all. What is to stop me from declaring =93+1
        214-555-1000=94 to be just a private number?

      


      

      
If the proposal is that private numbers are not in
        the numbering (E.164? TN?) name space, then say so. Then Keith=92s=

        question becomes relevant: what is the use case? Cullen, is this
        in the Cisco world? Steven, is this in the Oracle world?

      


      

      
Thanks,

      
Eric

      


      

      

      

        

          
On May 24, 2015, at 1:27 AM, DRAGE, Keith
            (Keith) <keith.drage@alcatel-lucent.com>
            wrote:

          

          

            
            
            

              
Adding
                    in private numbers introduces all sorts of
                    complications.

              
 

              
In
                    many cases there is a mapping between E.164 numbers
                    and private numbers, i.e. the allocation by the
                    public administration of an E.164 number
                    automatically generates a valid private number, and
                    vice versa. In other cases there could be no such
                    mapping. When you apply the above to international
                    private networks, with DDI ranges in multiple
                    countries belonging to the same private network, it
                    gets even more complicated.
                  

              
 

              
There
                    are other complications resulting from the joint
                    ownership of some companies, resulting in an owned
                    companies network forming part of the private
                    numbering plan of both parent =
companies.

              
 

              
Unless
                    there is a proven use case from deployers of private
                    networks, I strongly propose that we should avoid
                    these cases altogether.

              
 

              
I'd
                    note by the way that I have not been pushing for
                    global uniqueness, only against the assumption that
                    the numbering plans are not locally unique to the
                    particular administration. I believe we should
                    assume local uniqueness, but that does not
                    presuppose global uniqueness.

              
 

              
regards

              
 

              
Keith

              
 

              
 

              

              

                

                  

                  From:
                    Modern [mailto:modern-bounces@ietf.org]
                    On Behalf Of Steve Donovan

                    Sent: 20 May 2015 15:31

                    To: modern@ietf.org

                    Subject: Re: [Modern] TN, E.164, =
or
                    Something Else?

                  

                

                Eric,

                

                I'm not comfortable with saying that MODERN  is =
ONLY
                about managing globally unique identifiers as this rules
                out private numbering plans put in place by enterprises.
                

                

                Yes, MODERN is about globally unique identifiers that
                have the format of a telephone number, but it is also
                about private identifiers that also have the format of a
                telephone number.

                

                Regards,

                

                Steve

                

                
On 5/18/15 5:23 PM, Eric
                  Burger wrote:

                

                

                  
Something I have been =
mulling about is the focus (and amount of list traffic) discussing =
whether the scope of MODERN is E.164 numbers, =93telephone numbers,=94 =
or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. =
An E.164 number carries a lot of a=92priori regulatory baggage. By =
definition, the ITU-T assigns country codes. National numbering =
authorities allocate numbers to service providers. Service providers =
manage them for users.

A =93telephone number=94 spawns the debate as to whether it is, in fact, =
a =91telephone=92 number. Given Henning=92s presentation, the value of =
the telephone number is global routing and global understanding for =
5/7ths of the world using romanized arabic script. Given that, the =
people who worry that =93telephone number=94 is just a code word for =
E.164 number are most likely correct. This spills into the whole =93It =
is not an E.164 number, it is the ABNF for an E.164 number (see =
RFC3966).=94 I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.


                  

                  

                  

                  
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org=
/mailman/listinfo/modern


                

                

              

            

            _______________________________________________
=

            Modern mailing list

            Modern@ietf.org

            https://www.ietf.org=
/mailman/listinfo/modern

          

        

      

      

      

      

      

      
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org=
/mailman/listinfo/modern


    

    

  


_______________________________________________
Modern =
mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

=

--Apple-Mail=_ADDAFB98-9576-40C8-9401-2B4D300EFC6F--


From nobody Tue May 26 08:20:13 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 2E4C71A89F2 for ; Tue, 26 May 2015 08:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.277
X-Spam-Level: 
X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 QLBjhr0yaGKE for ; Tue, 26 May 2015 08:20:04 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 017291A89F6 for ; Tue, 26 May 2015 08:19:33 -0700 (PDT)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t4QFJXuh005147 for ; Tue, 26 May 2015 11:19:33 -0400
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1umg4m0pmt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 May 2015 11:19:32 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 26 May 2015 11:19:31 -0400
From: "McGarry, Tom" 
To: "modern@ietf.org" 
Thread-Topic: [Modern] TN, E.164, or Something Else?
Thread-Index: AQHQkblMm58SJXXENkeFQAPg43E2IJ2FMtWAgAWxd4CAAkDIAIAAr+KAgADKrAD//8uiAA==
Date: Tue, 26 May 2015 15:19:30 +0000
Message-ID: 
In-Reply-To: <7C3520CB-016D-4030-96E7-67A0FF504EA9@chriswendt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [192.168.132.15]
Content-Type: multipart/alternative; boundary="_000_D18A071325A0Ftommcgarryneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-05-26_02:2015-05-26,2015-05-26,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.12719039657705e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999691671959393 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.999691671959393 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.999691671959393 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505260198
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 15:20:08 -0000

--_000_D18A071325A0Ftommcgarryneustarbiz_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Why do you think that the WG wouldn't "keep it simple"?

From: Chris Wendt >
Date: Tuesday, May 26, 2015 10:26 AM
To: Steve Donovan >
Cc: Modern List >
Subject: Re: [Modern] TN, E.164, or Something Else?

I=92d like to reiterate my higher level struggle with this, to add a bit to=
 Eric=92s more policy oriented questions.

To me, provisioning interfaces are dime a dozen.

To the new world providers that are looking at this new telecom environment=
 where there are private numbers and we have a nice easy to use provisionin=
g interface (assuming policy allows) the preference would be something that=
 would be a few weeks work to integrate a number provisioning interface.  M=
uch in the same style you would integrate Facebook or twitter interfaces fo=
r auth, etc.

To a traditional telecom service provider, they would likely look at this w=
orld as pain and headache, but that=92s the world we live in currently, hop=
efully that is slowly changing for the better.

Correlating the concepts of =93easy to use provisioning for new web oriente=
d service providers=94 and building a new set of IETF protocols for provisi=
oning does not compute in my head.

Ask any typical web oriented application provider, would they want to use D=
NS style protocols in their web applications to provision numbers for their=
 customer??  Absolutely not, most would request an HTTP based interface.

So, i feel like there is a convoluted discussion going on that placates bot=
h new and old worlds with the opposite arguments.

If the policy side allows, the representatives of whatever private numberin=
g space folks want to conform to should just build a simple straight forwar=
d RESTful interface to allow for number provisioning and call it a day.  I =
see no reason why this isn=92t a completely valid easily adoptable path for=
 all parties for private numbering.

This would support adaptation between a number of worlds quite easily as we=
ll:
You could easily support multiple public and private numbering spaces withi=
n a single customer facing service and a new world begins, happy days.
This could be a business or product opportuntity that easily adapts new and=
 old worlds with interface adaptors from and to old world provisioning syst=
ems.
Eventually, old world provisioning systems could be scrapped and overhauled=
 into the new world.

To me, trying to do anything beyond the keep-it-simple approach is almost a=
 guarantee for a repeat of history for these efforts.  Primarily because it=
=92s the most painful for everyone option, new world has to use protocols t=
hey aren=92t used to, old world needs to adapt protocols anyway.

-Chris

Comcast


On May 25, 2015, at 10:21 PM, Steve Donovan > wrote:

Private number spaces cannot be part of the publicly managed numbers.  They=
 can and generally are mapped to public numbers but that is very different =
from me declaring that "+1 214 555 0000" is a private number.  Private numb=
ers only work in the context of devices used in the "domain" that is admini=
stering the private number space.

I thought I had already said that private numbers are not a part of E.164. =
 They are, however, still TNs by the definition currently in the charter: "=
TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate co=
mmunication with another user of a service. "

Steve

On 5/25/15 10:52 AM, Eric Burger wrote:
Now I am confused.

I was thinking we are building something more complex than just a registry =
of strings of digits to services and maybe routing. IANA (and a host of oth=
ers) can do that today.

I thought the thing that needed solving, which Henning described at the BOF=
, was a how to provision and interface with a registry that maps strings of=
 digits to services and maybe routing, where there was a clear need for som=
e sort of (outside of scope) policy that needs to be enforced.

Am I wrong in thinking the entire point of MODERN is the mechanisms for pol=
icy enforcement?

By policy enforcement, I mean that, depending on jurisdiction, policies may=
 be that only the national numbering authority can delegate the authority t=
o allocate numbers to registered service providers. Or, a policy may be tha=
t only the national numbering authority can allocate numbers to users. Or, =
a policy may be that only the user can assign which services or service pro=
viders are allowed to service the number. What the policies are is out of s=
cope for the work group. However, that there are policies I was under the i=
mpression is the whole point of the work group.

I am very leery of a policy that says that some part of the name space live=
s with the ITU-T and national numbering authorities, but another part of th=
e name space is a free-for-all. What is to stop me from declaring =93+1 214=
-555-1000=94 to be just a private number?

If the proposal is that private numbers are not in the numbering (E.164? TN=
?) name space, then say so. Then Keith=92s question becomes relevant: what =
is the use case? Cullen, is this in the Cisco world? Steven, is this in the=
 Oracle world?

Thanks,
Eric


On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) > wrote:

Adding in private numbers introduces all sorts of complications.

In many cases there is a mapping between E.164 numbers and private numbers,=
 i.e. the allocation by the public administration of an E.164 number automa=
tically generates a valid private number, and vice versa. In other cases th=
ere could be no such mapping. When you apply the above to international pri=
vate networks, with DDI ranges in multiple countries belonging to the same =
private network, it gets even more complicated.

There are other complications resulting from the joint ownership of some co=
mpanies, resulting in an owned companies network forming part of the privat=
e numbering plan of both parent companies.

Unless there is a proven use case from deployers of private networks, I str=
ongly propose that we should avoid these cases altogether.

I'd note by the way that I have not been pushing for global uniqueness, onl=
y against the assumption that the numbering plans are not locally unique to=
 the particular administration. I believe we should assume local uniqueness=
, but that does not presuppose global uniqueness.

regards

Keith



________________________________
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: 20 May 2015 15:31
To: modern@ietf.org
Subject: Re: [Modern] TN, E.164, or Something Else?

Eric,

I'm not comfortable with saying that MODERN  is ONLY about managing globall=
y unique identifiers as this rules out private numbering plans put in place=
 by enterprises.

Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.

Regards,

Steve

On 5/18/15 5:23 PM, Eric Burger wrote:

Something I have been mulling about is the focus (and amount of list traffi=
c) discussing whether the scope of MODERN is E.164 numbers, =93telephone nu=
mbers,=94 or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a=92priori regulatory baggage. By definition, =
the ITU-T assigns country codes. National numbering authorities allocate nu=
mbers to service providers. Service providers manage them for users.

A =93telephone number=94 spawns the debate as to whether it is, in fact, a =
=91telephone=92 number. Given Henning=92s presentation, the value of the te=
lephone number is global routing and global understanding for 5/7ths of the=
 world using romanized arabic script. Given that, the people who worry that=
 =93telephone number=94 is just a code word for E.164 number are most likel=
y correct. This spills into the whole =93It is not an E.164 number, it is t=
he ABNF for an E.164 number (see RFC3966).=94 I.e., it looks, smells, and t=
astes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.




_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinf=
o/modern

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern




_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinf=
o/modern

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


--_000_D18A071325A0Ftommcgarryneustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <71DA4FEBEC14BF4AB4AD6334D26D1EEE@neustar.biz>
Content-Transfer-Encoding: quoted-printable







Why do you think that the WG wouldn't "keep it simple"? &nbs=
p;









From: Chris Wendt <chris-ietf@chriswendt.net>

Date: Tuesday, May 26, 2015 10:26 A=
M

To: Steve Donovan <srdonovan@usdonovans.com>

Cc: Modern List <modern@ietf.org>

Subject: Re: [Modern] TN, E.164, or=
 Something Else?












I=92d like to reiterate my higher level struggle with this, to add a bit to=
 Eric=92s more policy oriented questions.






To me, provisioning interfaces are dime a dozen.







To the new world providers that are looking at this new tel=
ecom environment where there are private numbers and we have a nice easy to=
 use provisioning interface (assuming policy allows) the preference would b=
e something that would be a few weeks
 work to integrate a number provisioning interface.  Much in the same =
style you would integrate Facebook or twitter interfaces for auth, etc.






To a traditional telecom service provider, they would likel=
y look at this world as pain and headache, but that=92s the world we live i=
n currently, hopefully that is slowly changing for the better.







Correlating the concepts of =93easy to use provisioning for=
 new web oriented service providers=94 and building a new set of IETF proto=
cols for provisioning does not compute in my head.







Ask any typical web oriented application provider, would th=
ey want to use DNS style protocols in their web applications to provision n=
umbers for their customer??  Absolutely not, most would request an HTT=
P based interface.







So, i feel like there is a convoluted discussion going on t=
hat placates both new and old worlds with the opposite arguments.







If the policy side allows, the representatives of whatever =
private numbering space folks want to conform to should just build a simple=
 straight forward RESTful interface to allow for number provisioning and ca=
ll it a day.  I see no reason why
 this isn=92t a completely valid easily adoptable path for all parties for =
private numbering.  







This would support adaptation between a number of worlds qu=
ite easily as well:


You could easily support multiple public and private number=
ing spaces within a single customer facing service and a new world begins, =
happy days.


This could be a business or product opportuntity that easil=
y adapts new and old worlds with interface adaptors from and to old world p=
rovisioning systems.


Eventually, old world provisioning systems could be scrappe=
d and overhauled into the new world.







To me, trying to do anything beyond the keep-it-simple appr=
oach is almost a guarantee for a repeat of history for these efforts.  =
;Primarily because it=92s the most painful for everyone option, new world h=
as to use protocols they aren=92t used to,
 old world needs to adapt protocols anyway.







-Chris







Comcast














On May 25, 2015, at 10:21 PM, Steve Donovan <srdonovan@usdonovans.com>=
; wrote:






Private number spaces =
cannot be part of the publicly managed numbers.  They can and generall=
y are mapped to public numbers but that is very different from me declaring=
 that "+1 214 555 0000" is a private number. 
 Private numbers only work in the context of devices used in the "doma=
in" that is administering the private number space.



I thought I had already said that private numbers are not a part of E.164.&=
nbsp; They are, however, still TNs by the definition currently in the chart=
er: "TNs, as defined in RFC3966, and blocks of TNs, that are used to i=
nitiate communication with another user of
 a service. "



Steve




On 5/25/15 10:52 AM, Eric Burger wrote:






Now I am confused.







I was thinking we are building something more complex than =
just a registry of strings of digits to services and maybe routing. IANA (a=
nd a host of others) can do that today.







I thought the thing that needed solving, which Henning desc=
ribed at the BOF, was a how to provision and interface with a registry that=
 maps strings of digits to services and maybe routing,
where there was a clear need for some sort of (outside of sco=
pe) policy that needs to be enforced.







Am I wrong in thinking the entire point of MODERN is the me=
chanisms for policy enforcement?







By policy enforcement, I mean that, depending on jurisdicti=
on, policies may be that only the national numbering authority can delegate=
 the authority to allocate numbers to registered service providers. Or, a p=
olicy may be that only the national
 numbering authority can allocate numbers to users. Or, a policy may be tha=
t only the user can assign which services or service providers are allowed =
to service the number. What the policies are is out of scope for the work g=
roup. However, that there are policies
 I was under the impression is the whole point of the work group.







I am very leery of a policy that says that some part of the=
 name space lives with the ITU-T and national numbering authorities, but an=
other part of the name space is a free-for-all. What is to stop me from dec=
laring =93+1 214-555-1000=94 to be just
 a private number?







If the proposal is that private numbers are not in the numb=
ering (E.164? TN?) name space, then say so. Then Keith=92s question becomes=
 relevant: what is the use case? Cullen, is this in the Cisco world? Steven=
, is this in the Oracle world?







Thanks,


Eric













On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:









Adding in private numbers introduces=
 all sorts of complications.


 


In many cases there is a mapping bet=
ween E.164 numbers and private numbers, i.e. the allocation by the public a=
dministration of an E.164 number automatically
 generates a valid private number, and vice versa. In other cases there cou=
ld be no such mapping. When you apply the above to international private ne=
tworks, with DDI ranges in multiple countries belonging to the same private=
 network, it gets even more complicated.



 


There are other complications result=
ing from the joint ownership of some companies, resulting in an owned compa=
nies network forming part of the private numbering
 plan of both parent companies.


 


Unless there is a proven use case fr=
om deployers of private networks, I strongly propose that we should avoid t=
hese cases altogether.


 


I'd note by the way that I have not =
been pushing for global uniqueness, only against the assumption that the nu=
mbering plans are not locally unique to the particular
 administration. I believe we should assume local uniqueness, but that does=
 not presuppose global uniqueness.


 


regards


 


Keith


 


 









From: Modern =
[mailto:modern-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: 20 May 2015 15:31

To: 
modern@ietf.org

Subject: Re: [Modern] TN, E.164, or Something Else?





Eric,



I'm not comfortable with saying that MODERN  is ONLY about managing gl=
obally unique identifiers as this rules out private numbering plans put in =
place by enterprises.




Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.



Regards,



Steve




On 5/18/15 5:23 PM, Eric Burger wrote:






Something I have been mulling about is the focus =
(and amount of list traffic) discussing whether the scope of MODERN is E.16=
4 numbers, =93telephone numbers,=94 or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a=92priori regulatory baggage. By definition, =
the ITU-T assigns country codes. National numbering authorities allocate nu=
mbers to service providers. Service providers manage them for users.

A =93telephone number=94 spawns the debate as to whether it is, in fact, a =
=91telephone=92 number. Given Henning=92s presentation, the value of the te=
lephone number is global routing and global understanding for 5/7ths of the=
 world using romanized arabic script. Given that, the people who worry that=
 =93telephone number=94 is just a code word for E.164 number are most likel=
y correct. This spills into the whole =93It is not an E.164 number, it is t=
he ABNF for an E.164 number (see RFC3966).=94 I.e., it looks, smells, and t=
astes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.





 


_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinfo/=
modern









_______________________________________________

Modern mailing list

Mode=
rn@ietf.org

https://www.ietf.org/mailman=
/listinfo/modern












 


_______________________________________________
Modern mailing list
Moder=
n@ietf.orghttps://www.ie=
tf.org/mailman/listinfo/modern







_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.o=
rg/mailman/listinfo/modern



















--_000_D18A071325A0Ftommcgarryneustarbiz_--


From nobody Tue May 26 11:36:22 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 08D2F1B2FD6 for ; Tue, 26 May 2015 11:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.61
X-Spam-Level: 
X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] 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 yZvp0CsYht3m for ; Tue, 26 May 2015 11:36:17 -0700 (PDT)
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4AA1B2F63 for ; Tue, 26 May 2015 11:36:17 -0700 (PDT)
Received: by qgf2 with SMTP id 2so34676907qgf.3 for ; Tue, 26 May 2015 11:36:16 -0700 (PDT)
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=gZmCutnC/6pjoWm0sk+CZl8zNgHwoOmXee3AASVeHYk=; b=SIZYGeOlu9/70/ppZH0UK2O4+cOn+aDq2ZYuMcUSmXUrGkFD5Jv4N2qabB6H4ByeMJ oRq/F4MowtfJuvR3iHwLUvof/+HawABVNAIyXYZS7Gzn5gEmSWlFtTL5+XN6AM0dVd/o 44MzvY2+d2F2J/2yMEcFQiF8QO7jc1AzBf1lbGBlUIJZBdMnvaUe9bzteU8mEmpRG+M6 tO7W7SKgOWqKpaub3isYQEtAU5qi4/oOguVhShh6ZmPf1ky9q8RPqISzVyGkCkw9FbhQ 0/LVkECgDRZUsZrKoJqccDF6bj/uj/UowOZaxZcN+IrFRzqIuebpU/bZ4773S3LqgT+M KpGw==
X-Gm-Message-State: ALoCoQnQEp3FsoKk/ZlWFuNjYNtLUykc+TLjkEqT9sl4wd118Np3yXCHigrPhMqwoyNlov/KscbD
X-Received: by 10.140.144.67 with SMTP id 64mr36951126qhq.40.1432665376582; Tue, 26 May 2015 11:36:16 -0700 (PDT)
Received: from [10.0.2.133] (c-69-247-98-164.hsd1.pa.comcast.net. [69.247.98.164]) by mx.google.com with ESMTPSA id 188sm8988195qhh.48.2015.05.26.11.36.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 May 2015 11:36:15 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7C59BCC1-DAA0-4245-B499-DC1A9C3FB186"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Chris Wendt 
In-Reply-To: 
Date: Tue, 26 May 2015 14:36:19 -0400
Message-Id: <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net>
References: 
To: "McGarry, Tom" 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 18:36:22 -0000

--Apple-Mail=_7C59BCC1-DAA0-4245-B499-DC1A9C3FB186
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Has the conversation to date provided any indication of this? =20

Is the IETF in the business of defining RESTful or web service =
interfaces?

=93Simple" is in the eye of the beholder of course.


> On May 26, 2015, at 11:19 AM, McGarry, Tom  =
wrote:
>=20
> Why do you think that the WG wouldn't "keep it simple"? =20
>=20
> From: Chris Wendt >
> Date: Tuesday, May 26, 2015 10:26 AM
> To: Steve Donovan >
> Cc: Modern List >
> Subject: Re: [Modern] TN, E.164, or Something Else?
>=20
> I=92d like to reiterate my higher level struggle with this, to add a =
bit to Eric=92s more policy oriented questions.
>=20
> To me, provisioning interfaces are dime a dozen.
>=20
> To the new world providers that are looking at this new telecom =
environment where there are private numbers and we have a nice easy to =
use provisioning interface (assuming policy allows) the preference would =
be something that would be a few weeks work to integrate a number =
provisioning interface.  Much in the same style you would integrate =
Facebook or twitter interfaces for auth, etc.
>=20
> To a traditional telecom service provider, they would likely look at =
this world as pain and headache, but that=92s the world we live in =
currently, hopefully that is slowly changing for the better.
>=20
> Correlating the concepts of =93easy to use provisioning for new web =
oriented service providers=94 and building a new set of IETF protocols =
for provisioning does not compute in my head.
>=20
> Ask any typical web oriented application provider, would they want to =
use DNS style protocols in their web applications to provision numbers =
for their customer??  Absolutely not, most would request an HTTP based =
interface.
>=20
> So, i feel like there is a convoluted discussion going on that =
placates both new and old worlds with the opposite arguments.
>=20
> If the policy side allows, the representatives of whatever private =
numbering space folks want to conform to should just build a simple =
straight forward RESTful interface to allow for number provisioning and =
call it a day.  I see no reason why this isn=92t a completely valid =
easily adoptable path for all parties for private numbering. =20
>=20
> This would support adaptation between a number of worlds quite easily =
as well:
> You could easily support multiple public and private numbering spaces =
within a single customer facing service and a new world begins, happy =
days.
> This could be a business or product opportuntity that easily adapts =
new and old worlds with interface adaptors from and to old world =
provisioning systems.
> Eventually, old world provisioning systems could be scrapped and =
overhauled into the new world.
>=20
> To me, trying to do anything beyond the keep-it-simple approach is =
almost a guarantee for a repeat of history for these efforts.  Primarily =
because it=92s the most painful for everyone option, new world has to =
use protocols they aren=92t used to, old world needs to adapt protocols =
anyway.
>=20
> -Chris
>=20
> Comcast
>=20
>=20
>> On May 25, 2015, at 10:21 PM, Steve Donovan > wrote:
>>=20
>> Private number spaces cannot be part of the publicly managed numbers. =
 They can and generally are mapped to public numbers but that is very =
different from me declaring that "+1 214 555 0000" is a private number.  =
Private numbers only work in the context of devices used in the "domain" =
that is administering the private number space.
>>=20
>> I thought I had already said that private numbers are not a part of =
E.164.  They are, however, still TNs by the definition currently in the =
charter: "TNs, as defined in RFC3966, and blocks of TNs, that are used =
to initiate communication with another user of a service. "
>>=20
>> Steve
>>=20
>> On 5/25/15 10:52 AM, Eric Burger wrote:
>>> Now I am confused.
>>>=20
>>> I was thinking we are building something more complex than just a =
registry of strings of digits to services and maybe routing. IANA (and a =
host of others) can do that today.
>>>=20
>>> I thought the thing that needed solving, which Henning described at =
the BOF, was a how to provision and interface with a registry that maps =
strings of digits to services and maybe routing, where there was a clear =
need for some sort of (outside of scope) policy that needs to be =
enforced.
>>>=20
>>> Am I wrong in thinking the entire point of MODERN is the mechanisms =
for policy enforcement?
>>>=20
>>> By policy enforcement, I mean that, depending on jurisdiction, =
policies may be that only the national numbering authority can delegate =
the authority to allocate numbers to registered service providers. Or, a =
policy may be that only the national numbering authority can allocate =
numbers to users. Or, a policy may be that only the user can assign =
which services or service providers are allowed to service the number. =
What the policies are is out of scope for the work group. However, that =
there are policies I was under the impression is the whole point of the =
work group.
>>>=20
>>> I am very leery of a policy that says that some part of the name =
space lives with the ITU-T and national numbering authorities, but =
another part of the name space is a free-for-all. What is to stop me =
from declaring =93+1 214-555-1000=94 to be just a private number?
>>>=20
>>> If the proposal is that private numbers are not in the numbering =
(E.164? TN?) name space, then say so. Then Keith=92s question becomes =
relevant: what is the use case? Cullen, is this in the Cisco world? =
Steven, is this in the Oracle world?
>>>=20
>>> Thanks,
>>> Eric
>>>=20
>>>=20
>>>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) =
> =
wrote:
>>>>=20
>>>> Adding in private numbers introduces all sorts of complications.
>>>> =20
>>>> In many cases there is a mapping between E.164 numbers and private =
numbers, i.e. the allocation by the public administration of an E.164 =
number automatically generates a valid private number, and vice versa. =
In other cases there could be no such mapping. When you apply the above =
to international private networks, with DDI ranges in multiple countries =
belonging to the same private network, it gets even more complicated.
>>>> =20
>>>> There are other complications resulting from the joint ownership of =
some companies, resulting in an owned companies network forming part of =
the private numbering plan of both parent companies.
>>>> =20
>>>> Unless there is a proven use case from deployers of private =
networks, I strongly propose that we should avoid these cases =
altogether.
>>>> =20
>>>> I'd note by the way that I have not been pushing for global =
uniqueness, only against the assumption that the numbering plans are not =
locally unique to the particular administration. I believe we should =
assume local uniqueness, but that does not presuppose global uniqueness.
>>>> =20
>>>> regards
>>>> =20
>>>> Keith
>>>> =20
>>>> =20
>>>>=20
>>>>> From: Modern [mailto:modern-bounces@ietf.org =
] On Behalf Of Steve Donovan
>>>>> Sent: 20 May 2015 15:31
>>>>> To: modern@ietf.org 
>>>>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>>>>=20
>>>>> Eric,
>>>>>=20
>>>>> I'm not comfortable with saying that MODERN  is ONLY about =
managing globally unique identifiers as this rules out private numbering =
plans put in place by enterprises.=20
>>>>>=20
>>>>> Yes, MODERN is about globally unique identifiers that have the =
format of a telephone number, but it is also about private identifiers =
that also have the format of a telephone number.
>>>>>=20
>>>>> Regards,
>>>>>=20
>>>>> Steve
>>>>>=20
>>>>> On 5/18/15 5:23 PM, Eric Burger wrote:
>>>>>> Something I have been mulling about is the focus (and amount of =
list traffic) discussing whether the scope of MODERN is E.164 numbers, =
=93telephone numbers,=94 or something else.
>>>>>>=20
>>>>>> We seem to get very emotional about E.164 numbers. Perhaps =
rightly so. An E.164 number carries a lot of a=92priori regulatory =
baggage. By definition, the ITU-T assigns country codes. National =
numbering authorities allocate numbers to service providers. Service =
providers manage them for users.
>>>>>>=20
>>>>>> A =93telephone number=94 spawns the debate as to whether it is, =
in fact, a =91telephone=92 number. Given Henning=92s presentation, the =
value of the telephone number is global routing and global understanding =
for 5/7ths of the world using romanized arabic script. Given that, the =
people who worry that =93telephone number=94 is just a code word for =
E.164 number are most likely correct. This spills into the whole =93It =
is not an E.164 number, it is the ABNF for an E.164 number (see =
RFC3966).=94 I.e., it looks, smells, and tastes like a rose.
>>>>>>=20
>>>>>> Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Modern mailing list
>>>>>> Modern@ietf.org =
https://www.ietf.org/mailman/listinfo/modern =

>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/modern =

>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org =
https://www.ietf.org/mailman/listinfo/modern =

>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org 
>> https://www.ietf.org/mailman/listinfo/modern =

>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


--Apple-Mail=_7C59BCC1-DAA0-4245-B499-DC1A9C3FB186
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Has the conversation to date provided any indication of this? =
 

Is the IETF =
in the business of defining RESTful or web service interfaces?

=93Simple" is in the eye =
of the beholder of course.


On May 26, 2015, at 11:19 AM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:








Why do you think that the WG wouldn't "keep it simple"? =
 









From: Chris Wendt =
<chris-ietf@chriswendt.net>

Date: Tuesday, May =
26, 2015 10:26 AM

To: Steve Donovan =
<srdonovan@usdonovans.com>

Cc: Modern List =
<modern@ietf.org>

Subject: Re: [Modern] =
TN, E.164, or Something Else?












I=92d like to reiterate my higher level struggle with this, to add a bit =
to Eric=92s more policy oriented questions.






To me, provisioning interfaces are dime a dozen.







To the new world providers that are looking at this new =
telecom environment where there are private numbers and we have a nice =
easy to use provisioning interface (assuming policy allows) the =
preference would be something that would be a few weeks
 work to integrate a number provisioning interface.  Much in the =
same style you would integrate Facebook or twitter interfaces for auth, =
etc.







To a traditional telecom service provider, they would =
likely look at this world as pain and headache, but that=92s the world =
we live in currently, hopefully that is slowly changing for the =
better.







Correlating the concepts of =93easy to use provisioning =
for new web oriented service providers=94 and building a new set of IETF =
protocols for provisioning does not compute in my head.







Ask any typical web oriented application provider, would =
they want to use DNS style protocols in their web applications to =
provision numbers for their customer??  Absolutely not, most would =
request an HTTP based interface.







So, i feel like there is a convoluted discussion going =
on that placates both new and old worlds with the opposite =
arguments.







If the policy side allows, the representatives of =
whatever private numbering space folks want to conform to should just =
build a simple straight forward RESTful interface to allow for number =
provisioning and call it a day.  I see no reason why
 this isn=92t a completely valid easily adoptable path for all parties =
for private numbering.  







This would support adaptation between a number of worlds =
quite easily as well:


You could easily support multiple public and private =
numbering spaces within a single customer facing service and a new world =
begins, happy days.


This could be a business or product opportuntity that =
easily adapts new and old worlds with interface adaptors from and to old =
world provisioning systems.


Eventually, old world provisioning systems could be =
scrapped and overhauled into the new world.







To me, trying to do anything beyond the keep-it-simple =
approach is almost a guarantee for a repeat of history for these =
efforts.  Primarily because it=92s the most painful for everyone =
option, new world has to use protocols they aren=92t used to,
 old world needs to adapt protocols anyway.







-Chris







Comcast














On May 25, 2015, at 10:21 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:






Private number =
spaces cannot be part of the publicly managed numbers.  They can =
and generally are mapped to public numbers but that is very different =
from me declaring that "+1 214 555 0000" is a private number. 
 Private numbers only work in the context of devices used in the =
"domain" that is administering the private number space.



I thought I had already said that private numbers are not a part of =
E.164.  They are, however, still TNs by the definition currently in =
the charter: "TNs, as defined in RFC3966, and blocks of TNs, that are =
used to initiate communication with another user of
 a service. "



Steve




On 5/25/15 10:52 AM, Eric Burger =
wrote:






Now I am confused.







I was thinking we are building something more complex =
than just a registry of strings of digits to services and maybe routing. =
IANA (and a host of others) can do that today.







I thought the thing that needed solving, which Henning =
described at the BOF, was a how to provision and interface with a =
registry that maps strings of digits to services and maybe routing,
where there was a clear need for some sort of (outside of =
scope) policy that needs to be enforced.







Am I wrong in thinking the entire point of MODERN is the =
mechanisms for policy enforcement?







By policy enforcement, I mean that, depending on =
jurisdiction, policies may be that only the national numbering authority =
can delegate the authority to allocate numbers to registered service =
providers. Or, a policy may be that only the national
 numbering authority can allocate numbers to users. Or, a policy may be =
that only the user can assign which services or service providers are =
allowed to service the number. What the policies are is out of scope for =
the work group. However, that there are policies
 I was under the impression is the whole point of the work group.







I am very leery of a policy that says that some part of =
the name space lives with the ITU-T and national numbering authorities, =
but another part of the name space is a free-for-all. What is to stop me =
from declaring =93+1 214-555-1000=94 to be just
 a private number?







If the proposal is that private numbers are not in the =
numbering (E.164? TN?) name space, then say so. Then Keith=92s question =
becomes relevant: what is the use case? Cullen, is this in the Cisco =
world? Steven, is this in the Oracle world?







Thanks,


Eric













On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:









Adding in private numbers =
introduces all sorts of complications.


 


In many cases there is a =
mapping between E.164 numbers and private numbers, i.e. the allocation =
by the public administration of an E.164 number automatically
 generates a valid private number, and vice versa. In other cases there =
could be no such mapping. When you apply the above to international =
private networks, with DDI ranges in multiple countries belonging to the =
same private network, it gets even more complicated.



 


There are other =
complications resulting from the joint ownership of some companies, =
resulting in an owned companies network forming part of the private =
numbering
 plan of both parent companies.


 


Unless there is a proven use =
case from deployers of private networks, I strongly propose that we =
should avoid these cases altogether.


 


I'd note by the way that I =
have not been pushing for global uniqueness, only against the assumption =
that the numbering plans are not locally unique to the particular
 administration. I believe we should assume local uniqueness, but that =
does not presuppose global uniqueness.


 


regards


 


Keith


 


 









From: =
Modern [mailto:modern-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: 20 May 2015 15:31

To: 
modern@ietf.org

Subject: Re: [Modern] TN, E.164, or Something Else?





Eric,



I'm not comfortable with saying that MODERN  is ONLY about managing =
globally unique identifiers as this rules out private numbering plans =
put in place by enterprises.




Yes, MODERN is about globally unique identifiers that have the format of =
a telephone number, but it is also about private identifiers that also =
have the format of a telephone number.



Regards,



Steve




On 5/18/15 5:23 PM, Eric Burger wrote:






Something I have been mulling about is the =
focus (and amount of list traffic) discussing whether the scope of =
MODERN is E.164 numbers, =93telephone numbers,=94 or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. =
An E.164 number carries a lot of a=92priori regulatory baggage. By =
definition, the ITU-T assigns country codes. National numbering =
authorities allocate numbers to service providers. Service providers =
manage them for users.

A =93telephone number=94 spawns the debate as to whether it is, in fact, =
a =91telephone=92 number. Given Henning=92s presentation, the value of =
the telephone number is global routing and global understanding for =
5/7ths of the world using romanized arabic script. Given that, the =
people who worry that =93telephone number=94 is just a code word for =
E.164 number are most likely correct. This spills into the whole =93It =
is not an E.164 number, it is the ABNF for an E.164 number (see =
RFC3966).=94 I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.





 


_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinfo/modern









_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.org/mailman/listinfo/modern












 


_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinfo/modern







_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.org/mailman/listinfo/modern
=



















_______________________________________________
Modern =
mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

=

--Apple-Mail=_7C59BCC1-DAA0-4245-B499-DC1A9C3FB186--


From nobody Tue May 26 11:56: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 AA8BB1B2D47 for ; Tue, 26 May 2015 11:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.277
X-Spam-Level: 
X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 aS0ASWr0qRyN for ; Tue, 26 May 2015 11:56:31 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 18C741B2D1C for ; Tue, 26 May 2015 11:56:30 -0700 (PDT)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t4QIrChN026795; Tue, 26 May 2015 14:56:28 -0400
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1umg4m10fx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 14:56:27 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 26 May 2015 14:56:26 -0400
From: "McGarry, Tom" 
To: Chris Wendt 
Thread-Topic: [Modern] TN, E.164, or Something Else?
Thread-Index: AQHQkblMm58SJXXENkeFQAPg43E2IJ2FMtWAgAWxd4CAAkDIAIAAr+KAgADKrAD//8uiAIAAeg2A///CjAA=
Date: Tue, 26 May 2015 18:56:25 +0000
Message-ID: 
In-Reply-To: <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.108]
Content-Type: multipart/alternative; boundary="_000_D18A37EE25A51tommcgarryneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-05-26_04:2015-05-26,2015-05-26,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=2.56207721704982e-10 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.992957022353465 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.992957022353465 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.992957022353465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505260242
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 18:56:35 -0000

--_000_D18A37EE25A51tommcgarryneustarbiz_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

We're not developing a solution on the list yet (although it seems some kee=
p trying to bring us there).  So I don't see any discussion on the list tha=
t would indicate that a WG would not try to avoid complexity and keep solut=
ions simple.

And I certainly would expect to discuss web-based solutions.

From: Chris Wendt >
Date: Tuesday, May 26, 2015 2:36 PM
To: Tom Mcgarry >
Cc: Modern List >
Subject: Re: [Modern] TN, E.164, or Something Else?

Has the conversation to date provided any indication of this?

Is the IETF in the business of defining RESTful or web service interfaces?

=93Simple" is in the eye of the beholder of course.


On May 26, 2015, at 11:19 AM, McGarry, Tom > wrote:

Why do you think that the WG wouldn't "keep it simple"?

From: Chris Wendt >
Date: Tuesday, May 26, 2015 10:26 AM
To: Steve Donovan >
Cc: Modern List >
Subject: Re: [Modern] TN, E.164, or Something Else?

I=92d like to reiterate my higher level struggle with this, to add a bit to=
 Eric=92s more policy oriented questions.

To me, provisioning interfaces are dime a dozen.

To the new world providers that are looking at this new telecom environment=
 where there are private numbers and we have a nice easy to use provisionin=
g interface (assuming policy allows) the preference would be something that=
 would be a few weeks work to integrate a number provisioning interface.  M=
uch in the same style you would integrate Facebook or twitter interfaces fo=
r auth, etc.

To a traditional telecom service provider, they would likely look at this w=
orld as pain and headache, but that=92s the world we live in currently, hop=
efully that is slowly changing for the better.

Correlating the concepts of =93easy to use provisioning for new web oriente=
d service providers=94 and building a new set of IETF protocols for provisi=
oning does not compute in my head.

Ask any typical web oriented application provider, would they want to use D=
NS style protocols in their web applications to provision numbers for their=
 customer??  Absolutely not, most would request an HTTP based interface.

So, i feel like there is a convoluted discussion going on that placates bot=
h new and old worlds with the opposite arguments.

If the policy side allows, the representatives of whatever private numberin=
g space folks want to conform to should just build a simple straight forwar=
d RESTful interface to allow for number provisioning and call it a day.  I =
see no reason why this isn=92t a completely valid easily adoptable path for=
 all parties for private numbering.

This would support adaptation between a number of worlds quite easily as we=
ll:
You could easily support multiple public and private numbering spaces withi=
n a single customer facing service and a new world begins, happy days.
This could be a business or product opportuntity that easily adapts new and=
 old worlds with interface adaptors from and to old world provisioning syst=
ems.
Eventually, old world provisioning systems could be scrapped and overhauled=
 into the new world.

To me, trying to do anything beyond the keep-it-simple approach is almost a=
 guarantee for a repeat of history for these efforts.  Primarily because it=
=92s the most painful for everyone option, new world has to use protocols t=
hey aren=92t used to, old world needs to adapt protocols anyway.

-Chris

Comcast


On May 25, 2015, at 10:21 PM, Steve Donovan > wrote:

Private number spaces cannot be part of the publicly managed numbers.  They=
 can and generally are mapped to public numbers but that is very different =
from me declaring that "+1 214 555 0000" is a private number.  Private numb=
ers only work in the context of devices used in the "domain" that is admini=
stering the private number space.

I thought I had already said that private numbers are not a part of E.164. =
 They are, however, still TNs by the definition currently in the charter: "=
TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate co=
mmunication with another user of a service. "

Steve

On 5/25/15 10:52 AM, Eric Burger wrote:
Now I am confused.

I was thinking we are building something more complex than just a registry =
of strings of digits to services and maybe routing. IANA (and a host of oth=
ers) can do that today.

I thought the thing that needed solving, which Henning described at the BOF=
, was a how to provision and interface with a registry that maps strings of=
 digits to services and maybe routing, where there was a clear need for som=
e sort of (outside of scope) policy that needs to be enforced.

Am I wrong in thinking the entire point of MODERN is the mechanisms for pol=
icy enforcement?

By policy enforcement, I mean that, depending on jurisdiction, policies may=
 be that only the national numbering authority can delegate the authority t=
o allocate numbers to registered service providers. Or, a policy may be tha=
t only the national numbering authority can allocate numbers to users. Or, =
a policy may be that only the user can assign which services or service pro=
viders are allowed to service the number. What the policies are is out of s=
cope for the work group. However, that there are policies I was under the i=
mpression is the whole point of the work group.

I am very leery of a policy that says that some part of the name space live=
s with the ITU-T and national numbering authorities, but another part of th=
e name space is a free-for-all. What is to stop me from declaring =93+1 214=
-555-1000=94 to be just a private number?

If the proposal is that private numbers are not in the numbering (E.164? TN=
?) name space, then say so. Then Keith=92s question becomes relevant: what =
is the use case? Cullen, is this in the Cisco world? Steven, is this in the=
 Oracle world?

Thanks,
Eric


On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) > wrote:

Adding in private numbers introduces all sorts of complications.

In many cases there is a mapping between E.164 numbers and private numbers,=
 i.e. the allocation by the public administration of an E.164 number automa=
tically generates a valid private number, and vice versa. In other cases th=
ere could be no such mapping. When you apply the above to international pri=
vate networks, with DDI ranges in multiple countries belonging to the same =
private network, it gets even more complicated.

There are other complications resulting from the joint ownership of some co=
mpanies, resulting in an owned companies network forming part of the privat=
e numbering plan of both parent companies.

Unless there is a proven use case from deployers of private networks, I str=
ongly propose that we should avoid these cases altogether.

I'd note by the way that I have not been pushing for global uniqueness, onl=
y against the assumption that the numbering plans are not locally unique to=
 the particular administration. I believe we should assume local uniqueness=
, but that does not presuppose global uniqueness.

regards

Keith



________________________________
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: 20 May 2015 15:31
To: modern@ietf.org
Subject: Re: [Modern] TN, E.164, or Something Else?

Eric,

I'm not comfortable with saying that MODERN  is ONLY about managing globall=
y unique identifiers as this rules out private numbering plans put in place=
 by enterprises.

Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.

Regards,

Steve

On 5/18/15 5:23 PM, Eric Burger wrote:

Something I have been mulling about is the focus (and amount of list traffi=
c) discussing whether the scope of MODERN is E.164 numbers, =93telephone nu=
mbers,=94 or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a=92priori regulatory baggage. By definition, =
the ITU-T assigns country codes. National numbering authorities allocate nu=
mbers to service providers. Service providers manage them for users.

A =93telephone number=94 spawns the debate as to whether it is, in fact, a =
=91telephone=92 number. Given Henning=92s presentation, the value of the te=
lephone number is global routing and global understanding for 5/7ths of the=
 world using romanized arabic script. Given that, the people who worry that=
 =93telephone number=94 is just a code word for E.164 number are most likel=
y correct. This spills into the whole =93It is not an E.164 number, it is t=
he ABNF for an E.164 number (see RFC3966).=94 I.e., it looks, smells, and t=
astes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.




_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinf=
o/modern

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern




_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinf=
o/modern

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


--_000_D18A37EE25A51tommcgarryneustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <388C4996E89832449BE004134BE84564@neustar.biz>
Content-Transfer-Encoding: quoted-printable







We're not developing a solution on the list yet (although it seems som=
e keep trying to bring us there).  So I don't see any discussion on th=
e list that would indicate that a WG would not try to avoid complexity and =
keep solutions simple.  







And I certainly would expect to discuss web-based solutions.  








From: Chris Wendt <chris-ietf@chriswendt.net>

Date: Tuesday, May 26, 2015 2:36 PM=


To: Tom Mcgarry <tom.mcgarry@neustar.biz>

Cc: Modern List <modern@ietf.org>

Subject: Re: [Modern] TN, E.164, or=
 Something Else?












Has the conversation to date provided any indication of this?  






Is the IETF in the business of defining RESTful or web serv=
ice interfaces?







=93Simple" is in the eye of the beholder of course.











On May 26, 2015, at 11:19 AM, McGarry, Tom <Tom.McGarry@neustar.biz> w=
rote:








Why do you think that the WG wouldn't "keep it simple&=
quot;?  









From: Chris Wendt <chris-ietf@chriswendt=
.net>

Date: Tuesday, May 26, 2=
015 10:26 AM

To: Steve Donovan <srdonovan@usdonovans.c=
om>

Cc: Modern List <modern@ietf.org>

Subject: Re: [Modern] TN=
, E.164, or Something Else?












I=92d like to reiterate my higher level struggle with this, to add a bit to=
 Eric=92s more policy oriented questions.






To me, provisioning interfaces are dime a dozen.







To the new world providers that are looking at this new tel=
ecom environment where there are private numbers and we have a nice easy to=
 use provisioning interface (assuming policy allows) the preference would b=
e something that would be a few weeks
 work to integrate a number provisioning interface.  Much in the same =
style you would integrate Facebook or twitter interfaces for auth, etc.






To a traditional telecom service provider, they would likel=
y look at this world as pain and headache, but that=92s the world we live i=
n currently, hopefully that is slowly changing for the better.







Correlating the concepts of =93easy to use provisioning for=
 new web oriented service providers=94 and building a new set of IETF proto=
cols for provisioning does not compute in my head.







Ask any typical web oriented application provider, would th=
ey want to use DNS style protocols in their web applications to provision n=
umbers for their customer??  Absolutely not, most would request an HTT=
P based interface.







So, i feel like there is a convoluted discussion going on t=
hat placates both new and old worlds with the opposite arguments.







If the policy side allows, the representatives of whatever =
private numbering space folks want to conform to should just build a simple=
 straight forward RESTful interface to allow for number provisioning and ca=
ll it a day.  I see no reason why
 this isn=92t a completely valid easily adoptable path for all parties for =
private numbering.  







This would support adaptation between a number of worlds qu=
ite easily as well:


You could easily support multiple public and private number=
ing spaces within a single customer facing service and a new world begins, =
happy days.


This could be a business or product opportuntity that easil=
y adapts new and old worlds with interface adaptors from and to old world p=
rovisioning systems.


Eventually, old world provisioning systems could be scrappe=
d and overhauled into the new world.







To me, trying to do anything beyond the keep-it-simple appr=
oach is almost a guarantee for a repeat of history for these efforts.  =
;Primarily because it=92s the most painful for everyone option, new world h=
as to use protocols they aren=92t used to,
 old world needs to adapt protocols anyway.







-Chris







Comcast














On May 25, 2015, at 10:21 PM, Steve Donovan <srdonovan@usdonovans.com>=
; wrote:






Private number spaces =
cannot be part of the publicly managed numbers.  They can and generall=
y are mapped to public numbers but that is very different from me declaring=
 that "+1 214 555 0000" is a private number. 
 Private numbers only work in the context of devices used in the "doma=
in" that is administering the private number space.



I thought I had already said that private numbers are not a part of E.164.&=
nbsp; They are, however, still TNs by the definition currently in the chart=
er: "TNs, as defined in RFC3966, and blocks of TNs, that are used to i=
nitiate communication with another user of
 a service. "



Steve




On 5/25/15 10:52 AM, Eric Burger wrote:






Now I am confused.







I was thinking we are building something more complex than =
just a registry of strings of digits to services and maybe routing. IANA (a=
nd a host of others) can do that today.







I thought the thing that needed solving, which Henning desc=
ribed at the BOF, was a how to provision and interface with a registry that=
 maps strings of digits to services and maybe routing,
where there was a clear need for some sort of (outside of sco=
pe) policy that needs to be enforced.







Am I wrong in thinking the entire point of MODERN is the me=
chanisms for policy enforcement?







By policy enforcement, I mean that, depending on jurisdicti=
on, policies may be that only the national numbering authority can delegate=
 the authority to allocate numbers to registered service providers. Or, a p=
olicy may be that only the national
 numbering authority can allocate numbers to users. Or, a policy may be tha=
t only the user can assign which services or service providers are allowed =
to service the number. What the policies are is out of scope for the work g=
roup. However, that there are policies
 I was under the impression is the whole point of the work group.







I am very leery of a policy that says that some part of the=
 name space lives with the ITU-T and national numbering authorities, but an=
other part of the name space is a free-for-all. What is to stop me from dec=
laring =93+1 214-555-1000=94 to be just
 a private number?







If the proposal is that private numbers are not in the numb=
ering (E.164? TN?) name space, then say so. Then Keith=92s question becomes=
 relevant: what is the use case? Cullen, is this in the Cisco world? Steven=
, is this in the Oracle world?







Thanks,


Eric













On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:









Adding in private numbers introduces=
 all sorts of complications.


 


In many cases there is a mapping bet=
ween E.164 numbers and private numbers, i.e. the allocation by the public a=
dministration of an E.164 number automatically
 generates a valid private number, and vice versa. In other cases there cou=
ld be no such mapping. When you apply the above to international private ne=
tworks, with DDI ranges in multiple countries belonging to the same private=
 network, it gets even more complicated.



 


There are other complications result=
ing from the joint ownership of some companies, resulting in an owned compa=
nies network forming part of the private numbering
 plan of both parent companies.


 


Unless there is a proven use case fr=
om deployers of private networks, I strongly propose that we should avoid t=
hese cases altogether.


 


I'd note by the way that I have not =
been pushing for global uniqueness, only against the assumption that the nu=
mbering plans are not locally unique to the particular
 administration. I believe we should assume local uniqueness, but that does=
 not presuppose global uniqueness.


 


regards


 


Keith


 


 









From: Modern =
[mailto:modern-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: 20 May 2015 15:31

To: 
modern@ietf.org

Subject: Re: [Modern] TN, E.164, or Something Else?





Eric,



I'm not comfortable with saying that MODERN  is ONLY about managing gl=
obally unique identifiers as this rules out private numbering plans put in =
place by enterprises.




Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.



Regards,



Steve




On 5/18/15 5:23 PM, Eric Burger wrote:






Something I have been mulling about is the focus =
(and amount of list traffic) discussing whether the scope of MODERN is E.16=
4 numbers, =93telephone numbers,=94 or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a=92priori regulatory baggage. By definition, =
the ITU-T assigns country codes. National numbering authorities allocate nu=
mbers to service providers. Service providers manage them for users.

A =93telephone number=94 spawns the debate as to whether it is, in fact, a =
=91telephone=92 number. Given Henning=92s presentation, the value of the te=
lephone number is global routing and global understanding for 5/7ths of the=
 world using romanized arabic script. Given that, the people who worry that=
 =93telephone number=94 is just a code word for E.164 number are most likel=
y correct. This spills into the whole =93It is not an E.164 number, it is t=
he ABNF for an E.164 number (see RFC3966).=94 I.e., it looks, smells, and t=
astes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.





 


_______________________________________________
Modern mailing list
Modern@ietf.orghttps://www.ietf.org/mailman/listinfo/=
modern









_______________________________________________

Modern mailing list

Mode=
rn@ietf.org

https://www.ietf.org/mailman=
/listinfo/modern












 


_______________________________________________
Modern mailing list
Moder=
n@ietf.orghttps://www.ie=
tf.org/mailman/listinfo/modern







_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.org/mailman/listinfo/modern<=
br class=3D"">
















_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.o=
rg/mailman/listinfo/modern





















--_000_D18A37EE25A51tommcgarryneustarbiz_--


From nobody Tue May 26 12:06:44 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 9A9D31B3031 for ; Tue, 26 May 2015 12:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6r_k75CSgr8M for ; Tue, 26 May 2015 12:06:40 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163961ACDE4 for ; Tue, 26 May 2015 12:06:32 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4QJ6GJI060715 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 May 2015 14:06:27 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Chris Wendt" 
Date: Tue, 26 May 2015 14:06:16 -0500
Message-ID: <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>
In-Reply-To: <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net>
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "modern@ietf.org" , "McGarry, Tom" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 19:06:43 -0000

Is the concern that we don't need/want to define "new" protocols? =

There's no reason a working group could not choose a RESTful or web =

services interface.

The charter text leaves room for choosing existing protocols rather than =

defining new ones. Perhaps it should go further and express a preference =

for using (or building on) existing protocols?

On 26 May 2015, at 13:36, Chris Wendt wrote:

> Has the conversation to date provided any indication of this?
>
> Is the IETF in the business of defining RESTful or web service =

> interfaces?
>
> =E2=80=9CSimple" is in the eye of the beholder of course.
>
>
>> On May 26, 2015, at 11:19 AM, McGarry, Tom  =

>> wrote:
>>
>> Why do you think that the WG wouldn't "keep it simple"?
>>
>> From: Chris Wendt > >
>> Date: Tuesday, May 26, 2015 10:26 AM
>> To: Steve Donovan > >
>> Cc: Modern List >
>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>
>> I=E2=80=99d like to reiterate my higher level struggle with this, to a=
dd a =

>> bit to Eric=E2=80=99s more policy oriented questions.
>>
>> To me, provisioning interfaces are dime a dozen.
>>
>> To the new world providers that are looking at this new telecom =

>> environment where there are private numbers and we have a nice easy =

>> to use provisioning interface (assuming policy allows) the preference =

>> would be something that would be a few weeks work to integrate a =

>> number provisioning interface.  Much in the same style you would =

>> integrate Facebook or twitter interfaces for auth, etc.
>>
>> To a traditional telecom service provider, they would likely look at =

>> this world as pain and headache, but that=E2=80=99s the world we live =
in =

>> currently, hopefully that is slowly changing for the better.
>>
>> Correlating the concepts of =E2=80=9Ceasy to use provisioning for new =
web =

>> oriented service providers=E2=80=9D and building a new set of IETF =

>> protocols for provisioning does not compute in my head.
>>
>> Ask any typical web oriented application provider, would they want to =

>> use DNS style protocols in their web applications to provision =

>> numbers for their customer??  Absolutely not, most would request an =

>> HTTP based interface.
>>
>> So, i feel like there is a convoluted discussion going on that =

>> placates both new and old worlds with the opposite arguments.
>>
>> If the policy side allows, the representatives of whatever private =

>> numbering space folks want to conform to should just build a simple =

>> straight forward RESTful interface to allow for number provisioning =

>> and call it a day.  I see no reason why this isn=E2=80=99t a completel=
y =

>> valid easily adoptable path for all parties for private numbering.
>>
>> This would support adaptation between a number of worlds quite easily =

>> as well:
>> You could easily support multiple public and private numbering spaces =

>> within a single customer facing service and a new world begins, happy =

>> days.
>> This could be a business or product opportuntity that easily adapts =

>> new and old worlds with interface adaptors from and to old world =

>> provisioning systems.
>> Eventually, old world provisioning systems could be scrapped and =

>> overhauled into the new world.
>>
>> To me, trying to do anything beyond the keep-it-simple approach is =

>> almost a guarantee for a repeat of history for these efforts.  =

>> Primarily because it=E2=80=99s the most painful for everyone option, n=
ew =

>> world has to use protocols they aren=E2=80=99t used to, old world need=
s to =

>> adapt protocols anyway.
>>
>> -Chris
>>
>> Comcast
>>
>>
>>> On May 25, 2015, at 10:21 PM, Steve Donovan =

>>> > wrote:
>>>
>>> Private number spaces cannot be part of the publicly managed =

>>> numbers.  They can and generally are mapped to public numbers but =

>>> that is very different from me declaring that "+1 214 555 0000" is a =

>>> private number.  Private numbers only work in the context of devices =

>>> used in the "domain" that is administering the private number space.
>>>
>>> I thought I had already said that private numbers are not a part of =

>>> E.164.  They are, however, still TNs by the definition currently in =

>>> the charter: "TNs, as defined in RFC3966, and blocks of TNs, that =

>>> are used to initiate communication with another user of a service. "
>>>
>>> Steve
>>>
>>> On 5/25/15 10:52 AM, Eric Burger wrote:
>>>> Now I am confused.
>>>>
>>>> I was thinking we are building something more complex than just a =

>>>> registry of strings of digits to services and maybe routing. IANA =

>>>> (and a host of others) can do that today.
>>>>
>>>> I thought the thing that needed solving, which Henning described at =

>>>> the BOF, was a how to provision and interface with a registry that =

>>>> maps strings of digits to services and maybe routing, where there =

>>>> was a clear need for some sort of (outside of scope) policy that =

>>>> needs to be enforced.
>>>>
>>>> Am I wrong in thinking the entire point of MODERN is the mechanisms =

>>>> for policy enforcement?
>>>>
>>>> By policy enforcement, I mean that, depending on jurisdiction, =

>>>> policies may be that only the national numbering authority can =

>>>> delegate the authority to allocate numbers to registered service =

>>>> providers. Or, a policy may be that only the national numbering =

>>>> authority can allocate numbers to users. Or, a policy may be that =

>>>> only the user can assign which services or service providers are =

>>>> allowed to service the number. What the policies are is out of =

>>>> scope for the work group. However, that there are policies I was =

>>>> under the impression is the whole point of the work group.
>>>>
>>>> I am very leery of a policy that says that some part of the name =

>>>> space lives with the ITU-T and national numbering authorities, but =

>>>> another part of the name space is a free-for-all. What is to stop =

>>>> me from declaring =E2=80=9C+1 214-555-1000=E2=80=9D to be just a pri=
vate =

>>>> number?
>>>>
>>>> If the proposal is that private numbers are not in the numbering =

>>>> (E.164? TN?) name space, then say so. Then Keith=E2=80=99s question =

>>>> becomes relevant: what is the use case? Cullen, is this in the =

>>>> Cisco world? Steven, is this in the Oracle world?
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>>
>>>>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) =

>>>>> >>>> > wrote:
>>>>>
>>>>> Adding in private numbers introduces all sorts of complications.
>>>>>
>>>>> In many cases there is a mapping between E.164 numbers and private =

>>>>> numbers, i.e. the allocation by the public administration of an =

>>>>> E.164 number automatically generates a valid private number, and =

>>>>> vice versa. In other cases there could be no such mapping. When =

>>>>> you apply the above to international private networks, with DDI =

>>>>> ranges in multiple countries belonging to the same private =

>>>>> network, it gets even more complicated.
>>>>>
>>>>> There are other complications resulting from the joint ownership =

>>>>> of some companies, resulting in an owned companies network forming =

>>>>> part of the private numbering plan of both parent companies.
>>>>>
>>>>> Unless there is a proven use case from deployers of private =

>>>>> networks, I strongly propose that we should avoid these cases =

>>>>> altogether.
>>>>>
>>>>> I'd note by the way that I have not been pushing for global =

>>>>> uniqueness, only against the assumption that the numbering plans =

>>>>> are not locally unique to the particular administration. I believe =

>>>>> we should assume local uniqueness, but that does not presuppose =

>>>>> global uniqueness.
>>>>>
>>>>> regards
>>>>>
>>>>> Keith
>>>>>
>>>>>
>>>>>
>>>>>> From: Modern [mailto:modern-bounces@ietf.org =

>>>>>> ] On Behalf Of Steve Donovan
>>>>>> Sent: 20 May 2015 15:31
>>>>>> To: modern@ietf.org 
>>>>>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>>>>>
>>>>>> Eric,
>>>>>>
>>>>>> I'm not comfortable with saying that MODERN  is ONLY about =

>>>>>> managing globally unique identifiers as this rules out private =

>>>>>> numbering plans put in place by enterprises.
>>>>>>
>>>>>> Yes, MODERN is about globally unique identifiers that have the =

>>>>>> format of a telephone number, but it is also about private =

>>>>>> identifiers that also have the format of a telephone number.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 5/18/15 5:23 PM, Eric Burger wrote:
>>>>>>> Something I have been mulling about is the focus (and amount of =

>>>>>>> list traffic) discussing whether the scope of MODERN is E.164 =

>>>>>>> numbers, =E2=80=9Ctelephone numbers,=E2=80=9D or something else.
>>>>>>>
>>>>>>> We seem to get very emotional about E.164 numbers. Perhaps =

>>>>>>> rightly so. An E.164 number carries a lot of a=E2=80=99priori =

>>>>>>> regulatory baggage. By definition, the ITU-T assigns country =

>>>>>>> codes. National numbering authorities allocate numbers to =

>>>>>>> service providers. Service providers manage them for users.
>>>>>>>
>>>>>>> A =E2=80=9Ctelephone number=E2=80=9D spawns the debate as to whet=
her it is, =

>>>>>>> in fact, a =E2=80=98telephone=E2=80=99 number. Given Henning=E2=80=
=99s =

>>>>>>> presentation, the value of the telephone number is global =

>>>>>>> routing and global understanding for 5/7ths of the world using =

>>>>>>> romanized arabic script. Given that, the people who worry that =

>>>>>>> =E2=80=9Ctelephone number=E2=80=9D is just a code word for E.164 =
number are =

>>>>>>> most likely correct. This spills into the whole =E2=80=9CIt is no=
t an =

>>>>>>> E.164 number, it is the ABNF for an E.164 number (see =

>>>>>>> RFC3966).=E2=80=9D I.e., it looks, smells, and tastes like a rose=
=2E
>>>>>>>
>>>>>>> Could we agree to disagree and say that MODERN is about managing =

>>>>>>> globally unique identifiers that have a syntax of up to 15 =

>>>>>>> decimal digits that have some hierarchical authorities mixed in =

>>>>>>> to lock down who can and cannot request and assign numbers? =

>>>>>>> Those authorities can be an opaque thingbat, because that is =

>>>>>>> where we get into the policy bits, and everyone on the list =

>>>>>>> swears MODERN will not touch policy.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Modern mailing list
>>>>>>> Modern@ietf.org =

>>>>>>> https://www.ietf.org/mailman/listinfo/mod=
ern =

>>>>>>> 
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>> Modern@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/modern =

>>>>> 
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org =

>>>> https://www.ietf.org/mailman/listinfo/modern=
 =

>>>> 
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/modern =

>>> 
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Tue May 26 13:17:15 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 832041B30FD for ; Tue, 26 May 2015 13:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level: 
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 igXPm4iMMlM5 for ; Tue, 26 May 2015 13:17:10 -0700 (PDT)
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 352561B30C0 for ; Tue, 26 May 2015 13:17:10 -0700 (PDT)
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 t4QKH3iJ005255; Tue, 26 May 2015 16:17:08 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1umxrx02pk-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 16:17:07 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 26 May 2015 16:16:06 -0400
From: "Peterson, Jon" 
To: Ben Campbell , Chris Wendt 
Thread-Topic: [Modern] TN, E.164, or Something Else?
Thread-Index: AQHQkblMDaFWIuBTckC2tpZskCKSv52FMtWAgAWxd4CAAkDIAIAAr+KAgADKrACAAA6yAIAANv2AgAAIXwD//54lAA==
Date: Tue, 26 May 2015 20:16:06 +0000
Message-ID: 
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>
In-Reply-To: <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.15]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8669F2DDA056DF42A9ADF7603299A069@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-05-26_04:2015-05-26,2015-05-26,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=3.93740595683312e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505260259
Archived-At: 
Cc: "modern@ietf.org" , "McGarry, Tom" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 20:17:13 -0000

I've envisioned that this group will be primary focused on developing
information models, with the encoding and transport of the data itself
taking place via pre-defined and popular protocols. We don't need to
invent a new JSON, we need the expertise to figure out what the basic
semantics of queries and responses should be for the architectures under
consideration. In that sense, even TeRQ is not a "new" protocol, it's just
an information model with rules for how to bind it to various lightweight
or heavyweight encodings as necessary.

Jon Peterson
Neustar, Inc.

On 5/26/15, 12:06 PM, "Ben Campbell"  wrote:

>Is the concern that we don't need/want to define "new" protocols?
>There's no reason a working group could not choose a RESTful or web
>services interface.
>
>The charter text leaves room for choosing existing protocols rather than
>defining new ones. Perhaps it should go further and express a preference
>for using (or building on) existing protocols?
>
>On 26 May 2015, at 13:36, Chris Wendt wrote:
>
>> Has the conversation to date provided any indication of this?
>>
>> Is the IETF in the business of defining RESTful or web service
>> interfaces?
>>
>> =B3Simple" is in the eye of the beholder of course.
>>
>>
>>> On May 26, 2015, at 11:19 AM, McGarry, Tom 
>>> wrote:
>>>
>>> Why do you think that the WG wouldn't "keep it simple"?
>>>
>>> From: Chris Wendt >> >
>>> Date: Tuesday, May 26, 2015 10:26 AM
>>> To: Steve Donovan >> >
>>> Cc: Modern List >
>>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>>
>>> I=B9d like to reiterate my higher level struggle with this, to add a
>>> bit to Eric=B9s more policy oriented questions.
>>>
>>> To me, provisioning interfaces are dime a dozen.
>>>
>>> To the new world providers that are looking at this new telecom
>>> environment where there are private numbers and we have a nice easy
>>> to use provisioning interface (assuming policy allows) the preference
>>> would be something that would be a few weeks work to integrate a
>>> number provisioning interface.  Much in the same style you would
>>> integrate Facebook or twitter interfaces for auth, etc.
>>>
>>> To a traditional telecom service provider, they would likely look at
>>> this world as pain and headache, but that=B9s the world we live in
>>> currently, hopefully that is slowly changing for the better.
>>>
>>> Correlating the concepts of =B3easy to use provisioning for new web
>>> oriented service providers=B2 and building a new set of IETF
>>> protocols for provisioning does not compute in my head.
>>>
>>> Ask any typical web oriented application provider, would they want to
>>> use DNS style protocols in their web applications to provision
>>> numbers for their customer??  Absolutely not, most would request an
>>> HTTP based interface.
>>>
>>> So, i feel like there is a convoluted discussion going on that
>>> placates both new and old worlds with the opposite arguments.
>>>
>>> If the policy side allows, the representatives of whatever private
>>> numbering space folks want to conform to should just build a simple
>>> straight forward RESTful interface to allow for number provisioning
>>> and call it a day.  I see no reason why this isn=B9t a completely
>>> valid easily adoptable path for all parties for private numbering.
>>>
>>> This would support adaptation between a number of worlds quite easily
>>> as well:
>>> You could easily support multiple public and private numbering spaces
>>> within a single customer facing service and a new world begins, happy
>>> days.
>>> This could be a business or product opportuntity that easily adapts
>>> new and old worlds with interface adaptors from and to old world
>>> provisioning systems.
>>> Eventually, old world provisioning systems could be scrapped and
>>> overhauled into the new world.
>>>
>>> To me, trying to do anything beyond the keep-it-simple approach is
>>> almost a guarantee for a repeat of history for these efforts.
>>> Primarily because it=B9s the most painful for everyone option, new
>>> world has to use protocols they aren=B9t used to, old world needs to
>>> adapt protocols anyway.
>>>
>>> -Chris
>>>
>>> Comcast
>>>
>>>
>>>> On May 25, 2015, at 10:21 PM, Steve Donovan
>>>> > wrote:
>>>>
>>>> Private number spaces cannot be part of the publicly managed
>>>> numbers.  They can and generally are mapped to public numbers but
>>>> that is very different from me declaring that "+1 214 555 0000" is a
>>>> private number.  Private numbers only work in the context of devices
>>>> used in the "domain" that is administering the private number space.
>>>>
>>>> I thought I had already said that private numbers are not a part of
>>>> E.164.  They are, however, still TNs by the definition currently in
>>>> the charter: "TNs, as defined in RFC3966, and blocks of TNs, that
>>>> are used to initiate communication with another user of a service. "
>>>>
>>>> Steve
>>>>
>>>> On 5/25/15 10:52 AM, Eric Burger wrote:
>>>>> Now I am confused.
>>>>>
>>>>> I was thinking we are building something more complex than just a
>>>>> registry of strings of digits to services and maybe routing. IANA
>>>>> (and a host of others) can do that today.
>>>>>
>>>>> I thought the thing that needed solving, which Henning described at
>>>>> the BOF, was a how to provision and interface with a registry that
>>>>> maps strings of digits to services and maybe routing, where there
>>>>> was a clear need for some sort of (outside of scope) policy that
>>>>> needs to be enforced.
>>>>>
>>>>> Am I wrong in thinking the entire point of MODERN is the mechanisms
>>>>> for policy enforcement?
>>>>>
>>>>> By policy enforcement, I mean that, depending on jurisdiction,
>>>>> policies may be that only the national numbering authority can
>>>>> delegate the authority to allocate numbers to registered service
>>>>> providers. Or, a policy may be that only the national numbering
>>>>> authority can allocate numbers to users. Or, a policy may be that
>>>>> only the user can assign which services or service providers are
>>>>> allowed to service the number. What the policies are is out of
>>>>> scope for the work group. However, that there are policies I was
>>>>> under the impression is the whole point of the work group.
>>>>>
>>>>> I am very leery of a policy that says that some part of the name
>>>>> space lives with the ITU-T and national numbering authorities, but
>>>>> another part of the name space is a free-for-all. What is to stop
>>>>> me from declaring =B3+1 214-555-1000=B2 to be just a private
>>>>> number?
>>>>>
>>>>> If the proposal is that private numbers are not in the numbering
>>>>> (E.164? TN?) name space, then say so. Then Keith=B9s question
>>>>> becomes relevant: what is the use case? Cullen, is this in the
>>>>> Cisco world? Steven, is this in the Oracle world?
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>>
>>>>>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith)
>>>>>> >>>>> > wrote:
>>>>>>
>>>>>> Adding in private numbers introduces all sorts of complications.
>>>>>>
>>>>>> In many cases there is a mapping between E.164 numbers and private
>>>>>> numbers, i.e. the allocation by the public administration of an
>>>>>> E.164 number automatically generates a valid private number, and
>>>>>> vice versa. In other cases there could be no such mapping. When
>>>>>> you apply the above to international private networks, with DDI
>>>>>> ranges in multiple countries belonging to the same private
>>>>>> network, it gets even more complicated.
>>>>>>
>>>>>> There are other complications resulting from the joint ownership
>>>>>> of some companies, resulting in an owned companies network forming
>>>>>> part of the private numbering plan of both parent companies.
>>>>>>
>>>>>> Unless there is a proven use case from deployers of private
>>>>>> networks, I strongly propose that we should avoid these cases
>>>>>> altogether.
>>>>>>
>>>>>> I'd note by the way that I have not been pushing for global
>>>>>> uniqueness, only against the assumption that the numbering plans
>>>>>> are not locally unique to the particular administration. I believe
>>>>>> we should assume local uniqueness, but that does not presuppose
>>>>>> global uniqueness.
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> Keith
>>>>>>
>>>>>>
>>>>>>
>>>>>>> From: Modern [mailto:modern-bounces@ietf.org
>>>>>>> ] On Behalf Of Steve Donovan
>>>>>>> Sent: 20 May 2015 15:31
>>>>>>> To: modern@ietf.org 
>>>>>>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>>>>>>
>>>>>>> Eric,
>>>>>>>
>>>>>>> I'm not comfortable with saying that MODERN  is ONLY about
>>>>>>> managing globally unique identifiers as this rules out private
>>>>>>> numbering plans put in place by enterprises.
>>>>>>>
>>>>>>> Yes, MODERN is about globally unique identifiers that have the
>>>>>>> format of a telephone number, but it is also about private
>>>>>>> identifiers that also have the format of a telephone number.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> On 5/18/15 5:23 PM, Eric Burger wrote:
>>>>>>>> Something I have been mulling about is the focus (and amount of
>>>>>>>> list traffic) discussing whether the scope of MODERN is E.164
>>>>>>>> numbers, =B3telephone numbers,=B2 or something else.
>>>>>>>>
>>>>>>>> We seem to get very emotional about E.164 numbers. Perhaps
>>>>>>>> rightly so. An E.164 number carries a lot of a=B9priori
>>>>>>>> regulatory baggage. By definition, the ITU-T assigns country
>>>>>>>> codes. National numbering authorities allocate numbers to
>>>>>>>> service providers. Service providers manage them for users.
>>>>>>>>
>>>>>>>> A =B3telephone number=B2 spawns the debate as to whether it is,
>>>>>>>> in fact, a =8Ctelephone=B9 number. Given Henning=B9s
>>>>>>>> presentation, the value of the telephone number is global
>>>>>>>> routing and global understanding for 5/7ths of the world using
>>>>>>>> romanized arabic script. Given that, the people who worry that
>>>>>>>> =B3telephone number=B2 is just a code word for E.164 number are
>>>>>>>> most likely correct. This spills into the whole =B3It is not an
>>>>>>>> E.164 number, it is the ABNF for an E.164 number (see
>>>>>>>> RFC3966).=B2 I.e., it looks, smells, and tastes like a rose.
>>>>>>>>
>>>>>>>> Could we agree to disagree and say that MODERN is about managing
>>>>>>>> globally unique identifiers that have a syntax of up to 15
>>>>>>>> decimal digits that have some hierarchical authorities mixed in
>>>>>>>> to lock down who can and cannot request and assign numbers?
>>>>>>>> Those authorities can be an opaque thingbat, because that is
>>>>>>>> where we get into the policy bits, and everyone on the list
>>>>>>>> swears MODERN will not touch policy.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Modern mailing list
>>>>>>>> Modern@ietf.org
>>>>>>>>=20
>>>>>>>>https://www.ietf.org/mailman/listinfo/moder
>>>>>>>>n=20
>>>>>>>>=20
>>>>>>>>>>>>>>>mailman_listinfo_modern&d=3DAwMF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4=
Klm32i
>>>>>>>>B7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3Dook7ezMBcf-_t2kjt1ww-SKyyB=
ZY
>>>>>>>>Z0aGnSyxTsyFB4k&s=3DMIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=
=3D>
>>>>>> _______________________________________________
>>>>>> Modern mailing list
>>>>>> Modern@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>>=20
>>>>>>>>>>>ilman_listinfo_modern&d=3DAwMF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm3=
2iB7Hu
>>>>>>fveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3Dook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aG=
nS
>>>>>>yxTsyFB4k&s=3DMIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=3D>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>> Modern@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>=20
>>>>>>>>>lman_listinfo_modern&d=3DAwMF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32i=
B7Hufv
>>>>>eeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3Dook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSy=
xT
>>>>>syFB4k&s=3DMIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=3D>
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>> 
>>>
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern


From nobody Tue May 26 13:19:43 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 C19401B3116 for ; Tue, 26 May 2015 13:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VRVmm-gI3a7R for ; Tue, 26 May 2015 13:19:40 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D914C1B3114 for ; Tue, 26 May 2015 13:19:40 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4QKJPVQ029840 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 May 2015 15:19:35 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Peterson, Jon" 
Date: Tue, 26 May 2015 15:19:24 -0500
Message-ID: <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com>
In-Reply-To: 
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com> 
MIME-Version: 1.0
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: Chris Wendt , "modern@ietf.org" , "McGarry, Tom" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 20:19:42 -0000

On 26 May 2015, at 15:16, Peterson, Jon wrote:

> I've envisioned that this group will be primary focused on developing
> information models, with the encoding and transport of the data itself
> taking place via pre-defined and popular protocols.

Should the charter say that?

> We don't need to
> invent a new JSON, we need the expertise to figure out what the basic
> semantics of queries and responses should be for the architectures under
> consideration. In that sense, even TeRQ is not a "new" protocol, it's just
> an information model with rules for how to bind it to various lightweight
> or heavyweight encodings as necessary.

Thanks!

Ben.


From nobody Tue May 26 13:34:49 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 BCDA21B3147 for ; Tue, 26 May 2015 13:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.309
X-Spam-Level: 
X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-5, 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 H3PDHaPr6vHz for ; Tue, 26 May 2015 13:34:42 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 E1FBD1B3150 for ; Tue, 26 May 2015 13:34:36 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id F41CDFE9D3714; Tue, 26 May 2015 20:34:31 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t4QKYZp3007664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 May 2015 22:34:35 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 26 May 2015 22:34:35 +0200
From: "DRAGE, Keith (Keith)" 
To: Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] TN, E.164, or Something Else?
Thread-Index: AQHQlwLL707hHz3yNUOeEQIMenKF+J2NZc6AgAFSN/A=
Date: Tue, 26 May 2015 20:34:33 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B6971D635@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <12180B6D-426A-49DA-9D65-FAC676587E8D@standardstrack.com> <5563D8AB.5090407@usdonovans.com>
In-Reply-To: <5563D8AB.5090407@usdonovans.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B6971D635FR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 20:34:48 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B6971D635FR712WXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It is the mere fact that they are mapped to public network numbers that cau=
ses the issues.

If you are trying to understand the usage of the private number, then you w=
ill also need to understand the mapping when that exists.

And that will depend also on whether you are the administrator of the priva=
te numbering space or the public numbering space, or in the case of Centrex=
 and business trunking, potentially both.


Keith

________________________________
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: 26 May 2015 03:22
To: modern@ietf.org
Subject: Re: [Modern] TN, E.164, or Something Else?

Private number spaces cannot be part of the publicly managed numbers.  They=
 can and generally are mapped to public numbers but that is very different =
from me declaring that "+1 214 555 0000" is a private number.  Private numb=
ers only work in the context of devices used in the "domain" that is admini=
stering the private number space.

I thought I had already said that private numbers are not a part of E.164. =
 They are, however, still TNs by the definition currently in the charter: "=
TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate co=
mmunication with another user of a service. "

Steve

On 5/25/15 10:52 AM, Eric Burger wrote:
Now I am confused.

I was thinking we are building something more complex than just a registry =
of strings of digits to services and maybe routing. IANA (and a host of oth=
ers) can do that today.

I thought the thing that needed solving, which Henning described at the BOF=
, was a how to provision and interface with a registry that maps strings of=
 digits to services and maybe routing, where there was a clear need for som=
e sort of (outside of scope) policy that needs to be enforced.

Am I wrong in thinking the entire point of MODERN is the mechanisms for pol=
icy enforcement?

By policy enforcement, I mean that, depending on jurisdiction, policies may=
 be that only the national numbering authority can delegate the authority t=
o allocate numbers to registered service providers. Or, a policy may be tha=
t only the national numbering authority can allocate numbers to users. Or, =
a policy may be that only the user can assign which services or service pro=
viders are allowed to service the number. What the policies are is out of s=
cope for the work group. However, that there are policies I was under the i=
mpression is the whole point of the work group.

I am very leery of a policy that says that some part of the name space live=
s with the ITU-T and national numbering authorities, but another part of th=
e name space is a free-for-all. What is to stop me from declaring "+1 214-5=
55-1000" to be just a private number?

If the proposal is that private numbers are not in the numbering (E.164? TN=
?) name space, then say so. Then Keith's question becomes relevant: what is=
 the use case? Cullen, is this in the Cisco world? Steven, is this in the O=
racle world?

Thanks,
Eric


On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) > wrote:

Adding in private numbers introduces all sorts of complications.

In many cases there is a mapping between E.164 numbers and private numbers,=
 i.e. the allocation by the public administration of an E.164 number automa=
tically generates a valid private number, and vice versa. In other cases th=
ere could be no such mapping. When you apply the above to international pri=
vate networks, with DDI ranges in multiple countries belonging to the same =
private network, it gets even more complicated.

There are other complications resulting from the joint ownership of some co=
mpanies, resulting in an owned companies network forming part of the privat=
e numbering plan of both parent companies.

Unless there is a proven use case from deployers of private networks, I str=
ongly propose that we should avoid these cases altogether.

I'd note by the way that I have not been pushing for global uniqueness, onl=
y against the assumption that the numbering plans are not locally unique to=
 the particular administration. I believe we should assume local uniqueness=
, but that does not presuppose global uniqueness.

regards

Keith



________________________________
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: 20 May 2015 15:31
To: modern@ietf.org
Subject: Re: [Modern] TN, E.164, or Something Else?

Eric,

I'm not comfortable with saying that MODERN  is ONLY about managing globall=
y unique identifiers as this rules out private numbering plans put in place=
 by enterprises.

Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.

Regards,

Steve

On 5/18/15 5:23 PM, Eric Burger wrote:

Something I have been mulling about is the focus (and amount of list traffi=
c) discussing whether the scope of MODERN is E.164 numbers, "telephone numb=
ers," or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a'priori regulatory baggage. By definition, th=
e ITU-T assigns country codes. National numbering authorities allocate numb=
ers to service providers. Service providers manage them for users.

A "telephone number" spawns the debate as to whether it is, in fact, a 'tel=
ephone' number. Given Henning's presentation, the value of the telephone nu=
mber is global routing and global understanding for 5/7ths of the world usi=
ng romanized arabic script. Given that, the people who worry that "telephon=
e number" is just a code word for E.164 number are most likely correct. Thi=
s spills into the whole "It is not an E.164 number, it is the ABNF for an E=
.164 number (see RFC3966)." I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.




_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern




_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern



--_000_949EF20990823C4C85C18D59AA11AD8B6971D635FR712WXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









It is the mere fact that they are mapped to public network n=
umbers that causes the issues.



 


If you are trying to understand the usage of the private num=
ber, then you will also need to understand the mapping when that exists.


 


And that will depend also on whether you are the administrat=
or of the private numbering space or the public numbering space, or in the =
case of Centrex and business trunking, potentially
 both.


 


 


Keith









From: Modern [mailto:modern-bounces=
@ietf.org]
On Behalf Of Steve Donovan

Sent: 26 May 2015 03:22

To: modern@ietf.org

Subject: Re: [Modern] TN, E.164, or Something Else?







Private number spaces cannot be part of the publicly managed numbers. =
 They can and generally are mapped to public numbers but that is very diffe=
rent from me declaring that "+1 214 555 0000" is a private nu=
mber.  Private numbers only work in the context of
 devices used in the "domain" that is administering the private n=
umber space.



I thought I had already said that private numbers are not a part of E.164.&=
nbsp; They are, however, still TNs by the definition currently in the chart=
er: "TNs, as defined in RFC3966, and blocks of TNs, that are used to i=
nitiate communication with another user of
 a service. "



Steve




On 5/25/15 10:52 AM, Eric Burger wrote:






Now I am confused.







I was thinking we are building something more complex than =
just a registry of strings of digits to services and maybe routing. IANA (a=
nd a host of others) can do that today.







I thought the thing that needed solving, which Henning desc=
ribed at the BOF, was a how to provision and interface with a registry that=
 maps strings of digits to services and maybe routing,
where there was a clear need for some sort of (outside of sco=
pe) policy that needs to be enforced.







Am I wrong in thinking the entire point of MODERN is the me=
chanisms for policy enforcement?







By policy enforcement, I mean that, depending on jurisdicti=
on, policies may be that only the national numbering authority can delegate=
 the authority to allocate numbers to registered service providers. Or, a p=
olicy may be that only the national
 numbering authority can allocate numbers to users. Or, a policy may be tha=
t only the user can assign which services or service providers are allowed =
to service the number. What the policies are is out of scope for the work g=
roup. However, that there are policies
 I was under the impression is the whole point of the work group.







I am very leery of a policy that says that some part of the=
 name space lives with the ITU-T and national numbering authorities, but an=
other part of the name space is a free-for-all. What is to stop me from dec=
laring “+1 214-555-1000” to be just
 a private number?







If the proposal is that private numbers are not in the numb=
ering (E.164? TN?) name space, then say so. Then Keith’s question bec=
omes relevant: what is the use case? Cullen, is this in the Cisco world? St=
even, is this in the Oracle world?







Thanks,


Eric













On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:









Adding in private numbers introduces a=
ll sorts of complications.


 


In many cases there is a mapping betwe=
en E.164 numbers and private numbers, i.e. the allocation by the public adm=
inistration of an E.164 number automatically
 generates a valid private number, and vice versa. In other cases there cou=
ld be no such mapping. When you apply the above to international private ne=
tworks, with DDI ranges in multiple countries belonging to the same private=
 network, it gets even more complicated.



 


There are other complications resultin=
g from the joint ownership of some companies, resulting in an owned compani=
es network forming part of the private numbering
 plan of both parent companies.


 


Unless there is a proven use case from=
 deployers of private networks, I strongly propose that we should avoid the=
se cases altogether.


 


I'd note by the way that I have not be=
en pushing for global uniqueness, only against the assumption that the numb=
ering plans are not locally unique to the particular
 administration. I believe we should assume local uniqueness, but that does=
 not presuppose global uniqueness.


 


regards


 


Keith


 


 









From: Modern =
[mailto:modern-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: 20 May 2015 15:31

To: 
modern@ietf.org

Subject: Re: [Modern] TN, E.164, or Something Else?





Eric,



I'm not comfortable with saying that MODERN  is ONLY about managing gl=
obally unique identifiers as this rules out private numbering plans put in =
place by enterprises.




Yes, MODERN is about globally unique identifiers that have the format of a =
telephone number, but it is also about private identifiers that also have t=
he format of a telephone number.



Regards,



Steve




On 5/18/15 5:23 PM, Eric Burger wrote:






Something I have been mulling about is the focus =
(and amount of list traffic) discussing whether the scope of MODERN is E.16=
4 numbers, “telephone numbers,” or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E=
.164 number carries a lot of a’priori regulatory baggage. By definiti=
on, the ITU-T assigns country codes. National numbering authorities allocat=
e numbers to service providers. Service providers manage them for users.

A “telephone number” spawns the debate as to whether it is, in =
fact, a ‘telephone’ number. Given Henning’s presentation,=
 the value of the telephone number is global routing and global understandi=
ng for 5/7ths of the world using romanized arabic script. Given that, the p=
eople who worry that “telephone number” is just a code word for=
 E.164 number are most likely correct. This spills into the whole “It=
 is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).&=
#8221; I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally u=
nique identifiers that have a syntax of up to 15 decimal digits that have s=
ome hierarchical authorities mixed in to lock down who can and cannot reque=
st and assign numbers? Those authorities can be an opaque thingbat, because=
 that is where we get into the policy bits, and everyone on the list swears=
 MODERN will not touch policy.





 


_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinf=
o/modern










_______________________________________________

Modern mailing list

Mode=
rn@ietf.org

https://www.ietf.org/mailman/listinfo/modern












 


_______________________________________________
Modern mailing list
Moder=
n@ietf.org
https://www.ietf.org/mailman/listinfo/modern











--_000_949EF20990823C4C85C18D59AA11AD8B6971D635FR712WXCHMBA11z_--


From nobody Tue May 26 14:03: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 B76801B31A3 for ; Tue, 26 May 2015 14:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level: 
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ZNiQMC-fQApH for ; Tue, 26 May 2015 14:03:55 -0700 (PDT)
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 05C341B3194 for ; Tue, 26 May 2015 14:03:54 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t4QKvINn032573; Tue, 26 May 2015 17:03:53 -0400
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1un0aag0aj-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 17:03:53 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 26 May 2015 17:03:52 -0400
From: "Peterson, Jon" 
To: Ben Campbell 
Thread-Topic: [Modern] TN, E.164, or Something Else?
Thread-Index: AQHQkblMDaFWIuBTckC2tpZskCKSv52FMtWAgAWxd4CAAkDIAIAAr+KAgADKrACAAA6yAIAANv2AgAAIXwD//54lAIAAdkoA//+XDYA=
Date: Tue, 26 May 2015 21:03:51 +0000
Message-ID: 
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>  <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com>
In-Reply-To: <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.15]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-05-26_04:2015-05-26,2015-05-26,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.56916726676582e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505260267
Archived-At: 
Cc: Chris Wendt , "modern@ietf.org" , "McGarry, Tom" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 26 May 2015 21:03:56 -0000

If it makes people more comfortable for that to be in the charter, I'm all
for it. I think it's a reasonable constraint on the design. I'm not sure
the charter needs to declare a preemptive consensus for JSON versus some
other format, say, but the general sentiment that we're not in the
business of building new transports, but instead focusing on semantics,
would be fine with me.

Jon Peterson
Neustar, Inc.

On 5/26/15, 1:19 PM, "Ben Campbell"  wrote:

>On 26 May 2015, at 15:16, Peterson, Jon wrote:
>
>> I've envisioned that this group will be primary focused on developing
>> information models, with the encoding and transport of the data itself
>> taking place via pre-defined and popular protocols.
>
>Should the charter say that?
>
>> We don't need to
>> invent a new JSON, we need the expertise to figure out what the basic
>> semantics of queries and responses should be for the architectures under
>> consideration. In that sense, even TeRQ is not a "new" protocol, it's
>>just
>> an information model with rules for how to bind it to various
>>lightweight
>> or heavyweight encodings as necessary.
>
>Thanks!
>
>Ben.


From nobody Tue May 26 18:46: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 7C1D51A1ACA for ; Tue, 26 May 2015 18:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 BKdnifNKmGWu for ; Tue, 26 May 2015 18:46:10 -0700 (PDT)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013071A1AD0 for ; Tue, 26 May 2015 18:46:09 -0700 (PDT)
Received: by qgg60 with SMTP id 60so20598493qgg.2 for ; Tue, 26 May 2015 18:46:09 -0700 (PDT)
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:content-transfer-encoding:message-id:references :to; bh=keKZXun7Zkw8DJ7Z9cQWwOJtEgPU/5LHHJS9DqZXYZU=; b=etrQRyTiWmWinmEl7m6e2rMfbgjGQk1R+smc1/Y3wsroUFphD3ozGzd688kWIRzgEg +NXqZBdzTck2Zc/KpsSDr72pCdANR7bfM+w1Lh6n3QuGC/VBxy5UFwuFv5EOY1QV/UkV hCUfjDFMI4Q7OAxwBjcp//llpBLrNOlaExMxhS5cMLlXK4rx/N1ouY/+C6RIXUx/siCr KYcPUnVTsdvKV6ws28HLKAMynFrAjaPJ2tDDsoM+lot43LLYJyY4JktvsJBWi02OYSEA 90fQDejmo877JjokSJNHTYYZnQBpCSYey1GHlK0AMITty4fAlqSop9L+NSD01QvnOcaD T7ng==
X-Gm-Message-State: ALoCoQlMkJFta9+taWjzYlaIUnIDgbTLfxEh/1cdEbaB1vTwWRi1C94lxNJoAg/2GAxVq5+YQeTe
X-Received: by 10.55.41.195 with SMTP id p64mr31365441qkp.40.1432691169049; Tue, 26 May 2015 18:46:09 -0700 (PDT)
Received: from [10.0.1.100] (c-68-81-246-249.hsd1.pa.comcast.net. [68.81.246.249]) by mx.google.com with ESMTPSA id m73sm9629570qkh.26.2015.05.26.18.46.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 May 2015 18:46:07 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Chris Wendt 
In-Reply-To: 
Date: Tue, 26 May 2015 21:45:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BD95645-8BC7-4625-910D-A07A33638C88@chriswendt.net>
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>  <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com> 
To: "Peterson, Jon" 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Ben Campbell , "modern@ietf.org" , "McGarry, Tom" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 27 May 2015 01:46:11 -0000

If this is the intent, specifically your statement about transports vs =
semantics, and everybody is in general agreement with this, then the =
scope is a lot less open-ended than i was interpreting.

It would certainly make me more comfortable to add this language to the =
charter.

Thanks.

-Chris

> On May 26, 2015, at 5:03 PM, Peterson, Jon  =
wrote:
>=20
>=20
> If it makes people more comfortable for that to be in the charter, I'm =
all
> for it. I think it's a reasonable constraint on the design. I'm not =
sure
> the charter needs to declare a preemptive consensus for JSON versus =
some
> other format, say, but the general sentiment that we're not in the
> business of building new transports, but instead focusing on =
semantics,
> would be fine with me.
>=20
> Jon Peterson
> Neustar, Inc.
>=20
> On 5/26/15, 1:19 PM, "Ben Campbell"  wrote:
>=20
>> On 26 May 2015, at 15:16, Peterson, Jon wrote:
>>=20
>>> I've envisioned that this group will be primary focused on =
developing
>>> information models, with the encoding and transport of the data =
itself
>>> taking place via pre-defined and popular protocols.
>>=20
>> Should the charter say that?
>>=20
>>> We don't need to
>>> invent a new JSON, we need the expertise to figure out what the =
basic
>>> semantics of queries and responses should be for the architectures =
under
>>> consideration. In that sense, even TeRQ is not a "new" protocol, =
it's
>>> just
>>> an information model with rules for how to bind it to various
>>> lightweight
>>> or heavyweight encodings as necessary.
>>=20
>> Thanks!
>>=20
>> Ben.
>=20


From nobody Tue May 26 18:50:24 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 5BB991B3380 for ; Tue, 26 May 2015 18:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 duisLeS10ouM for ; Tue, 26 May 2015 18:50:22 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135BB1AD0C1 for ; Tue, 26 May 2015 18:50:22 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4R1o6be060512 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 May 2015 20:50:17 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Chris Wendt" 
Date: Tue, 26 May 2015 20:50:06 -0500
Message-ID: <4978F6B6-0A98-477A-BDB4-8A3335930AEA@nostrum.com>
In-Reply-To: <2BD95645-8BC7-4625-910D-A07A33638C88@chriswendt.net>
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>  <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com>  <2BD95645-8BC7-4625-910D-A07A33638C88@chriswendt.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "modern@ietf.org" , "McGarry, Tom" , "Peterson, Jon" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 27 May 2015 01:50:23 -0000

On 26 May 2015, at 20:45, Chris Wendt wrote:

> If this is the intent, specifically your statement about transports vs 
> semantics, and everybody is in general agreement with this, then the 
> scope is a lot less open-ended than i was interpreting.

I am in general agreement with this. While I would hesitate to 
completely forbid the working group from designing new protocols in the 
unlikely case that it decided no reasonable choice met the requirements, 
I very much agree to stating a strong preference for not doing so.

>
> It would certainly make me more comfortable to add this language to 
> the charter.
>
> Thanks.
>
> -Chris
>
>> On May 26, 2015, at 5:03 PM, Peterson, Jon  
>> wrote:
>>
>>
>> If it makes people more comfortable for that to be in the charter, 
>> I'm all
>> for it. I think it's a reasonable constraint on the design. I'm not 
>> sure
>> the charter needs to declare a preemptive consensus for JSON versus 
>> some
>> other format, say, but the general sentiment that we're not in the
>> business of building new transports, but instead focusing on 
>> semantics,
>> would be fine with me.
>>
>> Jon Peterson
>> Neustar, Inc.
>>
>> On 5/26/15, 1:19 PM, "Ben Campbell"  wrote:
>>
>>> On 26 May 2015, at 15:16, Peterson, Jon wrote:
>>>
>>>> I've envisioned that this group will be primary focused on 
>>>> developing
>>>> information models, with the encoding and transport of the data 
>>>> itself
>>>> taking place via pre-defined and popular protocols.
>>>
>>> Should the charter say that?
>>>
>>>> We don't need to
>>>> invent a new JSON, we need the expertise to figure out what the 
>>>> basic
>>>> semantics of queries and responses should be for the architectures 
>>>> under
>>>> consideration. In that sense, even TeRQ is not a "new" protocol, 
>>>> it's
>>>> just
>>>> an information model with rules for how to bind it to various
>>>> lightweight
>>>> or heavyweight encodings as necessary.
>>>
>>> Thanks!
>>>
>>> Ben.
>>


From nobody Wed May 27 07:35:39 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 4D9A61B2B5D for ; Wed, 27 May 2015 07:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] 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 FqyjgBhGeQkt for ; Wed, 27 May 2015 07:35:34 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 E438E1B2B69 for ; Wed, 27 May 2015 07:35:10 -0700 (PDT)
Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:65097 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YxcQG-0009ww-NM for modern@ietf.org; Wed, 27 May 2015 07:35:10 -0700
Message-ID: <5565D61B.2060101@usdonovans.com>
Date: Wed, 27 May 2015 09:35:07 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: modern@ietf.org
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>  <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com>  <2BD95645-8BC7-4625-910D-A07A33638C88@chriswendt.net> <4978F6B6-0A98-477A-BDB4-8A3335930AEA@nostrum.com>
In-Reply-To: <4978F6B6-0A98-477A-BDB4-8A3335930AEA@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 27 May 2015 14:35:38 -0000

I think we're pretty close.

Here's the paragraph in question:

The working group will define an information management framework for 
the roles
and functions involved in associating information with one or more TNs 
in an IP
environment.  The working group will also define protocol mechanisms to 
support
the interactions between the functions defined by the framework. This 
includes
either recommending or defining protocol mechanisms for acquiring, 
associating
and resolving TNs.  The protocol mechanism for acquiring TNs will provide an
enrollment process for the entities that use and manage TNs. TNs may 
either be
managed in a hierarchical tree, or in a distributed peer-to-peer 
architecture.
Privacy of the managed data and security of the resource will be primary
considerations.  The protocol mechanism for resolving TNs will allow 
entities
such as service providers, devices, and applications to access data 
related to
TNs.  Maintaining reliability, real time application performance, 
security and
privacy are primary considerations.  The working group will take into
consideration existing IETF work including ENUM, SPEERMINT, DRINKS and SCIM.

How about if we change the second sentence from "...The working group 
will define protocol mechanisms..." to "...The working group will 
___identify___ protocol mechanisms.

The next sentence already talks about recommending or defining. Maybe if 
we change "...This includes
either recommending or defining protocol mechanisms for acquiring, 
associating
and resolving TNs..." to "...This includes
either recommending or defining protocol mechanisms for acquiring, 
associating
and resolving TNs, ___with a preference for use of existing transports___".

This should hopefully address the concern.

Steve

On 5/26/15 8:50 PM, Ben Campbell wrote:
> On 26 May 2015, at 20:45, Chris Wendt wrote:
>
>> If this is the intent, specifically your statement about transports 
>> vs semantics, and everybody is in general agreement with this, then 
>> the scope is a lot less open-ended than i was interpreting.
>
> I am in general agreement with this. While I would hesitate to 
> completely forbid the working group from designing new protocols in 
> the unlikely case that it decided no reasonable choice met the 
> requirements, I very much agree to stating a strong preference for not 
> doing so.
>
>>
>> It would certainly make me more comfortable to add this language to 
>> the charter.
>>
>> Thanks.
>>
>> -Chris
>>
>>> On May 26, 2015, at 5:03 PM, Peterson, Jon 
>>>  wrote:
>>>
>>>
>>> If it makes people more comfortable for that to be in the charter, 
>>> I'm all
>>> for it. I think it's a reasonable constraint on the design. I'm not 
>>> sure
>>> the charter needs to declare a preemptive consensus for JSON versus 
>>> some
>>> other format, say, but the general sentiment that we're not in the
>>> business of building new transports, but instead focusing on semantics,
>>> would be fine with me.
>>>
>>> Jon Peterson
>>> Neustar, Inc.
>>>
>>> On 5/26/15, 1:19 PM, "Ben Campbell"  wrote:
>>>
>>>> On 26 May 2015, at 15:16, Peterson, Jon wrote:
>>>>
>>>>> I've envisioned that this group will be primary focused on developing
>>>>> information models, with the encoding and transport of the data 
>>>>> itself
>>>>> taking place via pre-defined and popular protocols.
>>>>
>>>> Should the charter say that?
>>>>
>>>>> We don't need to
>>>>> invent a new JSON, we need the expertise to figure out what the basic
>>>>> semantics of queries and responses should be for the architectures 
>>>>> under
>>>>> consideration. In that sense, even TeRQ is not a "new" protocol, it's
>>>>> just
>>>>> an information model with rules for how to bind it to various
>>>>> lightweight
>>>>> or heavyweight encodings as necessary.
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
>


From nobody Wed May 27 07:41: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 E83A81B2B90 for ; Wed, 27 May 2015 07:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.28
X-Spam-Level: 
X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 RctGci2_UUV8 for ; Wed, 27 May 2015 07:41:46 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 36BCF1B2B94 for ; Wed, 27 May 2015 07:41:46 -0700 (PDT)
Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:65131 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YxcWd-0002DO-Lg; Wed, 27 May 2015 07:41:45 -0700
Message-ID: <5565D7A6.5060106@usdonovans.com>
Date: Wed, 27 May 2015 09:41:42 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" ,  "modern@ietf.org" 
References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <12180B6D-426A-49DA-9D65-FAC676587E8D@standardstrack.com> <5563D8AB.5090407@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971D635@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6971D635@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------040501010800050003060804"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 27 May 2015 14:41:50 -0000

This is a multi-part message in MIME format.
--------------040501010800050003060804
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Keith,

I don't see this as a reason for precluding looking at private number 
spaces in the MODERN charter.

The mapping, should there be one, will be handled in context of the 
private space administrator, whether directly or delegated.  It 
shouldn't have any impact on the public numbering space.

It might be as simple as having an optional information element that 
includes the mapping for operations within the private number space.  
But this can be addressed by the working group.

Steve

On 5/26/15 3:34 PM, DRAGE, Keith (Keith) wrote:
> It is the mere fact that they are mapped to public network numbers 
> that causes the issues.
> If you are trying to understand the usage of the private number, then 
> you will also need to understand the mapping when that exists.
> And that will depend also on whether you are the administrator of the 
> private numbering space or the public numbering space, or in the case 
> of Centrex and business trunking, potentially both.
> Keith
>
>     ------------------------------------------------------------------------
>     *From:* Modern [mailto:modern-bounces@ietf.org] *On Behalf Of
>     *Steve Donovan
>     *Sent:* 26 May 2015 03:22
>     *To:* modern@ietf.org
>     *Subject:* Re: [Modern] TN, E.164, or Something Else?
>
>     Private number spaces cannot be part of the publicly managed
>     numbers.  They can and generally are mapped to public numbers but
>     that is very different from me declaring that "+1 214 555 0000" is
>     a private number.  Private numbers only work in the context of
>     devices used in the "domain" that is administering the private
>     number space.
>
>     I thought I had already said that private numbers are not a part
>     of E.164.  They are, however, still TNs by the definition
>     currently in the charter: "TNs, as defined in RFC3966, and blocks
>     of TNs, that are used to initiate communication with another user
>     of a service. "
>
>     Steve
>
>     On 5/25/15 10:52 AM, Eric Burger wrote:
>>     Now I am confused.
>>
>>     I was thinking we are building something more complex than just a
>>     registry of strings of digits to services and maybe routing. IANA
>>     (and a host of others) can do that today.
>>
>>     I thought the thing that needed solving, which Henning described
>>     at the BOF, was a how to provision and interface with a registry
>>     that maps strings of digits to services and maybe routing, *where
>>     there was a clear need for some sort of (outside of scope) policy
>>     that needs to be enforced.*
>>     *
>>     *
>>     Am I wrong in thinking the entire point of MODERN is the
>>     mechanisms for policy enforcement?
>>
>>     By policy enforcement, I mean that, depending on jurisdiction,
>>     policies may be that only the national numbering authority can
>>     delegate the authority to allocate numbers to registered service
>>     providers. Or, a policy may be that only the national numbering
>>     authority can allocate numbers to users. Or, a policy may be that
>>     only the user can assign which services or service providers are
>>     allowed to service the number. What the policies are is out of
>>     scope for the work group. However, that there are policies I was
>>     under the impression is the whole point of the work group.
>>
>>     I am very leery of a policy that says that some part of the name
>>     space lives with the ITU-T and national numbering authorities,
>>     but another part of the name space is a free-for-all. What is to
>>     stop me from declaring “+1 214-555-1000” to be just a private number?
>>
>>     If the proposal is that private numbers are not in the numbering
>>     (E.164? TN?) name space, then say so. Then Keith’s question
>>     becomes relevant: what is the use case? Cullen, is this in the
>>     Cisco world? Steven, is this in the Oracle world?
>>
>>     Thanks,
>>     Eric
>>
>>
>>>     On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith)
>>>     >>     > wrote:
>>>
>>>     Adding in private numbers introduces all sorts of complications.
>>>     In many cases there is a mapping between E.164 numbers and
>>>     private numbers, i.e. the allocation by the public
>>>     administration of an E.164 number automatically generates a
>>>     valid private number, and vice versa. In other cases there could
>>>     be no such mapping. When you apply the above to international
>>>     private networks, with DDI ranges in multiple countries
>>>     belonging to the same private network, it gets even more
>>>     complicated.
>>>     There are other complications resulting from the joint ownership
>>>     of some companies, resulting in an owned companies
>>>     network forming part of the private numbering plan of both
>>>     parent companies.
>>>     Unless there is a proven use case from deployers of private
>>>     networks, I strongly propose that we should avoid these cases
>>>     altogether.
>>>     I'd note by the way that I have not been pushing for global
>>>     uniqueness, only against the assumption that the numbering plans
>>>     are not locally unique to the particular administration. I
>>>     believe we should assume local uniqueness, but that does not
>>>     presuppose global uniqueness.
>>>     regards
>>>     Keith
>>>
>>>         ------------------------------------------------------------------------
>>>         *From:* Modern [mailto:modern-bounces@ietf.org] *On Behalf
>>>         Of *Steve Donovan
>>>         *Sent:* 20 May 2015 15:31
>>>         *To:* modern@ietf.org 
>>>         *Subject:* Re: [Modern] TN, E.164, or Something Else?
>>>
>>>         Eric,
>>>
>>>         I'm not comfortable with saying that MODERN  is ONLY about
>>>         managing globally unique identifiers as this rules out
>>>         private numbering plans put in place by enterprises.
>>>
>>>         Yes, MODERN is about globally unique identifiers that have
>>>         the format of a telephone number, but it is also about
>>>         private identifiers that also have the format of a telephone
>>>         number.
>>>
>>>         Regards,
>>>
>>>         Steve
>>>
>>>         On 5/18/15 5:23 PM, Eric Burger wrote:
>>>>         Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else.
>>>>
>>>>         We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.
>>>>
>>>>         A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose.
>>>>
>>>>         Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy.
>>>>
>>>>
>>>>         _______________________________________________
>>>>         Modern mailing list
>>>>         Modern@ietf.org
>>>>         https://www.ietf.org/mailman/listinfo/modern
>>>
>>>     _______________________________________________
>>>     Modern mailing list
>>>     Modern@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/modern
>>
>>
>>
>>     _______________________________________________
>>     Modern mailing list
>>     Modern@ietf.org
>>     https://www.ietf.org/mailman/listinfo/modern
>


--------------040501010800050003060804
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Keith,

    

    I don't see this as a reason for precluding looking at private
    number spaces in the MODERN charter. 

    

    The mapping, should there be one, will be handled in context of the
    private space administrator, whether directly or delegated.  It
    shouldn't have any impact on the public numbering space.

    

    It might be as simple as having an optional information element that
    includes the mapping for operations within the private number
    space.  But this can be addressed by the working group.

    

    Steve

    

    
On 5/26/15 3:34 PM, DRAGE, Keith
      (Keith) wrote:

    

    

      
      
      
It is the mere fact that they are
            mapped to public network numbers that causes the issues.
          

      
 

      
If you are trying to understand the
            usage of the private number, then you will also need to
            understand the mapping when that exists.

      
 

      
And that will depend also on whether
            you are the administrator of the private numbering space or
            the public numbering space, or in the case of Centrex and
            business trunking, potentially both.

      
 

      
 

      
Keith

      

      

        

          

          From: Modern
            [mailto:modern-bounces@ietf.org]
            On Behalf Of Steve Donovan

            Sent: 26 May 2015 03:22

            To: modern@ietf.org

            Subject: Re: [Modern] TN, E.164, or Something Else?

          

        

        Private number spaces cannot be part of the publicly managed
        numbers.  They can and generally are mapped to public numbers
        but that is very different from me declaring that "+1 214 555
        0000" is a private number.  Private numbers only work in the
        context of devices used in the "domain" that is administering
        the private number space.

        

        I thought I had already said that private numbers are not a part
        of E.164.  They are, however, still TNs by the definition
        currently in the charter: "TNs, as defined in RFC3966, and
        blocks of TNs, that are used to initiate communication with
        another user of a service. "

        

        Steve

        

        
On 5/25/15 10:52 AM, Eric Burger
          wrote:

        

        

          
Now I am confused.

          


          

          
I was thinking we are building something more
            complex than just a registry of strings of digits to
            services and maybe routing. IANA (and a host of others) can
            do that today.

          


          

          
I thought the thing that needed solving, which
            Henning described at the BOF, was a how to provision and
            interface with a registry that maps strings of digits to
            services and maybe routing,
            where there was a clear need for some sort of
              (outside of scope) policy that needs to be enforced.

          


            

          
Am I wrong in thinking the entire point of
            MODERN is the mechanisms for policy enforcement?

          


          

          
By policy enforcement, I mean that, depending on
            jurisdiction, policies may be that only the national
            numbering authority can delegate the authority to allocate
            numbers to registered service providers. Or, a policy may be
            that only the national numbering authority can allocate
            numbers to users. Or, a policy may be that only the user can
            assign which services or service providers are allowed to
            service the number. What the policies are is out of scope
            for the work group. However, that there are policies I was
            under the impression is the whole point of the work group.

          


          

          
I am very leery of a policy that says that some
            part of the name space lives with the ITU-T and national
            numbering authorities, but another part of the name space is
            a free-for-all. What is to stop me from declaring “+1
            214-555-1000” to be just a private number?

          


          

          
If the proposal is that private numbers are not
            in the numbering (E.164? TN?) name space, then say so. Then
            Keith’s question becomes relevant: what is the use case?
            Cullen, is this in the Cisco world? Steven, is this in the
            Oracle world?

          


          

          
Thanks,

          
Eric

          


          

          

          

            

              
On May 24, 2015, at 1:27 AM, DRAGE, Keith
                (Keith) <keith.drage@alcatel-lucent.com>
                wrote:

              

              

                
                

                  
Adding
                        in private numbers introduces all sorts of
                        complications.

                  
 

                  
In
                        many cases there is a mapping between E.164
                        numbers and private numbers, i.e. the allocation
                        by the public administration of an E.164 number
                        automatically generates a valid private number,
                        and vice versa. In other cases there could be no
                        such mapping. When you apply the above to
                        international private networks, with DDI ranges
                        in multiple countries belonging to the same
                        private network, it gets even more complicated.
                      

                  
 

                  
There
                        are other complications resulting from the joint
                        ownership of some companies, resulting in an
                        owned companies network forming part of the
                        private numbering plan of both parent companies.

                  
 

                  
Unless
                        there is a proven use case from deployers of
                        private networks, I strongly propose that we
                        should avoid these cases altogether.

                  
 

                  
I'd
                        note by the way that I have not been pushing for
                        global uniqueness, only against the assumption
                        that the numbering plans are not locally unique
                        to the particular administration. I believe we
                        should assume local uniqueness, but that does
                        not presuppose global uniqueness.

                  
 

                  
regards

                  
 

                  
Keith

                  
 

                  
 

                  

                  

                    

                      

                      From:
                        Modern [mailto:modern-bounces@ietf.org]
                        On Behalf Of Steve Donovan

                        Sent: 20 May 2015 15:31

                        To: 
                          modern@ietf.org

                        Subject: Re: [Modern] TN, E.164,
                        or Something Else?

                      

                    

                    Eric,

                    

                    I'm not comfortable with saying that MODERN  is ONLY
                    about managing globally unique identifiers as this
                    rules out private numbering plans put in place by
                    enterprises.
                    

                    

                    Yes, MODERN is about globally unique identifiers
                    that have the format of a telephone number, but it
                    is also about private identifiers that also have the
                    format of a telephone number.

                    

                    Regards,

                    

                    Steve

                    

                    
On 5/18/15 5:23 PM,
                      Eric Burger wrote:

                    

                    

                      
Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.

A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy.


                      

                      

                      

                      
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


                    

                    

                  

                

                _______________________________________________

                Modern mailing list

                Modern@ietf.org

                https://www.ietf.org/mailman/listinfo/modern

              

            

          

          

          

          

          

          
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


        

        

      

    

    

  


--------------040501010800050003060804--


From nobody Wed May 27 07:46:54 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 9DD2B1B2BDC for ; Wed, 27 May 2015 07:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JX33I6IM1gyb for ; Wed, 27 May 2015 07:46:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3891B2BB5 for ; Wed, 27 May 2015 07:46:52 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4REkfZH034494 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 May 2015 09:46:51 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Steve Donovan" 
Date: Wed, 27 May 2015 09:46:41 -0500
Message-ID: <38D20186-9C2F-446F-A5D7-2D99C9701AE9@nostrum.com>
In-Reply-To: <5565D61B.2060101@usdonovans.com>
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>  <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com>  <2BD95645-8BC7-4625-910D-A07A33638C88@chriswendt.net> <4978F6B6-0A98-477A-BDB4-8A3335930AEA@nostrum.com> <5565D61B.2060101@usdonovans.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: modern@ietf.org
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 27 May 2015 14:46:53 -0000

On 27 May 2015, at 9:35, Steve Donovan wrote:

> I think we're pretty close.
>
> Here's the paragraph in question:
>
> The working group will define an information management framework for 
> the roles
> and functions involved in associating information with one or more TNs 
> in an IP
> environment.  The working group will also define protocol mechanisms 
> to support
> the interactions between the functions defined by the framework. This 
> includes
> either recommending or defining protocol mechanisms for acquiring, 
> associating
> and resolving TNs.  The protocol mechanism for acquiring TNs will 
> provide an
> enrollment process for the entities that use and manage TNs. TNs may 
> either be
> managed in a hierarchical tree, or in a distributed peer-to-peer 
> architecture.
> Privacy of the managed data and security of the resource will be 
> primary
> considerations.  The protocol mechanism for resolving TNs will allow 
> entities
> such as service providers, devices, and applications to access data 
> related to
> TNs.  Maintaining reliability, real time application performance, 
> security and
> privacy are primary considerations.  The working group will take into
> consideration existing IETF work including ENUM, SPEERMINT, DRINKS and 
> SCIM.
>
> How about if we change the second sentence from "...The working group 
> will define protocol mechanisms..." to "...The working group will 
> ___identify___ protocol mechanisms.
>
> The next sentence already talks about recommending or defining. Maybe 
> if we change "...This includes
> either recommending or defining protocol mechanisms for acquiring, 
> associating
> and resolving TNs..." to "...This includes
> either recommending or defining protocol mechanisms for acquiring, 
> associating
> and resolving TNs, ___with a preference for use of existing 
> transports___".
>
> This should hopefully address the concern.

s/"existing transports"/"existing protocol mechanisms" and I think it's 
good. (The TSV guys are protective of the word "transport" :-) )


From nobody Wed May 27 08:37:46 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 EF56C1B2DA0 for ; Wed, 27 May 2015 08:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 J6ucPbwI2HN9 for ; Wed, 27 May 2015 08:37:41 -0700 (PDT)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A38F1A8A60 for ; Wed, 27 May 2015 08:37:41 -0700 (PDT)
Received: by qgfa63 with SMTP id a63so5022714qgf.0 for ; Wed, 27 May 2015 08:37:40 -0700 (PDT)
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=9jDg3Cp03EQnqAAraqMQTsuOa73c9FVbZarTlxNNFSo=; b=RggncHt5kT9a6B+DZaet9HSC4Ll/hlbsDgdd12r1+HqRkX+frnPt7Gbl4Ga2bQ+Mrk tLlhH70vguDnbsF3euYxuLGl90StkW3dPCb67GKgvw+37MyVgqLk8ojvU60j0CH5/3l/ 0R66/kREi74rRW25cP7H1khji5Dbbzveyv/Ra4pOkvylEBNYvRSYajOTink91/Y6Q55Y vVquucVB2IqdnHBKRa1CpOEfPahEUV9yPNpYh25y/A/0aBzOp5T7JU2mdhp04NtUe9y3 U0Bih366ad5t8L+obEUPex0G6b7ZO+C97TcgKP9+0Pt71jeAzJrCjVoCd/FSA7fnSkgw 3//A==
X-Gm-Message-State: ALoCoQm6APhaus7AaNMMlxBOPL+QmAXspYfEeqpEJRIlX9ifru0kaPy8oF5hBsuAPEiNbh7ChxrV
X-Received: by 10.140.196.140 with SMTP id r134mr41756386qha.60.1432741060148;  Wed, 27 May 2015 08:37:40 -0700 (PDT)
Received: from [172.24.127.2] (cpe-173-95-186-253.nc.res.rr.com. [173.95.186.253]) by mx.google.com with ESMTPSA id 64sm10423842qkw.13.2015.05.27.08.37.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 May 2015 08:37:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F8D6418E-BE3E-41AE-B9F0-22B221B6917A"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mark R Lindsey 
In-Reply-To: <5565D7A6.5060106@usdonovans.com>
Date: Wed, 27 May 2015 11:37:38 -0400
Message-Id: <5C3C5829-A733-41CC-998B-0B0B3F05658C@e-c-group.com>
References: <3C4797ED-1162-4E5B-B081-6C546DD62C2A@standardstrack.com> <555C9AAD.4080806@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971B7C1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <12180B6D-426A-49DA-9D65-FAC676587E8D@standardstrack.com> <5563D8AB.5090407@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6971D635@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5565D7A6.5060106@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "DRAGE, Keith \(Keith\)" , "modern@ietf.org" 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 27 May 2015 15:37:46 -0000

--Apple-Mail=_F8D6418E-BE3E-41AE-B9F0-22B221B6917A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Steve --=20

An upside to handling private number space is this: Private number =
spaces follow the general Internet pattern of defining domains to give =
context.
-- Email addresses have a domain.
-- All DNS zones have a domain, which might just be the root domain, "."
-- The tel URI already has a phone-context idea=20

Where we don't have an explicit domain, a new, invisible level of =
indirection is added:
-- Private IP address space doesn't indicate its context

So far, we're all thinking about E.164 as the root domain for TNs. Let's =
plan to make domain specific, and E.164 should be one of them.

If we don't make the domain explicit, private number spaces will be =
created by replicating the numbering plan. For example, folks replicate =
the routing table every time a new private Internet routing domain / VRF =
instance is created.  And for telephony, without an explicit indicator =
of context, each system that needs its private space will run another =
instance of the TN-management system using the MODERN-defined =
mechanisms.  For example, ALU's phone system might end up having one =
server for managing internal telephone extensions, and a separate server =
involved in E.164 TNs.


Downsides to managing private number spaces:

-- We'll need to spend time thinking about the mapping. Is it a matter =
of defining the canonical name and its variants? Is this private address =
merely a speed-dial feature? Does the mapping between the extension =
"2207" and the E.164 EN "+12293160013" mean that the linking between the =
two needs specific authority delegated?

-- It'll make any resulting standards longer, more complicated, and =
therefore more likely to be buggy and ignored.


I hope to convince everyone to avoid optional parameters, because most =
telecom developers won't implement any optional parameter until forced. =
This leads to a mixture of implementations with and without support for =
any given optional parameter, putting us all in worse shape than if you =
had never define the optional parameter. E.g., look at the tel URI, and =
how often the phone-context is actually used in real networks. Though it =
might be a fine idea, phone-context is effectively a wart on RFC 3966 =
for practical application because interop engineers have to ensure both =
sides don't use it.



Mark





> On May 27, 2015, at 10:41 , Steve Donovan  =
wrote:
>=20
> Keith,
>=20
> I don't see this as a reason for precluding looking at private number =
spaces in the MODERN charter.=20
>=20
> The mapping, should there be one, will be handled in context of the =
private space administrator, whether directly or delegated.  It =
shouldn't have any impact on the public numbering space.
>=20
> It might be as simple as having an optional information element that =
includes the mapping for operations within the private number space.  =
But this can be addressed by the working group.
>=20
> Steve
>=20
> On 5/26/15 3:34 PM, DRAGE, Keith (Keith) wrote:
>> It is the mere fact that they are mapped to public network numbers =
that causes the issues.
>> =20
>> If you are trying to understand the usage of the private number, then =
you will also need to understand the mapping when that exists.
>> =20
>> And that will depend also on whether you are the administrator of the =
private numbering space or the public numbering space, or in the case of =
Centrex and business trunking, potentially both.
>> =20
>> =20
>> Keith
>>=20
>> From: Modern [mailto:modern-bounces@ietf.org =
] On Behalf Of Steve Donovan
>> Sent: 26 May 2015 03:22
>> To: modern@ietf.org 
>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>=20
>> Private number spaces cannot be part of the publicly managed numbers. =
 They can and generally are mapped to public numbers but that is very =
different from me declaring that "+1 214 555 0000" is a private number.  =
Private numbers only work in the context of devices used in the "domain" =
that is administering the private number space.
>>=20
>> I thought I had already said that private numbers are not a part of =
E.164.  They are, however, still TNs by the definition currently in the =
charter: "TNs, as defined in RFC3966, and blocks of TNs, that are used =
to initiate communication with another user of a service. "
>>=20
>> Steve
>>=20
>> On 5/25/15 10:52 AM, Eric Burger wrote:
>>> Now I am confused.
>>>=20
>>> I was thinking we are building something more complex than just a =
registry of strings of digits to services and maybe routing. IANA (and a =
host of others) can do that today.
>>>=20
>>> I thought the thing that needed solving, which Henning described at =
the BOF, was a how to provision and interface with a registry that maps =
strings of digits to services and maybe routing, where there was a clear =
need for some sort of (outside of scope) policy that needs to be =
enforced.
>>>=20
>>> Am I wrong in thinking the entire point of MODERN is the mechanisms =
for policy enforcement?
>>>=20
>>> By policy enforcement, I mean that, depending on jurisdiction, =
policies may be that only the national numbering authority can delegate =
the authority to allocate numbers to registered service providers. Or, a =
policy may be that only the national numbering authority can allocate =
numbers to users. Or, a policy may be that only the user can assign =
which services or service providers are allowed to service the number. =
What the policies are is out of scope for the work group. However, that =
there are policies I was under the impression is the whole point of the =
work group.
>>>=20
>>> I am very leery of a policy that says that some part of the name =
space lives with the ITU-T and national numbering authorities, but =
another part of the name space is a free-for-all. What is to stop me =
from declaring =93+1 214-555-1000=94 to be just a private number?
>>>=20
>>> If the proposal is that private numbers are not in the numbering =
(E.164? TN?) name space, then say so. Then Keith=92s question becomes =
relevant: what is the use case? Cullen, is this in the Cisco world? =
Steven, is this in the Oracle world?
>>>=20
>>> Thanks,
>>> Eric
>>>=20
>>>=20
>>>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) =
> =
wrote:
>>>>=20
>>>> Adding in private numbers introduces all sorts of complications.
>>>> =20
>>>> In many cases there is a mapping between E.164 numbers and private =
numbers, i.e. the allocation by the public administration of an E.164 =
number automatically generates a valid private number, and vice versa. =
In other cases there could be no such mapping. When you apply the above =
to international private networks, with DDI ranges in multiple countries =
belonging to the same private network, it gets even more complicated.
>>>> =20
>>>> There are other complications resulting from the joint ownership of =
some companies, resulting in an owned companies network forming part of =
the private numbering plan of both parent companies.
>>>> =20
>>>> Unless there is a proven use case from deployers of private =
networks, I strongly propose that we should avoid these cases =
altogether.
>>>> =20
>>>> I'd note by the way that I have not been pushing for global =
uniqueness, only against the assumption that the numbering plans are not =
locally unique to the particular administration. I believe we should =
assume local uniqueness, but that does not presuppose global uniqueness.
>>>> =20
>>>> regards
>>>> =20
>>>> Keith
>>>> =20
>>>> =20
>>>>=20
>>>> From: Modern [mailto:modern-bounces@ietf.org =
] On Behalf Of Steve Donovan
>>>> Sent: 20 May 2015 15:31
>>>> To: modern@ietf.org 
>>>> Subject: Re: [Modern] TN, E.164, or Something Else?
>>>>=20
>>>> Eric,
>>>>=20
>>>> I'm not comfortable with saying that MODERN  is ONLY about managing =
globally unique identifiers as this rules out private numbering plans =
put in place by enterprises.=20
>>>>=20
>>>> Yes, MODERN is about globally unique identifiers that have the =
format of a telephone number, but it is also about private identifiers =
that also have the format of a telephone number.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>>> On 5/18/15 5:23 PM, Eric Burger wrote:
>>>>> Something I have been mulling about is the focus (and amount of =
list traffic) discussing whether the scope of MODERN is E.164 numbers, =
=93telephone numbers,=94 or something else.
>>>>>=20
>>>>> We seem to get very emotional about E.164 numbers. Perhaps rightly =
so. An E.164 number carries a lot of a=92priori regulatory baggage. By =
definition, the ITU-T assigns country codes. National numbering =
authorities allocate numbers to service providers. Service providers =
manage them for users.
>>>>>=20
>>>>> A =93telephone number=94 spawns the debate as to whether it is, in =
fact, a =91telephone=92 number. Given Henning=92s presentation, the =
value of the telephone number is global routing and global understanding =
for 5/7ths of the world using romanized arabic script. Given that, the =
people who worry that =93telephone number=94 is just a code word for =
E.164 number are most likely correct. This spills into the whole =93It =
is not an E.164 number, it is the ABNF for an E.164 number (see =
RFC3966).=94 I.e., it looks, smells, and tastes like a rose.
>>>>>=20
>>>>> Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>> Modern@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/modern =

>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/modern =

>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/modern =

>>=20
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern

              --- mailto:mark@ecg.co=20
                  tel:+1-229-316-0013=20
                  http://ecg.co/lindsey=20



--Apple-Mail=_F8D6418E-BE3E-41AE-B9F0-22B221B6917A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Steve -- 

An upside to handling private number =
space is this: Private number spaces follow the general Internet pattern =
of defining domains to give context.
-- Email =
addresses have a domain.
-- All DNS zones have a =
domain, which might just be the root domain, "."
-- =
The tel URI already has a phone-context idea 

Where we don't have an =
explicit domain, a new, invisible level of indirection is =
added:
-- Private IP address space doesn't indicate =
its context

So =
far, we're all thinking about E.164 as the root domain for TNs. Let's =
plan to make domain specific, and E.164 should be one of them.

If we don't make the =
domain explicit, private number spaces will be created by replicating =
the numbering plan. For example, folks replicate the routing table every =
time a new private Internet routing domain / VRF instance is created. =
 And for telephony, without an explicit indicator of context, each =
system that needs its private space will run another instance of the =
TN-management system using the MODERN-defined mechanisms.  For =
example, ALU's phone system might end up having one server for managing =
internal telephone extensions, and a separate server involved in E.164 =
TNs.


Downsides to managing private number =
spaces:

-- =
We'll need to spend time thinking about the mapping. Is it a matter of =
defining the canonical name and its variants? Is this private address =
merely a speed-dial feature? Does the mapping between the extension =
"2207" and the E.164 EN "+12293160013" mean that the linking between the =
two needs specific authority delegated?

-- It'll make any resulting standards =
longer, more complicated, and therefore more likely to be buggy and =
ignored.


I hope to convince everyone to avoid =
optional parameters, because most telecom developers won't implement any =
optional parameter until forced. This leads to a mixture of =
implementations with and without support for any given optional =
parameter, putting us all in worse shape than if you had never define =
the optional parameter. E.g., look at the tel URI, and how often the =
phone-context is actually used in real networks. Though it might be a =
fine idea, phone-context is effectively a wart on RFC 3966 for practical =
application because interop engineers have to ensure both sides don't =
use it.



Mark






On May 27, 2015, at 10:41 , Steve Donovan <srdonovan@usdonovans.com> wrote:


 =20
    
 =20
  

    Keith,

    

    I don't see this as a reason for precluding looking at private
    number spaces in the MODERN charter. 

    

    The mapping, should there be one, will be handled in context of the
    private space administrator, whether directly or delegated.  It
    shouldn't have any impact on the public numbering space.

    

    It might be as simple as having an optional information element that
    includes the mapping for operations within the private number
    space.  But this can be addressed by the working group.

    

    Steve

    

    
On 5/26/15 3:34 PM, DRAGE, Keith
      (Keith) wrote:

    

    

      
      
      
It is the mere =
fact that they are
            mapped to public network numbers that causes the issues.
          

      
 

      
If you are trying =
to understand the
            usage of the private number, then you will also need to
            understand the mapping when that exists.

      
 

      
And that will =
depend also on whether
            you are the administrator of the private numbering space or
            the public numbering space, or in the case of Centrex and
            business trunking, potentially both.

      
 

      
 

      
Keith

      

      

        

          

          From: Modern
            [mailto:modern-bounces@ietf.org=
]
            On Behalf Of Steve Donovan

            Sent: 26 May 2015 03:22

            To: modern@ietf.org

            Subject: Re: [Modern] TN, E.164, or =
Something Else?

          

        

        Private number spaces cannot be part of the publicly managed
        numbers.  They can and generally are mapped to public =
numbers
        but that is very different from me declaring that "+1 214 555
        0000" is a private number.  Private numbers only work in =
the
        context of devices used in the "domain" that is administering
        the private number space.

        

        I thought I had already said that private numbers are not a part
        of E.164.  They are, however, still TNs by the definition
        currently in the charter: "TNs, as defined in RFC3966, and
        blocks of TNs, that are used to initiate communication with
        another user of a service. "

        

        Steve

        

        
On 5/25/15 10:52 AM, Eric Burger
          wrote:

        

        

          
Now I am confused.

          


          

          
I was thinking we are building something more
            complex than just a registry of strings of digits to
            services and maybe routing. IANA (and a host of others) can
            do that today.

          


          

          
I thought the thing that needed solving, which
            Henning described at the BOF, was a how to provision and
            interface with a registry that maps strings of digits to
            services and maybe routing,
            where there was a clear need for some sort of
              (outside of scope) policy that needs to be =
enforced.

          


            

          
Am I wrong in thinking the entire point of
            MODERN is the mechanisms for policy enforcement?

          


          

          
By policy enforcement, I mean that, depending =
on
            jurisdiction, policies may be that only the national
            numbering authority can delegate the authority to allocate
            numbers to registered service providers. Or, a policy may be
            that only the national numbering authority can allocate
            numbers to users. Or, a policy may be that only the user can
            assign which services or service providers are allowed to
            service the number. What the policies are is out of scope
            for the work group. However, that there are policies I was
            under the impression is the whole point of the work =
group.

          


          

          
I am very leery of a policy that says that =
some
            part of the name space lives with the ITU-T and national
            numbering authorities, but another part of the name space is
            a free-for-all. What is to stop me from declaring =93+1
            214-555-1000=94 to be just a private number?

          


          

          
If the proposal is that private numbers are =
not
            in the numbering (E.164? TN?) name space, then say so. Then
            Keith=92s question becomes relevant: what is the use case?
            Cullen, is this in the Cisco world? Steven, is this in the
            Oracle world?

          


          

          
Thanks,

          
Eric

          


          

          

          

            

              
On May 24, 2015, at 1:27 AM, DRAGE, Keith
                (Keith) <keith.drage@alcatel-lucent.com>
                wrote:

              

              

                
                

                  
Adding
                        in private numbers introduces all sorts of
                        complications.

                  
 

                  
In
                        many cases there is a mapping between E.164
                        numbers and private numbers, i.e. the allocation
                        by the public administration of an E.164 number
                        automatically generates a valid private number,
                        and vice versa. In other cases there could be no
                        such mapping. When you apply the above to
                        international private networks, with DDI ranges
                        in multiple countries belonging to the same
                        private network, it gets even more complicated.
                      

                  
 

                  
There
                        are other complications resulting from the joint
                        ownership of some companies, resulting in an
                        owned companies network forming part of the
                        private numbering plan of both parent =
companies.

                  
 

                  
Unless
                        there is a proven use case from deployers of
                        private networks, I strongly propose that we
                        should avoid these cases =
altogether.

                  
 

                  
I'd
                        note by the way that I have not been pushing for
                        global uniqueness, only against the assumption
                        that the numbering plans are not locally unique
                        to the particular administration. I believe we
                        should assume local uniqueness, but that does
                        not presuppose global =
uniqueness.

                  
 

                  
regards

                  
 

                  
Keith

                  
 

                  
 

                  

                  

                    

                      

                      From:
                        Modern [mailto:modern-bounces@ietf.org]
                        On Behalf Of Steve Donovan

                        Sent: 20 May 2015 15:31

                        To: 
                          modern@ietf.org

                        Subject: Re: [Modern] TN, =
E.164,
                        or Something Else?

                      

                    

                    Eric,

                    

                    I'm not comfortable with saying that MODERN  is =
ONLY
                    about managing globally unique identifiers as this
                    rules out private numbering plans put in place by
                    enterprises.
                    

                    

                    Yes, MODERN is about globally unique identifiers
                    that have the format of a telephone number, but it
                    is also about private identifiers that also have the
                    format of a telephone number.

                    

                    Regards,

                    

                    Steve

                    

                    
On 5/18/15 5:23 PM,
                      Eric Burger wrote:

                    

                    

                      
Something I have been =
mulling about is the focus (and amount of list traffic) discussing =
whether the scope of MODERN is E.164 numbers, =93telephone numbers,=94 =
or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. =
An E.164 number carries a lot of a=92priori regulatory baggage. By =
definition, the ITU-T assigns country codes. National numbering =
authorities allocate numbers to service providers. Service providers =
manage them for users.

A =93telephone number=94 spawns the debate as to whether it is, in fact, =
a =91telephone=92 number. Given Henning=92s presentation, the value of =
the telephone number is global routing and global understanding for =
5/7ths of the world using romanized arabic script. Given that, the =
people who worry that =93telephone number=94 is just a code word for =
E.164 number are most likely correct. This spills into the whole =93It =
is not an E.164 number, it is the ABNF for an E.164 number (see =
RFC3966).=94 I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing =
globally unique identifiers that have a syntax of up to 15 decimal =
digits that have some hierarchical authorities mixed in to lock down who =
can and cannot request and assign numbers? Those authorities can be an =
opaque thingbat, because that is where we get into the policy bits, and =
everyone on the list swears MODERN will not touch policy.


                      

                      
=

                      

                      
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


                    

                    

                  

                

                _______________________________________________

                Modern mailing list

                Modern@ietf.org

                https://www.ietf.org=
/mailman/listinfo/modern

              

            

          

          

          

          

          

          
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org=
/mailman/listinfo/modern


        

        

      

    

    

  


_______________________________________________
Modern =
mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

  =
   =
   =
   =
   =
--- mailto:mark@ecg.co 
 =
    =
   =
   =
   =
   =
 tel:+1-229-316-0013 
                  http://ecg.co/lindsey 


=

--Apple-Mail=_F8D6418E-BE3E-41AE-B9F0-22B221B6917A--


From nobody Wed May 27 14:32:11 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 D57281AC41B for ; Wed, 27 May 2015 14:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level: 
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gAn8QEQKujwl for ; Wed, 27 May 2015 14:32:02 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 841B31AC40E for ; Wed, 27 May 2015 14:32:02 -0700 (PDT)
Received: (qmail 12734 invoked by uid 0); 27 May 2015 21:31:57 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 27 May 2015 21:31:57 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id Z94J1q00z1MNPNq0194MFG; Wed, 27 May 2015 15:04:22 -0600
X-Authority-Analysis: v=2.1 cv=efyuId0H c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=h1PgugrvaO0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=doUQZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=5b3Chl7SFygC0E7W7ScA:9 a=76bxv8w_EVnjo5YY:21 a=NH4lH-OsDN-jwm8s:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=OtSP2khXrCftyCH1UqcA:9 a=ylOOC2o1ixwJrnnt:21 a=jDV6mGxcPVLnZbbq:21 a=qXZODu3-bno3ut3S:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=Pw54Ht9mVdTlLu9l+4chnM96CdkozxIzEtf3Jms9eKM=;  b=l64UdLLBE8kiHx1bHkBCHtVMftq7xitAhiYLzd4fVvjWep/O/s4EsQ6UBJVXu12hCmRyiqfsX67sRFU3TibLnH5DDXbroTOW5ufGS2SScs/rZWJNZ3CnCbZTlAHwwxGh;
Received: from [108.56.131.201] (port=53240 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YxicD-0007t1-N1; Wed, 27 May 2015 15:11:54 -0600
User-Agent: Microsoft-MacOutlook/14.5.1.150515
Date: Wed, 27 May 2015 17:11:46 -0400
From: Richard Shockey 
To: Mary Barnes , , , 
Message-ID: 
Thread-Topic: [cnit] CNIT Charter bashing..
References:   
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3515591513_968782"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] [cnit] CNIT Charter bashing..
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, 27 May 2015 21:32:08 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3515591513_968782
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


FYI  The usual suspects are on the warpath.  They have friends in Ottawa an=
d
London.

https://www.fcc.gov/blog/another-win-consumers



=8B=20
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richardshockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From:  Mary Barnes 
Date:  Friday, May 22, 2015 at 12:58 PM
To:  Richard Shockey 
Subject:  Re: [cnit] CNIT Charter bashing..

Attached is what I have at this point. Really, the only thing I'm strugglin=
g
with is the milestones as I don't think we can request publication of the
data object and headers without having defined the trust model.  However, I
think it's important that we're clear that we anticipate getting the
proposed mechanism defined early and then hammer out the trust model.  We
could just do two milestones which is what Martini did: 1) Problem Statemen=
t
and Requirements and 2) Solution.  The charter provides the detailed
deliverables in the body earlier and I'm not sure that we would want things
in separate documents UNLESS we think those mechanisms could be used for
other things. But, I don't think so - I think the trust model has to be
ingrained with those.

Let me know your thoughts.

Regards,
Mary.

On Fri, May 22, 2015 at 11:11 AM, Mary Barnes 
wrote:
> Just FYI, I'm working on updates to this charter and will ship to you sho=
rtly
> for review.  We can then repost on CNIT/DISPATCH and see if we can get th=
is
> wrapped up.  I will separately ping Ben and let him know that this ought =
to be
> ready for him to send to the IESG soon and stress the importance of doing=
 this
> work in the IETF and the careful selection of chairs.
>=20
> Regards,
> Mary.
>=20
> On Mon, Mar 30, 2015 at 10:03 AM, Richard Shockey  wr=
ote:
>>=20
>> My running assumption after DISPATCH last week is we have a conditional =
go
>> ahead to proceed to a WG if we can answer the questions posed which, if
>> memory serves me,
>>=20
>> A. Refine and or further define the problem we are trying to solve.
>>=20
>> B. Include into the requirements the Trust Validation concept.  I presum=
e
>> Brian is willing to help edit text on that.
>>=20
>> I do have a issue for the AD=B9s. I really want to know up front if we hav=
e to
>> define a new header here.
>>=20
>> I would like to know in advance the level of torture we are going to hav=
e to
>> deal with.
>>=20
>>=20
>> ************
>> CNIT Charter [Calling Name Identity Trust]
>> =20
>> WG Chairs TBD:
>> =20
>> Calling Name Delivery [CNAM] is currently a string of 15 ASCII and/or
>> potentially 50 characters of information associated with a specific E.16=
4
>> calling party number in the Public Switched Telephone Network [PSTN] as
>> defined in ITU-T Recommendation I.251.9. This PSTN data is sent by the
>> originating network only at the specific request of the terminating netw=
ork
>> via a SS7 Transaction Application Part [TCAP] response message.  In the
>> Session Initiation Protocol [SIP] this information can be inserted into =
the
>> FROM: part of the originating INVITE message or imbedded in the Provider
>> Asserted Identity [PAI] header.
>> =20
>> As with the originating source telephone number, this data can be altere=
d in
>> transit creating a variety of malicious abuses similar to the ones ident=
ified
>> by the IETF STIR working group.
>> =20
>> The purpose of the CNIT working group will be to define a data structure=
, a
>> new SIP header or repurpose an existing SIP header to carry an advanced
>> form(s) of trusted multi media CNAM as well as information from a STIR
>> Validation Authority.  The purpose of this work is to present to the SIP
>> called party trusted information from the calling party in order that th=
e
>> called party make a more reasoned and informed judgment on whether to ac=
cept
>> the INVITE or not.
>> =20
>> The working group will not invalidate any existing SIP mechanism for
>> anonymous calling.
>> =20
>> The working group will not define registration, provisioning or data que=
ry
>> response mechanisms for the creation and storage of the CNIT data object=
(s) .
>> =20
>> The working group will, to the best of its ability, reuse existing IETF
>> protocols.
>> =20
>> Full Internationalization of the Calling Name Identity Trust data object=
(s)
>> is a requirement.
>> =20
>> The working group will closely work with the IETF STIR working group
>> =20
>> The working group will immediately liaison with 3GPP SA-1 and other
>> appropriate SDO=B9s in order to coordinate efforts.
>> =20
>> The working group will coordinate with National Numbering Authorities an=
d
>> National Regulatory Authorities as needed.
>> =20
>> The working group will deliver the flowing.
>> =20
>> =B7     A problem statement and requirements detailing the current deploym=
ent
>> environment and situations that motivate work on Calling Name Identity T=
rust.
>>=20
>> =B7     Define either a new SIP header or document a repurpose of an SIP
>> existing header for Calling Name Identify Trust data
>>=20
>> =B7     Define a data model for the Calling Name Identity Trust object (s)
>> which may include various forms of multimedia data.
>>=20
>> =B7     Define a Trust Mechanism for CNIT data. (Brian text?)
>>=20
>> =B7     Deliver an analysis of privacy implications of the proposed Callin=
g
>> Name Identity Trust mechanism.
>>=20
>> =20
>> =20
>> Milestones:
>> =20
>> January 2016 : Problem Statement and Requirements for Calling Name Ident=
ity
>> Trust
>> =20
>> April 2016 : Data Objects and SIP headers for Calling Name Identity Trus=
t
>> =20
>> November 2016 :  Trust Mechanism for Calling Name Identity Trust
>> =20
>> =20
>> =20
>> =20
>> =8B=20
>> Richard Shockey
>> Shockey Consulting LLC
>> Chairman of the Board SIP Forum
>> www.shockey.us 
>> www.sipforum.org 
>> richardshockey.us 
>> Skype-Linkedin-Facebook rshockey101
>> PSTN +1 703-593-2683 
>>=20
>>=20
>> _______________________________________________
>> cnit mailing list
>> cnit@ietf.org
>> https://www.ietf.org/mailman/listinfo/cnit
>>=20
>=20




--B_3515591513_968782
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable



FYI =
 The usual suspects are on the warpath.  They have friends in Otta=
wa and London.

https://www.fcc.gov/blog/another-win-consumers



— 
<=
div>Richard Shockey
Shockey Consulting LLC
Chairman of t=
he Board SIP Forum
www.shockey.us
www.sipforum.org
=

richard<at>shockey.us
Skype-Linkedin-Facebook rshockey1=
01
PSTN +1 703-593-2683


From:  Mary Barnes <mary.ietf.barnes@gmail.com>
<=
span style=3D"font-weight:bold">Date:  Friday, May 22, 2015 at 12:58 PM=

To:  Richard Shockey <richard@shockey.us>
Subject:  Re: [cnit] CNIT Charter bashing..

Attached is what I have at this point. Really, the=
 only thing I'm struggling with is the milestones as I don't think we can re=
quest publication of the data object and headers without having defined the =
trust model.  However, I think it's important that we're clear that we =
anticipate getting the proposed mechanism defined early and then hammer out =
the trust model.  We could just do two milestones which is what Martini=
 did: 1) Problem Statement and Requirements and 2) Solution.  The chart=
er provides the detailed deliverables in the body earlier and I'm not sure t=
hat we would want things in separate documents UNLESS we think those mechani=
sms could be used for other things. But, I don't think so - I think the trus=
t model has to be ingrained with those.   

Let =
me know your thoughts.

Regards,
Mary.
=


On Fri, Ma=
y 22, 2015 at 11:11 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Just FYI, I'm worki=
ng on updates to this charter and will ship to you shortly for review. =
 We can then repost on CNIT/DISPATCH and see if we can get this wrapped up.&=
nbsp; I will separately ping Ben and let him know that this ought to be read=
y for him to send to the IESG soon and stress the importance of doing this w=
ork in the IETF and the careful selection of chairs.

Rega=
rds,
Mary.

On Mon, Mar 30, 2015 at 10:03 AM, Richard Sho=
ckey <richard@shockey.us> wrote:

My runn=
ing assumption after DISPATCH last week is we have a conditional go ahead to=
 proceed to a WG if we can answer the questions posed which, if memory serve=
s me,

A. Refine and or further define the problem w=
e are trying to solve.

B. Include into the requirem=
ents the Trust Validation concept.  I presume Brian is willing to help =
edit text on that.

I do have a issue for the ADR=
17;s. I really want to know up front if we have to define a new header here.=


I would like to know in advance the level of tortu=
re we are going to have to deal with.


************
CNIT Charter [Calling Name Identity=
 Trust]
 
WG Chairs TBD:
&=
nbsp;
Calling Name Delivery [CNAM] is current=
ly a string of 15
ASCII and/or potentially 50 characters of information associated with a
specific E.164 calling party number in the Public Switched Telephone Networ=
k
[PSTN] as defined in ITU-T Recommendatio=
n I.251.9. This PSTN data is sent by the
originating network only at the specific request of the terminating network=
 via
a SS7 Transaction Application Part [TCAP] response message.  In the Se=
ssion Initiation Protocol [SIP] this
information can be inserted into the FROM: part of the originating INVITE
message or imbedded in the Provider Asserted Identity [PAI] header.<=
u>
 
=
As with the originating source telephone number, this data
can be altered in transit creating a variety of malicious abuses similar to=
 the
ones identified by the IETF STIR working group.
 
The purpose of the C=
NIT working group will be to define a data
structure, a new SIP header or repurpose an existing SIP header to carry an=

advanced form(s) of trusted multi media CNAM as well as information from a =
STIR
Validation Authority.  The purpose of
this work is to present to the SIP called party trusted information from th=
e
calling party in order that the called party make a more reasoned and infor=
med
judgment on whether to accept the INVITE or not.
 
The working group w=
ill not invalidate any existing SIP
mechanism for anonymous calling.  
 
The working group will not d=
efine registration, provisioning
or data query response mechanisms for the creation and storage of the CNIT =
data
object(s) .
 
<=
p class=3D"MsoNormal">The working group will, to the best of its ability, reus=
e existing
IETF protocols.
 <=
/p>
Full Internationalization of the Calling Name Identi=
ty Trust
data object(s) is a requirement.
<=
/u> 
The working group will closely work=
 with the IETF STIR
working group
 
The working group will immediately liaison with 3GPP S=
A-1 and
other appropriate SDO’s in order to coordinate efforts.=

 
The wo=
rking group will coordinate with National Numbering
Authorities and National Regulatory Authorities as needed.
 
The worki=
ng group will deliver the flowing.
=
 
=B7     
A problem statement and requirements detailing
the current deployment environment and situations that motivate work on Cal=
ling
Name Identity Trust.
=B7     
Define either a new SIP header or
document a repurpose of an SIP existing header for Calling Name Identify Tr=
ust
data
=B7     
Define a data model for the Calling
Name Identity Trust object (s) which may include various forms of multimedi=
a
data.
=B7     
Define a Trust Mechanism for CNIT data.
(Brian text?) 
=B7     
Deliver an analysis of privacy
implications of the proposed Calling Name Identity Trust mechanism.<=
u>
 
=
 
Milestones:
 
January 2016=
 : Problem Statement and
Requirements for Calling Name Identity Trust
 
April 
2016 : Data Objects and SIP headers for Calling Name Identity Trust<=
u>
 
=
November 2016 :  Trust Mechanism for Calling Name Identity
Trust
 
 
 <=
/u>
 
— 
=

Richard Shockey
Shockey Cons=
ulting LLC
Chairman of the Board SIP Forum
richard=
<at>shockey.us
Skype-Linkedin-Facebook rshockey101


_____________________=
__________________________

cnit mailing list
cnit@ie=
tf.org
https://www.ietf.org/mailman/listinfo/cnit





--B_3515591513_968782--



From nobody Wed May 27 19:06: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 7D2A41B2B8E for ; Wed, 27 May 2015 19:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 oX0HMNdY55RA for ; Wed, 27 May 2015 19:06:00 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409D21B2B7C for ; Wed, 27 May 2015 19:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=XcpqW0pgHTlFK2oJRbDJo5hF6fRGyRRAnp7PEOdygyE=;  b=gtswUCzHzWBgVuY+t0xoztB12MTkmBSRKywYL+VxO0OSNHF9WN4l/zMOirrE1To9EKZ6MBNgZfvqudljMfoQ4EEOPPYFfQQE8sC4BrhwgnHyvuZ5dCnSB/55a6u9Hyg7yM3bfhvoTXuCKvd01SmdJ44tabhVBfZkqVsBQkPCmts=;
Received: from [70.166.72.189] (port=25478 helo=[10.48.4.81]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YxnCm-0003tW-OU for modern@ietf.org; Wed, 27 May 2015 19:05:59 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_A07DB066-6950-468E-B5B7-760D08D942B3"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Burger 
In-Reply-To: <38D20186-9C2F-446F-A5D7-2D99C9701AE9@nostrum.com>
Date: Wed, 27 May 2015 22:05:54 -0400
Message-Id: <9CE3AD2B-7977-48D4-B17A-E848A6B3AC96@standardstrack.com>
References:  <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> <79D929AC-2107-4B7A-BBD7-83C03BDB661D@nostrum.com>  <6D95D9A9-30AE-4684-8248-26820C878818@nostrum.com>  <2BD95645-8BC7-4625-910D-A07A33638C88@chriswendt.net> <4978F6B6-0A98-477A-BDB4-8A3335930AEA@nostrum.com> <5565D61B.2060101@usdonovans.com> <38D20186-9C2F-446F-A5D7-2D99C9701AE9@nostrum.com>
To: modern@ietf.org
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] TN, E.164, or Something Else?
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, 28 May 2015 02:06:01 -0000

--Apple-Mail=_A07DB066-6950-468E-B5B7-760D08D942B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I am all for the charter saying the work group will produce [a set of] =
protocol(s) for provisioning / allocating =E2=80=98numbers=E2=80=99 that =
may or may not be private.

I seriously question the wisdom of chartering an IETF work group to =
build a data model.

The IETF is really good at developing protocols.

The IETF is spotty at best at developing stand-alone data models.

The idea of a data model that could be transported over REST, XMPP, =
SMTP, or foobar sounds intellectually stimulating but practically worse =
than useless. It encourages bloat to make sure the data could be =
exchanged over transaction ensured, sequenced, unreliable, or =
frobotz-capable transport protocols.

If we are not ready to produce protocols, we are not ready for a work =
group.

Reiterating sentence 1: let=E2=80=99s do what the IETF is good at and =
charter a protocol-developing work group.

Once we get there, I am sure we will include the =E2=80=9Cmotherhood and =
apple pie=E2=80=9D [1] statement that we will build upon existing IETF =
protocols, if they are available and make sense.

- Eric

[1] http://idioms.thefreedictionary.com/motherhood+and+apple+pie

> On May 27, 2015, at 10:46 AM, Ben Campbell  wrote:
>=20
> On 27 May 2015, at 9:35, Steve Donovan wrote:
>=20
>> I think we're pretty close.
>>=20
>> Here's the paragraph in question:
>>=20
>> The working group will define an information management framework for =
the roles
>> and functions involved in associating information with one or more =
TNs in an IP
>> environment.  The working group will also define protocol mechanisms =
to support
>> the interactions between the functions defined by the framework. This =
includes
>> either recommending or defining protocol mechanisms for acquiring, =
associating
>> and resolving TNs.  The protocol mechanism for acquiring TNs will =
provide an
>> enrollment process for the entities that use and manage TNs. TNs may =
either be
>> managed in a hierarchical tree, or in a distributed peer-to-peer =
architecture.
>> Privacy of the managed data and security of the resource will be =
primary
>> considerations.  The protocol mechanism for resolving TNs will allow =
entities
>> such as service providers, devices, and applications to access data =
related to
>> TNs.  Maintaining reliability, real time application performance, =
security and
>> privacy are primary considerations.  The working group will take into
>> consideration existing IETF work including ENUM, SPEERMINT, DRINKS =
and SCIM.
>>=20
>> How about if we change the second sentence from "...The working group =
will define protocol mechanisms..." to "...The working group will =
___identify___ protocol mechanisms.
>>=20
>> The next sentence already talks about recommending or defining. Maybe =
if we change "...This includes
>> either recommending or defining protocol mechanisms for acquiring, =
associating
>> and resolving TNs..." to "...This includes
>> either recommending or defining protocol mechanisms for acquiring, =
associating
>> and resolving TNs, ___with a preference for use of existing =
transports___".
>>=20
>> This should hopefully address the concern.
>=20
> s/"existing transports"/"existing protocol mechanisms" and I think =
it's good. (The TSV guys are protective of the word "transport" :-) )
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


--Apple-Mail=_A07DB066-6950-468E-B5B7-760D08D942B3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVZngDAAoJEDY/T2tCIPW3mH0QAIckntufqd1Z26gAe1XUl4R8
hSn0uyymHrB4FMRjfq8aCUEIQeTTfUJa1awCi9vkJUw6bw4TrwnSaJIE8AUnT4sJ
XUeLkNx00KvJeZGKoA4Q9LtRQyj9eNFHjZdfivrJKyyZEW8T6kTAJ/n/npO/4QqF
MmtUH1w484U+4sTKYZ94TBsNwojCuidSCX6MF4ZzfeBEl2Xpq9OixCzDgeYpEafg
/4KSpk4kNk4pvsJ8WNnztdptvdtVa0Gt95g8y2QZBPytCA0sC5adOVgc5fHc5lEX
CVIWhawAwI5wsA34DQOkSGZB0fM9NQeS+gTqnBTa1HhUIQ/UkCxusR0zVBegEceU
oWaDCGVn6qo8pLeIxiPWkd9Teyjes1KpRdEsbsEm5lyBoY4OjxvtJMwGX3Y5PUyy
znafG65jB11V27FGmKetbusEfV0axjo6KY8hytsHp56jMwItQhAVss1QzBjU8PLS
mAVII9FeHGL9FUkalptsbHVC/KLbA9/u75jjAhA3jOTCv1f/65JoXuB3tGlvlzgx
hQCI+TMIqQszFBt5rUMUDgJJtZmNERTNG26RQotG8rS0hlPxuDTIpTxRj93P4RD7
uXXt/1RRjjUou+yqATeZZXEPav1+tzO4+cCqzRFz80iTrvLJEYtDkxSAYEpF9eNb
8Cb7IpFH1tlm7irjugBZ
=LJA/
-----END PGP SIGNATURE-----

--Apple-Mail=_A07DB066-6950-468E-B5B7-760D08D942B3--


From nobody Thu May 28 09:14:15 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 A5C731B2C26 for ; Thu, 28 May 2015 09:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] 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 OrJHpIx4Gp9S for ; Thu, 28 May 2015 09:14:13 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 678751B2C25 for ; Thu, 28 May 2015 09:14:13 -0700 (PDT)
Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:55877 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yy0Rg-000AB0-Aj for modern@ietf.org; Thu, 28 May 2015 09:14:13 -0700
Message-ID: <55673ED3.80407@usdonovans.com>
Date: Thu, 28 May 2015 11:14:11 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "modern@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: [Modern] Updated charter
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, 28 May 2015 16:14:14 -0000

I've updated the charter below based on list discussions.

This contains two changes, changing peer-to-peer to distributed and the 
change related to a preference to use existing protocol mechanisms.

Steve

-----

The MODERN working group will define a set of Internet-based mechanisms for
the purposes of managing and resolving telephone numbers (TNs) in an IP
environment.  Existing mechanisms for these purposes face obsolescence 
as the
voice communications infrastructure evolves to IP technology and new
applications for TNs become possible.  The traditional model of a TN 
having an
association to a single service provider and a single application is 
breaking
down.  Its use as a network locator is going away, but its use as an 
identifier
for an individual or an organization will remain for some time. Devices,
applications, and network tools increasingly need to manage TNs, including
requesting and acquiring TN delegations from authorities.  A sample of 
problems
with existing mechanisms include:

- lack of flexibility (for example, it can be difficult to add fields 
without a
very elaborate and lengthy process typically spanning years)

- lack of distribution (for example, it is hard or impossible to have 
more than
one administrator for each database)

- complexity (leading, for example, to a fair amount of rural call 
completion
problems which aren't helped by small providers struggling to keep numbers
straight)

- difficulty of adopting more modern allocation (e.g., "blocks" of 1) and
porting mechanisms

The working group will define an information management framework for 
the roles
and functions involved in associating information with one or more TNs 
in an IP
environment.  The working group will also identify protocol mechanisms 
to support
the interactions between the functions defined by the framework. This 
includes
either recommending or defining protocol mechanisms for acquiring, 
associating
and resolving TNs, with a preference for use of existing protocol 
mechanisms.
The protocol mechanism for acquiring TNs will provide an enrollment 
process for
the entities that use and manage TNs. TNs may either be managed in a 
hierarchical
tree, or in a distributed registry.  Privacy of the managed data and 
security of the
resource will be primary considerations.  The protocol mechanism for 
resolving
TNs will allow entities such as service providers, devices, and 
applications to
access data related toTNs.  Maintaining reliability, real time 
application performance,
security and privacy are primary considerations.  The working group will 
take into
consideration existing IETF work including ENUM, SPEERMINT, DRINKS and SCIM.

The work of this group will focus on TNs, as defined in RFC3966, and 
blocks of
TNs, that are used to initiate communication with another user of a 
service.
The work is motivated by the changing telecom environment and interest 
expressed
by telecommunications industry regulators to support more flexible 
regulatory
models than exist today.   There is an expectation that aspects of the
architecture and protocols defined by the working group will be reusable for
other user-focused identifiers.  Any such extensions or reuse of MODERN
mechanisms are out of scope for the MODERN working group. Solutions and
mechanisms created by the working group will be flexible enough to 
accommodate
different policies, e.g., by different regulatory agencies.

The work group will deliver the following:

- An architecture overview, including high level requirements and
security/privacy considerations

- A description of the enrollment processes for existing and new TNs 
including
any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information
associated with enrollments

- A description of mechanisms for resolving information related to TNs