Yes, but such a green field space can, and has been, implemented on = the PSTN, so the use of an all IP solution is=A0 not a requirement. = =A0Whereas your draft implies that it is, unless I misunderstood = something.

Best,

Richard

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, = Tom
Sent: jeudi, 25. f=E9vrier 2016 15:42
To: = 'Modern List'
Subject: Re: [Modern] Nationwide Number = Portability MODERN Use Case Draft

The point is, it is a green field numbering space within a country. = These concepts would apply to any green field numbering space. = And it is a use case, it just so happens to be based on a proposal = in the USA, it could have been proposed anywhere and it would still be a = use case.

From: Richard Hill <rhill@hill-a.ch>
Date: = Thursday, February 25, 2016 4:25 AM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>, = Modern List <modern@ietf.org>
Subject: = RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

The abstract states “While this focuses on an effort = occurring in the USA the concepts are applicable to any = country.”

I think that it would be better to change that to “This focuses = on an effort occurring in the USA; but the concepts may be applicable to = other countries.”

I say this because non-geographic numbers have already been = implemented in other countries, on the PSTN, without the use of = IP-networks, whereas the Introduction of the draft states that = non-geographic numbers “would be hosted on an all-IP network = of switches called non-geographic gateways (NGGW), rather than the = existing TDM tandems operated by the incumbent local = exchange carriers (ILECs).”

Separately, I still wonder whether it is appropriate for the IETF, = which is supposed to be a global entity, to develop a protocol that is = apparently of interest to the USA only.

Best,

Richard

= From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier = 2016 02:18
To: Modern List
Subject: [Modern] = Nationwide Number Portability MODERN Use Case Draft

http://www.ietf.org/id/draft-mc= garry-nnp-use-case-00.txt

------=_NextPart_000_00CE_01D16FE3.7BD6F780-- From nobody Thu Feb 25 06:57:03 2016 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 3A3A71AD218 for ; Thu, 25 Feb 2016 06:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cMOJ1MgueJPV for ; Thu, 25 Feb 2016 06:56:59 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EA41AD277 for ; Thu, 25 Feb 2016 06:56:59 -0800 (PST) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1PEqJx8012632 for ; Thu, 25 Feb 2016 09:56:59 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 219kyda7e4-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 25 Feb 2016 09:56:58 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.131]) by stntexhc10.cis.neustar.com ([169.254.4.23]) with mapi id 14.03.0279.002; Thu, 25 Feb 2016 09:56:56 -0500 From: "McGarry, Tom" To: "'Modern List'" Thread-Topic: [Modern] Nationwide Number Portability MODERN Use Case Draft Thread-Index: AQHRb2pm7PDoPWgGMEWIEhdbfE2ttZ88e5hwgABbCQCAAAB2AIAAA5cA Date: Thu, 25 Feb 2016 14:56:56 +0000 Message-ID: In-Reply-To: <00cd01d16fdb$1a128f80$4e37ae80$@ch> 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.96] Content-Type: multipart/alternative; boundary="_000_D2F480443507Dtommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602250215 Archived-At: Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft 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 Feb 2016 14:57:01 -0000 --_000_D2F480443507Dtommcgarryneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No, it is just one "proposed" solution. From: Richard Hill > Date: Thursday, February 25, 2016 9:44 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft Yes, but such a green field space can, and has been, implemented on the PST= N, so the use of an all IP solution is not a requirement. Whereas your dr= aft implies that it is, unless I misunderstood something. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 15:42 To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft The point is, it is a green field numbering space within a country. These = concepts would apply to any green field numbering space. And it is a use c= ase, it just so happens to be based on a proposal in the USA, it could have= been proposed anywhere and it would still be a use case. From: Richard Hill > Date: Thursday, February 25, 2016 4:25 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft The abstract states =93While this focuses on an effort occurring in the US= A the concepts are applicable to any country.=94 I think that it would be better to change that to =93This focuses on an eff= ort occurring in the USA; but the concepts may be applicable to other count= ries.=94 I say this because non-geographic numbers have already been implemented in = other countries, on the PSTN, without the use of IP-networks, whereas the I= ntroduction of the draft states that non-geographic numbers =93would be hos= ted on an all-IP network of switches called non-geographic gateways (NGGW)= , rather than the existing TDM tandems operated by the incumbent local exc= hange carriers (ILECs).=94 Separately, I still wonder whether it is appropriate for the IETF, which is= supposed to be a global entity, to develop a protocol that is apparently o= f interest to the USA only. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 02:18 To: Modern List Subject: [Modern] Nationwide Number Portability MODERN Use Case Draft http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt --_000_D2F480443507Dtommcgarryneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

No, it is just one "proposed" solution.

From: Richard Hill <rhill@hill-a.ch>
Date: Thursday, February 25, 2016 9= :44 AM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>, Modern List &l= t;modern@ietf.org>
Subject: RE: [Modern] Nationwide Nu= mber Portability MODERN Use Case Draft

Yes, but such a green field space = can, and has been, implemented on the PSTN, so the use of an all IP solutio= n is not a requirement. Whereas your draft implies that it is, unless I misunderstood something.

Best,

Richard

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 15:42
To: 'Modern List'
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

The point is, it is a green field numbering= space within a country. These concepts would apply to any green fiel= d numbering space. And it is a use case, it just so happens to be based on a proposal in the USA, it could have bee= n proposed anywhere and it would still be a use case.

From: Richard Hill <rhill= @hill-a.ch>
Date: Thursday, February 25, 2016 4:25 AM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>, Modern List <modern@ietf.org>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

The abstract states =93While this&= nbsp; focuses on an effort occurring in the USA the concepts are appl= icable to any country.=94

I think that it would be better to= change that to =93This focuses on an effort occurring in the USA; but the = concepts may be applicable to other countries.=94

I say this because non-geographic = numbers have already been implemented in other countries, on the PSTN, with= out the use of IP-networks, whereas the Introduction of the draft states that non-geographic numbers =93would = be hosted on an all-IP network of switches called non-geographic gate= ways (NGGW), rather than the existing TDM tandems operated by the inc= umbent local exchange carriers (ILECs).=94

Separately, I still wonder whether= it is appropriate for the IETF, which is supposed to be a global entity, t= o develop a protocol that is apparently of interest to the USA only.=

Best,

Richard

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 02:18
To: Modern List
Subject: [Modern] Nationwide Number Portability MODERN Use Case Draf= t

http:/= /www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt

--_000_D2F480443507Dtommcgarryneustarbiz_-- From nobody Thu Feb 25 08:28:22 2016 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 309EE1B2CB4 for ; Thu, 25 Feb 2016 08:28:21 -0800 (PST) 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 5dPXF01gCKmJ for ; Thu, 25 Feb 2016 08:28:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39FF1B2CB0 for ; Thu, 25 Feb 2016 08:28:14 -0800 (PST) Received: from BN1AFFO11FD038.protection.gbl (10.58.52.32) by BN1AFFO11HUB039.protection.gbl (10.58.52.150) with Microsoft SMTP Server (TLS) id 15.1.422.5; Thu, 25 Feb 2016 16:27:56 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1AFFO11FD038.mail.protection.outlook.com (10.58.52.242) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Thu, 25 Feb 2016 16:27:55 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u1PFQeKA027914; Thu, 25 Feb 2016 10:27:55 -0600 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm3.corp.sprint.com with ESMTP id 216p9b8jw9-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Feb 2016 10:27:55 -0600 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.1076.9; Thu, 25 Feb 2016 10:27:54 -0600 Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Thu, 25 Feb 2016 10:27:53 -0600 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , 'Modern List' Thread-Topic: [Modern] Nationwide Number Portability MODERN Use Case Draft Thread-Index: AQHRb2pm7PDoPWgGMEWIEhdbfE2ttZ88e5hwgABbCQCAAAB2AIAAA5cAgAAUeeA= Date: Thu, 25 Feb 2016 16:27:52 +0000 Message-ID: <68346e41454447f1b75d61da4c51821b@PLSWE13M08.ad.sprint.com> References: <00cd01d16fdb$1a128f80$4e37ae80$@ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.20] Content-Type: multipart/alternative; boundary="_000_68346e41454447f1b75d61da4c51821bPLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CPI:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(51444003)(189002)(377454003)(199003)(5001770100001)(561944003)(19625215002)(2906002)(4546004)(107886002)(5001960100002)(19300405004)(19617315012)(5250100002)(30436002)(33646002)(24736003)(5004730100002)(6806005)(5008740100001)(19580395003)(19580405001)(3846002)(790700001)(300700001)(2950100001)(11100500001)(86362001)(87936001)(106116001)(575784001)(16236675004)(1220700001)(1096002)(189998001)(512934002)(92566002)(102836003)(2900100001)(586003)(106466001)(76176999)(50986999)(15975445007)(54356999)(108616004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB039; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD038; 1:OEXz1ft+G59WZwOeQNzdzgHH1jiegIwshmss+pIMx6B8tiwR7npdvA+A/Ju3NIMNGdbvUsU8LRRQACpug7LBj+fUopxcgAm5SvJZSs2OjisKyMwkW1VLosWACwO6jQ2O1gybr9UC8UlAMGseoCF69y87Ep6MLCD28s2LQT5lkqEmSnwEeqX/ueosAie0KlpGiLLCvOfyTv4Jr3YiYzn8usgkJpuOffKHkrgWlE7LT33CeKgp/SYVtlWGdBAfrdnnDiyuBGUi14NVt4cSEaszjVmx5X9iuk0y5DhDUZecpeNSwUefjyg2Z6rED3FmyTQqBuhig4P6ciG7xbq/wU2627Ga8IQ4qaaM0oaA6oJ3+lEvngu3yfuGMIJPuvjdoTWLjgERXY/a1oKA5oDC/VKsbilwj3jEXBoKEOLabBtGTavPPRverKMmG4n313/ZQcFY77KIGDbibzLSYvhoZ9RLnQ== X-MS-Office365-Filtering-Correlation-Id: 0d4f6813-634c-42f8-b34f-08d33e009dd3 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB039; 2:UnspnPxfc/A5CcrHsTYRTZMN5ReMlnv6P7AWOYBLEsUZOId2xpfrc5p8BqBZN9IRZGKvihCrvvfmcc1SLYbt5s71XgMSmKjVN0niGF53x0RYBE8SZHmlX9WWtnpDwCSBSbkWN3Egk+EIu5unRS9BsLMMl5RVT6HZ5yGPhq2htpQp/b+ll+FynsSjDAV1rVOP; 3:8MFuiUjiRTRxvjzGj1ScV9mcKGi2RaX58hDR8wmSm2fEQW6Eb88kvo1AS6iWolfhbDoxXZzdQWUAel9ecwJZ145UmwJMnR9NK7XB/l0ETT5BBGOkUfB2zcxCrVrK+qEsY8cNCcdmPobGSE8EG2rdN7s19bxn22L9c371n/BD+c85rpYtMI8vuseQS3RhUz4IXOlab1wHdWpn9w1sBzJJ8w==; 25:mKdIUjORniE75l6+mlOM+S6DY7xIq5i4ZAhcL/lsfDSWuo3z20dtdqARZBmfQj4t+UonYyDE7iCPHnc6ZrvNEjp04o9R5fV04pW9dCDbckhJRHQAUsW5c5toEi4vwOwTIKtqiOfHXmX0XNBSj8hifTLsr3llITDW79hXndRKNXzomUq0OpxJHACaRnwQC430ptlzfSf1FXBhdJTGr1Bhaxif5GhQaMjvBqyyZ7OOSkt1D8OiIEHfXlfjJUtEmXZJmuACgAcV68Aa9jCnUlMtE1U44bhPB43P0PMrOUpuJo4rrd4wV6XYbQ2KfUQfnI/xd9/YNTatJRZHCwf9xGAgCNx1k04N+kh8lP8QC/Tl8653ZRmwXklFH4t8WsiKR9OqSMLc5VIalTuiTBhfKEQwqxVRoAQHmddi3/YQd1K2wkI= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB039; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB039; 20:yuAvnZR62n1xn5VHIyWw11U1q5hFLbI5hrS94tby0YsohastAPyCOqqTTmBG58vbxFQktYTiYwasong1avQ+Z/95BzSM0/sNcaBdFXbFAEt0+L6o4mo4Z1NMvvhNysMOZRZuk3Dz6igZ6dwomC/02cultLmDFMzoIJ9visOJPZ8iZ9MKhPNh0Qb7p5w7j5iiMs5HYGpw9aQhYRvGLi/SZ3eU4H95vx2Se+xcXT1VxY2TtYSVzfgpI2lqKRxlrPfl; 4:GINL4lWkf7bp/zKQUDBnb7H5c8YLIAfhMlGcUAAQ5UNaqwVm/Cxso0ytJ9bX5UwzZxYDaGO4jfHf9sXwCU46SiyrQMTAcGn0QNpf97kqrLPb/FWlGbPwPBgW8T6APBiE3ld0TWhWpmLxiO4asUXpr29ooZZ9Vu4R6CExnjHA/oaqIfm6T//VGqAqOYKAgouOtEXkrmLENV5jXb88XToK97U2T4ZNqUrtcAGT7qF2X8R7qHjNudHUc/Wz17VruQZZKJws0aTukXUJ2fXUNT3B943vYEhAD0y0Vb2wy75eLfuwupx6/FjruVNkH4x+GyVimBrUV1Iz5tQTsPwaxF1SRCqQ0H7THWM4V/EcvaOR4+qk7YsxZS4XVv05cjmCEIvjo/fZMLJvx6pDZIsp61h4q5ZXznDIZIcDb87MzmxryUnYWmBCCDLwmIkguKbOZnFKd/eZPkdM1KTNHZMEmG3m9w== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13018025)(13015025)(5005006)(13017025)(13023025)(13024025)(10201501046)(3002001); SRVR:BN1AFFO11HUB039; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB039; X-Forefront-PRVS: 08635C03D4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB039; 23:VUSWrHBpB7GzhIDwxgr/FJunasEpTjq0Z/TV3rv?= =?us-ascii?Q?KovmOYIcsoVPEowHYYkmKjss53F1PCmSRkVqe1Ql/myGeAqZKr3e7KVzGjJd?= =?us-ascii?Q?8Q8+q3Hu8YlY+aeaqkIWXdmIpzKBC39Da0DBHy7XdZKvohCw/aZ7FGHQEltG?= =?us-ascii?Q?Mf7C1oUgcI2xbhWRKJfwQbu62XWVbjNXp83daewfSfci0fNthKAy4/rjcyRa?= =?us-ascii?Q?f+62oFq0zFE5qo+OU2dJJWeF7SgsSlpkEsj9CJ5m78U1LAyBZ3WtQLwB2AOW?= =?us-ascii?Q?18PJPUZwZKz7yAHOnV23YbV/j0OQuop97TgNMPxz/hoF+lEfK7Xox3PTC+qR?= =?us-ascii?Q?+o8YBm2emCOPaclHZJ2wCDoJIwXoQIkvMRisSYHWRVgmXiA9umNPxEWFBMga?= =?us-ascii?Q?wnBWxSyVUHjtGG+PlfaqViFAlJxypkJus3xO5eziiTPgEHyK7Y6L6e1jeA2L?= =?us-ascii?Q?QSHGTcEfRMftsvEh5NzpQi8f/f5qBcTxtQwr5DnGY8qwjHboUbybDT85fDOi?= =?us-ascii?Q?NjVpxPpYaktL7lft9xcoza95VkpxGrlNjFC7LUTf4wT44JErr3nARHYgXkzV?= =?us-ascii?Q?SW/y9MgHXa7j4njF5RnYmMXbIWHOsiIFpEu6M6qM3ERuHuDsxeXTtirllS7o?= =?us-ascii?Q?OPm9V3poybb6rj0V5iRxjTF4BtMET8SfHdBMGCIsCjgFIavE2A6usYNTBFqT?= =?us-ascii?Q?y4onPlOuQGZAzkN/1TcQxDSPutCYMnGBdkvRisiJ6l1kZh0W7NA5OSqB+wFO?= =?us-ascii?Q?AbFACwyNVmKo4NnGx4VsMwV/tw/QG0sIxoqa/kgnqi9wbNzg0+8LzlJPkT7H?= =?us-ascii?Q?TtGjEzyT1ctJQ4xuu+nsnDkxcbb1+rsIoq//6fFcbj44kvjJCM1eiRtYPEcG?= =?us-ascii?Q?BdFFIxXlgSWMuWo3jNaMW9Q8ssig5Wx8VOzqAw7jW6hFHjHW3eoNmZJmeIcH?= =?us-ascii?Q?PBWDmgVuA2dS7DkogiON868fp8/IkN+3cTjfDoESWsOlMXy7kBCEWmQDF6FS?= =?us-ascii?Q?vTgRWUge16AZlKJ6rP+Y+qgQll6GQ77b53Ch46XrZBinz3xCq/ZggQK3yrij?= =?us-ascii?Q?2LuroqcbPZSL9MRUX1TyT3sjIrDNoRyDP2CDpqTc8nypV0biIGyjbUgymCD9?= =?us-ascii?Q?gBjdt1ARkl4CXMwbq+mN9MrVIDRIhiXIgOG3y1EnLtgcNlhi8MTlVk/MMTYj?= =?us-ascii?Q?Mx6nj4wTq5mgcBPF6Fo8x3S8AqtQdpeKpsJsDcImTbts0HWAMPpNBoou57g6?= =?us-ascii?Q?aNOzg0ETZ87ylXf0IjrKzE9wgyVGzN/lzmvPSRza8?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB039; 5:cQDZoUT1AAMX53eawWJxkkvCvdDZ6Zh3DGy9CnlOEUOoDkZEttyJit0W1Qs5zWOt2NQ6gN0MPNPG+/H2TCjqCVrH3uLJjaFYvQp8MIjfI7c4rue/Y/6OHI5JuMNYtQ1EghqhzhAGOQiDHtcVyqv1Hw==; 24:wFpH5vkM6AC8Y8+ZlHfkh38tfs87XP5JPR4oEB9Sk/RA67TxvIFCTyR/+NERSS3oyqtybiQOp8wJsFhecZ7onNjquU30YdCAdzENpodwT3I= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2016 16:27:55.6318 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB039 Archived-At: Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft 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 Feb 2016 16:28:21 -0000 --_000_68346e41454447f1b75d61da4c51821bPLSWE13M08adsprintcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "One way to enable NNP is to remove the NPAC edit and allow the TN and RN t= o be in different geographic areas... It's been reported that a call of this type in certain older technology swi= tches will fail. If so, then new software would have to be developed for t= hese switches to implement this solution." I feel like I've been transported back in time to read e-mails offering "te= chnical" reasons why number portability is challenging or impossible. Can the claim starting, "It's been reported.." be substantiated with a refe= rence? As an editorial comment, I'll offer I was confused by references to "NXX-NX= X". From the context, I assume you actually meant NPA-NXX. Do I assume co= rrectly? I agree with those who question whether the transition to IP drives a need = for new number management solutions. >From my last response to the MODERN "problem statement"... "The MODERN problem statement is in fact a TN management solution framework= . i.e., a solution looking for a problem. If there is a problem that MODERN addresses, it is the inability of end use= rs to directly (through a protocol) manage requisition and release of TNs a= nd manage their associated metadata. This is not a protocol problem. It i= s a policy problem (if it is a problem at all). And the only provisioning = protocol I remember seeing referenced in the solution statement is a SIP RE= GISTER. In this, MODERN is hardly any different then TRIP and equally usef= ul. My main recommendation is to scrap the so-called problem statement and star= t over. Do not introduce any text that even resembles a solution framework= . The problems can then be easily identified and discussed. And I encoura= ge discussion of policy as part of the problem so that in the end you can h= opefully clearly differentiate between issues that are political and issues= which are technical and therefore appropriate for the MODERN WG." Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: February 25, 2016 8:57 AM To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft No, it is just one "proposed" solution. From: Richard Hill > Date: Thursday, February 25, 2016 9:44 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft Yes, but such a green field space can, and has been, implemented on the PST= N, so the use of an all IP solution is not a requirement. Whereas your dr= aft implies that it is, unless I misunderstood something. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 15:42 To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft The point is, it is a green field numbering space within a country. These = concepts would apply to any green field numbering space. And it is a use c= ase, it just so happens to be based on a proposal in the USA, it could have= been proposed anywhere and it would still be a use case. From: Richard Hill > Date: Thursday, February 25, 2016 4:25 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft The abstract states "While this focuses on an effort occurring in the USA = the concepts are applicable to any country." I think that it would be better to change that to "This focuses on an effor= t occurring in the USA; but the concepts may be applicable to other countri= es." I say this because non-geographic numbers have already been implemented in = other countries, on the PSTN, without the use of IP-networks, whereas the I= ntroduction of the draft states that non-geographic numbers "would be hoste= d on an all-IP network of switches called non-geographic gateways (NGGW), = rather than the existing TDM tandems operated by the incumbent local excha= nge carriers (ILECs)." Separately, I still wonder whether it is appropriate for the IETF, which is= supposed to be a global entity, to develop a protocol that is apparently o= f interest to the USA only. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 02:18 To: Modern List Subject: [Modern] Nationwide Number Portability MODERN Use Case Draft http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt ________________________________ 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_68346e41454447f1b75d61da4c51821bPLSWE13M08adsprintcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

“One way to enable NNP is to remove th= e NPAC edit and allow the TN and RN to be in different geographic areas…

It's been reported that a call of this type in certain older tec= hnology switches will fail. If so, then new software would have to be= developed for these switches to implement this solution.”

I feel like I’ve been transported= back in time to read e-mails offering “technical” reasons why = number portability is challenging or impossible.

Can the claim starting, “It’= ;s been reported..” be substantiated with a reference?

As an editorial comment, I’ll off= er I was confused by references to “NXX-NXX”. From the co= ntext, I assume you actually meant NPA-NXX. Do I assume correctly?

I agree with those who question whether= the transition to IP drives a need for new number management solutions.

From my last response to the MODERN = 220;problem statement”…

“The MODERN p= roblem statement is in fact a TN management solution framework. i.e.,= a solution looking for a problem.

If there is a problem = that MODERN addresses, it is the inability of end users to directly (throug= h a protocol) manage requisition and release of TNs and manage their associ= ated metadata. This is not a protocol problem. It is a policy problem (if it is a problem at all). A= nd the only provisioning protocol I remember seeing referenced in the solut= ion statement is a SIP REGISTER. In this, MODERN is hardly any differ= ent then TRIP and equally useful.

My main recommendation= is to scrap the so-called problem statement and start over. Do not i= ntroduce any text that even resembles a solution framework. The probl= ems can then be easily identified and discussed. And I encourage discussion of policy as part of the problem so that in the= end you can hopefully clearly differentiate between issues that are politi= cal and issues which are technical and therefore appropriate for the MODERN= WG.= ”

Pierce

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of McGarry, Tom
Sent: February 25, 2016 8:57 AM
To: 'Modern List' <modern@ietf.org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

No, it is just one "proposed"= solution.

From: Richard Hill <rhill@hill-a.ch>
Date: Thursday, February 25, 2016 9:44 AM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>, Modern List <modern@ietf.org>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

Yes, but such a green field space can= , and has been, implemented on the PSTN, so the use of an all IP solution i= s not a requirement. Whereas your draft implies that it is, unless I misunderstood something.

Best,

Richard

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 15:42
To: 'Modern List'
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

The point is, it is a green field numbe= ring space within a country. These concepts would apply to any green = field numbering space. And it is a use case, it just so happens to be based on a proposal in the USA, it could have been propos= ed anywhere and it would still be a use case.

From: Richard Hill <rhill@hill-a.ch>
Date: Thursday, February 25, 2016 4:25 AM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>, Modern List <modern@ietf.org>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

The abstract states “While this= focuses on an effort occurring in the USA the concepts are app= licable to any country.”

I think that it would be better to ch= ange that to “This focuses on an effort occurring in the USA; but the= concepts may be applicable to other countries.”

I say this because non-geographic num= bers have already been implemented in other countries, on the PSTN, without= the use of IP-networks, whereas the Introduction of the draft states that non-geographic numbers “would be hosted on = an all-IP network of switches called non-geographic gateways (NGGW), = rather than the existing TDM tandems operated by the incumbent local = exchange carriers (ILECs).”<= o:p>

Separately, I still wonder whether it= is appropriate for the IETF, which is supposed to be a global entity, to d= evelop a protocol that is apparently of interest to the USA only.

Best,

Richard

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 02:18
To: Modern List
Subject: [Modern] Nationwide Number Portability MODERN Use Case Draf= t

ht= tp://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt

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_68346e41454447f1b75d61da4c51821bPLSWE13M08adsprintcom_-- From nobody Thu Feb 25 08:46:23 2016 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 75DDB1B2C73 for ; Thu, 25 Feb 2016 08:46:15 -0800 (PST) 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, 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 tnWIWZYPmp52 for ; Thu, 25 Feb 2016 08:46:03 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655891B2D8E for ; Thu, 25 Feb 2016 08:46:03 -0800 (PST) Received: from BL2FFO11FD007.protection.gbl (10.173.160.34) by BL2FFO11HUB039.protection.gbl (10.173.160.245) with Microsoft SMTP Server (TLS) id 15.1.422.5; Thu, 25 Feb 2016 16:46:01 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Thu, 25 Feb 2016 16:46:01 +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 u1PGeb6K048104; Thu, 25 Feb 2016 10:46:01 -0600 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm1.corp.sprint.com with ESMTP id 216pnh0naq-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Feb 2016 10:46:01 -0600 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 25 Feb 2016 11:45:59 -0500 Received: from PLSWE13M01.ad.sprint.com ([fe80::5440:326b:eaea:697e]) by PLSWE13M01.ad.sprint.com ([fe80::5440:326b:eaea:697e%24]) with mapi id 15.00.1076.000; Thu, 25 Feb 2016 10:45:59 -0600 From: "Holmes, David W [CTO]" To: "Gorman, Pierce A [CTO]" , "McGarry, Tom" , 'Modern List' Thread-Topic: [Modern] Nationwide Number Portability MODERN Use Case Draft Thread-Index: AQHRb2pm7PDoPWgGMEWIEhdbfE2ttZ88e5hwgABbCQCAAAB2AIAAA5cAgAAUeeCAAAWi8A== Date: Thu, 25 Feb 2016 16:45:58 +0000 Message-ID: <3af9e40382f34867bd866707fc4b1ce9@PLSWE13M01.ad.sprint.com> References: <00cd01d16fdb$1a128f80$4e37ae80$@ch> <68346e41454447f1b75d61da4c51821b@PLSWE13M08.ad.sprint.com> In-Reply-To: <68346e41454447f1b75d61da4c51821b@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.92] Content-Type: multipart/alternative; boundary="_000_3af9e40382f34867bd866707fc4b1ce9PLSWE13M01adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD007; 1:kc4Dt+5CBOYT6RB7kL0SDqrrCFnXl4/MJT/dopxkMiB+DgRTeXwZt1KPeTBRIWJjcn5K4wxwZ+LQF2cncpVOGFo6z0TD7P+ThjPaneGiOixMrcL6Jhjv+m0IINPY9e/jEYfdG1DQIU5+8Nv6sdbn3fXD7u+xJHIhODSgfoO73qlDd52RqEsXJigoCrJBSNdoHfIXlJT3IacvIpJljj5EcEozjMu1hGOaIJWpq4ThmzUG47cU3U/kSf1PNiLyhQzCQ0WudGfUOcpbCd+8NOFlLaSze320R9jJ6WSnyXFj/vFU/61crg2vLBKbVqnrePL1NllsZ+vFWpU7x49JKLECmd7C74NnjJF/PJRRDdmT+yW2JbAfCWApk/E4A0mI4maYiTYzzcu7TqWfRnWjWqZmGi5pYQe5A8+BfxpD8Fpi7f0= X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(189002)(51444003)(199003)(377454003)(189998001)(108616004)(16236675004)(106466001)(106116001)(586003)(19617315012)(5001960100002)(107886002)(87936001)(33646002)(1220700001)(2950100001)(2900100001)(6806005)(19300405004)(3846002)(512934002)(5008740100001)(15975445007)(102836003)(11100500001)(1096002)(300700001)(54356999)(86362001)(2906002)(92566002)(19580405001)(4546004)(575784001)(5004730100002)(19580395003)(5001770100001)(50986999)(76176999)(790700001)(30436002)(24736003)(561944003)(19625215002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB039; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-MS-Office365-Filtering-Correlation-Id: 51b611f9-23b3-4a55-d80f-08d33e032518 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB039; 2:NmnXKv3t7R9HsVa+F8yDR3IUH43Hg+zWoCC7XWxhrHX3Wse6bNLcfjWrr2V4VtZDV9Xecc5Fp06ZvSAFXJfE3xr91XJpEa+PRgUUZng1R9j2FVGLYjgQjmnMib5lU9K58DJs1O4zLXHuXqzGo5ay28CkzaddUlGDEyw9Hdk/qcv+lWvruEVoVKkhxMi3guzL; 3:oXLJNrAPI0H0mzCK2Fe4eULGKX/7tbj6EPVCH1weE+WmD0enn9qGBFVjZe+jG2k4XSZE91Kv11a6rrCS5vSSxNbJ1u9TV8G9otheh5+tmfoea+7HSY+pPpvoP39ESmrLK7mBuFT1Mn0OGdWS32ykB2LHovVgl9SjZlSZsyXVw6Kuw/Cdpi6opqBaL7QRf+A4gzL7t+28sX0jIwBsZNtbgkEdYZ1F9tB+n1gUolEVarJI3JwSX5JnnQ6GXa56CY9r1EQmkFad1VxGWi0VSdLMgQ==; 25:d2Hh1Yvbdq5aivR3eHeomgs/II9iWWlYs3lh6a7Aq7+XmVDNJmCNtg4LTrMa9JKezU6ykfGKIGyD3Yn2YESIrXcXexdqiM2epmlZ4XPZVx3v6WiwWECwMZ7/CflBXGoV1831HFdI9JqmXl1Fyzm+jnPbPhZa9koSwL/wUqWPXFDQ1A/mV/8Ub8sigTzxLi758wW/I7NDocY5dr3HHg1sPzuqb9OLO22S0FA/jS6Dlh4Pfau6Fy1BmAcOLpXUUs+LlPAgliO7b9NEgtjeIi9YPhXguJIxxCAs15fG8GVTN+kZoHm9vMC1Ee+piaP+KvW/oKZ7kt24vKAJ6zDYbSmKFOyqlbs/QQuX6t4V/k8gk4ZtEizqIcctXHIW0sG8iazBP8y2I/mZrV3vnHC4VRH8Cw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB039; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB039; 20:vGOhZ8vfOy3OvwK2aIZffxcJBLsVBgSmknVH8P5Q8MBjKX5sXhWnEtNBmTUPfpEXs8n4Ea5RE1xjrqNFCwijrsOLAYFG0Ql3lfYQVQ8mbeFkgyAZLpSbKmyLMcYxOm2t4sFLrVw2i/ul4X1BOpqontMPKmeAvIxhBkjXGNSz2LY3JKiGmajegnDpfZWqroY6d0kIGWtcO9zrmlW0URovrhDBlhLHAqyZtwcuI1OzHd8Nbq8WHE1YqC3kjLAOFETP; 4:0Pae58eNYQ7w21zIrLBpssA2dbGyq/WB7vycKQmw0tVh85qw3zL1SBU8sJiSHWEJ2kZnrMNwYkiuYf4RGJad+YL69/L2YZyqHItx5r4um2b+NyYimlSRYuESpSd2f33mYmCfwezKPrFatUBMBybiruBxPyRdF+aDo0lOZgwUIpJEzInls6FXNR/9RBf/0KTHCS/4F7c+NXj+GYPO61ZsiLUC5X31DDqoLox/K2dA/hWMUjWHDnJ4BFQRxYpW/RXem7XRkuUBRH+Wf67OyLrYS6MFn/Yo4e73CdkC393hWTanxSiVF4nO1SlAYMUiA3F15paoZHXdqjuSFUIqjpDJB6Ha9my7nmiMuseCgkejTy3p6Y1LshPfwKtq436VlDWCm7cKEH8okcD6BMz/ab5zuPR7wvYHALWs8Ft8QZKPUNmQ6I0nYVarmZxApYj5wBhqgNS8UHJ9nmvVcTlxWX+eXg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13015025)(5005006)(13017025)(13023025)(13024025)(13018025)(8121501046)(3002001)(10201501046); SRVR:BL2FFO11HUB039; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB039; X-Forefront-PRVS: 08635C03D4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB039; 23:nn4YHc03IYhrlqbhR2zjwehbyf5KkshpPJtsDLvq?= =?us-ascii?Q?STojtKD0e7sVwnh2c7iiED0cjnZkzPIqKPjuRbHwu/GMxvgzsGuht/c3c+XG?= =?us-ascii?Q?qL/ljaZ6GfyBxCsgyVM4Rvk6LbLCl2X8fhCOz1MDjEbsue4fiB6gJQXkM0Yt?= =?us-ascii?Q?AzYT/pR/qLZvpss7w1zaOD7KkE/rAFl6fIQUCSnFHA/Muyrlzq0Ptv7Pc+Bu?= =?us-ascii?Q?VKhF02ptWdMyoQcR3YwZ/d+C5dNSDw+nCExrF5OckwomntSojSTOQWfyyksT?= =?us-ascii?Q?IQzzfmdRynSjhvhFP0I/YvPONw38J6lByfg/eNcCcluLHADUfKKV0rx1HZpp?= =?us-ascii?Q?MHPV/kEFjc0o7QF0WLs21pl+TFLGw7N1vYKpzOn3laYaz8XJZZMQqyLLD264?= =?us-ascii?Q?7iRcPMvKRWf7P+QIxKwKDqgxMRDrThSF/fm/pmFPsT/Y9DQW7yp65i/MH5F6?= =?us-ascii?Q?CPwqpE+o3yWaBjARArnHRYBsiK99sqIqm3yU/VN3/38Cwhs7DxbhAJWI3tjm?= =?us-ascii?Q?SmzJi1krUbU6/q6Kxmn6R4ROBelyD5bF0nfMq2MK9VHybs/UyPP34o3k4mRh?= =?us-ascii?Q?CF7nmzTpky/SqmVcRPBN6T+1Gfm08DI4MYkXZ0aKiuCzIUFKrYD7zzKWvuGk?= =?us-ascii?Q?RmKNM4P2AabT4yQi3268yFVYgeWjavMAHA80J7l81LogvVMv0JMV6SjTz4En?= =?us-ascii?Q?IYB7xuNcQhVYQL1WziU5e9aRJ2Rb2X1O+R4hCAELQll+nTU0M0KMpVizn59O?= =?us-ascii?Q?ZAzKd767jcH3ApRyi7rlhpOHhZYTHKsIwSTQ/bWNtd2EO8RukWgQFrxiGWAd?= =?us-ascii?Q?env3/F+KZtDmaz5VrmFdz6/i2r4F3fDIZuDibD/NY6ZXHDVciFAal7Q0qM6w?= =?us-ascii?Q?NFfeORA69iwEy4IrN6KNYdOOA7dWcwzrsXJG3cfRpTW21fFB4r+mT1AgOA0y?= =?us-ascii?Q?GQP+FyBrznUa+j55ao1OLmaKwRyQoET61Pz/OddDv86NFVsoIijpe9/bYMHB?= =?us-ascii?Q?6xB7YdNRpiEAL73ZPKAN1796xfGHCDHxfUgww5aNDUJBpONZETHOLMIfGgso?= =?us-ascii?Q?L1aTmB3aM5gJlXKDhj8DilPopg5+YEt5veLWOxkkvPiE2795rqSx61dgvIeF?= =?us-ascii?Q?i0Y25JB9KwGNHwOcqkJRU+foRnAN6/Sm2E9Tnsq4t0+vm5K+18E3ARLqyBi0?= =?us-ascii?Q?DzBb910SRhbUWcfHdJXWr4uRCHMRBP5MRdGgfaetHDI6conHuHstegSxkDQq?= =?us-ascii?Q?WEPp61VLVKUiaWIKyNgV0zFLzvYfCUrpZn+ukanFlFX12z4qS+uJk8T1/Tet?= =?us-ascii?Q?Iw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB039; 5:eKqd1qUSyIeMtvTb9PnQsN6OvYrBU/gxXthzJCJI8VdIRJoGM8/cDHSqpEMkpg5LtGxXXnqhGl133bVCw/LVnUKx31ZuDigd0jmG/QikSUlUjpMnzldHsPcGIdj9Pa8m9gPJbb67h07/eGjYOgXLRA==; 24:bmjYxsW8anqEUTH79UPPa20Ql4C7OF7TCQV2RdJXInc1Lfno4NcvdDcRBz+vXUZYQ9jBQBxzMyUy4p5sak4w56Ku18AOA/bcWyM5NHbQHWo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2016 16:46:01.6177 (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: BL2FFO11HUB039 Archived-At: Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft 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 Feb 2016 16:46:15 -0000 --_000_3af9e40382f34867bd866707fc4b1ce9PLSWE13M01adsprintcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And that , to quote Mr. Dolly, would require "digging up the graveyards aro= und Indian Hill". In other words, ain't going to happen. What we need is an "official" statement from ALU Nokia et al that this is n= ot practical. But would they make such a statement, effectively to the FCC= ? In terms of what is driving this, I'm similarly confused. Unlike in the ca= se of other work we are doing in PTSC that impacts backwards compatibility = (e.g. caller ID spoofing), I don't see a massive public push for this, it w= ould be more of a convenience. Are there any current issues with interconn= ection rating for VoIP providers generally, who operate number blocks that = they use on a NG basis, but are charged for some kind of LD interconnect wh= en these numbers call others in their geo but which are in another LATA? From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A= [CTO] Sent: Thursday, February 25, 2016 8:28 AM To: McGarry, Tom ; 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft "One way to enable NNP is to remove the NPAC edit and allow the TN and RN t= o be in different geographic areas... It's been reported that a call of this type in certain older technology swi= tches will fail. If so, then new software would have to be developed for t= hese switches to implement this solution." I feel like I've been transported back in time to read e-mails offering "te= chnical" reasons why number portability is challenging or impossible. Can the claim starting, "It's been reported.." be substantiated with a refe= rence? As an editorial comment, I'll offer I was confused by references to "NXX-NX= X". From the context, I assume you actually meant NPA-NXX. Do I assume co= rrectly? I agree with those who question whether the transition to IP drives a need = for new number management solutions. >From my last response to the MODERN "problem statement"... "The MODERN problem statement is in fact a TN management solution framework= . i.e., a solution looking for a problem. If there is a problem that MODERN addresses, it is the inability of end use= rs to directly (through a protocol) manage requisition and release of TNs a= nd manage their associated metadata. This is not a protocol problem. It i= s a policy problem (if it is a problem at all). And the only provisioning = protocol I remember seeing referenced in the solution statement is a SIP RE= GISTER. In this, MODERN is hardly any different then TRIP and equally usef= ul. My main recommendation is to scrap the so-called problem statement and star= t over. Do not introduce any text that even resembles a solution framework= . The problems can then be easily identified and discussed. And I encoura= ge discussion of policy as part of the problem so that in the end you can h= opefully clearly differentiate between issues that are political and issues= which are technical and therefore appropriate for the MODERN WG." Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: February 25, 2016 8:57 AM To: 'Modern List' > Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft No, it is just one "proposed" solution. From: Richard Hill > Date: Thursday, February 25, 2016 9:44 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft Yes, but such a green field space can, and has been, implemented on the PST= N, so the use of an all IP solution is not a requirement. Whereas your dr= aft implies that it is, unless I misunderstood something. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 15:42 To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft The point is, it is a green field numbering space within a country. These = concepts would apply to any green field numbering space. And it is a use c= ase, it just so happens to be based on a proposal in the USA, it could have= been proposed anywhere and it would still be a use case. From: Richard Hill > Date: Thursday, February 25, 2016 4:25 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft The abstract states "While this focuses on an effort occurring in the USA = the concepts are applicable to any country." I think that it would be better to change that to "This focuses on an effor= t occurring in the USA; but the concepts may be applicable to other countri= es." I say this because non-geographic numbers have already been implemented in = other countries, on the PSTN, without the use of IP-networks, whereas the I= ntroduction of the draft states that non-geographic numbers "would be hoste= d on an all-IP network of switches called non-geographic gateways (NGGW), = rather than the existing TDM tandems operated by the incumbent local excha= nge carriers (ILECs)." Separately, I still wonder whether it is appropriate for the IETF, which is= supposed to be a global entity, to develop a protocol that is apparently o= f interest to the USA only. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 02:18 To: Modern List Subject: [Modern] Nationwide Number Portability MODERN Use Case Draft http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt ________________________________ 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_3af9e40382f34867bd866707fc4b1ce9PLSWE13M01adsprintcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

And that , to quo= te Mr. Dolly, would require “digging up the graveyards around Indian = Hill”. In other words, ain’t going to happen.

Wh= at we need is an “official” statement from ~~ALU~~ Nokia et al that this is not practical.&nb= sp; But would they make such a statement, effectively to the FCC?

In terms of what is driving this, I&#= 8217;m similarly confused. Unlike in the case of other work we are do= ing in PTSC that impacts backwards compatibility (e.g. caller ID spoofing), I don’t see a massive public push for this, it would b= e more of a convenience. Are there any current issues with interconne= ction rating for VoIP providers generally, who operate number blocks that t= hey use on a NG basis, but are charged for some kind of LD interconnect when these numbers call others in their geo b= ut which are in another LATA?

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of Gorman, Pierce A [CTO]
Sent: Thursday, February 25, 2016 8:28 AM
To: McGarry, Tom <Tom.McGarry@neustar.biz>; 'Modern List' <= modern@ietf.org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

“One way to enable NNP is to remove th= e NPAC edit and allow the TN and RN to be in different geographic areas…

It's been reported that a call of this type in certain older technology switches will fail. If so, then new software would have to be developed for these switches to implement thi= s solution.”

I feel like I’ve been transported= back in time to read e-mails offering “technical” reasons why = number portability is challenging or impossible.

Can the claim starting, “It’= ;s been reported..” be substantiated with a reference?

As an editorial comment, I’ll off= er I was confused by references to “NXX-NXX”. From the co= ntext, I assume you actually meant NPA-NXX. Do I assume correctly?

I agree with those who question whether= the transition to IP drives a need for new number management solutions.

From my last response to the MODERN = 220;problem statement”…

“The MODERN p= roblem statement is in fact a TN management solution framework. i.e.,= a solution looking for a problem.

Pierce

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: February 25, 2016 8:57 AM
To: 'Modern List' <modern@ietf= .org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

No, it is just one "proposed"= solution.

Best,

Richard

The abstract states “While this= focuses on an effort occurring in the USA the concepts are app= licable to any country.”

I think that it would be better to ch= ange that to “This focuses on an effort occurring in the USA; but the= concepts may be applicable to other countries.”

Separately, I still wonder whether it= is appropriate for the IETF, which is supposed to be a global entity, to d= evelop a protocol that is apparently of interest to the USA only.

Best,

Richard

ht= tp://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt

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_3af9e40382f34867bd866707fc4b1ce9PLSWE13M01adsprintcom_-- From nobody Thu Feb 25 09:33:21 2016 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 A061C1B2ECA for ; Thu, 25 Feb 2016 09:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j5kl-muYheQf for ; Thu, 25 Feb 2016 09:33:16 -0800 (PST) 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 901081A6FFA for ; Thu, 25 Feb 2016 09:33:16 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.15.0.59) with SMTP id u1PHNCir009729; Thu, 25 Feb 2016 12:33:11 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 2190hgw3t4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Feb 2016 12:33:11 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.140]) by stntexhc10.cis.neustar.com ([169.254.4.23]) with mapi id 14.03.0279.002; Thu, 25 Feb 2016 12:33:10 -0500 From: "Peterson, Jon" To: "Holmes, David W [CTO]" , "Gorman, Pierce A [CTO]" , "McGarry, Tom" , "'Modern List'" Thread-Topic: [Modern] Nationwide Number Portability MODERN Use Case Draft Thread-Index: AQHRb2pm7PDoPWgGMEWIEhdbfE2ttZ88e5hwgABbCQCAAAB2AIAAA5cAgAAUeeCAAAWi8P//30YA Date: Thu, 25 Feb 2016 17:33:10 +0000 Message-ID: References: <00cd01d16fdb$1a128f80$4e37ae80$@ch> <68346e41454447f1b75d61da4c51821b@PLSWE13M08.ad.sprint.com> <3af9e40382f34867bd866707fc4b1ce9@PLSWE13M01.ad.sprint.com> In-Reply-To: <3af9e40382f34867bd866707fc4b1ce9@PLSWE13M01.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [192.168.129.20] Content-Type: multipart/alternative; boundary="_000_D2F473C517AE33jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-25_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602250234 Archived-At: Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft 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 Feb 2016 17:33:20 -0000 --_000_D2F473C517AE33jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable While many of the people on this list are concerned exclusively with managi= ng carrier numbering resources, a lot of the inspiration for this effort ca= me from the increasing diversity of players who seem to be allocating and m= anaging numbers outside of the traditional carrier case. That would include= enterprises, and OTT VoIP providers, and Internet texting system, things t= hat don't tend to have lots of installed traditional PSTN infrastructure. W= hile I wouldn't go so far as to call it a "massive public push," there are = lots of systems today that let users acquire and managing telephone numbers= as resources for basically Internet applications. In some cases, even enti= ties we'd recognize as traditional carriers are fielding services that let = users allocate and manage multiple telephone numbers as aliases for differe= nt household members on one line, or similar functions. And moreover, we keep hearing that there is some kind of IP transition unde= rway, and that many carrier networks will move permanently to systems that = look at least somewhat more like Internet applications. How much they will = resemble them, and how quickly we will get there, are matters of debate, su= re. But having some protocol tools to perform these functions isn't a parti= cularly far-fetched goal, nor is it particularly a question about policy, n= or will it force anyone to adopt anything any faster. It will just enable t= he services that want these capabilities to deploy them. It is literally on= ly a protocol problem. >From my perspective, the NNP use case isn't an outlier in terms of what it = would require from those protocol mechanisms. I do imagine that a lot of th= e "native" Internet applications that use telephone numbers benefit from po= rtability, and would benefit more if portability were more flexible: the ge= ographical limitations on portability are an obvious anachronism in our age= of mobile phones. If we're going to build these protocol tools, ideally th= ey should be able to handle the range of policy outcomes that we anticipate= are coming down the pike. I'm not sure I'd be defining a solution here any= differently because of NNP's specific requirements; depending on exactly h= ow it is realized, the information model might admit of a different field h= ere and there, but the information model needs that extensibility anyway. S= o... the protocol tools will basically accommodate it, if industry and regu= lators wanted to use them. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of "Holmes, David W [CTO]" > Date: Thursday, February 25, 2016 at 8:45 AM To: "Gorman, Pierce A [CTO]" >, "McGarry, Tom" >, 'Modern List' > Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft And that , to quote Mr. Dolly, would require =93digging up the graveyards a= round Indian Hill=94. In other words, ain=92t going to happen. What we need is an =93official=94 statement from ALU Nokia et al that this = is not practical. But would they make such a statement, effectively to the= FCC? In terms of what is driving this, I=92m similarly confused. Unlike in the = case of other work we are doing in PTSC that impacts backwards compatibilit= y (e.g. caller ID spoofing), I don=92t see a massive public push for this, = it would be more of a convenience. Are there any current issues with inter= connection rating for VoIP providers generally, who operate number blocks t= hat they use on a NG basis, but are charged for some kind of LD interconnec= t when these numbers call others in their geo but which are in another LATA= ? From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A= [CTO] Sent: Thursday, February 25, 2016 8:28 AM To: McGarry, Tom >;= 'Modern List' > Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft =93One way to enable NNP is to remove the NPAC edit and allow the TN and RN= to be in different geographic areas=85 It's been reported that a call of this type in certain older technology swi= tches will fail. If so, then new software would have to be developed for t= hese switches to implement this solution.=94 I feel like I=92ve been transported back in time to read e-mails offering = =93technical=94 reasons why number portability is challenging or impossible= . Can the claim starting, =93It=92s been reported..=94 be substantiated with = a reference? As an editorial comment, I=92ll offer I was confused by references to =93NX= X-NXX=94. From the context, I assume you actually meant NPA-NXX. Do I ass= ume correctly? I agree with those who question whether the transition to IP drives a need = for new number management solutions. >From my last response to the MODERN =93problem statement=94=85 =93The MODERN problem statement is in fact a TN management solution framewo= rk. i.e., a solution looking for a problem. If there is a problem that MODERN addresses, it is the inability of end use= rs to directly (through a protocol) manage requisition and release of TNs a= nd manage their associated metadata. This is not a protocol problem. It i= s a policy problem (if it is a problem at all). And the only provisioning = protocol I remember seeing referenced in the solution statement is a SIP RE= GISTER. In this, MODERN is hardly any different then TRIP and equally usef= ul. My main recommendation is to scrap the so-called problem statement and star= t over. Do not introduce any text that even resembles a solution framework= . The problems can then be easily identified and discussed. And I encoura= ge discussion of policy as part of the problem so that in the end you can h= opefully clearly differentiate between issues that are political and issues= which are technical and therefore appropriate for the MODERN WG.=94 Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: February 25, 2016 8:57 AM To: 'Modern List' > Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft No, it is just one "proposed" solution. From: Richard Hill > Date: Thursday, February 25, 2016 9:44 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft Yes, but such a green field space can, and has been, implemented on the PST= N, so the use of an all IP solution is not a requirement. Whereas your dr= aft implies that it is, unless I misunderstood something. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 15:42 To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft The point is, it is a green field numbering space within a country. These = concepts would apply to any green field numbering space. And it is a use c= ase, it just so happens to be based on a proposal in the USA, it could have= been proposed anywhere and it would still be a use case. From: Richard Hill > Date: Thursday, February 25, 2016 4:25 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft The abstract states =93While this focuses on an effort occurring in the US= A the concepts are applicable to any country.=94 I think that it would be better to change that to =93This focuses on an eff= ort occurring in the USA; but the concepts may be applicable to other count= ries.=94 I say this because non-geographic numbers have already been implemented in = other countries, on the PSTN, without the use of IP-networks, whereas the I= ntroduction of the draft states that non-geographic numbers =93would be hos= ted on an all-IP network of switches called non-geographic gateways (NGGW)= , rather than the existing TDM tandems operated by the incumbent local exc= hange carriers (ILECs).=94 Separately, I still wonder whether it is appropriate for the IETF, which is= supposed to be a global entity, to develop a protocol that is apparently o= f interest to the USA only. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 02:18 To: Modern List Subject: [Modern] Nationwide Number Portability MODERN Use Case Draft http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt ________________________________ 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_D2F473C517AE33jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

While many of the people on this list are concerned exclusively with m= anaging carrier numbering resources, a lot of the inspiration for this effo= rt came from the increasing diversity of players who seem to be allocating = and managing numbers outside of the traditional carrier case. That would include enterprises, and OTT VoIP= providers, and Internet texting system, things that don't tend to have lot= s of installed traditional PSTN infrastructure. While I wouldn't go so far = as to call it a "massive public push," there are lots of systems today that let users acquire and man= aging telephone numbers as resources for basically Internet applications. I= n some cases, even entities we'd recognize as traditional carriers are fiel= ding services that let users allocate and manage multiple telephone numbers as aliases for different household m= embers on one line, or similar functions.

And moreover, we keep hearing that there is some kind of IP transition= underway, and that many carrier networks will move permanently to systems = that look at least somewhat more like Internet applications. How much they = will resemble them, and how quickly we will get there, are matters of debate, sure. But having some protocol t= ools to perform these functions isn't a particularly far-fetched goal, nor = is it particularly a question about policy, nor will it force anyone to ado= pt anything any faster. It will just enable the services that want these capabilities to deploy them. It i= s literally only a protocol problem.

</first principles>

From my perspective, the NNP use case isn't an outlier in terms of wha= t it would require from those protocol mechanisms. I do imagine that a lot = of the "native" Internet applications that use telephone numbers = benefit from portability, and would benefit more if portability were more flexible: the geographical limitations on po= rtability are an obvious anachronism in our age of mobile phones. If we're = going to build these protocol tools, ideally they should be able to handle = the range of policy outcomes that we anticipate are coming down the pike. I'm not sure I'd be defining a sol= ution here any differently because of NNP's specific requirements; dependin= g on exactly how it is realized, the information model might admit of a dif= ferent field here and there, but the information model needs that extensibility anyway. So... the protocol = tools will basically accommodate it, if industry and regulators wanted to u= se them.

Jon Peterson

Neustar, Inc.

From: Modern <modern-bounces@ietf.org> on behalf of "= ;Holmes, David W [CTO]" <David.Holmes@sprint.com>
Date: Thursday, February 25, 2016 a= t 8:45 AM
To: "Gorman, Pierce A [CTO]&qu= ot; <Pierce.Gorman@sprint.co= m>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, 'Modern List' <modern@ietf.org>
Subject: Re: [Modern] Nationwide Nu= mber Portability MODERN Use Case Draft

And that , to quo= te Mr. Dolly, would require =93digging up the graveyards around Indian Hill= =94. In other words, ain=92t going to happen.

What we need= is an =93official=94 statement from ~~ALU~~ Nokia et al that this is not practical.&= nbsp; But would they make such a statement, effectively to the FCC?

In terms of what is driving this, I= =92m similarly confused. Unlike in the case of other work we are doin= g in PTSC that impacts backwards compatibility (e.g. caller ID spoofing), I don=92t see a massive public push for this, i= t would be more of a convenience. Are there any current issues with i= nterconnection rating for VoIP providers generally, who operate number bloc= ks that they use on a NG basis, but are charged for some kind of LD interconnect when these numbers call others in= their geo but which are in another LATA?

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A [CTO]
Sent: Thursday, February 25, 2016 8:28 AM
To: McGarry, Tom <Tom.= McGarry@neustar.biz>; 'Modern List' <modern@ietf.org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

=93One way to enable NNP is to remove the NPAC edit= and allow the TN and RN to be in different geographic areas=85

It's been reported that a call of this type in certain older technology switches will fail. = If so, then new software would h= ave to be developed for these switches to implement this solution.=94

I feel like I=92ve been transported bac= k in time to read e-mails offering =93technical=94 reasons why number porta= bility is challenging or impossible.

Can the claim starting, =93It=92s been = reported..=94 be substantiated with a reference?

As an editorial comment, I=92ll offer I= was confused by references to =93NXX-NXX=94. From the context, I ass= ume you actually meant NPA-NXX. Do I assume correctly?

I agree with those who question whether= the transition to IP drives a need for new number management solutions.

From my last response to the MODERN =93= problem statement=94=85

=93The MODERN probl= em statement is in fact a TN management solution framework. i.e., a s= olution looking for a problem.

If there is a problem = that MODERN addresses, it is the inability of end users to directly (throug= h a protocol) manage requisition and release of TNs and manage their associ= ated metadata. This is not a protocol problem. It is a policy problem (if it is a problem at all). A= nd the only provisioning protocol I remember seeing referenced in the solut= ion statement is a SIP REGISTER. In this, MODERN is hardly any differ= ent then TRIP and equally useful.

My main recommendation= is to scrap the so-called problem statement and start over. Do not i= ntroduce any text that even resembles a solution framework. The probl= ems can then be easily identified and discussed. And I encourage discussion of policy as part of the problem so that in the= end you can hopefully clearly differentiate between issues that are politi= cal and issues which are technical and therefore appropriate for the MODERN= WG.= =94

Pierce

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: February 25, 2016 8:57 AM
To: 'Modern List' <modern@ietf= .org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

No, it is just one "proposed" solu= tion.

From: Richard Hill <rhill@= hill-a.ch>
Date: Thursday, February 25, 2016 9:44 AM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>, Modern List <modern@ietf.org>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

Yes, but such a green field space c= an, and has been, implemented on the PSTN, so the use of an all IP solution= is not a requirement. Whereas your draft implies that it is, unless I misunderstood something.

Best,

Richard

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 15:42
To: 'Modern List'
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

=

The point is, it is a green field numbering = space within a country. These concepts would apply to any green field= numbering space. And it is a use case, it just so happens to be based on a proposal in the USA, it could have bee= n proposed anywhere and it would still be a use case.

From: Richard Hill <rhill@= hill-a.ch>
Date: Thursday, February 25, 2016 4:25 AM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>, Modern List <modern@ietf.org>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

The abstract states =93While this&n= bsp; focuses on an effort occurring in the USA the concepts are appli= cable to any country.=94

I think that it would be better to = change that to =93This focuses on an effort occurring in the USA; but the c= oncepts may be applicable to other countries.=94

I say this because non-geographic n= umbers have already been implemented in other countries, on the PSTN, witho= ut the use of IP-networks, whereas the Introduction of the draft states that non-geographic numbers =93would be h= osted on an all-IP network of switches called non-geographic gateways= (NGGW), rather than the existing TDM tandems operated by the incumbe= nt local exchange carriers (ILECs).=94

Separately, I still wonder whether = it is appropriate for the IETF, which is supposed to be a global entity, to= develop a protocol that is apparently of interest to the USA only.=

Best,

Richard

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 02:18
To: Modern List
Subject: [Modern] Nationwide Number Portability MODERN Use Case Draf= t

=

http://= www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt

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_D2F473C517AE33jonpetersonneustarbiz_-- From nobody Thu Feb 25 10:02:05 2016 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 669551B2F70 for ; Thu, 25 Feb 2016 10:02:04 -0800 (PST) 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, 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 aXo1R6gZdyH3 for ; Thu, 25 Feb 2016 10:01:55 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445111B2F12 for ; Thu, 25 Feb 2016 10:01:42 -0800 (PST) Received: from BN1AFFO11FD030.protection.gbl (10.58.52.34) by BN1AFFO11HUB025.protection.gbl (10.58.52.135) with Microsoft SMTP Server (TLS) id 15.1.422.5; Thu, 25 Feb 2016 18:01:40 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN1AFFO11FD030.mail.protection.outlook.com (10.58.52.168) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Thu, 25 Feb 2016 18:01:40 +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 u1PHHWL7025178; Thu, 25 Feb 2016 13:01:40 -0500 Received: from plswe13m01.ad.sprint.com (plswe13m01.corp.sprint.com [144.229.214.20]) by preapdm3.corp.sprint.com with ESMTP id 216k989mda-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Feb 2016 13:01:39 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 25 Feb 2016 12:01:38 -0600 Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Thu, 25 Feb 2016 12:01:38 -0600 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , "Holmes, David W [CTO]" , "McGarry, Tom" , "'Modern List'" Thread-Topic: [Modern] Nationwide Number Portability MODERN Use Case Draft Thread-Index: AQHRb2pm7PDoPWgGMEWIEhdbfE2ttZ88e5hwgABbCQCAAAB2AIAAA5cAgAAUeeCAAAWi8P//30YAgAAzgrA= Date: Thu, 25 Feb 2016 18:01:37 +0000 Message-ID: <0dd72becae6d4d9b8ea4bccc4d9f9602@PLSWE13M08.ad.sprint.com> References: <00cd01d16fdb$1a128f80$4e37ae80$@ch> <68346e41454447f1b75d61da4c51821b@PLSWE13M08.ad.sprint.com> <3af9e40382f34867bd866707fc4b1ce9@PLSWE13M01.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.20] Content-Type: multipart/alternative; boundary="_000_0dd72becae6d4d9b8ea4bccc4d9f9602PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CPI:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(199003)(51444003)(377454003)(189002)(93886004)(2906002)(108616004)(76176999)(19300405004)(1220700001)(54356999)(1096002)(790700001)(16236675004)(19625215002)(300700001)(102836003)(50986999)(11100500001)(2900100001)(92566002)(5250100002)(33646002)(3846002)(561944003)(2950100001)(5001770100001)(19580395003)(19580405001)(4546004)(15975445007)(107886002)(5001960100002)(189998001)(106466001)(106116001)(87936001)(6806005)(575784001)(30436002)(86362001)(586003)(5008740100001)(19617315012)(5004730100002)(512934002)(24736003)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB025; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD030; 1:mYlNq+9exp1ShUyxyXOU4lyg54DVuwVK3jz4WiBDkdUc8DSUCaUJWucHbD1MWLmoXGBrE2LJZYUzr6tnM6+rxweEWOZ2sfCaG1Nd/vs5byWiFN3nVjtSR+11Nxrwds4M502SD81fCex43y0xuQhVb+afuKbAj6LjN9GRKkJsTaTGtJCqxHQpOVco6Ry0BdGE+BoubLUKLyeBu2WCSyuSd8AAKaFCYb5jI5qrj55O1mxqE1KUQw0AxnvEwP3xH3AEJWA4UFUNSMgVCZA0fxcyao2SUIA4W96cafvwk674ifv9BazquNCjG0Uisfh7s7MB4w8lXoU66miy5D8hUTvLENT5Le3PdNMl81n1ZMzPSgmFKdejRfQctHtNQ1e6Cho4/ROQgcR4Bsfc1HT4TZcR7+Ndlf2kIjRjJH/AbcbWcFEPDSDUyPrV6QW9uLAzFy8G1r6UqkSOJtXFj2+2ALnn4A== X-MS-Office365-Filtering-Correlation-Id: 21584b95-d3a6-45e6-d13c-08d33e0db65f X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 2:ZNgP8MexF0T2SKeYHUDm/nDLFv6blAseGnEJPk76E26HXlZc7NRGzMOd2BYDmbASi5WIhsnV4Xuk5liG7G4Nq9Aq6njEqsLt5qG4BhirTg8zim+v5YIHlmTakatA7oZHSyATwChraJtgRHMkHsXtMS3i9YvVMQVwQj50VneEPPOpFwwxZaO12rosGpQn5zWe; 3:imNOH6BT1iCYX8OFEnmTQvZw5aSvWCJZtLKqeqT9c07zh2bFG2nGMYKx6gZh0+KBW2UVqXT16JDQU/UuRopUhwkJYU11nPJjkJY+Vtx2bMPu/MuoBG0z+ZRbxYELghTYrJGzQKYspK98Yp/gLJ6ZFtHTkl6pH+rH6sITzoJ9mvs9BeRVgF6qyydMTD/UltEOdFSpghhwe30vgFe+7iScMA==; 25:eBDu1a0EHwII2R4r2dlDuLO/tWCjlfgsTl7yvd6A/Jh4xZuUTAvuHNGjm+cPJQnAzWu6tjqNem6lnZQeNs7TMknbV6In5qsLh3ZsdjtKKFs9EA+k4J3eBd5rF9JhmxkyDBsscGHo3XPnEuY3ezZMxz9V0KE2fQZCRLduadFI1LqCsN63d4+z/2mUScbzEmhb9RRa3IaMx31gfvHbgni67TkFxG5/npVVIBr04emkG1HwNthJbCkTKoO2MOH7uN5UG1NII06XiWYnErB68pum/MWqm4vaUdRSkJBqMT50Wl/BwM0uqdvAPp9fy0jiEdfv9d0kSEo0FLkhYRywqxDGJMpCLHGdBv5plYLlCBU1ZIxv+0TGmH05zhC6QE4pZea/ X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB025; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 20:HaaxlindcXzpcyVzUGP0jBbHU+miRrdXRMkw5BOcEhcgNr66S9uOVN9642MZjDiG01patM/s3qCtn+uwXkxtSeQ/kLoA+kt6jGj7CVWfy0nxRPTKZIlIx0Cm8gTO5Xh3mXrhZIbTWL3z3qJJl54QHf+scNYEjPv8rS69FywVOR3A9vek6MpxzZDe7k8MOHylUX5THGQj77P1NOa53kSpHn2WMaFTJ/9NoW88CUWm52EPOh7PgZG/6qNT66QTTu1n; 4:DOmp+8jLgLl+5ZkL4CgH5MVTz8m3G1zmb5+DtEfxW6Yq0cOXr9OWfz0jGumHe9LAg6ZNng8K1YGZSo3HRnZzvg3mCQvAOTLVIz98lZBpWFhBTzsL27gtoebQbQT8oL++e/S6Eg4QAAAuzsdtuKr31dbH5yFvK84gPmrZyx0aTk8LisWTOGyokc8pFPZmeNnILxXpKV9MbCSnsZGdsuD7uioMQfb0coXlWCvQ3OFasj5YlYNTQt45A06tkIQ6vVEfOFMynZ6cKPjJgM1D0daM3Hsug3wGz6vRmFluwMQqs3yjx3rnc2+wc0AOzpe7hm2pEQ88tv7/cfURXmv8abbD52xxHw8RkCS/ClZuUAh7sFa9exBPTqvPFttlNGi4tc3UmFB+bOmJx6adczY6Ye0ymvOwBWSKTF4Bx0CY71ulLPFU/gyXo5OO3Qur74vcgAVAc1rbicdthNch9fGVl/wvF7dYBCVLm6RCPwH+QQpB5zs+qUp6gNE2jtLP9VXwaRLz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(18430343700868); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13018025)(13015025)(5005006)(13017025)(13023025)(13024025)(10201501046)(3002001); SRVR:BN1AFFO11HUB025; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB025; X-Forefront-PRVS: 08635C03D4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB025; 23:pAw8ZNu+6GZNlskIYqO2FdZayqZmQj6rJTOCGJN?= =?us-ascii?Q?Ry9X6iBYNflxy0Ay8/+9b7NYHyJj87vgQcdikLOSPQ1r1Kx5p8K33B7Iv4jI?= =?us-ascii?Q?MUAfyaZuVcRwII6ZHYKIxYB2hiFsHuu7Y6sNeEd0ZFtUT5wGd6SKPeFLLlU/?= =?us-ascii?Q?Y/9Cj0VoTMgIdnz0eLPbP6IdQLrjxmdziwJNrOgWIWe6bWqxRL7rfxEVNRYK?= =?us-ascii?Q?qV/AMJDHgLoXsuUR38ncDh0o0ai7OFoj59348PSSPu8UncX5iYlTuTsUV+wr?= =?us-ascii?Q?EWlwnRORNTlmVd4OLdqRsdhokAh45aMu2LY+DOftoJJCn+YF6o5TbBt/62u0?= =?us-ascii?Q?YZZ6/19kdIi4+tRfxsVEJQSxU18PO0iGNGdVPRO8Dav+FapNR8+xuY495Qj2?= =?us-ascii?Q?biKMF7NYA2v6trT1QpoMYXQSwE9QT65xJa3zMiDL2j+kAqzDgNQdFA7l6kkE?= =?us-ascii?Q?zWuUHnjy0LUDFzrNPpC60nq85kk5kAU8nfHaQao66PGbDQ7XxnoyjAhef+MC?= =?us-ascii?Q?1s/Nnh5Kk9ewnH6Hhj0sgTEJvnpJ0RAGeCTL4wfcamdIoAxHMXoud7RuBdc3?= =?us-ascii?Q?yewExJNnPflyGrh2Lfb4WdB78deLNf6Q4G1fiSPaRP8Xi3VbcBDlHhRaaeHV?= =?us-ascii?Q?D8QEd22bNoc5yDEdOUoHYV6nQslMAkWu3luNHPcD1sGXg2V67jtP2IyMWcLW?= =?us-ascii?Q?fkWhJsX0qapeTXKUIkzrjJOuudpbLrGfVtOllEvT3L2uhIjqv+IELOif1xgY?= =?us-ascii?Q?KI8DtJaV3IUbQHzZomIdMQMVT2nMxLh928awmP6FuYi54KQk30gUipdOVdQn?= =?us-ascii?Q?GxdpNCfjP7bJATUFRylwSWzMAX58fPOtNPS77C8wavigOD1xEe9GnxOaTUKI?= =?us-ascii?Q?kV0QjZ3CvBnJMkzlLrSOkZnq6rWaSLHTI9fQdiPDMJprykx1lWPBd6cvgPDd?= =?us-ascii?Q?gwwKLcFYvidxgVt91jA6J7bxn4kuhag8kj4bMf1V9KoCheEWaPZNWo/61YdN?= =?us-ascii?Q?EpdffH4qW4FW9R91TIGO9nxRJUm6pAU4cYTaEeSZzNc/SdCnYoxSXt8TnQui?= =?us-ascii?Q?hiUDy9eGIEiR2N1BiDXtrSUXtkchih7oLKAK5UAb6A7KVSVuYawNMtbswPKg?= =?us-ascii?Q?7ko4i+qFj9ZjoNB46QSjRYmj7SWMewSzyzH/YkSp3knXmZJGNtc6qqQPEGtO?= =?us-ascii?Q?etlNadzg5F5ja5XEbHbGpnr9+mYQiMG9659tSs8MW49JNx+vlU7kzHWdQduB?= =?us-ascii?Q?kwlgJ0sDckLU7BbNyRKGnvSIazJmu+7MVpWOldm4H1p9d+P69avoatcw44q+?= =?us-ascii?Q?23ttd4zzJnJS9wexjatFlq0w=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 5:z/l6SiKeI07lAyekRajtBPPSlDjFUfXq8Ueu7TtZeNBxjeyrbuSMP8XJkNnU6GhEqdyy6HWdjuZVUOnPYz+O+tyc9pxUJctWd3vkvS2LnTUEcEy4KF8/MSuGit1mDxCPoiPiKmNx455qCkz4wtYkCQ==; 24:QxUoBbllRKqD/hyq8qljca9lttEoqz2wK33IqeuvSYnPzHKbdbHbKpZMYpeNcN3V7B65rvleE+vwHOl8RWEPDjpoYQG2ECJQyKEP31J4R7Y= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2016 18:01:40.3977 (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: BN1AFFO11HUB025 Archived-At: Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft 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 Feb 2016 18:02:04 -0000 --_000_0dd72becae6d4d9b8ea4bccc4d9f9602PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I didn't say there was no problem for MODERN to solve. I said that the MOD= ERN "problem statement" was not a problem statement, but instead a solution= framework for an undefined problem. Telephone numbers are owned and assigned first and foremost by national num= bering authorities. The number authorities delegate number blocks to licensed regulated entitie= s which both make individual assignments and further delegate block assignm= ents. (Very much like RIRs not surprisingly.) At some point of distribution, delegation presents serious problems for eff= icient management of address space. (Anybody remember RFC 1918 and NATs fr= om Hell?) Any solution framework with proposes non-traditional management of telephon= e numbers MUST address efficient and accountable assignment. How is this n= ot a policy issue? From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: February 25, 2016 11:33 AM To: Holmes, David W [CTO] ; Gorman, Pierce A [CTO]= ; McGarry, Tom ; 'Moder= n List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft While many of the people on this list are concerned exclusively with managi= ng carrier numbering resources, a lot of the inspiration for this effort ca= me from the increasing diversity of players who seem to be allocating and m= anaging numbers outside of the traditional carrier case. That would include= enterprises, and OTT VoIP providers, and Internet texting system, things t= hat don't tend to have lots of installed traditional PSTN infrastructure. W= hile I wouldn't go so far as to call it a "massive public push," there are = lots of systems today that let users acquire and managing telephone numbers= as resources for basically Internet applications. In some cases, even enti= ties we'd recognize as traditional carriers are fielding services that let = users allocate and manage multiple telephone numbers as aliases for differe= nt household members on one line, or similar functions. And moreover, we keep hearing that there is some kind of IP transition unde= rway, and that many carrier networks will move permanently to systems that = look at least somewhat more like Internet applications. How much they will = resemble them, and how quickly we will get there, are matters of debate, su= re. But having some protocol tools to perform these functions isn't a parti= cularly far-fetched goal, nor is it particularly a question about policy, n= or will it force anyone to adopt anything any faster. It will just enable t= he services that want these capabilities to deploy them. It is literally on= ly a protocol problem. >From my perspective, the NNP use case isn't an outlier in terms of what it = would require from those protocol mechanisms. I do imagine that a lot of th= e "native" Internet applications that use telephone numbers benefit from po= rtability, and would benefit more if portability were more flexible: the ge= ographical limitations on portability are an obvious anachronism in our age= of mobile phones. If we're going to build these protocol tools, ideally th= ey should be able to handle the range of policy outcomes that we anticipate= are coming down the pike. I'm not sure I'd be defining a solution here any= differently because of NNP's specific requirements; depending on exactly h= ow it is realized, the information model might admit of a different field h= ere and there, but the information model needs that extensibility anyway. S= o... the protocol tools will basically accommodate it, if industry and regu= lators wanted to use them. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of "Holmes, David W [CTO]" > Date: Thursday, February 25, 2016 at 8:45 AM To: "Gorman, Pierce A [CTO]" >, "McGarry, Tom" >, 'Modern List' > Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft And that , to quote Mr. Dolly, would require "digging up the graveyards aro= und Indian Hill". In other words, ain't going to happen. What we need is an "official" statement from ALU Nokia et al that this is n= ot practical. But would they make such a statement, effectively to the FCC= ? In terms of what is driving this, I'm similarly confused. Unlike in the ca= se of other work we are doing in PTSC that impacts backwards compatibility = (e.g. caller ID spoofing), I don't see a massive public push for this, it w= ould be more of a convenience. Are there any current issues with interconn= ection rating for VoIP providers generally, who operate number blocks that = they use on a NG basis, but are charged for some kind of LD interconnect wh= en these numbers call others in their geo but which are in another LATA? From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A= [CTO] Sent: Thursday, February 25, 2016 8:28 AM To: McGarry, Tom >;= 'Modern List' > Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft "One way to enable NNP is to remove the NPAC edit and allow the TN and RN t= o be in different geographic areas... It's been reported that a call of this type in certain older technology swi= tches will fail. If so, then new software would have to be developed for t= hese switches to implement this solution." I feel like I've been transported back in time to read e-mails offering "te= chnical" reasons why number portability is challenging or impossible. Can the claim starting, "It's been reported.." be substantiated with a refe= rence? As an editorial comment, I'll offer I was confused by references to "NXX-NX= X". From the context, I assume you actually meant NPA-NXX. Do I assume co= rrectly? I agree with those who question whether the transition to IP drives a need = for new number management solutions. >From my last response to the MODERN "problem statement"... "The MODERN problem statement is in fact a TN management solution framework= . i.e., a solution looking for a problem. If there is a problem that MODERN addresses, it is the inability of end use= rs to directly (through a protocol) manage requisition and release of TNs a= nd manage their associated metadata. This is not a protocol problem. It i= s a policy problem (if it is a problem at all). And the only provisioning = protocol I remember seeing referenced in the solution statement is a SIP RE= GISTER. In this, MODERN is hardly any different then TRIP and equally usef= ul. My main recommendation is to scrap the so-called problem statement and star= t over. Do not introduce any text that even resembles a solution framework= . The problems can then be easily identified and discussed. And I encoura= ge discussion of policy as part of the problem so that in the end you can h= opefully clearly differentiate between issues that are political and issues= which are technical and therefore appropriate for the MODERN WG." Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: February 25, 2016 8:57 AM To: 'Modern List' > Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft No, it is just one "proposed" solution. From: Richard Hill > Date: Thursday, February 25, 2016 9:44 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft Yes, but such a green field space can, and has been, implemented on the PST= N, so the use of an all IP solution is not a requirement. Whereas your dr= aft implies that it is, unless I misunderstood something. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 15:42 To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft The point is, it is a green field numbering space within a country. These = concepts would apply to any green field numbering space. And it is a use c= ase, it just so happens to be based on a proposal in the USA, it could have= been proposed anywhere and it would still be a use case. From: Richard Hill > Date: Thursday, February 25, 2016 4:25 AM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft The abstract states "While this focuses on an effort occurring in the USA = the concepts are applicable to any country." I think that it would be better to change that to "This focuses on an effor= t occurring in the USA; but the concepts may be applicable to other countri= es." I say this because non-geographic numbers have already been implemented in = other countries, on the PSTN, without the use of IP-networks, whereas the I= ntroduction of the draft states that non-geographic numbers "would be hoste= d on an all-IP network of switches called non-geographic gateways (NGGW), = rather than the existing TDM tandems operated by the incumbent local excha= nge carriers (ILECs)." Separately, I still wonder whether it is appropriate for the IETF, which is= supposed to be a global entity, to develop a protocol that is apparently o= f interest to the USA only. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=E9vrier 2016 02:18 To: Modern List Subject: [Modern] Nationwide Number Portability MODERN Use Case Draft http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt ________________________________ 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. ________________________________ 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_0dd72becae6d4d9b8ea4bccc4d9f9602PLSWE13M08adsprintcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I didn’t say there was no problem= for MODERN to solve. I said that the MODERN “problem statement= ” was not a problem statement, but instead a solution framework for an undefined problem.

Telephone numbers are owned and assigne= d first and foremost by national numbering authorities.

The number authorities delegate number = blocks to licensed regulated entities which both make individual assignment= s and further delegate block assignments. (Very much like RIRs not surprisingly.)

At some point of distribution, delegati= on presents serious problems for efficient management of address space.&nbs= p; (Anybody remember RFC 1918 and NATs from Hell?)

Any solution framework with proposes no= n-traditional management of telephone numbers MUST address efficient and ac= countable assignment. How is this not a policy issue?

From: Peterson, Jon [mailto:jon.pete= rson@neustar.biz]
Sent: February 25, 2016 11:33 AM
To: Holmes, David W [CTO] <David.Holmes@sprint.com>; Gorman, P= ierce A [CTO] <Pierce.Gorman@sprint.com>; McGarry, Tom <Tom.McGarr= y@neustar.biz>; 'Modern List' <modern@ietf.org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

While many of the people on this list a= re concerned exclusively with managing carrier numbering resources, a lot o= f the inspiration for this effort came from the increasing diversity of players who seem to be allocating and managing num= bers outside of the traditional carrier case. That would include enterprise= s, and OTT VoIP providers, and Internet texting system, things that don't t= end to have lots of installed traditional PSTN infrastructure. While I wouldn't go so far as to call it a "mass= ive public push," there are lots of systems today that let users acqui= re and managing telephone numbers as resources for basically Internet appli= cations. In some cases, even entities we'd recognize as traditional carriers are fielding services that let users all= ocate and manage multiple telephone numbers as aliases for different househ= old members on one line, or similar functions.

And moreover, we keep hearing that ther= e is some kind of IP transition underway, and that many carrier networks wi= ll move permanently to systems that look at least somewhat more like Internet applications. How much they will resemble them= , and how quickly we will get there, are matters of debate, sure. But havin= g some protocol tools to perform these functions isn't a particularly far-f= etched goal, nor is it particularly a question about policy, nor will it force anyone to adopt anything any fa= ster. It will just enable the services that want these capabilities to depl= oy them. It is literally only a protocol problem.

</first principles>

From my perspective, the NNP use case i= sn't an outlier in terms of what it would require from those protocol mecha= nisms. I do imagine that a lot of the "native" Internet applications that use telephone numbers benefit from portability,= and would benefit more if portability were more flexible: the geographical= limitations on portability are an obvious anachronism in our age of mobile= phones. If we're going to build these protocol tools, ideally they should be able to handle the range of p= olicy outcomes that we anticipate are coming down the pike. I'm not sure I'= d be defining a solution here any differently because of NNP's specific req= uirements; depending on exactly how it is realized, the information model might admit of a different field= here and there, but the information model needs that extensibility anyway.= So... the protocol tools will basically accommodate it, if industry and re= gulators wanted to use them.

Jon Peterson

Neustar, Inc.

From: Modern <modern-bounces@ietf.org> on behalf of "Holmes, David W [CTO]= " <David.Holmes@sprint.c= om>
Date: Thursday, February 25, 2016 at 8:45 AM
To: "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com>, "McGarry, Tom&quo= t; <Tom.McGarry@neustar.biz>, 'Modern List' <modern@ietf.or= g>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

And that , to quo= te Mr. Dolly, would require “digging up the graveyards around Indian = Hill”. In other words, ain’t going to happen.

What we need is an &#= 8220;official” statement from ~~ALU~~ Nokia et al that this is not practical.&nb= sp; But would they make such a statement, effectively to the FCC?

In terms of what is driving this, I&#= 8217;m similarly confused. Unlike in the case of other work we are do= ing in PTSC that impacts backwards compatibility (e.g. caller ID spoofing), I don’t see a massive public push for this, it would b= e more of a convenience. Are there any current issues with interconne= ction rating for VoIP providers generally, who operate number blocks that t= hey use on a NG basis, but are charged for some kind of LD interconnect when these numbers call others in their geo b= ut which are in another LATA?

From: Modern= [mailto:modern-bounces@ietf.org= ] On Behalf Of Gorman, Pierce A [CTO]
Sent: Thursday, February 25, 2016 8:28 AM
To: McGarry, Tom <Tom.= McGarry@neustar.biz>; 'Modern List' <modern@ietf.org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

=

“One way to enable NNP is to remove th= e NPAC edit and allow the TN and RN to be in different geographic areas…

It's been reported that a call= of this type in certain older technology switches will fail. If so, then new software would have to be developed for these switches to implemen= t this solution.”

I feel like I’ve been transported= back in time to read e-mails offering “technical” reasons why = number portability is challenging or impossible.

Can the claim starting, “It’= ;s been reported..” be substantiated with a reference?

As an editorial comment, I’ll off= er I was confused by references to “NXX-NXX”. From the co= ntext, I assume you actually meant NPA-NXX. Do I assume correctly?

I agree with those who question whether= the transition to IP drives a need for new number management solutions.

From my last response to the MODERN = 220;problem statement”…=

“The MODERN problem statement is in fact a TN management so= lution framework. i.e., a solution looking for a problem.<= /span>

If there is a problem that MODERN addresses, it is the inability of e= nd users to directly (through a protocol) manage requisition and release of= TNs and manage their associated metadata. This is not a protocol problem. It is a policy problem (if it = is a problem at all). And the only provisioning protocol I remember s= eeing referenced in the solution statement is a SIP REGISTER. In this= , MODERN is hardly any different then TRIP and equally useful.

My main recommendation is to scrap the so-called problem statement an= d start over. Do not introduce any text that even resembles a solutio= n framework. The problems can then be easily identified and discussed. And I encourage discussion of policy as pa= rt of the problem so that in the end you can hopefully clearly differentiat= e between issues that are political and issues which are technical and ther= efore appropriate for the MODERN WG.”

Pierce

From: Modern= [mailto:modern-bounces@ietf.org= ] On Behalf Of McGarry, Tom
Sent: February 25, 2016 8:57 AM
To: 'Modern List' <modern@ietf= .org>
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

=

No, it is just one "proposed"= solution.

From: Richard Hill <rhill@hill-a.ch>
Date: Thursday, February 25, 2016 9:44 AM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>, Modern List <modern@ietf.org>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

Yes, but such a green field space can= , and has been, implemented on the PSTN, so the use of an all IP solution i= s not a requirement. Whereas your draft implies that it is, unless I misunderstood something.

Best,

Richard

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 15:42
To: 'Modern List'
Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case = Draft

=

The point is, it is a green field numbe= ring space within a country. These concepts would apply to any green = field numbering space. And it is a use case, it just so happens to be based on a proposal in the USA, it could have been propos= ed anywhere and it would still be a use case.

From: Richard Hill <rhill@hill-a.ch>
Date: Thursday, February 25, 2016 4:25 AM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>, Modern List <modern@ietf.org>
Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case = Draft

The abstract states “While this= focuses on an effort occurring in the USA the concepts are app= licable to any country.”

I think that it would be better to ch= ange that to “This focuses on an effort occurring in the USA; but the= concepts may be applicable to other countries.”

I say this because non-geographic num= bers have already been implemented in other countries, on the PSTN, without= the use of IP-networks, whereas the Introduction of the draft states that non-geographic numbers “would be hosted on = an all-IP network of switches called non-geographic gateways (NGGW), = rather than the existing TDM tandems operated by the incumbent local = exchange carriers (ILECs).”<= o:p>

Separately, I still wonder whether it= is appropriate for the IETF, which is supposed to be a global entity, to d= evelop a protocol that is apparently of interest to the USA only.

Best,

Richard

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: jeudi, 25. f=E9vrier 2016 02:18
To: Modern List
Subject: [Modern] Nationwide Number Portability MODERN Use Case Draf= t

=

ht= tp://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt

=

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.

Sure, I'm not saying the problem statement is perfect - it needs to be= tter reflect the motivations here, and hopefully the next iteration of it w= ill do so. But it does in fact identify a problem: the problem is the lack = of protocol tools that support allocation, management, and resolution of telephone numbers in the all-IP environments= within our scope.

Telephone numbers are owned and assigne= d first and foremost by national numbering authorities.

Naturally, delegation begins with the numbering authorities, and nothi= ng we say here suggests otherwise.

The number authorities delegate number = blocks to licensed regulated entities which both make individual assignment= s and further delegate block assignments. (Very much like RIRs not surprisingly.)

We have lots of pretty pictures of number blocks passing from regulato= rs, through carriers, potentially to resellers, and ultimately to end users= , and the use cases in the modern-problems document show flows just like th= at. That is the common case.

However, we wouldn't all be here today if there was not interest, from= both regulators and from some companies, in tweaking what sorts of creatur= es are "licensed regulated entities." The IETF doesn't drive or e= ven influence that decision. In some nationalities, regulators have already issued rulings that qualify entities other than on= es we'd traditionally deem "carriers" to be first-class citizens = in numbering, to receive their own number blocks allocations. So, we also s= how that as a use case, because it is, apparently, a reality on the ground. Not the only reality, but something to show as a = use case.

At some point of distribution, delegati= on presents serious problems for efficient management of address space.&nbs= p; (Anybody remember RFC 1918 and NATs from Hell?)

Creating protocol tools to support allocating, managing, and resolving= telephone numbers on the Internet is not synonymous with a free-for-all th= at will exhaust the numbering space because I can get a new telephone numbe= r every time I send a packet to a web service. If it was, then the first iteration of Google voice (or any= number of similar systems that let you log in to a web page and, you know = allocate yourself a number) would have destroyed the PSTN, right? The tools= have to have foundational security and authorization capabilities that will let authorities at various points= in that chain of delegation. Our use cases will elucidate what those requi= rements are.

I do remember RFC1918, it is one of the IETF's most successful technol= ogies. We aren't suggesting private numbering spaces as a MODERN use case -= though now that you mention it, I could imagine one. ..

Any solution framework with proposes no= n-traditional management of telephone numbers MUST address efficient and ac= countable assignment. How is this not a policy issue?

You mean something different by a "framework" than a protoco= l framework, and probably something different by "solution" than = an RFC. Other bodies will make administrative decisions about how numbering= blocks, at a national or carrier or corporate level, will get divvied up and used efficiently. The tools we are generating here= are protocol tools that only serve those policy decisions.

Jon Peterson

Neustar, Inc.

--_000_D2F4829C17AECCjonpetersonneustarbiz_-- From nobody Thu Feb 25 11:08:19 2016 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 82A2C1B31B0 for ; Thu, 25 Feb 2016 11:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 kEAHWelx_c8W for ; Thu, 25 Feb 2016 11:08:11 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C221B31A7 for ; Thu, 25 Feb 2016 11:08:11 -0800 (PST) Received: from BL2FFO11OLC002.protection.gbl (10.173.160.31) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.1.422.5; Thu, 25 Feb 2016 19:08:08 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BL2FFO11OLC002.mail.protection.outlook.com (10.173.161.186) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Thu, 25 Feb 2016 19:08:08 +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 u1PIChgO018921; Thu, 25 Feb 2016 13:08:07 -0600 Received: from plswe13m02.ad.sprint.com (plswe13m02.corp.sprint.com [144.229.214.21]) by plsapdm1.corp.sprint.com with ESMTP id 216pnh1x5c-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Feb 2016 13:08:07 -0600 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 25 Feb 2016 13:08:07 -0600 Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Thu, 25 Feb 2016 13:08:07 -0600 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , "Holmes, David W [CTO]" , "McGarry, Tom" , "'Modern List'" Thread-Topic: [Modern] Nationwide Number Portability MODERN Use Case Draft Thread-Index: AQHRb2pm7PDoPWgGMEWIEhdbfE2ttZ88e5hwgABbCQCAAAB2AIAAA5cAgAAUeeCAAAWi8P//30YAgAAzgrD//9xCAIAAOCdg Date: Thu, 25 Feb 2016 19:08:06 +0000 Message-ID: References: <00cd01d16fdb$1a128f80$4e37ae80$@ch> <68346e41454447f1b75d61da4c51821b@PLSWE13M08.ad.sprint.com> <3af9e40382f34867bd866707fc4b1ce9@PLSWE13M01.ad.sprint.com> <0dd72becae6d4d9b8ea4bccc4d9f9602@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.25] Content-Type: multipart/alternative; boundary="_000_c24a377076914feba117b48c2fd24c84PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC002; 1:OBBpVtW1HzfY6guKzh7vlf1JQY6WlHaxkNWNav8tdVT5HB4xnKjrB0bg/YjSgkhuxXBWHiWHT+Ajb8U8POVG2uax0EN9SoBT2afGi3WWKawvvLO5rz5jv1zV5q5Sym53ei48jMa77FVk44P94R63wBGRKPxhBd9PfQWtBhLZu3PoTthz+mMWajHf5Hr+UjsB4onO6AhTst3DhOsZb9xATct9jmW/R8ErItTIwz8qA71OWN+2J/TOIdSBJNeUAoTlbH7z8jNFuhNEheAH6F1CUXQiXTCAGS3dK1jIODh+A27Lj07Q1x9gEAYoceYilLPFj05mCSfo6RvBPbGBWJSYlzhTmQiHhoOAtur2WwdfewnqxB+pJaxGEaKGO7Me47KOOUVmTZSERN3JLWiOX2XeSSxrEqDitSaRwUPuQcQWn+8= X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(199003)(87936001)(24736003)(108616004)(76176999)(54356999)(86362001)(33646002)(50986999)(11100500001)(93886004)(189998001)(106466001)(1220700001)(5004730100002)(5008740100001)(3846002)(586003)(16236675004)(102836003)(1096002)(6806005)(790700001)(19625215002)(92566002)(300700001)(106116001)(15975445007)(107886002)(19580395003)(5001770100001)(5001960100002)(2950100001)(2900100001)(19300405004)(2906002)(260700001)(512954002)(4546004)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB016; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-MS-Office365-Filtering-Correlation-Id: 84435ffa-e39f-48b5-e203-08d33e16ff92 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB016; 2:EkYBeKZCvQwBwyt9VGbiAWPQJtJPniXeZRa0Cc5970W2S2wKB8AXSlWFg4NKM8q7juQfL/PBXXjb9W3m1K0QluOIjsnx/Miv58ONOdGVzsCJYgCasy0vtvzHsSZrpe/GeVF/GZtAMJ88YbliEBbMHDSc+Q/z5Vb/mUIUEvWImNHVSODvKg+knZAx16g2cK2p; 3:WQUx99+Kxz9b33gXyG848LcdnkQts/M3M44L7ZUVE2wenm2UWCC/GfS5K3LBUKaAQdv86iQLcepFglxe2CYx0Kl8A0GQp9e3AaTNasPjS4zRza5ZMKYlWzESH3f7SrWkGkb54EURFt17Pxu6dMdqhwzoIaGjnf7mE48jQR2tQDTz8o+0I8RIPm4Y68cA0EcPuMJdnDO/TLk3s6yZLEbd3q4tzoaec5dAE9/y1azkvKCPbRn5ausEB+9/UjkY04J3yqbXW7kbRpMr5I3vT7jlTw==; 25:yvH01Q8wkOv7LDPCymsn8C2ulU8QNYhTzMPiaOkVTGhwmORaLZMynV6DXSVGTtk2vEl6ufDN0bm4XmGAHFI9KB+3GLyh/ZvqXFYqrwon6nJKKvsgnfKLdyF7dPJr8vkfS2WhwOOEgHRCdQ4Mh88keN7CuirtMinhEkVtlqueSPdXHFuIUMKRPJgoS9CU+Izcr2dBIf2IDeXEtRY4xLH6gUWbJtvHJLU8qmileKNpIYi+0489Dp7/i+aH4Ln40FKNVhnylaCgnVNClW6uU5tD3xggJNGeq4do21wdc+OztiKK/naXlmYSsizMrK1H8+7yUGMi8yxoryq/eYJOm70Nc5lUbf1WghImtz5ufllx2E+mketszZ6L6OsugQb3IBV0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB016; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB016; 20:PhDcooPqHtesx9Vp5Le2hCNJVd3/JTkTJ9jg17z4DwWhtDA33LqvCTRyZpay0VI2q4pO9CMm0fLCXckb7aozjRf4vwmh/Em8ERRjYhAHY4Q9UovPg9jA7fc9UCCMTMsCUTrtQ0CCQG8DTJ0Bas4njE4sKZY7iONcDFyIj7mVUpADXbU2vKw1TCN+M7DAr0vNRYXqy0GG9L4uHtC2R4iBGw/JEcX+AVg1P5RmiXWAghnrT+OR6VFbNsDIgwq3ADLz; 4:LAHk3t84dlKf68mlW3J5N/AGB4uJdg2uw2JKyCU181j3jZXN6hKFeEzNjM66BF9/yyQcCnkAgIJgNqgPEDr7V5Zd+C2MhjyhYXJYhVLXwyQz3d+SeNNOlpyzzYXgpPx+hTPh2O8x+WBfGWfL2WStwLBu9oJDVHkkCseCLyYR2nMyc5AGiaCHi5QQ3eAVwhdk0DQSlDZlcDhSld2bAbFJ2IO0MRwgFUfex9woYuUo0cN14gIxrSg2MuReok8HdssBOMtv3EISZ7nMmXKM8E2ljpe1gkZpg+YblFrfGdJOrKLHU2ge5W/wl5+rpoKaTok3ILUpw4/wlfVxDP+hfvkHiTW4EFhsC6RLrxKr/DJnhvu7IeyguI8d7Y+/Z6o/ZVsJYHdJiW2KvehKuQOamb7/tJMhCISjfFNBOucnkIjlsccVhP956ujM6wflo2oY2E/EU5eM1HnGWyKEMXJgIjqWyQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13018025)(13015025)(5005006)(13017025)(13023025)(13024025)(10201501046)(3002001); SRVR:BL2FFO11HUB016; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB016; X-Forefront-PRVS: 08635C03D4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB016; 23:Xzb/vjGHvdwlVnbkGSw2M7aZCGziaCESHDACVLC7?= =?us-ascii?Q?9AC8njzjf5q/q2Jw9CGzn9sfhLG3N7g2GkfP96lMytubNlxU/5HMc5BdK0cz?= =?us-ascii?Q?hxzLQpHK4WY9nXJB65yY3v1rDHFTl+Kw9R/VuzyLSg/cUduU0ijkv8leKhhA?= =?us-ascii?Q?GmFk9mMxX8Gyufuv2aDNTcjiqKyvQ6B+FuVGkjHoSyQgqDKaXrvC8t+UNjMf?= =?us-ascii?Q?qEBsred5UCZhQ9QLrahKOv6r/qhEbRyH9MxefDBWu/v8QVKLN5AfFCk82kJE?= =?us-ascii?Q?mU/9ZPAZXK7H56MxxrqxLV5GQWSl6PcKUetLklhVnR8et0yyko6M2G6F25t+?= =?us-ascii?Q?39/hlQ+4WdhFYOFEaJl5cltTQFmGRvsZBZt8wopuP1PSlG8Co2bObMrbgNdL?= =?us-ascii?Q?0MtQWvUu+H/po8XRroTyfKXdRa1vVRbj34EWSwVnefAX3exGEI/IixPVRROM?= =?us-ascii?Q?pSRVmwUYhFcW5ff4CRNiR1cIVORi4lXVk2yZKNqcoWEpd/6AnpRQwTmoGZJ+?= =?us-ascii?Q?9jdYVzWpludlauTbRVu3IKnIZ+LlyCdK9M4Vt1IjeOxoTwiLRz0secqsQx0p?= =?us-ascii?Q?pOJI9aTLag7OKePLDykiPheG8qsMDY6QWHfXmkWYd8dRDyTawhxvy3GJDzIi?= =?us-ascii?Q?ZedyhKNzb+SX3Nh27QcztMbs8IZXHm0li8sOgzBRqwLh6f4OP+jIzsZTzxjA?= =?us-ascii?Q?yhtJi82baAwoIsFtaoBQm3qcVqoMXiAN8k/RYfDqXfPgRZN1Y5/XrYSfeVtV?= =?us-ascii?Q?JNpCbSx0N5OcSbMR7zm89aYbfJvOE2t3yje/6FIj26zTzg8/yb/fl6ZCuppk?= =?us-ascii?Q?VqhfQhpb3XT7qzQX/l7k10EPpoKKYfKo6QjoRqwbcs46Fk3uaFeMFhrK3nYA?= =?us-ascii?Q?36f6KXXCLYl9OTIMQFsYxWQDuO0CYQfZy/5Z66DViKFoYjb1OMsg1EjriA0+?= =?us-ascii?Q?WKYCK05EmJBR0xRt0WCp8u899bI7ZRoJAdkeDQeueqhwffKeZ5kFCf7wu6dz?= =?us-ascii?Q?BDgBZdK8zh6Ml6E7UlXgBeLHtuXi7aUlBSLlc2NJzIyAfuuB5iK/LaLo9vzl?= =?us-ascii?Q?5aKZOrkQUW8/NjSDYpWg+JlbC2k9bSgdxSMK/5Zr+D/8z4wanOLbglDgwFSf?= =?us-ascii?Q?ZY75J6SUg9dxZm3VhcOsfx52jviEKJ5UuAcRKYmgGTVzc3zmjLglydETLSJx?= =?us-ascii?Q?+iAKxxT9ccrPenY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB016; 5:qTawhlAokCqKPPCA6bINK7SdKTlTom3K2WiU9MTSEXAeotf0RF9dp0sUv5mX+O/Z/H3H/3zDXI1p+i7uMrUZkUA64cGAwh5i/Zj/IjGk9kQqu8XiPdh26ipL1BzitGvL7v7dbKm80uwhqQDHewGreQ==; 24:owjZIo3qv0NpKvobUIfeNn2bnZpDjUJNVuK9SCWaGfbAO7PsBndTKPU3S19oNOLCcn6fZFjSal+PiDEWVTq0hNkSdIavmlYPzYDCGthb13o= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2016 19:08:08.5674 (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: BL2FFO11HUB016 Archived-At: Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft 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 Feb 2016 19:08:16 -0000 --_000_c24a377076914feba117b48c2fd24c84PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It feels like maybe we're making progress. You agreed the MODERN problem statement "needs to better reflect the motiva= tions here". You've asserted, "the problem is the lack of protocol tools that support al= location, management, and resolution of telephone numbers in the all-IP env= ironments within our scope." Some questions about "the problem" statement you've offered. What are "the motivations here"? Which protocol "protocol tools" are missing? What do you mean by "resolution of telephone numbers"? What are "the all-IP environments within our scope"? What is "our scope"? Asserting that protocol tools for " allocation, management, and resolution = of telephone numbers" do not need to be developed with consideration for ef= ficient accountable number space allocation is disingenuous. ________________________________ 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_c24a377076914feba117b48c2fd24c84PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It feels like maybe we’re making = progress.

You agreed the MODERN problem statement= “needs to better reflect the motivations here”.

You’ve asserted, “the problem is the lack of protocol tools that support allocatio= n, management, and resolution of telephone numbers in the all-IP environments= within our scope.”

Some questions about “the problem“ statement you’ve offered.

What are “the= motivations here”?

Which protocol “protocol tools” are missing?

What do you mean by “resolution of telephone numbers”?

What are “the= all-IP environments within our scope”?

What is “our = scope”?

Asserting that protocol tools for ̶= 1; allocation, management, and resolution of telephone numbers” do not need to be developed w= ith consideration for efficient accountable number space allocation is disi= ngenuous.

It feels like maybe we=92re making prog= ress.

Well, to me it feels like we're regressing into unnecessarily fine que= stions of definition, but, I'm willing to do that a bit if it helps to move= the work forward.

You agreed the MODERN problem statement= =93needs to better reflect the motivations here=94.

You=92ve asserted, =93th= e problem is the lack of protocol tools that support allocation, management, and resolution of telephone numbers in the= all-IP environments within our scope.=94

Some questions about =93= the problem=93 statement you=92ve offered.

What are =93the motivati= ons here=94?

As I'm sure you recall, the discussions that led to this effort were i= nspired by an FCC workshop which explored some questions about the future o= f number administration, related to industry trends that the participants p= erceived. Some of its issues were protocol questions, others weren't. The IETF created a mailing list about = it to discuss those protocol questions, and left other questions to other p= arties to address.

Which protocol =93protoc= ol tools=94 are missing?

Above, you quote me saying the tools that are missing were the ones th= at support allocation, management and resolution of telephone numbers. I ca= n say it louder if that would help.

Shifting briefly to envisioned solutions, I imagine that these three f= unctions will be accomplished by web services in most cases, in which case = what is largely missing to standardize these functions is the information m= odel. If you look at the TeRI draft, you'll at least get a sense of what I think the direction for developing a= n informational model would be.

I don't think this information is a revelation to anyone reading this = list.

What do you mean by =93r= esolution of telephone numbers=94?

A successor to ENUM as a protocol, effectively, though one with a rich= er syntax and semantics, something better aligned with the needs of communi= cations services for both service data and administrative data. Something w= here you can ask questions about telephone numbers of some sort of service, and receive answers from potent= ially diverse authorities who authorize you to see responses. More extensib= le, more like an Internet service.

This is discussed at some length in the problem statement draft, and I= don't think it is a particularly confusing concept.

What are =93the all-IP e= nvironments within our scope=94?

The ones I articulated: they run the gamut from traditional Internet t= elephony services for PSTN replacement, to over-the-top providers, to IP PB= Xs deployed by enterprises, to services like Google voice, to text-only ser= vices and related mobility functions, and the emerging services that we imagine constitute this "IP transit= ion" we're all talking about. It includes some relatively novel approa= ches that were discussed at the original FCC workshop, like distributed reg= istries. But ultimately, the environment is wherever we use telephone numbers on the Internet, as a communications end= point identifier or alias.

What is =93our scope=94?

Is this a repeat from the last question above? Are your next two quest= ions, "What is 'our'?" and "What is 'scope'?"

At a high level, the overall scope is the charter. I understand that y= ou don't support the charter, but I mostly just hear misunderstanding in th= ose conversations, where to me this charter is a simple and crisp protocol = development exercise, but people are going out of their way to read it like we're taking on a set of respon= sibilities for solutions the IETF would never willingly address.

Asserting that protocol tools for =94 allocation, management, and resolution of telephone numbers=94 do not need to be d= eveloped with consideration for efficient accountable number space allocati= on is disingenuous.

The only consideration that the tools need to give in this regard is t= he necessary security apparatus to enforce policies. What the tools do not = need to do is to bake in policy decisions: nothing about the development of= a tool that performs the protocol-level authentication of an allocation request needs to understand how or why tha= t request is authorized. This is how the IETF operates. We've developed man= y tools that support the allocation and assignment of domain names, say, in= cluding authorizing how people request and modify domain names, but the tools that perform those functions have n= othing to do with how much you get charged for a domain name by whom, or ho= w one makes decisions about who gets which names, or anything like that.&nb= sp;

Again, where is the consideration for efficient accountable number spa= ce allocation in Google voice? Well, in Google's policy decisions. Not in t= he web service, or the database interactions - not in the protocol guts tha= t turned into bits on the wire as you requested and received your number allocation. We're doing the protoco= ls, not the policies. That's what the IETF does.

If you see the work here for what it really is, it does not warrant th= e level of shock and indignation that it mysteriously inspires. It's much l= ess radical than, say, ENUM was when that was chartered.

Jon Peterson

Neustar, Inc.

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_D2F4915917AF8Ajonpetersonneustarbiz_-- From nobody Thu Feb 25 13:38:15 2016 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 4FB311B35B9 for ; Thu, 25 Feb 2016 13:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, 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 UU-7tISy-K5X for ; Thu, 25 Feb 2016 13:38:05 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 799D31B353D for ; Thu, 25 Feb 2016 13:38:05 -0800 (PST) Received: (qmail 14557 invoked by uid 0); 25 Feb 2016 21:38:05 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 25 Feb 2016 21:38:05 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id Nldu1s00R1MNPNq01ldxRT; Thu, 25 Feb 2016 14:38:03 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=8WrITzYgnNwA:10 a=feb39VjOjl0A:10 a=jFJIQSaiL_oA:10 a=PeFO9FbFhS32YxYntvkA:9 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=i0JjlejyNv93Mn0nxS8A:9 a=tHfkpv9B9fhxjVQB:21 a=BHbZ4Jjxq5b-HFVY:21 a=QEXdDO2ut3YA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=RpNjiQI2AAAA:8 a=c1ZxgNJpDHC3llkq:21 a=qdPXCP007o_ltkti:21 a=wv5KSD_wyKVP9EFx:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA: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=g3udmB1JwE62I14MiFf5SOJ7tBDAAqugkZNRe+65aRg=; b=H9ay5OPgvcSFkxAHNH1+daNvN6tAvTi4g0fFtwNGLiTmiywmRwTxz8xaB9aB9nJch82zFwNl6quDgqZF6IzrxjsZKZXnvSE2FE0U2jWq4YxwlIIMfK72PjZDlIGsVpkP; Received: from [12.251.244.54] (port=2775 helo=[10.20.101.180]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aZ3bf-0007Zv-Of; Thu, 25 Feb 2016 14:37:56 -0700 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 25 Feb 2016 15:37:48 -0600 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , "Peterson, Jon" , "Holmes, David W [CTO]" , "McGarry, Tom" , 'Modern List' Message-ID: <30829D02-D580-458F-9E88-FC5A7B3E0DF2@shockey.us> Thread-Topic: [Modern] Nationwide Number Portability MODERN Use Case Draft References: <00cd01d16fdb$1a128f80$4e37ae80$@ch> <68346e41454447f1b75d61da4c51821b@PLSWE13M08.ad.sprint.com> <3af9e40382f34867bd866707fc4b1ce9@PLSWE13M01.ad.sprint.com> <0dd72becae6d4d9b8ea4bccc4d9f9602@PLSWE13M08.ad.sprint.com> In-Reply-To: <0dd72becae6d4d9b8ea4bccc4d9f9602@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3539259475_927741969" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 12.251.244.54 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft 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 Feb 2016 21:38:14 -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_3539259475_927741969 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Pierce, there is a political agenda here that is unclear and very very ina= ppropriate for the IETF to pursue, but Jon doesn=E2=80=99t care. The IETF does no= t do policy and all of these requirements are clearly policy driven not to m= ention North American specific. I=E2=80=99ve given up trying to explain that National Numbering policy is a Natio= n State specific task under national law. Its seems to make no difference t= o Jon and company that there is no request or requirements from a authoritat= ive NRA for this work. There does seem to be a requirement to disrupt the ex= isting number allocation policy and or reverse the current direction the FCC= has taken regarding Local Number Portability Adminstration. They will not t= ake NO for an answer and will pursue their political agenda with all the zea= l of a Tea Party convert. So be it. They have their sandbox let them play = in it. As we know the realities of the situation may radically change in 9 months.= =20 We all believe that in the future we could use better tools to manage namin= g and addressing resources and better tools for the distribution of SIP inte= rconnection data but in the current scheme of things and policy priorities t= hat I=E2=80=99m aware of these issues are far far beyond the radar screen.=20 From: Modern on behalf of "Pierce.Gorman@sprint.= com" Date: Thursday, February 25, 2016 at 12:01 PM To: "Peterson, Jon" , "Holmes, David W [CTO]" , "McGarry, Tom" , 'Modern L= ist' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft I didn=E2=80=99t say there was no problem for MODERN to solve. I said that the M= ODERN =E2=80=9Cproblem statement=E2=80=9D was not a problem statement, but instead a sol= ution framework for an undefined problem. =20 Telephone numbers are owned and assigned first and foremost by national num= bering authorities. =20 The number authorities delegate number blocks to licensed regulated entitie= s which both make individual assignments and further delegate block assignme= nts. (Very much like RIRs not surprisingly.) =20 At some point of distribution, delegation presents serious problems for eff= icient management of address space. (Anybody remember RFC 1918 and NATs fro= m Hell?) =20 Any solution framework with proposes non-traditional management of telephon= e numbers MUST address efficient and accountable assignment. How is this no= t a policy issue? =20 From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 Sent: February 25, 2016 11:33 AM To: Holmes, David W [CTO] ; Gorman, Pierce A [CTO]= ; McGarry, Tom ; 'Modern= List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 While many of the people on this list are concerned exclusively with managi= ng carrier numbering resources, a lot of the inspiration for this effort cam= e from the increasing diversity of players who seem to be allocating and man= aging numbers outside of the traditional carrier case. That would include en= terprises, and OTT VoIP providers, and Internet texting system, things that = don't tend to have lots of installed traditional PSTN infrastructure. While = I wouldn't go so far as to call it a "massive public push," there are lots o= f systems today that let users acquire and managing telephone numbers as res= ources for basically Internet applications. In some cases, even entities we'= d recognize as traditional carriers are fielding services that let users all= ocate and manage multiple telephone numbers as aliases for different househo= ld members on one line, or similar functions. =20 And moreover, we keep hearing that there is some kind of IP transition unde= rway, and that many carrier networks will move permanently to systems that l= ook at least somewhat more like Internet applications. How much they will re= semble them, and how quickly we will get there, are matters of debate, sure.= But having some protocol tools to perform these functions isn't a particula= rly far-fetched goal, nor is it particularly a question about policy, nor wi= ll it force anyone to adopt anything any faster. It will just enable the ser= vices that want these capabilities to deploy them. It is literally only a pr= otocol problem. =20 >From my perspective, the NNP use case isn't an outlier in terms of what it = would require from those protocol mechanisms. I do imagine that a lot of the= "native" Internet applications that use telephone numbers benefit from port= ability, and would benefit more if portability were more flexible: the geogr= aphical limitations on portability are an obvious anachronism in our age of = mobile phones. If we're going to build these protocol tools, ideally they sh= ould be able to handle the range of policy outcomes that we anticipate are c= oming down the pike. I'm not sure I'd be defining a solution here any differ= ently because of NNP's specific requirements; depending on exactly how it is= realized, the information model might admit of a different field here and t= here, but the information model needs that extensibility anyway. So... the p= rotocol tools will basically accommodate it, if industry and regulators want= ed to use them. =20 Jon Peterson Neustar, Inc. =20 From: Modern on behalf of "Holmes, David W [CTO]"= Date: Thursday, February 25, 2016 at 8:45 AM To: "Gorman, Pierce A [CTO]" , "McGarry, Tom" , 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 And that , to quote Mr. Dolly, would require =E2=80=9Cdigging up the graveyards a= round Indian Hill=E2=80=9D. In other words, ain=E2=80=99t going to happen.=20 =20 What we need is an =E2=80=9Cofficial=E2=80=9D statement from ALU Nokia et al that this = is not practical. But would they make such a statement, effectively to the = FCC?=20 =20 In terms of what is driving this, I=E2=80=99m similarly confused. Unlike in the = case of other work we are doing in PTSC that impacts backwards compatibility= (e.g. caller ID spoofing), I don=E2=80=99t see a massive public push for this, it= would be more of a convenience. Are there any current issues with intercon= nection rating for VoIP providers generally, who operate number blocks that = they use on a NG basis, but are charged for some kind of LD interconnect whe= n these numbers call others in their geo but which are in another LATA?=20 =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A= [CTO] Sent: Thursday, February 25, 2016 8:28 AM To: McGarry, Tom ; 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 =E2=80=9COne way to enable NNP is to remove the NPAC edit and allow the TN and RN= to be in different geographic areas=E2=80=A6 =20 It's been reported that a call of this type in certain older technology swi= tches will fail. If so, then new software would have to be developed for th= ese switches to implement this solution.=E2=80=9D =20 I feel like I=E2=80=99ve been transported back in time to read e-mails offering =E2= =80=9Ctechnical=E2=80=9D reasons why number portability is challenging or impossible. =20 Can the claim starting, =E2=80=9CIt=E2=80=99s been reported..=E2=80=9D be substantiated with = a reference? =20 As an editorial comment, I=E2=80=99ll offer I was confused by references to =E2=80=9CNX= X-NXX=E2=80=9D. From the context, I assume you actually meant NPA-NXX. Do I assu= me correctly? =20 I agree with those who question whether the transition to IP drives a need = for new number management solutions. =20 >From my last response to the MODERN =E2=80=9Cproblem statement=E2=80=9D=E2=80=A6 =20 =E2=80=9CThe MODERN problem statement is in fact a TN management solution framewo= rk. i.e., a solution looking for a problem. =20 If there is a problem that MODERN addresses, it is the inability of end use= rs to directly (through a protocol) manage requisition and release of TNs an= d manage their associated metadata. This is not a protocol problem. It is = a policy problem (if it is a problem at all). And the only provisioning pro= tocol I remember seeing referenced in the solution statement is a SIP REGIST= ER. In this, MODERN is hardly any different then TRIP and equally useful. =20 My main recommendation is to scrap the so-called problem statement and star= t over. Do not introduce any text that even resembles a solution framework.= The problems can then be easily identified and discussed. And I encourage= discussion of policy as part of the problem so that in the end you can hope= fully clearly differentiate between issues that are political and issues whi= ch are technical and therefore appropriate for the MODERN WG.=E2=80=9D =20 Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: February 25, 2016 8:57 AM To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 No, it is just one "proposed" solution. =20 =20 From: Richard Hill Date: Thursday, February 25, 2016 9:44 AM To: Tom Mcgarry , Modern List Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 Yes, but such a green field space can, and has been, implemented on the PST= N, so the use of an all IP solution is not a requirement. Whereas your dra= ft implies that it is, unless I misunderstood something. =20 Best, Richard =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=C3=A9vrier 2016 15:42 To: 'Modern List' Subject: Re: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 The point is, it is a green field numbering space within a country. These = concepts would apply to any green field numbering space. And it is a use ca= se, it just so happens to be based on a proposal in the USA, it could have b= een proposed anywhere and it would still be a use case. =20 =20 From: Richard Hill Date: Thursday, February 25, 2016 4:25 AM To: Tom Mcgarry , Modern List Subject: RE: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 The abstract states =E2=80=9CWhile this focuses on an effort occurring in the US= A the concepts are applicable to any country.=E2=80=9D =20 I think that it would be better to change that to =E2=80=9CThis focuses on an eff= ort occurring in the USA; but the concepts may be applicable to other countr= ies.=E2=80=9D =20 I say this because non-geographic numbers have already been implemented in = other countries, on the PSTN, without the use of IP-networks, whereas the In= troduction of the draft states that non-geographic numbers =E2=80=9Cwould be hoste= d on an all-IP network of switches called non-geographic gateways (NGGW), r= ather than the existing TDM tandems operated by the incumbent local exchang= e carriers (ILECs).=E2=80=9D =20 Separately, I still wonder whether it is appropriate for the IETF, which is= supposed to be a global entity, to develop a protocol that is apparently of= interest to the USA only. =20 Best, Richard =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: jeudi, 25. f=C3=A9vrier 2016 02:18 To: Modern List Subject: [Modern] Nationwide Number Portability MODERN Use Case Draft =20 http://www.ietf.org/id/draft-mcgarry-nnp-use-case-00.txt =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 t= he intended recipient, please contact the sender and delete all copies of th= e message. =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 t= he intended recipient, please contact the sender and delete all copies of th= e 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 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_3539259475_927741969 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Pierce, &= nbsp;there is a political agenda here that is unclear and very very inapprop= riate for the IETF to pursue, but Jon doesn’t care. The IETF doe= s not do policy and all of these requirements are clearly policy driven not = to mention North American specific.

I’ve give= n up trying to explain that National Numbering policy is a Nation State spec= ific task under national law. Its seems to make no difference to Jon a= nd company that there is no request or requirements from a authoritative NRA= for this work. There does seem to be a requirement to disrupt the existing = number allocation policy and or reverse the current direction the FCC has ta= ken regarding Local Number Portability Adminstration. They will not take NO = for an answer and will pursue their political agenda with all the zeal of a = Tea Party convert. So be it. They have their sandbox let them pl= ay in it.

As we know the realities of the situation= may radically change in 9 months.

We all bel= ieve that in the future we could use better tools to manage naming and addre= ssing resources and better tools for the distribution of SIP interconnection= data but in the current scheme of things and policy priorities that I’= ;m aware of these issues are far far beyond the radar screen.

Meeting number:	640 492 516
Meeting password:	12345

Meeting number:	640 492 516
Meeting password:	12345