From nobody Tue Jun 2 08:25:40 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5131ACE5C for ; Tue, 2 Jun 2015 08:25:39 -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_40=-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 IRMoTppq0NJS for ; Tue, 2 Jun 2015 08:25: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 327D01ACE51 for ; Tue, 2 Jun 2015 08:25:38 -0700 (PDT) Received: from [64.31.33.135] (port=64575 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Yzo4N-0000KE-BV for modern@ietf.org; Tue, 02 Jun 2015 08:25:37 -0700 Message-ID: <556DCAEE.2030202@usdonovans.com> Date: Tue, 02 Jun 2015 10:25:34 -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=-1.0 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] Progressing 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: Tue, 02 Jun 2015 15:25:39 -0000 All, We plan to take the updated MODERN charter to the IESG to start the approval process. The next IETF teleconference happens on June 11th. If I understand correctly, the request to put it on the agenda needs to happen in the next few days. We also plan to request a slot for the Prague meeting. If we get the charter approved in time we would like start work in earnest during the Prague meeting. The updated charter can be found on the MODERN BOF datatracker page found here: https://datatracker.ietf.org/doc/charter-ietf-modern/ Please let us know if there are any objections to this plan. Steve and Tom From nobody Wed Jun 3 14:19: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 60A1C1B2FFE for ; Wed, 3 Jun 2015 14:19:44 -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 G2OnnuJik5Dv for ; Wed, 3 Jun 2015 14:19:42 -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 49E831B2FD3 for ; Wed, 3 Jun 2015 14:19:41 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Progressing the MODERN charter Thread-Index: AQHQnUhpRhCZBNninkqRK6pcWrvwcp2bSycM Date: Wed, 3 Jun 2015 21:19:39 +0000 References: <556DCAEE.2030202@usdonovans.com> In-Reply-To: <556DCAEE.2030202@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Progressing 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: Wed, 03 Jun 2015 21:19:44 -0000 Sorry for dropping out of the discussion; the current charter text looks go= od to me. I will be presenting the text to the NANC (North American Numberi= ng Council) as an FYI tomorrow.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Steve Donovan [srdonova= n@usdonovans.com]=0A= Sent: Tuesday, June 02, 2015 11:25 AM=0A= To: modern@ietf.org=0A= Subject: [Modern] Progressing the MODERN charter=0A= =0A= All,=0A= =0A= We plan to take the updated MODERN charter to the IESG to start the=0A= approval process. The next IETF teleconference happens on June 11th.=0A= If I understand correctly, the request to put it on the agenda needs to=0A= happen in the next few days. We also plan to request a slot for the=0A= Prague meeting. If we get the charter approved in time we would like=0A= start work in earnest during the Prague meeting. The updated charter=0A= can be found on the MODERN BOF datatracker page found here:=0A= =0A= https://datatracker.ietf.org/doc/charter-ietf-modern/=0A= =0A= Please let us know if there are any objections to this plan.=0A= =0A= Steve and Tom=0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= From nobody Wed Jun 3 14:44: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 952661A9025 for ; Wed, 3 Jun 2015 14:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMEOpvMPuNrl for ; Wed, 3 Jun 2015 14:44:55 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF9E1A0019 for ; Wed, 3 Jun 2015 14:44:54 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "modern@ietf.org" Thread-Topic: Numbering-related item on FCC agenda (FYI) Thread-Index: AdCeRoYod4QLzqVOTM2t7W515gbmIA== Date: Wed, 3 Jun 2015 21:44:52 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Modern] Numbering-related item on FCC agenda (FYI) 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, 03 Jun 2015 21:44:57 -0000 http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0528/DOC-333= 693A1.pdf From nobody Wed Jun 3 14:48: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 E9AE11AD1EC for ; Wed, 3 Jun 2015 14:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmGEBw75IKb2 for ; Wed, 3 Jun 2015 14:48:01 -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 C7AFE1AD0B9 for ; Wed, 3 Jun 2015 14:48:00 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] All-IP telecommunications network or TN identifiers Thread-Index: AQHQg4jrCGEIAxFgu0qaCtgolyqjrJ1mWOwAgAADNwCAAVLqgIAABOcA///IMSaAAEezgIAzwpBu Date: Wed, 3 Jun 2015 21:47:59 +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> , <85AB55FD-62F3-4935-B9FE-6606097333C3@standardstrack.com> In-Reply-To: <85AB55FD-62F3-4935-B9FE-6606097333C3@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: Wed, 03 Jun 2015 21:48:03 -0000 W0NhdGNoaW5nIHVwIG9uIG9sZCBlbWFpbF0KClRoZSBBVElTIGRvY3VtZW50IGlzIGJyb2FkZXI7 IHNlZSwgZm9yIGV4YW1wbGUsIFNlY3Rpb24gNS4xLjE6CgouMS4xIE51bWJlcmluZyBVc2UgQ2Fz ZSAxIOKAkyBKSVQvSVROIE51bWJlciBBc3NpZ25tZW50IGZvciBpbmRpdmlkdWFsIFROICYgYmxv Y2sgYWxsb2NhdGlvbgpTcG9uc29yOiBBVCZUCk9iamVjdGl2ZTogRXhwbG9yZSBhbGxvY2F0aW9u IG9mIG51bWJlcmluZyByZXNvdXJjZXMgb24gYSBqdXN0LWluLXRpbWUsIHBlciBjdXN0b21lciBi YXNpcyB3aXRoaW4gdGhlCmZyYW1ld29yayBvZiBhIGNvbnZlcmdlZCBwbGF0Zm9ybSBmb3IgbnVt YmVyaW5nIGxpZmVjeWNsZSBtYW5hZ2VtZW50IHN1cHBvcnRpbmc6Cu+CtyBOdW1iZXIgYWxsb2Nh dGlvbiB0byBzZXJ2aWNlIHByb3ZpZGVycy4K74K3IFNlcnZpY2UgUHJvdmlkZXIgUG9ydGFiaWxp dHkuCu+CtyBEaXN0cmlidXRpb24gb2Ygc2VydmljZSBwcm92aWRlciBpbmZvcm1hdGlvbiBhbmQg cm91dGluZyBpbmZvcm1hdGlvbiBmb3Igc2Vzc2lvbiBlc3RhYmxpc2htZW50IGFuZAptZXRhZGF0 YSBhY2Nlc3MuClRoZSBSZWdpc3RyeSB3b3VsZCBlbmZvcmNlIG51bWJlcmluZyByZXNvdXJjZSBw b2xpY2llcyBhbmQgcHJvdmlkZSB1dGlsaXphdGlvbiByZXBvcnRzIGZvciByZWd1bGF0b3J5IGF1 dGhvcml0aWVzLgpBbHRob3VnaCBkZXBpY3RlZCBpbiB3aGF0IGZvbGxvd3MgYXMgYSBjZW50cmFs aXplZCByZWdpc3RyeSBpdCBtaWdodCBiZSBpbXBsZW1lbnRlZCBpbiBhIGRpc3RyaWJ1dGVkIGZh c2hpb24uClNjb3BlOgrvgrcgVGVzdCBSZXF1aXJlbWVudHM6IFNvbWUgZW50aXRpZXMgd291bGQg bmVlZCB0byBwcm92aWRlIGEgcmVnaXN0cnkgd2l0aCBpbnRlcmZhY2VzIHRvIGludGVyYWN0IHdp dGggU1BzLiBTUHMgd291bGQgbmVlZCB0byBpbnRlcmZhY2Ugd2l0aCB0aGUgcmVnaXN0cnkuCu+C tyBTcGVjaWZpY2F0aW9uczogVGhlIFNlcnZpY2UgUHJvdmlkZXJzIGFuZCBWZW5kb3JzIHdvdWxk IG5lZWQgdG8gYWdyZWUgb24gc3RhbmRhcmQgaW50ZXJmYWNlcyB0byBhY2NvbW1vZGF0ZSB0aGUg dXNlIGNhc2UuIEludGVyZmFjZXMgd291bGQgbmVlZCB0byBiZSBhZ3JlZWQgdXBvbiBvbmNlIHBh cnRpY2lwYW50cyBkZXZlbG9wZWQgYW5kIGFncmVlZCB0byB0aGUgdXNlIGNhc2UuIERpZmZlcmVu dCBwcm90b2NvbHMgY291bGQgYmUgdGVzdGVkLgrvgrcgQmFzaWMgZnVuY3Rpb25hbGl0eSB3b3Vs ZCBoYXZlIHRvIGluY2x1ZGUgbWFpbnRhaW5pbmcgYSBwb29sIG9mIG51bWJlcnMgZm9yIGFsbG9j YXRpb24gYW5kIGFiaWxpdHkgdG8gZGlzcGxheSBhdmFpbGFibGUgaW52ZW50b3J5IGJhc2VkIG9u IHF1ZXJpZXMgZm9yIGF0dHJpYnV0ZXMgc3VjaCBhcyBsb2NhdGlvbiwgbWFraW5nIGFzc2lnbm1l bnRzLCByZWNlaXZpbmcgZGF0YSBmcm9tIFNQcyBhYm91dCBhc3NpZ25lZCBudW1iZXJzLCBhbmQg ZGlzdHJpYnV0aW9uIG9mIGRhdGEgdG8gc2VydmljZSBwcm92aWRlcnMvYnVyZWF1cy4gSXQgaXMg bm90IGNsZWFyIGlmIHBvcnRhYmlsaXR5IG5lZWRzIHRvIGJlIGltcGxlbWVudGVkIGluIHRoZSBp bml0aWFsIHRlc3QgY2FzZXMuCu+CtyBEdXJhdGlvbiBvZiBUZXN0OiBUZXN0IGR1cmF0aW9uIHdp bGwgYmUgdXAgdG8gcGFydGljaXBhdGluZyBTZXJ2aWNlIFByb3ZpZGVycyBhbmQgVmVuZG9ycyBi dXQgY291bGQgYmUgYXMgc2hvcnQgYXMgYSBmZXcgZGF5cyBvciBsYXN0IGxvbmdlciB0aGFuIG9u ZSBtb250aC4K74K3IERlcHRoIG9mIFRlc3Rpbmc6IFRlc3Qgd2lsbCBwcm92aWRlIHByb29mIG9m IGNvbmNlcHQgYW5kIHZhbGlkYXRlIHByb3Zpc2lvbmluZy4gT3V0cHV0OgrvgrcgRm9ybWF0IOKA kyBBIHJlcG9ydCB3aWxsIGJlIGlzc3VlZC4K74K3IFRhcmdldCBBdWRpZW5jZSDigJNTZXJ2aWNl IFByb3ZpZGVycywgVmVuZG9ycy4gTm9uLXByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGNvdWxkIGJl IHNoYXJlZAp3aXRoIG90aGVycyBpZiBhcHByb3ZlZCBieSBwYXJ0aWNpcGFudHMuCkluZGljYXRp b24gb2YgSW50ZXJlc3Q6IEFUJlQsIENlbnR1cnlMaW5rLCBDb21jYXN0LCBpY29uZWN0aXYsIEpT SSwgYW5kIFNwcmludC4gVGhlIEFQSSBjYXBhYmlsaXRpZXMgZm9yIG51bWJlciBtYW5hZ2VtZW50 IGFyZSBkZXRhaWxlZCBiZWxvdy4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkZyb206IE1vZGVybiBbbW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBv ZiBFcmljIEJ1cmdlciBbZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb21dClNlbnQ6IEZyaWRheSwg TWF5IDAxLCAyMDE1IDM6MjAgUE0KVG86IG1vZGVybkBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW01v ZGVybl0gQWxsLUlQIHRlbGVjb21tdW5pY2F0aW9ucyBuZXR3b3JrIG9yIFROIGlkZW50aWZpZXJz CgpTbyBmb2xrcyBvbiB0aGUgbGlzdCBoYXZlIGl0LCB0aGUgZG9jdW1lbnQgaXMgYXQKaHR0cHM6 Ly9hY2Nlc3MuYXRpcy5vcmcvYXBwcy9ncm91cF9wdWJsaWMvZG93bmxvYWQucGhwLzIxNzI3L1Rl c3RiZXNkc19MYW5kc2NhcGVfVGVhbS5wZGYKCkFsbCBvZiB0aGUgdXNlIGNhc2VzIGFyZSBmb3Ig bGVnYWN5IGNhcnJpZXJzIGRvaW5nIGxlZ2FjeSBudW1iZXIgcm91dGluZy4gVGhlIHVzZSBjYXNl cyBhcmUgYXJvdW5kIGhvdyB0byBkbyBFTlVNIGFuZCB3aGV0aGVyIHRvIHVzZSBOUyByZWNvcmRz LCBVUklzLCBjZW50cmFsaXplZCB2cy4gZGlzdHJpYnV0ZWQgTlBBQywgYW5kIGhvdyB0byByb3V0 ZSA4MDAjIChmcmVlIHBob25lKSBjYWxscy4KCldoYXQgYXJlIHRoZSBwcm9ibGVtcyBiZWluZyBz b2x2ZWQ/Cgo+IE9uIE1heSAxLCAyMDE1LCBhdCAzOjA4IFBNLCBIZW5uaW5nIFNjaHVsenJpbm5l IDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+IHdyb3RlOgo+Cj4gRm9yIHdoYXQgaXQncyB3 b3J0aCwgQVRJUyBoYXMgYWxyZWFkeSBwcm9kdWNlZCBhIHVzZXMgY2FzZXMgZG9jdW1lbnQsIGFu ZCBldmVuIGEgdmVyeSByb3VnaCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLCB3aXRoIG1hbnkgb2Yg dGhlIHNhbWUgb3JnYW5pemF0aW9ucyBsaXN0ZWQgdGhhdCBhcmUgcGFydGljaXBhdGluZyBpbiB0 aGlzIGRpc2N1c3Npb24gKGJ1dCBwb3NzaWJseSBhbmQgcHJvYmFibHkgZGlmZmVyZW50IGluZGl2 aWR1YWxzKS4gU2VlIEFUSVMtSS0wMDAwMDQ3Lgo= From nobody Wed Jun 3 15:12: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 8DA391A8940 for ; Wed, 3 Jun 2015 15:12:35 -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 atq1xgWe9nx0 for ; Wed, 3 Jun 2015 15:12:33 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC901A88DC for ; Wed, 3 Jun 2015 15:12:32 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] P2P (was Third revision of MODERN charter) Thread-Index: AQHQkbgOsuX9C0x/7UWyBbAwJAb9uJ2bcDa4 Date: Wed, 3 Jun 2015 22:12:10 +0000 References: <5554EAEC.2070208@usdonovans.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 03 Jun 2015 22:12:35 -0000 [Catching up]=0A= =0A= The current ("distributed") text is fine, but what I meant to encapsulate i= s that the set of entities cooperating would be peers, somewhat similar to = the multiple, cooperating white spaces database, rather than simply a distr= ibuted set of nodes, each responsible for a disjoint part of the number sp= ace. Thus, peer in the "a person of the same legal status" dictionary sense= , not (necessarily) the IETF RELOAD sense.=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Eric Burger [eburger@st= andardstrack.com]=0A= Sent: Monday, May 18, 2015 6:14 PM=0A= To: modern@ietf.org=0A= Subject: [Modern] P2P (was Third revision of MODERN charter)=0A= =0A= All of Henning=92s slides were about number assignments in a hierarchy. My = recollection is all of the use cases were about number assignments in a hie= rarchy. I am not against working on peer-to-peer assignment technology. How= ever, I wanted to make sure this is something that people want to work on.= =0A= =0A= What is the use case? Sorry if I missed it. When I greped the archive, the = term =91peer=92 does not hit, other than in the charter drafts.=0A= =0A= > On May 14, 2015, at 2:35 PM, Steve Donovan wro= te:=0A= >=0A= > TNs may either be managed in a hierarchical tree, or in a distributed pe= er-to-peer architecture.=0A= =0A= From nobody Wed Jun 3 15:24:52 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 995E91B2FFB for ; Wed, 3 Jun 2015 15:24:50 -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 8DnOG3BhsXz4 for ; Wed, 3 Jun 2015 15:24:47 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id A34931B3001 for ; Wed, 3 Jun 2015 15:24:45 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Chris Wendt , "McGarry, Tom" Thread-Topic: [Modern] TN, E.164, or Something Else? Thread-Index: AQHQkblL5Ay4MY6fS0KgxJG4wBM4+Z2FMtWAgAWxd4CAAkDIAIAAr+KAgADKrACAAA6yAIAANv2AgAyOxjg= Date: Wed, 3 Jun 2015 22:24:43 +0000 References: , <76FFBCF5-2FF7-4630-811C-47E2E7C40840@chriswendt.net> 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: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 03 Jun 2015 22:24:50 -0000 Two historical RAI examples that come close are LoST and HELD (not exactly = REST, but close). RDAP (out of WEIRDS) is a more recent, somewhat related, = standards-track effort. ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt [chris-ietf= @chriswendt.net] Sent: Tuesday, May 26, 2015 2:36 PM To: McGarry, Tom Cc: 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 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 From nobody Mon Jun 8 09:58: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 EB4D61B3082; Mon, 8 Jun 2015 09:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NKwI8d-yEcKM; Mon, 8 Jun 2015 09:46:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51E1A92BA; Mon, 8 Jun 2015 09:46:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608164652.22130.333.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 09:46:52 -0700 Archived-At: X-Mailman-Approved-At: Mon, 08 Jun 2015 09:58:36 -0700 Cc: modern@ietf.org, Steve Donovan , Alissa Cooper , Tom McGarry , ben@nostrum.com Subject: [Modern] Stephen Farrell's No Record on charter-ietf-modern-00-02: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 16:46:54 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-modern-00-02: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-modern/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - What does keeping "numbers straight" mean? - It'll be interesting to see what external feedback this gets. From nobody Tue Jun 9 16:09:55 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 36AF31A8A13; Tue, 9 Jun 2015 16:09:54 -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_40=-0.001, DKIM_ADSP_ALL=0.8] 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 m7gc1gEbMVZP; Tue, 9 Jun 2015 16:09:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6251A89B3; Tue, 9 Jun 2015 16:09:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 16:09:52 -0700 Archived-At: Cc: modern@ietf.org, Steve Donovan , Alissa Cooper , Tom McGarry , ben@nostrum.com Subject: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 23:09:54 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-modern-00-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-modern/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since I was on leave and Ben was shepherding this work until very recently, I did not have a chance to provide comments on the charter until now. I think overall the charter is good but I have a bunch of suggestions to make it crisper and more understandable for people who are new to this work. In the edit below I've tried to remove some of the redundant language. I edited the first paragraph and removed the example problems, which included a lot of domain-specific terms that were not properly explained and didn't add much overall. I added STIR to the list of other relevant IETF WGs. The substance of the charter hasn't changed, but I'd like the folks on the mailing list to review the changes before I put them into the tracker. -- 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. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Wed Jun 10 08:25:52 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 2D1241A87D1; Wed, 10 Jun 2015 08:25:52 -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 KBGOUoa5Mgp3; Wed, 10 Jun 2015 08:25:50 -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 CB8D81A8761; Wed, 10 Jun 2015 08:25:50 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:58309 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Z2hsz-0009QN-AY; Wed, 10 Jun 2015 08:25:50 -0700 Message-ID: <557856FC.8020800@usdonovans.com> Date: Wed, 10 Jun 2015 10:25:48 -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: Alissa Cooper , The IESG References: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> In-Reply-To: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 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: Cc: ben@nostrum.com, modern@ietf.org, Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) 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, 10 Jun 2015 15:25:52 -0000 Alissa, The changes look good to me. Steve On 6/9/15 6:09 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-modern-00-02: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-modern/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since I was on leave and Ben was shepherding this work until very > recently, I did not have a chance to provide comments on the charter > until now. I think overall the charter is good but I have a bunch of > suggestions to make it crisper and more understandable for people who are > new to this work. In the edit below I've tried to remove some of the > redundant language. I edited the first paragraph and removed the example > problems, which included a lot of domain-specific terms that were not > properly explained and didn't add much overall. I added STIR to the list > of other relevant IETF WGs. The substance of the charter hasn't changed, > but I'd like the folks on the mailing list to review the changes before I > put them into the tracker. > > -- > > 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. The output of the working group should make > distribution, acquisition, and management of TNs simpler for all entities > involved. > > 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. TNs may either be > managed in a hierarchical tree, or in a distributed registry. The > protocol mechanism for acquiring TNs will provide an enrollment process > for the entities that use and manage TNs. > > 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, and > security and privacy for both the data and the protocol interactions are > primary considerations. The working group will take into consideration > existing IETF work including STIR, 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. 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 for TN assignment and management, for > example those established by different regulatory agencies. > > The working 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 Wed Jun 10 08:33: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 DCB721B2BBC; Wed, 10 Jun 2015 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7TKaN-hCeClh; Wed, 10 Jun 2015 08:33:13 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E773C1B2BB7; Wed, 10 Jun 2015 08:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1433950393; x=1465486393; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Eh5Dw40H1JLYiO38FducwbNe7UbxRVaiBY1o6su3H+E=; b=cAS7AAnWyRRM6iNlTg5lg0zS0BKf2idGpV8ityzeayjkqHtWJ+llir0Z r3tKZ3Wt3ov58TJVnvI7wiyrR4er/EGBTZygL6CD2Zpu+4LIgCBPxzUtr dZZoVsr0ccdaLIGjrhhTs6sfALE5QrSuyeHzKXTobSvn91rR6Ir/Y24Qm o=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe02.verizonbusiness.com with ESMTP; 10 Jun 2015 15:32:55 +0000 From: "Castagna, James T (Jim)" X-IronPort-AV: E=Sophos;i="5.13,588,1427760000"; d="scan'208";a="1016825447" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 10 Jun 2015 15:32:54 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 10 Jun 2015 11:32:53 -0400 To: Steve Donovan , Alissa Cooper , The IESG Date: Wed, 10 Jun 2015 11:32:52 -0400 Thread-Topic: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) Thread-Index: AdCjkb/5WvPofiyAQQ+rha/Pej3M9wAAMT/g Message-ID: <480816B49261A94EB6628FA890E4C7B6141A9129A7@FHDP1LUMXC7V11.us.one.verizon.com> References: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> <557856FC.8020800@usdonovans.com> In-Reply-To: <557856FC.8020800@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ben@nostrum.com" , "modern@ietf.org" , Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) 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, 10 Jun 2015 15:33:16 -0000 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Now that the charter is nearly finalized it becomes more evident that the s= econd and third sentences in the first paragraph don't belong in a charter.= I don't believe the IETF needs to substantiate their interest in developi= ng new tools and eliminating these sentences will avoid the misinterpretati= on that these issues are the only reasons why the IETF is taking on this wo= rk. =20 See how it reads without these sentences: -- MODERN (2 / 3 paragraph deleted) 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs.= =20 The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, June 10, 2015 11:26 AM To: Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) Alissa, The changes look good to me. Steve On 6/9/15 6:09 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-modern-00-02: Yes > > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-modern/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since I was on leave and Ben was shepherding this work until very=20 > recently, I did not have a chance to provide comments on the charter=20 > until now. I think overall the charter is good but I have a bunch of=20 > suggestions to make it crisper and more understandable for people who=20 > are new to this work. In the edit below I've tried to remove some of=20 > the redundant language. I edited the first paragraph and removed the=20 > example problems, which included a lot of domain-specific terms that=20 > were not properly explained and didn't add much overall. I added STIR=20 > to the list of other relevant IETF WGs. The substance of the charter=20 > hasn't changed, but I'd like the folks on the mailing list to review=20 > the changes before I put them into the tracker. > > -- > > The MODERN working group will define a set of Internet-based=20 > mechanisms for the purposes of managing and resolving telephone=20 > numbers (TNs) in an IP environment. Existing mechanisms for these=20 > purposes face obsolescence as the voice communications infrastructure=20 > evolves to IP technology and new applications for TNs become possible.=20 > The traditional model of a TN having an association to a single=20 > service provider and a single application is breaking down. Its use as=20 > a network locator is going away, but its use as an identifier for an=20 > individual or an organization will remain for some time. Devices,=20 > applications, and network tools increasingly need to manage TNs,=20 > including requesting and acquiring TN delegations from authorities.=20 > The output of the working group should make distribution, acquisition,=20 > and management of TNs simpler for all entities involved. > > The working group will define an information management framework for=20 > the roles and functions involved in associating information with one=20 > or more TNs in an IP environment. The working group will also=20 > identify protocol mechanisms to support the interactions between the=20 > functions defined by the framework. This includes either recommending=20 > or defining protocol mechanisms for acquiring, associating and=20 > resolving TNs, with a preference for use of existing protocol=20 > mechanisms. TNs may either be managed in a hierarchical tree, or in a=20 > distributed registry. The protocol mechanism for acquiring TNs will=20 > provide an enrollment process for the entities that use and manage TNs. > > The protocol mechanism for resolving TNs will allow entities such as=20 > service providers, devices, and applications to access data related to=20 > TNs. Maintaining reliability, real-time application performance, and=20 > security and privacy for both the data and the protocol interactions=20 > are primary considerations. The working group will take into=20 > consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. > > The work of this group will focus on TNs, as defined in RFC3966, and=20 > blocks of TNs, that are used to initiate communication with another=20 > user of a service. There is an expectation that aspects of the=20 > architecture and protocols defined by the working group will be=20 > reusable for other user-focused identifiers. Any such extensions or=20 > reuse of MODERN mechanisms are out of scope for the MODERN working=20 > group. Solutions and mechanisms created by the working group will be=20 > flexible enough to accommodate different policies for TN assignment=20 > and management, for example those established by different regulatory age= ncies. > > The working group will deliver the following: > > - An architecture overview, including high level requirements and=20 > security/privacy considerations > > - A description of the enrollment processes for existing and new TNs=20 > including any modifications to metadata related to those TNs > > - A description of protocol mechanisms for accessing contact=20 > 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 > _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jun 10 15:14: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 9C3911A1BDB; Wed, 10 Jun 2015 15:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 L439-T8rI6eu; Wed, 10 Jun 2015 15:14:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80511A1BD1; Wed, 10 Jun 2015 15:14:04 -0700 (PDT) Received: from BN1AFFO11OLC001.protection.gbl (10.58.52.32) by BN1AFFO11HUB040.protection.gbl (10.58.52.151) with Microsoft SMTP Server (TLS) id 15.1.190.9; Wed, 10 Jun 2015 22:13:38 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; neustar.biz; 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 BN1AFFO11OLC001.mail.protection.outlook.com (10.58.53.72) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Wed, 10 Jun 2015 22:13:25 +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 t5AMAv5W046049; Wed, 10 Jun 2015 18:13:21 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm3.corp.sprint.com with ESMTP id 1uuu41y4c0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Jun 2015 18:13:21 -0400 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; Wed, 10 Jun 2015 18:13:20 -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; Wed, 10 Jun 2015 17:13:20 -0500 From: "Gorman, Pierce A [CTO]" To: "Castagna, James T (Jim)" , Steve Donovan , Alissa Cooper , The IESG Thread-Topic: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) Thread-Index: AQHQo5G/nfo3WVLuq0OHZJZVOUafo52mMhsAgAAbxbA= Date: Wed, 10 Jun 2015 22:13:20 +0000 Message-ID: <9731a5aaf58e47fb9c969d0491806bae@PLSWE13M08.ad.sprint.com> References: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> <557856FC.8020800@usdonovans.com> <480816B49261A94EB6628FA890E4C7B6141A9129A7@FHDP1LUMXC7V11.us.one.verizon.com> In-Reply-To: <480816B49261A94EB6628FA890E4C7B6141A9129A7@FHDP1LUMXC7V11.us.one.verizon.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.22] Content-Type: multipart/alternative; boundary="_000_9731a5aaf58e47fb9c969d0491806baePLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC001; 1:k9c7u+DfmaUGJuKeK6JRhqPeDTW1gh0Ym8jqtcyCRXb5lYVe2xIWrSM4fJaaoQdVEXcRZK3XwjgbLuGirdpXhDauc3FhoddO90rUkgTezS0FgjOarqW6doXIuD0TwR24P3Xd7XWhgpTt5TRJ3IdKtqkWoaO2XvE0aEeNBUIfbQu6Fei0eVIpP2ul6D3GmORZr9ZnBeqNZ+4ksLAxdxRZxJnizQUjSwHUtcpkHL8YHLpISSajorAmXJCx4UnPdpLyNO6Rd1aVSy47w044Wtvsn255tY691AXuszJZrvWTsHv+DpINYxrNXDocF4x4AZQY X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(448002)(13464003)(24454002)(479174004)(199003)(52044002)(189002)(377454003)(51704005)(46102003)(50986999)(19617315012)(189998001)(512954002)(54356999)(76176999)(5001770100001)(5001960100002)(6806004)(16236675004)(77156002)(62966003)(30436002)(33646002)(5250100002)(84326002)(19300405004)(85326001)(4546004)(92566002)(230783001)(102836002)(2900100001)(87936001)(15975445007)(106116001)(2656002)(108616004)(19625215002)(2950100001)(24736003)(19580405001)(19580395003)(106466001)(86362001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB040; H:preapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB040; 2:/qLdGcdjyRtBjunYm7tO0fLnG0vHzWNwCDcbVqofPyvexvkQzEoHrmkWO2FOnSMb; 2:Bl1BtJH2nLIXDLCCRthyEUEdeFGnKkYNjAXTJCFYeWXRlSNoIG6oKfGSGy4mqUCC4KeRdLJ9iD5z1d/GHKAm/QIx4SpnrYKPd5eNR9z2aqe4yw9pnU8PmINp4sszv+FlZPNh+9Vu11+OcSJAy9sj9hGd2lPMDQ0vDd3GCsInN/JpeYvGkkhePJw7bxW+cSgF3Ne9iT7sAtyiKj7SYGgEu6C552iTLepolOwKD85jKto=; 6:7k/yCqQ92//bfJCHoxsLZu5z9Onq1atie5ltHfwGjPTQPLRIGOCsl/RcrMw19jDWrTKhsWXkoQQaD+VbDQ2EOP5JBhsVeBSqoaxN0dc++vhM14Mj7I7KBNXT0eiNL6mZbwLDsubwk7heQu91AFm5CnqtzjmoascP6Ebp1Z3KfAVMtaDiCCaAf5dWkjJttYIfhnDx1QkZ/n0011iWT6Lfw2XkZxit9UWajERUmNig60gFHo+DLLX6Ci8jSbAqO7UG; 3:3shta0vzcnvflsFBN7OL/gkyvnJq7dhoSMuR93HSYiNDU0QbVyzSiKfELP39GzJ6nIfryGkFvQIsGnI814vlxfkQejLNVQb5Z9JIJFxZGIw4nwK6MNkeq4p+kYy/k66UFM86nhfeMgH2KQiqHiwGSLCnzgXFxhBMqy9L4HHtT1GjA7fxXJOA0zdp406k+Hc8aUuqo6+95E+eljEWmnqJf3muXTC+3nrirSTpzFTDNEIO1hyDus+L8+D3VLTLmd16iChm8sMh2xGytYSmkb1Pf9029PwkGsNpOKkpowOuqaxttMqIYCl0Z1ohYv+ROO86 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB040; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1AFFO11HUB040; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB040; X-Forefront-PRVS: 06036BD506 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB040; 9:uKv/lIiWmHX/jkUjDdDVGv57m94eo/J1zDXnx04h?= =?us-ascii?Q?Fj5ATmXdx/Q9wjNSaLQLEB0AjwtjSvDnbLtKfnFoKrtRGHYkPox5wWmYzgug?= =?us-ascii?Q?J4RBUXGqDFi5F76foTqMHtqVzw4y5gz+r2ikciVcVH0GqWxC4s4mHEEVTPv3?= =?us-ascii?Q?/mJ6uUeiCmx8JKKQ1/sCF3zR9VLR0HrZg24r4ab4UIAZk/57wrv+gv7bqwey?= =?us-ascii?Q?iUH7xxAyKpTW+beGx7Pkh5E6rUpdXUn6xZenv7xeLnhrShjx8IqYGI2BrAdW?= =?us-ascii?Q?SgnSrStVHzAyBfizKbgdfEM/IC/9W7jo6ZyXbxWLH0XBdot+BTcSqxCcNfbl?= =?us-ascii?Q?6byL6+B0oJayXbTOdem0T6YYbXAj2fFA5caP91Gntdgeu9Gob3Z8ppvk/B9f?= =?us-ascii?Q?jZSHuZ5JOr4UhJSGMuqjiKWjZVC8Rzam7+NqaukbRUPJKRaqYNecy7wO3JqJ?= =?us-ascii?Q?e2gtag5MJLwRa1xTg6BK1W9d2f4iokHiyA8VlNPTlp9ASCL1A20B7ATrnPf/?= =?us-ascii?Q?5ZzJhzbp4Wz5WJsBrXA7fhvD+4kCvSN0OTYTYuKVBFaZ9DN5i21rT5ERsgrR?= =?us-ascii?Q?cYMyXJlGxBZxOqAZFgR1+QmJXt6uVsfabAqGAyiKpOjQ2dw2xjUkHGXOnJXG?= =?us-ascii?Q?VahaFhSpVaDX2lQYNsPVXCwWbCFG5I3iIPWpLHR+klFJW3Xv8D4bettK1HNE?= =?us-ascii?Q?Dsm2GZ871epkV7yHp+6fAQvxvKRPgp1ivo/AVTJfkl9uE9OLwXkA9OEX97Ay?= =?us-ascii?Q?iCStY5i+G4KrCGymmopVpHEh71k7Z0BQHviU9WHHmV0JHgEau9sjDamOtuHt?= =?us-ascii?Q?ZPLAJtDrMTZI/TlMqk5y8iEsNekG2jwxQXJyPM+JqrimJ9bDvgT6zDjBI/iW?= =?us-ascii?Q?mFpryyMXdhFPwuAOoXYaskNHyASZ5gpVTcuAnPifMQIpp07lvJ71gCueuHl+?= =?us-ascii?Q?Xn0t/SGrn84U2K6mWY//xnJBELDATwZkeXpQlEmplSK1Ve73iKaPOVfeoK8p?= =?us-ascii?Q?fBH0jBkOEHnE0A1BKsM0IwvgvfRyS1ciRvyB1WDcR0jlhlg1zbUj85T51iIM?= =?us-ascii?Q?fdCHaM4/K8NfyNwgcf853qjvHGAc7t9EkSs5imhSZVBcM5tZUvXyLyMc2P5e?= =?us-ascii?Q?9TrWZDKxgLbF0pkPRaFPYi3gzjuDSJNOo6eKmMkIwrDzMU54K7bJK68R0ct1?= =?us-ascii?Q?yQvsJl2rNojZ0oXkDKcwO3kzqSBqgZPIMTkb?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB040; 3:dmiAeR4skmX9q8b4Be8VnAcp08wnfrgOhXibOWZgnrnsumD/neEzj0DgUsNOzmxize3OWhmoqp9fgiF/p1oc931jedevpDvwdNC2XxMZpx2VoXONYQXeS3pssCvXHhSH4w/Q3slJUbhwhYDVi8myvQ==; 10:VSkLrGAmkbTAQxvK/XuOAtqYpFY7B4+Dp3gsYFn20WgJ6v6KzjCsd8jrJUoSmE6L4y0JDS/4+hJX5+H9ZYJ+azKrFlmOCtgd/GK6/cQqE0Y= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2015 22:13:25.3131 (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: BN1AFFO11HUB040 Archived-At: Cc: "ben@nostrum.com" , "modern@ietf.org" , Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) 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, 10 Jun 2015 22:14:15 -0000 --_000_9731a5aaf58e47fb9c969d0491806baePLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think you meant 2nd, 3rd, and 4th sentences don't belong in the charter. = At least, that's what you deleted. (See highlighted deleted sentences bel= ow.) 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 Castagna, James = T (Jim) Sent: June 10, 2015 10:33 AM To: Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Now that the charter is nearly finalized it becomes more evident that the s= econd and third sentences in the first paragraph don't belong in a charter.= I don't believe the IETF needs to substantiate their interest in developi= ng new tools and eliminating these sentences will avoid the misinterpretati= on that these issues are the only reasons why the IETF is taking on this wo= rk. See how it reads without these sentences: -- MODERN (2 / 3 paragraph deleted) 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, June 10, 2015 11:26 AM To: Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) Alissa, The changes look good to me. Steve On 6/9/15 6:09 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-modern-00-02: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-modern/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since I was on leave and Ben was shepherding this work until very > recently, I did not have a chance to provide comments on the charter > until now. I think overall the charter is good but I have a bunch of > suggestions to make it crisper and more understandable for people who > are new to this work. In the edit below I've tried to remove some of > the redundant language. I edited the first paragraph and removed the > example problems, which included a lot of domain-specific terms that > were not properly explained and didn't add much overall. I added STIR > to the list of other relevant IETF WGs. The substance of the charter > hasn't changed, but I'd like the folks on the mailing list to review > the changes before I put them into the tracker. > > -- > > 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. > The output of the working group should make distribution, acquisition, > and management of TNs simpler for all entities involved. > > 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. TNs may either be managed in a hierarchical tree, or in a > distributed registry. The protocol mechanism for acquiring TNs will > provide an enrollment process for the entities that use and manage TNs. > > 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, and > security and privacy for both the data and the protocol interactions > are primary considerations. The working group will take into > consideration existing IETF work including STIR, 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. 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 for TN assignment > and management, for example those established by different regulatory age= ncies. > > The working 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 > _______________________________________________ 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. --_000_9731a5aaf58e47fb9c969d0491806baePLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think you meant 2nd, 3rd, and 4th sentences don= 't belong in the charter.  At least, that's what you deleted.  (S= ee highlighted deleted sentences below.)

 

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 Castagna, James = T (Jim)
Sent: June 10, 2015 10:33 AM
To: Steve Donovan; Alissa Cooper; The IESG
Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry
Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT)

 

-------------------------------------------------= ---------------------

COMMENT:

-------------------------------------------------= ---------------------

 

Now that the charter is nearly finalized it becom= es more evident that the second and third sentences in the first paragraph = don't belong in a charter.  I don't believe the IETF needs to substant= iate their interest in developing new tools and eliminating these sentences will avoid the misinterpretation that thes= e issues are the only reasons why the IETF is taking on this work. 

 

See how it reads without these sentences:

 

--

 

MODERN (2 / 3 paragraph deleted)

 

The MODERN working group will define a set of Int= ernet-based mechanisms for the purposes of managing and resolving telephone= numbers (TNs) in an IP environment. Devices, applications, and network too= ls increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The ou= tput of the working group should make distribution, acquisition, and manage= ment of TNs simpler for all entities involved.

 

The working group will define an information mana= gement framework for the roles and functions involved in associating inform= ation with one or more TNs in an IP environment.  The working group wi= ll also identify protocol mechanisms to support the interactions between the functions defined by the framework. T= his includes either recommending or defining protocol mechanisms for acquir= ing, associating and resolving TNs, with a preference for use of existing p= rotocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The proto= col mechanism for acquiring TNs will provide an enrollment process for the = entities that use and manage TNs.

 

The protocol mechanism for resolving TNs will all= ow entities such as service providers, devices, and applications to access = data related to TNs. Maintaining reliability, real-time application perform= ance, and security and privacy for both the data and the protocol interactions are primary considerations. Th= e working group will take into consideration existing IETF work including S= TIR, ENUM, SPEERMINT, DRINKS and SCIM.

 

The work of this group will focus on TNs, as defi= ned in RFC3966, and blocks of TNs, that are used to initiate communication = with another user of a service. 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 for TN assignment and management, for example those est= ablished by different regulatory agencies.

 

The working group will deliver the following:

 

- An architecture overview, including high level = requirements and security/privacy considerations

 

- A description of the enrollment processes for e= xisting and new TNs including any modifications to metadata related to thos= e TNs

 

- A description of protocol mechanisms for access= ing contact information associated with enrollments

 

- A description of mechanisms for resolving infor= mation related to TNs

 

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

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

Sent: Wednesday, June 10, 2015 11:26 AM

To: Alissa Cooper; The IESG

Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry

Subject: Re: [Modern] Alissa Cooper's Yes on char= ter-ietf-modern-00-02: (with COMMENT)

 

  Alissa,

 

The changes look good to me.

 

Steve

 

On 6/9/15 6:09 PM, Alissa Cooper wrote:

> Alissa Cooper has entered the following ball= ot position for

> charter-ietf-modern-00-02: Yes

> 

> When responding, please keep the subject lin= e intact and reply to all

> email addresses included in the To and CC li= nes. (Feel free to cut

> this introductory paragraph, however.)<= /o:p>

> 

> 

> 

> The document, along with other ballot positi= ons, can be found here:

> https://datatracker.i= etf.org/doc/charter-ietf-modern/

> 

> 

> 

> --------------------------------------------= --------------------------

> COMMENT:

> --------------------------------------------= --------------------------

> 

> Since I was on leave and Ben was shepherding= this work until very

> recently, I did not have a chance to provide= comments on the charter

> until now. I think overall the charter is go= od but I have a bunch of

> suggestions to make it crisper and more unde= rstandable for people who

> are new to this work. In the edit below I've= tried to remove some of

> the redundant language. I edited the first p= aragraph and removed the

> example problems, which included a lot of do= main-specific terms that

> were not properly explained and didn't add m= uch overall. I added STIR

> to the list of other relevant IETF WGs. The = substance of the charter

> hasn't changed, but I'd like the folks on th= e mailing list to review

> the changes before I put them into the track= er.

> 

> --

> 

> The MODERN working group will define a set o= f 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 infrastru= cture

> evolves to IP technology and new applications for TNs become pos= sible.

> 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. Devi= ces,

> applications, and network tools increasingly= need to manage TNs,

> including requesting and acquiring TN delega= tions from authorities.

> The output of the working group should make = distribution, acquisition,

> and management of TNs simpler for all entiti= es involved.

> 

> The working group will define an information= management framework for

> the roles and functions involved in associat= ing 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 inc= ludes either recommending

> or defining protocol mechanisms for acquirin= g, associating and

> resolving TNs, with a preference for use of = existing protocol

> mechanisms. TNs may either be managed in a h= ierarchical tree, or in a

> distributed registry. The protocol mechanism= for acquiring TNs will

> provide an enrollment process for the entiti= es that use and manage TNs.

> 

> The protocol mechanism for resolving TNs wil= l allow entities such as

> service providers, devices, and applications= to access data related to

> TNs. Maintaining reliability, real-time appl= ication performance, and

> security and privacy for both the data and t= he protocol interactions

> are primary considerations. The working grou= p will take into

> consideration existing IETF work including S= TIR, 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 com= munication with another

> user of a service. There is an expectation t= hat aspects of the

> architecture and protocols defined by the wo= rking 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 t= he working group will be

> flexible enough to accommodate different pol= icies for TN assignment

> and management, for example those establishe= d by different regulatory agencies.

> 

> The working group will deliver the following= :

> 

> - An architecture overview, including high l= evel requirements and

> security/privacy considerations

> 

> - A description of the enrollment processes = for existing and new TNs

> including any modifications to metadata rela= ted to those TNs

> 

> - A description of protocol mechanisms for a= ccessing 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

> 

 

_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.i= etf.org/mailman/listinfo/modern

 

_______________________________________________

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_9731a5aaf58e47fb9c969d0491806baePLSWE13M08adsprintcom_-- From nobody Wed Jun 10 15:15: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 05B771A1BF6; Wed, 10 Jun 2015 15:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LJeadI2Ad_Qj; Wed, 10 Jun 2015 15:15:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AFB01A1BE9; Wed, 10 Jun 2015 15:15:48 -0700 (PDT) Received: from BN1AFFO11FD019.protection.gbl (10.58.52.32) by BN1AFFO11HUB010.protection.gbl (10.58.52.120) with Microsoft SMTP Server (TLS) id 15.1.190.9; Wed, 10 Jun 2015 22:15:29 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; neustar.biz; 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 BN1AFFO11FD019.mail.protection.outlook.com (10.58.52.79) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Wed, 10 Jun 2015 22:15:28 +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 t5ALYjak041127; Wed, 10 Jun 2015 17:15:27 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm2.corp.sprint.com with ESMTP id 1uuxn0wykx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Jun 2015 17:15:27 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 10 Jun 2015 18:15:26 -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; Wed, 10 Jun 2015 17:15:25 -0500 From: "Gorman, Pierce A [CTO]" To: "Castagna, James T (Jim)" , Steve Donovan , Alissa Cooper , The IESG Thread-Topic: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) Thread-Index: AQHQo5G/nfo3WVLuq0OHZJZVOUafo52mMhsAgAAbxbCAAAC44A== Date: Wed, 10 Jun 2015 22:15:25 +0000 Message-ID: <87bd231a4f5f41e2a75196e13f6f6b39@PLSWE13M08.ad.sprint.com> References: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> <557856FC.8020800@usdonovans.com> <480816B49261A94EB6628FA890E4C7B6141A9129A7@FHDP1LUMXC7V11.us.one.verizon.com> <9731a5aaf58e47fb9c969d0491806bae@PLSWE13M08.ad.sprint.com> In-Reply-To: <9731a5aaf58e47fb9c969d0491806bae@PLSWE13M08.ad.sprint.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.22] Content-Type: multipart/related; boundary="_004_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD019; 1:B8VXqir35Y+EXF3AP21wY9+gOHJF0Ypr0S9QPIFMWAni4CB3xVldHj0rAlfmM/4zP7o+UuyJxc84vtx/gKkzmhBWBijdEr2ZjIPmXg+aU/auty+BANxyMYWVrQxV+6Z3fTHXB8H8TkXcFXtMGI8sedf6d1yTpMmX3S40M07ecX1+AbKKPKNjVoDitA27sTNmS37esLXWHtovoimXyGz+FrSWkEBmAI2h1lHs5+FZuOZ/zGtXiKifYTYeUUV+BIg7jHsdGbvHVhr7DGYMS8LYcQOiRBnG9lI5RRAZNeYVbw3QR1FX9NYA1clyt6h/yZU3njg2k8FLy6I+3hkgLiqbjQ== X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(448002)(479174004)(51704005)(377454003)(52044002)(189002)(13464003)(199003)(24454002)(67866002)(5250100002)(46102003)(77156002)(189998001)(19625215002)(108616004)(512954002)(15975445007)(106116001)(54356999)(76176999)(102836002)(2656002)(106466001)(2900100001)(2950100001)(5001960100002)(62966003)(17760045003)(230783001)(87936001)(99936001)(19627595001)(33646002)(85326001)(18206015028)(19617315012)(575784001)(93886004)(86362001)(92566002)(84326002)(19300405004)(19580405001)(5001770100001)(30436002)(50986999)(16236675004)(66926002)(19580395003)(24736003)(6806004)(5003600100002)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB010; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB010; 2:hY8SK88sYVRhizNRysb4BcVssB0wAOIVpu4XTM+189drJx2WAauFMH9Aek59k6L9; 2:hOh3o3rbidNjRz+uu+bbM+yaOFcgUyY6gpLcOUmHLZpU8X4sme/hFEQWxAK89TO4w9C4L//AF3MrnPmCht9npkHTvofHl7JeVeSKEGKsg1QOwT3c1ewZNNamr+O+Cd3LpjBcvW+MEeGkBvj0/Zh4+gzsLmPFQrEpZDUOFLLKLIEmvuOJkztbH0Qec2MUXucprrCae1SpBycwMBtM3bl6kIAMVPCMy8pQ/nxkQ4bSYHHjuN6dAXnpW5r/YmPEdK2m; 6:9idNtYFHYUwh0oTd6NpET+6ZtIj+rtXwuadmQQJs2a2UvDQ+gePEOKNJ5tPmmy7Moup+ufGybCMRN9hpsxsZCY++3vlg43oCeZiruUNBTeV0eHUGowp5fS9favmKSMjh79YWS6sloXsHL2IiO5GIeZwtofHwn4Eebqz3Pwk4nJp3PVYFmucxGecdGAajJQzv4dNPYgCCKs5mBoEjaYmUnMpCVNHJuK9JEIOIhwEL+aEAabm8IYVnw7CQie29b/n4; 3:vfzOlnJgUlFJWEEjDAlSCFmXbLNU5T9JYGM0CQNRyqdz890nQBpvBfVZax7Wa1yuFtEG6ztAojEyMtpBAF6yAp8duPxj6RRDy+BJ9Rirlt0tdQNWDmR9k6tRpriuPzj5hyCM/1yQOgkYgrjqCcEcJiv3ZKaLHWqAzjrpXy1B4+Zib+PS35osgNQgw4Xc0GFavTHUpT0Vn2Y53TE/rFUdRBya927flDzbXznfjm6EL2nGRDhoAeGQuCJb68MaQ8wkQVP3eavCAPx4LAsL/+QPD8JC4hLMymlyugqUDLEkndWB8+dza+eUrNY3IxuVc9dr X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB010; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1AFFO11HUB010; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB010; X-Forefront-PRVS: 06036BD506 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB010; 9:EgtiTtfc4SueUCN1v45ITdHY7a4KdEk92IcL+T10?= =?us-ascii?Q?CvUKyBDU55PLcNnxZY15P7ZLWEVSifntUisDVn6yneshS15EjCG3FfXLtet9?= =?us-ascii?Q?/3z0Ksq+Z7QchZ7/UwOKwlLgoFNoXm2IQlNtvM16qpqHyamr1hm/x50w6UB1?= =?us-ascii?Q?1TezRu9r5RmazENDA1F9Z02b7EiQkg3N/hh0m+SWLHulXiY4hEhoozAtw7dm?= =?us-ascii?Q?Kd6cYWy/JBSMVt7pGazoPRV8Ul6evk5FuAI9LvzZ6nLAUBROS4UcbnKQRXkP?= =?us-ascii?Q?kZ/4L2fUhLNVUwhUiIlnMe/ceDM32ZcuMMolqO3VoXt/gnU5zYaABX8kPITQ?= =?us-ascii?Q?aSB3kwclm+LKREhRkx8/HgmLAfUbsnnCwq+3P5UYqGSjlTBw8MvQHZyOGJnn?= =?us-ascii?Q?/QZ7dmdi42xpqKwbOc7hL1XtRZDNwkbZh6nITV3j+vyh0AHwmbi0DkqKux0l?= =?us-ascii?Q?rEjybLxnVW6seLglcRyb0Gsv3U7gyOBU3H8nOJMZ710+cD4Im9U7asdOebFK?= =?us-ascii?Q?0Fx7OaqWqjjh/H5HLlLxXhg9PDVCOrBv4Yw2u5Lbr6gzd54fDLUUXwZ6FJVg?= =?us-ascii?Q?IG6yYGXx00v+OQje3PbPWNly6lGjvSvPZ2kMOeVpOVbhj6gC9cSG6i87bEM8?= =?us-ascii?Q?PZ7AwYgTOzLEM1qCF2UxYghocZ+ElVo5FxaKvmrd1ogCR9oIKGo6g7M9+73h?= =?us-ascii?Q?2PTh0gOhKJqT9vhgosAN8GqjO/LIvgYrDizEDCiPNGzRCVVqoO8nTVRalgT7?= =?us-ascii?Q?JfUlSPQhuSabRA0r236QtVRpVz6kcWmIYsodUAe34uB4YKRSMq5txPeFUyPA?= =?us-ascii?Q?VJoowzP+tu8o5a6dewEIJzFwQZMEYFGkcVlBXZzOSrgNokDYjpD7Ky1vZskO?= =?us-ascii?Q?wbwDo/VexeUGoC34AOJLYGpRvprkutHEjqxwTAAAhYHyhH/tYaDnUV9ykKAw?= =?us-ascii?Q?BiW3NMf0KTrcEeWZERWnqql0AAhUxjPIIKA119zeQekcLfGUProv8VBdfKrS?= =?us-ascii?Q?nLiTPzfbJpGzYZYUpvHY4OLg/3v6OMW4d6FbaFK+P0aOLIIxivWsTY53eSP1?= =?us-ascii?Q?kEppps/vvDYFrxqqUCJX9OvIi+2nKeW73MunUQwC4M8c6C0GhQd26ttMwPc/?= =?us-ascii?Q?POS3G1/rjROthX4GlV10uVxq81o5I+PL2inv2w3o+Fo9vWVEa/O6ePilqpI1?= =?us-ascii?Q?bXi0A4AxqCXZ0xzErW80RV2r4AullFwNMRK81Ega8FfPqwAq5+vmO0MrQlTx?= =?us-ascii?Q?CG5Qb9TlgehYxSAMim/dF4hyNsWNP2vivwEI7V4ITe+nZ7sxRz9bFy/Lio8q?= =?us-ascii?Q?0NSxAofybIw9JgWRxeWiFGm54Q8rtguzqE/WoUgDeANl/heECS6mjjd/aLFm?= =?us-ascii?Q?F91KhKMiPkv4Zm0NGEcYvQWhklhbW2LKi/dLzqkBJg259nEg?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB010; 3:cwRly5pKs7Z+m64ciWwVVvcnKPwhw33u4jqAeIdgwg75AGDO3wgkEgtkadkVwbQNEBImiUlbGZyCXAeYJmwiwHESO2mKCsrchV8KTVdAJqGCpRD8/zggKKBdXefjP3CPEgq/wdUGYJ3Ni8C7GqeGKQ==; 10:x36GYzt0RiHyjYZWepL2SBtcOZsa+hBibCAXlPtdgnnjh9djtsOgPWbiIryAgp9HeM6IafEX/3s5un9E+ONHHunsOG0C8uhV0uAg61DdpCQ= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2015 22:15:28.7197 (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: BN1AFFO11HUB010 Archived-At: Cc: "ben@nostrum.com" , "modern@ietf.org" , Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) 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, 10 Jun 2015 22:15:53 -0000 --_004_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_" --_000_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I should also mention Sprint agrees with the suggested changes from Jim. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A= [CTO] Sent: June 10, 2015 5:13 PM To: Castagna, James T (Jim); Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) I think you meant 2nd, 3rd, and 4th sentences don't belong in the charter. = At least, that's what you deleted. (See highlighted deleted sentences bel= ow.) 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 Castagna, James = T (Jim) Sent: June 10, 2015 10:33 AM To: Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Now that the charter is nearly finalized it becomes more evident that the s= econd and third sentences in the first paragraph don't belong in a charter.= I don't believe the IETF needs to substantiate their interest in developi= ng new tools and eliminating these sentences will avoid the misinterpretati= on that these issues are the only reasons why the IETF is taking on this wo= rk. See how it reads without these sentences: -- MODERN (2 / 3 paragraph deleted) 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, June 10, 2015 11:26 AM To: Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) Alissa, The changes look good to me. Steve On 6/9/15 6:09 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-modern-00-02: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-modern/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since I was on leave and Ben was shepherding this work until very > recently, I did not have a chance to provide comments on the charter > until now. I think overall the charter is good but I have a bunch of > suggestions to make it crisper and more understandable for people who > are new to this work. In the edit below I've tried to remove some of > the redundant language. I edited the first paragraph and removed the > example problems, which included a lot of domain-specific terms that > were not properly explained and didn't add much overall. I added STIR > to the list of other relevant IETF WGs. The substance of the charter > hasn't changed, but I'd like the folks on the mailing list to review > the changes before I put them into the tracker. > > -- > > 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. > The output of the working group should make distribution, acquisition, > and management of TNs simpler for all entities involved. > > 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. TNs may either be managed in a hierarchical tree, or in a > distributed registry. The protocol mechanism for acquiring TNs will > provide an enrollment process for the entities that use and manage TNs. > > 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, and > security and privacy for both the data and the protocol interactions > are primary considerations. The working group will take into > consideration existing IETF work including STIR, 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. 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 for TN assignment > and management, for example those established by different regulatory age= ncies. > > The working 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 > _______________________________________________ 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. ________________________________ 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_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I should also mention Sprint agrees with the suggested c= hanges from Jim.

 

Best regards,

 

 

Pierce Gorman=

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorm= an@sprint.com

3D"cid:408000_086801428601145001@pvmxe13=

 

From: Modern [mailto:modern-bounces@ietf.org]= On Behalf Of Gorman, Pierce A [CTO]
Sent: June 10, 2015 5:13 PM
To: Castagna, James T (Jim); Steve Donovan; Alissa Cooper; The IESG<= br> Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry
Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-= 02: (with COMMENT)

 

I think you meant 2nd, 3rd, and 4th sentences don= 't belong in the charter.  At least, that's what you deleted.  (S= ee highlighted deleted sentences below.)

 

Best regards,

 

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierc= e.gorman@sprint.com

 

 

-----Original Message-----
From: Modern [mailto:modern-boun= ces@ietf.org] On Behalf Of Castagna, James T (Jim)
Sent: June 10, 2015 10:33 AM
To: Steve Donovan; Alissa Cooper; The IESG
Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry
Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT)

 

-------------------------------------------------= ---------------------

COMMENT:

-------------------------------------------------= ---------------------

 

Now that the charter is nearly finalized it becom= es more evident that the second and third sentences in the first paragraph = don't belong in a charter.  I don't believe the IETF needs to substant= iate their interest in developing new tools and eliminating these sentences will avoid the misinterpretation that thes= e issues are the only reasons why the IETF is taking on this work. 

 

See how it reads without these sentences:

 

--

 

MODERN (2 / 3 paragraph deleted)

 

The MODERN working group will define a set of Int= ernet-based mechanisms for the purposes of managing and resolving telephone= numbers (TNs) in an IP environment. Devices, applications, and network too= ls increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The ou= tput of the working group should make distribution, acquisition, and manage= ment of TNs simpler for all entities involved.

 

The working group will define an information mana= gement framework for the roles and functions involved in associating inform= ation with one or more TNs in an IP environment.  The working group wi= ll also identify protocol mechanisms to support the interactions between the functions defined by the framework. T= his includes either recommending or defining protocol mechanisms for acquir= ing, associating and resolving TNs, with a preference for use of existing p= rotocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The proto= col mechanism for acquiring TNs will provide an enrollment process for the = entities that use and manage TNs.

 

The protocol mechanism for resolving TNs will all= ow entities such as service providers, devices, and applications to access = data related to TNs. Maintaining reliability, real-time application perform= ance, and security and privacy for both the data and the protocol interactions are primary considerations. Th= e working group will take into consideration existing IETF work including S= TIR, ENUM, SPEERMINT, DRINKS and SCIM.

 

The work of this group will focus on TNs, as defi= ned in RFC3966, and blocks of TNs, that are used to initiate communication = with another user of a service. 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 for TN assignment and management, for example those est= ablished by different regulatory agencies.

 

The working group will deliver the following:

 

- An architecture overview, including high level = requirements and security/privacy considerations

 

- A description of the enrollment processes for e= xisting and new TNs including any modifications to metadata related to thos= e TNs

 

- A description of protocol mechanisms for access= ing contact information associated with enrollments

 

- A description of mechanisms for resolving infor= mation related to TNs

 

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

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

Sent: Wednesday, June 10, 2015 11:26 AM

To: Alissa Cooper; The IESG

Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry

Subject: Re: [Modern] Alissa Cooper's Yes on char= ter-ietf-modern-00-02: (with COMMENT)

 

  Alissa,

 

The changes look good to me.

 

Steve

 

On 6/9/15 6:09 PM, Alissa Cooper wrote:

> Alissa Cooper has entered the following ball= ot position for

> charter-ietf-modern-00-02: Yes

> 

> When responding, please keep the subject lin= e intact and reply to all

> email addresses included in the To and CC li= nes. (Feel free to cut

> this introductory paragraph, however.)<= /o:p>

> 

> 

> 

> The document, along with other ballot positi= ons, can be found here:

> https://datatracker.i= etf.org/doc/charter-ietf-modern/

> 

> 

> 

> --------------------------------------------= --------------------------

> COMMENT:

> --------------------------------------------= --------------------------

> 

> Since I was on leave and Ben was shepherding= this work until very

> recently, I did not have a chance to provide= comments on the charter

> until now. I think overall the charter is go= od but I have a bunch of

> suggestions to make it crisper and more unde= rstandable for people who

> are new to this work. In the edit below I've= tried to remove some of

> the redundant language. I edited the first p= aragraph and removed the

> example problems, which included a lot of do= main-specific terms that

> were not properly explained and didn't add m= uch overall. I added STIR

> to the list of other relevant IETF WGs. The = substance of the charter

> hasn't changed, but I'd like the folks on th= e mailing list to review

> the changes before I put them into the track= er.

> 

> --

> 

> The MODERN working group will define a set o= f 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 infrastru= cture

> evolves to IP technology and new applications for TNs become pos= sible.

> 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. Devi= ces,

> applications, and network tools increasingly= need to manage TNs,

> including requesting and acquiring TN delega= tions from authorities.

> The output of the working group should make = distribution, acquisition,

> and management of TNs simpler for all entiti= es involved.

> 

> The working group will define an information= management framework for

> the roles and functions involved in associat= ing 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 inc= ludes either recommending

> or defining protocol mechanisms for acquirin= g, associating and

> resolving TNs, with a preference for use of = existing protocol

> mechanisms. TNs may either be managed in a h= ierarchical tree, or in a

> distributed registry. The protocol mechanism= for acquiring TNs will

> provide an enrollment process for the entiti= es that use and manage TNs.

> 

> The protocol mechanism for resolving TNs wil= l allow entities such as

> service providers, devices, and applications= to access data related to

> TNs. Maintaining reliability, real-time appl= ication performance, and

> security and privacy for both the data and t= he protocol interactions

> are primary considerations. The working grou= p will take into

> consideration existing IETF work including S= TIR, 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 com= munication with another

> user of a service. There is an expectation t= hat aspects of the

> architecture and protocols defined by the wo= rking 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 t= he working group will be

> flexible enough to accommodate different pol= icies for TN assignment

> and management, for example those establishe= d by different regulatory agencies.

> 

> The working group will deliver the following= :

> 

> - An architecture overview, including high l= evel requirements and

> security/privacy considerations

> 

> - A description of the enrollment processes = for existing and new TNs

> including any modifications to metadata rela= ted to those TNs

> 

> - A description of protocol mechanisms for a= ccessing 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

> 

 

_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.i= etf.org/mailman/listinfo/modern

 

_______________________________________________

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.



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_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_-- --_004_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Wed, 10 Jun 2015 22:15:24 GMT"; modification-date="Wed, 10 Jun 2015 22:15:24 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_87bd231a4f5f41e2a75196e13f6f6b39PLSWE13M08adsprintcom_-- From nobody Wed Jun 10 15:36:55 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 BE9401B2CAE; Wed, 10 Jun 2015 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, RCVD_IN_DNSWL_LOW=-0.7, 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 9_BRos_gB7lC; Wed, 10 Jun 2015 15:36:43 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAD11A8F4B; Wed, 10 Jun 2015 15:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1433975802; x=1465511802; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version; bh=MTR4JHupWXhD8ixqofhTS+nWLMxDs1utl5vd7DpLjOc=; b=ekc28WbyWmCthf96oGOTqHv02RSHuLiqbBVuRLL/Topadem755MOYIqq QDHjcsu3bxd/yFvld4PNILATHCewExQmY95c2JBjIzmkZZmTVCP5XqaWH SlSJ8ZxTYk492Vm30W8nsuCK5CJu1kXebfbjr/sEO/U0egCsIsqOap3md o=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe03.verizon.com with ESMTP; 10 Jun 2015 22:36:41 +0000 From: "Castagna, James T (Jim)" X-IronPort-AV: E=Sophos;i="5.13,590,1427760000"; d="png'150?scan'150,208,217,150";a="1017101222" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 10 Jun 2015 22:36:40 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 10 Jun 2015 18:36:40 -0400 To: "Gorman, Pierce A [CTO]" , Steve Donovan , Alissa Cooper , The IESG Date: Wed, 10 Jun 2015 18:36:39 -0400 Thread-Topic: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) Thread-Index: AQHQo5G/nfo3WVLuq0OHZJZVOUafo52mMhsAgAAbxbCAAAC44IAABeDg Message-ID: <480816B49261A94EB6628FA890E4C7B6141A912C52@FHDP1LUMXC7V11.us.one.verizon.com> References: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> <557856FC.8020800@usdonovans.com> <480816B49261A94EB6628FA890E4C7B6141A9129A7@FHDP1LUMXC7V11.us.one.verizon.com> <9731a5aaf58e47fb9c969d0491806bae@PLSWE13M08.ad.sprint.com> <87bd231a4f5f41e2a75196e13f6f6b39@PLSWE13M08.ad.sprint.com> In-Reply-To: <87bd231a4f5f41e2a75196e13f6f6b39@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "ben@nostrum.com" , "modern@ietf.org" , Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) 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, 10 Jun 2015 22:36:47 -0000 --_004_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_ Content-Type: multipart/alternative; boundary="_000_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_" --_000_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My error, thank you. From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com] Sent: Wednesday, June 10, 2015 6:15 PM To: Castagna, James T (Jim); Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: RE: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) I should also mention Sprint agrees with the suggested changes from Jim. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:image001.png@01D0A3AC.634A9900] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A= [CTO] Sent: June 10, 2015 5:13 PM To: Castagna, James T (Jim); Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) I think you meant 2nd, 3rd, and 4th sentences don't belong in the charter. = At least, that's what you deleted. (See highlighted deleted sentences bel= ow.) 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 Castagna, James = T (Jim) Sent: June 10, 2015 10:33 AM To: Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Now that the charter is nearly finalized it becomes more evident that the s= econd and third sentences in the first paragraph don't belong in a charter.= I don't believe the IETF needs to substantiate their interest in developi= ng new tools and eliminating these sentences will avoid the misinterpretati= on that these issues are the only reasons why the IETF is taking on this wo= rk. See how it reads without these sentences: -- MODERN (2 / 3 paragraph deleted) 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, June 10, 2015 11:26 AM To: Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT) Alissa, The changes look good to me. Steve On 6/9/15 6:09 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-modern-00-02: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-modern/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since I was on leave and Ben was shepherding this work until very > recently, I did not have a chance to provide comments on the charter > until now. I think overall the charter is good but I have a bunch of > suggestions to make it crisper and more understandable for people who > are new to this work. In the edit below I've tried to remove some of > the redundant language. I edited the first paragraph and removed the > example problems, which included a lot of domain-specific terms that > were not properly explained and didn't add much overall. I added STIR > to the list of other relevant IETF WGs. The substance of the charter > hasn't changed, but I'd like the folks on the mailing list to review > the changes before I put them into the tracker. > > -- > > 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. > The output of the working group should make distribution, acquisition, > and management of TNs simpler for all entities involved. > > 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. TNs may either be managed in a hierarchical tree, or in a > distributed registry. The protocol mechanism for acquiring TNs will > provide an enrollment process for the entities that use and manage TNs. > > 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, and > security and privacy for both the data and the protocol interactions > are primary considerations. The working group will take into > consideration existing IETF work including STIR, 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. 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 for TN assignment > and management, for example those established by different regulatory age= ncies. > > The working 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 > _______________________________________________ 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. ________________________________ 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_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My error, thank you.

=  

 

From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
<= b>Sent: Wednesday, June 10, 2015 6:15 PM
To: Castagna, James = T (Jim); Steve Donovan; Alissa Cooper; The IESG
Cc: ben@nostrum.c= om; modern@ietf.org; Tom McGarry
Subject: RE: [Modern] Alissa Coo= per's Yes on charter-ietf-modern-00-02: (with COMMENT)

 

I should al= so mention Sprint agrees with the suggested changes from Jim.

 

Best regards,

 

 = ;

Pierce Gorman

Core Network Planning

O: 913-439-4368=

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"<= /o:p>

 

<= p class=3DMsoNormal>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pi= erce A [CTO]
Sent: June 10, 2015 5:13 PM
To: Castagna, = James T (Jim); Steve Donovan; Alissa Cooper; The IESG
Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry
Subject: Re: [Modern] A= lissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT)<= /p>

 

I think you meant 2nd, 3rd, and 4th sentences don't belong in the cha= rter.  At least, that's what you deleted.  (See highlighted delet= ed sentences below.)

 

Best regards,

 

 

Pierce Gorman

Co= re Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

 

 

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of C= astagna, James T (Jim)
Sent: June 10, 2015 10:33 AM
To: Steve Donovan= ; Alissa Cooper; The IESG
Cc: ben@nos= trum.com; modern@ietf.org; Tom M= cGarry
Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-= 00-02: (with COMMENT)

 

---------------------------------------------= -------------------------

COMMENT:

---------------------------------------= -------------------------------

=  

Now that the charter is nearly fina= lized it becomes more evident that the second and third sentences in the fi= rst paragraph don't belong in a charter.  I don't believe the IETF nee= ds to substantiate their interest in developing new tools and eliminating t= hese sentences will avoid the misinterpretation that these issues are the o= nly reasons why the IETF is taking on this work. 

 

See how it = reads without these sentences:

&= nbsp;

--

 

MODERN (2 / 3 paragraph d= eleted)

 

The MODERN working group will define a set of Internet-base= d mechanisms for the purposes of managing and resolving telephone numbers (= TNs) in an IP environment. Devices, applications, and network tools increas= ingly need to manage TNs, including requesting and acquiring TN delegations= from authorities. The output of the working group should make distribution= , acquisition, and management of TNs simpler for all entities involved.

 

The working group will define an information management framework for = the roles and functions involved in associating information with one or mor= e TNs in an IP environment.  The working group will also identify prot= ocol mechanisms to support the interactions between the functions defined b= y the framework. This includes either recommending or defining protocol mec= hanisms for acquiring, associating and resolving TNs, with a preference for= use of existing protocol mechanisms. TNs may either be managed in a hierar= chical tree, or in a distributed registry. The protocol mechanism for acqui= ring TNs will provide an enrollment process for the entities that use and m= anage TNs.

 

The protocol mechanism for resolving TNs will allow ent= ities such as service providers, devices, and applications to access data r= elated to TNs. Maintaining reliability, real-time application performance, = and security and privacy for both the data and the protocol interactions ar= e primary considerations. The working group will take into consideration ex= isting IETF work including STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies.

 

=

The working group will deliver the following:<= /o:p>

 

- An architecture overview, including high level requirements and securi= ty/privacy considerations

 =

- A description of the enrollment process= es 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

 

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

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

Sent: Wednesday, June 10, 2015= 11:26 AM

To: Alissa Cooper; The IESG=

Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry<= /p>

Subject: Re: [Modern] Alissa Cooper's Yes on cha= rter-ietf-modern-00-02: (with COMMENT)

 

  Alissa,

 

The c= hanges look good to me.

 

Steve

 

On 6/9/15 6:09 PM, Alissa Coo= per wrote:

> Alissa Cooper has ent= ered the following ballot position for

> charter-ietf-modern-00-02: Yes

> 

> When responding, ple= ase keep the subject line intact and reply to all

> email addresses included in the To and CC lines. (Feel= free to cut

> this introductory = paragraph, however.)

> <= /o:p>

> 

> 

> The document, = along with other ballot positions, can be found here:

> https://= datatracker.ietf.org/doc/charter-ietf-modern/

> 

> 

> 

> -----------------------------------------------------= -----------------

> COMMENT:<= /o:p>

> -------------------------------------= ---------------------------------

>= ; 

> Since I was on leave and= Ben was shepherding this work until very

> recently, I did not have a chance to provide comments on the cha= rter

> until now. I think overall= the charter is good but I have a bunch of

> suggestions to make it crisper and more understandable for peop= le who

> are new to this work. In= the edit below I've tried to remove some of

> the redundant language. I edited the first paragraph and remo= ved the

> example problems, which= included a lot of domain-specific terms that

> were not properly explained and didn't add much overall. I a= dded STIR

> to the list of other = relevant IETF WGs. The substance of the charter

> hasn't changed, but I'd like the folks on the mailing list= to review

> the changes before I= put them into the tracker.

>=  

> --

> 

> The MODERN= working group will define a set of Internet-based

> mechanisms for the purposes of managing and resolving = telephone

> numbers (TNs) in an I= P environment. Exist= ing mechanisms for these

> purposes face obsol= escence as the voice communications infrastructure

> evolves to IP technology and new applications for TNs become possibl= e.

> The traditional model of a TN having an as= sociation to a single

> service provider and a= single application is breaking down. Its use as

> a network locato= r is going away, but its use as an identifier for an

=

= > individual or an organization will remain for some time. Device= s,

> applications, and network to= ols increasingly need to manage TNs,

> including requesting and acquiring TN delegations from authorities.

> The output of the working group s= hould make distribution, acquisition,

> and management of TNs simpler for all entities involved.<= /p>

> 

> The working group will define an information management framework for=

> the roles and functions involv= ed in associating information with one

> or more TNs in an IP environment.  The working group will also=

> identify protocol mechanisms t= o support the interactions between the

> functions defined by the framework. This includes either recommendi= ng

> or defining protocol mechani= sms for acquiring, associating and

&= gt; resolving TNs, with a preference for use of existing protocol

> mechanisms. TNs may either be managed in= a hierarchical tree, or in a

> d= istributed registry. The protocol mechanism for acquiring TNs will

> provide an enrollment process for the e= ntities that use and manage TNs.

>=  

> The protocol mechanism fo= r resolving TNs will allow entities such as

> service providers, devices, and applications to access data re= lated to

> TNs. Maintaining relia= bility, real-time application performance, and

> security and privacy for both the data and the protocol int= eractions

> are primary considera= tions. The working group will take into

> consideration existing IETF work including STIR, ENUM, SPEERMINT, = DRINKS and SCIM.

> 

> The work of this group will focus on TNs,= as defined in RFC3966, and

> blo= cks of TNs, that are used to initiate communication with another

> user of a service. There is an expectatio= n that aspects of the

> architect= ure and protocols defined by the working group will be

> reusable for other user-focused identifiers. Any su= ch extensions or

> reuse of MODER= N mechanisms are out of scope for the MODERN working

> group. Solutions and mechanisms created by the workin= g group will be

> flexible enough= to accommodate different policies for TN assignment

> and management, for example those established by diff= erent regulatory agencies.

>&= nbsp;

> The working group will deliver = the following:

> <= /p>

> - An architecture overview, including high = level requirements and

> security= /privacy considerations

>&nbs= p;

> - A description of the enrollment = processes for existing and new TNs

&= gt; including any modifications to metadata related to those TNs=

> 

> - A description of protocol mechanisms for accessing contact

> information associated with enrollment= s

> 

> - A description of mechanisms for resolving informatio= n related to TNs

> 

> 

> _______________________________________________

> Modern mailing list

> Modern@ietf.org

> https://www.ietf.o= rg/mailman/listinfo/modern

> 

 

_______________________________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.or= g/mailman/listinfo/modern

=  

______________________________= _________________

Modern mailing list=

<= span style=3D'color:windowtext;text-decoration:none'>Modern@ietf.org=

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

<= p class=3DMsoPlainText> 

 

&nbs= p;


This e-mail may contain Sprint proprietary information intende= d 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 a= ll copies of the message.

&nb= sp;


This e-mail may contain Sprint proprietary information intend= ed for the sole use of the recipient(s). Any use by others is prohibited. I= f you are not the intended recipient, please contact the sender and delete = all copies of the message.

= --_000_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_-- --_004_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Wed, 10 Jun 2015 22:36:39 GMT"; modification-date="Wed, 10 Jun 2015 22:36:39 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_480816B49261A94EB6628FA890E4C7B6141A912C52FHDP1LUMXC7V1_-- From nobody Wed Jun 10 20:10: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 01D9E1A89A8 for ; Wed, 10 Jun 2015 20:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_BASE64_BLANKS=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 yRJdx6MtSw-V for ; Wed, 10 Jun 2015 20:10:08 -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 112871A00E4 for ; Wed, 10 Jun 2015 20:10:08 -0700 (PDT) Received: (qmail 24387 invoked by uid 0); 11 Jun 2015 03:10:07 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 11 Jun 2015 03:10:07 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id eqiL1q00N1MNPNq01qiP8f; Wed, 10 Jun 2015 20:42:32 -0600 X-Authority-Analysis: v=2.1 cv=cooIzTIi 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=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=izV7ms69AAAA:8 a=ZsyXEVtvAAAA:8 a=yakATiurAAAA:8 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=hGBaWAWWAAAA:8 a=XSaUPZVfOiL5Hs0oYSgA:9 a=bqM8gRuS_NXGiHBK:21 a=wQ4tD0PEfhfJGtuR:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=DzjOOp_o1eYA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=LhTPfU53co6TTTfLSW8A:9 a=8Pk6bRi-zV8VCl7A:21 a=Ac_hsCev3Iwc0lDS:21 a=Pvyl1de_b2IiyL3Y: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:CC:To:From:Subject:Date; bh=ihwP1T8aFtvyQoivRk72Rpvmh4MI90ZyRT/97k5pHL0=; b=EIIx0RVBTBStUMaBqbftYwiWpWnFPtq7q3PAWPs8sJfdPoMqCbSsPVW6Ch/txb9VAJtqweNB+pQT1kHqkQrtSLrAmzFpVaUiwyO/5Nmnt0t/iIde2g3eHX2FNIVoWcy5; Received: from [108.56.131.149] (port=49987 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z2sZ1-0000g6-S6; Wed, 10 Jun 2015 20:49:56 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Wed, 10 Jun 2015 22:49:50 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , "Castagna, James T (Jim)" , Steve Donovan , Alissa Cooper , The IESG Message-ID: Thread-Topic: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) References: <20150609230952.25066.70663.idtracker@ietfa.amsl.com> <557856FC.8020800@usdonovans.com> <480816B49261A94EB6628FA890E4C7B6141A9129A7@FHDP1LUMXC7V11.us.one.verizon.com> <9731a5aaf58e47fb9c969d0491806bae@PLSWE13M08.ad.sprint.com> <87bd231a4f5f41e2a75196e13f6f6b39@PLSWE13M08.ad.sprint.com> In-Reply-To: <87bd231a4f5f41e2a75196e13f6f6b39@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3516821395_2477719" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Cc: "ben@nostrum.com" , "modern@ietf.org" , Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) 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, 11 Jun 2015 03:10:15 -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_3516821395_2477719 Content-type: multipart/alternative; boundary="B_3516821395_2461707" --B_3516821395_2461707 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable As do I.=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 From: "Pierce.Gorman@sprint.com" Date: Wednesday, June 10, 2015 at 6:15 PM To: James Castagna , Steve Donovan , Alissa Cooper , The IESG Cc: Ben Campbell , "modern@ietf.org" , Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) I should also mention Sprint agrees with the suggested changes from Jim. =20 Best regards, =20 =20 Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A [CTO] Sent: June 10, 2015 5:13 PM To: Castagna, James T (Jim); Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) =20 I think you meant 2nd, 3rd, and 4th sentences don't belong in the charter. At least, that's what you deleted. (See highlighted deleted sentences below.) =20 Best regards, =20 =20 Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com =20 =20 -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Castagna, James = T (Jim) Sent: June 10, 2015 10:33 AM To: Steve Donovan; Alissa Cooper; The IESG Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 Now that the charter is nearly finalized it becomes more evident that the second and third sentences in the first paragraph don't belong in a charter= . I don't believe the IETF needs to substantiate their interest in developing new tools and eliminating these sentences will avoid the misinterpretation that these issues are the only reasons why the IETF is taking on this work. =20 See how it reads without these sentences: =20 -- =20 MODERN (2 / 3 paragraph deleted) =20 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. =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 identify protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanism= s for acquiring, associating and resolving TNs, with a preference for use of existing protocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TN= s will provide an enrollment process for the entities that use and manage TNs= . =20 The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maintaining reliability, real-time application performance, and security an= d privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IET= F work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. =20 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. 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 for TN assignment and management, for example those established by different regulatory agencies. =20 The working group will deliver the following: =20 - An architecture overview, including high level requirements and security/privacy considerations =20 - A description of the enrollment processes for existing and new TNs including any modifications to metadata related to those TNs =20 - A description of protocol mechanisms for accessing contact information associated with enrollments =20 - A description of mechanisms for resolving information related to TNs =20 -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org ] On Behalf Of Steve Donovan Sent: Wednesday, June 10, 2015 11:26 AM To: Alissa Cooper; The IESG Cc: ben@nostrum.com ; modern@ietf.org ; Tom McGarry Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT) =20 Alissa, =20 The changes look good to me. =20 Steve =20 On 6/9/15 6:09 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-modern-00-02: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-modern/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Since I was on leave and Ben was shepherding this work until very > recently, I did not have a chance to provide comments on the charter > until now. I think overall the charter is good but I have a bunch of > suggestions to make it crisper and more understandable for people who > are new to this work. In the edit below I've tried to remove some of > the redundant language. I edited the first paragraph and removed the > example problems, which included a lot of domain-specific terms that > were not properly explained and didn't add much overall. I added STIR > to the list of other relevant IETF WGs. The substance of the charter > hasn't changed, but I'd like the folks on the mailing list to review > the changes before I put them into the tracker. >=20 > -- >=20 > 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. > The output of the working group should make distribution, acquisition, > and management of TNs simpler for all entities involved. >=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 > 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. TNs may either be managed in a hierarchical tree, or in a > distributed registry. The protocol mechanism for acquiring TNs will > provide an enrollment process for the entities that use and manage TNs. >=20 > 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, and > security and privacy for both the data and the protocol interactions > are primary considerations. The working group will take into > consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. >=20 > 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. 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 for TN assignment > and management, for example those established by different regulatory agencies. >=20 > The working group will deliver the following: >=20 > - An architecture overview, including high level requirements and > security/privacy considerations >=20 > - A description of the enrollment processes for existing and new TNs > including any modifications to metadata related to those TNs >=20 > - A description of protocol mechanisms for accessing contact > information associated with enrollments >=20 > - A description of mechanisms for resolving information related to TNs >=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 =20 _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern =20 =20 =20 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 th= e intended recipient, please contact the sender and delete all copies of the message. 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 th= e 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 --B_3516821395_2461707 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

As d= o I. 


— 
<= 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: "Pierce.Gorman@sprint.com" <Pierce.Gorman@sprint.com>
Date: Wednesday, June 10, 2015 at 6:15 PM
To: James Castagna <james.t.castagna@verizon.com>, Steve Donovan <= srdonovan@usdonovans.com>, = Alissa Cooper <alissa@cooperw.in&g= t;, The IESG <iesg@ietf.org>
Cc: Ben Campbell <ben@nostrum.com>, "mod= ern@ietf.org" <modern@ietf.org&g= t;, Tom McGarry <tom.mcgarry@neu= star.biz>
Subject: Re: [Mod= ern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT)

I should also mention Sprint= agrees with the suggested changes from Jim.

 

Best regards,<= /span>

 

 = ;

Pierce Gorman<= /span>

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

3D"cid:=

 

From:= Modern [mailto:modern-bounces@ietf= .org] On Behalf Of Gorman, Pierce A [CTO]
Sent: June 10, 2015 5:13 PM
To:<= /b> Castagna, James T (Jim); Steve Donovan; Alissa Cooper; The IESG
Cc= : ben@nostrum.com; modern@ietf.org; Tom McGarry
Subject: Re: [Mo= dern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (with COMMENT)<= /o:p>

 

I think you meant 2nd, 3rd, and 4th sentences don't belong in the= charter.  At least, that's what you deleted.  (See highlighted de= leted sentences below.)

 

Best regards,

 

 

Pierce Gorman

Cor= e Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

&nb= sp;

 

-----Original Message-----
From: Modern [mailto:modern-bounce= s@ietf.org] On Behalf Of Castagna, James T (Jim)
Sent: June 10, 2015 10:33 AM
To: Steve Donovan; Alissa Cooper; The IESG
Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry
Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern-00-02: (wi= th COMMENT)

 

---------------------------------------------------------= -------------

COMMENT:

<= p class=3D"MsoPlainText">-----------------------------------------------------= -----------------

 

Now that the charter is nearly finalized it becomes= more evident that the second and third sentences in the first paragraph don= 't belong in a charter.  I don't believe the IETF needs to substantiate= their interest in developing new tools and eliminating these sentences will avoid the misinterpretation that thes= e issues are the only reasons why the IETF is taking on this work. 

 

See how it reads without these sentences:

 

--

<= p class=3D"MsoPlainText"> 

MODERN (= 2 / 3 paragraph deleted)

 

The MODERN working group will define a set o= f Internet-based mechanisms for the purposes of managing and resolving telep= hone numbers (TNs) in an IP environment. Devices, applications, and network = tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The ou= tput of the working group should make distribution, acquisition, and managem= ent of TNs simpler for all entities involved.

 

The working group will = define an information management framework for the roles and functions invol= ved in associating information with one or more TNs in an IP environment.&nb= sp; The working group will also identify protocol mechanisms to support the interactions between the functions defined by the framework. T= his includes either recommending or defining protocol mechanisms for acquiri= ng, associating and resolving TNs, with a preference for use of existing pro= tocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The proto= col mechanism for acquiring TNs will provide an enrollment process for the e= ntities that use and manage TNs.

 

The protocol mechanism for resolving TNs will allow entities such a= s service providers, devices, and applications to access data related to TNs= . Maintaining reliability, real-time application performance, and security a= nd privacy for both the data and the protocol interactions are primary considerations. Th= e working group will take into consideration existing IETF work including ST= IR, ENUM, SPEERMINT, DRINKS and SCIM.

=  

The work of this group will foc= us on TNs, as defined in RFC3966, and blocks of TNs, that are used to initia= te communication with another user of a service. There is an expectation tha= t 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 M= ODERN working group. Solutions and mechanisms created by the working group w= ill be flexible enough to accommodate different policies for TN assignment and management, for example those est= ablished by different regulatory agencies.

 

The working group will del= iver the following:

 <= /p>

- An architecture overview, including high level = requirements and security/privacy considerations

 

- A description of t= he enrollment processes for existing and new TNs including any modifications= to metadata related to those TNs

 

- A description of protocol mechani= sms for accessing contact information associated with enrollments=

 

- A= description of mechanisms for resolving information related to TNs

 

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

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

Sent: Wednesday, June 10,= 2015 11:26 AM

To: Alissa Cooper; The = IESG

Cc: ben@nostrum.com; modern@ietf.org; Tom McGarry

Subject: Re: [Modern] Alissa Cooper's Yes on charter-ietf-modern= -00-02: (with COMMENT)

 

  Alissa,

 

The changes look good to= me.

 

Steve

 

On 6/9/15 6:09 PM, Alissa Cooper wrote:<= /p>

> Alissa Cooper has entered the following ball= ot position for

> charter-ietf-mode= rn-00-02: Yes

> 

> When responding, please keep the subject line = intact and reply to all

> email addresses included in the= To and CC lines. (Feel free to cut

> this introductory paragraph, ho= wever.)

> 

> 

> 

> The document, along with other= ballot positions, can be found here:

= > https://datatracker.ietf.org/do= c/charter-ietf-modern/

>=  

> 

> 

> ----= ------------------------------------------------------------------

> COMMENT:

> ------------------------------------------------------------------= ----

> 

> Since I was on leave and Ben was shepherding this work = until very

> recently, I did not have a chan= ce to provide comments on the charter

> until now. I think overall the = charter is good but I have a bunch of

> suggestions to make it crisper = and more understandable for people who

> are new to this work. In the ed= it below I've tried to remove some of

> the redundant language. I edite= d the first paragraph and removed the

> example problems, which include= d a lot of domain-specific terms that

> were not properly explained and= didn't add much overall. I added STIR

> to the list of other relevant I= ETF WGs. The substance of the charter

> hasn't changed, but I'd like th= e folks on the mailing list to review

> the changes before I put them i= nto the tracker.

> =

> --

&g= t; 

> 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 environm= ent. Existing mechanisms for these

> purposes face obs= olescence as the voice communications infrastructure

> evolves to IP technology and new applications f= or TNs become possible.

> The traditional model of = a TN having an association to a single

> service provider and a single application is br= eaking down.Its use = as

> a network locator is going away, but its use as a= n 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 acquir= ing TN delegations from authorities.

&= gt; The output of the working group should make distribution, acquisition,

> and management of TNs simpler f= or all entities involved.

>&nb= sp;

> The working group will define an i= nformation management framework for

> the roles and functions involve= d in associating information with one

> or more TNs in an IP environmen= t.  The working group will also

> identify protocol mechanisms to= support the interactions between the

> functions defined by the framew= ork. This includes either recommending

> or defining protocol mechanisms= for acquiring, associating and

> resolving TNs, with a preferenc= e for use of existing protocol

> mechanisms. TNs may either be m= anaged in a hierarchical tree, or in a

> distributed registry. The proto= col mechanism for acquiring TNs will

> provide an enrollment process f= or the entities that use and manage TNs.

> 

> The protocol mechan= ism for resolving TNs will allow entities such as

> service providers, devices, and= applications to access data related to

> TNs. Maintaining reliability, r= eal-time application performance, and

> security and privacy for both t= he data and the protocol interactions

> are primary considerations. The= working group will take into

> consideration existing IETF wor= k including STIR, 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. There is an = expectation that aspects of the

> architecture and protocols defi= ned 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 for TN assignment

> and management, for example tho= se established by different regulatory agencies.

> 

> The working= group will deliver the following:

>= ; 

> - An architecture overvie= w, including high level requirements and

> security/privacy considerations=

> 

> - A description of the enrollment processes for existing an= d new TNs

> including any modifications to = metadata related to those TNs

> 

> - A description of protocol me= chanisms for accessing contact

> information associated with enr= ollments

> 

> - A description of mechanisms for resolving informa= tion related to TNs

> 

> 

> _______________________________________________

> Modern mailing list

> Modern@ietf.org

> https://www.ietf.org/mailman/li= stinfo/modern

>&nbs= p;

 

_______________________________________________

Modern mailing list

Modern@ietf.org

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

 

_______________________________________________

<= p class=3D"MsoPlainText">Modern mailing list

Modern@ietf.org

https://www.ietf.org/mailman/listinfo/mode= rn

 

 

<= p class=3D"MsoNormal"> 


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 t= he intended recipient, please contact the sender and delete all copies of th= e message. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:24:12 -0000 I think the the charter would be fine with or without the sentences in = question, so if people prefer to remove them that seems okay. I don=92t = think these changes affect the scope of the group=92s work. I=92ll post the below version of the charter text to the tracker on = Friday and it will go out for external review then unless other folks on = the list object. Alissa On Jun 10, 2015, at 8:32 AM, Castagna, James T (Jim) = wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Now that the charter is nearly finalized it becomes more evident that = the second and third sentences in the first paragraph don't belong in a = charter. I don't believe the IETF needs to substantiate their interest = in developing new tools and eliminating these sentences will avoid the = misinterpretation that these issues are the only reasons why the IETF is = taking on this work. =20 >=20 > See how it reads without these sentences: >=20 > -- >=20 > MODERN (2 / 3 paragraph deleted) >=20 > 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. Devices, applications, and network tools = increasingly need to manage TNs, including requesting and acquiring TN = delegations from authorities. The output of the working group should = make distribution, acquisition, and management of TNs simpler for all = entities involved. >=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 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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs.=20 >=20 > 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, and = security and privacy for both the data and the protocol interactions are = primary considerations. The working group will take into consideration = existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. >=20 > 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. 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 for TN assignment and management, for = example those established by different regulatory agencies. >=20 > The working group will deliver the following: >=20 > - An architecture overview, including high level requirements and = security/privacy considerations >=20 > - A description of the enrollment processes for existing and new TNs = including any modifications to metadata related to those TNs >=20 > - A description of protocol mechanisms for accessing contact = information associated with enrollments >=20 > - A description of mechanisms for resolving information related to TNs From nobody Thu Jun 11 21:02: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 972CE1B2F5A; Thu, 11 Jun 2015 03:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aluYTewH4pgP; Thu, 11 Jun 2015 03:57:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3C1B2F57; Thu, 11 Jun 2015 03:57:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611105705.5381.54286.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 03:57:05 -0700 Archived-At: X-Mailman-Approved-At: Thu, 11 Jun 2015 21:02:00 -0700 Cc: modern@ietf.org, Steve Donovan , Alissa Cooper , Tom McGarry , ben@nostrum.com Subject: [Modern] Benoit Claise's No Objection on charter-ietf-modern-00-02: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 10:57:06 -0000 Benoit Claise has entered the following ballot position for charter-ietf-modern-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-modern/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I started to have questions around "lack of flexibility (for example, it can be difficult to add fields without a very elaborate and lengthy process typically spanning years)", then I only reviewed Alissa's new proposal at https://datatracker.ietf.org/doc/charter-ietf-modern/ballot/#alissa-cooper No objection to that one. From nobody Fri Jun 12 12:14: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 0D8CE1ACEC1; Fri, 12 Jun 2015 11:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Jaj-rS62-9SW; Fri, 12 Jun 2015 11:45:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11C1ACEBE; Fri, 12 Jun 2015 11:45:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612184539.31257.17908.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 11:45:39 -0700 Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 12:14:11 -0700 Cc: modern WG Subject: [Modern] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2015 18:45:41 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD From nobody Thu Jun 25 02:02: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 B59151B3367 for ; Thu, 25 Jun 2015 02:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QXzVefKHvkbj for ; Thu, 25 Jun 2015 02:02:24 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 07F7A1B31FF for ; Thu, 25 Jun 2015 02:02:23 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5P92Mpm032588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 25 Jun 2015 11:02:22 +0200 Received: from RHillNew (adsl-178-38-12-166.adslplus.ch [178.38.12.166]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5P92LXD007095 for ; Thu, 25 Jun 2015 11:02:21 +0200 From: "Richard Hill" To: Date: Thu, 25 Jun 2015 11:02:22 +0200 Message-ID: <007001d0af25$a5fe94c0$f1fbbe40$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCvJOg5Dlbkvi9rSgCEkL6kWmG8UwAAKV/A Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [Modern] FW: [new-work] Comment on WG modern 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, 25 Jun 2015 09:02:27 -0000 Please find below the message that I have sent to the IESG regarding the proposed creation of this working group. Best, Richard -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of Richard Hill Sent: Thursday, June 25, 2015 10:57 To: new-work@ietf.org Subject: [new-work] Comment on WG modern I refer to: https://www.ietf.org/mailman/private/new-work/2015-June/000533.html As I understand it, this is a proposal to create new working group that will consider managing, ordering, distributing, and registering telephone numbers. In my view, the proposed work clearly falls within the remit of ITU-T Study Group 2 and I don't think that it would be a good idea for the IETF to create a group whose mandate squarely overlaps with the mandate of ITU-T. A more detailed explanation follows. I presume that "telephone numbers" refers to E.164 numbers, that is, numbers that are standardized and administered in accordance with ITU-T Recommendations E.164, E.164.1, E.190, and related ITU-T Recommendations. In accordance with those recommendations, and related ITU Plenipotentiary Resolutions, the management and administration of those numbers is done at the international level by the Telecommunications Standardization Bureau (TSB) which assigned country codes (such as 41 for Switzerland) and by national authorities at the country level. Countries can have more than one country code, or less than one country code: that is, several countries can share one country code. The best-known example of this situation is country code 1, which is shared by the USA, Canada, and a number of other countries. The administration of the numbers under country code 1 is performed by the North American Numbering Plan Administration, which is a private entity to which the US Federal Communication Commission delegates the administration. At present that entity is Neustar. The policies that the Administration implements are developed by the North American Numbering Plan which, if I understand correctly, is comprised of operators that use numbers under country code 1. The US arrangements for the management of telephone numbers are, I believe, unusual. In other countries the management is performed directly by the national regulatory authority, which sets the policies and assigns blocks of numbers to operators. Thus, in general, decisions about managing, ordering, distributing and registering telephone numbers are made by national regulatory authorities. I now refer to one of the presentations that was made during early discussions regarding this working group: http://www.ietf.org/proceedings/92/slides/slides-92-modern-2.pdf Slide 2 states that phone numbers are "opaque". I don't know what is meant by that, but it is true that it is not obvious whether a particular phone number is fixed or mobile, or, if fixed, what geography it corresponds to. But that is because phone numbers do not have significance: you have to look up the code in a database to find out what meaning, if any, is attached to it (e.g. that 41 corresponds to Switzerland and that 4179 corresponds to mobile phones in Switzerland). (By the way, many countries now have full number portability within the fixed and mobile numbering plans, so it is no longer possible to tell which mobile operator is service a particular mobile number, or what geographical area corresponds to a particular fixed number. For example, 4122 was the geographic code for Geneva, Switzerland, but now, with number portability, it could correspond to a fixed telephone in Zurich, Switzerland.) Slide 2 states that phone numbers are "still anchored in the PSTN". Of course: they were designed for the PSTN and have been adapted and upgraded to meet the needs of the current telephony system, including mobile telephony. Slide 3 says: "What if you could get numbers the way you get domain names? Or what if you could get numbers like you get IP addresses?" Those are rhetorical questions, because it would require changes in the ITU-T Recommendations, and national regulations, to be able to do that. Slide 5 says that the proposed working group will not set telephone number policies. Obviously, since those policies are set by the ITU-T and by national regulatory authorities. So I don't understand what the proposed working group would do that would help to achieve the objectives set forth in slide 3, other than to develop standards that would facilitate the exchange of information related to the administration of numbers (that's my understanding of what slides 9 to 17 are presenting). For sure standards to facilitate exchange of information are very useful, and there are some ITU-T Recommendations relating to that (in particular for providing information on national numbering plans). But it seems to me that development of such standards falls squarely within the remit of ITU-T Study Group 2, so it does not appear appropriate to me to create an IETF working group whose mandate would clearly overlap with the ITU-T's mandate. I was heavily involved in the ENUM discussions that arose when the IETF made some decisions without first liaising with ITU-T Study Group 2. That created a difficult atmosphere and it took a lot of effort to find a solution that satisfied both the IETF folks that designed ENUM and national regulators. I would urge the IETF not to repeat that mistake. If somebody thinks that some additional standards are needed regarding telephone numbers, then I would recommend that the requirements be submitted to ITU-T Study Group 2, and that the folks who are interested in the issue participate in the discussions in ITU-T Study Group 2. Otherwise you will likely wind up with the same contentious situation that arose back in 2001 regarding ENUM. Slide 5 says "Numbering inventory is a scarce asset, not like the DNS". There may be some scarcity under code 1, because the North American Numbering Plan has not expanded the number of digits in a very long time. In most other countries, the number of digits has been increased and there is no scarcity. Slide 10 refers to Skype. Skype actually applied to ITU-T to obtain an international code (country codes need not be geographic, there are non-geographic country codes; sub-codes of those non-geographic codes are assigned to operators that provide services in more than one country). Skype was refused the code because they refused to certify that they operate physical infrastructure in at least two countries (that's one of the conditions for obtaining a non-geographic code). As I understood the discussion at the time, Skype did not wish to certify that because they did not wish to be subject to telephony regulations. So any assignments to Skype would presumably have to comply with applicable regulations. Since the people who know and understand the applicable regulations participate in the work of ITU-T Study Group 2, it seems to me that discussions of these topics should take place there, and not in the IETF. Best, Richard Hill _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Jun 25 04:44: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 2489D1B34DB for ; Thu, 25 Jun 2015 04:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 VdmArA4evRV6 for ; Thu, 25 Jun 2015 04:44:05 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACC71B353A for ; Thu, 25 Jun 2015 04:44:04 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 155D021C68 for ; Thu, 25 Jun 2015 07:44:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 25 Jun 2015 07:44:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Fa4S6owFdATsAQe7 6KQrhIWGbQQ=; b=eITUjTJqcqFWmieSdPX6ytog7799qfIT4u4+twkNm3zzcVGs 3H/yJGGvybjn30W2vpoObhzJo6rCE/WfZRYFInmyg0CjljewY/1MZF+dH4ojC7AS 63S0ovlkqUOYBR7XQocUaJa+ta56k50t8Po2OuUKt9sZSrAdmH9sTT8YuGk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=Fa4S6owFdATsAQe76KQrhIWGbQQ=; b=oubV91EeKhDSzylZdES7 JxqnX7vM934lRGaruPtN/Ay90RH9MsXVG7Wemd61sqjAtEnOIIAV4Zd4Rys6SajM Eku1vkYu046JEO0dMtlOspW5bb0P0KRpfU4YajNYrMiILNWti3udWCcXnsMmtLx7 OCU1wurU8/2N2Nxr1FyX6nA= X-Sasl-enc: YQQa8NyiW/xtO4zKrO9x8bUYZlWSzy700F9KotxBBF8N 1435232643 Received: from [10.24.81.225] (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 9C856C00293 for ; Thu, 25 Jun 2015 07:44:02 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_B6646C09-853F-48B3-98D2-0AF2A2FD66E9" Date: Thu, 25 Jun 2015 08:44:22 -0300 References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> To: modern@ietf.org Message-Id: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 25 Jun 2015 11:44:09 -0000 --Apple-Mail=_B6646C09-853F-48B3-98D2-0AF2A2FD66E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Would appreciate people=92s thoughts on whether any charter edits may be = warranted in response to these comments, and/or whether a separate = response may be useful for addressing some of the questions below. Alissa Begin forwarded message: > From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern) > Date: June 23, 2015 at 1:56:42 PM GMT-3 > To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" >=20 > Dear Sir/Madam, >=20 > Below please find comments from the ITU Telecommunication = Standardization Bureau on the proposed IETF working group MODERN. >=20 > 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1=20 > It is stated at the beginning of the Charter that 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. And = it is mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to here = only deals with Tel URI? Would there be any impact on Recommendation = ITU-E E.164 and E.164.1 which are core recommendations on Telephone = Numbers? > 2. Entities participating in the defined mechanisms > The Charter states that the protocol mechanism for resolving TNs will = allow entities such as service providers, devices, and applications to = access data related to TNs. But it is not clear what kind of entities = can participate in the mechanisms defined by this MODERN working group. = Would it be restricted to the entities who have been assigned a TN or a = block of TNS? > 3. Status of Telephone numbers in the defined mechanisms > Several operations related to TNs are mentioned in the Charter, = including requesting, acquiring, resolving and associating. It is also = stated that the protocol mechanism for acquiring TNs will provide an = enrollment process for the entities that use and manage TNs. Does that = mean Telephone numbers with various status, such as assigned, spare and = reclaimed numbers will all be managed in the mechanisms defined by the = MODERN working group? > 4. Regulatory issues > The Charter states that Solutions and mechanisms created by the = working group will be flexible enough to accommodate different policies = for TN assignment and management, for example those established by = different regulatory agencies. We would like to bring your attention to = the fact that the E.164 international public telecommunication numbering = plan is a politically significant numbering resource with direct = implications on national sovereignty. ITU Plenipotentiary Conference = Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and = sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined in = Recommendation ITU-T E.164", and further instructed the ITU = Secretary-General and the Directors of three Bureaux (Telecommunication = Standardization, Development, and Radiocommunication) to "take any = necessary action to ensure the sovereignty of ITU Member States with = regard to Recommendation ITU-T E.164 numbering plans whatever the = application in which they are used". > 5. Relationship with .Tel > DNS-based use of international numbering resources has been discussed = in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. = TSB Director has also exchanged letters with ICANN on issues related to = registering digit strings in the .TEL domain. A representative from = ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and = provided some background on the TELNIC application. A correspondence = group under ITU-T SG2 was also set up in this regard. We would like to = know how the work of this new WG would relate to issues related to = registering digit strings in the .TEL domain and other DNS-based use of = telephone numbers. > 6. Relationship with related existing or concluded WGs > It is stated in the Charter that the working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. Detailed description of the relationship between this new WG = and the above mentioned other existing or concluded WGs would be = appreciated. > 7. The name of this new WG > The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the Charter, = ordering, exposing and registering TNs are not mentioned, which seems to = be a little bit inconsistent. >=20 > Best regards, >=20 > Jie Zhang > Advisor, ITU-T SG2 > International Telecommunication Union > Place des Nations > CH-1211 Geneva , Switzerland=20 > Tel :+41 22 730 5855 > jie.zhang@itu.int > www.itu.int > www.itu150.org >=20 >=20 > -----Original Message----- > From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The = IESG > Sent: Friday, June 12, 2015 8:47 PM > To: new-work@ietf.org > Subject: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern) >=20 > A new IETF working group has been proposed in the Applications and = Real-Time Area. The IESG has not made any determination yet. The = following draft charter was submitted, and is provided for informational = purposes only. Please send your comments to the IESG mailing list (iesg = at ietf.org) by 2015-06-22. >=20 > Managing, Ordering, Distributing, Exposing, & Registering telephone = Numbers (modern) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Chairs: > Tom McGarry > Steve Donovan >=20 > Assigned Area Director: > Alissa Cooper >=20 > Mailing list > Address: modern@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/modern > Archive: http://www.ietf.org/mail-archive/web/modern/ >=20 > Charter: >=20 > 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. Devices, applications, and network tools = increasingly need to manage TNs, including requesting and acquiring TN = delegations from authorities. The output of the working group should = make distribution, acquisition, and management of TNs simpler for all = entities involved. >=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 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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs.=20 >=20 > 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, and = security and privacy for both the data and the protocol interactions are = primary considerations. The working group will take into consideration = existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. >=20 > 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. 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 for TN assignment and management, for = example those established by different regulatory agencies. >=20 > The working group will deliver the following: >=20 > - An architecture overview, including high level requirements and = security/privacy considerations >=20 > - A description of the enrollment processes for existing and new TNs = including any modifications to metadata related to those TNs >=20 > - A description of protocol mechanisms for accessing contact = information associated with enrollments >=20 > - A description of mechanisms for resolving information related to TNs >=20 > Milestones: >=20 > TBD >=20 > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work >=20 --Apple-Mail=_B6646C09-853F-48B3-98D2-0AF2A2FD66E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Would = appreciate people=92s thoughts on whether any charter edits may be = warranted in response to these comments, and/or whether a separate = response may be useful for addressing some of the questions = below.


Alissa

Begin forwarded = message:

From: = "Zhang, Jie" <jie.zhang@itu.int>
Subject: RE: [new-work] WG Review: = Managing, Ordering, Distributing, Exposing, & Registering telephone = Numbers (modern)
Date: = June 23, 2015 at = 1:56:42 PM GMT-3
Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>
<= /span>

Dear Sir/Madam,

Below please find comments = from the ITU Telecommunication Standardization Bureau on the proposed = IETF working group MODERN.

1. Potential impacts on = Recommendation ITU-T E.164 and E.164.1
It is stated at the beginning = of the Charter that 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. And it is mentioned that = TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does = that mean the mechanism being referred to here only deals with Tel URI? = Would there be any impact on Recommendation ITU-E E.164 and E.164.1 = which are core recommendations on Telephone Numbers?
2. Entities = participating in the defined mechanisms
The Charter states that the = protocol mechanism for resolving TNs will allow entities such as service = providers, devices, and applications to access data related to TNs. But = it is not clear what kind of entities can participate in the mechanisms = defined by this MODERN working group. Would it be restricted to the = entities who have been assigned a TN or a block of TNS?
3. Status of = Telephone numbers in the defined mechanisms
Several operations = related to TNs are mentioned in the Charter, including requesting, = acquiring, resolving and associating. It is also stated that the = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs. Does that mean Telephone = numbers with various status, such as assigned, spare and reclaimed = numbers will all be managed in the mechanisms defined by the MODERN = working group?
4. Regulatory issues
The Charter = states that Solutions and mechanisms created by the working group will = be flexible enough to accommodate different policies for TN assignment = and management, for example those established by different regulatory = agencies. We would like to bring your attention to the fact that the = E.164 international public telecommunication numbering plan is a = politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU = Member States with respect to allocation and management of their country = code numbering resources as enshrined in Recommendation ITU-T E.164", = and further instructed the ITU Secretary-General and the Directors of = three Bureaux (Telecommunication Standardization, Development, and = Radiocommunication) to "take any necessary action to ensure the = sovereignty of ITU Member States with regard to Recommendation ITU-T = E.164 numbering plans whatever the application in which they are = used".
5. = Relationship with .Tel
DNS-based use of international = numbering resources has been discussed in ITU-T Study Group 2 (SG2) = since its meeting of 17-26 September 2013. TSB Director has also = exchanged letters with ICANN on issues related to registering digit = strings in the .TEL domain. A representative from ICANN participated in = the ITU-T SG2 meeting (28 May - June 2014) and provided some background = on the TELNIC application. A correspondence group under ITU-T SG2 was = also set up in this regard. We would like to know how the work of this = new WG would relate to issues related to registering digit strings in = the .TEL domain and other DNS-based use of telephone numbers.
6. = Relationship with related existing or concluded WGs
It is = stated in the Charter that the working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. Detailed description of the relationship between this new WG = and the above mentioned other existing or concluded WGs would be = appreciated.
7. The name of this new WG
The = name of this new WG is "Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)". But in the Charter, = ordering, exposing and registering TNs are not mentioned, which seems to = be a little bit inconsistent.

Best regards,

Jie = Zhang
Advisor, ITU-T SG2
International Telecommunication = Union
Place des Nations
CH-1211 Geneva , Switzerland
Tel :+41 = 22 730 5855
jie.zhang@itu.int
www.itu.int
= www.itu150.org


-----Original Message-----
From: new-work = [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG
Sent: = Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry = <tom.mcgarry@neustar.biz>
 Steve Donovan = <srdonovan@usdonovans.com>

Assigned Area Director:
=  Alissa Cooper <alissa@cooperw.in>

Mailing list
=  Address: modern@ietf.org
 To Subscribe: = https://www.ietf.org/mailman/listinfo/modern
 Archive: = http://www.ietf.org/mail-archive/web/modern/

Charter:

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. Devices, applications, and network tools increasingly need = to manage TNs, including requesting and acquiring TN delegations from = authorities. The output of the working group should make distribution, = acquisition, and management of TNs simpler for all entities = involved.

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. TNs may either be managed in a hierarchical tree, or in a = distributed registry. The protocol mechanism for acquiring TNs will = provide an enrollment process for the entities that use and manage TNs. =

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, and security and privacy for both the data and the protocol = interactions are primary considerations. The working group will take = into consideration existing IETF work including STIR, 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. 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 for TN = assignment and management, for example those established by different = regulatory agencies.

The working 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

Milestones:

TBD

_________________________________= ______________
new-work mailing = list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-wor= k


= --Apple-Mail=_B6646C09-853F-48B3-98D2-0AF2A2FD66E9-- From nobody Thu Jun 25 12:30: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 7DAD81ACD25 for ; Thu, 25 Jun 2015 12:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 Wk-vv__WcIQ0 for ; Thu, 25 Jun 2015 12:30:22 -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 235741ACD0D for ; Thu, 25 Jun 2015 12:30:22 -0700 (PDT) Received: (qmail 11639 invoked by uid 0); 25 Jun 2015 19:30:16 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 25 Jun 2015 19:30:16 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id kp3M1q00d1MNPNq01p3QTC; Thu, 25 Jun 2015 19:03:24 -0600 X-Authority-Analysis: v=2.1 cv=LLP1Hvm9 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=BsZzRlnUWeQA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=DZsV_1M2FacA:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=hZG83p_yAAAA:8 a=UqAplN6HAAAA:8 a=hGBaWAWWAAAA:8 a=yakATiurAAAA:8 a=hSQZmzSFDNvRm4y_zwIA:9 a=2WHKfzyYmgxZGtQ3:21 a=mwleYATuf5rYQG_P:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=kkUMZHjH4KkA:10 a=rcOQXM4wMrtryUgj6vwA:9 a=oMBZ581hdb51I-_P:21 a=tfcVN7WM68xQEHDK:21 a=1l57yv1GinqjKury: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=1RZbt4rtctbeAZl4oWS1rglqJM4qIax+z9GSeOeLEJM=; b=VPcSHFD0KjehejLBR92m/iPCrnr42sThMuWmjhnX20VwLCBWcTK7kAYy1Segr31fp2qyy+ey1ZdwTKXgInvbO0/09kZUrg6VNUopc5c4qKPApDxkyV0rnJ4HWmWANzFP; Received: from [64.134.43.227] (port=60975 helo=[192.168.20.103]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z8CXN-00065y-Av; Thu, 25 Jun 2015 13:10:13 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Thu, 25 Jun 2015 15:10:08 -0400 From: Richard Shockey To: Alissa Cooper , Message-ID: Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> In-Reply-To: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518089813_798977" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 64.134.43.227 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 25 Jun 2015 19:30:27 -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_3518089813_798977 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable DEL *.* ? =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: Modern on behalf of Alissa Cooper Date: Thursday, June 25, 2015 at 7:44 AM To: Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people=B9s thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: > From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Expo= sing, > & Registering telephone Numbers (modern) > Date: June 23, 2015 at 1:56:42 PM GMT-3 > To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" >=20 > Dear Sir/Madam, >=20 > Below please find comments from the ITU Telecommunication Standardization > Bureau on the proposed IETF working group MODERN. >=20 > 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 > It is stated at the beginning of the Charter that the MODERN working grou= p > will define a set of Internet-based mechanisms for the purposes of managi= ng > and resolving telephone numbers (TNs) in an IP environment. And it is > mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone > Numbers". Does that mean the mechanism being referred to here only deals = with > Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.16= 4.1 > which are core recommendations on Telephone Numbers? > 2. Entities participating in the defined mechanisms > The Charter states that the protocol mechanism for resolving TNs will all= ow > entities such as service providers, devices, and applications to access d= ata > related to TNs. But it is not clear what kind of entities can participate= in > the mechanisms defined by this MODERN working group. Would it be restrict= ed to > the entities who have been assigned a TN or a block of TNS? > 3. Status of Telephone numbers in the defined mechanisms > Several operations related to TNs are mentioned in the Charter, including > requesting, acquiring, resolving and associating. It is also stated that = the > protocol mechanism for acquiring TNs will provide an enrollment process f= or > the entities that use and manage TNs. Does that mean Telephone numbers wi= th > various status, such as assigned, spare and reclaimed numbers will all be > managed in the mechanisms defined by the MODERN working group? > 4. Regulatory issues > The Charter states that Solutions and mechanisms created by the working g= roup > will be flexible enough to accommodate different policies for TN assignme= nt > and management, for example those established by different regulatory > agencies. We would like to bring your attention to the fact that the E.16= 4 > international public telecommunication numbering plan is a politically > significant numbering resource with direct implications on national > sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2= 014) > recognized "the existing role and sovereignty of ITU Member States with > respect to allocation and management of their country code numbering reso= urces > as enshrined in Recommendation ITU-T E.164", and further instructed the I= TU > Secretary-General and the Directors of three Bureaux (Telecommunication > Standardization, Development, and Radiocommunication) to "take any necess= ary > action to ensure the sovereignty of ITU Member States with regard to > Recommendation ITU-T E.164 numbering plans whatever the application in wh= ich > they are used". > 5. Relationship with .Tel > DNS-based use of international numbering resources has been discussed in = ITU-T > Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Direct= or > has also exchanged letters with ICANN on issues related to registering di= git > strings in the .TEL domain. A representative from ICANN participated in t= he > ITU-T SG2 meeting (28 May - June 2014) and provided some background on th= e > TELNIC application. A correspondence group under ITU-T SG2 was also set u= p in > this regard. We would like to know how the work of this new WG would rela= te to > issues related to registering digit strings in the .TEL domain and other > DNS-based use of telephone numbers. > 6. Relationship with related existing or concluded WGs > It is stated in the Charter that the working group will take into > consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and > SCIM. Detailed description of the relationship between this new WG and th= e > above mentioned other existing or concluded WGs would be appreciated. > 7. The name of this new WG > The name of this new WG is "Managing, Ordering, Distributing, Exposing, & > Registering telephone Numbers (modern)". But in the Charter, ordering, > exposing and registering TNs are not mentioned, which seems to be a littl= e bit > inconsistent. >=20 > Best regards, >=20 > Jie Zhang > Advisor, ITU-T SG2 > International Telecommunication Union > Place des Nations > CH-1211 Geneva , Switzerland > Tel :+41 22 730 5855 > jie.zhang@itu.int > www.itu.int > www.itu150.org >=20 >=20 > -----Original Message----- > From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, June 12, 2015 8:47 PM > To: new-work@ietf.org > Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing= , & > Registering telephone Numbers (modern) >=20 > A new IETF working group has been proposed in the Applications and Real-T= ime > Area. The IESG has not made any determination yet. The following draft ch= arter > was submitted, and is provided for informational purposes only. Please se= nd > your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. >=20 > Managing, Ordering, Distributing, Exposing, & Registering telephone Numbe= rs > (modern) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Chairs: > Tom McGarry > Steve Donovan >=20 > Assigned Area Director: > Alissa Cooper >=20 > Mailing list > Address: modern@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/modern > Archive: http://www.ietf.org/mail-archive/web/modern/ >=20 > Charter: >=20 > The MODERN working group will define a set of Internet-based mechanisms f= or > the purposes of managing and resolving telephone numbers (TNs) in an IP > environment. Devices, applications, and network tools increasingly need t= o > manage TNs, including requesting and acquiring TN delegations from > authorities. The output of the working group should make distribution, > acquisition, and management of TNs simpler for all entities involved. >=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 identify protocol > mechanisms to support the interactions between the functions defined by t= he > framework. This includes either recommending or defining protocol mechani= sms > for acquiring, associating and resolving TNs, with a preference for use o= f > existing protocol mechanisms. TNs may either be managed in a hierarchical > tree, or in a distributed registry. The protocol mechanism for acquiring = TNs > will provide an enrollment process for the entities that use and manage T= Ns. >=20 > The protocol mechanism for resolving TNs will allow entities such as serv= ice > providers, devices, and applications to access data related to TNs. > Maintaining reliability, real-time application performance, and security = and > privacy for both the data and the protocol interactions are primary > considerations. The working group will take into consideration existing I= ETF > work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. >=20 > The work of this group will focus on TNs, as defined in RFC3966, and bloc= ks of > TNs, that are used to initiate communication with another user of a servi= ce. > There is an expectation that aspects of the architecture and protocols de= fined > 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 MO= DERN > working group. Solutions and mechanisms created by the working group will= be > flexible enough to accommodate different policies for TN assignment and > management, for example those established by different regulatory agencie= s. >=20 > The working group will deliver the following: >=20 > - An architecture overview, including high level requirements and > security/privacy considerations >=20 > - A description of the enrollment processes for existing and new TNs incl= uding > any modifications to metadata related to those TNs >=20 > - A description of protocol mechanisms for accessing contact information > associated with enrollments >=20 > - A description of mechanisms for resolving information related to TNs >=20 > Milestones: >=20 > TBD >=20 > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work >=20 _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3518089813_798977 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

DEL = *.* ?


— 
R= ichard Shockey
Shockey Consulting LLC
Chairman of the Bo= ard SIP Forum
www.shockey.us
www.sipforum.org
= richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


=
From: Modern <modern-bounces@ietf.org> on behalf of Alissa = Cooper <alissa@cooperw.in>
<= span style=3D"font-weight:bold">Date: Thursday, June 25, 2015 at 7:44 = AM
To: <modern@ietf.org>
Subject:= [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)

=
Would appreciate people’s thoughts on= whether any charter edits may be warranted in response to these comments, a= nd/or whether a separate response may be useful for addressing some of the q= uestions below.

Alissa

Begin forwar= ded message:

From: "Zhang, Jie" = <jie.zhang@itu.int>
<= /div>
Subject: RE: [n= ew-work] WG Review: Managing, Ordering, Distributing, Exposing, & Regist= ering telephone Numbers (modern)
Date: June 23, 2015 at 1:56:42 PM GMT-3
Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam= ,

Below please find comments from the ITU Telecommunication Standardi= zation Bureau on the proposed IETF working group MODERN.

1. Potential impacts on Reco= mmendation ITU-T E.164 and E.164.1
It is stated at the beginning of the = Charter that the MODERN working group will define a set of Internet-based me= chanisms for the purposes of managing and resolving telephone numbers (TNs) = in an IP environment. And it is mentioned that TNs are defined in RFC 3966 "= The tel URI for Telephone Numbers". Does that mean the mechanism being refer= red to here only deals with Tel URI? Would there be any impact on Recommenda= tion ITU-E E.164 and E.164.1 which are core recommendations on Telephone Num= bers?
2. Enti= ties participating in the defined mechanisms
The Charter states that the = protocol mechanism for resolving TNs will allow entities such as service pro= viders, devices, and applications to access data related to TNs. But it is n= ot clear what kind of entities can participate in the mechanisms defined by = this MODERN working group. Would it be restricted to the entities who have b= een assigned a TN or a block of TNS?
3. Status of Telephone numbers in the defined mechan= isms
Several operations related to TNs are mentioned in the Charter, incl= uding requesting, acquiring, resolving and associating. It is also stated th= at the protocol mechanism for acquiring TNs will provide an enrollment proce= ss for the entities that use and manage TNs. Does that mean Telephone number= s with various status, such as assigned, spare and reclaimed numbers will al= l be managed in the mechanisms defined by the MODERN working group?
4. Regulatory issues<= br>The Charter states that Solutions and mechanisms created by the working g= roup will be flexible enough to accommodate different policies for TN assign= ment and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 in= ternational public telecommunication numbering plan is a politically signifi= cant numbering resource with direct implications on national sovereignty. IT= U Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "t= he existing role and sovereignty of ITU Member States with respect to alloca= tion and management of their country code numbering resources as enshrined i= n Recommendation ITU-T E.164", and further instructed the ITU Secretary-Gene= ral and the Directors of three Bureaux (Telecommunication Standardization, D= evelopment, and Radiocommunication) to "take any necessary action to ensure = the sovereignty of ITU Member States with regard to Recommendation ITU-T E.1= 64 numbering plans whatever the application in which they are used".
5. Relationship with= .Tel
DNS-based use of international numbering resources has been discuss= ed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. T= SB Director has also exchanged letters with ICANN on issues related to regis= tering digit strings in the .TEL domain. A representative from ICANN partici= pated in the ITU-T SG2 meeting (28 May - June 2014) and provided some backgr= ound on the TELNIC application. A correspondence group under ITU-T SG2 was a= lso set up in this regard. We would like to know how the work of this new WG= would relate to issues related to registering digit strings in the .TEL dom= ain and other DNS-based use of telephone numbers.
6. Relationship with related existing o= r concluded WGs
It is stated in the Charter that the working group will t= ake into consideration existing IETF work including STIR, ENUM, SPEERMINT, D= RINKS and SCIM. Detailed description of the relationship between this new WG= and the above mentioned other existing or concluded WGs would be appreciate= d.
7. The nam= e of this new WG
The name of this new WG is "Managing, Ordering, Distribu= ting, Exposing, & Registering telephone Numbers (modern)". But in the Ch= arter, ordering, exposing and registering TNs are not mentioned, which seems= to be a little bit inconsistent.

Best regards,

Jie Zhang
A= dvisor, ITU-T SG2
International Telecommunication Union
Place des Nati= ons
CH-1211 Geneva , Switzerland
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.or= g


-----Original Message-----
From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of= The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Manag= ing, Ordering, Distributing, Exposing, & Registering telephone Numbers (= modern)

A new IETF working group has been proposed in the Application= s and Real-Time Area. The IESG has not made any determination yet. The follo= wing draft charter was submitted, and is provided for informational purposes= only. Please send your comments to the IESG mailing list (iesg at ietf.org)= by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Reg= istering telephone Numbers (modern)
-------------------------------------= -----------
Current Status: Proposed WG

Chairs:
 Tom McGa= rry <tom.mcgarry@neustar.biz= >
 Steve Donovan <s= rdonovan@usdonovans.com>

Assigned Area Director:
 Ali= ssa Cooper <alissa@cooperw.in><= br>
Mailing list
 Address: mode= rn@ietf.org
 To Subscribe: https://www.ietf.org/mailman/listinfo/modern
&nbs= p;Archive: http://www= .ietf.org/mail-archive/web/modern/

Charter:

The MODERN wor= king group will define a set of Internet-based mechanisms for the purposes o= f managing and resolving telephone numbers (TNs) in an IP environment. Devic= es, applications, and network tools increasingly need to manage TNs, includi= ng requesting and acquiring TN delegations from authorities. The output of t= he working group should make distribution, acquisition, and management of TN= s simpler for all entities involved.

The working group will define an= information management framework for the roles and functions involved in as= sociating information with one or more TNs in an IP environment.  The w= orking group will also identify protocol mechanisms to support the interacti= ons between the functions defined by the framework. This includes either rec= ommending or defining protocol mechanisms for acquiring, associating and res= olving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. T= he protocol mechanism for acquiring TNs will provide an enrollment process f= or the entities that use and manage TNs.

The protocol mechanism for = resolving TNs will allow entities such as service providers, devices, and ap= plications to access data related to TNs. Maintaining reliability, real-time= application performance, and security and privacy for both the data and the= protocol interactions are primary considerations. The working group will ta= ke into consideration existing IETF work including STIR, ENUM, SPEERMINT, DR= INKS and SCIM.

The work of this group will focus on TNs, as defined i= n RFC3966, and blocks of TNs, that are used to initiate communication with a= nother user of a service. There is an expectation that aspects of the archit= ecture 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 cre= ated by the working group will be flexible enough to accommodate different p= olicies for TN assignment and management, for example those established by d= ifferent regulatory agencies.

The working group will deliver the foll= owing:

- 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 acces= sing contact information associated with enrollments

- A description = of mechanisms for resolving information related to TNs

Milestones:
TBD

_______________________________________________
new-work = mailing list
new-work@ietf.org
= https://www.ietf.or= g/mailman/listinfo/new-work


_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3518089813_798977-- From nobody Thu Jun 25 12:32: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 632491ACD55 for ; Thu, 25 Jun 2015 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 axYUfqE1HBIO for ; Thu, 25 Jun 2015 12:32:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F29B1ACD28 for ; Thu, 25 Jun 2015 12:32:13 -0700 (PDT) Received: from BY2FFO11FD002.protection.gbl (10.1.14.32) by BY2FFO11HUB011.protection.gbl (10.1.15.222) with Microsoft SMTP Server (TLS) id 15.1.201.10; Thu, 25 Jun 2015 19:32:07 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) 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 plsapdm1.corp.sprint.com (144.230.172.36) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Thu, 25 Jun 2015 19:32:07 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5PJVvka002255; Thu, 25 Jun 2015 14:32:06 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm1.corp.sprint.com with ESMTP id 1v8n7e1apt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2015 14:32:06 -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; Thu, 25 Jun 2015 14:32:05 -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; Thu, 25 Jun 2015 14:32:05 -0500 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Alissa Cooper , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQr31oVhNQitnoIUyGmpgejVxL7J29nAuQ Date: Thu, 25 Jun 2015 19:32:04 +0000 Message-ID: <963da9c467264967a5b96bc81a08bb44@PLSWE13M08.ad.sprint.com> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> In-Reply-To: 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.214.116.22] Content-Type: multipart/related; boundary="_004_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD002; 1:54MSe8MvTNyBQInNi0s8tirNZA4h9v3+B09jlPv3zmec7BqqAMsU7q7ttYX/V1j0XIUWO1k/usj7aqO0Vg5Vu8DmytwVqnh1Kqi7mtUm2DrsNpegUFj/EdjuFP+aPVya2KgqdMJ79i6rqFdCOsl7+U8nOsSkYm2NjZHOvFPPptsbB5AqiYKs2wBvFF21xFDU8t5S4yxllB+6UGWdrv/VQtv2O4T3/CivFX/SMyS5+PWI2NYO/LiRA7kUpTdYrRb/4ZlZemikPI0cdIe9ChXIyanUKPpRaj+RvlYJctKRM4V0UCl3ovcI98dz3xT5QJlX X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(448002)(2473001)(45074003)(377454003)(13464003)(60444003)(189002)(199003)(19625215002)(108616004)(5003600100002)(77156002)(19580395003)(15975445007)(24736003)(102836002)(92566002)(18206015028)(62966003)(2656002)(5250100002)(87936001)(84326002)(2950100001)(85326001)(106466001)(76176999)(2900100001)(54356999)(2501003)(86362001)(575784001)(19580405001)(107886002)(5001960100002)(512954002)(189998001)(99936001)(46102003)(33646002)(19627595001)(19617315012)(5001770100001)(17760045003)(106116001)(66926002)(30436002)(67866002)(50986999)(16601075003)(6806004)(15974865002)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB011; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB011; 2:lSKFXe26aPzAjScI4ZxQnwD841e1ApEfAOJ6Gcs2a2qjxCuyGGdF/a6o1yI1CkBL; 3:nk/glaf/jQVGn1jDxefXSfzuCMeTyLKr/eYyZQczgllHkLL71udjEdPW+228aw8BRFm/2nqT/lwQX4ikGEKd8RoLTOi2HEv9TsX84bZ+3oWk+bD+NJIxzE2nR8UZHBWAGQ5YQQPX9j9BVk91SkweDE11VhShsiEkhY01xkDrWrx5Db+sUyYsA/CJ7EKA2jOS9c3mLg7OTVEf2fd1X2As1FKYiDbaq+yiunjSCGfnhyHNrVnjRrums8fxGvns6hrP; 20:eM9ZbfF7qqMiwrUdLgK9wM9u7XGh70VhuEjzgO3vDkFTpEQ7N2dExyZj9xCBaZyNwbrbj9LzS6Q8d4P/n7Q34UQPUyIOTdMLpwnJmiyzTNTME2rsjoqeJieOlyC6SudkuiUd9/kaldymoB0a4bAb2Xd4rQnQdkPX9REa/9mrfxSn8dUBVARfQX0x9s3awEa3/iHRPgzeyz7ffwrzrDo/EWz3+jOYFaEGizrJY0gidIGG10ALfX4WBpDFZ+/hM95Y; 4:bYkXipNdkj/Lisq++P1sbI+lFF2MydcbNhu/lB/fbPH3bIFQHXceQH0Y59fzf02Vi66F4PWZB/MuSRHvk4Im2k7QtYpD2yZJlnWyN6veglIZqXpq35cHj7mm9wM1958Dlz3D9Dc6mPRafPRHqOEMIt1PFP3GBrYdtfqtBIw6SzcpZcFm0G+OMx/JDdpDdLsqwQzwzwd4+HGBq/Xe3vGFM9J0U/6H1PwIaFG+4S51O5GkKS87FgCntfGeDORqCzI7leMEfiP2mF7ja19ZiWkipcimC06XXH0U039fYmKNP8M= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB011; 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:BY2FFO11HUB011; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB011; X-Forefront-PRVS: 0618E4E7E1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB011; 23:nkkgJsbBFZwVbl8U6QP44lCI74giZh2rk3xVvRnE?= =?us-ascii?Q?I5qpFnhO56vGSIwwfMQYIL4A/SWcA5dt0AJy5xM+l47sIm8GSQaQ03QPmDKS?= =?us-ascii?Q?YwlCKGVkbmUSHxIhRdmRt5Bk6yz9fE9vpSVyd35cMl6K9kMHSh7BjRF397FB?= =?us-ascii?Q?c/2dYGSI90/tpm6rKW0IE8U301Grb+GFflUuOxblvWzy9VAiYRirUgj3Qmak?= =?us-ascii?Q?4HHEzAvCqhdX1qSiYerKiMiEltYkgufXpuj2fMaRae5OQSwxU3XUa3l/AfSm?= =?us-ascii?Q?xmEQ7Kt/iX0YwRC46sdqcjKF6dDSqViWLOzdSqeHk/yB4j3D60HWR7nvGTWr?= =?us-ascii?Q?2xSe9MhBq3eyJYI7A7C6tN2I1zLnb5342L0Vw7UyiFITI7n6yevBD77mV++r?= =?us-ascii?Q?DZlBmA1HL8xdhnQUiO3Xafhq2jozUrwysuGpPz5BxbwoMRM+2+ar2pQf+19S?= =?us-ascii?Q?tyHPqYOxNIcLu4WqKkDh/9SfhOhq3TgtYyz4/MISqQR7SIydCYBHp13LoPs5?= =?us-ascii?Q?tnattl3NBzY32J58dNPIZGPB3OrUeZ3cNTZGJRQ4ntSmjayb4NSAsoQsMRXK?= =?us-ascii?Q?8+/ald39epjEQPEngIsV7WbN7G0irF5wS5oqQ3yc5bMSc3vnuqmHz335nu5y?= =?us-ascii?Q?sH4aZXA0mHzM+KBUEOjFfAG/lIjFJ7BDGfl2MFq36wk2a8yZ4BT7xuJhF2lj?= =?us-ascii?Q?4C/55qhrjv/GOQwPHs6uPpdcZDNpstUOcULhxAkuD4U6vUFr6evhpABlrsb7?= =?us-ascii?Q?DE0bwMqM/0Kb5J5fShONj7PAfRM6xjz+We+Uf4O6ZDc5Yc96Du7/iJWBsduH?= =?us-ascii?Q?pNPMcrGgENEKc2HQU3n9jA9Hdzx66LZ+6Nc8ee4EYeJcBiEJVZp1Tz94Umyi?= =?us-ascii?Q?04saE4N96Ho4imXow8/PmEnWo/v8Oj891D3SppUYqYhZ+gncReKgI7Vu4T/4?= =?us-ascii?Q?EHJaeY9ibievQ6L9gqCLp/Vj+NY6i04gZ2I1QetOpdNqucnPG7edAiEzeFXP?= =?us-ascii?Q?2cThsI4OGWxUqg+e3jHOmCIrdgxyGYw/D2L5wkOEfjwtnIUqZnZpFTckATa7?= =?us-ascii?Q?jiWoyf3rwlJjpp0VNlwZsJJudkCRdPJreE1BQOQastaDq9snoC9ypXTWc7Us?= =?us-ascii?Q?EUzkT0NZkHuP2YpLdOgl+2QxYcg6Hvqbu5tgpn1Q4zMiizDUBHfz4uDOBhkA?= =?us-ascii?Q?5EErIbmh8rLbrmgl+95oLOTc0Mc9SulUuzqvqSWOAvszrq3B4Na9wjEdooo3?= =?us-ascii?Q?BB7xEpcYTy6LcpO3vsW/+I0RjC1OIoIxgvEszjFb2N0+ZGf2c8nqIMO8Rrqn?= =?us-ascii?Q?ltCApb6LU98mymH0wnt8yEamNpnYIJL1FJqjj4AHfVP2V7FwsuF4BnIDQDtJ?= =?us-ascii?Q?oXOEJ6ZoRtVyAHojdZyvAVQYhlF6JRqkerRfUd1mD0flPQgp?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB011; 5:OBH4FtR5effsHKRM8hkfblkO/PMWdVXEXYlvBSO0mULvFCynanjEpAbEiLeRlsTfhfT+hKOFY5qP1dW44ZCdy9Qw+KorlQyVw2UTEQ8UIlJWVagPBX/2erZDRJZu45wBbB6MNIH1WVQveC3e+o1Qjw==; 24:s4Gti/U6/D0DL6AYVpTi6LZ0Fs1Y4MIoXOapgTnwyaY4QnoDEFZZxGZly+rfjNhQp05zhCj0vsj3cHpRcfldHnID6B3XRn06vwLeHAfPH6c= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2015 19:32:07.1299 (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.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB011 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 25 Jun 2015 19:32:21 -0000 --_004_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_" --_000_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Which part Richard? The charter, or the ITU-T concerns? :) Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: June 25, 2015 2:10 PM To: Alissa Cooper; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) DEL *.* ? - 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: Modern > on b= ehalf of Alissa Cooper > Date: Thursday, June 25, 2015 at 7:44 AM To: > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warr= anted in response to these comments, and/or whether a separate response may= be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ Modern mailing list Modern@= ietf.org https://www.ietf.org/mailman/listinfo/mode= rn ________________________________ 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_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Which part Richard?  The charter, = or the ITU-T concerns?  J

 

Best regards,

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorm= an@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of Richard Shockey
Sent: June 25, 2015 2:10 PM
To: Alissa Cooper; modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

DEL *.* ?

 

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

richard<at>shockey.us<= /span>

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

 

 

From: Modern <modern-bounces@ietf.org> on behalf of Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 at 7:44 AM
To: <modern@ietf.org> Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people’s thought= s on whether any charter edits may be warranted in response to these commen= ts, and/or whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:



From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review:= Managing, Ordering, Distributing, Exposing, & Registering telephone Nu= mbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

 

Dear Sir= /Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1.       =      Potential impacts on Recommendation ITU-T E= .164 and E.164.1
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?
2.       =      Entities participating in the defined mecha= nisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?
3.       =      Status of Telephone numbers in the defined = mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?
4.       =      Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".
5.       =      Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.
6.       =      Relationship with related existing or concl= uded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.
7.       =      The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org
 To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: htt= p://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs.

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work

 

_______________________________________= ________ 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_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_-- --_004_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Thu, 25 Jun 2015 19:32:04 GMT"; modification-date="Thu, 25 Jun 2015 19:32:04 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_963da9c467264967a5b96bc81a08bb44PLSWE13M08adsprintcom_-- From nobody Thu Jun 25 12:48: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 681701A7113 for ; Thu, 25 Jun 2015 12:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 Wf-q2eBgoXYK for ; Thu, 25 Jun 2015 12:47:50 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 716881ACD66 for ; Thu, 25 Jun 2015 12:47:49 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5PJli1e022278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Jun 2015 21:47:44 +0200 Received: from RHillNew (adsl-178-38-12-166.adslplus.ch [178.38.12.166]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5PJlgSM007112; Thu, 25 Jun 2015 21:47:43 +0200 From: "Richard Hill" To: "'Gorman, Pierce A [CTO]'" , "'Richard Shockey'" , "'Alissa Cooper'" , References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <963da9c467264967a5b96bc81a08bb44@PLSWE13M08.ad.sprint.com> In-Reply-To: <963da9c467264967a5b96bc81a08bb44@PLSWE13M08.ad.sprint.com> Date: Thu, 25 Jun 2015 21:47:44 +0200 Message-ID: <043901d0af7f$ce73d730$6b5b8590$@ch> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_043A_01D0AF90.91FCA730" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQr31oVhNQitnoIUyGmpgejVxL7J29nAuQgAAEPZA= Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 25 Jun 2015 19:47:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_043A_01D0AF90.91FCA730 Content-Type: multipart/alternative; boundary="----=_NextPart_001_043B_01D0AF90.91FCA730" ------=_NextPart_001_043B_01D0AF90.91FCA730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not creating the group would resolve the ITU-T concerns, so it would be a "del *.*". Ignoring the ITU-T concerns would, in my opinion, lead to even more concerns being expressed subsequently. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A [CTO] Sent: Thursday, June 25, 2015 21:32 To: Richard Shockey; Alissa Cooper; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Which part Richard? The charter, or the ITU-T concerns? J Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com cid:408000_086801428601145001@pvmxe13g01 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: June 25, 2015 2:10 PM To: Alissa Cooper; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) DEL *.* ? - 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: Modern on behalf of Alissa Cooper Date: Thursday, June 25, 2015 at 7:44 AM To: Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers? 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS? 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group? 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used". 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated. 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ 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. ------=_NextPart_001_043B_01D0AF90.91FCA730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not creating the group would resolve the ITU-T concerns, so it would = be a “del *.*”.

 

Ignoring the ITU-T concerns would, in my opinion, lead to even more = concerns being expressed subsequently.


Best,

Richard

 

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, = Pierce A [CTO]
Sent: Thursday, June 25, 2015 = 21:32
To: Richard Shockey; Alissa Cooper; = modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)

 

Which part Richard?  The charter, or the ITU-T concerns?  = J

 

Best regards,

 

 

Pierce Gorman

= Core Network Planning

= O: 913-439-4368

= pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Modern = [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: June 25, 2015 = 2:10 PM
To: Alissa Cooper; modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

 

DEL *.* ?

 

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

 

 

From: Modern <modern-bounces@ietf.org> = on behalf of Alissa Cooper <alissa@cooperw.in>
Date: = Thursday, June 25, 2015 at 7:44 AM
To: <modern@ietf.org>
Subject: = [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Would appreciate people’s thoughts on whether any charter edits = may be warranted in response to these comments, and/or whether a = separate response may be useful for addressing some of the questions = below.

 

Alissa

 

Begin forwarded message:

 

From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

 

Dear Sir/Madam,

Below please find comments from the ITU = Telecommunication Standardization Bureau on the proposed IETF working = group MODERN.

1.        &n= bsp;   Potential impacts on Recommendation ITU-T E.164 = and E.164.1
It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 = "The tel URI for Telephone Numbers". Does that mean the = mechanism being referred to here only deals with Tel URI? Would there be = any impact on Recommendation ITU-E E.164 and E.164.1 which are core = recommendations on Telephone Numbers?
2.        &n= bsp;   Entities participating in the defined = mechanisms
The Charter states that the protocol mechanism for = resolving TNs will allow entities such as service providers, devices, = and applications to access data related to TNs. But it is not clear what = kind of entities can participate in the mechanisms defined by this = MODERN working group. Would it be restricted to the entities who have = been assigned a TN or a block of TNS?
3.        &n= bsp;   Status of Telephone numbers in the defined = mechanisms
Several operations related to TNs are mentioned in the = Charter, including requesting, acquiring, resolving and associating. It = is also stated that the protocol mechanism for acquiring TNs will = provide an enrollment process for the entities that use and manage TNs. = Does that mean Telephone numbers with various status, such as assigned, = spare and reclaimed numbers will all be managed in the mechanisms = defined by the MODERN working group?
4.        &n= bsp;   Regulatory issues
The Charter states that = Solutions and mechanisms created by the working group will be flexible = enough to accommodate different policies for TN assignment and = management, for example those established by different regulatory = agencies. We would like to bring your attention to the fact that the = E.164 international public telecommunication numbering plan is a = politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of = ITU Member States with respect to allocation and management of their = country code numbering resources as enshrined in Recommendation ITU-T = E.164", and further instructed the ITU Secretary-General and the = Directors of three Bureaux (Telecommunication Standardization, = Development, and Radiocommunication) to "take any necessary action = to ensure the sovereignty of ITU Member States with regard to = Recommendation ITU-T E.164 numbering plans whatever the application in = which they are used".
5.        &n= bsp;   Relationship with .Tel
DNS-based use of = international numbering resources has been discussed in ITU-T Study = Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director = has also exchanged letters with ICANN on issues related to registering = digit strings in the .TEL domain. A representative from ICANN = participated in the ITU-T SG2 meeting (28 May - June 2014) and provided = some background on the TELNIC application. A correspondence group under = ITU-T SG2 was also set up in this regard. We would like to know how the = work of this new WG would relate to issues related to registering digit = strings in the .TEL domain and other DNS-based use of telephone = numbers.
6.        &n= bsp;   Relationship with related existing or concluded = WGs
It is stated in the Charter that the working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. Detailed description of the relationship between this new WG = and the above mentioned other existing or concluded WGs would be = appreciated.
7.        &n= bsp;   The name of this new WG
The name of this new = WG is "Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)". But in the Charter, = ordering, exposing and registering TNs are not mentioned, which seems to = be a little bit inconsistent.

Best regards,

Jie = Zhang
Advisor, ITU-T SG2
International Telecommunication = Union
Place des Nations
CH-1211 Geneva , Switzerland
Tel :+41 = 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Origina= l Message-----
From: new-work [mailto:new-work-bounces@ietf.or= g] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 = PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz> Steve Donovan <srdonovan@usdonovans.com>=

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailin= g list
 Address: modern@ietf.org
 To = Subscribe: https://www.ietf.or= g/mailman/listinfo/modern
 Archive: http://www.ietf.org= /mail-archive/web/modern/

Charter:

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. = Devices, applications, and network tools increasingly need to manage = TNs, including requesting and acquiring TN delegations from authorities. = The output of the working group should make distribution, acquisition, = and management of TNs simpler for all entities involved.

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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs.

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, and security and privacy = for both the data and the protocol interactions are primary = considerations. The working group will take into consideration existing = IETF work including STIR, 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. 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 for TN assignment and management, for = example those established by different regulatory agencies.

The = working 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

Milestones:

TBD

________________________________= _______________
new-work mailing list
new-work@ietf.org
https://www.ietf.= org/mailman/listinfo/new-work

 

_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.or= g/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.

------=_NextPart_001_043B_01D0AF90.91FCA730-- ------=_NextPart_000_043A_01D0AF90.91FCA730 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: 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= ------=_NextPart_000_043A_01D0AF90.91FCA730-- From nobody Thu Jun 25 15:31: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 B80361B2AEF for ; Thu, 25 Jun 2015 15:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 OUA4cIJa65c7 for ; Thu, 25 Jun 2015 15:31:19 -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 54B0B1B2A8F for ; Thu, 25 Jun 2015 15:31:19 -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 t5PMNaoX009158 for ; Thu, 25 Jun 2015 18:31:19 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1v852a1jqk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 25 Jun 2015 18:31:18 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.54]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Thu, 25 Jun 2015 18:31:15 -0400 From: "McGarry, Tom" To: "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEB/Zz98yjqU+KL6VWQx+3vZ29zs4A Date: Thu, 25 Jun 2015 22:31:15 +0000 Message-ID: In-Reply-To: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> 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.65] Content-Type: multipart/alternative; boundary="_000_D1B1F5DD27B63tommcgarryneustarbiz_" 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-06-25_08:2015-06-25,2015-06-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.13657137035261e-08 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-1506250381 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 25 Jun 2015 22:31:23 -0000 --_000_D1B1F5DD27B63tommcgarryneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --_000_D1B1F5DD27B63tommcgarryneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1A2EF1C8040CA040B68473D269B52358@neustar.biz> Content-Transfer-Encoding: quoted-printable

This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers.  Entities can choose to use = these tools or not.  These tools are not for the ITU-T's processes or role, nor for how national administrators= interact with the ITU-T.  But of course we want your input and feedba= ck, so thanks for sending this along.  More comments in line below. &n= bsp;


From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 = AM
To: Modern List <modern@ietf.org>
Subject: [Modern] Fwd: [new-work] W= G Review: Managing, Ordering, Distributing, Exposing, & Registering tel= ephone Numbers (modern)

Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below.

Alissa

Begin forwarded message:

From:= "Zhang, Jie"= <jie.zhang@itu.int>
Subje= ct: RE: [new-work] WG Review= : Managing, Ordering, Distributing, Exposing, & Registering telephone N= umbers (modern)
Date:= June 23, 2015 at 1:56:= 42 PM GMT-3
Cc: <= /b>"Jamoussi, Bilel&qu= ot; <bilel.jamoussi@itu.int>
Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Poten= tial impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?
There will be no impacts on E.164 and E.164.1.

2. Entit= ies participating in the defined mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?
Who participates in numbering processes within coun= tries is subject to regulation.  The WG cannot make any decisions with= regard to this.  I expect the WG to define "roles" wit= hin the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those rol= es could interact with each other.  This will be a baseline = for what tools and solutions would be useful to facilitate those interactio= ns.  

3. Statu= s of Telephone numbers in the defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?
I would expect proposed solutions to be able to address the status of = a telephone number.

4. Regul= atory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".
We are aware of Resolution 133 and will certainly respect i= t.  I=  would propose adding the following text after the first sentence in the last ful= l paragraph =96 "The group acknowledges ITU Plen= ipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocat= ion and management of their country code numbering resources as enshrined i= n Recommendation ITU-T E.164.= "  

5. Relat= ionship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.
The WG will not create any new namespace that would= require regulatory oversight, e.g., a new TLD, SLD, etc.  I = ;wouldn't rule out the WG leveraging existing namespaces as part of pr= oposed solutions.  But it's too early to say anything specific about that.  There is nothing in the charter that references= .tel.  

6. Relat= ionship with related existing or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.
I agree.  I would modify that senten= ce to add the following at the end - "as well as other relevant&n= bsp;industry and standards organizations."

7. The n= ame of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.
The IETF often has fun with creating WG names. &nbs= p;: )  But the charter is where to look for the scope of work.  T= he charter uses the following phrases "distribution, acquisition and m= anagement of TNs", "functions involved in associating information =85 with TNs", "associating, acquiring and=  resolving TNs", "access data related to TNs"= , and "mechanisms for resolving information related to TNs".=  The functions you believe were left out of the charter will be part = of one or more of these processes.  


Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work



 --_000_D1B1F5DD27B63tommcgarryneustarbiz_-- From nobody Thu Jun 25 16:55: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 EED1B1B2D50 for ; Thu, 25 Jun 2015 16:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.236 X-Spam-Level: X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBHAgMibiHYf for ; Thu, 25 Jun 2015 16:55:14 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEF81B2D4F for ; Thu, 25 Jun 2015 16:55:13 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 0e49c855.0.6973260.00-2244.19739808.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 25 Jun 2015 23:55:13 +0000 (UTC) X-MXL-Hash: 558c94e17bce384c-574f6bf886e90c45874ae49f417b8291b1766ce3 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5PNtCdH014399; Thu, 25 Jun 2015 19:55:12 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5PNt2Pu014348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jun 2015 19:55:07 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 25 Jun 2015 23:54:54 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0224.002; Thu, 25 Jun 2015 19:54:54 -0400 From: "DOLLY, MARTIN C" To: "McGarry, Tom" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxCXLiAfQjM5UeumY0PI1Ehkp2+EeCA///UUG4= Date: Thu, 25 Jun 2015 23:54:53 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FC6E11B6D5114C4B9321922478ACA1D7attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=bsn78jmi c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=QHza4DjpNGAA:10 a=BLceEmwcHowA:10 a=XAFQ] X-AnalysisOut: [embCKUMA:10 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=hZG83p_yAA] X-AnalysisOut: [AA:8 a=UqAplN6HAAAA:8 a=yakATiurAAAA:8 a=2zS351wxUPmjVBILa] X-AnalysisOut: [8oA:9 a=pILNOxqGKmIA:10 a=n-uPhCOgxyIA:10 a=kkUMZHjH4KkA:1] X-AnalysisOut: [0 a=qU8kb4skuVOPDRh6:21 a=WmyFSyCjlPmOTcws:21 a=1HoBFe0z2H] X-AnalysisOut: [HYyWOcKMUA:9 a=_W_S_7VecoQA:10 a=UjAsg7WArRlNN63m:21 a=QDX] X-AnalysisOut: [feQlBMZcnc8AL:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 25 Jun 2015 23:55:20 -0000 --_000_FC6E11B6D5114C4B9321922478ACA1D7attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Litmus test: E.164 plus Private numbers in the format above At issue: A model where the carrier has to pay for giving a DB in the cloud our numbe= rs and then pay to query So when did the IETF get into this.... Sent from my iPhone On Jun 25, 2015, at 6:31 PM, McGarry, Tom > wrote: This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --_000_FC6E11B6D5114C4B9321922478ACA1D7attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Litmus test: E.164 plus
Private numbers in the format above
At issue:
A model where the carrier has to pay for giving a DB in the cloud our = numbers and then pay to query
So when did the IETF get into this....

Sent from my iPhone

On Jun 25, 2015, at 6:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:


This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers.  Entities can choose to use = these tools or not.  These tools are not for the ITU-T's processes or role, nor for how national administrators= interact with the ITU-T.  But of course we want your input and feedba= ck, so thanks for sending this along.  More comments in line below. &n= bsp;


From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 = AM
To: Modern List <modern@ietf.org>
Subject: [Modern] Fwd: [new-work] W= G Review: Managing, Ordering, Distributing, Exposing, & Registering tel= ephone Numbers (modern)

Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below.

Alissa

Begin forwarded message:

From:= "Zhang, Jie"= <jie.zhang@itu.int>
Subje= ct: RE: [new-work] WG Review= : Managing, Ordering, Distributing, Exposing, & Registering telephone N= umbers (modern)
Date:= June 23, 2015 at 1:56:= 42 PM GMT-3
Cc: <= /b>"Jamoussi, Bilel&qu= ot; <bilel.jamoussi@itu.int>
Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Poten= tial impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?
There will be no impacts on E.164 and E.164.1.

2. Entit= ies participating in the defined mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?
Who participates in numbering processes within coun= tries is subject to regulation.  The WG cannot make any decisions with= regard to this.  I expect the WG to define "roles" wit= hin the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those rol= es could interact with each other.  This will be a baseline = for what tools and solutions would be useful to facilitate those interactio= ns.  

3. Statu= s of Telephone numbers in the defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?
I would expect proposed solutions to be able to address the status of = a telephone number.

4. Regul= atory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".
We are aware of Resolution 133 and will certainly respect i= t.  I=  would propose adding the following text after the first sentence in the last ful= l paragraph =96 "The group acknowledges ITU Plen= ipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocat= ion and management of their country code numbering resources as enshrined i= n Recommendation ITU-T E.164.= "  

5. Relat= ionship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.
The WG will not create any new namespace that would= require regulatory oversight, e.g., a new TLD, SLD, etc.  I = ;wouldn't rule out the WG leveraging existing namespaces as part of pr= oposed solutions.  But it's too early to say anything specific about that.  There is nothing in the charter that references= .tel.  

6. Relat= ionship with related existing or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.
I agree.  I would modify that senten= ce to add the following at the end - "as well as other relevant&n= bsp;industry and standards organizations."

7. The n= ame of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.
The IETF often has fun with creating WG names. &nbs= p;: )  But the charter is where to look for the scope of work.  T= he charter uses the following phrases "distribution, acquisition and m= anagement of TNs", "functions involved in associating information =85 with TNs", "associating, acquiring and=  resolving TNs", "access data related to TNs"= , and "mechanisms for resolving information related to TNs".=  The functions you believe were left out of the charter will be part = of one or more of these processes.  


Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work



_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.= ietf.org/mailman/listinfo/modern
--_000_FC6E11B6D5114C4B9321922478ACA1D7attcom_-- From nobody Fri Jun 26 08:09: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 154991B3090 for ; Fri, 26 Jun 2015 08:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 oLzhTvrbK70F for ; Fri, 26 Jun 2015 08:09:26 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 134221B30A7 for ; Fri, 26 Jun 2015 08:09:25 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QF9NVg016355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 17:09:23 +0200 Received: from Timea (35.56.14.46.dynamic.wline.lns.sme.cust.swisscom.ch [46.14.56.35]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QF9MRp006384; Fri, 26 Jun 2015 17:09:22 +0200 From: "Richard Hill" To: "'McGarry, Tom'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> In-Reply-To: Date: Fri, 26 Jun 2015 17:09:23 +0200 Message-ID: <005a01d0b022$169bcbb0$43d36310$@ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01D0B032.DA249BB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxEB/Zz98yjqU+KL6VWQx+3vZ29zs4AgAERc1A= Content-Language: fr-ch X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 15:09:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005B_01D0B032.DA249BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you for this clarification. Since the intent is to create tools and solutions that would be used by national regulators, presumably they should be involved in the development of the tools. As far as I know, national regulators from most countries don't normally participate in the IETF, for a number of reasons, including the IETF's decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU's decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at first, then I would suggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If the US experience proved successful, then the tools could be proposed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the start, then I would suggest that the appropriate forum would be ITU-T, not IETF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers. Entities can choose to use these tools or not. These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T. But of course we want your input and feedback, so thanks for sending this along. More comments in line below. From: Alissa Cooper Date: Thursday, June 25, 2015 7:44 AM To: Modern List Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say whether there would be an impact. Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recognition of course that the changes would have to be proposed to ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regulation. The WG cannot make any decisions with regard to this. I expect the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other. This will be a baseline for what tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That is, the definition of a "role" may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a telephone number. >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU-T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used". We are aware of Resolution 133 and will certainly respect it. I would propose adding the following text after the first sentence in the last full paragraph - "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, I would suggest adding "The group's outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein." >RH: For the sake of clarity I reiterate that I oppose the creation of this group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions. But it's too early to say anything specific about that. There is nothing in the charter that references .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "as well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent. The IETF often has fun with creating WG names. : ) But the charter is where to look for the scope of work. The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information . with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs". The functions you believe were left out of the charter will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ------=_NextPart_000_005B_01D0B032.DA249BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for this clarification.

 

Since the intent is to create tools and solutions that would be used = by national regulators, presumably they should be involved in the = development of the tools. 


As far as I know, national regulators from most countries = don’t normally participate in the IETF, for a number of reasons, = including the IETF’s decision-making process and the fact that the = IETF works in English. National regulators do participate in ITU-T, for = a number of reasons, including the ITU’s decision-making process = and the fact that documents are translated into the six UN languages = before they are formally approved (and some discussions takes place with = interpretation in six languages).

 

If the intent is to develop tools that would be used only in the USA = at first, then I would suggest that it would be more appropriate to = develop them in a forum such as ATIS or an ad-hoc group created = specifically for the purpose. If the US experience proved successful, = then the tools could be proposed for adoption elsewhere, for example = through ITU-T.

 

If the intent is to develop tools for use in many countries right at = the start, then I would suggest that the appropriate forum would be = ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the creation of this new working group, = and this even if the Charter is modified as suggested = below.

 

Please see additional comments inline.

 

Thanks and best,

Richard

 

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, = Tom
Sent: vendredi, 26. juin 2015 00:31
To: = modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)

 

 

This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. =  Entities can choose to use these tools or not.  These tools = are not for the ITU-T's processes or role, nor for how national = administrators interact with the ITU-T.  But of course we want your = input and feedback, so thanks for sending this along.  More = comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: = Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: = [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Would appreciate people’s thoughts on whether any charter edits = may be warranted in response to these comments, and/or whether a = separate response may be useful for addressing some of the questions = below.

 

Alissa

 

Begin forwarded message:



From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU = Telecommunication Standardization Bureau on the proposed IETF working = group MODERN.

1. Potential = impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated = at the beginning of the Charter that 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. And it is = mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to = here only deals with Tel URI? Would there be any impact on = Recommendation ITU-E E.164 and E.164.1 which are core recommendations on = Telephone Numbers?

= There will be no impacts on E.164 and E.164.1.

 

>RH: Given the scope of the work, I think that it is too early to = say whether there would be an impact. Those Recommendations are = regularly updated, in particular E.164.1, so there is nothing wrong with = envisaging changes, with the recognition of course that the changes = would have to be proposed to ITI-T Study Group 2 and agreed by that = group.


2. Entities participating in = the defined mechanisms
The Charter states that the protocol mechanism = for resolving TNs will allow entities such as service providers, = devices, and applications to access data related to TNs. But it is not = clear what kind of entities can participate in the mechanisms defined by = this MODERN working group. Would it be restricted to the entities who = have been assigned a TN or a block of = TNS?

= Who participates in numbering processes within countries is subject to = regulation.  The WG cannot make any decisions with regard to this. =  I expect the WG to define "roles" within the number = management processes; e.g., administrator, telecom = carrier, application provider, consumer, etc.; and how those = roles could interact with each other.  This will be = a baseline for what tools and solutions would be useful to = facilitate those interactions.  

 

>RH: Even that might be subject to, or affect, national = regulations.  That is, the definition of a “role” may = well depend on national = regulations.


3. Status of Telephone numbers = in the defined mechanisms
Several operations related to TNs are = mentioned in the Charter, including requesting, acquiring, resolving and = associating. It is also stated that the protocol mechanism for acquiring = TNs will provide an enrollment process for the entities that use and = manage TNs. Does that mean Telephone numbers with various status, such = as assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working = group?

I=  would expect proposed solutions to be able to address the status = of a telephone number.=

 

>RH: Since the terms “assigned”, “spare” = and “reclaimed” are defined in ITU-T Recommendations (albeit = sometimes implicitly), addressing the status of a telephone number might = well impact E.164 or = E.164.1.


4. Regulatory issues
The = Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact = that the E.164 international public telecommunication numbering plan is = a politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of = ITU Member States with respect to allocation and management of their = country code numbering resources as enshrined in Recommendation ITU-T = E.164", and further instructed the ITU Secretary-General and the = Directors of three Bureaux (Telecommunication Standardization, = Development, and Radiocommunication) to "take any necessary action = to ensure the sovereignty of ITU Member States with regard to = Recommendation ITU-T E.164 numbering plans whatever the application in = which they are = used".

We are aware of = Resolution 133 and will certainly respect it.  I would propose = adding the following text after the first sentence in the last full = paragraph – "The group acknowledges ITU = Plenipotentiary Conference Resolution 133 which recognizes the existing = role and sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined = in Recommendation ITU-T E.164."  

 

>RH: That certainly would be a helpful addition. In addition to = the above, I would suggest adding “The group’s outputs would = be consistent with the provisions of relevant ITU-T Recommendations, in = particular E.164, E.164.1, E.190 and the Recommendations referenced = therein.” 

 

>RH: For the sake of clarity I reiterate that I oppose the = creation of this group even if the Charter is modified to include the = text above.

 


5. Relationship with = .Tel
DNS-based use of international numbering resources has been = discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 = September 2013. TSB Director has also exchanged letters with ICANN on = issues related to registering digit strings in the .TEL domain. A = representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A = correspondence group under ITU-T SG2 was also set up in this regard. We = would like to know how the work of this new WG would relate to issues = related to registering digit strings in the .TEL domain and other = DNS-based use of telephone = numbers.

= The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule = out the WG leveraging existing namespaces as part of proposed = solutions.  But it's too early to say anything specific about that. =  There is nothing in the charter that references .tel. =  


6. Relationship with related = existing or concluded WGs
It is stated in the Charter that the = working group will take into consideration existing IETF work including = STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the = relationship between this new WG and the above mentioned other existing = or concluded WGs would be = appreciated.

= I agree.  I would modify that sentence to add the = following at the end - "as well as = other relevant industry and standards = organizations."


7. The name of this new = WG
The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the = Charter, ordering, exposing and registering TNs are not mentioned, which = seems to be a little bit = inconsistent.

= The IETF often has fun with creating WG names.  : )  But the = charter is where to look for the scope of work.  The charter uses = the following phrases "distribution, acquisition and management = of TNs", "functions involved in associating = information … with TNs", "associating, = acquiring and resolving TNs", "access data related = to TNs", and "mechanisms for resolving information = related to TNs".  The functions you believe were left out = of the charter will be part of one or more of these processes. =  



Best regards,

Jie Zhang
Advisor, ITU-T = SG2
International Telecommunication Union
Place des = Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 = 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Origina= l Message-----
From: new-work [mailto:new-work-bounces@ietf.or= g] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 = PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz> Steve Donovan <srdonovan@usdonovans.com>=

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailin= g list
 Address: modern@ietf.org
 To = Subscribe: https://www.ietf.or= g/mailman/listinfo/modern
 Archive: http://www.ietf.org= /mail-archive/web/modern/

Charter:

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. = Devices, applications, and network tools increasingly need to manage = TNs, including requesting and acquiring TN delegations from authorities. = The output of the working group should make distribution, acquisition, = and management of TNs simpler for all entities involved.

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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs. 

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, and security = and privacy for both the data and the protocol interactions are primary = considerations. The working group will take into consideration existing = IETF work including STIR, 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. 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 for TN assignment and management, for = example those established by different regulatory agencies.

The = working 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

Milestones:

TBD

________________________________= _______________
new-work mailing list
new-work@ietf.org
https://www.ietf.= org/mailman/listinfo/new-work

 

 

<= /html> ------=_NextPart_000_005B_01D0B032.DA249BB0-- From nobody Fri Jun 26 09:35:09 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 A75B71A6F05 for ; Fri, 26 Jun 2015 09:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 bzK5zljZy55q for ; Fri, 26 Jun 2015 09:34:41 -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 0D6E91A6EF1 for ; Fri, 26 Jun 2015 09:34:41 -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 t5QGX3ia011045; Fri, 26 Jun 2015 12:34:37 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1v8ytw8q5t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 12:34:36 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 12:34:33 -0400 From: "Peterson, Jon" To: Richard Hill , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugA== Date: Fri, 26 Jun 2015 16:34:32 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: <005a01d0b022$169bcbb0$43d36310$@ch> 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.179] Content-Type: multipart/alternative; boundary="_000_D1B2C60015475Ejonpetersonneustarbiz_" 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-06-26_06:2015-06-26,2015-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506260239 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 16:34:50 -0000 --_000_D1B2C60015475Ejonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, surely the IETF is not a suitable body for = managing the DNS! And it isn't. But it is a suitable body for managing the = protocol work on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies th= ere are lots of national regulators and they worry about the sorts of thing= s you are worrying about here. The IETF just produces tools, and that is al= l MODERN proposes to do. Trying to characterize this effort otherwise is si= mply an error. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. This makes the IETF really di= fferent from places like the ITU, where the products of work have some bind= ing effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. But we're just building some p= rotocol tools. There is also related work here for ATIS to do, and I'm sure= ATIS or some other body could later take some the protocol tools developed= in the IETF and conduct an experiment with various carriers to see if it w= orks for that interest group or not, and that would be interesting informat= ion. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the= ITU=92s decision-making process and the fact that documents are translated= into the six UN languages before they are formally approved (and some disc= ussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =93role=94 may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 are de= fined in ITU-T Recommendations (albeit sometimes implicitly), addressing th= e status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =93The group=92s outputs would be consistent with th= e provisions of relevant ITU-T Recommendations, in particular E.164, E.164.= 1, E.190 and the Recommendations referenced therein.=94 >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --_000_D1B2C60015475Ejonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <72077F9C7C6C5B4EB1A2F0C32ED825EC@neustar.biz> Content-Transfer-Encoding: quoted-printable

Your arguments here could equally well be applied to any important res= ource on which the IETF does protocol work - like, say, the DNS. The IETF m= anages the DNS protocol and publishes RFCs about it. But since national aut= horities are responsible for ccTLDs, surely the IETF is not a suitable body for managing the DNS! And it isn't.= But it is a suitable body for managing the protocol work on the DNS. Other= , effectively unrelated entities handle the administrative dimensions of op= erating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sort= s of things you are worrying about here. The IETF just produces tools, and = that is all MODERN proposes to do. Trying to characterize this effort other= wise is simply an error.

All work at the IETF is done by a coalition of the willing. If it turn= s out that the coalition is not representative of the needs of the communit= y, then what happens? Well, the work built here doesn't get used. The only = people who wasted any time or effort were the members of that coalition. No national interests can possibly be = harmed by that, even if the failed work involved ways of talking about tele= phone numbers. This makes the IETF really different from places like the IT= U, where the products of work have some binding effect on the world.

Virtually all proposed work at the IETF also faces a coalition of the = unwilling. People who aren't interested, or who think the work should be do= ne elsewhere, or that the work simply shouldn't be done at all. But I maint= ain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agre= e that if this proposed work required regulatory oversight, that the IETF s= houldn't do it. But we're just building some protocol tools. There is also = related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol to= ols developed in the IETF and conduct an experiment with various carriers t= o see if it works for that interest group or not, and that would be interes= ting information. But the IETF doesn't do that part, and doesn't aspire to do that part.

Finally, I'm not really sure how much I would expect "national re= gulators" to literally use the tools proposed in this work. They are t= ools for the use of a diverse industry of enterprises, carriers, end users,= and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part ins= tigated by an FCC workshop, yes, and someone associated with the FCC spoke = at the MODERN BoF. But I don't anticipate that the FCC would be propping up= servers to deploy this work - surely they would leave that to industry. 

Jon Peterson
Neustar, Inc.

From: Richard Hill <rhill@hill-a.ch>
Date: Friday, June 26, 2015 at 8:09= AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, &= quot;modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] Fwd: [new-wor= k] WG Review: Managing, Ordering, Distributing, Exposing, & Registering= telephone Numbers (modern)

Thank you for this clarification.

 

Since the intent is to create tools= and solutions that would be used by national regulators, presumably they s= hould be involved in the development of the tools. 


As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the ITU=92s decision-making process and= the fact that documents are translated into the six UN languages before th= ey are formally approved (and some discussions takes place with interpretat= ion in six languages).

 

If the intent is to develop tools t= hat would be used only in the USA at first, then I would suggest that it wo= uld be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the pu= rpose. If the US experience proved successful, then the tools could be prop= osed for adoption elsewhere, for example through ITU-T.

 

If the intent is to develop tools f= or use in many countries right at the start, then I would suggest that the = appropriate forum would be ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the crea= tion of this new working group, and this even if the Charter is modified as= suggested below.

 

Please see additional comments inli= ne.

 

Thanks and best,<= /p>

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

This effort is intended to create tools and = solutions to enable flexibility in the process of managing numbers among na= tional administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for h= ow national administrators interact with the ITU-T.  But of course we = want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <ali= ssa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people=92s thoughts on whet= her any charter edits may be warranted in response to these comments, and/o= r whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:



From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Mana= ging, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3<= /o:p>

To: "iesg@ietf.org" <iesg@ietf.org><= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; color: b= lack;">

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.164.1= .

 

>RH: Given the scope of the work= , I think that it is too early to say whether there would be an impact. Tho= se Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, = with the recognition of course that the changes would have to be proposed t= o ITI-T Study Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes withi= n countries is subject to regulation.  The WG cannot make any decision= s with regard to this.  I expect the WG to define "roles" within the number management processes; e.g.= , administrator, telecom carrier, application provider, consumer,= etc.; and how those roles could interact with each other.  This will = be a baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject = to, or affect, national regulations.  That is, the definition of a =93= role=94 may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions to be able = to address the status of a telephone number.

 

>RH: Since the terms =93assigned= =94, =93spare=94 and =93reclaimed=94 are defined in ITU-T Recommendations (= albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".

We are aware of Resolution 133 and will certainly respect it. &n= bsp;I would propose adding the following text after the first sentence= in the last full paragraph =96 "The group acknowledges = ;ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  

 

>RH: That certainly would be a h= elpful addition. In addition to the above, I would suggest adding =93The gr= oup=92s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1= , E.190 and the Recommendations referenced therein.=94 

 

>RH: For the sake of clarity I r= eiterate that I oppose the creation of this group even if the Charter is mo= dified to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.=

The WG will not create any new namespace that= would require regulatory oversight, e.g., a new TLD, SLD, etc.  = I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say = anything specific about that.  There is nothing in the charter that re= ferences .tel.  


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify that = sentence to add the following at the end - "as well as other rele= vant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG names= .  : )  But the charter is where to look for the scope of work. &= nbsp;The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information =85 with TNs", "associating, ac= quiring and resolving TNs", "access data related to&nbs= p;TNs", and "mechanisms for resolving information related to = ;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work

 

 

 --_000_D1B2C60015475Ejonpetersonneustarbiz_-- From nobody Fri Jun 26 09:55: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 2CA281A1B83 for ; Fri, 26 Jun 2015 09:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 erfJa8R1zQ2V for ; Fri, 26 Jun 2015 09:55:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FE11A0105 for ; Fri, 26 Jun 2015 09:55:28 -0700 (PDT) Received: from BY2FFO11FD055.protection.gbl (10.1.14.30) by BY2FFO11HUB014.protection.gbl (10.1.14.80) with Microsoft SMTP Server (TLS) id 15.1.201.10; Fri, 26 Jun 2015 16:55:23 +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 BY2FFO11FD055.mail.protection.outlook.com (10.1.15.192) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Fri, 26 Jun 2015 16:55:22 +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 t5QGqIKr006980; Fri, 26 Jun 2015 12:55:21 -0400 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by preapdm1.corp.sprint.com with ESMTP id 1v8yr13u6m-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 12:55:21 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 26 Jun 2015 12:55:20 -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; Fri, 26 Jun 2015 11:55:20 -0500 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEVhNQitnoIUyGmpgejVxL7J2+EeCAgAEW4ID//6JugIAAM3mQ Date: Fri, 26 Jun 2015 16:55:19 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: 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.229.91.92] Content-Type: multipart/related; boundary="_004_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD055; 1:eF4OUWSskjIibEU32rYtcNc4MRYLMRWHQr5vQMjWBiQjxX5bU4e0yDtpdC3WFqEn4EA1JNztcbLCxIbwJX5OP2Us/w4EAqXgHowg8gJnbEXdXzrJNOWLqUZKdp+gPnCcKhDIndc/5MyeIMqv8ye0wtyVLy1KhwY1sWCZ1DYvN8x1PjotFPhY9OP+cQrYlHTd8qVU2mumbidaMCvy2HSKvaDwepgLjl9IopbevHfpn5YJ1fp0+h/bWgvyluon9JzULlMwEBAil7ZMvy5YYfr7xH4ETDJkkuDl7PbOQ9L1Z6nBipcVOZF2JV6jlH2n31Vk X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(448002)(2473001)(51444003)(13464003)(377454003)(45074003)(60444003)(189002)(199003)(52604005)(86362001)(575784001)(2900100001)(2950100001)(108616004)(2501003)(5250100002)(93886004)(85326001)(18206015028)(19580405001)(19580395003)(77156002)(62966003)(84326002)(15975445007)(87936001)(5003600100002)(92566002)(19625215002)(102836002)(2656002)(54356999)(76176999)(99936001)(50986999)(189998001)(512954002)(107886002)(17760045003)(5001770100001)(16236675004)(5001960100002)(46102003)(33646002)(19617315012)(19627595001)(106466001)(67866002)(66926002)(15974865002)(6806004)(16601075003)(106116001)(19300405004)(7099028)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB014; H:preapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB014; 2:k1w2Zg7dlIS1CH6h73RGtKrp4zRel7fOyhgkLRKOii7j8tMKOgvG97p2HAu+tFwD; 3:C9UwAyMNnCGXnWLvdujNiXnkrcD6lgsyklfj8duU4PWE3IiLOHRqjVNJBscDXvm7n8xWU8AIFgkhbw1vKtYcewrge8BXxukZX/G8rp2KlJgSz8+pi63/+sEJEEKOuuL8dEQEHFFDoi1f6bP86TXn0+GYDY+8hFDRbSKi9tInPPmhQvAFt9J7F3d2pbgaCeH9aDUufO3A1FD71iV0CX+Dlla3Und9euJ+Y+vMzzfMfJU=; 20:OYlgFS7AmlfuFLkNIZ6BUvbJcy8T1Bt2WQLGHxHvVFWq9sl2590fe5fvNIUTgvCDh/Q4GhFLEsgGYMmVc3sx4GF2eSjUpPsL2v4sn5cN2n/m5eiJnPci9Zy20Yi2h1ZZhyGMwzO72K+nScrOYaPPZ8bk0OVr8RJiNZAxnTyAcI1rJTgNKSHAuVWIovnJkuFOnU4hbpGdb7+2VlLG1t2wOLp4WH6R9lSlAqBKOEsUbn/n/WKboZW8K/TTIi0Q+HhR; 4:vytv0QsFvRcoIleIW3GGtQH/jm7K2sNrJLlPvuC/kIdtbSF1xb1gQHKqvPHbx+qkG+sNJvCZiYxDSUb/OdAs81uW2DfH6xlYs2vanWsuks/NYr6LEu5FyZzdTmvyiialMDRU5bsPzbKtPnmv7j8/1HR2YHpC3iNBC0ubZBJjC23VyRgx77UYdQqlQ//K3pKW2U2r/FMyDHjSq/eHB8Q1rl3tH2bRpGw6qyRSEFUn13qWXBn/bGBfGyhBoSNoRRQQxnX9+nbj1VmgAsK/74D9/NkE0Sp3JEhIInBZeFShwfQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB014; 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:BY2FFO11HUB014; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB014; X-Forefront-PRVS: 0619D53754 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB014; 23:Mnr+wmpj78iI/coAAwbQnF3enYo5gV1PTKl3Ahf2?= =?us-ascii?Q?Hqs2DLUatKxbzBF6mneanhMcAoo24kX8VItJRz85Mv8wcPu+tNOHnFY+/eFw?= =?us-ascii?Q?qphhpi8R6j2AQOZm2J8tSqA1G4wDP7BcBZq8gA2SpSnzB9QPTWY8Iz+kInGi?= =?us-ascii?Q?e1kI572V/ULTO3aTaM5UjulhvPZPaW/St3M5RLgAZ+Nf7dVirlvecGmyigII?= =?us-ascii?Q?1sBnUcLilJCp8jf/pjlvCEfzjjmwyWSwuzudPOumyGssGVNjJsOb0zt1MZgq?= =?us-ascii?Q?tltYi1Mk+1h+PlF+6B03nzPkz/45nvFaLaOQqT9qKJtSxHSvI+2VxL6xkGN3?= =?us-ascii?Q?4FNMrX9Y1W7cd/UOo6L4tLeVA0YUeSjZEJwO1IoCfrljluP0buPP67ZQxSt7?= =?us-ascii?Q?DyWmLpm+SA+XcQ/z627HhQtn9HL3zmQFfFK4fid6eqcyKUd1HnS8tc6RsNu1?= =?us-ascii?Q?99+0OlnQce3Ct9aFD+NvJvkj5H+518n9gsm4WeKjlG+0meYwJYJIA3CQa+71?= =?us-ascii?Q?HgTCH/NVgHiPrt4Frnp4NAjOtwZ0xqbKo+1vGhcDIv8+JxK2jHZ3vUxmN4fT?= =?us-ascii?Q?RKqgz+sQwFIH0nO+3ZorDkIsHNsCKEkeSR5awpP23Ay/goyaemsuD8eWHaw1?= =?us-ascii?Q?e5dtYB26szvhYx5r/bDfyL89TmJvfko6UY8HD+9L35NUXGmXFjdDafcDS78U?= =?us-ascii?Q?lwpBwq/1ZwJyQkHoz8hGGfDT9NMnPU38AWrAyjfv2wHtegq8LIZXlbmdieUw?= =?us-ascii?Q?S9+ZV77IocymwoOnjHSIyFtnVntdXM6+74dJuHqG78CCr45GelEuGxULAgw2?= =?us-ascii?Q?wXney+PyEqB0m2eloVPS58X8/0l6a67n0jhmbE8/8nfukFX8rypjBNzaOWVb?= =?us-ascii?Q?ykFU8vv/BNUGVTL18vrgtODan+BdVvC4gTOBKS6mRC9HHdByl7uqFqc0Z/ld?= =?us-ascii?Q?vKa6r5ushDYMiE1fLk1TPR59FjoCSkUGg1yhtSnIvPmP9u5dSyd+iTRq79JV?= =?us-ascii?Q?cvi4/l9gnDU6TUL36AOA2Br/fVAfUcPKK+GNrH8U50E5nQyO5fNMYZ/dVuno?= =?us-ascii?Q?rMq9fSxLMl720/g/03oEZESEjGPruHo5zLDZEieRPojYNnw7Oa8Fb75P2zV+?= =?us-ascii?Q?5AQeFJFuXFASio9EujDbfaLVrYXZeQUC607DXQuBIxbWQMY+l5Uf4d5dqm2w?= =?us-ascii?Q?J0deL6F2F/mmTgbPclZwTjLsmQsl2bvIP2N+9yfsq3bP/ueEtSc3b78jKOCi?= =?us-ascii?Q?y03GmTCx0SeaqyoOziFc+b3cIpjZ7DS7M1Gra2SlA0KqOo5Al3NU92vXtzvV?= =?us-ascii?Q?UJnZKt5SBh3MljQtEMSViBDeQsFUgocNn0mk4kZzM7VG/bxYBnqjoOYsKhST?= =?us-ascii?Q?5eKNKdLBPt7UC6JvQEIohXcfahSvPKuwZWTjsriN67B+QlI9urrbQMeUuO8T?= =?us-ascii?Q?B17B27TBzMZ/3FnYn3Rqnsfp1Fxb02m55rzyG94R3YxACBuffqicTeGxR4vQ?= =?us-ascii?Q?RnoX+hYHOe+N/FVmvgWeTht9YA04NdnG3SU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB014; 5:g3KP8EZgV8QBbB/6ssFZnnX+cOk/L3JPPlp+sDUlR+TzOUrEua1xj9/QKwTwBPrR2hLAkeN1pMbJ4SPCusEJHRlsBhnvHnwoh44jpQL+YK1DvTf2ilhKLaZKAkHpNDdZLwqqNshdaqbkzbLIdga1TA==; 24:YiFaZSxn00iwokFHl8YMB1zVY1ibPf4TwGCe75u6UepgSlJz/H3MZK2kYg4oTWku6If3Ttzm8CMEp3HIO9CwOHeHK3WtPwzEzobgt0bStIk= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2015 16:55:22.9403 (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: BY2FFO11HUB014 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 16:55:43 -0000 --_004_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_" --_000_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Many use cases under consideration would not have a national regulator as = an actor." - J. Peterson I've struggled with this point. What are the "many" use cases? For exampl= e, I've not been able to envision the use case that would require a device = to use a MODERN protocol tool to acquire an RFC 3966 telephone number. Wha= t is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol= tools to manage telephone numbers? What is broken about the existing syst= em(s)? And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., = 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,= SMS800, et cetera. And the administration is distributed (in the US) at national and state lev= els. Has anyone from any of the US or international number management administra= tive organizations requested that the IETF build tools for them? If they d= on't use them, who will? And how can they integrate with an existing syste= m? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, surely the IETF is not a suitable body for = managing the DNS! And it isn't. But it is a suitable body for managing the = protocol work on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies th= ere are lots of national regulators and they worry about the sorts of thing= s you are worrying about here. The IETF just produces tools, and that is al= l MODERN proposes to do. Trying to characterize this effort otherwise is si= mply an error. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. This makes the IETF really di= fferent from places like the ITU, where the products of work have some bind= ing effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. But we're just building some p= rotocol tools. There is also related work here for ATIS to do, and I'm sure= ATIS or some other body could later take some the protocol tools developed= in the IETF and conduct an experiment with various carriers to see if it w= orks for that interest group or not, and that would be interesting informat= ion. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don't normally pa= rticipate in the IETF, for a number of reasons, including the IETF's decisi= on-making process and the fact that the IETF works in English. National reg= ulators do participate in ITU-T, for a number of reasons, including the ITU= 's decision-making process and the fact that documents are translated into = the six UN languages before they are formally approved (and some discussion= s takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warr= anted in response to these comments, and/or whether a separate response may= be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a "role" may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU= -T Recommendations (albeit sometimes implicitly), addressing the status of = a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph - "The group acknowledges ITU Plenipotentiary Conference Resolution = 133 which recognizes the existing role and sovereignty of ITU Member States= with respect to allocation and management of their country code numbering = resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding "The group's outputs would be consistent with the pr= ovisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E= .190 and the Recommendations referenced therein." >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information ... with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ________________________________ 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_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“Many use cas= es under consideration would not have a national regulator as an actor.”  - J. Peterson

 

I’ve struggled with this point.&n= bsp; What are the “many” use cases?  For example, I’= ve not been able to envision the use case that would require a device to us= e a MODERN protocol tool to acquire an RFC 3966 telephone number.  What is this = use case?

 

This continues to baffle me.  Why = is the IETF proposing to develop protocol tools to manage telephone numbers= ?  What is broken about the existing system(s)?

 

And I really struggle with how this is = supposed to work because there are so many different kinds of telephone num= bers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs, IMRNs, = ported numbers, and multiple administrative databases, NPAC, LERG, SMS800, = et cetera.

 

And the administration is distributed (= in the US) at national and state levels.

 

Has anyone from any of the US or intern= ational number management administrative organizations requested that the I= ETF build tools for them?  If they don’t use them, who will?  And how can they integrate with an existing system?  = Sorry Jon.  Still lost.

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorm= an@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

Your arguments here could equally well = be applied to any important resource on which the IETF does protocol work -= like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are r= esponsible for ccTLDs, surely the IETF is not a suitable body for managing = the DNS! And it isn't. But it is a suitable body for managing the protocol = work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the D= NS, and yes, at those bodies there are lots of national regulators and they= worry about the sorts of things you are worrying about here. The IETF just= produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is sim= ply an error.

 

All work at the IETF is done by a coali= tion of the willing. If it turns out that the coalition is not representati= ve of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any= time or effort were the members of that coalition. No national interests c= an possibly be harmed by that, even if the failed work involved ways of tal= king about telephone numbers. This makes the IETF really different from places like the ITU, where the produc= ts of work have some binding effect on the world.

 

Virtually all proposed work at the IETF= also faces a coalition of the unwilling. People who aren't interested, or = who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "f= ormal objection" treats the scope of the proposed work as being differ= ent than it is, and I'd agree that if this proposed work required regulator= y oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related work he= re for ATIS to do, and I'm sure ATIS or some other body could later take so= me the protocol tools developed in the IETF and conduct an experiment with = various carriers to see if it works for that interest group or not, and that would be interesting information.= But the IETF doesn't do that part, and doesn't aspire to do that part.

 

Finally, I'm not really sure how much I= would expect "national regulators" to literally use the tools pr= oposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases un= der consideration would not have a national regulator as an actor. This wor= k was in part instigated by an FCC workshop, yes, and someone associated wi= th the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy= this work - surely they would leave that to industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <mod= ern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

Thank you for this clarification.

 

Since the intent is to create tools a= nd solutions that would be used by national regulators, presumably they sho= uld be involved in the development of the tools. 


As far as I know, national regulators from most countries don’t norma= lly participate in the IETF, for a number of reasons, including the IETF= 217;s decision-making process and the fact that the IETF works in English. = National regulators do participate in ITU-T, for a number of reasons, including the ITU’s decision-making process= and the fact that documents are translated into the six UN languages befor= e they are formally approved (and some discussions takes place with interpr= etation in six languages).

 

If the intent is to develop tools tha= t would be used only in the USA at first, then I would suggest that it woul= d be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If t= he US experience proved successful, then the tools could be proposed for ad= option elsewhere, for example through ITU-T.

 

If the intent is to develop tools for= use in many countries right at the start, then I would suggest that the ap= propriate forum would be ITU-T, not IETF, for the reasons outlined above.<= /span>

 

Thus, I formally object to the creati= on of this new working group, and this even if the Charter is modified as s= uggested below.

 

Please see additional comments inline= .

 

Thanks and best,

Richard

 

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

This effort is intended to create tools= and solutions to enable flexibility in the process of managing numbers amo= ng national administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for h= ow national administrators interact with the ITU-T.  But of course we = want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people’s thought= s on whether any charter edits may be warranted in response to these commen= ts, and/or whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:




From: "Zhang, Jie" <jie.zhang@itu.int>=

Subject: RE: [new-work] WG Review:= Managing, Ordering, Distributing, Exposing, & Registering telephone Nu= mbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.= 164.1.

 

>RH: Given the scope of the work, = I think that it is too early to say whether there would be an impact. Those= Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recog= nition of course that the changes would have to be proposed to ITI-T Study = Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes = within countries is subject to regulation.  The WG cannot make any dec= isions with regard to this.  I expect the WG to define "roles" within the number management processes; e.g., admin= istrator, telecom carrier, application provider, consumer, etc.; = and how those roles could interact with each other.  This will be a&nb= sp;baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject to= , or affect, national regulations.  That is, the definition of a ̶= 0;role” may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions= to be able to address the status of a telephone number.

 

>RH: Since the terms “assign= ed”, “spare” and “reclaimed” are defined in I= TU-T Recommendations (albeit sometimes implicitly), addressing the status o= f a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".<= /p>

We are aware of Resolution 133 and will certainly respect= it.  I would propose adding the following text after the first s= entence in the last full paragraph – "The group acknow= ledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  =

 

>RH: That certainly would be a hel= pful addition. In addition to the above, I would suggest adding “The = group’s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and= the Recommendations referenced therein.” 

 

>RH: For the sake of clarity I rei= terate that I oppose the creation of this group even if the Charter is modi= fied to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace= that would require regulatory oversight, e.g., a new TLD, SLD, etc. &= nbsp;I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say anything sp= ecific about that.  There is nothing in the charter that references .t= el.  


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify = that sentence to add the following at the end - "as well as other = ;relevant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG = names.  : )  But the charter is where to look for the scope of wo= rk.  The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information … with TNs", "associating= , acquiring and resolving TNs", "access data related to=  TNs", and "mechanisms for resolving information related to&= nbsp;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work<= /o:p>

 

 



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_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_-- --_004_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Fri, 26 Jun 2015 16:55:19 GMT"; modification-date="Fri, 26 Jun 2015 16:55:19 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_d2460d69736a4afb8eb74b19fc05304dPLSWE13M08adsprintcom_-- From nobody Fri Jun 26 10:00:10 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EC41A894E for ; Fri, 26 Jun 2015 10:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 8ykDfMXgUn2n for ; Fri, 26 Jun 2015 10:00:01 -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 642031A8881 for ; Fri, 26 Jun 2015 10:00:01 -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 t5QGxRvW009801; Fri, 26 Jun 2015 12:59:57 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1v97d9r9gq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 12:59:56 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 12:59:53 -0400 From: "Peterson, Jon" To: "Gorman, Pierce A [CTO]" , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugIAAeyuA//+L6YA= Date: Fri, 26 Jun 2015 16:59:52 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.179] Content-Type: multipart/mixed; boundary="_004_D1B2D27A154820jonpetersonneustarbiz_" 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-06-26_06:2015-06-26,2015-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506260245 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:00:08 -0000 --_004_D1B2D27A154820jonpetersonneustarbiz_ Content-Type: multipart/alternative; boundary="_000_D1B2D27A154820jonpetersonneustarbiz_" --_000_D1B2D27A154820jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One would be an enterprise IP phone that has just been deployed and wants t= o acquire a new number from an IP PBX. Another would be a VoIP service prov= ider who wants to receive a block of new numbers through a delegation from = a carrier. I ran through such use cases at the MODERN BoF. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" > Date: Friday, June 26, 2015 at 9:55 AM To: Jon Peterson = >, Richard Hill >, "McGarry, Tom" <= Tom.McGarry@neustar.biz>, "modern@ietf.org<= mailto:modern@ietf.org>" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) =93Many use cases under consideration would not have a national regulator a= s an actor.=94 - J. Peterson I=92ve struggled with this point. What are the =93many=94 use cases? For = example, I=92ve not been able to envision the use case that would require a= device to use a MODERN protocol tool to acquire an RFC 3966 telephone numb= er. What is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol= tools to manage telephone numbers? What is broken about the existing syst= em(s)? And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., = 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,= SMS800, et cetera. And the administration is distributed (in the US) at national and state lev= els. Has anyone from any of the US or international number management administra= tive organizations requested that the IETF build tools for them? If they d= on=92t use them, who will? And how can they integrate with an existing sys= tem? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, surely the IETF is not a suitable body for = managing the DNS! And it isn't. But it is a suitable body for managing the = protocol work on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies th= ere are lots of national regulators and they worry about the sorts of thing= s you are worrying about here. The IETF just produces tools, and that is al= l MODERN proposes to do. Trying to characterize this effort otherwise is si= mply an error. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. This makes the IETF really di= fferent from places like the ITU, where the products of work have some bind= ing effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. But we're just building some p= rotocol tools. There is also related work here for ATIS to do, and I'm sure= ATIS or some other body could later take some the protocol tools developed= in the IETF and conduct an experiment with various carriers to see if it w= orks for that interest group or not, and that would be interesting informat= ion. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the= ITU=92s decision-making process and the fact that documents are translated= into the six UN languages before they are formally approved (and some disc= ussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =93role=94 may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 are de= fined in ITU-T Recommendations (albeit sometimes implicitly), addressing th= e status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =93The group=92s outputs would be consistent with th= e provisions of relevant ITU-T Recommendations, in particular E.164, E.164.= 1, E.190 and the Recommendations referenced therein.=94 >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ________________________________ 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_D1B2D27A154820jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9C7A57F990ACBB468853352AA91D1318@neustar.biz> Content-Transfer-Encoding: quoted-printable

One would be an enterprise IP phone that has just been deployed and wa= nts to acquire a new number from an IP PBX. Another would be a VoIP service= provider who wants to receive a block of new numbers through a delegation = from a carrier. I ran through such use cases at the MODERN BoF.

Jon Peterson
Neustar, Inc.

From: <Gorman>, "Pierce = A [CTO]" <Pierce.Gorman= @sprint.com>
Date: Friday, June 26, 2015 at 9:55= AM
To: Jon Peterson <jon.peterson@neustar.biz>, Richard Hil= l <rhill@hill-a.ch>, "McG= arry, Tom" <Tom.McGarry@= neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-wor= k] WG Review: Managing, Ordering, Distributing, Exposing, & Registering= telephone Numbers (modern)

=93Many use cases under = consideration would not have a national regulator as an actor.=94  - J. Peterson

 

I=92ve struggled with this point. = What are the =93many=94 use cases?  For example, I=92ve not been able= to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number.&nbs= p; What is this use case?

 

This continues to baffle me.  Why = is the IETF proposing to develop protocol tools to manage telephone numbers= ?  What is broken about the existing system(s)?

 

And I really struggle with how this is = supposed to work because there are so many different kinds of telephone num= bers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDN= s, IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG= , SMS800, et cetera.

 

And the administration is distributed (= in the US) at national and state levels.

 

Has anyone from any of the US or intern= ational number management administrative organizations requested that the I= ETF build tools for them?  If they don=92t use them, who will?  And how can they integrate with an existing syst= em?  Sorry Jon.  Still lost.

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; m= odern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

Your arguments here could equally well be ap= plied to any important resource on which the IETF does protocol work - like= , say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities a= re responsible for ccTLDs, surely the IETF is not a suitable body for manag= ing the DNS! And it isn't. But it is a suitable body for managing the proto= col work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the D= NS, and yes, at those bodies there are lots of national regulators and they= worry about the sorts of things you are worrying about here. The IETF just= produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is sim= ply an error.

 

All work at the IETF is done by a coalition = of the willing. If it turns out that the coalition is not representative of= the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who w= asted any time or effort were the members of that coalition. No national in= terests can possibly be harmed by that, even if the failed work involved wa= ys of talking about telephone numbers. This makes the IETF really different from places like the ITU, where the p= roducts of work have some binding effect on the world.

 

Virtually all proposed work at the IETF also= faces a coalition of the unwilling. People who aren't interested, or who t= hink the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your &quo= t;formal objection" treats the scope of the proposed work as being dif= ferent than it is, and I'd agree that if this proposed work required regula= tory oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related wor= k here for ATIS to do, and I'm sure ATIS or some other body could later tak= e some the protocol tools developed in the IETF and conduct an experiment w= ith various carriers to see if it works for that interest group or not, and that would be interesting inform= ation. But the IETF doesn't do that part, and doesn't aspire to do that par= t.

 

Finally, I'm not really sure how much I woul= d expect "national regulators" to literally use the tools propose= d in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many us= e cases under consideration would not have a national regulator as an actor= . This work was in part instigated by an FCC workshop, yes, and someone ass= ociated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up serve= rs to deploy this work - surely they would leave that to industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@= hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <mod= ern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

Thank you for this clarification.

 

Since the intent is to create tools= and solutions that would be used by national regulators, presumably they s= hould be involved in the development of the tools.  <= /p>


As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the ITU=92s decision-making process and= the fact that documents are translated into the six UN languages before th= ey are formally approved (and some discussions takes place with interpretat= ion in six languages).=

 

If the intent is to develop tools t= hat would be used only in the USA at first, then I would suggest that it wo= uld be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the pu= rpose. If the US experience proved successful, then the tools could be prop= osed for adoption elsewhere, for example through ITU-T.

 

If the intent is to develop tools f= or use in many countries right at the start, then I would suggest that the = appropriate forum would be ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the crea= tion of this new working group, and this even if the Charter is modified as= suggested below.

 

Please see additional comments inli= ne.

 

Thanks and best,

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

This effort is intended to create tools and = solutions to enable flexibility in the process of managing numbers among na= tional administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for h= ow national administrators interact with the ITU-T.  But of course we = want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <ali= ssa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people=92s thoughts on whet= her any charter edits may be warranted in response to these comments, and/o= r whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:




From: "Zhang, Jie" <jie.zhang@itu.int>=

Subject: RE: [new-work] WG Review: Mana= ging, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

To: "iesg@ietf.org" <iesg@ietf.org><= span style=3D"color:black">

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.164.1= .

 

>RH: Given the scope of the work= , I think that it is too early to say whether there would be an impact. Tho= se Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, = with the recognition of course that the changes would have to be proposed t= o ITI-T Study Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes withi= n countries is subject to regulation.  The WG cannot make any decision= s with regard to this.  I expect the WG to define "roles" within the number management processes; e.g.= , administrator, telecom carrier, application provider, consumer,= etc.; and how those roles could interact with each other.  This will = be a baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject = to, or affect, national regulations.  That is, the definition of a =93= role=94 may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions to be able = to address the status of a telephone number.

 

>RH: Since the terms =93assigned= =94, =93spare=94 and =93reclaimed=94 are defined in ITU-T Recommendations (= albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".<= /p>

We are aware of Resolution 133 and will certainly respect it. &n= bsp;I would propose adding the following text after the first sentence= in the last full paragraph =96 "The group acknowledges = ;ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  =

 

>RH: That certainly would be a h= elpful addition. In addition to the above, I would suggest adding =93The gr= oup=92s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1= , E.190 and the Recommendations referenced therein.=94 

 

>RH: For the sake of clarity I r= eiterate that I oppose the creation of this group even if the Charter is mo= dified to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace that= would require regulatory oversight, e.g., a new TLD, SLD, etc.  = I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say = anything specific about that.  There is nothing in the charter that re= ferences .tel.  <= /p>


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify that = sentence to add the following at the end - "as well as other rele= vant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG names= .  : )  But the charter is where to look for the scope of work. &= nbsp;The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information =85 with TNs", "associating, ac= quiring and resolving TNs", "access data related to&nbs= p;TNs", and "mechanisms for resolving information related to = ;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work<= /o:p>

 

 



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_D1B2D27A154820jonpetersonneustarbiz_-- --_004_D1B2D27A154820jonpetersonneustarbiz_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=5171; creation-date="Fri, 26 Jun 2015 16:59:52 GMT"; modification-date="Fri, 26 Jun 2015 16:59:52 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_D1B2D27A154820jonpetersonneustarbiz_-- From nobody Fri Jun 26 10:02: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 DFA291A8978 for ; Fri, 26 Jun 2015 10:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 pT8VBcu5a7Jz for ; Fri, 26 Jun 2015 10:02:37 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 434111A8945 for ; Fri, 26 Jun 2015 10:02:37 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QH2YoK010395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 19:02:34 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QH2XwB001113; Fri, 26 Jun 2015 19:02:33 +0200 From: "Richard Hill" To: "'Peterson, Jon'" , "'Gorman, Pierce A [CTO]'" , "'McGarry, Tom'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: Date: Fri, 26 Jun 2015 19:02:33 +0200 Message-ID: <005e01d0b031$e5b513c0$b11f3b40$@ch> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_005F_01D0B042.A93DE3C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugIAAeyuA//+L6YCAADLG0A== Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:02:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01D0B042.A93DE3C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0060_01D0B042.A93DE3C0" ------=_NextPart_001_0060_01D0B042.A93DE3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A "VoIP service provider who wants to receive a block of new numbers through a delegation from a carrier" might well be subject to national regulation, so the national regulator might well be involved in that use case. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Friday, June 26, 2015 19:00 To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) One would be an enterprise IP phone that has just been deployed and wants to acquire a new number from an IP PBX. Another would be a VoIP service provider who wants to receive a block of new numbers through a delegation from a carrier. I ran through such use cases at the MODERN BoF. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" Date: Friday, June 26, 2015 at 9:55 AM To: Jon Peterson , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) "Many use cases under consideration would not have a national regulator as an actor." - J. Peterson I've struggled with this point. What are the "many" use cases? For example, I've not been able to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number. What is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol tools to manage telephone numbers? What is broken about the existing system(s)? And I really struggle with how this is supposed to work because there are so many different kinds of telephone numbers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs, IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG, SMS800, et cetera. And the administration is distributed (in the US) at national and state levels. Has anyone from any of the US or international number management administrative organizations requested that the IETF build tools for them? If they don't use them, who will? And how can they integrate with an existing system? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com cid:408000_086801428601145001@pvmxe13g01 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource on which the IETF does protocol work - like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are responsible for ccTLDs, surely the IETF is not a suitable body for managing the DNS! And it isn't. But it is a suitable body for managing the protocol work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sorts of things you are worrying about here. The IETF just produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is simply an error. All work at the IETF is done by a coalition of the willing. If it turns out that the coalition is not representative of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly be harmed by that, even if the failed work involved ways of talking about telephone numbers. This makes the IETF really different from places like the ITU, where the products of work have some binding effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwilling. People who aren't interested, or who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agree that if this proposed work required regulatory oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol tools developed in the IETF and conduct an experiment with various carriers to see if it works for that interest group or not, and that would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" to literally use the tools proposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part instigated by an FCC workshop, yes, and someone associated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy this work - surely they would leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" , "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by national regulators, presumably they should be involved in the development of the tools. As far as I know, national regulators from most countries don't normally participate in the IETF, for a number of reasons, including the IETF's decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU's decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at first, then I would suggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If the US experience proved successful, then the tools could be proposed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the start, then I would suggest that the appropriate forum would be ITU-T, not IETF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers. Entities can choose to use these tools or not. These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T. But of course we want your input and feedback, so thanks for sending this along. More comments in line below. From: Alissa Cooper Date: Thursday, June 25, 2015 7:44 AM To: Modern List Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say whether there would be an impact. Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recognition of course that the changes would have to be proposed to ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regulation. The WG cannot make any decisions with regard to this. I expect the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other. This will be a baseline for what tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That is, the definition of a "role" may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a telephone number. >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU-T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used". We are aware of Resolution 133 and will certainly respect it. I would propose adding the following text after the first sentence in the last full paragraph - "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, I would suggest adding "The group's outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein." >RH: For the sake of clarity I reiterate that I oppose the creation of this group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions. But it's too early to say anything specific about that. There is nothing in the charter that references .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "as well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent. The IETF often has fun with creating WG names. : ) But the charter is where to look for the scope of work. The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information . with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs". The functions you believe were left out of the charter will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _____ 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. ------=_NextPart_001_0060_01D0B042.A93DE3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A “VoIP service provider who wants to receive a block of new = numbers through a delegation from a carrier” might well be subject = to national regulation, so the national regulator might well be involved = in that use case.


Best,

Richard

 

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, = Jon
Sent: Friday, June 26, 2015 19:00
To: Gorman, = Pierce A [CTO]; Richard Hill; McGarry, Tom; = modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)

 

=  

= One would be an enterprise IP phone that has just been deployed and = wants to acquire a new number from an IP PBX. Another would be a VoIP = service provider who wants to receive a block of new numbers through a = delegation from a carrier. I ran through such use cases at the MODERN = BoF.

=  

= Jon Peterson

= Neustar, Inc.

=  

From: <Gorman>, "Pierce A [CTO]" <Pierce.Gorman@sprint.com>=
Date: Friday, June 26, 2015 at 9:55 AM
To: Jon = Peterson <jon.peterson@neustar.biz>= , Richard Hill <rhill@hill-a.ch>, "McGarry, = Tom" <Tom.McGarry@neustar.biz>, = "modern@ietf.org" = <modern@ietf.org>
Subject: = RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

=  

“Many use cases under consideration would not have a national regulator = as an actor.”  - J. Peterson

 

I’ve struggled with this point.  What are the = “many” use cases?  For example, I’ve not been = able to envision the use case that would require a device to use a = MODERN protocol tool to acquire an RFC 3966 telephone number.  What = is this use case?

 

This continues to baffle me.  Why is the IETF proposing to develop = protocol tools to manage telephone numbers?  What is broken about = the existing system(s)?

 

And I really struggle with how this is supposed to work because there = are so many different kinds of telephone numbers such as service numbers = (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline = numbers, TLDNs, IMRNs, ported numbers, and multiple administrative = databases, NPAC, LERG, SMS800, et cetera.

 

And the administration is distributed (in the US) at national and state = levels.

 

Has anyone from any of the US or international number management = administrative organizations requested that the IETF build tools for = them?  If they don’t use them, who will?  And how can = they integrate with an existing system?  Sorry Jon.  Still = lost.

 

 

Pierce Gorman

= Core Network Planning

= O: 913-439-4368

= pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 = AM
To: Richard Hill; McGarry, Tom; modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

 

Your arguments here could equally well be applied to any important = resource on which the IETF does protocol work - like, say, the DNS. The = IETF manages the DNS protocol and publishes RFCs about it. But since = national authorities are responsible for ccTLDs, surely the IETF is not = a suitable body for managing the DNS! And it isn't. But it is a suitable = body for managing the protocol work on the DNS. Other, effectively = unrelated entities handle the administrative dimensions of operating the = DNS, and yes, at those bodies there are lots of national regulators and = they worry about the sorts of things you are worrying about here. The = IETF just produces tools, and that is all MODERN proposes to do. Trying = to characterize this effort otherwise is simply an error.

 

All work at the IETF is done by a coalition of the willing. If it turns = out that the coalition is not representative of the needs of the = community, then what happens? Well, the work built here doesn't get = used. The only people who wasted any time or effort were the members of = that coalition. No national interests can possibly be harmed by that, = even if the failed work involved ways of talking about telephone = numbers. This makes the IETF really different from places like the ITU, = where the products of work have some binding effect on the = world.

 

Virtually all proposed work at the IETF also faces a coalition of the = unwilling. People who aren't interested, or who think the work should be = done elsewhere, or that the work simply shouldn't be done at all. But I = maintain your "formal objection" treats the scope of the = proposed work as being different than it is, and I'd agree that if this = proposed work required regulatory oversight, that the IETF shouldn't do = it. But we're just building some protocol tools. There is also related = work here for ATIS to do, and I'm sure ATIS or some other body could = later take some the protocol tools developed in the IETF and conduct an = experiment with various carriers to see if it works for that interest = group or not, and that would be interesting information. But the IETF = doesn't do that part, and doesn't aspire to do that part.

 

Finally, I'm not really sure how much I would expect "national = regulators" to literally use the tools proposed in this work. They = are tools for the use of a diverse industry of enterprises, carriers, = end users, and so on. Many use cases under consideration would not have = a national regulator as an actor. This work was in part instigated by an = FCC workshop, yes, and someone associated with the FCC spoke at the = MODERN BoF. But I don't anticipate that the FCC would be propping up = servers to deploy this work - surely they would leave that to = industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@hill-a.ch>
Date: = Friday, June 26, 2015 at 8:09 AM
To: "McGarry, = Tom" <Tom.McGarry@neustar.biz>, = "modern@ietf.org" = <modern@ietf.org>
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Thank you for this clarification.

 

Since the intent is to create tools and solutions that would be used = by national regulators, presumably they should be involved in the = development of the tools. 


As far as I know, national regulators from most countries = don’t normally participate in the IETF, for a number of reasons, = including the IETF’s decision-making process and the fact that the = IETF works in English. National regulators do participate in ITU-T, for = a number of reasons, including the ITU’s decision-making process = and the fact that documents are translated into the six UN languages = before they are formally approved (and some discussions takes place with = interpretation in six languages).

 

If the intent is to develop tools that would be used only in the USA = at first, then I would suggest that it would be more appropriate to = develop them in a forum such as ATIS or an ad-hoc group created = specifically for the purpose. If the US experience proved successful, = then the tools could be proposed for adoption elsewhere, for example = through ITU-T.

 

If the intent is to develop tools for use in many countries right at = the start, then I would suggest that the appropriate forum would be = ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the creation of this new working group, = and this even if the Charter is modified as suggested below.

 

Please see additional comments inline.

 

Thanks and best,

Richard

 

= From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin = 2015 00:31
To: modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

 

This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. =  Entities can choose to use these tools or not.  These tools = are not for the ITU-T's processes or role, nor for how national = administrators interact with the ITU-T.  But of course we want your = input and feedback, so thanks for sending this along.  More = comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: = Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: = [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Would appreciate people’s thoughts on whether any charter edits = may be warranted in response to these comments, and/or whether a = separate response may be useful for addressing some of the questions = below.

 

Alissa

 

Begin forwarded message:





From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU = Telecommunication Standardization Bureau on the proposed IETF working = group MODERN.

1. Potential = impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated = at the beginning of the Charter that 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. And it is = mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to = here only deals with Tel URI? Would there be any impact on = Recommendation ITU-E E.164 and E.164.1 which are core recommendations on = Telephone Numbers?

= There will be no impacts on E.164 and E.164.1.

 

>RH: Given the scope of the work, I think that it is too early to = say whether there would be an impact. Those Recommendations are = regularly updated, in particular E.164.1, so there is nothing wrong with = envisaging changes, with the recognition of course that the changes = would have to be proposed to ITI-T Study Group 2 and agreed by that = group.


2. Entities participating in = the defined mechanisms
The Charter states that the protocol mechanism = for resolving TNs will allow entities such as service providers, = devices, and applications to access data related to TNs. But it is not = clear what kind of entities can participate in the mechanisms defined by = this MODERN working group. Would it be restricted to the entities who = have been assigned a TN or a block of TNS?

= Who participates in numbering processes within countries is subject to = regulation.  The WG cannot make any decisions with regard to this. =  I expect the WG to define "roles" within the number = management processes; e.g., administrator, telecom = carrier, application provider, consumer, etc.; and how those = roles could interact with each other.  This will be = a baseline for what tools and solutions would be useful to = facilitate those interactions.  

 

>RH: Even that might be subject to, or affect, national = regulations.  That is, the definition of a “role” may = well depend on national regulations.


3. Status of Telephone numbers = in the defined mechanisms
Several operations related to TNs are = mentioned in the Charter, including requesting, acquiring, resolving and = associating. It is also stated that the protocol mechanism for acquiring = TNs will provide an enrollment process for the entities that use and = manage TNs. Does that mean Telephone numbers with various status, such = as assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working group?

I=  would expect proposed solutions to be able to address the status = of a telephone number.

 

>RH: Since the terms “assigned”, “spare” = and “reclaimed” are defined in ITU-T Recommendations (albeit = sometimes implicitly), addressing the status of a telephone number might = well impact E.164 or E.164.1.


4. Regulatory issues
The = Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact = that the E.164 international public telecommunication numbering plan is = a politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of = ITU Member States with respect to allocation and management of their = country code numbering resources as enshrined in Recommendation ITU-T = E.164", and further instructed the ITU Secretary-General and the = Directors of three Bureaux (Telecommunication Standardization, = Development, and Radiocommunication) to "take any necessary action = to ensure the sovereignty of ITU Member States with regard to = Recommendation ITU-T E.164 numbering plans whatever the application in = which they are used".

We are aware of = Resolution 133 and will certainly respect it.  I would propose = adding the following text after the first sentence in the last full = paragraph – "The group acknowledges ITU = Plenipotentiary Conference Resolution 133 which recognizes the existing = role and sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined = in Recommendation ITU-T E.164."  

 

>RH: That certainly would be a helpful addition. In addition to = the above, I would suggest adding “The group’s outputs would = be consistent with the provisions of relevant ITU-T Recommendations, in = particular E.164, E.164.1, E.190 and the Recommendations referenced = therein.” 

 

>RH: For the sake of clarity I reiterate that I oppose the = creation of this group even if the Charter is modified to include the = text above.

 


5. Relationship with = .Tel
DNS-based use of international numbering resources has been = discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 = September 2013. TSB Director has also exchanged letters with ICANN on = issues related to registering digit strings in the .TEL domain. A = representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A = correspondence group under ITU-T SG2 was also set up in this regard. We = would like to know how the work of this new WG would relate to issues = related to registering digit strings in the .TEL domain and other = DNS-based use of telephone numbers.

= The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule = out the WG leveraging existing namespaces as part of proposed = solutions.  But it's too early to say anything specific about that. =  There is nothing in the charter that references .tel. =  


6. Relationship with related = existing or concluded WGs
It is stated in the Charter that the = working group will take into consideration existing IETF work including = STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the = relationship between this new WG and the above mentioned other existing = or concluded WGs would be appreciated.

= I agree.  I would modify that sentence to add the = following at the end - "as well as = other relevant industry and standards = organizations."


7. The name of this new = WG
The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the = Charter, ordering, exposing and registering TNs are not mentioned, which = seems to be a little bit inconsistent.

= The IETF often has fun with creating WG names.  : )  But the = charter is where to look for the scope of work.  The charter uses = the following phrases "distribution, acquisition and management = of TNs", "functions involved in associating = information … with TNs", "associating, = acquiring and resolving TNs", "access data related = to TNs", and "mechanisms for resolving information = related to TNs".  The functions you believe were left out = of the charter will be part of one or more of these processes. =  



Best regards,

Jie Zhang
Advisor, ITU-T = SG2
International Telecommunication Union
Place des = Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 = 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Origina= l Message-----
From: new-work [mailto:new-work-bounces@ietf.or= g] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 = PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz> Steve Donovan <srdonovan@usdonovans.com>=

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailin= g list
 Address: modern@ietf.org
 To = Subscribe: https://www.ietf.or= g/mailman/listinfo/modern
 Archive: http://www.ietf.org= /mail-archive/web/modern/

Charter:

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. = Devices, applications, and network tools increasingly need to manage = TNs, including requesting and acquiring TN delegations from authorities. = The output of the working group should make distribution, acquisition, = and management of TNs simpler for all entities involved.

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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs. 

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, and security = and privacy for both the data and the protocol interactions are primary = considerations. The working group will take into consideration existing = IETF work including STIR, 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. 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 for TN assignment and management, for = example those established by different regulatory agencies.

The = working 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

Milestones:

TBD

________________________________= _______________
new-work mailing list
new-work@ietf.org
https://www.ietf.= org/mailman/listinfo/new-work

 

 

=  

=

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

------=_NextPart_001_0060_01D0B042.A93DE3C0-- ------=_NextPart_000_005F_01D0B042.A93DE3C0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: 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= ------=_NextPart_000_005F_01D0B042.A93DE3C0-- From nobody Fri Jun 26 10:11:40 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCFC1A897F for ; Fri, 26 Jun 2015 10:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 0cjiHcSa8bLh for ; Fri, 26 Jun 2015 10:11:30 -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 B38D61A897B for ; Fri, 26 Jun 2015 10:11:29 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t5QHAZsx005227; Fri, 26 Jun 2015 13:11:25 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1v8ytvgs9f-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 13:11:25 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.54]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 13:11:23 -0400 From: "McGarry, Tom" To: Richard Hill , "Peterson, Jon" , "'Gorman, Pierce A [CTO]'" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEB/Zz98yjqU+KL6VWQx+3vZ29zs4AgAERc1CAAGBKAIAABc6AgAABRgCAAAC/gP//v2cA Date: Fri, 26 Jun 2015 17:11:22 +0000 Message-ID: In-Reply-To: <005e01d0b031$e5b513c0$b11f3b40$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.168.132.65] Content-Type: multipart/mixed; boundary="_004_D1B2FF4C27BFFtommcgarryneustarbiz_" 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-06-26_06:2015-06-26,2015-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506260248 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:11:37 -0000 --_004_D1B2FF4C27BFFtommcgarryneustarbiz_ Content-Type: multipart/alternative; boundary="_000_D1B2FF4C27BFFtommcgarryneustarbiz_" --_000_D1B2FF4C27BFFtommcgarryneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable They most likely would be involved in deciding whether that use case can ha= ppen (one entity delegating numbers to another), but it is unlikely they wo= uld be involved in the actual interaction. Even if there are cases where t= hey would, there are certainly cases where they wouldn't. This is why the = solutions need to be flexible enough to account for different policies. From: Richard Hill > Date: Friday, June 26, 2015 1:02 PM To: Jon Peterson = >, Pierce Gorman = >, Tom Mcgarry >, M= odern List > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) A =93VoIP service provider who wants to receive a block of new numbers thro= ugh a delegation from a carrier=94 might well be subject to national regula= tion, so the national regulator might well be involved in that use case. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Friday, June 26, 2015 19:00 To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) One would be an enterprise IP phone that has just been deployed and wants t= o acquire a new number from an IP PBX. Another would be a VoIP service prov= ider who wants to receive a block of new numbers through a delegation from = a carrier. I ran through such use cases at the MODERN BoF. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" > Date: Friday, June 26, 2015 at 9:55 AM To: Jon Peterson = >, Richard Hill >, "McGarry, Tom" <= Tom.McGarry@neustar.biz>, "modern@ietf.org<= mailto:modern@ietf.org>" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) =93Many use cases under consideration would not have a national regulator a= s an actor.=94 - J. Peterson I=92ve struggled with this point. What are the =93many=94 use cases? For = example, I=92ve not been able to envision the use case that would require a= device to use a MODERN protocol tool to acquire an RFC 3966 telephone numb= er. What is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol= tools to manage telephone numbers? What is broken about the existing syst= em(s)? And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., = 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,= SMS800, et cetera. And the administration is distributed (in the US) at national and state lev= els. Has anyone from any of the US or international number management administra= tive organizations requested that the IETF build tools for them? If they d= on=92t use them, who will? And how can they integrate with an existing sys= tem? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, surely the IETF is not a suitable body for = managing the DNS! And it isn't. But it is a suitable body for managing the = protocol work on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies th= ere are lots of national regulators and they worry about the sorts of thing= s you are worrying about here. The IETF just produces tools, and that is al= l MODERN proposes to do. Trying to characterize this effort otherwise is si= mply an error. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. This makes the IETF really di= fferent from places like the ITU, where the products of work have some bind= ing effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. But we're just building some p= rotocol tools. There is also related work here for ATIS to do, and I'm sure= ATIS or some other body could later take some the protocol tools developed= in the IETF and conduct an experiment with various carriers to see if it w= orks for that interest group or not, and that would be interesting informat= ion. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the= ITU=92s decision-making process and the fact that documents are translated= into the six UN languages before they are formally approved (and some disc= ussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =93role=94 may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 are de= fined in ITU-T Recommendations (albeit sometimes implicitly), addressing th= e status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =93The group=92s outputs would be consistent with th= e provisions of relevant ITU-T Recommendations, in particular E.164, E.164.= 1, E.190 and the Recommendations referenced therein.=94 >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ________________________________ 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_D1B2FF4C27BFFtommcgarryneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
They most likely would be involved in deciding whether that use case c= an happen (one entity delegating numbers to another), but it is unlikely th= ey would be involved in the actual interaction.  Even if there are cas= es where they would, there are certainly cases where they wouldn't.  This is why the solutions need to be flex= ible enough to account for different policies.  

From: Richard Hill <rhill@hill-a.ch>
Date: Friday, June 26, 2015 1:02 PM=
To: Jon Peterson <jon.peterson@neustar.biz>, Pierce Gorm= an <Pierce.Gorman@sprint.com= >, Tom Mcgarry <tom.mc= garry@neustar.biz>, Modern List <modern@ietf.org>=
Subject: RE: [Modern] Fwd: [new-wor= k] WG Review: Managing, Ordering, Distributing, Exposing, & Registering= telephone Numbers (modern)

A =93VoIP service provider who wan= ts to receive a block of new numbers through a delegation from a carrier=94= might well be subject to national regulation, so the national regulator might well be involved in that use case.


Best,

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Friday, June 26, 2015 19:00
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

One would be an enterprise IP phone that has= just been deployed and wants to acquire a new number from an IP PBX. Anoth= er would be a VoIP service provider who wants to receive a block of new numbers through a delegation from a ca= rrier. I ran through such use cases at the MODERN BoF.

 

Jon Peterson

Neustar, Inc.

 

From: <Gorman>, "Pierce A [CTO]" <Pierce.Gorman@sprint.com>
Date: Friday, June 26, 2015 at 9:55 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Richard Hill <rhill@hill-a.ch>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

=93Many use cases unde= r consideration would not have a national regulator as an actor.=94  - J. Peterson<= span style=3D"color:black">

 

I=92ve struggled with this point. = ; What are the =93many=94 use cases?  For example, I=92ve not been abl= e to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number.&nbs= p; What is this use case?

 

This continues to baffle me.  Why= is the IETF proposing to develop protocol tools to manage telephone number= s?  What is broken about the existing system(s)?

 

And I really struggle with how this is= supposed to work because there are so many different kinds of telephone nu= mbers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDN= s, IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG= , SMS800, et cetera.

 

And the administration is distributed = (in the US) at national and state levels.

 

Has anyone from any of the US or inter= national number management administrative organizations requested that the = IETF build tools for them?  If they don=92t use them, who will?  And how can they integrate with an exist= ing system?  Sorry Jon.  Still lost.

 

 

Pierce= Gorman

Core Netwo= rk Planning

O: 913-439= -4368

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g=

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; m= odern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

Your arguments here could equally well be a= pplied to any important resource on which the IETF does protocol work - lik= e, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities a= re responsible for ccTLDs, surely the IETF is not a suitable body for manag= ing the DNS! And it isn't. But it is a suitable body for managing the proto= col work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the D= NS, and yes, at those bodies there are lots of national regulators and they= worry about the sorts of things you are worrying about here. The IETF just= produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is sim= ply an error.

 

All work at the IETF is done by a coalition= of the willing. If it turns out that the coalition is not representative o= f the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who w= asted any time or effort were the members of that coalition. No national in= terests can possibly be harmed by that, even if the failed work involved wa= ys of talking about telephone numbers. This makes the IETF really different from places like the ITU, where the p= roducts of work have some binding effect on the world.

 

Virtually all proposed work at the IETF als= o faces a coalition of the unwilling. People who aren't interested, or who = think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your &quo= t;formal objection" treats the scope of the proposed work as being dif= ferent than it is, and I'd agree that if this proposed work required regula= tory oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related wor= k here for ATIS to do, and I'm sure ATIS or some other body could later tak= e some the protocol tools developed in the IETF and conduct an experiment w= ith various carriers to see if it works for that interest group or not, and that would be interesting inform= ation. But the IETF doesn't do that part, and doesn't aspire to do that par= t.

 

Finally, I'm not really sure how much I wou= ld expect "national regulators" to literally use the tools propos= ed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many us= e cases under consideration would not have a national regulator as an actor= . This work was in part instigated by an FCC workshop, yes, and someone ass= ociated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up serve= rs to deploy this work - surely they would leave that to industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill= @hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <mod= ern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 

Thank you for this clarification.<= /span>

 

Since the intent is to create tool= s and solutions that would be used by national regulators, presumably they = should be involved in the development of the tools.  <= /p>


As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the ITU=92s decision-making process and= the fact that documents are translated into the six UN languages before th= ey are formally approved (and some discussions takes place with interpretat= ion in six languages).=

 

If the intent is to develop tools = that would be used only in the USA at first, then I would suggest that it w= ould be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for t= he purpose. If the US experience proved successful, then the tools could be= proposed for adoption elsewhere, for example through ITU-T.

 

If the intent is to develop tools = for use in many countries right at the start, then I would suggest that the= appropriate forum would be ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the cre= ation of this new working group, and this even if the Charter is modified a= s suggested below.

 

Please see additional comments inl= ine.

 

Thanks and best,

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

This effort is intended to create tools and= solutions to enable flexibility in the process of managing numbers among n= ational administrators, service and application providers, and consumers.  Entities can choose to use the= se tools or not.  These tools are not for the ITU-T's processes or rol= e, nor for how national administrators interact with the ITU-T.  But o= f course we want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <al= issa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people=92s thoughts on whe= ther any charter edits may be warranted in response to these comments, and/= or whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:





From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Man= aging, Ordering, Distributing, Exposing, & Registering telephone Number= s (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.164.= 1.

 

>RH: Given the scope of the wor= k, I think that it is too early to say whether there would be an impact. Th= ose Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, = with the recognition of course that the changes would have to be proposed t= o ITI-T Study Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes with= in countries is subject to regulation.  The WG cannot make any decisio= ns with regard to this.  I expect the WG to define "roles" within the number management processes; e= .g., administrator, telecom carrier, application provider, consum= er, etc.; and how those roles could interact with each other.  This wi= ll be a baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject= to, or affect, national regulations.  That is, the definition of a = =93role=94 may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions to be abl= e to address the status of a telephone number.

 

>RH: Since the terms =93assigne= d=94, =93spare=94 and =93reclaimed=94 are defined in ITU-T Recommendations = (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".<= /p>

We are aware of Resolution 133 and will certainly respect it. &= nbsp;I would propose adding the following text after the first sentenc= e in the last full paragraph =96 "The group acknowledges&nbs= p;ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  =

 

>RH: That certainly would be a = helpful addition. In addition to the above, I would suggest adding =93The g= roup=92s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1= , E.190 and the Recommendations referenced therein.=94 

 

>RH: For the sake of clarity I = reiterate that I oppose the creation of this group even if the Charter is m= odified to include the text above.<= /o:p>

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace tha= t would require regulatory oversight, e.g., a new TLD, SLD, etc.  = ;I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say = anything specific about that.  There is nothing in the charter that re= ferences .tel.  <= /p>


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify that= sentence to add the following at the end - "as well as other rel= evant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG name= s.  : )  But the charter is where to look for the scope of work. =  The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information =85 with TNs", "associating, ac= quiring and resolving TNs", "access data related to&nbs= p;TNs", and "mechanisms for resolving information related to = ;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int=
www.itu1= 50.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/list= info/modern
 Archive: http://www.ietf.org/mail-archive/web= /modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

 

 

 


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_D1B2FF4C27BFFtommcgarryneustarbiz_-- --_004_D1B2FF4C27BFFtommcgarryneustarbiz_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=5171; creation-date="Fri, 26 Jun 2015 17:11:22 GMT"; modification-date="Fri, 26 Jun 2015 17:11:22 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_D1B2FF4C27BFFtommcgarryneustarbiz_-- From nobody Fri Jun 26 10:12: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 32E251A88DC for ; Fri, 26 Jun 2015 10:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 50-o3PeNESDN for ; Fri, 26 Jun 2015 10:12:04 -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 DE6131A897B for ; Fri, 26 Jun 2015 10:12:04 -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 t5QH4W9T013549; Fri, 26 Jun 2015 13:12:01 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1v97d9ra5x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 13:12:00 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 13:11:57 -0400 From: "Peterson, Jon" To: Richard Hill , "'Gorman, Pierce A [CTO]'" , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugIAAeyuA//+L6YCAADLG0P//0JyA Date: Fri, 26 Jun 2015 17:11:57 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <005e01d0b031$e5b513c0$b11f3b40$@ch> In-Reply-To: <005e01d0b031$e5b513c0$b11f3b40$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.179] Content-Type: multipart/mixed; boundary="_004_D1B2D412154839jonpetersonneustarbiz_" 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-06-26_06:2015-06-26,2015-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506260248 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:12:12 -0000 --_004_D1B2D412154839jonpetersonneustarbiz_ Content-Type: multipart/alternative; boundary="_000_D1B2D412154839jonpetersonneustarbiz_" --_000_D1B2D412154839jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A lot hinges on how you understand involvement there. Surely a regulator co= uld set policies that determine if and how a carrier delegates numbers, say= . There may be environments where a carrier could not delegate numbers in t= he fashion I described. And perhaps if MODERN designed a flow that worked t= hat way, that particular flow wold not be relevant to an environment where = regulatory policy disallowed it. Whether or not that makes the regulator an= "actor" in the protocol flow is a semantic question. I wouldn't think so. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 10:02 AM To: Jon Peterson = >, "'Gorman, Pierce A [CTO]'" >, "McGarry, Tom" >, "modern@ietf.org" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) A =93VoIP service provider who wants to receive a block of new numbers thro= ugh a delegation from a carrier=94 might well be subject to national regula= tion, so the national regulator might well be involved in that use case. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Friday, June 26, 2015 19:00 To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) One would be an enterprise IP phone that has just been deployed and wants t= o acquire a new number from an IP PBX. Another would be a VoIP service prov= ider who wants to receive a block of new numbers through a delegation from = a carrier. I ran through such use cases at the MODERN BoF. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" > Date: Friday, June 26, 2015 at 9:55 AM To: Jon Peterson = >, Richard Hill >, "McGarry, Tom" <= Tom.McGarry@neustar.biz>, "modern@ietf.org<= mailto:modern@ietf.org>" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) =93Many use cases under consideration would not have a national regulator a= s an actor.=94 - J. Peterson I=92ve struggled with this point. What are the =93many=94 use cases? For = example, I=92ve not been able to envision the use case that would require a= device to use a MODERN protocol tool to acquire an RFC 3966 telephone numb= er. What is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol= tools to manage telephone numbers? What is broken about the existing syst= em(s)? And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., = 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,= SMS800, et cetera. And the administration is distributed (in the US) at national and state lev= els. Has anyone from any of the US or international number management administra= tive organizations requested that the IETF build tools for them? If they d= on=92t use them, who will? And how can they integrate with an existing sys= tem? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, surely the IETF is not a suitable body for = managing the DNS! And it isn't. But it is a suitable body for managing the = protocol work on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies th= ere are lots of national regulators and they worry about the sorts of thing= s you are worrying about here. The IETF just produces tools, and that is al= l MODERN proposes to do. Trying to characterize this effort otherwise is si= mply an error. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. This makes the IETF really di= fferent from places like the ITU, where the products of work have some bind= ing effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. But we're just building some p= rotocol tools. There is also related work here for ATIS to do, and I'm sure= ATIS or some other body could later take some the protocol tools developed= in the IETF and conduct an experiment with various carriers to see if it w= orks for that interest group or not, and that would be interesting informat= ion. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the= ITU=92s decision-making process and the fact that documents are translated= into the six UN languages before they are formally approved (and some disc= ussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =93role=94 may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 are de= fined in ITU-T Recommendations (albeit sometimes implicitly), addressing th= e status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =93The group=92s outputs would be consistent with th= e provisions of relevant ITU-T Recommendations, in particular E.164, E.164.= 1, E.190 and the Recommendations referenced therein.=94 >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ________________________________ 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_D1B2D412154839jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

A lot hinges on how you understand involvement there. Surely a regulat= or could set policies that determine if and how a carrier delegates numbers= , say. There may be environments where a carrier could not delegate numbers= in the fashion I described. And perhaps if MODERN designed a flow that worked that way, that particular fl= ow wold not be relevant to an environment where regulatory policy disallowe= d it. Whether or not that makes the regulator an "actor" in the p= rotocol flow is a semantic question. I wouldn't think so.

Jon Peterson
Neustar, Inc.

From: Richard Hill <rhill@hill-a.ch>
Date: Friday, June 26, 2015 at 10:0= 2 AM
To: Jon Peterson <jon.peterson@neustar.biz>, "'Gorm= an, Pierce A [CTO]'" <P= ierce.Gorman@sprint.com>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-wor= k] WG Review: Managing, Ordering, Distributing, Exposing, & Registering= telephone Numbers (modern)

A =93VoIP service provider who want= s to receive a block of new numbers through a delegation from a carrier=94 = might well be subject to national regulation, so the national regulator might well be involved in that use case.


Best,

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Friday, June 26, 2015 19:00
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

One would be an enterprise IP phone that has = just been deployed and wants to acquire a new number from an IP PBX. Anothe= r would be a VoIP service provider who wants to receive a block of new numbers through a delegation from a carrie= r. I ran through such use cases at the MODERN BoF.

 

Jon Peterson

Neustar, Inc.

 

From: <Gorman>, "Pierce A [CTO]" <Pierce.Gorman@sprint.com>
Date: Friday, June 26, 2015 at 9:55 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Richard Hill <rhill@hill-a.ch>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

=93Many use cases under = consideration would not have a national regulator as an actor.=94  - J. Peterson

 

I=92ve struggled with this point. = What are the =93many=94 use cases?  For example, I=92ve not been able= to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number.&nbs= p; What is this use case?

 

This continues to baffle me.  Why = is the IETF proposing to develop protocol tools to manage telephone numbers= ?  What is broken about the existing system(s)?

 

And I really struggle with how this is = supposed to work because there are so many different kinds of telephone num= bers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDN= s, IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG= , SMS800, et cetera.

 

And the administration is distributed (= in the US) at national and state levels.=

 

Has anyone from any of the US or intern= ational number management administrative organizations requested that the I= ETF build tools for them?  If they don=92t use them, who will?  And how can they integrate with an existing syst= em?  Sorry Jon.  Still lost.

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g0=

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; m= odern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

Your arguments here could equally well be ap= plied to any important resource on which the IETF does protocol work - like= , say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities a= re responsible for ccTLDs, surely the IETF is not a suitable body for manag= ing the DNS! And it isn't. But it is a suitable body for managing the proto= col work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the D= NS, and yes, at those bodies there are lots of national regulators and they= worry about the sorts of things you are worrying about here. The IETF just= produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is sim= ply an error.

 

All work at the IETF is done by a coalition = of the willing. If it turns out that the coalition is not representative of= the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who w= asted any time or effort were the members of that coalition. No national in= terests can possibly be harmed by that, even if the failed work involved wa= ys of talking about telephone numbers. This makes the IETF really different from places like the ITU, where the p= roducts of work have some binding effect on the world.

 

Virtually all proposed work at the IETF also= faces a coalition of the unwilling. People who aren't interested, or who t= hink the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your &quo= t;formal objection" treats the scope of the proposed work as being dif= ferent than it is, and I'd agree that if this proposed work required regula= tory oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related wor= k here for ATIS to do, and I'm sure ATIS or some other body could later tak= e some the protocol tools developed in the IETF and conduct an experiment w= ith various carriers to see if it works for that interest group or not, and that would be interesting inform= ation. But the IETF doesn't do that part, and doesn't aspire to do that par= t.

 

Finally, I'm not really sure how much I woul= d expect "national regulators" to literally use the tools propose= d in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many us= e cases under consideration would not have a national regulator as an actor= . This work was in part instigated by an FCC workshop, yes, and someone ass= ociated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up serve= rs to deploy this work - surely they would leave that to industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@= hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <mod= ern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 

Thank you for this clarification.

 

Since the intent is to create tools= and solutions that would be used by national regulators, presumably they s= hould be involved in the development of the tools.  <= /p>


As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the ITU=92s decision-making process and= the fact that documents are translated into the six UN languages before th= ey are formally approved (and some discussions takes place with interpretat= ion in six languages).=

 

If the intent is to develop tools t= hat would be used only in the USA at first, then I would suggest that it wo= uld be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the pu= rpose. If the US experience proved successful, then the tools could be prop= osed for adoption elsewhere, for example through ITU-T.

 

If the intent is to develop tools f= or use in many countries right at the start, then I would suggest that the = appropriate forum would be ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the crea= tion of this new working group, and this even if the Charter is modified as= suggested below.

 

Please see additional comments inli= ne.

 

Thanks and best,

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

This effort is intended to create tools and = solutions to enable flexibility in the process of managing numbers among na= tional administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for h= ow national administrators interact with the ITU-T.  But of course we = want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <ali= ssa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people=92s thoughts on whet= her any charter edits may be warranted in response to these comments, and/o= r whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:





From: "Zhang, Jie" <jie.zhang@itu.int>=

Subject: RE: [new-work] WG Review: Mana= ging, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

To: "iesg@ietf.org" <iesg@ietf.org><= span style=3D"color:black">

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.164.1= .

 

>RH: Given the scope of the work= , I think that it is too early to say whether there would be an impact. Tho= se Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, = with the recognition of course that the changes would have to be proposed t= o ITI-T Study Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes withi= n countries is subject to regulation.  The WG cannot make any decision= s with regard to this.  I expect the WG to define "roles" within the number management processes; e.g.= , administrator, telecom carrier, application provider, consumer,= etc.; and how those roles could interact with each other.  This will = be a baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject = to, or affect, national regulations.  That is, the definition of a =93= role=94 may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions to be able = to address the status of a telephone number.

 

>RH: Since the terms =93assigned= =94, =93spare=94 and =93reclaimed=94 are defined in ITU-T Recommendations (= albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".<= /p>

We are aware of Resolution 133 and will certainly respect it. &n= bsp;I would propose adding the following text after the first sentence= in the last full paragraph =96 "The group acknowledges = ;ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  =

 

>RH: That certainly would be a h= elpful addition. In addition to the above, I would suggest adding =93The gr= oup=92s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1= , E.190 and the Recommendations referenced therein.=94 

 

>RH: For the sake of clarity I r= eiterate that I oppose the creation of this group even if the Charter is mo= dified to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace that= would require regulatory oversight, e.g., a new TLD, SLD, etc.  = I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say = anything specific about that.  There is nothing in the charter that re= ferences .tel.  <= /p>


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify that = sentence to add the following at the end - "as well as other rele= vant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG names= .  : )  But the charter is where to look for the scope of work. &= nbsp;The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information =85 with TNs", "associating, ac= quiring and resolving TNs", "access data related to&nbs= p;TNs", and "mechanisms for resolving information related to = ;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work<= /o:p>

 

 

 


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_D1B2D412154839jonpetersonneustarbiz_-- --_004_D1B2D412154839jonpetersonneustarbiz_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=5171; creation-date="Fri, 26 Jun 2015 17:11:57 GMT"; modification-date="Fri, 26 Jun 2015 17:11:57 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_D1B2D412154839jonpetersonneustarbiz_-- From nobody Fri Jun 26 10:15: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 8F6721A89A0 for ; Fri, 26 Jun 2015 10:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 tKKnJuYbMQhf for ; Fri, 26 Jun 2015 10:15:31 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 24C271A89B0 for ; Fri, 26 Jun 2015 10:15:30 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QHFSUP022868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 19:15:28 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QHFR1d032497; Fri, 26 Jun 2015 19:15:27 +0200 From: "Richard Hill" To: "'Peterson, Jon'" , "'McGarry, Tom'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: Date: Fri, 26 Jun 2015 19:15:28 +0200 Message-ID: <00c701d0b033$b327e020$1977a060$@ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01D0B044.76B0B020" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugIAAOi1Q Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:15:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C8_01D0B044.76B0B020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Jon, Thank you for the thoughtful reply. Please see embedded comments below. Thanks and best, Richard From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, June 26, 2015 18:35 To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource on which the IETF does protocol work - like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are responsible for ccTLDs, >RH: The degree of involvement of national authorities with ccTLDs varies greatly, but I'm not aware of any that regulate ccTLDs to the same extent that telephone numbers are regulated. Further, the protocols and policies for the DNS were mostly developed before anybody thought that there should be any government involvement. And today ICANN develops most of the policies, even if the IETF is developing the protocols. So it is not an appropriate analogy. surely the IETF is not a suitable body for managing the DNS! >RH: The IETF does not manage the DNS. ICANN manages the DNS, to the extent that it requires top level management. And it isn't. But it is a suitable body for managing the protocol work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sorts of things you are worrying about here. The IETF just produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is simply an error. >RH: I'm not convinced that you can develop tools that don't affect policies. Indeed, it seems to me that the policies will condition whether certain tools are useable or not. All work at the IETF is done by a coalition of the willing. If it turns out that the coalition is not representative of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly be harmed by that, even if the failed work involved ways of talking about telephone numbers. >RH: That is true if nobody uses the work. It is not true if some country, say the US, adopts the outputs and then lobbies to have them adopted elsewhere. That can lead to serious friction and pushback. Better to involve all concerned parties early in the game. This makes the IETF really different from places like the ITU, where the products of work have some binding effect on the world. >RH> ITU-T Recommendations are no more (or less) binding that IETF RFCs or ISO Standards. Virtually all proposed work at the IETF also faces a coalition of the unwilling. People who aren't interested, or who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agree that if this proposed work required regulatory oversight, that the IETF shouldn't do it. >RH: I see that we agree on the principles but not the details. I don't see how the proposed work would not have regulatory impacts in at least some (probably many) countries, even if it has no impact in the US. Again, if the idea is to develop tools that would first be used in the US, then the work should be done in a US-only body. If the idea is to develop tools that would be used in many countries, then I think that the ITU-T is a more suitable forum. But we're just building some protocol tools. There is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol tools developed in the IETF and conduct an experiment with various carriers to see if it works for that interest group or not, and that would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part. >RH: I still don't understand why you think that IETF is uniquely well positioned to do this work. Surely nobody would suggest that the IETF should develop standards for nuts and bolts, when ISO is doing that. So why should the IETF develop standards (or tools) for telephone numbers when the ITU-T is doing that? Finally, I'm not really sure how much I would expect "national regulators" to literally use the tools proposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part instigated by an FCC workshop, yes, and someone associated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy this work - surely they would leave that to industry. >RH: That may well be true for the US, but it may well not be true in other countries. Which is why I think that the work is better done in a forum where you are more likely to get inputs from national regulators. If the inputs are of the form "go ahead, we don't care", then that is fine. But if you do the work in the IETF, you are not likely to get inputs from national regulators. Jon Peterson Neustar, Inc. From: Richard Hill Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" , "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by national regulators, presumably they should be involved in the development of the tools. As far as I know, national regulators from most countries don't normally participate in the IETF, for a number of reasons, including the IETF's decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU's decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at first, then I would suggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If the US experience proved successful, then the tools could be proposed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the start, then I would suggest that the appropriate forum would be ITU-T, not IETF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers. Entities can choose to use these tools or not. These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T. But of course we want your input and feedback, so thanks for sending this along. More comments in line below. From: Alissa Cooper Date: Thursday, June 25, 2015 7:44 AM To: Modern List Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say whether there would be an impact. Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recognition of course that the changes would have to be proposed to ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regulation. The WG cannot make any decisions with regard to this. I expect the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other. This will be a baseline for what tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That is, the definition of a "role" may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a telephone number. >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU-T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used". We are aware of Resolution 133 and will certainly respect it. I would propose adding the following text after the first sentence in the last full paragraph - "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, I would suggest adding "The group's outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein." >RH: For the sake of clarity I reiterate that I oppose the creation of this group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions. But it's too early to say anything specific about that. There is nothing in the charter that references .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "as well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent. The IETF often has fun with creating WG names. : ) But the charter is where to look for the scope of work. The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information . with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs". The functions you believe were left out of the charter will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ------=_NextPart_000_00C8_01D0B044.76B0B020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Jon,

 

Thank you for the thoughtful reply.

 

Please see embedded comments below.


Thanks and best,

Richard

 

From:= = Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Friday, = June 26, 2015 18:35
To: Richard Hill; McGarry, Tom; = modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)

 

=  

= Your arguments here could equally well be applied to any important = resource on which the IETF does protocol work - like, say, the DNS. The = IETF manages the DNS protocol and publishes RFCs about it. But since = national authorities are responsible for ccTLDs,

 

>RH: The degree of involvement of national authorities with ccTLDs = varies greatly, but I’m not aware of any that regulate ccTLDs to = the same extent that telephone numbers are regulated. Further, the = protocols and policies for the DNS were mostly developed before anybody = thought that there should be any government involvement. And today ICANN = develops most of the policies, even if the IETF is developing the = protocols. So it is not an appropriate analogy.

 

= surely the IETF is not a suitable body for managing the = DNS!

 

>RH: The IETF does not manage the DNS. ICANN manages the DNS, to = the extent that it requires top level = management.

 

= And it isn't. But it is a suitable body for managing the protocol work = on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies = there are lots of national regulators and they worry about the sorts of = things you are worrying about here. The IETF just produces tools, and = that is all MODERN proposes to do. Trying to characterize this effort = otherwise is simply an error.

 

>RH: I’m not convinced that you can develop tools that = don’t affect policies.  Indeed, it seems to me that the = policies will condition whether certain tools are useable or = not.

=  

= All work at the IETF is done by a coalition of the willing. If it turns = out that the coalition is not representative of the needs of the = community, then what happens? Well, the work built here doesn't get = used. The only people who wasted any time or effort were the members of = that coalition. No national interests can possibly be harmed by that, = even if the failed work involved ways of talking about telephone = numbers.

 

>RH: That is true if nobody uses the work. It is not true if some = country, say the US, adopts the outputs and then lobbies to have them = adopted elsewhere.  That can lead to serious friction and pushback. = Better to involve all concerned parties early in the = game.

 

= This makes the IETF really different from places like the ITU, where = the products of work have some binding effect on the = world.

 

>RH> ITU-T Recommendations are no more (or less) binding that = IETF RFCs or ISO Standards.

=  

= Virtually all proposed work at the IETF also faces a coalition of the = unwilling. People who aren't interested, or who think the work should be = done elsewhere, or that the work simply shouldn't be done at all. But I = maintain your "formal objection" treats the scope of the = proposed work as being different than it is, and I'd agree that if this = proposed work required regulatory oversight, that the IETF shouldn't do = it.

 

>RH: I see that we agree on the principles but not the details. I = don’t see how the proposed work would not have regulatory impacts = in at least some (probably many) countries, even if it has no impact in = the US. Again, if the idea is to develop tools that would first be used = in the US, then the work should be done in a US-only body. If the idea = is to develop tools that would be used in many countries, then I think = that the ITU-T is a more suitable forum.

 

= But we're just building some protocol tools. There is also related work = here for ATIS to do, and I'm sure ATIS or some other body could later = take some the protocol tools developed in the IETF and conduct an = experiment with various carriers to see if it works for that interest = group or not, and that would be interesting information. But the IETF = doesn't do that part, and doesn't aspire to do that = part.

 

>RH: I still don’t understand why you think that IETF is = uniquely well positioned to do this work. Surely nobody would suggest = that the IETF should develop standards for nuts and bolts, when ISO is = doing that. So why should the IETF develop standards (or tools) for = telephone numbers when the ITU-T is doing = that?

=  

= Finally, I'm not really sure how much I would expect "national = regulators" to literally use the tools proposed in this work. They = are tools for the use of a diverse industry of enterprises, carriers, = end users, and so on. Many use cases under consideration would not have = a national regulator as an actor. This work was in part instigated by an = FCC workshop, yes, and someone associated with the FCC spoke at the = MODERN BoF. But I don't anticipate that the FCC would be propping up = servers to deploy this work - surely they would leave that to = industry. 

 

>RH: That may well be true for the US, but it may well not be true = in other countries. Which is why I think that the work is better done in = a forum where you are more likely to get inputs from national = regulators. If the inputs are of the form “go ahead, we = don’t care”, then that is fine. But if you do the work in = the IETF, you are not likely to get inputs from national = regulators.

=  

= Jon Peterson

= Neustar, Inc.

=  

From: Richard Hill <rhill@hill-a.ch>
Date: = Friday, June 26, 2015 at 8:09 AM
To: "McGarry, = Tom" <Tom.McGarry@neustar.biz>, = "modern@ietf.org" = <modern@ietf.org>
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

=  

Thank you for this clarification.

 

Since the intent is to create tools and solutions that would be used = by national regulators, presumably they should be involved in the = development of the tools. 


As far as I know, national regulators from most countries = don’t normally participate in the IETF, for a number of reasons, = including the IETF’s decision-making process and the fact that the = IETF works in English. National regulators do participate in ITU-T, for = a number of reasons, including the ITU’s decision-making process = and the fact that documents are translated into the six UN languages = before they are formally approved (and some discussions takes place with = interpretation in six languages).

 

If the intent is to develop tools that would be used only in the USA = at first, then I would suggest that it would be more appropriate to = develop them in a forum such as ATIS or an ad-hoc group created = specifically for the purpose. If the US experience proved successful, = then the tools could be proposed for adoption elsewhere, for example = through ITU-T.

 

If the intent is to develop tools for use in many countries right at = the start, then I would suggest that the appropriate forum would be = ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the creation of this new working group, = and this even if the Charter is modified as suggested below.

 

Please see additional comments inline.

 

Thanks and best,

Richard

 

= From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin = 2015 00:31
To: modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

 

This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. =  Entities can choose to use these tools or not.  These tools = are not for the ITU-T's processes or role, nor for how national = administrators interact with the ITU-T.  But of course we want your = input and feedback, so thanks for sending this along.  More = comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: = Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: = [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Would appreciate people’s thoughts on whether any charter edits = may be warranted in response to these comments, and/or whether a = separate response may be useful for addressing some of the questions = below.

 

Alissa

 

Begin forwarded message:




From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU = Telecommunication Standardization Bureau on the proposed IETF working = group MODERN.

1. Potential = impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated = at the beginning of the Charter that 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. And it is = mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to = here only deals with Tel URI? Would there be any impact on = Recommendation ITU-E E.164 and E.164.1 which are core recommendations on = Telephone Numbers?

= There will be no impacts on E.164 and E.164.1.

 

>RH: Given the scope of the work, I think that it is too early to = say whether there would be an impact. Those Recommendations are = regularly updated, in particular E.164.1, so there is nothing wrong with = envisaging changes, with the recognition of course that the changes = would have to be proposed to ITI-T Study Group 2 and agreed by that = group.


2. Entities participating in = the defined mechanisms
The Charter states that the protocol mechanism = for resolving TNs will allow entities such as service providers, = devices, and applications to access data related to TNs. But it is not = clear what kind of entities can participate in the mechanisms defined by = this MODERN working group. Would it be restricted to the entities who = have been assigned a TN or a block of TNS?

= Who participates in numbering processes within countries is subject to = regulation.  The WG cannot make any decisions with regard to this. =  I expect the WG to define "roles" within the number = management processes; e.g., administrator, telecom = carrier, application provider, consumer, etc.; and how those = roles could interact with each other.  This will be = a baseline for what tools and solutions would be useful to = facilitate those interactions.  

 

>RH: Even that might be subject to, or affect, national = regulations.  That is, the definition of a “role” may = well depend on national regulations.


3. Status of Telephone numbers = in the defined mechanisms
Several operations related to TNs are = mentioned in the Charter, including requesting, acquiring, resolving and = associating. It is also stated that the protocol mechanism for acquiring = TNs will provide an enrollment process for the entities that use and = manage TNs. Does that mean Telephone numbers with various status, such = as assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working group?

I=  would expect proposed solutions to be able to address the status = of a telephone number.

 

>RH: Since the terms “assigned”, “spare” = and “reclaimed” are defined in ITU-T Recommendations (albeit = sometimes implicitly), addressing the status of a telephone number might = well impact E.164 or E.164.1.


4. Regulatory issues
The = Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact = that the E.164 international public telecommunication numbering plan is = a politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of = ITU Member States with respect to allocation and management of their = country code numbering resources as enshrined in Recommendation ITU-T = E.164", and further instructed the ITU Secretary-General and the = Directors of three Bureaux (Telecommunication Standardization, = Development, and Radiocommunication) to "take any necessary action = to ensure the sovereignty of ITU Member States with regard to = Recommendation ITU-T E.164 numbering plans whatever the application in = which they are used".

We are aware of = Resolution 133 and will certainly respect it.  I would propose = adding the following text after the first sentence in the last full = paragraph – "The group acknowledges ITU = Plenipotentiary Conference Resolution 133 which recognizes the existing = role and sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined = in Recommendation ITU-T E.164."  

 

>RH: That certainly would be a helpful addition. In addition to = the above, I would suggest adding “The group’s outputs would = be consistent with the provisions of relevant ITU-T Recommendations, in = particular E.164, E.164.1, E.190 and the Recommendations referenced = therein.” 

 

>RH: For the sake of clarity I reiterate that I oppose the = creation of this group even if the Charter is modified to include the = text above.

 


5. Relationship with = .Tel
DNS-based use of international numbering resources has been = discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 = September 2013. TSB Director has also exchanged letters with ICANN on = issues related to registering digit strings in the .TEL domain. A = representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A = correspondence group under ITU-T SG2 was also set up in this regard. We = would like to know how the work of this new WG would relate to issues = related to registering digit strings in the .TEL domain and other = DNS-based use of telephone numbers.

= The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule = out the WG leveraging existing namespaces as part of proposed = solutions.  But it's too early to say anything specific about that. =  There is nothing in the charter that references .tel. =  


6. Relationship with related = existing or concluded WGs
It is stated in the Charter that the = working group will take into consideration existing IETF work including = STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the = relationship between this new WG and the above mentioned other existing = or concluded WGs would be appreciated.

= I agree.  I would modify that sentence to add the = following at the end - "as well as = other relevant industry and standards = organizations."


7. The name of this new = WG
The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the = Charter, ordering, exposing and registering TNs are not mentioned, which = seems to be a little bit inconsistent.

= The IETF often has fun with creating WG names.  : )  But the = charter is where to look for the scope of work.  The charter uses = the following phrases "distribution, acquisition and management = of TNs", "functions involved in associating = information … with TNs", "associating, = acquiring and resolving TNs", "access data related = to TNs", and "mechanisms for resolving information = related to TNs".  The functions you believe were left out = of the charter will be part of one or more of these processes. =  



Best regards,

Jie Zhang
Advisor, ITU-T = SG2
International Telecommunication Union
Place des = Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 = 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Origina= l Message-----
From: new-work [mailto:new-work-bounces@ietf.or= g] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 = PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz> Steve Donovan <srdonovan@usdonovans.com>=

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailin= g list
 Address: modern@ietf.org
 To = Subscribe: https://www.ietf.or= g/mailman/listinfo/modern
 Archive: http://www.ietf.org= /mail-archive/web/modern/

Charter:

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. = Devices, applications, and network tools increasingly need to manage = TNs, including requesting and acquiring TN delegations from authorities. = The output of the working group should make distribution, acquisition, = and management of TNs simpler for all entities involved.

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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs. 

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, and security = and privacy for both the data and the protocol interactions are primary = considerations. The working group will take into consideration existing = IETF work including STIR, 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. 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 for TN assignment and management, for = example those established by different regulatory agencies.

The = working 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

Milestones:

TBD

________________________________= _______________
new-work mailing list
new-work@ietf.org
https://www.ietf.= org/mailman/listinfo/new-work

 

 

------=_NextPart_000_00C8_01D0B044.76B0B020-- From nobody Fri Jun 26 10:17: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 A925F1A8AC3 for ; Fri, 26 Jun 2015 10:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 H2cLyNjuW7W7 for ; Fri, 26 Jun 2015 10:17:04 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 924F51A8A62 for ; Fri, 26 Jun 2015 10:16:59 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QHGu30024424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 19:16:56 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QHGtmY003726; Fri, 26 Jun 2015 19:16:55 +0200 From: "Richard Hill" To: "'McGarry, Tom'" , "'Peterson, Jon'" , "'Gorman, Pierce A [CTO]'" , References: <005e01d0b031$e5b513c0$b11f3b40$@ch> In-Reply-To: Date: Fri, 26 Jun 2015 19:16:56 +0200 Message-ID: <00e301d0b033$e7aade60$b7009b20$@ch> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00E4_01D0B044.AB33AE60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxEB/Zz98yjqU+KL6VWQx+3vZ29zs4AgAERc1CAAGBKAIAABc6AgAABRgCAAAC/gP//v2cAgAABRqA= Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:17:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E4_01D0B044.AB33AE60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E5_01D0B044.AB33AE60" ------=_NextPart_001_00E5_01D0B044.AB33AE60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Tom, Thank you for this. My point is that you are more likely to be able to develop solutions with the requisite flexibility if you get inputs from national regulators early on. And that that is more likely to happen if the matters are discussed in ITU-T. Best, Richard From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz] Sent: Friday, June 26, 2015 19:11 To: Richard Hill; Peterson, Jon; 'Gorman, Pierce A [CTO]'; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) They most likely would be involved in deciding whether that use case can happen (one entity delegating numbers to another), but it is unlikely they would be involved in the actual interaction. Even if there are cases where they would, there are certainly cases where they wouldn't. This is why the solutions need to be flexible enough to account for different policies. From: Richard Hill Date: Friday, June 26, 2015 1:02 PM To: Jon Peterson , Pierce Gorman , Tom Mcgarry , Modern List Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A "VoIP service provider who wants to receive a block of new numbers through a delegation from a carrier" might well be subject to national regulation, so the national regulator might well be involved in that use case. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Friday, June 26, 2015 19:00 To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) One would be an enterprise IP phone that has just been deployed and wants to acquire a new number from an IP PBX. Another would be a VoIP service provider who wants to receive a block of new numbers through a delegation from a carrier. I ran through such use cases at the MODERN BoF. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" Date: Friday, June 26, 2015 at 9:55 AM To: Jon Peterson , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) "Many use cases under consideration would not have a national regulator as an actor." - J. Peterson I've struggled with this point. What are the "many" use cases? For example, I've not been able to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number. What is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol tools to manage telephone numbers? What is broken about the existing system(s)? And I really struggle with how this is supposed to work because there are so many different kinds of telephone numbers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs, IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG, SMS800, et cetera. And the administration is distributed (in the US) at national and state levels. Has anyone from any of the US or international number management administrative organizations requested that the IETF build tools for them? If they don't use them, who will? And how can they integrate with an existing system? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com cid:408000_086801428601145001@pvmxe13g01 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource on which the IETF does protocol work - like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are responsible for ccTLDs, surely the IETF is not a suitable body for managing the DNS! And it isn't. But it is a suitable body for managing the protocol work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sorts of things you are worrying about here. The IETF just produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is simply an error. All work at the IETF is done by a coalition of the willing. If it turns out that the coalition is not representative of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly be harmed by that, even if the failed work involved ways of talking about telephone numbers. This makes the IETF really different from places like the ITU, where the products of work have some binding effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwilling. People who aren't interested, or who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agree that if this proposed work required regulatory oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol tools developed in the IETF and conduct an experiment with various carriers to see if it works for that interest group or not, and that would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" to literally use the tools proposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part instigated by an FCC workshop, yes, and someone associated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy this work - surely they would leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" , "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by national regulators, presumably they should be involved in the development of the tools. As far as I know, national regulators from most countries don't normally participate in the IETF, for a number of reasons, including the IETF's decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU's decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at first, then I would suggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If the US experience proved successful, then the tools could be proposed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the start, then I would suggest that the appropriate forum would be ITU-T, not IETF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers. Entities can choose to use these tools or not. These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T. But of course we want your input and feedback, so thanks for sending this along. More comments in line below. From: Alissa Cooper Date: Thursday, June 25, 2015 7:44 AM To: Modern List Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say whether there would be an impact. Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recognition of course that the changes would have to be proposed to ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regulation. The WG cannot make any decisions with regard to this. I expect the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other. This will be a baseline for what tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That is, the definition of a "role" may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a telephone number. >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU-T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used". We are aware of Resolution 133 and will certainly respect it. I would propose adding the following text after the first sentence in the last full paragraph - "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, I would suggest adding "The group's outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein." >RH: For the sake of clarity I reiterate that I oppose the creation of this group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions. But it's too early to say anything specific about that. There is nothing in the charter that references .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "as well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent. The IETF often has fun with creating WG names. : ) But the charter is where to look for the scope of work. The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information . with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs". The functions you believe were left out of the charter will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _____ 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. ------=_NextPart_001_00E5_01D0B044.AB33AE60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Tom,


Thank you for this. My point is that you are more likely to be = able to develop solutions with the requisite flexibility if you get = inputs from national regulators early on. And that that is more likely = to happen if the matters are discussed in ITU-T.


Best,

Richard

 

From:= = McGarry, Tom [mailto:Tom.McGarry@neustar.biz]
Sent: Friday, = June 26, 2015 19:11
To: Richard Hill; Peterson, Jon; 'Gorman, = Pierce A [CTO]'; modern@ietf.org
Subject: Re: [Modern] Fwd: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)

 

= They most likely would be involved in deciding whether that use case can = happen (one entity delegating numbers to another), but it is unlikely = they would be involved in the actual interaction.  Even if there = are cases where they would, there are certainly cases where they = wouldn't.  This is why the solutions need to be flexible enough to = account for different policies. =  

=  

From: Richard Hill <rhill@hill-a.ch>
Date: = Friday, June 26, 2015 1:02 PM
To: Jon Peterson <jon.peterson@neustar.biz>= , Pierce Gorman <Pierce.Gorman@sprint.com>= , Tom Mcgarry <tom.mcgarry@neustar.biz>, = Modern List <modern@ietf.org>
Subject: = RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

=  

A “VoIP service provider who wants to receive a block of new = numbers through a delegation from a carrier” might well be subject = to national regulation, so the national regulator might well be involved = in that use case.


Best,

Richard

 

= From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Friday, June 26, = 2015 19:00
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, = Tom; modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

=  

= One would be an enterprise IP phone that has just been deployed and = wants to acquire a new number from an IP PBX. Another would be a VoIP = service provider who wants to receive a block of new numbers through a = delegation from a carrier. I ran through such use cases at the MODERN = BoF.

=  

= Jon Peterson

= Neustar, Inc.

=  

From: <Gorman>, "Pierce A [CTO]" <Pierce.Gorman@sprint.com>=
Date: Friday, June 26, 2015 at 9:55 AM
To: Jon = Peterson <jon.peterson@neustar.biz>= , Richard Hill <rhill@hill-a.ch>, "McGarry, = Tom" <Tom.McGarry@neustar.biz>, = "modern@ietf.org" = <modern@ietf.org>
Subject: = RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

=  

“Many use cases under consideration would not have a national regulator = as an actor.”  - J. Peterson

 

I’ve struggled with this point.  What are the = “many” use cases?  For example, I’ve not been = able to envision the use case that would require a device to use a = MODERN protocol tool to acquire an RFC 3966 telephone number.  What = is this use case?

 

This continues to baffle me.  Why is the IETF proposing to develop = protocol tools to manage telephone numbers?  What is broken about = the existing system(s)?

 

And I really struggle with how this is supposed to work because there = are so many different kinds of telephone numbers such as service numbers = (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline = numbers, TLDNs, IMRNs, ported numbers, and multiple administrative = databases, NPAC, LERG, SMS800, et cetera.

 

And the administration is distributed (in the US) at national and state = levels.

 

Has anyone from any of the US or international number management = administrative organizations requested that the IETF build tools for = them?  If they don’t use them, who will?  And how can = they integrate with an existing system?  Sorry Jon.  Still = lost.

 

 

Pierce Gorman

= Core Network Planning

= O: 913-439-4368

= pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 = AM
To: Richard Hill; McGarry, Tom; modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

 

Your arguments here could equally well be applied to any important = resource on which the IETF does protocol work - like, say, the DNS. The = IETF manages the DNS protocol and publishes RFCs about it. But since = national authorities are responsible for ccTLDs, surely the IETF is not = a suitable body for managing the DNS! And it isn't. But it is a suitable = body for managing the protocol work on the DNS. Other, effectively = unrelated entities handle the administrative dimensions of operating the = DNS, and yes, at those bodies there are lots of national regulators and = they worry about the sorts of things you are worrying about here. The = IETF just produces tools, and that is all MODERN proposes to do. Trying = to characterize this effort otherwise is simply an error.

 

All work at the IETF is done by a coalition of the willing. If it turns = out that the coalition is not representative of the needs of the = community, then what happens? Well, the work built here doesn't get = used. The only people who wasted any time or effort were the members of = that coalition. No national interests can possibly be harmed by that, = even if the failed work involved ways of talking about telephone = numbers. This makes the IETF really different from places like the ITU, = where the products of work have some binding effect on the = world.

 

Virtually all proposed work at the IETF also faces a coalition of the = unwilling. People who aren't interested, or who think the work should be = done elsewhere, or that the work simply shouldn't be done at all. But I = maintain your "formal objection" treats the scope of the = proposed work as being different than it is, and I'd agree that if this = proposed work required regulatory oversight, that the IETF shouldn't do = it. But we're just building some protocol tools. There is also related = work here for ATIS to do, and I'm sure ATIS or some other body could = later take some the protocol tools developed in the IETF and conduct an = experiment with various carriers to see if it works for that interest = group or not, and that would be interesting information. But the IETF = doesn't do that part, and doesn't aspire to do that part.

 

Finally, I'm not really sure how much I would expect "national = regulators" to literally use the tools proposed in this work. They = are tools for the use of a diverse industry of enterprises, carriers, = end users, and so on. Many use cases under consideration would not have = a national regulator as an actor. This work was in part instigated by an = FCC workshop, yes, and someone associated with the FCC spoke at the = MODERN BoF. But I don't anticipate that the FCC would be propping up = servers to deploy this work - surely they would leave that to = industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@hill-a.ch>
Date: = Friday, June 26, 2015 at 8:09 AM
To: "McGarry, = Tom" <Tom.McGarry@neustar.biz>, = "modern@ietf.org" = <modern@ietf.org>
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Thank you for this clarification.

 

Since the intent is to create tools and solutions that would be used = by national regulators, presumably they should be involved in the = development of the tools. 


As far as I know, national regulators from most countries = don’t normally participate in the IETF, for a number of reasons, = including the IETF’s decision-making process and the fact that the = IETF works in English. National regulators do participate in ITU-T, for = a number of reasons, including the ITU’s decision-making process = and the fact that documents are translated into the six UN languages = before they are formally approved (and some discussions takes place with = interpretation in six languages).

 

If the intent is to develop tools that would be used only in the USA = at first, then I would suggest that it would be more appropriate to = develop them in a forum such as ATIS or an ad-hoc group created = specifically for the purpose. If the US experience proved successful, = then the tools could be proposed for adoption elsewhere, for example = through ITU-T.

 

If the intent is to develop tools for use in many countries right at = the start, then I would suggest that the appropriate forum would be = ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the creation of this new working group, = and this even if the Charter is modified as suggested below.

 

Please see additional comments inline.

 

Thanks and best,

Richard

 

= From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin = 2015 00:31
To: modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

 

This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. =  Entities can choose to use these tools or not.  These tools = are not for the ITU-T's processes or role, nor for how national = administrators interact with the ITU-T.  But of course we want your = input and feedback, so thanks for sending this along.  More = comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: = Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: = [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Would appreciate people’s thoughts on whether any charter edits = may be warranted in response to these comments, and/or whether a = separate response may be useful for addressing some of the questions = below.

 

Alissa

 

Begin forwarded message:






From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU = Telecommunication Standardization Bureau on the proposed IETF working = group MODERN.

1. Potential = impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated = at the beginning of the Charter that 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. And it is = mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to = here only deals with Tel URI? Would there be any impact on = Recommendation ITU-E E.164 and E.164.1 which are core recommendations on = Telephone Numbers?

= There will be no impacts on E.164 and E.164.1.

 

>RH: Given the scope of the work, I think that it is too early to = say whether there would be an impact. Those Recommendations are = regularly updated, in particular E.164.1, so there is nothing wrong with = envisaging changes, with the recognition of course that the changes = would have to be proposed to ITI-T Study Group 2 and agreed by that = group.


2. Entities participating in = the defined mechanisms
The Charter states that the protocol mechanism = for resolving TNs will allow entities such as service providers, = devices, and applications to access data related to TNs. But it is not = clear what kind of entities can participate in the mechanisms defined by = this MODERN working group. Would it be restricted to the entities who = have been assigned a TN or a block of TNS?

= Who participates in numbering processes within countries is subject to = regulation.  The WG cannot make any decisions with regard to this. =  I expect the WG to define "roles" within the number = management processes; e.g., administrator, telecom = carrier, application provider, consumer, etc.; and how those = roles could interact with each other.  This will be = a baseline for what tools and solutions would be useful to = facilitate those interactions.  

 

>RH: Even that might be subject to, or affect, national = regulations.  That is, the definition of a “role” may = well depend on national regulations.


3. Status of Telephone numbers = in the defined mechanisms
Several operations related to TNs are = mentioned in the Charter, including requesting, acquiring, resolving and = associating. It is also stated that the protocol mechanism for acquiring = TNs will provide an enrollment process for the entities that use and = manage TNs. Does that mean Telephone numbers with various status, such = as assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working group?

I=  would expect proposed solutions to be able to address the status = of a telephone number.

 

>RH: Since the terms “assigned”, “spare” = and “reclaimed” are defined in ITU-T Recommendations (albeit = sometimes implicitly), addressing the status of a telephone number might = well impact E.164 or E.164.1.


4. Regulatory issues
The = Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact = that the E.164 international public telecommunication numbering plan is = a politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of = ITU Member States with respect to allocation and management of their = country code numbering resources as enshrined in Recommendation ITU-T = E.164", and further instructed the ITU Secretary-General and the = Directors of three Bureaux (Telecommunication Standardization, = Development, and Radiocommunication) to "take any necessary action = to ensure the sovereignty of ITU Member States with regard to = Recommendation ITU-T E.164 numbering plans whatever the application in = which they are used".

We are aware of = Resolution 133 and will certainly respect it.  I would propose = adding the following text after the first sentence in the last full = paragraph – "The group acknowledges ITU = Plenipotentiary Conference Resolution 133 which recognizes the existing = role and sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined = in Recommendation ITU-T E.164."  

 

>RH: That certainly would be a helpful addition. In addition to = the above, I would suggest adding “The group’s outputs would = be consistent with the provisions of relevant ITU-T Recommendations, in = particular E.164, E.164.1, E.190 and the Recommendations referenced = therein.” 

 

>RH: For the sake of clarity I reiterate that I oppose the = creation of this group even if the Charter is modified to include the = text above.

 


5. Relationship with = .Tel
DNS-based use of international numbering resources has been = discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 = September 2013. TSB Director has also exchanged letters with ICANN on = issues related to registering digit strings in the .TEL domain. A = representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A = correspondence group under ITU-T SG2 was also set up in this regard. We = would like to know how the work of this new WG would relate to issues = related to registering digit strings in the .TEL domain and other = DNS-based use of telephone numbers.

= The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule = out the WG leveraging existing namespaces as part of proposed = solutions.  But it's too early to say anything specific about that. =  There is nothing in the charter that references .tel. =  


6. Relationship with related = existing or concluded WGs
It is stated in the Charter that the = working group will take into consideration existing IETF work including = STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the = relationship between this new WG and the above mentioned other existing = or concluded WGs would be appreciated.

= I agree.  I would modify that sentence to add the = following at the end - "as well as = other relevant industry and standards = organizations."


7. The name of this new = WG
The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the = Charter, ordering, exposing and registering TNs are not mentioned, which = seems to be a little bit inconsistent.

= The IETF often has fun with creating WG names.  : )  But the = charter is where to look for the scope of work.  The charter uses = the following phrases "distribution, acquisition and management = of TNs", "functions involved in associating = information … with TNs", "associating, = acquiring and resolving TNs", "access data related = to TNs", and "mechanisms for resolving information = related to TNs".  The functions you believe were left out = of the charter will be part of one or more of these processes. =  



Best regards,

Jie Zhang
Advisor, ITU-T = SG2
International Telecommunication Union
Place des = Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 = 5855
jie.zhang@itu.int
www.it= u.int
www= .itu150.org


-----Original Message-----
From: new-work = [mailto:new-work-bounces@ietf.or= g] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 = PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz> Steve Donovan <srdonovan@usdonovans.com>=

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailin= g list
 Address: modern@ietf.org
 To = Subscribe: https://www.ietf.org/mailman/listinfo/modern
&= nbsp;Archive: http://www.ietf.org/mail-archive/web/modern/
Charter:

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. Devices, applications, and = network tools increasingly need to manage TNs, including requesting and = acquiring TN delegations from authorities. The output of the working = group should make distribution, acquisition, and management of TNs = simpler for all entities involved.

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. TNs may either be managed in a = hierarchical tree, or in a distributed registry. The protocol mechanism = for acquiring TNs will provide an enrollment process for the entities = that use and manage TNs. 

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, and security and privacy for both the = data and the protocol interactions are primary considerations. The = working group will take into consideration existing IETF work including = STIR, 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. 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 = for TN assignment and management, for example those established by = different regulatory agencies.

The working 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

Milestones:

TBD

________________________________= _______________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

=  

=

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.

------=_NextPart_001_00E5_01D0B044.AB33AE60-- ------=_NextPart_000_00E4_01D0B044.AB33AE60 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: 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= ------=_NextPart_000_00E4_01D0B044.AB33AE60-- From nobody Fri Jun 26 10:18: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 870C21A8A96 for ; Fri, 26 Jun 2015 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 KWOyvGetnbmB for ; Fri, 26 Jun 2015 10:17:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6121E1A89A0 for ; Fri, 26 Jun 2015 10:17:54 -0700 (PDT) Received: from BY2FFO11OLC006.protection.gbl (10.1.14.33) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.1.201.10; Fri, 26 Jun 2015 17:17:51 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) 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 plsapdm1.corp.sprint.com (144.230.172.36) by BY2FFO11OLC006.mail.protection.outlook.com (10.1.14.199) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Fri, 26 Jun 2015 17:17:51 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5QHH3un035778; Fri, 26 Jun 2015 12:17:50 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm1.corp.sprint.com with ESMTP id 1v8yr140vg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 12:17:50 -0500 Received: from PLSWE13M08.ad.sprint.com (144.229.214.27) by PREWE13M07.ad.sprint.com (144.226.128.26) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 26 Jun 2015 13:17: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; Fri, 26 Jun 2015 12:17:48 -0500 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEVhNQitnoIUyGmpgejVxL7J2+EeCAgAEW4ID//6JugIAAM3mQgABZuwD//60YMA== Date: Fri, 26 Jun 2015 17:17:47 +0000 Message-ID: <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: 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.229.91.92] Content-Type: multipart/related; boundary="_004_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC006; 1:UXvsjGF6saWhriuNajkRcdUJbKjB6+w8FYDyhMYyxQ0c27TW+3kz9EBnor4WEfS/642AnIg/qX6W2NCq8toVOr2G0wr09PITEjVNE//i1MUJ8gC28freCCmeSV1DHYYA+CT4amzqbPnKK8ILDt6NDxYV/eQfxgbe2q5mGPn2aKS9C/i4kLFhK7A267/BfHFxy1rR9sujqhABd+CR081w8VCxQHuFWlOHbaK7iKzBmKtcumGRQJxiD4cu2k5hDYGWMTQYAsAbcvSQWxmU3BnvaMSFQTWm7XCZU6AJj/7whwQtikB1EK0m8UpkAxcdlvvQ X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(448002)(45074003)(2473001)(60444003)(51444003)(13464003)(377454003)(52604005)(199003)(189002)(5250100002)(2501003)(18206015028)(19627595001)(19617315012)(77156002)(62966003)(108616004)(5001960100002)(107886002)(106466001)(15974865002)(19300405004)(93886004)(33646002)(16601075003)(5001770100001)(66926002)(102836002)(6806004)(15975445007)(189998001)(2950100001)(2900100001)(30436002)(5003600100002)(106116001)(19580405001)(19580395003)(19625215002)(67866002)(84326002)(87936001)(76176999)(50986999)(512954002)(54356999)(99936001)(85326001)(86362001)(16236675004)(575784001)(17760045003)(46102003)(2656002)(92566002)(7099028)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB038; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB038; 2:0W7V1LZq40W28ca/sxtpPVrq8z4uWBWaQ2zhBp2REuc1FmOy3rdldEP36Yyl0Y0u; 3:bjoU6rErX+Ry8I+9q6eYCjRCrPsFaJjurHCL2d+bGTJtHRwXO6Go9ijwpy9SXIlwUFSQTzpds1vf6v0cfwgEpYveOdwiEa/0A50YJeO1gr1LDdD+o4VFzGtbix9GwwopJUHIGZhaINiLzo6EglQTCotT9GBKGaMpu5HNRblXy7fP9CMUfRxUDffjfK/dbLWUEG9OSlV8Q3RAsETYtOmp/EvrFKA1XnxG1dA0WB3QIvS1hB0ul5ecTQpoeZi/E9Vd; 20:bLrZ2yPSKNRUVoReAXYLKlbqBV8quSc43P/d32yQPlQPsLYXMJd5fivOvsdgKyJsMiulpZYMTxhMON+d0X2O8frcAnhY206OuokR4/E9ctTIMHIpK5iMEoTreMnOZvBzh8tIrPzFgAbOCff7Wy2t1tkACfV5K2cObDXutJns0lDsCnfn6YK6/2L252mhxWrBC1ZUGawLh+sGPdNQjVVtAshFBi5haXhpW7Wxp1esCZd09BfWn2V+nEVKNx56WlAM; 4:LFesvTMFwDUCiYGoFoqTD2SemLc3j6la+OCN/4Oyq+0JCzJf4OhvKVfqLtqs18j6p/jmGD0VM9VSKFgRyfErv062BaRUhBdfzN/qel+EDz0tqUhTp2Jlp5WuSGI9u/yGqYR1NZ7BTAszN9qjVWsW+BRqqx8cvCGRQ/1NFvaFjjFIVZMyTmvRFJggxZGIRNf3VLyD5HcKlp7XWnAvEjOIAuFQ5f7yEq+N22Y0bSmL4mGbFTwWiXju2uHF0ZvlBBTQriebdFxhRc0eG++rvsP8JcNB71CMeWx6/RNC8Vmm9YU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB038; 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:BY2FFO11HUB038; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB038; X-Forefront-PRVS: 0619D53754 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB038; 23:y0Vcfz85nsHrzDG3ntaNlRxBAEJhmd0t6exq2Bd1?= =?us-ascii?Q?XWQfbvB56GysfAqs653VIjzI1r+TjfVReLSR0aMFTR2brrnSJdTL/9/+Ejn7?= =?us-ascii?Q?DsTy/galNxeBvTDxyr8RE8Skg9NseRCTbcyQcXpd0jMKFHD28keOXerFUKPf?= =?us-ascii?Q?6vn7xIrQLIe+CoiBvxBxkPx8QpBmopYAeXvhrlKe3REsKn3R5IcdjTFyjliU?= =?us-ascii?Q?HXtlaG2y7pPyNSuZSiw1anoeEo+TEyw0UuTN2hmFgSynYQ7KXd+EbX5K+p//?= =?us-ascii?Q?em8DT5mwny8dMLcrTOI3ZJ+DwebW53jFOpGJ+WRDK8C2A2HJ+TsCMfPVHZqd?= =?us-ascii?Q?J51Xk/2Kork0PdVtQuv3N8h8xYBOinv2w/xemSGQz6KkrLgrCrHoBMivUpWj?= =?us-ascii?Q?BmT8yaxNDXP3dVeLo/r61J0V0uKzKjspatbmgo8Q7G0wXG6VImPvqDAPC3yR?= =?us-ascii?Q?TrQlktSJ06g9Qe0mFPGM89nMe1ItXObAJhu+HfpBaGnIeHHdZxetcox9QQQl?= =?us-ascii?Q?yj0D44V1XybzJ0EveOh69v3wB4J/yWl+F3yLfw98Tn6XCsPfc5bLy2LbKDHC?= =?us-ascii?Q?QyFnote9DCGHa6x9p3Nl3XzCtpqihNAB8/dZAtg2M00jtu2JeIrCTwVe6zY3?= =?us-ascii?Q?zqKkyxAArU7xvOIGu48/gTBP6BcheoOZNc39fmsE36UF0ej2e3yNqffQ7gdz?= =?us-ascii?Q?RlQnkrlhF+LmaiBIcaUXRfUXX9ahPdE5hGKu5xUkf49Z670q4/QdWb+wk1QO?= =?us-ascii?Q?0yqQAffqcpInujLUSIlEmQFR7li+2OuhLIhN/ALhQFF4QPtkNwDijo89LC4p?= =?us-ascii?Q?gk75zdB8Q/cs3IemMx7bbsVyvOe5gJEfXfz3ExPqOQmfp7f+LW+YCrN0D1fc?= =?us-ascii?Q?o4ZNgO5yKokC1ZFD/xz3mvJsO2FNJ9EWWr0JlxQaZoueH37k4dYAt1BiXkaY?= =?us-ascii?Q?j0TsyGn7cqUot9WTvvY/InRbvJCqX/msJWtGHr/g4ivnvRBmkk6jykGNDJ7Y?= =?us-ascii?Q?TkrY9A2bapM3qg6/HpdjibGXtJyTgfFnJYaEj/6FO8holnLY9qDbUncGQ5xx?= =?us-ascii?Q?8zH6OmI87qK+zos+68AaBiRgJNkHXKqEtY4cQdie0K5JM1Gtf+/yjiTyrcFi?= =?us-ascii?Q?NwZOc+Ne7WaIqaWU8s+ae6wVUL3wQpf045Y6qdyK+ItmSrfIai6/G67oXNWv?= =?us-ascii?Q?aLKC4cSbiQHHorLdDvMx4xKHs9TNgVte4r0SXEMSXS0mm8uH9VJumTP8Xj8N?= =?us-ascii?Q?EMTtPeB5x5nb5ewVsUijHkFh5bD+O8YS0f5BiR1i3wSK6+hgBKP5TkBtNL6U?= =?us-ascii?Q?W+St+L558MUaKiIxoY40GcwxDSgmRHhqueF6sILvuWYK83UrLgNjfeZse0Yx?= =?us-ascii?Q?ji4rzS1jgBAoha9QyyLWW1FalUDySnhEgCnolJlVSL5shkZWg7AkOecu85IV?= =?us-ascii?Q?dL7gvV0veL7OhQlepgI4ngqlZwXvyfEb0s0OY3u+UQoqcP3VFZN6y5C/D+/M?= =?us-ascii?Q?wgmw1St8d912NLeS8PCeVKx8j8cQepzhrWLc3Smr49MXPLB4h3/kiCgQ?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB038; 5:6xzo6r/oKo0zm5lSkLvrjEjhx3xTQ18l2p5ei1kw+035K0VzX5F7445Vg6bZJov6I7Io9I0EvPLmH9L6m7vCJKTdXjwprOn0XqM6o5RcT5ikZCC41hH6tPSuaA2/uY506pUrJ7vLGSQDovUDVB0wzA==; 24:+0NejborsdCdqdti+FajHYMJUnq4JNOI6C2yxzfr/S5x9fp/0twcbvZ9boqPRONA5syOqpDGnhp3BYPGsjBK5pfjzX2ZN4gndUuW2W1VBZs= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2015 17:17:51.0145 (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.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB038 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:18:09 -0000 --_004_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_" --_000_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "One would be an enterprise IP phone that has just been deployed and wants = to acquire a new number from an IP PBX." There are two existing protocols = which spring to mind which solve this problem; MGCP and SIP. I'm sure other= s can point to other similar protocols as well (e.g., NCS). And I would a= rgue the enterprise IP phone doesn't get a new number, the IP PBX does. Th= e phone merely gets associated with the number provisioned in the IP PBX in= order to originate or terminate calls through the IP PBX. I wasn't able to attend the MODERN BoF so I'm not familiar with the many us= e cases. In your example of the VoIP service provider I have questions. H= as it been determined that there are no suitable existing number provisioni= ng or number management protocols? ESPP and TERQ spring to mind as example= s of protocols which have been previously developed by the IETF for such pu= rposes and I'm sure there are other examples as well. And is a special protocol required for this example? Numerous peering rela= tionships are managed using spreadsheets in e-mail. It may be manual, inel= egant and prone to error, but it certainly is cheap and is often used. Hav= e there been VoIP providers that have claimed they are disadvantaged becaus= e they don't have a special protocol for provisioning subtended number bloc= ks with their carrier? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: June 26, 2015 12:00 PM To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) One would be an enterprise IP phone that has just been deployed and wants t= o acquire a new number from an IP PBX. Another would be a VoIP service prov= ider who wants to receive a block of new numbers through a delegation from = a carrier. I ran through such use cases at the MODERN BoF. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" > Date: Friday, June 26, 2015 at 9:55 AM To: Jon Peterson = >, Richard Hill >, "McGarry, Tom" <= Tom.McGarry@neustar.biz>, "modern@ietf.org<= mailto:modern@ietf.org>" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) "Many use cases under consideration would not have a national regulator as = an actor." - J. Peterson I've struggled with this point. What are the "many" use cases? For exampl= e, I've not been able to envision the use case that would require a device = to use a MODERN protocol tool to acquire an RFC 3966 telephone number. Wha= t is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol= tools to manage telephone numbers? What is broken about the existing syst= em(s)? And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., = 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,= SMS800, et cetera. And the administration is distributed (in the US) at national and state lev= els. Has anyone from any of the US or international number management administra= tive organizations requested that the IETF build tools for them? If they d= on't use them, who will? And how can they integrate with an existing syste= m? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, surely the IETF is not a suitable body for = managing the DNS! And it isn't. But it is a suitable body for managing the = protocol work on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies th= ere are lots of national regulators and they worry about the sorts of thing= s you are worrying about here. The IETF just produces tools, and that is al= l MODERN proposes to do. Trying to characterize this effort otherwise is si= mply an error. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. This makes the IETF really di= fferent from places like the ITU, where the products of work have some bind= ing effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. But we're just building some p= rotocol tools. There is also related work here for ATIS to do, and I'm sure= ATIS or some other body could later take some the protocol tools developed= in the IETF and conduct an experiment with various carriers to see if it w= orks for that interest group or not, and that would be interesting informat= ion. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don't normally pa= rticipate in the IETF, for a number of reasons, including the IETF's decisi= on-making process and the fact that the IETF works in English. National reg= ulators do participate in ITU-T, for a number of reasons, including the ITU= 's decision-making process and the fact that documents are translated into = the six UN languages before they are formally approved (and some discussion= s takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warr= anted in response to these comments, and/or whether a separate response may= be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a "role" may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU= -T Recommendations (albeit sometimes implicitly), addressing the status of = a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph - "The group acknowledges ITU Plenipotentiary Conference Resolution = 133 which recognizes the existing role and sovereignty of ITU Member States= with respect to allocation and management of their country code numbering = resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding "The group's outputs would be consistent with the pr= ovisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E= .190 and the Recommendations referenced therein." >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information ... with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ________________________________ 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. ________________________________ 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_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“One would be= an enterprise IP phone that has just been deployed and wants to acquire a new number from an IP PBX.”  Ther= e are two existing protocols which spring to mind which solve this problem;= MGCP and SIP. I’m sure others can point to other similar protocols as well (e.g., NCS).   And I would argue the enterpris= e IP phone doesn’t get a new number, the IP PBX does.  The phone= merely gets associated with the number provisioned in the IP PBX in order = to originate or terminate calls through the IP PBX.

 

I wasn’t able to attend the MODER= N BoF so I’m not familiar with the many use cases.  In your exam= ple of the VoIP service provider I have questions.  Has it been determined that there are no suitable existing number provisioning or numb= er management protocols?  ESPP and TERQ spring to mind as examples of = protocols which have been previously developed by the IETF for such purpose= s and I’m sure there are other examples as well.

 

And is a special protocol required for = this example?  Numerous peering relationships are managed using spread= sheets in e-mail.  It may be manual, inelegant and prone to error, but it certainly is cheap and is often used.  Have th= ere been VoIP providers that have claimed they are disadvantaged because th= ey don’t have a special protocol for provisioning subtended number bl= ocks with their carrier?

 

Best regards,

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorm= an@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Peterson, Jon [mailto:jon.pete= rson@neustar.biz]
Sent: June 26, 2015 12:00 PM
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.= org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

One would be an enterprise IP phone tha= t has just been deployed and wants to acquire a new number from an IP PBX. = Another would be a VoIP service provider who wants to receive a block of new numbers through a delegation from a carrier. I r= an through such use cases at the MODERN BoF.

 

Jon Peterson

Neustar, Inc.

 

From: <Gorman>, "Pierce A [CTO]" <Pierce.Gorman@sprint.com> Date: Friday, June 26, 2015 at 9:55 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Richard Hill <rhill@hill-a.ch>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

“Many use cas= es under consideration would not have a national regulator as an actor.”  - J. Peterson

 

I’ve struggled with this point.&n= bsp; What are the “many” use cases?  For example, I’= ve not been able to envision the use case that would require a device to us= e a MODERN protocol tool to acquire an RFC 3966 telephone number.  What is this = use case?

 

This continues to baffle me.  Why = is the IETF proposing to develop protocol tools to manage telephone numbers= ?  What is broken about the existing system(s)?

 

And I really struggle with how this is = supposed to work because there are so many different kinds of telephone num= bers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs, IMRNs, = ported numbers, and multiple administrative databases, NPAC, LERG, SMS800, = et cetera.

 

And the administration is distributed (= in the US) at national and state levels.=

 

Has anyone from any of the US or intern= ational number management administrative organizations requested that the I= ETF build tools for them?  If they don’t use them, who will?  And how can they integrate with an existing system?  = Sorry Jon.  Still lost.<= /span>

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g0=

 

From: Modern= [mailto:modern-bounces@ietf.org= ] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; m= odern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

Your arguments here could equally well = be applied to any important resource on which the IETF does protocol work -= like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are r= esponsible for ccTLDs, surely the IETF is not a suitable body for managing = the DNS! And it isn't. But it is a suitable body for managing the protocol = work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the D= NS, and yes, at those bodies there are lots of national regulators and they= worry about the sorts of things you are worrying about here. The IETF just= produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is sim= ply an error.

 

All work at the IETF is done by a coali= tion of the willing. If it turns out that the coalition is not representati= ve of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any= time or effort were the members of that coalition. No national interests c= an possibly be harmed by that, even if the failed work involved ways of tal= king about telephone numbers. This makes the IETF really different from places like the ITU, where the produc= ts of work have some binding effect on the world.

 

Virtually all proposed work at the IETF= also faces a coalition of the unwilling. People who aren't interested, or = who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "f= ormal objection" treats the scope of the proposed work as being differ= ent than it is, and I'd agree that if this proposed work required regulator= y oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related work he= re for ATIS to do, and I'm sure ATIS or some other body could later take so= me the protocol tools developed in the IETF and conduct an experiment with = various carriers to see if it works for that interest group or not, and that would be interesting information.= But the IETF doesn't do that part, and doesn't aspire to do that part.

 

Finally, I'm not really sure how much I= would expect "national regulators" to literally use the tools pr= oposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases un= der consideration would not have a national regulator as an actor. This wor= k was in part instigated by an FCC workshop, yes, and someone associated wi= th the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy= this work - surely they would leave that to industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <mod= ern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 

Thank you for this clarification.

 

Since the intent is to create tools a= nd solutions that would be used by national regulators, presumably they sho= uld be involved in the development of the tools. 


As far as I know, national regulators from most countries don’t norma= lly participate in the IETF, for a number of reasons, including the IETF= 217;s decision-making process and the fact that the IETF works in English. = National regulators do participate in ITU-T, for a number of reasons, including the ITU’s decision-making process= and the fact that documents are translated into the six UN languages befor= e they are formally approved (and some discussions takes place with interpr= etation in six languages).

 

If the intent is to develop tools tha= t would be used only in the USA at first, then I would suggest that it woul= d be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If t= he US experience proved successful, then the tools could be proposed for ad= option elsewhere, for example through ITU-T.

 

If the intent is to develop tools for= use in many countries right at the start, then I would suggest that the ap= propriate forum would be ITU-T, not IETF, for the reasons outlined above.<= /span>

 

Thus, I formally object to the creati= on of this new working group, and this even if the Charter is modified as s= uggested below.

 

Please see additional comments inline= .

 

Thanks and best,

Richard

 

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

This effort is intended to create tools= and solutions to enable flexibility in the process of managing numbers amo= ng national administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for h= ow national administrators interact with the ITU-T.  But of course we = want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people’s thought= s on whether any charter edits may be warranted in response to these commen= ts, and/or whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:





From: "Zhang, Jie" <jie.zhang@itu.int>=

Subject: RE: [new-work] WG Review:= Managing, Ordering, Distributing, Exposing, & Registering telephone Nu= mbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.= 164.1.

 

>RH: Given the scope of the work, = I think that it is too early to say whether there would be an impact. Those= Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recog= nition of course that the changes would have to be proposed to ITI-T Study = Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes = within countries is subject to regulation.  The WG cannot make any dec= isions with regard to this.  I expect the WG to define "roles" within the number management processes; e.g., admin= istrator, telecom carrier, application provider, consumer, etc.; = and how those roles could interact with each other.  This will be a&nb= sp;baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject to= , or affect, national regulations.  That is, the definition of a ̶= 0;role” may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions= to be able to address the status of a telephone number.

 

>RH: Since the terms “assign= ed”, “spare” and “reclaimed” are defined in I= TU-T Recommendations (albeit sometimes implicitly), addressing the status o= f a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".<= /p>

We are aware of Resolution 133 and will certainly respect= it.  I would propose adding the following text after the first s= entence in the last full paragraph – "The group acknow= ledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  =

 

>RH: That certainly would be a hel= pful addition. In addition to the above, I would suggest adding “The = group’s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and= the Recommendations referenced therein.” 

 

>RH: For the sake of clarity I rei= terate that I oppose the creation of this group even if the Charter is modi= fied to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace= that would require regulatory oversight, e.g., a new TLD, SLD, etc. &= nbsp;I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say anything sp= ecific about that.  There is nothing in the charter that references .t= el.  


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify = that sentence to add the following at the end - "as well as other = ;relevant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG = names.  : )  But the charter is where to look for the scope of wo= rk.  The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information … with TNs", "associating= , acquiring and resolving TNs", "access data related to=  TNs", and "mechanisms for resolving information related to&= nbsp;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work<= /o:p>

 

 

 


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.



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_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_-- --_004_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Fri, 26 Jun 2015 17:17:47 GMT"; modification-date="Fri, 26 Jun 2015 17:17:47 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_42916ac616f94a6f8225e16c9dc83e2ePLSWE13M08adsprintcom_-- From nobody Fri Jun 26 10:43: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 AD8981A9085 for ; Fri, 26 Jun 2015 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 rvDILhs9iTI8 for ; Fri, 26 Jun 2015 10:43:28 -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 0C6BE1A9081 for ; Fri, 26 Jun 2015 10:43:27 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t5QHhFr8027904; Fri, 26 Jun 2015 13:43:24 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1v8ytvgth8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 13:43:23 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 13:43:21 -0400 From: "Peterson, Jon" To: Richard Hill , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugIAAOi1Q///ZD4A= Date: Fri, 26 Jun 2015 17:43:21 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <00c701d0b033$b327e020$1977a060$@ch> In-Reply-To: <00c701d0b033$b327e020$1977a060$@ch> 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.179] Content-Type: multipart/alternative; boundary="_000_D1B2D80D154872jonpetersonneustarbiz_" 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-06-26_06:2015-06-26,2015-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506260257 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:43:35 -0000 --_000_D1B2D80D154872jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The entire point of my raising the DNS analogy was indeed that the IETF onl= y creates the tools, not the policies, and that we're not proposing to do a= nything else here in MODERN. We know the IETF doesn't determine numbering p= olicy. No one is confused about that (well, no one advocating for MODERN, a= nyway). Furthermore, the overwhelming majority of the protocol decisions th= at the IETF makes about the DNS aren't really matters of policy. They are m= atters like choosing between two proposed ways that a particular bit-field = might be filled to enable a new application. The application in question ma= y not ultimately apply everywhere that the DNS is used, and nor do we alway= s know in advance if the application will ever have any real impact on the = world. But this is what the IETF does and where its expertise lies. Ultimately, it's why the IETF is the right place to do work like this, beca= use the proposed MODERN work is that sort of low-level protocol work. We un= derstand how to create protocols like this, how to encode them, how to secu= re them, and we have some interested vendors willing to work on implementat= ion. The MODERN work is not being designed exclusively with US interests in= mind, but like all IETF work, it will be determined by our consensus proce= ss, forged from the coalition of the willing who want to do this work - we = certainly welcome non-US involvement. Our mailing lists and process are ope= n (see OpenStand). Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 10:15 AM To: Jon Peterson = >, "McGarry, Tom" >= , "modern@ietf.org" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Dear Jon, Thank you for the thoughtful reply. Please see embedded comments below. Thanks and best, Richard From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, June 26, 2015 18:35 To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, >RH: The degree of involvement of national authorities with ccTLDs varies g= reatly, but I=92m not aware of any that regulate ccTLDs to the same extent = that telephone numbers are regulated. Further, the protocols and policies f= or the DNS were mostly developed before anybody thought that there should b= e any government involvement. And today ICANN develops most of the policies= , even if the IETF is developing the protocols. So it is not an appropriate= analogy. surely the IETF is not a suitable body for managing the DNS! >RH: The IETF does not manage the DNS. ICANN manages the DNS, to the extent= that it requires top level management. And it isn't. But it is a suitable body for managing the protocol work on t= he DNS. Other, effectively unrelated entities handle the administrative dim= ensions of operating the DNS, and yes, at those bodies there are lots of na= tional regulators and they worry about the sorts of things you are worrying= about here. The IETF just produces tools, and that is all MODERN proposes = to do. Trying to characterize this effort otherwise is simply an error. >RH: I=92m not convinced that you can develop tools that don=92t affect pol= icies. Indeed, it seems to me that the policies will condition whether cer= tain tools are useable or not. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. >RH: That is true if nobody uses the work. It is not true if some country, = say the US, adopts the outputs and then lobbies to have them adopted elsewh= ere. That can lead to serious friction and pushback. Better to involve all= concerned parties early in the game. This makes the IETF really different from places like the ITU, where the pr= oducts of work have some binding effect on the world. >RH> ITU-T Recommendations are no more (or less) binding that IETF RFCs or = ISO Standards. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. >RH: I see that we agree on the principles but not the details. I don=92t s= ee how the proposed work would not have regulatory impacts in at least some= (probably many) countries, even if it has no impact in the US. Again, if t= he idea is to develop tools that would first be used in the US, then the wo= rk should be done in a US-only body. If the idea is to develop tools that w= ould be used in many countries, then I think that the ITU-T is a more suita= ble forum. But we're just building some protocol tools. There is also related work her= e for ATIS to do, and I'm sure ATIS or some other body could later take som= e the protocol tools developed in the IETF and conduct an experiment with v= arious carriers to see if it works for that interest group or not, and that= would be interesting information. But the IETF doesn't do that part, and d= oesn't aspire to do that part. >RH: I still don=92t understand why you think that IETF is uniquely well po= sitioned to do this work. Surely nobody would suggest that the IETF should = develop standards for nuts and bolts, when ISO is doing that. So why should= the IETF develop standards (or tools) for telephone numbers when the ITU-T= is doing that? Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. >RH: That may well be true for the US, but it may well not be true in other= countries. Which is why I think that the work is better done in a forum wh= ere you are more likely to get inputs from national regulators. If the inpu= ts are of the form =93go ahead, we don=92t care=94, then that is fine. But = if you do the work in the IETF, you are not likely to get inputs from natio= nal regulators. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the= ITU=92s decision-making process and the fact that documents are translated= into the six UN languages before they are formally approved (and some disc= ussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =93role=94 may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 are de= fined in ITU-T Recommendations (albeit sometimes implicitly), addressing th= e status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =93The group=92s outputs would be consistent with th= e provisions of relevant ITU-T Recommendations, in particular E.164, E.164.= 1, E.190 and the Recommendations referenced therein.=94 >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --_000_D1B2D80D154872jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

The entire point of my raising the DNS analogy was indeed that the IET= F only creates the tools, not the policies, and that we're not proposing to= do anything else here in MODERN. We know the IETF doesn't determine number= ing policy. No one is confused about that (well, no one advocating for MODERN, anyway). Furthermore, the overwh= elming majority of the protocol decisions that the IETF makes about the DNS= aren't really matters of policy. They are matters like choosing between tw= o proposed ways that a particular bit-field might be filled to enable a new application. The application in = question may not ultimately apply everywhere that the DNS is used, and nor = do we always know in advance if the application will ever have any real imp= act on the world. But this is what the IETF does and where its expertise lies.

Ultimately, it's why the IETF is the right place to do work like this,= because the proposed MODERN work is that sort of low-level protocol work. = We understand how to create protocols like this, how to encode them, how to= secure them, and we have some interested vendors willing to work on implementation. The MODERN work is not being de= signed exclusively with US interests in mind, but like all IETF work, it wi= ll be determined by our consensus process, forged from the coalition of the= willing who want to do this work - we certainly welcome non-US involvement. Our mailing lists and process a= re open (see OpenStand).

Jon Peterson
Neustar, Inc.

From: Richard Hill <rhill@hill-a.ch>
Date: Friday, June 26, 2015 at 10:1= 5 AM
To: Jon Peterson <jon.peterson@neustar.biz>, "McGar= ry, Tom" <Tom.McGarry@ne= ustar.biz>, "modern@ietf.org= " <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-wor= k] WG Review: Managing, Ordering, Distributing, Exposing, & Registering= telephone Numbers (modern)

Dear Jon,

 

Thank you for the thoughtful reply.=

 

Please see embedded comments below.=


Thanks and best,

Richard

 

From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Friday, June 26, 2015 18:35
To: Richard Hill; McGarry, Tom; m= odern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

Your arguments here could equally well be app= lied to any important resource on which the IETF does protocol work - like,= say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities a= re responsible for ccTLDs,

 

>RH: The degree of involvement o= f national authorities with ccTLDs varies greatly, but I=92m not aware of a= ny that regulate ccTLDs to the same extent that telephone numbers are regulated. Further, the protocols and policies = for the DNS were mostly developed before anybody thought that there should = be any government involvement. And today ICANN develops most of the policie= s, even if the IETF is developing the protocols. So it is not an appropriate analogy.

 

surely the IETF is not a suitable body for ma= naging the DNS!

 

>RH: The IETF does not manage th= e DNS. ICANN manages the DNS, to the extent that it requires top level mana= gement.

 

And it isn't. But it is a suitable body for m= anaging the protocol work on the DNS. Other, effectively unrelated entities= handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national = regulators and they worry about the sorts of things you are worrying about = here. The IETF just produces tools, and that is all MODERN proposes to do. = Trying to characterize this effort otherwise is simply an error.

 

>RH: I=92m not convinced that yo= u can develop tools that don=92t affect policies.  Indeed, it seems to= me that the policies will condition whether certain tools are useable or not.

 

All work at the IETF is done by a coalition o= f the willing. If it turns out that the coalition is not representative of = the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who w= asted any time or effort were the members of that coalition. No national in= terests can possibly be harmed by that, even if the failed work involved wa= ys of talking about telephone numbers.<= /span>

 

>RH: That is true if nobody uses= the work. It is not true if some country, say the US, adopts the outputs a= nd then lobbies to have them adopted elsewhere.  That can lead to serious friction and pushback. Better to involve al= l concerned parties early in the game.

 

This makes the IETF really different from pla= ces like the ITU, where the products of work have some binding effect on th= e world.

 

>RH> ITU-T Recommendations ar= e no more (or less) binding that IETF RFCs or ISO Standards.

 

Virtually all proposed work at the IETF also = faces a coalition of the unwilling. People who aren't interested, or who th= ink the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your &quo= t;formal objection" treats the scope of the proposed work as being dif= ferent than it is, and I'd agree that if this proposed work required regula= tory oversight, that the IETF shouldn't do it.

 

>RH: I see that we agree on the = principles but not the details. I don=92t see how the proposed work would n= ot have regulatory impacts in at least some (probably many) countries, even if it has no impact in the US. Again, if t= he idea is to develop tools that would first be used in the US, then the wo= rk should be done in a US-only body. If the idea is to develop tools that w= ould be used in many countries, then I think that the ITU-T is a more suitable forum.

 

But we're just building some protocol tools. = There is also related work here for ATIS to do, and I'm sure ATIS or some o= ther body could later take some the protocol tools developed in the IETF and conduct an experiment with variou= s carriers to see if it works for that interest group or not, and that woul= d be interesting information. But the IETF doesn't do that part, and doesn'= t aspire to do that part.

 

>RH: I still don=92t understand = why you think that IETF is uniquely well positioned to do this work. Surely= nobody would suggest that the IETF should develop standards for nuts and bolts, when ISO is doing that. So why shoul= d the IETF develop standards (or tools) for telephone numbers when the ITU-= T is doing that?

 

Finally, I'm not really sure how much I would= expect "national regulators" to literally use the tools proposed= in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use = cases under consideration would not have a national regulator as an actor. = This work was in part instigated by an FCC workshop, yes, and someone assoc= iated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up serve= rs to deploy this work - surely they would leave that to industry. 

 

>RH: That may well be true for t= he US, but it may well not be true in other countries. Which is why I think= that the work is better done in a forum where you are more likely to get inputs from national regulators. If the i= nputs are of the form =93go ahead, we don=92t care=94, then that is fine. B= ut if you do the work in the IETF, you are not likely to get inputs from na= tional regulators.

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@= hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <mod= ern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

Thank you for this clarification.

 

Since the intent is to create tools= and solutions that would be used by national regulators, presumably they s= hould be involved in the development of the tools.  <= /p>


As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the ITU=92s decision-making process and= the fact that documents are translated into the six UN languages before th= ey are formally approved (and some discussions takes place with interpretat= ion in six languages).=

 

If the intent is to develop tools t= hat would be used only in the USA at first, then I would suggest that it wo= uld be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the pu= rpose. If the US experience proved successful, then the tools could be prop= osed for adoption elsewhere, for example through ITU-T.

 

If the intent is to develop tools f= or use in many countries right at the start, then I would suggest that the = appropriate forum would be ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the crea= tion of this new working group, and this even if the Charter is modified as= suggested below.

 

Please see additional comments inli= ne.

 

Thanks and best,

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

This effort is intended to create tools and = solutions to enable flexibility in the process of managing numbers among na= tional administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for h= ow national administrators interact with the ITU-T.  But of course we = want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <ali= ssa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people=92s thoughts on whet= her any charter edits may be warranted in response to these comments, and/o= r whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:




From: "Zhang, Jie" <jie.zhang@itu.int>=

Subject: RE: [new-work] WG Review: Mana= ging, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

To: "iesg@ietf.org" <iesg@ietf.org><= span style=3D"color:black">

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.164.1= .

 

>RH: Given the scope of the work= , I think that it is too early to say whether there would be an impact. Tho= se Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, = with the recognition of course that the changes would have to be proposed t= o ITI-T Study Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes withi= n countries is subject to regulation.  The WG cannot make any decision= s with regard to this.  I expect the WG to define "roles" within the number management processes; e.g.= , administrator, telecom carrier, application provider, consumer,= etc.; and how those roles could interact with each other.  This will = be a baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject = to, or affect, national regulations.  That is, the definition of a =93= role=94 may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions to be able = to address the status of a telephone number.

 

>RH: Since the terms =93assigned= =94, =93spare=94 and =93reclaimed=94 are defined in ITU-T Recommendations (= albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".<= /p>

We are aware of Resolution 133 and will certainly respect it. &n= bsp;I would propose adding the following text after the first sentence= in the last full paragraph =96 "The group acknowledges = ;ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  =

 

>RH: That certainly would be a h= elpful addition. In addition to the above, I would suggest adding =93The gr= oup=92s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1= , E.190 and the Recommendations referenced therein.=94 

 

>RH: For the sake of clarity I r= eiterate that I oppose the creation of this group even if the Charter is mo= dified to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace that= would require regulatory oversight, e.g., a new TLD, SLD, etc.  = I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say = anything specific about that.  There is nothing in the charter that re= ferences .tel.  <= /p>


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify that = sentence to add the following at the end - "as well as other rele= vant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG names= .  : )  But the charter is where to look for the scope of work. &= nbsp;The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information =85 with TNs", "associating, ac= quiring and resolving TNs", "access data related to&nbs= p;TNs", and "mechanisms for resolving information related to = ;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work<= /o:p>

 

 

 --_000_D1B2D80D154872jonpetersonneustarbiz_-- From nobody Fri Jun 26 10:50: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 BF1431A909A for ; Fri, 26 Jun 2015 10:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 0V_Am-KFoXvy for ; Fri, 26 Jun 2015 10:49:54 -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 D67C01A908C for ; Fri, 26 Jun 2015 10:49: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 t5QHiPEJ020835; Fri, 26 Jun 2015 13:49:50 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1v8ytw8tfa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2015 13:49:49 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 13:49:46 -0400 From: "Peterson, Jon" To: "Gorman, Pierce A [CTO]" , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugIAAeyuA//+L6YCAAHpegP//k5IA Date: Fri, 26 Jun 2015 17:49:45 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> In-Reply-To: <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.179] Content-Type: multipart/mixed; boundary="_004_D1B2DD5A1548D4jonpetersonneustarbiz_" 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-06-26_06:2015-06-26,2015-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506260257 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:50:03 -0000 --_004_D1B2DD5A1548D4jonpetersonneustarbiz_ Content-Type: multipart/alternative; boundary="_000_D1B2DD5A1548D4jonpetersonneustarbiz_" --_000_D1B2DD5A1548D4jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think if someone wanted to propose a SIP extension, say, that let a new p= hone acquire a semi-permanent telephone number from an IP PBX, that would b= e a candidate solution for that part of MODERN's scope. Again, we're not de= liberating about solutions now, just over whether the problem space is wort= h exploring. Also, although TeRQ was proposed, we didn't bring it to RFC, in part becaus= e we deferred forming a TeRQ working group to look at this broader problem = space. TeRQ would be a candidate protocol for fulfilling some of MODERN's s= cope as well. I don't know that MODERN will replace all forms of peering out there in the= world, and in some cases, spreadsheets surely will still be used. With a b= roader IP transition looming, I guess the idea is that we should try to bui= ld some tools that could make things a bit easier when all of this migrates= to IP. That requires some crystal-ball gazing, some informed guessing. But= even if we get it wrong, we'll probably learn some lessons that will be va= luable to the industry for the transition. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" > Date: Friday, June 26, 2015 at 10:17 AM To: Jon Peterson = >, Richard Hill >, "McGarry, Tom" <= Tom.McGarry@neustar.biz>, "modern@ietf.org<= mailto:modern@ietf.org>" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) =93One would be an enterprise IP phone that has just been deployed and want= s to acquire a new number from an IP PBX.=94 There are two existing protoc= ols which spring to mind which solve this problem; MGCP and SIP. I=92m sure= others can point to other similar protocols as well (e.g., NCS). And I w= ould argue the enterprise IP phone doesn=92t get a new number, the IP PBX d= oes. The phone merely gets associated with the number provisioned in the I= P PBX in order to originate or terminate calls through the IP PBX. I wasn=92t able to attend the MODERN BoF so I=92m not familiar with the man= y use cases. In your example of the VoIP service provider I have questions= . Has it been determined that there are no suitable existing number provis= ioning or number management protocols? ESPP and TERQ spring to mind as exa= mples of protocols which have been previously developed by the IETF for suc= h purposes and I=92m sure there are other examples as well. And is a special protocol required for this example? Numerous peering rela= tionships are managed using spreadsheets in e-mail. It may be manual, inel= egant and prone to error, but it certainly is cheap and is often used. Hav= e there been VoIP providers that have claimed they are disadvantaged becaus= e they don=92t have a special protocol for provisioning subtended number bl= ocks with their carrier? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: June 26, 2015 12:00 PM To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) One would be an enterprise IP phone that has just been deployed and wants t= o acquire a new number from an IP PBX. Another would be a VoIP service prov= ider who wants to receive a block of new numbers through a delegation from = a carrier. I ran through such use cases at the MODERN BoF. Jon Peterson Neustar, Inc. From: , "Pierce A [CTO]" > Date: Friday, June 26, 2015 at 9:55 AM To: Jon Peterson = >, Richard Hill >, "McGarry, Tom" <= Tom.McGarry@neustar.biz>, "modern@ietf.org<= mailto:modern@ietf.org>" > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) =93Many use cases under consideration would not have a national regulator a= s an actor.=94 - J. Peterson I=92ve struggled with this point. What are the =93many=94 use cases? For = example, I=92ve not been able to envision the use case that would require a= device to use a MODERN protocol tool to acquire an RFC 3966 telephone numb= er. What is this use case? This continues to baffle me. Why is the IETF proposing to develop protocol= tools to manage telephone numbers? What is broken about the existing syst= em(s)? And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., = 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,= SMS800, et cetera. And the administration is distributed (in the US) at national and state lev= els. Has anyone from any of the US or international number management administra= tive organizations requested that the IETF build tools for them? If they d= on=92t use them, who will? And how can they integrate with an existing sys= tem? Sorry Jon. Still lost. Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource= on which the IETF does protocol work - like, say, the DNS. The IETF manage= s the DNS protocol and publishes RFCs about it. But since national authorit= ies are responsible for ccTLDs, surely the IETF is not a suitable body for = managing the DNS! And it isn't. But it is a suitable body for managing the = protocol work on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies th= ere are lots of national regulators and they worry about the sorts of thing= s you are worrying about here. The IETF just produces tools, and that is al= l MODERN proposes to do. Trying to characterize this effort otherwise is si= mply an error. All work at the IETF is done by a coalition of the willing. If it turns out= that the coalition is not representative of the needs of the community, th= en what happens? Well, the work built here doesn't get used. The only peopl= e who wasted any time or effort were the members of that coalition. No nati= onal interests can possibly be harmed by that, even if the failed work invo= lved ways of talking about telephone numbers. This makes the IETF really di= fferent from places like the ITU, where the products of work have some bind= ing effect on the world. Virtually all proposed work at the IETF also faces a coalition of the unwil= ling. People who aren't interested, or who think the work should be done el= sewhere, or that the work simply shouldn't be done at all. But I maintain y= our "formal objection" treats the scope of the proposed work as being diffe= rent than it is, and I'd agree that if this proposed work required regulato= ry oversight, that the IETF shouldn't do it. But we're just building some p= rotocol tools. There is also related work here for ATIS to do, and I'm sure= ATIS or some other body could later take some the protocol tools developed= in the IETF and conduct an experiment with various carriers to see if it w= orks for that interest group or not, and that would be interesting informat= ion. But the IETF doesn't do that part, and doesn't aspire to do that part. Finally, I'm not really sure how much I would expect "national regulators" = to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Man= y use cases under consideration would not have a national regulator as an a= ctor. This work was in part instigated by an FCC workshop, yes, and someone= associated with the FCC spoke at the MODERN BoF. But I don't anticipate th= at the FCC would be propping up servers to deploy this work - surely they w= ould leave that to industry. Jon Peterson Neustar, Inc. From: Richard Hill > Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" = >, "modern@ietf.org" > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the= ITU=92s decision-making process and the fact that documents are translated= into the six UN languages before they are formally approved (and some disc= ussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =93role=94 may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 are de= fined in ITU-T Recommendations (albeit sometimes implicitly), addressing th= e status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =93The group=92s outputs would be consistent with th= e provisions of relevant ITU-T Recommendations, in particular E.164, E.164.= 1, E.190 and the Recommendations referenced therein.=94 >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ________________________________ 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. ________________________________ 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_D1B2DD5A1548D4jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E2EE59AD3EFD64D8BBFB8EDFFB518BE@neustar.biz> Content-Transfer-Encoding: quoted-printable

I think if someone wanted to propose a SIP extension, say, that let a = new phone acquire a semi-permanent telephone number from an IP PBX, that wo= uld be a candidate solution for that part of MODERN's scope. Again, we're n= ot deliberating about solutions now, just over whether the problem space is worth exploring.

Also, although TeRQ was proposed, we didn't bring it to RFC, in part b= ecause we deferred forming a TeRQ working group to look at this broader pro= blem space. TeRQ would be a candidate protocol for fulfilling some of MODER= N's scope as well.

I don't know that MODERN will replace all forms of peering out there i= n the world, and in some cases, spreadsheets surely will still be used. Wit= h a broader IP transition looming, I guess the idea is that we should try t= o build some tools that could make things a bit easier when all of this migrates to IP. That requires some cr= ystal-ball gazing, some informed guessing. But even if we get it wrong, we'= ll probably learn some lessons that will be valuable to the industry for th= e transition. 

Jon Peterson
Neustar, Inc.

From: <Gorman>, "Pierce = A [CTO]" <Pierce.Gorman= @sprint.com>
Date: Friday, June 26, 2015 at 10:1= 7 AM
To: Jon Peterson <jon.peterson@neustar.biz>, Richard Hil= l <rhill@hill-a.ch>, "McG= arry, Tom" <Tom.McGarry@= neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-wor= k] WG Review: Managing, Ordering, Distributing, Exposing, & Registering= telephone Numbers (modern)

=93One would be an enter= prise IP phone that has just been deployed and wants to acquire a new number from an IP PBX.=94&n= bsp; There are two existing protocols which spring to mind which solve this= problem; MGCP and SIP. I=92m sure others can point to other similar protocols as well (e.g., NCS).   And I wo= uld argue the enterprise IP phone doesn=92t get a new number, the IP PBX do= es.  The phone merely gets associated with the number provisioned in t= he IP PBX in order to originate or terminate calls through the IP PBX.

 

I wasn=92t able to attend the MODERN Bo= F so I=92m not familiar with the many use cases.  In your example of t= he VoIP service provider I have questions.  Has it been determined that there are no suitable existing number provisioning= or number management protocols?  ESPP and TERQ spring to mind as exam= ples of protocols which have been previously developed by the IETF for such= purposes and I=92m sure there are other examples as well.

 

And is a special protocol required for = this example?  Numerous peering relationships are managed using spread= sheets in e-mail.  It may be manual, inelegant and prone to error, but it certainly is cheap and is often used.  Hav= e there been VoIP providers that have claimed they are disadvantaged becaus= e they don=92t have a special protocol for provisioning subtended number bl= ocks with their carrier?

 

Best regards,

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: June 26, 2015 12:00 PM
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

 

One would be an enterprise IP phone that has= just been deployed and wants to acquire a new number from an IP PBX. Anoth= er would be a VoIP service provider who wants to receive a block of new numbers through a delegation from a ca= rrier. I ran through such use cases at the MODERN BoF.

 

Jon Peterson

Neustar, Inc.

 

From: <Gorman>, "Pierce A [CTO]" <Pierce.Gorman@sprint.com>
Date: Friday, June 26, 2015 at 9:55 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Richard Hill <rhill@hill-a.ch>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)<= /o:p>

 

=93Many use cases under = consideration would not have a national regulator as an actor.=94  - J. Peterson

 

I=92ve struggled with this point. = What are the =93many=94 use cases?  For example, I=92ve not been able= to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number.&nbs= p; What is this use case?

 

This continues to baffle me.  Why = is the IETF proposing to develop protocol tools to manage telephone numbers= ?  What is broken about the existing system(s)?

 

And I really struggle with how this is = supposed to work because there are so many different kinds of telephone num= bers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDN= s, IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG= , SMS800, et cetera.

 

And the administration is distributed (= in the US) at national and state levels.=

 

Has anyone from any of the US or intern= ational number management administrative organizations requested that the I= ETF build tools for them?  If they don=92t use them, who will?  And how can they integrate with an existing syst= em?  Sorry Jon.  Still lost.

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g0=

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; m= odern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

Your arguments here could equally well be ap= plied to any important resource on which the IETF does protocol work - like= , say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities a= re responsible for ccTLDs, surely the IETF is not a suitable body for manag= ing the DNS! And it isn't. But it is a suitable body for managing the proto= col work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the D= NS, and yes, at those bodies there are lots of national regulators and they= worry about the sorts of things you are worrying about here. The IETF just= produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is sim= ply an error.

 

All work at the IETF is done by a coalition = of the willing. If it turns out that the coalition is not representative of= the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who w= asted any time or effort were the members of that coalition. No national in= terests can possibly be harmed by that, even if the failed work involved wa= ys of talking about telephone numbers. This makes the IETF really different from places like the ITU, where the p= roducts of work have some binding effect on the world.

 

Virtually all proposed work at the IETF also= faces a coalition of the unwilling. People who aren't interested, or who t= hink the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your &quo= t;formal objection" treats the scope of the proposed work as being dif= ferent than it is, and I'd agree that if this proposed work required regula= tory oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related wor= k here for ATIS to do, and I'm sure ATIS or some other body could later tak= e some the protocol tools developed in the IETF and conduct an experiment w= ith various carriers to see if it works for that interest group or not, and that would be interesting inform= ation. But the IETF doesn't do that part, and doesn't aspire to do that par= t.

 

Finally, I'm not really sure how much I woul= d expect "national regulators" to literally use the tools propose= d in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many us= e cases under consideration would not have a national regulator as an actor= . This work was in part instigated by an FCC workshop, yes, and someone ass= ociated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up serve= rs to deploy this work - surely they would leave that to industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@= hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <mod= ern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 

Thank you for this clarification.

 

Since the intent is to create tools= and solutions that would be used by national regulators, presumably they s= hould be involved in the development of the tools.  <= /p>


As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the ITU=92s decision-making process and= the fact that documents are translated into the six UN languages before th= ey are formally approved (and some discussions takes place with interpretat= ion in six languages).=

 

If the intent is to develop tools t= hat would be used only in the USA at first, then I would suggest that it wo= uld be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the pu= rpose. If the US experience proved successful, then the tools could be prop= osed for adoption elsewhere, for example through ITU-T.

 

If the intent is to develop tools f= or use in many countries right at the start, then I would suggest that the = appropriate forum would be ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the crea= tion of this new working group, and this even if the Charter is modified as= suggested below.

 

Please see additional comments inli= ne.

 

Thanks and best,

Richard

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,= Distributing, Exposing, & Registering telephone Numbers (modern)

 =

 

This effort is intended to create tools and = solutions to enable flexibility in the process of managing numbers among na= tional administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for h= ow national administrators interact with the ITU-T.  But of course we = want your input and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <ali= ssa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people=92s thoughts on whet= her any charter edits may be warranted in response to these comments, and/o= r whether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:





From: "Zhang, Jie" <jie.zhang@itu.int>=

Subject: RE: [new-work] WG Review: Mana= ging, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

To: "iesg@ietf.org" <iesg@ietf.org><= span style=3D"color:black">

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.164.1= .

 

>RH: Given the scope of the work= , I think that it is too early to say whether there would be an impact. Tho= se Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, = with the recognition of course that the changes would have to be proposed t= o ITI-T Study Group 2 and agreed by that group.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes withi= n countries is subject to regulation.  The WG cannot make any decision= s with regard to this.  I expect the WG to define "roles" within the number management processes; e.g.= , administrator, telecom carrier, application provider, consumer,= etc.; and how those roles could interact with each other.  This will = be a baseline for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even that might be subject = to, or affect, national regulations.  That is, the definition of a =93= role=94 may well depend on national regulations.


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions to be able = to address the status of a telephone number.

 

>RH: Since the terms =93assigned= =94, =93spare=94 and =93reclaimed=94 are defined in ITU-T Recommendations (= albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".<= /p>

We are aware of Resolution 133 and will certainly respect it. &n= bsp;I would propose adding the following text after the first sentence= in the last full paragraph =96 "The group acknowledges = ;ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  =

 

>RH: That certainly would be a h= elpful addition. In addition to the above, I would suggest adding =93The gr= oup=92s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1= , E.190 and the Recommendations referenced therein.=94 

 

>RH: For the sake of clarity I r= eiterate that I oppose the creation of this group even if the Charter is mo= dified to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace that= would require regulatory oversight, e.g., a new TLD, SLD, etc.  = I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say = anything specific about that.  There is nothing in the charter that re= ferences .tel.  <= /p>


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify that = sentence to add the following at the end - "as well as other rele= vant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG names= .  : )  But the charter is where to look for the scope of work. &= nbsp;The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information =85 with TNs", "associating, ac= quiring and resolving TNs", "access data related to&nbs= p;TNs", and "mechanisms for resolving information related to = ;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work<= /o:p>

 

 

 


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.



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_D1B2DD5A1548D4jonpetersonneustarbiz_-- --_004_D1B2DD5A1548D4jonpetersonneustarbiz_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=5171; creation-date="Fri, 26 Jun 2015 17:49:45 GMT"; modification-date="Fri, 26 Jun 2015 17:49: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_D1B2DD5A1548D4jonpetersonneustarbiz_-- From nobody Fri Jun 26 10:52:57 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25031A90AD for ; Fri, 26 Jun 2015 10:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_BASE64_BLANKS=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 9o3nWWvvLfGP for ; Fri, 26 Jun 2015 10:52:43 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 898561A90B6 for ; Fri, 26 Jun 2015 10:52:39 -0700 (PDT) Received: (qmail 13122 invoked by uid 0); 26 Jun 2015 17:52:31 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 26 Jun 2015 17:52:31 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id l5N01q00D1MNPNq015N3Ll; Fri, 26 Jun 2015 11:22:10 -0600 X-Authority-Analysis: v=2.1 cv=ALgDonD0 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=sNEldo0-0YMA:10 a=IYETQKA4aJkA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=hZG83p_yAAAA:8 a=UqAplN6HAAAA:8 a=yakATiurAAAA:8 a=qb5AeoveEj9_vRKy0AYA:9 a=fXH3lMBJ42S_-c2q:21 a=DZbCQG10rFuXbDkC:21 a=wPNLvfGTeEIA:10 a=DzjOOp_o1eYA:10 a=kkUMZHjH4KkA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=5qHAxTPpvGyLm7KCZycA:9 a=c6PcdC7AMBajFKTI:21 a=KMSyyVF-RjcN2eQv:21 a=2C26eYgu42FFWfOc: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=ol2vjKWkTENp/qRRUuq3rw6+cgwTPBH+xkMuqRw7jRU=; b=VfLTSsrdpFMzyezGiXT6H/FlpjH7On/RFp/wnqsbdTFXpzKXLPjT6J/z96GI+PdoyCOixkR4fo/IeGsOMwH2re+aPg3krdH7DV3gqHZ75DQbLJSdDJyNhQ7QUwusurz3; Received: from [100.36.26.202] (port=58157 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z8XUC-0005ri-Kx; Fri, 26 Jun 2015 11:32:21 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Fri, 26 Jun 2015 13:32:14 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , "Peterson, Jon" , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3518170340_750263" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 17:52:55 -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_3518170340_750263 Content-type: multipart/alternative; boundary="B_3518170340_739501" --B_3518170340_739501 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable In line. From: Modern on behalf of "Pierce.Gorman@sprint.com" Date: Friday, June 26, 2015 at 12:55 PM To: "Peterson, Jon" , Richard Hill , "McGarry, Tom" , "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) =B3Many use cases under consideration would not have a national regulator as an actor.=B2 - J. Peterson =20 I=B9ve struggled with this point. What are the =B3many=B2 use cases? For example, I=B9ve not been able to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number. What is this use case? =20 This continues to baffle me. Why is the IETF proposing to develop protocol tools to manage telephone numbers? What is broken about the existing system(s)? =20 And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG, SMS800, et cetera. =20 And the administration is distributed (in the US) at national and state levels. =20 Has anyone from any of the US or international number management administrative organizations requested that the IETF build tools for them? RS > Excellent point as you well know there has not been any formal communication from the NANC ( the US FAC ) to the IETF on this issue. The IETF as we all know does actually respond to regulatory requests ..if you look at nearly all of the PROVREG and WHOIS issues they are in direct response to ICANN requests or mandates. I can testify to the fact that some other NRA=B9s are interested in new ideas about number administration and they are desperate to first find solutions to the robocall spoofing problems but each jurisdiction is at various point= s in the overall PSTN Transition and it is not clear a US centric solution would be appropriate. That said there was universal consensus that the STIR proposition was neede= d and the IETF was the only appropriate body to revise 4474 in order to enabl= e a PKI infrastructure but beyond 4474bis I think there will need to be some debate on how NRA=B9s actually attempt to implement the protocol and design the PKI system. If they don=B9t use them, who will? And how can they integrate with an existing system? Sorry Jon. Still lost. =20 =20 Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: June 26, 2015 11:35 AM To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) =20 =20 Your arguments here could equally well be applied to any important resource on which the IETF does protocol work - like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authoritie= s are responsible for ccTLDs, surely the IETF is not a suitable body for managing the DNS! And it isn't. But it is a suitable body for managing the protocol work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sorts of things you are worrying about here. The IETF just produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is simply an error. =20 All work at the IETF is done by a coalition of the willing. If it turns out that the coalition is not representative of the needs of the community, the= n what happens? Well, the work built here doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly be harmed by that, even if the failed work involved ways of talking about telephone numbers. This makes the IETF reall= y different from places like the ITU, where the products of work have some binding effect on the world. =20 Virtually all proposed work at the IETF also faces a coalition of the unwilling. People who aren't interested, or who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agree that if this proposed work required regulatory oversight, that the IETF shouldn't do it. But we're jus= t building some protocol tools. There is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol tools developed in the IETF and conduct an experiment with various carriers to see if it works for that interest group or not, and that would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part. =20 Finally, I'm not really sure how much I would expect "national regulators" to literally use the tools proposed in this work. They are tools for the us= e of a diverse industry of enterprises, carriers, end users, and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part instigated by an FCC workshop, yes, and someon= e associated with the FCC spoke at the MODERN BoF. But I don't anticipate tha= t the FCC would be propping up servers to deploy this work - surely they woul= d leave that to industry. =20 Jon Peterson Neustar, Inc. =20 From: Richard Hill Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" , "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) =20 Thank you for this clarification. =20 Since the intent is to create tools and solutions that would be used by national regulators, presumably they should be involved in the development of the tools.=20 As far as I know, national regulators from most countries don=B9t normally participate in the IETF, for a number of reasons, including the IETF=B9s decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU=B9s decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages). =20 If the intent is to develop tools that would be used only in the USA at first, then I would suggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for th= e purpose. If the US experience proved successful, then the tools could be proposed for adoption elsewhere, for example through ITU-T. =20 If the intent is to develop tools for use in many countries right at the start, then I would suggest that the appropriate forum would be ITU-T, not IETF, for the reasons outlined above. =20 Thus, I formally object to the creation of this new working group, and this even if the Charter is modified as suggested below. =20 Please see additional comments inline. =20 Thanks and best, Richard =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) =20 =20 This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers. Entities can choose to use these tools or not. These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T. But of course we want your input and feedback, so thanks for sending this along. More comments in line below. =20 =20 From: Alissa Cooper Date: Thursday, June 25, 2015 7:44 AM To: Modern List Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) =20 Would appreciate people=B9s thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. =20 Alissa =20 Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" > Dear Sir/Madam, >=20 > Below please find comments from the ITU Telecommunication Standardization > Bureau on the proposed IETF working group MODERN. >=20 > 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 > It is stated at the beginning of the Charter that the MODERN working grou= p > will define a set of Internet-based mechanisms for the purposes of managi= ng > and resolving telephone numbers (TNs) in an IP environment. And it is > mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone > Numbers". Does that mean the mechanism being referred to here only deals = with > Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.16= 4.1 > which are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. =20 >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with= the recognition of course that the changes would have to be proposed to ITI-T S= tudy Group 2 and agreed by that group. >=20 >=20 > 2. Entities participating in the defined mechanisms > The Charter states that the protocol mechanism for resolving TNs will all= ow > entities such as service providers, devices, and applications to access d= ata > related to TNs. But it is not clear what kind of entities can participate= in > the mechanisms defined by this MODERN working group. Would it be restrict= ed to > the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regulation. The WG cannot make any decisions with regard to this. I expec= t the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other. This will be a baseline fo= r what tools and solutions would be useful to facilitate those interactions. =20 >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =B3role=B2 may well depend on national regulations. >=20 >=20 > 3. Status of Telephone numbers in the defined mechanisms > Several operations related to TNs are mentioned in the Charter, including > requesting, acquiring, resolving and associating. It is also stated that = the > protocol mechanism for acquiring TNs will provide an enrollment process f= or > the entities that use and manage TNs. Does that mean Telephone numbers wi= th > various status, such as assigned, spare and reclaimed numbers will all be > managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a telephone number. =20 >RH: Since the terms =B3assigned=B2, =B3spare=B2 and =B3reclaimed=B2 are defined in ITU= -T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1. >=20 >=20 > 4. Regulatory issues > The Charter states that Solutions and mechanisms created by the working g= roup > will be flexible enough to accommodate different policies for TN assignme= nt > and management, for example those established by different regulatory > agencies. We would like to bring your attention to the fact that the E.16= 4 > international public telecommunication numbering plan is a politically > significant numbering resource with direct implications on national > sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2= 014) > recognized "the existing role and sovereignty of ITU Member States with > respect to allocation and management of their country code numbering reso= urces > as enshrined in Recommendation ITU-T E.164", and further instructed the I= TU > Secretary-General and the Directors of three Bureaux (Telecommunication > Standardization, Development, and Radiocommunication) to "take any necess= ary > action to ensure the sovereignty of ITU Member States with regard to > Recommendation ITU-T E.164 numbering plans whatever the application in wh= ich > they are used". We are aware of Resolution 133 and will certainly respect it. I would propose adding the following text after the first sentence in the last full paragraph =AD "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164." =20 >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =B3The group=B9s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein.=B2 =20 >RH: For the sake of clarity I reiterate that I oppose the creation of this group even if the Charter is modified to include the text above. =20 >=20 >=20 > 5. Relationship with .Tel > DNS-based use of international numbering resources has been discussed in = ITU-T > Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Direct= or > has also exchanged letters with ICANN on issues related to registering di= git > strings in the .TEL domain. A representative from ICANN participated in t= he > ITU-T SG2 meeting (28 May - June 2014) and provided some background on th= e > TELNIC application. A correspondence group under ITU-T SG2 was also set u= p in > this regard. We would like to know how the work of this new WG would rela= te to > issues related to registering digit strings in the .TEL domain and other > DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveragin= g existing namespaces as part of proposed solutions. But it's too early to say anything specific about that. There is nothing in the charter that references .tel. =20 >=20 >=20 > 6. Relationship with related existing or concluded WGs > It is stated in the Charter that the working group will take into > consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and > SCIM. Detailed description of the relationship between this new WG and th= e > above mentioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." >=20 >=20 > 7. The name of this new WG > The name of this new WG is "Managing, Ordering, Distributing, Exposing, & > Registering telephone Numbers (modern)". But in the Charter, ordering, > exposing and registering TNs are not mentioned, which seems to be a littl= e bit > inconsistent. The IETF often has fun with creating WG names. : ) But the charter is where to look for the scope of work. The charter uses the following phrase= s "distribution, acquisition and management of TNs", "functions involved in associating information =8A with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs". The functions you believe were left out of th= e charter will be part of one or more of these processes. >=20 >=20 >=20 > Best regards, >=20 > Jie Zhang > Advisor, ITU-T SG2 > International Telecommunication Union > Place des Nations > CH-1211 Geneva , Switzerland > Tel :+41 22 730 5855 > jie.zhang@itu.int > www.itu.int > www.itu150.org >=20 >=20 > -----Original Message----- > From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, June 12, 2015 8:47 PM > To: new-work@ietf.org > Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing= , & > Registering telephone Numbers (modern) >=20 > A new IETF working group has been proposed in the Applications and Real-T= ime > Area. The IESG has not made any determination yet. The following draft ch= arter > was submitted, and is provided for informational purposes only. Please se= nd > your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. >=20 > Managing, Ordering, Distributing, Exposing, & Registering telephone Numbe= rs > (modern) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Chairs: > Tom McGarry > Steve Donovan >=20 > Assigned Area Director: > Alissa Cooper >=20 > Mailing list > Address: modern@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/modern > Archive: http://www.ietf.org/mail-archive/web/modern/ >=20 > Charter: >=20 > The MODERN working group will define a set of Internet-based mechanisms f= or > the purposes of managing and resolving telephone numbers (TNs) in an IP > environment. Devices, applications, and network tools increasingly need t= o > manage TNs, including requesting and acquiring TN delegations from > authorities. The output of the working group should make distribution, > acquisition, and management of TNs simpler for all entities involved. >=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 identify protocol > mechanisms to support the interactions between the functions defined by t= he > framework. This includes either recommending or defining protocol mechani= sms > for acquiring, associating and resolving TNs, with a preference for use o= f > existing protocol mechanisms. TNs may either be managed in a hierarchical > tree, or in a distributed registry. The protocol mechanism for acquiring = TNs > will provide an enrollment process for the entities that use and manage T= Ns. >=20 > The protocol mechanism for resolving TNs will allow entities such as serv= ice > providers, devices, and applications to access data related to TNs. > Maintaining reliability, real-time application performance, and security = and > privacy for both the data and the protocol interactions are primary > considerations. The working group will take into consideration existing I= ETF > work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. >=20 > The work of this group will focus on TNs, as defined in RFC3966, and bloc= ks of > TNs, that are used to initiate communication with another user of a servi= ce. > There is an expectation that aspects of the architecture and protocols de= fined > 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 MO= DERN > working group. Solutions and mechanisms created by the working group will= be > flexible enough to accommodate different policies for TN assignment and > management, for example those established by different regulatory agencie= s. >=20 > The working group will deliver the following: >=20 > - An architecture overview, including high level requirements and > security/privacy considerations >=20 > - A description of the enrollment processes for existing and new TNs incl= uding > any modifications to metadata related to those TNs >=20 > - A description of protocol mechanisms for accessing contact information > associated with enrollments >=20 > - A description of mechanisms for resolving information related to TNs >=20 > Milestones: >=20 > TBD >=20 > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work > =20 =20 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 th= e 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 --B_3518170340_739501 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

In line.

From: Modern <modern-bounces@ietf.o= rg> on behalf of "Pierce.Go= rman@sprint.com" <Pierce.Go= rman@sprint.com>
Date: Frid= ay, June 26, 2015 at 12:55 PM
To: = "Peterson, Jon" <jon.peterson@n= eustar.biz>, Richard Hill <rhill@= hill-a.ch>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern= @ietf.org" <modern@ietf.org><= br>Subject: Re: [Modern] Fwd: [new-wo= rk] WG Review: Managing, Ordering, Distributing, Exposing, & Registering= telephone Numbers (modern)

“<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; color: blac= k;">Many use cases under consideration would not have a national regulator a= s an actor.”  - J. Peterson

 

I’ve struggled with this point.  What are the “= many” use cases?  For example, I’ve not been able to envisi= on the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number.  What is this = use case?

 

This continues to baffle me.&nb= sp; Why is the IETF proposing to develop protocol tools to manage telephone = numbers?  What is broken about the existing system(s)?

 

And I really struggle with how this is supposed to work b= ecause there are so many different kinds of telephone numbers such as servic= e numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs, IMRNs, = ported numbers, and multiple administrative databases, NPAC, LERG, SMS800, e= t cetera.

 

And the administration is distr= ibuted (in the US) at national and state levels.

 

Has anyone from any of the US or international number management adm= inistrative organizations requested that the IETF build tools for them? = ;


RS > Excellent p= oint as you well know there has not been any formal communication from the N= ANC ( the US FAC ) to the IETF on this issue.  The IETF as we all know = does actually respond to regulatory requests ..if you look at nearly all of = the PROVREG and WHOIS issues they are in direct response to ICANN requests o= r mandates. 

I can testify to the fact that so= me other NRA’s are interested in new ideas about number administration= and they are desperate to first  find solutions to the robocall spoofi= ng problems but each jurisdiction is at various points in the overall PSTN T= ransition and it is not clear a US centric solution would be appropriate.&nb= sp;

That said there was universal consensus that th= e STIR proposition was needed and the IETF was the only appropriate body to = revise 4474 in order to enable a PKI infrastructure but beyond 4474bis I thi= nk there will need to be some debate on how NRA’s actually attempt to = implement the protocol and design the PKI system.

<= br>

If they don’t use them, who will?  And how can they integrate with an existing system?  = Sorry Jon.  Still lost.

=  

&n= bsp;

Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

=

 

=

From: Modern [mailto:m= odern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AMTo: Richard Hill; McGarry, Tom; mod= ern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: = Managing, Ordering, Distributing, Exposing, & Registering telephone Numb= ers (modern)

&nbs= p;

 

Your arguments here could equally well be ap= plied to any important resource on which the IETF does protocol work - like,= say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are r= esponsible for ccTLDs, surely the IETF is not a suitable body for managing t= he DNS! And it isn't. But it is a suitable body for managing the protocol wo= rk on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the D= NS, and yes, at those bodies there are lots of national regulators and they = worry about the sorts of things you are worrying about here. The IETF just p= roduces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is sim= ply an error.

 

All work a= t the IETF is done by a coalition of the willing. If it turns out that the c= oalition is not representative of the needs of the community, then what happ= ens? Well, the work built here doesn't get used. The only people who wasted any= time or effort were the members of that coalition. No national interests ca= n possibly be harmed by that, even if the failed work involved ways of talki= ng about telephone numbers. This makes the IETF really different from places like the ITU, where the produc= ts of work have some binding effect on the world.

 

Virtually all proposed work at the IETF also faces a co= alition of the unwilling. People who aren't interested, or who think the wor= k should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal= objection" treats the scope of the proposed work as being different than it= is, and I'd agree that if this proposed work required regulatory oversight,= that the IETF shouldn't do it. But we're just building some protocol tools. There is also related work he= re for ATIS to do, and I'm sure ATIS or some other body could later take som= e the protocol tools developed in the IETF and conduct an experiment with va= rious carriers to see if it works for that interest group or not, and that would be interesting information.= But the IETF doesn't do that part, and doesn't aspire to do that part.=

 

Finally, I'm not really sur= e how much I would expect "national regulators" to literally use the tools p= roposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases un= der consideration would not have a national regulator as an actor. This work= was in part instigated by an FCC workshop, yes, and someone associated with= the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy= this work - surely they would leave that to industry. 

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@hill-= a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: = "McGarry, Tom" <Tom.McGarry@neus= tar.biz>, "modern@ietf.org" <= modern@ietf.org>
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Ex= posing, & Registering telephone Numbers (modern)

 

Thank you for this clarification.

 

Since the intent is to create tools and solutio= ns that would be used by national regulators, presumably they should be invo= lved in the development of the tools. 


As far as I know, national regulators from most countries don’t norma= lly participate in the IETF, for a number of reasons, including the IETFR= 17;s decision-making process and the fact that the IETF works in English. Na= tional regulators do participate in ITU-T, for a number of reasons, including the ITU’s decision-making process= and the fact that documents are translated into the six UN languages before= they are formally approved (and some discussions takes place with interpret= ation in six languages).<= /p>

 

If the intent is t= o develop tools that would be used only in the USA at first, then I would su= ggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If t= he US experience proved successful, then the tools could be proposed for ado= ption elsewhere, for example through ITU-T.=

 

If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IET= F, for the reasons outlined above.

 

Thus, I forma= lly object to the creation of this new working group, and this even if the C= harter is modified as suggested below.=

 

Plea= se see additional comments inline.

 

Thanks a= nd best,

Richard

 

From: Modern [mailto:modern-b= ounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00= :31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Di= stributing, Exposing, & Registering telephone Numbers (modern)

 

 

This effort is intended to create tools and= solutions to enable flexibility in the process of managing numbers among na= tional administrators, service and application providers, and consumers.  Entities can choose to use these tools or = not.  These tools are not for the ITU-T's processes or role, nor for ho= w national administrators interact with the ITU-T.  But of course we wa= nt your input and feedback, so thanks for sending this along.  More comments in line below.  

 = ;

 

From: Alissa Cooper <alissa@c= ooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: = Modern List <modern@ietf.org>=
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern)<= span style=3D"color:black">

 

<= div>

Would appreciate people’s thoughts = on whether any charter edits may be warranted in response to these comments,= and/or whether a separate response may be useful for addressing some of the questions below.

 

 <= /p>

Begin forwarded message:



From: "Zhang, Jie" <jie.z= hang@itu.int>

<= /div>

Subject: RE: [new-work] WG Review: = Managing, Ordering, Distributing, Exposing, & Registering telephone Numb= ers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

To:= "iesg@ietf.org" <iesg@ietf.org>

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear= Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendation = ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is mentio= ned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism bei= ng referred to here only deals with Tel URI? Would there be any impact on Re= commendation ITU-E E.164 and E.164.1 which are core recommendations on Telep= hone Numbers?

There will be no impacts on E.164 a= nd E.164.1.

 <= /span>

>RH: Given the scope of the = work, I think that it is too early to say whether there would be an impact. = Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recog= nition of course that the changes would have to be proposed to ITI-T Study G= roup 2 and agreed by that group.=


2. Entities participating in the define= d mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access dat= a related to TNs. But it is not clear what kind of entities can participate = in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participate= s in numbering processes within countries is subject to regulation.  Th= e WG cannot make any decisions with regard to this.  I expect the = WG to define "roles" within the number management processes; e.g., administrator, = telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other.  This will be a baseline&= nbsp;for what tools and solutions would be useful to facilitate those interactions.  

 

>RH: Even t= hat might be subject to, or affect, national regulations.  That is, the= definition of a “role” may well depend on national regulations.=

3. Status of Telephone numbers in the d= efined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the = protocol mechanism for acquiring TNs will provide an enrollment process for = the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms defined= by the MODERN working group?

I would expect propose= d solutions to be able to address the status of a telephone number.

 

>RH: Since the terms “assigned”, = 220;spare” and “reclaimed” are defined in ITU-T Recommenda= tions (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignme= nt and management, for example those established by different regulatory age= ncies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with d= irect implications on national sovereignty. ITU Plenipotentiary Conference R= esolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with re= spect to allocation and management of their country code numbering resources= as enshrined in Recommendation ITU-T E.164", and further instructed the ITU= Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignty of I= TU Member States with regard to Recommendation ITU-T E.164 numbering plans w= hatever the application in which they are used".

We are aware of Resolution 133 and will certainly = respect it.  I would propose adding the following text after the f= irst sentence in the last full paragraph – "The group acknow= ledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and manag= ement of their country code numbering resources as enshrined in Recomme= ndation ITU-T E.164."  

 

>RH: That c= ertainly would be a helpful addition. In addition to the above, I would sugg= est adding “The group’s outputs would be consistent with the pro= visions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and= the Recommendations referenced therein.” 

 

=

>RH: For the sake of clarity I reitera= te that I oppose the creation of this group even if the Charter is modified = to include the text above.

 


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Direc= tor has also exchanged letters with ICANN on issues related to registering d= igit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corre= spondence group under ITU-T SG2 was also set up in this regard. We would lik= e to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.

The WG will not create any new namespace that would require regulat= ory oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule ou= t the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say anything sp= ecific about that.  There is nothing in the charter that references .te= l.  

<= blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">


6. Relationship with related existing o= r concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. De= tailed description of the relationship between this new WG and the above men= tioned other existing or concluded WGs would be appreciated.

I agree.  I=  would modify that sentence to add the following at the end - "as well = as other relevant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing, &am= p; Registering telephone Numbers (modern)". But in the Charter, ordering, ex= posing and registering TNs are not mentioned, which seems to be a little bit= inconsistent.

The IETF often has fun with creati= ng WG names.  : )  But the charter is where to look for the scope = of work.  The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associatin= g information … with TNs", "associating, acquiring and = resolving TNs", "access data related to TNs", and "mechanisms for = resolving information related to TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  

<= blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.in= t
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-work-= bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft cha= rter was submitted, and is provided for informational purposes only. Please = send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@= neustar.biz>
 Steve Donovan <srdonovan= @usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.i= n>

Mailing list
 Address: modern@ietf.org  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: = http://www.ietf.org/mail-archive/web/modern/

Charter:

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 env= ironment. Devices, applications, and network tools increasingly need to mana= ge TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for al= l entities involved.

The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs = in an IP environment.  The working group will also identify protocol me= chanisms to support the interactions between the functions defined by the framework. This includes either recom= mending or defining protocol mechanisms for acquiring, associating and resol= ving TNs, with a preference for use of existing protocol mechanisms. TNs may= either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage T= Ns. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Mainta= ining reliability, real-time application performance, and security and priva= cy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, 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 serv= ice. 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 reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solut= ions and mechanisms created by the working group will be flexible enough to = accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs
<= br> Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.o= rg
https://w= ww.ietf.org/mailman/listinfo/new-work

=

 

 =



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 t= he intended recipient, please contact the sender and delete all copies of th= e message.
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3518170340_739501-- --B_3518170340_750263 Content-type: image/png; name="image001.png" Content-ID: Content-disposition: inline; filename="image001.png" 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_3518170340_750263-- From nobody Fri Jun 26 11:19: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 5D7AD1A90AB for ; Fri, 26 Jun 2015 11:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 SNEwIznIRQW6 for ; Fri, 26 Jun 2015 11:18:43 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 180061A90B4 for ; Fri, 26 Jun 2015 11:18:39 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QIIb4h015365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 20:18:37 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QIIZds023441; Fri, 26 Jun 2015 20:18:36 +0200 From: "Richard Hill" To: "'Peterson, Jon'" , "'McGarry, Tom'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <00c701d0b033$b327e020$1977a060$@ch> In-Reply-To: Date: Fri, 26 Jun 2015 20:18:36 +0200 Message-ID: <016701d0b03c$854df730$8fe9e590$@ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0168_01D0B04D.48D6C730" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxEOhQnvTf5r0GIPBAfUM7OgZ2+EeCAgAEW4ID//6JugIAAOi1Q///ZD4CAADfm8A== Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 18:18:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0168_01D0B04D.48D6C730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Jon, Thank you for this and please see inline comments below. Thanks and best, Richard From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, June 26, 2015 19:43 To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) The entire point of my raising the DNS analogy was indeed that the IETF only creates the tools, not the policies, and that we're not proposing to do anything else here in MODERN. We know the IETF doesn't determine numbering policy. No one is confused about that (well, no one advocating for MODERN, anyway). Furthermore, the overwhelming majority of the protocol decisions that the IETF makes about the DNS aren't really matters of policy. They are matters like choosing between two proposed ways that a particular bit-field might be filled to enable a new application. >RH: Again, I'm not convinced that this applies to telephone numbers. I still don't see how the things you wish to develop would not be related to regulatory policies. The application in question may not ultimately apply everywhere that the DNS is used, and nor do we always know in advance if the application will ever have any real impact on the world. But this is what the IETF does and where its expertise lies. >RH: For sure the IETF has expertise regarding the DNS. But I didn't realize that it had expertise regarding telephone numbers. Ultimately, it's why the IETF is the right place to do work like this, because the proposed MODERN work is that sort of low-level protocol work. >RH: Again, I not convinced that is the case: the things that you want to do are not, in my view, low-level protocol work and I don't think that the IETF has lots of people who are experts in telephone numbers. Neustar is a member of ITU-T. What's the disadvantage to you of doing the work there, where you could benefit from the inputs of other folks who have expertise in telephone numbers? We understand how to create protocols like this, how to encode them, how to secure them, and we have some interested vendors willing to work on implementation. >RH: It would be good to hear from the other interested vendors. The MODERN work is not being designed exclusively with US interests in mind, >RH: It would be good to hear from any of the non-US folks who would be interested in this work. but like all IETF work, it will be determined by our consensus process, >RH: I look forward to finding out whether there is rough consensus to create this working group. forged from the coalition of the willing who want to do this work - we certainly welcome non-US involvement. >RH: As I said before, you are more likely to get that if you do the work in ITU-T, or at least formally inform them of what you are doing and liaise with them. You will find the IETF and ITU-T collaboration guidelines at: http://www.itu.int/rec/T-REC-A.Sup3-201207-I That document has been approved by both entities. I cite some portions here: "Early identification of topics of mutual interest will allow for constructive efforts between the two organizations based on mutual respect." "An IETF working group should also evaluate and identify areas of relationship with the ITU-T and document the collaboration with the ITU-T study group in its charter." "During the course of ITU-T and IETF collaboration, it is important to share working drafts and documents among the technical working groups." "It is envisaged that the processes of clauses 2.5.1 and 2.5.2 will often be used simultaneously by both an IETF working group and an ITU-T study group to collaborate on a topic of mutual interest." Our mailing lists and process are open (see OpenStand). >RH: Yes, but they are English-only. Jon Peterson Neustar, Inc. From: Richard Hill Date: Friday, June 26, 2015 at 10:15 AM To: Jon Peterson , "McGarry, Tom" , "modern@ietf.org" Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Dear Jon, Thank you for the thoughtful reply. Please see embedded comments below. Thanks and best, Richard From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, June 26, 2015 18:35 To: Richard Hill; McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Your arguments here could equally well be applied to any important resource on which the IETF does protocol work - like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are responsible for ccTLDs, >RH: The degree of involvement of national authorities with ccTLDs varies greatly, but I'm not aware of any that regulate ccTLDs to the same extent that telephone numbers are regulated. Further, the protocols and policies for the DNS were mostly developed before anybody thought that there should be any government involvement. And today ICANN develops most of the policies, even if the IETF is developing the protocols. So it is not an appropriate analogy. surely the IETF is not a suitable body for managing the DNS! >RH: The IETF does not manage the DNS. ICANN manages the DNS, to the extent that it requires top level management. And it isn't. But it is a suitable body for managing the protocol work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sorts of things you are worrying about here. The IETF just produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is simply an error. >RH: I'm not convinced that you can develop tools that don't affect policies. Indeed, it seems to me that the policies will condition whether certain tools are useable or not. All work at the IETF is done by a coalition of the willing. If it turns out that the coalition is not representative of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly be harmed by that, even if the failed work involved ways of talking about telephone numbers. >RH: That is true if nobody uses the work. It is not true if some country, say the US, adopts the outputs and then lobbies to have them adopted elsewhere. That can lead to serious friction and pushback. Better to involve all concerned parties early in the game. This makes the IETF really different from places like the ITU, where the products of work have some binding effect on the world. >RH> ITU-T Recommendations are no more (or less) binding that IETF RFCs or ISO Standards. Virtually all proposed work at the IETF also faces a coalition of the unwilling. People who aren't interested, or who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agree that if this proposed work required regulatory oversight, that the IETF shouldn't do it. >RH: I see that we agree on the principles but not the details. I don't see how the proposed work would not have regulatory impacts in at least some (probably many) countries, even if it has no impact in the US. Again, if the idea is to develop tools that would first be used in the US, then the work should be done in a US-only body. If the idea is to develop tools that would be used in many countries, then I think that the ITU-T is a more suitable forum. But we're just building some protocol tools. There is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol tools developed in the IETF and conduct an experiment with various carriers to see if it works for that interest group or not, and that would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part. >RH: I still don't understand why you think that IETF is uniquely well positioned to do this work. Surely nobody would suggest that the IETF should develop standards for nuts and bolts, when ISO is doing that. So why should the IETF develop standards (or tools) for telephone numbers when the ITU-T is doing that? Finally, I'm not really sure how much I would expect "national regulators" to literally use the tools proposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part instigated by an FCC workshop, yes, and someone associated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy this work - surely they would leave that to industry. >RH: That may well be true for the US, but it may well not be true in other countries. Which is why I think that the work is better done in a forum where you are more likely to get inputs from national regulators. If the inputs are of the form "go ahead, we don't care", then that is fine. But if you do the work in the IETF, you are not likely to get inputs from national regulators. Jon Peterson Neustar, Inc. From: Richard Hill Date: Friday, June 26, 2015 at 8:09 AM To: "McGarry, Tom" , "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by national regulators, presumably they should be involved in the development of the tools. As far as I know, national regulators from most countries don't normally participate in the IETF, for a number of reasons, including the IETF's decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU's decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at first, then I would suggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If the US experience proved successful, then the tools could be proposed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the start, then I would suggest that the appropriate forum would be ITU-T, not IETF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers. Entities can choose to use these tools or not. These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T. But of course we want your input and feedback, so thanks for sending this along. More comments in line below. From: Alissa Cooper Date: Thursday, June 25, 2015 7:44 AM To: Modern List Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say whether there would be an impact. Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recognition of course that the changes would have to be proposed to ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regulation. The WG cannot make any decisions with regard to this. I expect the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other. This will be a baseline for what tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That is, the definition of a "role" may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a telephone number. >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU-T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used". We are aware of Resolution 133 and will certainly respect it. I would propose adding the following text after the first sentence in the last full paragraph - "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, I would suggest adding "The group's outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein." >RH: For the sake of clarity I reiterate that I oppose the creation of this group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions. But it's too early to say anything specific about that. There is nothing in the charter that references .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "as well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent. The IETF often has fun with creating WG names. : ) But the charter is where to look for the scope of work. The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information . with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs". The functions you believe were left out of the charter will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work ------=_NextPart_000_0168_01D0B04D.48D6C730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Jon,


Thank you for this and please see inline comments = below.


Thanks and best,

Richard

 

From:= = Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Friday, = June 26, 2015 19:43
To: Richard Hill; McGarry, Tom; = modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)

 

=  

= The entire point of my raising the DNS analogy was indeed that the IETF = only creates the tools, not the policies, and that we're not proposing = to do anything else here in MODERN. We know the IETF doesn't determine = numbering policy. No one is confused about that (well, no one advocating = for MODERN, anyway). Furthermore, the overwhelming majority of the = protocol decisions that the IETF makes about the DNS aren't really = matters of policy. They are matters like choosing between two proposed = ways that a particular bit-field might be filled to enable a new = application.

 

>RH: Again, I’m not convinced that this applies to telephone = numbers. I still don’t see how the things you wish to develop = would not be related to regulatory policies.

 

= The application in question may not ultimately apply everywhere that the = DNS is used, and nor do we always know in advance if the application = will ever have any real impact on the world. But this is what the IETF = does and where its expertise lies.

 

>RH: For sure the IETF has expertise regarding the DNS. But I = didn’t realize that it had expertise regarding telephone = numbers.

=  

= Ultimately, it's why the IETF is the right place to do work like this, = because the proposed MODERN work is that sort of low-level protocol = work.

 

>RH: Again, I not convinced that is the case: the things that you = want to do are not, in my view, low-level protocol work and I = don’t think that the IETF has lots of people who are experts in = telephone numbers.  Neustar is a member of ITU-T. What’s the = disadvantage to you of doing the work there, where you could benefit = from the inputs of other folks who have expertise in telephone = numbers?

 

= We understand how to create protocols like this, how to encode them, how = to secure them, and we have some interested vendors willing to work on = implementation.

 

>RH: It would be good to hear from the other interested = vendors.

 

= The MODERN work is not being designed exclusively with US interests in = mind,

 

>RH: It would be good to hear from any of the non-US folks who = would be interested in this work.

 

= but like all IETF work, it will be determined by our consensus = process,

 

>RH: I look forward to finding out whether there is rough = consensus to create this working group.

 

= forged from the coalition of the willing who want to do this work - we = certainly welcome non-US involvement.

 

>RH: As I said before, you are more likely to get that if you do = the work in ITU-T, or at least formally inform them of what you are = doing and liaise with them.

 

You will find the IETF and ITU-T collaboration guidelines = at:

 

  http://www.itu.int/= rec/T-REC-A.Sup3-201207-I

 

That document has been approved by both entities.  I cite some = portions here:

 

“Early identification of topics of mutual interest will allow = for constructive efforts between the two organizations based on mutual = respect.”

 

“An IETF working group should also evaluate and identify areas = of relationship with the ITU-T and document the collaboration with the = ITU-T study group in its charter.”

 

“During the course of ITU-T and IETF collaboration, it is = important to share working drafts and documents among the technical = working groups.”

 

“It is envisaged that the processes of clauses 2.5.1 and 2.5.2 = will often be used simultaneously by both an IETF working group and an = ITU-T study group to collaborate on a topic of mutual interest.” =

 

= Our mailing lists and process are open (see = OpenStand).

 

>RH: Yes, but they are = English-only.

=  

= Jon Peterson

= Neustar, Inc.

=  

From: Richard Hill <rhill@hill-a.ch>
Date: = Friday, June 26, 2015 at 10:15 AM
To: Jon Peterson <jon.peterson@neustar.biz>= , "McGarry, Tom" <Tom.McGarry@neustar.biz>, = "modern@ietf.org" = <modern@ietf.org>
Subject: = RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

=  

Dear Jon,

 

Thank you for the thoughtful reply.

 

Please see embedded comments below.


Thanks and best,

Richard

 

= From:= Peterson, Jon [mailto:jon.peterson@neustar.biz<= /a>]
Sent: Friday, June 26, 2015 18:35
To: Richard = Hill; McGarry, Tom; modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

=  

= Your arguments here could equally well be applied to any important = resource on which the IETF does protocol work - like, say, the DNS. The = IETF manages the DNS protocol and publishes RFCs about it. But since = national authorities are responsible for ccTLDs,

 

>RH: The degree of involvement of national authorities with ccTLDs = varies greatly, but I’m not aware of any that regulate ccTLDs to = the same extent that telephone numbers are regulated. Further, the = protocols and policies for the DNS were mostly developed before anybody = thought that there should be any government involvement. And today ICANN = develops most of the policies, even if the IETF is developing the = protocols. So it is not an appropriate analogy.

 

= surely the IETF is not a suitable body for managing the DNS!

 

>RH: The IETF does not manage the DNS. ICANN manages the DNS, to = the extent that it requires top level management.

 

= And it isn't. But it is a suitable body for managing the protocol work = on the DNS. Other, effectively unrelated entities handle the = administrative dimensions of operating the DNS, and yes, at those bodies = there are lots of national regulators and they worry about the sorts of = things you are worrying about here. The IETF just produces tools, and = that is all MODERN proposes to do. Trying to characterize this effort = otherwise is simply an error.

 

>RH: I’m not convinced that you can develop tools that = don’t affect policies.  Indeed, it seems to me that the = policies will condition whether certain tools are useable or = not.

=  

= All work at the IETF is done by a coalition of the willing. If it turns = out that the coalition is not representative of the needs of the = community, then what happens? Well, the work built here doesn't get = used. The only people who wasted any time or effort were the members of = that coalition. No national interests can possibly be harmed by that, = even if the failed work involved ways of talking about telephone = numbers.

 

>RH: That is true if nobody uses the work. It is not true if some = country, say the US, adopts the outputs and then lobbies to have them = adopted elsewhere.  That can lead to serious friction and pushback. = Better to involve all concerned parties early in the game.

 

= This makes the IETF really different from places like the ITU, where the = products of work have some binding effect on the world.

 

>RH> ITU-T Recommendations are no more (or less) binding that = IETF RFCs or ISO Standards.

=  

= Virtually all proposed work at the IETF also faces a coalition of the = unwilling. People who aren't interested, or who think the work should be = done elsewhere, or that the work simply shouldn't be done at all. But I = maintain your "formal objection" treats the scope of the = proposed work as being different than it is, and I'd agree that if this = proposed work required regulatory oversight, that the IETF shouldn't do = it.

 

>RH: I see that we agree on the principles but not the details. I = don’t see how the proposed work would not have regulatory impacts = in at least some (probably many) countries, even if it has no impact in = the US. Again, if the idea is to develop tools that would first be used = in the US, then the work should be done in a US-only body. If the idea = is to develop tools that would be used in many countries, then I think = that the ITU-T is a more suitable forum.

 

= But we're just building some protocol tools. There is also related work = here for ATIS to do, and I'm sure ATIS or some other body could later = take some the protocol tools developed in the IETF and conduct an = experiment with various carriers to see if it works for that interest = group or not, and that would be interesting information. But the IETF = doesn't do that part, and doesn't aspire to do that part.

 

>RH: I still don’t understand why you think that IETF is = uniquely well positioned to do this work. Surely nobody would suggest = that the IETF should develop standards for nuts and bolts, when ISO is = doing that. So why should the IETF develop standards (or tools) for = telephone numbers when the ITU-T is doing that?

=  

= Finally, I'm not really sure how much I would expect "national = regulators" to literally use the tools proposed in this work. They = are tools for the use of a diverse industry of enterprises, carriers, = end users, and so on. Many use cases under consideration would not have = a national regulator as an actor. This work was in part instigated by an = FCC workshop, yes, and someone associated with the FCC spoke at the = MODERN BoF. But I don't anticipate that the FCC would be propping up = servers to deploy this work - surely they would leave that to = industry. 

 

>RH: That may well be true for the US, but it may well not be true = in other countries. Which is why I think that the work is better done in = a forum where you are more likely to get inputs from national = regulators. If the inputs are of the form “go ahead, we = don’t care”, then that is fine. But if you do the work in = the IETF, you are not likely to get inputs from national = regulators.

=  

= Jon Peterson

= Neustar, Inc.

=  

From: Richard Hill <rhill@hill-a.ch>
Date: = Friday, June 26, 2015 at 8:09 AM
To: "McGarry, = Tom" <Tom.McGarry@neustar.biz>, = "modern@ietf.org" = <modern@ietf.org>
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

=  

Thank you for this clarification.

 

Since the intent is to create tools and solutions that would be used = by national regulators, presumably they should be involved in the = development of the tools. 


As far as I know, national regulators from most countries = don’t normally participate in the IETF, for a number of reasons, = including the IETF’s decision-making process and the fact that the = IETF works in English. National regulators do participate in ITU-T, for = a number of reasons, including the ITU’s decision-making process = and the fact that documents are translated into the six UN languages = before they are formally approved (and some discussions takes place with = interpretation in six languages).

 

If the intent is to develop tools that would be used only in the USA = at first, then I would suggest that it would be more appropriate to = develop them in a forum such as ATIS or an ad-hoc group created = specifically for the purpose. If the US experience proved successful, = then the tools could be proposed for adoption elsewhere, for example = through ITU-T.

 

If the intent is to develop tools for use in many countries right at = the start, then I would suggest that the appropriate forum would be = ITU-T, not IETF, for the reasons outlined above.

 

Thus, I formally object to the creation of this new working group, = and this even if the Charter is modified as suggested below.

 

Please see additional comments inline.

 

Thanks and best,

Richard

 

= From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin = 2015 00:31
To: modern@ietf.org
Subject: = Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

 

This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. =  Entities can choose to use these tools or not.  These tools = are not for the ITU-T's processes or role, nor for how national = administrators interact with the ITU-T.  But of course we want your = input and feedback, so thanks for sending this along.  More = comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: = Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: = [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Would appreciate people’s thoughts on whether any charter edits = may be warranted in response to these comments, and/or whether a = separate response may be useful for addressing some of the questions = below.

 

Alissa

 

Begin forwarded message:





From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU = Telecommunication Standardization Bureau on the proposed IETF working = group MODERN.

1. Potential = impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated = at the beginning of the Charter that 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. And it is = mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to = here only deals with Tel URI? Would there be any impact on = Recommendation ITU-E E.164 and E.164.1 which are core recommendations on = Telephone Numbers?

= There will be no impacts on E.164 and E.164.1.

 

>RH: Given the scope of the work, I think that it is too early to = say whether there would be an impact. Those Recommendations are = regularly updated, in particular E.164.1, so there is nothing wrong with = envisaging changes, with the recognition of course that the changes = would have to be proposed to ITI-T Study Group 2 and agreed by that = group.


2. Entities participating in = the defined mechanisms
The Charter states that the protocol mechanism = for resolving TNs will allow entities such as service providers, = devices, and applications to access data related to TNs. But it is not = clear what kind of entities can participate in the mechanisms defined by = this MODERN working group. Would it be restricted to the entities who = have been assigned a TN or a block of TNS?

= Who participates in numbering processes within countries is subject to = regulation.  The WG cannot make any decisions with regard to this. =  I expect the WG to define "roles" within the number = management processes; e.g., administrator, telecom = carrier, application provider, consumer, etc.; and how those = roles could interact with each other.  This will be = a baseline for what tools and solutions would be useful to = facilitate those interactions.  

 

>RH: Even that might be subject to, or affect, national = regulations.  That is, the definition of a “role” may = well depend on national regulations.


3. Status of Telephone numbers = in the defined mechanisms
Several operations related to TNs are = mentioned in the Charter, including requesting, acquiring, resolving and = associating. It is also stated that the protocol mechanism for acquiring = TNs will provide an enrollment process for the entities that use and = manage TNs. Does that mean Telephone numbers with various status, such = as assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working group?

I=  would expect proposed solutions to be able to address the status = of a telephone number.

 

>RH: Since the terms “assigned”, “spare” = and “reclaimed” are defined in ITU-T Recommendations (albeit = sometimes implicitly), addressing the status of a telephone number might = well impact E.164 or E.164.1.


4. Regulatory issues
The = Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact = that the E.164 international public telecommunication numbering plan is = a politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of = ITU Member States with respect to allocation and management of their = country code numbering resources as enshrined in Recommendation ITU-T = E.164", and further instructed the ITU Secretary-General and the = Directors of three Bureaux (Telecommunication Standardization, = Development, and Radiocommunication) to "take any necessary action = to ensure the sovereignty of ITU Member States with regard to = Recommendation ITU-T E.164 numbering plans whatever the application in = which they are used".

We are aware of = Resolution 133 and will certainly respect it.  I would propose = adding the following text after the first sentence in the last full = paragraph – "The group acknowledges ITU = Plenipotentiary Conference Resolution 133 which recognizes the existing = role and sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined = in Recommendation ITU-T E.164."  

 

>RH: That certainly would be a helpful addition. In addition to = the above, I would suggest adding “The group’s outputs would = be consistent with the provisions of relevant ITU-T Recommendations, in = particular E.164, E.164.1, E.190 and the Recommendations referenced = therein.” 

 

>RH: For the sake of clarity I reiterate that I oppose the = creation of this group even if the Charter is modified to include the = text above.

 


5. Relationship with = .Tel
DNS-based use of international numbering resources has been = discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 = September 2013. TSB Director has also exchanged letters with ICANN on = issues related to registering digit strings in the .TEL domain. A = representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A = correspondence group under ITU-T SG2 was also set up in this regard. We = would like to know how the work of this new WG would relate to issues = related to registering digit strings in the .TEL domain and other = DNS-based use of telephone numbers.

= The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule = out the WG leveraging existing namespaces as part of proposed = solutions.  But it's too early to say anything specific about that. =  There is nothing in the charter that references .tel. =  


6. Relationship with related = existing or concluded WGs
It is stated in the Charter that the = working group will take into consideration existing IETF work including = STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the = relationship between this new WG and the above mentioned other existing = or concluded WGs would be appreciated.

= I agree.  I would modify that sentence to add the = following at the end - "as well as = other relevant industry and standards = organizations."


7. The name of this new = WG
The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the = Charter, ordering, exposing and registering TNs are not mentioned, which = seems to be a little bit inconsistent.

= The IETF often has fun with creating WG names.  : )  But the = charter is where to look for the scope of work.  The charter uses = the following phrases "distribution, acquisition and management = of TNs", "functions involved in associating = information … with TNs", "associating, = acquiring and resolving TNs", "access data related = to TNs", and "mechanisms for resolving information = related to TNs".  The functions you believe were left out = of the charter will be part of one or more of these processes. =  



Best regards,

Jie Zhang
Advisor, ITU-T = SG2
International Telecommunication Union
Place des = Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 = 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Origina= l Message-----
From: new-work [mailto:new-work-bounces@ietf.or= g] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 = PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz> Steve Donovan <srdonovan@usdonovans.com>=

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailin= g list
 Address: modern@ietf.org
 To = Subscribe: https://www.ietf.or= g/mailman/listinfo/modern
 Archive: http://www.ietf.org= /mail-archive/web/modern/

Charter:

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. = Devices, applications, and network tools increasingly need to manage = TNs, including requesting and acquiring TN delegations from authorities. = The output of the working group should make distribution, acquisition, = and management of TNs simpler for all entities involved.

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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs. 

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, and security = and privacy for both the data and the protocol interactions are primary = considerations. The working group will take into consideration existing = IETF work including STIR, 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. 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 for TN assignment and management, for = example those established by different regulatory agencies.

The = working 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

Milestones:

TBD

________________________________= _______________
new-work mailing list
new-work@ietf.org
https://www.ietf.= org/mailman/listinfo/new-work

 

 

------=_NextPart_000_0168_01D0B04D.48D6C730-- From nobody Fri Jun 26 13:30: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 7A4061A874C for ; Fri, 26 Jun 2015 13:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Tzhtjy8Et7JL for ; Fri, 26 Jun 2015 13:30:36 -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 2E1171A701E for ; Fri, 26 Jun 2015 13:30:36 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+iBXg== Date: Fri, 26 Jun 2015 20:30:13 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 20:30:37 -0000 Since the nesting is getting confusing, let me add a few general points tha= t refer to a number of different discussion items: * My sense is that a number of national regulators are well aware of the MO= DERN work. NANC has been kept in the loop, and their input on requirements = (e.g., through their Future of Numbering (FON) effort) has informed and wil= l continue to inform the discussion. * Everyone involved understands that any viable efforts need to be neutral = in terms of regulatory policy decisions (such as who the actors are and wha= t precise rights they have), as these vary by geography and change over tim= e. It would help the discussion to move beyond this general insight and ide= ntify any specific concerns that need to be addressed. * I'm not sure other standards bodies have demonstrated equivalent IP-based= design experience, but (as noted) I suspect everybody welcomes inputs from= as many interested parties as possible. * The type and number of entities that are in the numbering ecosystem is in= creasing, at least in some jurisdictions. See the recent FCC R&O on number = access by interconnected VoIP providers as an example, or the use of phone = numbers for vehicular (telematics) and IOT systems further down the pipelin= e. There is a general tendency to automate and standardize the process of s= ervice creation, including the assignment of identifiers (here, phone numbe= rs), even if one discounts the SDN/NFV hype. * The current number porting model (in the US) predates the Internet and le= aves room for improvement from a consumer and carrier perspective. * The current assignment model (at least in the US) is not a model of effic= iency and flexibility. There are numerous examples, but the most recent dif= ficult transition process of the LNPA is a high-profile one. * Traditional carriers may not be the only "customers". In IETF work, there= 's sometimes the danger of equating the installed base with the total marke= t. As always, participation in the IETF process is voluntary. If there are no = volunteers, there will be no documents. If the output doesn't meet the need= of NRAs, their designated number administration entities or other entities= in the numbering ecosystem, the volunteers will have wasted their time, bu= t nobody else will be harmed. Henning From nobody Fri Jun 26 13:37: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 D303A1A701E for ; Fri, 26 Jun 2015 13:37:15 -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 VJ2vGbsJf7TV for ; Fri, 26 Jun 2015 13:37:14 -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 6C2081A8749 for ; Fri, 26 Jun 2015 13:37:14 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+9Zjg== Date: Fri, 26 Jun 2015 20:36:51 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 20:37:16 -0000 As far as I can tell, there is really no assignment problem for special num= bers (N11, say), given their static nature and the small pool. One goal tha= t I see is to rationalize the current set of databases; their design seems = to best be explained by historical, rather than technical, reasons. In many= ways, 800 numbers do share similarities in the basic problem set (need to = allocate, track who has been assigned numbers, etc.), so a good test of gen= erality and "policy neutrality" may well be whether the same basic protocol= s and interfaces work for both traditional subscriber and toll-free numbers= . I'm not sure why mobile numbers differ in some fundamental way that would= affect protocols and data structures. And I really struggle with how this is supposed to work because there are s= o many different kinds of telephone numbers such as service numbers (e.g., = 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs= , IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,= SMS800, et cetera. From nobody Fri Jun 26 13:54: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 BFB711ACDB1 for ; Fri, 26 Jun 2015 13:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.238 X-Spam-Level: X-Spam-Status: No, score=-4.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 TD-NolKI5ZV9 for ; Fri, 26 Jun 2015 13:54:03 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0E31A1AC6 for ; Fri, 26 Jun 2015 13:54:02 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill , "'McGarry, Tom'" , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABoS1A== Date: Fri, 26 Jun 2015 20:54:01 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> , <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: <005a01d0b022$169bcbb0$43d36310$@ch> 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] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 20:54:06 -0000 My sense is that national regulatory staff have started to pay more attenti= on to the IETF, but they are generally not protocol engineers. It is not ob= vious that most of my colleagues, however skilled they are in legal, policy= and economic matters, would want to debate the use of JSON formats and pro= tocol timers. I don't get the sense that the NRA participants in the ITU-T = processes are typically Internet protocol engineers, either... Thus, my suggestion would be that the ITU-T could play a constructive role = by providing requirements and vetting work ("does this fit into the univers= e of requirements out there that we know about"). However, I think that's b= est done based on concrete work since it may turn out that many aspects wil= l essentially have no policy implications. (As an example, if a protocol de= signates an abstract entity as being authorized to do something, there's no= t much need to enumerate all the entities in the real world that may wear t= hat hat now or in the future since that's an operational problem, not a pro= tocol design issue.) This fits into the fashionable "agile" software develo= pment model where you create something and get feedback early (and are prep= ared to discard work), rather than getting stuck forever in a requirements = process. Henning ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Richard Hill [rhill@hil= l-a.ch] Sent: Friday, June 26, 2015 11:09 AM To: 'McGarry, Tom'; modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Thank you for this clarification. Since the intent is to create tools and solutions that would be used by nat= ional regulators, presumably they should be involved in the development of = the tools. As far as I know, national regulators from most countries don=92t normally = participate in the IETF, for a number of reasons, including the IETF=92s de= cision-making process and the fact that the IETF works in English. National= regulators do participate in ITU-T, for a number of reasons, including the= ITU=92s decision-making process and the fact that documents are translated= into the six UN languages before they are formally approved (and some disc= ussions takes place with interpretation in six languages). If the intent is to develop tools that would be used only in the USA at fir= st, then I would suggest that it would be more appropriate to develop them = in a forum such as ATIS or an ad-hoc group created specifically for the pur= pose. If the US experience proved successful, then the tools could be propo= sed for adoption elsewhere, for example through ITU-T. If the intent is to develop tools for use in many countries right at the st= art, then I would suggest that the appropriate forum would be ITU-T, not IE= TF, for the reasons outlined above. Thus, I formally object to the creation of this new working group, and this= even if the Charter is modified as suggested below. Please see additional comments inline. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: vendredi, 26. juin 2015 00:31 To: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people=92s thoughts on whether any charter edits may be wa= rranted in response to these comments, and/or whether a separate response m= ay be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. >RH: Given the scope of the work, I think that it is too early to say wheth= er there would be an impact. Those Recommendations are regularly updated, i= n particular E.164.1, so there is nothing wrong with envisaging changes, wi= th the recognition of course that the changes would have to be proposed to = ITI-T Study Group 2 and agreed by that group. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. >RH: Even that might be subject to, or affect, national regulations. That = is, the definition of a =93role=94 may well depend on national regulations. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 are de= fined in ITU-T Recommendations (albeit sometimes implicitly), addressing th= e status of a telephone number might well impact E.164 or E.164.1. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolutio= n 133 which recognizes the existing role and sovereignty of ITU Member Stat= es with respect to allocation and management of their country code numberin= g resources as enshrined in Recommendation ITU-T E.164." >RH: That certainly would be a helpful addition. In addition to the above, = I would suggest adding =93The group=92s outputs would be consistent with th= e provisions of relevant ITU-T Recommendations, in particular E.164, E.164.= 1, E.190 and the Recommendations referenced therein.=94 >RH: For the sake of clarity I reiterate that I oppose the creation of this= group even if the Charter is modified to include the text above. 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information =85 with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 26 13:55: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 BCEC31ACDCB for ; Fri, 26 Jun 2015 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RT6cMWo8URVz for ; Fri, 26 Jun 2015 13:55:33 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 5FE1D1ACD7D for ; Fri, 26 Jun 2015 13:55:33 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QKtTQV010470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 22:55:29 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QKtTgu012349; Fri, 26 Jun 2015 22:55:29 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , In-Reply-To: Date: Fri, 26 Jun 2015 22:55:30 +0200 Message-ID: <01db01d0b052$6ffe2d80$4ffa8880$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+iBXoAACgnQ Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 20:55:36 -0000 Please see inline. > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning > Schulzrinne > Sent: Friday, June 26, 2015 22:30 > To: modern@ietf.org > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Since the nesting is getting confusing, let me add a few general points > that refer to a number of different discussion items: > > * My sense is that a number of national regulators Can you specify which national regulators are aware of the creation of the proposed working group, other than the FCC, which I presume you are representing in this discussion? > are well aware of > the MODERN work. NANC has been kept in the loop, and their input on > requirements (e.g., through their Future of Numbering (FON) effort) Can you please give the URL for the cited documents? > has > informed and will continue to inform the discussion. > > * Everyone involved understands that any viable efforts need to be > neutral in terms of regulatory policy decisions (such as who the actors > are and what precise rights they have), as these vary by geography and > change over time. It would help the discussion to move beyond this > general insight and identify any specific concerns that need to be > addressed. I'm sorry if I am not being clear. My concern is that, unless you bring the national regulators into the discussion, you won't know what their specific concerns are. And this precisely because the regulatory policies vary considerably by geography. > > * I'm not sure other standards bodies have demonstrated equivalent IP- > based design experience, but (as noted) I suspect everybody welcomes > inputs from as many interested parties as possible. I'm not sure that I understand what the IP-based specifics are of the project. As I understand it, the idea is to develop protocols for specifying requests to get numbers, etc. How is that specifically tied to TCP/IP? > > * The type and number of entities that are in the numbering ecosystem > is increasing, at least in some jurisdictions. See the recent FCC R&O > on number access by interconnected VoIP providers as an example, or the > use of phone numbers for vehicular (telematics) and IOT systems further > down the pipeline. There is a general tendency to automate and > standardize the process of service creation, including the assignment > of identifiers (here, phone numbers), even if one discounts the SDN/NFV > hype. Agreed. I have no doubt that the work is useful, the question is how to make it most useful and in which forum to carry out the work. > > * The current number porting model (in the US) predates the Internet > and leaves room for improvement from a consumer and carrier > perspective. No kidding. The US numbering plan is, in my view, obsolete and badly in need of reform. But US industry and US authorities don't seem to agree (or at least they didn't last time I checked a couple of years ago). But I don't see what this has to do with the proposed working group or the IETF. Decisions regarding the US numbering plan are in the remit of the FCC (but correct me if I'm wrong about that). > > * The current assignment model (at least in the US) is not a model of > efficiency and flexibility. There are numerous examples, but the most > recent difficult transition process of the LNPA is a high-profile one. This is no doubt correct, but, again, changes in the assignment model are in the remit of the FCC, not the IETF (again, correct me if I'm wrong about that). > > * Traditional carriers may not be the only "customers". In IETF work, > there's sometimes the danger of equating the installed base with the > total market. Indeed, I think that carriers should not be the only recipients of telephone numbers. But, again, that is a policy question that is not in the remit of the IETF (but correct me if I'm wrong about that). > > As always, participation in the IETF process is voluntary. If there are > no volunteers, there will be no documents. If the output doesn't meet > the need of NRAs, their designated number administration entities or > other entities in the numbering ecosystem, the volunteers will have > wasted their time, but nobody else will be harmed. As I said before, I think the risk is that something gets developed that makes sense for the US, and the US then tries to convince other countries to use it. That will likely result in push back and bad blood. If the idea is to develop something that can be used in many countries, then better to get the national regulatory authorities involved up front, and I doubt that they will flock to IETF. If the idea is to develop something that will only be used in the US, at least for now, then it would be, in my view, more appropriate to develop the solutions in a US-only body, not in the IETF. > > Henning > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Fri Jun 26 13:57: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 8C2451ACDB6 for ; Fri, 26 Jun 2015 13:57:45 -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 ciKcF0mr6kUA for ; Fri, 26 Jun 2015 13:57:44 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 8363A1AC413 for ; Fri, 26 Jun 2015 13:57:44 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DOLLY, MARTIN C" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAAXXoCAARznPg== Date: Fri, 26 Jun 2015 20:57:42 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 20:57:45 -0000 I'm not quite sure I understand your paragraph below, but one of the models= discussed would (technically, leaving policy/regulatory issues aside) allo= w a carrier to bypass the middle man and avoid paying third parties for dat= abase services. Obviously, as I suspect we both agree, the "who pays whom" = discussion is well beyond the scope of protocol work. ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135= @att.com] Sent: Thursday, June 25, 2015 7:54 PM To: McGarry, Tom Cc: modern@ietf.org Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern) Litmus test: E.164 plus Private numbers in the format above At issue: A model where the carrier has to pay for giving a DB in the cloud our numbe= rs and then pay to query So when did the IETF get into this.... From nobody Fri Jun 26 13:58:35 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 C48D71ACDD6 for ; Fri, 26 Jun 2015 13:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xa6dfkSbyy6y for ; Fri, 26 Jun 2015 13:58:31 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 68A2F1ACD7F for ; Fri, 26 Jun 2015 13:58:31 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QKwRnA011700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 22:58:28 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QKwRvI019327; Fri, 26 Jun 2015 22:58:27 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , In-Reply-To: Date: Fri, 26 Jun 2015 22:58:28 +0200 Message-ID: <01de01d0b052$da16ab70$8e440250$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+9ZjoAABoRA Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 20:58:34 -0000 Again, things vary according to countries. In the US, you don't use specific area codes for mobile numbers. Elsewhere they do. So mobile numbers are, in some ways, different from fixed numbers in many countries. Also, assignment criteria for special numbers (short codes) differ widely by country. As do the solutions adopted for number portability. This seems to me to argue that you need to get significant input from national regulators around the world if you want to develop truly policy-neutral solutions. Best, Richard > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning > Schulzrinne > Sent: Friday, June 26, 2015 22:37 > To: modern@ietf.org > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > As far as I can tell, there is really no assignment problem for special > numbers (N11, say), given their static nature and the small pool. One > goal that I see is to rationalize the current set of databases; their > design seems to best be explained by historical, rather than technical, > reasons. In many ways, 800 numbers do share similarities in the basic > problem set (need to allocate, track who has been assigned numbers, > etc.), so a good test of generality and "policy neutrality" may well be > whether the same basic protocols and interfaces work for both > traditional subscriber and toll-free numbers. I'm not sure why mobile > numbers differ in some fundamental way that would affect protocols and > data structures. > > And I really struggle with how this is supposed to work because there > are so many different kinds of telephone numbers such as service > numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, > wireline numbers, TLDNs, IMRNs, ported numbers, and multiple > administrative databases, NPAC, LERG, SMS800, et cetera. > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Fri Jun 26 14:04:10 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BFA1A1B4B for ; Fri, 26 Jun 2015 14:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 q3A6I4MhuAAI for ; Fri, 26 Jun 2015 14:04:05 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 0F0E61A1B43 for ; Fri, 26 Jun 2015 14:04:04 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QL41Ev014756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 23:04:01 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QL41od013423; Fri, 26 Jun 2015 23:04:01 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , "'McGarry, Tom'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> , <005a01d0b022$169bcbb0$43d36310$@ch> In-Reply-To: Date: Fri, 26 Jun 2015 23:04:01 +0200 Message-ID: <01e101d0b053$a1192c20$e34b8460$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABoS1IAABKmA Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 21:04:09 -0000 Indeed I agree that a constructive approach would be to do this work in cooperation between the IETF and the ITU-T, because, as you correctly say, they typically draw different types of experts as participants. And I do agree that it is better to present some concrete proposals and ask whether they have policy implications, rather than to ask for abstract requirements which may be difficult to formulate. But I still don't understand why the people who wish to develop the proposed protocols don't simply send their proposals to ITU-T Study Group 2 and see how that group reacts. And, to begin with, why nobody seems to have thought of sending the draft working group charter to ITU-T Study Group 2 to see what they thought of it. Best, Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Friday, June 26, 2015 22:54 > To: Richard Hill; 'McGarry, Tom'; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > My sense is that national regulatory staff have started to pay more > attention to the IETF, but they are generally not protocol engineers. > It is not obvious that most of my colleagues, however skilled they are > in legal, policy and economic matters, would want to debate the use of > JSON formats and protocol timers. I don't get the sense that the NRA > participants in the ITU-T processes are typically Internet protocol > engineers, either... > > Thus, my suggestion would be that the ITU-T could play a constructive > role by providing requirements and vetting work ("does this fit into > the universe of requirements out there that we know about"). However, I > think that's best done based on concrete work since it may turn out > that many aspects will essentially have no policy implications. (As an > example, if a protocol designates an abstract entity as being > authorized to do something, there's not much need to enumerate all the > entities in the real world that may wear that hat now or in the future > since that's an operational problem, not a protocol design issue.) This > fits into the fashionable "agile" software development model where you > create something and get feedback early (and are prepared to discard > work), rather than getting stuck forever in a requirements process. > > Henning > > ________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of Richard Hill > [rhill@hill-a.ch] > Sent: Friday, June 26, 2015 11:09 AM > To: 'McGarry, Tom'; modern@ietf.org > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Thank you for this clarification. > > Since the intent is to create tools and solutions that would be used by > national regulators, presumably they should be involved in the > development of the tools. > > As far as I know, national regulators from most countries don't > normally participate in the IETF, for a number of reasons, including > the IETF's decision-making process and the fact that the IETF works in > English. National regulators do participate in ITU-T, for a number of > reasons, including the ITU's decision-making process and the fact that > documents are translated into the six UN languages before they are > formally approved (and some discussions takes place with interpretation > in six languages). > > If the intent is to develop tools that would be used only in the USA at > first, then I would suggest that it would be more appropriate to > develop them in a forum such as ATIS or an ad-hoc group created > specifically for the purpose. If the US experience proved successful, > then the tools could be proposed for adoption elsewhere, for example > through ITU-T. > > If the intent is to develop tools for use in many countries right at > the start, then I would suggest that the appropriate forum would be > ITU-T, not IETF, for the reasons outlined above. > > Thus, I formally object to the creation of this new working group, and > this even if the Charter is modified as suggested below. > > Please see additional comments inline. > > Thanks and best, > Richard > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom > Sent: vendredi, 26. juin 2015 00:31 > To: modern@ietf.org > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > > This effort is intended to create tools and solutions to enable > flexibility in the process of managing numbers among national > administrators, service and application providers, and consumers. > Entities can choose to use these tools or not. These tools are not for > the ITU-T's processes or role, nor for how national administrators > interact with the ITU-T. But of course we want your input and > feedback, so thanks for sending this along. More comments in line > below. > > > From: Alissa Cooper > > Date: Thursday, June 25, 2015 7:44 AM > To: Modern List > > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Would appreciate people's thoughts on whether any charter edits may be > warranted in response to these comments, and/or whether a separate > response may be useful for addressing some of the questions below. > > Alissa > > Begin forwarded message: > > > From: "Zhang, Jie" > > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, > Exposing, & Registering telephone Numbers (modern) > Date: June 23, 2015 at 1:56:42 PM GMT-3 > To: "iesg@ietf.org" > > > Cc: "Jamoussi, Bilel" > > > Dear Sir/Madam, > > Below please find comments from the ITU Telecommunication > Standardization Bureau on the proposed IETF working group MODERN. > > 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is > stated at the beginning of the Charter that 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. > And it is mentioned that TNs are defined in RFC 3966 "The tel URI for > Telephone Numbers". Does that mean the mechanism being referred to here > only deals with Tel URI? Would there be any impact on Recommendation > ITU-E E.164 and E.164.1 which are core recommendations on Telephone > Numbers? > There will be no impacts on E.164 and E.164.1. > > >RH: Given the scope of the work, I think that it is too early to say > whether there would be an impact. Those Recommendations are regularly > updated, in particular E.164.1, so there is nothing wrong with > envisaging changes, with the recognition of course that the changes > would have to be proposed to ITI-T Study Group 2 and agreed by that > group. > > 2. Entities participating in the defined mechanisms The Charter states > that the protocol mechanism for resolving TNs will allow entities such > as service providers, devices, and applications to access data related > to TNs. But it is not clear what kind of entities can participate in > the mechanisms defined by this MODERN working group. Would it be > restricted to the entities who have been assigned a TN or a block of > TNS? > Who participates in numbering processes within countries is subject to > regulation. The WG cannot make any decisions with regard to this. I > expect the WG to define "roles" within the number management processes; > e.g., administrator, telecom carrier, application provider, consumer, > etc.; and how those roles could interact with each other. This will be > a baseline for what tools and solutions would be useful to facilitate > those interactions. > > >RH: Even that might be subject to, or affect, national regulations. > That is, the definition of a "role" may well depend on national > regulations. > > 3. Status of Telephone numbers in the defined mechanisms Several > operations related to TNs are mentioned in the Charter, including > requesting, acquiring, resolving and associating. It is also stated > that the protocol mechanism for acquiring TNs will provide an > enrollment process for the entities that use and manage TNs. Does that > mean Telephone numbers with various status, such as assigned, spare and > reclaimed numbers will all be managed in the mechanisms defined by the > MODERN working group? > I would expect proposed solutions to be able to address the status of a > telephone number. > > >RH: Since the terms "assigned", "spare" and "reclaimed" are defined in > ITU-T Recommendations (albeit sometimes implicitly), addressing the > status of a telephone number might well impact E.164 or E.164.1. > > 4. Regulatory issues > The Charter states that Solutions and mechanisms created by the working > group will be flexible enough to accommodate different policies for TN > assignment and management, for example those established by different > regulatory agencies. We would like to bring your attention to the fact > that the E.164 international public telecommunication numbering plan is > a politically significant numbering resource with direct implications > on national sovereignty. ITU Plenipotentiary Conference Resolution 133 > (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU > Member States with respect to allocation and management of their > country code numbering resources as enshrined in Recommendation ITU-T > E.164", and further instructed the ITU Secretary-General and the > Directors of three Bureaux (Telecommunication Standardization, > Development, and Radiocommunication) to "take any necessary action to > ensure the sovereignty of ITU Member States with regard to > Recommendation ITU-T E.164 numbering plans whatever the application in > which they are used". > We are aware of Resolution 133 and will certainly respect it. I would > propose adding the following text after the first sentence in the last > full paragraph - "The group acknowledges ITU Plenipotentiary Conference > Resolution 133 which recognizes the existing role and sovereignty of > ITU Member States with respect to allocation and management of their > country code numbering resources as enshrined in Recommendation ITU-T > E.164." > > >RH: That certainly would be a helpful addition. In addition to the > above, I would suggest adding "The group's outputs would be consistent > with the provisions of relevant ITU-T Recommendations, in particular > E.164, E.164.1, E.190 and the Recommendations referenced therein." > > >RH: For the sake of clarity I reiterate that I oppose the creation of > this group even if the Charter is modified to include the text above. > > > 5. Relationship with .Tel > DNS-based use of international numbering resources has been discussed > in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. > TSB Director has also exchanged letters with ICANN on issues related to > registering digit strings in the .TEL domain. A representative from > ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and > provided some background on the TELNIC application. A correspondence > group under ITU-T SG2 was also set up in this regard. We would like to > know how the work of this new WG would relate to issues related to > registering digit strings in the .TEL domain and other DNS-based use of > telephone numbers. > The WG will not create any new namespace that would require regulatory > oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG > leveraging existing namespaces as part of proposed solutions. But it's > too early to say anything specific about that. There is nothing in the > charter that references .tel. > > 6. Relationship with related existing or concluded WGs It is stated in > the Charter that the working group will take into consideration > existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. > Detailed description of the relationship between this new WG and the > above mentioned other existing or concluded WGs would be appreciated. > I agree. I would modify that sentence to add the following at the end > - "as well as other relevant industry and standards organizations." > > 7. The name of this new WG > The name of this new WG is "Managing, Ordering, Distributing, Exposing, > & Registering telephone Numbers (modern)". But in the Charter, > ordering, exposing and registering TNs are not mentioned, which seems > to be a little bit inconsistent. > The IETF often has fun with creating WG names. : ) But the charter is > where to look for the scope of work. The charter uses the following > phrases "distribution, acquisition and management of TNs", "functions > involved in associating information . with TNs", "associating, > acquiring and resolving TNs", "access data related to TNs", and > "mechanisms for resolving information related to TNs". The functions > you believe were left out of the charter will be part of one or more of > these processes. > > > Best regards, > > Jie Zhang > Advisor, ITU-T SG2 > International Telecommunication Union > Place des Nations > CH-1211 Geneva , Switzerland > Tel :+41 22 730 5855 > jie.zhang@itu.int > www.itu.int > www.itu150.org > > > -----Original Message----- > From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, June 12, 2015 8:47 PM > To: new-work@ietf.org > Subject: [new-work] WG Review: Managing, Ordering, Distributing, > Exposing, & Registering telephone Numbers (modern) > > A new IETF working group has been proposed in the Applications and > Real-Time Area. The IESG has not made any determination yet. The > following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG > mailing list (iesg at ietf.org) by 2015-06-22. > > Managing, Ordering, Distributing, Exposing, & Registering telephone > Numbers (modern) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Tom McGarry > > Steve Donovan > > > > Assigned Area Director: > Alissa Cooper > > > Mailing list > Address: modern@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/modern > Archive: http://www.ietf.org/mail-archive/web/modern/ > > Charter: > > 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. Devices, applications, and network tools > increasingly need to manage TNs, including requesting and acquiring TN > delegations from authorities. The output of the working group should > make distribution, acquisition, and management of TNs simpler for all > entities involved. > > 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. TNs may either be > managed in a hierarchical tree, or in a distributed registry. The > protocol mechanism for acquiring TNs will provide an enrollment process > for the entities that use and manage TNs. > > 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, and > security and privacy for both the data and the protocol interactions > are primary considerations. The working group will take into > consideration existing IETF work including STIR, 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. 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 for TN assignment and > management, for example those established by different regulatory > agencies. > > The working 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 > > Milestones: > > TBD > > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work > > From nobody Fri Jun 26 14:04: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 3F3731A1B56 for ; Fri, 26 Jun 2015 14:04:43 -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 GIhOtaQzrigN for ; Fri, 26 Jun 2015 14:04:42 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id D59ED1A1B4B for ; Fri, 26 Jun 2015 14:04:41 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+9ZjoAABoRAgAABGMI= Date: Fri, 26 Jun 2015 21:04:40 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , , <01de01d0b052$da16ab70$8e440250$@ch> In-Reply-To: <01de01d0b052$da16ab70$8e440250$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 21:04:43 -0000 I think we all agree that the criteria for "who gets what numbers", includi= ng restrictions on what numbers can be assigned for what services, are beyo= nd the scope of the discussion. They are not currently in the existing SS7 = or SOAP-based protocols, for example, and thus I'm still unsure how they wo= uld enter a protocol (rather than implementation) discussion. =0A= =0A= I would indeed encourage input from regulators or, as an aggregator of sort= s, the ITU-T on porting models. I know Ofcom and others have done some work= in this area already.=0A= =0A= ________________________________________=0A= From: Richard Hill [rhill@hill-a.ch]=0A= Sent: Friday, June 26, 2015 4:58 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Again, things vary according to countries.=0A= =0A= In the US, you don't use specific area codes for mobile numbers. Elsewhere= =0A= they do. So mobile numbers are, in some ways, different from fixed numbers= =0A= in many countries.=0A= =0A= Also, assignment criteria for special numbers (short codes) differ widely b= y=0A= country. As do the solutions adopted for number portability.=0A= =0A= This seems to me to argue that you need to get significant input from=0A= national regulators around the world if you want to develop truly=0A= policy-neutral solutions.=0A= =0A= Best,=0A= Richard=0A= From nobody Fri Jun 26 14:09:30 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 5EFFC1A1C02 for ; Fri, 26 Jun 2015 14:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TfCGv6c4WAnz for ; Fri, 26 Jun 2015 14:09:19 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 718271A3BA2 for ; Fri, 26 Jun 2015 14:09:19 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QL9GZR017199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 23:09:16 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QL9FkB014731; Fri, 26 Jun 2015 23:09:16 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , , <01de01d0b052$da16ab70$8e440250$@ch> In-Reply-To: Date: Fri, 26 Jun 2015 23:09:16 +0200 Message-ID: <01ea01d0b054$5cacbbf0$160633d0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+9ZjoAABoRAgAABGMKAAAJrcA== Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 21:09:21 -0000 Regarding numbering portability, you may be interested in this ITU-T document: http://www.itu.int/rec/T-REC-E.164-201406-I!Sup2 Best, Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Friday, June 26, 2015 23:05 > To: Richard Hill; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > I think we all agree that the criteria for "who gets what numbers", > including restrictions on what numbers can be assigned for what > services, are beyond the scope of the discussion. They are not > currently in the existing SS7 or SOAP-based protocols, for example, and > thus I'm still unsure how they would enter a protocol (rather than > implementation) discussion. > > I would indeed encourage input from regulators or, as an aggregator of > sorts, the ITU-T on porting models. I know Ofcom and others have done > some work in this area already. > > ________________________________________ > From: Richard Hill [rhill@hill-a.ch] > Sent: Friday, June 26, 2015 4:58 PM > To: Henning Schulzrinne; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Again, things vary according to countries. > > In the US, you don't use specific area codes for mobile numbers. > Elsewhere they do. So mobile numbers are, in some ways, different from > fixed numbers in many countries. > > Also, assignment criteria for special numbers (short codes) differ > widely by country. As do the solutions adopted for number portability. > > This seems to me to argue that you need to get significant input from > national regulators around the world if you want to develop truly > policy-neutral solutions. > > Best, > Richard From nobody Fri Jun 26 14:10:01 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 602B01A6EF4 for ; Fri, 26 Jun 2015 14:10:00 -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 ModgbGe9jlgK for ; Fri, 26 Jun 2015 14:09:59 -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 1B2AC1A3BA2 for ; Fri, 26 Jun 2015 14:09:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABoS1IAABKmAgAABu4Y= Date: Fri, 26 Jun 2015 21:09:57 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> , <005a01d0b022$169bcbb0$43d36310$@ch> , <01e101d0b053$a1192c20$e34b8460$@ch> In-Reply-To: <01e101d0b053$a1192c20$e34b8460$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 21:10:00 -0000 Rather than individuals sending drafts to ITU-T SG2, it may well be more pr= oductive to have engineering-level discussions here and then, as there are = concrete and specific proposals that have received some technical vetting, = solicit feedback early from any number of parties, including SG2. Obviously= , the IETF mailing lists and drafts are freely accessible without membershi= p requirement, so any interested party can take a look at any time or they = can wait until there's a more specific or baked proposal. Trying to prevent= technical work doesn't seem to help progress, however.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Richard Hill [rhill@hill-a.ch]=0A= Sent: Friday, June 26, 2015 5:04 PM=0A= To: Henning Schulzrinne; 'McGarry, Tom'; modern@ietf.org=0A= Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Indeed I agree that a constructive approach would be to do this work in=0A= cooperation between the IETF and the ITU-T, because, as you correctly say,= =0A= they typically draw different types of experts as participants.=0A= =0A= And I do agree that it is better to present some concrete proposals and ask= =0A= whether they have policy implications, rather than to ask for abstract=0A= requirements which may be difficult to formulate.=0A= =0A= But I still don't understand why the people who wish to develop the propose= d=0A= protocols don't simply send their proposals to ITU-T Study Group 2 and see= =0A= how that group reacts.=0A= =0A= And, to begin with, why nobody seems to have thought of sending the draft= =0A= working group charter to ITU-T Study Group 2 to see what they thought of it= .=0A= =0A= Best,=0A= Richard=0A= From nobody Fri Jun 26 14:22:48 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 84A461A8A54 for ; Fri, 26 Jun 2015 14:22:47 -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 QaKdVAaGKYbF for ; Fri, 26 Jun 2015 14:22:46 -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 1F3A31A89B8 for ; Fri, 26 Jun 2015 14:22:46 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+9ZjoAABoRAgAABGMKAAAJrcIAAAL54 Date: Fri, 26 Jun 2015 21:22:23 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , , <01de01d0b052$da16ab70$8e440250$@ch> , <01ea01d0b054$5cacbbf0$160633d0$@ch> In-Reply-To: <01ea01d0b054$5cacbbf0$160633d0$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 21:22:47 -0000 Thanks for the document. However, it seems to address a somewhat different = problem, namely how to route calls in a number-ported environment. In case = that isn't clear, I'm pretty sure nobody here is proposing implementing or = specifying call routing, with or without porting, in this working group. Th= e part that is more relevant to number administration is the interaction be= tween consumer (subscriber) and the gaining/losing carrier so that the gain= ing carrier can update any call routing instructions, for example.=0A= =0A= To make this more concrete, this may involve a process where the gaining ca= rrier, once ready to offer service, sends a protocol message to the losing = carrier or where the possession of credentials by one or more of the partic= ipants (consumer/subscriber, gaining/losing carrier) is used to effect the = change in number holding. Beyond the scope of the effort is any update of c= all routing (SS7, say) databases. In practice, as today, numbering-related = database information is likely to influence those databases, but the detail= s seem beyond the scope of this effort.=0A= =0A= In many cases, the protocol work is likely to simply specify the message, w= ith processes such as third-party verification ("did you really mean to cha= nge carriers?") or policies ("must be ported only after party X has agreed = and check Y has completed") well outside the scope of any IETF work.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Richard Hill [rhill@hill-a.ch]=0A= Sent: Friday, June 26, 2015 5:09 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Regarding numbering portability, you may be interested in this ITU-T=0A= document:=0A= =0A= http://www.itu.int/rec/T-REC-E.164-201406-I!Sup2=0A= =0A= Best,=0A= Richard=0A= From nobody Fri Jun 26 14:23:32 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B576C1A8AB4 for ; Fri, 26 Jun 2015 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qc_zEZfpICoH for ; Fri, 26 Jun 2015 14:23:28 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 DC7F71A8AB5 for ; Fri, 26 Jun 2015 14:23:20 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QLNHYG023998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jun 2015 23:23:17 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5QLNHPL022945; Fri, 26 Jun 2015 23:23:17 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> , <005a01d0b022$169bcbb0$43d36310$@ch> , <01e101d0b053$a1192c20$e34b8460$@ch> In-Reply-To: Date: Fri, 26 Jun 2015 23:23:18 +0200 Message-ID: <01ed01d0b056$52395730$f6ac0590$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABoS1IAABKmAgAABu4aAAAO2sA== Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 21:23:30 -0000 Indeed there are at least two ways to proceed. One would be for Neustar, which is an ITU-T member, and other interested parties to submit their proposals directly to ITU-T for discussion. The other would be for this group to start to do some work and then to liaise it to ITU-T Study Group 2. But the first step would be to communicate the draft charter to ITU-T Study Group 2 to see if they have any comments. Personally, I think that the first approach above would be the best if the intent is to develop solutions that would be used in several countries, because it would be faster. In case people don't know, work such as this is carried out in ITU-T in what they call "Rapporteur Groups" or "Editor Groups". Those groups can (and should) meet outside of the official ITU meeting so they can allow (indeed encourage) participation from entities that are not ITU members. And if the intent is to develop US-only solutions, then I still don't see why the IETF should be involved: do the work in a US-only body. Best, Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Friday, June 26, 2015 23:10 > To: Richard Hill; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Rather than individuals sending drafts to ITU-T SG2, it may well be > more productive to have engineering-level discussions here and then, as > there are concrete and specific proposals that have received some > technical vetting, solicit feedback early from any number of parties, > including SG2. Obviously, the IETF mailing lists and drafts are freely > accessible without membership requirement, so any interested party can > take a look at any time or they can wait until there's a more specific > or baked proposal. Trying to prevent technical work doesn't seem to > help progress, however. > > Henning > > ________________________________________ > From: Richard Hill [rhill@hill-a.ch] > Sent: Friday, June 26, 2015 5:04 PM > To: Henning Schulzrinne; 'McGarry, Tom'; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Indeed I agree that a constructive approach would be to do this work in > cooperation between the IETF and the ITU-T, because, as you correctly > say, they typically draw different types of experts as participants. > > And I do agree that it is better to present some concrete proposals and > ask whether they have policy implications, rather than to ask for > abstract requirements which may be difficult to formulate. > > But I still don't understand why the people who wish to develop the > proposed protocols don't simply send their proposals to ITU-T Study > Group 2 and see how that group reacts. > > And, to begin with, why nobody seems to have thought of sending the > draft working group charter to ITU-T Study Group 2 to see what they > thought of it. > > Best, > Richard From nobody Fri Jun 26 14:52: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 7D9731AC3EC for ; Fri, 26 Jun 2015 14:52:28 -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 Vdrafznf7L7f for ; Fri, 26 Jun 2015 14:52:26 -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 6A8AC1AC3D2 for ; Fri, 26 Jun 2015 14:52:26 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+iBXoAACgnQgAAMREg= Date: Fri, 26 Jun 2015 21:52:24 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , , <01db01d0b052$6ffe2d80$4ffa8880$@ch> In-Reply-To: <01db01d0b052$6ffe2d80$4ffa8880$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 26 Jun 2015 21:52:28 -0000 I'll let other NRA staff speak for themselves, but a number were present du= ring the IETF Dallas BOF, from what I recall.=0A= =0A= The NANC documents can be found at=0A= =0A= http://nanc-chair.org/=0A= =0A= FTN 7 is probably the most relevant effort. (I haven't actively participate= d in the effort since this is an advisory committee to the FCC, but I think= we have NANC participants on the mailing list who might be willing to prov= ide updates; contact information is provided on the meeting slides.)=0A= =0A= The protocols being discussed have two "IP" angles: They are based on IP it= self (rather than, say, TCAP) and they are likely most relevant in all-IP (= VoIP) environments where both new entrants and carriers transitioning to an= all-IP environment are more likely to use new number management approaches= that are not encumbered by legacy constraints. As you well know, many of t= hose VoIP protocols have their technical home in the IETF.=0A= =0A= I don't think anybody is proposing changing the US numbering plan (e.g., th= e number of digits in a phone number or fixed-vs-variable length) and that = is well outside the scope of any IETF effort that I could imagine. I'm more= concerned with the hodge-podge of numbering-related databases that have em= erged over the decades and all made sense at some point.=0A= =0A= For number porting (i.e., the change of the carrier or other authorized ent= ity that controls attributes related to a phone number), this has been a ch= icken-and-egg problem to some extent: From my experience, policy makers ten= d to want to have access to tools before making rules, so it is helpful to = have a set of technical options available that then allow policy flexibilit= y at a much more rapid pace than the current change order model, including = real-world experimentation before making policy changes.=0A= =0A= We don't seem to be communicating on the "assignment model". I'm talking ab= out the technical entities that manage the assignment, not who can get what= numbers. (This is indeed, as we all seem to agree but seem to be repeating= again and again, an NRA issue well beyond IETF scope.) The LNPA pain that = you may not be familiar with is the transition, after a competitive bidding= process, between the previous contracted number management entity and the = new one. Having engineering options that bypass or minimize such disputes, = should an NRA want to avail themselves of those, is one interest of mine.= =0A= =0A= My point about "new entrants" is simply that incumbents are not the only au= dience for this. We may not know exactly who will be playing in this sandbo= x in ten years (and neither the ITU nor the IETF are in the sandbox admissi= on policing business), but it's pretty clear that there will be new kids on= the playground.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Richard Hill [rhill@hill-a.ch]=0A= Sent: Friday, June 26, 2015 4:55 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Please see inline.=0A= =0A= > -----Original Message-----=0A= > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning=0A= > Schulzrinne=0A= > Sent: Friday, June 26, 2015 22:30=0A= > To: modern@ietf.org=0A= > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,=0A= > Distributing, Exposing, & Registering telephone Numbers (modern)=0A= >=0A= > Since the nesting is getting confusing, let me add a few general points= =0A= > that refer to a number of different discussion items:=0A= >=0A= > * My sense is that a number of national regulators=0A= =0A= Can you specify which national regulators are aware of the creation of the= =0A= proposed working group, other than the FCC, which I presume you are=0A= representing in this discussion?=0A= =0A= > are well aware of=0A= > the MODERN work. NANC has been kept in the loop, and their input on=0A= > requirements (e.g., through their Future of Numbering (FON) effort)=0A= =0A= Can you please give the URL for the cited documents?=0A= =0A= =0A= >=0A= > * I'm not sure other standards bodies have demonstrated equivalent IP-=0A= > based design experience, but (as noted) I suspect everybody welcomes=0A= > inputs from as many interested parties as possible.=0A= =0A= I'm not sure that I understand what the IP-based specifics are of the=0A= project. As I understand it, the idea is to develop protocols for=0A= specifying requests to get numbers, etc. How is that specifically tied to= =0A= TCP/IP?=0A= =0A= =0A= >=0A= > * The current number porting model (in the US) predates the Internet=0A= > and leaves room for improvement from a consumer and carrier=0A= > perspective.=0A= =0A= No kidding. The US numbering plan is, in my view, obsolete and badly in nee= d=0A= of reform. But US industry and US authorities don't seem to agree (or at=0A= least they didn't last time I checked a couple of years ago).=0A= =0A= =0A= >=0A= > * The current assignment model (at least in the US) is not a model of=0A= > efficiency and flexibility. There are numerous examples, but the most=0A= > recent difficult transition process of the LNPA is a high-profile one.=0A= =0A= This is no doubt correct, but, again, changes in the assignment model are i= n=0A= the remit of the FCC, not the IETF (again, correct me if I'm wrong about=0A= that).=0A= =0A= >=0A= > * Traditional carriers may not be the only "customers". In IETF work,=0A= > there's sometimes the danger of equating the installed base with the=0A= > total market.=0A= =0A= Indeed, I think that carriers should not be the only recipients of telephon= e=0A= numbers. But, again, that is a policy question that is not in the remit of= =0A= the IETF (but correct me if I'm wrong about that).= From nobody Sat Jun 27 01:31:52 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 1B0D81A8726 for ; Sat, 27 Jun 2015 01:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dJtRE9Sm6aCs for ; Sat, 27 Jun 2015 01:31:47 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 0F7811A70FE for ; Sat, 27 Jun 2015 01:31:46 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5R8VgrC010395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 27 Jun 2015 10:31:43 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5R8Vfjj021254; Sat, 27 Jun 2015 10:31:42 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , , <01db01d0b052$6ffe2d80$4ffa8880$@ch> In-Reply-To: Date: Sat, 27 Jun 2015 10:31:42 +0200 Message-ID: <002701d0b0b3$b2b69890$1823c9b0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+iBXoAACgnQgAAMREiAAK4gwA== Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 08:31:51 -0000 Dear Henning, Thank you for this and please see embedded comments below. Best, Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Friday, June 26, 2015 23:52 > To: Richard Hill; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > I'll let other NRA staff speak for themselves, I see two other people from FCC on this list, and one each from the Swiss and UK national regulatory authorities. I don't see anybody else. But maybe I missed some. > but a number were > present during the IETF Dallas BOF, from what I recall. > > The NANC documents can be found at > > http://nanc-chair.org/ That's the North American Numbering Plan, which concerns mostly the US, with some input from Canada, since the other countries are mostly too small to have much of a stake in whatever is decided. > > FTN 7 is probably the most relevant effort. (I haven't actively > participated in the effort since this is an advisory committee to the > FCC, but I think we have NANC participants on the mailing list who > might be willing to provide updates; contact information is provided on > the meeting slides.) I suppose that you are referring to this: http://nanc-chair.org/docs/mtg_docs/Jun15_FoN_Report.pptx That presentation says "The Working Group will investigate new telephone numbering assignment approaches and future telephone number assignment requirements." So it is about changes that may require changes to current regulatory policies. But maybe you were referring to a different document. > > The protocols being discussed have two "IP" angles: They are based on > IP itself (rather than, say, TCAP) and they are likely most relevant in > all-IP (VoIP) environments where both new entrants and carriers > transitioning to an all-IP environment are more likely to use new > number management approaches that are not encumbered by legacy > constraints. Yes, but as I understand the charter, the proposed work is mostly about figuring out how best to automate certain information flows. In my experience, that quickly leads to thinking about business process engineering, as we did for Electronic Data Interchange (EDI). In the USA, much of that work was done by ANSI, with the IETF contribution being limited to protocols for transmitting data. That is, the IETF did not get into the EDI equivalents of "managing, distributing, registering", etc. >As you well know, many of those VoIP protocols have their > technical home in the IETF. Yes, and as you also know well, some of the VoIP protocols have their technical home in the ITU-T. Indeed you wrote an article comparing SIP to H.323, at: http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.pdf There seem to be divergent opinions regarding the relative merits of H.323 and SIP, and on which has greater market share, but for sure both are widely deployed, see: http://www.packetizer.com/ipmc/h323_vs_sip/ http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00 80092947.shtml http://www.dailypayload.com/content/3111 And some people think that both are obsolete and should/will be replaced by something newer, see for example: https://bloggeek.me/h323-sip-xmpp-js/ Be that as it may, the codecs standardized by ITU-T seem still to be widely used, so apparently ITU-T is also able to produce ways of packaging bits that are commercially useful. But, as I said above, I doubt that the thrust of the work of the proposed Working Group would actually be about how to package bits. It seems to me that it will be more related to business processes and business process engineering, which is not an area in which the IETF has traditionally been active. > > I don't think anybody is proposing changing the US numbering plan > (e.g., the number of digits in a phone number or fixed-vs-variable > length) Pity because, as I said before, I think that that is long overdue. I didn't say it before, but I think that the whole idea of using one E.164 geographic country code for many countries is a deleterious relic of the past, a "legacy system" in the worst sense of the term. In my view, the US should take "1" for itself and the other countries should get new codes (or, if the US were willing to share more equitably, it could move to 11 and free up 9 codes). And the US could take advantage of that change to expand its numbering plan. (As you know, most countries have expanded their numbering plans during the past 20 years.) >and that is well outside the scope of any IETF effort that I > could imagine. True. But it would not necessarily outside the scope of ITU-T Study Group 2, if everybody agreed that the matter should be discussed in ITU-T. But maybe that's one of the reasons why some people would prefer not to bring the matter to the ITU: they wish to ensure that the scope of the discussions is restricted. That's certainly a legitimate desire, but I would submit that it would be better fulfilled by creating an ad-hoc group to discuss the matter. As several people have pointed out, IETF is open, so you never know what will be brought into discussions. >I'm more concerned with the hodge-podge of numbering- > related databases that have emerged over the decades and all made sense > at some point. Indeed. But, again, this is not a matter of figuring out how to package bits. It is a business process issue. And the IETF has not typically been involved in those sorts of issues, at least not for what concerns telephone numbers. Whereas ITU-T Study Group 2 has considered such matters. > > For number porting (i.e., the change of the carrier or other authorized > entity that controls attributes related to a phone number), this has > been a chicken-and-egg problem to some extent: From my experience, > policy makers tend to want to have access to tools before making rules, > so it is helpful to have a set of technical options available that then > allow policy flexibility at a much more rapid pace than the current > change order model, including real-world experimentation before making > policy changes. Agreed. But, again, this is an argument in favor of conducting the discussions in an environment where there will be policy makers. And more policy makers participate in ITU-T than in IETF. > > We don't seem to be communicating on the "assignment model". I'm > talking about the technical entities that manage the assignment, not > who can get what numbers. I did understand that distinction. But which technical entities do what is a policy matter, not a protocol issue. In the US, the technical management is performed by a private sector entity. That is not the case elsewhere. So, elsewhere, anything related to the management of the assignments involves the national regulator. >(This is indeed, as we all seem to agree but > seem to be repeating again and again, an NRA issue well beyond IETF > scope.) The LNPA pain that you may not be familiar with is the > transition, after a competitive bidding process, between the previous > contracted number management entity and the new one. Having engineering > options that bypass or minimize such disputes, should an NRA want to > avail themselves of those, is one interest of mine. I don't follow the US developments closely, but I had heard that Neustar lost its contract, or might lose its contract, or something to that effect. Perhaps you could provide more detail on what you outline above, so that we all have the same level of understanding of what is happening in the US. > > My point about "new entrants" is simply that incumbents are not the > only audience for this. We may not know exactly who will be playing in > this sandbox in ten years (and neither the ITU nor the IETF are in the > sandbox admission policing business), Actually the ITU is in the sandbox admission business, for the non-geographic country codes (881, 882, 883). For many years there were few requests, about 1-2 per year. But things have picked up now and they are getting several requests per year. And ITU is in the policing business, even if it has no enforcement powers, with respect to misuse of E.164 numbers. Both issues may be related to some of the work of the proposed Working Group. > but it's pretty clear that there > will be new kids on the playground. In my view, there would be more new kids if the legacy US numbering plan were reformed. For example, if you had dedicated area codes for mobile, then some mobile operators could envisage offering "caller pays" pricing plans. I know that some people think that "receiver pays" is the only model that makes sense, but in fact most of the world uses "caller pays". And the proportion of people who move to relatively expensive flat rate plans might be different if they could choose between caller pays and receiver pays. > > Henning > > ________________________________________ > From: Richard Hill [rhill@hill-a.ch] > Sent: Friday, June 26, 2015 4:55 PM > To: Henning Schulzrinne; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Please see inline. > > > -----Original Message----- > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning > > Schulzrinne > > Sent: Friday, June 26, 2015 22:30 > > To: modern@ietf.org > > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > > Distributing, Exposing, & Registering telephone Numbers (modern) > > > > Since the nesting is getting confusing, let me add a few general > > points that refer to a number of different discussion items: > > > > * My sense is that a number of national regulators > > Can you specify which national regulators are aware of the creation of > the proposed working group, other than the FCC, which I presume you are > representing in this discussion? > > > are well aware of > > the MODERN work. NANC has been kept in the loop, and their input on > > requirements (e.g., through their Future of Numbering (FON) effort) > > Can you please give the URL for the cited documents? > > > > > > * I'm not sure other standards bodies have demonstrated equivalent > IP- > > based design experience, but (as noted) I suspect everybody welcomes > > inputs from as many interested parties as possible. > > I'm not sure that I understand what the IP-based specifics are of the > project. As I understand it, the idea is to develop protocols for > specifying requests to get numbers, etc. How is that specifically tied > to TCP/IP? > > > > > > * The current number porting model (in the US) predates the Internet > > and leaves room for improvement from a consumer and carrier > > perspective. > > No kidding. The US numbering plan is, in my view, obsolete and badly in > need of reform. But US industry and US authorities don't seem to agree > (or at least they didn't last time I checked a couple of years ago). > > > > > > * The current assignment model (at least in the US) is not a model of > > efficiency and flexibility. There are numerous examples, but the most > > recent difficult transition process of the LNPA is a high-profile > one. > > This is no doubt correct, but, again, changes in the assignment model > are in the remit of the FCC, not the IETF (again, correct me if I'm > wrong about that). > > > > > * Traditional carriers may not be the only "customers". In IETF work, > > there's sometimes the danger of equating the installed base with the > > total market. > > Indeed, I think that carriers should not be the only recipients of > telephone numbers. But, again, that is a policy question that is not in > the remit of the IETF (but correct me if I'm wrong about that). From nobody Sat Jun 27 05:05: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 0BAEC1B338D for ; Sat, 27 Jun 2015 05:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.438 X-Spam-Level: * X-Spam-Status: No, score=1.438 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DATE_IN_PAST_12_24=1.049, 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 I2Zm4cGm7Dke for ; Sat, 27 Jun 2015 05:05:36 -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 9963A1B338C for ; Sat, 27 Jun 2015 05:05:36 -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=1LWeRvSeo2KpgTIxd9Y+Q+YIapHA2wvxYbdOrvr4u7Y=; b=A3fGlCRVkvLP06mQxvry9NVRXKzVSZ83b1jZVoc71WC1TFvn8sEP80C7sURSC+YAt8/cvuAXtYidoxZM8NwsNMVktwYyAuw/RGZ2ySq2z2mg3gzDmgR4EtjUh+lpTCz5s2shLofR1MBWCc29LN2u/LsKfIhMIGIDC3bAths9VMc=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:63725 helo=[192.168.15.119]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Z8orW-0008QM-7E for modern@ietf.org; Sat, 27 Jun 2015 05:05:36 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_E9008007-5416-483E-9696-B762849771DA"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5 From: Eric Burger In-Reply-To: <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> Date: Fri, 26 Jun 2015 19:54:02 -0400 Message-Id: <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> To: "modern@ietf.org" X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-1.8 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] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 12:05:38 -0000 --Apple-Mail=_E9008007-5416-483E-9696-B762849771DA Content-Type: multipart/alternative; boundary="Apple-Mail=_1F24454E-808F-4583-B4B5-CE78E42173A8" --Apple-Mail=_1F24454E-808F-4583-B4B5-CE78E42173A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On the one hand, neither MGCP nor SIP do number assignments for phones. = It is irrelevant for MGCP, because the soft switch handles the numbers. = On the SIP side, phone provisioning is the purview of the SIPForum = device configuration specification. On the other hand, Cullen=E2=80=99s use case of a large enterprise doing = its own allocations of numbers across multiple campuses, and as such = down to the phone, was compelling to me. I do not think it has = regulatory issues, and it is a real problem that his customers would = like to see solved. Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of = other vendors and large enterprises would be interested. Any comments = from those folks? > On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] = wrote: >=20 > =E2=80=9COne would be an enterprise IP phone that has just been = deployed and wants to acquire a new number from an IP PBX.=E2=80=9D = There are two existing protocols which spring to mind which solve this = problem; MGCP and SIP. I=E2=80=99m sure others can point to other = similar protocols as well (e.g., NCS). And I would argue the = enterprise IP phone doesn=E2=80=99t get a new number, the IP PBX does. = The phone merely gets associated with the number provisioned in the IP = PBX in order to originate or terminate calls through the IP PBX. >=20 > I wasn=E2=80=99t able to attend the MODERN BoF so I=E2=80=99m not = familiar with the many use cases. In your example of the VoIP service = provider I have questions. Has it been determined that there are no = suitable existing number provisioning or number management protocols? = ESPP and TERQ spring to mind as examples of protocols which have been = previously developed by the IETF for such purposes and I=E2=80=99m sure = there are other examples as well. >=20 > And is a special protocol required for this example? Numerous peering = relationships are managed using spreadsheets in e-mail. It may be = manual, inelegant and prone to error, but it certainly is cheap and is = often used. Have there been VoIP providers that have claimed they are = disadvantaged because they don=E2=80=99t have a special protocol for = provisioning subtended number blocks with their carrier? >=20 > Best regards, >=20 >=20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > [snip] --Apple-Mail=_1F24454E-808F-4583-B4B5-CE78E42173A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On the one hand, neither MGCP nor SIP do number assignments = for phones. It is irrelevant for MGCP, because the soft switch handles = the numbers. On the SIP side, phone provisioning is the purview of the = SIPForum device configuration specification.

On the other hand, Cullen=E2=80=99s use = case of a large enterprise doing its own allocations of numbers across = multiple campuses, and as such down to the phone, was compelling to me. = I do not think it has regulatory issues, and it is a real problem that = his customers would like to see solved.

Besides Cisco, I would presume Avaya, = Unify, Oracle, and a handful of other vendors and large enterprises = would be interested. Any comments from those folks?

On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com> wrote:

=E2=80=9COne would be an enterprise IP phone that has just been = deployed and wants to acquire a new number from an IP PBX.=E2=80=9D  There are two existing protocols = which spring to mind which solve this problem; MGCP and SIP. I=E2=80=99m = sure others can point to other similar protocols as well (e.g., = NCS).   And I would argue the enterprise IP phone doesn=E2=80=99= t get a new number, the IP PBX does.  The phone merely gets = associated with the number provisioned in the IP PBX in order to = originate or terminate calls through the IP PBX.
 
I = wasn=E2=80=99t able to attend the MODERN BoF so I=E2=80=99m not familiar = with the many use cases.  In your example of the VoIP service = provider I have questions.  Has it been determined that there are = no suitable existing number provisioning or number management = protocols?  ESPP and TERQ spring to mind as examples of protocols = which have been previously developed by the IETF for such purposes and = I=E2=80=99m sure there are other examples as well.
 
And = is a special protocol required for this example?  Numerous peering = relationships are managed using spreadsheets in e-mail.  It may be = manual, inelegant and prone to error, but it certainly is cheap and is = often used.  Have there been VoIP providers that have claimed they = are disadvantaged because they don=E2=80=99t have a special protocol for = provisioning subtended number blocks with their carrier?
 
Best = regards,
 
 
Pierce = Gorman
Core Network = Planning
O: = 913-439-4368
<image001.png>
[snip]

= --Apple-Mail=_1F24454E-808F-4583-B4B5-CE78E42173A8-- --Apple-Mail=_E9008007-5416-483E-9696-B762849771DA 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 iQIcBAEBCAAGBQJVjeYaAAoJEDY/T2tCIPW3KSgP/2pAIXmvFMngPc9O2YQch1Ny Nl/PhHUq2FgjNPNH11bhW5eeDfoRXr+2/rQ5tpwY8oHlspJukAqePviOstn7Pt9m qsqtEg9784dRhLuROZh6RCB3Sp0UWTquR3GWJf8HY3Wc7+td1fnUVXiaQfj1ozOM IBI8iDZRrbDlFSdE1dvQdFvVAFrRF2100bmoxdMnyBRWTQUY1fd2qEqZ0GQvlcg2 429MVNHiuuPVLX87AN5vCoWy+GbUFObYLD4ZwqybEpK259UUW1HbxAmWU5DPnjvo n/gsGEDVu+A9R5EuDbLaJwyuHrBL6F2L1xGcbTbnJVMwXSZqGScx4JgKju39u3e6 gtw8LTWz86JMVSuyx6rrYvORKNP1dL65to+nh4xbggLiqfBw+t7FAIvxT54j/zos YiOdjkTXsDySMk49eA41muRF+Cb5PRYg+IME234WkPXgbahyqRlGedrDmsMH8iTv JSgVB70dV9L3XDkHEh/TxBDxp47ydChyaW0RgaqWshR4g82RZ2wLOHqMx45x6SLQ 1WBuE9j3Sx9A2l6Uq0sW7XM1ZoR/hhdoaLQfDOK0eiUPnluba7QwsGlGb2rvtqlQ AoSUWoOChS5Z1IQqmwO5h4XAWILHt8o/rZLWmNVVMFLfpjRTu76dBAlDIB0zythi vGITQ+pMWs/ThiT0VsBc =3prP -----END PGP SIGNATURE----- --Apple-Mail=_E9008007-5416-483E-9696-B762849771DA-- From nobody Sat Jun 27 06:07:35 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 D025F1A19FE for ; Sat, 27 Jun 2015 06:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHcYZ0-iaga5 for ; Sat, 27 Jun 2015 06:07:30 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476991A070E for ; Sat, 27 Jun 2015 06:07:30 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 110ae855.0.7775545.00-2016.22004322.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 27 Jun 2015 13:07:30 +0000 (UTC) X-MXL-Hash: 558ea012199bab4a-b806d5f97aa8f3e71e3fd6fd8c8c312ed82fb617 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5RD7SAg030675; Sat, 27 Jun 2015 09:07:29 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5RD7DDR030570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Jun 2015 09:07:24 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sat, 27 Jun 2015 13:07:07 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Sat, 27 Jun 2015 09:07:07 -0400 From: "DOLLY, MARTIN C" To: Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZk/EVKozy60OW6OdQfnITd53AUOow Date: Sat, 27 Jun 2015 13:07:06 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> In-Reply-To: <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.161.141] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656036462F7MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=bsn78jmi c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=QHza4DjpNGAA:10 a=jTUuR] X-AnalysisOut: [AvXLdMA:10 a=BLceEmwcHowA:10 a=XAFQembCKUMA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=izV7ms69AAAA:8 a=f7FovTPOzydjT8URJxIA:9 a=QEXdDO2u] X-AnalysisOut: [t3YA:10 a=DzjOOp_o1eYA:10 a=TzqvExmJBivXTJPq:21 a=q4UIF--H] X-AnalysisOut: [0GAospEH:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=UU4caYnrii] X-AnalysisOut: [xBWqa0P9oA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Y] X-AnalysisOut: [k6K0A:10 a=frz4AuCg-hUA:10 a=bBjFX2WMdLP4HJ7q:21 a=Jk7ZBrt] X-AnalysisOut: [J9VZtDxto:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 13:07:33 -0000 --_000_E42CCDDA6722744CB241677169E83656036462F7MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TnVtYmVycyBhcmUgYSB2YWx1YWJsZSByZXNvdXJjZS4NClRyYWRpdGlvbmFsbHksIHRoZSBGQ0Mg YXNzaWducyB0aGUgbnVtYmVycyB0byBzZXJ2aWNlIHByb3ZpZGVycywgdG8gd2hpY2ggdGhlIEZD QyByZWd1bGF0ZXMgYW5kIGNhbiBwdW5pc2ggd2l0aCBmaW5lcywgZXRj4oCmLiBJIGRvIG5vdCBi ZWxpZXZlIHRoZSBGQ0Mgd2lsbCBhc3NpZ24gbnVtYmVycyB0byBhbnlvbmUgdGhhdCB0aGV5IGNh bm5vdCBQVU5JU0ggaWYgYWJ1c2Ugb2NjdXJzLg0KWWVzIHRoZXJlIGhhdmUgYmVlbiBleHBlcmlt ZW50cyBhc3NpZ25pbmcgdG8gbm9uLXRyYWRpdGlvbmFsIFNQcywgYnV0IHRoZXNlIGNhbWUgd2l0 aCDigJxjb25kaXRpb25z4oCdDQpXUlQgYXNzaWduaW5nIG51bWJlcnMgdG8gRW50ZXJwcmlzZXMs IHdoZXJlIGlzIHRoZSBsaW5lIGRyYXduIGJldHdlZW4gYXNzaWduaW5nIHRvIENpc2NvIHZlcnN1 cyBIb3QgRG9nIHZlbmRvcj8/Pw0KDQoNCkZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVybi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBCdXJnZXINClNlbnQ6IEZyaWRheSwgSnVu ZSAyNiwgMjAxNSA3OjU0IFBNDQpUbzogbW9kZXJuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01v ZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0 aW5nLCBFeHBvc2luZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0K DQpPbiB0aGUgb25lIGhhbmQsIG5laXRoZXIgTUdDUCBub3IgU0lQIGRvIG51bWJlciBhc3NpZ25t ZW50cyBmb3IgcGhvbmVzLiBJdCBpcyBpcnJlbGV2YW50IGZvciBNR0NQLCBiZWNhdXNlIHRoZSBz b2Z0IHN3aXRjaCBoYW5kbGVzIHRoZSBudW1iZXJzLiBPbiB0aGUgU0lQIHNpZGUsIHBob25lIHBy b3Zpc2lvbmluZyBpcyB0aGUgcHVydmlldyBvZiB0aGUgU0lQRm9ydW0gZGV2aWNlIGNvbmZpZ3Vy YXRpb24gc3BlY2lmaWNhdGlvbi4NCg0KT24gdGhlIG90aGVyIGhhbmQsIEN1bGxlbuKAmXMgdXNl IGNhc2Ugb2YgYSBsYXJnZSBlbnRlcnByaXNlIGRvaW5nIGl0cyBvd24gYWxsb2NhdGlvbnMgb2Yg bnVtYmVycyBhY3Jvc3MgbXVsdGlwbGUgY2FtcHVzZXMsIGFuZCBhcyBzdWNoIGRvd24gdG8gdGhl IHBob25lLCB3YXMgY29tcGVsbGluZyB0byBtZS4gSSBkbyBub3QgdGhpbmsgaXQgaGFzIHJlZ3Vs YXRvcnkgaXNzdWVzLCBhbmQgaXQgaXMgYSByZWFsIHByb2JsZW0gdGhhdCBoaXMgY3VzdG9tZXJz IHdvdWxkIGxpa2UgdG8gc2VlIHNvbHZlZC4NCg0KQmVzaWRlcyBDaXNjbywgSSB3b3VsZCBwcmVz dW1lIEF2YXlhLCBVbmlmeSwgT3JhY2xlLCBhbmQgYSBoYW5kZnVsIG9mIG90aGVyIHZlbmRvcnMg YW5kIGxhcmdlIGVudGVycHJpc2VzIHdvdWxkIGJlIGludGVyZXN0ZWQuIEFueSBjb21tZW50cyBm cm9tIHRob3NlIGZvbGtzPw0KDQpPbiBKdW4gMjYsIDIwMTUsIGF0IDE6MTcgUE0sIEdvcm1hbiwg UGllcmNlIEEgW0NUT10gPFBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbTxtYWlsdG86UGllcmNlLkdv cm1hbkBzcHJpbnQuY29tPj4gd3JvdGU6DQoNCuKAnE9uZSB3b3VsZCBiZSBhbiBlbnRlcnByaXNl IElQIHBob25lIHRoYXQgaGFzIGp1c3QgYmVlbiBkZXBsb3llZCBhbmQgd2FudHMgdG8gYWNxdWly ZSBhIG5ldyBudW1iZXIgZnJvbSBhbiBJUCBQQlgu4oCdICBUaGVyZSBhcmUgdHdvIGV4aXN0aW5n IHByb3RvY29scyB3aGljaCBzcHJpbmcgdG8gbWluZCB3aGljaCBzb2x2ZSB0aGlzIHByb2JsZW07 IE1HQ1AgYW5kIFNJUC4gSeKAmW0gc3VyZSBvdGhlcnMgY2FuIHBvaW50IHRvIG90aGVyIHNpbWls YXIgcHJvdG9jb2xzIGFzIHdlbGwgKGUuZy4sIE5DUykuICAgQW5kIEkgd291bGQgYXJndWUgdGhl IGVudGVycHJpc2UgSVAgcGhvbmUgZG9lc27igJl0IGdldCBhIG5ldyBudW1iZXIsIHRoZSBJUCBQ QlggZG9lcy4gIFRoZSBwaG9uZSBtZXJlbHkgZ2V0cyBhc3NvY2lhdGVkIHdpdGggdGhlIG51bWJl ciBwcm92aXNpb25lZCBpbiB0aGUgSVAgUEJYIGluIG9yZGVyIHRvIG9yaWdpbmF0ZSBvciB0ZXJt aW5hdGUgY2FsbHMgdGhyb3VnaCB0aGUgSVAgUEJYLg0KDQpJIHdhc27igJl0IGFibGUgdG8gYXR0 ZW5kIHRoZSBNT0RFUk4gQm9GIHNvIEnigJltIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBtYW55IHVz ZSBjYXNlcy4gIEluIHlvdXIgZXhhbXBsZSBvZiB0aGUgVm9JUCBzZXJ2aWNlIHByb3ZpZGVyIEkg aGF2ZSBxdWVzdGlvbnMuICBIYXMgaXQgYmVlbiBkZXRlcm1pbmVkIHRoYXQgdGhlcmUgYXJlIG5v IHN1aXRhYmxlIGV4aXN0aW5nIG51bWJlciBwcm92aXNpb25pbmcgb3IgbnVtYmVyIG1hbmFnZW1l bnQgcHJvdG9jb2xzPyAgRVNQUCBhbmQgVEVSUSBzcHJpbmcgdG8gbWluZCBhcyBleGFtcGxlcyBv ZiBwcm90b2NvbHMgd2hpY2ggaGF2ZSBiZWVuIHByZXZpb3VzbHkgZGV2ZWxvcGVkIGJ5IHRoZSBJ RVRGIGZvciBzdWNoIHB1cnBvc2VzIGFuZCBJ4oCZbSBzdXJlIHRoZXJlIGFyZSBvdGhlciBleGFt cGxlcyBhcyB3ZWxsLg0KDQpBbmQgaXMgYSBzcGVjaWFsIHByb3RvY29sIHJlcXVpcmVkIGZvciB0 aGlzIGV4YW1wbGU/ICBOdW1lcm91cyBwZWVyaW5nIHJlbGF0aW9uc2hpcHMgYXJlIG1hbmFnZWQg dXNpbmcgc3ByZWFkc2hlZXRzIGluIGUtbWFpbC4gIEl0IG1heSBiZSBtYW51YWwsIGluZWxlZ2Fu dCBhbmQgcHJvbmUgdG8gZXJyb3IsIGJ1dCBpdCBjZXJ0YWlubHkgaXMgY2hlYXAgYW5kIGlzIG9m dGVuIHVzZWQuICBIYXZlIHRoZXJlIGJlZW4gVm9JUCBwcm92aWRlcnMgdGhhdCBoYXZlIGNsYWlt ZWQgdGhleSBhcmUgZGlzYWR2YW50YWdlZCBiZWNhdXNlIHRoZXkgZG9u4oCZdCBoYXZlIGEgc3Bl Y2lhbCBwcm90b2NvbCBmb3IgcHJvdmlzaW9uaW5nIHN1YnRlbmRlZCBudW1iZXIgYmxvY2tzIHdp dGggdGhlaXIgY2Fycmllcj8NCg0KQmVzdCByZWdhcmRzLA0KDQoNClBpZXJjZSBHb3JtYW4NCkNv cmUgTmV0d29yayBQbGFubmluZw0KTzogOTEzLTQzOS00MzY4DQpwaWVyY2UuZ29ybWFuQHNwcmlu dC5jb208bWFpbHRvOnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbT4NCjxpbWFnZTAwMS5wbmc+DQpb c25pcF0NCg0K --_000_E42CCDDA6722744CB241677169E83656036462F7MISOUT7MSGUSRDB_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5OdW1i ZXJzIGFyZSBhIHZhbHVhYmxlIHJlc291cmNlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRyYWRpdGlv bmFsbHksIHRoZSBGQ0MgYXNzaWducyB0aGUgbnVtYmVycyB0byBzZXJ2aWNlIHByb3ZpZGVycywg dG8gd2hpY2ggdGhlIEZDQyByZWd1bGF0ZXMgYW5kIGNhbiBwdW5pc2ggd2l0aCBmaW5lcywgZXRj 4oCmLiBJIGRvIG5vdCBiZWxpZXZlIHRoZSBGQ0Mgd2lsbCBhc3NpZ24NCiBudW1iZXJzIHRvIGFu eW9uZSB0aGF0IHRoZXkgY2Fubm90IFBVTklTSCBpZiBhYnVzZSBvY2N1cnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlllcyB0aGVyZSBoYXZlIGJlZW4gZXhwZXJpbWVudHMgYXNzaWduaW5nIHRvIG5vbi10 cmFkaXRpb25hbCBTUHMsIGJ1dCB0aGVzZSBjYW1lIHdpdGgg4oCcY29uZGl0aW9uc+KAnTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5XUlQgYXNzaWduaW5nIG51bWJlcnMgdG8gRW50ZXJwcmlzZXMsIHdoZXJl IGlzIHRoZSBsaW5lIGRyYXduIGJldHdlZW4gYXNzaWduaW5nIHRvIENpc2NvIHZlcnN1cyBIb3Qg RG9nIHZlbmRvcj8/PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1vZGVybiBbbWFpbHRvOm1vZGVybi1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIEJ1cmdlcjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEp1bmUgMjYsIDIwMTUgNzo1NCBQTTxicj4NCjxiPlRvOjwvYj4gbW9kZXJuQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTW9kZXJuXSBbbmV3LXdvcmtdIFdHIFJl dmlldzogTWFuYWdpbmcsIE9yZGVyaW5nLCBEaXN0cmlidXRpbmcsIEV4cG9zaW5nLCAmYW1wOyBS ZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIHRoZSBvbmUgaGFuZCwgbmVpdGhlciBNR0NQ IG5vciBTSVAgZG8gbnVtYmVyIGFzc2lnbm1lbnRzIGZvciBwaG9uZXMuIEl0IGlzIGlycmVsZXZh bnQgZm9yIE1HQ1AsIGJlY2F1c2UgdGhlIHNvZnQgc3dpdGNoIGhhbmRsZXMgdGhlIG51bWJlcnMu IE9uIHRoZSBTSVAgc2lkZSwgcGhvbmUgcHJvdmlzaW9uaW5nIGlzIHRoZSBwdXJ2aWV3IG9mIHRo ZSBTSVBGb3J1bSBkZXZpY2UgY29uZmlndXJhdGlvbiBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdGhlIG90aGVyIGhhbmQsIEN1 bGxlbuKAmXMgdXNlIGNhc2Ugb2YgYSBsYXJnZSBlbnRlcnByaXNlIGRvaW5nIGl0cyBvd24gYWxs b2NhdGlvbnMgb2YgbnVtYmVycyBhY3Jvc3MgbXVsdGlwbGUgY2FtcHVzZXMsIGFuZCBhcyBzdWNo IGRvd24gdG8gdGhlIHBob25lLCB3YXMgY29tcGVsbGluZyB0byBtZS4gSSBkbyBub3QgdGhpbmsg aXQgaGFzIHJlZ3VsYXRvcnkgaXNzdWVzLCBhbmQgaXQgaXMgYSByZWFsIHByb2JsZW0NCiB0aGF0 IGhpcyBjdXN0b21lcnMgd291bGQgbGlrZSB0byBzZWUgc29sdmVkLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXNpZGVzIENpc2NvLCBJIHdv dWxkIHByZXN1bWUgQXZheWEsIFVuaWZ5LCBPcmFjbGUsIGFuZCBhIGhhbmRmdWwgb2Ygb3RoZXIg dmVuZG9ycyBhbmQgbGFyZ2UgZW50ZXJwcmlzZXMgd291bGQgYmUgaW50ZXJlc3RlZC4gQW55IGNv bW1lbnRzIGZyb20gdGhvc2UgZm9sa3M/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gSnVuIDI2LCAyMDE1LCBhdCAxOjE3IFBNLCBHb3JtYW4sIFBpZXJj ZSBBIFtDVE9dICZsdDs8YSBocmVmPSJtYWlsdG86UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tIj5Q aWVyY2UuR29ybWFuQHNwcmludC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+ 4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T25lIHdvdWxkIGJlIGFuIGVudGVycHJpc2UgSVAg cGhvbmUgdGhhdCBoYXMganVzdCBiZWVuIGRlcGxveWVkIGFuZCB3YW50cyB0byBhY3F1aXJlIGEg bmV3DQogbnVtYmVyIGZyb20gYW4gSVAgUEJYLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDAwQ0MiPuKAnSZuYnNwOyBUaGVyZSBhcmUgdHdvIGV4aXN0aW5nIHByb3RvY29scyB3aGljaCBz cHJpbmcgdG8gbWluZCB3aGljaCBzb2x2ZSB0aGlzIHByb2JsZW07IE1HQ1AgYW5kIFNJUC4gSeKA mW0gc3VyZSBvdGhlcnMgY2FuIHBvaW50IHRvIG90aGVyIHNpbWlsYXIgcHJvdG9jb2xzIGFzDQog d2VsbCAoZS5nLiwgTkNTKS4mbmJzcDsgJm5ic3A7QW5kIEkgd291bGQgYXJndWUgdGhlIGVudGVy cHJpc2UgSVAgcGhvbmUgZG9lc27igJl0IGdldCBhIG5ldyBudW1iZXIsIHRoZSBJUCBQQlggZG9l cy4mbmJzcDsgVGhlIHBob25lIG1lcmVseSBnZXRzIGFzc29jaWF0ZWQgd2l0aCB0aGUgbnVtYmVy IHByb3Zpc2lvbmVkIGluIHRoZSBJUCBQQlggaW4gb3JkZXIgdG8gb3JpZ2luYXRlIG9yIHRlcm1p bmF0ZSBjYWxscyB0aHJvdWdoIHRoZSBJUCBQQlguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAw MENDIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPkkgd2FzbuKAmXQgYWJs ZSB0byBhdHRlbmQgdGhlIE1PREVSTiBCb0Ygc28gSeKAmW0gbm90IGZhbWlsaWFyIHdpdGggdGhl IG1hbnkgdXNlIGNhc2VzLiZuYnNwOyBJbiB5b3VyIGV4YW1wbGUgb2YgdGhlIFZvSVAgc2Vydmlj ZSBwcm92aWRlciBJIGhhdmUgcXVlc3Rpb25zLiZuYnNwOyBIYXMgaXQgYmVlbg0KIGRldGVybWlu ZWQgdGhhdCB0aGVyZSBhcmUgbm8gc3VpdGFibGUgZXhpc3RpbmcgbnVtYmVyIHByb3Zpc2lvbmlu ZyBvciBudW1iZXIgbWFuYWdlbWVudCBwcm90b2NvbHM/Jm5ic3A7IEVTUFAgYW5kIFRFUlEgc3By aW5nIHRvIG1pbmQgYXMgZXhhbXBsZXMgb2YgcHJvdG9jb2xzIHdoaWNoIGhhdmUgYmVlbiBwcmV2 aW91c2x5IGRldmVsb3BlZCBieSB0aGUgSUVURiBmb3Igc3VjaCBwdXJwb3NlcyBhbmQgSeKAmW0g c3VyZSB0aGVyZSBhcmUgb3RoZXIgZXhhbXBsZXMNCiBhcyB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5BbmQg aXMgYSBzcGVjaWFsIHByb3RvY29sIHJlcXVpcmVkIGZvciB0aGlzIGV4YW1wbGU/Jm5ic3A7IE51 bWVyb3VzIHBlZXJpbmcgcmVsYXRpb25zaGlwcyBhcmUgbWFuYWdlZCB1c2luZyBzcHJlYWRzaGVl dHMgaW4gZS1tYWlsLiZuYnNwOyBJdCBtYXkgYmUgbWFudWFsLCBpbmVsZWdhbnQgYW5kDQogcHJv bmUgdG8gZXJyb3IsIGJ1dCBpdCBjZXJ0YWlubHkgaXMgY2hlYXAgYW5kIGlzIG9mdGVuIHVzZWQu Jm5ic3A7IEhhdmUgdGhlcmUgYmVlbiBWb0lQIHByb3ZpZGVycyB0aGF0IGhhdmUgY2xhaW1lZCB0 aGV5IGFyZSBkaXNhZHZhbnRhZ2VkIGJlY2F1c2UgdGhleSBkb27igJl0IGhhdmUgYSBzcGVjaWFs IHByb3RvY29sIGZvciBwcm92aXNpb25pbmcgc3VidGVuZGVkIG51bWJlciBibG9ja3Mgd2l0aCB0 aGVpciBjYXJyaWVyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+QmVzdCByZWdhcmRzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMEND Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDo1LjhwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDAwQ0MiPlBpZXJjZSBHb3JtYW48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6NS44cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPkNvcmUgTmV0d29yayBQbGFubmluZzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjUuOHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5POiA5 MTMtNDM5LTQzNjg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDo1LjhwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMDBDQyI+PGEgaHJlZj0ibWFpbHRvOnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tPC9zcGFuPjwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdo dDo1LjhwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MDBDQyI+Jmx0O2ltYWdlMDAxLnBuZyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+W3NuaXBdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_E42CCDDA6722744CB241677169E83656036462F7MISOUT7MSGUSRDB_-- From nobody Sat Jun 27 06:24: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 5E4471A1B1C for ; Sat, 27 Jun 2015 06:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 QjM1jK728pSp for ; Sat, 27 Jun 2015 06:24:29 -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 329231A1B19 for ; Sat, 27 Jun 2015 06:24:29 -0700 (PDT) Received: by qgal13 with SMTP id l13so42355132qga.3 for ; Sat, 27 Jun 2015 06:24:28 -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=SQlaQENP/8TCXHy/1T2yLHAjFq1b60M2CBq02sLsI08=; b=P9iMXDNxYWCuWUPRF0c1d4BgvcwR7AEPbg5EQ3dCZVhEPyBERyL+eTLCoL9799powg DFBLlhyzgKBF1wYqYCIjINFfscVJ6dDM2MgUbw+V/hGLHkhZctj/WWM7VkMVBCL3bPWK cXgyEFD/JeljX8Hym0uypc/bLNFZ/EayqSpIWtK8hmAv5unOOmMIM/QVgOHVpwIh4Zzy RuCVjJ184acsxslEbkFFswMTMBkKwEKr0BqzEQ0IDtjGd492ACET8Dn76mfCaYSne8Jr sv1SWi3JrL3sXnEw520TIgZwk+xCK19GBmea4mz9E4xIHgaAP0ZpTLVPKbygcTf5Fmhf n+pQ== X-Gm-Message-State: ALoCoQmgobtYkxy53KMjrD3TjSGsjVo3pMYHUbOoYUKwZtOHHx7DQXPCDTh4R/zDONNyl6YF0dJU X-Received: by 10.55.23.195 with SMTP id 64mr14539475qkx.9.1435411468293; Sat, 27 Jun 2015 06:24:28 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9242:c830:805a:990a:f2f3? ([2601:41:c101:9242:c830:805a:990a:f2f3]) by mx.google.com with ESMTPSA id d8sm7556426qka.21.2015.06.27.06.24.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jun 2015 06:24:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5D77EF10-7C7C-4AF1-BFF4-CE728CF45180" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Chris Wendt In-Reply-To: Date: Sat, 27 Jun 2015 09:24:31 -0400 Message-Id: <76DDFC7A-41DE-46C1-9EEF-A9EFD6DA9BFF@chriswendt.net> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> To: "Peterson, Jon" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Richard Hill , "modern@ietf.org" , "McGarry, Tom" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 13:24:36 -0000 --Apple-Mail=_5D77EF10-7C7C-4AF1-BFF4-CE728CF45180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jon, I=92m trying to figure out the logic in the DNS analogy. =93Acquiring=94 a telephone number and =93Acquiring=94 an IP address are = both processes that involve little protocol work and lots of governance = to avoid wild-west attitude toward allocation of each currently as i = understand. The only analogy I can think about here is DNS manages FQDNs and records = associated with IP addresses and maybe calling-name or STIR certificates = would be a potential similar association to a telephone number? =20 Point is, I think the analogy is at the wrong level of process in the = lifecycle of IP addresses and where DNS protocols are involved. Maybe I=92m taking the importance of the analogy to far, but i think = there was a lot of emphasis on this analogy in the presentations. I = also do think they can be very helpful and/or hurtful if portrayed the = right way. In either case, it does seem an important and interesting = distinction to understand, because unless i=92m misinterpreting the = point of your analogy, is that IETF gets involved in DNS management = protocols so therefore it makes sense for IETF to develop protocols = associated with number management? To me, i would say that is incorrect = association and actually hurts your argument. -Chris > On Jun 26, 2015, at 12:34 PM, Peterson, Jon = wrote: >=20 >=20 > Your arguments here could equally well be applied to any important = resource on which the IETF does protocol work - like, say, the DNS. The = IETF manages the DNS protocol and publishes RFCs about it. But since = national authorities are responsible for ccTLDs, surely the IETF is not = a suitable body for managing the DNS! And it isn't. But it is a suitable = body for managing the protocol work on the DNS. Other, effectively = unrelated entities handle the administrative dimensions of operating the = DNS, and yes, at those bodies there are lots of national regulators and = they worry about the sorts of things you are worrying about here. The = IETF just produces tools, and that is all MODERN proposes to do. Trying = to characterize this effort otherwise is simply an error. >=20 > All work at the IETF is done by a coalition of the willing. If it = turns out that the coalition is not representative of the needs of the = community, then what happens? Well, the work built here doesn't get = used. The only people who wasted any time or effort were the members of = that coalition. No national interests can possibly be harmed by that, = even if the failed work involved ways of talking about telephone = numbers. This makes the IETF really different from places like the ITU, = where the products of work have some binding effect on the world. >=20 > Virtually all proposed work at the IETF also faces a coalition of the = unwilling. People who aren't interested, or who think the work should be = done elsewhere, or that the work simply shouldn't be done at all. But I = maintain your "formal objection" treats the scope of the proposed work = as being different than it is, and I'd agree that if this proposed work = required regulatory oversight, that the IETF shouldn't do it. But we're = just building some protocol tools. There is also related work here for = ATIS to do, and I'm sure ATIS or some other body could later take some = the protocol tools developed in the IETF and conduct an experiment with = various carriers to see if it works for that interest group or not, and = that would be interesting information. But the IETF doesn't do that = part, and doesn't aspire to do that part. >=20 > Finally, I'm not really sure how much I would expect "national = regulators" to literally use the tools proposed in this work. They are = tools for the use of a diverse industry of enterprises, carriers, end = users, and so on. Many use cases under consideration would not have a = national regulator as an actor. This work was in part instigated by an = FCC workshop, yes, and someone associated with the FCC spoke at the = MODERN BoF. But I don't anticipate that the FCC would be propping up = servers to deploy this work - surely they would leave that to industry.=20= >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Richard Hill > > Date: Friday, June 26, 2015 at 8:09 AM > To: "McGarry, Tom" >, "modern@ietf.org = " > > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > Thank you for this clarification. > =20 > Since the intent is to create tools and solutions that would be used = by national regulators, presumably they should be involved in the = development of the tools.=20 >=20 > As far as I know, national regulators from most countries don=92t = normally participate in the IETF, for a number of reasons, including the = IETF=92s decision-making process and the fact that the IETF works in = English. National regulators do participate in ITU-T, for a number of = reasons, including the ITU=92s decision-making process and the fact that = documents are translated into the six UN languages before they are = formally approved (and some discussions takes place with interpretation = in six languages). > =20 > If the intent is to develop tools that would be used only in the USA = at first, then I would suggest that it would be more appropriate to = develop them in a forum such as ATIS or an ad-hoc group created = specifically for the purpose. If the US experience proved successful, = then the tools could be proposed for adoption elsewhere, for example = through ITU-T. > =20 > If the intent is to develop tools for use in many countries right at = the start, then I would suggest that the appropriate forum would be = ITU-T, not IETF, for the reasons outlined above. > =20 > Thus, I formally object to the creation of this new working group, and = this even if the Charter is modified as suggested below. > =20 > Please see additional comments inline. > =20 > Thanks and best, > Richard > =20 > From: Modern [mailto:modern-bounces@ietf.org = ] On Behalf Of McGarry, Tom > Sent: vendredi, 26. juin 2015 00:31 > To: modern@ietf.org > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) > =20 > =20 > This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. = Entities can choose to use these tools or not. These tools are not for = the ITU-T's processes or role, nor for how national administrators = interact with the ITU-T. But of course we want your input and feedback, = so thanks for sending this along. More comments in line below. =20 > =20 > =20 > From: Alissa Cooper > > Date: Thursday, June 25, 2015 7:44 AM > To: Modern List > > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) > =20 > Would appreciate people=92s thoughts on whether any charter edits may = be warranted in response to these comments, and/or whether a separate = response may be useful for addressing some of the questions below. > =20 > Alissa > =20 > Begin forwarded message: >=20 >=20 > From: "Zhang, Jie" > > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern) > Date: June 23, 2015 at 1:56:42 PM GMT-3 > To: "iesg@ietf.org " > > Cc: "Jamoussi, Bilel" > >> Dear Sir/Madam, >>=20 >> Below please find comments from the ITU Telecommunication = Standardization Bureau on the proposed IETF working group MODERN. >>=20 >> 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1=20 >> It is stated at the beginning of the Charter that 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. And = it is mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to here = only deals with Tel URI? Would there be any impact on Recommendation = ITU-E E.164 and E.164.1 which are core recommendations on Telephone = Numbers? >=20 > There will be no impacts on E.164 and E.164.1. > =20 > >RH: Given the scope of the work, I think that it is too early to say = whether there would be an impact. Those Recommendations are regularly = updated, in particular E.164.1, so there is nothing wrong with = envisaging changes, with the recognition of course that the changes = would have to be proposed to ITI-T Study Group 2 and agreed by that = group. >>=20 >> 2. Entities participating in the defined mechanisms >> The Charter states that the protocol mechanism for resolving TNs will = allow entities such as service providers, devices, and applications to = access data related to TNs. But it is not clear what kind of entities = can participate in the mechanisms defined by this MODERN working group. = Would it be restricted to the entities who have been assigned a TN or a = block of TNS? >=20 > Who participates in numbering processes within countries is subject to = regulation. The WG cannot make any decisions with regard to this. I = expect the WG to define "roles" within the number management processes; = e.g., administrator, telecom carrier, application provider, consumer, = etc.; and how those roles could interact with each other. This will be = a baseline for what tools and solutions would be useful to facilitate = those interactions. =20 > =20 > >RH: Even that might be subject to, or affect, national regulations. = That is, the definition of a =93role=94 may well depend on national = regulations. >>=20 >> 3. Status of Telephone numbers in the defined mechanisms >> Several operations related to TNs are mentioned in the Charter, = including requesting, acquiring, resolving and associating. It is also = stated that the protocol mechanism for acquiring TNs will provide an = enrollment process for the entities that use and manage TNs. Does that = mean Telephone numbers with various status, such as assigned, spare and = reclaimed numbers will all be managed in the mechanisms defined by the = MODERN working group? >=20 > I would expect proposed solutions to be able to address the status of = a telephone number. > =20 > >RH: Since the terms =93assigned=94, =93spare=94 and =93reclaimed=94 = are defined in ITU-T Recommendations (albeit sometimes implicitly), = addressing the status of a telephone number might well impact E.164 or = E.164.1. >>=20 >> 4. Regulatory issues >> The Charter states that Solutions and mechanisms created by the = working group will be flexible enough to accommodate different policies = for TN assignment and management, for example those established by = different regulatory agencies. We would like to bring your attention to = the fact that the E.164 international public telecommunication numbering = plan is a politically significant numbering resource with direct = implications on national sovereignty. ITU Plenipotentiary Conference = Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and = sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined in = Recommendation ITU-T E.164", and further instructed the ITU = Secretary-General and the Directors of three Bureaux (Telecommunication = Standardization, Development, and Radiocommunication) to "take any = necessary action to ensure the sovereignty of ITU Member States with = regard to Recommendation ITU-T E.164 numbering plans whatever the = application in which they are used". >=20 > We are aware of Resolution 133 and will certainly respect it. I would = propose adding the following text after the first sentence in the last = full paragraph =96 "The group acknowledges ITU Plenipotentiary = Conference Resolution 133 which recognizes the existing role and = sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined in = Recommendation ITU-T E.164." =20 > =20 > >RH: That certainly would be a helpful addition. In addition to the = above, I would suggest adding =93The group=92s outputs would be = consistent with the provisions of relevant ITU-T Recommendations, in = particular E.164, E.164.1, E.190 and the Recommendations referenced = therein.=94=20 > =20 > >RH: For the sake of clarity I reiterate that I oppose the creation of = this group even if the Charter is modified to include the text above. > =20 >>=20 >> 5. Relationship with .Tel >> DNS-based use of international numbering resources has been discussed = in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. = TSB Director has also exchanged letters with ICANN on issues related to = registering digit strings in the .TEL domain. A representative from = ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and = provided some background on the TELNIC application. A correspondence = group under ITU-T SG2 was also set up in this regard. We would like to = know how the work of this new WG would relate to issues related to = registering digit strings in the .TEL domain and other DNS-based use of = telephone numbers. >=20 > The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG = leveraging existing namespaces as part of proposed solutions. But it's = too early to say anything specific about that. There is nothing in the = charter that references .tel. =20 >>=20 >> 6. Relationship with related existing or concluded WGs >> It is stated in the Charter that the working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. Detailed description of the relationship between this new WG = and the above mentioned other existing or concluded WGs would be = appreciated. >=20 > I agree. I would modify that sentence to add the following at the end = - "as well as other relevant industry and standards organizations." >>=20 >> 7. The name of this new WG >> The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the Charter, = ordering, exposing and registering TNs are not mentioned, which seems to = be a little bit inconsistent. >=20 > The IETF often has fun with creating WG names. : ) But the charter = is where to look for the scope of work. The charter uses the following = phrases "distribution, acquisition and management of TNs", "functions = involved in associating information =85 with TNs", "associating, = acquiring and resolving TNs", "access data related to TNs", and = "mechanisms for resolving information related to TNs". The functions = you believe were left out of the charter will be part of one or more of = these processes. =20 >>=20 >>=20 >> Best regards, >>=20 >> Jie Zhang >> Advisor, ITU-T SG2 >> International Telecommunication Union >> Place des Nations >> CH-1211 Geneva , Switzerland=20 >> Tel :+41 22 730 5855 >> jie.zhang@itu.int >> www.itu.int >> www.itu150.org >>=20 >>=20 >> -----Original Message----- >> From: new-work [mailto:new-work-bounces@ietf.org = ] On Behalf Of The IESG >> Sent: Friday, June 12, 2015 8:47 PM >> To: new-work@ietf.org >> Subject: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern) >>=20 >> A new IETF working group has been proposed in the Applications and = Real-Time Area. The IESG has not made any determination yet. The = following draft charter was submitted, and is provided for informational = purposes only. Please send your comments to the IESG mailing list (iesg = at ietf.org) by 2015-06-22. >>=20 >> Managing, Ordering, Distributing, Exposing, & Registering telephone = Numbers (modern) >> ------------------------------------------------ >> Current Status: Proposed WG >>=20 >> Chairs: >> Tom McGarry > >> Steve Donovan > >>=20 >> Assigned Area Director: >> Alissa Cooper > >>=20 >> Mailing list >> Address: modern@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/modern = >> Archive: http://www.ietf.org/mail-archive/web/modern/ = >>=20 >> Charter: >>=20 >> 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. Devices, applications, and network tools = increasingly need to manage TNs, including requesting and acquiring TN = delegations from authorities. The output of the working group should = make distribution, acquisition, and management of TNs simpler for all = entities involved. >>=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 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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs.=20 >>=20 >> 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, and = security and privacy for both the data and the protocol interactions are = primary considerations. The working group will take into consideration = existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. >>=20 >> 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. 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 for TN assignment and management, for = example those established by different regulatory agencies. >>=20 >> The working group will deliver the following: >>=20 >> - An architecture overview, including high level requirements and = security/privacy considerations >>=20 >> - A description of the enrollment processes for existing and new TNs = including any modifications to metadata related to those TNs >>=20 >> - A description of protocol mechanisms for accessing contact = information associated with enrollments >>=20 >> - A description of mechanisms for resolving information related to = TNs >>=20 >> Milestones: >>=20 >> TBD >>=20 >> _______________________________________________ >> new-work mailing list >> new-work@ietf.org >> https://www.ietf.org/mailman/listinfo/new-work = >> =20 >=20 > =20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_5D77EF10-7C7C-4AF1-BFF4-CE728CF45180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jon,

I=92= m trying to figure out the logic in the DNS analogy.

=93Acquiring=94 a = telephone number and =93Acquiring=94 an IP address are both processes = that involve little protocol work and lots of governance to avoid = wild-west attitude toward allocation of each currently as i = understand.

The = only analogy I can think about here is DNS manages FQDNs and records = associated with IP addresses and maybe calling-name or STIR certificates = would be a potential similar association to a telephone number? =  

Point = is, I think the analogy is at the wrong level of process in the = lifecycle of IP addresses and where DNS protocols are = involved.

Maybe = I=92m taking the importance of the analogy to far, but i think there was = a lot of emphasis on this analogy in the presentations.  I also do = think they can be very helpful and/or hurtful if portrayed the right = way.  In either case, it does seem an important and interesting = distinction to understand, because unless i=92m misinterpreting the = point of your analogy, is that IETF gets involved in DNS management = protocols so therefore it makes sense for IETF to develop protocols = associated with number management?  To me, i would say that is = incorrect association and actually hurts your argument.

-Chris



On Jun 26, 2015, at 12:34 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:


Your arguments here could equally well be applied to any = important resource on which the IETF does protocol work - like, say, the = DNS. The IETF manages the DNS protocol and publishes RFCs about it. But = since national authorities are responsible for ccTLDs, surely the IETF is not a suitable body for managing the DNS! And it = isn't. But it is a suitable body for managing the protocol work on the = DNS. Other, effectively unrelated entities handle the administrative = dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the = sorts of things you are worrying about here. The IETF just produces = tools, and that is all MODERN proposes to do. Trying to characterize = this effort otherwise is simply an error.

All work at the IETF is done by a coalition of the = willing. If it turns out that the coalition is not representative of the = needs of the community, then what happens? Well, the work built here = doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly = be harmed by that, even if the failed work involved ways of talking = about telephone numbers. This makes the IETF really different from = places like the ITU, where the products of work have some binding effect on the world.

Virtually all proposed work at the IETF also faces a = coalition of the unwilling. People who aren't interested, or who think = the work should be done elsewhere, or that the work simply shouldn't be = done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd = agree that if this proposed work required regulatory oversight, that the = IETF shouldn't do it. But we're just building some protocol tools. There = is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol = tools developed in the IETF and conduct an experiment with various = carriers to see if it works for that interest group or not, and that = would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part.

Finally, I'm not really sure how much I would expect = "national regulators" to literally use the tools proposed in this work. = They are tools for the use of a diverse industry of enterprises, = carriers, end users, and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part = instigated by an FCC workshop, yes, and someone associated with the FCC = spoke at the MODERN BoF. But I don't anticipate that the FCC would be = propping up servers to deploy this work - surely they would leave that to industry. 

Jon Peterson
Neustar, Inc.

From: Richard Hill = <rhill@hill-a.ch>
Date: Friday, June = 26, 2015 at 8:09 AM
To: "McGarry, Tom" = <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] = Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

Thank you for this clarification.
 
Since the intent is to create tools and = solutions that would be used by national regulators, presumably they = should be involved in the development of the tools. 

As far as I know, national regulators from most countries don=92t = normally participate in the IETF, for a number of reasons, including the = IETF=92s decision-making process and the fact that the IETF works in = English. National regulators do participate in ITU-T, for a number of reasons, including the ITU=92s decision-making process = and the fact that documents are translated into the six UN languages = before they are formally approved (and some discussions takes place with = interpretation in six languages).
 
If the intent is to develop tools that = would be used only in the USA at first, then I would suggest that it = would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the = purpose. If the US experience proved successful, then the tools could be = proposed for adoption elsewhere, for example through ITU-T.
 
If the intent is to develop tools for use = in many countries right at the start, then I would suggest that the = appropriate forum would be ITU-T, not IETF, for the reasons outlined above.
 
Thus, I formally object to the creation of = this new working group, and this even if the Charter is modified as = suggested below.
 
Please see additional comments inline.
 
Thanks and best,
Richard
 
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: = Managing, Ordering, Distributing, Exposing, & Registering telephone = Numbers (modern)
 
 
This effort is = intended to create tools and solutions to enable flexibility in the = process of managing numbers among national administrators, service and = application providers, and consumers.  Entities can choose to use these tools = or not.  These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T.  But of = course we want your input and feedback, so thanks for sending this along.  More comments in line below.  
 
 
From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, = Ordering, Distributing, Exposing, & Registering telephone Numbers = (modern)
 
Would appreciate = people=92s thoughts on whether any charter edits may be warranted in = response to these comments, and/or whether a separate response may be = useful for addressing some of the questions below.
 
Alissa
 
Begin forwarded = message:


From: "Zhang, Jie" <jie.zhang@itu.int>
Subject: RE: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)
Date: June 23, 2015 at 1:56:42 PM GMT-3
To: "iesg@ietf.org" <iesg@ietf.org>
Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>
Dear Sir/Madam,

Below please find comments from the ITU Telecommunication = Standardization Bureau on the proposed IETF working group MODERN.

1. Potential impacts on = Recommendation ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And = it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism = being referred to here only deals with Tel URI? Would there be any = impact on Recommendation ITU-E E.164 and E.164.1 which are core = recommendations on Telephone Numbers?
There = will be no impacts on E.164 and E.164.1.
 
>RH: Given the scope of the work, I = think that it is too early to say whether there would be an impact. = Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging = changes, with the recognition of course that the changes would have to = be proposed to ITI-T Study Group 2 and agreed by that group.

2. Entities participating in the = defined mechanisms
The Charter states that the protocol mechanism for resolving TNs will = allow entities such as service providers, devices, and applications to = access data related to TNs. But it is not clear what kind of entities = can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have = been assigned a TN or a block of TNS?
Who = participates in numbering processes within countries is subject to = regulation.  The WG cannot make any decisions with regard to this. =  I expect the WG to define "roles" within the number management processes; e.g., = administrator, telecom carrier, application provider, = consumer, etc.; and how those roles could interact with each other. =  This will be a baseline for what tools and solutions = would be useful to facilitate those interactions.  
 
>RH: Even that might be subject to, or = affect, national regulations.  That is, the definition of a =93role=94= may well depend on national regulations.

3. Status of Telephone numbers in = the defined mechanisms
Several operations related to TNs are mentioned in the Charter, = including requesting, acquiring, resolving and associating. It is also = stated that the protocol mechanism for acquiring TNs will provide an = enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as = assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working group?
I would expect proposed solutions to be able to = address the status of a telephone number.
 
>RH: Since the terms =93assigned=94, = =93spare=94 and =93reclaimed=94 are defined in ITU-T Recommendations = (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.

4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact that the E.164 international public = telecommunication numbering plan is a politically significant numbering = resource with direct implications on national sovereignty. ITU = Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with = respect to allocation and management of their country code numbering = resources as enshrined in Recommendation ITU-T E.164", and further = instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and = Radiocommunication) to "take any necessary action to ensure the = sovereignty of ITU Member States with regard to Recommendation ITU-T = E.164 numbering plans whatever the application in which they are used".
We are aware of Resolution = 133 and will certainly respect it.  I would propose adding the = following text after the first sentence in the last full = paragraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing = role and sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined = in Recommendation ITU-T E.164."  
 
>RH: That certainly would be a helpful = addition. In addition to the above, I would suggest adding =93The = group=92s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, = E.164.1, E.190 and the Recommendations referenced therein.=94 
 
>RH: For the sake of clarity I = reiterate that I oppose the creation of this group even if the Charter = is modified to include the text above.
 

5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in = ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB = Director has also exchanged letters with ICANN on issues related to = registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 = May - June 2014) and provided some background on the TELNIC application. = A correspondence group under ITU-T SG2 was also set up in this regard. = We would like to know how the work of this new WG would relate to issues related to registering digit strings in = the .TEL domain and other DNS-based use of telephone numbers.
The = WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule = out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to = say anything specific about that.  There is nothing in the charter = that references .tel.  

6. Relationship with related = existing or concluded WGs
It is stated in the Charter that the working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. Detailed description of the relationship between this new WG = and the above mentioned other existing or concluded WGs would be appreciated.
I agree.  I would modify that sentence to add = the following at the end - "as well as other relevant industry = and standards organizations."

7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)". But in the Charter, = ordering, exposing and registering TNs are not mentioned, which seems to = be a little bit inconsistent.
The = IETF often has fun with creating WG names.  : )  But the = charter is where to look for the scope of work.  The charter uses = the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information =85 with TNs", "associating, acquiring = and resolving TNs", "access data related to TNs", and = "mechanisms for resolving information related to TNs".  The = functions you believe were left out of the charter will be part of one or more of these = processes.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The = IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and = Real-Time Area. The IESG has not made any determination yet. The = following draft charter was submitted, and is provided for informational = purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone = Numbers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz>
 Steve Donovan <srdonovan@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailing list
 Address: modern@ietf.org
 To Subscribe: https://www.ietf.org/mailman/listinfo/modern
=  Archive: http://www.ietf.org/mail-archive/web/modern/
=
Charter:

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. Devices, applications, and network tools increasingly = need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working = group should make distribution, acquisition, and management of TNs = simpler for all entities involved.

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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for = acquiring TNs will provide an enrollment process for the entities that = use and manage TNs. 

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, and = security and privacy for both the data and the protocol interactions are primary considerations. The working group will take = into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by = different regulatory agencies.

The working 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

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

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

= --Apple-Mail=_5D77EF10-7C7C-4AF1-BFF4-CE728CF45180-- From nobody Sat Jun 27 11:32: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 A4CE91A8710 for ; Sat, 27 Jun 2015 11:32:47 -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 MSPhmb3gAQPe for ; Sat, 27 Jun 2015 11:32:46 -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 374EF1A86FE for ; Sat, 27 Jun 2015 11:32:45 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Chris Wendt Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNyiK2B6nfQIcUOqixn+BS2y9p3Aq57E Date: Sat, 27 Jun 2015 18:32:44 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , <76DDFC7A-41DE-46C1-9EEF-A9EFD6DA9BFF@chriswendt.net> In-Reply-To: <76DDFC7A-41DE-46C1-9EEF-A9EFD6DA9BFF@chriswendt.net> 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: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 18:32:47 -0000 Can't speak for Jon or what he has in mind, but the closest DNS analogy I c= an think of is the set of registrar-registry protocols (EPP), RFC 5730 et a= l, as well as the recent output of the WEIRDS working group (RDAP, RFC 7480= ). I believe both are mentioned in the draft charter. With the usual danger= of analogies, both illustrate the basic concept of separating policy (who = can get what names, e.g., trademark and name character set issues) and the = nuts-and-bolts "request domain name" protocol operation. For RDAP, the prot= ocol does not specify what information needs to be provided, how it is veri= fied or who gets to access it, just the basic retrieval of JSON objects. Whether you want to use the analogy of DHCP, i.e., short term assignment of= domain names and IP addresses to authorized hosts, is a more tricky issue,= but I don't think anybody has proposed using DHCP for assigning phone numb= ers to SIP UAs, except indirectly (through the SIP configuration protocol m= echanisms). ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt [chris-ietf= @chriswendt.net] Sent: Saturday, June 27, 2015 9:24 AM To: Peterson, Jon Cc: Richard Hill; modern@ietf.org; McGarry, Tom Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Hi Jon, I=92m trying to figure out the logic in the DNS analogy. =93Acquiring=94 a telephone number and =93Acquiring=94 an IP address are bo= th processes that involve little protocol work and lots of governance to av= oid wild-west attitude toward allocation of each currently as i understand. The only analogy I can think about here is DNS manages FQDNs and records as= sociated with IP addresses and maybe calling-name or STIR certificates woul= d be a potential similar association to a telephone number? Point is, I think the analogy is at the wrong level of process in the lifec= ycle of IP addresses and where DNS protocols are involved. Maybe I=92m taking the importance of the analogy to far, but i think there = was a lot of emphasis on this analogy in the presentations. I also do thin= k they can be very helpful and/or hurtful if portrayed the right way. In e= ither case, it does seem an important and interesting distinction to unders= tand, because unless i=92m misinterpreting the point of your analogy, is th= at IETF gets involved in DNS management protocols so therefore it makes sen= se for IETF to develop protocols associated with number management? To me,= i would say that is incorrect association and actually hurts your argument= . -Chris From nobody Sat Jun 27 11:45: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 CB36A1A878A for ; Sat, 27 Jun 2015 11:45:00 -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 hGmt8jmo08OG for ; Sat, 27 Jun 2015 11:44:59 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id C14EC1A3B9B for ; Sat, 27 Jun 2015 11:44:58 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DOLLY, MARTIN C" , Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3AlcAAgAAZE3g= Date: Sat, 27 Jun 2015 18:43:53 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 18:45:01 -0000 Martin, this was discussed at some length during the BoF. The idea is that, as toda= y, a carrier or other authorized entity assigns a block of numbers to a lar= ge enterprise. For example, Columbia University has the 212 854 xxxx block = (among others). Within the enterprise, these are then delegated, automatica= lly, to various sub-units. This does not change the responsibility of the c= arrier, just automates a manual process. Indeed, a number of traditional ce= rtificated carriers apparently have been delegating numbers to their VoIP p= artners, whether those are consumer companies like Vonage or Skype or web A= PI providers, like Twilio. You may also find https://www.fcc.gov/document/fcc-releases-voip-direct-access-numbering-repo= rt-and-order of interest. It doesn't involve hot dog vendors, or Cisco (unless they turn= their WebEx business into iVoIP). Henning ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135= @att.com] Sent: Saturday, June 27, 2015 9:07 AM To: Eric Burger; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Numbers are a valuable resource. Traditionally, the FCC assigns the numbers to service providers, to which t= he FCC regulates and can punish with fines, etc=85. I do not believe the FC= C will assign numbers to anyone that they cannot PUNISH if abuse occurs. Yes there have been experiments assigning to non-traditional SPs, but these= came with =93conditions=94 WRT assigning numbers to Enterprises, where is the line drawn between assig= ning to Cisco versus Hot Dog vendor??? From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger Sent: Friday, June 26, 2015 7:54 PM To: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) On the one hand, neither MGCP nor SIP do number assignments for phones. It = is irrelevant for MGCP, because the soft switch handles the numbers. On the= SIP side, phone provisioning is the purview of the SIPForum device configu= ration specification. On the other hand, Cullen=92s use case of a large enterprise doing its own = allocations of numbers across multiple campuses, and as such down to the ph= one, was compelling to me. I do not think it has regulatory issues, and it = is a real problem that his customers would like to see solved. Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of other= vendors and large enterprises would be interested. Any comments from those= folks? On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] > wrote: =93One would be an enterprise IP phone that has just been deployed and want= s to acquire a new number from an IP PBX.=94 There are two existing protoc= ols which spring to mind which solve this problem; MGCP and SIP. I=92m sure= others can point to other similar protocols as well (e.g., NCS). And I w= ould argue the enterprise IP phone doesn=92t get a new number, the IP PBX d= oes. The phone merely gets associated with the number provisioned in the I= P PBX in order to originate or terminate calls through the IP PBX. I wasn=92t able to attend the MODERN BoF so I=92m not familiar with the man= y use cases. In your example of the VoIP service provider I have questions= . Has it been determined that there are no suitable existing number provis= ioning or number management protocols? ESPP and TERQ spring to mind as exa= mples of protocols which have been previously developed by the IETF for suc= h purposes and I=92m sure there are other examples as well. And is a special protocol required for this example? Numerous peering rela= tionships are managed using spreadsheets in e-mail. It may be manual, inel= egant and prone to error, but it certainly is cheap and is often used. Hav= e there been VoIP providers that have claimed they are disadvantaged becaus= e they don=92t have a special protocol for provisioning subtended number bl= ocks with their carrier? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [snip] From nobody Sat Jun 27 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 F12A11A87C3 for ; Sat, 27 Jun 2015 11:56:34 -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 OcupQGG8nqj8 for ; Sat, 27 Jun 2015 11:56:32 -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 C5C1C1A87B9 for ; Sat, 27 Jun 2015 11:56:31 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill , "modern@ietf.org" Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+iBXoAACgnQgAAMREiAAK4gwIAAttro Date: Sat, 27 Jun 2015 18:56:30 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , , <01db01d0b052$6ffe2d80$4ffa8880$@ch> , <002701d0b0b3$b2b69890$1823c9b0$@ch> In-Reply-To: <002701d0b0b3$b2b69890$1823c9b0$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 18:56:35 -0000 I don't think a discussion on H.323 vs. SIP is productive or relevant here,= nor attempts to raise issues about the US numbering plan.=0A= =0A= You had asked about interactions with the US NRA; NANC is the advisory body= and I have provided a link. I did not claim that they do anything except d= eal with the NANP. I think it would be helpful if you didn't try to extrapo= late beyond what I say.=0A= =0A= You can get the official statements about the LNPA from the FCC web site; f= or example,=0A= =0A= https://apps.fcc.gov/edocs_public/attachmatch/DA-15-554A1.pdf=0A= =0A= As noted earlier and discussed during the BoF, this particular model is one= model of several, but they basically fall into the "one administrator" (wh= ether the NRA directly or a contracted third party seems to matter little f= rom a technical perspective) or "many administrators" (somewhat similar to = the US 800# RespOrg model, albeit one layer down, or the US TV whitespace d= atabase).=0A= =0A= You keep repeating the same assertions, and arguments about separating tech= nology (protocols) from policy do not seem to convince you, so I don't thin= k the discussion is particularly productive at this point. I look forward t= o your constructive contributions to the working group.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Richard Hill [rhill@hill-a.ch]=0A= Sent: Saturday, June 27, 2015 4:31 AM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distri= buting, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Dear Henning,=0A= =0A= Thank you for this and please see embedded comments below.=0A= =0A= Best,=0A= Richard=0A= =0A= =0A= =0A= > but a number were=0A= > present during the IETF Dallas BOF, from what I recall.=0A= >=0A= > The NANC documents can be found at=0A= >=0A= > http://nanc-chair.org/=0A= =0A= That's the North American Numbering Plan, which concerns mostly the US, wit= h=0A= some input from Canada, since the other countries are mostly too small to= =0A= have much of a stake in whatever is decided.=0A= =0A= >=0A= > FTN 7 is probably the most relevant effort. (I haven't actively=0A= > participated in the effort since this is an advisory committee to the=0A= > FCC, but I think we have NANC participants on the mailing list who=0A= > might be willing to provide updates; contact information is provided on= =0A= > the meeting slides.)=0A= =0A= I suppose that you are referring to this:=0A= =0A= http://nanc-chair.org/docs/mtg_docs/Jun15_FoN_Report.pptx=0A= =0A= That presentation says "The Working Group will investigate new telephone=0A= numbering assignment approaches and future telephone number assignment=0A= requirements."=0A= =0A= So it is about changes that may require changes to current regulatory=0A= policies.=0A= =0A= =0A= But maybe you were referring to a different document.=0A= =0A= >=0A= > The protocols being discussed have two "IP" angles: They are based on=0A= > IP itself (rather than, say, TCAP) and they are likely most relevant in= =0A= > all-IP (VoIP) environments where both new entrants and carriers=0A= > transitioning to an all-IP environment are more likely to use new=0A= > number management approaches that are not encumbered by legacy=0A= > constraints.=0A= =0A= Yes, but as I understand the charter, the proposed work is mostly about=0A= figuring out how best to automate certain information flows. In my=0A= experience, that quickly leads to thinking about business process=0A= engineering, as we did for Electronic Data Interchange (EDI). In the USA,= =0A= much of that work was done by ANSI, with the IETF contribution being limite= d=0A= to protocols for transmitting data.=0A= =0A= That is, the IETF did not get into the EDI equivalents of "managing,=0A= distributing, registering", etc.=0A= =0A= >As you well know, many of those VoIP protocols have their=0A= > technical home in the IETF.=0A= =0A= Yes, and as you also know well, some of the VoIP protocols have their=0A= technical home in the ITU-T. Indeed you wrote an article comparing SIP to= =0A= H.323, at:=0A= =0A= http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.pdf=0A= =0A= There seem to be divergent opinions regarding the relative merits of H.323= =0A= and SIP, and on which has greater market share, but for sure both are widel= y=0A= deployed, see:=0A= =0A= http://www.packetizer.com/ipmc/h323_vs_sip/=0A= =0A= =0A= http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a0= 0=0A= 80092947.shtml=0A= =0A= http://www.dailypayload.com/content/3111=0A= =0A= And some people think that both are obsolete and should/will be replaced by= =0A= something newer, see for example:=0A= =0A= https://bloggeek.me/h323-sip-xmpp-js/=0A= =0A= Be that as it may, the codecs standardized by ITU-T seem still to be widely= =0A= used, so apparently ITU-T is also able to produce ways of packaging bits=0A= that are commercially useful.=0A= =0A= But, as I said above, I doubt that the thrust of the work of the proposed= =0A= Working Group would actually be about how to package bits. It seems to me= =0A= that it will be more related to business processes and business process=0A= engineering, which is not an area in which the IETF has traditionally been= =0A= active.=0A= =0A= >=0A= > I don't think anybody is proposing changing the US numbering plan=0A= > (e.g., the number of digits in a phone number or fixed-vs-variable=0A= > length)=0A= =0A= Pity because, as I said before, I think that that is long overdue. I didn'= t=0A= say it before, but I think that the whole idea of using one E.164 geographi= c=0A= country code for many countries is a deleterious relic of the past, a=0A= "legacy system" in the worst sense of the term. In my view, the US should= =0A= take "1" for itself and the other countries should get new codes (or, if th= e=0A= US were willing to share more equitably, it could move to 11 and free up 9= =0A= codes).=0A= =0A= And the US could take advantage of that change to expand its numbering plan= .=0A= (As you know, most countries have expanded their numbering plans during the= =0A= past 20 years.)=0A= =0A= >and that is well outside the scope of any IETF effort that I=0A= > could imagine.=0A= =0A= True. But it would not necessarily outside the scope of ITU-T Study Group 2= ,=0A= if everybody agreed that the matter should be discussed in ITU-T.=0A= =0A= But maybe that's one of the reasons why some people would prefer not to=0A= bring the matter to the ITU: they wish to ensure that the scope of the=0A= discussions is restricted.=0A= =0A= That's certainly a legitimate desire, but I would submit that it would be= =0A= better fulfilled by creating an ad-hoc group to discuss the matter. As=0A= several people have pointed out, IETF is open, so you never know what will= =0A= be brought into discussions.=0A= =0A= >I'm more concerned with the hodge-podge of numbering-=0A= > related databases that have emerged over the decades and all made sense= =0A= > at some point.=0A= =0A= Indeed. But, again, this is not a matter of figuring out how to package=0A= bits. It is a business process issue. And the IETF has not typically been= =0A= involved in those sorts of issues, at least not for what concerns telephone= =0A= numbers. Whereas ITU-T Study Group 2 has considered such matters.=0A= =0A= =0A= =0A= =0A= =0A= >(This is indeed, as we all seem to agree but=0A= > seem to be repeating again and again, an NRA issue well beyond IETF=0A= > scope.) The LNPA pain that you may not be familiar with is the=0A= > transition, after a competitive bidding process, between the previous=0A= > contracted number management entity and the new one. Having engineering= =0A= > options that bypass or minimize such disputes, should an NRA want to=0A= > avail themselves of those, is one interest of mine.=0A= =0A= I don't follow the US developments closely, but I had heard that Neustar=0A= lost its contract, or might lose its contract, or something to that effect.= =0A= =0A= Perhaps you could provide more detail on what you outline above, so that we= =0A= all have the same level of understanding of what is happening in the US.=0A= =0A= >=0A= > My point about "new entrants" is simply that incumbents are not the=0A= > only audience for this. We may not know exactly who will be playing in=0A= > this sandbox in ten years (and neither the ITU nor the IETF are in the=0A= > sandbox admission policing business),=0A= =0A= Actually the ITU is in the sandbox admission business, for the=0A= non-geographic country codes (881, 882, 883). For many years there were fe= w=0A= requests, about 1-2 per year. But things have picked up now and they are=0A= getting several requests per year.=0A= =0A= And ITU is in the policing business, even if it has no enforcement powers,= =0A= with respect to misuse of E.164 numbers.=0A= =0A= Both issues may be related to some of the work of the proposed Working=0A= Group.=0A= =0A= > but it's pretty clear that there=0A= > will be new kids on the playground.=0A= =0A= =0A= In my view, there would be more new kids if the legacy US numbering plan=0A= were reformed.=0A= =0A= For example, if you had dedicated area codes for mobile, then some mobile= =0A= operators could envisage offering "caller pays" pricing plans. I know that= =0A= some people think that "receiver pays" is the only model that makes sense,= =0A= but in fact most of the world uses "caller pays".=0A= =0A= And the proportion of people who move to relatively expensive flat rate=0A= plans might be different if they could choose between caller pays and=0A= receiver pays.=0A= =0A= =0A= =0A= >=0A= > Henning=0A= >=0A= > ________________________________________=0A= > From: Richard Hill [rhill@hill-a.ch]=0A= > Sent: Friday, June 26, 2015 4:55 PM=0A= > To: Henning Schulzrinne; modern@ietf.org=0A= > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,=0A= > Distributing, Exposing, & Registering telephone Numbers (modern)=0A= >=0A= > Please see inline.=0A= >=0A= > > -----Original Message-----=0A= > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning=0A= > > Schulzrinne=0A= > > Sent: Friday, June 26, 2015 22:30=0A= > > To: modern@ietf.org=0A= > > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,=0A= > > Distributing, Exposing, & Registering telephone Numbers (modern)=0A= > >=0A= > > Since the nesting is getting confusing, let me add a few general=0A= > > points that refer to a number of different discussion items:=0A= > >=0A= > > * My sense is that a number of national regulators=0A= >=0A= > Can you specify which national regulators are aware of the creation of=0A= > the proposed working group, other than the FCC, which I presume you are= =0A= > representing in this discussion?=0A= >=0A= > > are well aware of=0A= > > the MODERN work. NANC has been kept in the loop, and their input on=0A= > > requirements (e.g., through their Future of Numbering (FON) effort)=0A= >=0A= > Can you please give the URL for the cited documents?=0A= >=0A= >=0A= > >=0A= > > * I'm not sure other standards bodies have demonstrated equivalent=0A= > IP-=0A= > > based design experience, but (as noted) I suspect everybody welcomes=0A= > > inputs from as many interested parties as possible.=0A= >=0A= > I'm not sure that I understand what the IP-based specifics are of the=0A= > project. As I understand it, the idea is to develop protocols for=0A= > specifying requests to get numbers, etc. How is that specifically tied=0A= > to TCP/IP?=0A= >=0A= >=0A= > >=0A= > > * The current number porting model (in the US) predates the Internet=0A= > > and leaves room for improvement from a consumer and carrier=0A= > > perspective.=0A= >=0A= > No kidding. The US numbering plan is, in my view, obsolete and badly in= =0A= > need of reform. But US industry and US authorities don't seem to agree=0A= > (or at least they didn't last time I checked a couple of years ago).=0A= >=0A= >=0A= > >=0A= > > * The current assignment model (at least in the US) is not a model of= =0A= > > efficiency and flexibility. There are numerous examples, but the most= =0A= > > recent difficult transition process of the LNPA is a high-profile=0A= > one.=0A= >=0A= > This is no doubt correct, but, again, changes in the assignment model=0A= > are in the remit of the FCC, not the IETF (again, correct me if I'm=0A= > wrong about that).=0A= >=0A= > >=0A= > > * Traditional carriers may not be the only "customers". In IETF work,= =0A= > > there's sometimes the danger of equating the installed base with the=0A= > > total market.=0A= >=0A= > Indeed, I think that carriers should not be the only recipients of=0A= > telephone numbers. But, again, that is a policy question that is not in= =0A= > the remit of the IETF (but correct me if I'm wrong about that).=0A= =0A= From nobody Sat Jun 27 16:17: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 EF6121AC43C for ; Sat, 27 Jun 2015 16:17:22 -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 F5vbhA_LokD1 for ; Sat, 27 Jun 2015 16:17:18 -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 208821AC438 for ; Sat, 27 Jun 2015 16:17:18 -0700 (PDT) Received: (qmail 502 invoked by uid 0); 27 Jun 2015 23:17:10 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy1.mail.unifiedlayer.com with SMTP; 27 Jun 2015 23:17:10 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id lgpv1q00V1MNPNq01gpyal; Sat, 27 Jun 2015 22:49:59 -0600 X-Authority-Analysis: v=2.1 cv=HpvlRSjS c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=sNEldo0-0YMA:10 a=IYETQKA4aJkA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=ll-iCDY8AAAA:8 a=doUQZJtgAAAA:8 a=ASjRbOs7AAAA:8 a=izV7ms69AAAA:8 a=1NEBYDS9io48riN6EEkA:9 a=otPPkxDMHQ9m9rQv:21 a=rp4JkIekuDlKQJRH:21 a=wPNLvfGTeEIA:10 a=DzjOOp_o1eYA:10 a=OT2nvUJKb2MA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=1639yHptV7giy4ZLUBAA:9 a=FG-wSIduoS0Eo1-n:21 a=LDtiQuUeO4x0RwKi:21 a=b26_HQuK6rnUg16M:21 a=_W_S_7VecoQA:10 a=HGYpPW1hh3wA: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=gnOs/mHWZvLXO+/0sJCXtABHUvaGx/7b7ypAEJsa5sM=; b=Pm1/EgPSyZ83zGrFZp2EC55Mh+ZXc9OAGTB4HQK7VL2sTHUCc+9Xr9ZW8ZGHoDsQqCTPcSrJUoj587IXpfW7lVTqzk64idWJpqCnPekQsdIKnV2m/m4Axm/bHy9LOcMQ; Received: from [100.36.26.202] (port=62418 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z8z22-0001Oe-Di; Sat, 27 Jun 2015 16:57:07 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Sat, 27 Jun 2015 18:57:00 -0400 From: Richard Shockey To: Eric Burger , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> In-Reply-To: <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518276226_1104616" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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: Sat, 27 Jun 2015 23:17:23 -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_3518276226_1104616 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable From: Modern on behalf of Eric Burger Date: Friday, June 26, 2015 at 7:54 PM To: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) On the one hand, neither MGCP nor SIP do number assignments for phones. It is irrelevant for MGCP, because the soft switch handles the numbers. On the SIP side, phone provisioning is the purview of the SIPForum device configuration specification. RS> Which I can testify has not gone very far for a variety of reasons. *** On the other hand, Cullen=B9s use case of a large enterprise doing its own allocations of numbers across multiple campuses, and as such down to the phone, was compelling to me. I do not think it has regulatory issues, and i= t is a real problem that his customers would like to see solved. RS> You are correct. It is actually a sensible use case there but complicated by the problem that large enterprises still cross multiple LATA boundaries in the US and managing blocks from multiple states is a royal . That is still a problem with US National Numbering policy that has yet to be resolved in the context of the PSTN Transition. US Numbering is WAY WAY far advanced even though the NANC is . LATA=B9s will go away but we are not there yet and the FCC still is avoiding the underlying regulatory vision to the public necessary to make actual progress.=20 If you eliminate the geographic or access means of numbering things get simpler. Yes as Brother Henning points out a TN is really a domain name an= d that is why this discussion actually is important and makes sense. IBM or Ford or Cisco could assign one single NPA to all of its employees for its business communications but you go tell citizens in Vermont Alaska or Maine PEI Yukon etc they have to dial 10 digits for all calls. http://www.shockey.us/index.php/download_file/view/13/142/ The unspoken issue here is where does the initial work get done and I=B9m not currently convinced the IETF is the right place to do it. OK I=B9ll finally say it. The IETF has not traditionally been hospitable to the concerns of service providers. There is a reason 3GPP ETSI ATIS exist. Collectively we understand that there is a problem in the US with numbering/routing databases and that the problem is manifesting itself first in the North American market since the level of SIP/IMS deployments now far exceed anything in Europe or AsiaPac. The PSTN Transition is no longer a idea its an inevitability. And yes.. Contrary to everything Henry Sinnreich and other used to preach ..TN are still here and I still don=B9t se= e SIP URI=B9s on the side of pizza delivery cars. Even within the FCC and the Commissioners there is some divergent views on what is actually at stake here. https://www.fcc.gov/article/fcc-15-70a6 The debate in the UK w/ BT is just starting. http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/= t elecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-to-help-it-= b attle-US-tech-giants.html *** Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of other vendors and large enterprises would be interested. Any comments from those folks? RS> Besides Cisco everyone seems to like their vendor specific presumed customer lock in solutions and even those are being disrupted by BYOD solutions. That will of course change over time when we do point to point video calling using E.164. > On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] > wrote: >=20 > =B3One would be an enterprise IP phone that has just been deployed and want= s to > acquire a new number from an IP PBX.=B2 There are two existing protocols w= hich > spring to mind which solve this problem; MGCP and SIP. I=B9m sure others ca= n > point to other similar protocols as well (e.g., NCS). And I would argue= the > enterprise IP phone doesn=B9t get a new number, the IP PBX does. The phone > merely gets associated with the number provisioned in the IP PBX in order= to > originate or terminate calls through the IP PBX. > =20 > I wasn=B9t able to attend the MODERN BoF so I=B9m not familiar with the many = use > cases. In your example of the VoIP service provider I have questions. H= as it > been determined that there are no suitable existing number provisioning o= r > number management protocols? ESPP and TERQ spring to mind as examples of > protocols which have been previously developed by the IETF for such purpo= ses > and I=B9m sure there are other examples as well. > =20 > And is a special protocol required for this example? Numerous peering > relationships are managed using spreadsheets in e-mail. It may be manual= , > inelegant and prone to error, but it certainly is cheap and is often used= . > Have there been VoIP providers that have claimed they are disadvantaged > because they don=B9t have a special protocol for provisioning subtended num= ber > blocks with their carrier? > =20 > Best regards, > =20 > =20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > [snip] _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3518276226_1104616 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable


From: Modern <modern-bounces@ietf.org> on behal= f of Eric Burger <eburger@sta= ndardstrack.com>
Date: Frid= ay, June 26, 2015 at 7:54 PM
To: "= modern@ietf.org" <modern@ietf.org>
Sub= ject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distrib= uting, Exposing, & Registering telephone Numbers (modern)
=
On the one hand, neither MGCP nor SIP= do number assignments for phones. It is irrelevant for MGCP, because the so= ft switch handles the numbers. On the SIP side, phone provisioning is the pu= rview of the SIPForum device configuration specification.
=


RS> Which I can testify has not gone v= ery far for a variety of reasons. 

***

On the other hand, Cullen’= ;s use case of a large enterprise doing its own allocations of numbers acros= s multiple campuses, and as such down to the phone, was compelling to me. I = do not think it has regulatory issues, and it is a real problem that his cus= tomers would like to see solved.

RS> You are correct. It is actually a sensible use case there but compli= cated by the problem that large enterprises still cross multiple LATA bounda= ries in the US and managing blocks from multiple states is a royal <fill = in the blank>.  That is still a problem with US National Numbering p= olicy that has yet to be resolved in the context of the PSTN Transition.&nbs= p;

US Numbering is WAY WAY far advanced even though= the NANC is <fill in the blank>.  LATA’s will go away but = we are not there yet and the FCC still is avoiding the underlying regulatory= vision to the public necessary to make actual progress. 
If you eliminate the geographic or access means of numbering thi= ngs get simpler.  Yes as Brother Henning points out a TN is really a do= main name and that is why this discussion actually is important and makes se= nse. IBM or Ford or Cisco could assign one single NPA to all of its employee= s for its business communications but you go tell citizens in Vermont Alaska= or Maine PEI Yukon etc they have to dial 10 digits for all calls.  


The unspoken issue here is where does the initial= work get done and I’m not currently convinced the IETF is the right p= lace to do it. 

OK I’ll finally say it.<= /div>

The IETF has not traditionally been hospitable to t= he concerns of service providers. There is a reason 3GPP ETSI ATIS exist. &n= bsp;

Collectively we understand that there is a pro= blem in the US with numbering/routing  databases and that the problem i= s manifesting itself first in the North American market since the level of S= IP/IMS deployments now far exceed anything in Europe or AsiaPac.  The P= STN Transition is no longer a idea its an inevitability.  And yes.. Con= trary to everything Henry Sinnreich and other used to preach ..TN are still = here and I still don’t see SIP URI’s on the side of pizza delive= ry cars.

Even within the FCC and the Commissioners = there is some divergent views on what is actually at stake here.
<= br>
https://www.fcc.gov/article/fcc-15-70a6

The debate in the UK w/ BT is just starting. 

http://www.telegraph.co.uk/finance/ne= wsbysector/mediatechnologyandtelecoms/telecoms/11696314/BT-aims-to-shut-down= -traditional-phone-network-to-help-it-battle-US-tech-giants.html





***

Besides Cisco, I would presume Avaya, Uni= fy, Oracle, and a handful of other vendors and large enterprises would be in= terested. Any comments from those folks?

RS> Besides Cisco everyone seems to like their vendor specific p= resumed customer lock in solutions and even those are being disrupted by BYO= D solutions. That will of course change over time when we do point to point = video calling using E.164.


On Jun 26, 2015, at= 1:17 PM, Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com> wrote:

“One would be an enterprise IP phone that= has just been deployed and wants to acquire a new number from an IP PBX.”  There are two existing protocols which = spring to mind which solve this problem; MGCP and SIP. I’m sure others= can point to other similar protocols as well (e.g., NCS).   And I= would argue the enterprise IP phone doesn’t get a new number, the IP = PBX does.  The phone merely gets associated with the number provisioned= in the IP PBX in order to originate or terminate calls through the IP PBX.<= o:p class=3D"">
 
I wasn&= #8217;t able to attend the MODERN BoF so I’m not familiar with the man= y use cases.  In your example of the VoIP service provider I have quest= ions.  Has it been determined that there are no suitable existing numbe= r provisioning or number management protocols?  ESPP and TERQ spring to= mind as examples of protocols which have been previously developed by the I= ETF for such purposes and I’m sure there are other examples as well.
 
And is a= special protocol required for this example?  Numerous peering relation= ships are managed using spreadsheets in e-mail.  It may be manual, inel= egant and prone to error, but it certainly is cheap and is often used. = Have there been VoIP providers that have claimed they are disadvantaged bec= ause they don’t have a special protocol for provisioning subtended num= ber blocks with their carrier?
 
Best regards,
 
<= span style=3D"font-size: 11pt; font-family: Arial, sans-serif; color: rgb(0, 0= , 204);" class=3D""> 
Pierce Gorman
Core Network Planning
O: 913-439-436= 8
<image001.png>
[snip]

_______= ________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3518276226_1104616-- From nobody Sat Jun 27 23:02: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 52F611A92E1 for ; Sat, 27 Jun 2015 23:02:42 -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 mE76TxbfvDuJ for ; Sat, 27 Jun 2015 23:02:35 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 50F7F1A9055 for ; Sat, 27 Jun 2015 23:02:35 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5S62WQp005967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Jun 2015 08:02:32 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5S62VUf025598; Sun, 28 Jun 2015 08:02:31 +0200 From: "Richard Hill" To: "'Richard Shockey'" , "'Eric Burger'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> In-Reply-To: Date: Sun, 28 Jun 2015 08:02:32 +0200 Message-ID: <000601d0b168$06723ed0$1356bc70$@ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01D0B178.C9FB0ED0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCxL28kqXFZvj4TRWuEZAlmIiLZ7AANYjJQ Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 28 Jun 2015 06:02:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01D0B178.C9FB0ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please see embedded comments below. Thanks and best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Sunday, June 28, 2015 00:57 To: Eric Burger; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) From: Modern on behalf of Eric Burger Date: Friday, June 26, 2015 at 7:54 PM To: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) SNIP If you eliminate the geographic or access means of numbering things get simpler. Yes as Brother Henning points out a TN is really a domain name and that is why this discussion actually is important and makes sense. IBM or Ford or Cisco could assign one single NPA to all of its employees for its business communications but you go tell citizens in Vermont Alaska or Maine PEI Yukon etc they have to dial 10 digits for all calls. http://www.shockey.us/index.php/download_file/view/13/142/ >RH: I find that the paper cited above is excellent and I would urge everybody who has a serious interest in these discussions to read it carefully. In Switzerland, we have full geographic portability for fixed numbers (as well as portability for mobile numbers), so users have to dial 10 digits for all calls (including the leading zero, as in 022 840 1021). The same is true in most European countries, but in some cases the number of digits in greater. Given the size of the US population (vs. the 8 million of Switzerland), it seems to me that the US should envisage moving to 12 digits, or at least 11. The unspoken issue here is where does the initial work get done and I'm not currently convinced the IETF is the right place to do it. OK I'll finally say it. The IETF has not traditionally been hospitable to the concerns of service providers. There is a reason 3GPP ETSI ATIS exist. >RH: People who have been around a long time and who are cynical might be tempted to recall the misunderstandings between the bell-heads and the net-heads. But I don't think that that is relevant any more. What is relevant is who tends to participate in which group. As far as I know, the people who understand the concerns of service providers (and carriers) don't typically participate in IETF. So I agree that IETF is not the right place to start this work. But I do agree that the work should be started. Those who wish to drive the work forward should pick an appropriate forum. Collectively we understand that there is a problem in the US with numbering/routing databases and that the problem is manifesting itself first in the North American market since the level of SIP/IMS deployments now far exceed anything in Europe or AsiaPac. The PSTN Transition is no longer a idea its an inevitability. And yes.. Contrary to everything Henry Sinnreich and other used to preach ..TN are still here and I still don't see SIP URI's on the side of pizza delivery cars. Even within the FCC and the Commissioners there is some divergent views on what is actually at stake here. https://www.fcc.gov/article/fcc-15-70a6 The debate in the UK w/ BT is just starting. http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/t elecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-to-help-it-b attle-US-tech-giants.html >RH: Interesting post from at least two points of view. First, while I haven't looked at the Swiss regulations in detail, it seems to me that they already don't require traditional PSTN, because service providers (including the incumbent Swisscom) are offering IP-only packages for data and voice. The only reason I don't have one is that, for now, they only offer up to 3 distinct telephone numbers as part of the offer, whereas I have 10 numbers with ISDN (if you remember ISDN, you are an "old hand"; if you remember rotary dials, analog phones, and Blue Boxes, you are an ). >RH: Second, I've spent most of my career in the highly competitive computer business. Calls for deregulation are in effect calls to create a competitive market. I'm all in favor of competition, so I think that it's great that regulated companies are calling for competition. But I'm obliged to remind them of the old adage "Be careful what you wish for, because your wish may be granted". *** Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of other vendors and large enterprises would be interested. Any comments from those folks? RS> Besides Cisco everyone seems to like their vendor specific presumed customer lock in solutions and even those are being disrupted by BYOD solutions. That will of course change over time when we do point to point video calling using E.164. >RH: As we all know, proprietary solutions are used to reduce competition and create opportunities for higher profits. Good regulations reduce the opportunities to do that and increase competition at all levels. Which is not to say that everything should be regulated. Quite the contrary, regulation should be imposed only when it is clear that a particular market is not competitive. And that should be done sparingly. On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] wrote: "One would be an enterprise IP phone that has just been deployed and wants to acquire a new number from an IP PBX." There are two existing protocols which spring to mind which solve this problem; MGCP and SIP. I'm sure others can point to other similar protocols as well (e.g., NCS). And I would argue the enterprise IP phone doesn't get a new number, the IP PBX does. The phone merely gets associated with the number provisioned in the IP PBX in order to originate or terminate calls through the IP PBX. I wasn't able to attend the MODERN BoF so I'm not familiar with the many use cases. In your example of the VoIP service provider I have questions. Has it been determined that there are no suitable existing number provisioning or number management protocols? ESPP and TERQ spring to mind as examples of protocols which have been previously developed by the IETF for such purposes and I'm sure there are other examples as well. And is a special protocol required for this example? Numerous peering relationships are managed using spreadsheets in e-mail. It may be manual, inelegant and prone to error, but it certainly is cheap and is often used. Have there been VoIP providers that have claimed they are disadvantaged because they don't have a special protocol for provisioning subtended number blocks with their carrier? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [snip] _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ------=_NextPart_000_0007_01D0B178.C9FB0ED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see embedded comments below.

 

Thanks and best,

Richard

 

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard = Shockey
Sent: Sunday, June 28, 2015 00:57
To: Eric = Burger; modern@ietf.org
Subject: Re: [Modern] [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)

 

=  

=  

From: Modern <modern-bounces@ietf.org> = on behalf of Eric Burger <eburger@standardstrack.com= >
Date: Friday, June 26, 2015 at 7:54 PM
To: = "modern@ietf.org" = <modern@ietf.org>
Subject: = Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers = (modern)

=  

 

SNIP

 

= If you eliminate the geographic or access means of numbering things get = simpler.  Yes as Brother Henning points out a TN is really a domain = name and that is why this discussion actually is important and makes = sense. IBM or Ford or Cisco could assign one single NPA to all of its = employees for its business communications but you go tell citizens in = Vermont Alaska or Maine PEI Yukon etc they have to dial 10 digits for = all calls.  

=  

= http:= //www.shockey.us/index.php/download_file/view/13/142/ =

 

>RH: I find that the paper cited above is excellent and I would = urge everybody who has a serious interest in these discussions to read = it carefully.  In Switzerland, we have full geographic portability = for fixed numbers (as well as portability for mobile numbers), so users = have to dial 10 digits for all calls (including the leading zero, as in = 022 840 1021).  The same is true in most European countries, but in = some cases the number of digits in greater. Given the size of the US = population (vs. the 8 million of Switzerland), it seems to me that the = US should envisage moving to 12 digits, or at least = 11.

=  

= The unspoken issue here is where does the initial work get done and = I’m not currently convinced the IETF is the right place to do = it. 

=  

= OK I’ll finally say it.

=  

= The IETF has not traditionally been hospitable to the concerns of = service providers. There is a reason 3GPP ETSI ATIS exist. =  

 

>RH: People who have been around a long time and who are cynical = might be tempted to recall the misunderstandings between the bell-heads = and the net-heads.  But I don’t think that that is relevant = any  more. What is relevant is who tends to participate in which = group.  As far as I know, the people who understand the concerns of = service providers (and carriers) don’t typically participate in = IETF. So I agree that IETF is not the right place to start this = work.  But I do agree that the work should be started.  Those = who wish to drive the work forward should pick an appropriate = forum.

=  

= Collectively we understand that there is a problem in the US with = numbering/routing  databases and that the problem is manifesting = itself first in the North American market since the level of SIP/IMS = deployments now far exceed anything in Europe or AsiaPac.  The PSTN = Transition is no longer a idea its an inevitability.  And yes.. = Contrary to everything Henry Sinnreich and other used to preach ..TN are = still here and I still don’t see SIP URI’s on the side of = pizza delivery cars.

=  

= Even within the FCC and the Commissioners there is some divergent views = on what is actually at stake here.

=  

=  

= The debate in the UK w/ BT is just = starting. 

=  

= http://www.telegraph.co.uk/finan= ce/newsbysector/mediatechnologyandtelecoms/telecoms/11696314/BT-aims-to-s= hut-down-traditional-phone-network-to-help-it-battle-US-tech-giants.html<= /a> =

 

>RH: Interesting post from at least two points of view. First, = while I haven’t looked at the Swiss regulations in detail, it = seems to me that they already don’t require traditional PSTN, = because service providers (including the incumbent Swisscom) are = offering IP-only packages for data and voice. The only reason I = don’t have one is that, for now, they only offer up to 3 distinct = telephone numbers as part of the offer, whereas I have 10 numbers with = ISDN (if you remember ISDN, you are an “old hand”; if you = remember rotary dials, analog phones, and Blue Boxes, you are an = <fill in the blank>).

 

>RH: Second,  I’ve spent most of my career in the = highly competitive computer business. Calls for deregulation are in = effect calls to create a competitive market. I’m all in favor of = competition, so I think that it’s great that regulated companies = are calling for competition. But I’m obliged to remind them of the = old adage “Be careful what you wish for, because your wish may be = granted”.

=  

=  

=  

“One would be an enterprise IP phone that has just been deployed and = wants to acquire a new number from an IP PBX.”  There are two existing protocols which spring to mind = which solve this problem; MGCP and SIP. I’m sure others can point = to other similar protocols as well (e.g., NCS).   And I would = argue the enterprise IP phone doesn’t get a new number, the IP PBX = does.  The phone merely gets associated with the number provisioned = in the IP PBX in order to originate or terminate calls through the IP = PBX.

 

I wasn’t able to attend the MODERN BoF so I’m not familiar = with the many use cases.  In your example of the VoIP service = provider I have questions.  Has it been determined that there are = no suitable existing number provisioning or number management = protocols?  ESPP and TERQ spring to mind as examples of protocols = which have been previously developed by the IETF for such purposes and = I’m sure there are other examples as well.

 

And is a special protocol required for this example?  Numerous = peering relationships are managed using spreadsheets in e-mail.  It = may be manual, inelegant and prone to error, but it certainly is cheap = and is often used.  Have there been VoIP providers that have = claimed they are disadvantaged because they don’t have a special = protocol for provisioning subtended number blocks with their = carrier?

 

Best regards,

 

 

Pierce Gorman

= Core Network Planning

= O: 913-439-4368

<image001.png>

= [snip]=

=  

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

------=_NextPart_000_0007_01D0B178.C9FB0ED0-- From nobody Sat Jun 27 23:52: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 7F6B81A1EF5 for ; Sat, 27 Jun 2015 23:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 acuA4ENx2Iq9 for ; Sat, 27 Jun 2015 23:52:17 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 B4B3C1A1E0E for ; Sat, 27 Jun 2015 23:52:16 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5S6qCK5021717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Jun 2015 08:52:13 +0200 Received: from RHillNew (adsl-178-39-175-231.adslplus.ch [178.39.175.231]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5S6qBSp031272; Sun, 28 Jun 2015 08:52:12 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> , , <01db01d0b052$6ffe2d80$4ffa8880$@ch> , <002701d0b0b3$b2b69890$1823c9b0$@ch> In-Reply-To: Date: Sun, 28 Jun 2015 08:52:13 +0200 Message-ID: <002e01d0b16e$f6fae0e0$e4f0a2a0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQrzxGVmw9PRd0eEaFafFKYdmKTp2+EeCAgAEW4ICAABfLAIAABc6AgAAKUQD//+iBXoAACgnQgAAMREiAAK4gwIAAttrogADFfkA= Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 28 Jun 2015 06:52:20 -0000 Dear Henning, Thank you for this and please see embedded comments below. Best, Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Saturday, June 27, 2015 20:57 > To: Richard Hill; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > I don't think a discussion on H.323 vs. SIP is productive or relevant > here, I was under the impression that you were referring to SIP as evidence that the IETF has expertise regarding VoIP, so I thought that it was appropriate to point out that the ITU-T also has expertise regarding VoIP. I apologize if I misunderstood your intent. > nor attempts to raise issues about the US numbering plan. I'm not so sure about that. The US numbering plan is very different from most other numbering plans, so solutions that cater to the US situation might not be appropriate elsewhere. In other words, it might be appropriate to understand the ways in which the situation in the US is different from the situation elsewhere. > > You had asked about interactions with the US NRA; NANC is the advisory > body and I have provided a link. I did not claim that they do anything > except deal with the NANP. I think it would be helpful if you didn't > try to extrapolate beyond what I say. I didn't think that I was extrapolating, but I apologize if I did. > > You can get the official statements about the LNPA from the FCC web > site; for example, > > https://apps.fcc.gov/edocs_public/attachmatch/DA-15-554A1.pdf Thank you. So, if I understand correctly, the Local Number Portability Administrator contract might be moved from Neustar to Telcordia (iconectiv). > > As noted earlier and discussed during the BoF, this particular model is > one model of several, but they basically fall into the "one > administrator" (whether the NRA directly or a contracted third party > seems to matter little from a technical perspective) or "many > administrators" (somewhat similar to the US 800# RespOrg model, albeit > one layer down, or the US TV whitespace database). Yes, and the business processes might be different, even within each of those two models. > > You keep repeating the same assertions, and arguments about separating > technology (protocols) from policy do not seem to convince you, so I > don't think the discussion is particularly productive at this point. I have indeed repeatedly raised the same points, but I haven't see any replies that I would consider satisfactory. The points that I have raised are: 1. If the intent is to develop solutions that would apply to many countries, then the discussions should take place in a forum were national regulators participate. The obvious forum is ITU-T Study Group 2. 2. If the intent is to, at least for now, develop solutions that would apply in the US, then the discussions should take place in a US forum, such as ATIS. 3. In any case, there are surely underlying business process, economic, and regulatory issues, so the matter is not purely technical and participation of people with the requisite knowledge and background should be encouraged. I doubt that this is purely about packaging bits, and I doubt that the IETF will attract all the people who should be involved. 4. In any case, the ITU-T should be involved or at least informed, for example through liaisons. >I look forward to your constructive contributions to the working group. I still think that this group should not be created within the IETF, so I hope that I won't have to contribute to it. And I trust that you appreciate and support my constructive contributions to date, in particular my suggestions regarding the text of the proposed Charter and liaising with ITU-T. > > Henning > > ________________________________________ > From: Richard Hill [rhill@hill-a.ch] > Sent: Saturday, June 27, 2015 4:31 AM > To: Henning Schulzrinne; modern@ietf.org > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Dear Henning, > > Thank you for this and please see embedded comments below. > > Best, > Richard > > > > > but a number were > > present during the IETF Dallas BOF, from what I recall. > > > > The NANC documents can be found at > > > > http://nanc-chair.org/ > > That's the North American Numbering Plan, which concerns mostly the US, > with some input from Canada, since the other countries are mostly too > small to have much of a stake in whatever is decided. > > > > > FTN 7 is probably the most relevant effort. (I haven't actively > > participated in the effort since this is an advisory committee to the > > FCC, but I think we have NANC participants on the mailing list who > > might be willing to provide updates; contact information is provided > > on the meeting slides.) > > I suppose that you are referring to this: > > http://nanc-chair.org/docs/mtg_docs/Jun15_FoN_Report.pptx > > That presentation says "The Working Group will investigate new > telephone numbering assignment approaches and future telephone number > assignment requirements." > > So it is about changes that may require changes to current regulatory > policies. > > > But maybe you were referring to a different document. > > > > > The protocols being discussed have two "IP" angles: They are based on > > IP itself (rather than, say, TCAP) and they are likely most relevant > > in all-IP (VoIP) environments where both new entrants and carriers > > transitioning to an all-IP environment are more likely to use new > > number management approaches that are not encumbered by legacy > > constraints. > > Yes, but as I understand the charter, the proposed work is mostly about > figuring out how best to automate certain information flows. In my > experience, that quickly leads to thinking about business process > engineering, as we did for Electronic Data Interchange (EDI). In the > USA, much of that work was done by ANSI, with the IETF contribution > being limited to protocols for transmitting data. > > That is, the IETF did not get into the EDI equivalents of "managing, > distributing, registering", etc. > > >As you well know, many of those VoIP protocols have their technical > >home in the IETF. > > Yes, and as you also know well, some of the VoIP protocols have their > technical home in the ITU-T. Indeed you wrote an article comparing SIP > to H.323, at: > > http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.pdf > > There seem to be divergent opinions regarding the relative merits of > H.323 and SIP, and on which has greater market share, but for sure both > are widely deployed, see: > > http://www.packetizer.com/ipmc/h323_vs_sip/ > > > http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper091 > 86a00 > 80092947.shtml > > http://www.dailypayload.com/content/3111 > > And some people think that both are obsolete and should/will be > replaced by something newer, see for example: > > https://bloggeek.me/h323-sip-xmpp-js/ > > Be that as it may, the codecs standardized by ITU-T seem still to be > widely used, so apparently ITU-T is also able to produce ways of > packaging bits that are commercially useful. > > But, as I said above, I doubt that the thrust of the work of the > proposed Working Group would actually be about how to package bits. It > seems to me that it will be more related to business processes and > business process engineering, which is not an area in which the IETF > has traditionally been active. > > > > > I don't think anybody is proposing changing the US numbering plan > > (e.g., the number of digits in a phone number or fixed-vs-variable > > length) > > Pity because, as I said before, I think that that is long overdue. I > didn't say it before, but I think that the whole idea of using one > E.164 geographic country code for many countries is a deleterious relic > of the past, a "legacy system" in the worst sense of the term. In my > view, the US should take "1" for itself and the other countries should > get new codes (or, if the US were willing to share more equitably, it > could move to 11 and free up 9 codes). > > And the US could take advantage of that change to expand its numbering > plan. > (As you know, most countries have expanded their numbering plans during > the past 20 years.) > > >and that is well outside the scope of any IETF effort that I could > >imagine. > > True. But it would not necessarily outside the scope of ITU-T Study > Group 2, if everybody agreed that the matter should be discussed in > ITU-T. > > But maybe that's one of the reasons why some people would prefer not to > bring the matter to the ITU: they wish to ensure that the scope of the > discussions is restricted. > > That's certainly a legitimate desire, but I would submit that it would > be better fulfilled by creating an ad-hoc group to discuss the matter. > As several people have pointed out, IETF is open, so you never know > what will be brought into discussions. > > >I'm more concerned with the hodge-podge of numbering- related > >databases that have emerged over the decades and all made sense at > >some point. > > Indeed. But, again, this is not a matter of figuring out how to package > bits. It is a business process issue. And the IETF has not typically > been involved in those sorts of issues, at least not for what concerns > telephone numbers. Whereas ITU-T Study Group 2 has considered such > matters. > > > > > > >(This is indeed, as we all seem to agree but seem to be repeating > >again and again, an NRA issue well beyond IETF > > scope.) The LNPA pain that you may not be familiar with is the > >transition, after a competitive bidding process, between the previous > >contracted number management entity and the new one. Having > engineering > >options that bypass or minimize such disputes, should an NRA want to > >avail themselves of those, is one interest of mine. > > I don't follow the US developments closely, but I had heard that > Neustar lost its contract, or might lose its contract, or something to > that effect. > > Perhaps you could provide more detail on what you outline above, so > that we all have the same level of understanding of what is happening > in the US. > > > > > My point about "new entrants" is simply that incumbents are not the > > only audience for this. We may not know exactly who will be playing > in > > this sandbox in ten years (and neither the ITU nor the IETF are in > the > > sandbox admission policing business), > > Actually the ITU is in the sandbox admission business, for the non- > geographic country codes (881, 882, 883). For many years there were > few requests, about 1-2 per year. But things have picked up now and > they are getting several requests per year. > > And ITU is in the policing business, even if it has no enforcement > powers, with respect to misuse of E.164 numbers. > > Both issues may be related to some of the work of the proposed Working > Group. > > > but it's pretty clear that there > > will be new kids on the playground. > > > In my view, there would be more new kids if the legacy US numbering > plan were reformed. > > For example, if you had dedicated area codes for mobile, then some > mobile operators could envisage offering "caller pays" pricing plans. I > know that some people think that "receiver pays" is the only model that > makes sense, but in fact most of the world uses "caller pays". > > And the proportion of people who move to relatively expensive flat rate > plans might be different if they could choose between caller pays and > receiver pays. > > > > > > > Henning > > > > ________________________________________ > > From: Richard Hill [rhill@hill-a.ch] > > Sent: Friday, June 26, 2015 4:55 PM > > To: Henning Schulzrinne; modern@ietf.org > > Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, > > Distributing, Exposing, & Registering telephone Numbers (modern) > > > > Please see inline. > > > > > -----Original Message----- > > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning > > > Schulzrinne > > > Sent: Friday, June 26, 2015 22:30 > > > To: modern@ietf.org > > > Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, > Ordering, > > > Distributing, Exposing, & Registering telephone Numbers (modern) > > > > > > Since the nesting is getting confusing, let me add a few general > > > points that refer to a number of different discussion items: > > > > > > * My sense is that a number of national regulators > > > > Can you specify which national regulators are aware of the creation > of > > the proposed working group, other than the FCC, which I presume you > > are representing in this discussion? > > > > > are well aware of > > > the MODERN work. NANC has been kept in the loop, and their input on > > > requirements (e.g., through their Future of Numbering (FON) effort) > > > > Can you please give the URL for the cited documents? > > > > > > > > > > * I'm not sure other standards bodies have demonstrated equivalent > > IP- > > > based design experience, but (as noted) I suspect everybody > welcomes > > > inputs from as many interested parties as possible. > > > > I'm not sure that I understand what the IP-based specifics are of the > > project. As I understand it, the idea is to develop protocols for > > specifying requests to get numbers, etc. How is that specifically > tied > > to TCP/IP? > > > > > > > > > > * The current number porting model (in the US) predates the > Internet > > > and leaves room for improvement from a consumer and carrier > > > perspective. > > > > No kidding. The US numbering plan is, in my view, obsolete and badly > > in need of reform. But US industry and US authorities don't seem to > > agree (or at least they didn't last time I checked a couple of years > ago). > > > > > > > > > > * The current assignment model (at least in the US) is not a model > > > of efficiency and flexibility. There are numerous examples, but the > > > most recent difficult transition process of the LNPA is a > > > high-profile > > one. > > > > This is no doubt correct, but, again, changes in the assignment model > > are in the remit of the FCC, not the IETF (again, correct me if I'm > > wrong about that). > > > > > > > > * Traditional carriers may not be the only "customers". In IETF > > > work, there's sometimes the danger of equating the installed base > > > with the total market. > > > > Indeed, I think that carriers should not be the only recipients of > > telephone numbers. But, again, that is a policy question that is not > > in the remit of the IETF (but correct me if I'm wrong about that). > From nobody Sun Jun 28 06:38:01 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 DEEC81B2CE5 for ; Sun, 28 Jun 2015 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG3XqRFkj0X5 for ; Sun, 28 Jun 2015 06:37:58 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3B91A1B25 for ; Sun, 28 Jun 2015 06:37:57 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 6b8ff855.2b3651214940.1003901.00-2499.2816591.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 28 Jun 2015 13:37:58 +0000 (UTC) X-MXL-Hash: 558ff8b616041b41-14f8e93995a15bbcf933b457eb0710c48f2072d8 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 1b8ff855.0.1003893.00-2371.2816562.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 28 Jun 2015 13:37:57 +0000 (UTC) X-MXL-Hash: 558ff8b53a550b90-ebcdd79271e169ab99fbd6fb3e2b05db7e76ecf1 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5SDbrc3021047; Sun, 28 Jun 2015 09:37:53 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5SDbia0021005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 28 Jun 2015 09:37:46 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 28 Jun 2015 13:37:32 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0224.002; Sun, 28 Jun 2015 09:37:32 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne , Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZk/EVKozy60OW6OdQfnITd53AUOowgACi74CAAPjK0A== Date: Sun, 28 Jun 2015 13:37:32 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.228.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OIKQK1mB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=tc-25_r96LQA:10 a=o04Br] X-AnalysisOut: [8NZvxgA:10 a=BLceEmwcHowA:10 a=XAFQembCKUMA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=doUQZJtgAAAA:8 a=izV7ms69AAAA:8 a=T_O0atqTO6jixM_g] X-AnalysisOut: [pjQA:9 a=CjuIK1q_8ugA:10 a=DzjOOp_o1eYA:10 a=zoQXHG9dsgLMf] X-AnalysisOut: [NEl:21 a=lgHO5zmSyalty3ea:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 28 Jun 2015 13:38:00 -0000 Henning, Thank you for the explanation and link to the report and order. I was alrea= dy aware of these use cases.=20 My comment was to the examples on the mailing list. Thank you, Martin -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Saturday, June 27, 2015 2:44 PM To: DOLLY, MARTIN C; Eric Burger; modern@ietf.org Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Martin, this was discussed at some length during the BoF. The idea is that, as toda= y, a carrier or other authorized entity assigns a block of numbers to a lar= ge enterprise. For example, Columbia University has the 212 854 xxxx block = (among others). Within the enterprise, these are then delegated, automatica= lly, to various sub-units. This does not change the responsibility of the c= arrier, just automates a manual process. Indeed, a number of traditional ce= rtificated carriers apparently have been delegating numbers to their VoIP p= artners, whether those are consumer companies like Vonage or Skype or web A= PI providers, like Twilio. You may also find https://www.fcc.gov/document/fcc-releases-voip-direct-access-numbering-repo= rt-and-order of interest. It doesn't involve hot dog vendors, or Cisco (unless they turn= their WebEx business into iVoIP). Henning ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135= @att.com] Sent: Saturday, June 27, 2015 9:07 AM To: Eric Burger; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Numbers are a valuable resource. Traditionally, the FCC assigns the numbers to service providers, to which t= he FCC regulates and can punish with fines, etc.... I do not believe the FC= C will assign numbers to anyone that they cannot PUNISH if abuse occurs. Yes there have been experiments assigning to non-traditional SPs, but these= came with "conditions" WRT assigning numbers to Enterprises, where is the line drawn between assig= ning to Cisco versus Hot Dog vendor??? From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger Sent: Friday, June 26, 2015 7:54 PM To: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) On the one hand, neither MGCP nor SIP do number assignments for phones. It = is irrelevant for MGCP, because the soft switch handles the numbers. On the= SIP side, phone provisioning is the purview of the SIPForum device configu= ration specification. On the other hand, Cullen's use case of a large enterprise doing its own al= locations of numbers across multiple campuses, and as such down to the phon= e, was compelling to me. I do not think it has regulatory issues, and it is= a real problem that his customers would like to see solved. Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of other= vendors and large enterprises would be interested. Any comments from those= folks? On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] > wrote: "One would be an enterprise IP phone that has just been deployed and wants = to acquire a new number from an IP PBX." There are two existing protocols = which spring to mind which solve this problem; MGCP and SIP. I'm sure other= s can point to other similar protocols as well (e.g., NCS). And I would a= rgue the enterprise IP phone doesn't get a new number, the IP PBX does. Th= e phone merely gets associated with the number provisioned in the IP PBX in= order to originate or terminate calls through the IP PBX. I wasn't able to attend the MODERN BoF so I'm not familiar with the many us= e cases. In your example of the VoIP service provider I have questions. H= as it been determined that there are no suitable existing number provisioni= ng or number management protocols? ESPP and TERQ spring to mind as example= s of protocols which have been previously developed by the IETF for such pu= rposes and I'm sure there are other examples as well. And is a special protocol required for this example? Numerous peering rela= tionships are managed using spreadsheets in e-mail. It may be manual, inel= egant and prone to error, but it certainly is cheap and is often used. Hav= e there been VoIP providers that have claimed they are disadvantaged becaus= e they don't have a special protocol for provisioning subtended number bloc= ks with their carrier? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [snip] From nobody Sun Jun 28 21:06: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 EDFBF1B2D43 for ; Sun, 28 Jun 2015 21:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 oL_F4ecm3OJW for ; Sun, 28 Jun 2015 21:06:49 -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 8B20C1AD09C for ; Sun, 28 Jun 2015 21:06:48 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 39A75DEAEA67C; Mon, 29 Jun 2015 04:06:46 +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 t5T46k5g020896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 06:06:46 +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; Mon, 29 Jun 2015 06:06:46 +0200 From: "DRAGE, Keith (Keith)" To: Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGYyfpGjnKN5EOWAsicctSAOp3CjM4w Date: Mon, 29 Jun 2015 04:06:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> In-Reply-To: <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B69736468FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 29 Jun 2015 04:06:52 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B69736468FR712WXCHMBA11z_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm struggling with this. Maybe the public network use case can exist that tells a provider that the = number has been assigned, but I cannot envisage the private network use cas= e as being possible without also transferring attributes, e.g. class of ser= vice, how to route to that number, etc, that are associated with that numbe= r, and under which that number is used. It therefore becomes something much= more in the network management sphere than a number assignment problem. An= d network management is not something that is defined in any of the charter= s I have seen. And if it is not a network management protocol, what is the interaction of = such a new assignment protocol with any network management protocol that ma= y also be assigning the numbers. along with the other attributes of the so = created users. regards Keith P.S. As for "and it is a real problem that his customers would like to see = solved", I do not remember Cullen actually saying that, and none of the oth= er enterprise vendors seem to have weighed in on this. _____ From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger Sent: 27 June 2015 00:54 To: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distribu= ting, Exposing, & Registering telephone Numbers (modern) On the one hand, neither MGCP nor SIP do number assignments for phones. = It is irrelevant for MGCP, because the soft switch handles the numbers. On = the SIP side, phone provisioning is the purview of the SIPForum device conf= iguration specification. On the other hand, Cullen=92s use case of a large enterprise doing its o= wn allocations of numbers across multiple campuses, and as such down to the= phone, was compelling to me. I do not think it has regulatory issues, and = it is a real problem that his customers would like to see solved. Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of ot= her vendors and large enterprises would be interested. Any comments from th= ose folks? On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] > wrote: =93One would be an enterprise IP phone that has just been deployed an= d wants to acquire a new number from an IP PBX.=94 There are two existing = protocols which spring to mind which solve this problem; MGCP and SIP. I=92= m sure others can point to other similar protocols as well (e.g., NCS). A= nd I would argue the enterprise IP phone doesn=92t get a new number, the IP= PBX does. The phone merely gets associated with the number provisioned in= the IP PBX in order to originate or terminate calls through the IP PBX. I wasn=92t able to attend the MODERN BoF so I=92m not familiar with t= he many use cases. In your example of the VoIP service provider I have que= stions. Has it been determined that there are no suitable existing number = provisioning or number management protocols? ESPP and TERQ spring to mind = as examples of protocols which have been previously developed by the IETF f= or such purposes and I=92m sure there are other examples as well. And is a special protocol required for this example? Numerous peerin= g relationships are managed using spreadsheets in e-mail. It may be manual= , inelegant and prone to error, but it certainly is cheap and is often used= . Have there been VoIP providers that have claimed they are disadvantaged = because they don=92t have a special protocol for provisioning subtended num= ber blocks with their carrier? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [snip] --_000_949EF20990823C4C85C18D59AA11AD8B69736468FR712WXCHMBA11z_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I'm struggling with this.
 
Maybe the public network use case can exist that tells a pro= vider that the number has been assigned, but I cannot envisage the private = network use case as being possible without also transferring attributes, e.g. class of service, how to route to that = number, etc, that are associated with that number, and under which tha= t number is used. It therefore becomes something much more in the network m= anagement sphere than a number assignment problem. And network management is not something that is defined in any of= the charters I have seen.
 
And if it is not a network management protocol, what is the = interaction of such a new assignment protocol with any network management p= rotocol that may also be assigning the numbers. along with the other attributes of the so created users.
 
&nbs= p;
regards
 
Keith
 
P.S. As for "and it is a real problem that his customers would like to see solve= d", I do not remember Cullen actually saying that, and none of the other enterprise vendors seem to have weighed in on = this.

From: Modern [mailto:modern-bounces= @ietf.org] On Behalf Of Eric Burger
Sent: 27 June 2015 00:54
To: modern@ietf.org
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Dist= ributing, Exposing, & Registering telephone Numbers (modern)

On the one hand, neither MGCP nor SIP do number assignments for phones. It = is irrelevant for MGCP, because the soft switch handles the numbers. On the= SIP side, phone provisioning is the purview of the SIPForum device configu= ration specification.

On the other hand, Cullen=92s use case of a large enterpris= e doing its own allocations of numbers across multiple campuses, and as suc= h down to the phone, was compelling to me. I do not think it has regulatory= issues, and it is a real problem that his customers would like to see solved.

Besides Cisco, I would presume Avaya, Unify, Oracle, and a = handful of other vendors and large enterprises would be interested. Any com= ments from those folks?

On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.co= m> wrote:

=93One would be an enterprise IP phone that= has just been deployed and wants to acquire a new number from an IP PBX.=94  There ar= e two existing protocols which spring to mind which solve this problem; MGC= P and SIP. I=92m sure others can point to other similar protocols as well (e.g., NCS).   And I would argue the e= nterprise IP phone doesn=92t get a new number, the IP PBX does.  The p= hone merely gets associated with the number provisioned in the IP PBX in or= der to originate or terminate calls through the IP PBX.
 
I wasn=92t able to attend the MODERN BoF so I=92m not = familiar with the many use cases.  In your example of the VoIP service= provider I have questions.  Has it been determined that there are no suitable existing number provisioning or number manageme= nt protocols?  ESPP and TERQ spring to mind as examples of protocols w= hich have been previously developed by the IETF for such purposes and I=92m= sure there are other examples as well.
 
And is a special protocol required for this example?&n= bsp; Numerous peering relationships are managed using spreadsheets in e-mai= l.  It may be manual, inelegant and prone to error, but it certainly is cheap and is often used.  Have there be= en VoIP providers that have claimed they are disadvantaged because they don= =92t have a special protocol for provisioning subtended number blocks with = their carrier?
 
Best regards,
 
 
Pierce Gorman
Core Network Planning
O: 913-439-4368
pierce.gorman@sprint.co= m
<= image001.png>
[snip]

--_000_949EF20990823C4C85C18D59AA11AD8B69736468FR712WXCHMBA11z_-- From nobody Sun Jun 28 21:58: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 704201B3205 for ; Sun, 28 Jun 2015 21:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 SvZIF13hE1YB for ; Sun, 28 Jun 2015 21:58:20 -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 58DBA1B3204 for ; Sun, 28 Jun 2015 21:58:20 -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 t5T4w7Md085055 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2015 23:58:18 -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: Sun, 28 Jun 2015 23:58:07 -0500 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 29 Jun 2015 04:58:21 -0000 On 28 Jun 2015, at 23:06, DRAGE, Keith (Keith) wrote: > P.S. As for "and it is a real problem that his customers would like > to see solved", I do not remember Cullen actually saying that, and > none of the other enterprise vendors seem to have weighed in on this. (no hats) Speaking just for myself (as are we all, right? ;-) ) : I've mentioned before that I would like to see this solved. That has not changed. From nobody Mon Jun 29 08: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 C18611A03E1 for ; Mon, 29 Jun 2015 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0kW1NMy8LY8Z for ; Mon, 29 Jun 2015 08:11:08 -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 29C121A03B3 for ; Mon, 29 Jun 2015 08:11:08 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill , 'Richard Shockey' , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3BOpEAgAB25ACAAeEWFA== Date: Mon, 29 Jun 2015 15:11:06 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> ,<000601d0b168$06723ed0$1356bc70$@ch> In-Reply-To: <000601d0b168$06723ed0$1356bc70$@ch> 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] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 29 Jun 2015 15:11:10 -0000 This is straying far afield, but a few quick remarks: * The US numbering system does have extension points that would allow trans= itioning to longer numbers, but I haven't heard anybody proposing this seri= ously. Partially, it's because the number utilization is low (800M out of 1= 0B theoretically possible numbers), so while individual area codes continue= to be split, there is no shortage of numbers as such, particularly as the = need for prefix dialing disappears with the use of mobile and VoIP. (Right = now, a bunch of area codes can't be assigned since they are short numbers, = such as N11.) Most of the increased demand is from non-human users (think p= arking and water meters) and they generally don't care about geographic are= a codes. We can take bets as to whether the US will transition first to the= metric system or variable-length numbers. At least a presidential candidat= e has proposed the former and there's probably more value to that transitio= n. As geographic numbering decreases somewhat in importance, due to mobile, I = suspect that we should essentially look at numbers as either fixed-length (= NANP) or variable-length strings, and the trade-offs aren't obvious. It cou= ld well be that non-human users of phone numbers if they ever get beyond th= e rather limited applications envisioned so far, use longer strings, just a= s some such applications have started to use non-dialable numbers (pANI). I suspect that there are millions of places where software, from spreadshee= ts to databases and billing systems, in North America assumes fixed-length = strings, so you're suggesting another Y2K-level effort, with no obvious ben= efit. * The different dialing plans are a pain, but unifying them into permissive= 10D dialing does not require changing to a European-style variable-length = plan. They are mainly used since many people are used to dialing local numb= ers as seven digits in the NANP (just like they dial numbers without area c= odes elsewhere), but I suspect that the distinction between local and non-l= ocal will gradually fade as mobile dominates. * We have lots of issues in MODERN, but shy service providers doesn't seem = to be one of them... Given the additional flexibility and "cutting out the = middle man" advantages, I would hope that they'd actually see this effort a= s being to their benefit. ATIS and the ITU do fine and important work (and they clearly have a lot to= contribute in this space in terms of requirements and operational practice= s, so liaisons are all good), but they have not been in the protocol engine= ering business for a while. For the ITU, ISDN was indeed probably the last = such major effort, followed by ISDN-over-IP (aka H.323). Henning ________________________________ From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Sunday, June 28, 2015 00:57 To: Eric Burger; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) From: Modern > on b= ehalf of Eric Burger > Date: Friday, June 26, 2015 at 7:54 PM To: "modern@ietf.org" > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) SNIP If you eliminate the geographic or access means of numbering things get sim= pler. Yes as Brother Henning points out a TN is really a domain name and t= hat is why this discussion actually is important and makes sense. IBM or Fo= rd or Cisco could assign one single NPA to all of its employees for its bus= iness communications but you go tell citizens in Vermont Alaska or Maine PE= I Yukon etc they have to dial 10 digits for all calls. http://www.shockey.us/index.php/download_file/view/13/142/ >RH: I find that the paper cited above is excellent and I would urge everyb= ody who has a serious interest in these discussions to read it carefully. = In Switzerland, we have full geographic portability for fixed numbers (as w= ell as portability for mobile numbers), so users have to dial 10 digits for= all calls (including the leading zero, as in 022 840 1021). The same is t= rue in most European countries, but in some cases the number of digits in g= reater. Given the size of the US population (vs. the 8 million of Switzerla= nd), it seems to me that the US should envisage moving to 12 digits, or at = least 11. The unspoken issue here is where does the initial work get done and I=92m n= ot currently convinced the IETF is the right place to do it. OK I=92ll finally say it. The IETF has not traditionally been hospitable to the concerns of service p= roviders. There is a reason 3GPP ETSI ATIS exist. >RH: People who have been around a long time and who are cynical might be t= empted to recall the misunderstandings between the bell-heads and the net-h= eads. But I don=92t think that that is relevant any more. What is relevan= t is who tends to participate in which group. As far as I know, the people= who understand the concerns of service providers (and carriers) don=92t ty= pically participate in IETF. So I agree that IETF is not the right place to= start this work. But I do agree that the work should be started. Those w= ho wish to drive the work forward should pick an appropriate forum. Collectively we understand that there is a problem in the US with numbering= /routing databases and that the problem is manifesting itself first in the= North American market since the level of SIP/IMS deployments now far excee= d anything in Europe or AsiaPac. The PSTN Transition is no longer a idea i= ts an inevitability. And yes.. Contrary to everything Henry Sinnreich and = other used to preach ..TN are still here and I still don=92t see SIP URI=92= s on the side of pizza delivery cars. Even within the FCC and the Commissioners there is some divergent views on = what is actually at stake here. https://www.fcc.gov/article/fcc-15-70a6 The debate in the UK w/ BT is just starting. http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/= telecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-to-help-it= -battle-US-tech-giants.html From nobody Mon Jun 29 13:51:03 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 81C231B3416 for ; Mon, 29 Jun 2015 13:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WfCzrAeJi19n for ; Mon, 29 Jun 2015 13:50:59 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 9A3BA1B3426 for ; Mon, 29 Jun 2015 13:50:41 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5TKoaer026491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Jun 2015 22:50:37 +0200 Received: from Timea (adsl-178-38-38-252.adslplus.ch [178.38.38.252]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5TKoZFK030390; Mon, 29 Jun 2015 22:50:35 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , "'Richard Shockey'" , References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> , <000601d0b168$06723ed0$1356bc70$@ch> In-Reply-To: Date: Mon, 29 Jun 2015 22:50:48 +0200 Message-ID: <002301d0b2ad$47bab890$d73029b0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3BOpEAgAB25ACAAeEWFIAAZawQ Content-Language: fr-ch X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 29 Jun 2015 20:51:02 -0000 Indeed we are straying afield, but I'd like to offer one clarification. Many (maybe most, but I haven't checked) European numbering plans are fixed-length. I don't like variable-length numbering plans, including for the reason mentioned by Henning below. When I'm asked for advice, I always advise fixed-length, with a sufficient number of digits. Best, Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: lundi, 29. juin 2015 17:11 > To: Richard Hill; 'Richard Shockey'; modern@ietf.org > Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > This is straying far afield, but a few quick remarks: > > * The US numbering system does have extension points that would allow > transitioning to longer numbers, but I haven't heard anybody proposing > this seriously. Partially, it's because the number utilization is low > (800M out of 10B theoretically possible numbers), so while individual > area codes continue to be split, there is no shortage of numbers as > such, particularly as the need for prefix dialing disappears with the > use of mobile and VoIP. (Right now, a bunch of area codes can't be > assigned since they are short numbers, such as N11.) Most of the > increased demand is from non-human users (think parking and water > meters) and they generally don't care about geographic area codes. We > can take bets as to whether the US will transition first to the metric > system or variable-length numbers. At least a presidential candidate > has proposed the former and there's probably more value to that > transition. > > As geographic numbering decreases somewhat in importance, due to > mobile, I suspect that we should essentially look at numbers as either > fixed-length (NANP) or variable-length strings, and the trade-offs > aren't obvious. It could well be that non-human users of phone numbers > if they ever get beyond the rather limited applications envisioned so > far, use longer strings, just as some such applications have started to > use non-dialable numbers (pANI). > > I suspect that there are millions of places where software, from > spreadsheets to databases and billing systems, in North America assumes > fixed-length strings, so you're suggesting another Y2K-level effort, > with no obvious benefit. > > * The different dialing plans are a pain, but unifying them into > permissive 10D dialing does not require changing to a European-style > variable-length plan. They are mainly used since many people are used > to dialing local numbers as seven digits in the NANP (just like they > dial numbers without area codes elsewhere), but I suspect that the > distinction between local and non-local will gradually fade as mobile > dominates. > > * We have lots of issues in MODERN, but shy service providers doesn't > seem to be one of them... Given the additional flexibility and "cutting > out the middle man" advantages, I would hope that they'd actually see > this effort as being to their benefit. > > ATIS and the ITU do fine and important work (and they clearly have a > lot to contribute in this space in terms of requirements and > operational practices, so liaisons are all good), but they have not > been in the protocol engineering business for a while. For the ITU, > ISDN was indeed probably the last such major effort, followed by ISDN- > over-IP (aka H.323). > > Henning > > ________________________________ > > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard > Shockey > Sent: Sunday, June 28, 2015 00:57 > To: Eric Burger; modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > > > From: Modern > > on behalf of Eric Burger > > > Date: Friday, June 26, 2015 at 7:54 PM > To: "modern@ietf.org" > > > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > > SNIP > > If you eliminate the geographic or access means of numbering things get > simpler. Yes as Brother Henning points out a TN is really a domain > name and that is why this discussion actually is important and makes > sense. IBM or Ford or Cisco could assign one single NPA to all of its > employees for its business communications but you go tell citizens in > Vermont Alaska or Maine PEI Yukon etc they have to dial 10 digits for > all calls. > > http://www.shockey.us/index.php/download_file/view/13/142/ > > >RH: I find that the paper cited above is excellent and I would urge > everybody who has a serious interest in these discussions to read it > carefully. In Switzerland, we have full geographic portability for > fixed numbers (as well as portability for mobile numbers), so users > have to dial 10 digits for all calls (including the leading zero, as in > 022 840 1021). The same is true in most European countries, but in > some cases the number of digits in greater. Given the size of the US > population (vs. the 8 million of Switzerland), it seems to me that the > US should envisage moving to 12 digits, or at least 11. > > The unspoken issue here is where does the initial work get done and I'm > not currently convinced the IETF is the right place to do it. > > OK I'll finally say it. > > The IETF has not traditionally been hospitable to the concerns of > service providers. There is a reason 3GPP ETSI ATIS exist. > > >RH: People who have been around a long time and who are cynical might > be tempted to recall the misunderstandings between the bell-heads and > the net-heads. But I don't think that that is relevant any more. What > is relevant is who tends to participate in which group. As far as I > know, the people who understand the concerns of service providers (and > carriers) don't typically participate in IETF. So I agree that IETF is > not the right place to start this work. But I do agree that the work > should be started. Those who wish to drive the work forward should > pick an appropriate forum. > > Collectively we understand that there is a problem in the US with > numbering/routing databases and that the problem is manifesting itself > first in the North American market since the level of SIP/IMS > deployments now far exceed anything in Europe or AsiaPac. The PSTN > Transition is no longer a idea its an inevitability. And yes.. > Contrary to everything Henry Sinnreich and other used to preach ..TN > are still here and I still don't see SIP URI's on the side of pizza > delivery cars. > > Even within the FCC and the Commissioners there is some divergent views > on what is actually at stake here. > > https://www.fcc.gov/article/fcc-15-70a6 > > The debate in the UK w/ BT is just starting. > > http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelec > oms/telecoms/11696314/BT-aims-to-shut-down-traditional-phone-network- > to-help-it-battle-US-tech-giants.html > From nobody Mon Jun 29 14:14: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 2342D1B349C for ; Mon, 29 Jun 2015 14:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 OvfX7MCmdkAe for ; Mon, 29 Jun 2015 14:14:46 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE6C1B349A for ; Mon, 29 Jun 2015 14:14:46 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 41ADB21D53 for ; Mon, 29 Jun 2015 17:14:45 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 29 Jun 2015 17:14:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=bGikw PoRyKr91cnsEzng04h2wl8=; b=1OhmXH6nEx6gKTodn1+Ep4yQy2PqTihQ6/7MS ImMd3bnLLNOsr/3J/472c/FAahWPzrTfeHSrbdM71eKqggKeHhk9AQD4Awc1x54+ a9flnXn41sXT6uwBhlJ1MDnTsC9qrdEDcLFIkq5XJJHgm1ks0ODmy20qtvgfd4tX EUj6tc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=bGikwPoRyKr91cnsEzng04h2wl8=; b=ueU8q Mxdf+tlot3FpX4BN1S1WLb70QOMwm+I6sbGpzB6SENyWLIQ6Napbqj8SvreBF2tU IQXHYzwstWw7vDanThT1kiI7jOfVlckJsbUYG8YlJwrnyDRWFOp8aeo/HfrmR5/j 6HuCVw8q+AejKSDloy5wV2lRWzgWkZP61XNWSw= X-Sasl-enc: fgNR8kIXZhNKThlN4NwSAqWVKR4vGambgdw7z4uOnQYB 1435612484 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id E8F9B68013E; Mon, 29 Jun 2015 17:14:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EFD0B46F-30A4-49EC-90E3-0FEA97B6CE51" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Mon, 29 Jun 2015 14:14:42 -0700 Message-Id: References: To: "McGarry, Tom" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "modern@ietf.org" Subject: [Modern] charter edits 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, 29 Jun 2015 21:14:52 -0000 --Apple-Mail=_EFD0B46F-30A4-49EC-90E3-0FEA97B6CE51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tom and all, Thanks for proposing some edits. I have reflected them with minor tweaks = in the latest version of the charter =97 = http://datatracker.ietf.org/doc/charter-ietf-modern/ The chartering of MODERN was approved on the IESG telechat last week = (which I unfortunately missed since I was at the ICANN meeting). I will = let these edits sit for a day before hitting the approval button. I think the discussion that resulted from the comments relating to ITU-T = SG 2 has been a useful airing at this stage in the game and a helpful = reminder to everyone to make sure we keep interested parties in the loop = on this one. Personally I will certainly keep that in mind as the group = reaches milestones where further external review might be appropriate. = But in any event we have consensus to move forward with chartering. Alissa On Jun 25, 2015, at 3:31 PM, McGarry, Tom = wrote: >=20 > This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. = Entities can choose to use these tools or not. These tools are not for = the ITU-T's processes or role, nor for how national administrators = interact with the ITU-T. But of course we want your input and feedback, = so thanks for sending this along. More comments in line below. =20 >=20 >=20 > From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM > To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > Would appreciate people=92s thoughts on whether any charter edits may = be warranted in response to these comments, and/or whether a separate = response may be useful for addressing some of the questions below. >=20 > Alissa >=20 > Begin forwarded message: >=20 >> From: "Zhang, Jie" >> Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern) >> Date: June 23, 2015 at 1:56:42 PM GMT-3 >> To: "iesg@ietf.org" >> Cc: "Jamoussi, Bilel" >=20 >> Dear Sir/Madam, >>=20 >> Below please find comments from the ITU Telecommunication = Standardization Bureau on the proposed IETF working group MODERN. >>=20 >> 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1=20 >> It is stated at the beginning of the Charter that 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. And = it is mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to here = only deals with Tel URI? Would there be any impact on Recommendation = ITU-E E.164 and E.164.1 which are core recommendations on Telephone = Numbers? >=20 > There will be no impacts on E.164 and E.164.1. >>=20 >> 2. Entities participating in the defined mechanisms >> The Charter states that the protocol mechanism for resolving TNs will = allow entities such as service providers, devices, and applications to = access data related to TNs. But it is not clear what kind of entities = can participate in the mechanisms defined by this MODERN working group. = Would it be restricted to the entities who have been assigned a TN or a = block of TNS? >=20 > Who participates in numbering processes within countries is subject to = regulation. The WG cannot make any decisions with regard to this. I = expect the WG to define "roles" within the number management processes; = e.g., administrator, telecom carrier, application provider, consumer, = etc.; and how those roles could interact with each other. This will be = a baseline for what tools and solutions would be useful to facilitate = those interactions. =20 >>=20 >> 3. Status of Telephone numbers in the defined mechanisms >> Several operations related to TNs are mentioned in the Charter, = including requesting, acquiring, resolving and associating. It is also = stated that the protocol mechanism for acquiring TNs will provide an = enrollment process for the entities that use and manage TNs. Does that = mean Telephone numbers with various status, such as assigned, spare and = reclaimed numbers will all be managed in the mechanisms defined by the = MODERN working group? >=20 > I would expect proposed solutions to be able to address the status of = a telephone number. >>=20 >> 4. Regulatory issues >> The Charter states that Solutions and mechanisms created by the = working group will be flexible enough to accommodate different policies = for TN assignment and management, for example those established by = different regulatory agencies. We would like to bring your attention to = the fact that the E.164 international public telecommunication numbering = plan is a politically significant numbering resource with direct = implications on national sovereignty. ITU Plenipotentiary Conference = Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and = sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined in = Recommendation ITU-T E.164", and further instructed the ITU = Secretary-General and the Directors of three Bureaux (Telecommunication = Standardization, Development, and Radiocommunication) to "take any = necessary action to ensure the sovereignty of ITU Member States with = regard to Recommendation ITU-T E.164 numbering plans whatever the = application in which they are used". >=20 > We are aware of Resolution 133 and will certainly respect it. I would = propose adding the following text after the first sentence in the last = full paragraph =96 "The group acknowledges ITU Plenipotentiary = Conference Resolution 133 which recognizes the existing role and = sovereignty of ITU Member States with respect to allocation and = management of their country code numbering resources as enshrined in = Recommendation ITU-T E.164." =20 >>=20 >> 5. Relationship with .Tel >> DNS-based use of international numbering resources has been discussed = in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. = TSB Director has also exchanged letters with ICANN on issues related to = registering digit strings in the .TEL domain. A representative from = ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and = provided some background on the TELNIC application. A correspondence = group under ITU-T SG2 was also set up in this regard. We would like to = know how the work of this new WG would relate to issues related to = registering digit strings in the .TEL domain and other DNS-based use of = telephone numbers. >=20 > The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG = leveraging existing namespaces as part of proposed solutions. But it's = too early to say anything specific about that. There is nothing in the = charter that references .tel. =20 >>=20 >> 6. Relationship with related existing or concluded WGs >> It is stated in the Charter that the working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. Detailed description of the relationship between this new WG = and the above mentioned other existing or concluded WGs would be = appreciated. >=20 > I agree. I would modify that sentence to add the following at the end = - "as well as other relevant industry and standards organizations." >>=20 >> 7. The name of this new WG >> The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the Charter, = ordering, exposing and registering TNs are not mentioned, which seems to = be a little bit inconsistent. >=20 > The IETF often has fun with creating WG names. : ) But the charter = is where to look for the scope of work. The charter uses the following = phrases "distribution, acquisition and management of TNs", "functions = involved in associating information =85 with TNs", "associating, = acquiring and resolving TNs", "access data related to TNs", and = "mechanisms for resolving information related to TNs". The functions = you believe were left out of the charter will be part of one or more of = these processes. =20 >>=20 >>=20 >> Best regards, >>=20 >> Jie Zhang >> Advisor, ITU-T SG2 >> International Telecommunication Union >> Place des Nations >> CH-1211 Geneva , Switzerland=20 >> Tel :+41 22 730 5855 >> jie.zhang@itu.int >> www.itu.int >> www.itu150.org >>=20 >>=20 >> -----Original Message----- >> From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The = IESG >> Sent: Friday, June 12, 2015 8:47 PM >> To: new-work@ietf.org >> Subject: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern) >>=20 >> A new IETF working group has been proposed in the Applications and = Real-Time Area. The IESG has not made any determination yet. The = following draft charter was submitted, and is provided for informational = purposes only. Please send your comments to the IESG mailing list (iesg = at ietf.org) by 2015-06-22. >>=20 >> Managing, Ordering, Distributing, Exposing, & Registering telephone = Numbers (modern) >> ------------------------------------------------ >> Current Status: Proposed WG >>=20 >> Chairs: >> Tom McGarry >> Steve Donovan >>=20 >> Assigned Area Director: >> Alissa Cooper >>=20 >> Mailing list >> Address: modern@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/modern >> Archive: http://www.ietf.org/mail-archive/web/modern/ >>=20 >> Charter: >>=20 >> 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. Devices, applications, and network tools = increasingly need to manage TNs, including requesting and acquiring TN = delegations from authorities. The output of the working group should = make distribution, acquisition, and management of TNs simpler for all = entities involved. >>=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 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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs.=20 >>=20 >> 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, and = security and privacy for both the data and the protocol interactions are = primary considerations. The working group will take into consideration = existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. >>=20 >> 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. 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 for TN assignment and management, for = example those established by different regulatory agencies. >>=20 >> The working group will deliver the following: >>=20 >> - An architecture overview, including high level requirements and = security/privacy considerations >>=20 >> - A description of the enrollment processes for existing and new TNs = including any modifications to metadata related to those TNs >>=20 >> - A description of protocol mechanisms for accessing contact = information associated with enrollments >>=20 >> - A description of mechanisms for resolving information related to = TNs >>=20 >> Milestones: >>=20 >> TBD >>=20 >> _______________________________________________ >> new-work mailing list >> new-work@ietf.org >> https://www.ietf.org/mailman/listinfo/new-work >>=20 >=20 >>=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_EFD0B46F-30A4-49EC-90E3-0FEA97B6CE51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Tom and all,

Thanks = for proposing some edits. I have reflected them with minor tweaks in the = latest version of the charter =97 http://datat= racker.ietf.org/doc/charter-ietf-modern/

The = chartering of MODERN was approved on the IESG telechat last week (which = I unfortunately missed since I was at the ICANN meeting). I will let = these edits sit for a day before hitting the approval = button.

I think the discussion that resulted = from the comments relating to ITU-T SG 2 has been a useful airing at = this stage in the game and a helpful reminder to everyone to make sure = we keep interested parties in the loop on this one. Personally I will = certainly keep that in mind as the group reaches milestones where = further external review might be appropriate. But in any event we have = consensus to move forward with = chartering.

Alissa

On Jun = 25, 2015, at 3:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> = wrote:


This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. =  Entities can choose to use these tools or not.  These tools = are not for the ITU-T's processes or role, nor for how national = administrators interact with the ITU-T.  But of course we want your = input and feedback, so thanks for sending this along.  More = comments in line below.  


From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 = 7:44 AM
To: Modern List <modern@ietf.org>
Subject: [Modern] Fwd: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

Would appreciate people=92s thoughts on whether any charter edits may be = warranted in response to these comments, and/or whether a separate = response may be useful for addressing some of the questions below.

Alissa

Begin forwarded message:

From: "Zhang, Jie" <jie.zhang@itu.int>
Subject: RE: [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)
Date: June 23, 2015 at 1:56:42 PM GMT-3
Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>
Dear Sir/Madam,

Below please find comments from the ITU Telecommunication = Standardization Bureau on the proposed IETF working group MODERN.

1. = Potential impacts on Recommendation ITU-T E.164 and = E.164.1 
It is stated at the beginning of the Charter that 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. And = it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism = being referred to here only deals with Tel URI? Would there be any = impact on Recommendation ITU-E E.164 and E.164.1 which are core = recommendations on Telephone Numbers?
There will be no impacts on E.164 and = E.164.1.

2. = Entities participating in the defined mechanisms
The Charter states that the protocol mechanism for resolving TNs will = allow entities such as service providers, devices, and applications to = access data related to TNs. But it is not clear what kind of entities = can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have = been assigned a TN or a block of TNS?
Who participates in numbering processes within = countries is subject to regulation.  The WG cannot make any = decisions with regard to this.  I expect the WG to define = "roles" within the number management processes; e.g., = administrator, telecom carrier, application provider, consumer, etc.; and how those = roles could interact with each other.  This will be = a baseline for what tools and solutions would be useful to = facilitate those interactions.  

3. = Status of Telephone numbers in the defined mechanisms
Several operations related to TNs are mentioned in the Charter, = including requesting, acquiring, resolving and associating. It is also = stated that the protocol mechanism for acquiring TNs will provide an = enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as = assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working group?
I would expect proposed solutions to be able to address the = status of a telephone number.

4. = Regulatory issues
The Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact that the E.164 international public = telecommunication numbering plan is a politically significant numbering = resource with direct implications on national sovereignty. ITU = Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with = respect to allocation and management of their country code numbering = resources as enshrined in Recommendation ITU-T E.164", and further = instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and = Radiocommunication) to "take any necessary action to ensure the = sovereignty of ITU Member States with regard to Recommendation ITU-T = E.164 numbering plans whatever the application in which they are used".
I would propose adding the following text after the first sentence in the last = full paragraph =96 "The group acknowledges ITU Plenipotentiary Conference Resolution = 133 which recognizes the existing role and sovereignty of ITU Member States with respect to = allocation and management of their country code numbering resources as = enshrined in Recommendation = ITU-T E.164."  

5. = Relationship with .Tel
DNS-based use of international numbering resources has been discussed in = ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB = Director has also exchanged letters with ICANN on issues related to = registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 = May - June 2014) and provided some background on the TELNIC application. = A correspondence group under ITU-T SG2 was also set up in this regard. = We would like to know how the work of this new WG would relate to issues related to registering digit strings in = the .TEL domain and other DNS-based use of telephone = numbers.
The WG will not create any new namespace that = would require regulatory oversight, e.g., a new TLD, SLD, etc. =  I wouldn't rule out the WG leveraging existing = namespaces as part of proposed solutions.  But it's too early to = say anything specific about that.  There is nothing in the charter that = references .tel.  

6. = Relationship with related existing or concluded WGs
It is stated in the Charter that the working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS = and SCIM. Detailed description of the relationship between this new WG = and the above mentioned other existing or concluded WGs would be appreciated.
I agree.  I would modify that = sentence to add the following at the end - "as well as = other relevant industry and standards = organizations."

7. = The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)". But in the Charter, = ordering, exposing and registering TNs are not mentioned, which seems to = be a little bit inconsistent.
The IETF often has fun with creating WG names. =  : )  But the charter is where to look for the scope of work. =  The charter uses the following phrases "distribution, acquisition = and management of TNs", "functions involved in associating information =85 with TNs", "associating, acquiring = and resolving TNs", "access data related to TNs", and = "mechanisms for resolving information related to TNs".  The = functions you believe were left out of the charter will be part of one = or more of these processes.  


Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-work-bounces@ietf.org= ] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and = Real-Time Area. The IESG has not made any determination yet. The = following draft charter was submitted, and is provided for informational = purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by = 2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone = Numbers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz>  Steve Donovan <srdonovan@usdonovans.com><= br>
Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailing list
 Address: modern@ietf.org
 To Subscribe: https://www.ietf.org= /mailman/listinfo/modern
 Archive: http://www.ietf.org/= mail-archive/web/modern/

Charter:

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. Devices, applications, and network tools increasingly = need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working = group should make distribution, acquisition, and management of TNs = simpler for all entities involved.

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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for = acquiring TNs will provide an enrollment process for the entities that = use and manage TNs. 

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, and = security and privacy for both the data and the protocol interactions are primary considerations. The working group will take = into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by = different regulatory agencies.

The working 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

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.o= rg/mailman/listinfo/new-work
_______________________________________________
Modern mailing = list
Modern@ietf.org
https://www.ietf.or= g/mailman/listinfo/modern

= --Apple-Mail=_EFD0B46F-30A4-49EC-90E3-0FEA97B6CE51-- From nobody Mon Jun 29 14:19:18 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EC91B34C3 for ; Mon, 29 Jun 2015 14:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 O1uRZ0_G0AO5 for ; Mon, 29 Jun 2015 14:19:16 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0021B34C1 for ; Mon, 29 Jun 2015 14:19:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E99BA21CBF for ; Mon, 29 Jun 2015 17:19:15 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 29 Jun 2015 17:19:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ZG+6DqqXay3JFpXAgOQp3bSODqE=; b=s9hkEc X2it5gdiPc+GArOXyb0WvGFzQ6C5OEAb4TPCPipDKJL4bhKV6LDoGm/x7dBg9DFe qzxQFDQNXTERj9aAleI/9Qsc0E+WXCTxS+a+15DIWVgBnIAoFmNOTG8fxGIbgpha JgWNn+LYzp+PsZJCZyCzAu+3rYfZo4NZUhf7w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ZG+6DqqXay3JFpX AgOQp3bSODqE=; b=HP9H63FuwhrfCzWvbPbzuVAQLBW75aiD/4FpwdwTdo3vX52 TqQSK0urv7oVe31ZQf+P6FJGzjMa2iT5qkfyEkxY1yJCiH35afC2pbq4BZxAUsU8 SFSC0Y08zPx/++N9PfUyKSd5GD52JBDEyKy3WR52EgfDbVjlWMzD4ipFAQsI= X-Sasl-enc: IWpGiv8teN6Fv+GPkmzCg7XdD4VSNScLPv+64Sfjimnd 1435612755 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 9A8CE680055; Mon, 29 Jun 2015 17:19:14 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <01e101d0b053$a1192c20$e34b8460$@ch> Date: Mon, 29 Jun 2015 14:19:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> , <005a01d0b022$169bcbb0$43d36310$@ch> <01e101d0b053$a1192c20$e34b8460$@ch> To: Richard Hill X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: modern@ietf.org, "McGarry, Tom" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 29 Jun 2015 21:19:17 -0000 Hi Richard, On Jun 26, 2015, at 2:04 PM, Richard Hill wrote: > And, to begin with, why nobody seems to have thought of sending the = draft > working group charter to ITU-T Study Group 2 to see what they thought = of it. That is indeed the purpose of the new-work mailing list and the external = review period for IETF WG charters. The message that began this thread = was a response from an ITU-T SG 2 advisor. So the process is working = exactly as intended. As I noted in my other message, I=92m glad the ITU-T related discussion = took place at this stage. We do have a quorum of people who want to see = the protocol work for this done in the IETF. Generally speaking if a = bunch of folks want to come to the IETF to do a piece of protocol work = that is not being done elsewhere then I see no reason to prevent that. Alissa= From nobody Mon Jun 29 14:49: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 A96B61B3555 for ; Mon, 29 Jun 2015 14:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 x2cLYoZzCraw for ; Mon, 29 Jun 2015 14:49:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6015E1B3551 for ; Mon, 29 Jun 2015 14:49:14 -0700 (PDT) Received: from BL2FFO11OLC011.protection.gbl (10.173.160.31) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.1.201.10; Mon, 29 Jun 2015 21:49:12 +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 BL2FFO11OLC011.mail.protection.outlook.com (10.173.160.157) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Mon, 29 Jun 2015 21:49:12 +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 t5TLmI5Q034205; Mon, 29 Jun 2015 17:49:11 -0400 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm2.corp.sprint.com with ESMTP id 1v9mupqrqg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Jun 2015 17:49:11 -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; Mon, 29 Jun 2015 16:49:10 -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, 29 Jun 2015 16:49:10 -0500 From: "Gorman, Pierce A [CTO]" To: Alissa Cooper , "McGarry, Tom" Thread-Topic: [Modern] charter edits Thread-Index: AQHQsrCn8pPIhdUOB0yIOuvidUYFU53EBQxA Date: Mon, 29 Jun 2015 21:49:09 +0000 Message-ID: <0c39102daf9b448595a17b16cd48be00@PLSWE13M08.ad.sprint.com> References: In-Reply-To: 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.214.116.49] Content-Type: multipart/related; boundary="_004_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC011; 1:1MVPi0Fc6sxZX4kKl3S5XH2nSr48tyqgr+p9/TA/h6+ioSEKxOH6u++M5qsBqG9z6M3u/oHFMM5ntUJ3yCUypMpNF1e8TFx1U1oZiLL4+L78Ax+6qMPCWzhu1FmdUGAh9mU76mdepUkEhpymmm4F1f/071vO8GuLns2dsCNrkaSltYoIZGoQ/4KjyDbIbjd5W10u4tmjfwJTMmUKlcDTrK4q1Ma/rHq/uYgN6TavXgjy7iN2QUhiiAEqyiPAS96h1XcDy1Ym3D60bW+3m8KvxkghtVZK47YuZiN9+VgROA/5e4/m5Z9SQQb6IJ9WMl5+ X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(448002)(52604005)(199003)(189002)(45074003)(24454002)(60444003)(377454003)(13464003)(15975445007)(102836002)(2900100001)(16601075003)(92566002)(2656002)(5003600100002)(30436002)(99936001)(86362001)(54356999)(50986999)(19300405004)(67866002)(2950100001)(5250100002)(15974865002)(19580395003)(84326002)(66926002)(6806004)(19580405001)(76176999)(106116001)(46102003)(5001770100001)(17760045003)(33646002)(16236675004)(19625215002)(575784001)(19617315012)(106466001)(189998001)(87936001)(85326001)(5001960100002)(24736003)(19627595001)(512954002)(77156002)(62966003)(108616004)(18206015028)(7099028)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB028; H:preapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB028; 2:KEJFmBCOPYgRV01djYhSPfnqTf/cB4F2QKEtAQclW1BTR261izkRp3LK8A9tIcr7; 3:o9MsdpyKe6bm8Bj7lujsuwsn5kd9/oONoSKdpFCeHVdS8G6YW1+5CzoHCWWqoQ6x9w9X4XiVkjqcNZyZvoCqEYcPIoTZe21Z7f0q0o+WGACVyjQrM6CX0wHZZxK3Cm/3j5OUfuUH312mQerf6miCEJNVEv2D6Qi9gx1v7uwTu3z4VWNRGCvrrQ56H83bDeHP+NMSyfwNwhFbwp93330PSCR1sOx8jxORaYWD0w3fASk=; 20:7XluBUB1fNQw6aw7Sa7QA0vU9FVoeiFQP1GgEI4TQ1HB52fXEz9WIF8/nNqSjKgnpcP3Pr3H619xjOLhn4ULRj8nKGljZu41VNRSnA3DpmgPKWrk3hcELDNaBavj9z1Hj+e0W+aJSDOJTmy9eiGY1dvYfohHKa9OS6bV1p1OYVuBUIC+oZEvZwhJCTuRmELYvvRDANMazx2FSbf+3i7N279TLBByvaw2orFHO9vF+Y7jhD169HNxc39hEgtEAOVP; 4:6YIKDRB2wlPSmawjceT5JEXuAupBzoT10OntT6yybQha4tN8rYYxV6VEkG+MsruZEgmHngrNA2a2CZHbKOcH16UKotPrKpCZMtClwoP6qpYt/5Q9dNmOSixgEFfcenzyoXq4aO5xTZOvjSP9gDrODKjI4ZeqR16LywiolW07akO2lJqjpctFoYiOtssCcgdhjnHrSRiuCTsVtvT3GKmdEJmqD9m3JgF+a/90g0VKDrKJJGwdkqe9YEC5gyIjFf3mSHwZbgq6QaZd12qKHC38hX93Cen7o0MCaqYL8bm2Ud4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB028; 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:BL2FFO11HUB028; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB028; X-Forefront-PRVS: 0622A98CD5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB028; 23:9BE6tAWK1LtSvgvtiMepD/QbXBgBMxfhwU56l5nw?= =?us-ascii?Q?hX3JnNOIWWMcMEejOWf0ujozfWzqaB9lUB9Ot+OI0JGzKwYy2Pw/ogi9gfDx?= =?us-ascii?Q?ouiKyNqpdrazX0op/BJC7Gkqs+pmEoDcBBHl6bQcCnPJ2oNqskxpOP+3oALN?= =?us-ascii?Q?G02UMtCtof68Es5O6YdoTIdIQaJgw2Imb2Mke2DCTAfkoIl9b28ieZpWTe6n?= =?us-ascii?Q?UTg0JU7MkVBA6KcrXEoq+Ao9Uq/+8Ai6gYKJmaqDXUj/hGLyv5W0Nxg/YlVj?= =?us-ascii?Q?3fyy5vyc1PrC0XRBcIp0GSzFyKy16OldoZzpQCL/NBoyd7upOJ9333u+Clix?= =?us-ascii?Q?OKRHDZJNI6UfOQUr3HQXX+qZnm8LjcPy6sntNHRpg5vMM4aZUnvzgrYC3xqr?= =?us-ascii?Q?DvCf4gQ79j10VqXWedqlQSzjq6B+T+IWHMkDTYmc4hlEq56KUfctUEJNksvG?= =?us-ascii?Q?b1wkObOYNIsPrQQzZOdLWC5CnGzK7LVextUgwrYdoBydChiSw7C2ACH42QiD?= =?us-ascii?Q?3nxfd4RLujD1IYVD+nPFoTjex0Xkp6IluybO0U4CdseyDrK1URhYttCGsAW3?= =?us-ascii?Q?yliI9CvKWWhibO6gFYDUUfeak4JD5aUF1rxl8z+Km9aGCE/+MnenCt5RCmk6?= =?us-ascii?Q?bLWstsU4e500wMnJW2w4y4kBXjSwi9AQC1nWi7oGkOkLM1xzt/ylOb7a6Xq8?= =?us-ascii?Q?YjiVfjhW1jT8nLx6ICiO7J/YtMVreG1iy+AdLkS80qtmWPKPpKfaov2khFV5?= =?us-ascii?Q?PISopOqWYW0tjev41+cCmXkEp2lVIL1Wdj4FlEjpLPh4qp6HulpMIrzZC5Nq?= =?us-ascii?Q?WNMkQ2eMBls21n/DK8ZdT01751/BNhosrohLXzX1M6PHu1/zLKFnJLniQiDA?= =?us-ascii?Q?5l598xFm3L9D7cnVkZDBG4NqP03ABttps+UUOVPSJ9RjBH+NTuoSYoO0r7pq?= =?us-ascii?Q?4fZYMZe/I6hFaovVMzJH6bOXexV5RWvxR9ITieuretRTG0zwGZ7a2MzbY2XI?= =?us-ascii?Q?teR774r0X4Xs8AnVwOaT88KcYyJPLVsXEn8cODRALFCKCuytUkg4ZQS2e85n?= =?us-ascii?Q?tdCkP8fOVufJTmghLaRKB4YYX74/TfnPdq09pCC/8lkHCIaXG1wlMqyVzbix?= =?us-ascii?Q?WkLgDK5Z2lJNz9GN2ofjACGf6XyO69sdm3IPzOO7cQJYq+Z2EQmkpbnHWISv?= =?us-ascii?Q?B56ifvJHMpubQEVf2N7EFw4/W2bxnBqyvdcGNRKbfzR+5+epwO38PQkbs1uP?= =?us-ascii?Q?fB+xaihg/5ScugnecoWY9GUPPu4J+Va5x19oQF5tPXEKcofa1xZ2BBKIh0zN?= =?us-ascii?Q?p6pkSX0nudIyf+Xe1BMrDTH7593e/VuuM4eWNYv3cgCF7DnX/wgNRvdwHm23?= =?us-ascii?Q?GGBXXmCzoNhjUFYpatSgue+d8ee7W4Pas8AHkUMmT58YamicC6s6dV0xCBZX?= =?us-ascii?Q?y9lmrR6wmB2/f+XxwP3QbeqhAnu4tzI=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB028; 5:8qOhpxIfxxWTGV65nD7P2vn8iT/7tUI+0F5yQEtoS21ISrQ6vZrSs0b6WTKD0eh+CmvBjCb45CwWJcvmWtX8C96yghdwydteh1wF/kFRXmOrNp9Sz7rQCyJqPMfIL61tiIyCnFAmgX0MewxqmZMF4w==; 24:Qh6qWOw9BpcXc+rUT/FUfD3TTq9vfhZKmECazCIAlrm0LdpcK4U7aKSmu2NGpjczMGZWHdSbFsNlQHG1sig9ZhVbRlhqkPJgA0o6hUi/eek= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2015 21:49:12.0680 (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: BL2FFO11HUB028 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] charter edits 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, 29 Jun 2015 21:49:24 -0000 --_004_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_" --_000_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alissa, The internal SDO folks I rely on for learning about IETF procedures are una= vailable. Does the "consensus" reached at the "IESG telechat" that occurre= d last week constitute the official commissioning of the IETF MODERN workin= g group? The reason I ask is I wanted to formulate a response to the dozens of e-mai= ls from over the weekend, but don't want to bother if it is now (and was?) = moot. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: June 29, 2015 4:15 PM To: McGarry, Tom Cc: modern@ietf.org Subject: [Modern] charter edits Tom and all, Thanks for proposing some edits. I have reflected them with minor tweaks in= the latest version of the charter - http://datatracker.ietf.org/doc/charte= r-ietf-modern/ The chartering of MODERN was approved on the IESG telechat last week (which= I unfortunately missed since I was at the ICANN meeting). I will let these= edits sit for a day before hitting the approval button. I think the discussion that resulted from the comments relating to ITU-T SG= 2 has been a useful airing at this stage in the game and a helpful reminde= r to everyone to make sure we keep interested parties in the loop on this o= ne. Personally I will certainly keep that in mind as the group reaches mile= stones where further external review might be appropriate. But in any event= we have consensus to move forward with chartering. Alissa On Jun 25, 2015, at 3:31 PM, McGarry, Tom > wrote: This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service = and application providers, and consumers. Entities can choose to use these= tools or not. These tools are not for the ITU-T's processes or role, nor = for how national administrators interact with the ITU-T. But of course we = want your input and feedback, so thanks for sending this along. More comme= nts in line below. From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributi= ng, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warr= anted in response to these comments, and/or whether a separate response may= be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" > Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposi= ng, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" > Cc: "Jamoussi, Bilel" > Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers".= Does that mean the mechanism being referred to here only deals with Tel UR= I? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 whic= h are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restr= icted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regu= lation. The WG cannot make any decisions with regard to this. I expect th= e WG to define "roles" within the number management processes; e.g., admini= strator, telecom carrier, application provider, consumer, etc.; and how tho= se roles could interact with each other. This will be a baseline for what = tools and solutions would be useful to facilitate those interactions. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers wi= th various status, such as assigned, spare and reclaimed numbers will all b= e managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a tel= ephone number. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 i= nternational public telecommunication numbering plan is a politically signi= ficant numbering resource with direct implications on national sovereignty.= ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognize= d "the existing role and sovereignty of ITU Member States with respect to a= llocation and management of their country code numbering resources as enshr= ined in Recommendation ITU-T E.164", and further instructed the ITU Secreta= ry-General and the Directors of three Bureaux (Telecommunication Standardiz= ation, Development, and Radiocommunication) to "take any necessary action t= o ensure the sovereignty of ITU Member States with regard to Recommendation= ITU-T E.164 numbering plans whatever the application in which they are use= d". We are aware of Resolution 133 and will certainly respect it. I would prop= ose adding the following text after the first sentence in the last full par= agraph - "The group acknowledges ITU Plenipotentiary Conference Resolution = 133 which recognizes the existing role and sovereignty of ITU Member States= with respect to allocation and management of their country code numbering = resources as enshrined in Recommendation ITU-T E.164." 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated= in the ITU-T SG2 meeting (28 May - June 2014) and provided some background= on the TELNIC application. A correspondence group under ITU-T SG2 was also= set up in this regard. We would like to know how the work of this new WG w= ould relate to issues related to registering digit strings in the .TEL doma= in and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory over= sight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging ex= isting namespaces as part of proposed solutions. But it's too early to say= anything specific about that. There is nothing in the charter that refere= nces .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "a= s well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & R= egistering telephone Numbers (modern)". But in the Charter, ordering, expos= ing and registering TNs are not mentioned, which seems to be a little bit i= nconsistent. The IETF often has fun with creating WG names. : ) But the charter is whe= re to look for the scope of work. The charter uses the following phrases "= distribution, acquisition and management of TNs", "functions involved in as= sociating information ... with TNs", "associating, acquiring and resolving = TNs", "access data related to TNs", and "mechanisms for resolving informati= on related to TNs". The functions you believe were left out of the charter= will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers= (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry > Steve Donovan > Assigned Area Director: Alissa Cooper > Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authoritie= s. The output of the working group should make distribution, acquisition, a= nd management of TNs simpler for all entities involved. The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs= in an IP environment. The working group will also identify protocol mecha= nisms to support the interactions between the functions defined by the fram= ework. This includes either recommending or defining protocol mechanisms fo= r acquiring, associating and resolving TNs, with a preference for use of ex= isting protocol mechanisms. TNs may either be managed in a hierarchical tre= e, or in a distributed registry. The protocol mechanism for acquiring TNs w= ill provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerat= ions. The working group will take into consideration existing IETF work inc= luding STIR, 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused iden= tifiers. Any such extensions or reuse of MODERN mechanisms are out of scope= for the MODERN working group. Solutions and mechanisms created by the work= ing group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different regul= atory agencies. The working 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 includ= ing any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information as= sociated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ 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_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alissa,

 

 

The internal SDO folks I rely on for le= arning about IETF procedures are unavailable.  Does the “consens= us” reached at the “IESG telechat” that occurred last wee= k constitute the official commissioning of the IETF MODERN working group?

 

The reason I ask is I wanted to formula= te a response to the dozens of e-mails from over the weekend, but don’= ;t want to bother if it is now (and was?) moot.

 

Best regards,

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorm= an@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of Alissa Cooper
Sent: June 29, 2015 4:15 PM
To: McGarry, Tom
Cc: modern@ietf.org
Subject: [Modern] charter edits

 

Tom and all,

 

Thanks for proposing some edits. I have reflected th= em with minor tweaks in the latest version of the charter — http://datatra= cker.ietf.org/doc/charter-ietf-modern/

 

The chartering of MODERN was approved on the IESG te= lechat last week (which I unfortunately missed since I was at the ICANN mee= ting). I will let these edits sit for a day before hitting the approval but= ton.

 

I think the discussion that resulted from the commen= ts relating to ITU-T SG 2 has been a useful airing at this stage in the gam= e and a helpful reminder to everyone to make sure we keep interested partie= s in the loop on this one. Personally I will certainly keep that in mind as the group reaches milestones where f= urther external review might be appropriate. But in any event we have conse= nsus to move forward with chartering.

 

Alissa

 

On Jun 25, 2015, at 3:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:=



 

This effort is intended to create tools and solutio= ns to enable flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers.  Entities can choose to use these tools or not.  = These tools are not for the ITU-T's processes or role, nor for how national= administrators interact with the ITU-T.  But of course we want your i= nput and feedback, so thanks for sending this along.  More comments in line below.  

 

 

From: Alissa Cooper <alissa@c= ooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.o= rg>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Dis= tributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people’s thoughts on whether= any charter edits may be warranted in response to these comments, and/or w= hether a separate response may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:



From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, O= rdering, Distributing, Exposing, & Registering telephone Numbers (moder= n)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential impacts on Recommendatio= n ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is ment= ioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mec= hanism being referred to here only deals with Tel URI? Would there be any i= mpact on Recommendation ITU-E E.164 and E.164.1 which are core recommendati= ons on Telephone Numbers?

There will be no impacts on E.164 and E.= 164.1.


2. Entities participating in the defi= ned mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access da= ta related to TNs. But it is not clear what kind of entities can participat= e in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?

Who participates in numbering processes = within countries is subject to regulation.  The WG cannot make any dec= isions with regard to this.  I expect the WG to define "roles" within the number management processes; e.g., admin= istrator, telecom carrier, application provider, consumer, etc.; = and how those roles could interact with each other.  This will be a&nb= sp;baseline for what tools and solutions would be useful to facilitate those interactions.  


3. Status of Telephone numbers in the= defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the= protocol mechanism for acquiring TNs will provide an enrollment process fo= r the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms define= d by the MODERN working group?

I would expect proposed solutions= to be able to address the status of a telephone number.<= /p>


4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignm= ent and management, for example those established by different regulatory a= gencies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with = direct implications on national sovereignty. ITU Plenipotentiary Conference= Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States wi= th respect to allocation and management of their country code numbering res= ources as enshrined in Recommendation ITU-T E.164", and further instru= cted the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignt= y of ITU Member States with regard to Recommendation ITU-T E.164 numbering = plans whatever the application in which they are used".

We are aware of Resolution 133 and will certainly respect= it.  I would propose adding the following text after the first s= entence in the last full paragraph – "The group acknow= ledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing ro= le and sovereignty of ITU Member States with respect to allocation and mana= gement of their country code numbering resources as enshrined in Recom= mendation ITU-T E.164."  


5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Dire= ctor has also exchanged letters with ICANN on issues related to registering= digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corr= espondence group under ITU-T SG2 was also set up in this regard. We would l= ike to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.=

The WG will not create any new namespace= that would require regulatory oversight, e.g., a new TLD, SLD, etc. &= nbsp;I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say anything sp= ecific about that.  There is nothing in the charter that references .t= el.  


6. Relationship with related existing= or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. D= etailed description of the relationship between this new WG and the above m= entioned other existing or concluded WGs would be appreciated.

I agree.  I would modify = that sentence to add the following at the end - "as well as other = ;relevant industry and standards organizations."


7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing= , & Registering telephone Numbers (modern)". But in the Charter, o= rdering, exposing and registering TNs are not mentioned, which seems to be = a little bit inconsistent.

The IETF often has fun with creating WG = names.  : )  But the charter is where to look for the scope of wo= rk.  The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in = associating information … with TNs", "associating= , acquiring and resolving TNs", "access data related to=  TNs", and "mechanisms for resolving information related to&= nbsp;TNs".  The functions you believe were left out of the charter will be part of one or more of these processe= s.  



Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-wor= k-bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft ch= arter was submitted, and is provided for informational purposes only. Pleas= e send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06= -22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarr= y@neustar.biz>
 Steve Donovan <srdonov= an@usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw= .in>

Mailing list
 Address: modern@ietf.org<= br>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

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 en= vironment. Devices, applications, and network tools increasingly need to ma= nage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for a= ll entities involved.

The working group will define an information management framework for the r= oles 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 recom= mending or defining protocol mechanisms for acquiring, associating and reso= lving TNs, with a preference for use of existing protocol mechanisms. TNs m= ay either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage = TNs. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Maint= aining reliability, real-time application performance, and security and pri= vacy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS an= d 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 ser= vice. There is an expectation that aspects of the architecture and protocol= s defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solu= tions and mechanisms created by the working group will be flexible enough t= o accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf= .org/mailman/listinfo/new-work

 

 

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.o= rg/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_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_-- --_004_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Mon, 29 Jun 2015 21:49:08 GMT"; modification-date="Mon, 29 Jun 2015 21:49:08 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_0c39102daf9b448595a17b16cd48be00PLSWE13M08adsprintcom_-- From nobody Mon Jun 29 15:20: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 BF9451A8AB8 for ; Mon, 29 Jun 2015 15:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 KT54Y2WukLJn for ; Mon, 29 Jun 2015 15:20:47 -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 105E31AC434 for ; Mon, 29 Jun 2015 15:20:47 -0700 (PDT) Received: (qmail 31166 invoked by uid 0); 29 Jun 2015 22:20:46 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 29 Jun 2015 22:20:46 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id mMt51q00Z1MNPNq01Mt8Dl; Mon, 29 Jun 2015 15:53:11 -0600 X-Authority-Analysis: v=2.1 cv=ItWNLtPg c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=tc-25_r96LQA:10 a=IYETQKA4aJkA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=hZG83p_yAAAA:8 a=UqAplN6HAAAA:8 a=yakATiurAAAA:8 a=V9yi7lyFSDbMPMlNOhUA:9 a=fVlo5w6JbQbvzkJV:21 a=5tB9WLe9qAs88bIR:21 a=wPNLvfGTeEIA:10 a=kkUMZHjH4KkA:10 a=JQe_0qb-7LM5u9TBNrIA:9 a=fCAgbImLEWCFtUed:21 a=RDWP7S2myAWYktfu:21 a=hGk5uqHn1-eanP2o: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:CC:To:From:Subject:Date; bh=DTMkLSf0xIXDFVEtSXskSMe+oaPw70nhXEnxhnqQTH4=; b=oWjaYHtjCy2J9Z/JD1awmRJ2a3i3ySphQMk6FmK7IicZxTN5uDFcoO/Ad3oJMiEjZkFXV/qpN2eo4AUC4HdTyEPO7nvqTsR9qxplcU41qdDe9Q5p+Ni4oKNa+ineddPM; Received: from [100.36.26.202] (port=62844 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z9h6W-0006KS-DJ; Mon, 29 Jun 2015 16:00:40 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Mon, 29 Jun 2015 18:00:36 -0400 From: Richard Shockey To: Alissa Cooper , "McGarry, Tom" Message-ID: Thread-Topic: [Modern] charter edits References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518445640_783732" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] charter edits 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, 29 Jun 2015 22:20:56 -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_3518445640_783732 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable This IMHO is a arbitrary move. There is not consensus. From: Modern on behalf of Alissa Cooper Date: Monday, June 29, 2015 at 5:14 PM To: "McGarry, Tom" Cc: "modern@ietf.org" Subject: [Modern] charter edits Tom and all, Thanks for proposing some edits. I have reflected them with minor tweaks in the latest version of the charter =8B http://datatracker.ietf.org/doc/charter-ietf-modern/ The chartering of MODERN was approved on the IESG telechat last week (which I unfortunately missed since I was at the ICANN meeting). I will let these edits sit for a day before hitting the approval button. I think the discussion that resulted from the comments relating to ITU-T SG 2 has been a useful airing at this stage in the game and a helpful reminder to everyone to make sure we keep interested parties in the loop on this one= . Personally I will certainly keep that in mind as the group reaches milestones where further external review might be appropriate. But in any event we have consensus to move forward with chartering. Alissa On Jun 25, 2015, at 3:31 PM, McGarry, Tom wrote: >=20 > This effort is intended to create tools and solutions to enable flexibili= ty in > the process of managing numbers among national administrators, service an= d > application providers, and consumers. Entities can choose to use these t= ools > or not. These tools are not for the ITU-T's processes or role, nor for h= ow > national administrators interact with the ITU-T. But of course we want y= our > input and feedback, so thanks for sending this along. More comments in l= ine > below. =20 >=20 >=20 > From: Alissa Cooper > Date: Thursday, June 25, 2015 7:44 AM > To: Modern List > Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distribu= ting, > Exposing, & Registering telephone Numbers (modern) >=20 > Would appreciate people=B9s thoughts on whether any charter edits may be > warranted in response to these comments, and/or whether a separate respon= se > may be useful for addressing some of the questions below. >=20 > Alissa >=20 > Begin forwarded message: >=20 >> From: "Zhang, Jie" >> Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, >> Exposing, & Registering telephone Numbers (modern) >> Date: June 23, 2015 at 1:56:42 PM GMT-3 >> To: "iesg@ietf.org" >> Cc: "Jamoussi, Bilel" >> Dear Sir/Madam, >>=20 >> Below please find comments from the ITU Telecommunication Standardizatio= n >> Bureau on the proposed IETF working group MODERN. >>=20 >> 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 >> It is stated at the beginning of the Charter that the MODERN working gro= up >> will define a set of Internet-based mechanisms for the purposes of manag= ing >> and resolving telephone numbers (TNs) in an IP environment. And it is >> mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone >> Numbers". Does that mean the mechanism being referred to here only deals= with >> Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.1= 64.1 >> which are core recommendations on Telephone Numbers? > There will be no impacts on E.164 and E.164.1. >>=20 >> 2. Entities participating in the defined mechanisms >> The Charter states that the protocol mechanism for resolving TNs will al= low >> entities such as service providers, devices, and applications to access = data >> related to TNs. But it is not clear what kind of entities can participat= e in >> the mechanisms defined by this MODERN working group. Would it be restric= ted >> to the entities who have been assigned a TN or a block of TNS? > Who participates in numbering processes within countries is subject to > regulation. The WG cannot make any decisions with regard to this. I exp= ect > the WG to define "roles" within the number management processes; e.g., > administrator, telecom carrier, application provider, consumer, etc.; and= how > those roles could interact with each other. This will be a baseline for = what > tools and solutions would be useful to facilitate those interactions. >>=20 >> 3. Status of Telephone numbers in the defined mechanisms >> Several operations related to TNs are mentioned in the Charter, includin= g >> requesting, acquiring, resolving and associating. It is also stated that= the >> protocol mechanism for acquiring TNs will provide an enrollment process = for >> the entities that use and manage TNs. Does that mean Telephone numbers w= ith >> various status, such as assigned, spare and reclaimed numbers will all b= e >> managed in the mechanisms defined by the MODERN working group? > I would expect proposed solutions to be able to address the status of a > telephone number. >>=20 >> 4. Regulatory issues >> The Charter states that Solutions and mechanisms created by the working = group >> will be flexible enough to accommodate different policies for TN assignm= ent >> and management, for example those established by different regulatory >> agencies. We would like to bring your attention to the fact that the E.1= 64 >> international public telecommunication numbering plan is a politically >> significant numbering resource with direct implications on national >> sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, = 2014) >> recognized "the existing role and sovereignty of ITU Member States with >> respect to allocation and management of their country code numbering >> resources as enshrined in Recommendation ITU-T E.164", and further instr= ucted >> the ITU Secretary-General and the Directors of three Bureaux >> (Telecommunication Standardization, Development, and Radiocommunication)= to >> "take any necessary action to ensure the sovereignty of ITU Member State= s >> with regard to Recommendation ITU-T E.164 numbering plans whatever the >> application in which they are used". > We are aware of Resolution 133 and will certainly respect it. I would pr= opose > adding the following text after the first sentence in the last full parag= raph > =AD "The group acknowledges ITU Plenipotentiary Conference Resolution 133 w= hich > recognizes the existing role and sovereignty of ITU Member States with re= spect > to allocation and management of their country code numbering resources as > enshrined in Recommendation ITU-T E.164." >>=20 >> 5. Relationship with .Tel >> DNS-based use of international numbering resources has been discussed in >> ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB >> Director has also exchanged letters with ICANN on issues related to >> registering digit strings in the .TEL domain. A representative from ICAN= N >> participated in the ITU-T SG2 meeting (28 May - June 2014) and provided = some >> background on the TELNIC application. A correspondence group under ITU-T= SG2 >> was also set up in this regard. We would like to know how the work of th= is >> new WG would relate to issues related to registering digit strings in th= e >> .TEL domain and other DNS-based use of telephone numbers. > The WG will not create any new namespace that would require regulatory > oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leverag= ing > existing namespaces as part of proposed solutions. But it's too early to= say > anything specific about that. There is nothing in the charter that refer= ences > .tel. =20 >>=20 >> 6. Relationship with related existing or concluded WGs >> It is stated in the Charter that the working group will take into >> consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS= and >> SCIM. Detailed description of the relationship between this new WG and t= he >> above mentioned other existing or concluded WGs would be appreciated. > I agree. I would modify that sentence to add the following at the end - = "as > well as other relevant industry and standards organizations." >>=20 >> 7. The name of this new WG >> The name of this new WG is "Managing, Ordering, Distributing, Exposing, = & >> Registering telephone Numbers (modern)". But in the Charter, ordering, >> exposing and registering TNs are not mentioned, which seems to be a litt= le >> bit inconsistent. > The IETF often has fun with creating WG names. : ) But the charter is w= here > to look for the scope of work. The charter uses the following phrases > "distribution, acquisition and management of TNs", "functions involved in > associating information =8A with TNs", "associating, acquiring and resolvin= g > TNs", "access data related to TNs", and "mechanisms for resolving informa= tion > related to TNs". The functions you believe were left out of the charter = will > be part of one or more of these processes. >>=20 >>=20 >> Best regards, >>=20 >> Jie Zhang >> Advisor, ITU-T SG2 >> International Telecommunication Union >> Place des Nations >> CH-1211 Geneva , Switzerland >> Tel :+41 22 730 5855 >> jie.zhang@itu.int >> www.itu.int >> www.itu150.org >>=20 >>=20 >> -----Original Message----- >> From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG >> Sent: Friday, June 12, 2015 8:47 PM >> To: new-work@ietf.org >> Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposin= g, & >> Registering telephone Numbers (modern) >>=20 >> A new IETF working group has been proposed in the Applications and Real-= Time >> Area. The IESG has not made any determination yet. The following draft >> charter was submitted, and is provided for informational purposes only. >> Please send your comments to the IESG mailing list (iesg at ietf.org >> ) by 2015-06-22. >>=20 >> Managing, Ordering, Distributing, Exposing, & Registering telephone Numb= ers >> (modern) >> ------------------------------------------------ >> Current Status: Proposed WG >>=20 >> Chairs: >> Tom McGarry >> Steve Donovan >>=20 >> Assigned Area Director: >> Alissa Cooper >>=20 >> Mailing list >> Address: modern@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/modern >> Archive: http://www.ietf.org/mail-archive/web/modern/ >>=20 >> Charter: >>=20 >> 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. Devices, applications, and network tools increasingly need = to >> manage TNs, including requesting and acquiring TN delegations from >> authorities. The output of the working group should make distribution, >> acquisition, and management of TNs simpler for all entities involved. >>=20 >> The working group will define an information management framework for th= e >> 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 mechan= isms >> for acquiring, associating and resolving TNs, with a preference for use = of >> existing protocol mechanisms. TNs may either be managed in a hierarchica= l >> tree, or in a distributed registry. The protocol mechanism for acquiring= TNs >> will provide an enrollment process for the entities that use and manage = TNs. >>=20 >> The protocol mechanism for resolving TNs will allow entities such as ser= vice >> providers, devices, and applications to access data related to TNs. >> Maintaining reliability, real-time application performance, and security= and >> privacy for both the data and the protocol interactions are primary >> considerations. The working group will take into consideration existing = IETF >> work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. >>=20 >> The work of this group will focus on TNs, as defined in RFC3966, and blo= cks >> of TNs, that are used to initiate communication with another user of a >> service. 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 mechani= sms >> are out of scope for the MODERN working group. Solutions and mechanisms >> created by the working group will be flexible enough to accommodate diff= erent >> policies for TN assignment and management, for example those established= by >> different regulatory agencies. >>=20 >> The working group will deliver the following: >>=20 >> - An architecture overview, including high level requirements and >> security/privacy considerations >>=20 >> - A description of the enrollment processes for existing and new TNs >> including any modifications to metadata related to those TNs >>=20 >> - A description of protocol mechanisms for accessing contact information >> associated with enrollments >>=20 >> - A description of mechanisms for resolving information related to TNs >>=20 >> Milestones: >>=20 >> TBD >>=20 >> _______________________________________________ >> new-work mailing list >> new-work@ietf.org >> https://www.ietf.org/mailman/listinfo/new-work >>=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 --B_3518445640_783732 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

This IMHO is a arbitrary move. There is not consensus. 

From: Modern <modern-bounces@ietf.org> on behalf of = Alissa Cooper <alissa@cooperw.in&g= t;
Date: Monday, June 29, 2015 at = 5:14 PM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>
Cc: "mo= dern@ietf.org" <modern@ietf.org&= gt;
Subject: [Modern] charter edit= s

Tom and all,
=

Thanks for proposing some edits. I have reflected them w= ith minor tweaks in the latest version of the charter — http://datatracker.iet= f.org/doc/charter-ietf-modern/

The chartering o= f MODERN was approved on the IESG telechat last week (which I unfortunately = missed since I was at the ICANN meeting). I will let these edits sit for a d= ay before hitting the approval button.

I think the = discussion that resulted from the comments relating to ITU-T SG 2 has been a= useful airing at this stage in the game and a helpful reminder to everyone = to make sure we keep interested parties in the loop on this one. Personally = I will certainly keep that in mind as the group reaches milestones where fur= ther external review might be appropriate. But in any event we have consensu= s to move forward with chartering.

Alissa

=
On Jun 25, 2015, at 3:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:

<= div style=3D"font-family: Calibri, sans-serif; font-size: 14px;">
This effort is intended to create tools and solutions to enable flexibility= in the process of managing numbers among national administrators, service a= nd application providers, and consumers.  Entities can choose to use th= ese tools or not.  These tools are not for the ITU-T's processes or role, nor for how national administrators= interact with the ITU-T.  But of course we want your input and feedbac= k, so thanks for sending this along.  More comments in line below. &nbs= p;

=

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>=
Subject: [Modern] Fwd: [new-work] = WG Review: Managing, Ordering, Distributing, Exposing, & Registering tel= ephone Numbers (modern)

From: "Zhang, Jie" <ji= e.zhang@itu.int>
Subject: <= b>RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &= ; Registering telephone Numbers (modern)
Date: June 23, 2015 at 1:56:42 PM GMT-3
Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>
<= /div>
Dear Sir/Madam,

Below please find comments from the ITU Telecommunication Standardization B= ureau on the proposed IETF working group MODERN.

1. Potential= impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is mentio= ned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism bei= ng referred to here only deals with Tel URI? Would there be any impact on Re= commendation ITU-E E.164 and E.164.1 which are core recommendations on Telep= hone Numbers?
There will be no impacts on= E.164 and E.164.1.

2. Entities = participating in the defined mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow= entities such as service providers, devices, and applications to access dat= a related to TNs. But it is not clear what kind of entities can participate = in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been= assigned a TN or a block of TNS?
Who par= ticipates in numbering processes within countries is subject to regulation. =  The WG cannot make any decisions with regard to this.  I exp= ect the WG to define "roles" within the number management processes; e.= g., administrator, telecom carrier, application provider, consumer, etc.; and how those rol= es could interact with each other.  This will be a baseline f= or what tools and solutions would be useful to facilitate those interactions= .  

3. Status of= Telephone numbers in the defined mechanisms
Several operations related to TNs are mentioned in the Charter, including r= equesting, acquiring, resolving and associating. It is also stated that the = protocol mechanism for acquiring TNs will provide an enrollment process for = the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigne= d, spare and reclaimed numbers will all be managed in the mechanisms defined= by the MODERN working group?
I would expect proposed so= lutions to be able to address the status of a telephone number.
=

4. Regulator= y issues
The Charter states that Solutions and mechanisms created by the working gro= up will be flexible enough to accommodate different policies for TN assignme= nt and management, for example those established by different regulatory age= ncies. We would like to bring your attention to the fact that the E.164 international public telecommuni= cation numbering plan is a politically significant numbering resource with d= irect implications on national sovereignty. ITU Plenipotentiary Conference R= esolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with re= spect to allocation and management of their country code numbering resources= as enshrined in Recommendation ITU-T E.164", and further instructed the ITU= Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radi= ocommunication) to "take any necessary action to ensure the sovereignty of I= TU Member States with regard to Recommendation ITU-T E.164 numbering plans w= hatever the application in which they are used".
We are aware of Resolution 133 and will = certainly respect it.  I would propose adding the following text after the first sentence in the last ful= l paragraph – "The group acknowledges ITU Plenipotent= iary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocat= ion and management of their country code numbering resources as enshrined in=  Recommendation ITU-T E.164." &n= bsp;

5. Relations= hip with .Tel
DNS-based use of international numbering resources has been discussed in IT= U-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Direc= tor has also exchanged letters with ICANN on issues related to registering d= igit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A corre= spondence group under ITU-T SG2 was also set up in this regard. We would lik= e to know how the work of this new WG would relate to issues related to registering digit strings in the = .TEL domain and other DNS-based use of telephone numbers.
=
The WG will not create any new namespace that would require= regulatory oversight, e.g., a new TLD, SLD, etc.  I wouldn't= rule out the WG leveraging existing namespaces as part of proposed sol= utions.  But it's too early to say anything specific about that.  There is nothing in the charter that references= .tel.  

6. Relations= hip with related existing or concluded WGs
It is stated in the Charter that the working group will take into considera= tion existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. De= tailed description of the relationship between this new WG and the above men= tioned other existing or concluded WGs would be appreciated.
I agree.=  I would modify that sentence to add the following at the end - "= as well as other relevant industry and standards organizations."
=
7. The name = of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing, &am= p; Registering telephone Numbers (modern)". But in the Charter, ordering, ex= posing and registering TNs are not mentioned, which seems to be a little bit= inconsistent.
The IETF often has fun wit= h creating WG names.  : )  But the charter is where to look for th= e scope of work.  The charter uses the following phrases "distribution,= acquisition and management of TNs", "functions involved in associating= information … with TNs", "associating, acquiring and = resolving TNs", "access data related to TNs", and "mechanisms for = resolving information related to TNs".  The functions you believe = were left out of the charter will be part of one or more of these processes.=  


Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
jie.zhang@itu.in= t
www.itu.int
www.itu150.org


-----Original Message-----
From: new-work [mailto:new-work-= bounces@ietf.org] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: new-work@ietf.org
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, = & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Tim= e Area. The IESG has not made any determination yet. The following draft cha= rter was submitted, and is provided for informational purposes only. Please = send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-2= 2.

Managing, Ordering, Distributing, Exposing, & Registering telephone Num= bers (modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@= neustar.biz>
 Steve Donovan <srdonovan= @usdonovans.com>

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.i= n>

Mailing list
 Address: modern@ietf.org  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: = http://www.ietf.org/mail-archive/web/modern/

Charter:

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 env= ironment. Devices, applications, and network tools increasingly need to mana= ge TNs, including requesting and acquiring TN delegations from authorities. The output of the working group= should make distribution, acquisition, and management of TNs simpler for al= l entities involved.

The working group will define an information management framework for the r= oles and functions involved in associating information with one or more TNs = in an IP environment.  The working group will also identify protocol me= chanisms to support the interactions between the functions defined by the framework. This includes either recom= mending or defining protocol mechanisms for acquiring, associating and resol= ving TNs, with a preference for use of existing protocol mechanisms. TNs may= either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring T= Ns will provide an enrollment process for the entities that use and manage T= Ns. 

The protocol mechanism for resolving TNs will allow entities such as servic= e providers, devices, and applications to access data related to TNs. Mainta= ining reliability, real-time application performance, and security and priva= cy for both the data and the protocol interactions are primary considerations. The working group will take into = consideration existing IETF work including STIR, 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 serv= ice. 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 reu= se of MODERN mechanisms are out of scope for the MODERN working group. Solut= ions and mechanisms created by the working group will be flexible enough to = accommodate different policies for TN assignment and management, for example those established by differe= nt regulatory agencies.

The working 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 includ= ing any modifications to metadata related to those TNs

- A description of protocol mechanisms for accessing contact information as= sociated with enrollments

- A description of mechanisms for resolving information related to TNs
<= br> Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.o= rg
https://w= ww.ietf.org/mailman/listinfo/new-work

<= /div>


_______________________________________________
Modern mailing list
<= a href=3D"mailto:Modern@ietf.org">Modern@ietf.org
https://www.ietf.org/mailman/listinfo/mode= rn

_______________________________= ________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3518445640_783732-- From nobody Mon Jun 29 15:39: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 0E09F1B29AE for ; Mon, 29 Jun 2015 15:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, GB_I_LETTER=-2, 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 7a-LFHjH0SMz for ; Mon, 29 Jun 2015 15:39:07 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 620FA1AD359 for ; Mon, 29 Jun 2015 15:39:07 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5TMd1Yq029442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2015 00:39:01 +0200 Received: from Timea (adsl-178-38-38-252.adslplus.ch [178.38.38.252]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5TMcx8U003809; Tue, 30 Jun 2015 00:38:59 +0200 From: "Richard Hill" To: "'Richard Shockey'" , "'Alissa Cooper'" , "'McGarry, Tom'" References: In-Reply-To: Date: Tue, 30 Jun 2015 00:39:31 +0200 Message-ID: <012201d0b2bc$784555b0$68d00110$@ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_01D0B2CD.3BCE25B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCyueEpUbGAG3yeShy34TRbZUf2pgAAar5Q Content-Language: fr-ch X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: modern@ietf.org Subject: Re: [Modern] charter edits 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, 29 Jun 2015 22:39:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0123_01D0B2CD.3BCE25B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't know much about IETF procedures, but it seems to me that several of the questions listed in 2.1 of RFC 2418 have not yet been addressed satisfactorily. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: mardi, 30. juin 2015 00:01 To: Alissa Cooper; McGarry, Tom Cc: modern@ietf.org Subject: Re: [Modern] charter edits This IMHO is a arbitrary move. There is not consensus. From: Modern on behalf of Alissa Cooper Date: Monday, June 29, 2015 at 5:14 PM To: "McGarry, Tom" Cc: "modern@ietf.org" Subject: [Modern] charter edits Tom and all, Thanks for proposing some edits. I have reflected them with minor tweaks in the latest version of the charter - http://datatracker.ietf.org/doc/charter-ietf-modern/ The chartering of MODERN was approved on the IESG telechat last week (which I unfortunately missed since I was at the ICANN meeting). I will let these edits sit for a day before hitting the approval button. I think the discussion that resulted from the comments relating to ITU-T SG 2 has been a useful airing at this stage in the game and a helpful reminder to everyone to make sure we keep interested parties in the loop on this one. Personally I will certainly keep that in mind as the group reaches milestones where further external review might be appropriate. But in any event we have consensus to move forward with chartering. Alissa On Jun 25, 2015, at 3:31 PM, McGarry, Tom wrote: This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers. Entities can choose to use these tools or not. These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T. But of course we want your input and feedback, so thanks for sending this along. More comments in line below. From: Alissa Cooper Date: Thursday, June 25, 2015 7:44 AM To: Modern List Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below. Alissa Begin forwarded message: From: "Zhang, Jie" Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Date: June 23, 2015 at 1:56:42 PM GMT-3 To: "iesg@ietf.org" Cc: "Jamoussi, Bilel" Dear Sir/Madam, Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN. 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers? There will be no impacts on E.164 and E.164.1. 2. Entities participating in the defined mechanisms The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS? Who participates in numbering processes within countries is subject to regulation. The WG cannot make any decisions with regard to this. I expect the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other. This will be a baseline for what tools and solutions would be useful to facilitate those interactions. 3. Status of Telephone numbers in the defined mechanisms Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group? I would expect proposed solutions to be able to address the status of a telephone number. 4. Regulatory issues The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used". We are aware of Resolution 133 and will certainly respect it. I would propose adding the following text after the first sentence in the last full paragraph - "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164." 5. Relationship with .Tel DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers. The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc. I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions. But it's too early to say anything specific about that. There is nothing in the charter that references .tel. 6. Relationship with related existing or concluded WGs It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated. I agree. I would modify that sentence to add the following at the end - "as well as other relevant industry and standards organizations." 7. The name of this new WG The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent. The IETF often has fun with creating WG names. : ) But the charter is where to look for the scope of work. The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information . with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs". The functions you believe were left out of the charter will be part of one or more of these processes. Best regards, Jie Zhang Advisor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva , Switzerland Tel :+41 22 730 5855 jie.zhang@itu.int www.itu.int www.itu150.org -----Original Message----- From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 12, 2015 8:47 PM To: new-work@ietf.org Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. 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. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 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, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, 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. 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 for TN assignment and management, for example those established by different regulatory agencies. The working 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 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ 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 ------=_NextPart_000_0123_01D0B2CD.3BCE25B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t know much about IETF procedures, but it seems to me = that several of the questions listed in 2.1 of RFC 2418 have not yet = been addressed satisfactorily. 

 

Best,

Richard

 

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard = Shockey
Sent: mardi, 30. juin 2015 00:01
To: Alissa = Cooper; McGarry, Tom
Cc: modern@ietf.org
Subject: = Re: [Modern] charter edits

 

 

This IMHO is a arbitrary move. There is not = consensus. 

 

From: Modern <modern-bounces@ietf.org> = on behalf of Alissa Cooper <alissa@cooperw.in>
Date: = Monday, June 29, 2015 at 5:14 PM
To: "McGarry, = Tom" <Tom.McGarry@neustar.biz>Cc: "modern@ietf.org" <modern@ietf.org>
Subject: = [Modern] charter edits

 

Tom and all,

 

Thanks for proposing some edits. I have reflected them with minor = tweaks in the latest version of the charter — http://data= tracker.ietf.org/doc/charter-ietf-modern/

=

 

The chartering of MODERN was approved on the IESG telechat last week = (which I unfortunately missed since I was at the ICANN meeting). I will = let these edits sit for a day before hitting the approval = button.

 

I think the discussion that resulted from the comments relating to = ITU-T SG 2 has been a useful airing at this stage in the game and a = helpful reminder to everyone to make sure we keep interested parties in = the loop on this one. Personally I will certainly keep that in mind as = the group reaches milestones where further external review might be = appropriate. But in any event we have consensus to move forward with = chartering.

 

Alissa

 

On Jun 25, 2015, at 3:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> = wrote:



 

This effort is intended to create tools and solutions to enable = flexibility in the process of managing numbers among national = administrators, service and application providers, and consumers. =  Entities can choose to use these tools or not.  These tools = are not for the ITU-T's processes or role, nor for how national = administrators interact with the ITU-T.  But of course we want your = input and feedback, so thanks for sending this along.  More = comments in line below.  

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: = Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: = [Modern] Fwd: [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers = (modern)

 

Would appreciate people’s thoughts on whether any charter edits = may be warranted in response to these comments, and/or whether a = separate response may be useful for addressing some of the questions = below.

 

Alissa

 

Begin forwarded message:



From: "Zhang, Jie" <jie.zhang@itu.int>

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)

Date: June 23, 2015 at 1:56:42 PM GMT-3

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

Dear Sir/Madam,

Below please find comments from the ITU = Telecommunication Standardization Bureau on the proposed IETF working = group MODERN.

1. Potential = impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated = at the beginning of the Charter that 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. And it is = mentioned that TNs are defined in RFC 3966 "The tel URI for = Telephone Numbers". Does that mean the mechanism being referred to = here only deals with Tel URI? Would there be any impact on = Recommendation ITU-E E.164 and E.164.1 which are core recommendations on = Telephone Numbers?

= There will be no impacts on E.164 and E.164.1.


2. Entities participating in = the defined mechanisms
The Charter states that the protocol mechanism = for resolving TNs will allow entities such as service providers, = devices, and applications to access data related to TNs. But it is not = clear what kind of entities can participate in the mechanisms defined by = this MODERN working group. Would it be restricted to the entities who = have been assigned a TN or a block of = TNS?

= Who participates in numbering processes within countries is subject to = regulation.  The WG cannot make any decisions with regard to this. =  I expect the WG to define "roles" within the number = management processes; e.g., administrator, telecom = carrier, application provider, consumer, etc.; and how those = roles could interact with each other.  This will be = a baseline for what tools and solutions would be useful to = facilitate those interactions.  


3. Status of Telephone numbers = in the defined mechanisms
Several operations related to TNs are = mentioned in the Charter, including requesting, acquiring, resolving and = associating. It is also stated that the protocol mechanism for acquiring = TNs will provide an enrollment process for the entities that use and = manage TNs. Does that mean Telephone numbers with various status, such = as assigned, spare and reclaimed numbers will all be managed in the = mechanisms defined by the MODERN working = group?

= I would expect proposed solutions to be able to address the status = of a telephone number.


4. Regulatory issues
The = Charter states that Solutions and mechanisms created by the working = group will be flexible enough to accommodate different policies for TN = assignment and management, for example those established by different = regulatory agencies. We would like to bring your attention to the fact = that the E.164 international public telecommunication numbering plan is = a politically significant numbering resource with direct implications on = national sovereignty. ITU Plenipotentiary Conference Resolution 133 = (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of = ITU Member States with respect to allocation and management of their = country code numbering resources as enshrined in Recommendation ITU-T = E.164", and further instructed the ITU Secretary-General and the = Directors of three Bureaux (Telecommunication Standardization, = Development, and Radiocommunication) to "take any necessary action = to ensure the sovereignty of ITU Member States with regard to = Recommendation ITU-T E.164 numbering plans whatever the application in = which they are = used".

= We are aware of Resolution 133 and will certainly respect it. =  I would propose adding the following text after the first = sentence in the last full paragraph – "The group = acknowledges ITU Plenipotentiary Conference Resolution 133 which = recognizes the existing role and sovereignty of ITU Member States with = respect to allocation and management of their country code numbering = resources as enshrined in Recommendation ITU-T E.164." =  


5. Relationship with = .Tel
DNS-based use of international numbering resources has been = discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 = September 2013. TSB Director has also exchanged letters with ICANN on = issues related to registering digit strings in the .TEL domain. A = representative from ICANN participated in the ITU-T SG2 meeting (28 May = - June 2014) and provided some background on the TELNIC application. A = correspondence group under ITU-T SG2 was also set up in this regard. We = would like to know how the work of this new WG would relate to issues = related to registering digit strings in the .TEL domain and other = DNS-based use of telephone = numbers.

= The WG will not create any new namespace that would require regulatory = oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule = out the WG leveraging existing namespaces as part of proposed = solutions.  But it's too early to say anything specific about that. =  There is nothing in the charter that references .tel. =  


6. Relationship with related = existing or concluded WGs
It is stated in the Charter that the = working group will take into consideration existing IETF work including = STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the = relationship between this new WG and the above mentioned other existing = or concluded WGs would be = appreciated.

= I agree.  I would modify that sentence to add the = following at the end - "as well as = other relevant industry and standards = organizations."


7. The name of this new = WG
The name of this new WG is "Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers (modern)". But in the = Charter, ordering, exposing and registering TNs are not mentioned, which = seems to be a little bit = inconsistent.

= The IETF often has fun with creating WG names.  : )  But the = charter is where to look for the scope of work.  The charter uses = the following phrases "distribution, acquisition and management = of TNs", "functions involved in associating = information … with TNs", "associating, = acquiring and resolving TNs", "access data related = to TNs", and "mechanisms for resolving information = related to TNs".  The functions you believe were left out = of the charter will be part of one or more of these processes. =  



Best regards,

Jie Zhang
Advisor, ITU-T = SG2
International Telecommunication Union
Place des = Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 = 5855
jie.zhang@itu.int
www.itu.int
www.itu150.org


-----Origina= l Message-----
From: new-work [mailto:new-work-bounces@ietf.or= g] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 = PM
To: new-work@ietf.org
Subject: = [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & = Registering telephone Numbers (modern)

A new IETF working group = has been proposed in the Applications and Real-Time Area. The IESG has = not made any determination yet. The following draft charter was = submitted, and is provided for informational purposes only. Please send = your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.

Managing, = Ordering, Distributing, Exposing, & Registering telephone Numbers = (modern)
------------------------------------------------
Current = Status: Proposed WG

Chairs:
 Tom McGarry <tom.mcgarry@neustar.biz> Steve Donovan <srdonovan@usdonovans.com>=

Assigned Area Director:
 Alissa Cooper <alissa@cooperw.in>

Mailin= g list
 Address: modern@ietf.org
 To = Subscribe: https://www.ietf.or= g/mailman/listinfo/modern
 Archive: http://www.ietf.org= /mail-archive/web/modern/

Charter:

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. = Devices, applications, and network tools increasingly need to manage = TNs, including requesting and acquiring TN delegations from authorities. = The output of the working group should make distribution, acquisition, = and management of TNs simpler for all entities involved.

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. TNs may either be = managed in a hierarchical tree, or in a distributed registry. The = protocol mechanism for acquiring TNs will provide an enrollment process = for the entities that use and manage TNs. 

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, and security = and privacy for both the data and the protocol interactions are primary = considerations. The working group will take into consideration existing = IETF work including STIR, 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. 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 for TN assignment and management, for = example those established by different regulatory agencies.

The = working 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

Milestones:

TBD

________________________________= _______________
new-work mailing list
new-work@ietf.org
https://www.ietf.= org/mailman/listinfo/new-work

 

 

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

 

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

------=_NextPart_000_0123_01D0B2CD.3BCE25B0-- From nobody Mon Jun 29 16:11: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 EAC181B2F2A for ; Mon, 29 Jun 2015 16:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-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 mTCuCaTxv-Gm for ; Mon, 29 Jun 2015 16:11:50 -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 AEB771B2EE5 for ; Mon, 29 Jun 2015 16:11:50 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5TNBlRd099720 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Jun 2015 18:11:47 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5591D0B2.7080008@nostrum.com> Date: Mon, 29 Jun 2015 18:11:46 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Shockey , Alissa Cooper , "McGarry, Tom" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] charter edits 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, 29 Jun 2015 23:11:52 -0000 On 6/29/15 17:00, Richard Shockey wrote: > This IMHO is a arbitrary move. There is not consensus. Consensus has nothing to do with it. You're confusing working group formation with the technical content of documents. Documents follow the standard of "rough consensus". Working group formation has a rather different standard, based on whether there is a large enough group of qualified people willing to engage in the work. While this standard may have informally existed prior to the formation of XMPP, the precedent cemented its place in IETF operation at that time: the IESG stood behind a general statement that working group formation does not take into account the existence or nature of opposition to the work moving forward. In fact, the XMPP BOF chairs quite pointedly refused to even call the question of opposition -- despite clear calls to do so -- under direct orders of their sponsoring AD. This precedent came into play again with the chartering of the CODEC working group similarly relying on the presence of willing participants, notwithstanding the volume and vehemence of objections from those who would prefer the work not happen. The ultimate decision here resides in the hands of the IESG under the guidance of the sponsoring AD. This is done by evaluating the chance of working group success, not by measuring consensus. If you had wanted to stop this train, you would have had to convince the IESG that success would be unlikely. But I think we're watching the caboose of that train receding rapidly into the distance, making the discussion somewhat moot at this point. /a From nobody Mon Jun 29 18:19: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 152121A212D for ; Mon, 29 Jun 2015 18:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0MLjIZqfPD9J for ; Mon, 29 Jun 2015 18:19:14 -0700 (PDT) Received: from smtp109.ord1c.emailsrvr.com (smtp109.ord1c.emailsrvr.com [108.166.43.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A5F1A1A1E for ; Mon, 29 Jun 2015 18:19:14 -0700 (PDT) Received: from smtp6.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 43C4980170; Mon, 29 Jun 2015 21:19:13 -0400 (EDT) Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BE2388011C; Mon, 29 Jun 2015 21:19:12 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.0.0.63] (c-71-198-88-125.hsd1.ca.comcast.net [71.198.88.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 30 Jun 2015 01:19:13 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 29 Jun 2015 18:19:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 01:19:17 -0000 I think private network case is already happening. There are more and = more PBX that integrate with cloud providers such as Tropo or Twillio to = get phone numbers using a simple API. I'm very happy to see modern is = charted as I hope it will define a standardized API for this. The fact = that right now each PBX has to code to each different non-standard API = is not optimal for anyone. That applications are doing this makes a = pretty compelling case that it is both possible and a desireable thing = to standardize this API. =46rom Cisco point of view, the idea that Tropo can hand out numbers to = a hot dog cart is even more exciting to Cisco than handing them out to = large enterprises but both are exciting. Getting them to large = enterprises reduces cost, improves user experience with easy number = plans and more. Getting them to a hot dog cart enables whole new classes = of innovation and applications on the internet. The way this is = happening today does not change the responsibilities of the carrier that = the regulators care about but it shows how the tools modern is = developing are somewhat separated from the policy in various countries. = Tropo offers numbers in many countries with different regulation using = the same API.=20 Cullen > On Jun 28, 2015, at 9:06 PM, DRAGE, Keith (Keith) = wrote: >=20 > I'm struggling with this. > =20 > Maybe the public network use case can exist that tells a provider that = the number has been assigned, but I cannot envisage the private network = use case as being possible without also transferring attributes, e.g. = class of service, how to route to that number, etc, that are associated = with that number, and under which that number is used. It therefore = becomes something much more in the network management sphere than a = number assignment problem. And network management is not something that = is defined in any of the charters I have seen. > =20 > And if it is not a network management protocol, what is the = interaction of such a new assignment protocol with any network = management protocol that may also be assigning the numbers. along with = the other attributes of the so created users. > =20 > =20 > regards > =20 > Keith > =20 > P.S. As for "and it is a real problem that his customers would like to = see solved", I do not remember Cullen actually saying that, and none of = the other enterprise vendors seem to have weighed in on this. >=20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger > Sent: 27 June 2015 00:54 > To: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > On the one hand, neither MGCP nor SIP do number assignments for = phones. It is irrelevant for MGCP, because the soft switch handles the = numbers. On the SIP side, phone provisioning is the purview of the = SIPForum device configuration specification. >=20 > On the other hand, Cullen=92s use case of a large enterprise doing its = own allocations of numbers across multiple campuses, and as such down to = the phone, was compelling to me. I do not think it has regulatory = issues, and it is a real problem that his customers would like to see = solved. >=20 > Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of = other vendors and large enterprises would be interested. Any comments = from those folks? >=20 >> On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] = wrote: >>=20 >> =93One would be an enterprise IP phone that has just been deployed = and wants to acquire a new number from an IP PBX.=94 There are two = existing protocols which spring to mind which solve this problem; MGCP = and SIP. I=92m sure others can point to other similar protocols as well = (e.g., NCS). And I would argue the enterprise IP phone doesn=92t get a = new number, the IP PBX does. The phone merely gets associated with the = number provisioned in the IP PBX in order to originate or terminate = calls through the IP PBX. >> =20 >> I wasn=92t able to attend the MODERN BoF so I=92m not familiar with = the many use cases. In your example of the VoIP service provider I have = questions. Has it been determined that there are no suitable existing = number provisioning or number management protocols? ESPP and TERQ = spring to mind as examples of protocols which have been previously = developed by the IETF for such purposes and I=92m sure there are other = examples as well. >> =20 >> And is a special protocol required for this example? Numerous = peering relationships are managed using spreadsheets in e-mail. It may = be manual, inelegant and prone to error, but it certainly is cheap and = is often used. Have there been VoIP providers that have claimed they = are disadvantaged because they don=92t have a special protocol for = provisioning subtended number blocks with their carrier? >> =20 >> Best regards, >> =20 >> =20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> > [snip] >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Mon Jun 29 18:56: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 D5F561A9131 for ; Mon, 29 Jun 2015 18:56:12 -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 W3EtYGdPbeQy for ; Mon, 29 Jun 2015 18:56:11 -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 9F4D91A9120 for ; Mon, 29 Jun 2015 18:56:11 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5U1uAHo014794 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 29 Jun 2015 20:56:11 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5591F73A.90301@nostrum.com> Date: Mon, 29 Jun 2015 20:56:10 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: modern@ietf.org References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> In-Reply-To: <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 01:56:13 -0000 On 6/29/15 20:19, Cullen Jennings wrote: > I think private network case is already happening. There are more and more PBX that integrate with cloud providers such as Tropo or Twillio to get phone numbers using a simple API. And, really, ever since we ruled this out of scope for MARTINI, it's been a pretty big gap in SIP PBX deployments. /a From nobody Mon Jun 29 19:01: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 1C67C1AC44D for ; Mon, 29 Jun 2015 19:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTjX91jPziXV for ; Mon, 29 Jun 2015 19:01:06 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772841ACE8B for ; Mon, 29 Jun 2015 19:01:03 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id e58f1955.0.946767.00-2357.2662523.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 30 Jun 2015 02:01:03 +0000 (UTC) X-MXL-Hash: 5591f85f07fc2d56-79ada50fd59ec9e559600cf3107bb9cbe567d9db Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5U212aO032164; Mon, 29 Jun 2015 22:01:02 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5U20oAO032006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jun 2015 22:00:59 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 02:00:36 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Mon, 29 Jun 2015 22:00:35 -0400 From: "DOLLY, MARTIN C" To: Adam Roach Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++Low= Date: Tue, 30 Jun 2015 02:00:35 +0000 Message-ID: <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>,<5591F73A.90301@nostrum.com> In-Reply-To: <5591F73A.90301@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=PexIcFdd c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=BLceEmwcHowA:10 a=XAFQembCKUMA:10 a=Z80J] X-AnalysisOut: [lwQ0AAAA:8 a=48vgC7mUAAAA:8 a=DiVKRRC_EQAFk7bzQXYA:9 a=Cju] X-AnalysisOut: [IK1q_8ugA:10 a=rKrVYePj7rwA:10 a=zACSEiOZvrUXtpoy:21 a=IBw] X-AnalysisOut: [hZpczyM6062Bk:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 02:01:10 -0000 Please explain the number assignment process=20 Sent from my iPhone > On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >=20 >> On 6/29/15 20:19, Cullen Jennings wrote: >> I think private network case is already happening. There are more and mo= re PBX that integrate with cloud providers such as Tropo or Twillio to get = phone numbers using a simple API. >=20 > And, really, ever since we ruled this out of scope for MARTINI, it's been= a pretty big gap in SIP PBX deployments. >=20 > /a >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Mon Jun 29 19:16:23 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 1B0A51B2F27 for ; Mon, 29 Jun 2015 19:16:21 -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 KLC6loDJmNLF for ; Mon, 29 Jun 2015 19:16:19 -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 93EA21B2F25 for ; Mon, 29 Jun 2015 19:16:19 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5U2GGQj016657 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Jun 2015 21:16:16 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5591FBEF.2000903@nostrum.com> Date: Mon, 29 Jun 2015 21:16:15 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> In-Reply-To: <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 02:16:21 -0000 In this context, there isn't one. MARTINI was predicated on a continuation of having VISPs do excruciatingly manual things like emailing -- or in some cases faxing -- spreadsheets to their customers detailing number ranges. I think I still have the one I got from our VISP back in the Estacado days when I was running our PBX. I can dig it up and forward it to you if you really don't know how number assignment works at that level. Basically, it's a lot of human reading and human typing. If you're lucky, you don't have to get a fax machine involved, so you can at least copy and paste. But emailing or faxing spreadsheets around is a brutally primitive and error-prone way to get this kind of thing done. I'm a little surprised it took this long for anyone to make a serious run at some standardized form of automation. /a On 6/29/15 21:00, DOLLY, MARTIN C wrote: > Please explain the number assignment process > > Sent from my iPhone > >> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >> >>> On 6/29/15 20:19, Cullen Jennings wrote: >>> I think private network case is already happening. There are more and more PBX that integrate with cloud providers such as Tropo or Twillio to get phone numbers using a simple API. >> And, really, ever since we ruled this out of scope for MARTINI, it's been a pretty big gap in SIP PBX deployments. >> >> /a >> >> _______________________________________________ >> 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 Jun 29 19:25: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 A50731B2F3C for ; Mon, 29 Jun 2015 19:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 e5r-RI4cFpze for ; Mon, 29 Jun 2015 19:24:55 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031411B2F3F for ; Mon, 29 Jun 2015 19:24:45 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id dedf1955.0.1770524.00-2098.4982959.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jun 2015 02:24:46 +0000 (UTC) X-MXL-Hash: 5591fdee624441a1-b086828a7c4b19d360f6a74f915ececcffaa7f49 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5U2OjM0011354; Mon, 29 Jun 2015 22:24:45 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5U2OZOR011322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jun 2015 22:24:38 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 02:24:14 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0224.002; Mon, 29 Jun 2015 22:24:13 -0400 From: "DOLLY, MARTIN C" To: Adam Roach Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAAEdvgP//vytr Date: Tue, 30 Jun 2015 02:24:13 +0000 Message-ID: <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>,<5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> In-Reply-To: <5591FBEF.2000903@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OIKQK1mB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=BLceEmwcHowA:10 a=XAFQembCKUMA:10 a=Z80J] X-AnalysisOut: [lwQ0AAAA:8 a=48vgC7mUAAAA:8 a=0_N95Tgo548r25Amk34A:9 a=Cju] X-AnalysisOut: [IK1q_8ugA:10 a=F_lBRs964Crp66BZ:21 a=pDoWwDX2HepHc5WI:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 02:25:06 -0000 How is that applicable? Scope question? Sent from my iPhone > On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: >=20 > In this context, there isn't one. >=20 > MARTINI was predicated on a continuation of having VISPs do excruciatingl= y manual things like emailing -- or in some cases faxing -- spreadsheets t= o their customers detailing number ranges. I think I still have the one I g= ot from our VISP back in the Estacado days when I was running our PBX. I ca= n dig it up and forward it to you if you really don't know how number assig= nment works at that level. Basically, it's a lot of human reading and human= typing. If you're lucky, you don't have to get a fax machine involved, so = you can at least copy and paste. >=20 > But emailing or faxing spreadsheets around is a brutally primitive and er= ror-prone way to get this kind of thing done. I'm a little surprised it too= k this long for anyone to make a serious run at some standardized form of a= utomation. >=20 > /a >=20 >> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >> Please explain the number assignment process >>=20 >> Sent from my iPhone >>=20 >>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >>>>=20 >>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>> I think private network case is already happening. There are more and = more PBX that integrate with cloud providers such as Tropo or Twillio to ge= t phone numbers using a simple API. >>> And, really, ever since we ruled this out of scope for MARTINI, it's be= en a pretty big gap in SIP PBX deployments. >>>=20 >>> /a >>>=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 From nobody Mon Jun 29 20:27:35 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 9EEF81B3009 for ; Mon, 29 Jun 2015 20:27:33 -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 jQQ3R4ewoRp8 for ; Mon, 29 Jun 2015 20:27:32 -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 EBCD11B3008 for ; Mon, 29 Jun 2015 20:27:31 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5U3RS97023040 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Jun 2015 22:27:29 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55920CA0.1070104@nostrum.com> Date: Mon, 29 Jun 2015 22:27:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> In-Reply-To: <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 03:27:33 -0000 We discussed this exact use case in Dallas. From Jon's presentation: https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-29%2022.12.37.png?dl=0 It's also described in the charter. In fact, it's really the main thrust of the work: the charter repeatedly talks about acquiring, managing, and resolving TNs. This is the "acquring" part. So now, as I'm reflecting on it, I'm a little confused about what *you* think MODERN will be doing. Perhaps whatever you're worried about isn't actually happening. /a On 6/29/15 21:24, DOLLY, MARTIN C wrote: > How is that applicable? Scope question? > > Sent from my iPhone > >> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: >> >> In this context, there isn't one. >> >> MARTINI was predicated on a continuation of having VISPs do excruciatingly manual things like emailing -- or in some cases faxing -- spreadsheets to their customers detailing number ranges. I think I still have the one I got from our VISP back in the Estacado days when I was running our PBX. I can dig it up and forward it to you if you really don't know how number assignment works at that level. Basically, it's a lot of human reading and human typing. If you're lucky, you don't have to get a fax machine involved, so you can at least copy and paste. >> >> But emailing or faxing spreadsheets around is a brutally primitive and error-prone way to get this kind of thing done. I'm a little surprised it took this long for anyone to make a serious run at some standardized form of automation. >> >> /a >> >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>> Please explain the number assignment process >>> >>> Sent from my iPhone >>> >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >>>>> >>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>> I think private network case is already happening. There are more and more PBX that integrate with cloud providers such as Tropo or Twillio to get phone numbers using a simple API. >>>> And, really, ever since we ruled this out of scope for MARTINI, it's been a pretty big gap in SIP PBX deployments. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> 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 Jun 29 20:39: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 B188F1B301B for ; Mon, 29 Jun 2015 20:39:04 -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 vqoOAtW6Hs_Y for ; Mon, 29 Jun 2015 20:39:03 -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 271311B301A for ; Mon, 29 Jun 2015 20:39:03 -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 t5U3cnTF024066 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Jun 2015 22:39:00 -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: "Adam Roach" Date: Mon, 29 Jun 2015 22:38:49 -0500 Message-ID: <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> In-Reply-To: <55920CA0.1070104@nostrum.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "modern@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 03:39:04 -0000 I have to wonder if everyone means the same thing when they say = "managing". I.e. managing how you get TNs to a lot of = telephone-like-clients vs managing numbering plans, assignment policy, = etc. On 29 Jun 2015, at 22:27, Adam Roach wrote: > We discussed this exact use case in Dallas. From Jon's presentation: > > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-29%2022.= 12.37.png?dl=3D0 > > It's also described in the charter. In fact, it's really the main = > thrust of the work: the charter repeatedly talks about acquiring, = > managing, and resolving TNs. This is the "acquring" part. > > So now, as I'm reflecting on it, I'm a little confused about what = > *you* think MODERN will be doing. Perhaps whatever you're worried = > about isn't actually happening. > > /a > > > On 6/29/15 21:24, DOLLY, MARTIN C wrote: >> How is that applicable? Scope question? >> >> Sent from my iPhone >> >>> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: >>> >>> In this context, there isn't one. >>> >>> MARTINI was predicated on a continuation of having VISPs do = >>> excruciatingly manual things like emailing -- or in some cases = >>> faxing -- spreadsheets to their customers detailing number ranges. = >>> I think I still have the one I got from our VISP back in the = >>> Estacado days when I was running our PBX. I can dig it up and = >>> forward it to you if you really don't know how number assignment = >>> works at that level. Basically, it's a lot of human reading and = >>> human typing. If you're lucky, you don't have to get a fax machine = >>> involved, so you can at least copy and paste. >>> >>> But emailing or faxing spreadsheets around is a brutally primitive = >>> and error-prone way to get this kind of thing done. I'm a little = >>> surprised it took this long for anyone to make a serious run at some = >>> standardized form of automation. >>> >>> /a >>> >>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>>> Please explain the number assignment process >>>> >>>> Sent from my iPhone >>>> >>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >>>>>> >>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>>> I think private network case is already happening. There are more = >>>>>> and more PBX that integrate with cloud providers such as Tropo or = >>>>>> Twillio to get phone numbers using a simple API. >>>>> And, really, ever since we ruled this out of scope for MARTINI, = >>>>> it's been a pretty big gap in SIP PBX deployments. >>>>> >>>>> /a >>>>> >>>>> _______________________________________________ >>>>> 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 Jun 29 21:10:30 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 D0E791B3056 for ; Mon, 29 Jun 2015 21:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rORI51J-h2wZ for ; Mon, 29 Jun 2015 21:10:26 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 AF57E1B302E for ; Mon, 29 Jun 2015 21:10:25 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5U4AJw4021290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2015 06:10:19 +0200 Received: from RHillNew (adsl-178-38-38-252.adslplus.ch [178.38.38.252]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5U4AIqi021700; Tue, 30 Jun 2015 06:10:18 +0200 From: "Richard Hill" To: "'Ben Campbell'" , "'Adam Roach'" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> In-Reply-To: <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> Date: Tue, 30 Jun 2015 06:10:21 +0200 Message-ID: <001901d0b2ea$af764700$0e62d500$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCy5lOvdnWuwQknS2GtXcE9aJ0GlwAA1MpA Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: modern@ietf.org, "'DOLLY, MARTIN C'" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 04:10:29 -0000 Dear Ben, Thank you for this very constructive comment. I think that you may well have identified a key concern. In my experience, when people refer to "managing" something (e.g. numbers or people) they usually refer to the entire business process, including rules for how to do it, and not just to the mechanical implementation of the rules. The first paragraph of the charter says: "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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved." The rest of the charter focuses on mechanics, but that opening paragraph seems to me to imply that the scope of the group's work could be broader than just mechanical implementation of existing rules. If the idea is to "manage how you get telephone numbers", as opposed to "managing telephone numbers", then I would suggest that the first paragraph should read: "The MODERN working group will define a set of Internet-based mechanisms for the purposes of acquiring and resolving telephone numbers (TNs) in an IP environment. Devices, applications, and network tools increasingly need to request and acquire TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved." And the title of the group might be changed to "Requesting, Acquiring, Distributing, Exposing, and Registering telephone numbers in an IP environment". Best, Richard > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Tuesday, June 30, 2015 05:39 > To: Adam Roach > Cc: modern@ietf.org; DOLLY, MARTIN C > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > I have to wonder if everyone means the same thing when they say > "managing". I.e. managing how you get TNs to a lot of telephone-like- > clients vs managing numbering plans, assignment policy, etc. > > > On 29 Jun 2015, at 22:27, Adam Roach wrote: > > > We discussed this exact use case in Dallas. From Jon's presentation: > > > > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06- > 29%2022 > > .12.37.png?dl=0 > > > > It's also described in the charter. In fact, it's really the main > > thrust of the work: the charter repeatedly talks about acquiring, > > managing, and resolving TNs. This is the "acquring" part. > > > > So now, as I'm reflecting on it, I'm a little confused about what > > *you* think MODERN will be doing. Perhaps whatever you're worried > > about isn't actually happening. > > > > /a > > > > > > On 6/29/15 21:24, DOLLY, MARTIN C wrote: > >> How is that applicable? Scope question? > >> > >> Sent from my iPhone > >> > >>> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: > >>> > >>> In this context, there isn't one. > >>> > >>> MARTINI was predicated on a continuation of having VISPs do > >>> excruciatingly manual things like emailing -- or in some cases > >>> faxing -- spreadsheets to their customers detailing number ranges. > >>> I think I still have the one I got from our VISP back in the > >>> Estacado days when I was running our PBX. I can dig it up and > >>> forward it to you if you really don't know how number assignment > >>> works at that level. Basically, it's a lot of human reading and > >>> human typing. If you're lucky, you don't have to get a fax machine > >>> involved, so you can at least copy and paste. > >>> > >>> But emailing or faxing spreadsheets around is a brutally primitive > >>> and error-prone way to get this kind of thing done. I'm a little > >>> surprised it took this long for anyone to make a serious run at > some > >>> standardized form of automation. > >>> > >>> /a > >>> > >>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > >>>> Please explain the number assignment process > >>>> > >>>> Sent from my iPhone > >>>> > >>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach > wrote: > >>>>>> > >>>>>> On 6/29/15 20:19, Cullen Jennings wrote: > >>>>>> I think private network case is already happening. There are > more > >>>>>> and more PBX that integrate with cloud providers such as Tropo > or > >>>>>> Twillio to get phone numbers using a simple API. > >>>>> And, really, ever since we ruled this out of scope for MARTINI, > >>>>> it's been a pretty big gap in SIP PBX deployments. > >>>>> > >>>>> /a > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Jun 29 21:58: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 39B771B30DF for ; Mon, 29 Jun 2015 21:58:03 -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 USaCWixg0cQW for ; Mon, 29 Jun 2015 21:58:01 -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 1CC671B30D1 for ; Mon, 29 Jun 2015 21:58:01 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t5U4toBg001548; Tue, 30 Jun 2015 00:57:56 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vbe5r8c7n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Jun 2015 00:57:55 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 30 Jun 2015 00:57:55 -0400 From: "Peterson, Jon" To: Richard Hill , "'Ben Campbell'" , "'Adam Roach'" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZvhRCs8bDCkmS/uKUejePp53DI3GAgAFjg4CAAApVAIAAATyAgAAEYYCAAAI6gIAAEawAgAADLICAAAjPgP//l+qA Date: Tue, 30 Jun 2015 04:57:54 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> <001901d0b2ea$af764700$0e62d500$@ch> In-Reply-To: <001901d0b2ea$af764700$0e62d500$@ch> 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.52] 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-06-30_01:2015-06-29,2015-06-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506300089 Archived-At: Cc: "modern@ietf.org" , "'DOLLY, MARTIN C'" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 04:58:03 -0000 I'd rather not get wrapped around a semantic axle of what "managing telephone numbers" versus "manage how you get telephone numbers" means. Acquisition largely is about managing how you get numbers. Various provisioning exercises may follow after acquisition, and I think those operations fall within the realm we typically call management. I think we have a management area here in the IETF, it is not concerned with the business process, say. And well, at the risk of being blithe, I think MODERN as an backronym befits the work better than RADER or something. Jon Peterson Neustar, Inc. On 6/29/15, 9:10 PM, "Richard Hill" wrote: >Dear Ben, > >Thank you for this very constructive comment. I think that you may well >have >identified a key concern. In my experience, when people refer to >"managing" >something (e.g. numbers or people) they usually refer to the entire >business >process, including rules for how to do it, and not just to the mechanical >implementation of the rules. > >The first paragraph of the charter says: > >"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. Devices, applications, and network tools increasingly need >to >manage TNs, including requesting and acquiring TN delegations from >authorities. The output of the working group should make distribution, >acquisition, and management of TNs simpler for all entities involved." > >The rest of the charter focuses on mechanics, but that opening paragraph >seems to me to imply that the scope of the group's work could be broader >than just mechanical implementation of existing rules. > >If the idea is to "manage how you get telephone numbers", as opposed to >"managing telephone numbers", then I would suggest that the first >paragraph >should read: > >"The MODERN working group will define a set of Internet-based mechanisms >for >the purposes of acquiring and resolving telephone numbers (TNs) in an IP >environment. Devices, applications, and network tools increasingly need >to >request and acquire TN delegations from authorities. The output of the >working group should make distribution, acquisition, and management of TNs >simpler for all entities involved." > >And the title of the group might be changed to "Requesting, Acquiring, >Distributing, Exposing, and Registering telephone numbers in an IP >environment". > >Best, >Richard > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Tuesday, June 30, 2015 05:39 >> To: Adam Roach >> Cc: modern@ietf.org; DOLLY, MARTIN C >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >> Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >> I have to wonder if everyone means the same thing when they say >> "managing". I.e. managing how you get TNs to a lot of telephone-like- >> clients vs managing numbering plans, assignment policy, etc. >>=20 >>=20 >> On 29 Jun 2015, at 22:27, Adam Roach wrote: >>=20 >> > We discussed this exact use case in Dallas. From Jon's presentation: >> > >> > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06- >> 29%2022 >> > .12.37.png?dl=3D0 >> > >> > It's also described in the charter. In fact, it's really the main >> > thrust of the work: the charter repeatedly talks about acquiring, >> > managing, and resolving TNs. This is the "acquring" part. >> > >> > So now, as I'm reflecting on it, I'm a little confused about what >> > *you* think MODERN will be doing. Perhaps whatever you're worried >> > about isn't actually happening. >> > >> > /a >> > >> > >> > On 6/29/15 21:24, DOLLY, MARTIN C wrote: >> >> How is that applicable? Scope question? >> >> >> >> Sent from my iPhone >> >> >> >>> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: >> >>> >> >>> In this context, there isn't one. >> >>> >> >>> MARTINI was predicated on a continuation of having VISPs do >> >>> excruciatingly manual things like emailing -- or in some cases >> >>> faxing -- spreadsheets to their customers detailing number ranges. >> >>> I think I still have the one I got from our VISP back in the >> >>> Estacado days when I was running our PBX. I can dig it up and >> >>> forward it to you if you really don't know how number assignment >> >>> works at that level. Basically, it's a lot of human reading and >> >>> human typing. If you're lucky, you don't have to get a fax machine >> >>> involved, so you can at least copy and paste. >> >>> >> >>> But emailing or faxing spreadsheets around is a brutally primitive >> >>> and error-prone way to get this kind of thing done. I'm a little >> >>> surprised it took this long for anyone to make a serious run at >> some >> >>> standardized form of automation. >> >>> >> >>> /a >> >>> >> >>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >> >>>> Please explain the number assignment process >> >>>> >> >>>> Sent from my iPhone >> >>>> >> >>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach >> wrote: >> >>>>>> >> >>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >> >>>>>> I think private network case is already happening. There are >> more >> >>>>>> and more PBX that integrate with cloud providers such as Tropo >> or >> >>>>>> Twillio to get phone numbers using a simple API. >> >>>>> And, really, ever since we ruled this out of scope for MARTINI, >> >>>>> it's been a pretty big gap in SIP PBX deployments. >> >>>>> >> >>>>> /a >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jun 30 03:52:56 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 1E2E71A87CA for ; Tue, 30 Jun 2015 03:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOaB97TfEJcJ for ; Tue, 30 Jun 2015 03:52:53 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2593F1A87CE for ; Tue, 30 Jun 2015 03:52:52 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 10572955.0.1106919.00-2269.3111350.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 30 Jun 2015 10:52:52 +0000 (UTC) X-MXL-Hash: 5592750433c0e91f-98e9e5174055a2d8f7a5aa36b8d30e313537191b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UAqnH2002071; Tue, 30 Jun 2015 06:52:49 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UAqgB2002018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2015 06:52:43 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 10:52:24 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 06:52:24 -0400 From: "DOLLY, MARTIN C" To: Adam Roach Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAAEdvgP//vytrgABUugCAADlCDg== Date: Tue, 30 Jun 2015 10:52:24 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>,<5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com>, <55920CA0.1070104@nostrum.com> In-Reply-To: <55920CA0.1070104@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=PexIcFdd c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=BLceEmwcHowA:10 a=XAFQembCKUMA:10 a=Z80J] X-AnalysisOut: [lwQ0AAAA:8 a=Q8-2WILDAAAA:20 a=48vgC7mUAAAA:8 a=VAMm1qzQAA] X-AnalysisOut: [AA:8 a=cwCiLfARjCMb8tmdRx4A:9 a=CjuIK1q_8ugA:10 a=E1T03fPy] X-AnalysisOut: [OttjDMsz:21 a=2Z2Mr4Vo_dTXKo5E:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 10:52:55 -0000 Not exactly Sent from my iPhone > On Jun 29, 2015, at 11:27 PM, Adam Roach wrote: >=20 > We discussed this exact use case in Dallas. From Jon's presentation: >=20 > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-29%2022.12= .37.png?dl=3D0 >=20 > It's also described in the charter. In fact, it's really the main thrust = of the work: the charter repeatedly talks about acquiring, managing, and re= solving TNs. This is the "acquring" part. >=20 > So now, as I'm reflecting on it, I'm a little confused about what *you* t= hink MODERN will be doing. Perhaps whatever you're worried about isn't actu= ally happening. >=20 > /a >=20 >=20 >> On 6/29/15 21:24, DOLLY, MARTIN C wrote: >> How is that applicable? Scope question? >>=20 >> Sent from my iPhone >>=20 >>> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: >>>=20 >>> In this context, there isn't one. >>>=20 >>> MARTINI was predicated on a continuation of having VISPs do excruciatin= gly manual things like emailing -- or in some cases faxing -- spreadsheets= to their customers detailing number ranges. I think I still have the one I= got from our VISP back in the Estacado days when I was running our PBX. I = can dig it up and forward it to you if you really don't know how number ass= ignment works at that level. Basically, it's a lot of human reading and hum= an typing. If you're lucky, you don't have to get a fax machine involved, s= o you can at least copy and paste. >>>=20 >>> But emailing or faxing spreadsheets around is a brutally primitive and = error-prone way to get this kind of thing done. I'm a little surprised it t= ook this long for anyone to make a serious run at some standardized form of= automation. >>>=20 >>> /a >>>=20 >>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>>> Please explain the number assignment process >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >>>>>>=20 >>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>>> I think private network case is already happening. There are more an= d more PBX that integrate with cloud providers such as Tropo or Twillio to = get phone numbers using a simple API. >>>>> And, really, ever since we ruled this out of scope for MARTINI, it's = been a pretty big gap in SIP PBX deployments. >>>>>=20 >>>>> /a >>>>>=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 From nobody Tue Jun 30 06:32: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 2B2311AD0A9 for ; Tue, 30 Jun 2015 06:32:04 -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 XyoVBKzDVd1i for ; Tue, 30 Jun 2015 06:32:01 -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 979701A90AE for ; Tue, 30 Jun 2015 06:32:01 -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 t5UDVbgf088131 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Jun 2015 08:31:47 -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, 30 Jun 2015 08:31:36 -0500 Message-ID: <8E3CE27E-B9D7-415E-9B74-14A3A553E124@nostrum.com> In-Reply-To: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> <001901d0b2ea$af764700$0e62d500$@ch> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "modern@ietf.org" , Richard Hill , Adam Roach , "DOLLY, MARTIN C" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 13:32:04 -0000 I agree that we should not remove the word "manage", because some usages of that word still apply. I brought it up because I was getting the impression that people were talking past each other. I do think we may already have some axle wrapping going on, though. A few words more clearly stating what sort of management we have in mind might be useful. Maybe something like "managing the distribution and transfer" (at the risk of either of those also being loaded terms...) On 29 Jun 2015, at 23:57, Peterson, Jon wrote: > I'd rather not get wrapped around a semantic axle of what "managing > telephone numbers" versus "manage how you get telephone numbers" > means. > Acquisition largely is about managing how you get numbers. Various > provisioning exercises may follow after acquisition, and I think those > operations fall within the realm we typically call management. I think > we > have a management area here in the IETF, it is not concerned with the > business process, say. > > And well, at the risk of being blithe, I think MODERN as an backronym > befits the work better than RADER or something. > > Jon Peterson > Neustar, Inc. > > On 6/29/15, 9:10 PM, "Richard Hill" wrote: > >> Dear Ben, >> >> Thank you for this very constructive comment. I think that you may >> well >> have >> identified a key concern. In my experience, when people refer to >> "managing" >> something (e.g. numbers or people) they usually refer to the entire >> business >> process, including rules for how to do it, and not just to the >> mechanical >> implementation of the rules. >> >> The first paragraph of the charter says: >> >> "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. Devices, applications, and network tools increasingly >> need >> to >> manage TNs, including requesting and acquiring TN delegations from >> authorities. The output of the working group should make >> distribution, >> acquisition, and management of TNs simpler for all entities >> involved." >> >> The rest of the charter focuses on mechanics, but that opening >> paragraph >> seems to me to imply that the scope of the group's work could be >> broader >> than just mechanical implementation of existing rules. >> >> If the idea is to "manage how you get telephone numbers", as opposed >> to >> "managing telephone numbers", then I would suggest that the first >> paragraph >> should read: >> >> "The MODERN working group will define a set of Internet-based >> mechanisms >> for >> the purposes of acquiring and resolving telephone numbers (TNs) in an >> IP >> environment. Devices, applications, and network tools increasingly >> need >> to >> request and acquire TN delegations from authorities. The output of >> the >> working group should make distribution, acquisition, and management >> of TNs >> simpler for all entities involved." >> >> And the title of the group might be changed to "Requesting, >> Acquiring, >> Distributing, Exposing, and Registering telephone numbers in an IP >> environment". >> >> Best, >> Richard >> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben >>> Campbell >>> Sent: Tuesday, June 30, 2015 05:39 >>> To: Adam Roach >>> Cc: modern@ietf.org; DOLLY, MARTIN C >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >>> Distributing, Exposing, & Registering telephone Numbers (modern) >>> >>> I have to wonder if everyone means the same thing when they say >>> "managing". I.e. managing how you get TNs to a lot of >>> telephone-like- >>> clients vs managing numbering plans, assignment policy, etc. >>> >>> >>> On 29 Jun 2015, at 22:27, Adam Roach wrote: >>> >>>> We discussed this exact use case in Dallas. From Jon's >>>> presentation: >>>> >>>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06- >>> 29%2022 >>>> .12.37.png?dl=0 >>>> >>>> It's also described in the charter. In fact, it's really the main >>>> thrust of the work: the charter repeatedly talks about acquiring, >>>> managing, and resolving TNs. This is the "acquring" part. >>>> >>>> So now, as I'm reflecting on it, I'm a little confused about what >>>> *you* think MODERN will be doing. Perhaps whatever you're worried >>>> about isn't actually happening. >>>> >>>> /a >>>> >>>> >>>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: >>>>> How is that applicable? Scope question? >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach >>>>>> wrote: >>>>>> >>>>>> In this context, there isn't one. >>>>>> >>>>>> MARTINI was predicated on a continuation of having VISPs do >>>>>> excruciatingly manual things like emailing -- or in some cases >>>>>> faxing -- spreadsheets to their customers detailing number >>>>>> ranges. >>>>>> I think I still have the one I got from our VISP back in the >>>>>> Estacado days when I was running our PBX. I can dig it up and >>>>>> forward it to you if you really don't know how number assignment >>>>>> works at that level. Basically, it's a lot of human reading and >>>>>> human typing. If you're lucky, you don't have to get a fax >>>>>> machine >>>>>> involved, so you can at least copy and paste. >>>>>> >>>>>> But emailing or faxing spreadsheets around is a brutally >>>>>> primitive >>>>>> and error-prone way to get this kind of thing done. I'm a little >>>>>> surprised it took this long for anyone to make a serious run at >>> some >>>>>> standardized form of automation. >>>>>> >>>>>> /a >>>>>> >>>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>>>>>> Please explain the number assignment process >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach >>> wrote: >>>>>>>>> >>>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>>>>>> I think private network case is already happening. There are >>> more >>>>>>>>> and more PBX that integrate with cloud providers such as Tropo >>> or >>>>>>>>> Twillio to get phone numbers using a simple API. >>>>>>>> And, really, ever since we ruled this out of scope for MARTINI, >>>>>>>> it's been a pretty big gap in SIP PBX deployments. >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 Jun 30 06:51: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 6ACEE1B2AFA for ; Tue, 30 Jun 2015 06:50:59 -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 kz9wvKqAteTq for ; Tue, 30 Jun 2015 06:50:56 -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 7EF691B2AF9 for ; Tue, 30 Jun 2015 06:50:56 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Ben Campbell , "Peterson, Jon" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgAADLICAAAjPgIAADUkAgACPhwD//71EGQ== Date: Tue, 30 Jun 2015 13:50:55 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> <001901d0b2ea$af764700$0e62d500$@ch> , <8E3CE27E-B9D7-415E-9B74-14A3A553E124@nostrum.com> In-Reply-To: <8E3CE27E-B9D7-415E-9B74-14A3A553E124@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Adam Roach , Richard Hill , "modern@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 13:50:59 -0000 One of the dangers of the noun-heavy charter languages we tend to write is = that the actions get lost. In my simple view, this is partially a "mother, = may I have a cookie" protocol, i.e., the supplicant asks the entity holding= a pool of numbers to (temporarily) be assigned such a number. This isn't f= undamentally different from the operation of EPP or, in a more remote sense= , DHCP. In all of these cases, there's a separable policy function that det= ermines whether the answer is "yes, here you are" or "no, you can't have on= e".=0A= =0A= In the numbering space, we may have to worry about things that don't matter= as much elsewhere, as in "I want a number from area code 212", "I want a m= obile number" or "can I get my old number 212 555 1234 back?" or "I need a = block of a 1000 numbers". Whether the cookie dispenser allows any of these = requests from a particular entity is somebody else's problem (including the= ITU and ATIS, along with NRAs).=0A= =0A= Fundamentally, the abstract operation isn't different (except in the "who c= an ask and for what") whether the hot dog vendor asks their VoIP provider o= r Verizon asks the LNPA. However, it is unlikely that the hot dog vendor wi= ll have to fill out an NRUF, for example.=0A= =0A= I think one of the productive exercises and where the expertise of people l= ike Richard is particularly helpful is to identify the invariants and varia= tions at the technical level. I'm not worried about number string lengths (= any reasonable protocol will support any string of digits or symbols of any= length), but more things like "can we assume an identifier for the assigne= d-to entity?"=0A= =0A= I don't think we consider EPP or DHCP management protocols; they are not in= the OPS area, for example.=0A= =0A= In the "working code spirit", a small team of Columbia students is playing = around with a pre-MODERN prototype; see http://e164.space for the current s= napshot.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com]=0A= Sent: Tuesday, June 30, 2015 9:31 AM=0A= To: Peterson, Jon=0A= Cc: modern@ietf.org; Richard Hill; Adam Roach; DOLLY, MARTIN C=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= I agree that we should not remove the word "manage", because some usages=0A= of that word still apply. I brought it up because I was getting the=0A= impression that people were talking past each other.=0A= =0A= I do think we may already have some axle wrapping going on, though. A=0A= few words more clearly stating what sort of management we have in mind=0A= might be useful. Maybe something like "managing the distribution and=0A= transfer" (at the risk of either of those also being loaded terms...)=0A= =0A= On 29 Jun 2015, at 23:57, Peterson, Jon wrote:=0A= =0A= > I'd rather not get wrapped around a semantic axle of what "managing=0A= > telephone numbers" versus "manage how you get telephone numbers"=0A= > means.=0A= > Acquisition largely is about managing how you get numbers. Various=0A= > provisioning exercises may follow after acquisition, and I think those=0A= > operations fall within the realm we typically call management. I think=0A= > we=0A= > have a management area here in the IETF, it is not concerned with the=0A= > business process, say.=0A= >=0A= > And well, at the risk of being blithe, I think MODERN as an backronym=0A= > befits the work better than RADER or something.=0A= >=0A= > Jon Peterson=0A= > Neustar, Inc.=0A= >=0A= > On 6/29/15, 9:10 PM, "Richard Hill" wrote:=0A= >=0A= >> Dear Ben,=0A= >>=0A= >> Thank you for this very constructive comment. I think that you may=0A= >> well=0A= >> have=0A= >> identified a key concern. In my experience, when people refer to=0A= >> "managing"=0A= >> something (e.g. numbers or people) they usually refer to the entire=0A= >> business=0A= >> process, including rules for how to do it, and not just to the=0A= >> mechanical=0A= >> implementation of the rules.=0A= >>=0A= >> The first paragraph of the charter says:=0A= >>=0A= >> "The MODERN working group will define a set of Internet-based=0A= >> mechanisms=0A= >> for=0A= >> the purposes of managing and resolving telephone numbers (TNs) in an=0A= >> IP=0A= >> environment. Devices, applications, and network tools increasingly=0A= >> need=0A= >> to=0A= >> manage TNs, including requesting and acquiring TN delegations from=0A= >> authorities. The output of the working group should make=0A= >> distribution,=0A= >> acquisition, and management of TNs simpler for all entities=0A= >> involved."=0A= >>=0A= >> The rest of the charter focuses on mechanics, but that opening=0A= >> paragraph=0A= >> seems to me to imply that the scope of the group's work could be=0A= >> broader=0A= >> than just mechanical implementation of existing rules.=0A= >>=0A= >> If the idea is to "manage how you get telephone numbers", as opposed=0A= >> to=0A= >> "managing telephone numbers", then I would suggest that the first=0A= >> paragraph=0A= >> should read:=0A= >>=0A= >> "The MODERN working group will define a set of Internet-based=0A= >> mechanisms=0A= >> for=0A= >> the purposes of acquiring and resolving telephone numbers (TNs) in an=0A= >> IP=0A= >> environment. Devices, applications, and network tools increasingly=0A= >> need=0A= >> to=0A= >> request and acquire TN delegations from authorities. The output of=0A= >> the=0A= >> working group should make distribution, acquisition, and management=0A= >> of TNs=0A= >> simpler for all entities involved."=0A= >>=0A= >> And the title of the group might be changed to "Requesting,=0A= >> Acquiring,=0A= >> Distributing, Exposing, and Registering telephone numbers in an IP=0A= >> environment".=0A= >>=0A= >> Best,=0A= >> Richard=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben=0A= >>> Campbell=0A= >>> Sent: Tuesday, June 30, 2015 05:39=0A= >>> To: Adam Roach=0A= >>> Cc: modern@ietf.org; DOLLY, MARTIN C=0A= >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=0A= >>> Distributing, Exposing, & Registering telephone Numbers (modern)=0A= >>>=0A= >>> I have to wonder if everyone means the same thing when they say=0A= >>> "managing". I.e. managing how you get TNs to a lot of=0A= >>> telephone-like-=0A= >>> clients vs managing numbering plans, assignment policy, etc.=0A= >>>=0A= >>>=0A= >>> On 29 Jun 2015, at 22:27, Adam Roach wrote:=0A= >>>=0A= >>>> We discussed this exact use case in Dallas. From Jon's=0A= >>>> presentation:=0A= >>>>=0A= >>>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-=0A= >>> 29%2022=0A= >>>> .12.37.png?dl=3D0=0A= >>>>=0A= >>>> It's also described in the charter. In fact, it's really the main=0A= >>>> thrust of the work: the charter repeatedly talks about acquiring,=0A= >>>> managing, and resolving TNs. This is the "acquring" part.=0A= >>>>=0A= >>>> So now, as I'm reflecting on it, I'm a little confused about what=0A= >>>> *you* think MODERN will be doing. Perhaps whatever you're worried=0A= >>>> about isn't actually happening.=0A= >>>>=0A= >>>> /a=0A= >>>>=0A= >>>>=0A= >>>> On 6/29/15 21:24, DOLLY, MARTIN C wrote:=0A= >>>>> How is that applicable? Scope question?=0A= >>>>>=0A= >>>>> Sent from my iPhone=0A= >>>>>=0A= >>>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach =0A= >>>>>> wrote:=0A= >>>>>>=0A= >>>>>> In this context, there isn't one.=0A= >>>>>>=0A= >>>>>> MARTINI was predicated on a continuation of having VISPs do=0A= >>>>>> excruciatingly manual things like emailing -- or in some cases=0A= >>>>>> faxing -- spreadsheets to their customers detailing number=0A= >>>>>> ranges.=0A= >>>>>> I think I still have the one I got from our VISP back in the=0A= >>>>>> Estacado days when I was running our PBX. I can dig it up and=0A= >>>>>> forward it to you if you really don't know how number assignment=0A= >>>>>> works at that level. Basically, it's a lot of human reading and=0A= >>>>>> human typing. If you're lucky, you don't have to get a fax=0A= >>>>>> machine=0A= >>>>>> involved, so you can at least copy and paste.=0A= >>>>>>=0A= >>>>>> But emailing or faxing spreadsheets around is a brutally=0A= >>>>>> primitive=0A= >>>>>> and error-prone way to get this kind of thing done. I'm a little=0A= >>>>>> surprised it took this long for anyone to make a serious run at=0A= >>> some=0A= >>>>>> standardized form of automation.=0A= >>>>>>=0A= >>>>>> /a=0A= >>>>>>=0A= >>>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote:=0A= >>>>>>> Please explain the number assignment process=0A= >>>>>>>=0A= >>>>>>> Sent from my iPhone=0A= >>>>>>>=0A= >>>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach =0A= >>> wrote:=0A= >>>>>>>>>=0A= >>>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote:=0A= >>>>>>>>> I think private network case is already happening. There are=0A= >>> more=0A= >>>>>>>>> and more PBX that integrate with cloud providers such as Tropo=0A= >>> or=0A= >>>>>>>>> Twillio to get phone numbers using a simple API.=0A= >>>>>>>> And, really, ever since we ruled this out of scope for MARTINI,=0A= >>>>>>>> it's been a pretty big gap in SIP PBX deployments.=0A= >>>>>>>>=0A= >>>>>>>> /a=0A= >>>>>>>>=0A= >>>>>>>> _______________________________________________=0A= >>>>>>>> Modern mailing list=0A= >>>>>>>> Modern@ietf.org=0A= >>>>>>>> https://www.ietf.org/mailman/listinfo/modern=0A= >>>>>>> _______________________________________________=0A= >>>>>>> Modern mailing list=0A= >>>>>>> Modern@ietf.org=0A= >>>>>>> https://www.ietf.org/mailman/listinfo/modern=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> Modern mailing list=0A= >>>> Modern@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/modern=0A= >>>=0A= >>> _______________________________________________=0A= >>> Modern mailing list=0A= >>> Modern@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/modern=0A= >>=0A= >> _______________________________________________=0A= >> Modern mailing list=0A= >> Modern@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/modern=0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= From nobody Tue Jun 30 06:51: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 5AC9A1B2AFA for ; Tue, 30 Jun 2015 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6Coe6ojL87cI for ; Tue, 30 Jun 2015 06:51:34 -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 1B6E11B2AF9 for ; Tue, 30 Jun 2015 06:51:33 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3DEA2C610648B; Tue, 30 Jun 2015 13:51:29 +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 t5UDoqII022146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 15:51:28 +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, 30 Jun 2015 15:50:37 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , "DOLLY, MARTIN C" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEyfpGjnKN5EOWAsicctSAOp3EKLIAgAABPICAAARggIAAAjqAgAARrACAAMvOcA== Date: Tue, 30 Jun 2015 13:50:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> In-Reply-To: <55920CA0.1070104@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 13:51:36 -0000 First of all, Jons presentation has no status (it was one of a number of pr= esentations made at the meeting as to a single individuals view of what mig= ht be useful); what matters is the charter.=20 However what is clear to me is that we have no consensus agreement on what = this group is meant to be doing or what the charter actually means. Otherwi= se this discussion would not be occurring. At the simplest it appears to me that people were stating a data model wher= e a telephone number is associated with a specific owner, and nothing more = than that.=20 However if you dive into various people's proposed use cases, it appears th= at more than that is envisaged. So for example to run any enterprise system= , that telephone number would need to be assocated with various other data = either: - in the end device itself, that controls how that telephone number fits wi= th the functions that the end device provides, any security certificates, o= r relates to other identifiers in the device; and/or - in some server belonging to the enterprise where the end users service po= licy is policed, and added functionality may also be provided. Now the first bullet above is device configuration, and the second bullet a= bove is network management. So I believe some people are talking as if the problem MODERN is meant to s= olve also includes device configuration and network management, as I have d= escribed above, and that is certainly considerably more that a simple alloc= ation problem. So which is it? In this new protocol, what data model will the end point of= the protocol end up with?=20 Keith=20 > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 30 June 2015 04:27 > To: DOLLY, MARTIN C > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing,=20 > Ordering, Distributing, Exposing, & Registering telephone=20 > Numbers (modern) >=20 > We discussed this exact use case in Dallas. From Jon's presentation: >=20 > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 > -29%2022.12.37.png?dl=3D0 >=20 > It's also described in the charter. In fact, it's really the=20 > main thrust of the work: the charter repeatedly talks about=20 > acquiring, managing, and resolving TNs. This is the "acquring" part. >=20 > So now, as I'm reflecting on it, I'm a little confused about=20 > what *you* think MODERN will be doing. Perhaps whatever=20 > you're worried about isn't actually happening. >=20 > /a >=20 >=20 > On 6/29/15 21:24, DOLLY, MARTIN C wrote: > > How is that applicable? Scope question? > > > > Sent from my iPhone > > > >> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: > >> > >> In this context, there isn't one. > >> > >> MARTINI was predicated on a continuation of having VISPs=20 > do excruciatingly manual things like emailing -- or in some=20 > cases faxing -- spreadsheets to their customers detailing=20 > number ranges. I think I still have the one I got from our=20 > VISP back in the Estacado days when I was running our PBX. I=20 > can dig it up and forward it to you if you really don't know=20 > how number assignment works at that level. Basically, it's a=20 > lot of human reading and human typing. If you're lucky, you=20 > don't have to get a fax machine involved, so you can at least=20 > copy and paste. > >> > >> But emailing or faxing spreadsheets around is a brutally=20 > primitive and error-prone way to get this kind of thing done.=20 > I'm a little surprised it took this long for anyone to make a=20 > serious run at some standardized form of automation. > >> > >> /a > >> > >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > >>> Please explain the number assignment process > >>> > >>> Sent from my iPhone > >>> > >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach=20 > wrote: > >>>>> > >>>>> On 6/29/15 20:19, Cullen Jennings wrote: > >>>>> I think private network case is already happening.=20 > There are more and more PBX that integrate with cloud=20 > providers such as Tropo or Twillio to get phone numbers using=20 > a simple API. > >>>> And, really, ever since we ruled this out of scope for=20 > MARTINI, it's been a pretty big gap in SIP PBX deployments. > >>>> > >>>> /a > >>>> > >>>> _______________________________________________ > >>>> 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 Tue Jun 30 06:54: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 B2B981B2B7A for ; Tue, 30 Jun 2015 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VDqTm3tbVMwd for ; Tue, 30 Jun 2015 06:54:24 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 7D14F1B2B65 for ; Tue, 30 Jun 2015 06:54:19 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5UDsDrP000990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2015 15:54:13 +0200 Received: from RHillNew (adsl-178-39-180-181.adslplus.ch [178.39.180.181]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5UDsCgT026991; Tue, 30 Jun 2015 15:54:13 +0200 From: "Richard Hill" To: "'Ben Campbell'" , "'Peterson, Jon'" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> <001901d0b2ea$af764700$0e62d500$@ch> <8E3CE27E-B9D7-415E-9B74-14A3A553E124@nostrum.com> In-Reply-To: <8E3CE27E-B9D7-415E-9B74-14A3A553E124@nostrum.com> Date: Tue, 30 Jun 2015 15:54:16 +0200 Message-ID: <003601d0b33c$41783130$c4689390$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCzOSnTuDKADGXxSD+GMxnq80wX5gAApbFw Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: 'Adam Roach' , modern@ietf.org, "'DOLLY, MARTIN C'" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 13:54:27 -0000 Dear Ben, Thank you for this. How about the following for the first paragraph: "The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing the acquisition and resolution of telephone numbers (TNs) in an IP environment. Devices, applications, and network tools increasingly need to request and acquire TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved." And the title could be "Managing the acquisition, ordering, distribution, and registration of telephone numbers in an IP environment". Best, Richard > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Tuesday, June 30, 2015 15:32 > To: Peterson, Jon > Cc: modern@ietf.org; Richard Hill; Adam Roach; DOLLY, MARTIN C > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > I agree that we should not remove the word "manage", because some > usages of that word still apply. I brought it up because I was getting > the impression that people were talking past each other. > > I do think we may already have some axle wrapping going on, though. A > few words more clearly stating what sort of management we have in mind > might be useful. Maybe something like "managing the distribution and > transfer" (at the risk of either of those also being loaded terms...) > > On 29 Jun 2015, at 23:57, Peterson, Jon wrote: > > > I'd rather not get wrapped around a semantic axle of what "managing > > telephone numbers" versus "manage how you get telephone numbers" > > means. > > Acquisition largely is about managing how you get numbers. Various > > provisioning exercises may follow after acquisition, and I think > those > > operations fall within the realm we typically call management. I > think > > we have a management area here in the IETF, it is not concerned with > > the business process, say. > > > > And well, at the risk of being blithe, I think MODERN as an backronym > > befits the work better than RADER or something. > > > > Jon Peterson > > Neustar, Inc. > > > > On 6/29/15, 9:10 PM, "Richard Hill" wrote: > > > >> Dear Ben, > >> > >> Thank you for this very constructive comment. I think that you may > >> well have identified a key concern. In my experience, when people > >> refer to "managing" > >> something (e.g. numbers or people) they usually refer to the entire > >> business process, including rules for how to do it, and not just to > >> the mechanical implementation of the rules. > >> > >> The first paragraph of the charter says: > >> > >> "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. Devices, applications, and > >> network tools increasingly need to manage TNs, including requesting > >> and acquiring TN delegations from authorities. The output of the > >> working group should make distribution, acquisition, and management > >> of TNs simpler for all entities involved." > >> > >> The rest of the charter focuses on mechanics, but that opening > >> paragraph seems to me to imply that the scope of the group's work > >> could be broader than just mechanical implementation of existing > >> rules. > >> > >> If the idea is to "manage how you get telephone numbers", as opposed > >> to "managing telephone numbers", then I would suggest that the first > >> paragraph should read: > >> > >> "The MODERN working group will define a set of Internet-based > >> mechanisms for the purposes of acquiring and resolving telephone > >> numbers (TNs) in an IP environment. Devices, applications, and > >> network tools increasingly need to request and acquire TN > delegations > >> from authorities. The output of the working group should make > >> distribution, acquisition, and management of TNs simpler for all > >> entities involved." > >> > >> And the title of the group might be changed to "Requesting, > >> Acquiring, Distributing, Exposing, and Registering telephone numbers > >> in an IP environment". > >> > >> Best, > >> Richard > >> > >>> -----Original Message----- > >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben > >>> Campbell > >>> Sent: Tuesday, June 30, 2015 05:39 > >>> To: Adam Roach > >>> Cc: modern@ietf.org; DOLLY, MARTIN C > >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > >>> Distributing, Exposing, & Registering telephone Numbers (modern) > >>> > >>> I have to wonder if everyone means the same thing when they say > >>> "managing". I.e. managing how you get TNs to a lot of > >>> telephone-like- > >>> clients vs managing numbering plans, assignment policy, etc. > >>> > >>> > >>> On 29 Jun 2015, at 22:27, Adam Roach wrote: > >>> > >>>> We discussed this exact use case in Dallas. From Jon's > >>>> presentation: > >>>> > >>>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06- > >>> 29%2022 > >>>> .12.37.png?dl=0 > >>>> > >>>> It's also described in the charter. In fact, it's really the main > >>>> thrust of the work: the charter repeatedly talks about acquiring, > >>>> managing, and resolving TNs. This is the "acquring" part. > >>>> > >>>> So now, as I'm reflecting on it, I'm a little confused about what > >>>> *you* think MODERN will be doing. Perhaps whatever you're worried > >>>> about isn't actually happening. > >>>> > >>>> /a > >>>> > >>>> > >>>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: > >>>>> How is that applicable? Scope question? > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach > >>>>>> wrote: > >>>>>> > >>>>>> In this context, there isn't one. > >>>>>> > >>>>>> MARTINI was predicated on a continuation of having VISPs do > >>>>>> excruciatingly manual things like emailing -- or in some cases > >>>>>> faxing -- spreadsheets to their customers detailing number > >>>>>> ranges. > >>>>>> I think I still have the one I got from our VISP back in the > >>>>>> Estacado days when I was running our PBX. I can dig it up and > >>>>>> forward it to you if you really don't know how number assignment > >>>>>> works at that level. Basically, it's a lot of human reading and > >>>>>> human typing. If you're lucky, you don't have to get a fax > >>>>>> machine involved, so you can at least copy and paste. > >>>>>> > >>>>>> But emailing or faxing spreadsheets around is a brutally > >>>>>> primitive and error-prone way to get this kind of thing done. > I'm > >>>>>> a little surprised it took this long for anyone to make a > serious > >>>>>> run at > >>> some > >>>>>> standardized form of automation. > >>>>>> > >>>>>> /a > >>>>>> > >>>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > >>>>>>> Please explain the number assignment process > >>>>>>> > >>>>>>> Sent from my iPhone > >>>>>>> > >>>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach > >>> wrote: > >>>>>>>>> > >>>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: > >>>>>>>>> I think private network case is already happening. There are > >>> more > >>>>>>>>> and more PBX that integrate with cloud providers such as > Tropo > >>> or > >>>>>>>>> Twillio to get phone numbers using a simple API. > >>>>>>>> And, really, ever since we ruled this out of scope for > MARTINI, > >>>>>>>> it's been a pretty big gap in SIP PBX deployments. > >>>>>>>> > >>>>>>>> /a > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 Tue Jun 30 06:58: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 C09FC1A1B22 for ; Tue, 30 Jun 2015 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pGb59MVkbPBh for ; Tue, 30 Jun 2015 06:58:42 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 209A21A0358 for ; Tue, 30 Jun 2015 06:58:41 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5UDwY1p016214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2015 15:58:35 +0200 Received: from RHillNew (adsl-178-39-180-181.adslplus.ch [178.39.180.181]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5UDwXwh017014; Tue, 30 Jun 2015 15:58:34 +0200 From: "Richard Hill" To: "'Henning Schulzrinne'" , "'Ben Campbell'" , "'Peterson, Jon'" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> <001901d0b2ea$af764700$0e62d500$@ch> , <8E3CE27E-B9D7-415E-9B74-14A3A553E124@nostrum.com> In-Reply-To: Date: Tue, 30 Jun 2015 15:58:37 +0200 Message-ID: <003901d0b33c$dd08b750$971a25f0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgAADLICAAAjPgIAADUkAgACPhwD//71EGYAABpAQ Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: 'Adam Roach' , modern@ietf.org, "'DOLLY, MARTIN C'" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 13:58:45 -0000 I agree with Henning's comments below (and thank him for the kind words). But I'm not able to access the cited URL: http://e164.space It seems to be password protected. (Pity they have adopted some of the bad features of the ITU.) Best, Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Tuesday, June 30, 2015 15:51 > To: Ben Campbell; Peterson, Jon > Cc: modern@ietf.org; Richard Hill; Adam Roach; DOLLY, MARTIN C > Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > One of the dangers of the noun-heavy charter languages we tend to write > is that the actions get lost. In my simple view, this is partially a > "mother, may I have a cookie" protocol, i.e., the supplicant asks the > entity holding a pool of numbers to (temporarily) be assigned such a > number. This isn't fundamentally different from the operation of EPP > or, in a more remote sense, DHCP. In all of these cases, there's a > separable policy function that determines whether the answer is "yes, > here you are" or "no, you can't have one". > > In the numbering space, we may have to worry about things that don't > matter as much elsewhere, as in "I want a number from area code 212", > "I want a mobile number" or "can I get my old number 212 555 1234 > back?" or "I need a block of a 1000 numbers". Whether the cookie > dispenser allows any of these requests from a particular entity is > somebody else's problem (including the ITU and ATIS, along with NRAs). > > Fundamentally, the abstract operation isn't different (except in the > "who can ask and for what") whether the hot dog vendor asks their VoIP > provider or Verizon asks the LNPA. However, it is unlikely that the hot > dog vendor will have to fill out an NRUF, for example. > > I think one of the productive exercises and where the expertise of > people like Richard is particularly helpful is to identify the > invariants and variations at the technical level. I'm not worried about > number string lengths (any reasonable protocol will support any string > of digits or symbols of any length), but more things like "can we > assume an identifier for the assigned-to entity?" > > I don't think we consider EPP or DHCP management protocols; they are > not in the OPS area, for example. > > In the "working code spirit", a small team of Columbia students is > playing around with a pre-MODERN prototype; see http://e164.space for > the current snapshot. > > Henning > > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell > [ben@nostrum.com] > Sent: Tuesday, June 30, 2015 9:31 AM > To: Peterson, Jon > Cc: modern@ietf.org; Richard Hill; Adam Roach; DOLLY, MARTIN C > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > I agree that we should not remove the word "manage", because some > usages of that word still apply. I brought it up because I was getting > the impression that people were talking past each other. > > I do think we may already have some axle wrapping going on, though. A > few words more clearly stating what sort of management we have in mind > might be useful. Maybe something like "managing the distribution and > transfer" (at the risk of either of those also being loaded terms...) > > On 29 Jun 2015, at 23:57, Peterson, Jon wrote: > > > I'd rather not get wrapped around a semantic axle of what "managing > > telephone numbers" versus "manage how you get telephone numbers" > > means. > > Acquisition largely is about managing how you get numbers. Various > > provisioning exercises may follow after acquisition, and I think > those > > operations fall within the realm we typically call management. I > think > > we have a management area here in the IETF, it is not concerned with > > the business process, say. > > > > And well, at the risk of being blithe, I think MODERN as an backronym > > befits the work better than RADER or something. > > > > Jon Peterson > > Neustar, Inc. > > > > On 6/29/15, 9:10 PM, "Richard Hill" wrote: > > > >> Dear Ben, > >> > >> Thank you for this very constructive comment. I think that you may > >> well have identified a key concern. In my experience, when people > >> refer to "managing" > >> something (e.g. numbers or people) they usually refer to the entire > >> business process, including rules for how to do it, and not just to > >> the mechanical implementation of the rules. > >> > >> The first paragraph of the charter says: > >> > >> "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. Devices, applications, and > >> network tools increasingly need to manage TNs, including requesting > >> and acquiring TN delegations from authorities. The output of the > >> working group should make distribution, acquisition, and management > >> of TNs simpler for all entities involved." > >> > >> The rest of the charter focuses on mechanics, but that opening > >> paragraph seems to me to imply that the scope of the group's work > >> could be broader than just mechanical implementation of existing > >> rules. > >> > >> If the idea is to "manage how you get telephone numbers", as opposed > >> to "managing telephone numbers", then I would suggest that the first > >> paragraph should read: > >> > >> "The MODERN working group will define a set of Internet-based > >> mechanisms for the purposes of acquiring and resolving telephone > >> numbers (TNs) in an IP environment. Devices, applications, and > >> network tools increasingly need to request and acquire TN > delegations > >> from authorities. The output of the working group should make > >> distribution, acquisition, and management of TNs simpler for all > >> entities involved." > >> > >> And the title of the group might be changed to "Requesting, > >> Acquiring, Distributing, Exposing, and Registering telephone numbers > >> in an IP environment". > >> > >> Best, > >> Richard > >> > >>> -----Original Message----- > >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben > >>> Campbell > >>> Sent: Tuesday, June 30, 2015 05:39 > >>> To: Adam Roach > >>> Cc: modern@ietf.org; DOLLY, MARTIN C > >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > >>> Distributing, Exposing, & Registering telephone Numbers (modern) > >>> > >>> I have to wonder if everyone means the same thing when they say > >>> "managing". I.e. managing how you get TNs to a lot of > >>> telephone-like- > >>> clients vs managing numbering plans, assignment policy, etc. > >>> > >>> > >>> On 29 Jun 2015, at 22:27, Adam Roach wrote: > >>> > >>>> We discussed this exact use case in Dallas. From Jon's > >>>> presentation: > >>>> > >>>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06- > >>> 29%2022 > >>>> .12.37.png?dl=0 > >>>> > >>>> It's also described in the charter. In fact, it's really the main > >>>> thrust of the work: the charter repeatedly talks about acquiring, > >>>> managing, and resolving TNs. This is the "acquring" part. > >>>> > >>>> So now, as I'm reflecting on it, I'm a little confused about what > >>>> *you* think MODERN will be doing. Perhaps whatever you're worried > >>>> about isn't actually happening. > >>>> > >>>> /a > >>>> > >>>> > >>>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: > >>>>> How is that applicable? Scope question? > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach > >>>>>> wrote: > >>>>>> > >>>>>> In this context, there isn't one. > >>>>>> > >>>>>> MARTINI was predicated on a continuation of having VISPs do > >>>>>> excruciatingly manual things like emailing -- or in some cases > >>>>>> faxing -- spreadsheets to their customers detailing number > >>>>>> ranges. > >>>>>> I think I still have the one I got from our VISP back in the > >>>>>> Estacado days when I was running our PBX. I can dig it up and > >>>>>> forward it to you if you really don't know how number assignment > >>>>>> works at that level. Basically, it's a lot of human reading and > >>>>>> human typing. If you're lucky, you don't have to get a fax > >>>>>> machine involved, so you can at least copy and paste. > >>>>>> > >>>>>> But emailing or faxing spreadsheets around is a brutally > >>>>>> primitive and error-prone way to get this kind of thing done. > I'm > >>>>>> a little surprised it took this long for anyone to make a > serious > >>>>>> run at > >>> some > >>>>>> standardized form of automation. > >>>>>> > >>>>>> /a > >>>>>> > >>>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > >>>>>>> Please explain the number assignment process > >>>>>>> > >>>>>>> Sent from my iPhone > >>>>>>> > >>>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach > >>> wrote: > >>>>>>>>> > >>>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: > >>>>>>>>> I think private network case is already happening. There are > >>> more > >>>>>>>>> and more PBX that integrate with cloud providers such as > Tropo > >>> or > >>>>>>>>> Twillio to get phone numbers using a simple API. > >>>>>>>> And, really, ever since we ruled this out of scope for > MARTINI, > >>>>>>>> it's been a pretty big gap in SIP PBX deployments. > >>>>>>>> > >>>>>>>> /a > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 Tue Jun 30 07:17:40 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718FC1A8F4F for ; Tue, 30 Jun 2015 07:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 g0hQyGkyi-w4 for ; Tue, 30 Jun 2015 07:17:37 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 37E8E1A8FD6 for ; Tue, 30 Jun 2015 07:17:23 -0700 (PDT) Received: (qmail 19593 invoked by uid 0); 30 Jun 2015 14:17:21 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 30 Jun 2015 14:17:21 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id mjq51q01R1MNPNq01jq8N9; Tue, 30 Jun 2015 13:50:10 -0600 X-Authority-Analysis: v=2.1 cv=HpvlRSjS c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=ll-iCDY8AAAA:8 a=doUQZJtgAAAA:8 a=ASjRbOs7AAAA:8 a=dvxUH5oTLfZSpuFJM8wA:9 a=uZtXqzbeNNAU53w0:21 a=EpLyuuRbI6kkG03f:21 a=wPNLvfGTeEIA:10 a=OT2nvUJKb2MA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA: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=fVgMflfl8cbYHDofpBrHo+ZPxVUSuKH7FUROnMQ/B4s=; b=eG6Sn+v2nl1sXcO1s0L9jjnVD3nwpjxXOek2GNlDxHWDGnVX4W3lxQ9ryfTOOX6PfTkmOyn5hhaQ97bQpJhtBpJuBBD4VplaR77a3ZGxAnpRnUpNKzm1I6wL52GoHyZ0; Received: from [100.36.26.202] (port=50689 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z9w2F-0002NB-TR; Tue, 30 Jun 2015 07:57:17 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Tue, 30 Jun 2015 09:57:10 -0400 From: Richard Shockey To: Henning Schulzrinne , Richard Hill , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <000601d0b168$06723ed0$1356bc70$@ch> 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 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 14:17:39 -0000 On 6/29/15, 11:11 AM, "Modern on behalf of Henning Schulzrinne" wrote: >This is straying far afield, but a few quick remarks: > >* The US numbering system does have extension points that would allow >transitioning to longer numbers, but I haven't heard anybody proposing >this seriously. Partially, it's because the number utilization is low >(800M out of 10B theoretically possible numbers), so while individual >area codes continue to be split, there is no shortage of numbers as such, >particularly as the need for prefix dialing disappears with the use of >mobile and VoIP. (Right now, a bunch of area codes can't be assigned >since they are short numbers, such as N11.) Most of the increased demand >is from non-human users (think parking and water meters) and they >generally don't care about geographic area codes. We can take bets as to >whether the US will transition first to the metric system or >variable-length numbers. LOL ! =20 >At least a presidential candidate has proposed the former and there's >probably more value to that transition. And WhatsAPP guys etc preforming arbitrage on the SMS service. The data does indicate US operators are actually smarter by devising a more =B3One Rate=B2 tm like service model w/ predictable pricing that has actually lead to higher ARPU than the EU etc. Yes Virginia there are business models here that can drive protocol. > >As geographic numbering decreases somewhat in importance, due to mobile, >I suspect that we should essentially look at numbers as either >fixed-length (NANP) or variable-length strings, and the trade-offs aren't >obvious. It could well be that non-human users of phone numbers if they >ever get beyond the rather limited applications envisioned so far, use >longer strings, just as some such applications have started to use >non-dialable numbers (pANI). Right. I do have to admit it is getting more interesting for IoT and phone numbers. Certainly we know some of the basic APP=B9s utility meters, Amazon Kindle devices, cars etc but literally today I got a CPAP device that =B3phones in=B2 my sleep data. > >I suspect that there are millions of places where software, from >spreadsheets to databases and billing systems, in North America assumes >fixed-length strings, so you're suggesting another Y2K-level effort, with >no obvious benefit. > >* The different dialing plans are a pain, but unifying them into >permissive 10D dialing does not require changing to a European-style >variable-length plan. They are mainly used since many people are used to >dialing local numbers as seven digits in the NANP (just like they dial >numbers without area codes elsewhere), but I suspect that the distinction >between local and non-local will gradually fade as mobile dominates. > >* We have lots of issues in MODERN, but shy service providers doesn't >seem to be one of them... Given the additional flexibility and "cutting >out the middle man" advantages, I would hope that they'd actually see >this effort as being to their benefit. > >ATIS and the ITU do fine and important work (and they clearly have a lot >to contribute in this space in terms of requirements and operational >practices, so liaisons are all good), but they have not been in the >protocol engineering business for a while. For the ITU, ISDN was indeed >probably the last such major effort, followed by ISDN-over-IP (aka H.323). Well at what point is this actually an open source vs a open standards/protocol=20 effort? It strikes me the former vs that latter. > >Henning > >________________________________ > > >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: Sunday, June 28, 2015 00:57 >To: Eric Burger; modern@ietf.org >Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > > > >From: Modern > on >behalf of Eric Burger >> >Date: Friday, June 26, 2015 at 7:54 PM >To: "modern@ietf.org" >> >Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > > >SNIP > >If you eliminate the geographic or access means of numbering things get >simpler. Yes as Brother Henning points out a TN is really a domain name >and that is why this discussion actually is important and makes sense. >IBM or Ford or Cisco could assign one single NPA to all of its employees >for its business communications but you go tell citizens in Vermont >Alaska or Maine PEI Yukon etc they have to dial 10 digits for all calls. > >http://www.shockey.us/index.php/download_file/view/13/142/ > >>RH: I find that the paper cited above is excellent and I would urge >>everybody who has a serious interest in these discussions to read it >>carefully. In Switzerland, we have full geographic portability for >>fixed numbers (as well as portability for mobile numbers), so users have >>to dial 10 digits for all calls (including the leading zero, as in 022 >>840 1021). The same is true in most European countries, but in some >>cases the number of digits in greater. Given the size of the US >>population (vs. the 8 million of Switzerland), it seems to me that the >>US should envisage moving to 12 digits, or at least 11. > >The unspoken issue here is where does the initial work get done and I=B9m >not currently convinced the IETF is the right place to do it. > >OK I=B9ll finally say it. > >The IETF has not traditionally been hospitable to the concerns of service >providers. There is a reason 3GPP ETSI ATIS exist. > >>RH: People who have been around a long time and who are cynical might be >>tempted to recall the misunderstandings between the bell-heads and the >>net-heads. But I don=B9t think that that is relevant any more. What is >>relevant is who tends to participate in which group. As far as I know, >>the people who understand the concerns of service providers (and >>carriers) don=B9t typically participate in IETF. So I agree that IETF is >>not the right place to start this work. But I do agree that the work >>should be started. Those who wish to drive the work forward should pick >>an appropriate forum. > >Collectively we understand that there is a problem in the US with >numbering/routing databases and that the problem is manifesting itself >first in the North American market since the level of SIP/IMS deployments >now far exceed anything in Europe or AsiaPac. The PSTN Transition is no >longer a idea its an inevitability. And yes.. Contrary to everything >Henry Sinnreich and other used to preach ..TN are still here and I still >don=B9t see SIP URI=B9s on the side of pizza delivery cars. > >Even within the FCC and the Commissioners there is some divergent views >on what is actually at stake here. > >https://www.fcc.gov/article/fcc-15-70a6 > >The debate in the UK w/ BT is just starting. > >http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms >/telecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-to-help- >it-battle-US-tech-giants.html > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jun 30 07:42: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 43DE11A9106 for ; Tue, 30 Jun 2015 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7cIvBBxWBVmm for ; Tue, 30 Jun 2015 07:41: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 18A5E1A9068 for ; Tue, 30 Jun 2015 07:40:29 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C41F08C5A1B6A; Tue, 30 Jun 2015 14:40:24 +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 t5UEdNRY006980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 16:40:22 +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, 30 Jun 2015 16:39:41 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , "DOLLY, MARTIN C" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEyfpGjnKN5EOWAsicctSAOp3EKLIAgAABPICAAARggIAA8GIw Date: Tue, 30 Jun 2015 14:39:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> In-Reply-To: <5591FBEF.2000903@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 14:41:55 -0000 IETF is about isolating a solveable problem and solving it.=20 You make this sound like MARTINI was originally meant to solve world hunger= , and somehow got scoped down, which is untrue.=20 Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 30 June 2015 03:16 > To: DOLLY, MARTIN C > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing,=20 > Ordering, Distributing, Exposing, & Registering telephone=20 > Numbers (modern) >=20 > In this context, there isn't one. >=20 > MARTINI was predicated on a continuation of having VISPs do=20 > excruciatingly manual things like emailing -- or in some cases faxing > -- spreadsheets to their customers detailing number ranges.=20 > I think I still have the one I got from our VISP back in the=20 > Estacado days when I was running our PBX. I can dig it up and=20 > forward it to you if you really don't know how number=20 > assignment works at that level. Basically, it's a lot of=20 > human reading and human typing. If you're lucky, you don't=20 > have to get a fax machine involved, so you can at least copy=20 > and paste. >=20 > But emailing or faxing spreadsheets around is a brutally=20 > primitive and error-prone way to get this kind of thing done.=20 > I'm a little surprised it took this long for anyone to make a=20 > serious run at some standardized form of automation. >=20 > /a >=20 > On 6/29/15 21:00, DOLLY, MARTIN C wrote: > > Please explain the number assignment process > > > > Sent from my iPhone > > > >> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: > >> > >>> On 6/29/15 20:19, Cullen Jennings wrote: > >>> I think private network case is already happening. There=20 > are more and more PBX that integrate with cloud providers=20 > such as Tropo or Twillio to get phone numbers using a simple API. > >> And, really, ever since we ruled this out of scope for=20 > MARTINI, it's been a pretty big gap in SIP PBX deployments. > >> > >> /a > >> > >> _______________________________________________ > >> 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 Tue Jun 30 08:15: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 2E41D1A9234 for ; Tue, 30 Jun 2015 08:15:50 -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 fcVtkbCtEE6b for ; Tue, 30 Jun 2015 08:15:49 -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 F16D91A907A for ; Tue, 30 Jun 2015 08:15:48 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5UFFioU097074 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Jun 2015 10:15:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5592B2A0.7050805@nostrum.com> Date: Tue, 30 Jun 2015 10:15:44 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "DOLLY, MARTIN C" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 15:15:50 -0000 On 6/30/15 08:50, DRAGE, Keith (Keith) wrote: > First of all, Jons presentation has no status (it was one of a number of presentations made at the meeting as to a single individuals view of what might be useful); what matters is the charter. Of course. That's why I cited the charter in my response as well. The reason I brought Jon's slide into it is that, even though Martin's responses appear to be coming from some kind of specially commissioned magic eight ball, he seemed to be expressing surprise that this use case was even on the table -- almost as if it were his first time hearing about it. My point was that he was in the front row in Dallas, not 20 feet from the screen where this slide was shown. > In this new protocol, what data model will the end point of the protocol end up with? If we had to have a design down to the data model level before we chartered a working group, then the IETF would be nothing more than a rubber stamp factory. I understand that one could do that and still call oneself an SDO, but it means that the real work would be happening elsewhere. The IETF chooses not to operate that way, instead taking in problems and creating solutions. /a From nobody Tue Jun 30 08: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 040451ACCE6 for ; Tue, 30 Jun 2015 08:23:35 -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 Isl3X9NqclA8 for ; Tue, 30 Jun 2015 08:23:33 -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 811411A6EE1 for ; Tue, 30 Jun 2015 08:23:25 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5UFNMJ0097772 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Jun 2015 10:23:22 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5592B469.1080204@nostrum.com> Date: Tue, 30 Jun 2015 10:23:21 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com>, <55920CA0.1070104@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 15:23:35 -0000 It's good to know that what you're worried about isn't exactly happening. I'm glad we could get this behind us. /a On 6/30/15 05:52, DOLLY, MARTIN C wrote: > Not exactly > > Sent from my iPhone > >> On Jun 29, 2015, at 11:27 PM, Adam Roach wrote: >> >> We discussed this exact use case in Dallas. From Jon's presentation: >> >> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-29%2022.12.37.png?dl=0 >> >> It's also described in the charter. In fact, it's really the main thrust of the work: the charter repeatedly talks about acquiring, managing, and resolving TNs. This is the "acquring" part. >> >> So now, as I'm reflecting on it, I'm a little confused about what *you* think MODERN will be doing. Perhaps whatever you're worried about isn't actually happening. >> >> /a >> >> >>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: >>> How is that applicable? Scope question? >>> >>> Sent from my iPhone >>> >>>> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: >>>> >>>> In this context, there isn't one. >>>> >>>> MARTINI was predicated on a continuation of having VISPs do excruciatingly manual things like emailing -- or in some cases faxing -- spreadsheets to their customers detailing number ranges. I think I still have the one I got from our VISP back in the Estacado days when I was running our PBX. I can dig it up and forward it to you if you really don't know how number assignment works at that level. Basically, it's a lot of human reading and human typing. If you're lucky, you don't have to get a fax machine involved, so you can at least copy and paste. >>>> >>>> But emailing or faxing spreadsheets around is a brutally primitive and error-prone way to get this kind of thing done. I'm a little surprised it took this long for anyone to make a serious run at some standardized form of automation. >>>> >>>> /a >>>> >>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>>>> Please explain the number assignment process >>>>> >>>>> Sent from my iPhone >>>>> >>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >>>>>>> >>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>>>> I think private network case is already happening. There are more and more PBX that integrate with cloud providers such as Tropo or Twillio to get phone numbers using a simple API. >>>>>> And, really, ever since we ruled this out of scope for MARTINI, it's been a pretty big gap in SIP PBX deployments. >>>>>> >>>>>> /a >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Jun 30 08:53: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 AE5D21ACD28 for ; Tue, 30 Jun 2015 08:53:18 -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 DkkKHc8OsO5c for ; Tue, 30 Jun 2015 08:53:17 -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 8C26E1ACD32 for ; Tue, 30 Jun 2015 08:53:17 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:62968 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Z9xqU-000AG4-NC for modern@ietf.org; Tue, 30 Jun 2015 08:53:17 -0700 Message-ID: <5592BB6A.3080807@usdonovans.com> Date: Tue, 30 Jun 2015 10:53:14 -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=-1.0 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 WG meeting in Prague 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, 30 Jun 2015 15:53:18 -0000 All, We have a two hour slot in Prague on Tuesday afternoon from 3:20 - 5:20. Please send any requests for agenda slots to Tom and me ASAP. Please make sure the requested slots apply to the deliverables outlined in the MODERN charter -- https://datatracker.ietf.org/doc/charter-ietf-modern/ As a reminder, the Internet Draft cutoff date is July 6th. Regards, Steve and Tom From nobody Tue Jun 30 09:28: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 D4BA71B2E6B for ; Tue, 30 Jun 2015 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sedk7RIxSh9h for ; Tue, 30 Jun 2015 09:27:56 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3107F1B2E6C for ; Tue, 30 Jun 2015 09:27:56 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id c83c2955.2ad7ea8a3940.117604.00-2487.337630.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:27:56 +0000 (UTC) X-MXL-Hash: 5592c38c70b96179-aaf48f1e5f0652071ee6c4afc58bd3799dbc84ec Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 453c2955.0.117099.00-2386.336180.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:27:00 +0000 (UTC) X-MXL-Hash: 5592c3545dc5003b-9c5619b46dca76b4ed965ab0522f7f821aaf295c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGQxPa027108; Tue, 30 Jun 2015 12:27:00 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGQpSu026950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2015 12:26:54 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 16:26:38 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 12:26:38 -0400 From: "DOLLY, MARTIN C" To: Adam Roach , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAAEdvgP//vytrgADXn5qAABHp0A== Date: Tue, 30 Jun 2015 16:26:37 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592B2A0.7050805@nostrum.com> In-Reply-To: <5592B2A0.7050805@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.27.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Rqhy2laK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=M2lCxREK3PIA:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=XAFQembCKUMA:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=t61qFc0B51n6ZbIcHPMA:9 a=QEXdDO2ut3YA:10 a=e-_cEPNs] X-AnalysisOut: [4MTmMBTU:21 a=JodEqec42u5jzdBe:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:28:01 -0000 QWRhbSwNCg0KSWYgSSB3YXMgYXQgdGhlIG1pYyBmb3IgZXZlcnkgcG9pbnQgaW4gSm9uJ3MgcHJl c2VudGF0aW9ucywgdGhlcmUgd291bGQgYmUgbm8gcm9vbSBmb3IgYW55b25lIGVsc2UgdG8gc3Bl YWsgOikgSnVzdCBiZWNhdXNlIHRoZXkgd2VyZSBpbiBKb24ncyBzbGlkZXMsIGRvZXMgbm90IG1l YW4gdGhlcmUgd2FzIG1lZXRpbmcgY29uc2Vuc3VzLg0KDQpJIHdpbGwgaGF2ZSB0byBsaXN0ZW4g dG8gdGhlIG1lZXRpbmcgYWdhaW4uLi4NCg0KSGVubmluZydzIHJlc3BvbnNlIHRvIG1lIHdhcyBy ZWFzb25hYmxlLCBudW1iZXJzIHdpbGwgbm90IGJlIGFzc2lnbmVkIHRvIENpc2NvLCBidXQgYSBu dW1iZXIgcmVxdWVzdCBpcyBnaXZlbiB0byB0aGVtIGJ1dCB0aGUgbnVtYmVyIGlzIHN0aWxsIGFz c2lnbmVkIHRvIHRoZSBSRVNQT05TSUJMRSBzZXJ2aWNlIHByb3ZpZGVyLg0KDQpJZiBHb29nbGUg d2FudHMgdG8gYmUgcmVndWxhdGVkIGFzIGFzLCBwbGVhc2Ugc3RlcCB1cCB0byB0aGUgYmFyLg0K DQpJIHdpbGwgcHV0IG15IG90aGVyIGNvbW1lbnRzIG9uIGEgc2VwYXJhdGUgdGhyZWFkLg0KDQpN YXJ0aW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkYW0gUm9hY2ggW21h aWx0bzphZGFtQG5vc3RydW0uY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgMTE6 MTYgQU0NClRvOiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgRE9MTFksIE1BUlRJTiBDDQpDYzogbW9k ZXJuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01vZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6 IE1hbmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0aW5nLCBFeHBvc2luZywgJiBSZWdpc3Rlcmlu ZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0KDQpPbiA2LzMwLzE1IDA4OjUwLCBEUkFHRSwg S2VpdGggKEtlaXRoKSB3cm90ZToNCj4gRmlyc3Qgb2YgYWxsLCBKb25zIHByZXNlbnRhdGlvbiBo YXMgbm8gc3RhdHVzIChpdCB3YXMgb25lIG9mIGEgbnVtYmVyIG9mIHByZXNlbnRhdGlvbnMgbWFk ZSBhdCB0aGUgbWVldGluZyBhcyB0byBhIHNpbmdsZSBpbmRpdmlkdWFscyB2aWV3IG9mIHdoYXQg bWlnaHQgYmUgdXNlZnVsKTsgd2hhdCBtYXR0ZXJzIGlzIHRoZSBjaGFydGVyLg0KDQpPZiBjb3Vy c2UuIFRoYXQncyB3aHkgSSBjaXRlZCB0aGUgY2hhcnRlciBpbiBteSByZXNwb25zZSBhcyB3ZWxs Lg0KDQpUaGUgcmVhc29uIEkgYnJvdWdodCBKb24ncyBzbGlkZSBpbnRvIGl0IGlzIHRoYXQsIGV2 ZW4gdGhvdWdoIE1hcnRpbidzIHJlc3BvbnNlcyBhcHBlYXIgdG8gYmUgY29taW5nIGZyb20gc29t ZSBraW5kIG9mIHNwZWNpYWxseSBjb21taXNzaW9uZWQgbWFnaWMgZWlnaHQgYmFsbCwgaGUgc2Vl bWVkIHRvIGJlIGV4cHJlc3Npbmcgc3VycHJpc2UgdGhhdCB0aGlzIHVzZSBjYXNlIHdhcyBldmVu IG9uIHRoZSB0YWJsZSAtLSBhbG1vc3QgYXMgaWYgaXQgd2VyZSBoaXMgZmlyc3QgdGltZSBoZWFy aW5nIGFib3V0IGl0LiBNeSBwb2ludCB3YXMgdGhhdCBoZSB3YXMgaW4gdGhlIGZyb250IHJvdyBp biBEYWxsYXMsIG5vdCAyMCBmZWV0IGZyb20gdGhlIHNjcmVlbiB3aGVyZSB0aGlzIHNsaWRlIHdh cyBzaG93bi4NCg0KPiBJbiB0aGlzIG5ldyBwcm90b2NvbCwgd2hhdCBkYXRhIG1vZGVsIHdpbGwg dGhlIGVuZCBwb2ludCBvZiB0aGUgcHJvdG9jb2wgZW5kIHVwIHdpdGg/DQoNCklmIHdlIGhhZCB0 byBoYXZlIGEgZGVzaWduIGRvd24gdG8gdGhlIGRhdGEgbW9kZWwgbGV2ZWwgYmVmb3JlIHdlIGNo YXJ0ZXJlZCBhIHdvcmtpbmcgZ3JvdXAsIHRoZW4gdGhlIElFVEYgd291bGQgYmUgbm90aGluZyBt b3JlIHRoYW4gYSBydWJiZXIgc3RhbXAgZmFjdG9yeS4gSSB1bmRlcnN0YW5kIHRoYXQgb25lIGNv dWxkIGRvIHRoYXQgYW5kIHN0aWxsIGNhbGwgb25lc2VsZiBhbiBTRE8sIGJ1dCBpdCBtZWFucyB0 aGF0IHRoZSByZWFsIHdvcmsgd291bGQgYmUgaGFwcGVuaW5nIGVsc2V3aGVyZS4gVGhlIElFVEYg Y2hvb3NlcyBub3QgdG8gb3BlcmF0ZSB0aGF0IHdheSwgaW5zdGVhZCB0YWtpbmcgaW4gcHJvYmxl bXMgYW5kIGNyZWF0aW5nIHNvbHV0aW9ucy4NCg0KL2ENCg== From nobody Tue Jun 30 09:31:32 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600E71ACE44 for ; Tue, 30 Jun 2015 09:31:30 -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 esCLVXG-kpty for ; Tue, 30 Jun 2015 09:31:28 -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 A54A81ACD6D for ; Tue, 30 Jun 2015 09:31:28 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5UGVOEm003993 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Jun 2015 11:31:24 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5592C45B.9030105@nostrum.com> Date: Tue, 30 Jun 2015 11:31:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "DOLLY, MARTIN C" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:31:30 -0000 On 6/30/15 09:39, DRAGE, Keith (Keith) wrote: > You make this sound like MARTINI was originally meant to solve world hunger, and somehow got scoped down, which is untrue. The MARTINI charter was silent on the issue of whether the AORs being registered were explicit or implicit. Making them implicit was a simplification, but not a necessary one. We could have been explicit about the AORs being registered and still been well within the charter. My point is that this simplification left a hole in the story, and that MODERN's work is well positioned to fill that hole. /a From nobody Tue Jun 30 09:34: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 4CC3B1ACE5C for ; Tue, 30 Jun 2015 09:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BqnudlcH0bA for ; Tue, 30 Jun 2015 09:33:58 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618AE1B2E6B for ; Tue, 30 Jun 2015 09:33:58 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 6f4c2955.2b0210c54940.49836.00-2475.142575.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:33:58 +0000 (UTC) X-MXL-Hash: 5592c4f660b0a11a-30ee78e5ffc7532cedddc435c3f82e0a7041be17 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 0f4c2955.0.49788.00-2381.142421.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:33:54 +0000 (UTC) X-MXL-Hash: 5592c4f27b14879e-9c62f39ad4f68d696bfc657d3bf70c3d42a93ec9 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGXp5p008561; Tue, 30 Jun 2015 12:33:52 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGXkvN008501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2015 12:33:49 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 16:33:34 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 12:33:34 -0400 From: "DOLLY, MARTIN C" To: Adam Roach , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAAPNd1YAAAFgg Date: Tue, 30 Jun 2015 16:33:33 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> In-Reply-To: <5592C45B.9030105@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.27.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=XshNzy59 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=M2lCxREK3PIA:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=XAFQembCKUMA:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=aTyGeTwKHz7-XezI7ocA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:34:03 -0000 QU9SIG9mIHRoZSBkZXZpY2U/IE9yIHdoYXQ/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBBZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0gDQpTZW50OiBUdWVz ZGF5LCBKdW5lIDMwLCAyMDE1IDEyOjMxIFBNDQpUbzogRFJBR0UsIEtlaXRoIChLZWl0aCk7IERP TExZLCBNQVJUSU4gQw0KQ2M6IG1vZGVybkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNb2Rlcm5d IFtuZXctd29ya10gV0cgUmV2aWV3OiBNYW5hZ2luZywgT3JkZXJpbmcsIERpc3RyaWJ1dGluZywg RXhwb3NpbmcsICYgUmVnaXN0ZXJpbmcgdGVsZXBob25lIE51bWJlcnMgKG1vZGVybikNCg0KT24g Ni8zMC8xNSAwOTozOSwgRFJBR0UsIEtlaXRoIChLZWl0aCkgd3JvdGU6DQo+IFlvdSBtYWtlIHRo aXMgc291bmQgbGlrZSBNQVJUSU5JIHdhcyBvcmlnaW5hbGx5IG1lYW50IHRvIHNvbHZlIHdvcmxk IGh1bmdlciwgYW5kIHNvbWVob3cgZ290IHNjb3BlZCBkb3duLCB3aGljaCBpcyB1bnRydWUuDQoN ClRoZSBNQVJUSU5JIGNoYXJ0ZXIgd2FzIHNpbGVudCBvbiB0aGUgaXNzdWUgb2Ygd2hldGhlciB0 aGUgQU9ScyBiZWluZyByZWdpc3RlcmVkIHdlcmUgZXhwbGljaXQgb3IgaW1wbGljaXQuIE1ha2lu ZyB0aGVtIGltcGxpY2l0IHdhcyBhIHNpbXBsaWZpY2F0aW9uLCBidXQgbm90IGEgbmVjZXNzYXJ5 IG9uZS4gV2UgY291bGQgaGF2ZSBiZWVuIGV4cGxpY2l0IGFib3V0IHRoZSBBT1JzIGJlaW5nIHJl Z2lzdGVyZWQgYW5kIHN0aWxsIGJlZW4gd2VsbCB3aXRoaW4gdGhlIGNoYXJ0ZXIuDQoNCk15IHBv aW50IGlzIHRoYXQgdGhpcyBzaW1wbGlmaWNhdGlvbiBsZWZ0IGEgaG9sZSBpbiB0aGUgc3Rvcnks IGFuZCB0aGF0IE1PREVSTidzIHdvcmsgaXMgd2VsbCBwb3NpdGlvbmVkIHRvIGZpbGwgdGhhdCBo b2xlLg0KDQovYQ0K From nobody Tue Jun 30 09:41: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 048531A6F07 for ; Tue, 30 Jun 2015 09:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.299 X-Spam-Level: ** X-Spam-Status: No, score=2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_IS_IT_OUR_ACCOUNT=4.2, 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 BhNUIqhh--FK for ; Tue, 30 Jun 2015 09:41:36 -0700 (PDT) Received: from smtp85.ord1c.emailsrvr.com (smtp85.ord1c.emailsrvr.com [108.166.43.85]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA161ACED0 for ; Tue, 30 Jun 2015 09:41:26 -0700 (PDT) Received: from smtp19.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp19.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 60BFC1802FF; Tue, 30 Jun 2015 12:41:25 -0400 (EDT) Received: by smtp19.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 89A4C180342; Tue, 30 Jun 2015 12:41:24 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.0.0.63] (c-71-198-88-125.hsd1.ca.comcast.net [71.198.88.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 30 Jun 2015 16:41:25 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> Date: Tue, 30 Jun 2015 09:41:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <, <5591F73A.90301@nostrum.com> <>> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:41:38 -0000 > On Jun 29, 2015, at 7:00 PM, DOLLY, MARTIN C wrote: > Please explain the number assignment process=20 I think I would summarize that number assignment process as the entity = wanting a number needs to provide account information to identify = themselves. And credit cards are a surprising strong form of that. Then = the entity asks for a number in a given area code.=20 I'll use AT&T API as an example but others are similar. Some nice docs = at https://developer.att.com/sdks-plugins/enhanced-webrtc Roughly speaking the steps are: Create and account along with things like a credit card or way to bill=20= Request some phones numbers - you can specify what area codes you want Use your account info to get a OAuth2 token that is used for rest of = requests Optionally provide some E911 info for each number=20 Say where to to route incoming calls and / or sms to For the Tropo flow, you get a number simply by doing a HTTP post saying = you want a number and country / area code you want it in to a URL that = manages the addresses for your applications. You can see the doc at and = it returns the new number. The application is already associated with = who to bill. More docs at = https://www.tropo.com/docs/rest/tutorials/adding-number-based-prefix From nobody Tue Jun 30 09:46:01 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 D141A1B3141 for ; Tue, 30 Jun 2015 09:46:00 -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 gUQj9v34omOs for ; Tue, 30 Jun 2015 09:45:59 -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 B1BA01B3142 for ; Tue, 30 Jun 2015 09:44:10 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5UGi4Q5005069 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Jun 2015 11:44:05 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5592C754.4030502@nostrum.com> Date: Tue, 30 Jun 2015 11:44:04 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" , "DRAGE, Keith (Keith)" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:46:01 -0000 On 6/30/15 11:33, DOLLY, MARTIN C wrote: > AOR of the device? Or what? AORs (plural) associated with the PBX making the registration request. Reviewing section 4 of RFC 6140 may be illustrative. /a > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, June 30, 2015 12:31 PM > To: DRAGE, Keith (Keith); DOLLY, MARTIN C > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) > > On 6/30/15 09:39, DRAGE, Keith (Keith) wrote: >> You make this sound like MARTINI was originally meant to solve world hunger, and somehow got scoped down, which is untrue. > The MARTINI charter was silent on the issue of whether the AORs being registered were explicit or implicit. Making them implicit was a simplification, but not a necessary one. We could have been explicit about the AORs being registered and still been well within the charter. > > My point is that this simplification left a hole in the story, and that MODERN's work is well positioned to fill that hole. > > /a > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jun 30 09:48: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 518091ACED4 for ; Tue, 30 Jun 2015 09:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tBMlXRJdVgU for ; Tue, 30 Jun 2015 09:48:25 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7201B314E for ; Tue, 30 Jun 2015 09:46:16 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 8d7c2955.2b593ea72940.24572.00-2479.70352.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:46:16 +0000 (UTC) X-MXL-Hash: 5592c7d845926932-1f545c2227c865cf219f9847f9235f43aac5b446 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 2d7c2955.0.24497.00-2023.70043.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:46:12 +0000 (UTC) X-MXL-Hash: 5592c7d454f90891-5bc71e71a96fe6bf74b0ce519a89abb4bda7409e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGk9wD023049; Tue, 30 Jun 2015 12:46:10 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGk1MV022910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2015 12:46:03 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 16:45:44 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 12:45:44 -0400 From: "DOLLY, MARTIN C" To: Adam Roach , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAAPNd1YAAAFgggABGMQD//71Q8A== Date: Tue, 30 Jun 2015 16:45:43 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> <5592C754.4030502@nostrum.com> In-Reply-To: <5592C754.4030502@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.27.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Z/db6gtA c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=M2lCxREK3PIA:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=XAFQembCKUMA:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=7LuvcVR7d8UbGBnJIW8A:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:48:27 -0000 UmVnaXN0cmF0aW9uIHJlcXVlc3QgdG8gd2hhdD8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXSANClNlbnQ6IFR1 ZXNkYXksIEp1bmUgMzAsIDIwMTUgMTI6NDQgUE0NClRvOiBET0xMWSwgTUFSVElOIEM7IERSQUdF LCBLZWl0aCAoS2VpdGgpDQpDYzogbW9kZXJuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01vZGVy bl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0aW5n LCBFeHBvc2luZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0KDQpP biA2LzMwLzE1IDExOjMzLCBET0xMWSwgTUFSVElOIEMgd3JvdGU6DQo+IEFPUiBvZiB0aGUgZGV2 aWNlPyBPciB3aGF0Pw0KDQpBT1JzIChwbHVyYWwpIGFzc29jaWF0ZWQgd2l0aCB0aGUgUEJYIG1h a2luZyB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QuIA0KUmV2aWV3aW5nIHNlY3Rpb24gNCBvZiBS RkMgNjE0MCBtYXkgYmUgaWxsdXN0cmF0aXZlLg0KDQovYQ0KDQoNCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5j b21dDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgMTI6MzEgUE0NCj4gVG86IERSQUdF LCBLZWl0aCAoS2VpdGgpOyBET0xMWSwgTUFSVElOIEMNCj4gQ2M6IG1vZGVybkBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW01vZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBP cmRlcmluZywgRGlzdHJpYnV0aW5nLCBFeHBvc2luZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUg TnVtYmVycyAobW9kZXJuKQ0KPg0KPiBPbiA2LzMwLzE1IDA5OjM5LCBEUkFHRSwgS2VpdGggKEtl aXRoKSB3cm90ZToNCj4+IFlvdSBtYWtlIHRoaXMgc291bmQgbGlrZSBNQVJUSU5JIHdhcyBvcmln aW5hbGx5IG1lYW50IHRvIHNvbHZlIHdvcmxkIGh1bmdlciwgYW5kIHNvbWVob3cgZ290IHNjb3Bl ZCBkb3duLCB3aGljaCBpcyB1bnRydWUuDQo+IFRoZSBNQVJUSU5JIGNoYXJ0ZXIgd2FzIHNpbGVu dCBvbiB0aGUgaXNzdWUgb2Ygd2hldGhlciB0aGUgQU9ScyBiZWluZyByZWdpc3RlcmVkIHdlcmUg ZXhwbGljaXQgb3IgaW1wbGljaXQuIE1ha2luZyB0aGVtIGltcGxpY2l0IHdhcyBhIHNpbXBsaWZp Y2F0aW9uLCBidXQgbm90IGEgbmVjZXNzYXJ5IG9uZS4gV2UgY291bGQgaGF2ZSBiZWVuIGV4cGxp Y2l0IGFib3V0IHRoZSBBT1JzIGJlaW5nIHJlZ2lzdGVyZWQgYW5kIHN0aWxsIGJlZW4gd2VsbCB3 aXRoaW4gdGhlIGNoYXJ0ZXIuDQo+DQo+IE15IHBvaW50IGlzIHRoYXQgdGhpcyBzaW1wbGlmaWNh dGlvbiBsZWZ0IGEgaG9sZSBpbiB0aGUgc3RvcnksIGFuZCB0aGF0IE1PREVSTidzIHdvcmsgaXMg d2VsbCBwb3NpdGlvbmVkIHRvIGZpbGwgdGhhdCBob2xlLg0KPg0KPiAvYQ0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNb2Rlcm4gbWFpbGluZyBs aXN0DQo+IE1vZGVybkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21vZGVybg0KDQo= From nobody Tue Jun 30 09:49:32 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A16A1B31E9 for ; Tue, 30 Jun 2015 09:49:31 -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 wM09otKF3uap for ; Tue, 30 Jun 2015 09:49:25 -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 71B621B3203 for ; Tue, 30 Jun 2015 09:47:21 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5UGlHkg005369 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Jun 2015 11:47:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5592C815.600@nostrum.com> Date: Tue, 30 Jun 2015 11:47:17 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" , "DRAGE, Keith (Keith)" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> <5592C754.4030502@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:49:31 -0000 Section 4. RFC 6140. Read it. /a On 6/30/15 11:45, DOLLY, MARTIN C wrote: > Registration request to what? > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, June 30, 2015 12:44 PM > To: DOLLY, MARTIN C; DRAGE, Keith (Keith) > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) > > On 6/30/15 11:33, DOLLY, MARTIN C wrote: >> AOR of the device? Or what? > AORs (plural) associated with the PBX making the registration request. > Reviewing section 4 of RFC 6140 may be illustrative. > > /a > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, June 30, 2015 12:31 PM >> To: DRAGE, Keith (Keith); DOLLY, MARTIN C >> Cc: modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) >> >> On 6/30/15 09:39, DRAGE, Keith (Keith) wrote: >>> You make this sound like MARTINI was originally meant to solve world hunger, and somehow got scoped down, which is untrue. >> The MARTINI charter was silent on the issue of whether the AORs being registered were explicit or implicit. Making them implicit was a simplification, but not a necessary one. We could have been explicit about the AORs being registered and still been well within the charter. >> >> My point is that this simplification left a hole in the story, and that MODERN's work is well positioned to fill that hole. >> >> /a >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jun 30 09:49:40 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9451B31E9 for ; Tue, 30 Jun 2015 09:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs00iuQQTTK4 for ; Tue, 30 Jun 2015 09:49:31 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2D11ACE8D for ; Tue, 30 Jun 2015 09:47:41 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id c28c2955.0.131584.00-2065.377601.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:47:41 +0000 (UTC) X-MXL-Hash: 5592c82d0784ed74-d09b231e69f7a22723df09e6405ea2d492600f26 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGld3V024927; Tue, 30 Jun 2015 12:47:40 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGlYrL024863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2015 12:47:37 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 16:47:19 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 12:47:19 -0400 From: "DOLLY, MARTIN C" To: Cullen Jennings Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAATklAP//vk2w Date: Tue, 30 Jun 2015 16:47:19 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <,<5591F73A.90301@nostrum.com> <>> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.27.213] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Rqhy2laK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=M2lCxREK3PIA:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=8492oggXAA] X-AnalysisOut: [AA:8 a=e_dwzRaMbxjL5uXERswA:9 a=CjuIK1q_8ugA:10 a=p-ches9N] X-AnalysisOut: [26FnFVYL:21 a=NIFJ9l_2sN54q__9:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:49:32 -0000 Providing this information to whom? -----Original Message----- From: Cullen Jennings [mailto:fluffy@iii.ca]=20 Sent: Tuesday, June 30, 2015 12:41 PM To: DOLLY, MARTIN C Cc: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) > On Jun 29, 2015, at 7:00 PM, DOLLY, MARTIN C wrote: > Please explain the number assignment process=20 I think I would summarize that number assignment process as the entity wan= ting a number needs to provide account information to identify themselves. = And credit cards are a surprising strong form of that. Then the entity asks= for a number in a given area code.=20 I'll use AT&T API as an example but others are similar. Some nice docs at h= ttps://developer.att.com/sdks-plugins/enhanced-webrtc Roughly speaking the steps are: Create and account along with things like a credit card or way to bill=20 Request some phones numbers - you can specify what area codes you want Use your account info to get a OAuth2 token that is used for rest of reques= ts Optionally provide some E911 info for each number=20 Say where to to route incoming calls and / or sms to For the Tropo flow, you get a number simply by doing a HTTP post saying you= want a number and country / area code you want it in to a URL that manages= the addresses for your applications. You can see the doc at and it returns= the new number. The application is already associated with who to bill. M= ore docs at https://www.tropo.com/docs/rest/tutorials/adding-number-based-p= refix From nobody Tue Jun 30 09:50: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 7E25C1B3177 for ; Tue, 30 Jun 2015 09:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J_8OixTD9Sf for ; Tue, 30 Jun 2015 09:50:19 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0932F1B2A96 for ; Tue, 30 Jun 2015 09:50:18 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id bc8c2955.2b024aca4940.61038.00-2423.174616.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:50:19 +0000 (UTC) X-MXL-Hash: 5592c8cb452e82ba-b749148a1e45f278f21e35ba4dacbddb13d557c3 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 198c2955.0.60546.00-2275.173226.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:49:21 +0000 (UTC) X-MXL-Hash: 5592c8911c5ecc5e-e0f6ec71d8ff69289217088eb50d3c2a90c8f4e7 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGnLRh027580; Tue, 30 Jun 2015 12:49:21 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGnBnf027379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2015 12:49:15 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 16:48:56 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 12:48:55 -0400 From: "DOLLY, MARTIN C" To: Adam Roach , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAAPNd1YAAAFgggABGMQD//71Q8IAAQ5aA//+9FKA= Date: Tue, 30 Jun 2015 16:48:55 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> <5592C754.4030502@nostrum.com> <5592C815.600@nostrum.com> In-Reply-To: <5592C815.600@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.27.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=XshNzy59 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=M2lCxREK3PIA:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=XAFQembCKUMA:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=_6rfEya_2gGQXO208d4A:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:50:24 -0000 V2UgZGlkIG5vdCBzdXBwb3J0IHRoYXQgd29yay4gVGhpcyBpcyBuZXcgd29yaywgc28gcGxlYXNl IGV4cGxhaW4uIFRoYW5rIHlvdS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1 bmUgMzAsIDIwMTUgMTI6NDcgUE0NClRvOiBET0xMWSwgTUFSVElOIEM7IERSQUdFLCBLZWl0aCAo S2VpdGgpDQpDYzogbW9kZXJuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01vZGVybl0gW25ldy13 b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0aW5nLCBFeHBvc2lu ZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0KDQpTZWN0aW9uIDQu IFJGQyA2MTQwLiBSZWFkIGl0Lg0KDQovYQ0KDQpPbiA2LzMwLzE1IDExOjQ1LCBET0xMWSwgTUFS VElOIEMgd3JvdGU6DQo+IFJlZ2lzdHJhdGlvbiByZXF1ZXN0IHRvIHdoYXQ/DQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5v c3RydW0uY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAyMDE1IDEyOjQ0IFBNDQo+IFRv OiBET0xMWSwgTUFSVElOIEM7IERSQUdFLCBLZWl0aCAoS2VpdGgpDQo+IENjOiBtb2Rlcm5AaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtNb2Rlcm5dIFtuZXctd29ya10gV0cgUmV2aWV3OiBNYW5h Z2luZywgT3JkZXJpbmcsIERpc3RyaWJ1dGluZywgRXhwb3NpbmcsICYgUmVnaXN0ZXJpbmcgdGVs ZXBob25lIE51bWJlcnMgKG1vZGVybikNCj4NCj4gT24gNi8zMC8xNSAxMTozMywgRE9MTFksIE1B UlRJTiBDIHdyb3RlOg0KPj4gQU9SIG9mIHRoZSBkZXZpY2U/IE9yIHdoYXQ/DQo+IEFPUnMgKHBs dXJhbCkgYXNzb2NpYXRlZCB3aXRoIHRoZSBQQlggbWFraW5nIHRoZSByZWdpc3RyYXRpb24gcmVx dWVzdC4NCj4gUmV2aWV3aW5nIHNlY3Rpb24gNCBvZiBSRkMgNjE0MCBtYXkgYmUgaWxsdXN0cmF0 aXZlLg0KPg0KPiAvYQ0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KPj4gU2VudDogVHVlc2Rh eSwgSnVuZSAzMCwgMjAxNSAxMjozMSBQTQ0KPj4gVG86IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBE T0xMWSwgTUFSVElOIEMNCj4+IENjOiBtb2Rlcm5AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBb TW9kZXJuXSBbbmV3LXdvcmtdIFdHIFJldmlldzogTWFuYWdpbmcsIE9yZGVyaW5nLCBEaXN0cmli dXRpbmcsIEV4cG9zaW5nLCAmIFJlZ2lzdGVyaW5nIHRlbGVwaG9uZSBOdW1iZXJzIChtb2Rlcm4p DQo+Pg0KPj4gT24gNi8zMC8xNSAwOTozOSwgRFJBR0UsIEtlaXRoIChLZWl0aCkgd3JvdGU6DQo+ Pj4gWW91IG1ha2UgdGhpcyBzb3VuZCBsaWtlIE1BUlRJTkkgd2FzIG9yaWdpbmFsbHkgbWVhbnQg dG8gc29sdmUgd29ybGQgaHVuZ2VyLCBhbmQgc29tZWhvdyBnb3Qgc2NvcGVkIGRvd24sIHdoaWNo IGlzIHVudHJ1ZS4NCj4+IFRoZSBNQVJUSU5JIGNoYXJ0ZXIgd2FzIHNpbGVudCBvbiB0aGUgaXNz dWUgb2Ygd2hldGhlciB0aGUgQU9ScyBiZWluZyByZWdpc3RlcmVkIHdlcmUgZXhwbGljaXQgb3Ig aW1wbGljaXQuIE1ha2luZyB0aGVtIGltcGxpY2l0IHdhcyBhIHNpbXBsaWZpY2F0aW9uLCBidXQg bm90IGEgbmVjZXNzYXJ5IG9uZS4gV2UgY291bGQgaGF2ZSBiZWVuIGV4cGxpY2l0IGFib3V0IHRo ZSBBT1JzIGJlaW5nIHJlZ2lzdGVyZWQgYW5kIHN0aWxsIGJlZW4gd2VsbCB3aXRoaW4gdGhlIGNo YXJ0ZXIuDQo+Pg0KPj4gTXkgcG9pbnQgaXMgdGhhdCB0aGlzIHNpbXBsaWZpY2F0aW9uIGxlZnQg YSBob2xlIGluIHRoZSBzdG9yeSwgYW5kIHRoYXQgTU9ERVJOJ3Mgd29yayBpcyB3ZWxsIHBvc2l0 aW9uZWQgdG8gZmlsbCB0aGF0IGhvbGUuDQo+Pg0KPj4gL2ENCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBNb2Rlcm4gbWFpbGluZyBsaXN0DQo+ PiBNb2Rlcm5AaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW9kZXJuDQoNCg== From nobody Tue Jun 30 09:57:32 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D9F1B2A96 for ; Tue, 30 Jun 2015 09:57:31 -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 07pqxCklku37 for ; Tue, 30 Jun 2015 09:57:30 -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 EC08B1AD0B4 for ; Tue, 30 Jun 2015 09:57:29 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5UGvOV2006288 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Jun 2015 11:57:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5592CA74.1050408@nostrum.com> Date: Tue, 30 Jun 2015 11:57:24 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" , "DRAGE, Keith (Keith)" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> <5592C754.4030502@nostrum.com> <5592C815.600@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 16:57:31 -0000 As amusing as it might be to spoon-feed you the overview sections of various RFCs, I'm afraid that it's neither productive nor on-topic. If you have legitimate questions, you have pointers for finding the answers yourself. /a On 6/30/15 11:48, DOLLY, MARTIN C wrote: > We did not support that work. This is new work, so please explain. Thank you. > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, June 30, 2015 12:47 PM > To: DOLLY, MARTIN C; DRAGE, Keith (Keith) > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) > > Section 4. RFC 6140. Read it. > > /a > > On 6/30/15 11:45, DOLLY, MARTIN C wrote: >> Registration request to what? >> >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, June 30, 2015 12:44 PM >> To: DOLLY, MARTIN C; DRAGE, Keith (Keith) >> Cc: modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) >> >> On 6/30/15 11:33, DOLLY, MARTIN C wrote: >>> AOR of the device? Or what? >> AORs (plural) associated with the PBX making the registration request. >> Reviewing section 4 of RFC 6140 may be illustrative. >> >> /a >> >> >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> Sent: Tuesday, June 30, 2015 12:31 PM >>> To: DRAGE, Keith (Keith); DOLLY, MARTIN C >>> Cc: modern@ietf.org >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) >>> >>> On 6/30/15 09:39, DRAGE, Keith (Keith) wrote: >>>> You make this sound like MARTINI was originally meant to solve world hunger, and somehow got scoped down, which is untrue. >>> The MARTINI charter was silent on the issue of whether the AORs being registered were explicit or implicit. Making them implicit was a simplification, but not a necessary one. We could have been explicit about the AORs being registered and still been well within the charter. >>> >>> My point is that this simplification left a hole in the story, and that MODERN's work is well positioned to fill that hole. >>> >>> /a >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jun 30 10:00: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 DEBED1ACD63 for ; Tue, 30 Jun 2015 10:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT6i3kFKxiOj for ; Tue, 30 Jun 2015 10:00:16 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C791B2A96 for ; Tue, 30 Jun 2015 10:00:14 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id e1bc2955.2ad7e809f940.139318.00-2469.399818.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 30 Jun 2015 17:00:14 +0000 (UTC) X-MXL-Hash: 5592cb1e37ed784c-4f03e287382fd307658b695320e2c1286196bd42 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 9fac2955.0.138907.00-2211.398660.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 30 Jun 2015 16:59:37 +0000 (UTC) X-MXL-Hash: 5592caf90f9c3eb5-5c971a9ee55ba56a9eaf0ee81e7e395e83aa0067 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGxbiU009102; Tue, 30 Jun 2015 12:59:37 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5UGxTYr008944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2015 12:59:34 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jun 2015 16:59:19 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 12:59:19 -0400 From: "DOLLY, MARTIN C" To: Adam Roach , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53EjUcA//++LoyAAPNd1YAAAFgggABGMQD//71Q8IAAQ5aA//+9FKAACLf8AAAIWbfQ Date: Tue, 30 Jun 2015 16:59:18 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> <5592C754.4030502@nostrum.com> <5592C815.600@nostrum.com> <5592CA74.1050408@nostrum.com> In-Reply-To: <5592CA74.1050408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.27.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Rqhy2laK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=M2lCxREK3PIA:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=XAFQembCKUMA:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=gNz-pEmqDj1QK1uIQLIA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 17:00:18 -0000 SSBkbyBub3QgYmVsaWV2ZSB0aGF0IGlzIGluIHRoZSBjaGFydGVyIG9mIHRoaXMgZ3JvdXAgdGhl bi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkYW0gUm9hY2ggW21haWx0 bzphZGFtQG5vc3RydW0uY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgMTI6NTcg UE0NClRvOiBET0xMWSwgTUFSVElOIEM7IERSQUdFLCBLZWl0aCAoS2VpdGgpDQpDYzogbW9kZXJu QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01vZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1h bmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0aW5nLCBFeHBvc2luZywgJiBSZWdpc3RlcmluZyB0 ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0KDQpBcyBhbXVzaW5nIGFzIGl0IG1pZ2h0IGJlIHRv IHNwb29uLWZlZWQgeW91IHRoZSBvdmVydmlldyBzZWN0aW9ucyBvZiB2YXJpb3VzIFJGQ3MsIEkn bSBhZnJhaWQgdGhhdCBpdCdzIG5laXRoZXIgcHJvZHVjdGl2ZSBub3Igb24tdG9waWMuIElmIHlv dSBoYXZlIGxlZ2l0aW1hdGUgcXVlc3Rpb25zLCB5b3UgaGF2ZSBwb2ludGVycyBmb3IgZmluZGlu ZyB0aGUgYW5zd2VycyB5b3Vyc2VsZi4NCg0KL2ENCg0KT24gNi8zMC8xNSAxMTo0OCwgRE9MTFks IE1BUlRJTiBDIHdyb3RlOg0KPiBXZSBkaWQgbm90IHN1cHBvcnQgdGhhdCB3b3JrLiBUaGlzIGlz IG5ldyB3b3JrLCBzbyBwbGVhc2UgZXhwbGFpbi4gVGhhbmsgeW91Lg0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVt LmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSAxMjo0NyBQTQ0KPiBUbzogRE9M TFksIE1BUlRJTiBDOyBEUkFHRSwgS2VpdGggKEtlaXRoKQ0KPiBDYzogbW9kZXJuQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBbbmV3LXdvcmtdIFdHIFJldmlldzogTWFuYWdpbmcs IE9yZGVyaW5nLCBEaXN0cmlidXRpbmcsIEV4cG9zaW5nLCAmIFJlZ2lzdGVyaW5nIHRlbGVwaG9u ZSBOdW1iZXJzIChtb2Rlcm4pDQo+DQo+IFNlY3Rpb24gNC4gUkZDIDYxNDAuIFJlYWQgaXQuDQo+ DQo+IC9hDQo+DQo+IE9uIDYvMzAvMTUgMTE6NDUsIERPTExZLCBNQVJUSU4gQyB3cm90ZToNCj4+ IFJlZ2lzdHJhdGlvbiByZXF1ZXN0IHRvIHdoYXQ/DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0K Pj4gU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSAxMjo0NCBQTQ0KPj4gVG86IERPTExZLCBN QVJUSU4gQzsgRFJBR0UsIEtlaXRoIChLZWl0aCkNCj4+IENjOiBtb2Rlcm5AaWV0Zi5vcmcNCj4+ IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBbbmV3LXdvcmtdIFdHIFJldmlldzogTWFuYWdpbmcsIE9y ZGVyaW5nLCBEaXN0cmlidXRpbmcsIEV4cG9zaW5nLCAmIFJlZ2lzdGVyaW5nIHRlbGVwaG9uZSBO dW1iZXJzIChtb2Rlcm4pDQo+Pg0KPj4gT24gNi8zMC8xNSAxMTozMywgRE9MTFksIE1BUlRJTiBD IHdyb3RlOg0KPj4+IEFPUiBvZiB0aGUgZGV2aWNlPyBPciB3aGF0Pw0KPj4gQU9ScyAocGx1cmFs KSBhc3NvY2lhdGVkIHdpdGggdGhlIFBCWCBtYWtpbmcgdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0 Lg0KPj4gUmV2aWV3aW5nIHNlY3Rpb24gNCBvZiBSRkMgNjE0MCBtYXkgYmUgaWxsdXN0cmF0aXZl Lg0KPj4NCj4+IC9hDQo+Pg0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ IEZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KPj4+IFNlbnQ6IFR1 ZXNkYXksIEp1bmUgMzAsIDIwMTUgMTI6MzEgUE0NCj4+PiBUbzogRFJBR0UsIEtlaXRoIChLZWl0 aCk7IERPTExZLCBNQVJUSU4gQw0KPj4+IENjOiBtb2Rlcm5AaWV0Zi5vcmcNCj4+PiBTdWJqZWN0 OiBSZTogW01vZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywg RGlzdHJpYnV0aW5nLCBFeHBvc2luZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAo bW9kZXJuKQ0KPj4+DQo+Pj4gT24gNi8zMC8xNSAwOTozOSwgRFJBR0UsIEtlaXRoIChLZWl0aCkg d3JvdGU6DQo+Pj4+IFlvdSBtYWtlIHRoaXMgc291bmQgbGlrZSBNQVJUSU5JIHdhcyBvcmlnaW5h bGx5IG1lYW50IHRvIHNvbHZlIHdvcmxkIGh1bmdlciwgYW5kIHNvbWVob3cgZ290IHNjb3BlZCBk b3duLCB3aGljaCBpcyB1bnRydWUuDQo+Pj4gVGhlIE1BUlRJTkkgY2hhcnRlciB3YXMgc2lsZW50 IG9uIHRoZSBpc3N1ZSBvZiB3aGV0aGVyIHRoZSBBT1JzIGJlaW5nIHJlZ2lzdGVyZWQgd2VyZSBl eHBsaWNpdCBvciBpbXBsaWNpdC4gTWFraW5nIHRoZW0gaW1wbGljaXQgd2FzIGEgc2ltcGxpZmlj YXRpb24sIGJ1dCBub3QgYSBuZWNlc3Nhcnkgb25lLiBXZSBjb3VsZCBoYXZlIGJlZW4gZXhwbGlj aXQgYWJvdXQgdGhlIEFPUnMgYmVpbmcgcmVnaXN0ZXJlZCBhbmQgc3RpbGwgYmVlbiB3ZWxsIHdp dGhpbiB0aGUgY2hhcnRlci4NCj4+Pg0KPj4+IE15IHBvaW50IGlzIHRoYXQgdGhpcyBzaW1wbGlm aWNhdGlvbiBsZWZ0IGEgaG9sZSBpbiB0aGUgc3RvcnksIGFuZCB0aGF0IE1PREVSTidzIHdvcmsg aXMgd2VsbCBwb3NpdGlvbmVkIHRvIGZpbGwgdGhhdCBob2xlLg0KPj4+DQo+Pj4gL2ENCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE1vZGVy biBtYWlsaW5nIGxpc3QNCj4+PiBNb2Rlcm5AaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0KDQo= From nobody Tue Jun 30 10:19:35 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 5B4701B29C6 for ; Tue, 30 Jun 2015 10:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnrYbyoZx2A0 for ; Tue, 30 Jun 2015 10:19:33 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id BD86E1B29C5 for ; Tue, 30 Jun 2015 10:19:31 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Hill Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgAADLICAAAjPgIAADUkAgACPhwD//71EGYAABpAQgAA2JY8= Date: Tue, 30 Jun 2015 17:19:28 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <59171341-D615-4C10-9F1D-8B00D9755E2F@nostrum.com> <001901d0b2ea$af764700$0e62d500$@ch> , <8E3CE27E-B9D7-415E-9B74-14A3A553E124@nostrum.com> , <003901d0b33c$dd08b750$971a25f0$@ch> In-Reply-To: <003901d0b33c$dd08b750$971a25f0$@ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 17:19:34 -0000 This is not a set of documents - it's a mock-up of a distributed number all= ocation system (obviously, if you believe you actually obtained a number fr= om that system you can use for anything real, I also have a bridge nearby i= n Brooklyn that I'm happy to sell you).=0A= =0A= You'll need to request an account to get access to the sandbox; you get to = play-act a carrier number administrator. (I know that while others dreamed = as kids about being train engineers and fire fighters, members of this mail= ing list said in kindergarten "Dad, when I grow up, I want to assign teleph= one numbers.") We obviously can't just let anybody administer numbers...=0A= =0A= (Your) feedback is appreciated.=0A= =0A= The current mock-up model (which is a web implementation feature, not a pro= tocol one) is that there are consumer and OCN/carrier code admins. The form= er get to see information only about their number (such as a porting PIN), = the latter get to request numbers and update information for their OCN/carr= ier code.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Richard Hill [rhill@hill-a.ch]=0A= Sent: Tuesday, June 30, 2015 9:58 AM=0A= To: Henning Schulzrinne; 'Ben Campbell'; 'Peterson, Jon'=0A= Cc: modern@ietf.org; 'Adam Roach'; 'DOLLY, MARTIN C'=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= I agree with Henning's comments below (and thank him for the kind words).= =0A= =0A= But I'm not able to access the cited URL:=0A= =0A= http://e164.space=0A= =0A= It seems to be password protected. (Pity they have adopted some of the bad= =0A= features of the ITU.)=0A= =0A= Best,=0A= Richard=0A= From nobody Tue Jun 30 11:21: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 F31AA1B2ADB for ; Tue, 30 Jun 2015 11:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 ujJOY1tNR5T6 for ; Tue, 30 Jun 2015 11:21:09 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id B31F41B2AD8 for ; Tue, 30 Jun 2015 11:21:09 -0700 (PDT) Received: (qmail 1472 invoked by uid 0); 30 Jun 2015 18:21:07 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 30 Jun 2015 18:21:07 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id mnu81q0041MNPNq01nuB1F; Tue, 30 Jun 2015 17:54:15 -0600 X-Authority-Analysis: v=2.1 cv=UNFOQkvy c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=8uNZ9Cuh11P-BKsXmXsA:9 a=39PGrlj3Vmk5E2bW:21 a=MoAp1aeHQtg-IYX9:21 a=wPNLvfGTeEIA: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:CC:To:From:Subject:Date; bh=ZX5s+M7cq0Wb5ghO6/zEabOotT/JtuAjKY1hG8p1/kc=; b=JJIkRzuEpi07TVHevEso+fmar0WuvmYp+6V7xt0L4V8FOZPLb35KvVKfwJg/c3gOEPyPmhK5zbn400l9UhRQi2xRQRUNiRHiDQRxw4fZ92clHtUmAGkChH5csItPBLHF; Received: from [100.36.26.202] (port=62852 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z9zq8-0002Fl-7f; Tue, 30 Jun 2015 12:01:00 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Tue, 30 Jun 2015 14:00:55 -0400 From: Richard Shockey To: Adam Roach , "DRAGE, Keith (Keith)" , "DOLLY, MARTIN C" Message-ID: Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> In-Reply-To: <5592C45B.9030105@nostrum.com> 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 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 18:21:11 -0000 Adam MARTINI was exactly the kind of problem Keith described "is about isolating a solveable problem and solving it.=B2 This entire enterprise has all of the charisticts of ending world hunger which means its deployability within the 21 Century is questionable. On 6/30/15, 12:31 PM, "Modern on behalf of Adam Roach" wrote: >On 6/30/15 09:39, DRAGE, Keith (Keith) wrote: >> You make this sound like MARTINI was originally meant to solve world >>hunger, and somehow got scoped down, which is untrue. > >The MARTINI charter was silent on the issue of whether the AORs being >registered were explicit or implicit. Making them implicit was a >simplification, but not a necessary one. We could have been explicit >about the AORs being registered and still been well within the charter. > >My point is that this simplification left a hole in the story, and that >MODERN's work is well positioned to fill that hole. > >/a > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jun 30 11:40: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 8F5101B2B08 for ; Tue, 30 Jun 2015 11:40:37 -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 8ELd7lYqZlDs for ; Tue, 30 Jun 2015 11:40:36 -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 34A181B2B01 for ; Tue, 30 Jun 2015 11:40:35 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , Richard Hill , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3BOpEAgAB25ACAAeEWFIAByDAAgAAJeWQ= Date: Tue, 30 Jun 2015 18:40:33 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <000601d0b168$06723ed0$1356bc70$@ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 18:40:37 -0000 [snipping a lot]=0A= =0A= I don't see the contradiction. I think the symbiotic relationship between t= he two is being discussed at the IETF "plenary" level (both literally as a = lunch talk in Dallas and more as "across the leadership"). Unless you just = want to leave the protocol formats to whoever decides to build the first op= en source implementation and then everybody reverse-engineering the on-the-= wire bits, there has to be a spec somewhere and I'd rather have such specs = developed with the input of domain experts such as yourself and Richard or = the operational input of people working for carriers.=0A= =0A= There's an interesting article on this topic at=0A= =0A= https://www.internetsociety.org/sites/default/files/Journal_March%202.pdf= =0A= =0A= I do believe that this work would make good material for the IETF Hackathon= in the future, possibly in conjunction with some of the WebRTC work.=0A= =0A= ________________________________________=0A= From: Richard Shockey [richard@shockey.us]=0A= Sent: Tuesday, June 30, 2015 9:57 AM=0A= =0A= =0A= Well at what point is this actually an open source vs a open=0A= standards/protocol=0A= effort? It strikes me the former vs that latter.=0A= From nobody Tue Jun 30 11:49: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 190881B2C3C for ; Tue, 30 Jun 2015 11:49:36 -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 Opxr4fRiWLHZ for ; Tue, 30 Jun 2015 11:49:32 -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 A04571B2C33 for ; Tue, 30 Jun 2015 11:49:31 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7A== Date: Tue, 30 Jun 2015 18:49:30 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com>, <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 18:49:36 -0000 I think of the phone number as a key into a logical (not necessarily physic= al) database with a variety of fields (and a change log), some that are nea= r-universal and others that are highly-specific to countries, use cases or = even companies. We do the same for domain names, e.g., technical and admini= strative contacts or for DHCP, where an IP address is associated with a set= of service records (e.g., for a SIP proxy, LIS or LoST server in our techn= ical neighborhood).=0A= =0A= Much of that information exists already and is in the AT&T and Tropos APIs,= the LNPA or LERG. Examples include:=0A= =0A= * OCN/carrier code (some kind of assignment identifier is probably unavoida= ble)=0A= * number state (available, locked, etc.)=0A= * reachability (URLs)=0A= * cryptographic keying materials=0A= =0A= All but the first and maybe second are likely to be optional. As usual, the= re would be suitable extension points, e.g., to accommodate storing 911 add= ress information that only makes sense in certain relationships (not for th= e LNPA, but for a carrier-customer relationship). All the usual stuff appli= es that the veterans in this group do by rote: IANA considerations, privacy= considerations, security considerations, ...=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of DRAGE, Keith (Keith) [k= eith.drage@alcatel-lucent.com]=0A= Sent: Tuesday, June 30, 2015 9:50 AM=0A= To: Adam Roach; DOLLY, MARTIN C=0A= Cc: modern@ietf.org=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= First of all, Jons presentation has no status (it was one of a number of pr= esentations made at the meeting as to a single individuals view of what mig= ht be useful); what matters is the charter.=0A= =0A= However what is clear to me is that we have no consensus agreement on what = this group is meant to be doing or what the charter actually means. Otherwi= se this discussion would not be occurring.=0A= =0A= At the simplest it appears to me that people were stating a data model wher= e a telephone number is associated with a specific owner, and nothing more = than that.=0A= =0A= However if you dive into various people's proposed use cases, it appears th= at more than that is envisaged. So for example to run any enterprise system= , that telephone number would need to be assocated with various other data = either:=0A= =0A= - in the end device itself, that controls how that telephone number f= its with the functions that the end device provides, any security certifica= tes, or relates to other identifiers in the device; and/or=0A= =0A= - in some server belonging to the enterprise where the end users serv= ice policy is policed, and added functionality may also be provided.=0A= =0A= Now the first bullet above is device configuration, and the second bullet a= bove is network management.=0A= =0A= So I believe some people are talking as if the problem MODERN is meant to s= olve also includes device configuration and network management, as I have d= escribed above, and that is certainly considerably more that a simple alloc= ation problem.=0A= =0A= So which is it? In this new protocol, what data model will the end point of= the protocol end up with?=0A= =0A= Keith=0A= =0A= > -----Original Message-----=0A= > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach=0A= > Sent: 30 June 2015 04:27=0A= > To: DOLLY, MARTIN C=0A= > Cc: modern@ietf.org=0A= > Subject: Re: [Modern] [new-work] WG Review: Managing,=0A= > Ordering, Distributing, Exposing, & Registering telephone=0A= > Numbers (modern)=0A= >=0A= > We discussed this exact use case in Dallas. From Jon's presentation:=0A= >=0A= > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06=0A= > -29%2022.12.37.png?dl=3D0=0A= >=0A= > It's also described in the charter. In fact, it's really the=0A= > main thrust of the work: the charter repeatedly talks about=0A= > acquiring, managing, and resolving TNs. This is the "acquring" part.=0A= >=0A= > So now, as I'm reflecting on it, I'm a little confused about=0A= > what *you* think MODERN will be doing. Perhaps whatever=0A= > you're worried about isn't actually happening.=0A= >=0A= > /a=0A= >=0A= >=0A= > On 6/29/15 21:24, DOLLY, MARTIN C wrote:=0A= > > How is that applicable? Scope question?=0A= > >=0A= > > Sent from my iPhone=0A= > >=0A= > >> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote:=0A= > >>=0A= > >> In this context, there isn't one.=0A= > >>=0A= > >> MARTINI was predicated on a continuation of having VISPs=0A= > do excruciatingly manual things like emailing -- or in some=0A= > cases faxing -- spreadsheets to their customers detailing=0A= > number ranges. I think I still have the one I got from our=0A= > VISP back in the Estacado days when I was running our PBX. I=0A= > can dig it up and forward it to you if you really don't know=0A= > how number assignment works at that level. Basically, it's a=0A= > lot of human reading and human typing. If you're lucky, you=0A= > don't have to get a fax machine involved, so you can at least=0A= > copy and paste.=0A= > >>=0A= > >> But emailing or faxing spreadsheets around is a brutally=0A= > primitive and error-prone way to get this kind of thing done.=0A= > I'm a little surprised it took this long for anyone to make a=0A= > serious run at some standardized form of automation.=0A= > >>=0A= > >> /a=0A= > >>=0A= > >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote:=0A= > >>> Please explain the number assignment process=0A= > >>>=0A= > >>> Sent from my iPhone=0A= > >>>=0A= > >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach=0A= > wrote:=0A= > >>>>>=0A= > >>>>> On 6/29/15 20:19, Cullen Jennings wrote:=0A= > >>>>> I think private network case is already happening.=0A= > There are more and more PBX that integrate with cloud=0A= > providers such as Tropo or Twillio to get phone numbers using=0A= > a simple API.=0A= > >>>> And, really, ever since we ruled this out of scope for=0A= > MARTINI, it's been a pretty big gap in SIP PBX deployments.=0A= > >>>>=0A= > >>>> /a=0A= > >>>>=0A= > >>>> _______________________________________________=0A= > >>>> Modern mailing list=0A= > >>>> Modern@ietf.org=0A= > >>>> https://www.ietf.org/mailman/listinfo/modern=0A= > >>> _______________________________________________=0A= > >>> Modern mailing list=0A= > >>> Modern@ietf.org=0A= > >>> https://www.ietf.org/mailman/listinfo/modern=0A= >=0A= > _______________________________________________=0A= > Modern mailing list=0A= > Modern@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/modern=0A= >=0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= From nobody Tue Jun 30 13:08: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 2D0911B2CC5 for ; Tue, 30 Jun 2015 13:08: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 0zBNliQ8sDcU for ; Tue, 30 Jun 2015 13:08:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57001B2CBA for ; Tue, 30 Jun 2015 13:08:19 -0700 (PDT) Received: from BN1BFFO11FD050.protection.gbl (10.58.144.34) by BN1BFFO11HUB042.protection.gbl (10.58.144.189) with Microsoft SMTP Server (TLS) id 15.1.201.10; Tue, 30 Jun 2015 20:08:02 +0000 Authentication-Results: spf=temperror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of sprint.com: DNS Timeout) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1BFFO11FD050.mail.protection.outlook.com (10.58.145.5) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Tue, 30 Jun 2015 20:08:00 +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 t5UK7Hxc002833; Tue, 30 Jun 2015 15:07:59 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 1v9sm1wd5q-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Jun 2015 15:07:59 -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, 30 Jun 2015 16:07:57 -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, 30 Jun 2015 15:07:57 -0500 From: "Gorman, Pierce A [CTO]" To: Adam Roach , "DOLLY, MARTIN C" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLMEwQ50yu6z0i1W6uAK8HRwp3EngsAgAABPICAAARggIAAAjqAgAARrACAAL3x4A== Date: Tue, 30 Jun 2015 20:07:56 +0000 Message-ID: <871bd27710eb49b495aa1971e67b44ac@PLSWE13M08.ad.sprint.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> In-Reply-To: <55920CA0.1070104@nostrum.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; BN1BFFO11FD050; 1:x7wYog6OemWmydkBNDve7aUYzgal0y/D7BbKwrTETaAcBsrW8gwLYA1loVp7QO/NeNd+RVjeZxc3hjdzloaK6tfBdcBS0Da3K3iqhuClxuYmGqqS4uJdkx04A9dKlF7EjjSxoLAWlp2ak15DrUkxuVnTqVQU+HzqpYsscbsLBcli6kgMX2PA1vqgSENi5AkGkWxbkLuQZ18xhLWoKR2QCukx6Ih78BoUJFwiC0Fx5xIQKJVoeoBA8nwXzD1P7r8ywoD3IptTZ4AV2PJfPHeyTVwv8+viRdt3fDAp6MhxwYygympyGhxEmCvF0+G5BR+J X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(377454003)(199003)(24454002)(13464003)(189002)(479174004)(51704005)(47776003)(85326001)(64706001)(50466002)(97756001)(108616004)(93886004)(33646002)(2656002)(86362001)(87936001)(106466001)(76176999)(54356999)(50986999)(23726002)(5003630100001)(77156002)(62966003)(5003600100002)(106116001)(4001540100001)(5001770100001)(97736004)(81156007)(5001830100001)(5001860100001)(5250100002)(2950100001)(2900100001)(68736005)(15975445007)(102836002)(189998001)(92566002)(24736003)(5001960100002)(46406003)(46102003)(19580405001)(19580395003)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB042; H:plsapdm2.corp.sprint.com; FPR:; SPF:TempError; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB042; 2:lpkwQcIYoLmGBQEvecHwUvuEvYIei5ZQpSx3ZFchS1tzjES8KNw4ULn/H0hHl6LF; 3:DsrH/bKATGH7m4W7FhKNxd+QMktJEE+bhv6qtr9yIM80zvgPIJjyBWnnTZe8StB7Q8vi3Bf3WRYFzA0LuMpZOkAreK8Nra8uqF9CBQ1Beb9BZjswLx21ukyPQ1MdQz8++3XIZtX9KypZTveouz21oQypZug54nA+KxDDgbZcdVq29IHfSXZqkiU4rmTueoOW65XonEdoPcOr/nlJtu59bqTlDz3xuJHT1wVzb1AenPMpsiIEPFfNt95Tgyy9lLXd; 20:nTzbv4Gqwl8sG/ZLMZ+5e4SVNrOTS3sj9AE2qCwK11s7okMNt+SgG0sO4IgXvRO1lyHQ6xEGm/Hpqpd2fXN1Thgk2uuEROoWcEtWfVnmKuYu/gF9u6TwezHdfnVTucwLT1VIEoFjsZCpT1n86oE1NVG0tnNUA1MKHbpSisxsq5i0ONe6sZJPPqnXBLxzNgvYELvekNpeniqgz0GuHOYQ//D3QVb7py/qhydXgDoEMHj1Ofh/mUr5J0g/RnLXgMEB; 4:GRLMB9vhgx0pkWulSbRuC/rN7tzZgeAy1qXLzliCxWiXaGDO0AxvPdZ3KUB8fqssI+e5UK0FxCyzfbXhrX4V7JHp0cmG29L3CacNl+n39q3SQnW6oGq7iNcrbSSKUlY9pQZkcrqKrAH0XyeGw7UVhXVIFHcCMIRezO7fSs923UvHiABp1tB0xwZ2CTyit0/9fWNtKz+d5WRklT0D0wbXnwTlOWlaDc+GZpSxBSQXpjOI7FuDoHeqftOiWvVqy4NZrkP6Uo1OS7OPre06O2dIV0di80HD445I4BqDiOAdwpk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB042; 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:BN1BFFO11HUB042; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB042; X-Forefront-PRVS: 06237E4555 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB042; 23:jZKtgak641QYllvYY/ww+neASu58DT37A0XBaOG?= =?us-ascii?Q?F/bjXudFlJuQr3fWa8aDK6vASyLLoZqWBvI/0P54APrmAG4b4F3sjJuNIjJJ?= =?us-ascii?Q?OwAE5RTMSUYpOQuSwYV/CuZf+8XkdJKF4Y585sJwZ2mC+sJ73mNDvGw67SR8?= =?us-ascii?Q?omXVSU339NTIL6vpsJrPnp1CnCoRrqTPFpSBluBRk8x/uPZ4TFJ1Wi+59kmU?= =?us-ascii?Q?NUuLl9L+fW94tVkiDIVFFAH+UJoAJ3nGsOYFSV67zHT9Q3TzKoOkqJNWLLIk?= =?us-ascii?Q?MUlv9ONOSEkVT4HYVWgxX6TMVjpJX2KB0qathxCt+xpN4Fb+N79ogx2o6k2U?= =?us-ascii?Q?k4ISeYcgrexzMp7bkyPI36Ltnv399VuBos3xWlNesimMrU+1qMnofUKl3L7V?= =?us-ascii?Q?xnnmRBOWY1BK0RNNRcYoxobe753KS/YXRy0B/JsMX5Ifp54PPvB+VX0yYvj2?= =?us-ascii?Q?vHhVuhS77BDjye+7f23CTZg6/cKB1aJmNaGkFLJ++5iehXoMTaAPs9vUU14u?= =?us-ascii?Q?BdAqfhl9fqkqC/BrFe6C0w7XmTBVOpPXa3G0kEPH3s11fdXz/AXc5ja+0Ql8?= =?us-ascii?Q?saU+sWBGaxvnBRN9uv35h/KhYPQBCD6bgVwix58YzmgRXs30OA0NvWBSoIG3?= =?us-ascii?Q?HI+Humepqiwsy7+yU2P2I5QnrFU5CSRfaG5XeageeH8DBeQhR6CBEfz6kZyA?= =?us-ascii?Q?dXGSxP1LfDML2amF2RcV8pLHD7Jno1/gVwis405P/qryhP2MNplyWp+4Oc+J?= =?us-ascii?Q?gP77PU0caHxGEo7TiLrmvx6tZP9gOLQIUOJPseUBjvG2Nn2DT2aqp2E9iq/Z?= =?us-ascii?Q?KYh4HY97HHLFYpNCSrUxPsgTWQb78Iz1Cepvg4g80CHM9WZzVyMzVtj/QwUu?= =?us-ascii?Q?TamU15jBopl3vNYDwh7Jqp5MR08yuyF2yancMVp9RpoSrVsP2ihk6StTTNhZ?= =?us-ascii?Q?mK9WQFPx46Uu/SIJcK5LJ0UhE37HUPzaIY0gi6MMBksYSLPj9RMJ26kEgySU?= =?us-ascii?Q?x3AqvgZoVyGUYSmv/iKDJxcYp1IG5woFT0sp97aIOQFQW+0Y93DIGPyFsCn2?= =?us-ascii?Q?CmBju+hZol0BvHs/AQKME6V9zzP9Cb62LcgvjecKCo3V2Q/5UgYPB9q9dOy9?= =?us-ascii?Q?EC/S1hfZW2RayYpXikfzZfvAn05LLiBHTYWhaYL+j2DgSJEkSti/3Kc6dOQ/?= =?us-ascii?Q?28isLuw1j4SZHCMBm0HB3kzd04V1YKUW6OpvNCyNSVC2pZ4cnsxtd1kFSRAL?= =?us-ascii?Q?P0fhGNeJUP4NZBirAtYV64JoLkqZNwrvqpSMfa8QB0uNryLm5po4u4PEXtzX?= =?us-ascii?Q?VM/OIaHvk6yNBpgYvJNjsfar9CtAthZggKqDuwheenDhGN3Xy32DPv6mDlRj?= =?us-ascii?Q?M34ZewQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB042; 5:K3TFHtp2d0rM0Jq16jTOwb6S/te+joFlsfK0MLB0lz2PUrKvqk/GS2lBLbFgZB5tiBaruXwiT4OBHE0oQ2Eg6PjDfTNSWLIHTx/KbZUHeihFdPOOwcvBbzjAFNJfIjuUtiCRjM3NnDjbA4DE0T+a2A==; 24:OUu2hell1oNg4dCU3VkhRf+cMe0pfrNSyzMdo8tbubqGbaOJwolYqciRUncz34H/N3+MLezYXwQBY5ziIrQcxjB79Ao9JIx80Qdx3oGCvr0= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2015 20:08:00.3406 (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: BN1BFFO11HUB042 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 20:08:25 -0000 Adam, The IP PBX use case that Cullen Jennings documented is sensible, but also s= mall scale, and if that was all the MODERN charter proposed to do, then the= re would probably be no lack of consensus (as compared to where we are in r= eality). The reality is if that was all MODERN would attempt, then its leading propo= nents would be very dissatisfied. Some are frustrated with the existing multi-database and multi-regulatory o= rganizational structure of number and routing information management in car= rier-based telecommunications and believe they see a possibility to bypass = this situation through a protocol and data model (of a super-database?) wor= k effort in the IETF. Apparently this is a political and commerical matter= with the emphasis on the former. As witness to this, it has been said on this reflector that " The LNPA pain= . . . . . is the transition, after a competitive bidding process, between t= he previous contracted number management entity and the new one. Having eng= ineering options that bypass or minimize such disputes, should an NRA want = to avail themselves of those, is one interest . . . " I'm sympathetic to your and the other proponents' interests, but remain unc= onvinced of the IETF approach being invoked here through fiat. So, while the work of MODERN is aimed to solve certain [relatively minor?] = specific allocation implementation issues: 1. This may not represent the overwhelming interests of current or fu= ture operators; & 2. Specifically MODERN must consider application to the current archi= tectures used for allocation, management, & use of E.164 resource, includin= g LERG, NPAC, Point Code Data, and SMS800 in the US. 3. IETF should formally liaise with those major national & internatio= nal bodies that support the allocation, administration & usage of numbering= data bases including ITU, NANC, LNPA WG, INC, and the FoN; both before the= WG is activated, & to help steer its work. 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 Adam Roach Sent: June 29, 2015 10:27 PM To: DOLLY, MARTIN C Cc: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) We discussed this exact use case in Dallas. From Jon's presentation: https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-29%2022.12.3= 7.png?dl=3D0 It's also described in the charter. In fact, it's really the main thrust of= the work: the charter repeatedly talks about acquiring, managing, and reso= lving TNs. This is the "acquring" part. So now, as I'm reflecting on it, I'm a little confused about what *you* thi= nk MODERN will be doing. Perhaps whatever you're worried about isn't actual= ly happening. /a On 6/29/15 21:24, DOLLY, MARTIN C wrote: > How is that applicable? Scope question? > > Sent from my iPhone > >> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: >> >> In this context, there isn't one. >> >> MARTINI was predicated on a continuation of having VISPs do excruciating= ly manual things like emailing -- or in some cases faxing -- spreadsheets = to their customers detailing number ranges. I think I still have the one I = got from our VISP back in the Estacado days when I was running our PBX. I c= an dig it up and forward it to you if you really don't know how number assi= gnment works at that level. Basically, it's a lot of human reading and huma= n typing. If you're lucky, you don't have to get a fax machine involved, so= you can at least copy and paste. >> >> But emailing or faxing spreadsheets around is a brutally primitive and e= rror-prone way to get this kind of thing done. I'm a little surprised it to= ok this long for anyone to make a serious run at some standardized form of = automation. >> >> /a >> >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>> Please explain the number assignment process >>> >>> Sent from my iPhone >>> >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: >>>>> >>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>> I think private network case is already happening. There are more and= more PBX that integrate with cloud providers such as Tropo or Twillio to g= et phone numbers using a simple API. >>>> And, really, ever since we ruled this out of scope for MARTINI, it's b= een a pretty big gap in SIP PBX deployments. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> 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 Tue Jun 30 13:30: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 5E2191B2DB2 for ; Tue, 30 Jun 2015 13:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y60-Dv4KhVXv for ; Tue, 30 Jun 2015 13:30:35 -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 BB8001B2DB6 for ; Tue, 30 Jun 2015 13:30:35 -0700 (PDT) Received: (qmail 20159 invoked by uid 0); 30 Jun 2015 20:30:35 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 30 Jun 2015 20:30:35 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id mq3b1q01M1MNPNq01q3eHc; Tue, 30 Jun 2015 20:03:43 -0600 X-Authority-Analysis: v=2.1 cv=UNFOQkvy c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=1ibwJlUuAAAA:8 a=DISpKC50CELNn-cLeZ4A:9 a=e28ZlARh9XFBEd6o:21 a=zO3DnHU3WelysuMj:21 a=wPNLvfGTeEIA: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=NrWpzW672RKSaRYsi7qPf8ygWbC1mxPz+7syELZd7QA=; b=O4e3Cw3wxw4ej0Q/rDitwZrzoHNKID1/6mEc8XHLxBhNQmpMApTv0cPoufTOrlFflNRnsu9kZxnwnNgYZYn3V0Pz8SdPTDGA9epd9YOVJNjg626AtVMGkzg4n8rX0Zl7; Received: from [100.36.26.202] (port=64186 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZA1rP-0005DV-Tr; Tue, 30 Jun 2015 14:10:28 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Tue, 30 Jun 2015 16:10:23 -0400 From: Richard Shockey To: Henning Schulzrinne , Richard Hill , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <000601d0b168$06723ed0$1356bc70$@ch> 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 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 20:30:37 -0000 Fair point.=20 I was thinking about the WebRTC work but at the rate that is progressing we=B9ll see the Chicago Cubs win the World Series before its done.=20 On 6/30/15, 2:40 PM, "Modern on behalf of Henning Schulzrinne" wrote: >[snipping a lot] > >I don't see the contradiction. I think the symbiotic relationship between >the two is being discussed at the IETF "plenary" level (both literally as >a lunch talk in Dallas and more as "across the leadership"). Unless you >just want to leave the protocol formats to whoever decides to build the >first open source implementation and then everybody reverse-engineering >the on-the-wire bits, there has to be a spec somewhere and I'd rather >have such specs developed with the input of domain experts such as >yourself and Richard or the operational input of people working for >carriers. > >There's an interesting article on this topic at > >https://www.internetsociety.org/sites/default/files/Journal_March%202.pdf > >I do believe that this work would make good material for the IETF >Hackathon in the future, possibly in conjunction with some of the WebRTC >work. > >________________________________________ >From: Richard Shockey [richard@shockey.us] >Sent: Tuesday, June 30, 2015 9:57 AM > > >Well at what point is this actually an open source vs a open >standards/protocol >effort? It strikes me the former vs that latter. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jun 30 13:32: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 9F89D1B2E04 for ; Tue, 30 Jun 2015 13:32:17 -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 6eL0IIsbBJfo for ; Tue, 30 Jun 2015 13:32:14 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03E1B2DBE for ; Tue, 30 Jun 2015 13:31:55 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" , Adam Roach , "DOLLY, MARTIN C" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgAEXhwD//8EwEA== Date: Tue, 30 Jun 2015 20:31:53 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com>, <871bd27710eb49b495aa1971e67b44ac@PLSWE13M08.ad.sprint.com> In-Reply-To: <871bd27710eb49b495aa1971e67b44ac@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 20:32:17 -0000 This is not a huge community - an overlapping set of people participate in = all of the organizations you mention. As important as formal liaisons are t= he informal outreach activities that all of us participate in, whether wear= ing a hat of a certain color or shape, or otherwise. I've been trying to ma= ke sure INC and NANC/FON are kept in the loop and hope that others will do = the same, both within their own organization (since most large carriers hav= e representatives in those bodies) and externally.=0A= =0A= My experience has been that concrete (strawman) proposals and questions get= the most useful answers from external organizations, as long as everybody = is willing to reconsider their initial notions and ideas. The sooner we can= get to the gory (and boring) details, the sooner we'll make progress - or = figure out that the problem is not amenable to an IETF solution.=0A= =0A= As discussed during the FCC workshop, if the MODERN effort is successful, I= suspect that legacy databases will continue to exist as interfaces, making= it largely invisible to those carriers who prefer things to remain as-is.= =0A= =0A= Henning=0A= =0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A [CTO] = [Pierce.Gorman@sprint.com]=0A= Sent: Tuesday, June 30, 2015 4:07 PM=0A= To: Adam Roach; DOLLY, MARTIN C=0A= Cc: modern@ietf.org=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Adam,=0A= =0A= The IP PBX use case that Cullen Jennings documented is sensible, but also s= mall scale, and if that was all the MODERN charter proposed to do, then the= re would probably be no lack of consensus (as compared to where we are in r= eality).=0A= =0A= The reality is if that was all MODERN would attempt, then its leading propo= nents would be very dissatisfied.=0A= =0A= Some are frustrated with the existing multi-database and multi-regulatory o= rganizational structure of number and routing information management in car= rier-based telecommunications and believe they see a possibility to bypass = this situation through a protocol and data model (of a super-database?) wor= k effort in the IETF. Apparently this is a political and commerical matter= with the emphasis on the former.=0A= =0A= As witness to this, it has been said on this reflector that " The LNPA pain= . . . . . is the transition, after a competitive bidding process, between t= he previous contracted number management entity and the new one. Having eng= ineering options that bypass or minimize such disputes, should an NRA want = to avail themselves of those, is one interest . . . "=0A= =0A= I'm sympathetic to your and the other proponents' interests, but remain unc= onvinced of the IETF approach being invoked here through fiat.=0A= =0A= So, while the work of MODERN is aimed to solve certain [relatively minor?] = specific allocation implementation issues:=0A= 1. This may not represent the overwhelming interests of current or fu= ture operators; &=0A= 2. Specifically MODERN must consider application to the current archi= tectures used for allocation, management, & use of E.164 resource, includin= g LERG, NPAC, Point Code Data, and SMS800 in the US.=0A= 3. IETF should formally liaise with those major national & internatio= nal bodies that support the allocation, administration & usage of numbering= data bases including ITU, NANC, LNPA WG, INC, and the FoN; both before the= WG is activated, & to help steer its work.=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Core Network Planning=0A= O: 913-439-4368=0A= pierce.gorman@sprint.com=0A= =0A= =0A= -----Original Message-----=0A= From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach=0A= Sent: June 29, 2015 10:27 PM=0A= To: DOLLY, MARTIN C=0A= Cc: modern@ietf.org=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= We discussed this exact use case in Dallas. From Jon's presentation:=0A= =0A= https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-29%2022.12.3= 7.png?dl=3D0=0A= =0A= It's also described in the charter. In fact, it's really the main thrust of= the work: the charter repeatedly talks about acquiring, managing, and reso= lving TNs. This is the "acquring" part.=0A= =0A= So now, as I'm reflecting on it, I'm a little confused about what *you* thi= nk MODERN will be doing. Perhaps whatever you're worried about isn't actual= ly happening.=0A= =0A= /a=0A= =0A= =0A= On 6/29/15 21:24, DOLLY, MARTIN C wrote:=0A= > How is that applicable? Scope question?=0A= >=0A= > Sent from my iPhone=0A= >=0A= >> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote:=0A= >>=0A= >> In this context, there isn't one.=0A= >>=0A= >> MARTINI was predicated on a continuation of having VISPs do excruciating= ly manual things like emailing -- or in some cases faxing -- spreadsheets = to their customers detailing number ranges. I think I still have the one I = got from our VISP back in the Estacado days when I was running our PBX. I c= an dig it up and forward it to you if you really don't know how number assi= gnment works at that level. Basically, it's a lot of human reading and huma= n typing. If you're lucky, you don't have to get a fax machine involved, so= you can at least copy and paste.=0A= >>=0A= >> But emailing or faxing spreadsheets around is a brutally primitive and e= rror-prone way to get this kind of thing done. I'm a little surprised it to= ok this long for anyone to make a serious run at some standardized form of = automation.=0A= >>=0A= >> /a=0A= >>=0A= >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote:=0A= >>> Please explain the number assignment process=0A= >>>=0A= >>> Sent from my iPhone=0A= >>>=0A= >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote:=0A= >>>>>=0A= >>>>> On 6/29/15 20:19, Cullen Jennings wrote:=0A= >>>>> I think private network case is already happening. There are more and= more PBX that integrate with cloud providers such as Tropo or Twillio to g= et phone numbers using a simple API.=0A= >>>> And, really, ever since we ruled this out of scope for MARTINI, it's b= een a pretty big gap in SIP PBX deployments.=0A= >>>>=0A= >>>> /a=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> Modern mailing list=0A= >>>> Modern@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/modern=0A= >>> _______________________________________________=0A= >>> Modern mailing list=0A= >>> Modern@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/modern=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= =0A= From nobody Tue Jun 30 14:01: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 E86321B3272 for ; Tue, 30 Jun 2015 14:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7oSOR1aS97Nn for ; Tue, 30 Jun 2015 14:01:32 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2B91B323A for ; Tue, 30 Jun 2015 14:01:32 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 23043215AF for ; Tue, 30 Jun 2015 17:01:25 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 30 Jun 2015 17:01:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=EhMfx IgP1z4TTikyH/vYcWnvAQE=; b=R3/1UECqfQlC/YIniA25LarCIl1Msa/p5LbYi 7zovKlkp4D22SJ3q3UN7IGWCIIj+pDkDZpZQU65cM7SlyD0uc3zyoOq0d4NOns6w 6u11/AJap2qiP39/1Wuqy0GMx45bUIl6NqKjXLZkYj6MEYKnlN3w+blLH1yJsHW2 Bqv2UU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=EhMfxIgP1z4TTikyH/vYcWnvAQE=; b=fpXhd wGnFP/7JEiAoPqhERxIQ+q6Uhergyb6CNqp3FnLavwhuYuPxyYfp+WnDt9X0HPGm 4IsLXPlpbgQ7Ugx3Eu8KINvIC4uFt9t3OhsNwsSbm1iJJm62tMiMyTk9AR1bFlkk UtIbqvVT1rpz6X6EwBOy4z6zGsw2Oj4veb5LAs= X-Sasl-enc: od41is9OKtBO6g8vkj/rPla0Di2fXmAiG8SB8+TVkaMT 1435698085 Received: from dhcp-171-68-20-84.cisco.com (unknown [171.68.20.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 169E6C00296 for ; Tue, 30 Jun 2015 17:01:24 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_07831812-7A2A-484B-840A-4EB20C4F2E28" Message-Id: <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 30 Jun 2015 14:01:21 -0700 References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> To: modern@ietf.org In-Reply-To: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) 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, 30 Jun 2015 21:01:34 -0000 --Apple-Mail=_07831812-7A2A-484B-840A-4EB20C4F2E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92d like to ask that each person participating in this discussion = remember to be respectful of one another=92s points of view and focus on = constructive dialogue. If you feel that you=92re wasting cycles on the = current threads then feel free to change the subject to something more = productive; likewise if you feel someone else is wasting your cycles, = don=92t feel compelled to respond. To review the process that got us to the current point: The conclusion from the BoF in Dallas was that there was rough consensus = in the room in support of forming the WG but that the charter and = problem scope needed refinement (feel free to review the minutes: = http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That = process of refinement took place on this list over several months = following the BoF. The charter was put out for review on June 12 with = comments requested to be sent to the IESG by June 22. The IESG = considered the two ITU-T related comments received (both after the = deadline) and issued no blocking comments on the charter but asked that = edits be considered on the basis of comments received. There were no = other comments received or indications provided to the IESG about the = readiness of this work for chartering. I=92m still working on edits = (Richard Hill pointed out that I missed his suggestions) and milestones = are in the works as well. Thus this WG is being formed according to the = usual process. Alissa= --Apple-Mail=_07831812-7A2A-484B-840A-4EB20C4F2E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92d like to ask that each = person participating in this discussion remember to be respectful of one = another=92s points of view and focus on constructive dialogue. If you = feel that you=92re wasting cycles on the current threads then feel free = to change the subject to something more productive; likewise if you feel = someone else is wasting your cycles, don=92t feel compelled to = respond.

To review the process that got us to the = current point:

The conclusion from the BoF in = Dallas was that there was rough consensus in the room in support of = forming the WG but that the charter and problem scope needed refinement = (feel free to review the minutes: http= ://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That = process of refinement took place on this list over several months = following the BoF. The charter was put out for review on June 12 with = comments requested to be sent to the IESG by June 22. The IESG = considered the two ITU-T related comments received (both after the = deadline) and issued no blocking comments on the charter but asked that = edits be considered on the basis of comments received. There were no = other comments received or indications provided to the IESG about the = readiness of this work for chartering. I=92m still working on edits = (Richard Hill pointed out that I missed his suggestions) and milestones = are in the works as well. Thus this WG is being formed according to the = usual process.

Alissa
= --Apple-Mail=_07831812-7A2A-484B-840A-4EB20C4F2E28--