From nobody Mon Jan 4 07:16:25 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 77C961A8979 for ; Mon, 4 Jan 2016 07:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 C4fK0wh1Gw6e for ; Mon, 4 Jan 2016 07:16:22 -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 1DF4F1A8977 for ; Mon, 4 Jan 2016 07:16:22 -0800 (PST) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u04FEbIf005801 for ; Mon, 4 Jan 2016 10:16:17 -0500 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 206a7n2fw8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 04 Jan 2016 10:16:17 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 4 Jan 2016 10:16:16 -0500 From: "McGarry, Tom" To: "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiA Date: Mon, 4 Jan 2016 15:16:15 +0000 Message-ID: In-Reply-To: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601040271 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 15:16:24 -0000 Pierce, thanks for reviewing the document and the feedback. See my comments in line below. On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" wrote: >Steve, > >In section 1 I would strike the sentence, " Telephone numbering, >however, has long been transitioning away from a provider-centric model >towards a user-centric model." I think the statement is arguable and >isn't needed. Tom: OK. =20 > >The statement, " TN administration processes rooted in PSTN technology >and policies dictate that this be an exception process fraught with >problems and delays" may stand on it's own for someone familiar with the >technology, policies, problems, and delays, but I think that is probably >a small minority. > >Can you elaborate? If not, I suggest removing this statement as well. Tom: How about following that sentence with: "Processes were built to associate a specific TN to a specific service provider and never change it. With number portability the industry had to build new infrastructure, new administration functions and processes to change the association of the TN from one service provider to another." > >Also, I would suggest that users already have full control of their TN. >Certainly nobody will take it from them (although the area code portion >of telephone numbers using the NANP dial plan can and does occassionally >change). And the porting process is solely driven by the users. >(Although it might be worth pointing out porting in order to improve >inbound call routing to IMS-based numbers has been a consideration for >some North American carriers deploying VoLTE.) > >The statement, " Ideally the user would have full control of their TN and >would drive the porting process on their own rather than rely on complex >and time >consuming back office processes among multiple service providers" needs >work. What is the definition of "full control" and what makes full >control "ideal"? Tom: A few years ago my sister moved from E. 62nd St to E. 85th St in NYC. Her service provider would not let her keep her number. You and I know that is because she moved from one CO serving area to another and the company didn't want to go through the process of porting her number between their switches. While I would think this is not common, it's not rare either. Service providers build rules into their systems and processes that account for things like rate centers, wire center boundaries, LATAs, consumer addresses, etc. that seem logical to them, but may not to a consumer. I do think it would be beneficial for consumers to have the opportunity for more control over their numbers. As we move to IP, the timing is right to look at improving this. > >How about, "Some members of the MODERN working group think users ought to >be able to use an Internet-available database to directly make changes to >the services associated with and the provisioning of their telephone >number without assistance from service providera."? Tom: I believe this is better handled in the use cases, where this example is covered. =20 > >As mentioned before, claiming that the back office process among multiple >service providers is complex does not imply harm or even a problem to be >fixed. Telephony is complex, but it is also very useful so the fact that >it is complex doesn't mean that it is bad, harmful, or a problem to be >addressed. > >I recommend striking the phrase, "rather than rely on complex and time >consuming back office processes among multiple service providers". > >Part of the problem here is you cannot really assert a priori that a >MODERN system will be less time consuming or even less complex. The fact >that the user will necessarily require assistance from one or more >service providers in completing the provisioning of their service (in the >case of mobile telephony at least) makes this a certainty. In fact, it >would be easy to argue that MODERN will be more complex. > >I'm also confused by the reference to back office processes as though >they are inherently harmful. Other terms for the same activity are >Operational Support Systems (OSS) and Business Support Systems (BSS). >These terms don't have a negative or positive connotation though, so >perhaps they also don't belong in a problem statement? > >With respect to geographic number assignment, the rejoinder, "But the >overwhelming success of mobile telephones has increasing eroded the >connection between numbers and regions" has problems at least in the >context of the North American numbering plan. Tom: You're over thinking this. Mobile has always eroded the connection between numbers and regions - that's what it does. This is pointing out that it is now a dominant portion of the market. > >I think what you mean is that after a mobile telephone number is assigned >(likely for the majority of a user's life once non-geographic portability >is supported), a fair quantity of users (but far less than even 50%?) >will move outside of the geography of the original assignment rendering >the geographic information associated with that mobile number >anachronistic and inaccurate. I would agree with this, and I would agree >it causes problems for service providers. I wouldn't necessarily agree >it's a problem a new MODERN system could help with. > >What is lost in this view is that there is an underlying routing number >which still retains a very certain geographic component. Even if we >eliminated routing numbers and their reference to the LERG (again North >America-centric view), there are very real operational reasons for >wanting to recognize geography when "homing" the terminating service >processing (at least). > >One of the problems with Internet telephony is the lack of recognition >for geography both in telephone call routing and in number assignment. >Understanding geography and it's interaction with call processing and >numbering is going to be one of the key challenges for MODERN. I don't >mean this as a reason not to work on MODERN. I mean it as helpful hint. >There is a real cost both to service providers and users for unoptimized >call routing and media transport. > >I recommend changing the statement to, " But the overwhelming success of >mobile telephones has increasing obfuscated the connection between >numbers and regions". > >This way you point out that there is and should be an intentional >relationship between mobile telephone numbering and operations at least, >but that portability and Internet-telephony present special signaling and >media path optimization problems. > >The issue will be for MODERN WG how to develop a new system of telephone >number databasing that doesn't just recognize those problems, but somehow >helps with them beyond what is available with conventional mechanisms. > >That's more than enough for this session. I'll try to pick up tomorrow. > >Regards, > >Pierce > > >________________________________ >Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T >or T-Mobile rates. See >sprint.com/50offt.com_50off&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcLe= xtZ1oo >Ncfp01IYIaVqsORjI&m=3DCbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=3D4e2G= daZQ >gxzYOrBnyWBi4uVzX8ABHMm4DZyRE0TMgCE&e=3D > for details. > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DCbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=3D= 97kr >pL5WZ4HCVAJuQEFeidiyONXQzq6MgU_YyxDjq1Y&e=3D=20 From nobody Mon Jan 4 07:25:52 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 746AA1A896C for ; Mon, 4 Jan 2016 07:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 1leZsmpu5u-j for ; Mon, 4 Jan 2016 07:25:41 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBFF01A898A for ; Mon, 4 Jan 2016 07:25:40 -0800 (PST) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u04FPbgj025297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 4 Jan 2016 16:25:37 +0100 Received: from RHillNew (adsl-178-38-58-89.adslplus.ch [178.38.58.89]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u04FPaX4017982; Mon, 4 Jan 2016 16:25:37 +0100 From: "Richard Hill" To: "'McGarry, Tom'" , References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> In-Reply-To: Date: Mon, 4 Jan 2016 16:25:38 +0100 Message-ID: <001901d14704$2afd0000$80f70000$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACwFp7A= Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 15:25:45 -0000 Please see embedded comment below. Thanks and best, Richard > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom > Sent: Monday, January 4, 2016 16:16 > To: modern@ietf.org > Subject: Re: [Modern] Problem statement draft problems > > Pierce, thanks for reviewing the document and the feedback. See my > comments in line below. > > On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" > > wrote: > > >Steve, > > SNIP > >With respect to geographic number assignment, the rejoinder, "But the > >overwhelming success of mobile telephones has increasing eroded the > >connection between numbers and regions" has problems at least in the > >context of the North American numbering plan. > > Tom: You're over thinking this. Mobile has always eroded the > connection between numbers and regions - that's what it does. This is > pointing out that it is now a dominant portion of the market. In other jurisdictions, fixed-number portability has eroded the connection between numbers and regions for fixed telephony. For example, my Geneva fixed number starts with 022, but if I move to Zurich, I can take that prefix with me. So in fact there is no longer any way to determine with certainty a geographical region from a telephone number. SNIP > >I recommend changing the statement to, " But the overwhelming success > >of mobile telephones has increasing obfuscated the connection between > >numbers and regions". Building on my comment above, I think that the following could be added to the end of the above statement: "Further, fixed number portability has obfuscated the connection between numbers and geographical regions, in the jurisdictions where fixed number portability has been implemented." From nobody Mon Jan 4 08:21:32 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 D98081A8A44 for ; Mon, 4 Jan 2016 08:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkRlYpsp7PTn for ; Mon, 4 Jan 2016 08:21:26 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721111A8A42 for ; Mon, 4 Jan 2016 08:21:26 -0800 (PST) Received: from BL2FFO11FD030.protection.gbl (10.173.160.33) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 4 Jan 2016 16:21:24 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) 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.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 4 Jan 2016 16:21:23 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u04CGxN7016522; Mon, 4 Jan 2016 11:21:21 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm1.corp.sprint.com with ESMTP id 206bwf5na5-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2016 11:21:21 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 4 Jan 2016 10:21:19 -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; Mon, 4 Jan 2016 10:21:19 -0600 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4A= Date: Mon, 4 Jan 2016 16:21:19 +0000 Message-ID: References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD030; 1:k6/4HXVQGgtqBtZXUTwXzapR7QF9VpFp35FLDT017s/f2lzsknZFQhoAJiLzv4gmrsdktZW0fUsBIHKmYlxX6wtFns5hVsZyazZL/snLllDSntom42qS/QlBgSsUmTYAlez6Kyhz78YPtI+tz6RhW4UYR80Dcoy/uddvxqCplXo+VLaacOj8opLPWJZS8hfgs9lHWQn1tLuLc1IIQPl6jCBVuvVGYVlzgNMK5C2uf/ltwgyYrqG0Hm76s4o+bZQvsHt7w35sBcexPzdTuThJfJVmtJSmJv7CPQ/xnx91us/gCXZ1vkhVdDyMCEPbRV9CKh3FHz/2h9ewNbx6fAulvHQCNz7t238mBCX1e/AQLQCmTYedMEy/3ZNty84C2rmt X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(24454002)(479174004)(199003)(52604005)(51444003)(189002)(377454003)(1220700001)(76176999)(92566002)(2900100001)(46406003)(23726003)(102836003)(86362001)(50986999)(33646002)(19580405001)(15975445007)(97736004)(106466001)(5001960100002)(3846002)(11100500001)(6116002)(1096002)(586003)(189998001)(54356999)(81156007)(575784001)(97756001)(108616004)(107886002)(5003600100002)(15395725005)(2501003)(19580395003)(5004730100002)(551944002)(5001770100001)(6806005)(2950100001)(5008740100001)(24736003)(47776003)(87936001)(5250100002)(50466002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB034; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB034; 2:JBE31jCynjUDHeuRBsXlOSig9ZPXtq8c5G3g3QfjKlvqLAGWBTxil5fa4ZOrBlD4oTHRGbhb1NOllBJ1+e8a3Z0dr2jflECXKC0uisY8Ah50y0sgz3qs++kUUOAoOcsg1wcs4SlHghqv+KpktRRRAQ==; 3:VVUMEgUJ1o4qz7q3w194sVnAsY8tNK34uxVg3HqHLaXgk/AvOr2VRPyh+G8ENOOz3ggxUslRw0NAH8LgcUSXPO373MSjfmuNfIBQ3FR/SHo+2LKoVGDQU1O/c6E5WQjMUG8ZXTHyOXnz8GiCxX4Xd/XEbTj4KOOfuHyfdoHyeuwjvHZam26MiYRV1DmvkaY0E+yGRh8ZL1dLHxS4jEdPcr//V5z8C7aILMvDa4Y5Lqn+IcLoh9EVoejLJXRVMfl1rAv+a6WHo902Y6TfueEc8w==; 25:z1Hz5hq3kVP8xrD+44jHKR86HQDTanKvbZQhCGauQih819IqKTcare4zINGBL9ie/mOVe+T6Ymo/R5i9WuRF/VQ09brQkkkYtQ6eu/AsknacTrTu3WwArcnhFnYtshStOcxb3juQb8oGy1/Xno55IJcATOzWb/0IjtAehsb5A2bcRvm6+CXRbG/xXwMCINqE/FOACy/OVeMVYUYzevUKPmEPPD13kap9wuUdRDCQzQOgyhj2aWh0BzdlfpsqpBLKwFoeHv1gV3ESEGMIpaXhfg== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB034; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB034; 20:0SjO8vz7D4IY/NlRvv9FC5p7jPg2BUt9M4FxmjAsJN9n5MJ9Kh4f6BelgbkKcutgNDuXqaBFCNbX0p8im83srFvk970hCewQWZSSK9CDnTBzy5yRiBNjPe8camtIMRYgGvV7T1brz66HgljaOikQJMj7i5fXeW5VnrLitAhzgX6G/9CJu0sbyToBA709DBh5AfaRpJU6spFm4QsJWEUXkj2Q8G+tEAZ8r8iuKYfaakuPBHZ/ZGr3ZwTFjZgrYs52; 4:p3xI5hUznKQWc04uh7VYvwKaRdb4a3XmC5Lp/ph8MBt3emRqZzyphrKO8CDo5ek0uyYYn1F4eVhiueppFLKHIBbAfmqeik8MJ6AF8tuIShqaK83ZLElgPe8mzDdaZylASarzTrFv2MaaXKQPiLB/YC6zZkhrRApgO/RBPFzWEPErkbmRGpMeMplC5zPdVsmvoj6YQr67j9dPn3u+DRjOXXc15gklQjmd4Mg2RjF7TU4rl515wyZStj3Jc2lDiNTLJuZ8MHI/emwWbFZQAVP5xD2wQWUGo/xJRdCdXwkJHkaUREHK248mNe2Iyy0DQcSJflJ/YVrOE/yKweALivQtGaK0r9/tNXVomEJzN2H8AEwPv5x8HsjDpkPDVXWgC+XEfxNGoOQ00faWOOon8vR6cXqflDskmS10T/5WeO4oqYALpH7v/qoP2WbqXeHBikKd X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BL2FFO11HUB034; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB034; X-Forefront-PRVS: 08118EFC2B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB034; 23:jcJ0+X1MuAQVxpy7fYov0JEE7wzaCN8yt+iFJx/F?= =?us-ascii?Q?kIpmAZZ+7I0fDVntlAvmtbr3IEOMMJtTIN/3eN5B1n3EzVjuTadLXxm1bNCH?= =?us-ascii?Q?WtRLeHNzh3rv1r+/i0hXX3Xsh3t5Xz0ACA55H40vsYSgWQ9dAissUQR9QVYo?= =?us-ascii?Q?ZgnjuDozlK0zTKmhb4ZnTJVXlDnkNfZUtaumuHPwB1N2sKLK2VuNRrhdIPbD?= =?us-ascii?Q?jmZNCzDRaLydEw+KSYoHLzH1qY/OqEhXfw8R+bLxg+rqoi9YXb9jr8voVHOg?= =?us-ascii?Q?VqDS7B2k4EBH6Iz974ODRUVLBvWc8pDsHaxHXSfRhld1hB1g3yCmCpj2pfRN?= =?us-ascii?Q?CcdvN3ZQOf5WT1YMr5kTrlQPoK83Pgl3J9VBzazwfF91txlghmUy0pHuTzBh?= =?us-ascii?Q?N2rt5XdpOECkCWzd2KjlAr0OKNCsZa8od45Pyzq8ec4c0XzXOPdYjqpgSDmh?= =?us-ascii?Q?4V8fu5+eK1WRzm+a08OyJz83uZVNVEz73U1YM2rM8CkVhdEuaj+DMcPRAs3/?= =?us-ascii?Q?Wvrkby88230mCrBQr6tFI6wy+83Lrfv85Qli3NKuzIFTg6C7XMtjL2geNc3e?= =?us-ascii?Q?2q9TjFvHlESWH1JVG8qbKhAisyN5wOPuCspH5pBccnd1w5sH/yCCOvvAPyPA?= =?us-ascii?Q?46D8fhMXm+rLyrbHj5dsXKbsA2gQ66bsYzNEumV5Gg9+ANNzUGVN9TUV4ewO?= =?us-ascii?Q?t/8HJCILyoOZbVQf4tIQSujJ+2Fo3vQQpSTxcNA1uLZph9Z3wvUGH+WdLJuD?= =?us-ascii?Q?hBxp8e40KKZN0YHz2AV9mFgVgSRGI5EgpgiVljy/TgRpui+cEgUlCbHkdvYx?= =?us-ascii?Q?WE/sZVNtdxvOBm2HevSi65jx/ShYPkgZAKRYkp099v4s4rYXGsDexAf92AAb?= =?us-ascii?Q?bufIQOhE5a7lGc894lcrpOVyaWr7+I3T9FNmJL07XzK2balR+hk3JNfnZCBq?= =?us-ascii?Q?2DkdCBXwRkvbhuP26nsB3JuOq6O39TtPzK/b+zfCX9FW+ZBnMrVR9nqTh8rR?= =?us-ascii?Q?wW9PCtJ4JrEZr6Nn4PPCBhbaZUBQiSz7KWMHrZP/dP/akrJ/lS7nraPJ0689?= =?us-ascii?Q?FHhNNKx2zgOuAgE8iQihNMkCaY7uDImd+3qlythqn2usptHKEc1fq/ziBXIk?= =?us-ascii?Q?eovJyv/vW8roLWT44nr+ikHjKolVZXc1F5tFmHTd16I75KaCnR50Py3LVkR7?= =?us-ascii?Q?u+lC64YYNs8h2lY2FSUFHUEzOiSWq3AxPUAdSw/VvFQDW9HB/IaVeiEg5wlI?= =?us-ascii?Q?DwUvyZ0mw7L0FAoNessWjnQwGYMS05NLjGCd3At8nSJY/ejgYbaa6Jy7onGw?= =?us-ascii?Q?Wd0Ydh0X8Ae5uhHqZl/I1UBRAOVnERmhklS0++t7zyNF6WkvdIk2YiwLcFcv?= =?us-ascii?Q?hFqQXZcGgj6r/oDcRDDvhy/VLFrRHApmhtpXT5cUeaBMWeWYrgJVtW6//ynQ?= =?us-ascii?Q?rMf8gHfIrQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB034; 5:o3wu4ogxxM8NtF0GU8s/tXN6boaXHQ2K9mF5HGHbqCui0JQ/PooE09YMhnMlZKhVJgsSCUal+Ad62p88sgp2oG7FBMWVw89kU378RIroEdpFS9+n4Vfx4Xt+qHmVtSoB190GNYc7GY4zvUDOgnfoxw==; 24:ZfOenZxfBAS0OkM4fgBjfxeWMCmTlNF6F9xs+vWhxwQmWop5gWlZ6q/wNVQry1WtSVMvKk2tw36afbZSYTA66yCJn3Al4dYLn3t5/I6lzzw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2016 16:21:23.5960 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB034 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:21:31 -0000 Thanks Tom. Inline. I also have more edits but didn't want to send them out until I've complete= d the review (this week?). Best regards, Pierce Gorman Office: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: January 04, 2016 9:16 AM To: modern@ietf.org Subject: Re: [Modern] Problem statement draft problems Pierce, thanks for reviewing the document and the feedback. See my comment= s in line below. On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" wrote: >Steve, > >In section 1 I would strike the sentence, " Telephone numbering, >however, has long been transitioning away from a provider-centric model >towards a user-centric model." I think the statement is arguable and >isn't needed. Tom: OK. > >The statement, " TN administration processes rooted in PSTN technology >and policies dictate that this be an exception process fraught with >problems and delays" may stand on it's own for someone familiar with >the technology, policies, problems, and delays, but I think that is >probably a small minority. > >Can you elaborate? If not, I suggest removing this statement as well. Tom: How about following that sentence with: "Processes were built to associate a specific TN to a specific service prov= ider and never change it. With number portability the industry had to buil= d new infrastructure, new administration functions and processes to change = the association of the TN from one service provider to another." PG-> I'm OK with it. > >Also, I would suggest that users already have full control of their TN. >Certainly nobody will take it from them (although the area code portion >of telephone numbers using the NANP dial plan can and does >occassionally change). And the porting process is solely driven by the us= ers. >(Although it might be worth pointing out porting in order to improve >inbound call routing to IMS-based numbers has been a consideration for >some North American carriers deploying VoLTE.) > >The statement, " Ideally the user would have full control of their TN >and would drive the porting process on their own rather than rely on >complex and time consuming back office processes among multiple service >providers" needs work. What is the definition of "full control" and >what makes full control "ideal"? Tom: A few years ago my sister moved from E. 62nd St to E. 85th St in NYC. Her service provider would not let her keep her number. You and I know th= at is because she moved from one CO serving area to another and the company= didn't want to go through the process of porting her number between their = switches. While I would think this is not common, it's not rare either. S= ervice providers build rules into their systems and processes that account = for things like rate centers, wire center boundaries, LATAs, consumer addre= sses, etc. that seem logical to them, but may not to a consumer. I do thin= k it would be beneficial for consumers to have the opportunity for more con= trol over their numbers. As we move to IP, the timing is right to look at = improving this. PG-> My understanding is rate centers and LATA boundaries were defined by = attorneys as part of Judge Green's "Modified Final Judgement" in the United= States vs. AT&T antitrust case of 1982. It's unfortunate that it impacted= your sister (and others), and I agree that Non-Geographic Portability (NGP= ) should (eventually) address the issue. I disagree that the move to VoIP = has very much to do with NGP. I think you need to prove that a new MODERN = system of numbering would eliminate time from the back office processes req= uired by CSPs, or drop the point. PG-> I think you still need to define full control better. The example yo= u provided will be a benefit of NGP, not MODERN (unless MODERN were an unav= oidable prerequisite or undeniable benefit which I don't think anyone will = argue). > >How about, "Some members of the MODERN working group think users ought >to be able to use an Internet-available database to directly make >changes to the services associated with and the provisioning of their >telephone number without assistance from service providera."? Tom: I believe this is better handled in the use cases, where this example = is covered. > >As mentioned before, claiming that the back office process among >multiple service providers is complex does not imply harm or even a >problem to be fixed. Telephony is complex, but it is also very useful >so the fact that it is complex doesn't mean that it is bad, harmful, or >a problem to be addressed. > >I recommend striking the phrase, "rather than rely on complex and time >consuming back office processes among multiple service providers". > >Part of the problem here is you cannot really assert a priori that a >MODERN system will be less time consuming or even less complex. The >fact that the user will necessarily require assistance from one or more >service providers in completing the provisioning of their service (in >the case of mobile telephony at least) makes this a certainty. In >fact, it would be easy to argue that MODERN will be more complex. > >I'm also confused by the reference to back office processes as though >they are inherently harmful. Other terms for the same activity are >Operational Support Systems (OSS) and Business Support Systems (BSS). >These terms don't have a negative or positive connotation though, so >perhaps they also don't belong in a problem statement? > >With respect to geographic number assignment, the rejoinder, "But the >overwhelming success of mobile telephones has increasing eroded the >connection between numbers and regions" has problems at least in the >context of the North American numbering plan. Tom: You're over thinking this. Mobile has always eroded the connection be= tween numbers and regions - that's what it does. This is pointing out that= it is now a dominant portion of the market. PG-> I think you're underthinking this. :-) The majority of phone calls = are "local" and charged accordingly per regulatory requirements. This isn'= t changing. Also, mobile carriers cannot page an entire network for every = call termination attempt so localizing the call termination processing is i= mportant. A benefit of NGP will be optimized call termination localization= (at the cost of additional porting information management). i.e., call pr= ocessing can be optimized by porting numbers which spend a high percentage = of time hosted from a "visited" platform (within a CSP's network). Mobile= call processing necessarily resides in a platform with a geographic locati= on and regional responsibility. Numbering and geography for mobile call pr= ocessing continue to have an important relationship that needs to be recogn= ized, not dismissed. i.e., to optimize call routing and number management,= new number assignments should still be done with a sensitivity to geograph= y. And when numbers are released back to the CSP, new assignments with a n= umber should be within the context of the region from which the number was = originally assigned. This isn't a policy suggestion, it's a network design= and operation optimization. Geography matters. > >I think what you mean is that after a mobile telephone number is >assigned (likely for the majority of a user's life once non-geographic >portability is supported), a fair quantity of users (but far less than >even 50%?) will move outside of the geography of the original >assignment rendering the geographic information associated with that >mobile number anachronistic and inaccurate. I would agree with this, >and I would agree it causes problems for service providers. I wouldn't >necessarily agree it's a problem a new MODERN system could help with. > >What is lost in this view is that there is an underlying routing number >which still retains a very certain geographic component. Even if we >eliminated routing numbers and their reference to the LERG (again North >America-centric view), there are very real operational reasons for >wanting to recognize geography when "homing" the terminating service >processing (at least). > >One of the problems with Internet telephony is the lack of recognition >for geography both in telephone call routing and in number assignment. >Understanding geography and it's interaction with call processing and >numbering is going to be one of the key challenges for MODERN. I don't >mean this as a reason not to work on MODERN. I mean it as helpful hint. >There is a real cost both to service providers and users for >unoptimized call routing and media transport. > >I recommend changing the statement to, " But the overwhelming success >of mobile telephones has increasing obfuscated the connection between >numbers and regions". > >This way you point out that there is and should be an intentional >relationship between mobile telephone numbering and operations at >least, but that portability and Internet-telephony present special >signaling and media path optimization problems. > >The issue will be for MODERN WG how to develop a new system of >telephone number databasing that doesn't just recognize those problems, >but somehow helps with them beyond what is available with conventional mec= hanisms. > >That's more than enough for this session. I'll try to pick up tomorrow. > >Regards, > >Pierce > > >________________________________ >Learn more on how to switch to Sprint and save 50% on most Verizon, >AT&T or T-Mobile rates. See >sprint.com/50offrin >t.com_50off&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcLe= xtZ >1oo >Ncfp01IYIaVqsORjI&m=3DCbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=3D4e2G= d >aZQ gxzYOrBnyWBi4uVzX8ABHMm4DZyRE0TMgCE&e=3D > for details. > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you >are not the intended recipient, please contact the sender and delete >all copies of the message. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext >Z1ooNcfp01IYIaVqsORjI&m=3DCbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=3D= 9 >7kr pL5WZ4HCVAJuQEFeidiyONXQzq6MgU_YyxDjq1Y&e=3D _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jan 4 08:26:08 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 F25F91A8A4A for ; Mon, 4 Jan 2016 08:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI2yazDVInpG for ; Mon, 4 Jan 2016 08:26:04 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32F71A8A45 for ; Mon, 4 Jan 2016 08:26:03 -0800 (PST) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u04GPxuM007773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 4 Jan 2016 17:25:59 +0100 Received: from RHillNew (adsl-178-38-58-89.adslplus.ch [178.38.58.89]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u04GPvCS008748; Mon, 4 Jan 2016 17:25:57 +0100 From: "Richard Hill" To: "'Gorman, Pierce A [CTO]'" , "'McGarry, Tom'" , References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> In-Reply-To: Date: Mon, 4 Jan 2016 17:25:59 +0100 Message-ID: <014501d1470c$99da5f60$cd8f1e20$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4AAAVroEA== Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:26:06 -0000 Please see embedded comment below. Best, Richard > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, > Pierce A [CTO] > Sent: Monday, January 4, 2016 17:21 > To: McGarry, Tom; modern@ietf.org > Subject: Re: [Modern] Problem statement draft problems > > Thanks Tom. Inline. > > I also have more edits but didn't want to send them out until I've > completed the review (this week?). > > Best regards, > > > Pierce Gorman > Office: 913-439-4368 > pierce.gorman@sprint.com > > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom > Sent: January 04, 2016 9:16 AM > To: modern@ietf.org > Subject: Re: [Modern] Problem statement draft problems > > Pierce, thanks for reviewing the document and the feedback. See my > comments in line below. > > On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" > > wrote: > > >Steve, > > SNIP > >With respect to geographic number assignment, the rejoinder, "But the > >overwhelming success of mobile telephones has increasing eroded the > >connection between numbers and regions" has problems at least in the > >context of the North American numbering plan. > > Tom: You're over thinking this. Mobile has always eroded the > connection between numbers and regions - that's what it does. This is > pointing out that it is now a dominant portion of the market. > > PG-> I think you're underthinking this. :-) The majority of phone > PG-> calls are "local" and charged accordingly per regulatory > PG-> requirements. This isn't changing. Introduction of fixed number portability in Switzerland resulted in the end of geographical charging. Indeed, how can you charge by geography if the caller cannot know in what geography the called number is? SNIP From nobody Mon Jan 4 08:36: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 57ADB1A8A66 for ; Mon, 4 Jan 2016 08:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNdy1UuPergr for ; Mon, 4 Jan 2016 08:36:02 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6D01A8A65 for ; Mon, 4 Jan 2016 08:36:01 -0800 (PST) Received: from BY2FFO11FD037.protection.gbl (10.1.14.31) by BY2FFO11HUB035.protection.gbl (10.1.14.119) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 4 Jan 2016 16:35:59 +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 BY2FFO11FD037.mail.protection.outlook.com (10.1.14.222) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 4 Jan 2016 16:35:59 +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 u04FTJ0t019514; Mon, 4 Jan 2016 11:35:58 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by preapdm3.corp.sprint.com with ESMTP id 2069p76ev1-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2016 11:35:58 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 4 Jan 2016 10:35:57 -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; Mon, 4 Jan 2016 10:35:56 -0600 From: "Gorman, Pierce A [CTO]" To: Richard Hill , "'McGarry, Tom'" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4AAAVroEAAAKDPg Date: Mon, 4 Jan 2016 16:35:56 +0000 Message-ID: <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <014501d1470c$99da5f60$cd8f1e20$@ch> In-Reply-To: <014501d1470c$99da5f60$cd8f1e20$@ch> 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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD037; 1:Io338w4PjPFyHM27udlQBCt7gjD4wgux9jj4Ph+ipeGau/xW7pX8KubuvzihONQsgC/vG3wEeeV4FpC66YEumT3YJI4Y4qjf+I4LnxZ+LrdGEV8oVBGwAzqsZhwthXj4lOjtR4YyI3ninmgE/qJ5l7/xj51OX8IkXBjTSesAuScRPNY+mpoFtcov+zFMuiAmr2E1biFIY3FYpwv/JnBSSQqoMIEfRy8sdFEJANNIi0w4oTQ2GRq62WXsOytw6d4962y+9qTlctSDPhc/FBsn7oeiq59ZF8ogMfZOO3gUKw5O1TXPJFKYcVmzxBs+rsFTkhLRQlnwJtSRyvpdONih4T5HUdnvH5pvFrJg6o5w6bLs8rJ8YABjxkyYl4NNApc4 X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(24454002)(189002)(377454003)(479174004)(52604005)(199003)(586003)(5004730100002)(5001960100002)(46406003)(3846002)(54356999)(47776003)(15395725005)(5001770100001)(93886004)(6116002)(92566002)(5250100002)(50986999)(97756001)(102836003)(2501003)(11100500001)(86362001)(1096002)(108616004)(23726003)(81156007)(5008740100001)(24736003)(15975445007)(19580395003)(97736004)(19580405001)(5003600100002)(76176999)(107886002)(87936001)(2950100001)(33646002)(6806005)(2900100001)(106466001)(189998001)(50466002)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB035; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB035; 2:pTzLzRtfVD2+gZq8weHVAr7YGfL+VVAuiPHQT5jokSQJHlLKL5L6yMAuphaX6oT4k8ku/nGTq1kI4dcBnosE1XQg8J3soAWyHd4P87LTDA90GEBckZkfnTN119i/sxKtTp2mNiF+YXWvSP519RvnRA==; 3:oj0u0NSiKGR9p2PAUG1xwTYF/qNmDh/G7jcqyZlwN95cYhBCnxkyYruSh0F581Z5V8fufNVm5Y04tDQTGHi6o14m8rx1utArwnBTSXEpAeGhKHSb3vS0JTyen+EXKsU+JlTR3ZLbffW99tQA63m4BX3JDrgqm6j+NuN3st5sjKoVfSsJYpJu1oR/sFBF8UMpJQFrMJNK2pp1rXTzoX8sD+5qBaE7Bdh6y7qEORbP+suv+SO7eZcdeBz3ynz7QAXkUIDkaRGs7sHsyhmKpfXPrQ==; 25:4ODBMwNgmsWkwrnEXb+omB9gPIYEwHpJv9G8rahQDqEQETlPVTJpRa829SiGgwn9D8a+JGSI8QIvYKB/Unw3oXaRY6Cup6dtPT/A0LRjZ11S2c9MXw2xp90EoCFjslFkCdAXINwaTpTqmB6fVqwtTN8InKnQLgQmdBueM0lEeFUgMnrkNYQjNaf5XrQc9RGeTdx9m2YI9YXl6EDd9Dev7w8KL+BVgWL680o1rJq0ubbaplZV6bSGjN2sPgtJsJsyNPvMj9snBbwNVDeNvIbijw== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB035; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB035; 20:C3pJvLybfsx9yNCZyW7YiLZE3kSbnACPhrdW89aUkzGznDHLnXLg77HF6l83JyWvN1UG0w3xPnbGTQC6EJUzBR8JBdUaTs6uvBgtb+BnWsqnXkzurUrPKo1uVmI1rLrAZtnBKXPiTHpjtCESwWqGVychl4s6eIjufUulMRYtYlzM2Cpzsy6fcZ1vKxPUWqFS11pw12Zs2f2myDs7nqaq08qTDdDjwXmf+sdUUmlIqks5TmabRNv4zKcG+mk8M/lC; 4:C7v7PCErRrIRnwNa8tBnMJDezV35Bcak6ap9rBm6m/LBJR5eevPX1g3n8OPOXtnhzKsBwJpOJaBc6pmD6Ih4cQfmywtUfU/uJEFjZoaD6Ggy0khTRwXq+wLCJwDz7wG63Jly+M8zZd7flWs/pVlyc4vYRKnxo/K3hnrhzVaaa9/2oYjt9caQUDlpAdumDR/SxnHjAI59YEtyrWIeH5kbLOHDlqSJqBV8lMO5bCBczBjgKn07MzSbdXXpPrNZaYbhqUq7CKEFzMUThKvi6COh3dN+f5pcKNVFyCLYoF9AjwlSsHoilGcehCgvWxIXiOJ/Zo1uBCNxq2+EpeShlh5mGViNEaosR+2d24SrdXfAYMxvsaSefRw01G+LBEExenBOUEefV6a4WayO9ePG1PZZfj+y9QNkhib+NKqOu/NtnznOelGSfM4Itv3ObpJcKYSg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2FFO11HUB035; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB035; X-Forefront-PRVS: 08118EFC2B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB035; 23:lv0Incy/lDYcesLnRNx77fcBDdYwXQUJMOzIUC4G?= =?us-ascii?Q?ISOzJVxGWK0M7CTqUwE6jUT2d8DOjvi3cmP+kCek5V03T52FZu/l8ewCxwCx?= =?us-ascii?Q?412C0JBo/EVdrIe44dsRiz8WoVPWgfWUrt01XkyoVLUymW0LbbZEfJrg35/u?= =?us-ascii?Q?T1K2tz7QpxbUgR0hFwwG0uOdEKHtUXs/Q2Ujkl2bOFMIlUA3ieM64L6AHa2M?= =?us-ascii?Q?HrTeF7dWhSN0N5QoB7fApLNodhN+K+FKq5mZeaMuHsMXF3q69zN5yoA0TYlX?= =?us-ascii?Q?VtqWJWO4f0IUGlIeo3bYsCTLc5JZYIxEJw/M2WXdoPWymlIxFH0PZDD+d48a?= =?us-ascii?Q?XCtkeXhFonv/zopr8rXtetRnBIbQ+oLhz7DfuGhRsCeByqYAZDgMO5TUsdQM?= =?us-ascii?Q?AIdj/vA05SXKl6DpoqC896rTlWfHjMg+h2vUwGYSz9S5TWE2Jv4eBvqvUCxJ?= =?us-ascii?Q?jyHT8zszmequJlP/Dyl3s5kZ10qQbAfRY4LjJsY+a9FnOFMBOrLRPmKN15ON?= =?us-ascii?Q?lqrkSifhVAyk1uCcAkpEQ/cHzMAyoM2jhlSfQL+sjPGaAZooN3uZFDPDl6gC?= =?us-ascii?Q?NhhTWHUGsq1sDXus32Ll7xV2I606bopfNT3mHoyG7OiTilsWQCJVDnU3hLLl?= =?us-ascii?Q?pB/og5rrXtZUdKSxDfruqYxJipVx2aqFIf9yxG0/Txx6G1L+H8s/0THgBChR?= =?us-ascii?Q?3EmaRwrfgl/xCVQYKIQdQXDJ41WfPI41p6q8/UevTvOZ6pf/iABcKHYyvpSj?= =?us-ascii?Q?jnuv+IzeyRFnuoDZoIRAa9BSt2RTEyH5wYWRFTur2Y9H/vGLgKmtUTvwliuW?= =?us-ascii?Q?skGagbPU/ul7GDkBc4rU9StIMNzKKenOihzWFbldUnkyRH9RB38cWJ5uaEWT?= =?us-ascii?Q?N1C63IyZ+n3j4t0xQkqz1f9ML8wGyb2Bsfye8sEeN9gDUfeF+ysIhibv9XMQ?= =?us-ascii?Q?t444OnQyUh3mlLKx1lPUkfvGv59s9pT6pu0njOIvPNOXcT7QNLLJ88uzLI9C?= =?us-ascii?Q?vm54pvpaScYpAKufpp2gQCmFwuAw4zlCWdpkicYA9Y2mzdD6nLkF1hYBk7Pq?= =?us-ascii?Q?ow6G7TAKfoyKnx82j3rS6lq0H4xFD+Yk9BKquiAUmaXG7biayv6zFjpcQ2bt?= =?us-ascii?Q?Li9YNl30xCGoIXKTSouxNirt5WA945sfCY63CqZ57CDAgsbQHaeHOwOvs7r/?= =?us-ascii?Q?qlvUUkr8asg3wL2nnRJjcPXkIoHcuhOm067/HTzVfzWZ8LG44eRHZKaJM5Yh?= =?us-ascii?Q?i/mbjbqoIAwwXmGpwdYnAcD741UoqxF4jBy8FFvn4dqe/mbNd802ZKlLmelR?= =?us-ascii?Q?c8Mu+ZNfZp2zkF0qZsry1/iB0J1qGZIc28XQ2brRr5Og?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB035; 5:c3NLjg2XNhCMWDPtU0/RpnHJYbJJ7jDL9OnOUHCW07KFfiyJrXED5QrD97wkzHlcUkR/CqbnLijTQTm1QXe+EyXUmryS1wnWDKiJ06++jyQLsjp1oSOLGPBe2RfU/+iyO0uL8RFiE4+1iHjCFcnbWQ==; 24:47wO49q29gwJyDIq1zBiEeJoZj6vnQaquttJbnTwwTOPR0f1MKEb0gLFPjTEPqazHjzNEvDds2P3WSWmEb4i3MizLzMMu0pN3JFxTDCCifg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2016 16:35:59.0926 (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: BY2FFO11HUB035 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:36:04 -0000 Good to know. Thank you. Just because the users don't know where a call originated and terminated do= esn't mean the network does not or cannot know. I'll speculate that the Sw= iss portability uses a similar mechanism as used in North America and the p= orted number is associated with a "Local Routing Number" which indexes back= to a central office switch with a specific geographic location. The origi= nating CSP presumably knows where the call originated, and can look at the = geographic location of the terminating switch (not the LRN, but the actual = switch which "owns" the LRN) and charge accordingly. The most current NANP regulatory guidelines with respect to the Order to Re= form InterCarrier Compensation Rates still includes access charges even aft= er there is bill-and-keep (on balance of traffic?). Pierce -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill Sent: January 04, 2016 10:26 AM To: Gorman, Pierce A [CTO] ; 'McGarry, Tom' ; modern@ietf.org Subject: Re: [Modern] Problem statement draft problems Please see embedded comment below. Best, Richard > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, > Pierce A [CTO] > Sent: Monday, January 4, 2016 17:21 > To: McGarry, Tom; modern@ietf.org > Subject: Re: [Modern] Problem statement draft problems > > Thanks Tom. Inline. > > I also have more edits but didn't want to send them out until I've > completed the review (this week?). > > Best regards, > > > Pierce Gorman > Office: 913-439-4368 > pierce.gorman@sprint.com > > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, > Tom > Sent: January 04, 2016 9:16 AM > To: modern@ietf.org > Subject: Re: [Modern] Problem statement draft problems > > Pierce, thanks for reviewing the document and the feedback. See my > comments in line below. > > On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" > > wrote: > > >Steve, > > SNIP > >With respect to geographic number assignment, the rejoinder, "But the > >overwhelming success of mobile telephones has increasing eroded the > >connection between numbers and regions" has problems at least in the > >context of the North American numbering plan. > > Tom: You're over thinking this. Mobile has always eroded the > connection between numbers and regions - that's what it does. This is > pointing out that it is now a dominant portion of the market. > > PG-> I think you're underthinking this. :-) The majority of phone > PG-> calls are "local" and charged accordingly per regulatory > PG-> requirements. This isn't changing. Introduction of fixed number portability in Switzerland resulted in the end= of geographical charging. Indeed, how can you charge by geography if the = caller cannot know in what geography the called number is? SNIP _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jan 4 09:03:18 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 15D791A8ABB for ; Mon, 4 Jan 2016 09:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoauvAJkR4Ye for ; Mon, 4 Jan 2016 09:03:15 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1571A8AA1 for ; Mon, 4 Jan 2016 09:03:14 -0800 (PST) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u04H3Ba1020414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 4 Jan 2016 18:03:11 +0100 Received: from RHillNew (adsl-178-38-58-89.adslplus.ch [178.38.58.89]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u04H3Ard030777; Mon, 4 Jan 2016 18:03:11 +0100 From: "Richard Hill" To: "'Gorman, Pierce A [CTO]'" , "'McGarry, Tom'" , References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <014501d1470c$99da5f60$cd8f1e20$@ch> <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> In-Reply-To: <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> Date: Mon, 4 Jan 2016 18:03:12 +0100 Message-ID: <01c201d14711$cc18f9a0$644aece0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4AAAVroEAAAKDPgAAErpfA= Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 17:03:17 -0000 I think that the Swiss solution is a bit more complex that what you outline below, but yes, of course the network does know where the call originated and terminated. The description of Swiss number portability is at (but only in French, German, and Italian): http://www.bakom.admin.ch/themen/telekom/00479/00625/index.html?lang=en Best, Richard > -----Original Message----- > From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com] > Sent: Monday, January 4, 2016 17:36 > To: Richard Hill; 'McGarry, Tom'; modern@ietf.org > Subject: RE: [Modern] Problem statement draft problems > > Good to know. Thank you. > > Just because the users don't know where a call originated and > terminated doesn't mean the network does not or cannot know. I'll > speculate that the Swiss portability uses a similar mechanism as used > in North America and the ported number is associated with a "Local > Routing Number" which indexes back to a central office switch with a > specific geographic location. The originating CSP presumably knows > where the call originated, and can look at the geographic location of > the terminating switch (not the LRN, but the actual switch which "owns" > the LRN) and charge accordingly. > > The most current NANP regulatory guidelines with respect to the Order > to Reform InterCarrier Compensation Rates still includes access charges > even after there is bill-and-keep (on balance of traffic?). > > Pierce > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill > Sent: January 04, 2016 10:26 AM > To: Gorman, Pierce A [CTO] ; 'McGarry, Tom' > ; modern@ietf.org > Subject: Re: [Modern] Problem statement draft problems > > Please see embedded comment below. > > Best, > Richard > > > -----Original Message----- > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, > > Pierce A [CTO] > > Sent: Monday, January 4, 2016 17:21 > > To: McGarry, Tom; modern@ietf.org > > Subject: Re: [Modern] Problem statement draft problems > > > > Thanks Tom. Inline. > > > > I also have more edits but didn't want to send them out until I've > > completed the review (this week?). > > > > Best regards, > > > > > > Pierce Gorman > > Office: 913-439-4368 > > pierce.gorman@sprint.com > > > > > > > > -----Original Message----- > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, > > Tom > > Sent: January 04, 2016 9:16 AM > > To: modern@ietf.org > > Subject: Re: [Modern] Problem statement draft problems > > > > Pierce, thanks for reviewing the document and the feedback. See my > > comments in line below. > > > > On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" > > > > wrote: > > > > >Steve, > > > > > SNIP > > > >With respect to geographic number assignment, the rejoinder, "But > the > > >overwhelming success of mobile telephones has increasing eroded the > > >connection between numbers and regions" has problems at least in the > > >context of the North American numbering plan. > > > > Tom: You're over thinking this. Mobile has always eroded the > > connection between numbers and regions - that's what it does. This > is > > pointing out that it is now a dominant portion of the market. > > > > PG-> I think you're underthinking this. :-) The majority of phone > > PG-> calls are "local" and charged accordingly per regulatory > > PG-> requirements. This isn't changing. > > Introduction of fixed number portability in Switzerland resulted in the > end of geographical charging. Indeed, how can you charge by geography > if the caller cannot know in what geography the called number is? > > SNIP > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > > ________________________________ > Learn more on how to switch to Sprint and save 50% on most Verizon, > AT&T or T-Mobile rates. See sprint.com/50off > for details. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete > all copies of the message. From nobody Mon Jan 4 12:07:26 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 3A2BC1A9129 for ; Mon, 4 Jan 2016 12:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc3Xs2sk_LiM for ; Mon, 4 Jan 2016 12:07:22 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id B9AFE1A910A for ; Mon, 4 Jan 2016 12:07:22 -0800 (PST) Received: (qmail 20878 invoked by uid 0); 4 Jan 2016 20:07:21 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 4 Jan 2016 20:07:21 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 22nA1s0081MNPNq012nDZf; Mon, 04 Jan 2016 19:47:19 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=7aQ_Q-yQQ-AA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=IaB7d55Bh-88lZv9USMA:9 a=llaQk4CTKHn0gWW1:21 a=HYGkNEBGMxl_-Tre:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=KBt8h9Nju2wyC5f+n61h/QjuOT9dPCVNKS5egmGtmPY=; b=e51oEB8IEjeNo7bk5tks/4o8wSoQ/54ZC0JRao41NfKIUyj6aNXFSN0QKpHLt7+elFpCVQKFgSlJWEx5mmIrgqMPkjAzLUiFOjavtpbxqGywdhIm1eAKOMl/CnZ5Nq/M; Received: from [100.36.35.60] (port=53637 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aGB60-0000AC-Dj; Mon, 04 Jan 2016 12:47:12 -0700 User-Agent: Microsoft-MacOutlook/0.0.0.151217 Date: Mon, 04 Jan 2016 14:47:05 -0500 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Richard Hill , "'McGarry, Tom'" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Problem statement draft problems References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <014501d1470c$99da5f60$cd8f1e20$@ch> <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> In-Reply-To: <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 20:07:25 -0000 On 1/4/16, 11:35 AM, "Modern on behalf of Gorman, Pierce A [CTO]" wrote: >Good to know. Thank you. > >Just because the users don't know where a call originated and terminated doesn't mean the network does not or cannot know. I'll speculate that the Swiss portability uses a similar mechanism as used in North America and the ported number is associated with a "Local Routing Number" which indexes back to a central office switch with a specific geographic location. The originating CSP presumably knows where the call originated, and can look at the geographic location of the terminating switch (not the LRN, but the actual switch which "owns" the LRN) and charge accordingly. > >The most current NANP regulatory guidelines with respect to the Order to Reform InterCarrier Compensation Rates still includes access charges even after there is bill-and-keep (on balance of traffic?). Its a function of terminating call access rates. Those have gone to .0005 or something like before it goes to zero. The issue is on origination access charges. The theory in the R&O was the rural carriers were not going to be able to modify their business models fast enough to accommodate both so on origination the regime is still in place for now. It too will go away especially if there is a move to National Geographic NP in the US which would essentially force the issue once and for all. That BTW was the principal topic of discussion at our last NANC meeting at the FCC. IMHO its coming. > >Pierce > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill >Sent: January 04, 2016 10:26 AM >To: Gorman, Pierce A [CTO] ; 'McGarry, Tom' ; modern@ietf.org >Subject: Re: [Modern] Problem statement draft problems > >Please see embedded comment below. > >Best, >Richard > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, >> Pierce A [CTO] >> Sent: Monday, January 4, 2016 17:21 >> To: McGarry, Tom; modern@ietf.org >> Subject: Re: [Modern] Problem statement draft problems >> >> Thanks Tom. Inline. >> >> I also have more edits but didn't want to send them out until I've >> completed the review (this week?). >> >> Best regards, >> >> >> Pierce Gorman >> Office: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, >> Tom >> Sent: January 04, 2016 9:16 AM >> To: modern@ietf.org >> Subject: Re: [Modern] Problem statement draft problems >> >> Pierce, thanks for reviewing the document and the feedback. See my >> comments in line below. >> >> On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" >> >> wrote: >> >> >Steve, >> > > >SNIP > >> >With respect to geographic number assignment, the rejoinder, "But the >> >overwhelming success of mobile telephones has increasing eroded the >> >connection between numbers and regions" has problems at least in the >> >context of the North American numbering plan. >> >> Tom: You're over thinking this. Mobile has always eroded the >> connection between numbers and regions - that's what it does. This is >> pointing out that it is now a dominant portion of the market. >> >> PG-> I think you're underthinking this. :-) The majority of phone >> PG-> calls are "local" and charged accordingly per regulatory >> PG-> requirements. This isn't changing. > >Introduction of fixed number portability in Switzerland resulted in the end of geographical charging. Indeed, how can you charge by geography if the caller cannot know in what geography the called number is? > >SNIP > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ >Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Mon Jan 4 12:13:08 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 0F7A31A9139 for ; Mon, 4 Jan 2016 12:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qOdSTSCyjQl for ; Mon, 4 Jan 2016 12:13:06 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04FD1A912F for ; Mon, 4 Jan 2016 12:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=50tBxF8QQUM6kd1Cal9erFRHsuK/BiMxT0faa/P2QV0=; b=BNE61pGuvGMVoleQHg13e4EtS7o4LIXHnBMgg5OpihsDbNFsjGA7wTJNQ+9mvEc/U5chQdxbOBfWdgPY+C6AtKH65Ftm/oPh6LJa0FGQQcWrA0mASrUF4eGxBf4hZgeeTpzazDD23JfhWexKJtvZM5UxU+04niIp4wHzHScIrNU=; Received: from 24-35-237-78.fidnet.com ([24.35.237.78]:60959 helo=[192.168.100.153]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aGBV1-0003md-F9 for modern@ietf.org; Mon, 04 Jan 2016 12:13:05 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_869FC45E-D91B-4F01-8927-313343DA3904"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> Date: Mon, 4 Jan 2016 14:13:02 -0600 Message-Id: <48D3ACF0-B3A8-45F8-A9EF-E104D7C94F3A@standardstrack.com> References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <014501d1470c$99da5f60$cd8f1e20$@ch> <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> To: "modern@ietf.org" X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 20:13:07 -0000 --Apple-Mail=_869FC45E-D91B-4F01-8927-313343DA3904 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Given the population of Switzerland is half a million fewer people than = the population of New York City, the Swiss experience might be = informative for Tom=E2=80=99s sister, who moved around in Manhattan, but = may not be informative for a larger country such as Germany, France, the = UK, Russia, or the U.S. > On Jan 4, 2016, at 10:35 AM, Gorman, Pierce A [CTO] = wrote: >=20 > Just because the users don't know where a call originated and = terminated doesn't mean the network does not or cannot know. I'll = speculate that the Swiss portability uses a similar mechanism as used in = North America and the ported number is associated with a "Local Routing = Number" which indexes back to a central office switch with a specific = geographic location. The originating CSP presumably knows where the = call originated, and can look at the geographic location of the = terminating switch (not the LRN, but the actual switch which "owns" the = LRN) and charge accordingly. >=20 > The most current NANP regulatory guidelines with respect to the Order = to Reform InterCarrier Compensation Rates still includes access charges = even after there is bill-and-keep (on balance of traffic?). > On Jan 4, 2016, at 9:16 AM, McGarry, Tom = wrote: >=20 > Tom: A few years ago my sister moved from E. 62nd St to E. 85th St in = NYC. > Her service provider would not let her keep her number. You and I = know > that is because she moved from one CO serving area to another and the > company didn't want to go through the process of porting her number > between their switches. While I would think this is not common, it's = not > rare either. Service providers build rules into their systems and > processes that account for things like rate centers, wire center > boundaries, LATAs, consumer addresses, etc. that seem logical to them, = but > may not to a consumer. >=20 --Apple-Mail=_869FC45E-D91B-4F01-8927-313343DA3904 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWitJOAAoJEORoZaSQsc1INxkQAIKsVui/4YqdJ+br7bhJu33Z Vj/hBucZyhfKtVrR6q+ogex/ptH42rs01Dw9P/sYWEmmOD45WC8WRRDmVYU6dFeG BEHtUUBbG+olydSGiIbeWeIH3EPFnysi9yZDGXUX9dVnKIbxfebH2nPdUqKJsQay JUnthbcefySnQRUjOT0M8OckmiT8oAH8OFB/s5pBlqFh4yKWnqMuoS/4k17qdYNt cjLnkkEKWfj1fXW5mqq12jIhMrtXE1Y2Fouow3QgvFQY3roy8wflxMB3pcOp/kig ZHeRucKjAlfN19mDe+Yll8VcEzd6R+yHMzvAoKwhq8EZyeh92xR72yKRvmoBspsR lZaREF/rrtRsHf6reSazEi/irol9BQpfihe4SEnQNaV7bopz9SZnHq9HOdyQ9P4z zqMb3Sesf8LLjSSh535ue4t+Tq/GiCNsbdBvVhbaSNrlkVp+spXz6f/bY9pkxc2X q6ksqBGpMjs2Ubt9WThaK/UkhY2JJD9+XgiF8/Gnaif0mgpI4v4ktgl2+Kpc0eh6 ZhOkfIQ6DR8V8N7+roG4bCgkUNXZT3l3egKFeGdVnkHeWexRE5o6ZdIvP0+hFy5T CGUNPCLtVpWPUWPc5nidpmfzq3AcSLcapHzVd7qfmJk/ui3YBW/a+LnOD/q1MsHk C5D6JM0ePd9nAmKcrYeH =3HXj -----END PGP SIGNATURE----- --Apple-Mail=_869FC45E-D91B-4F01-8927-313343DA3904-- From nobody Mon Jan 4 13:09:42 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 620261ABC75 for ; Mon, 4 Jan 2016 13:09:40 -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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byGAkUsSQRWR for ; Mon, 4 Jan 2016 13:09:37 -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 445221ABC74 for ; Mon, 4 Jan 2016 13:09:37 -0800 (PST) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u04L9OQh031983; Mon, 4 Jan 2016 16:09:28 -0500 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 206a7n31bn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 04 Jan 2016 16:09:28 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 4 Jan 2016 16:09:27 -0500 From: "McGarry, Tom" To: "Gorman, Pierce A [CTO]" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4AAC1jVAA== Date: Mon, 4 Jan 2016 21:09:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-04_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601040349 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:09:40 -0000 Thanks Pierce and Richard, please see comments in line below. On 1/4/16 11:21 AM, "Gorman, Pierce A [CTO]" wrote: >Thanks Tom. Inline. > >I also have more edits but didn't want to send them out until I've >completed the review (this week?). > >Best regards, > > >Pierce Gorman >Office: 913-439-4368 >pierce.gorman@sprint.com > > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom >Sent: January 04, 2016 9:16 AM >To: modern@ietf.org >Subject: Re: [Modern] Problem statement draft problems > >Pierce, thanks for reviewing the document and the feedback. See my >comments in line below. > >On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" >wrote: > >>Steve, >> >>In section 1 I would strike the sentence, " Telephone numbering, >>however, has long been transitioning away from a provider-centric model >>towards a user-centric model." I think the statement is arguable and >>isn't needed. > >Tom: OK. >> >>The statement, " TN administration processes rooted in PSTN technology >>and policies dictate that this be an exception process fraught with >>problems and delays" may stand on it's own for someone familiar with >>the technology, policies, problems, and delays, but I think that is >>probably a small minority. >> >>Can you elaborate? If not, I suggest removing this statement as well. > >Tom: How about following that sentence with: >"Processes were built to associate a specific TN to a specific service >provider and never change it. With number portability the industry had >to build new infrastructure, new administration functions and processes >to change the association of the TN from one service provider to another." > >PG-> I'm OK with it. > >> >>Also, I would suggest that users already have full control of their TN. >>Certainly nobody will take it from them (although the area code portion >>of telephone numbers using the NANP dial plan can and does >>occassionally change). And the porting process is solely driven by the >>users. >>(Although it might be worth pointing out porting in order to improve >>inbound call routing to IMS-based numbers has been a consideration for >>some North American carriers deploying VoLTE.) >> >>The statement, " Ideally the user would have full control of their TN >>and would drive the porting process on their own rather than rely on >>complex and time consuming back office processes among multiple service >>providers" needs work. What is the definition of "full control" and >>what makes full control "ideal"? > >Tom: A few years ago my sister moved from E. 62nd St to E. 85th St in NYC. > Her service provider would not let her keep her number. You and I know >that is because she moved from one CO serving area to another and the >company didn't want to go through the process of porting her number >between their switches. While I would think this is not common, it's not >rare either. Service providers build rules into their systems and >processes that account for things like rate centers, wire center >boundaries, LATAs, consumer addresses, etc. that seem logical to them, >but may not to a consumer. I do think it would be beneficial for >consumers to have the opportunity for more control over their numbers. >As we move to IP, the timing is right to look at improving this. > >PG-> My understanding is rate centers and LATA boundaries were defined >by attorneys as part of Judge Green's "Modified Final Judgement" in the >United States vs. AT&T antitrust case of 1982. It's unfortunate that it >impacted your sister (and others), and I agree that Non-Geographic >Portability (NGP) should (eventually) address the issue. I disagree that >the move to VoIP has very much to do with NGP. I think you need to prove >that a new MODERN system of numbering would eliminate time from the back >office processes required by CSPs, or drop the point. > >PG-> I think you still need to define full control better. The example >you provided will be a benefit of NGP, not MODERN (unless MODERN were an >unavoidable prerequisite or undeniable benefit which I don't think anyone >will argue). Tom: The use cases propose that the consumer receives a credential that proves they have been allocated the TN. The example given is for number portability. They present the credential to the new service provider and the service provider uses this proof to port the number w/o a back and forth with the old service provider. They activate service for the customer and in essence send a "loss notification" to the old service provider. I could ultimately see this credential being used for other purposes such as associating a TN with a new app. Would "more" control work better for you? > >> >>How about, "Some members of the MODERN working group think users ought >>to be able to use an Internet-available database to directly make >>changes to the services associated with and the provisioning of their >>telephone number without assistance from service providera."? > >Tom: I believe this is better handled in the use cases, where this >example is covered. >> >>As mentioned before, claiming that the back office process among >>multiple service providers is complex does not imply harm or even a >>problem to be fixed. Telephony is complex, but it is also very useful >>so the fact that it is complex doesn't mean that it is bad, harmful, or >>a problem to be addressed. >> >>I recommend striking the phrase, "rather than rely on complex and time >>consuming back office processes among multiple service providers". >> >>Part of the problem here is you cannot really assert a priori that a >>MODERN system will be less time consuming or even less complex. The >>fact that the user will necessarily require assistance from one or more >>service providers in completing the provisioning of their service (in >>the case of mobile telephony at least) makes this a certainty. In >>fact, it would be easy to argue that MODERN will be more complex. >> >>I'm also confused by the reference to back office processes as though >>they are inherently harmful. Other terms for the same activity are >>Operational Support Systems (OSS) and Business Support Systems (BSS). >>These terms don't have a negative or positive connotation though, so >>perhaps they also don't belong in a problem statement? >> >>With respect to geographic number assignment, the rejoinder, "But the >>overwhelming success of mobile telephones has increasing eroded the >>connection between numbers and regions" has problems at least in the >>context of the North American numbering plan. > >Tom: You're over thinking this. Mobile has always eroded the connection >between numbers and regions - that's what it does. This is pointing out >that it is now a dominant portion of the market. > >PG-> I think you're underthinking this. :-) The majority of phone >calls are "local" and charged accordingly per regulatory requirements. >This isn't changing. Also, mobile carriers cannot page an entire network >for every call termination attempt so localizing the call termination >processing is important. A benefit of NGP will be optimized call >termination localization (at the cost of additional porting information >management). i.e., call processing can be optimized by porting numbers >which spend a high percentage of time hosted from a "visited" platform >(within a CSP's network). Mobile call processing necessarily resides in >a platform with a geographic location and regional responsibility. >Numbering and geography for mobile call processing continue to have an >important relationship that needs to be recognized, not dismissed. i.e., >to optimize call routing and number management, new number assignments >should still be done with a sensitivity to geography. And when numbers >are released back to the CSP, new assignments with a number should be >within the context of the region from which the number was originally >assigned. This isn't a policy suggestion, it's a network design and >operation optimization. Geography matters. So this discussion seems to be about the changing the word "erode" to "obfuscate". By erode I was suggesting that there was less and less connection between the geography associated with the phone number and the geography of the consumer (where they are). Can you explain what you are trying to communicate by using the word "obfuscate"?=20 > >> >>I think what you mean is that after a mobile telephone number is >>assigned (likely for the majority of a user's life once non-geographic >>portability is supported), a fair quantity of users (but far less than >>even 50%?) will move outside of the geography of the original >>assignment rendering the geographic information associated with that >>mobile number anachronistic and inaccurate. I would agree with this, >>and I would agree it causes problems for service providers. I wouldn't >>necessarily agree it's a problem a new MODERN system could help with. >> >>What is lost in this view is that there is an underlying routing number >>which still retains a very certain geographic component. Even if we >>eliminated routing numbers and their reference to the LERG (again North >>America-centric view), there are very real operational reasons for >>wanting to recognize geography when "homing" the terminating service >>processing (at least). >> >>One of the problems with Internet telephony is the lack of recognition >>for geography both in telephone call routing and in number assignment. >>Understanding geography and it's interaction with call processing and >>numbering is going to be one of the key challenges for MODERN. I don't >>mean this as a reason not to work on MODERN. I mean it as helpful hint. >>There is a real cost both to service providers and users for >>unoptimized call routing and media transport. >> >>I recommend changing the statement to, " But the overwhelming success >>of mobile telephones has increasing obfuscated the connection between >>numbers and regions". >> >>This way you point out that there is and should be an intentional >>relationship between mobile telephone numbering and operations at >>least, but that portability and Internet-telephony present special >>signaling and media path optimization problems. >> >>The issue will be for MODERN WG how to develop a new system of >>telephone number databasing that doesn't just recognize those problems, >>but somehow helps with them beyond what is available with conventional >>mechanisms. >> >>That's more than enough for this session. I'll try to pick up tomorrow. >> >>Regards, >> >>Pierce >> >> >>________________________________ >>Learn more on how to switch to Sprint and save 50% on most Verizon, >>AT&T or T-Mobile rates. See >>sprint.com/50off>rin >>t.com_50off&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcL= extZ >>1oo >>Ncfp01IYIaVqsORjI&m=3DCbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=3D4e2= Gd >>aZQ gxzYOrBnyWBi4uVzX8ABHMm4DZyRE0TMgCE&e=3D > for details. >> >>________________________________ >> >>This e-mail may contain Sprint proprietary information intended for the >>sole use of the recipient(s). Any use by others is prohibited. If you >>are not the intended recipient, please contact the sender and delete >>all copies of the message. >> >>_______________________________________________ >>Modern mailing list >>Modern@ietf.org >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >>an_ >>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee= IDcL >>ext >>Z1ooNcfp01IYIaVqsORjI&m=3DCbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s= =3D9 >>7kr pL5WZ4HCVAJuQEFeidiyONXQzq6MgU_YyxDjq1Y&e=3D > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3Dsgz7ixbLC0QKplG2qlyreASixYtoRiCSnpEzKKPlpt0&s=3D= LgXU >YaelEAQGsIst1HeErsD9lEyaytfi-fSS-Mpb4f0&e=3D > >________________________________ >Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T >or T-Mobile rates. See >sprint.com/50offt.com_50off&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcLe= xtZ1oo >Ncfp01IYIaVqsORjI&m=3Dsgz7ixbLC0QKplG2qlyreASixYtoRiCSnpEzKKPlpt0&s=3DTZG_= jHsj >47Qat6lA8kdJjHdz2sp9bCcWZ9Q7RVmA4Ec&e=3D > for details. > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. From nobody Mon Jan 4 13:38:09 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 412A01AC3C4 for ; Mon, 4 Jan 2016 13:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8UO_QEAIZm8i for ; Mon, 4 Jan 2016 13:38:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BE31AC3C2 for ; Mon, 4 Jan 2016 13:38:03 -0800 (PST) Received: from BY2FFO11FD023.protection.gbl (10.1.14.33) by BY2FFO11HUB020.protection.gbl (10.1.14.140) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 4 Jan 2016 21:37:41 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) 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.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 4 Jan 2016 21:37:40 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u04J8SK2044213; Mon, 4 Jan 2016 15:37:40 -0600 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm2.corp.sprint.com with ESMTP id 206d76823s-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2016 15:37:40 -0600 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 4 Jan 2016 16:37:38 -0500 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; Mon, 4 Jan 2016 15:37:38 -0600 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Richard Hill , "'McGarry, Tom'" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4AAAVroEAAAKDPgABOItYAACQa0AA== Date: Mon, 4 Jan 2016 21:37:37 +0000 Message-ID: <9c7c0a78e6c64f5f986c38252bef0f15@PLSWE13M08.ad.sprint.com> References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <014501d1470c$99da5f60$cd8f1e20$@ch> <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD023; 1:wqGzENT0Ze/wLf180COssZy82X7g0nIiDSU8qDKMEyZCaXUOw5xW6SYiDq9JneUCXoLC+IYzowSuekEvSJgc1kXYI7ncqlDFffHtWh85oB4sHawOpRTZfMy1hAp1kF0zQ3PuNeJEO3qQfn6rf2CAz32sGwdkETOfSvyF6kKfnlvMd/fR4ezsbP1cPKBHRuwoHa3qmBUy/aWEdX7xr5Xf5UW3PCoIXf2/Zn8L+6DXWPUkqbfKsgrx0XR9602qJ0RLmf4lK1pwX2anVyFNBN+DaF9ocybzRZuzidvzioZ7S0pXt//SCtRLWL9/mdFg3Vb2O05nhWFAHwl5W4PExFp+wwURBdDQ5uTY/iBacwzN0VMajHXDKkOA1z+GEd8XvuXF X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(52604005)(479174004)(199003)(189002)(377454003)(24454002)(13464003)(87936001)(5001960100002)(189998001)(24736003)(76176999)(97736004)(107886002)(50986999)(81156007)(15395725005)(50466002)(2950100001)(5001770100001)(2900100001)(33646002)(15975445007)(92566002)(19580395003)(5250100002)(19580405001)(86362001)(47776003)(23676002)(2501003)(1220700001)(5003600100002)(93886004)(102836003)(3846002)(586003)(1096002)(5008740100001)(6116002)(54356999)(6806005)(106466001)(108616004)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB020; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB020; 2:ZqRvhTGJ0cGtXFeov4R3NCoLNGV/8GRHX56TjYPGqumOxvlr9jjpJv6W9rCnjEx59xS5fN4tI3oJMHrjr9qDGFO990qmlQqE+gkKKTkLW2skDUKfaSafTmqgMOEepawiwOaHSplIxOpWL8JPFy17NA==; 3:Yw8iJ1d+yc9WAtn0mpr41J1wV9pITnt36yXXp8kMq0Vad4G759Qs4fYzEemSmUOZJorsSRkcM2ZvznLunioh9a5Vrp5WdCPNPUG6Orsyid2s25es2JobpcdtRvTth5ixCnccw7WbvLfKEM03bJ07TdE85cw4T249Tn3rb0sfyDCleeq6q7zoBrSQjESIDm+Uk3EPvTGybo6PTRpO95xcADKfIi0G65+WETORTXN5p38ehvzeHcDaZ0GdzrGnuIVKh6hR8fA9M0x3BbWv69Br4w==; 25:3seYB8oIKFeiwKzgyVxfp+UOwX4nGVfa57bHvxh9bIUk4QoWdYKYkZmzaQVF2nUKu+xJ+ZfztigAd0lKPMbpTANkOENXJw0n3hSHT+Y8nHRLujyBhjuBfkr2XxZHEBWVnc5EIRDP5fEr2yyBMCcWpFl4Vw/DOcK49lOlcY5Y1p+7gm4S3dnLeavtbprmvcITDlBAJqCDYKzg0fugfjM8ISoqm5vEA8cOywWJR/1ItU081MsBLEGPcLPvqe9hRZl9uSlC5KF6ysa8WA3/cuiQNQ== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB020; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB020; 20:kBTI66yw4LEvm8iuhtrTU0uYYmPkHLlOL+lx1Wz4loi4hvK+zjZ4RbaPDeDm/0hKrhFhwa9cFRf2mLZakCwHuFfyvFFvZ8rHkaTafy6FTqbsO1U0TDMZN/04nG4283V8McAYUIky9R/+UOsrC7tUNfP8WIAW19L1IQAEOV4ZogKMOaj78hCY9XF0pWmPFZlAmLhcS/yCVvmdUE5dzcQ34fHbwXmr+B055k88xulAubNdZljtWz+yU6rrOCLwq3Js; 4:fC5aZCDUsF6SZhhWxCMQRNp84JEoQ/5K/VQmk1TwIqn61AMnMrerHvjjjT3s3smSxjhTkBnFW9TqLWf+nsOQQ51G5A7THWy3BcKnhj37gMzRkBY78XTedOqF7m2Bqevw34YIlMCiHy0vvR6AXjwCZKwIzrmc3OFUtEwBGqdMLC5mv8rYuinlZInWljB/2MiX9iMzZbjYWiIwbun2CSHDEaWbK6MDJdFAx7/AwJ30j6Lt1HU0D67r1RhPn1qqo1FGb3CFLnH6H8/EgYULj374hrHh5SAgrfAmEGfXjNahsiIoSECUpWmyY1ZTNXY2oaJY1ArPHet5yqJ05DyQEDdUr2qddSL9bJ1uPYHreNmXRyEJy2cyu/hDYL/yfLI/IpVwpi1JCoWZvhaiax1v3WKUhEmkLwQxpHy+98QNqaKXbRrap129CdzF2XBBl9VHDBXi X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BY2FFO11HUB020; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB020; X-Forefront-PRVS: 08118EFC2B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJGRk8xMUhVQjAyMDsyMzpDSElkakNOVVBCRnp1SWhsdFRhSzVzMFlj?= =?utf-8?B?WW9uTEUwVldaMlBhekRIOFZWbDh4aHgzRytWZDFoMGU1NU5MblhxcmdvVGFu?= =?utf-8?B?SVM3SjFRZlFXQ09GQ0RIa3lqWDJpWStZQ2prNVZlcFFWUm11em9CMGVkbi9x?= =?utf-8?B?QVlSQUFFWHZHcWg2TU5KTXBIMDNKa1QyRWxzMWFJZ2hXRXVHM2d0K1VkNUFH?= =?utf-8?B?SjREcC9BTFNkN1pORzZET2tqaHdPSmxMcWpWUm83TlhFOVBXamZEMUsxTWNX?= =?utf-8?B?UjZ2WndiUDVIUHAwWFhhZDQ5N0wrNm5NK050clJ4MHBLLzEvNnUyd1NVei91?= =?utf-8?B?RTB1UVFvWCtXNXF0N3daUmk3S0ZTQ3dDMnJvaXlNN2ZFRndUWU5XV3JUQzFZ?= =?utf-8?B?a1hhOEFHQ0o0eXVETFJvd2hybWtiTnZQcGwwaDE4a05FcktFMlhEa29PYzFO?= =?utf-8?B?Z05ZL2JJYmFJNnFFLzJlRlUrNXlha3hzbDUzSlZ3UUEzbE5sNzBVUUJTdXg0?= =?utf-8?B?R2hHKy9TQm9FcUdkMVlubFdQYllhS1lzVGx2cGtUdGNmQVA0Zi9uS3BicUZH?= =?utf-8?B?UVpsSzRwNERKRys2ZUdjc3J3TzJvNXc2T0c0cjVWMlJZQklsSFkvMENZYlQ3?= =?utf-8?B?TmNnUmp0Nk9PTWYvN3hmdUwycjdhMnNUSFZXRi85VUU2VDl2SFdORHUvTmJC?= =?utf-8?B?UkM5Q3VRM1AyS3NHZ1JkWjNYWStZVys3U1FPRTFIeFB4NTJrbG5xTEx2UHYx?= =?utf-8?B?L2M5UllFZ0dZK1FPNHB4Ym1ZenhaRlNTNzUzTklvcHZXQyttZU55T2p3a0pD?= =?utf-8?B?V3hzSWZjOXh0b1lWcnNJUDQzTjdzRk1zQXhBUXU0eWZDcnl6ajlpSmliaUI3?= =?utf-8?B?Ti81b3ZXQzBwS1BnN1VBWVVqVVl4UGJDM3Y0eGZzNVBVYTJyeWwrVmppbVVp?= =?utf-8?B?MmcrenU2cy8yZVVKb09hMkQ2RklhUVZmTXpvcGo4amJwRGpSN240QitRZkpC?= =?utf-8?B?ZWRyVW0zaWZJU3NJNzdpaDZwMGdYcUNYOTZYKzdkY2tEQm11dDJZbzdVYnBB?= =?utf-8?B?S0U4NFp4MUljT01PVWZVeDc1ZGVyT1M4RmJ4VjVNWDBIUUtnazMyaGRIQ3pC?= =?utf-8?B?QU9PSDZmRHhoamRTM3JsRmtYWkF3d2Vtbys4ZVprWm4vTERXdU9zQ0tiUCto?= =?utf-8?B?Ylpmai8zUkd6dGhNRHgrdVpiVkdvMEI4TEJUaXRRcEJUMnZYMjVmdFNXNlB2?= =?utf-8?B?UkhVaCs4MnFmZUhrTm5OS2pnc2ZoZUpOUUt4Zm01MHFKVmZVWlhZRGZKT1ZR?= =?utf-8?B?UnRVQ3NRd0prem1nSndwbmgrY0RSREd5cEhKK2x3dzA0RTBUbnc0WnZWZjhF?= =?utf-8?B?eml0U1ZNYTRqOVNXR2ZhbndMWXprbjN2VUtNaEZhT0pMU2NCQ2hJWlluQWR2?= =?utf-8?B?UUovS3hneWxPTlpScHZ3OVY1eEdQVzRNUGVNUXFLd1VPQjFYb2FiQmlnbTBZ?= =?utf-8?B?TVdoZzdBNXIvVVZ2cEpZQUI5blZKdjl2ZFVXV2NNRjZsWXU2aStRd1k2SjU4?= =?utf-8?B?TVRBQkpCQ281M0FhdWhhdEE3YXBBYW9jbVV0RmpTMzFxM205YTNDNGFXTGJv?= =?utf-8?B?Q0FGRzNqMDhJMXRaN0RJQ3NMT2lhVW1ReVh4bTJVYWtMZ09JL2llcDhuL29o?= =?utf-8?Q?ynYjUKjcqKxhTlunoBkNYSSVrmTdLgX3XYHCN2a7?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB020; 5:nIgY5vo74TcQcpqy+KricyoPwKizJPZU/RrCdVbCZYWDAlmNK8Y9zGoKsruD2s7Vk9yXML/4+FzEkVz3VeRleQ1f0Kj91OWa/7PZ8RbRa4FJasyObUtyKU/kk+8+noVpd6JF2xB+R5IAF6r6lBeTXA==; 24:1XNeuX1sBKrwknx8XdMMdD8HYxUpEHZ+Of6xmAGMCXl1ZpqYpEaKXAZf3+hWSds+l6Uw+rwj6U24JEg+x4uH34z4y6SUsKraAg4ViCsqTeg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2016 21:37:40.7849 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB020 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:38:08 -0000 UmljaGFyZCwNCg0KVGhpcyBtYXkgbm90IGJlIGNvbXBsZXRlbHkgYXBwcm9wcmlhdGUgdG8gdGhl IE1PREVSTiBXRyBkaXNjdXNzaW9uLCBidXQganVzdCBhIHF1aWNrIHBvaW50IG9mIGNsYXJpZmlj YXRpb24uDQoNCk15IG5vdGVzIG9uIHRoZSBPcmRlciB0byBSZWZvcm0gSUNDIFJhdGVzIHNob3cg dGhhdCB0aGUgInByaWNlIGNhcCIgTEVDcyAoYWthIFJCT0MncykgYW5kIHRoZSAicmF0ZSBvZiBy ZXR1cm4iIExFQ3MgKGFrYSBydXJhbCBMRUNzKSBib3RoIGdldCB0byAuMDAwNyAob24gZGlmZmVy ZW50IHNjaGVkdWxlcyBhcyB5b3UgbWVudGlvbmVkKSwgYnV0IG15IHdvcmtpbmcgYXNzdW1wdGlv biBoYXMgYmVlbiBpdCBuZXZlciBnb2VzIHRvICJ6ZXJvIiBhcyB5b3Ugd3JvdGUgYmVsb3cuDQoN ClRoZXJlIGlzIGEgYmlsbC1hbmQta2VlcCBjb21wb25lbnQuICBJJ3ZlIGFzc3VtZWQgdGhhdCBi aWxsLWFuZC1rZWVwIGlzIGJhbGFuY2Ugb2YgdHJhZmZpYyBvbmx5IGFuZCB0aGF0IGJhbGFuY2Ug b2YgdHJhZmZpYyBvdmVyYWdlcyB3b3VsZCBiZSBwYWlkIHRvIHRoZSB0ZXJtaW5hdGluZyBMRUMu ICBpLmUuLCB0aGVyZSB3aWxsIHN0aWxsIGJlIHRyYW5zcG9ydCBhY2Nlc3MgY2hhcmdlcyAoYWxi ZWl0IGF0IC4wMDA3IHBlciBtaW51dGUpLg0KDQpUaGlzIGV4YWN0IHVuZGVyc3RhbmRpbmcgaGFz IGJlZW4gYSBiaXQgb2YgYSBwcm9ibGVtIGZvciBtZSB0byBuYWlsIGRvd24uICBFaXRoZXIgSSBh c2sgdGhlIHF1ZXN0aW9uIHdyb25nLCBvciBhc2sgdGhlIHdyb25nIHBlb3BsZSwgYnV0IEknbSBu b3QgY29tZm9ydGFibGUgSSBrbm93IHRoZSBjb21wbGV0ZSBzdG9yeS4gIEl0IGNvdWxkIGJlIEkn bSB3cm9uZywgYW5kIHRoZSBvbmx5IGFjY2VzcyB3aWxsIGJlIGZhY2lsaXRpZXMgY2hhcmdlcyBh bmQgdHJhbnNwb3J0IGNvc3RzIG9mIC4wMDA3ICh0YXJpZmZzIHRvIGJlIGZpbGVkIHRoaXMgeWVh cikgZG8gaW5kZWVkIGZhbGwgdG8gemVybyAoaW4gMjAxOCBmb3IgcHJpY2UgY2FwIExFQ3MpLiAg Q2FuIHlvdSBjb25maXJtPw0KDQpQaWVyY2UNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogUmljaGFyZCBTaG9ja2V5IFttYWlsdG86cmljaGFyZEBzaG9ja2V5LnVzXQ0KU2Vu dDogSmFudWFyeSAwNCwgMjAxNiAxOjQ3IFBNDQpUbzogR29ybWFuLCBQaWVyY2UgQSBbQ1RPXSA8 UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPjsgUmljaGFyZCBIaWxsIDxyaGlsbEBoaWxsLWEuY2g+ OyAnTWNHYXJyeSwgVG9tJyA8VG9tLk1jR2FycnlAbmV1c3Rhci5iaXo+OyBtb2Rlcm5AaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbTW9kZXJuXSBQcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBwcm9ibGVt cw0KDQoNCg0KDQoNCg0KT24gMS80LzE2LCAxMTozNSBBTSwgIk1vZGVybiBvbiBiZWhhbGYgb2Yg R29ybWFuLCBQaWVyY2UgQSBbQ1RPXSIgPG1vZGVybi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBQaWVyY2UuR29ybWFuQHNwcmludC5jb20+IHdyb3RlOg0KDQo+R29vZCB0byBrbm93LiAg VGhhbmsgeW91Lg0KPg0KPkp1c3QgYmVjYXVzZSB0aGUgdXNlcnMgZG9uJ3Qga25vdyB3aGVyZSBh IGNhbGwgb3JpZ2luYXRlZCBhbmQgdGVybWluYXRlZCBkb2Vzbid0IG1lYW4gdGhlIG5ldHdvcmsg ZG9lcyBub3Qgb3IgY2Fubm90IGtub3cuICBJJ2xsIHNwZWN1bGF0ZSB0aGF0IHRoZSBTd2lzcyBw b3J0YWJpbGl0eSB1c2VzIGEgc2ltaWxhciBtZWNoYW5pc20gYXMgdXNlZCBpbiBOb3J0aCBBbWVy aWNhIGFuZCB0aGUgcG9ydGVkIG51bWJlciBpcyBhc3NvY2lhdGVkIHdpdGggYSAiTG9jYWwgUm91 dGluZyBOdW1iZXIiIHdoaWNoIGluZGV4ZXMgYmFjayB0byBhIGNlbnRyYWwgb2ZmaWNlIHN3aXRj aCB3aXRoIGEgc3BlY2lmaWMgZ2VvZ3JhcGhpYyBsb2NhdGlvbi4gIFRoZSBvcmlnaW5hdGluZyBD U1AgcHJlc3VtYWJseSBrbm93cyB3aGVyZSB0aGUgY2FsbCBvcmlnaW5hdGVkLCBhbmQgY2FuIGxv b2sgYXQgdGhlIGdlb2dyYXBoaWMgbG9jYXRpb24gb2YgdGhlIHRlcm1pbmF0aW5nIHN3aXRjaCAo bm90IHRoZSBMUk4sIGJ1dCB0aGUgYWN0dWFsIHN3aXRjaCB3aGljaCAib3ducyIgdGhlIExSTikg YW5kIGNoYXJnZSBhY2NvcmRpbmdseS4NCj4NCj5UaGUgbW9zdCBjdXJyZW50IE5BTlAgcmVndWxh dG9yeSBndWlkZWxpbmVzIHdpdGggcmVzcGVjdCB0byB0aGUgT3JkZXIgdG8gUmVmb3JtIEludGVy Q2FycmllciBDb21wZW5zYXRpb24gUmF0ZXMgc3RpbGwgaW5jbHVkZXMgYWNjZXNzIGNoYXJnZXMg ZXZlbiBhZnRlciB0aGVyZSBpcyBiaWxsLWFuZC1rZWVwIChvbiBiYWxhbmNlIG9mIHRyYWZmaWM/ KS4NCg0KDQpJdHMgYSBmdW5jdGlvbiBvZiB0ZXJtaW5hdGluZyBjYWxsIGFjY2VzcyByYXRlcy4g IFRob3NlIGhhdmUgZ29uZSB0byAuMDAwNSBvciBzb21ldGhpbmcgbGlrZSBiZWZvcmUgaXQgZ29l cyB0byB6ZXJvLiBUaGUgaXNzdWUgaXMgb24gb3JpZ2luYXRpb24gYWNjZXNzIGNoYXJnZXMuIFRo ZSB0aGVvcnkgaW4gdGhlIFImTyB3YXMgdGhlIHJ1cmFsIGNhcnJpZXJzIHdlcmUgbm90IGdvaW5n IHRvIGJlIGFibGUgdG8gbW9kaWZ5IHRoZWlyIGJ1c2luZXNzIG1vZGVscyBmYXN0IGVub3VnaCB0 byBhY2NvbW1vZGF0ZSBib3RoIHNvIG9uIG9yaWdpbmF0aW9uIHRoZSByZWdpbWUgaXMgc3RpbGwg aW4gcGxhY2UgZm9yIG5vdy4gIEl0IHRvbyB3aWxsIGdvIGF3YXkgZXNwZWNpYWxseSBpZiB0aGVy ZSBpcyBhIG1vdmUgdG8gTmF0aW9uYWwgR2VvZ3JhcGhpYyBOUCBpbiB0aGUgVVMgd2hpY2ggd291 bGQgZXNzZW50aWFsbHkgZm9yY2UgdGhlIGlzc3VlIG9uY2UgYW5kIGZvciBhbGwuICBUaGF0IEJU VyB3YXMgdGhlIHByaW5jaXBhbCB0b3BpYyBvZiBkaXNjdXNzaW9uIGF0IG91ciBsYXN0IE5BTkMg bWVldGluZyBhdCB0aGUgRkNDLiBJTUhPIGl0cyBjb21pbmcuDQoNCg0KDQoNCj4NCj5QaWVyY2UN Cj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IE1vZGVybiBbbWFpbHRvOm1v ZGVybi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBIaWxsDQo+U2VudDog SmFudWFyeSAwNCwgMjAxNiAxMDoyNiBBTQ0KPlRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIDxQ aWVyY2UuR29ybWFuQHNwcmludC5jb20+OyAnTWNHYXJyeSwgVG9tJw0KPjxUb20uTWNHYXJyeUBu ZXVzdGFyLmJpej47IG1vZGVybkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbTW9kZXJuXSBQcm9i bGVtIHN0YXRlbWVudCBkcmFmdCBwcm9ibGVtcw0KPg0KPlBsZWFzZSBzZWUgZW1iZWRkZWQgY29t bWVudCBiZWxvdy4NCj4NCj5CZXN0LA0KPlJpY2hhcmQNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEdvcm1hbiwNCj4+IFBpZXJjZSBBIFtDVE9dDQo+PiBTZW50OiBNb25k YXksIEphbnVhcnkgNCwgMjAxNiAxNzoyMQ0KPj4gVG86IE1jR2FycnksIFRvbTsgbW9kZXJuQGll dGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW01vZGVybl0gUHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQg cHJvYmxlbXMNCj4+DQo+PiBUaGFua3MgVG9tLiAgSW5saW5lLg0KPj4NCj4+IEkgYWxzbyBoYXZl IG1vcmUgZWRpdHMgYnV0IGRpZG4ndCB3YW50IHRvIHNlbmQgdGhlbSBvdXQgdW50aWwgSSd2ZQ0K Pj4gY29tcGxldGVkIHRoZSByZXZpZXcgKHRoaXMgd2Vlaz8pLg0KPj4NCj4+IEJlc3QgcmVnYXJk cywNCj4+DQo+Pg0KPj4gUGllcmNlIEdvcm1hbg0KPj4gT2ZmaWNlOiA5MTMtNDM5LTQzNjgNCj4+ IHBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbQ0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+IEZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVybi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTWNHYXJyeSwNCj4+IFRvbQ0KPj4gU2VudDogSmFudWFyeSAwNCwg MjAxNiA5OjE2IEFNDQo+PiBUbzogbW9kZXJuQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW01v ZGVybl0gUHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgcHJvYmxlbXMNCj4+DQo+PiBQaWVyY2UsIHRo YW5rcyBmb3IgcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBhbmQgdGhlIGZlZWRiYWNrLiAgU2VlIG15 DQo+PiBjb21tZW50cyBpbiBsaW5lIGJlbG93Lg0KPj4NCj4+IE9uIDEyLzI4LzE1IDU6NTMgUE0s ICJHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIg0KPj4gPFBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4N Cj4+IHdyb3RlOg0KPj4NCj4+ID5TdGV2ZSwNCj4+ID4NCj4NCj5TTklQDQo+DQo+PiA+V2l0aCBy ZXNwZWN0IHRvIGdlb2dyYXBoaWMgbnVtYmVyIGFzc2lnbm1lbnQsIHRoZSByZWpvaW5kZXIsICJC dXQNCj4+ID50aGUgb3ZlcndoZWxtaW5nIHN1Y2Nlc3Mgb2YgbW9iaWxlIHRlbGVwaG9uZXMgaGFz IGluY3JlYXNpbmcgZXJvZGVkDQo+PiA+dGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBudW1iZXJzIGFu ZCByZWdpb25zIiBoYXMgcHJvYmxlbXMgYXQgbGVhc3QgaW4NCj4+ID50aGUgY29udGV4dCBvZiB0 aGUgTm9ydGggQW1lcmljYW4gbnVtYmVyaW5nIHBsYW4uDQo+Pg0KPj4gVG9tOiBZb3UncmUgb3Zl ciB0aGlua2luZyB0aGlzLiAgTW9iaWxlIGhhcyBhbHdheXMgZXJvZGVkIHRoZQ0KPj4gY29ubmVj dGlvbiBiZXR3ZWVuIG51bWJlcnMgYW5kIHJlZ2lvbnMgLSB0aGF0J3Mgd2hhdCBpdCBkb2VzLiAg VGhpcw0KPj4gaXMgcG9pbnRpbmcgb3V0IHRoYXQgaXQgaXMgbm93IGEgZG9taW5hbnQgcG9ydGlv biBvZiB0aGUgbWFya2V0Lg0KPj4NCj4+IFBHLT4gIEkgdGhpbmsgeW91J3JlIHVuZGVydGhpbmtp bmcgdGhpcy4gIDotKSAgVGhlIG1ham9yaXR5IG9mIHBob25lDQo+PiBQRy0+IGNhbGxzIGFyZSAi bG9jYWwiIGFuZCBjaGFyZ2VkIGFjY29yZGluZ2x5IHBlciByZWd1bGF0b3J5DQo+PiBQRy0+IHJl cXVpcmVtZW50cy4gIFRoaXMgaXNuJ3QgY2hhbmdpbmcuDQo+DQo+SW50cm9kdWN0aW9uIG9mIGZp eGVkIG51bWJlciBwb3J0YWJpbGl0eSBpbiBTd2l0emVybGFuZCByZXN1bHRlZCBpbiB0aGUgZW5k IG9mIGdlb2dyYXBoaWNhbCBjaGFyZ2luZy4gIEluZGVlZCwgaG93IGNhbiB5b3UgY2hhcmdlIGJ5 IGdlb2dyYXBoeSBpZiB0aGUgY2FsbGVyIGNhbm5vdCBrbm93IGluIHdoYXQgZ2VvZ3JhcGh5IHRo ZSBjYWxsZWQgbnVtYmVyIGlzPw0KPg0KPlNOSVANCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPk1vZGVybiBtYWlsaW5nIGxpc3QNCj5Nb2Rlcm5A aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+TGVhcm4gbW9yZSBvbiBob3cg dG8gc3dpdGNoIHRvIFNwcmludCBhbmQgc2F2ZSA1MCUgb24gbW9zdCBWZXJpem9uLCBBVCZUIG9y IFQtTW9iaWxlIHJhdGVzLiBTZWUgc3ByaW50LmNvbS81MG9mZjxodHRwOi8vc3ByaW50LmNvbS81 MG9mZj4gZm9yIGRldGFpbHMuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4NCj5UaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNl IGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBv ZiB0aGUgbWVzc2FnZS4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPk1vZGVybiBtYWlsaW5nIGxpc3QNCj5Nb2Rlcm5AaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpMZWFybiBtb3JlIG9uIGhvdyB0byBzd2l0Y2ggdG8gU3By aW50IGFuZCBzYXZlIDUwJSBvbiBtb3N0IFZlcml6b24sIEFUJlQgb3IgVC1Nb2JpbGUgcmF0ZXMu IFNlZSBzcHJpbnQuY29tLzUwb2ZmPGh0dHA6Ly9zcHJpbnQuY29tLzUwb2ZmPiBmb3IgZGV0YWls cy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5 IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGli aXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRh Y3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Mon Jan 4 13:57:00 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 3FBF31AC3E2 for ; Mon, 4 Jan 2016 13:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSSVHl3A6ZPm for ; Mon, 4 Jan 2016 13:56:56 -0800 (PST) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2801A01FC for ; Mon, 4 Jan 2016 13:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1451944614; bh=IZYbWsQ2mN5CbyCd128c7lOEpgWunEjK+cNcxe1pnCk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=tQds+E2aewRvChiRff9RGFTcbO5QaZc6FntkoKL/NOWGzmD6C1uC5F+jpjjCQL0PSsBmE1aCnJAD3ncOKbqle+zAsvrljd+5jJ2UaaySdhdvCppj6A2nq7lS2Q6TKWsa1vYYfXIL6Aj/32c7PnGeQxZZH9XMkHn8y3YEsx5VV1f8lYyRQCUf8ZwvMhHktitk7KmnWU/jpnoJMb00NEDtRG+Rq7X+qyWwoZ0tUmSjQrgtAoPiX+bAVnXTPtObDnTINOk4sVpvw2SuOTw9zgtsOssrX0J2uwhMppr/FPRItzJ/TcvCO3l251TRecJRa12rDJwo3wQPBbm/kWul1CEXNg== Received: from [66.196.81.171] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2016 21:56:54 -0000 Received: from [98.139.212.211] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2016 21:56:54 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 04 Jan 2016 21:56:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 901340.14932.bm@omp1020.mail.bf1.yahoo.com X-YMail-OSG: BuUENc4VM1nWd5O4c8X0zTihdXSWcWNbulbyjOWYf0PouR0MyMjSEsd7IJzFC9w nGRzf4g6lOwFHcsNm4d3zGqEA3O9EAz.8iT2KJR.Jg0_AqX3YckEJjVFisljMsxaqRpTDmWsASe2 i4eKv1.Roo4nn4V_Ij41jOMB9n_KFBTExVbrQSM_gVBw645mFfEIwIZ.ppdolY5etZjTvQJaHxgE VY_KmN_C_u6laVh0xcCJoZmpRiOgUcFUfU39tZnGc1aEx3APPEPN7SNqd4zJgB9noVpamp.7cxN. 9GdVbJ.qxEEShj5EJaY3evDE_krbxTYucL_j..fM.uEAvFJv2Sedjj8kt8xsZXp0bF.Me6CRcFqT YjEIICYr4ahrd5dRYwkYdixEa3ycG4v4GB008w_Rgs1QhsAJPw_eGxEmzt9YqpABmLKGTGWj10n2 R6DgU0x1e.u49v1ZNqijiWgBoYFJ_5VdbNmrVb1PAy.l_sTTu3s05gaTkFcPqXgUJt2O2QIXlZ1O h_juqI.2qBcXumyaiz.NrAcKXwcNhpZHZXaH_wc3S4A-- Received: by 66.196.80.121; Mon, 04 Jan 2016 21:56:54 +0000 Date: Mon, 4 Jan 2016 21:56:53 +0000 (UTC) From: David Greenhaus To: "Gorman, Pierce A [CTO]" , Richard Shockey , Richard Hill , "'McGarry, Tom'" , "modern@ietf.org" Message-ID: <958436400.7089703.1451944613815.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <9c7c0a78e6c64f5f986c38252bef0f15@PLSWE13M08.ad.sprint.com> References: <9c7c0a78e6c64f5f986c38252bef0f15@PLSWE13M08.ad.sprint.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7089702_1419939349.1451944613806" Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Greenhaus List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:56:59 -0000 ------=_Part_7089702_1419939349.1451944613806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, Regarding the issue of geographic origination, I'd like to bring your atten= tion to a white paper prepared by the Future of Numbering Working Group of = the NANC).=C2=A0 This document was transmitted by the NANC to the FCC, by m= ember agreement, at a recent NANC meeting; it illustrates the critical impo= rtance of "fuzzy" geographic origination information required to route many= toll free calls.=C2=A0=20 The document can be found at:=C2=A0=C2=A0=C2=A0 http://www.nanc-chair.org/d= ocs/documents.html FoN White Paper on Geographic Routing of Toll Free Services =20 On Monday, January 4, 2016 4:37 PM, "Gorman, Pierce A [CTO]" wrote: =20 Richard, This may not be completely appropriate to the MODERN WG discussion, but jus= t a quick point of clarification. My notes on the Order to Reform ICC Rates show that the "price cap" LECs (a= ka RBOC's) and the "rate of return" LECs (aka rural LECs) both get to .0007= (on different schedules as you mentioned), but my working assumption has b= een it never goes to "zero" as you wrote below. There is a bill-and-keep component.=C2=A0 I've assumed that bill-and-keep i= s balance of traffic only and that balance of traffic overages would be pai= d to the terminating LEC.=C2=A0 i.e., there will still be transport access = charges (albeit at .0007 per minute). This exact understanding has been a bit of a problem for me to nail down.= =C2=A0 Either I ask the question wrong, or ask the wrong people, but I'm no= t comfortable I know the complete story.=C2=A0 It could be I'm wrong, and t= he only access will be facilities charges and transport costs of .0007 (tar= iffs to be filed this year) do indeed fall to zero (in 2018 for price cap L= ECs).=C2=A0 Can you confirm? Pierce -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: January 04, 2016 1:47 PM To: Gorman, Pierce A [CTO] ; Richard Hill ; 'McGarry, Tom' ; modern@ietf.org Subject: Re: [Modern] Problem statement draft problems On 1/4/16, 11:35 AM, "Modern on behalf of Gorman, Pierce A [CTO]" wrote: >Good to know.=C2=A0 Thank you. > >Just because the users don't know where a call originated and terminated d= oesn't mean the network does not or cannot know.=C2=A0 I'll speculate that = the Swiss portability uses a similar mechanism as used in North America and= the ported number is associated with a "Local Routing Number" which indexe= s back to a central office switch with a specific geographic location.=C2= =A0 The originating CSP presumably knows where the call originated, and can= look at the geographic location of the terminating switch (not the LRN, bu= t the actual switch which "owns" the LRN) and charge accordingly. > >The most current NANP regulatory guidelines with respect to the Order to R= eform InterCarrier Compensation Rates still includes access charges even af= ter there is bill-and-keep (on balance of traffic?). Its a function of terminating call access rates.=C2=A0 Those have gone to .= 0005 or something like before it goes to zero. The issue is on origination = access charges. The theory in the R&O was the rural carriers were not going= to be able to modify their business models fast enough to accommodate both= so on origination the regime is still in place for now.=C2=A0 It too will = go away especially if there is a move to National Geographic NP in the US w= hich would essentially force the issue once and for all.=C2=A0 That BTW was= the principal topic of discussion at our last NANC meeting at the FCC. IMH= O its coming. > >Pierce > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill >Sent: January 04, 2016 10:26 AM >To: Gorman, Pierce A [CTO] ; 'McGarry, Tom' >; modern@ietf.org >Subject: Re: [Modern] Problem statement draft problems > >Please see embedded comment below. > >Best, >Richard > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, >> Pierce A [CTO] >> Sent: Monday, January 4, 2016 17:21 >> To: McGarry, Tom; modern@ietf.org >> Subject: Re: [Modern] Problem statement draft problems >> >> Thanks Tom.=C2=A0 Inline. >> >> I also have more edits but didn't want to send them out until I've >> completed the review (this week?). >> >> Best regards, >> >> >> Pierce Gorman >> Office: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, >> Tom >> Sent: January 04, 2016 9:16 AM >> To: modern@ietf.org >> Subject: Re: [Modern] Problem statement draft problems >> >> Pierce, thanks for reviewing the document and the feedback.=C2=A0 See my >> comments in line below. >> >> On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" >> >> wrote: >> >> >Steve, >> > > >SNIP > >> >With respect to geographic number assignment, the rejoinder, "But >> >the overwhelming success of mobile telephones has increasing eroded >> >the connection between numbers and regions" has problems at least in >> >the context of the North American numbering plan. >> >> Tom: You're over thinking this.=C2=A0 Mobile has always eroded the >> connection between numbers and regions - that's what it does.=C2=A0 This >> is pointing out that it is now a dominant portion of the market. >> >> PG->=C2=A0 I think you're underthinking this.=C2=A0 :-)=C2=A0 The majori= ty of phone >> PG-> calls are "local" and charged accordingly per regulatory >> PG-> requirements.=C2=A0 This isn't changing. > >Introduction of fixed number portability in Switzerland resulted in the en= d of geographical charging.=C2=A0 Indeed, how can you charge by geography i= f the caller cannot know in what geography the called number is? > >SNIP > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ >Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T o= r T-Mobile rates. See sprint.com/50off for details= . > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the so= le use of the recipient(s). Any use by others is prohibited. If you are not= the intended recipient, please contact the sender and delete all copies of= the message. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ------=_Part_7089702_1419939349.1451944613806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Re= garding the issue of geographic origination, I'd like to bring your attenti= on to a white paper prepared by the Future of Numbering Working Group of th= e NANC).  This document was transmitted by the NANC to the FCC, by mem= ber agreement, at a recent NANC meeting; it illustrates the critical import= ance of "fuzzy" geographic origination information required to route many t= oll free calls. 

The do= cument can be found at:    http://www= .nanc-chair.org/docs/documents.html





On Mon= day, January 4, 2016 4:37 PM, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sp= rint.com> wrote:


Richard,

This may not be completely= appropriate to the MODERN WG discussion, but just a quick point of clarifi= cation.

My notes on the Order to Refor= m ICC Rates show that the "price cap" LECs (aka RBOC's) and the "rate of re= turn" LECs (aka rural LECs) both get to .0007 (on different schedules as yo= u mentioned), but my working assumption has been it never goes to "zero" as= you wrote below.

There is a bill-and-= keep component.  I've assumed that bill-and-keep is balance of traffic= only and that balance of traffic overages would be paid to the terminating= LEC.  i.e., there will still be transport access charges (albeit at .= 0007 per minute).

This exact understan= ding has been a bit of a problem for me to nail down.  Either I ask th= e question wrong, or ask the wrong people, but I'm not comfortable I know t= he complete story.  It could be I'm wrong, and the only access will be= facilities charges and transport costs of .0007 (tariffs to be filed this = year) do indeed fall to zero (in 2018 for price cap LECs).  Can you co= nfirm?

Pierce


-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us]
Sent: January 04, 2016 1:47 PM
To: Gorman,= Pierce A [CTO] <Pierce.Gorman@sprint.com>; Richard Hill <rhill@hill-a.ch>; 'McGarry, Tom' &= lt;Tom.McGarry@neustar.biz>; mod= ern@ietf.org
Subject: Re: [Modern] Problem statement = draft problems






On = 1/4/16, 11:35 AM, "Modern on behalf of Gorman, Pierce A [CTO]" <modern-bounces@ietf.org on behalf of Pierce.Gorman@sprint.com> wrote:

>Good to know.  Thank you.
>
>Just because the users don't know where a call originate= d and terminated doesn't mean the network does not or cannot know.  I'= ll speculate that the Swiss portability uses a similar mechanism as used in= North America and the ported number is associated with a "Local Routing Nu= mber" which indexes back to a central office switch with a specific geograp= hic location.  The originating CSP presumably knows where the call ori= ginated, and can look at the geographic location of the terminating switch = (not the LRN, but the actual switch which "owns" the LRN) and charge accord= ingly.
>
>The most current NANP r= egulatory guidelines with respect to the Order to Reform InterCarrier Compe= nsation Rates still includes access charges even after there is bill-and-ke= ep (on balance of traffic?).


Its a function of terminating call access rates.  Those have= gone to .0005 or something like before it goes to zero. The issue is on or= igination access charges. The theory in the R&O was the rural carriers = were not going to be able to modify their business models fast enough to ac= commodate both so on origination the regime is still in place for now. = ; It too will go away especially if there is a move to National Geographic = NP in the US which would essentially force the issue once and for all. = ; That BTW was the principal topic of discussion at our last NANC meeting a= t the FCC. IMHO its coming.




>
>= Pierce
>
>-----Original Message--= ---
>From: Modern [mailto:mo= dern-bounces@ietf.org] On Behalf Of Richard Hill
>= Sent: January 04, 2016 10:26 AM
>To: Gorman, Pierce A = [CTO] <Pierce.Gorman@sprint.com>; 'Mc= Garry, Tom'
><Tom.McGarry= @neustar.biz>; modern@ietf.org
>S= ubject: Re: [Modern] Problem statement draft problems
>= ;
>Please see embedded comment below.
>
>Best,
>Richard
>
>> -----Original Message-----
>> From: Modern [mailto:modern-= bounces@ietf.org] On Behalf Of Gorman,
>> Pierc= e A [CTO]
>> Sent: Monday, January 4, 2016 17:21>> To: McGarry, Tom; modern@ietf.org>> Subject: Re: [Modern] Problem statement draft prob= lems
>>
>> Thanks Tom. = ; Inline.
>>
>> I also have= more edits but didn't want to send them out until I've
&= gt;> completed the review (this week?).
>>
>> Best regards,
>>
>>
>> Pierce Gorman
&= gt;> Office: 913-439-4368
>> pierce.gorman@sprint.com
>>
>>
>>
>> --= ---Original Message-----
>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry,<= br clear=3D"none">>> Tom
>> Sent: January 04,= 2016 9:16 AM
>> To: modern@ietf.org<= br clear=3D"none">>> Subject: Re: [Modern] Problem statement draft pr= oblems
>>
>> Pierce, thanks= for reviewing the document and the feedback.  See my
>> comments in line below.
>>
>> On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]"
>> <Pierce.Gorman@sprint.com>= ;
>> wrote:
>>
>> >Steve,
>> >
>
>SNIP
>
&= gt;> >With respect to geographic number assignment, the rejoinder, "B= ut
>> >the overwhelming success of mobile teleph= ones has increasing eroded
>> >the connection be= tween numbers and regions" has problems at least in
>&= gt; >the context of the North American numbering plan.
>>
>> Tom: You're over thinking this.  = Mobile has always eroded the
>> connection between = numbers and regions - that's what it does.  This
>= ;> is pointing out that it is now a dominant portion of the market.
>>
>> PG->  I think you= 're underthinking this.  :-)  The majority of phone
>> PG-> calls are "local" and charged accordingly per regulat= ory
>> PG-> requirements.  This isn't chang= ing.
>
>Introduction of fixed num= ber portability in Switzerland resulted in the end of geographical charging= .  Indeed, how can you charge by geography if the caller cannot know i= n what geography the called number is?
>
>SNIP
>
>________________= _______________________________
>Modern mailing list>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern
>
>________________________________
>Learn more on how to switch to Sprint and save 50% on most Ve= rizon, AT&T or T-Mobile rates. See sprint.com/50off<http://sprint.com/50of= f> for details.
>
>_______= _________________________
>
>This= e-mail may contain Sprint proprietary information intended for the sole us= e 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.

&= gt;
>_______________________________________________>Modern mailing list
>Mo= dern@ietf.org
>https://www.ietf.org= /mailman/listinfo/modern


________________________________
Learn more on = how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile = rates. See sprint.com/50off<http://sprint.com/50off> for details.

________________________________

This e-mail may contain Sprint proprietary inf= ormation intended for the sole use of the recipient(s). Any use by others i= s prohibited. If you are not the intended recipient, please contact the sen= der and delete all copies of the message.
_______________= ________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern
=

------=_Part_7089702_1419939349.1451944613806-- From nobody Mon Jan 4 13:57:59 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 20BA81A033B for ; Mon, 4 Jan 2016 13:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzygNkwL01c0 for ; Mon, 4 Jan 2016 13:57:56 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7FB1A01FC for ; Mon, 4 Jan 2016 13:57:55 -0800 (PST) Received: from BN1BFFO11FD037.protection.gbl (10.58.144.30) by BN1BFFO11HUB053.protection.gbl (10.58.144.200) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 4 Jan 2016 21:57:54 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) 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.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN1BFFO11FD037.mail.protection.outlook.com (10.58.144.100) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 4 Jan 2016 21:57:54 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u04J8RHW016715; Mon, 4 Jan 2016 16:57:53 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm1.corp.sprint.com with ESMTP id 206bwf8esf-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2016 16:57:53 -0500 Received: from PLSWE13M08.ad.sprint.com (144.229.214.27) by PREWE13M07.ad.sprint.com (144.226.128.26) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 4 Jan 2016 16:57:52 -0500 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; Mon, 4 Jan 2016 15:57:52 -0600 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4AAC1jVAAABVs0g Date: Mon, 4 Jan 2016 21:57:51 +0000 Message-ID: <2a15ff4397ee4b2f8f34dbb25b7b7be6@PLSWE13M08.ad.sprint.com> References: 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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD037; 1:Piwf8zfAPlEaYMxVmwsf7unKt4jCcmvaa90GFZ9dyVsD/BOMckA6m+FxqoEeP6mVrgxnCMPsCFSFAesX57KdCXyBjxcThilgySOBUY+MTZgTwQH+RJGBIa7LC2k3aJIfU/UXoLSSOZ6XnbMRafNbeL6QY3/rtxbisvAKSB7sfoTpTI3wSPQTAWNh1/HfVrtiZ2D3xAX9Fk9f5cuzIOhjDt28hZ+huUAJ4ZNfwtE40+lg1BOIJNy8jBBGzf/A/Bn9klTm3OsmhZWdnFY7X68sxKnFkHp5xK9mJlu9EB4hb9KR7mU4w5cGJeivq+yT6Yok5yxgtsyYnkINqmm6RbMAywnEqGg5kS9Gj/qkkXed1AYLyBMjs2zPSSZz2dVgeFNF X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(102836003)(33646002)(92566002)(5003600100002)(586003)(3846002)(6806005)(5001770100001)(46406003)(76176999)(5250100002)(15395725005)(24736003)(47776003)(81156007)(107886002)(1220700001)(6116002)(189998001)(2900100001)(50986999)(108616004)(5001960100002)(54356999)(5008740100001)(19580395003)(97736004)(2501003)(86362001)(87936001)(15975445007)(11100500001)(1096002)(106466001)(5004730100002)(50466002)(2950100001)(23726003)(97756001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB053; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB053; 2:d5ynTh43UtDHhjeXuGqAvduDS6Ao0vIryUCLgCCMvMG/fszrselxDzIV/VqtSZJiW8hvkjSuy9PEeBom5oQwQWhWhYVnmd/w/NacGElQg2eAA4WMfofQ+5CCJDeKP/QjAnQamh5MSuUNl7FP6VpE4Q==; 3:GOziV/Ko1lYNC0qMoZryttOvlRg4G6oPeyQZC6hzQ2pxLqP+4xIwVxphlG4P+HibcF1QF7O/A11e41aGkF2AD6n5dtM681DF5KlzKKGnL9EM/Fjt/7Mfh1sWIXS3B3VWTPPXv+LmT4Lv6bqhhVqJdWDOAowZTPnlCY6/Z+XiuDVqWoEf49XzOcFhw5Ufe/RTZVrDIpz0MaGfwnJjaForq4RHPAmyaa9EoT/3USIKVv0NZwyTNyZrV1nGqcbUukGP0kZQCsDFfvhnGIm2JSEOoQ==; 25:N89+mlZGmT06vWj8S7Sk2kweeYgR0wUy1YwOY9VT4rlHNOhv15/g3RX5W20UD1vRUiX/txi3JuT/5gs9NtK7CaMNUKvNCCz0Rs60TJn+BoiJwOKvqlM8CIElx1gOVtO5Heq7n/OeSIgy743oySEH9jEJTJ9cVyAJgbUJe9dQVKrR931EeJwrFdEjOky8vUT6q01F/S/oTJ+4sLA9XJivkYR/z+/PNHNBB7/kDeOk6m5VmassTrbBLMsBxwHymMSxYKt4mv6pALGuufZed/SPNA== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1BFFO11HUB053; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB053; 20:ZVJLRXWqmqwkzUb3ts6MaVz5rP5FHJ37O9tdoP0nxsOVnqGnG59YyvulenqwecsmMqYunmVQFhF8UiBfq+W7AyVIpPPvfIoWJSusJ/UZYN5Xx4vL1FSI1Pm0lkjm+j+uY/6A89VALW6JIfFB8YTCFpIBlTfHbdmS2KqeggFzCy3FcUV10rHydB4wbpX/mowxp/JcaAUCPLuZkfEVG+5q3NPiB2m3s6euLOeYcM8pzba93Zr73KZgr9Omehxq1YEa; 4:aY2aYNZBS852M5QoOPl6YuIPgnOipPlxR48W29Ufp7ScGgP0Mt1cmDYFQy3V/ID3X+h8tnxj2AeqTGBM4jQf4hTLxJeZ/pYZY8S4QH57IVn/TLv3biCqLMLN/DvajiXzsWzW5P2ODFuenVBayr9vtxOoewZ5qPl49z9VMY8t0g66hq51NTxVfJB6YzZikvr7fMm9Wwu6JxhVm7bzJCya9kdlmf00u4oqFz1npgqmogqGuO5mhu09vq4SnnUB3h2QcT2te8ddKtzDZvVWQec+r60a56tSX7AS/dAmIcMm6cVhk4pzOF0nLyskOv/VU2e45/atn38KdfyLwky20C0hk98J1Rbtg8lqIf2M9ETZqaQErPmMitSRRWaukoqIYrgFVM+sz+B6G5oEdyv1C8LeyDuGeaKipg3XVPjnBby5ZyQi7Bn6IlFKlNOjbhqXb3Xa X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BN1BFFO11HUB053; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB053; X-Forefront-PRVS: 08118EFC2B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB053; 23:QcgnK3uKgqhsDym6MN5Bu49Az9A36gy+iLD271Y?= =?us-ascii?Q?MWVjQT1Br+IpDC93enN8g2qBRikbaTluqRqMwnM5kWTdkgosVqHOKWmhsGDJ?= =?us-ascii?Q?CSVaZFzYD6pOgOqB0ICaSuXQ/jv2cUQ8pn9yo+PFwbzJDKwq791q6V9c2yim?= =?us-ascii?Q?eQaTunWlsanzcF1urIiBa/P2jR7TBXVmYo2vADRt6yHT67aYpDDCNMpBR8ls?= =?us-ascii?Q?eL6p3vR2X2xstzvJ4EWG/h/1CaPGkRrFcwFTKHEzcjDUwTWq5J/CM2ur7QZD?= =?us-ascii?Q?MQ+U+CRg/QwENom+ZcotAEq+dYE87nMicv8IGRux6OOW3AtVdf1tYC1MbB+V?= =?us-ascii?Q?tsGOk74OdZ0u0Yf6rSGTI5dzw1GlJIp7WUsDKq/7WylAfXnqpRcbiIV1a4EN?= =?us-ascii?Q?ELCWGcedIk0pLfgG1nLgemFJEY6/B9CQ/3UqRohN2rV+TtrO5YUqDFvwxq2c?= =?us-ascii?Q?2hGdlIRifM1b10fH/tqEgY6Hx1ho1rltUDRvXoKZxNbmbts5JGkeC0LHOFtO?= =?us-ascii?Q?QZn/JNarVP3QKRh8/DdgtyqCpy8oA6WXx5TwzUr4rNTYLcDZ7JCkhFpUgG60?= =?us-ascii?Q?6q3uX1lpeY5LdhkAcq6UyeyHJB94r23euiDOm5XIuB2dzfK7SbY5JsFIK4wQ?= =?us-ascii?Q?CJshWJ5PgTfyUfR5gHG7tDPrHV30IrhjT4Ug6frretJ80Rz6IPcNI/ShXiZj?= =?us-ascii?Q?5U5ndzkMUbo31K0+OPRwMwBarkxsXSmpa+UP3VbujDTWccA2RY51CivOpEVm?= =?us-ascii?Q?xKfhSICZyq5+oZVN6CbZSLzh/cBg4OAynU/hmoifeK4mvXS6LwzbtzPYUEBD?= =?us-ascii?Q?cnStuutPhxz+Ma7edBPpDebYRvbZ+Z5OuBmPWd1vh2bQKufJBWFqaJo9kZ3p?= =?us-ascii?Q?JWGWjrF+nbc2XDS3u3/kGdkvtrFL/FURB6afPAKcuzwH19aB6ZNZSW8iAvrK?= =?us-ascii?Q?HMLotBWJh8VIQi34W0tTpPqSPSZszRtX5ILLs+eQgxt/XbpmVjqC4tuqgxYv?= =?us-ascii?Q?9QryW3cQDI74i8NYHc4ZAwv9xQGL5vx+ZgYyi7cVPV5ocx8NbAm+W0LD/E5i?= =?us-ascii?Q?g13OCkPWlmDgZfX8yImldpP1lOUzvDqdnweeh4JOhpsP4heI12oGr4ZY5xtF?= =?us-ascii?Q?5+o0Yrh+em5fh7EpJO/iEGXQzMiVZ5Vlw2UhuNw9g/gtvrFHtEdgTr/Mu8qf?= =?us-ascii?Q?RWpsBw23TZ6O+YyY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB053; 5:jryQJVgEROGtrxhvgDQvOpL5/JoSI+CAPe+QkX3Brc27QgAI3rNNgplUq6pnEij/62mwWbuiTcdTHf4edeDZCbe3frr6mp3o6PM5xUf55LMzR+N1gd24mTQt7MzaSPNYkjVK/lEQ/zGmZxPtLvzsWA==; 24:JsH5MBmWEMz/Apa6NVLS01ouYbT0gd5EF0hsa5hwM/KXSUlCUqY/bg9rTHYYGn2TfXUq2PGxgDa7fx/DwkmSQ2pRHlF8C53UEi0q1Ii/ldw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2016 21:57:54.0450 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB053 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:57:58 -0000 >>I recommend changing the statement to, " But the overwhelming success >>of mobile telephones has increasingly obfuscated the connection between >>numbers and regions". >> " Can you explain what you are trying to communicate by using the word "obf= uscate"? " Blurred. Confused. Made non-obvious. Obstructed a clear and easy underst= anding. Overcomplicates. ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jan 4 14:16: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 7FC021AC424 for ; Mon, 4 Jan 2016 14:16:14 -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 JaUEF43LHvtJ for ; Mon, 4 Jan 2016 14:16:08 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211D01AC41F for ; Mon, 4 Jan 2016 14:16:07 -0800 (PST) Received: from BL2FFO11FD020.protection.gbl (10.173.160.31) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 4 Jan 2016 22:16:04 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) 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.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BL2FFO11FD020.mail.protection.outlook.com (10.173.161.38) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 4 Jan 2016 22:16:04 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u04Lt3GI017704; Mon, 4 Jan 2016 16:16:04 -0600 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 206d768ba7-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2016 16:16:04 -0600 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 4 Jan 2016 17:16:02 -0500 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; Mon, 4 Jan 2016 16:16:02 -0600 From: "Gorman, Pierce A [CTO]" To: David Greenhaus , Richard Shockey , Richard Hill , "'McGarry, Tom'" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4AAAVroEAAAKDPgABOItYAACQa0AP//3A6AgABfoFA= Date: Mon, 4 Jan 2016 22:16:01 +0000 Message-ID: <88104851c8c84c30bd4778db8bc66fe8@PLSWE13M08.ad.sprint.com> References: <9c7c0a78e6c64f5f986c38252bef0f15@PLSWE13M08.ad.sprint.com> <958436400.7089703.1451944613815.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <958436400.7089703.1451944613815.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.38] Content-Type: multipart/alternative; boundary="_000_88104851c8c84c30bd4778db8bc66fe8PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD020; 1:uw+xmELpLCUhvVmQw38nXZ9KlsVBruoULy+UffU7990XUmV0OVC0uNzFsuXnhWfjkTH9WGzZ9IYMdeQQL3UABQ+X8PebK5VTIWiQTp8C1mn46vkLsfXW6L1WXJDRwxW9Y8CO8658uazeG4cBSUVCB2BWMqQwxrZ2hRzb+bbf1ea/4uOZal8XCaRi7qdoX4xJHQVHFTXlnQR/hHP8lQ48f0W81Lf6c+kby3XXRo82NAw6bVGJJ7UTqraMYSF5r6wbIaoln2/WeUE9aNtsYdywHxm068nZ479B8OPjqTocar0BLEC8WZNotVNsOZDLhprlO1PTr7IvUgbxZzHf6RSyfZ5JLMtAKMJS04sxz+zsN/tqe6rBI5YwU1Iu1zsjPRrHL/yv4EAxaHQPRZSLQ2sWdA== X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(2980300002)(438002)(13464003)(24454002)(479174004)(199003)(52604005)(189002)(377454003)(1220700001)(790700001)(86362001)(19625215002)(92566002)(76176999)(102836003)(50986999)(15975445007)(97736004)(19580405001)(33646002)(2900100001)(106466001)(5001960100002)(189998001)(3846002)(6116002)(11100500001)(586003)(1096002)(54356999)(81156007)(4546004)(16297215004)(108616004)(2521001)(107886002)(19273905006)(5003600100002)(19617315012)(84326002)(2501003)(15395725005)(24736003)(19580395003)(5001770100001)(5004730100002)(300700001)(512874002)(6806005)(19300405004)(30436002)(5008740100001)(87936001)(5250100002)(2950100001)(16236675004)(562404015)(563064011)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB034; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB034; 2:0/vSwoF/jLyDH9ym+qEp8eoZVDJo07/MPDuWHKdMJqDrhrMlZYsqlvu3G4Xm1nBuHJ4WRAef4yO/U8+zZSVHZ1h1ZFau9JRhntXfyFz9fyZzcYB/HTggt0of0EcPkiD3zfRpXJ6A4G6n+02DeQId4A==; 3:R/tByqOGsHZ+Bsg5wXxt5axUmIM3dn9+3s6YgkzHxWmdSXXm40JGbBSoxtgvoHJrJBJumQoHF20oVW75gAYW4iwqVK28TIm+rWU1QV5wzi2gWpwVLykgS49ppthaD0Or2cHNSVwxOLScWx/rRHKgd9vnokefXS/i8m/qf5acEss+OT+pWwda4k3vGqhXqbeFgae2na2p0N8Z3TuNyd3F0lO/OmUpTxXaOQbmUM23hDNW1DmFtiDzEWANR2TSsksxfxorDreeslkbMJir/YsIRA==; 25:/fb8jovd2tMjWBG+EHjKDeko+Yxpuq9ss6nqBPAaSyBdC4IfXp2uHV9ukklNnchlcJ3ehnfYNXBI3017lqwDk9NjVkRg2InmMlH3Rdo7Tm+xmowmFI2Gll66IAIO5vEaIKpcb+HSAy9lEidOA9VsDKMsz9N0hSUWKx3AngmIUoxMpp4e/wAYkdvPrQ3t8rx5RD/M3lJ+SKU3Unjoqs86YrkaX4m2446B7WQVD8qwYXedNsZlZZtFQylHcqyFihFhp73aniKGjoTB3Yd+0q2RfA== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB034; UriScan:(201166117486090)(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB034; 20:DCIiFBgiTvqZvmeMNQGtQ6/1SvCAjENtWCJbmZumy4H1CQjPleKkYBoH5kKiWMLcfRz7wqC3hrwbTy0VT3qXQLlBOb/t7oAjKcLp/anU3GMqHBqPlpEdmhDoxubW/mIbBB08tsiy++9pRiSQIYTKe1elEPigC831N+lR1hwR5kYTSixtuqaXecLOVmnmVSrmPG4hB4KPtxvHgZyO5jVXGBl1vq244RMypn3vDful30MdbCFZl88dxWndhFiNZiv3; 4:wNzZPy/uCWDgnUG964Paai2DQYECQeO4P6+rVTmRVXSqLndNT6kxILtnQmLidPgLZqohEjH9DzT57dUHFdiuymP10sO0U6zVnDgdi/cptx6n9fJbsiO9KTUYxSyHXozw6qXpxOPmTK/qVlvclZhOOGle/XvoMfLnBbLVqS9KCjZ5AFO0SNOQ0cG+L8hdCcOV7Q1O1mWZgeShKZyFlDL3zSIFsZlN/qZX+Jz6XOZh8lvEywlEsztTzLbW34z/kRu1K6KDwr2fWvDboEDYb3RetMLhmDM5Fve7dYCXh3twUwlcZJgeCOh9D4HiWButGMl65swh50/TQR8zrxd0KuhqjAfHm//pDgAMe7Ww+tdOnEDU8muoKZ7WvzhA9MPc+fMrDPEEHrhr5OOmE+Ee5PP328/UIyAd85cGOtVxuPltVXSaYFwAmAcamhWxhSvGs/pcS0W5BxuuiP4m7y1GKslD/g== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BL2FFO11HUB034; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB034; X-Forefront-PRVS: 08118EFC2B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB034; 23:BVC5OQ0Q/wKhVCOSHemlJ1tni01KO5IiSQYEbEG6?= =?us-ascii?Q?IGUjH+LB4JHxUbaxSsGSYH7Gg/jQr6OEEhITWcfOOW3eY4hJii/yyFpXhwcR?= =?us-ascii?Q?+J0zHmTdwE0WjM0rKiVWAFh9JUSMe9V8PKn34d9jxMgA5ORl6QkvKrMs8X+B?= =?us-ascii?Q?4I4IUY517jT8qE4VmSAbeK1KH4MGXTzegfQ7q+gPsfneMfcexUKsGIhx8rDA?= =?us-ascii?Q?+wtnO9xAzs5WJOmJKhfESGEwoFK8WIo21p9OfLzNDuKLtCDwMw9V4A5xO1UZ?= =?us-ascii?Q?qUASfkPcFQMKRFMtFE7JPYPB3ax2tT3K/kk7bOkdEgBeyDYghOg/q2uUbuJZ?= =?us-ascii?Q?oH2x+SL9kFXujh626DkYeaGgzaabsq3NVe7RjYUoJQdXasV7l27PJt7/4fvw?= =?us-ascii?Q?9MWaDlHhykq2hzl7rTAUdn9ZIrAThg3H1Y6v+EzoyyDAveMhLZE3/fbFJ8Pw?= =?us-ascii?Q?HW932YDyvEnTSbBw1zmzCvwMMv0LHTWzaVi+MyonuzWccEMQ88m4ttJ34FFg?= =?us-ascii?Q?c3+hT3Ko3zBf+obNEqhbq6X7nPQTGAchCMU4pBsyGDMSHKDzv68eBKgB5is/?= =?us-ascii?Q?FvoDs0lkuKYdKSOd+4zvy39QNgkpzf3p8c/CLVxWE7JyCbgVoaAi6VW20kvG?= =?us-ascii?Q?I/Ut7/ni0EaVZP34uPVMVcbAda2Db8PfAnu9FGN7HOEUL2sc/G/KRYO71hJc?= =?us-ascii?Q?yMkh6nr/1x4IXioFU9N/RvsLIHcE5zf1sjC+76pMhsUCscfSHA2Tk+HLdJHU?= =?us-ascii?Q?J9fmmXE9Hl7kh89Ap425XWVOpmu/WTR27UW7F9bZi+oFTVtCE6G94Septia+?= =?us-ascii?Q?PvjOc1vhaaEi1rG3tgNTwXN8yiYHgkd4L9ub150rkcqT5g9Q5J8WhcaM5pyi?= =?us-ascii?Q?s8mQy6V6kvudCgNm9GYbRK0tSdheRsMymvd3uwAjTSennqrAnkKw1UYdeS36?= =?us-ascii?Q?JRGrQgwQ5erXfnmLB3IQ38UntbPpxEogk4UVjVBrcux4G+qqyXBC+I2Uf2PC?= =?us-ascii?Q?H347Q6D95Qg6cuVcpPclwa5Cr1NIJwq8rqAJdmvmpy4cLbd0GXlv8E3dbHuQ?= =?us-ascii?Q?vfx46+5ct7ppzUP+zSvfLB8SUnKzMuoaBroR+vuxs5luvx4E0W0mXElBCerN?= =?us-ascii?Q?JxG3w/1BWfYc8MIO/HiiPbmETCYHn+0ZhGKPeWQBKZFdw8+1KXS4poLPdiBs?= =?us-ascii?Q?Y4yTvD9Z8cl9Co64lsX3UopNA+cl1/3M+W2uqyMgfRJyHQxaqwe8ewFV9jJ5?= =?us-ascii?Q?Ci74j0V7oH5ytJv5Fuow4Gym/Jw7GmgD2Uvm04Zszosr9yFZzIU/bF+Sj8HS?= =?us-ascii?Q?A/4DAbaTCliG3eSA+AJMMlQ3RhfJggkxaCwalDCJyDcssU5DF52mwQ30U8AX?= =?us-ascii?Q?WKr4Aq03Nph2hR/lMikmOc988Mig7RGcmimiGgljmv2lIV7YSk8zE+lpT4pH?= =?us-ascii?Q?Cxo7AfJSdSxBd/SQegWKYV6duAyEkk0PbhMmWHS0zbo4BlDnHWl3fA8Sj9M4?= =?us-ascii?Q?Fp9Dde4/x/Ii79K1NPhfPMwr+qj+AVrIuMqFHZaRPnvKXXS8uLAkz2jyuM0w?= =?us-ascii?Q?IHLrSd4ADpv1X5k0R26Q/DWDul+hxD7Oi1wYUF2nN7GOLSNiyaQtavSMuvVS?= =?us-ascii?Q?HjXrDD2lwkYW8CJB+DsC5fq6pDt6Vb6kFO7EwPFtty3I3AMcH7X1xy+kJV1S?= =?us-ascii?Q?77mP?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB034; 5:NKti8eYdpJHg9t4vMMf+5B1HPKEF6ajAbTXYU/7uW+RZqTBlmfcIDHnNxX1wTFIyJtsg8b+8hzwwJwcNIatqFkq2D4mhnsRgiXVHm7nDK9SV8zuZpqE8+E/XIJuh01dACiyCKxWM+BR+Cvk2VMOdCw==; 24:/pwoP3n43hVNBLE8OYUB19kJCeuK10iubZro8pVrIm+lL0Od3eTNsevxsOTEWt7dR28WNM1HjLZKZC5OzNdfs3wQOV9X7n3dB38swC2OI2g= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2016 22:16:04.7909 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB034 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:16:14 -0000 --_000_88104851c8c84c30bd4778db8bc66fe8PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IERhdmlkLiAgQWdyZWUgdGhhdCBUb2xsIEZyZWUgaXMgb25lIGV4YW1wbGUgb2Yg bWFueSBjYWxsIHJvdXRpbmcgcmVxdWlyZW1lbnRzIHdpdGggbmVjZXNzYXJ5IGNvbnNpZGVyYXRp b24gZm9yIGdlb2dyYXBoeS4NCg0KUGllcmNlDQoNCg0KRnJvbTogRGF2aWQgR3JlZW5oYXVzIFtt YWlsdG86ZGtncmVlbmhhdXNAeWFob28uY29tXQ0KU2VudDogSmFudWFyeSAwNCwgMjAxNiAzOjU3 IFBNDQpUbzogR29ybWFuLCBQaWVyY2UgQSBbQ1RPXSA8UGllcmNlLkdvcm1hbkBzcHJpbnQuY29t PjsgUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNob2NrZXkudXM+OyBSaWNoYXJkIEhpbGwgPHJo aWxsQGhpbGwtYS5jaD47ICdNY0dhcnJ5LCBUb20nIDxUb20uTWNHYXJyeUBuZXVzdGFyLmJpej47 IG1vZGVybkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNb2Rlcm5dIFByb2JsZW0gc3RhdGVtZW50 IGRyYWZ0IHByb2JsZW1zDQoNCkFsbCwNCg0KUmVnYXJkaW5nIHRoZSBpc3N1ZSBvZiBnZW9ncmFw aGljIG9yaWdpbmF0aW9uLCBJJ2QgbGlrZSB0byBicmluZyB5b3VyIGF0dGVudGlvbiB0byBhIHdo aXRlIHBhcGVyIHByZXBhcmVkIGJ5IHRoZSBGdXR1cmUgb2YgTnVtYmVyaW5nIFdvcmtpbmcgR3Jv dXAgb2YgdGhlIE5BTkMpLiAgVGhpcyBkb2N1bWVudCB3YXMgdHJhbnNtaXR0ZWQgYnkgdGhlIE5B TkMgdG8gdGhlIEZDQywgYnkgbWVtYmVyIGFncmVlbWVudCwgYXQgYSByZWNlbnQgTkFOQyBtZWV0 aW5nOyBpdCBpbGx1c3RyYXRlcyB0aGUgY3JpdGljYWwgaW1wb3J0YW5jZSBvZiAiZnV6enkiIGdl b2dyYXBoaWMgb3JpZ2luYXRpb24gaW5mb3JtYXRpb24gcmVxdWlyZWQgdG8gcm91dGUgbWFueSB0 b2xsIGZyZWUgY2FsbHMuDQoNClRoZSBkb2N1bWVudCBjYW4gYmUgZm91bmQgYXQ6ICAgIGh0dHA6 Ly93d3cubmFuYy1jaGFpci5vcmcvZG9jcy9kb2N1bWVudHMuaHRtbA0KDQpGb04gV2hpdGUgUGFw ZXIgb24gR2VvZ3JhcGhpYyBSb3V0aW5nIG9mIFRvbGwgRnJlZSBTZXJ2aWNlczxodHRwOi8vd3d3 Lm5hbmMtY2hhaXIub3JnL2RvY3MvZm9uL0ZvTl9XaGl0ZV9QYXBlcl9HZW9ncmFwaGljX1JvdXRp bmdfVG9sbF9GcmVlX1NlcnZpY2VzXzIwMTQxMDAxLmRvY3g+DQoNCg0KPGh0dHA6Ly93d3cubmFu Yy1jaGFpci5vcmcvZG9jcy9mb24vRm9OX1doaXRlX1BhcGVyX0dlb2dyYXBoaWNfUm91dGluZ19U b2xsX0ZyZWVfU2VydmljZXNfMjAxNDEwMDEuZG9jeD4NCg0KT24gTW9uZGF5LCBKYW51YXJ5IDQs IDIwMTYgNDozNyBQTSwgIkdvcm1hbiwgUGllcmNlIEEgW0NUT10iIDxQaWVyY2UuR29ybWFuQHNw cmludC5jb208bWFpbHRvOlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4+IHdyb3RlOg0KDQpSaWNo YXJkLA0KDQpUaGlzIG1heSBub3QgYmUgY29tcGxldGVseSBhcHByb3ByaWF0ZSB0byB0aGUgTU9E RVJOIFdHIGRpc2N1c3Npb24sIGJ1dCBqdXN0IGEgcXVpY2sgcG9pbnQgb2YgY2xhcmlmaWNhdGlv bi4NCg0KTXkgbm90ZXMgb24gdGhlIE9yZGVyIHRvIFJlZm9ybSBJQ0MgUmF0ZXMgc2hvdyB0aGF0 IHRoZSAicHJpY2UgY2FwIiBMRUNzIChha2EgUkJPQydzKSBhbmQgdGhlICJyYXRlIG9mIHJldHVy biIgTEVDcyAoYWthIHJ1cmFsIExFQ3MpIGJvdGggZ2V0IHRvIC4wMDA3IChvbiBkaWZmZXJlbnQg c2NoZWR1bGVzIGFzIHlvdSBtZW50aW9uZWQpLCBidXQgbXkgd29ya2luZyBhc3N1bXB0aW9uIGhh cyBiZWVuIGl0IG5ldmVyIGdvZXMgdG8gInplcm8iIGFzIHlvdSB3cm90ZSBiZWxvdy4NCg0KVGhl cmUgaXMgYSBiaWxsLWFuZC1rZWVwIGNvbXBvbmVudC4gIEkndmUgYXNzdW1lZCB0aGF0IGJpbGwt YW5kLWtlZXAgaXMgYmFsYW5jZSBvZiB0cmFmZmljIG9ubHkgYW5kIHRoYXQgYmFsYW5jZSBvZiB0 cmFmZmljIG92ZXJhZ2VzIHdvdWxkIGJlIHBhaWQgdG8gdGhlIHRlcm1pbmF0aW5nIExFQy4gIGku ZS4sIHRoZXJlIHdpbGwgc3RpbGwgYmUgdHJhbnNwb3J0IGFjY2VzcyBjaGFyZ2VzIChhbGJlaXQg YXQgLjAwMDcgcGVyIG1pbnV0ZSkuDQoNClRoaXMgZXhhY3QgdW5kZXJzdGFuZGluZyBoYXMgYmVl biBhIGJpdCBvZiBhIHByb2JsZW0gZm9yIG1lIHRvIG5haWwgZG93bi4gIEVpdGhlciBJIGFzayB0 aGUgcXVlc3Rpb24gd3JvbmcsIG9yIGFzayB0aGUgd3JvbmcgcGVvcGxlLCBidXQgSSdtIG5vdCBj b21mb3J0YWJsZSBJIGtub3cgdGhlIGNvbXBsZXRlIHN0b3J5LiAgSXQgY291bGQgYmUgSSdtIHdy b25nLCBhbmQgdGhlIG9ubHkgYWNjZXNzIHdpbGwgYmUgZmFjaWxpdGllcyBjaGFyZ2VzIGFuZCB0 cmFuc3BvcnQgY29zdHMgb2YgLjAwMDcgKHRhcmlmZnMgdG8gYmUgZmlsZWQgdGhpcyB5ZWFyKSBk byBpbmRlZWQgZmFsbCB0byB6ZXJvIChpbiAyMDE4IGZvciBwcmljZSBjYXAgTEVDcykuICBDYW4g eW91IGNvbmZpcm0/DQoNClBpZXJjZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBSaWNoYXJkIFNob2NrZXkgW21haWx0bzpyaWNoYXJkQHNob2NrZXkudXM8bWFpbHRvOnJp Y2hhcmRAc2hvY2tleS51cz5dDQpTZW50OiBKYW51YXJ5IDA0LCAyMDE2IDE6NDcgUE0NClRvOiBH b3JtYW4sIFBpZXJjZSBBIFtDVE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb208bWFpbHRvOlBp ZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4+OyBSaWNoYXJkIEhpbGwgPHJoaWxsQGhpbGwtYS5jaDxt YWlsdG86cmhpbGxAaGlsbC1hLmNoPj47ICdNY0dhcnJ5LCBUb20nIDxUb20uTWNHYXJyeUBuZXVz dGFyLmJpejxtYWlsdG86VG9tLk1jR2FycnlAbmV1c3Rhci5iaXo+PjsgbW9kZXJuQGlldGYub3Jn PG1haWx0bzptb2Rlcm5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01vZGVybl0gUHJvYmxlbSBz dGF0ZW1lbnQgZHJhZnQgcHJvYmxlbXMNCg0KDQoNCg0KDQoNCk9uIDEvNC8xNiwgMTE6MzUgQU0s ICJNb2Rlcm4gb24gYmVoYWxmIG9mIEdvcm1hbiwgUGllcmNlIEEgW0NUT10iIDxtb2Rlcm4tYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBQaWVyY2UuR29ybWFuQHNwcmludC5jb208bWFpbHRvOlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNv bT4+IHdyb3RlOg0KDQo+R29vZCB0byBrbm93LiAgVGhhbmsgeW91Lg0KPg0KPkp1c3QgYmVjYXVz ZSB0aGUgdXNlcnMgZG9uJ3Qga25vdyB3aGVyZSBhIGNhbGwgb3JpZ2luYXRlZCBhbmQgdGVybWlu YXRlZCBkb2Vzbid0IG1lYW4gdGhlIG5ldHdvcmsgZG9lcyBub3Qgb3IgY2Fubm90IGtub3cuICBJ J2xsIHNwZWN1bGF0ZSB0aGF0IHRoZSBTd2lzcyBwb3J0YWJpbGl0eSB1c2VzIGEgc2ltaWxhciBt ZWNoYW5pc20gYXMgdXNlZCBpbiBOb3J0aCBBbWVyaWNhIGFuZCB0aGUgcG9ydGVkIG51bWJlciBp cyBhc3NvY2lhdGVkIHdpdGggYSAiTG9jYWwgUm91dGluZyBOdW1iZXIiIHdoaWNoIGluZGV4ZXMg YmFjayB0byBhIGNlbnRyYWwgb2ZmaWNlIHN3aXRjaCB3aXRoIGEgc3BlY2lmaWMgZ2VvZ3JhcGhp YyBsb2NhdGlvbi4gIFRoZSBvcmlnaW5hdGluZyBDU1AgcHJlc3VtYWJseSBrbm93cyB3aGVyZSB0 aGUgY2FsbCBvcmlnaW5hdGVkLCBhbmQgY2FuIGxvb2sgYXQgdGhlIGdlb2dyYXBoaWMgbG9jYXRp b24gb2YgdGhlIHRlcm1pbmF0aW5nIHN3aXRjaCAobm90IHRoZSBMUk4sIGJ1dCB0aGUgYWN0dWFs IHN3aXRjaCB3aGljaCAib3ducyIgdGhlIExSTikgYW5kIGNoYXJnZSBhY2NvcmRpbmdseS4NCj4N Cj5UaGUgbW9zdCBjdXJyZW50IE5BTlAgcmVndWxhdG9yeSBndWlkZWxpbmVzIHdpdGggcmVzcGVj dCB0byB0aGUgT3JkZXIgdG8gUmVmb3JtIEludGVyQ2FycmllciBDb21wZW5zYXRpb24gUmF0ZXMg c3RpbGwgaW5jbHVkZXMgYWNjZXNzIGNoYXJnZXMgZXZlbiBhZnRlciB0aGVyZSBpcyBiaWxsLWFu ZC1rZWVwIChvbiBiYWxhbmNlIG9mIHRyYWZmaWM/KS4NCg0KDQpJdHMgYSBmdW5jdGlvbiBvZiB0 ZXJtaW5hdGluZyBjYWxsIGFjY2VzcyByYXRlcy4gIFRob3NlIGhhdmUgZ29uZSB0byAuMDAwNSBv ciBzb21ldGhpbmcgbGlrZSBiZWZvcmUgaXQgZ29lcyB0byB6ZXJvLiBUaGUgaXNzdWUgaXMgb24g b3JpZ2luYXRpb24gYWNjZXNzIGNoYXJnZXMuIFRoZSB0aGVvcnkgaW4gdGhlIFImTyB3YXMgdGhl IHJ1cmFsIGNhcnJpZXJzIHdlcmUgbm90IGdvaW5nIHRvIGJlIGFibGUgdG8gbW9kaWZ5IHRoZWly IGJ1c2luZXNzIG1vZGVscyBmYXN0IGVub3VnaCB0byBhY2NvbW1vZGF0ZSBib3RoIHNvIG9uIG9y aWdpbmF0aW9uIHRoZSByZWdpbWUgaXMgc3RpbGwgaW4gcGxhY2UgZm9yIG5vdy4gIEl0IHRvbyB3 aWxsIGdvIGF3YXkgZXNwZWNpYWxseSBpZiB0aGVyZSBpcyBhIG1vdmUgdG8gTmF0aW9uYWwgR2Vv Z3JhcGhpYyBOUCBpbiB0aGUgVVMgd2hpY2ggd291bGQgZXNzZW50aWFsbHkgZm9yY2UgdGhlIGlz c3VlIG9uY2UgYW5kIGZvciBhbGwuICBUaGF0IEJUVyB3YXMgdGhlIHByaW5jaXBhbCB0b3BpYyBv ZiBkaXNjdXNzaW9uIGF0IG91ciBsYXN0IE5BTkMgbWVldGluZyBhdCB0aGUgRkNDLiBJTUhPIGl0 cyBjb21pbmcuDQoNCg0KDQoNCj4NCj5QaWVyY2UNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPkZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVybi1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBSaWNoYXJkIEhpbGwNCj5T ZW50OiBKYW51YXJ5IDA0LCAyMDE2IDEwOjI2IEFNDQo+VG86IEdvcm1hbiwgUGllcmNlIEEgW0NU T10gPFBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbTxtYWlsdG86UGllcmNlLkdvcm1hbkBzcHJpbnQu Y29tPj47ICdNY0dhcnJ5LCBUb20nDQo+PFRvbS5NY0dhcnJ5QG5ldXN0YXIuYml6PG1haWx0bzpU b20uTWNHYXJyeUBuZXVzdGFyLmJpej4+OyBtb2Rlcm5AaWV0Zi5vcmc8bWFpbHRvOm1vZGVybkBp ZXRmLm9yZz4NCj5TdWJqZWN0OiBSZTogW01vZGVybl0gUHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQg cHJvYmxlbXMNCj4NCj5QbGVhc2Ugc2VlIGVtYmVkZGVkIGNvbW1lbnQgYmVsb3cuDQo+DQo+QmVz dCwNCj5SaWNoYXJkDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTog TW9kZXJuIFttYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1vZGVybi1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEdvcm1hbiwNCj4+IFBpZXJjZSBBIFtDVE9dDQo+ PiBTZW50OiBNb25kYXksIEphbnVhcnkgNCwgMjAxNiAxNzoyMQ0KPj4gVG86IE1jR2FycnksIFRv bTsgbW9kZXJuQGlldGYub3JnPG1haWx0bzptb2Rlcm5AaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBS ZTogW01vZGVybl0gUHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgcHJvYmxlbXMNCj4+DQo+PiBUaGFu a3MgVG9tLiAgSW5saW5lLg0KPj4NCj4+IEkgYWxzbyBoYXZlIG1vcmUgZWRpdHMgYnV0IGRpZG4n dCB3YW50IHRvIHNlbmQgdGhlbSBvdXQgdW50aWwgSSd2ZQ0KPj4gY29tcGxldGVkIHRoZSByZXZp ZXcgKHRoaXMgd2Vlaz8pLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+Pg0KPj4gUGllcmNl IEdvcm1hbg0KPj4gT2ZmaWNlOiA5MTMtNDM5LTQzNjgNCj4+IHBpZXJjZS5nb3JtYW5Ac3ByaW50 LmNvbTxtYWlsdG86cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tPg0KPj4NCj4+DQo+Pg0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVybi1i b3VuY2VzQGlldGYub3JnPG1haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBNY0dhcnJ5LA0KPj4gVG9tDQo+PiBTZW50OiBKYW51YXJ5IDA0LCAyMDE2IDk6MTYgQU0N Cj4+IFRvOiBtb2Rlcm5AaWV0Zi5vcmc8bWFpbHRvOm1vZGVybkBpZXRmLm9yZz4NCj4+IFN1Ympl Y3Q6IFJlOiBbTW9kZXJuXSBQcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBwcm9ibGVtcw0KPj4NCj4+ IFBpZXJjZSwgdGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIGRvY3VtZW50IGFuZCB0aGUgZmVlZGJh Y2suICBTZWUgbXkNCj4+IGNvbW1lbnRzIGluIGxpbmUgYmVsb3cuDQo+Pg0KPj4gT24gMTIvMjgv MTUgNTo1MyBQTSwgIkdvcm1hbiwgUGllcmNlIEEgW0NUT10iDQo+PiA8UGllcmNlLkdvcm1hbkBz cHJpbnQuY29tPG1haWx0bzpQaWVyY2UuR29ybWFuQHNwcmludC5jb20+Pg0KPj4gd3JvdGU6DQo+ Pg0KPj4gPlN0ZXZlLA0KPj4gPg0KPg0KPlNOSVANCj4NCj4+ID5XaXRoIHJlc3BlY3QgdG8gZ2Vv Z3JhcGhpYyBudW1iZXIgYXNzaWdubWVudCwgdGhlIHJlam9pbmRlciwgIkJ1dA0KPj4gPnRoZSBv dmVyd2hlbG1pbmcgc3VjY2VzcyBvZiBtb2JpbGUgdGVsZXBob25lcyBoYXMgaW5jcmVhc2luZyBl cm9kZWQNCj4+ID50aGUgY29ubmVjdGlvbiBiZXR3ZWVuIG51bWJlcnMgYW5kIHJlZ2lvbnMiIGhh cyBwcm9ibGVtcyBhdCBsZWFzdCBpbg0KPj4gPnRoZSBjb250ZXh0IG9mIHRoZSBOb3J0aCBBbWVy aWNhbiBudW1iZXJpbmcgcGxhbi4NCj4+DQo+PiBUb206IFlvdSdyZSBvdmVyIHRoaW5raW5nIHRo aXMuICBNb2JpbGUgaGFzIGFsd2F5cyBlcm9kZWQgdGhlDQo+PiBjb25uZWN0aW9uIGJldHdlZW4g bnVtYmVycyBhbmQgcmVnaW9ucyAtIHRoYXQncyB3aGF0IGl0IGRvZXMuICBUaGlzDQo+PiBpcyBw b2ludGluZyBvdXQgdGhhdCBpdCBpcyBub3cgYSBkb21pbmFudCBwb3J0aW9uIG9mIHRoZSBtYXJr ZXQuDQo+Pg0KPj4gUEctPiAgSSB0aGluayB5b3UncmUgdW5kZXJ0aGlua2luZyB0aGlzLiAgOi0p ICBUaGUgbWFqb3JpdHkgb2YgcGhvbmUNCj4+IFBHLT4gY2FsbHMgYXJlICJsb2NhbCIgYW5kIGNo YXJnZWQgYWNjb3JkaW5nbHkgcGVyIHJlZ3VsYXRvcnkNCj4+IFBHLT4gcmVxdWlyZW1lbnRzLiAg VGhpcyBpc24ndCBjaGFuZ2luZy4NCj4NCj5JbnRyb2R1Y3Rpb24gb2YgZml4ZWQgbnVtYmVyIHBv cnRhYmlsaXR5IGluIFN3aXR6ZXJsYW5kIHJlc3VsdGVkIGluIHRoZSBlbmQgb2YgZ2VvZ3JhcGhp Y2FsIGNoYXJnaW5nLiAgSW5kZWVkLCBob3cgY2FuIHlvdSBjaGFyZ2UgYnkgZ2VvZ3JhcGh5IGlm IHRoZSBjYWxsZXIgY2Fubm90IGtub3cgaW4gd2hhdCBnZW9ncmFwaHkgdGhlIGNhbGxlZCBudW1i ZXIgaXM/DQo+DQo+U05JUA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+TW9kZXJuIG1haWxpbmcgbGlzdA0KPk1vZGVybkBpZXRmLm9yZzxtYWls dG86TW9kZXJuQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW9kZXJuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5MZWFybiBt b3JlIG9uIGhvdyB0byBzd2l0Y2ggdG8gU3ByaW50IGFuZCBzYXZlIDUwJSBvbiBtb3N0IFZlcml6 b24sIEFUJlQgb3IgVC1Nb2JpbGUgcmF0ZXMuIFNlZSBzcHJpbnQuY29tLzUwb2ZmPGh0dHA6Ly9z cHJpbnQuY29tLzUwb2ZmPiBmb3IgZGV0YWlscy4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPg0KPlRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFy eSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQo cykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBh bGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5Nb2Rlcm4gbWFpbGluZyBsaXN0DQo+TW9kZXJuQGll dGYub3JnPG1haWx0bzpNb2Rlcm5AaWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tb2Rlcm4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KTGVhcm4gbW9yZSBvbiBob3cgdG8gc3dpdGNoIHRvIFNwcmludCBhbmQgc2F2ZSA1MCUgb24g bW9zdCBWZXJpem9uLCBBVCZUIG9yIFQtTW9iaWxlIHJhdGVzLiBTZWUgc3ByaW50LmNvbS81MG9m ZjxodHRwOi8vc3ByaW50LmNvbS81MG9mZj4gZm9yIGRldGFpbHMuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9w cmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNp cGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk1vZGVybiBtYWlsaW5nIGxpc3QNCk1vZGVybkBpZXRm Lm9yZzxtYWlsdG86TW9kZXJuQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tb2Rlcm4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K TGVhcm4gbW9yZSBvbiBob3cgdG8gc3dpdGNoIHRvIFNwcmludCBhbmQgc2F2ZSA1MCUgb24gbW9z dCBWZXJpem9uLCBBVCZUIG9yIFQtTW9iaWxlIHJhdGVzLiBTZWUgc3ByaW50LmNvbS81MG9mZjxo dHRwOi8vc3ByaW50LmNvbS81MG9mZj4gZm9yIGRldGFpbHMuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGll bnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0K --_000_88104851c8c84c30bd4778db8bc66fe8PLSWE13M08adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMDBDQzsNCglmb250LXdlaWdodDpu b3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5UaGFuayB5b3UgRGF2aWQu Jm5ic3A7IEFncmVlIHRoYXQgVG9sbCBGcmVlIGlzIG9uZSBleGFtcGxlIG9mIG1hbnkgY2FsbCBy b3V0aW5nIHJlcXVpcmVtZW50cyB3aXRoIG5lY2Vzc2FyeSBjb25zaWRlcmF0aW9uIGZvciBnZW9n cmFwaHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPlBpZXJjZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLXJpZ2h0OjUuOHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEYXZpZCBHcmVl bmhhdXMgW21haWx0bzpka2dyZWVuaGF1c0B5YWhvby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g SmFudWFyeSAwNCwgMjAxNiAzOjU3IFBNPGJyPg0KPGI+VG86PC9iPiBHb3JtYW4sIFBpZXJjZSBB IFtDVE9dICZsdDtQaWVyY2UuR29ybWFuQHNwcmludC5jb20mZ3Q7OyBSaWNoYXJkIFNob2NrZXkg Jmx0O3JpY2hhcmRAc2hvY2tleS51cyZndDs7IFJpY2hhcmQgSGlsbCAmbHQ7cmhpbGxAaGlsbC1h LmNoJmd0OzsgJ01jR2FycnksIFRvbScgJmx0O1RvbS5NY0dhcnJ5QG5ldXN0YXIuYml6Jmd0Ozsg bW9kZXJuQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTW9kZXJuXSBQcm9ibGVt IHN0YXRlbWVudCBkcmFmdCBwcm9ibGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQ1MTkzODk3ODYxOF8yMzI4MCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5BbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18x Nl8wXzFfMTQ1MTkzODk3ODYxOF8yMzY4MiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDUxOTM4OTc4 NjE4XzIzNjgzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZGluZyB0aGUgaXNzdWUgb2YgZ2VvZ3Jh cGhpYyBvcmlnaW5hdGlvbiwgSSdkIGxpa2UgdG8gYnJpbmcgeW91ciBhdHRlbnRpb24gdG8gYSB3 aGl0ZSBwYXBlciBwcmVwYXJlZCBieSB0aGUgRnV0dXJlIG9mIE51bWJlcmluZyBXb3JraW5nIEdy b3VwIG9mIHRoZSBOQU5DKS4mbmJzcDsgVGhpcyBkb2N1bWVudCB3YXMgdHJhbnNtaXR0ZWQNCiBi eSB0aGUgTkFOQyB0byB0aGUgRkNDLCBieSBtZW1iZXIgYWdyZWVtZW50LCBhdCBhIHJlY2VudCBO QU5DIG1lZXRpbmc7IGl0IGlsbHVzdHJhdGVzIHRoZSBjcml0aWNhbCBpbXBvcnRhbmNlIG9mICZx dW90O2Z1enp5JnF1b3Q7IGdlb2dyYXBoaWMgb3JpZ2luYXRpb24gaW5mb3JtYXRpb24gcmVxdWly ZWQgdG8gcm91dGUgbWFueSB0b2xsIGZyZWUgY2FsbHMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDUxOTM4OTc4NjE4XzIzNjg0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0NTE5Mzg5Nzg2MThfMjM2ODUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+VGhlIGRvY3VtZW50IGNhbiBiZSBmb3VuZCBhdDombmJzcDsmbmJzcDsmbmJzcDsNCjxhIGhy ZWY9Imh0dHA6Ly93d3cubmFuYy1jaGFpci5vcmcvZG9jcy9kb2N1bWVudHMuaHRtbCIgaWQ9Inl1 aV8zXzE2XzBfMV8xNDUxOTM4OTc4NjE4XzIzODQ1Ij4NCmh0dHA6Ly93d3cubmFuYy1jaGFpci5v cmcvZG9jcy9kb2N1bWVudHMuaHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDUxOTM4OTc4NjE4XzI0Mzk2Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNf MTZfMF8xXzE0NTE5Mzg5Nzg2MThfMjQzOTciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0 cDovL3d3dy5uYW5jLWNoYWlyLm9yZy9kb2NzL2Zvbi9Gb05fV2hpdGVfUGFwZXJfR2VvZ3JhcGhp Y19Sb3V0aW5nX1RvbGxfRnJlZV9TZXJ2aWNlc18yMDE0MTAwMS5kb2N4Ij5Gb04gV2hpdGUgUGFw ZXIgb24gR2VvZ3JhcGhpYyBSb3V0aW5nIG9mIFRvbGwgRnJlZSBTZXJ2aWNlczwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDUxOTM4OTc4 NjE4XzI0NDY3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cubmFuYy1j aGFpci5vcmcvZG9jcy9mb24vRm9OX1doaXRlX1BhcGVyX0dlb2dyYXBoaWNfUm91dGluZ19Ub2xs X0ZyZWVfU2VydmljZXNfMjAxNDEwMDEuZG9jeCIgaWQ9Inl1aV8zXzE2XzBfMV8xNDUxOTM4OTc4 NjE4XzI0Mzk5Ij48YnI+DQo8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPk9uIE1vbmRheSwgSmFudWFyeSA0LCAyMDE2IDQ6MzcgUE0sICZxdW90O0dvcm1hbiwg UGllcmNlIEEgW0NUT10mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpQaWVyY2UuR29ybWFuQHNw cmludC5jb20iPlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJpY2hh cmQsPGJyPg0KPGJyPg0KVGhpcyBtYXkgbm90IGJlIGNvbXBsZXRlbHkgYXBwcm9wcmlhdGUgdG8g dGhlIE1PREVSTiBXRyBkaXNjdXNzaW9uLCBidXQganVzdCBhIHF1aWNrIHBvaW50IG9mIGNsYXJp ZmljYXRpb24uPGJyPg0KPGJyPg0KTXkgbm90ZXMgb24gdGhlIE9yZGVyIHRvIFJlZm9ybSBJQ0Mg UmF0ZXMgc2hvdyB0aGF0IHRoZSAmcXVvdDtwcmljZSBjYXAmcXVvdDsgTEVDcyAoYWthIFJCT0Mn cykgYW5kIHRoZSAmcXVvdDtyYXRlIG9mIHJldHVybiZxdW90OyBMRUNzIChha2EgcnVyYWwgTEVD cykgYm90aCBnZXQgdG8gLjAwMDcgKG9uIGRpZmZlcmVudCBzY2hlZHVsZXMgYXMgeW91IG1lbnRp b25lZCksIGJ1dCBteSB3b3JraW5nIGFzc3VtcHRpb24gaGFzIGJlZW4gaXQgbmV2ZXIgZ29lcyB0 byAmcXVvdDt6ZXJvJnF1b3Q7IGFzIHlvdQ0KIHdyb3RlIGJlbG93Ljxicj4NCjxicj4NClRoZXJl IGlzIGEgYmlsbC1hbmQta2VlcCBjb21wb25lbnQuJm5ic3A7IEkndmUgYXNzdW1lZCB0aGF0IGJp bGwtYW5kLWtlZXAgaXMgYmFsYW5jZSBvZiB0cmFmZmljIG9ubHkgYW5kIHRoYXQgYmFsYW5jZSBv ZiB0cmFmZmljIG92ZXJhZ2VzIHdvdWxkIGJlIHBhaWQgdG8gdGhlIHRlcm1pbmF0aW5nIExFQy4m bmJzcDsgaS5lLiwgdGhlcmUgd2lsbCBzdGlsbCBiZSB0cmFuc3BvcnQgYWNjZXNzIGNoYXJnZXMg KGFsYmVpdCBhdCAuMDAwNyBwZXIgbWludXRlKS48YnI+DQo8YnI+DQpUaGlzIGV4YWN0IHVuZGVy c3RhbmRpbmcgaGFzIGJlZW4gYSBiaXQgb2YgYSBwcm9ibGVtIGZvciBtZSB0byBuYWlsIGRvd24u Jm5ic3A7IEVpdGhlciBJIGFzayB0aGUgcXVlc3Rpb24gd3JvbmcsIG9yIGFzayB0aGUgd3Jvbmcg cGVvcGxlLCBidXQgSSdtIG5vdCBjb21mb3J0YWJsZSBJIGtub3cgdGhlIGNvbXBsZXRlIHN0b3J5 LiZuYnNwOyBJdCBjb3VsZCBiZSBJJ20gd3JvbmcsIGFuZCB0aGUgb25seSBhY2Nlc3Mgd2lsbCBi ZSBmYWNpbGl0aWVzIGNoYXJnZXMgYW5kDQogdHJhbnNwb3J0IGNvc3RzIG9mIC4wMDA3ICh0YXJp ZmZzIHRvIGJlIGZpbGVkIHRoaXMgeWVhcikgZG8gaW5kZWVkIGZhbGwgdG8gemVybyAoaW4gMjAx OCBmb3IgcHJpY2UgY2FwIExFQ3MpLiZuYnNwOyBDYW4geW91IGNvbmZpcm0/PGJyPg0KPGJyPg0K UGllcmNlPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpG cm9tOiBSaWNoYXJkIFNob2NrZXkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cmljaGFyZEBzaG9j a2V5LnVzIj5yaWNoYXJkQHNob2NrZXkudXM8L2E+XTxicj4NClNlbnQ6IEphbnVhcnkgMDQsIDIw MTYgMTo0NyBQTTxicj4NClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dICZsdDs8YSBocmVmPSJt YWlsdG86UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tIj5QaWVyY2UuR29ybWFuQHNwcmludC5jb208 L2E+Jmd0OzsgUmljaGFyZCBIaWxsICZsdDs8YSBocmVmPSJtYWlsdG86cmhpbGxAaGlsbC1hLmNo Ij5yaGlsbEBoaWxsLWEuY2g8L2E+Jmd0OzsgJ01jR2FycnksIFRvbScgJmx0OzxhIGhyZWY9Im1h aWx0bzpUb20uTWNHYXJyeUBuZXVzdGFyLmJpeiI+VG9tLk1jR2FycnlAbmV1c3Rhci5iaXo8L2E+ Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2Rlcm5AaWV0Zi5vcmciPm1vZGVybkBpZXRmLm9yZzwv YT48YnI+DQpTdWJqZWN0OiBSZTogW01vZGVybl0gUHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgcHJv YmxlbXM8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAxLzQvMTYs IDExOjM1IEFNLCAmcXVvdDtNb2Rlcm4gb24gYmVoYWxmIG9mIEdvcm1hbiwgUGllcmNlIEEgW0NU T10mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZyI+bW9k ZXJuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOlBp ZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbSI+UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KPGJyPg0KJmd0O0dvb2QgdG8ga25vdy4mbmJzcDsgVGhhbmsgeW91Ljxicj4N CiZndDs8YnI+DQomZ3Q7SnVzdCBiZWNhdXNlIHRoZSB1c2VycyBkb24ndCBrbm93IHdoZXJlIGEg Y2FsbCBvcmlnaW5hdGVkIGFuZCB0ZXJtaW5hdGVkIGRvZXNuJ3QgbWVhbiB0aGUgbmV0d29yayBk b2VzIG5vdCBvciBjYW5ub3Qga25vdy4mbmJzcDsgSSdsbCBzcGVjdWxhdGUgdGhhdCB0aGUgU3dp c3MgcG9ydGFiaWxpdHkgdXNlcyBhIHNpbWlsYXIgbWVjaGFuaXNtIGFzIHVzZWQgaW4gTm9ydGgg QW1lcmljYSBhbmQgdGhlIHBvcnRlZCBudW1iZXIgaXMgYXNzb2NpYXRlZCB3aXRoDQogYSAmcXVv dDtMb2NhbCBSb3V0aW5nIE51bWJlciZxdW90OyB3aGljaCBpbmRleGVzIGJhY2sgdG8gYSBjZW50 cmFsIG9mZmljZSBzd2l0Y2ggd2l0aCBhIHNwZWNpZmljIGdlb2dyYXBoaWMgbG9jYXRpb24uJm5i c3A7IFRoZSBvcmlnaW5hdGluZyBDU1AgcHJlc3VtYWJseSBrbm93cyB3aGVyZSB0aGUgY2FsbCBv cmlnaW5hdGVkLCBhbmQgY2FuIGxvb2sgYXQgdGhlIGdlb2dyYXBoaWMgbG9jYXRpb24gb2YgdGhl IHRlcm1pbmF0aW5nIHN3aXRjaCAobm90IHRoZSBMUk4sIGJ1dA0KIHRoZSBhY3R1YWwgc3dpdGNo IHdoaWNoICZxdW90O293bnMmcXVvdDsgdGhlIExSTikgYW5kIGNoYXJnZSBhY2NvcmRpbmdseS48 YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZSBtb3N0IGN1cnJlbnQgTkFOUCByZWd1bGF0b3J5IGd1aWRl bGluZXMgd2l0aCByZXNwZWN0IHRvIHRoZSBPcmRlciB0byBSZWZvcm0gSW50ZXJDYXJyaWVyIENv bXBlbnNhdGlvbiBSYXRlcyBzdGlsbCBpbmNsdWRlcyBhY2Nlc3MgY2hhcmdlcyBldmVuIGFmdGVy IHRoZXJlIGlzIGJpbGwtYW5kLWtlZXAgKG9uIGJhbGFuY2Ugb2YgdHJhZmZpYz8pLjxicj4NCjxi cj4NCjxicj4NCkl0cyBhIGZ1bmN0aW9uIG9mIHRlcm1pbmF0aW5nIGNhbGwgYWNjZXNzIHJhdGVz LiZuYnNwOyBUaG9zZSBoYXZlIGdvbmUgdG8gLjAwMDUgb3Igc29tZXRoaW5nIGxpa2UgYmVmb3Jl IGl0IGdvZXMgdG8gemVyby4gVGhlIGlzc3VlIGlzIG9uIG9yaWdpbmF0aW9uIGFjY2VzcyBjaGFy Z2VzLiBUaGUgdGhlb3J5IGluIHRoZSBSJmFtcDtPIHdhcyB0aGUgcnVyYWwgY2FycmllcnMgd2Vy ZSBub3QgZ29pbmcgdG8gYmUgYWJsZSB0byBtb2RpZnkgdGhlaXIgYnVzaW5lc3MNCiBtb2RlbHMg ZmFzdCBlbm91Z2ggdG8gYWNjb21tb2RhdGUgYm90aCBzbyBvbiBvcmlnaW5hdGlvbiB0aGUgcmVn aW1lIGlzIHN0aWxsIGluIHBsYWNlIGZvciBub3cuJm5ic3A7IEl0IHRvbyB3aWxsIGdvIGF3YXkg ZXNwZWNpYWxseSBpZiB0aGVyZSBpcyBhIG1vdmUgdG8gTmF0aW9uYWwgR2VvZ3JhcGhpYyBOUCBp biB0aGUgVVMgd2hpY2ggd291bGQgZXNzZW50aWFsbHkgZm9yY2UgdGhlIGlzc3VlIG9uY2UgYW5k IGZvciBhbGwuJm5ic3A7IFRoYXQgQlRXIHdhcyB0aGUNCiBwcmluY2lwYWwgdG9waWMgb2YgZGlz Y3Vzc2lvbiBhdCBvdXIgbGFzdCBOQU5DIG1lZXRpbmcgYXQgdGhlIEZDQy4gSU1ITyBpdHMgY29t aW5nLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7UGllcmNlPGJy Pg0KJmd0Ozxicj4NCiZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDtGcm9t OiBNb2Rlcm4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmci Pm1vZGVybi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFJpY2hhcmQgSGlsbDxi cj4NCiZndDtTZW50OiBKYW51YXJ5IDA0LCAyMDE2IDEwOjI2IEFNPGJyPg0KJmd0O1RvOiBHb3Jt YW4sIFBpZXJjZSBBIFtDVE9dICZsdDs8YSBocmVmPSJtYWlsdG86UGllcmNlLkdvcm1hbkBzcHJp bnQuY29tIj5QaWVyY2UuR29ybWFuQHNwcmludC5jb208L2E+Jmd0OzsgJ01jR2FycnksIFRvbSc8 YnI+DQomZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpUb20uTWNHYXJyeUBuZXVzdGFyLmJpeiI+VG9t Lk1jR2FycnlAbmV1c3Rhci5iaXo8L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOm1vZGVybkBpZXRm Lm9yZyI+DQptb2Rlcm5AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0O1N1YmplY3Q6IFJlOiBbTW9kZXJu XSBQcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBwcm9ibGVtczxicj4NCiZndDs8YnI+DQomZ3Q7UGxl YXNlIHNlZSBlbWJlZGRlZCBjb21tZW50IGJlbG93Ljxicj4NCiZndDs8YnI+DQomZ3Q7QmVzdCw8 YnI+DQomZ3Q7UmljaGFyZDxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IE1vZGVybiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZyI+bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBPbiBCZWhhbGYgT2YgR29ybWFuLDxicj4NCiZndDsmZ3Q7IFBpZXJjZSBBIFtDVE9dPGJyPg0K Jmd0OyZndDsgU2VudDogTW9uZGF5LCBKYW51YXJ5IDQsIDIwMTYgMTc6MjE8YnI+DQomZ3Q7Jmd0 OyBUbzogTWNHYXJyeSwgVG9tOyA8YSBocmVmPSJtYWlsdG86bW9kZXJuQGlldGYub3JnIj5tb2Rl cm5AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgU3ViamVjdDogUmU6IFtNb2Rlcm5dIFByb2Js ZW0gc3RhdGVtZW50IGRyYWZ0IHByb2JsZW1zPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBU aGFua3MgVG9tLiZuYnNwOyBJbmxpbmUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIGFs c28gaGF2ZSBtb3JlIGVkaXRzIGJ1dCBkaWRuJ3Qgd2FudCB0byBzZW5kIHRoZW0gb3V0IHVudGls IEkndmU8YnI+DQomZ3Q7Jmd0OyBjb21wbGV0ZWQgdGhlIHJldmlldyAodGhpcyB3ZWVrPykuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFBpZXJjZSBHb3JtYW48YnI+DQomZ3Q7Jmd0OyBPZmZp Y2U6IDkxMy00MzktNDM2ODxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpwaWVyY2UuZ29y bWFuQHNwcmludC5jb20iPnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbTwvYT48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IE1vZGVybiBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZyI+bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgTWNHYXJyeSw8YnI+DQomZ3Q7Jmd0OyBUb208YnI+DQomZ3Q7Jmd0 OyBTZW50OiBKYW51YXJ5IDA0LCAyMDE2IDk6MTYgQU08YnI+DQomZ3Q7Jmd0OyBUbzogPGEgaHJl Zj0ibWFpbHRvOm1vZGVybkBpZXRmLm9yZyI+bW9kZXJuQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBQcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBwcm9ibGVt czxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGllcmNlLCB0aGFua3MgZm9yIHJldmlld2lu ZyB0aGUgZG9jdW1lbnQgYW5kIHRoZSBmZWVkYmFjay4mbmJzcDsgU2VlIG15PGJyPg0KJmd0OyZn dDsgY29tbWVudHMgaW4gbGluZSBiZWxvdy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9u IDEyLzI4LzE1IDU6NTMgUE0sICZxdW90O0dvcm1hbiwgUGllcmNlIEEgW0NUT10mcXVvdDs8YnI+ DQomZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbSI+ UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDtTdGV2ZSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDtTTklQPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDtXaXRoIHJl c3BlY3QgdG8gZ2VvZ3JhcGhpYyBudW1iZXIgYXNzaWdubWVudCwgdGhlIHJlam9pbmRlciwgJnF1 b3Q7QnV0PGJyPg0KJmd0OyZndDsgJmd0O3RoZSBvdmVyd2hlbG1pbmcgc3VjY2VzcyBvZiBtb2Jp bGUgdGVsZXBob25lcyBoYXMgaW5jcmVhc2luZyBlcm9kZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7dGhl IGNvbm5lY3Rpb24gYmV0d2VlbiBudW1iZXJzIGFuZCByZWdpb25zJnF1b3Q7IGhhcyBwcm9ibGVt cyBhdCBsZWFzdCBpbjxicj4NCiZndDsmZ3Q7ICZndDt0aGUgY29udGV4dCBvZiB0aGUgTm9ydGgg QW1lcmljYW4gbnVtYmVyaW5nIHBsYW4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUb206 IFlvdSdyZSBvdmVyIHRoaW5raW5nIHRoaXMuJm5ic3A7IE1vYmlsZSBoYXMgYWx3YXlzIGVyb2Rl ZCB0aGU8YnI+DQomZ3Q7Jmd0OyBjb25uZWN0aW9uIGJldHdlZW4gbnVtYmVycyBhbmQgcmVnaW9u cyAtIHRoYXQncyB3aGF0IGl0IGRvZXMuJm5ic3A7IFRoaXM8YnI+DQomZ3Q7Jmd0OyBpcyBwb2lu dGluZyBvdXQgdGhhdCBpdCBpcyBub3cgYSBkb21pbmFudCBwb3J0aW9uIG9mIHRoZSBtYXJrZXQu PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBQRy0mZ3Q7Jm5ic3A7IEkgdGhpbmsgeW91J3Jl IHVuZGVydGhpbmtpbmcgdGhpcy4mbmJzcDsgOi0pJm5ic3A7IFRoZSBtYWpvcml0eSBvZiBwaG9u ZTxicj4NCiZndDsmZ3Q7IFBHLSZndDsgY2FsbHMgYXJlICZxdW90O2xvY2FsJnF1b3Q7IGFuZCBj aGFyZ2VkIGFjY29yZGluZ2x5IHBlciByZWd1bGF0b3J5PGJyPg0KJmd0OyZndDsgUEctJmd0OyBy ZXF1aXJlbWVudHMuJm5ic3A7IFRoaXMgaXNuJ3QgY2hhbmdpbmcuPGJyPg0KJmd0Ozxicj4NCiZn dDtJbnRyb2R1Y3Rpb24gb2YgZml4ZWQgbnVtYmVyIHBvcnRhYmlsaXR5IGluIFN3aXR6ZXJsYW5k IHJlc3VsdGVkIGluIHRoZSBlbmQgb2YgZ2VvZ3JhcGhpY2FsIGNoYXJnaW5nLiZuYnNwOyBJbmRl ZWQsIGhvdyBjYW4geW91IGNoYXJnZSBieSBnZW9ncmFwaHkgaWYgdGhlIGNhbGxlciBjYW5ub3Qg a25vdyBpbiB3aGF0IGdlb2dyYXBoeSB0aGUgY2FsbGVkIG51bWJlciBpcz88YnI+DQomZ3Q7PGJy Pg0KJmd0O1NOSVA8YnI+DQomZ3Q7PGJyPg0KJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O01vZGVybiBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7PGEgaHJlZj0ibWFpbHRvOk1vZGVybkBpZXRmLm9yZyI+TW9kZXJuQGlldGYub3JnPC9hPjxi cj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21v ZGVybiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW9kZXJuPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7TGVhcm4gbW9yZSBvbiBob3cgdG8gc3dpdGNoIHRvIFNwcmludCBh bmQgc2F2ZSA1MCUgb24gbW9zdCBWZXJpem9uLCBBVCZhbXA7VCBvciBULU1vYmlsZSByYXRlcy4g U2VlIHNwcmludC5jb20vNTBvZmYmbHQ7PGEgaHJlZj0iaHR0cDovL3NwcmludC5jb20vNTBvZmYi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc3ByaW50LmNvbS81MG9mZjwvYT4mZ3Q7IGZvciBkZXRh aWxzLjxicj4NCiZndDs8YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7PGJyPg0KJmd0O1RoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGll bnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg aWQ9InlxdGZkMjkxNzciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtNb2Rlcm4gbWFpbGluZyBs aXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0bzpNb2Rlcm5AaWV0Zi5vcmciPk1vZGVybkBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tb2Rlcm4iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21vZGVybjwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCkxlYXJuIG1vcmUgb24gaG93IHRvIHN3aXRjaCB0byBTcHJp bnQgYW5kIHNhdmUgNTAlIG9uIG1vc3QgVmVyaXpvbiwgQVQmYW1wO1Qgb3IgVC1Nb2JpbGUgcmF0 ZXMuIFNlZSBzcHJpbnQuY29tLzUwb2ZmJmx0OzxhIGhyZWY9Imh0dHA6Ly9zcHJpbnQuY29tLzUw b2ZmIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NwcmludC5jb20vNTBvZmY8L2E+Jmd0OyBmb3Ig ZGV0YWlscy48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cjxicj4NClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1h dGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1 c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVz IG9mIHRoZSBtZXNzYWdlLjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KTW9kZXJuIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpNb2Rlcm5AaWV0Zi5vcmciPk1vZGVybkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9kZXJuPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJCbGFjayIg c2l6ZT0iMiI+PGI+TGVhcm4gbW9yZSBvbiBob3cgdG8gc3dpdGNoIHRvIFNwcmludCBhbmQgc2F2 ZSA1MCUgb24gbW9zdCBWZXJpem9uLCBBVCZhbXA7VCBvciBULU1vYmlsZSByYXRlcy4gU2VlDQo8 YSBocmVmPSJodHRwOi8vc3ByaW50LmNvbS81MG9mZiI+c3ByaW50LmNvbS81MG9mZjwvYT4gZm9y IGRldGFpbHMuIDxicj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3Jh eSIgc2l6ZT0iMSI+PGJyPg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVu dChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRl IGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuPGJyPg0KPC9mb250PjwvYj48L2ZvbnQ+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_88104851c8c84c30bd4778db8bc66fe8PLSWE13M08adsprintcom_-- From nobody Mon Jan 4 14:47:34 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 DF2341ACC92 for ; Mon, 4 Jan 2016 14:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ld9RdrqcxwL for ; Mon, 4 Jan 2016 14:47:30 -0800 (PST) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 8565D1AC410 for ; Mon, 4 Jan 2016 14:47:30 -0800 (PST) Received: (qmail 5855 invoked by uid 0); 4 Jan 2016 22:47:28 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 4 Jan 2016 22:47:28 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 1yTJ1s00n1MNPNq01yTMrh; Mon, 04 Jan 2016 15:27:27 -0700 X-Authority-Analysis: v=2.1 cv=Zc6OaKlA c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=7aQ_Q-yQQ-AA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=PUKOpctjNGsY9nrIamIA:9 a=XYnOa4Ksg7F8nIfW:21 a=7tZsTboe4IEKXYKT:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=ZznrIXRgSH9Q8slF4m1CCSH2mvLj8DdSdrhhZqREgrY=; b=EJHrJnZnBtZakilCfUKrCgMi5JrfS2K8frIXAGvnERsi/pnBhBBzbbnPHNOvoFz6/z3YXbiWD5o6iuLIQNVwPDFe2cJo8/jaflT1ojwestpEfGTcByphwEnFz+23bnYf; Received: from [100.36.35.60] (port=54788 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aGDax-00042X-Io; Mon, 04 Jan 2016 15:27:19 -0700 User-Agent: Microsoft-MacOutlook/0.0.0.151217 Date: Mon, 04 Jan 2016 17:27:12 -0500 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Richard Hill , "'McGarry, Tom'" , "modern@ietf.org" Message-ID: <3E468FA0-983E-4E76-9261-BC2394631356@shockey.us> Thread-Topic: [Modern] Problem statement draft problems References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <014501d1470c$99da5f60$cd8f1e20$@ch> <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> <9c7c0a78e6c64f5f986c38252bef0f15@PLSWE13M08.ad.sprint.com> In-Reply-To: <9c7c0a78e6c64f5f986c38252bef0f15@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:47:34 -0000 Its appropriate=E2=80=A6 We are actually discussing the technical justification f= or the problem statement in the context of North America.=20 To your point. IMHO it goes to zero sooner rather than later since the cos= t of billing then outweighs the monies collected. The EU still doesn=E2=80=99t get= this. The basic theory behind IP interconnection aka rough symmetry. At th= at point its a bilateral agreement between service providers. Obviously the = issue is with the RLEC's. Termination rates falls to zero in 2018 but the i= ssue of access rates has yet to be resolved.=20 Its a complicated issue to be sure. The Commission has issued endless Furth= er Reconsiderations here. I=E2=80=99d go into gory details but that to consultants= like me ..that=E2=80=99s billable hours.=20 However the trend is unmistakable. The reason it gets interesting is this i= ssue of NG-NP. I=E2=80=99ve seen the briefs here in the US and its very persuasiv= e. The smaller wireless carriers have successfully argued that they are at a= competitive disadvantage since they cannot port in numbers out of LATA from= the national carriers. National carriers like Sprint ATT VZ and T-MO just = enable roaming and simply change the billing address.=20 The smaller carriers went to Congress, Congress sent nasty grams to Chairma= n Wheeler, Tom agreed =E2=80=A6and the ball started rolling. I=E2=80=99ve been around Am= erica=E2=80=99s swampland long enough to know what is coming. The Chairman will p= reach =E2=80=9Ccompetition competition completion=E2=80=9D at every bully pulpit he can = find. I=E2=80=99ll bet serious money there is a NPRM on this this summer. Not to m= ention that 10% of the US population moves every year. That is Census data.= =20 Pierce when you see a letter from the House Commerce Committee that has Gre= g Waldren and Anna Eshoo signature on the same page I smell =E2=80=9Cconsensus=E2=80=9D.= =20 The single NPA states will whine but I was invited to NARUC last month in A= ustin to muse on this subject and I did not sense a lot of resistance.=20 So what does this mean for Modern. Well if you assume NG-NP is coming then= that means you have to implement national 10 digit dialing across the board= landline as well as wireless. Ok then that means you get to open up the D = digit in the dialing plan. The second N in NPA-NXX which can never be 0 or = 1. Open up the D digit you instantly increase the size of the NANP by 20% an= d all of the NANP numbering exhaust issues go away until hell freezes over o= r we are all dead and you have to reform the entire access regime at the sam= e time. Oh and BTW you really don=E2=80=99t need single number allocation techno= logy, at least in North America because the rationale for the problem statem= ent, at least in North America is moot, unless there is some other private a= genda the proponents of this problem statement have. :-)=20 =20 On 1/4/16, 4:37 PM, "Modern on behalf of Gorman, Pierce A [CTO]" wrote: >Richard, > >This may not be completely appropriate to the MODERN WG discussion, but ju= st a quick point of clarification. > >My notes on the Order to Reform ICC Rates show that the "price cap" LECs (= aka RBOC's) and the "rate of return" LECs (aka rural LECs) both get to .0007= (on different schedules as you mentioned), but my working assumption has be= en it never goes to "zero" as you wrote below. > >There is a bill-and-keep component. I've assumed that bill-and-keep is ba= lance of traffic only and that balance of traffic overages would be paid to = the terminating LEC. i.e., there will still be transport access charges (al= beit at .0007 per minute). > >This exact understanding has been a bit of a problem for me to nail down. = Either I ask the question wrong, or ask the wrong people, but I'm not comfo= rtable I know the complete story. It could be I'm wrong, and the only acces= s will be facilities charges and transport costs of .0007 (tariffs to be fil= ed this year) do indeed fall to zero (in 2018 for price cap LECs). Can you = confirm? > >Pierce > > >-----Original Message----- >From: Richard Shockey [mailto:richard@shockey.us] >Sent: January 04, 2016 1:47 PM >To: Gorman, Pierce A [CTO] ; Richard Hill ; 'McGarry, Tom' ; modern@ietf.org >Subject: Re: [Modern] Problem statement draft problems > > > > > > >On 1/4/16, 11:35 AM, "Modern on behalf of Gorman, Pierce A [CTO]" wrote: > >>Good to know. Thank you. >> >>Just because the users don't know where a call originated and terminated = doesn't mean the network does not or cannot know. I'll speculate that the S= wiss portability uses a similar mechanism as used in North America and the p= orted number is associated with a "Local Routing Number" which indexes back = to a central office switch with a specific geographic location. The origina= ting CSP presumably knows where the call originated, and can look at the geo= graphic location of the terminating switch (not the LRN, but the actual swit= ch which "owns" the LRN) and charge accordingly. >> >>The most current NANP regulatory guidelines with respect to the Order to = Reform InterCarrier Compensation Rates still includes access charges even af= ter there is bill-and-keep (on balance of traffic?). > > >Its a function of terminating call access rates. Those have gone to .0005= or something like before it goes to zero. The issue is on origination acces= s charges. The theory in the R&O was the rural carriers were not going to be= able to modify their business models fast enough to accommodate both so on = origination the regime is still in place for now. It too will go away espec= ially if there is a move to National Geographic NP in the US which would ess= entially force the issue once and for all. That BTW was the principal topic= of discussion at our last NANC meeting at the FCC. IMHO its coming. > > > > >> >>Pierce >> >>-----Original Message----- >>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill >>Sent: January 04, 2016 10:26 AM >>To: Gorman, Pierce A [CTO] ; 'McGarry, Tom' >>; modern@ietf.org >>Subject: Re: [Modern] Problem statement draft problems >> >>Please see embedded comment below. >> >>Best, >>Richard >> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, >>> Pierce A [CTO] >>> Sent: Monday, January 4, 2016 17:21 >>> To: McGarry, Tom; modern@ietf.org >>> Subject: Re: [Modern] Problem statement draft problems >>> >>> Thanks Tom. Inline. >>> >>> I also have more edits but didn't want to send them out until I've >>> completed the review (this week?). >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Office: 913-439-4368 >>> pierce.gorman@sprint.com >>> >>> >>> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, >>> Tom >>> Sent: January 04, 2016 9:16 AM >>> To: modern@ietf.org >>> Subject: Re: [Modern] Problem statement draft problems >>> >>> Pierce, thanks for reviewing the document and the feedback. See my >>> comments in line below. >>> >>> On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" >>> >>> wrote: >>> >>> >Steve, >>> > >> >>SNIP >> >>> >With respect to geographic number assignment, the rejoinder, "But >>> >the overwhelming success of mobile telephones has increasing eroded >>> >the connection between numbers and regions" has problems at least in >>> >the context of the North American numbering plan. >>> >>> Tom: You're over thinking this. Mobile has always eroded the >>> connection between numbers and regions - that's what it does. This >>> is pointing out that it is now a dominant portion of the market. >>> >>> PG-> I think you're underthinking this. :-) The majority of phone >>> PG-> calls are "local" and charged accordingly per regulatory >>> PG-> requirements. This isn't changing. >> >>Introduction of fixed number portability in Switzerland resulted in the e= nd of geographical charging. Indeed, how can you charge by geography if the= caller cannot know in what geography the called number is? >> >>SNIP >> >>_______________________________________________ >>Modern mailing list >>Modern@ietf.org >>https://www.ietf.org/mailman/listinfo/modern >> >>________________________________ >>Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T = or T-Mobile rates. See sprint.com/50off for details= . >> >>________________________________ >> >>This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are not= the intended recipient, please contact the sender and delete all copies of = the message. >> >>_______________________________________________ >>Modern mailing list >>Modern@ietf.org >>https://www.ietf.org/mailman/listinfo/modern > > >________________________________ >Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T o= r T-Mobile rates. See sprint.com/50off for details. > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the so= le use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of t= he message. >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Tue Jan 5 02:22:20 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 E51071B2A79 for ; Tue, 5 Jan 2016 02:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SREgbql0tJNM for ; Tue, 5 Jan 2016 02:22:14 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4E61B2A7D for ; Tue, 5 Jan 2016 02:22:14 -0800 (PST) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u05AMBDK008538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 5 Jan 2016 11:22:11 +0100 Received: from RHillNew (adsl-178-38-58-89.adslplus.ch [178.38.58.89]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u05AMAgv022951; Tue, 5 Jan 2016 11:22:11 +0100 From: "Richard Hill" To: "'Eric Burger'" , References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <014501d1470c$99da5f60$cd8f1e20$@ch> <5fc178a0f1a84e8ea9634feda77770af@PLSWE13M08.ad.sprint.com> <48D3ACF0-B3A8-45F8-A9EF-E104D7C94F3A@standardstrack.com> In-Reply-To: <48D3ACF0-B3A8-45F8-A9EF-E104D7C94F3A@standardstrack.com> Date: Tue, 5 Jan 2016 11:22:13 +0100 Message-ID: <004a01d147a2$f1b85ac0$d5291040$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdFHLFWOmwuaofE0T/uvgHczkDMpZgAbt7Cg Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 10:22:18 -0000 > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Monday, January 4, 2016 21:13 > To: modern@ietf.org > Subject: Re: [Modern] Problem statement draft problems >=20 > Given the population of Switzerland is half a million fewer people = than > the population of New York City, the Swiss experience might be > informative for Tom=E2=80=99s sister, who moved around in Manhattan, = but may > not be informative for a larger country such as Germany, France, the > UK, Russia, or the U.S. I used Switzerland as an example merely because that's where I live. = Geographic number portability was actually implemented in other European = countries before it was implemented in Switzerland, see for example: https://en.m.wikipedia.org/wiki/Local_number_portability#Europe=20 The Wikipedia article cites an EU Directive. That directive is at: http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=3DCELEX:32002L0022=20 As you will see from its article 30, that Directive only imposes = provider portability for geographic numbers. And indeed, as far as I can = tell, most countries seem to have implemented only provider portability, = not full geographic portability. One thing that I noticed when looking at individual country numbering = plans is that they all seem to take the view that numbers are assigned = to operators, not to end-users, even if end-users have specific rights, = such as portability. Regarding the US (and the NANP in general), there is of course a big = difference with respect to most of the rest of the world. In most of the = rest of the world, mobile is caller-pays, and separate "area codes" are = used for mobile, so that the caller knows that he or she will be paying = more for the call. So there is no portability between fixed and mobile = numbers. In the NANP, mobile is receiver-pays and there is no = distinction between mobile numbers and fixed numbers, so there could be = portability between fixed and mobile numbers. Best, Richard >=20 > > On Jan 4, 2016, at 10:35 AM, Gorman, Pierce A [CTO] > wrote: > > > > Just because the users don't know where a call originated and > terminated doesn't mean the network does not or cannot know. I'll > speculate that the Swiss portability uses a similar mechanism as used > in North America and the ported number is associated with a "Local > Routing Number" which indexes back to a central office switch with a > specific geographic location. The originating CSP presumably knows > where the call originated, and can look at the geographic location of > the terminating switch (not the LRN, but the actual switch which = "owns" > the LRN) and charge accordingly. > > > > The most current NANP regulatory guidelines with respect to the = Order > to Reform InterCarrier Compensation Rates still includes access = charges > even after there is bill-and-keep (on balance of traffic?). >=20 >=20 > > On Jan 4, 2016, at 9:16 AM, McGarry, Tom > wrote: > > > > Tom: A few years ago my sister moved from E. 62nd St to E. 85th St = in > NYC. > > Her service provider would not let her keep her number. You and I > > know that is because she moved from one CO serving area to another > and > > the company didn't want to go through the process of porting her > > number between their switches. While I would think this is not > > common, it's not rare either. Service providers build rules into > > their systems and processes that account for things like rate > centers, > > wire center boundaries, LATAs, consumer addresses, etc. that seem > > logical to them, but may not to a consumer. > > From nobody Tue Jan 5 13:29:51 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 C71391A92AE for ; Tue, 5 Jan 2016 13:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.865 X-Spam-Level: X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO4BjZFq2LcU for ; Tue, 5 Jan 2016 13:29:49 -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 9CC291A9252 for ; Tue, 5 Jan 2016 13:29:49 -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 u05LO2Ek029652 for ; Tue, 5 Jan 2016 16:29:49 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 206bhtn1nd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 05 Jan 2016 16:29:49 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.121]) with mapi id 14.03.0158.001; Tue, 5 Jan 2016 16:29:47 -0500 From: "McGarry, Tom" To: Modern List Thread-Topic: MODERN Interim Meeting Thread-Index: AQHRSAAy8r+P0LInaUCu1ptb2eXiZQ== Date: Tue, 5 Jan 2016 21:29:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.82] Content-Type: multipart/alternative; boundary="_000_D2B18D213356Btommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601050357 Archived-At: Subject: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 21:29:51 -0000 --_000_D2B18D213356Btommcgarryneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in l= ate February to be held in the Washington, DC area. Please let us know wha= t dates work best for you. http://doodle.com/poll/5t5p98x5nnntmmcd Thanks, Tom --_000_D2B18D213356Btommcgarryneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <8E533E14E30E204C9A541DC5F901DA38@neustar.biz> Content-Transfer-Encoding: quoted-printable
Due to the length of time between the last IETF and the next, the chai= rs and AD believe we should have an interim meeting.  We're proposing = dates in late February to be held in the Washington, DC area.  Please = let us know what dates work best for you.  


Thanks,
Tom
--_000_D2B18D213356Btommcgarryneustarbiz_-- From nobody Tue Jan 5 13:31:31 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 D474F1A92AE for ; Tue, 5 Jan 2016 13:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 pIVGgctFz14X for ; Tue, 5 Jan 2016 13:31:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B1C1A9252 for ; Tue, 5 Jan 2016 13:31:20 -0800 (PST) Received: from BY2FFO11FD055.protection.gbl (10.1.14.30) by BY2FFO11HUB009.protection.gbl (10.1.14.165) with Microsoft SMTP Server (TLS) id 15.1.355.15; Tue, 5 Jan 2016 21:31: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 BY2FFO11FD055.mail.protection.outlook.com (10.1.15.192) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Tue, 5 Jan 2016 21:31: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 u05J64Te018718; Tue, 5 Jan 2016 15:31:00 -0600 Received: from plswe13m02.ad.sprint.com (plswe13m02.corp.sprint.com [144.229.214.21]) by plsapdm1.corp.sprint.com with ESMTP id 206d2ggmtw-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Jan 2016 15:31:00 -0600 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 5 Jan 2016 15:30:59 -0600 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; Tue, 5 Jan 2016 15:30:59 -0600 From: "Holmes, David W [CTO]" To: "McGarry, Tom" , Modern List Thread-Topic: MODERN Interim Meeting Thread-Index: AQHRSAAy8r+P0LInaUCu1ptb2eXiZZ7tcJ7w Date: Tue, 5 Jan 2016 21:30:58 +0000 Message-ID: <11a46fec9e7945c087809c036785deb4@PLSWE13M01.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.96] Content-Type: multipart/related; boundary="_004_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD055; 1:vc8YLs70F2PbKpqaU1mGG5oEgv6yvfup36STS3zwC5UDRNmrQt+dLqbcp0A7QslUYNFXvlAgirIw01csG1ovzLaW7DH66sL/Fi29W+7GanOr5UF0Ehb1LLOSeZZQTEG1dfaM2WNmz7VZ1mGEPy3bGk690RXL1yi16KVrnVuuu1Zop9xzFOMLWhJzJcz7pZUKWu9QfR4ObSgAH+olHmx4Mnokydu8EE+XVyGBb4J+7nCrku3CbYVg2wD6uqZjrxSNnaV4J3vj8222kt2LyaJ6PbM1lGisowFmVWB6p/fJupVkOng32oxgWBRW3onH7ffEw867KDt/j/JLMBou9IgBSQ9Ltf236rWSaz34rntP0UfnQROG8Mii93TpHUhF8376 X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(199003)(164054003)(189002)(377454003)(5001960100002)(97736004)(790700001)(300700001)(54356999)(5003600100002)(16236675004)(19300405004)(1220700001)(5001770100001)(18206015028)(108616004)(5250100002)(15395725005)(19580395003)(107886002)(189998001)(24736003)(81156007)(5004730100002)(99936001)(76176999)(102836003)(17760045003)(11100500001)(50986999)(1096002)(19580405001)(6806005)(586003)(86362001)(3846002)(260700001)(6116002)(92566002)(19627595001)(19617315012)(67866002)(33646002)(2950100001)(106116001)(19625215002)(106466001)(87936001)(84326002)(2900100001)(5008740100001)(15975445007)(512954002)(66926002)(30436002)(1720100001)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB009; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB009; 2:ls63zgznLzCCKIU0jadpBlA0RBd5fsOcNaxJZfgaINkFj8d/Tgqh9zhHqLdYDZsD4QHw+ZvbwC8oCtAhVJz+MW3mv3jBT3vOjedAvA3yGcEEQ7BHpZconfHSFdxVLEYdE6P3vI2EtDg4a4OEk51b7Q==; 3:fXftyG4tk9MOLe4r/cNNLzOZ+bIdC7o0yZH4LZUSj3l/e+BTMF/Xsnat2Zj8pGc8D07yisK4We972LcvK/YwTJPuFngr6A/s8k7tmscJP19nCZ3gtBX85zz857nIbjF/k1anqqZNnY+gcyTVT8VKa0k9Psu+SmZnBd7wVVaYDfoGqDBO7fZLgmqaoYRQ5tBjm40g6dl1BoZq06Jcm7YldbBCIxvUEV6+wVTb83UxBlnYBkFDFDvTK8R9pV3+dyL5Xkd5x7MVBoMbnVvshT7YaA==; 25:Ao+VhdVnNMKq3tbBbgLFx0gP+R4n9XZEWyZRARoO1WOz1C4mu3u1RL8giFcM1b4+11qfXMuADarknohBwkEVKY6V5hFP8qp4oQVJD8kuZOEu18/yMKGMFNXk1DfqRCM14KSIAjYDKhm7ZX4PyMS1gnWWEcjU2LSHWBZKR+eT891cQbLGk24pYaUl+HswLlhqoPfqQ2rfjQ3szE/HPyWRjADBK1LAg+PSyKjthsKbppVsLT456L5xfqet3jdPJQYy8DIP2nbtCQazjmXLb0AD6w== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB009; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB009; 20:Et8TxruGQa75j0nh/Ik9Btw8KwGxDzPnITjrBK1OioCzhWvQ8uG6uUEfHf5OtBJS2aq0bwulsAsCbYbHuJ+4tCwYJIIHbp+cRYT0Ffrk6dvyHG6vx/cQ1kwkK4mLfChox5A2jJ5N/ofR/pU+WrcLrrIxwYrIM1+jV+cqo9ah3cArslqIR74htDpg6M2Xfig7wnh86+VQZA1UCqe9iSJeas9V8brkPlqgO+jHZqNQA6f2XSlUeAkYlg3f+r3A+vi9; 4:7QRiZz/EHw6h+PttntLu1d6odts49w5XaDBYWU9uYKXMMv2WgmL8DbZ2lejl9oID2DVJtGRJSD9gThflYitNpFFAfoHORSs4XesCS/oHcBc4Tl47LzK07oWp20Kc1+kv3PZK9ZotJOx1oQmROAWhqi1QVOAPIbnDjpOZLTYeGmHCFZCWrRabtbYCxlk/yJ/m7ZNolCNxl28g+jFf7KuIYTReWVpI1VyrWs8FKkyRXGAtSs3nrN5/928U4AR7GCC2SHfBh4fvRLrO3ICetPxLsw0Ye37fQMeKWJ5NrWPvzSaTkAurf2RKiErqlVZ1hPeDPi0Y7M095+Ve/rRzKC1PvJ7+9kx75/0xHKyjwxU3YR+UB6SoStsE9GlN/z8kRWGwZ8NujYBlk9MJ5GUx2hUKIi1F1EgR70rZlOcFddL+GFh4sWfTG1I8NiCMp+z1HXp5sC1izTqi7ugnaarzOoRdhQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102615235)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:BY2FFO11HUB009; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB009; X-Forefront-PRVS: 0812095267 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB009; 23:/t1kKPZuF3Oj4c4BwqeiSQCzrl00btbdNgT4Tlbe?= =?us-ascii?Q?tAd+jLK8R9Z2zmaiOfnEI7v0i1g1ZiW2/bFNiNmYPSwKF2xCC2X5Fbk6F48m?= =?us-ascii?Q?MwtwxRT9HDfrrcbtNMWrp5E1sGdIsan6GecmJT0eAlDEvnFmLp1hnkVEQhG+?= =?us-ascii?Q?X78/s/lxc3r/YqXywE8qpnC5Fc2HnBW2RsvFtFMZgsnZe/wpu41C1X2p8VuJ?= =?us-ascii?Q?Kvo0y3YgXLNml2bekzHjAUZlLDtoXTk7y8Jm00KbZ2DmlXABE/KCXBysDj/W?= =?us-ascii?Q?K0izSoLVRkW/oWVFPWAz7Io6SVrGyaSzn2zBpO9PNw7jMqSssSv987wu52HY?= =?us-ascii?Q?W6Pnxst7D+4GomDF2II24y0fDxo4ooJkEwpJN6XcdTbPOJB+JQu5fNWL2xJF?= =?us-ascii?Q?E8GoNxXschugs23rds/qkRZSAh7RnDP8Cl8Y8rIHOJ60jfkIwkToFLHWfSp3?= =?us-ascii?Q?gmi1RxBnEH9Grse+5eGoh4CfFXLC3Dv/j5XInOZyrx8fP1mGBUZIFXl7CxOZ?= =?us-ascii?Q?LiZHjdMd/q8dfBdRZWoZws7/iAWw2oGRnM8UcEav4CcyhEKhQKyXjvcenapJ?= =?us-ascii?Q?FWR7vAL8KrPxW1AaAlvw6tNUsjkZw3xZcFmhwjWwk0VbdGgcLthNRw9a+jVa?= =?us-ascii?Q?oVet9bRGY1eUtW/hS6EFjxQXmi+klhj8x722zru44Co4ZHMxoEGTh3BYTsbW?= =?us-ascii?Q?p6u4iJN3AW86+P8Su/UCofo7lK666iKAszvypsi+9TqJQ8dQF17BxcrLjK/H?= =?us-ascii?Q?Apg8mJ2nLECHshPFYWw42bl1III5Ib/XDFEpa6ikOQEVFehYj12S/K1UjxGX?= =?us-ascii?Q?zBspZ6rg4FTzCi/jo4SptLzkfWB8/ziArOqmmUi4jeXqZuluPak9FwVuIFVo?= =?us-ascii?Q?OzrmJ3TkR0dvzOEbY5k8fa7t6Ae5R8t2Nbwt7Q63jI6LR9VpP2pjjv4uFM4D?= =?us-ascii?Q?MNGcjmUOgLJ//XqlTPTH2cnbDKwk1M7fWExAc03Le4YHdqZV5XgjHYJRg77C?= =?us-ascii?Q?O47D7U7V2J+bd94+LrrOigQylsFrUJOofIbwtXoINveMHAHFtjOuK/F2RPlS?= =?us-ascii?Q?lqqMIeXc2UIsEUI0quAEg6lhUVJuu/D9meI7VXDJtdrP5iOwgHBm1Hxpz+lj?= =?us-ascii?Q?mw7G8SWeYNXrJUS6/uCB5zeXYKqK1ERpsNbW0y0KlIy8Pe8oNdx5/9SwmYSM?= =?us-ascii?Q?yFwTw9lK2UYlsnoN+Q3G9oqbK4LAowueJEseEhRYi6/JdrAHmiFUCyIHjBD+?= =?us-ascii?Q?VBjfwg557nQ+Nudc8y8dd6VmB4JWESdFwiSU10rpePzSAGZ4Sj2hSJxE4aWf?= =?us-ascii?Q?8YXQDbfmKdhLWKtTqdG/85oej++kF7Ie9+XmtLFoQdiHtxllAIOcjDGkY05S?= =?us-ascii?Q?4YSTHzduJXpMvCs584t2EoRcOeDBrEtTAHy0OrU+O+q0S9uuv5i1bAQSC/A2?= =?us-ascii?Q?/yV0ScB18qcXJ0PBJKfo+lB6eTK1Kx4KPm+2ksUbv1b+DBx/RqULhif5GQfI?= =?us-ascii?Q?sXSgEkoonZFDucK9J3bcuXp6EyvbtM89B3SypZqWzcWvBUQiVbUFmz7DHhUX?= =?us-ascii?Q?teN35XoG2t/rgFQESw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB009; 5:YuppyZ1N58PytRuwe8E7bs6sW8z9edi0kytkY4YGOedmyT+Sg/fzoAnJVVuU2zN8vPOnX0pdYRrwlsiFqAghdZD46wTVkl08FQdXg5Vq1AOI5FaZG/Z2RIAXBTOelxo+Zrghyo5Djfx67ufvZ2TaNw==; 24:Ca1EW1rlzdJBUG7Z88LejSh6O/8KjVJNzAJrbK1a6/DPue9fg32o+MaEUQJDhx2KmDe4di/nrsGF8Ol9dm0sYZXseVBQY+NGhBk440UYPww= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2016 21:31:01.1999 (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: BY2FFO11HUB009 Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 21:31:30 -0000 --_004_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_ Content-Type: multipart/alternative; boundary="_000_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_" --_000_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will remote access be provided? Thanks. David Holmes Standards +1 425 256 7082 david.holmes@sprint.com [Untitled] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: Tuesday, January 05, 2016 1:30 PM To: Modern List Subject: [Modern] MODERN Interim Meeting Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in l= ate February to be held in the Washington, DC area. Please let us know wha= t dates work best for you. http://doodle.com/poll/5t5p98x5nnntmmcd Thanks, Tom ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ 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_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will remote access be provided? = Thanks.

 

David H= olmes

Standards

+1 425 = 256 7082

david.holme= s@sprint.com

3D"Untitled"

 

 

 

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of McGarry, Tom
Sent: Tuesday, January 05, 2016 1:30 PM
To: Modern List <modern@ietf.org>
Subject: [Modern] MODERN Interim Meeting

 

Due to the length of time between the l= ast IETF and the next, the chairs and AD believe we should have an interim = meeting.  We're proposing dates in late February to be held in the Washington, DC area.  Please let us know what dates= work best for you.  

 

 

Thanks,

Tom


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_-- --_004_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4405; creation-date="Tue, 05 Jan 2016 21:30:58 GMT"; modification-date="Tue, 05 Jan 2016 21:30:58 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAVIAAAA0CAIAAABXbSdLAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAABDKSURBVHhe7Z0JdFRVmscfSYAsiGkQkC3QyCqo iEGWUfY5YrOMhtUmOCIwyqqAKDioQMJE2gFi1G4CQoOKrAEO+5o9VdlIwhLCFiAxSyVVqapX+6u3 3Pm/ukVN2lYbxGNS59zfuafOd79738t7OfX/vu/eV6lwhMFgND4k+x3Zes3b+a1hsmcwGiOyrIh3 NpC7a7393xQmewajMSLKxGEzCAUjSEGk1/XbwWTPYDRGZEmyOgnP26WcjuTKWPSpX5Hd1HgYmOwZ jEaKJIq8ndRVXSYZHLn+JlE8Tv6KVLZZUTydXwuTPYPRSIGyBUGosxHrtY9IOkf0SXBKkkvQPCmX zH8Y3TPZMxiNF4XIDpegN7qcV6eRTI649AIhjjuJyilOKt92b84Dw2TPYDReUMzLsmyxK3q9Qcrv SEpGuRXC62+SNE5MayNaSzFHFm2K7Q6df58w2TMYjR2324VS31z6LcnmZP4Y7yKitqtynhMq1LJf dNSImX2VumQ6+X5gsmcwGjvI+W63usi3X19KLj3hUIjj2kqSwdm0AzEq2HRCWrh4mpPLv6Lz/yVM 9gyGHwDlO1ySodYsFPaTarfzujSi4YT0cDdqAbtOTG8npXJSelvFcV/VPpM9g+EfyIpksRNT+XGl pL/VXCnlh0kazmqVJadOyWhDMoKk85x0O47u8P3yPh+TPYPhH6ilviibrMR2fZWg+04o+RPJ4mym SoEvVrJbEk1TJZUTLs+RCZGw2r/wqmIt9h75TzDZMxj+g0LsTslosjtvxQmlc0m2R/Y1h+XcJiQn UMnkHFcWo+x3Xo8Vz3Biaku58rufTPtM9gyGPyFKEm8nZl2J62o0ucDxtSVu3XfKBY7kByhazlK+ 1+60Cxl/VNIDpRROTA5UbDe9R9aDI64q1lhjreFaBZEdXjneB4qsiKKAUt/ywxHI3lSRKVRsIAUc KeSk3Ed4Y6X12v+oH+zJai5nhEqnOaHygHoUPfgeHDnNGmusNVw7yRHd11453jcugfCGu1Jec9Od 48KtKeSiKntn8asGXZWobUFyOZLTnGiC3Oc4q/GC017n+mE/sauf7aEgKoSyxhprDdRCSEYToj/o leN9oyjE6iBCfk/T7T3ijf9QZX+RM92MN11dixKA5AeS3KZY6lsvzTHYSHXWXDG1taztRaxX6eFM 9qyx1nAtM8T3NzYPBIp2l0wcRS877/yveLEnpC5e7mO4+jfpYktyiSNFASSfsxWNqKiorkqdQrJD lAxOTOXEc83kajXEcCQjgDXWWGug1oSkQfb7qJjvH8heJMRyK9F5c51c2IXkcebLi21FY8llziN7 TilqXVZ6s1ozW8kNJlqOaIKVzFA5lZMyWim268j2j7LGGmsN1FqSzDBieOAiH8iQfdkRV/7LJLeZ VBBhLFioFASr1X4RJxVHlJccrMmKUoqC1Zo/rynJaUa0UH5zco6Tq79jD/AYDL8ECd9qcznz/51o OGPeLDEvAjlfrfYL21cUJFRpZpBiNQSQwgBSgJq/KckNIFmcO+9ph7WWyZ7B8EsUhbgIcWe2d2j7 23NGkhyO5HJifrsfCtfXZY+lm3xqwa/m/wBPzuecV2foa8t4m8Jkz2D4K4IgSKkh1uzxijYMOd+V 3b48J4bPG6s+xofOkecvNaFLffniH/iyr6rriMHosjscTPYMhl+CIl/Wn7On9xE13UgG58zqWp71 vj1vDMnmSE4gyQsiF9T9fDThxoTa2rs1dcRo5B0OhyhKTPYMhl8C2Tuvb3JndSWZnDWte6VmuVvb Hat3ommmflYnO4BoObGop/mHQ1Umoje5rLzF7XbT795ksmcw/BJZJs7CGSSNM6YNqM2cpWR3UZ8I ZoWQzObqN+2mcdYbMXrdXZ1BrjMa7XYbkrwnVqgw2TMY/gfkK5QsVZK5mpTR5uxoRRMmpwepmk9v QtI594WRhuriGjOpM9osVqsoST/6fm0mewbD/xCrDrjOBevTx9uyhpDMYDmjqQLBp3CSpgN/e4eu jtQaRZ43OZwuWf5HxXtgsmcw/AzFesWW9pwhbZxTO1DJaCKlBZBkTs5oZbu6prbmbo2JmMx2m9Xm SfI/oXnAZM9g+BOS7aY5a5IhbbyU2UlM5aRkTknhnBf/U19bAcHrTXarxeoWBQj+5zQPmOwZDL8B Bbu5eAOf/gJJDZLPcVJKiLNoprEiV2cmBqOT5y1Oh0OSvP8t7xdgsmcw/AOXW+AvxzlTuiqnOTk5 yFk401h2BoKvMYkms9nudIii+PMJ/h9gsmcwGjvQssNSxWf/WTrJyac4IW+8obqwps5da3CaeYvn Ezii+mHd+4bJnsFo1EiiZLkSYz8RJiaHO0s+NBqqdVZiMIsQvN3uECXZO+9BYLJnMBopSN/2Wq09 a6JbE+ku/Yut7q7BQvRGp8lkttvtbjdKekx5gCTvg8mewWiMQNGW4jh30dtKXbrdLZhs6i69yczf 27T7NUneh1f2u3fvPnnyZHV19fr16xFCZFneu3dvXFzcwYMH6z8GqKysjImJWb16dVVVldf10CBu ffPNNxs3bty0aRNewWeffXb79m3vcMNx7NixgICA7du3e/sMxu+ILNQptlI3IRYXMZt4C29xOl2S JP6a5P5PeGXfvXv3NWvWQH4cp3qcTme/fv1gg1u3btE5IDo6mjpTUlK8roemoqKiS5cu9LQ+Dh06 5B1uOBD4cCXr1q3z9hmM3xFZJoKoWO0Om1rPu5HhZSTgB9m3+wU4o9GYmJgYFhY2a9asqVOnNm/e fNeuXRiIjIykCtyzZw+dCqgHZGZmel2edH3lyhVvhxBcHzzezj3g8T1OFATh2rVr1AYoMbp16xYY GJicnFxWVlZSUlJcXGyz2bzDhFy+fNlkMnk7HnAGatTU1FgsFl+Xou5q3gO/L4fD+yXkLpcLp4KH dgFs1DUwEOYMBgN1wsY1wDh69CjuFKUH9TMYvyfQi/rn9FDNbyT1+nCXLl2C5vH+fuyxxzyK5oYP H46BAQMGhIaGtmzZ8pFHHqFTaS3QqVMnvFLZ19XVjRo1ynOQyocffggn6nPEDt9RoHPnzugiqyPE REVF0cmon7/44guM6nQ6yD44OBgGne8DkmvSpAmd37dv35s31f/vUVRUhO6ECROmTZsG46OPPsLr 3Llz6SG9evXCT6dhCCsXDMXHx2OdMmnSJNiUefPm0ZULbrxnz570DDt27IBn8eLFdA5+Gxs2bIDB ZM9oEPAWpe9S4EZi+1fiVx/j1Utpv4xa0qempuL9jSQJDaPUhwcx5sknn3z22WfffPNNDCFJwjlk yBDoE0UvPFqtFp5hw4bBXr58+ZEjR9544w3YkA38EydO9B1VXl4Oe/r06bB79+4NG6v3/Px8eGAj fPA8j9M2a9YMl4HJKAQQTTB527ZtmPDcc88lJSVBuigHHn/8cdwbagH4AaLJBx98gMzcoUOHdu3a 4RBkbDqE+hxdxALYqCagcxjLli07ceLE2LFjYX///feY0KJFC9ht2rRBBMGPTkhIQHfcuHH79u3b tGkTbMBkz2hArFbrX7/8asSLL742eQrVxc8xKHLg119v9XbqcebU6YSEz/W1tVs2b/a6IHukxCee eALv71deeQXZr23btgcPqt/j2adPn/79+586dQpDK1asqKqqgvHll1/GxsbCKCgoOHPmDIwZM2bQ E+H6kGnhgY1pMDATNrIo7C1btiCswEBq9UxX6/Pw8HCEEpTZPXr0wFDTpk2DgoJgQMyYACVDkFev er/Q/7333sMQlImFAIyuXbv6VhZjxoyBB6XE+fPnYYC4uDj4EbkQGmDk5uamp6d75pKzZ89iAr0M XABsxCzYWFbgftFFVeKZSFCMoMtkz2gokO0XLlgY0rRZbEzMrNdfr62p8Q78FMveXarVarydeiyc N3/4C8NgXLx4kXoAt3XrVry5IbmnnnoKBmSPpT4GIPvu3bvDGDx4MBQ4Z84cjKK7aNEiGJAcpsGo v/JfuXIlPNAPgCyRhOHEkgErBRi+/OkDybZfv364Nxp3UEcgOmAaYgoCGzw4Fgtyz7kJFiPwzJ49 u7KyEkZ0dDT1A5QP8CDWLFmyBBUBToI6n54Bd4cJSPiffPIJhuChrFq1Cn6EuYEDB9KtgRs3buA2 UXeoZ/Rw6NAhzGSyZzQULqdz0MDIubNne/uETImKmjf3v/r26jM4MlJXrTucdGjo4CGDIiNPHDu+ fOmyE8eOHT9+fOjzgxfNXxDEBXy7Y8fWLVs6d+jY4bG2QwcPrr+IVpU8efJkJMzr16/jXY4SGh4o AbKnGvj88889SuFQCaNLC2aIkC716fqcQut8ao8cORJ1OxIp8u3o0aPhgY1RKBOLf6zPUcyjgqAL frq2r62tpcdSMBkVPooI2j18+DA88+fPxyEwoqKi6G4cuHv3LjyoVgYNGoRK4fTp0+iiUMcr8j8m 9O3bF/bq1atzcnKwioFNsz1kj2BHaydcFS4VUU89o4eTJ09iJpM9owFZ8f4HeBO+NnVa8vlkdAc8 079j+/ZJ+5MiOnRc8u67+zwPmzAKEbVv2y4hPn7fXvVtv2zJkr/ErQ9v2TJHmz351SgcdfTIEZv1 /zfa1SU91vBIhtBV69atUXvDixyLChlJmO5709o7KysL9ttvvw07Ly8PxXZISEhERARyO/xYY8OP M8AGGo0G3VatWuGVhhIAG7UDtVG9Q3JDhw7FBUD2KDfojp0PBAvMR3Cp301OTi4tLYUxadIk34YH QGECJ7hz5w4CCi4jICAgMjLS4XDo9Xr4EYbozE8//RRdKnuUG08//TSVPSLdiBEjMHTggPofQsEz zzyDLpM9owGBAPPyLzzVuw/eirdKS0e+OCxmzVr4V69eM2H8+H179rRp1Yo3m+H5Y+eIxMTNB/fv b9dW3eeyWa04xGw2v7d02Yhh6iZ9fdTkjOyPzGkymXiep1673d6+fXuIlkoaC3hogBbDM2fOxOnO nTsHe+fOnbABYgReO3bsWP9JHh2qnz/pOh9iQ3ERGBgIG4kaSZ4+RPBFBwouCeEAfrryB0jX8Ofn 58PGGXxPBMHHH38MJ86DWICLp3uHWBFgCJ7nn38e3QEDBiDA0UcD77zzDoZgYDHiqzJwAaGhoXDi 3hGGEBFgIyDSUQajAYno1PnY0WN/GvvSju1/R/eNma9PnjR57+7d3SK60A18VfabNx/Ytw+ZGN1q z2acwaBfvHDRqOEj1FPUw1uT/wgoHNV7fHw8lToW22fPnqVDWDwsX74cKZd2z5w5g7p6wYIF69ev r//BHrBr1y4kVRTb3r6H9PT0tWvXQnWxsbEo9eFBrMGyHEn4R0U+QOmRkJDw1ltvrVixgm40Aqzt IXKc3FfkAyh25cqVvtIAo4gRhYWFtIsSIC4uDufBDzp16hQu4MSJE/DjGhITE2loo6SkpOB2li5d unv3blQBuNPU1FTvGIPx++IWxfhNmxYtXDR9ypQ/PPpoeXnZS6PHjHvp5bh1cS2CQ5KSkv7+9bYW YWE2m1q9PxraApO/3bkzPDwc3YpydecbYvnov1dhnf/++8sNer3nrCo/LXsGg9HgoJ7duGHjiBeH vx4dneZJP8P/7YXBAwdOnzL1W0+Gy83NjY2JRXSAvW5tbLZGi1QaExODroXnly5ZYjKbdLqaVydO /PP017DahZ/CZM9g+A29e/TYmrjF23kImOwZDL8BS/qD+71bzg8Dkz2D4Td4v0jnISHk/wBXBvPp pq3fGgAAAABJRU5ErkJggg== --_004_11a46fec9e7945c087809c036785deb4PLSWE13M01adsprintcom_-- From nobody Tue Jan 5 15:49:59 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 9EF651ACD02 for ; Tue, 5 Jan 2016 15:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 AU0CZygwy60B for ; Tue, 5 Jan 2016 15:49:56 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9341ACD04 for ; Tue, 5 Jan 2016 15:49:55 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id v14so206072034ykd.3 for ; Tue, 05 Jan 2016 15:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IgncID7Cz9YB0mRoJKLUyjQ9sG+DE6wM/lxNUNT10w4=; b=wThniGoa6tFF6ZorzBJ01KMipk7ktJUndcPpB9l8WwfAgjq29erhjYENVV0SpduuND ReULUBaUdyJjYsi3kW4OXRWzs9rMHFxw3O/2ksnru/eqS/q8tT1itDg6gly1j66dOuLh +3CEc9rnwcqy+mvUc+GtNsuO8I82kUu2N7WTXfPVGJdC1JWOOBaL1o1CMQGqOy3N3A/X /EJoPk3wcsm393+c9jKMQmKIeHtPKy7gTh9rIPjAV0PA6jP6pz1sLEKMgddcwFo1jbE8 GnChp+ODXGAE9g04dzkaCOvemeO4iu1PrqvXEClGEH4YEdjRlObAgaEr0crFsbv7Nant sITQ== MIME-Version: 1.0 X-Received: by 10.129.154.73 with SMTP id r70mr68375487ywg.243.1452037794441; Tue, 05 Jan 2016 15:49:54 -0800 (PST) Received: by 10.37.90.65 with HTTP; Tue, 5 Jan 2016 15:49:54 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Jan 2016 17:49:54 -0600 Message-ID: From: Mary Barnes To: "McGarry, Tom" Content-Type: multipart/alternative; boundary=94eb2c0b874cf0327805289ee4c6 Archived-At: Cc: Modern List Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 23:49:57 -0000 --94eb2c0b874cf0327805289ee4c6 Content-Type: text/plain; charset=UTF-8 I'm curious as to why a f2f meeting is being proposed as opposed to a virtual interim? The challenge is that when there are folks at a f2f meeting and others trying to participate remotely, the remote participants are often marginalized. It's surprisingly rare that people can get a meeting room setup that makes remote participation work well. Regards, Mary. On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom wrote: > Due to the length of time between the last IETF and the next, the chairs > and AD believe we should have an interim meeting. We're proposing dates in > late February to be held in the Washington, DC area. Please let us know > what dates work best for you. > > http://doodle.com/poll/5t5p98x5nnntmmcd > > Thanks, > Tom > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > > --94eb2c0b874cf0327805289ee4c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm curious as to why a f2f meeting is being proposed = as opposed to a virtual interim? =C2=A0 The challenge is that when there ar= e folks at a f2f meeting and others trying to participate remotely, the rem= ote participants are often marginalized.=C2=A0 It's surprisingly rare t= hat people can get a meeting room setup that makes remote participation wor= k well. =C2=A0

Regards,
Mary.=C2=A0

On Tue, Jan 5, 2= 016 at 3:29 PM, McGarry, Tom <Tom.McGarry@neustar.biz>= wrote:
Due to the length of time between the last IETF and the next, the chai= rs and AD believe we should have an interim meeting.=C2=A0 We're propos= ing dates in late February to be held in the Washington, DC area.=C2=A0 Ple= ase let us know what dates work best for you. =C2=A0


Thanks,
Tom

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


--94eb2c0b874cf0327805289ee4c6-- From nobody Wed Jan 6 10:10:07 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 ADDCE1A0058 for ; Wed, 6 Jan 2016 10:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-XgrnZNpYQW for ; Wed, 6 Jan 2016 10:10:04 -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 A20E21A0053 for ; Wed, 6 Jan 2016 10:10:04 -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 u06I5hCC015914 for ; Wed, 6 Jan 2016 13:10:04 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 206bhtph68-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 06 Jan 2016 13:10:04 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.121]) with mapi id 14.03.0158.001; Wed, 6 Jan 2016 13:10:03 -0500 From: "McGarry, Tom" To: Modern List Thread-Topic: [Modern] MODERN Interim Meeting Thread-Index: AQHRR/UcSxBkvNqNuUyaJNOvbpps6p7t63QAgADfiwA= Date: Wed, 6 Jan 2016 18:10:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.50] Content-Type: multipart/alternative; boundary="_000_D2B2C1DC33669tommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-06_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601060323 Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:10:06 -0000 --_000_D2B2C1DC33669tommcgarryneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There will be remote access, video depending upon venue. I should have men= tioned this. We're hoping by having people f2f, with a good amount of time, to generate = some productive discussion. We expect remote participation and will certai= nly make sure that it can be effective. Thanks for responding to the poll. From: Mary Barnes > Date: Tuesday, January 5, 2016 6:49 PM To: Tom Mcgarry > Cc: Modern List > Subject: Re: [Modern] MODERN Interim Meeting I'm curious as to why a f2f meeting is being proposed as opposed to a virtu= al interim? The challenge is that when there are folks at a f2f meeting a= nd others trying to participate remotely, the remote participants are often= marginalized. It's surprisingly rare that people can get a meeting room s= etup that makes remote participation work well. Regards, Mary. On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom > wrote: Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in l= ate February to be held in the Washington, DC area. Please let us know wha= t dates work best for you. http://doodle.com/poll/5t5p98x5nnntmmcd Thanks, Tom _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --_000_D2B2C1DC33669tommcgarryneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
There will be remote access, video depending upon venue.  I shoul= d have mentioned this.

We're hoping by having people f2f, with a good amount of time, to gene= rate some productive discussion.  We expect remote participation and w= ill certainly make sure that it can be effective.  

Thanks for responding to the poll.  


From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tuesday, January 5, 2016 6:49= PM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>
Cc: Modern List <modern@ietf.org>
Subject: Re: [Modern] MODERN Interi= m Meeting

I'm curious as to why a f2f meeting is being proposed as o= pposed to a virtual interim?   The challenge is that when there are fo= lks at a f2f meeting and others trying to participate remotely, the remote = participants are often marginalized.  It's surprisingly rare that people can get a meeting room setup that makes remo= te participation work well.  

Regards,
Mary. 

On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom <Tom.McGarr= y@neustar.biz> wrote:
Due to the length of time between the last IETF and the next, the chai= rs and AD believe we should have an interim meeting.  We're proposing = dates in late February to be held in the Washington, DC area.  Please = let us know what dates work best for you.  


Thanks,
Tom

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


 --_000_D2B2C1DC33669tommcgarryneustarbiz_-- From nobody Wed Jan 6 10:24:28 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 CE71E1A00A1 for ; Wed, 6 Jan 2016 10:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 L4WJJJE-vGvn for ; Wed, 6 Jan 2016 10:24:23 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107951A009F for ; Wed, 6 Jan 2016 10:24:23 -0800 (PST) Received: from BL2FFO11FD053.protection.gbl (10.173.160.30) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.1.355.15; Wed, 6 Jan 2016 18:24:20 +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 BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Wed, 6 Jan 2016 18:24:20 +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 u06HiSok009401; Wed, 6 Jan 2016 13:24:19 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm3.corp.sprint.com with ESMTP id 2069p7rd9n-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jan 2016 13:24:19 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 6 Jan 2016 12:24:18 -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; Wed, 6 Jan 2016 12:24:18 -0600 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , Modern List Thread-Topic: [Modern] MODERN Interim Meeting Thread-Index: AQHRSAAy8r+P0LInaUCu1ptb2eXiZZ7t/CEAgAEzYYD//59MMA== Date: Wed, 6 Jan 2016 18:24:17 +0000 Message-ID: <4348b076672245e4bf90786284562340@PLSWE13M08.ad.sprint.com> References: 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.38] Content-Type: multipart/alternative; boundary="_000_4348b076672245e4bf90786284562340PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD053; 1:RUqWaf9ooorXPOM7ovavPIhswtQBdUhDsuQ+Pwud5Ke/GkkmllEpEgXWVVx4y/ps8nQhXMgzZAHpeDYdYF2fbesZ7vcDNuQg9jmxxE2fnSMc+8X3hwzEkESyiHZoK81yFNXRdaUuGcsHX+4c6y960woQxl9Dj96vsfPJg7F8fg1563dwywFBZiV1w4RazLcgLC4+gxltUqTi7pj21wlmGvpOjo+spTW3I3jS/EpH7TSX1JfbK1KKYeUVq1II88qtgUqUrRVXR1SaSYwrtAtuk3FWCDiinV+8IMtzOGA4UdfP6qN9RT5ey7bd2CXNBx3AM+DEuV0u/Zi+iSLpV61JooQJyEUbjEiH4iGyaZkt61CB9ga03jrkAwx6EEPQw4Hg X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(24454002)(199003)(52604005)(189002)(164054003)(377454003)(575784001)(3846002)(6806005)(81156007)(189998001)(1220700001)(76176999)(30436002)(106116001)(97736004)(106466001)(5001770100001)(108616004)(300700001)(33646002)(84326002)(86362001)(790700001)(260700001)(87936001)(19625215002)(2950100001)(92566002)(5001960100002)(2900100001)(102836003)(6116002)(19580405001)(24736003)(11100500001)(586003)(19617315012)(4546004)(1096002)(512954002)(5250100002)(19300405004)(50986999)(16236675004)(15395725005)(5008740100001)(54356999)(107886002)(5004730100002)(5003600100002)(19580395003)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB038; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 2:X8b86szhyXC0VqX8vuqTEuWll433rSG2QIZQQbsHCnEcEcQtGyxygr3UHWZtcpvaLvIgqYT7jvkvZNFdGYBYxxW5VONOWII60hd0uLw3hUoRvrHsBbJs+IDNz/Eu4UgslP5Vt7GVeIwRfry9XErTXw==; 3:3GQoGv3yAm6ITJa5AdmL1lu/3/4fxnQjnxaYiiM8m6jrf3qu25gEBLGIyQXtS1b46saxRih+PFfZ+tT5AQian++HTMgJMASOwihcBF5A1SrDwjQXzvikaH/nRBmcE73LFXX/KblxcH0bq8ejzBb/6c6to02xCsbE+3pf8vopkQJ+oI3ebAQMnKRtOHoTpyhl8F534JVvGysfKcHTR7EZ7R12hk+GbAaSFTcMarmRpmAudfIhlwq2XLy7kLhB18j5hZWsKs/18Le/Ntt86kw8/Q==; 25:Cxu+SO36RgXUE8b2oU4xOp5zu8I3/dcB4YW+ajZiv8IzXFR/kCfaBWhwANXOKfrBj4j8gt65CdMCDXs9qM9xY2LLZ8Axc9brgVvHk9KZ/C8is9/83sY6kJSGDH33G7Y4CebHYVLOim2JKLdyhdCbSj9beRE0/Zgc1aGm9KOX1YlaWaJau6I1LFu3BjqPJRBJGk5qk1AiHI3K9M9wa6GIDo5x5IPXp3NwAxpTtIIHzEWHZf/iLYbTEvdi/JmB8zj64d/22bUPsrsPUuQHrmqlgQ== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB038; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 20:IPSoNANEe5wnfv4CIFja5z4npJusWebdktpMvT/UiLaJLciCGuM0KxSpmH7G8k21vzTD3QwJhSK4l6fI+sDfr9qdj4nAc+myaDmvq8ye9cEoCqpcpVpKqbBmdMTlOPrGdYfL8n/c0bhfRYsHSlwp03NXP5pA37axuD4Znq25At1CGqXHrexkpZwpjl6rRouL77ZjalINvqWINPDshdqbrjnaAXZ36HXhqrBDJQmgITzvXcySZ4GpDjZjjgmOP+m3; 4:jX0m5tkL5iZQ4mRCOY83hcQlmzM8mmn88ljSCd0DHKRzlet99B50eJi6dz2wGGD+N/OtakZf12nv71OslBa3JBOV4u9SsuEnDaM/0X9vlkC4l0DXtVDNL2POpHICjYFB9QEju+Sd1KwOZys9t7iRO23YdrfSfbAhv6mNY/I8bdbfDRSFZF2VLwWF8jhi4EBOsHpeVuqpdxqMSsNt59vTLV2Tm0pQg7OgZIIV8cbadQ5o+xRpzW1YlmOGIrkOOkcJWb9uSkd62URvouQfaY0ICUPyeFj4KsZPRAbshYYdaCZPrn1XfwvUcC9PGokSqYjsb5kfnWTMoH3LT8OztLfNZzrSjqmPS0aQhvLrbgcc4Ycn7sjlSynSsVZpSSpvsYrifhbqp0Iha+Fg/OOF7h/ejqtsN3ygt9Ngulphm9I+GX0iS95/3fJgsqw/KRVZeBY6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BL2FFO11HUB038; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB038; X-Forefront-PRVS: 0813C68E65 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB038; 23:jCirVUAdYjIvCS/y7osKXyflckjrbL+fttBrBOYO?= =?us-ascii?Q?9i3fAenjU9FS5b1xA4j5uZe801+dthZ3BXt3rpGj9yXQVtWWfCAgXSe7ITgN?= =?us-ascii?Q?0wnT7CcQ0KmSBbLlYuwbCoVXarHKNzPYOqt67Z8j230KDNFx/sLsIwbU/EoP?= =?us-ascii?Q?o4zsECXFyum1z8fQUQor0xAYc4JaJkKRER0djKMtuCRZ4H7t9+2AFv7l8yOH?= =?us-ascii?Q?Ufjj0dV7S3sWfFpSs/UGSFOmfGqL4G/xZ2XAKVRzz+bByKjRbNq+V8+rqKKh?= =?us-ascii?Q?FFohcSDLVoL4GFqEdG0ZPkqT8twOD1hmBgCgsEbTJBAz1wz3T4rsGSkZoIGc?= =?us-ascii?Q?sYEM3c6KK7ViqisexQaBM5l0vHw1nlx7zuH0O8SRoof/DMyvVk452pIa6D1x?= =?us-ascii?Q?3RKonNEX7zJxhA5fhM+YDWAYqC0Cn0L0K4KZeckCnuI8kdkrLpBvC9So78V5?= =?us-ascii?Q?fAHH+BZ2gFqm0sITL7Vcq+ZYZ26H9BO0n9/3fm6xn2TJwyGASyyjVMZwey+5?= =?us-ascii?Q?AbrExK4AOg2whPBFjMpZOHlb81aPe/aJ7I2Cyup7a1QHfiSUTB/sF6ViDy8G?= =?us-ascii?Q?aMTIZIS84QiE51jk4k/iLBk5uRuwEqbXrRSc1K9AfolZ81m82OpQBwK8c61a?= =?us-ascii?Q?c3F0/7+zrs3cA+/3fOLbmfPjYG6zuC046/cthWi7pdKXIjxvkmEs49aKK4Yt?= =?us-ascii?Q?5zEldp7wLaACuE/nBHD2RQX/P1PGI9Wr905EhhpzFHnnl509M5TmJz4l2Vdg?= =?us-ascii?Q?5ygbVkNx39e24rPgNx2bwLSaUEpWJ7FtdEpQKFGp21kjMZFCF9UUhdAylZrp?= =?us-ascii?Q?kIC1vO1UKsACDxrNY6OHsBTcdu03n9UJi+88yoh5pP+tg4BcRyeauiEW7itR?= =?us-ascii?Q?1DCrrOrT1kVUWdk2wlKS9Kn8bpVCEdXhAk4njYTnx/QHH/j9/EjIYPKr26nX?= =?us-ascii?Q?x7EXQ49XA+B1E+Wx23T20Ja3Udd96Wxj6LqTql0VUDbtlLbX3QmHzIqEzv8o?= =?us-ascii?Q?8maiG1Jv02lga7vTfb7WeTNK33PLKP3I7YaiTqvAJ39ykQHH0Cg97ZwiILI8?= =?us-ascii?Q?a2iMdYioeMhpa//KyR6MeX8aZs+FZWRQiYiRzNVedCmBG/qhcWEDTWrXbvsg?= =?us-ascii?Q?IZBXW0jXpiQLPcHTOF8TQQ3V82lQJjKN5VEHxuckkQt505HGsfsmzN4l+wQ+?= =?us-ascii?Q?cUFiTmMKiFMdhfcBii/8cYR/wzpxtvq/ld4SLFbMppKsJD3uyrdgErmWS31H?= =?us-ascii?Q?IdIT5Pw9EvUxU4APhCnWmbTZppMSbfG4hSc0VBdxtT0utcs5Z55HzBvBSZ2J?= =?us-ascii?Q?QgjbNwVKIT+qz2IyNAOOIOfp+FCY6raS9nn5ugPTghUkoupIwscGVZMjMpBL?= =?us-ascii?Q?pBG49DStDb6Ev5iE/iiNDciRzIPYyifNhg6Df4g9cwcDnzf+PLrsH8C+wl2Q?= =?us-ascii?Q?+bquY2iZkKpD38UwcJzkjXqqsyAP1gH4YSJJmImiojLaAxzIZHQE?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 5:gzGp1Uo87ZGFIBaBEj6cGjcD9pdNHkC3BnQ45U6xM48HSoq1UN40hG/kmw2RXaQzg6+fhRYw7hCtmEkfcB05dSukggB4cLDujaORhUoFG9j7D/QNM0yZmany7jtEPf9LxsfZ8YXXmFyanqcnQM1JFw==; 24:xhvjnJbYIPMu5E0MkP0ocEXlhFfR4ekSjmyR95vZTHAkRTREH/ppr38ak1XAi/02KJq/shZK7g1U8TDIgiI6SQKsTJ7+h4D1fx38x9t3wZE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2016 18:24:20.2641 (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: BL2FFO11HUB038 Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:24:27 -0000 --_000_4348b076672245e4bf90786284562340PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You didn't answer Mary's question. From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: January 06, 2016 12:10 PM To: Modern List Subject: Re: [Modern] MODERN Interim Meeting There will be remote access, video depending upon venue. I should have men= tioned this. We're hoping by having people f2f, with a good amount of time, to generate = some productive discussion. We expect remote participation and will certai= nly make sure that it can be effective. Thanks for responding to the poll. From: Mary Barnes > Date: Tuesday, January 5, 2016 6:49 PM To: Tom Mcgarry > Cc: Modern List > Subject: Re: [Modern] MODERN Interim Meeting I'm curious as to why a f2f meeting is being proposed as opposed to a virtu= al interim? The challenge is that when there are folks at a f2f meeting a= nd others trying to participate remotely, the remote participants are often= marginalized. It's surprisingly rare that people can get a meeting room s= etup that makes remote participation work well. Regards, Mary. On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom > wrote: Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in l= ate February to be held in the Washington, DC area. Please let us know wha= t dates work best for you. http://doodle.com/poll/5t5p98x5nnntmmcd Thanks, Tom _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ 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_4348b076672245e4bf90786284562340PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You didn’t answer Mary’s qu= estion.

&nb= sp;

 

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of McGarry, Tom
Sent: January 06, 2016 12:10 PM
To: Modern List <modern@ietf.org>
Subject: Re: [Modern] MODERN Interim Meeting

 

There will be remote access, video depe= nding upon venue.  I should have mentioned this.

 

We're hoping by having people f2f, with= a good amount of time, to generate some productive discussion.  We ex= pect remote participation and will certainly make sure that it can be effective.  

 

Thanks for responding to the poll. &nbs= p;

 

 

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tuesday, January 5, 2016 6:49 PM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>
Cc: Modern List <modern@ietf.o= rg>
Subject: Re: [Modern] MODERN Interim Meeting

 

I'm curious as to why a f2f meeting is = being proposed as opposed to a virtual interim?   The challenge is tha= t when there are folks at a f2f meeting and others trying to participate remotely, the remote participants are often marginal= ized.  It's surprisingly rare that people can get a meeting room setup= that makes remote participation work well.  

 

Regards,

Mary. 

 

On Tue, Jan 5, 2016 at 3:29 PM, McGarry= , Tom <Tom.= McGarry@neustar.biz> wrote:

Due to the length of time between the l= ast IETF and the next, the chairs and AD believe we should have an interim = meeting.  We're proposing dates in late February to be held in the Washington, DC area.  Please let us know what dates= work best for you.  

 

 

Thanks,

Tom


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

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_4348b076672245e4bf90786284562340PLSWE13M08adsprintcom_-- From nobody Wed Jan 6 10:43:37 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 5ECB81A00DD for ; Wed, 6 Jan 2016 10:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 f8RcpSU_Jm-S for ; Wed, 6 Jan 2016 10:43:30 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9721A00D8 for ; Wed, 6 Jan 2016 10:43:29 -0800 (PST) Received: from BY2FFO11FD052.protection.gbl (10.1.14.32) by BY2FFO11HUB007.protection.gbl (10.1.14.213) with Microsoft SMTP Server (TLS) id 15.1.355.15; Wed, 6 Jan 2016 18:43:13 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) 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.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11FD052.mail.protection.outlook.com (10.1.15.189) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Wed, 6 Jan 2016 18:43:12 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u06HiSgX032861; Wed, 6 Jan 2016 12:43:12 -0600 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 206d76qnsd-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jan 2016 12:43:12 -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; Wed, 6 Jan 2016 12:43:11 -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; Wed, 6 Jan 2016 12:43:11 -0600 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , Modern List Thread-Topic: [Modern] MODERN Interim Meeting Thread-Index: AQHRSAAy8r+P0LInaUCu1ptb2eXiZZ7t/CEAgAEzYYD//59MMIAAA2iA Date: Wed, 6 Jan 2016 18:43:10 +0000 Message-ID: <2ad827d162aa4b2e8e40ea8c72d5bd28@PLSWE13M08.ad.sprint.com> References: 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.38] Content-Type: multipart/alternative; boundary="_000_2ad827d162aa4b2e8e40ea8c72d5bd28PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD052; 1:OxqrAIaratveFFhvCCE4zmhismKHeK2iHwHFH+3zwiGMyGE26zSYEh4Uyv8UrnPo8qRTg/XLZXue23yejXVREeoJUoZb/hXZt++RjoWY/8HyO2Qpkd1uMTov9A7JUUugieyFLOZMOJDtVgl4t14RbW3JHE7SvNkZin4D5YH1h1KYstVgCcStrY1B5I3NJXzu4xQwyQO4mdg4N69GZH14Tq34VCNo5WhK25dok/FyukuP3au46JpZw9TUCkF+R7RbPx/HsU3cv2R+5QP8xaBpL6Y7z01PE+DC4YcNpz228uVYzLEp53Nh3RGM6pHf3Yvi2AvawFmIEdWvF4KI6zF4qt5GCr9KCd3aTwVQ13tBe6rOrt2sPo1mWAczsqMhbzUM X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(24454002)(189002)(164054003)(377454003)(57704003)(199003)(52604005)(15975445007)(512954002)(575784001)(15395725005)(86362001)(50986999)(108616004)(19625215002)(24736003)(4546004)(260700001)(106466001)(2900100001)(30436002)(76176999)(54356999)(5003600100002)(19617315012)(16236675004)(19300405004)(19580405001)(87936001)(19580395003)(11100500001)(106116001)(300700001)(84326002)(5008740100001)(790700001)(5250100002)(5001770100001)(102836003)(3846002)(81156007)(33646002)(586003)(1220700001)(92566002)(5001960100002)(5004730100002)(97736004)(6116002)(6806005)(1096002)(107886002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB007; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB007; 2:ZSUz7fQfpF+LSP3cigKOnyhoAYEaG94Rs+C5O5J5W0/lUdKzRjyzqQRFdzXig25bJxTk5X+4qfgXtGj+FVkr2yw4vetSsqnz27VIOXdCRUkRi9ruY9I/4LPLwWweN0JDO4K9+e3O6WuFxFmi4mP08g==; 3:jL2bVaaBqYSFXo7WpnSDcr+Jd7VZXYqZvhLH5C4FNRTeKj38+JEWG4vc5cs1wkcBGuHP4Lg6y0B0cUQV+xPHKW1c8rviQ2zaLQrVBJL/C2zrX8VRenFPYLRcOEP6vDLg3uConr3UHmRM25XUVhkvAlaHoxyyeTcXDa03pCMxmsqufOlRqTYAZAXowBzUOP8wnKGmEWJH/k4BzsuIIKqpvHsu+yi9ImI/HzM+7FyZ/WFJo3Te/R5NhvnRyxLpfMflROhEUVf0c7a8+xVnebWTpw==; 25:r4G0/OqKEUFt6fzJtHQB4ROcZEFltK+Ku6dVaACLY9Cod/Aar6hkDcy+pPe05X0weX++OZf5/3aQOTNuVTieGlarMNOFzV0vcGhUlgUHBTxQZT/WSIn9I/RJeqVVBY3r0QMWm3J41WeOpYm9PyTRKhITfv6nWMlKwajFqLto65FgZXEDGWynsZnAPxdPlRZuYyAvkeB0kJ5OTb6W+arH62jW0eMTBcHT2Ws6ZQW3IXqftvK3+Pxk6I14JsbDA4YVhfKglerQ4OFrynkEBFLGPQ== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB007; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB007; 20:WNNuvW2oEdASANcqlnn0DuT0V16l+V17V+2F7wbZi9ubLK097jwTaO0IJ9JeY6nmrkknxhtuL/z8pZYy/EKRzzwT+gAN3viDS6QK0cArZ/OaZewWZdjbyzq5H6mzUlk1wsg2Inm+R5Zv2nNf/U2qqkmaGSgZDSeI6tIxWS7M8cRXUTmi7TAy1Xx/n4C3Mragwkr/zU3BbGXhwz6Dlk7vjJgaR3MssbEVmJxC3yRMQCyA5ZB6unNvuwVWvbnjbVPn; 4:v9ZtRXNjFz1NDdkIlJNZwTAeNNvQClribZVF2oatcGlUdktZdgntReFX6U+f3erkVAvVsWKFUs2L/suRBa3ZQktD/n0DDA5CVcsi+WCs/YJCHYExq8pjNcnImeF2Yuly2slHayp83bEo0gZVOvMt7sa7SBJNJnhgn4RtfRLZI963cS8p66JwEFnkNOQixq4/Gd5YfEip2nAetZC8oSjXxaIUzMh6mSouK3pyFO7ffc/60+c9RaLu2k6xaC5G6Y8m3JLftTMhEmOradqlVdxUab7rG8rLjA77Q/xLCVObIETJFNK4PI1y8M1WwHxUVOvFs5yE1NqoBVQyg1gJ0MhQlMdFqMoONMm5ix8QXufvqpRER0YFa2qHJmkpAVRHRiVwOZ491MtKzc5iScmEAvmVzLfmSwujONeuZp7rqBoQ+oNCk6zwf8dBieOBtNnfywuB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BY2FFO11HUB007; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB007; X-Forefront-PRVS: 0813C68E65 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB007; 23:Z1eGuZf6ZDwvH6hIJBcWw57/g9lGXeININ7zKIjy?= =?us-ascii?Q?yE/U0TrLMy++9puc2jU/pzcFsQd/6EsavQOS7JOL5PPyY40JwYvVs0z1zdLK?= =?us-ascii?Q?a/GAqU/FywhPqg5Z5Irhb5ZOgdEGFUR5ft/1zHXL7KbljHw6fzJBOILOcqo6?= =?us-ascii?Q?NdNufHCZLYt4wfgoa1C4R/a+x1bVe2dGHxg7sHYSsDu0yTbK1FsYx8QCW4hX?= =?us-ascii?Q?PekL7mxGOioNmQISNwbyjLUJXzogGcc+spx4x60WoIOf5Mp9b10dMXWNVTZU?= =?us-ascii?Q?3sGK9UbKkyWCTZfnFRaISe7SEKvImp4ziCFR9A5UIBSBs7d16RPSShLpChuk?= =?us-ascii?Q?UR7v5ksuEA6W7PvL6EOtbLwtvMlSNxhJ2dVrki/Dw9knkXZbEb+5BMvho4YU?= =?us-ascii?Q?CdVOe3p8LnuU7hIt5GHTyL6WCbU8GuU4LmNcGlj37yvwFUyXIC+dasVpoWB/?= =?us-ascii?Q?8n8YjwIWZRTHse2LfR2m8+1KiMcuXjJNcyx5fCScs5OQk6yYlCbsmI1J71TF?= =?us-ascii?Q?swbnw/2lIunsRMnhy3nuNOauVPZPqoWbQp/UGmCYppySXHPuOrgAdLvRxxCP?= =?us-ascii?Q?uckEMmDCvo7AMnApUPrSKgh8kfmhwJ4EogGqPgYoUM7a7oE2If051l6vpDcW?= =?us-ascii?Q?RCBAuBlvnglOMYGDsMXhLrTsOmvYOAW7i/JyHGqbvlZKroVSLd70OyF/eGtn?= =?us-ascii?Q?oNoK5azkAB3BNgd3mbtOmIviiVVPMYd2YpdQ+RYr4PH5s//X9txVUOc22++M?= =?us-ascii?Q?nqVIS/IfUNtFaUY8HSIcy1CAHQMeEjTJlkCAqQ/N1i4V58dacgdMUkXTUFif?= =?us-ascii?Q?oihQ0G+HceKFNxMhRb8zjiG/BxWWCaraqT5h5cAxV9z3wRyOyct6ggje+37V?= =?us-ascii?Q?mLilsYva/KarZCbfMh2v5VWXIAJnpJmRsSf+j2KKc23lqIzl2+yvL/Ka6c60?= =?us-ascii?Q?aw1bHSRi7vQcqs9qIW/NGv14Gjr4eBchaKuq05b/w+xqa7dv+7DmqnT6L9Sl?= =?us-ascii?Q?GRx9pbQ6lhudRNR4LndzciVXOEQ+qPYS9DWNVXylVLcQ/tDMAiUK+SsYRoZi?= =?us-ascii?Q?mcx2IWIfIsihEtQrspMJDjRxomO26sATC3rbcLJQzHuTohAKYjWoCiHVAYgm?= =?us-ascii?Q?mc5txE1KUx4cwkphtPCXI/r29YlhzDv5IrwXdg0q2h/ocZM5q0+3TbF7S4Je?= =?us-ascii?Q?I8m3FSAQ1jX1/es5u94jlGEINEraft00WjFWIEX/4MODLiStCgoik1iq4NLt?= =?us-ascii?Q?o/g82Jrfr88eZchyMRcPVLhPIs8qrwnvfy645YeULubzhfwFPCbQP+znCieC?= =?us-ascii?Q?QjlLSgT8/aFnubgI3TQyYPvyfTGkGSfHAMFos/ozJ6RzTj8GUIBEiPHg6cUo?= =?us-ascii?Q?goufSZtvc0Vs/EP3vwTXKwUKzUiTy44zb+4JucOP3k/n0XPSKEzyqsqFuDBo?= =?us-ascii?Q?msrSZvaBD86z1tn1fJ/OTOPRPkbxuamgWrYoVrELvdu18FLQbo9w?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB007; 5:AZdhgfhMiC/YBHKnZXk0f0Q79y/aENha1/Vwbxz8pgTHmrfRNaWqL5U5mtjwomuTCxxIcIYOOKyz+chvbb5jHFloVKNpxmhSODQuu3FIuVF/n7xSmRCClZMnbCLrqIhMPBH9v+ZPC3Gl3v5CvHI9dQ==; 24:6pA5pQv6vtjWq9syrBNHghEHqu8dn8qfirybVJskI812zbOhnhtTqScIHSOC6Cgq53ctQaMbA9UQGIarUeZUYtcWAXwbj0QVxjThxcsIJyg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2016 18:43:12.9968 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB007 Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:43:36 -0000 --_000_2ad827d162aa4b2e8e40ea8c72d5bd28PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To be more clear. Mary's question wasn't what did you and the ADs hope for out of a face-2-fa= ce interim meeting. Mary's question was why is a face-to-face required instead of a virtual mee= ting with everyone equally disadvantaged? My question would have been why do we need an interim meeting? I believe there are members of the working group who have been, and felt, m= arginalized by both the definition of consensus and the inability to argue = about what occurred in a meeing halfway around the world where they either = weren't able to attend or were unable to attend equally with the participan= ts in the room face-to-face. One way to be more inclusive, and ensure greater (if somewhat disadvantaged= ) participation would be to hold the interim meeting (if it must be held) a= s an interim virtual meeting versus face-to-face. Since I'm new I don't know what is customary, but I inferred from Mary's qu= estion that a virtual meeting was customary (and certainly cheaper), and so= the question you failed to answer has additional merit. Pierce From: Gorman, Pierce A [CTO] Sent: January 06, 2016 12:24 PM To: 'McGarry, Tom' ; Modern List Subject: RE: [Modern] MODERN Interim Meeting You didn't answer Mary's question. From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: January 06, 2016 12:10 PM To: Modern List > Subject: Re: [Modern] MODERN Interim Meeting There will be remote access, video depending upon venue. I should have men= tioned this. We're hoping by having people f2f, with a good amount of time, to generate = some productive discussion. We expect remote participation and will certai= nly make sure that it can be effective. Thanks for responding to the poll. From: Mary Barnes > Date: Tuesday, January 5, 2016 6:49 PM To: Tom Mcgarry > Cc: Modern List > Subject: Re: [Modern] MODERN Interim Meeting I'm curious as to why a f2f meeting is being proposed as opposed to a virtu= al interim? The challenge is that when there are folks at a f2f meeting a= nd others trying to participate remotely, the remote participants are often= marginalized. It's surprisingly rare that people can get a meeting room s= etup that makes remote participation work well. Regards, Mary. On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom > wrote: Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in l= ate February to be held in the Washington, DC area. Please let us know wha= t dates work best for you. http://doodle.com/poll/5t5p98x5nnntmmcd Thanks, Tom _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ 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_2ad827d162aa4b2e8e40ea8c72d5bd28PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To be more clear.

 

Mary’s question wasn’t what= did you and the ADs hope for out of a face-2-face interim meeting.

 

Mary’s question was why is a face= -to-face required instead of a virtual meeting with everyone equally disadv= antaged?

 

My question would have been why do we n= eed an interim meeting?

 

I believe there are members of the work= ing group who have been, and felt, marginalized by both the definition of c= onsensus and the inability to argue about what occurred in a meeing halfway around the world where they either weren̵= 7;t able to attend or were unable to attend equally with the participants i= n the room face-to-face.

 

One way = to be more inclusive, and ensure greater (if somewhat disadvantaged) partic= ipation would be to hold the interim meeting (if it must be held) as an interim virtual meeting versus face-to-face.

&nb= sp;

Since I&= #8217;m new I don’t know what is customary, but I inferred from Mary&= #8217;s question that a virtual meeting was customary (and certainly cheaper), and so the question you failed to answer has additional merit.

&nb= sp;

Pierce

 

From: Gorman, Pierce A [CTO]
Sent: January 06, 2016 12:24 PM
To: 'McGarry, Tom' <Tom.McGarry@neustar.biz>; Modern List <= modern@ietf.org>
Subject: RE: [Modern] MODERN Interim Meeting

 

You didn’t answer Mary’s qu= estion.

&nb= sp;

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: January 06, 2016 12:10 PM
To: Modern List <modern@ietf.o= rg>
Subject: Re: [Modern] MODERN Interim Meeting

 

There will be remote access, video depe= nding upon venue.  I should have mentioned this.

 

We're hoping by having people f2f, with= a good amount of time, to generate some productive discussion.  We ex= pect remote participation and will certainly make sure that it can be effective.  

 

Thanks for responding to the poll. &nbs= p;

 

 

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tuesday, January 5, 2016 6:49 PM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>
Cc: Modern List <modern@ietf.o= rg>
Subject: Re: [Modern] MODERN Interim Meeting

 

I'm curious as to why a f2f meeting is = being proposed as opposed to a virtual interim?   The challenge is tha= t when there are folks at a f2f meeting and others trying to participate remotely, the remote participants are often marginal= ized.  It's surprisingly rare that people can get a meeting room setup= that makes remote participation work well.  

 

Regards,

Mary. 

 

On Tue, Jan 5, 2016 at 3:29 PM, McGarry= , Tom <Tom.= McGarry@neustar.biz> wrote:

Due to the length of time between the l= ast IETF and the next, the chairs and AD believe we should have an interim = meeting.  We're proposing dates in late February to be held in the Washington, DC area.  Please let us know what dates= work best for you.  

 

 

Thanks,

Tom


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

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_2ad827d162aa4b2e8e40ea8c72d5bd28PLSWE13M08adsprintcom_-- From nobody Wed Jan 6 10:49: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 D1BB61A00DC for ; Wed, 6 Jan 2016 10:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.276 X-Spam-Level: X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 H0DI-Q0cMuPY for ; Wed, 6 Jan 2016 10:49:00 -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 27D991A00DA for ; Wed, 6 Jan 2016 10:49:00 -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 u06IlR7H012506 for ; Wed, 6 Jan 2016 13:49:00 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 206bhtpkd8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 06 Jan 2016 13:48:58 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.121]) with mapi id 14.03.0158.001; Wed, 6 Jan 2016 13:48:57 -0500 From: "McGarry, Tom" To: Modern List Thread-Topic: [Modern] MODERN Interim Meeting Thread-Index: AQHRR/UcSxBkvNqNuUyaJNOvbpps6p7t/CEAgAEzYYD//59MMIAAA2iAgAADpQA= Date: Wed, 6 Jan 2016 18:48:56 +0000 Message-ID: In-Reply-To: <2ad827d162aa4b2e8e40ea8c72d5bd28@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.50] Content-Type: multipart/alternative; boundary="_000_D2B2CAE43367Etommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-06_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601060336 Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:49:05 -0000 --_000_D2B2CAE43367Etommcgarryneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable F2F encourages more rigorous discussion. You say so yourself. And that's = what we're looking for. We realize that not everyone can attend in person,= but as I said we will make sure to support the remote attendees. From: , Pierce Gorman > Date: Wednesday, January 6, 2016 1:43 PM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] MODERN Interim Meeting To be more clear. Mary=92s question wasn=92t what did you and the ADs hope for out of a face-= 2-face interim meeting. Mary=92s question was why is a face-to-face required instead of a virtual m= eeting with everyone equally disadvantaged? My question would have been why do we need an interim meeting? I believe there are members of the working group who have been, and felt, m= arginalized by both the definition of consensus and the inability to argue = about what occurred in a meeing halfway around the world where they either = weren=92t able to attend or were unable to attend equally with the particip= ants in the room face-to-face. One way to be more inclusive, and ensure greater (if somewhat disadvantaged= ) participation would be to hold the interim meeting (if it must be held) a= s an interim virtual meeting versus face-to-face. Since I=92m new I don=92t know what is customary, but I inferred from Mary= =92s question that a virtual meeting was customary (and certainly cheaper),= and so the question you failed to answer has additional merit. Pierce From: Gorman, Pierce A [CTO] Sent: January 06, 2016 12:24 PM To: 'McGarry, Tom' = >; Modern List > Subject: RE: [Modern] MODERN Interim Meeting You didn=92t answer Mary=92s question. From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: January 06, 2016 12:10 PM To: Modern List > Subject: Re: [Modern] MODERN Interim Meeting There will be remote access, video depending upon venue. I should have men= tioned this. We're hoping by having people f2f, with a good amount of time, to generate = some productive discussion. We expect remote participation and will certai= nly make sure that it can be effective. Thanks for responding to the poll. From: Mary Barnes > Date: Tuesday, January 5, 2016 6:49 PM To: Tom Mcgarry > Cc: Modern List > Subject: Re: [Modern] MODERN Interim Meeting I'm curious as to why a f2f meeting is being proposed as opposed to a virtu= al interim? The challenge is that when there are folks at a f2f meeting a= nd others trying to participate remotely, the remote participants are often= marginalized. It's surprisingly rare that people can get a meeting room s= etup that makes remote participation work well. Regards, Mary. On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom > wrote: Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in l= ate February to be held in the Washington, DC area. Please let us know wha= t dates work best for you. http://doodle.com/poll/5t5p98x5nnntmmcd Thanks, Tom _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off f= or details. ________________________________ 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_D2B2CAE43367Etommcgarryneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <12912DC307CD4049845E0808B505DCBE@neustar.biz> Content-Transfer-Encoding: quoted-printable
F2F encourages more rigorous discussion.  You say so yourself. &n= bsp;And that's what we're looking for.  We realize that not everyone c= an attend in person, but as I said we will make sure to support the remote = attendees.  

From: <Gorman>, Pierce Gorman= <Pierce.Gorman@sprint.com>
Date: Wednesday, January 6, 2016 1:= 43 PM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>, Modern List &l= t;modern@ietf.org>
Subject: RE: [Modern] MODERN Interi= m Meeting

To be more clear.

 

Mary=92s question wasn=92t what did yo= u and the ADs hope for out of a face-2-face interim meeting.

 

Mary=92s question was why is a face-to= -face required instead of a virtual meeting with everyone equally disadvant= aged?

 

My question would have been why do we = need an interim meeting?

 

I believe there are members of the wor= king group who have been, and felt, marginalized by both the definition of = consensus and the inability to argue about what occurred in a meeing halfway around the world where they either= weren=92t able to attend or were unable to attend equally with the partici= pants in the room face-to-face.

 

One way= to be more inclusive, and ensure greater (if somewhat disadvantaged) parti= cipation would be to hold the interim meeting (if it must be held) as an interim virtual meeting versus face-to-= face.

&n= bsp;

Since I= =92m new I don=92t know what is customary, but I inferred from Mary=92s que= stion that a virtual meeting was customary (and certainly cheaper), and so the question you failed to answer has additiona= l merit.

&n= bsp;

Pierce<= o:p>

 

From: Gorman, Pierce A [CTO]
Sent: January 06, 2016 12:24 PM
To: 'McGarry, Tom' <To= m.McGarry@neustar.biz>; Modern List <modern@ietf.org>
Subject: RE: [Modern] MODERN Interim Meeting

 

You didn=92t answer Mary=92s question.=

&n= bsp;

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: January 06, 2016 12:10 PM
To: Modern List <modern@ietf.o= rg>
Subject: Re: [Modern] MODERN Interim Meeting

 

There will be remote access, video dependin= g upon venue.  I should have mentioned this.

 

We're hoping by having people f2f, with a g= ood amount of time, to generate some productive discussion.  We expect= remote participation and will certainly make sure that it can be effective.  

 

Thanks for responding to the poll.  

 

 

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tuesday, January 5, 2016 6:49 PM
To: Tom Mcgarry <tom.m= cgarry@neustar.biz>
Cc: Modern List <modern@ietf.o= rg>
Subject: Re: [Modern] MODERN Interim Meeting

 

I'm curious as to why a f2f meeting is bein= g proposed as opposed to a virtual interim?   The challenge is that wh= en there are folks at a f2f meeting and others trying to participate remotely, the remote participants are often marginal= ized.  It's surprisingly rare that people can get a meeting room setup= that makes remote participation work well.  

 

Regards,

Mary. 

 

On Tue, Jan 5, 2016 at 3:29 PM, McGarry, To= m <Tom.McGa= rry@neustar.biz> wrote:

Due to the length of time between the last = IETF and the next, the chairs and AD believe we should have an interim meet= ing.  We're proposing dates in late February to be held in the Washington, DC area.  Please let us know w= hat dates work best for you.  

 

 

Thanks,

Tom


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

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_D2B2CAE43367Etommcgarryneustarbiz_-- From nobody Wed Jan 6 12:16:44 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 E3CF31A01D7 for ; Wed, 6 Jan 2016 12:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.978 X-Spam-Level: X-Spam-Status: No, score=0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTflYZTi6SFW for ; Wed, 6 Jan 2016 12:16:40 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BEA1A0263 for ; Wed, 6 Jan 2016 12:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=O/8iLOceGsRjkbhrvT9FwGOvE8eaJ9oGY6z+SwkDJn0=; b=XMENwyDZAbBzqp5ndoyrTZ7EYaFQz7ceqKP3pJjNRDarl5nnOYQ/MfyRpa5LUp3YgMC4noYxN4oomux2Vx8zA57d3PYXfB2yEd6dtcNU9TFTVTGewUflsEcqQV+rVKreFJmAEWIgsR4cklKr7arxhHoWe8AHjX82FkrTqp0P2yg=; Received: from 24-35-237-78.fidnet.com ([24.35.237.78]:60469 helo=[192.168.100.153]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aGuVY-0002BA-BT for modern@ietf.org; Wed, 06 Jan 2016 12:16:39 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_931459E5-E0F1-4F4D-A511-0FD1948F2B80"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: Date: Wed, 6 Jan 2016 14:16:35 -0600 Message-Id: References: To: Modern List X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-0.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:16:43 -0000 --Apple-Mail=_931459E5-E0F1-4F4D-A511-0FD1948F2B80 Content-Type: multipart/alternative; boundary="Apple-Mail=_52E91D9A-AA01-4849-B53B-964D3BC17E5A" --Apple-Mail=_52E91D9A-AA01-4849-B53B-964D3BC17E5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Great. Let=92s do it in Lenexa. Centrally located. Equally bad for = everybody. Also, it=92s only applicable to some of us, but the first week offered = is the DHS PI=92s meeting in Washington and the second week is the RSA = Conference in San Francisco. > On Jan 6, 2016, at 12:48 PM, McGarry, Tom = wrote: >=20 > F2F encourages more rigorous discussion. You say so yourself. And = that's what we're looking for. We realize that not everyone can attend = in person, but as I said we will make sure to support the remote = attendees. >=20 > From: , Pierce Gorman > > Date: Wednesday, January 6, 2016 1:43 PM > To: Tom Mcgarry >, Modern List > > Subject: RE: [Modern] MODERN Interim Meeting >=20 > To be more clear. >=20 > Mary=92s question wasn=92t what did you and the ADs hope for out of a = face-2-face interim meeting. >=20 > Mary=92s question was why is a face-to-face required instead of a = virtual meeting with everyone equally disadvantaged? >=20 > My question would have been why do we need an interim meeting? >=20 > I believe there are members of the working group who have been, and = felt, marginalized by both the definition of consensus and the inability = to argue about what occurred in a meeing halfway around the world where = they either weren=92t able to attend or were unable to attend equally = with the participants in the room face-to-face. >=20 > One way to be more inclusive, and ensure greater (if somewhat = disadvantaged) participation would be to hold the interim meeting (if it = must be held) as an interim virtual meeting versus face-to-face. >=20 > Since I=92m new I don=92t know what is customary, but I inferred from = Mary=92s question that a virtual meeting was customary (and certainly = cheaper), and so the question you failed to answer has additional merit. >=20 > Pierce >=20 > From: Gorman, Pierce A [CTO] > Sent: January 06, 2016 12:24 PM > To: 'McGarry, Tom' >; Modern List > > Subject: RE: [Modern] MODERN Interim Meeting >=20 > You didn=92t answer Mary=92s question. >=20 >=20 > From: Modern [mailto:modern-bounces@ietf.org = ] On Behalf Of McGarry, Tom > Sent: January 06, 2016 12:10 PM > To: Modern List > > Subject: Re: [Modern] MODERN Interim Meeting >=20 > There will be remote access, video depending upon venue. I should = have mentioned this. >=20 > We're hoping by having people f2f, with a good amount of time, to = generate some productive discussion. We expect remote participation and = will certainly make sure that it can be effective. >=20 > Thanks for responding to the poll. >=20 >=20 > From: Mary Barnes > > Date: Tuesday, January 5, 2016 6:49 PM > To: Tom Mcgarry > > Cc: Modern List > > Subject: Re: [Modern] MODERN Interim Meeting >=20 > I'm curious as to why a f2f meeting is being proposed as opposed to a = virtual interim? The challenge is that when there are folks at a f2f = meeting and others trying to participate remotely, the remote = participants are often marginalized. It's surprisingly rare that people = can get a meeting room setup that makes remote participation work well. >=20 > Regards, > Mary. >=20 > On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom > wrote: >> Due to the length of time between the last IETF and the next, the = chairs and AD believe we should have an interim meeting. We're = proposing dates in late February to be held in the Washington, DC area. = Please let us know what dates work best for you. >>=20 >> http://doodle.com/poll/5t5p98x5nnntmmcd = >>=20 >> Thanks, >> Tom >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern = >=20 >=20 > Learn more on how to switch to Sprint and save 50% on most Verizon, = AT&T or T-Mobile rates. See sprint.com/50off = for details. >=20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_52E91D9A-AA01-4849-B53B-964D3BC17E5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Great. Let=92s do it in Lenexa. Centrally located. Equally = bad for everybody.

Also, it=92s only applicable to some of us, but the first = week offered is the DHS PI=92s meeting in Washington and the second week = is the RSA Conference in San Francisco.

On Jan 6, 2016, at 12:48 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:

F2F encourages more = rigorous discussion.  You say so yourself.  And that's what = we're looking for.  We realize that not everyone can attend in = person, but as I said we will make sure to support the remote attendees. =  

From: <Gorman>, = Pierce Gorman <Pierce.Gorman@sprint.com>
Date: Wednesday, January = 6, 2016 1:43 PM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>, = Modern List <modern@ietf.org>Subject: RE: [Modern] MODERN = Interim Meeting

To be more clear.
 
Mary=92= s question wasn=92t what did you and the ADs hope for out of a = face-2-face interim meeting.
 
Mary=92s question was why = is a face-to-face required instead of a virtual meeting with everyone = equally disadvantaged?
 
My question would have = been why do we need an interim meeting?
 
I = believe there are members of the working group who have been, and felt, = marginalized by both the definition of consensus and the inability to = argue about what occurred in a meeing halfway around the world where = they either weren=92t able to attend or were unable to attend equally = with the participants in the room face-to-face.
 
One way to be more inclusive, and ensure = greater (if somewhat disadvantaged) participation would be to hold the = interim meeting (if it must be held) as an interim virtual meeting = versus face-to-face.
 
Since I=92m new I don=92t = know what is customary, but I inferred from Mary=92s question that a = virtual meeting was customary (and certainly cheaper), and so the = question you failed to answer has additional merit.
 
Pierce
 
From: Gorman, = Pierce A [CTO] 
Sent: January 06, 2016 12:24 = PM
To: 'McGarry, Tom' <Tom.McGarry@neustar.biz>; = Modern List <modern@ietf.org>Subject: RE: [Modern] MODERN Interim = Meeting
 
You = didn=92t answer Mary=92s question.
 
 
From: Modern [mailto:modern-bounces@ietf.org] On Behalf = Of McGarry, Tom
Sent: January 06, 2016 12:10 = PM
To: Modern List <modern@ietf.org>
Subject: Re: [Modern] MODERN Interim = Meeting
 
There will be remote access, video depending upon venue. =  I should have mentioned this.
 
We're hoping by having = people f2f, with a good amount of time, to generate some productive = discussion.  We expect remote participation and will certainly make = sure that it can be effective.  
 
Thanks for responding to = the poll.  
 
 
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tuesday, January 5, = 2016 6:49 PM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>Cc: Modern List <modern@ietf.org>
Subject: Re: [Modern] MODERN = Interim Meeting
 
I'm curious as to why a f2f meeting is being = proposed as opposed to a virtual interim?   The challenge is that = when there are folks at a f2f meeting and others trying to participate = remotely, the remote participants are often marginalized.  It's = surprisingly rare that people can get a meeting room setup that makes = remote participation work well.  
 
Regards,
Mary. 
 
On Tue, Jan 5, 2016 at 3:29 PM, = McGarry, Tom <Tom.McGarry@neustar.biz> wrote:
Due to the length of time = between the last IETF and the next, the chairs and AD believe we should = have an interim meeting.  We're proposing dates in late February to = be held in the Washington, DC area.  Please let us know what dates = work best for you.  
 
http://doodle.com/poll/5t5p98x5nnntmmcd
 
Thanks,
Tom


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

 

Learn more on how to switch to Sprint and save 50% on most = Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. 

This e-mail may contain Sprint proprietary = information intended for the sole use of the recipient(s). Any use by = others is prohibited. If you are not the intended recipient, please = contact the sender and delete all copies of the message.
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

= --Apple-Mail=_52E91D9A-AA01-4849-B53B-964D3BC17E5A-- --Apple-Mail=_931459E5-E0F1-4F4D-A511-0FD1948F2B80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWjXYjAAoJEORoZaSQsc1ION4QAIGmjw3PN9YtlnFl0P02JMcs 4oH4zlbK42mc0vz/k/xZWr/U4bfKshq77GUJKZMhy+2IRdMtXOVFneB6Tm+al6jL dE69zakvGau7byV4i4wYKEX4f2h6VLvNazlz0/sA4C9D/fawxv+ISLpNkvZGKOnX mSqhOFhhh5I7XCB4z9au0VkO/orRD+vQj40lUeGEEBJmV4384yZGwg9wrhRNNkFO 0itJcbqFD4SguhMCIQhFxZmYdRiMGwgz0GQwKZd+jg2m00a7ZJmOyoccbGA3hFCY jAVmvIyBQAGS8SvKCU/QSDfkFxIBFRQj53ckAwR0CUVZc1nkDQMmqO8VkP1K2BPY Gup70q1b2wEU4cmvYEUywiAhtSFLtScZEfedFFKZ97ANSkv6/LEQzuYsUIJppn4I DDbFfFBL3aMaY2Zuo+Hwe4iZE1ogO0Eg3WMDrZ91Y2CGcCiw0Ngd67NrX6FkFTBr Rqg1wuvOQPVAceS8zdwUN6tJ1UfPIWiM/C0xTMvT9lNIqSBWFzCQXeFkEa9JHJCg ZqQevfxrqYRLAol0ADV/hyisGLsZIGecUTKIzJvyI6DdxmCXH0z8E/e2TQe7bfu7 +QeP5cQAFZWqvRNvfEEaujhQhbni3+zAYdsHatvK9tnotnwOsu72HR0Pwn+dkgMN UQn8+tELUYfMAhbmAd+v =lXpG -----END PGP SIGNATURE----- --Apple-Mail=_931459E5-E0F1-4F4D-A511-0FD1948F2B80-- From nobody Wed Jan 6 13:28:31 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 B57FD1A1A31 for ; Wed, 6 Jan 2016 13:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 4jo-y95eWAlW for ; Wed, 6 Jan 2016 13:28:22 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055BA1A1A2D for ; Wed, 6 Jan 2016 13:28:21 -0800 (PST) Received: from BY2FFO11FD041.protection.gbl (10.1.14.34) by BY2FFO11HUB015.protection.gbl (10.1.15.224) with Microsoft SMTP Server (TLS) id 15.1.355.15; Wed, 6 Jan 2016 21:28:18 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.81) 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.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com; Received: from preapdm2.corp.sprint.com (144.230.32.81) by BY2FFO11FD041.mail.protection.outlook.com (10.1.14.226) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Wed, 6 Jan 2016 21:28:18 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u06Kpc05021689; Wed, 6 Jan 2016 16:28:17 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by preapdm2.corp.sprint.com with ESMTP id 2068eut6hc-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jan 2016 16:28:17 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 6 Jan 2016 15:28:15 -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; Wed, 6 Jan 2016 15:28:15 -0600 From: "Gorman, Pierce A [CTO]" To: Eric Burger , Modern List Thread-Topic: [Modern] MODERN Interim Meeting Thread-Index: AQHRSL8j8r+P0LInaUCu1ptb2eXiZZ7u/pMw Date: Wed, 6 Jan 2016 21:28:14 +0000 Message-ID: References: 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.38] Content-Type: multipart/alternative; boundary="_000_e81f9ef93046453ca2de515821d937f1PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD041; 1:R9IquKGSbprdYdurrsuB2CTMsc72hqPjifeNObGu7td65q4T0h6rMtnWa0iTzeUrvnbzD1Iv8L5yXkNlaeRZBDcdCSvMKFTgSCSBCwdDO5/fz0egPhn94cuouS8vOcPE3aKAVdz6TfJq++zcfcqdFarXJKF76gseQ5jICLkP3pBXWtnhEhFYkVzzzVACduZiPHgNMRtSZ41G7JlIn79nQRIXiiylBIzEYjBSq8Ezcmls3AICFtSJuccIjkvi8evBi63qcWqm4fZfzJIAkZvpETDkTgxyiTmU0akQu2AlR4MtZrdk9TAvYreOCKnD0ztbUJD7TiqStJ0wgTFol8r1xoXYdxMlwAeSDjYey5nVbDKe0VIWY7LgUGMZHJCIoqtm X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(189002)(377454003)(57704003)(164054003)(199003)(24454002)(52604005)(108616004)(512954002)(19617315012)(33646002)(3846002)(6116002)(586003)(790700001)(1220700001)(1096002)(102836003)(86362001)(575784001)(5008740100001)(6806005)(260700001)(300700001)(5003600100002)(107886002)(5001960100002)(189998001)(106466001)(106116001)(5001770100001)(97736004)(11100500001)(15395725005)(5250100002)(16236675004)(50986999)(76176999)(54356999)(2900100001)(2950100001)(19625215002)(81156007)(4546004)(92566002)(5004730100002)(15975445007)(87936001)(24736003)(19300405004)(19580405001)(19580395003)(84326002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB015; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB015; 2:g+xQXAz/PFlUA/CDynkIYnPwSepYHQE6UQ8ZHkL7Soj6bDg0yIbyk8izJ2aQQ32aa05m+inTMcGJqz0T6gEFI9VTpuPDZrzUq8LvReuVVnaeMkF7HcZBz/s/dlO5HBH0DeIQ4KZ83Xsr+R3Jcgp/Eg==; 3:K8RdzjF1C4gX40pdql5v5TughkQZTY1j4ycGGcvUcJt/AiWf0W7yC1CJpkBy99myJAua2Kb7ZakA4YhJY3jDcqLZBoQk3Xxpc0WteElOhFII4rkio1dmGIw5BzSlq6rXaJlPPs9t0UjxrN9Q5nxbabbrTdYF0QW3ThFbd6TWu97KDdEBbox9NtTYOgXTMOhoE28D04+7k9/sxnZ4nPOIv4MG1UV6gw5FvSdOC0uwWLoPXQ5qyPU7Z+aj7amUiQ0zX0d+ak6VPdfyzdo2b40/9Q==; 25:FoOcDvtFYWQc2IGWPVBh3mi4ITy+66Yea8mShFyiQIVQxmgzJlMcSlpCNr+bXNQc3s05dGSMOKvARGRaTQhl+VLwfwGjoKVU1CVJ2QN/q6PYQ6r3pZYk/7MxVpmFASOw4/LhMANcJNHvYul9AQgcC4NSxQdXhbhCXFPqyjVOeAYLy/P0NXviFlCUnXCpicXUlC7QF4Ob+Z7RIKV4lGjd6ZRY03H21rNG6myessmnKVGklwTIde/qO0G1rFh4r86B3d5DCvwMMaWvn9L5+nRtzg== X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB015; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB015; 20:l0a9iGJFlvJzYnLmGvK1mjE5igUQSgCAVAXauj6i5fLk4HJ8eKRjZSi5f3Sgy+D8+mvntC85KVP6kDFExXrIPQ6J8SGP/KMPoIc7P4dzK/RguXdrXP6l1hPGBqKhk/WkDnayYY03fQXPiGVB5sDVCWwFc/6PeL/krhqCnKDvyWY4TYPMHrlsxg21QWWvkkiksjSULK1ZeW8+1JsZP3D7pHCIoq+0Y5yjO0HEIXfBMkuwYrY+h+/IFDY0feqIIGes; 4:ZyKdIQGh3KSqJsq6C3etqVjsTLMfOcc1s9IYpcx9pHiZeTbAnuLocvWlT7JGwhhdOp277uYIBF3dvPL4/nXQhgMjo6pjLf/pqJ5Sexx219pGUkF9eAOTMX/hYtk/E5JyHvDpxSS91jJ/JNZvCSR2WFgaxXjm0uUWIWGqcrxx8fSdwsi8dw0E9h1VfJSn/p+/yCmMj87coV8SPQVblypRzKGSvL7REyxWykkBj8xEb14HCW4+C5+/u8z3I+3Lur2W+R2TF9siTBUnY5d+s6R6UXjVBNEzM2jj2PZRFywdRsw1q7jlsIGJ9uzvufdOjnssDyFGypBqGT+Ehhz3rLMfWjU4p5TsvgIch8qt9lbLOy3qOEe9OK6Z554NcWM9EENtRYIsp5h30+QmoT72cRl9WMQsAUdVd1nQSzP0BKqt4uOJ+IGEQiKRiyfVuSLRZcmr X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY2FFO11HUB015; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB015; X-Forefront-PRVS: 0813C68E65 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB015; 23:Y7Ol1BiJC8QEdagMgR78Wi30Uu1RTGOVP0dGWRXA?= =?us-ascii?Q?sLuMR9Ctqs3DrZl1A61u9heryZTFgWoQh0UOQFFD7Te4AiVjnWpfpnIhuhTr?= =?us-ascii?Q?70OltMw2uwkMDBvvwb2HOXUG0ho6reVKMN3tfH9ug9Ni7zOuRD42pzY70Wqt?= =?us-ascii?Q?fxE1NxCmjbrHyE/EmuHxgFoCKGD+DX/+mtckfYEnjSg+yF78fbC7c+u1r3HZ?= =?us-ascii?Q?gMUs9qfEP0b7u+gAWGejHVO8G5V+xI4FeFF7h7S2ZODpiABzhtW3I8zLhQQ6?= =?us-ascii?Q?9Fw8EPjIQIvQYln+L6Rf0QQLpcwGUGOVWr8JpqUbNMo0nalu7rHywyTSyaM/?= =?us-ascii?Q?a7ZR8h80XkXZKlx4gYNJS+BjrEvZgwdaFQ3oWxSs6386V5VZMeZp36cpEKce?= =?us-ascii?Q?kcYNez3AvtAZjnCxVwuJDwT0T3kL7Fb16u5Pv55IgZkFlIkfZi7jcVY6DVls?= =?us-ascii?Q?VscQQv+r8UqwdjZH03x5txF0IqBTSss0cl/iuTg/hvEFT926wkV2DH5AW2SX?= =?us-ascii?Q?X68U0D66QYCqOtY7IC5c7bpOE/dQwdrX1uFLK5P7YjAy9WElDKAV2GBQEYRF?= =?us-ascii?Q?5wOwmtJciTcuqEGKFluXIuh+jeQWE7DexhhUYPM++qB5pWiFvw14pdRZk38S?= =?us-ascii?Q?1edZOnYKjWhyjw5FQldQT5Syay+oaQPTHqsfdwNCGDWXvSIYt2EYg6ya/nHA?= =?us-ascii?Q?G7u2MS7Pi4Yx+oEc3MxaXqVaSyiUeMQZOexroAOe9cMjI9WkdUDafHcSICbb?= =?us-ascii?Q?DhDzLVGlzVZcQNQ6yDAaRCU8xDdRVOVHd7FQObwSJPo+FQ8PztanOW/jGHZX?= =?us-ascii?Q?/A+1esibh7m/9baabOunZ8qsu1ZPHgWdGlgxQB0vPwiCfDaWc4umW6BQ3uEC?= =?us-ascii?Q?6/3nNQ7KgwLYORyTW4GUnzyiR9S4dGn6t4R4qOd8kcc/cg1cdnCxwUFGwiDi?= =?us-ascii?Q?lZfmYInDYBDD2dwkiRAiZ3dY4jSOq84aquWAXjvABV3SdpVYaKZzFwdMLLAn?= =?us-ascii?Q?9vebMGGeapntc9u7UuHDEvnc7dAUMci9WIgu7Qh/gEqngKolfno6gpivhcJZ?= =?us-ascii?Q?sjgyu48M+FKDjCtyKnOtfTZYx8Tca5V/oZOpAsCizod05DuHbkSYpHrK2txd?= =?us-ascii?Q?0xiebcrUN+4xjpmOFOKwKl4mxHugAlsS/6t1gykp+Au3F19SgkSXTS/NyUpq?= =?us-ascii?Q?mJgNbUERExz/1L8lY1umG92+NclOojgVIhxwb7NugLdjkYvsnaYKDw81Fw71?= =?us-ascii?Q?GZBlKLSZsKxXiGRwkORItHhPZj+86cUYqIjLay+PmKtgpe0m43nFWgMmM/R+?= =?us-ascii?Q?10N+go36SOwLtWQEenA2Rp/4g4Is5WbJvXG4qpdoBh13Tf+ntYNyE6eqeCdm?= =?us-ascii?Q?hFYjA6QPxP2efdSv49g04/CKzg8DtbDMgejaFR1pmMxOj8ix5SYDfEHAaGjT?= =?us-ascii?Q?Xss0aujNYYIdWzlYp8hB4pxCsS5f4SsCmSRRVmG6JeTCso4gQc2neBIIK7r7?= =?us-ascii?Q?6H9EnOR3upQA+Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB015; 5:nZ8YEkQCNW/cfbEY56xKC5f8lyCMJNOHQjm1QdM2Is3Z1LHInYs5MX6kqSWc2cQfPc0Db5WHqNevEOGvPKnr7XUBKX9joyFLCFjNVPkwx/OtaBSRS4yfiM4XPMmBY1vh5HLaYuwPh5KGlT9IZnXKqw==; 24:yse2WWhwTdxHm7KS6A2TM0wlHpRoIBbYHJeYWMiQG2NsHH8k2IFErjMDppQqadebqbpyb24swW3/NNshcNKwQet6EKde3QS3T/dtRkCsRbI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2016 21:28:18.1586 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB015 Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 21:28:28 -0000 --_000_e81f9ef93046453ca2de515821d937f1PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cool. I work about 5 miles from there and could probably get us a conferen= ce room for 100+ people with lots of cute microphones that hang from the ce= iling (but which might still provide the expected frustratingly bad audio f= or people on remote connections). Lots of good barbecue and other renowned= midwest attractions. e.g., good fermented and distilled grain spirits. From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger Sent: January 06, 2016 2:17 PM To: Modern List Subject: Re: [Modern] MODERN Interim Meeting Great. Let's do it in Lenexa. Centrally located. Equally bad for everybody. Also, it's only applicable to some of us, but the first week offered is the= DHS PI's meeting in Washington and the second week is the RSA Conference i= n San Francisco. On Jan 6, 2016, at 12:48 PM, McGarry, Tom > wrote: F2F encourages more rigorous discussion. You say so yourself. And that's = what we're looking for. We realize that not everyone can attend in person,= but as I said we will make sure to support the remote attendees. From: , Pierce Gorman > Date: Wednesday, January 6, 2016 1:43 PM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] MODERN Interim Meeting To be more clear. Mary's question wasn't what did you and the ADs hope for out of a face-2-fa= ce interim meeting. Mary's question was why is a face-to-face required instead of a virtual mee= ting with everyone equally disadvantaged? My question would have been why do we need an interim meeting? I believe there are members of the working group who have been, and felt, m= arginalized by both the definition of consensus and the inability to argue = about what occurred in a meeing halfway around the world where they either = weren't able to attend or were unable to attend equally with the participan= ts in the room face-to-face. One way to be more inclusive, and ensure greater (if somewhat disadvantaged= ) participation would be to hold the interim meeting (if it must be held) a= s an interim virtual meeting versus face-to-face. Since I'm new I don't know what is customary, but I inferred from Mary's qu= estion that a virtual meeting was customary (and certainly cheaper), and so= the question you failed to answer has additional merit. Pierce From: Gorman, Pierce A [CTO] Sent: January 06, 2016 12:24 PM To: 'McGarry, Tom' = >; Modern List > Subject: RE: [Modern] MODERN Interim Meeting You didn't answer Mary's question. From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: January 06, 2016 12:10 PM To: Modern List > Subject: Re: [Modern] MODERN Interim Meeting There will be remote access, video depending upon venue. I should have men= tioned this. We're hoping by having people f2f, with a good amount of time, to generate = some productive discussion. We expect remote participation and will certai= nly make sure that it can be effective. Thanks for responding to the poll. From: Mary Barnes > Date: Tuesday, January 5, 2016 6:49 PM To: Tom Mcgarry > Cc: Modern List > Subject: Re: [Modern] MODERN Interim Meeting I'm curious as to why a f2f meeting is being proposed as opposed to a virtu= al interim? The challenge is that when there are folks at a f2f meeting a= nd others trying to participate remotely, the remote participants are often= marginalized. It's surprisingly rare that people can get a meeting room s= etup that makes remote participation work well. Regards, Mary. On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom > wrote: Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in l= ate February to be held in the Washington, DC area. Please let us know wha= t dates work best for you. http://doodle.com/poll/5t5p98x5nnntmmcd Thanks, Tom _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off f= or details. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ 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_e81f9ef93046453ca2de515821d937f1PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cool.  I work about 5 miles from t= here and could probably get us a conference room for 100+ people with l= ots of cute microphones that hang from the ceiling (but which might still provide the expected frustratingly bad audio for people = on remote connections).  Lots of good barbecue and other renowned midw= est attractions.  e.g., good fermented and distilled grain spirits.

 

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of Eric Burger
Sent: January 06, 2016 2:17 PM
To: Modern List <modern@ietf.org>
Subject: Re: [Modern] MODERN Interim Meeting

 

Great. Let’s do it in Lenexa. Centrally locate= d. Equally bad for everybody.

 

Also, it’s only applicable to some of us, but = the first week offered is the DHS PI’s meeting in Washington and the = second week is the RSA Conference in San Francisco.

 

On Jan 6, 2016, at 12:48 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:=

 

F2F encourages more rigorous discussion.  You = say so yourself.  And that's what we're looking for.  We realize = that not everyone can attend in person, but as I said we will make sure to support the remote attendees.  

 

From: = ;<Gorman>, Pierce Gorman <Pierce.Gorman@sprint.co= m>
Date: Wednesday, J= anuary 6, 2016 1:43 PM
To: Tom Mcgarry &l= t;t= om.mcgarry@neustar.biz>, Modern List <modern@ietf.org><= br> Subject: RE: [Mode= rn] MODERN Interim Meeting

 

To be more clear.

 

Mary’s question wasn’t what= did you and the ADs hope for out of a face-2-face interim meeting.<= o:p>

 

Mary’s question was why is a face= -to-face required instead of a virtual meeting with everyone equally disadv= antaged?

 

My question would have been why do we n= eed an interim meeting?

 

I believe there are members of the work= ing group who have been, and felt, marginalized by both the definition of c= onsensus and the inability to argue about what occurred in a meeing halfway around the world where they either weren̵= 7;t able to attend or were unable to attend equally with the participants i= n the room face-to-face.

 

One way to be more inclusive, and ens= ure greater (if somewhat disadvantaged) participation would be to hold the = interim meeting (if it must be held) as an interim virtual meeting versus face-to-face.

 

Since I’m new I don’t kno= w what is customary, but I inferred from Mary’s question that a virtu= al meeting was customary (and certainly cheaper), and so the question you failed to answer has additional merit.

 

Pierce

 

From: Gorman, Pierce A [CTO] 
Sent: January 06, = 2016 12:24 PM
To: 'McGarry, Tom'= <Tom.McGarry@neustar.biz>; Modern List <modern@ietf.org&g= t;
Subject: RE: [Mode= rn] MODERN Interim Meeting

 

You didn’t answer Mary’s qu= estion.

 

 

From: Modern [m= ailto:modern-bounces@ietf.org] On Behalf Of = ;McGarry, Tom
Sent: January 06, = 2016 12:10 PM
To: Modern List &l= t;modern@ie= tf.org>
Subject: Re: [Mode= rn] MODERN Interim Meeting

 

There will be remote access, video depending upon v= enue.  I should have mentioned this.

 

We're hoping by having people f2f, with a good amou= nt of time, to generate some productive discussion.  We expect remote = participation and will certainly make sure that it can be effective.  

 

Thanks for responding to the poll.  

 

 

From: = ;Mary Barnes <mary.ietf.barnes@gmail.com&g= t;
Date: Tuesday, Jan= uary 5, 2016 6:49 PM
To: Tom Mcgarry &l= t;t= om.mcgarry@neustar.biz>
Cc: Modern List &l= t;modern@ie= tf.org>
Subject: Re: [Mode= rn] MODERN Interim Meeting

 

I'm curious as to why a f2f meeting is being propos= ed as opposed to a virtual interim?   The challenge is that when there= are folks at a f2f meeting and others trying to participate remotely, the remote participants are often marginalized.  It's surpr= isingly rare that people can get a meeting room setup that makes remote par= ticipation work well.  

 

Regards,

Mary. 

 

On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:

Due to the length of time between the last IETF and= the next, the chairs and AD believe we should have an interim meeting.&nbs= p; We're proposing dates in late February to be held in the Washington, DC area.  Please let us know what dates work best = for you.  

 

 

Thanks,

Tom


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

 

 

Learn more on how t= o switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates= . See sprint.com/50off = for details. 


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

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

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_e81f9ef93046453ca2de515821d937f1PLSWE13M08adsprintcom_-- From nobody Wed Jan 6 15:22:08 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 514DF1A1BC3 for ; Wed, 6 Jan 2016 15:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.324 X-Spam-Level: X-Spam-Status: No, score=0.324 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, HTTPS_HTTP_MISMATCH=1.989, 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 Nx40kU0tFBMR for ; Wed, 6 Jan 2016 15:22:02 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 4A2601A1BBC for ; Wed, 6 Jan 2016 15:22:02 -0800 (PST) Received: (qmail 31747 invoked by uid 0); 6 Jan 2016 23:21:59 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 6 Jan 2016 23:21:59 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id 2n1q1s00m1MNPNq01n1tNe; Wed, 06 Jan 2016 16:01:59 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=7aQ_Q-yQQ-AA:10 a=jqBRFv0mrdUA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=bfLuiRfvAAAA:8 a=hGBaWAWWAAAA:8 a=pGLkceISAAAA:8 a=_JY9ZxHVAAAA:8 a=xrOcWEd9QobsC7imNbEA:9 a=KgUIMHO_RGppw0re:21 a=u03RSnKCEgPDGRg9:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=RpNjiQI2AAAA:8 a=eHdfvDN03cgYDutuzigA:9 a=iV2-2ywOXX9cNb8e:21 a=iNXzRd3rUmRGv5oT:21 a=soJv_s_uhCasZzjt: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=JfeoWDALPQvILitDheKuPsgalSEf6zr1MEmyQRgklIw=; b=lVIYrHRvuM2Detr5EKOrpImPNGmyx6dzL5LjUNUa2vNvFwo9zoWUrv5WePA/9gu1H4EgV56bXEwYmyu+E80gXGXpQ+khCtFm1eCktfxOHzlxSEa38RlVoaMvSmNfV14w; Received: from [100.36.35.60] (port=65356 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aGx5S-0004wr-IC; Wed, 06 Jan 2016 16:01:50 -0700 User-Agent: Microsoft-MacOutlook/0.0.0.151217 Date: Wed, 06 Jan 2016 18:01:49 -0500 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Eric Burger , Modern List Message-ID: Thread-Topic: [Modern] MODERN Interim Meeting References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3534948110_1885320440" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 23:22:07 -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_3534948110_1885320440 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Did someone say barbecue? =20 Drat .. Forget Minneapolis .. KC or Austin for the permeant home of IETF m= eetings. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Modern on behalf of "Pierce.Gorman@sprint.= com" Date: Wednesday, January 6, 2016 at 4:28 PM To: Eric Berger , Modern List Subject: Re: [Modern] MODERN Interim Meeting Cool. I work about 5 miles from there and could probably get us a conferen= ce room for 100+ people with lots of cute microphones that hang from the cei= ling (but which might still provide the expected frustratingly bad audio for= people on remote connections). Lots of good barbecue and other renowned mi= dwest attractions. e.g., good fermented and distilled grain spirits. =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger Sent: January 06, 2016 2:17 PM To: Modern List Subject: Re: [Modern] MODERN Interim Meeting =20 Great. Let=E2=80=99s do it in Lenexa. Centrally located. Equally bad for everybod= y. =20 Also, it=E2=80=99s only applicable to some of us, but the first week offered is t= he DHS PI=E2=80=99s meeting in Washington and the second week is the RSA Conferenc= e in San Francisco. =20 On Jan 6, 2016, at 12:48 PM, McGarry, Tom wrote: =20 F2F encourages more rigorous discussion. You say so yourself. And that's = what we're looking for. We realize that not everyone can attend in person, = but as I said we will make sure to support the remote attendees. =20 =20 From: , Pierce Gorman Date: Wednesday, January 6, 2016 1:43 PM To: Tom Mcgarry , Modern List Subject: RE: [Modern] MODERN Interim Meeting =20 To be more clear. =20 Mary=E2=80=99s question wasn=E2=80=99t what did you and the ADs hope for out of a face-= 2-face interim meeting. =20 Mary=E2=80=99s question was why is a face-to-face required instead of a virtual m= eeting with everyone equally disadvantaged? =20 My question would have been why do we need an interim meeting? =20 I believe there are members of the working group who have been, and felt, m= arginalized by both the definition of consensus and the inability to argue a= bout what occurred in a meeing halfway around the world where they either we= ren=E2=80=99t able to attend or were unable to attend equally with the participant= s in the room face-to-face. =20 One way to be more inclusive, and ensure greater (if somewhat disadvantaged= ) participation would be to hold the interim meeting (if it must be held) as= an interim virtual meeting versus face-to-face. =20 Since I=E2=80=99m new I don=E2=80=99t know what is customary, but I inferred from Mary=E2= =80=99s question that a virtual meeting was customary (and certainly cheaper), a= nd so the question you failed to answer has additional merit. =20 Pierce =20 From: Gorman, Pierce A [CTO]=20 Sent: January 06, 2016 12:24 PM To: 'McGarry, Tom' ; Modern List Subject: RE: [Modern] MODERN Interim Meeting =20 You didn=E2=80=99t answer Mary=E2=80=99s question. =20 =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: January 06, 2016 12:10 PM To: Modern List Subject: Re: [Modern] MODERN Interim Meeting =20 There will be remote access, video depending upon venue. I should have men= tioned this. =20 We're hoping by having people f2f, with a good amount of time, to generate = some productive discussion. We expect remote participation and will certain= ly make sure that it can be effective. =20 =20 Thanks for responding to the poll. =20 =20 =20 From: Mary Barnes Date: Tuesday, January 5, 2016 6:49 PM To: Tom Mcgarry Cc: Modern List Subject: Re: [Modern] MODERN Interim Meeting =20 I'm curious as to why a f2f meeting is being proposed as opposed to a virtu= al interim? The challenge is that when there are folks at a f2f meeting an= d others trying to participate remotely, the remote participants are often m= arginalized. It's surprisingly rare that people can get a meeting room setu= p that makes remote participation work well. =20 =20 Regards, Mary.=20 =20 On Tue, Jan 5, 2016 at 3:29 PM, McGarry, Tom wrot= e: Due to the length of time between the last IETF and the next, the chairs an= d AD believe we should have an interim meeting. We're proposing dates in la= te February to be held in the Washington, DC area. Please let us know what = dates work best for you. =20 =20 http://doodle.com/poll/5t5p98x5nnntmmcd =20 Thanks, Tom _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern =20 =20 Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details.=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. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern =20 Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details.=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. _______________________________________________ Modern mailing list Modern@= ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3534948110_1885320440 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Did = someone say barbecue?  

Drat ..  Forget M= inneapolis .. KC or Austin for the permeant home of IETF meetings.


—&= nbsp;
Richard Shockey
Shockey Consulting LLC
C= hairman of the Board SIP Forum
www.shockey.us
www.sipfor= um.org
richard<at>shockey.us
Skype-Linkedin-Facebo= ok rshockey101
PSTN +1 703-593-2683


From: Moder= n <modern-bounces@ietf.org&g= t; on behalf of "Pierce.Gorman@spr= int.com" <Pierce.Gorman@spr= int.com>
Date: Wednesday, J= anuary 6, 2016 at 4:28 PM
To: Eric= Berger <eburger@standardstra= ck.com>, Modern List <modern@ietf= .org>
Subject: Re: [Modern]= MODERN Interim Meeting

Cool.  I w= ork about 5 miles from there and could probably get us a conference room for= 100+ people with lots of cute microphones that hang from the ceiling (but which might still provide the expected frustratingly bad audio for people = on remote connections).  Lots of good barbecue and other renowned midwe= st attractions.  e.g., good fermented and distilled grain spirits.=

 

=

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Eric Burger
Sent: January 06, 2016 2:17 PMTo: Modern List <modern@ietf.org= >
Subject: Re: [Modern] MODERN Interim Meeting

 

Great. Let’s do it in Lenexa. Centrally located. Equally bad f= or everybody.

 

<= /div>

Also, it’s only applicable to some of u= s, but the first week offered is the DHS PI’s meeting in Washington an= d the second week is the RSA Conference in San Francisco.

 

On Jan 6, = 2016, at 12:48 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:

 

F2F encourages more r= igorous discussion.  You say so yourself.  And that's what we're l= ooking for.  We realize that not everyone can attend in person, but as = I said we will make sure to support the remote attendees.  

 

From: = <Gorman>, Pierce Gorman <= Pierce.Gorman@sprint.com>
Dat= e: Wednesday, January 6,= 2016 1:43 PM
To: = Tom Mcgarry <tom.mcgarry@neustar.biz>, Modern List <modern@ietf.org&g= t;
Subject: RE: [M= odern] MODERN Interim Meeting

 

<= span style=3D"font-size:11.0pt;font-family:"Arial",sans-serif;color:= #0000CC">To be more clear.

 

Mary’s question wasn’t what did you and the ADs hope for= out of a face-2-face interim meeting.

 

Mary’s question was why is a face-to-face required= instead of a virtual meeting with everyone equally disadvantaged?

 

My question would have been = why do we need an interim meeting?

 

I believe there are members of the working group who have be= en, and felt, marginalized by both the definition of consensus and the inabi= lity to argue about what occurred in a meeing halfway around the world where they either weren̵= 7;t able to attend or were unable to attend equally with the participants in= the room face-to-face.

 

One way to be more inclusive, and ens= ure greater (if somewhat disadvantaged) participation would be to hold the i= nterim meeting (if it must be held) as an interim virtual meeting versus face-to-face.

 

Since I’m new I don’t know what is customary, but I inferred f= rom Mary’s question that a virtual meeting was customary (and certainl= y cheaper), and so the question you failed to answer has additional merit.

 

Pierce

 

From: Gorm= an, Pierce A [CTO] 
Sent= : January 06, 2016 12:24= PM
To: 'McGarry, = Tom' <Tom.McGarry@neustar.biz>; Modern List <modern@ietf.org>
<= b>Subject: RE: [Modern] = MODERN Interim Meeting

 

Y= ou didn’t answer Mary’s question.

 

 

From:<= /b> Modern [mailt= o:modern-bounces@ietf.org]&nb= sp;On Behalf Of McGarry, Tom
Sent: January 06, 2016 12:10 PM
To: Modern List <modern@ietf.org>
Subject: Re: [Modern] MODERN Interim Meeting

 

There will be remote access, video= depending upon venue.  I should have mentioned this.=

 

We're hoping by having people f2f, wit= h a good amount of time, to generate some productive discussion.  We ex= pect remote participation and will certainly make sure that it can be effective.  

 

Thanks for responding to the poll.  

<= /div>

 

 

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date:<= span class=3D"apple-converted-space"> Tuesday, January 5, 2016= 6:49 PM
To: Tom M= cgarry <tom.mcgarry@neustar.biz>
Cc: Modern List <modern@ietf.org>
Subject: Re: [Modern] MODERN Interi= m Meeting

&nbs= p;

I= 'm curious as to why a f2f meeting is being proposed as opposed to a virtual= interim?   The challenge is that when there are folks at a f2f meeting= and others trying to participate remotely, the remote participants are often marginalized.  It's surpr= isingly rare that people can get a meeting room setup that makes remote part= icipation work well.  

 

Regards,

Mary= . 

 

Learn more on how to switch to Sprint and save 50% on most Verizon, AT&a= mp;T or T-Mobile rates. See = sprint.com/50off for details. 

=

<= span style=3D"font-size:7.5pt;font-family:"Arial",sans-serif;color:g= ray">
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

 


Learn more on how to switch to Sprint= and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_3534948110_1885320440-- From nobody Sun Jan 10 15:37:04 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 4F0FF1A1AB1 for ; Sun, 10 Jan 2016 15:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0miaXkxsOpp for ; Sun, 10 Jan 2016 15:36:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F92C1A1A9A for ; Sun, 10 Jan 2016 15:36:35 -0800 (PST) Received: from BN1BFFO11FD038.protection.gbl (10.58.144.32) by BN1BFFO11HUB046.protection.gbl (10.58.144.193) with Microsoft SMTP Server (TLS) id 15.1.355.15; Sun, 10 Jan 2016 23:36:12 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.81) 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.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com; Received: from preapdm2.corp.sprint.com (144.230.32.81) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Sun, 10 Jan 2016 23:36:12 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u0AGsrqe038610; Sun, 10 Jan 2016 18:36:12 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm2.corp.sprint.com with ESMTP id 20av3u2t68-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 10 Jan 2016 18:36:12 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 10 Jan 2016 18:36:10 -0500 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; Sun, 10 Jan 2016 17:36:10 -0600 From: "Gorman, Pierce A [CTO]" To: "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4ABPUe9kA== Date: Sun, 10 Jan 2016 23:36:09 +0000 Message-ID: <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@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.214.116.34] Content-Type: multipart/alternative; boundary="_000_691495e5e2834619937f30fcccc78df6PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD038; 1:1eAdExl5Xn0XhKxOziXxruzUuOwprepnO2CRteynUFtpGrTCO2J63jfw9523rasQ+WFVS2P6Ye9vV1+Uhmuh43Y2bzLiew8LOxm4WoHftPfyRUee95WbEUa0fzappVoaPTgW8KBTmEWMoyTJDEo+w7hpf28gTvFr6grBlXddayfabEjtYcxW/WTRfiMME2CVVmQFEihdRR7y52T9LgfgXVoLCcsO2e26HLgUzk3r6w0yvuzNzrqCuEBwUPKjlrQQ6UChf8BfIvCbHvwY/sNO1hz52n0Yg4v57fg+0KBRy/R3bhjnwd7voAP/Xk1jtBqSA/M59fFT6R3AzBr15foS/DK8c6HBRyBfQpEM9GK1hAm3acoG80oyjlxFJ0WiUYFpTXT2N+/QxqZZC1qB82i9ww== X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(51894002)(189002)(199003)(149574003)(5003600100002)(24736003)(2900100001)(19625215002)(1220700001)(5250100002)(1096002)(76176999)(586003)(3846002)(11100500001)(15975445007)(84326002)(790700001)(92566002)(19617315012)(189998001)(102836003)(6116002)(86362001)(107886002)(50986999)(54356999)(5004730100002)(106466001)(33646002)(16236675004)(15395725005)(108616004)(4546004)(2501003)(87936001)(6806005)(300700001)(5001960100002)(512954002)(81156007)(5001770100001)(5008740100001)(260700001)(97736004)(2906002)(30436002)(19580395003)(19300405004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB046; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-MS-Office365-Filtering-Correlation-Id: ba54acb9-39c2-4df0-d231-08d31a16d34d X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB046; 2:3MBevt3MmmkJ1bvE7OTCNq8a53ButpK7O4Fo5qbNRnOkbmi00vmh+lykUHpbe3cuBrFuSaTq25EGrYJJWGP9R/gT1DEUXVPFrLewbQ/XiYcQ0FjakgE723jk+2WAIWaeghJFgTaUdoITvIWPywklooNWw1qhCejLNIHDCAbZWeLGb9lAKB75KZAJ/Q3TIlbP; 3:XpDNUgVIS1Z1Ntut7pznhGuNMQGqfh9LmFhktqBJkkuWiqioxTywVwAV4APchVYp1am3gS2uT/b5fKyb/8FwpHzlh4GvWgmwQCYTsTH7IfK7uWIlzDjqFmaQT0sU6ApWNrlJ5Dx8e72f7Aule7U4Yizu8/pSIw+YAXKDb3HAtzC5SKdh8r0Beiv66tlZBHMAGal9BDlycbjsT/4k1iCgPY+aIoI62TCme0Kd5q9y3paJ6fwgGh2yK+NUrpjBXvsBT+yrvPNUmJxTBKgCqrQwrA==; 25:vlV8+6DxIbS/nM3q9A2514L9bkmbX/LOPQPhBtI0ZIvE20Z8ieDWThAbjGDM65fWhYV7U4oJbhC/TUFFkuJMBQ/EwIW8A4PK34ZBU0UElHhNUYPfehHpXaIDE9YAUhbeB3pQukJUyHAfhVnNWfZp9B8t1FkjmOvTeUbrFVcaRvy8jS+xRWiZFpoKJN+vBjyfMYTQ/080EE588SiDesjfSC/U0fKyF3jQHpec8JYiHxApGfatXDhhVjyanjOckkmI X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1BFFO11HUB046; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB046; 20:xCDeQsf9cmiXNc1X4MOWbvpxytLcJckKK8MckL8yg/VMDXJp0j/+p0AS919wsbK5Q+pMBwOwVRXMoKPl95oc/YFUx3yCvJBCumQvky030p7N2gAeuYwsr5/HFQmzgS7w3pVqrdjlNE4SXnBbSc5nhOEt0NxFg4vxtPs+nq7Yv5WBuRIsloShpyfkNvFA0hPQ4lBgMRAP3bwK3xq4xp5wZO4EwNG5h2FEzqdPB5eChScIvU001vt6+PGGXERrzRLM; 4:beGPwgQopplSar3YRXhC4aXbrlwjSagH7ACFhMSDZ0p2xCmyJLZltn4FzgSXF2A6GXm6K+ctFayffUvdA+Ovdqkyy4c06XcLIuAcB+JL82M/uXKsMO5mUzvUwuc0+Ab956blYnEy2angxUQQpMmQ0Fj9Sjei3NOcrmdyIq03P5dc2r9PBokqvRllr91ag+xLnGeD+vQ8qt4Ce/mNGnt5lqQGQ+CKgrWjq3NRtshlaQC1+TJL/+disuNPtngsxOfP4C+ga9jXspESWLObZEANPx2XT/kA1voPA2Azz1D0d7uqP4eq8j9VVkLyAvFkUAd/hXJGQ4xCKxoJAQ6IJtacwKJfWzimdss7i76YLNvmQyoQcR6SvVO087b6JEkVT9mkesN6LoUVj85J5iUOiEe4qJSrzYGDqfJHVCp88j5rr7AM+DiYF3gNV8dGokjVTehfs4iptiFWt50lHLyhA07n/4eSOGcpCcr32xzDe4QEJjs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(13015025)(13018025)(13017025)(10201501046)(3002001); SRVR:BN1BFFO11HUB046; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB046; X-Forefront-PRVS: 0817737FD1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB046; 23:9uBtgSQtrlHP3CrInNgO5dfC9wkHvB9YPHEoyxT?= =?us-ascii?Q?S+U4qUDNAwZG+yiwTrywEJ12XvfFmMccqAsTNwaB5pmdZ7Cq/PJoOm5Z/vEl?= =?us-ascii?Q?IYlMqx/o2r2NTnImRsV1ga582fgVFL9M2TBsy/2UjzBeDCBUa2j7D3F5/MSI?= =?us-ascii?Q?IeIzU9Z6heAEYItGjELIVtZdensx7CviYmd97n3SFDUJIpZ0SX0Rbn9O0aua?= =?us-ascii?Q?YW6T23yQeFVhcGFpOzEwx+eaky3tERVQFVSrb4ZtxNq4NO69S3cld6HFc/G3?= =?us-ascii?Q?tBIGkJdPo2C1ZqRa8p6GIHMLrB+p88aQvIh1qdFdMm0Xy2B8duKIBZsYs9DD?= =?us-ascii?Q?CxpBzjgCSugIila7NXphZNelbjjIoz1O7XDvnO+oKaJqwQ63XqABhu11ug3l?= =?us-ascii?Q?2+UODUXaZYiQVg0apEjVoDrdPQ58aaCuXU2Kw7oK0hns83ti2cow/7YkVtDY?= =?us-ascii?Q?bmg8ba440CXJiLwZu3dBgl0T4nKTXLzDVdBzSj/UlW+o0oMutqr99LF/qria?= =?us-ascii?Q?VtCSVVsBEgkxGp/xIk3Zl3h74EIepwbsIvYc+ZwPOB2FzwEoneX/OPGPYDuP?= =?us-ascii?Q?OSUtPBGQWq0hG2mAdIkyTsvNOca9kV4wxGOozFmLgrPK22eJxq9Q6sPqoVb0?= =?us-ascii?Q?56mteI8Wdas1ngH6w9pYjeCrYmXB6+u7HIqyl72vble8HPNQt38lmp4+lDQh?= =?us-ascii?Q?Eo6uDyqgNhxvNQhioFtiMezc9V2kcXJRL1T7Um9YbgWTUW268KNtiEDsN/wQ?= =?us-ascii?Q?miBEkTxSSvcY3yAJMyFcSEqH23mqf4bR0UITKKVE6CpJMExdqcCaRhxTXxD1?= =?us-ascii?Q?UO1cmoB2BoLWix5Cv/KriUFAoA7QbAjVITS1lNqMDCQvVZbLoFA7RSuJU0wb?= =?us-ascii?Q?FvOwO/0DQCFkazM+6rSVN75y97NazJ4d42s5P5mac7UP9Q9qqPRsTmn+Sq9y?= =?us-ascii?Q?dn5z7j/MSsSIXeN0ZKg+y7fdH0ZBbLlfbyvx9ZWr9yrNAkUVt694FIYRTtiD?= =?us-ascii?Q?72VJaatA0zTdSYG1fjzDTAam42PdLrGxpkrh+r8gnniAos9xj1ZfXoME2qMC?= =?us-ascii?Q?Cw6YL1G4YRD/3VpPBq++iuOQGkFZTlDQV+vyIO5tn1mXj797EB+e/g81fMi1?= =?us-ascii?Q?8lKxpKsBg0Z4c8LAf4IAwPmKZ3lrfRXdWprxm7zJjf4J4htfikmaVM156DKk?= =?us-ascii?Q?YurodtJB6DMRvJZFbROLa03aL5kchUQLxzkz4X+/S213LBtia0RaE2d2trtu?= =?us-ascii?Q?CPm6ErUOz0kSaB5cXcTpd+A8iShxMTr8/P1/Vx1Zx1jxXvDk3X4KMyZAyVwd?= =?us-ascii?Q?FZE2QX0A3Fdr8FWScHcJpdNy7f5e9n5kNOv5gcpGRVGzmpDJ/2DOHIxL2ENy?= =?us-ascii?Q?UASmuDtd2eUvlJp10EV7iCxoHFCg=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB046; 5:UJh/iEb6Oo986bufAAVsy3xtpdz7lOTsI/q2G79af+M7XtspJo8fmM6opoiOyMlPfNmKtv/L/vcUKyVdCCnFpuoaZfktPpQwytUckIyyVtwoQjxnlPkneDJFmtQr7k9xJJuyNMWIkU8PjCCLwNm6pA==; 24:N87QuEmxutjfvR/jzYlVy6BTPsn6YVKdf1qUz77VPHX5GUxQsV0+svllz/UOoPJqkFxBUB1TCskFdX+r60kPBEc6jE7kD3jvuEHBc/6nH6U= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2016 23:36:12.4819 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB046 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 23:36:50 -0000 --_000_691495e5e2834619937f30fcccc78df6PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As promised, below are my remaining edits and editorial comments. The format of my comments is as follows: - Section reference - Quoted content from the Problem Statement - Recommended edits and/or editorial comments I'll preface the work below by saying I have completely read the document w= ord for word and my previous estimation remains that the main issue with th= e problem statement is that it fails to meet the burden of proof that there= is a problem that needs to be solved. A problem statement is something like, "The alligators in the swamp adjoini= ng my back yard keep eating my pets." A solution statement would be something like, "In order to deal with the is= sue(s) outlined in the problem statement, it is recommended that a strong f= ence be constructed (which prevents access to my pets from alligators in th= e swamp adjoining my back yard)." 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. Respectfully, Pierce Gorman _________________________________________________________ 1. Problem Statement "In an Internet environment, establishing a network architecture for routin= g TNs would depend little on geography." I recommend changing the word "would" in the previous sentence to "could". At a minimum the routing of calls to and from TNs is impacted by the geogra= phy and the policies of the nation in which the TN is assigned regardless o= f the layer 2/3 network transport. The fundamental problem with the line o= f reasoning in this sentence is that it misses the fact that geography is a= key consideration in TN assignment, service provisioning, delivery and ass= urance, that must not be dismissed or overlooked but recognized and dealt w= ith. "Adapting TNs to the Internet requires more security, richer datasets and m= ore complex query and response capabilities than previous efforts have prov= ided." Can you provide comparative examples to"previous efforts" illustrating why = more security, richer datasets and more complex query and response capabili= ties are required? If so, it will be helpful to the reader. If not, then = you should strike the sentence. "With the PSTN well on its way to transitioning to an all IP network,and TN= s showing no signs of sunsetting as a resource, it is time to address the i= ssues of routing, management and administration of TNs in an IP environment= ." The subject at the end of the sentence is ironically juxtaposed to the preq= ualifying assumptive phrases at the beginning of the sentence. That is, if the PSTN is already "well on its way to transitioning to an all= IP network", then how can it be that now is the "time to address the issue= s of routing, management and administration of TNs in an IP environment?" It can be argued that the proof that those issues have already been address= ed adequately is the very the fact that the PSTN is already "well on its wa= y to transitioning to an all IP network". I would strike the sentence as being unnecessary to the MODERN problem stat= ement. Section 2.1 "The following actors are defined in this document: Numbering Authority: A regulatory body within a country that manages that = country's TNs. The Numbering Authority decides national numbering policy, = including what TNs can be allocated, and which are reserved." Countries can and do have more than one numbering authority. Either change= the wording or change the actor name to "National Numbering Authority" and= add a subcategory for "Regional or otherwise subtended Numbering Authority= (to the National Numbering Authority)". I would change "The Numbering Authority decides national numbering policy" = to "The Numbering Authority decides numbering policy for the nation, region= , or other domain for which it has authority". "There are two types of Registries an authoritative Registry and a distribu= ted Registry. An authoritative Registry is a single entity with sole responsibility = for specific numbering resources. Distributed Registries are multiple Registries responsible for the same num= bering resources. (There's more on distributed Registries later in this se= ction.) The general term Registry in this document refers to both kinds of Registri= es. When referring to one versus the other this document will use the spec= ific term." I recommend breaking out each registry type as it's own actor. I also am struggling with your use of the term "registry" whereas I think y= ou're referring not so much to registries (i.e., database services) so much= as database models with respect specifically to non-duplicated versus dupl= icated data. The database models you described can have hybrids. One hybrid could be multiple independent distributed (in the sense that the= y are non-collocated and/or in different administrative domains) databases = who collectively represent an authoritative (i.e., non-duplicative) set of = assignment data. An example of this model would be the set of .com top-lev= el domain name databases. Another hybrid could contain top level (e.g., Numbering Plan Area) assignme= nts maintained in a single national-level non-duplicative authoritative dat= abase and subtending assignments maintained in distributed (non-duplicative= or duplicative) databases managed by regional numbering authorities. "User: An individual reachable through a communications service; usually a= customer of a communication service provider who uses TNs to reach and ide= ntify services. Sophisticated users may also act as their own CSPs." The "User" actor definition is ambiguous. To reduce ambiguity consider striking the phrase, "...who uses TNs to reach= and identify services" from the first sentence of the definition (assuming= the phrase refers to the CSP and not the User). The phrase is uncessary a= nd does not add clarity. I recommend striking the 2nd sentence, "Sophisticated users may also act as= their own CSPs." Doing so would not presumably preclude a sophisticated u= ser from being a CSP, but it appears to be a statement of policy or capabil= ity and isn't clear in either case. "Government Entity: An entity that, due to legal powers deriving from nati= onal policy, has privileged access to information about number administrati= on under certain conditions. Note that a given entity may act in one or more of the roles above. An enti= ty acting as a CSP, Service Enabler, or User can also be said to have a rel= ationship to the Registry of either an assignee or delegate:" The "entity" stuff is confusing. Are you indicating that an "entity" is somehow different from an "Actor"? = Or, are you saying that an entity is a special kind of "Actor"? How about replacing the phrase, "a given entity" with the phrase, "an actor= "? How about removing the phrase, "An entity acting as" in the 2nd sentence of= the 2nd paragraph? "Assignee: An entity that is assigned a TN by the Registry. There is alwa= ys a direct relationship between the Registry and the assignee. Delegate: An entity that is delegated a TN from an assignee or another del= egate. Delegates may use a TN for a communications service or delegate it = in turn." I didn't understand the need for the qualification, "There is always a dire= ct relationship between the Registry and the assignee" in the definition of= the Assignee actor. I would avoid the use of the term, "entity", and replace the entire Assigne= e actor definition with the following: "Assignee: An actor that is assigned a TN by the Registry." Similarly, I would replace the word "entity" with "actor" in the definition= for Delegate. The second sentence in the definition of the Delegate is confusing and ambi= guous. The phrase "Delegates may use a TN for a communications service" is written= such that it could imply that a TN could be used as a form of communicatio= ns service although clearly this wasn't the intent. And the end of the sen= tence referring to additional delegation is too open-ended and should not b= e combined with the first part of the sentence. I recommend breaking the sentence into 2 parts. First change the phrase, "Delegates may use a TN for a communications servi= ce" to be a sentence reading, "Delegates may associate a TN with a communic= ations service." Second change the phrase, "or delegate it in turn" to be a sentence reading= , "Delegates may delegate one or more of their TN assignment(s)to one or m= ore further downstream subdelegates who may also delegate their assignment(= s). There can be up to 1024 levels of sub-delegation." (Just kidding abou= t the 1024 levels, but you get the idea.) Section 2.2 "Administrative Data: assignment data related to the TN and the relevant a= ctors; it includes TN status, contact data for the assignee or delegate, et= c. and typically does not require real-time performance." What is meant by "TN status"? If the definition of "TN status" is clear, unambiguous, and short, use that= instead. If it is not, delete it from the definition of "Administrative D= ata". "Service Data: data necessary to enable service for the TN; it includes ad= dressing data, feature capabilities, etc. and typically does require real-t= ime performance." If examples or the definition of "feature capabilities" is clear, unambiguo= us, and short, use that instead. If it is not, delete it from the definiti= on of "Service Data". Delete "etc.". Define what is meant by "real-time performance" in the context of it being = a requirement. i.e., what part of the problem statement indicates a need f= or real-time, or non-real-time performance? If we look at existing numbering and registration systems (in North America= ) as an example, what about their real-time, near-real-time, or non-real-ti= me performance is a problem to be solved? "Public: data that anyone can access, for example a list of which numberin= g resources are available for acquisition from the Registry." Define "numbering resources". Define "available". "Semi-restricted: data that a somewhat broad subset of actors can access, = for example CSPs may be able to access other CSP's service data." Delete the words "somewhat broad". Delete the example. Defining policy should be outside the scope of the pro= blem statement should it not? "Restricted: data that is only available to a small subset of actors, for = example a Government Entity may be able access contact information for a Us= er." Delete the example. As you acknowledge there are really only two categories; unrestricted and r= estricted. Degree of restriction is a matter of policy. 2.3 Data Management Architectures "Beyond traditional centralized Registries, this framework also supports en= vironments where the same data is being managed by multiple entities, and s= tored in many locations." I would delete this paragraph for being inappropriate to a problem statemen= t. Save it for the solution to the problem(s). "Data store: a service that stores and enables access to administrative an= d/or service data. Typically Registries and CSPs would manage data stores.= " I would delete the last sentence, "Typically Registries and CSPs would mana= ge data stores." "Reference Address: a URL that dereferences to the location of the data st= ore." This is an artifact of a presupposed solution to a problem and does not bel= ong in a problem statement. I would delete this and save it for a solution= statement. "Distributed Registries: refers to multiple Registries managing the same n= umbering resource. Actors could interact with one or multiple Registries. = The Registries would update each other when change occurs. The challenge = is to ensure there are no clashes, e.g., two Registries assigning the same = TN to two different actors." Define "numbering resource". I would delete, "The Registries would update each other when change occurs.= The challenge is to ensure there are no clashes, e.g., two Registries ass= igning the same TN to two different actors." These statements presuppose a solution architecture and make assumptions ab= out the type of TN being assigned. These statements do not belong in a pro= blem statement. They should be saved for a solution statement. 3. Framework "The framework outlined in this document requires three Internet-based mech= anisms for managing and resolving TNs (TNs) in an IP environment. These me= chanisms will likely reuse existing protocols for sharing structured data; = it is unlikely that new protocol development work will be required, though = new information models specific to the data itself will be a major focus of= framework development. Likely candidates for reuse here include work done= in DRINKS and WEIRDS, as well as the TeRQ [12] framework. These protocol mechanisms are scoped in a way that makes them likely to app= ly to a broad range of future policies for number administration. It is no= t the purpose of this framework to dictate number policy, but instead to pr= ovide tools that will work with policies as they evolve going forward. The= se mechanisms therefore do not assume that number administration is central= ized, nor that number "ownership" is restricted to any privileged service p= roviders, though these tools must and will work in environments with those = properties." The first sentence in the first paragraph has parentheses around the acrony= m TN without spelling out the acronym. Either eliminate the parenthetical = TN or spell out Telephone Number. Here I will also mention that Telephone = Number is an ambiguous and increasingly anachronistic term that might be be= tter served being replaced by the term "E.164 number". I would delete the sentence, "Likely candidates for reuse here include work= done in DRINKS and WEIRDS, as well as the TeRQ [12] framework." It is an= editorial opinion and not necessarily appropriate to a problem statement. "Acquisition: a protocol mechanism for acquiring TNs, including an enrollm= ent process." Define "enrollment". Does "enrollment" imply or mean "subscription"? "Retrieval: a protocol mechanism for retrieving data about TNs from either= an authority or a CSP." I would delete the end of the definition beginning with the word "from". I= t presupposes a solution architecture and is not appropriate to a problem s= tatement. "The acquisition mechanism will enable actors to acquire TNs for use with a= communications service. The acquisition mechanism will provide a means to= request numbering resources from a service operated by a Registry, CSP or = similar actor. TNs may be requested either on a number-by-number basis, or= as inventory blocks. Any actor who grants numbering resources will retain= metadata about the assignment, including the responsible or individual to = whom numbers have been assigned." Define "numbering resources". Insert the word "parties" between the words "responsible" and "or" in the = last sentence. Should the paragraph describing acquisition mechanism be included as a subp= aragraph under the initial definition of "Acquisition"? "The management mechanism will let actors provision data associated with TN= s at CSPs. For example, if a User has been assigned a TN, they may select = a CSP to provide a particular service associated with the TN, or a CSP may = assign a TN to a User upon service activation. In either case, a mechanism= is needed to provision data associated with the TN at that CSP." To me, the first sentence is ambiguous with respect to where management act= ion is taking place. Are you indicating management of TN and TN-associated= information withing the corporate database of a CSP? Or, are you indicati= ng the ability to manage the TN and TN-associated information within a MODE= RN database hosted by one or more MODERN-enabled registries? The latter of the two possibilities seems less fraught with legal and opera= tional problems. I would have just assumed the latter except for your add= itional remarks about the "retrieval mechanism". More on that below, but = here I'll just state my opinion you should confine your scope to the public= realm (as inferred in the last sentence of the charter) and will direct mo= st of my remarks as though you agreed. Perhaps change the first sentence to read, "The management mechanism will p= ermit actors to provision data associated with TNs within registries." And change the last sentence to be, "In either case, a mechanism is needed = to provision data associated with the TN within registries." Should the paragraph describing the management mechanism be moved to be a s= ubparagraph under the initial definition of "Management"? "The retrieval mechanism will enable actors to learn information about TNs,= typically by sending a request to a CSP. For some information, an actor m= ay need to send a request to a Registry rather than a CSP. Different parti= es may be authorized to receive different information about TNs." The Charter implies the output of the working group is a a potentially glob= al process and method which user and CSP actors would use to manage TN assi= gnment and the metadata associated with the TN. I'm stunned that you're also recommending that the framework include a requ= irement for user actors to be able to directly manage TN and TN metadata wi= thin a CSP actor's private corporate database. My opinion is you should confine your scope to the public registry realm an= d avoid creating mechanisms and frameworks which force CSPs to expose their= private corporate databases in any particular way. CSPs often (and increasingly so) make user-defined provisioning options ava= ilable as a matter of competitive advantage, but creating an IETF-designed = requirement to do so as part of a TN and TN metadata management framework i= s not advisable. It makes adoption hurdles more difficult and therefore in= creases the chances that MODERN is more narrowly accepted, if at all. If you want your work used, you should aim for the broadest possible adopti= on and requiring user actor access to CSP actor information is probably goi= ng to harm your chances of achieving your goals. I recommend you confine y= our framework and design to publicly-held and managed implementations. Many IETF protocols and mechanisms have been the source of cyberplagues and= MODERN is an obvious target. If you have a specific kind of information t= hat you think would only be available to a CSP actor and that MUST be direc= tly retrievable or changeable by user actor having direct access to a CSP a= ctor's database, then you should state what that information is and why tha= t steers away from a design using an indirect method through a public regis= try. 4. Use Cases 4.1 Acquisition "There are three actors from which numbers can be acquired: a Registry, a C= SP and a User (presumably one who is delegating to another party). In these= use cases, a User may acquire TNs either from a CSP or a Registry, or from= an intermediate delegate." The use of the term "delegate" is very loose in this document. The definit= ions and use cases seem to imply delgation and subdelegation between user, = CSP, and service enabler actors can cascade factorily. I appreciate that Section 4.1.1 tries to more precisely outline and proscri= be possible or probable assignee and delegation relationships. This is nec= essary. It would be good if you could also describe what are the expected = reasons for having permitted/designed those relationships. Section 4.1.1 CSP Aquires TN from Registry "The Registry maintains a profile of the CSP and what qualifications they p= ossess for requesting TNs." Please explain (somewhere) what is meant by "a profile of the CSP". Please outline why it is important for the registry to maintain a profile t= hat contains the CSP "qualifications they possess for requesting TNs". Is there also an expectation that a registry should also maintain profiles = of users and the "qualifications they possess for requesting TNs"? The suggestion of using the MODERN numbering management process to also per= form key management for another IETF initiative (STIR) is sensible in the c= ontext of advocates of MODERN promoting other favorite sons, but hopefully = won't be a detailed part of the MODERN number management solution. It is f= ine to suggest it as a plausible thing to do, but there isn't anything like= consensus with regard to whether STIR is a good or favored approach for au= thenticating calling identity and should be outside of the scope of MODERN. I'm going to skip over making any further comments on the various MODERN us= e cases. They would have been useful as part of a definition of terms from= which a problem statement was constructed. In the case of this document t= hey are presented as functional parts of a MODERN solution framework, not a= problem statement. 4.2 Management "While some similar use cases may apply to individual Users, it is anticipa= ted that for the most part these lower-level service information changes wo= uld be communicated via existing protocols (like the baseline [2] SIP REGIS= TER method) rather than through any interfaces defined by MODERN." The above paragraph is duplicated in it's entirety across pages 10 and 11. = Delete the duplicate that ends on page 11. 4.2.2. Management of Service Data "Service data is data necessary to enable communications service to the del= egate or User, for example a SIP URI." This is naive. It assumes a simple single SIP URI would be sufficient "to = enable communications service to the delegate or User". A consequence of private interconnection networks used for exchanging peeri= ng traffic between CSPs (which is the norm) means that a single SIP URI is = almost certainly out of the question. As I tried to explain in on-line dis= cussions about numbers and geography, call routing of services to a TN ofte= n requires knowing where the call is originating (either physically and/or = logically) and then using the terminating address that makes sense in the c= ontext of the originating network. This oversimplified model of how call routing works is a weakness of the MO= DERN TN information management model. CSPs often have multiple (and regional) physical and logical private and pu= blic network boundaries using a mixture of private (e.g., RFC1918) and publ= ic IP (IPv4 or IPv6) addressing. This impacts managing SIP URIs associated= with a TN and what the visibility should be to those URIs and by whom. It= eliminates any practical possibility that a single URI is sufficient. URI information associated with a TN will be different for different interc= onnection relationships which steers toward a distributed database model ma= intained largely by and for CSPs moreso than end-users and governments. (I= think you tacitly acknowledge this in section "4.2.2.1. CSP to other CSPs= ".) 4.2.2.3. User to Registry "As stated already the protocol should enable Users to acquire TNs directly= from a Registry and in essence act as their own CSP." This is just impractical in the case where there are tens or hundreds, or e= ven thousands of millions of users (which is all of the important cases) be= cause the registry cannot possibly vet with any usable reliability the trus= tworthiness of this many actors let alone prosecute them. Ask anyone whose= worked in the US Internal Revenue Service. They can't possibly know if al= l of the "users" are alive, dead, illegal aliens or where they say they are= , or whether they appropriately paid their taxes. Tax fraud is a multi-bil= lion dollar problem. If we overlay that model on management of TNs, you ca= n practically guarantee that STIR will be of no use whatsoever. The reality is users are going to want (and should be permitted) multiple T= Ns, but the management of their access and use has to be delegated to organ= izations who have a vested interest in being able to recover the TNs, make = efficient use of them, and who can prosecute the users if there is a proble= m. That is, the government needs to give inventory to CSPs who then need t= o manage the users' use of it. 4.2.3.1. Changing the CSP for an Existing Communications Service "The User provides their credential to the new CSP and the CSP initiates th= e change in service." No argument with the method, but will mention at least two large regulatory= environments do not embrace it. You should consider how to integrate othe= r methods such as requesting that the old CSP move the TN assignment to the= new CSP. "The old credential is revoked and a new one is provided." This seems to imply an integrated STIR or STIR-like function which might ma= ke sense but should be outside of the scope of MODERN. I recommend deleting all references to credential management that fall outs= ide of section 4.1. use case examples. "[TBD - more on the case where multiple CSPs provide services for a given T= N, and only one service is "ported" to a new CSP?]" This is actually one of the more important use cases in my mind but not as = a part of a problem that MODERN is required to solve. Based on what I've r= ead of problems in the so-called "problem statement" I still don't believe = MODERN is required. Regardless, the use case is valid and important. I have a sincere frustration that my e-mail address is broken if I move my = e-mail between e-mail service providers. I would much prefer to have e-mai= l address portability. I could easily have this if my e-mail address were = based on my TN. This is an example of where TNs are far superior to domain= names. They are not vulnerable to international character set exploits, e= t cetera. So, I am very sympathetic to a broadened use of TNs and associat= ing metadata (such as e-mail URI) to them for the very purpose of enabling = portability between CSPs if nothing else. It's just that MODERN isn't requ= ired in order to achieve this outcome and benefit. 4.2.3.2. Terminating a Service "In an alternative use case, a User who received their own TN assignment di= rectly from the Registry terminates their service with a CSP. At this time= , the User might terminate their assignment from the Registry, and return t= he TN to the Registry for re-assignment. Alternatively, they could retain t= he TN and elect to assign it to some other service at a later time." I'll encourage others who know more about TN inventory management, but on t= he surface this and delegation look promising for providing an environment = ripe for problems with fraud, abuse, and number exhaust. 4.3.1. Retrieval of Public Data "Under most circumstances, a CSP wants its communications service tobe publ= icly reachable through TNs, so the retrieval interface supports public inte= rfaces that permit clients to query for service data about a TN. Some serv= ice data may however require that the client by authorized to receive it, p= er the use case in Section 4.3.3 below. Public data can simply be posted on websites or made available through a pu= blicly available API. Public data hosted by a CSP may have a reference add= ress at the Registry." One of the robocalling problems plaguing the industry are calls that are ap= parently sequencing through number blocks in an apparent attempt to identif= y which numbers are assigned and which are not. The intentions of the robo= callers wanting this information are suspect and assumed to be bad. Making= the information publicly available on the Internet may actually put the pu= blic at risk of material harm. Ask any mobile user if they would prefer th= at their TN and CSP information be available on a public database and see w= hat they say. Most of this paragraph is of a policy nature and does not belong in a probl= em statement or an RFC. Section 4.2.3.2 has similar weaknesses. i recomme= nd removing any references to policy. 4.3.2. Retrieval of Semi-restricted Administrative Data "A CSP is having service problems completing calls to a specific TN, so it = wants to contact the CSP serving that TN." This is not representative of how trouble management is handled in the US. = Trouble management is between carriers with Inter-Connection Agreements, n= ot between originating and terminating carriers. I believe the sentence and example does not contribute usefully to the sect= ion. I recommend deleting it. 4.3.3. Retrieval of Semi-restricted Service Data "There are multiple scenarios to for the query and response." Delete either the word "to", or the word "for" from the sentence. I recomm= end deleting "to". 5. Distributed Registries and Data Stores "For example, when a CSP enables service for a User they can initiative an = update of the service address to multiple other data stores managed by othe= r service providers." The word "initiative" should be changed to "initiate". The phrase "[More TBD]" should be removed or more should be added. 8. Security Considerations "TBD." This is a bigger handwave then the usual caveat that security is important = and be careful because the authors didn't know what else useful to write. I recommend adding the usual useless boiler-plate, or actually try to intro= duce discussion and description about potential fraud and abuse issues from= malintentioned User actors being able to directly request and manage the m= etadata associated with their own TN number assignments or the unrestricted= public data of other TN and associated CSP assignments. ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off for details. ________________________________ 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_691495e5e2834619937f30fcccc78df6PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As promised, below are my remaining edits and edi= torial comments.

 

The format of my comments is as follows:

 

- Section reference

- Quoted content from the Problem Statement<= /o:p>

- Recommended edits and/or editorial comments

 

I'll preface the work below by saying I have comp= letely read the document word for word and my previous estimation remains t= hat the main issue with the problem statement is that it fails to meet the = burden of proof that there is a problem that needs to be solved.

 

A problem statement is something like, "The = alligators in the swamp adjoining my back yard keep eating my pets."

 

A solution statement would be something like, &qu= ot;In order to deal with the issue(s) outlined in the problem statement, it= is recommended that a strong fence be constructed (which prevents access t= o my pets from alligators in the swamp adjoining my back yard)."

 

The MODERN problem statement is in fact a TN mana= gement solution framework.  i.e., a solution looking for a problem.

 

If there is a problem that MODERN addresses, it i= s the inability of end users to directly (through a protocol) manage requis= ition and release of TNs and manage their associated metadata.  This i= s not a protocol problem.  It is a policy problem (if it is a problem at all).  And the only provisioning proto= col I remember seeing referenced in the solution statement is a SIP REGISTE= R.  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 start over.  Do not introduce any text that even= resembles a solution framework.  The problems can then be easily iden= tified and discussed.  And I encourage discussion of policy as part of the problem so that in the end you can hopefully clea= rly differentiate between issues that are political and issues which are te= chnical and therefore appropriate for the MODERN WG.

 

Respectfully,

 

Pierce Gorman

_____________________= ____________________________________

 

1.  Problem Statement

 

"In an Internet environment, establishin= g a network architecture for routing TNs would depend little on geography.&= quot;

 

I recommend changing the word "woul= d" in the previous sentence to "could".

 

At a minimum the routing of calls to and= from TNs is impacted by the geography and the policies of the nation in wh= ich the TN is assigned regardless of the layer 2/3 network transport.  The fundamental problem with the line of reasonin= g in this sentence is that it misses the fact that geography is a key consi= deration in TN assignment, service provisioning, delivery and assurance, th= at must not be dismissed or overlooked but recognized and dealt with.

 

&quo= t;Adapting TNs t= o the Internet requires more security, richer datasets and more complex que= ry and response capabilities than previous efforts have provided."

 

Can = you provide comparative examples to"previous efforts" illustratin= g why more security, richer datasets and more complex query and response ca= pabilities are required?  If so, it will be helpful to the reader.  If not, then you should strike the sentence.

 

&quo= t;With the PSTN = well on its way to transitioning to an all IP network,and TNs showing no si= gns of sunsetting as a resource, it is time to address the issues of routing, management and administration of TNs in an IP envir= onment."

 

The = subject at the end of the sentence is ironically juxtaposed to the prequali= fying assumptive phrases at the beginning of the sentence.

 

That= is, if the PSTN is already "well on its way to transitioning to an all IP network", then how can it be that now is the "time to a= ddress the issues of routing, management and administration of TNs in an IP= environment?"

 

It c= an be argued that the proof that those issues have already been addressed a= dequately is the very the fact that the PSTN is already "well on its way to transitioning to an all IP network".<= o:p>

 

I wo= uld strike the sentence as being unnecessary to the MODERN problem statemen= t.

 

Sect= ion 2.1

 

&quo= t;The following = actors are defined in this document:

 

Numbering Authority:  A regulatory body = within a country that manages that country's TNs.  The Numbering Autho= rity decides national numbering policy, including what TNs can be allocated, and which are reserved."

 

Coun= tries can and do have more than one numbering authority.  Either chang= e the wording or change the actor name to "National Numbering Authorit= y" and add a subcategory for "Regional or otherwise subtended Numbering Authority (to the National Numbering Authority)".=

 

I wo= uld change "The Numbering Authority decides national numbering policy" to "The Numbering Authority decides numbering policy for the nation, region, or other domain for which it has authority".<= o:p>

 

&quo= t;There are two = types of Registries an authoritative Registry and a distributed Registry.

 

An authoritative Registry is a single entity = with sole responsibility      for specific numberi= ng resources.

 

Distributed Registries are multiple Registrie= s responsible for the same numbering resources.  (There's more on dist= ributed Registries later in this section.)

 

The general term Registry in this document re= fers to both kinds of Registries.  When referring to one versus the ot= her this document will use the specific term."= ;

 

I re= commend breaking out each registry type as it's own actor.

 

I al= so am struggling with your use of the term "registry" whereas I t= hink you're referring not so much to registries (i.e., database services) s= o much as database models with respect specifically to non-duplicated versus duplicated data. 

 

The = database models you described can have hybrids.

 

One = hybrid could be multiple independent distributed (in the sense that they ar= e non-collocated and/or in different administrative domains) databases who = collectively represent an authoritative (i.e., non-duplicative) set of assignment data.  An example of this m= odel would be the set of .com top-level domain name databases.

 

Anot= her hybrid could contain top level (e.g., Numbering Plan Area) assignments = maintained in a single national-level non-duplicative authoritative databas= e and subtending assignments maintained in distributed (non-duplicative or duplicative) databases managed by regio= nal numbering authorities.

 

&quo= t;User:  An= individual reachable through a communications service; usually a customer = of a communication service provider who uses TNs to reach and identify services.  Sophisticated users may also act as their own CSP= s."

 

The = "User" actor definition is ambiguous.

 

To r= educe ambiguity consider striking the phrase, "...who uses TNs to reach and identify= services" from the first sentence of the definition (assuming the phrase refers to the CSP and not the User)= .  The phrase is uncessary and does not add clarity.=

 

I re= commend striking the 2nd sentence, "Sophisticated users may also act as their own CSPs= ."  Doing so would not presumably preclude a sophisticated user from being a CSP, but it appears to be a sta= tement of policy or capability and isn't clear in either case.

 

&quo= t;Government Ent= ity:  An entity that, due to legal powers deriving from national polic= y, has privileged access to information about number administration under certain conditions.

 

Note that a given entity may act in one or mo= re of the roles above. An entity acting as a CSP, Service Enabler, or User = can also be said to have a relationship to the Registry of either an assignee or delegate:"

 

The = "entity" stuff is confusing.

 

Are = you indicating that an "entity" is somehow different from an &quo= t;Actor"?  Or, are you saying that an entity is a special kind of= "Actor"?

 

How = about replacing the phrase, "a given entity" with the ph= rase, "an actor"?

 

How = about removing the phrase, "An entity acting as" in the 2nd sentence of the 2nd p= aragraph?

 

"Assignee:  An entity that is assig= ned a TN by the Registry.  There is always a direct relationship betwe= en the Registry and the assignee.

 

Delegate:  An entity that is delegated a= TN from an assignee or another delegate.  Delegates may use a TN for = a communications service or delegate it in turn."

 

I di= dn't understand the need for the qualification, "There is always a direct relationship= between the Registry and the assignee" in the definition of the Assignee actor.

 

I wo= uld avoid the use of the term, "entity", and replace the= entire Assignee actor definition with the following:

 

&quo= t;Assignee: = ; An actor that is assigned a TN by the Registry.&= quot;

 

Simi= larly, I would replace the word "entity" with "actor" i= n the definition for Delegate.

 

The = second sentence in the definition of the Delegate is confusing and ambiguou= s.

 

The = phrase "Del= egates may use a TN for a communications service&q= uot; is written such that it could imply that a TN could be used as a form of communications service although clearly this wasn't the inten= t.  And the end of the sentence referring to additional delegation is = too open-ended and should not be combined with the first part of the senten= ce.

 

I re= commend breaking the sentence into 2 parts.

 

Firs= t change the phrase, "Delegates may use a TN for a communications service"= to be a sentence reading, "Delegates may associate a TN with a communications service."

 

Seco= nd change the phrase, "or delegate it in turn" to be a s= entence reading,  "Delegates may delegate one or more of their TN assignment(s)to one or more further d= ownstream subdelegates who may also delegate their assignment(s).  The= re can be up to 1024 levels of sub-delegation.&quo= t;  (Just kidding about the 1024 levels, but you get the idea.)

 

Sect= ion 2.2

 

&quo= t;Administrative= Data:  assignment data related to the TN and the relevant actors; it = includes TN status, contact data for the assignee or delegate, etc. and typically does not require real-time performance."

 

What= is meant by "TN status"?

 

If t= he definition of "TN status" is clear, unambiguous, and = short, use that instead.  If it is not, delete it from the definition of "Admini= strative Data".

 

&quo= t;Service Data:&= nbsp; data necessary to enable service for the TN; it includes addressing d= ata, feature capabilities, etc. and typically does require real-time performance."

 

If e= xamples or the definition of "feature capabilities" is c= lear, unambiguous, and short, use that instead.  If it is not, delete it from the definition of "Service Data".

 

Dele= te "etc.".

 

Defi= ne what is meant by "real-time performance" in the conte= xt of it being a requirement.  i.e., what part of the problem statement indicates a need for real-time, or non-real-time performance?

 

If w= e look at existing numbering and registration systems (in North America) as= an example, what about their real-time, near-real-time, or non-real-time p= erformance is a problem to be solved?

 

&quo= t;Public:  = data that anyone can access, for example a list of which numbering resource= s are available for acquisition from the Registry.= "

 

Defi= ne "numberi= ng resources".

 

Defi= ne "availab= le".

 

&quo= t;Semi-restricte= d:  data that a somewhat broad subset of actors can access, for exampl= e CSPs may be able to access other CSP's service data."

 

Dele= te the words "somewhat broad".

 

Dele= te the example.  Defining policy should be outside the scope of the pr= oblem statement should it not?

 

&quo= t;Restricted:&nb= sp; data that is only available to a small subset of actors, for example a = Government Entity may be able access contact information for a User."

 

Dele= te the example.

 

As y= ou acknowledge there are really only two categories; unrestricted and restr= icted.  Degree of restriction is a matter of policy.=

 

2.3 = Data Management Architectures

 

&quo= t;Beyond traditi= onal centralized Registries, this framework also supports environments wher= e the same data is being managed by multiple entities, and stored in many locations."

 

I wo= uld delete this paragraph for being inappropriate to a problem statement.&n= bsp; Save it for the solution to the problem(s).

 

&quo= t;Data store:&nb= sp; a service that stores and enables access to administrative and/or servi= ce data.  Typically Registries and CSPs would manage data stores."

 

I wo= uld delete the last sentence, "Typically Registries and CSPs would manage data stores.= "

 

&quo= t;Reference Addr= ess:  a URL that dereferences to the location of the data store."

 

This= is an artifact of a presupposed solution to a problem and does not belong = in a problem statement.  I would delete this and save it for a solutio= n statement.

 

&quo= t;Distributed Re= gistries:  refers to multiple Registries managing the same numbering r= esource.  Actors could interact with one or multiple Registries.  The Registries would update each other when change occurs.  The chall= enge is to ensure there are no clashes, e.g., two Registries assigning the = same TN to two different actors."<= /span>

 

Defi= ne "numberi= ng resource".

 

I wo= uld delete, "&qu= ot;

 

Thes= e statements presuppose a solution architecture and make assumptions about = the type of TN being assigned.  These statements do not belong in a pr= oblem statement.  They should be saved for a solution statement.

 

3. F= ramework

 

&quo= t;The framework = outlined in this document requires three Internet-based mechanisms for mana= ging and resolving TNs (TNs) in an IP environment.  These mechanisms will likely reuse existing protocols for sharing structured dat= a; it is unlikely that new protocol development work will be required, thou= gh new information models specific to the data itself will be a major focus= of framework development.  Likely candidates for reuse here include work done in DRINKS and WEIRDS, as well = as the TeRQ [12] framework.

 

These protocol mechanisms are scoped in a way= that makes them likely to apply to a broad range of future policies for nu= mber administration.  It is not the purpose of this framework to dictate number policy, but instead to provide tools that will= work with policies as they evolve going forward.  These mechanisms th= erefore do not assume that number administration is centralized, nor that n= umber "ownership" is restricted to any privileged service providers, though these tools must and will work in env= ironments with those properties."<= /span>

 

The = first sentence in the first paragraph has parentheses around the acronym TN= without spelling out the acronym.  Either eliminate the parenthetical= TN or spell out Telephone Number.  Here I will also mention that Telephone Number is an ambiguous and increasingly a= nachronistic term that might be better served being replaced by the term &q= uot;E.164 number".

 

I wo= uld delete the sentence, "Likely candidates for reuse here include work done in DRINKS= and WEIRDS, as well as the TeRQ [12] framework.&q= uot;   It is an editorial opinion and not necessarily appropriate to a problem st= atement.

 

&quo= t;Acquisition:&n= bsp; a protocol mechanism for acquiring TNs, including an enrollment proces= s."

 

Defi= ne "enrollm= ent".  Does "enrollment" imply= or mean "subscription"?

 

&quo= t;Retrieval:&nbs= p; a protocol mechanism for retrieving data about TNs from either an author= ity or a CSP."

 

I wo= uld delete the end of the definition beginning with the word "<= span style=3D"font-family:"Courier New"">from".  It presupposes a solution architecture and is not appropriate to a problem statement.

 

&quo= t;The acquisitio= n mechanism will enable actors to acquire TNs for use with a communications= service.  The acquisition mechanism will provide a means to request numbering resources from a service operated by a Registry, CSP = or similar actor.  TNs may be requested either on a number-by-number b= asis, or as inventory blocks.  Any actor who grants numbering resource= s will retain metadata about the assignment, including the responsible or individual to whom numbers have been assigned= ."

 

Defi= ne "numberi= ng resources".

 

Inse= rt  the word "parties" between the words "responsible" and "or" in the last sentence.

 

Shou= ld the paragraph describing acquisition mechanism be included as a subparag= raph under the initial definition of "Acquisition"?=

 

"The management mechanism will let actor= s provision data associated with TNs at CSPs.  For example, if a User = has been assigned a TN, they may select a CSP to provide a particular service associated with the TN, or a CSP may assign a TN to a U= ser upon service activation.  In either case, a mechanism is needed to= provision data associated with the TN at that CSP."

 

To m= e, the first sentence is ambiguous with respect to where management action = is taking place.  Are you indicating management of TN and TN-associate= d information withing the corporate database of a CSP?  Or, are you indicating the ability to manage the TN and TN= -associated information within a MODERN database hosted by one or more MODE= RN-enabled registries?

 

The = latter of the two possibilities seems less fraught with legal and operation= al problems.   I would have just assumed the latter except for yo= ur additional remarks about the "retrieval mechanism".  = ; More on that below, but here I'll just state my opinion you should confine= your scope to the public realm (as inferred in the last sentence of the ch= arter) and will direct most of my remarks as though you agreed. 

 

Perh= aps change the first sentence to read, "The management mechanism will permit actors to= provision data associated with TNs within registries."

 

And = change the last sentence to be, "In either case, a mechanism is needed to provision da= ta associated with the TN within registries."=

 

Shou= ld the paragraph describing the management mechanism be moved to be a subpa= ragraph under the initial definition of "Management"?

 

&quo= t;The retrieval = mechanism will enable actors to learn information about TNs, typically by s= ending a request to a CSP.  For some information, an actor may need to send a request to a Registry rather than a CSP.  Differen= t parties may be authorized to receive different information about TNs."

 

The = Charter implies the output of the working group is a a potentially global p= rocess and method which user and CSP actors would use to manage TN assignme= nt and the metadata associated with the TN.

 

I'm = stunned that you're also recommending that the framework include a requirem= ent for user actors to be able to directly manage TN and TN metadata within= a CSP actor's private corporate database.

 

My o= pinion is you should confine your scope to the public registry realm and av= oid creating mechanisms and frameworks which force CSPs to expose their pri= vate corporate databases in any particular way.

 

CSPs= often (and increasingly so) make user-defined provisioning options availab= le as a matter of competitive advantage, but creating an IETF-designed requ= irement to do so as part of a TN and TN metadata management framework is not advisable.  It makes adoption hu= rdles more difficult and therefore increases the chances that MODERN is mor= e narrowly accepted, if at all.

 

If y= ou want your work used, you should aim for the broadest possible adoption a= nd requiring user actor access to CSP actor information is probably going t= o harm your chances of achieving your goals.  I recommend you confine your framework and design to publicly= -held and managed implementations.

 

Many= IETF protocols and mechanisms have been the source of cyberplagues and MOD= ERN is an obvious target.  If you have a specific kind of information = that you think would only be available to a CSP actor and that MUST be directly retrievable or changeable by user acto= r having direct access to a CSP actor's database, then you should state wha= t that information is and why that steers away from a design using an indir= ect method through a public registry.

 

 

4. U= se Cases

 

4.1 = Acquisition

 

&quo= t;There are thre= e actors from which numbers can be acquired: a Registry, a CSP and a User (= presumably one who is delegating to another party). In these use cases, a User may acquire TNs either from a CSP or a Registry, o= r from an intermediate delegate."<= /span>

 

The = use of the term "delegate" is very loose in this documen= t.  The definitions and use cases seem to imply delgation and subdelegation between user, CSP, and service enabler actors can cascade fa= ctorily.

 

I ap= preciate that Section 4.1.1 tries to more precisely outline and proscribe p= ossible or probable assignee and delegation relationships.  This is ne= cessary.  It would be good if you could also describe what are the expected reasons for having permitted/designed those= relationships.

 

Sect= ion 4.1.1 CSP Aquires TN from Registry

 

&quo= t;The Registry m= aintains a profile of the CSP and what qualifications they possess for requ= esting TNs."

 

Plea= se explain (somewhere) what is meant by "a profile of the CSP".

 

Plea= se outline why it is important for the registry to maintain a profile that = contains the CSP "qualifications they possess for requesting TNs".

 

Is t= here also an expectation that a registry should also maintain profiles of u= sers and the "qualifications they possess for requesting TNs&= quot;?

 

The = suggestion of using the MODERN numbering management process to also perform= key management for another IETF initiative (STIR) is sensible in the conte= xt of advocates of MODERN promoting other favorite sons, but hopefully won't be a detailed part of the MODERN number= management solution.  It is fine to suggest it as a plausible thing t= o do, but there isn't anything like consensus with regard to whether STIR i= s a good or favored approach for authenticating calling identity and should be outside of the scope of MODERN.<= /span>

 

I'm = going to skip over making any further comments on the various MODERN use ca= ses.  They would have been useful as part of a definition of terms fro= m which a problem statement was constructed.  In the case of this document they are presented as functional parts of a M= ODERN solution framework, not a problem statement.

 

4.2 = Management

 

&quo= t;While some sim= ilar use cases may apply to individual Users, it is anticipated that for th= e most part these lower-level service information changes would be communicated via existing protocols (like the baseline [2] SIP RE= GISTER method) rather than through any interfaces defined by MODERN.= "

 

The = above paragraph is duplicated in it's entirety across pages 10 and 11. = ; Delete the duplicate that ends on page 11.

 

4.2.= 2.  Management of Service Data

 

&quo= t;Service data i= s data necessary to enable communications service to the delegate or User, = for example a SIP URI."

 

This= is naive.  It assumes a simple single SIP URI would be sufficient &qu= ot;to enable com= munications service to the delegate or User".

 

A co= nsequence of private interconnection networks used for exchanging peering t= raffic between CSPs (which is the norm) means that a single SIP URI is almo= st certainly out of the question.  As I tried to explain in on-line discussions about numbers and geography, cal= l routing of services to a TN often requires knowing where the call is orig= inating (either physically and/or logically) and then using the terminating= address that makes sense in the context of the originating network.

 

This= oversimplified model of how call routing works is a weakness of the MODERN= TN information management model.

 

CSPs= often have multiple (and regional) physical and logical private and public= network boundaries using a mixture of private (e.g., RFC1918) and public I= P (IPv4 or IPv6) addressing.  This impacts managing SIP URIs associated with a TN and what the visibility should be t= o those URIs and by whom.  It eliminates any practical possibility tha= t a single URI is sufficient.

 

URI = information associated with a TN will be different for different interconne= ction relationships which steers toward a distributed database model mainta= ined largely by and for CSPs moreso than end-users and governments.  (I think you tacitly acknowledge this in = section "4.= 2.2.1.  CSP to other CSPs".)<= /span>

 

4.2.= 2.3.  User to Registry

 

&quo= t;As stated alre= ady the protocol should enable Users to acquire TNs directly from a Registr= y and in essence act as their own CSP."<= /o:p>

 

This= is just impractical in the case where there are tens or hundreds, or even = thousands of millions of users (which is all of the important cases) becaus= e the registry cannot possibly vet with any usable reliability the trustworthiness of this many actors let alone p= rosecute them.  Ask anyone whose worked in the US Internal Revenue Ser= vice.  They can't possibly know if all of the "users" are al= ive, dead, illegal aliens or where they say they are, or whether they appropriately paid their taxes.  Tax fraud is a multi= -billion dollar problem.  If we overlay that model on management of TN= s, you can practically guarantee that STIR will be of no use whatsoever.

 

The = reality is users are going to want (and should be permitted) multiple TNs, = but the management of their access and use has to be delegated to organizat= ions who have a vested interest in being able to recover the TNs, make efficient use of them, and who can prosecute= the users if there is a problem.  That is, the government needs to gi= ve inventory to CSPs who then need to manage the users' use of it.

 

4.2.= 3.1.  Changing the CSP for an Existing Communications Service

 

&quo= t;The User provi= des their credential to the new CSP and the CSP initiates the change in ser= vice."

 

No a= rgument with the method, but will mention at least two large regulatory env= ironments do not embrace it.  You should consider how to integrate oth= er methods such as requesting that the old CSP move the TN assignment to the new CSP.

 

&quo= t;The old creden= tial is revoked and a new one is provided."

 

This= seems to imply an integrated STIR or STIR-like function which might make s= ense but should be outside of the scope of MODERN.

 

I re= commend deleting all references to credential management that fall outside = of section 4.1. use case examples.

 

&quo= t;[TBD - more on= the case where multiple CSPs provide services for a given TN, and only one= service is "ported" to a new CSP?]"= ;

 

This= is actually one of the more important use cases in my mind but not as a pa= rt of a problem that MODERN is required to solve.  Based on what I've = read of problems in the so-called "problem statement" I still don't believe MODERN is required.  Regardless= , the use case is valid and important.

 

I ha= ve a sincere frustration that my e-mail address is broken if I move my e-ma= il between e-mail service providers.  I would much prefer to have e-ma= il address portability.  I could easily have this if my e-mail address were based on my TN.  This is an example of= where TNs are far superior to domain names.  They are not vulnerable = to international character set exploits, et cetera.  So, I am very sym= pathetic to a broadened use of TNs and associating metadata (such as e-mail URI) to them for the very purpose of enabling por= tability between CSPs if nothing else.  It's just that MODERN isn't re= quired in order to achieve this outcome and benefit.

 

4.2.= 3.2.  Terminating a Service

 

&quo= t;In an alternat= ive use case, a User who received their own TN assignment directly from the= Registry terminates their service with a CSP.  At this time, the User might terminate their assignment from the Registry, and ret= urn the TN to the Registry for re-assignment. Alternatively, they could ret= ain the TN and elect to assign it to some other service at a later time."

 

I'll= encourage others who know more about TN inventory management, but on the s= urface this and delegation look promising for providing an environment ripe= for problems with fraud, abuse, and number exhaust.

 

4.3.= 1.  Retrieval of Public Data

 

&quo= t;Under most cir= cumstances, a CSP wants its communications service tobe publicly reachable = through TNs, so the retrieval interface supports public interfaces that permit clients to query for service data about a TN. = Some service data may however require that the client by authorized to rec= eive it, per the use case in Section 4.3.3 below.

 

Public data can simply be posted on websites = or made available through a publicly available API.  Public data hoste= d by a CSP may have a reference address at the Registry."

 

One = of the robocalling problems plaguing the industry are calls that are appare= ntly sequencing through number blocks in an apparent attempt to identify wh= ich numbers are assigned and which are not.  The intentions of the robocallers wanting this information are = suspect and assumed to be bad.  Making the information publicly availa= ble on the Internet may actually put the public at risk of material harm.&n= bsp; Ask any mobile user if they would prefer that their TN and CSP information be available on a public database and see wha= t they say.

 

Most= of this paragraph is of a policy nature and does not belong in a problem s= tatement or an RFC.  Section 4.2.3.2 has similar weaknesses.  i r= ecommend removing any references to policy.

 

4.3.= 2.  Retrieval of Semi-restricted Administrative Data=

 

&quo= t;A CSP is havin= g service problems completing calls to a specific TN, so it wants to contac= t the CSP serving that TN."=

 

This= is not representative of how trouble management is handled in the US. = ; Trouble management is between carriers with Inter-Connection Agreements, = not between originating and terminating carriers.

 

I be= lieve the sentence and example does not contribute usefully to the section.=   I recommend deleting it.

 

4.3.= 3.  Retrieval of Semi-restricted Service Data

 

&quo= t;There are mult= iple scenarios to for the query and response."= ;

 

Dele= te either the word "to", or the word "for" from the sen= tence.  I recommend deleting "to".

 

5.&n= bsp; Distributed Registries and Data Stores

 

&quo= t;For example, w= hen a CSP enables service for a User they can initiative an update of the s= ervice address to multiple other data stores managed by other service providers."<= /p>

 

The = word "initiative" should be changed to "initiate".=

 

The = phrase "[More TBD]" should be removed or more should be added.

 

8.&n= bsp; Security Considerations

 

&quo= t;TBD."

 

This= is a bigger handwave then the usual caveat that security is important and = be careful because the authors didn't know what else useful to write.<= /o:p>

 

I re= commend adding the usual useless boiler-plate, or actually try to introduce= discussion and description about potential fraud and abuse issues from mal= intentioned User actors being able to directly request and manage the metadata associated with their own TN numb= er assignments or the unrestricted public data of other TN  and associ= ated CSP assignments.

 

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_691495e5e2834619937f30fcccc78df6PLSWE13M08adsprintcom_-- From nobody Sun Jan 10 20:47:11 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 950EE1A86DD for ; Sun, 10 Jan 2016 20:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqcvjoZqn_LT for ; Sun, 10 Jan 2016 20:47:09 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947D81A86E2 for ; Sun, 10 Jan 2016 20:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=GoTeUl1cC7D/+XoU0viBaFUJQX0tiER6nSRmXJCkWTw=; b=p6I2mgmqgp1PQlXm1zZ9LvZ5AVvAcJPh+g4aofa/5XzWv7ZiCOlFcIekF6wJo+X8gkdy6ytT+I9hsbWVQvCZVoYrfTnm3dA+9BLxvmt9LlValwGYK73KXe404WE24ZWhwXLGu6Rvqrbiz3OeoMdcmDYh50Bvlc9m8vj6OUyckzY=; Received: from [24.204.47.123] (port=56723 helo=[10.0.27.72]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aIUNk-0001t4-W4 for modern@ietf.org; Sun, 10 Jan 2016 20:47:09 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_25FAB655-5C30-4AE7-AF16-72E4A93ED4EA"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> Date: Sun, 10 Jan 2016 22:47:03 -0600 Message-Id: <20421E5C-63F4-4EE2-8DED-969417E14AC2@standardstrack.com> References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> To: "modern@ietf.org" X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 04:47:10 -0000 --Apple-Mail=_25FAB655-5C30-4AE7-AF16-72E4A93ED4EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Smells like we are a long way from a WG document. > On Jan 10, 2016, at 5:36 PM, Gorman, Pierce A [CTO] = wrote: >=20 > As promised, below are my remaining edits and editorial comments. >=20 > The format of my comments is as follows: >=20 > - Section reference > - Quoted content from the Problem Statement > - Recommended edits and/or editorial comments >=20 > I'll preface the work below by saying I have completely read the = document word for word and my previous estimation remains that the main = issue with the problem statement is that it fails to meet the burden of = proof that there is a problem that needs to be solved. >=20 > A problem statement is something like, "The alligators in the swamp = adjoining my back yard keep eating my pets." >=20 > A solution statement would be something like, "In order to deal with = the issue(s) outlined in the problem statement, it is recommended that a = strong fence be constructed (which prevents access to my pets from = alligators in the swamp adjoining my back yard)." >=20 > The MODERN problem statement is in fact a TN management solution = framework. i.e., a solution looking for a problem. >=20 > If there is a problem that MODERN addresses, it is the inability of = end 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 seeing referenced in the = solution statement is a SIP REGISTER. 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 = start 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 hopefully clearly differentiate between issues that are = political and issues which are technical and therefore appropriate for = the MODERN WG. >=20 > Respectfully, >=20 > Pierce Gorman --Apple-Mail=_25FAB655-5C30-4AE7-AF16-72E4A93ED4EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWkzPIAAoJEORoZaSQsc1ImbIP/2MJt8bXeBpuPLHlkcZqRqGp 7colwJXbH5M126ijvsB1K9WIQ+PJFtlTYRx+EOAdkPPo+tj4Lqt+b4e0YqJJACw8 c7wJnh+0er8/iwAg4fGd27yS/mNap1NqFx2Z/pGe2zgA2cuJWpErpMM9VH+FSMyv y3eeAd1F8AAmkiBdFMR364AQaNh03/0iiHLLDuEXX36cTm+fAvvtYG3UhKqo2IIJ h7DdG387etvQfbzM7+hq/4DNjsJLaeHB0MqbhzLyLg8eeSPi7SX69MSWVPM6OoKK TI89zqxJqP/Rh15ABBqSiWKVWXcIYCKGyG70T/oLMjnH2fHfMj6EJMtuLKYgCxTl D2hbWPh/W5Lx2Pg8TohRrHhpC5/1kABN4aeOXJ8K8JzVZcvnxNmrkmziKPMZ56z5 dJTopCOi/USDIcliE5cm1xbdF0ekqlzmixzd3CKh6k7aEmupMSGJbXn/KMgQRIme DwM6K5mEu9nlhidDa2CIizOZbUMafq/cBciIJXXrDr14GRU8LZJtpwiF/UwkRb+r hEqSty3YWHC64sYOXUiSi0shs1u0hq6kI/nYW7Veekw1PCvadHLp+W5WIdXHBK2I J5rWs/ncdH5dLqT92T5WKUIsAPBrbkN0cUnGVONU6cMmjE/Zry5SXsWCranELhrs tjp5QW7SswQMEVSOME6c =J4yb -----END PGP SIGNATURE----- --Apple-Mail=_25FAB655-5C30-4AE7-AF16-72E4A93ED4EA-- From nobody Mon Jan 11 13:36:58 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 0CB431A92EE for ; Mon, 11 Jan 2016 13:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 kc0A9Q3pTB1h for ; Mon, 11 Jan 2016 13:36:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44A61A92EC for ; Mon, 11 Jan 2016 13:36:47 -0800 (PST) Received: from BN1AFFO11FD029.protection.gbl (10.58.52.32) by BN1AFFO11HUB030.protection.gbl (10.58.52.140) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 11 Jan 2016 21:36:25 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) 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.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN1AFFO11FD029.mail.protection.outlook.com (10.58.52.184) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 11 Jan 2016 21:36:25 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u0BJperc039963; Mon, 11 Jan 2016 16:36:25 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm1.corp.sprint.com with ESMTP id 20ayjf9bmn-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Jan 2016 16:36:25 -0500 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; Mon, 11 Jan 2016 16:36:24 -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; Mon, 11 Jan 2016 15:36:24 -0600 From: "Holmes, David W [CTO]" To: Richard Shockey , "Gorman, Pierce A [CTO]" , Eric Burger , "Modern List" Thread-Topic: [Modern] MODERN Interim Meeting Thread-Index: AQHRSAAy8r+P0LInaUCu1ptb2eXiZZ7t/CEAgAEzYYD//59MMIAAA2iAgABoKQCAABh9gIAAFAUAgAAaJoCAB04yMA== Date: Mon, 11 Jan 2016 21:36:24 +0000 Message-ID: <1b663c1a6e62475d8e123865fde98d9b@PLSWE13M01.ad.sprint.com> References: 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.29] Content-Type: multipart/alternative; boundary="_000_1b663c1a6e62475d8e123865fde98d9bPLSWE13M01adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD029; 1:fJZOEwV49ojipQnLKeFDTclzAn9j9KHoswOK6HTmrQeKr/aZc6ExPjWyyeMLTTL4p1wPcX/lKAN20HoEHefVhxDCnKIbXirmp+GwcOUF6zezK19SzDCq5fU7I6iiyiK2kVHdD/uOGfcjey2jMpSqLHGMvzEVZwAVFbuIROLc8ej5GZ+Ru4Er/JgkaebFXp783IYaquOtmaAnWKDCRudlXzagcbhqhjmQ9PeZ/pnyVZQ2mud8hXzbSaFZPWnWK7XeNfSoTOePui90TU2qg+k5qmbFuszZ0/sJjwyQ3G3/wT145MjaiM/U2wk7uIuopJj5z4MTRRJXdKaFhySC59WV47fd5ZsvCEiYm8kDEBaUXo8DMrO3zQTbwbRdkOKLs3Y3RzfNZ5Rk+zCWGOVcaOWRRw== X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(377454003)(164054003)(189002)(24454002)(52604005)(57704003)(199003)(1680700002)(2950100001)(5001770100001)(586003)(86362001)(16601075003)(102836003)(106466001)(106116001)(19617315012)(15975445007)(5250100002)(5004730100002)(24736003)(1096002)(11100500001)(5008740100001)(84326002)(575784001)(1220700001)(33646002)(92566002)(790700001)(108616004)(6806005)(6116002)(15974865002)(2900100001)(19625215002)(3846002)(93886004)(16236675004)(81156007)(97736004)(15395725005)(19300405004)(512874002)(300700001)(107886002)(189998001)(87936001)(19580395003)(76176999)(5001960100002)(50986999)(54356999)(30436002)(2906002)(4546004)(19580405001)(5003600100002)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB030; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-MS-Office365-Filtering-Correlation-Id: 0d5b6894-a226-4c21-0fb0-08d31acf4215 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 2:5xOQeVV+vWPaFtXZDNHMsCU4ho2vrJ82kxS8IxkMekCqMHUGRZgqGUSGTr85vqq9p9iuSb689Qgo/AQWI+V1ZU68tuX+kA3l9MBCTEQczP+jH5UI0zkWGPShR8AaOpxFRFwr9oLfQScVOA7Hdykb9L+B2t8bRwHOk7QLDYJI0YlJ3qaF6a0v/S2ZW2kBMou/; 3:lmf8qHdQ8DhVEAn+8H7c64GqLEd4aBXeT9JMcC8xwWOcAONaJxRCvnjHJLdtYtQhr99FgG9osfJzG6XEqQkQQR4RSnkQK+iK40Y1XATHX/QVThfEl3Qmd/8x4vpK8TkooaI7D/A0wIGAYw17q+Evv/Rtn6AS1fpEBmuWp0u3l7sT1Z4BAYv6f7gSI4eLy4TQEb8B7lUVxnM5p5wq1qKY9AN9bPWPHdoY88qR0woUWpt4HWlBRQNJFPIdCAoHHNySlM0WvdJSTgUvLrfUZVSolQ==; 25:hrGyXxyXexXsubT8PfqwLapcwM/6FfqW7kPK92/1qyI/51BqQjv9ndTSERdcLWlHB0+1U19kJ8WRrdMv+Al9ngu8xkEPIzAkXJwTwR3HviPm8KZUmlNil5erVDaUf5OV4yg6aSXfOeHzjeGIMbg1BHbpAlTnEILO/IlZDYCl0jLl6haeEeAr7667VTtKtE3/KDTZ1G52hZdchQIrmu6OdtIX0x5pbLCJinhX70ZObVRqTFCYTY9zlCfNvdtbd4uO X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB030; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 20:Ml0GNJO/HzOxJPdJOYuFxoHLA8k6M0OwdGVdgtNPy49nNev77A7OATU+v5mFA28cYftyaLdAw2JzYPwu1qm//Yi5PSU7XZylsvPo9WzNVHpy5hPMijiABOkxq0M1sWZogmx75lprv/I6aE5VX5MFa1uV0dbpgQlTyzHcl89gMd/eoGiy7ygiJ5RIrvjcd6/S3x8DQsxK7Sn2vUYQwECXQZ3KohJhJ4SsUK00Pk7D6ZGdVu7T68YXN6BHNCxuN+EF; 4:bBvAIGL8dJzagJSWiNItQvHK5kuLUrrnADIoexURrHYsqzbmTTver39ifQ7/ALLTeNEyWbwwl8s2zbzLhCgRKWNKA94nns3CjDmcqLGYrSNyk5MUCfOVzRImoKsijZNHMQI8qMhNqQ3SNSFmpKxAzL/AoGT534gIINpwIGw0QKr6LoTNvokI6vYaSC4tORywGaHE79Y7tFuIJGxWBqI8oKHj0iE01k1SHfI722mwVHjO9TOFAyWZ9CD2OogP04p5sbmy/lj0a6SzryHsCnEk6xdgRaY2n8uJ2ycxx3OVTHTETQjISocYiDS0ZaaIuOy1tKwfu01cGpMXY9Yj4fc7DB0UrXb+wAVMawtx9n5TKqP/VJ5lOYmM6PD9jupR/QKA61AQiG29P5za57616j7jH4XQLTY0gzJzdZPm4UIRRB41TtZpqiNZaC1/7/+taUAyWvHN9zy7CyxIJLkhhPRxNoXQHnSGsWhheREcOYkLl10= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13017025)(13015025)(5005006)(520078)(13018025)(10201501046)(3002001); SRVR:BN1AFFO11HUB030; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB030; X-Forefront-PRVS: 0818724663 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB030; 23:GM4DlObBSh6MdYDUWehRbGGRAxhYKYsfaZvFeMa?= =?us-ascii?Q?q9R7Dyo7cSL1kFUiclbxacGNw4wDsEPYMjJ9khfHzXHxH3oXk3G/IGipSNZi?= =?us-ascii?Q?m+iCXIzqRYx63fETyEUlFKlGKhxmNWfbPF3X7XkpDl2MY4Hl57fTcXZgqnGB?= =?us-ascii?Q?RxHgaCCjELKPfPw/XVCzsntpjGzXuh3mdJjf4Bkp9JyQzuHA3owdwsm6Y84x?= =?us-ascii?Q?EVOVAGqCrtWO5pEeu/+zgCpoBBFQnxPLpxLL35fDcvbIsG0t8grXEWknx8lg?= =?us-ascii?Q?4ulAieJLIDbWb7Gti7w7DmTWveRhA9JS0zz7D7cm8KBFzYJAhDiY74vLvoY2?= =?us-ascii?Q?OkcZg1k/HpgD9G+0fXB9ELU5NpOWbpiKLXcs87bo8r16t7YFS0R1TtkX/OlR?= =?us-ascii?Q?x4BgmsYxQ5aIxDs66hwT68PGsLMWtk6zBV13S/Ns2Wbwm56j2ydKlcgJAgle?= =?us-ascii?Q?MaRMgSpvGi7gywVQXorPSK/QW1nhKdRSD7tm+KZxAuyK1focxsYGpyg8LaQf?= =?us-ascii?Q?wSh0mSGaBwSJ4D4/ILLa2eHS36VPCRbao2d97LlCLm8zH4AGpOcVh//8UBj4?= =?us-ascii?Q?H74GmDyfFuQgO2taSykgn5jtaU82ucOtuyg1rw5ZuIyQkeANzjEEpL5u10tj?= =?us-ascii?Q?HyTRDr7KE89ArlnPnvzNzFKwjnXQcdc499gj0OxEiZ22nmWbzdDSlaD3PGcn?= =?us-ascii?Q?hWZPnlTUqw4IEjqhKI53VPGp9k44LGYR4TUwOSddOHnmndRfeYZtfZYa5OEn?= =?us-ascii?Q?jdjQ8Hx+uveSJcPtYV5KvJuK+I+LgdnOHe4iN5eeBDdUbu5qTLh9cZRjWnUL?= =?us-ascii?Q?hKRxfiFmPnbTkK45rDWK67gnJveJR68KWuBh5C72fRBXz/C6g3IXy1ogzJpx?= =?us-ascii?Q?4vlg5zMyZKc+E43UDlGNBlNSAsEgIZl4DMANBxSwfVVPWaQzq1cZrqFAnFvy?= =?us-ascii?Q?RZ7HwjVX9p9zbLzZmyoPR8R9geOByGspQgFqGfVQjWDTV4MHR63BJGbOnhup?= =?us-ascii?Q?AS65nxw9Iiq5zbbGBX3OtEfd650ZCwYuLvQ1SaCVm6m+Xh0C5yaHHffmlZgC?= =?us-ascii?Q?oe3WxDvoy1SF7QgfUz1DIQSwf/Bnq77B5ki5BXN/gV7ayjGpmRCb/SV8FOwF?= =?us-ascii?Q?hFHxD3Z2PVpCiIMJfuzRKRVBet4/+4lbyY/J0Gie1Od0OSymW+6BK0xYHjv4?= =?us-ascii?Q?psd8r/o4RRLz5+CMuLoCE/FCab0xiku/GPNDnTFzlmgakM/ZvZUX0kfi7509?= =?us-ascii?Q?df9ChRsMQzw/8VpyPxrXUSJ2DoRMUXnerdnEPElF5dsu+KfP1zYrb+CKXPFL?= =?us-ascii?Q?pQHTVlVkW8u6Qu9GtQ1I5ugku2dVHrF1Zjt0Sk3ntxkG8NWEVynSrTmHs5kE?= =?us-ascii?Q?jXXCAEHkovK8trWPe76toQFxcfmwr4uB9xG+a7cnDgi1nw55nS7wYqwFpBQf?= =?us-ascii?Q?e0t7dqSHOyh3NNbtF31pDclO/tOdjvJRgqO6MK4jrMU5rRv4IScZ/e26yWqV?= =?us-ascii?Q?EWdT4JSFwFr1VIGvdlYggGILlIxBY8hkdy7JPx8Ck95nMqy/1ltorKdv0UD+?= =?us-ascii?Q?Ld9vDQDXAmWyr11Nx7zm09FblKR6PwvcyXE3ERLADJNWU7YDRQ1w3qH+g7Kj?= =?us-ascii?Q?14Blxqh+Z3ZPdL9RXgxQAcg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 5:7+xLPjMc269rs0L5LeCAOefvlbaCeJGjMp9/dhfge8Fj961111CBybMsTHAp4jydi60cthlJ2JUKMS19ZQOZ4X907m69k47qRkERAW8N8upKPO8PZCRe7+ZISSIjhaz0nV9Rhmy10K2KFoNwX87xgw==; 24:nRpW2/eU32PepwtM3Y56NkFTnqWKHgo48CuqhaqYAEzPNvwxaMYK/Ska3BOW80ob2ScwmtrRVcZIxCNALUXNVHixzVratmnlivXTP/YGsdk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2016 21:36:25.7976 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB030 Archived-At: Subject: Re: [Modern] MODERN Interim Meeting X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 21:36:56 -0000 --_000_1b663c1a6e62475d8e123865fde98d9bPLSWE13M01adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFzZWQgb24gYWJvdXQgYSBkZWNhZGUgb2YgdXNpbmcgcmVtb3RlIGNvb3BlcmF0aW9uIHRvb2xz IGZvciBzdGFuZGFyZHMgbWVldGluZ3MgJiBhYm91dCA0MCB5ZWFycyBvZiBGdEYgd29yaywgSU1P IGJvdGggY2FuIGJlIGVxdWFsbHkgcHJvZHVjdGl2ZSBpZiBtYW5hZ2VkIHByb3Blcmx5LiAgSWRl YWxseSB5b3UgdXNlIGEgbWl4dHVyZSBvZiBib3RoLCBzbyBpZiB0aGlzIGludGVyaW0gbWVldGlu ZyBpcyB1c2VkIHRvIGNvbXBsaW1lbnQgdGhlIEZ0RnMgYXQgdGhlIElFVEYgRnRGcywgYSB2aXJ0 dWFsIG1lZXRpbmcgc2hvdWxkIHdvcmsgZmluZS4gIEhhdmluZyBzYWlkIHRoYXQsIGFzIFBpZXJj ZSBub3RlcywgU3ByaW50IGRvZXMgaGF2ZSBhbiBleGNlbGxlbnQgY29uZmVyZW5jZSBmYWNpbGl0 eSBpbiBPdmVybGFuZCBQYXJrIEtTLCB3aGljaCB3ZSBoYXZlIHVzZWQgZm9yIG1hbnkgaW5kdXN0 cnkgbWVldGluZ3MgaW4gdGhlIHBhc3QuDQoNClRvIG1ha2UgdmlydHVhbCBtZWV0aW5ncyB3b3Jr IHdlbGwsIHlvdSBuZWVkOg0KDQotICAgICAgICAgIEEgbWVldGluZyBmb3JtYXQgdGhhdCBjYW4g d29yayB1c2luZyB0aGVzZSB0ZWNobmlxdWVzOyBlLmcuIHByZXNlbnRhdGlvbiBvZiBuZXcgbWF0 ZXJpYWwgd2ViaW5hciBzdHlsZSwgZGlzY3Vzc2lvbi9maW5hbGl6YXRpb24gb2YgY29tbWVudHMv ZWRpdHMgdG8gYSBwcmUtY2lyY3VsYXRlZCBkb2N1bWVudCwgYXMgd2UgYXJlIGN1cnJlbnRseSB0 cnlpbmcgdG8gcGVyZm9ybSB2aWEgZW1haWwuICBWaXJ0dWFsIG1lZXRpbmdzIGFyZSBub3Qgb3B0 aW11bSBmb3IgYSBmcmVlLWZvcm0gZGlzY3Vzc2lvbiwgdW5sZXNzIHRoZSBwYXJ0aWNpcGFudHMg a25vdyBlYWNoIG90aGVyIHdlbGwuDQoNCi0gICAgICAgICAgR29vZCBwYXJ0aWNpcGFudCBkaXNj aXBsaW5lLCAmIHN0cm9uZyBtYW5hZ2VtZW50IGJ5IHRoZSBDaGFpciAmIGZhY2lsaXRhdG9yIChl LmcuIG11dGluZyBub2lzeSBsaW5lcywgZW5jb3VyYWdpbmcgdXNlIG9mIGhlYWRzZXRzIGZvciBh dWRpbykuDQoNCi0gICAgICAgICAgQSBnb29kIGNvbW1lcmNpYWwgcmVhbC10aW1lIGNvbGxhYm9y YXRpb24gdG9vbCB0aGF0IG1vc3Qgb2YgdXMgYWxyZWFkeSB1c2UgKHNvIHRoYXQgaXQgaXMgaW5z dGFsbGVkIG9uIGNvcnBvcmF0ZSBQQ3MpLCB0byBhbGxvdyBkb2N1bWVudHMgdG8gYmUgZWRpdGVk IG9uIHNjcmVlbiBpbiBmcm9udCBvZiBhbGwgcGFydGljaXBhbnRzOyBTa3lwZSBmb3IgQnVzaW5l c3MgKEx5bmMpLCBHb1RvTWVldGluZywgb3IgV2ViZXggYXJlIHRob3NlIGNvbW1vbmx5IHVzZWQg Ynkgb3RoZXIgU0RPczsgdGhleSBlYWNoIGhhdmUgdGhlaXIgc3BlY2lmaWMgbWVyaXRzOyBTcHJp bnQgdXNlcyBTZkIgJiB0aGF0IHdvcmtzIGZpbmUuICBUcnlpbmcgdG8gZGlzY3VzcyBwcmUtZGlz dHJpYnV0ZWQgZG9jdW1lbnRzIOKAnGJsaW5k4oCdIG92ZXIgYW4gYXVkaW8tb25seSBsaW5rIGNh biBiZSB2ZXJ5IHVucHJvZHVjdGl2ZS4NCg0KLSAgICAgICAgICBMZWFkZXJzaGlwIHRoYXQgY2Fu IHdvcmsgd2l0aCAoJiBoYXMgZXhwZXJpZW5jZSBvZikgdGhlIGNvbGxhYm9yYXRpb24gdG9vbDsg Y29tbW9ubHkgbmVlZHMgYSBzZXBhcmF0ZSBDaGFpciwgZmFjaWxpdGF0b3Ivbm90ZS10YWtlciwg JiBkb2N1bWVudCBlZGl0b3IuDQoNCi0gICAgICAgICAgQSB0aW1lIG9mIGRheSB0aGF0IHdvcmtz IGZvciBhbGwga25vd24gcGFydGljaXBhbnRzOyBpLmUuIDE0MDAtMTYwMFogZm9yIGdsb2JhbCBt ZWV0aW5ncyAob25seSB0aGUgUGFjaWZpYyBpcyBkYXJrKTsgbG9uZ2VyIG1lZXRpbmdzIGFyZSBw b3NzaWJsZSB3aGVuIHBhcnRpY2lwYW50cyBhcmUgaW4gY2x1c3RlcmVkIFRacywgYnV0IDQtNSBo b3VycyAod2l0aCBhIHNob3J0IG1pZC1icmVhaykgaXMgYSBnb29kIHVwcGVyIGxpbWl0Lg0KDQot ICAgICAgICAgIE90aGVyd2lzZSBhIHNlcmllcyBvZiBzaG9ydCAoMS0yIGhvdXIpIHZpcnR1YWwg bWVldGluZ3Mgb3ZlciBhIGZldyBkYXlzIGlzIG9mdGVuIHZlcnkgcHJvZHVjdGl2ZSBpdCBhbGxv d3MgcmFwaWQgcmV2aWV3L2NvbW1lbnQgb24gdGhlIGxhdGVzdCBkb2N1bWVudCB1cGRhdGVzIG9m ZmxpbmUsIGZvciBhZ3JlZW1lbnQgb24gdGhlIG5leHQg4oCcY2FsbOKAnS4NCg0KSU1PIEZ0RiBt ZWV0aW5ncyBhcmUgYmVzdCB3aGVuIHRoZSBkaXNjdXNzaW9uIGlzIG1vcmUgb3Blbiwgd2hlcmUg 4oCcYm9keSBsYW5ndWFnZeKAnSBpcyBvZnRlbiBhcyBpbXBvcnRhbnQgYXMgdGhlIHNwb2tlbiB3 b3JkOyBhbmQgdG8gc2V0IHRoZSB0b25lIGZvciB0aGUgZ3JvdXAsIHRvIGFsbG93IHBhcnRpY2lw YW50cyB0byBnZXQgdG8ga25vdyBlYWNoIG90aGVyIGF0IGEgZGlmZmVyZW50IGxldmVsLiAgSG93 ZXZlciwgdGhlIG5hdHVyZSBvZiB0aGUgSUVURiBtZWV0aW5ncyBpcyBub3QgcmVhbGx5IGdvb2Qg Zm9yIHRoaXMsIGFzIGZvciBhbnkgb25lIFdHIHRoZSBtZWV0aW5ncyBhcmUgc2hvcnQsIGFuZCB3 aXRoIGEgc3BlY2lhbGlzdCBncm91cCBsaWtlIHRoaXMsIHNvbWV3aGF0IGRpbHV0ZWQgaW4gdGhl IGdlbmVyYWwgbWVsZWUgb2YgYW4gSUVURiBGdEYuICBHZW5lcmFsbHkgdGhlIGJlc3QgKG1vc3Qg ZGlzY3Vzc2lvbiAmL29yIGFncmVlbWVudDsgbW9zdCBjb3N0LWVmZmVjdGl2ZSkgRnRGIG1lZXRp bmdzIHNob3VsZCBzcGFuIHNldmVyYWwgZGF5cywgdG8gYWxsb3cgb2ZmbGluZSAmIHNvY2lhbCBk aXNjdXNzaW9uIGJldHdlZW4gZGVsZWdhdGVzIOKAkyBhdCBsZWFzdCBhIHdvcmtpbmcgbHVuY2gg b3IgdHdvLiAgTWl4ZWQgbWVldGluZ3MgKEZ0RiArIHJlbW90ZSkgYXJlIE9LIGFzIGEgYmFja3Vw IGlmIHRoZSBwcmltZSB2ZW51ZSBpcyB3ZWxsIGRlc2lnbmVkIGZvciB0aGUgcHVycG9zZTsgaS5l LiBhIGNvbmZlcmVuY2Ugcm9vbSB3aXRoIG11bHRpcGxlIG1pY3JvcGhvbmVzIGV0Yy47IGEgc3Bl YWtlcnBob25lIGluIGEgaG90ZWwgYmFsbHJvb20ganVzdCBkb2VzIG5vdCBjdXQgaXQsIGV2ZW4g d2l0aCBjb2xsYWJvcmF0aW9uIHRvb2xzLg0KDQpJbiB0aGlzIGNhc2Ugd2UgcHJvYmFibHkgZG9u 4oCZdCBoYXZlIGVub3VnaCBtYXRlcmlhbCBmb3IgbW9yZSB0aGFuIGEgZmV3IGhvdXJzIGRpc2N1 c3Npb24sIHNvIGEgc2hvcnQgdmlydHVhbCBtZWV0aW5nIG9yIHR3byBzaG91bGQgY292ZXIgaXQs IGJ1dCBpdCBuZWVkcyB0byBmb2xsb3cgdGhlIHByaW5jaXBsZXMgb3V0bGluZWQgYWJvdmUgdG8g YmUgZWZmZWN0aXZlLg0KDQpCUi9EYXZpZA0KDQpGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgU2hvY2tleQ0KU2VudDogV2Vk bmVzZGF5LCBKYW51YXJ5IDA2LCAyMDE2IDM6MDIgUE0NClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtD VE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+OyBFcmljIEJ1cmdlciA8ZWJ1cmdlckBzdGFu ZGFyZHN0cmFjay5jb20+OyBNb2Rlcm4gTGlzdCA8bW9kZXJuQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtNb2Rlcm5dIE1PREVSTiBJbnRlcmltIE1lZXRpbmcNCg0KDQpEaWQgc29tZW9uZSBzYXkg YmFyYmVjdWU/DQoNCkRyYXQgLi4gIEZvcmdldCBNaW5uZWFwb2xpcyAuLiBLQyBvciBBdXN0aW4g Zm9yIHRoZSBwZXJtZWFudCBob21lIG9mIElFVEYgbWVldGluZ3MuDQoNCg0K4oCUDQpSaWNoYXJk IFNob2NrZXkNClNob2NrZXkgQ29uc3VsdGluZyBMTEMNCkNoYWlybWFuIG9mIHRoZSBCb2FyZCBT SVAgRm9ydW0NCnd3dy5zaG9ja2V5LnVzPGh0dHA6Ly93d3cuc2hvY2tleS51cz4NCnd3dy5zaXBm b3J1bS5vcmc8aHR0cDovL3d3dy5zaXBmb3J1bS5vcmc+DQpyaWNoYXJkPGF0PnNob2NrZXkudXMN ClNreXBlLUxpbmtlZGluLUZhY2Vib29rIHJzaG9ja2V5MTAxDQpQU1ROICsxIDcwMy01OTMtMjY4 Mw0KDQoNCkZyb206IE1vZGVybiA8bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1vZGVy bi1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJQaWVyY2UuR29ybWFuQHNwcmludC5j b208bWFpbHRvOlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4iIDxQaWVyY2UuR29ybWFuQHNwcmlu dC5jb208bWFpbHRvOlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXks IEphbnVhcnkgNiwgMjAxNiBhdCA0OjI4IFBNDQpUbzogRXJpYyBCZXJnZXIgPGVidXJnZXJAc3Rh bmRhcmRzdHJhY2suY29tPG1haWx0bzplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbT4+LCBNb2Rl cm4gTGlzdCA8bW9kZXJuQGlldGYub3JnPG1haWx0bzptb2Rlcm5AaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtNb2Rlcm5dIE1PREVSTiBJbnRlcmltIE1lZXRpbmcNCg0KQ29vbC4gIEkgd29yayBh Ym91dCA1IG1pbGVzIGZyb20gdGhlcmUgYW5kIGNvdWxkIHByb2JhYmx5IGdldCB1cyBhIGNvbmZl cmVuY2Ugcm9vbSBmb3IgMTAwKyBwZW9wbGUgd2l0aCBsb3RzIG9mIGN1dGUgbWljcm9waG9uZXMg dGhhdCBoYW5nIGZyb20gdGhlIGNlaWxpbmcgKGJ1dCB3aGljaCBtaWdodCBzdGlsbCBwcm92aWRl IHRoZSBleHBlY3RlZCBmcnVzdHJhdGluZ2x5IGJhZCBhdWRpbyBmb3IgcGVvcGxlIG9uIHJlbW90 ZSBjb25uZWN0aW9ucykuICBMb3RzIG9mIGdvb2QgYmFyYmVjdWUgYW5kIG90aGVyIHJlbm93bmVk IG1pZHdlc3QgYXR0cmFjdGlvbnMuICBlLmcuLCBnb29kIGZlcm1lbnRlZCBhbmQgZGlzdGlsbGVk IGdyYWluIHNwaXJpdHMuDQoNCkZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVybi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBCdXJnZXINClNlbnQ6IEphbnVhcnkgMDYsIDIwMTYg MjoxNyBQTQ0KVG86IE1vZGVybiBMaXN0IDxtb2Rlcm5AaWV0Zi5vcmc8bWFpbHRvOm1vZGVybkBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01vZGVybl0gTU9ERVJOIEludGVyaW0gTWVldGluZw0K DQpHcmVhdC4gTGV04oCZcyBkbyBpdCBpbiBMZW5leGEuIENlbnRyYWxseSBsb2NhdGVkLiBFcXVh bGx5IGJhZCBmb3IgZXZlcnlib2R5Lg0KDQpBbHNvLCBpdOKAmXMgb25seSBhcHBsaWNhYmxlIHRv IHNvbWUgb2YgdXMsIGJ1dCB0aGUgZmlyc3Qgd2VlayBvZmZlcmVkIGlzIHRoZSBESFMgUEnigJlz IG1lZXRpbmcgaW4gV2FzaGluZ3RvbiBhbmQgdGhlIHNlY29uZCB3ZWVrIGlzIHRoZSBSU0EgQ29u ZmVyZW5jZSBpbiBTYW4gRnJhbmNpc2NvLg0KDQpPbiBKYW4gNiwgMjAxNiwgYXQgMTI6NDggUE0s IE1jR2FycnksIFRvbSA8VG9tLk1jR2FycnlAbmV1c3Rhci5iaXo8bWFpbHRvOlRvbS5NY0dhcnJ5 QG5ldXN0YXIuYml6Pj4gd3JvdGU6DQoNCkYyRiBlbmNvdXJhZ2VzIG1vcmUgcmlnb3JvdXMgZGlz Y3Vzc2lvbi4gIFlvdSBzYXkgc28geW91cnNlbGYuICBBbmQgdGhhdCdzIHdoYXQgd2UncmUgbG9v a2luZyBmb3IuICBXZSByZWFsaXplIHRoYXQgbm90IGV2ZXJ5b25lIGNhbiBhdHRlbmQgaW4gcGVy c29uLCBidXQgYXMgSSBzYWlkIHdlIHdpbGwgbWFrZSBzdXJlIHRvIHN1cHBvcnQgdGhlIHJlbW90 ZSBhdHRlbmRlZXMuDQoNCkZyb206IDxHb3JtYW4+LCBQaWVyY2UgR29ybWFuIDxQaWVyY2UuR29y bWFuQHNwcmludC5jb208bWFpbHRvOlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4+DQpEYXRlOiBX ZWRuZXNkYXksIEphbnVhcnkgNiwgMjAxNiAxOjQzIFBNDQpUbzogVG9tIE1jZ2FycnkgPHRvbS5t Y2dhcnJ5QG5ldXN0YXIuYml6PG1haWx0bzp0b20ubWNnYXJyeUBuZXVzdGFyLmJpej4+LCBNb2Rl cm4gTGlzdCA8bW9kZXJuQGlldGYub3JnPG1haWx0bzptb2Rlcm5AaWV0Zi5vcmc+Pg0KU3ViamVj dDogUkU6IFtNb2Rlcm5dIE1PREVSTiBJbnRlcmltIE1lZXRpbmcNCg0KVG8gYmUgbW9yZSBjbGVh ci4NCg0KTWFyeeKAmXMgcXVlc3Rpb24gd2FzbuKAmXQgd2hhdCBkaWQgeW91IGFuZCB0aGUgQURz IGhvcGUgZm9yIG91dCBvZiBhIGZhY2UtMi1mYWNlIGludGVyaW0gbWVldGluZy4NCg0KTWFyeeKA mXMgcXVlc3Rpb24gd2FzIHdoeSBpcyBhIGZhY2UtdG8tZmFjZSByZXF1aXJlZCBpbnN0ZWFkIG9m IGEgdmlydHVhbCBtZWV0aW5nIHdpdGggZXZlcnlvbmUgZXF1YWxseSBkaXNhZHZhbnRhZ2VkPw0K DQpNeSBxdWVzdGlvbiB3b3VsZCBoYXZlIGJlZW4gd2h5IGRvIHdlIG5lZWQgYW4gaW50ZXJpbSBt ZWV0aW5nPw0KDQpJIGJlbGlldmUgdGhlcmUgYXJlIG1lbWJlcnMgb2YgdGhlIHdvcmtpbmcgZ3Jv dXAgd2hvIGhhdmUgYmVlbiwgYW5kIGZlbHQsIG1hcmdpbmFsaXplZCBieSBib3RoIHRoZSBkZWZp bml0aW9uIG9mIGNvbnNlbnN1cyBhbmQgdGhlIGluYWJpbGl0eSB0byBhcmd1ZSBhYm91dCB3aGF0 IG9jY3VycmVkIGluIGEgbWVlaW5nIGhhbGZ3YXkgYXJvdW5kIHRoZSB3b3JsZCB3aGVyZSB0aGV5 IGVpdGhlciB3ZXJlbuKAmXQgYWJsZSB0byBhdHRlbmQgb3Igd2VyZSB1bmFibGUgdG8gYXR0ZW5k IGVxdWFsbHkgd2l0aCB0aGUgcGFydGljaXBhbnRzIGluIHRoZSByb29tIGZhY2UtdG8tZmFjZS4N Cg0KT25lIHdheSB0byBiZSBtb3JlIGluY2x1c2l2ZSwgYW5kIGVuc3VyZSBncmVhdGVyIChpZiBz b21ld2hhdCBkaXNhZHZhbnRhZ2VkKSBwYXJ0aWNpcGF0aW9uIHdvdWxkIGJlIHRvIGhvbGQgdGhl IGludGVyaW0gbWVldGluZyAoaWYgaXQgbXVzdCBiZSBoZWxkKSBhcyBhbiBpbnRlcmltIHZpcnR1 YWwgbWVldGluZyB2ZXJzdXMgZmFjZS10by1mYWNlLg0KDQpTaW5jZSBJ4oCZbSBuZXcgSSBkb27i gJl0IGtub3cgd2hhdCBpcyBjdXN0b21hcnksIGJ1dCBJIGluZmVycmVkIGZyb20gTWFyeeKAmXMg cXVlc3Rpb24gdGhhdCBhIHZpcnR1YWwgbWVldGluZyB3YXMgY3VzdG9tYXJ5IChhbmQgY2VydGFp bmx5IGNoZWFwZXIpLCBhbmQgc28gdGhlIHF1ZXN0aW9uIHlvdSBmYWlsZWQgdG8gYW5zd2VyIGhh cyBhZGRpdGlvbmFsIG1lcml0Lg0KDQpQaWVyY2UNCg0KRnJvbTogR29ybWFuLCBQaWVyY2UgQSBb Q1RPXQ0KU2VudDogSmFudWFyeSAwNiwgMjAxNiAxMjoyNCBQTQ0KVG86ICdNY0dhcnJ5LCBUb20n IDxUb20uTWNHYXJyeUBuZXVzdGFyLmJpejxtYWlsdG86VG9tLk1jR2FycnlAbmV1c3Rhci5iaXo+ PjsgTW9kZXJuIExpc3QgPG1vZGVybkBpZXRmLm9yZzxtYWlsdG86bW9kZXJuQGlldGYub3JnPj4N ClN1YmplY3Q6IFJFOiBbTW9kZXJuXSBNT0RFUk4gSW50ZXJpbSBNZWV0aW5nDQoNCllvdSBkaWRu 4oCZdCBhbnN3ZXIgTWFyeeKAmXMgcXVlc3Rpb24uDQoNCg0KRnJvbTogTW9kZXJuIFttYWlsdG86 bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNY0dhcnJ5LCBUb20NClNlbnQ6 IEphbnVhcnkgMDYsIDIwMTYgMTI6MTAgUE0NClRvOiBNb2Rlcm4gTGlzdCA8bW9kZXJuQGlldGYu b3JnPG1haWx0bzptb2Rlcm5AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtNb2Rlcm5dIE1PREVS TiBJbnRlcmltIE1lZXRpbmcNCg0KVGhlcmUgd2lsbCBiZSByZW1vdGUgYWNjZXNzLCB2aWRlbyBk ZXBlbmRpbmcgdXBvbiB2ZW51ZS4gIEkgc2hvdWxkIGhhdmUgbWVudGlvbmVkIHRoaXMuDQoNCldl J3JlIGhvcGluZyBieSBoYXZpbmcgcGVvcGxlIGYyZiwgd2l0aCBhIGdvb2QgYW1vdW50IG9mIHRp bWUsIHRvIGdlbmVyYXRlIHNvbWUgcHJvZHVjdGl2ZSBkaXNjdXNzaW9uLiAgV2UgZXhwZWN0IHJl bW90ZSBwYXJ0aWNpcGF0aW9uIGFuZCB3aWxsIGNlcnRhaW5seSBtYWtlIHN1cmUgdGhhdCBpdCBj YW4gYmUgZWZmZWN0aXZlLg0KDQpUaGFua3MgZm9yIHJlc3BvbmRpbmcgdG8gdGhlIHBvbGwuDQoN Cg0KRnJvbTogTWFyeSBCYXJuZXMgPG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPG1haWx0bzpt YXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDUsIDIw MTYgNjo0OSBQTQ0KVG86IFRvbSBNY2dhcnJ5IDx0b20ubWNnYXJyeUBuZXVzdGFyLmJpejxtYWls dG86dG9tLm1jZ2FycnlAbmV1c3Rhci5iaXo+Pg0KQ2M6IE1vZGVybiBMaXN0IDxtb2Rlcm5AaWV0 Zi5vcmc8bWFpbHRvOm1vZGVybkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01vZGVybl0gTU9E RVJOIEludGVyaW0gTWVldGluZw0KDQpJJ20gY3VyaW91cyBhcyB0byB3aHkgYSBmMmYgbWVldGlu ZyBpcyBiZWluZyBwcm9wb3NlZCBhcyBvcHBvc2VkIHRvIGEgdmlydHVhbCBpbnRlcmltPyAgIFRo ZSBjaGFsbGVuZ2UgaXMgdGhhdCB3aGVuIHRoZXJlIGFyZSBmb2xrcyBhdCBhIGYyZiBtZWV0aW5n IGFuZCBvdGhlcnMgdHJ5aW5nIHRvIHBhcnRpY2lwYXRlIHJlbW90ZWx5LCB0aGUgcmVtb3RlIHBh cnRpY2lwYW50cyBhcmUgb2Z0ZW4gbWFyZ2luYWxpemVkLiAgSXQncyBzdXJwcmlzaW5nbHkgcmFy ZSB0aGF0IHBlb3BsZSBjYW4gZ2V0IGEgbWVldGluZyByb29tIHNldHVwIHRoYXQgbWFrZXMgcmVt b3RlIHBhcnRpY2lwYXRpb24gd29yayB3ZWxsLg0KDQpSZWdhcmRzLA0KTWFyeS4NCg0KT24gVHVl LCBKYW4gNSwgMjAxNiBhdCAzOjI5IFBNLCBNY0dhcnJ5LCBUb20gPFRvbS5NY0dhcnJ5QG5ldXN0 YXIuYml6PG1haWx0bzpUb20uTWNHYXJyeUBuZXVzdGFyLmJpej4+IHdyb3RlOg0KRHVlIHRvIHRo ZSBsZW5ndGggb2YgdGltZSBiZXR3ZWVuIHRoZSBsYXN0IElFVEYgYW5kIHRoZSBuZXh0LCB0aGUg Y2hhaXJzIGFuZCBBRCBiZWxpZXZlIHdlIHNob3VsZCBoYXZlIGFuIGludGVyaW0gbWVldGluZy4g IFdlJ3JlIHByb3Bvc2luZyBkYXRlcyBpbiBsYXRlIEZlYnJ1YXJ5IHRvIGJlIGhlbGQgaW4gdGhl IFdhc2hpbmd0b24sIERDIGFyZWEuICBQbGVhc2UgbGV0IHVzIGtub3cgd2hhdCBkYXRlcyB3b3Jr IGJlc3QgZm9yIHlvdS4NCg0KaHR0cDovL2Rvb2RsZS5jb20vcG9sbC81dDVwOTh4NW5ubnRtbWNk PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19kb29k bGUuY29tX3BvbGxfNXQ1cDk4eDVubm50bW1jZCZkPUN3TUZhUSZjPU1PcHRObFZ0SUVUZURBTENf bFVMcncmcj00S2xtMzJpQjdIdWZ2ZWVJRGNMZXh0WjFvb05jZnAwMUlZSWFWcXNPUmpJJm09MUdt MllCeUtjczBmZGtGTTQ2aFB3OWhFU0F4WWxvOVBUb3JoZ3RPeDQydyZzPXBZa1hhcWJQeXV4THpW OUhEbDZuMDhSd0V6QnlSbVNlaGxfdjVtOXZlUEkmZT0+DQoNClRoYW5rcywNClRvbQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTW9kZXJuIG1haWxp bmcgbGlzdA0KTW9kZXJuQGlldGYub3JnPG1haWx0bzpNb2Rlcm5AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybjxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX21vZGVybiZkPUN3TUZhUSZjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmcj00S2xtMzJp QjdIdWZ2ZWVJRGNMZXh0WjFvb05jZnAwMUlZSWFWcXNPUmpJJm09MUdtMllCeUtjczBmZGtGTTQ2 aFB3OWhFU0F4WWxvOVBUb3JoZ3RPeDQydyZzPXdQUEh4Ukl5dld4c3Frc3N2YWozdGZKOWZBN05J RWtDUmdhZjk4bGM5XzQmZT0+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkxlYXJuIG1vcmUgb24gaG93IHRvIHN3aXRjaCB0byBTcHJpbnQgYW5kIHNhdmUgNTAlIG9uIG1v c3QgVmVyaXpvbiwgQVQmVCBvciBULU1vYmlsZSByYXRlcy4gU2VlIHNwcmludC5jb20vNTBvZmY8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Nwcmlu dC5jb21fNTBvZmYmZD1Dd01GQWcmYz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3JnI9NEtsbTMyaUI3 SHVmdmVlSURjTGV4dFoxb29OY2ZwMDFJWUlhVnFzT1JqSSZtPThsNDFSbE5ZbnppVXJjdmFvbFpK VzEzNm9uYm5MN3FkVGVGWHNhWlFWa2smcz1jUW82ZUtqUEJxLVdublkwNnR0OFdqcGI4RENrd0tv QWV2MmNqdlU4eWRvJmU9PiBmb3IgZGV0YWlscy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZv cm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFu eSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29w aWVzIG9mIHRoZSBtZXNzYWdlLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk1vZGVybiBtYWlsaW5nIGxpc3QNCk1vZGVybkBpZXRmLm9yZzxtYWlsdG86 TW9kZXJuQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t b2Rlcm4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTGVhcm4gbW9yZSBv biBob3cgdG8gc3dpdGNoIHRvIFNwcmludCBhbmQgc2F2ZSA1MCUgb24gbW9zdCBWZXJpem9uLCBB VCZUIG9yIFQtTW9iaWxlIHJhdGVzLiBTZWUgc3ByaW50LmNvbS81MG9mZjxodHRwOi8vc3ByaW50 LmNvbS81MG9mZj4gZm9yIGRldGFpbHMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNl IGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBv ZiB0aGUgbWVzc2FnZS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIE1vZGVybiBtYWlsaW5nIGxpc3QgTW9kZXJuQGlldGYub3JnPG1haWx0bzpNb2Rlcm5A aWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9kZXJuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMZWFybiBtb3JlIG9uIGhvdyB0byBz d2l0Y2ggdG8gU3ByaW50IGFuZCBzYXZlIDUwJSBvbiBtb3N0IFZlcml6b24sIEFUJlQgb3IgVC1N b2JpbGUgcmF0ZXMuIFNlZSBzcHJpbnQuY29tLzUwb2ZmPGh0dHA6Ly9zcHJpbnQuY29tLzUwb2Zm PiBmb3IgZGV0YWlscy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhp cyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVu ZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhl cnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1l c3NhZ2UuDQo= --_000_1b663c1a6e62475d8e123865fde98d9bPLSWE13M01adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBp bjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0 Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAwMENDOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm b250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTUwMzg5MTA4 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTYzNzU1 ODAxNCAtMTE2NDkxMTkwMiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmFzZWQgb24g YWJvdXQgYSBkZWNhZGUgb2YgdXNpbmcgcmVtb3RlIGNvb3BlcmF0aW9uIHRvb2xzIGZvciBzdGFu ZGFyZHMgbWVldGluZ3MgJmFtcDsgYWJvdXQgNDAgeWVhcnMgb2YgRnRGIHdvcmssIElNTyBib3Ro IGNhbiBiZSBlcXVhbGx5IHByb2R1Y3RpdmUgaWYgbWFuYWdlZCBwcm9wZXJseS4mbmJzcDsNCiBJ ZGVhbGx5IHlvdSB1c2UgYSBtaXh0dXJlIG9mIGJvdGgsIHNvIGlmIHRoaXMgaW50ZXJpbSBtZWV0 aW5nIGlzIHVzZWQgdG8gY29tcGxpbWVudCB0aGUgRnRGcyBhdCB0aGUgSUVURiBGdEZzLCBhIHZp cnR1YWwgbWVldGluZyBzaG91bGQgd29yayBmaW5lLiZuYnNwOyBIYXZpbmcgc2FpZCB0aGF0LCBh cyBQaWVyY2Ugbm90ZXMsIFNwcmludCBkb2VzIGhhdmUgYW4gZXhjZWxsZW50IGNvbmZlcmVuY2Ug ZmFjaWxpdHkgaW4gT3ZlcmxhbmQgUGFyayBLUywgd2hpY2gNCiB3ZSBoYXZlIHVzZWQgZm9yIG1h bnkgaW5kdXN0cnkgbWVldGluZ3MgaW4gdGhlIHBhc3QuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbWFrZSB2aXJ0dWFsIG1lZXRpbmdzIHdvcmsgd2VsbCwg eW91IG5lZWQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIG1lZXRpbmcgZm9ybWF0IHRoYXQgY2FuIHdvcmsg dXNpbmcgdGhlc2UgdGVjaG5pcXVlczsgZS5nLiBwcmVzZW50YXRpb24gb2YgbmV3IG1hdGVyaWFs IHdlYmluYXIgc3R5bGUsIGRpc2N1c3Npb24vZmluYWxpemF0aW9uIG9mIGNvbW1lbnRzL2VkaXRz IHRvDQogYSBwcmUtY2lyY3VsYXRlZCBkb2N1bWVudCwgYXMgd2UgYXJlIGN1cnJlbnRseSB0cnlp bmcgdG8gcGVyZm9ybSB2aWEgZW1haWwuJm5ic3A7IFZpcnR1YWwgbWVldGluZ3MgYXJlIG5vdCBv cHRpbXVtIGZvciBhIGZyZWUtZm9ybSBkaXNjdXNzaW9uLCB1bmxlc3MgdGhlIHBhcnRpY2lwYW50 cyBrbm93IGVhY2ggb3RoZXIgd2VsbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkdvb2QgcGFydGljaXBhbnQg ZGlzY2lwbGluZSwgJmFtcDsgc3Ryb25nIG1hbmFnZW1lbnQgYnkgdGhlIENoYWlyICZhbXA7IGZh Y2lsaXRhdG9yIChlLmcuIG11dGluZyBub2lzeSBsaW5lcywgZW5jb3VyYWdpbmcgdXNlIG9mIGhl YWRzZXRzIGZvciBhdWRpbykuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIGdvb2QgY29tbWVyY2lhbCByZWFs LXRpbWUgY29sbGFib3JhdGlvbiB0b29sIHRoYXQgbW9zdCBvZiB1cyBhbHJlYWR5IHVzZSAoc28g dGhhdCBpdCBpcyBpbnN0YWxsZWQgb24gY29ycG9yYXRlIFBDcyksIHRvIGFsbG93IGRvY3VtZW50 cyB0byBiZSBlZGl0ZWQNCiBvbiBzY3JlZW4gaW4gZnJvbnQgb2YgYWxsIHBhcnRpY2lwYW50czsg U2t5cGUgZm9yIEJ1c2luZXNzIChMeW5jKSwgR29Ub01lZXRpbmcsIG9yIFdlYmV4IGFyZSB0aG9z ZSBjb21tb25seSB1c2VkIGJ5IG90aGVyIFNET3M7IHRoZXkgZWFjaCBoYXZlIHRoZWlyIHNwZWNp ZmljIG1lcml0czsgU3ByaW50IHVzZXMgU2ZCICZhbXA7IHRoYXQgd29ya3MgZmluZS4gJm5ic3A7 VHJ5aW5nIHRvIGRpc2N1c3MgcHJlLWRpc3RyaWJ1dGVkIGRvY3VtZW50cyDigJxibGluZOKAnSBv dmVyDQogYW4gYXVkaW8tb25seSBsaW5rIGNhbiBiZSB2ZXJ5IHVucHJvZHVjdGl2ZS4gPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+TGVhZGVyc2hpcCB0aGF0IGNhbiB3b3JrIHdpdGggKCZhbXA7IGhhcyBleHBlcmll bmNlIG9mKSB0aGUgY29sbGFib3JhdGlvbiB0b29sOyBjb21tb25seSBuZWVkcyBhIHNlcGFyYXRl IENoYWlyLCBmYWNpbGl0YXRvci9ub3RlLXRha2VyLCAmYW1wOyBkb2N1bWVudCBlZGl0b3IuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5BIHRpbWUgb2YgZGF5IHRoYXQgd29ya3MgZm9yIGFsbCBrbm93biBwYXJ0 aWNpcGFudHM7IGkuZS4gMTQwMC0xNjAwWiBmb3IgZ2xvYmFsIG1lZXRpbmdzIChvbmx5IHRoZSBQ YWNpZmljIGlzIGRhcmspOyBsb25nZXIgbWVldGluZ3MgYXJlIHBvc3NpYmxlIHdoZW4NCiBwYXJ0 aWNpcGFudHMgYXJlIGluIGNsdXN0ZXJlZCBUWnMsIGJ1dCA0LTUgaG91cnMgKHdpdGggYSBzaG9y dCBtaWQtYnJlYWspIGlzIGEgZ29vZCB1cHBlciBsaW1pdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk90aGVy d2lzZSBhIHNlcmllcyBvZiBzaG9ydCAoMS0yIGhvdXIpIHZpcnR1YWwgbWVldGluZ3Mgb3ZlciBh IGZldyBkYXlzIGlzIG9mdGVuIHZlcnkgcHJvZHVjdGl2ZSBpdCBhbGxvd3MgcmFwaWQgcmV2aWV3 L2NvbW1lbnQgb24gdGhlIGxhdGVzdCBkb2N1bWVudA0KIHVwZGF0ZXMgb2ZmbGluZSwgZm9yIGFn cmVlbWVudCBvbiB0aGUgbmV4dCDigJxjYWxs4oCdLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPklNTyBGdEYgbWVldGluZ3MgYXJlIGJlc3Qgd2hlbiB0aGUgZGlz Y3Vzc2lvbiBpcyBtb3JlIG9wZW4sIHdoZXJlIOKAnGJvZHkgbGFuZ3VhZ2XigJ0gaXMgb2Z0ZW4g YXMgaW1wb3J0YW50IGFzIHRoZSBzcG9rZW4gd29yZDsgYW5kIHRvIHNldCB0aGUgdG9uZSBmb3Ig dGhlIGdyb3VwLA0KIHRvIGFsbG93IHBhcnRpY2lwYW50cyB0byBnZXQgdG8ga25vdyBlYWNoIG90 aGVyIGF0IGEgZGlmZmVyZW50IGxldmVsLiZuYnNwOyBIb3dldmVyLCB0aGUgbmF0dXJlIG9mIHRo ZSBJRVRGIG1lZXRpbmdzIGlzIG5vdCByZWFsbHkgZ29vZCBmb3IgdGhpcywgYXMgZm9yIGFueSBv bmUgV0cgdGhlIG1lZXRpbmdzIGFyZSBzaG9ydCwgYW5kIHdpdGggYSBzcGVjaWFsaXN0IGdyb3Vw IGxpa2UgdGhpcywgc29tZXdoYXQgZGlsdXRlZCBpbiB0aGUgZ2VuZXJhbCBtZWxlZQ0KIG9mIGFu IElFVEYgRnRGLiZuYnNwOyBHZW5lcmFsbHkgdGhlIGJlc3QgKG1vc3QgZGlzY3Vzc2lvbiAmYW1w Oy9vciBhZ3JlZW1lbnQ7IG1vc3QgY29zdC1lZmZlY3RpdmUpIEZ0RiBtZWV0aW5ncyBzaG91bGQg c3BhbiBzZXZlcmFsIGRheXMsIHRvIGFsbG93IG9mZmxpbmUgJmFtcDsgc29jaWFsIGRpc2N1c3Np b24gYmV0d2VlbiBkZWxlZ2F0ZXMg4oCTIGF0IGxlYXN0IGEgd29ya2luZyBsdW5jaCBvciB0d28u ICZuYnNwO01peGVkIG1lZXRpbmdzIChGdEYgJiM0MzsgcmVtb3RlKSBhcmUgT0sNCiBhcyBhIGJh Y2t1cCBpZiB0aGUgcHJpbWUgdmVudWUgaXMgd2VsbCBkZXNpZ25lZCBmb3IgdGhlIHB1cnBvc2U7 IGkuZS4gYSBjb25mZXJlbmNlIHJvb20gd2l0aCBtdWx0aXBsZSBtaWNyb3Bob25lcyBldGMuOyBh IHNwZWFrZXJwaG9uZSBpbiBhIGhvdGVsIGJhbGxyb29tIGp1c3QgZG9lcyBub3QgY3V0IGl0LCBl dmVuIHdpdGggY29sbGFib3JhdGlvbiB0b29scy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SW4gdGhpcyBjYXNlIHdlIHByb2JhYmx5IGRvbuKAmXQgaGF2ZSBl bm91Z2ggbWF0ZXJpYWwgZm9yIG1vcmUgdGhhbiBhIGZldyBob3VycyBkaXNjdXNzaW9uLCBzbyBh IHNob3J0IHZpcnR1YWwgbWVldGluZyBvciB0d28gc2hvdWxkIGNvdmVyIGl0LCBidXQgaXQgbmVl ZHMgdG8gZm9sbG93DQogdGhlIHByaW5jaXBsZXMgb3V0bGluZWQgYWJvdmUgdG8gYmUgZWZmZWN0 aXZlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJSL0Rhdmlk PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNb2Rlcm4gW21haWx0 bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmljaGFyZCBT aG9ja2V5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAwNiwgMjAxNiAzOjAy IFBNPGJyPg0KPGI+VG86PC9iPiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dICZsdDtQaWVyY2UuR29y bWFuQHNwcmludC5jb20mZ3Q7OyBFcmljIEJ1cmdlciAmbHQ7ZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20mZ3Q7OyBNb2Rlcm4gTGlzdCAmbHQ7bW9kZXJuQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW01vZGVybl0gTU9ERVJOIEludGVyaW0gTWVldGluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5EaWQgc29tZW9uZSBzYXkgYmFyYmVjdWU/ICZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5E cmF0IC4uICZuYnNwO0ZvcmdldCBNaW5uZWFwb2xpcyAuLiBLQyBvciBBdXN0aW4gZm9yIHRoZSBw ZXJtZWFudCBob21lIG9mIElFVEYgbWVldGluZ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05B VFVSRSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj7igJQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJpY2hhcmQg U2hvY2tleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2hvY2tleSBDb25zdWx0aW5n IExMQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2hhaXJtYW4gb2YgdGhlIEJvYXJk IFNJUCBGb3J1bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDov L3d3dy5zaG9ja2V5LnVzIj53d3cuc2hvY2tleS51czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2lwZm9ydW0ub3JnIj53d3cuc2lwZm9ydW0u b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+cmljaGFyZCZsdDthdCZndDtz aG9ja2V5LnVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Ta3lwZS1MaW5rZWRpbi1G YWNlYm9vayByc2hvY2tleTEwMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UFNUTiAm IzQzOzEgNzAzLTU5My0yNjgzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0K PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Nb2Rlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzptb2Rlcm4t Ym91bmNlc0BpZXRmLm9yZyI+bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOlBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbSI+UGll cmNlLkdvcm1hbkBzcHJpbnQuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOlBpZXJj ZS5Hb3JtYW5Ac3ByaW50LmNvbSI+UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKYW51YXJ5IDYsIDIwMTYgYXQgNDoyOCBQTTxicj4N CjxiPlRvOiA8L2I+RXJpYyBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzplYnVyZ2VyQHN0YW5k YXJkc3RyYWNrLmNvbSI+ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb208L2E+Jmd0OywgTW9kZXJu IExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzptb2Rlcm5AaWV0Zi5vcmciPm1vZGVybkBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTW9kZXJuXSBNT0RFUk4gSW50ZXJp bSBNZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5Db29sLiZuYnNwOyBJIHdvcmsgYWJvdXQgNSBt aWxlcyBmcm9tIHRoZXJlIGFuZCBjb3VsZCBwcm9iYWJseSBnZXQgdXMgYSBjb25mZXJlbmNlIHJv b20gZm9yIDEwMCYjNDM7IHBlb3BsZSB3aXRoIGxvdHMgb2YgY3V0ZSBtaWNyb3Bob25lcyB0aGF0 IGhhbmcgZnJvbSB0aGUgY2VpbGluZyAoYnV0DQogd2hpY2ggbWlnaHQgc3RpbGwgcHJvdmlkZSB0 aGUgZXhwZWN0ZWQgZnJ1c3RyYXRpbmdseSBiYWQgYXVkaW8gZm9yIHBlb3BsZSBvbiByZW1vdGUg Y29ubmVjdGlvbnMpLiZuYnNwOyBMb3RzIG9mIGdvb2QgYmFyYmVjdWUgYW5kIG90aGVyIHJlbm93 bmVkIG1pZHdlc3QgYXR0cmFjdGlvbnMuJm5ic3A7IGUuZy4sIGdvb2QgZmVybWVudGVkIGFuZCBk aXN0aWxsZWQgZ3JhaW4gc3Bpcml0cy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDAwQ0MiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiBNb2Rlcm4gWzxhIGhyZWY9 Im1haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1vZGVybi1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBCdXJnZXI8YnI+DQo8Yj5TZW50 OjwvYj4gSmFudWFyeSAwNiwgMjAxNiAyOjE3IFBNPGJyPg0KPGI+VG86PC9iPiBNb2Rlcm4gTGlz dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vZGVybkBpZXRmLm9yZyI+bW9kZXJuQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNb2Rlcm5dIE1PREVSTiBJbnRlcmltIE1l ZXRpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWF0LiBMZXTigJlzIGRvIGl0IGluIExl bmV4YS4gQ2VudHJhbGx5IGxvY2F0ZWQuIEVxdWFsbHkgYmFkIGZvciBldmVyeWJvZHkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbHNvLCBp dOKAmXMgb25seSBhcHBsaWNhYmxlIHRvIHNvbWUgb2YgdXMsIGJ1dCB0aGUgZmlyc3Qgd2VlayBv ZmZlcmVkIGlzIHRoZSBESFMgUEnigJlzIG1lZXRpbmcgaW4gV2FzaGluZ3RvbiBhbmQgdGhlIHNl Y29uZCB3ZWVrIGlzIHRoZSBSU0EgQ29uZmVyZW5jZSBpbiBTYW4gRnJhbmNpc2NvLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPk9uIEphbiA2LCAyMDE2LCBhdCAxMjo0OCBQTSwgTWNHYXJyeSwgVG9tICZsdDs8YSBo cmVmPSJtYWlsdG86VG9tLk1jR2FycnlAbmV1c3Rhci5iaXoiPlRvbS5NY0dhcnJ5QG5ldXN0YXIu Yml6PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5GMkYgZW5jb3VyYWdlcyBtb3JlIHJpZ29yb3VzIGRpc2N1c3Np b24uICZuYnNwO1lvdSBzYXkgc28geW91cnNlbGYuICZuYnNwO0FuZCB0aGF0J3Mgd2hhdCB3ZSdy ZSBsb29raW5nIGZvci4gJm5ic3A7V2UgcmVhbGl6ZSB0aGF0IG5vdCBldmVyeW9uZSBjYW4gYXR0 ZW5kIGluIHBlcnNvbiwgYnV0IGFzIEkNCiBzYWlkIHdlIHdpbGwgbWFrZSBzdXJlIHRvIHN1cHBv cnQgdGhlIHJlbW90ZSBhdHRlbmRlZXMuICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bHQ7R29ybWFuJmd0OywgUGllcmNlIEdvcm1hbg0KICZsdDs8YSBocmVmPSJtYWlsdG86UGllcmNl Lkdvcm1hbkBzcHJpbnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5QaWVyY2UuR29y bWFuQHNwcmludC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5LCBKYW51YXJ5 IDYsIDIwMTYgMTo0MyBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VG9tIE1jZ2FycnkgJmx0OzxhIGhyZWY9Im1haWx0bzp0 b20ubWNnYXJyeUBuZXVzdGFyLmJpeiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dG9tLm1j Z2FycnlAbmV1c3Rhci5iaXo8L3NwYW4+PC9hPiZndDssIE1vZGVybiBMaXN0ICZsdDs8YSBocmVm PSJtYWlsdG86bW9kZXJuQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tb2Rl cm5AaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UkU6IFtNb2Rlcm5dIE1PREVS TiBJbnRlcmltIE1lZXRpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5UbyBi ZSBtb3JlIGNsZWFyLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5NYXJ54oCZcyBxdWVzdGlvbiB3YXNu 4oCZdCB3aGF0IGRpZCB5b3UgYW5kIHRoZSBBRHMgaG9wZSBmb3Igb3V0IG9mIGEgZmFjZS0yLWZh Y2UgaW50ZXJpbSBtZWV0aW5nLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5NYXJ54oCZcyBxdWVzdGlv biB3YXMgd2h5IGlzIGEgZmFjZS10by1mYWNlIHJlcXVpcmVkIGluc3RlYWQgb2YgYSB2aXJ0dWFs IG1lZXRpbmcgd2l0aCBldmVyeW9uZSBlcXVhbGx5IGRpc2FkdmFudGFnZWQ/PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDAwQ0MiPk15IHF1ZXN0aW9uIHdvdWxkIGhhdmUgYmVlbiB3aHkgZG8gd2UgbmVlZCBhbiBp bnRlcmltIG1lZXRpbmc/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPkkgYmVsaWV2ZSB0aGVyZSBhcmUg bWVtYmVycyBvZiB0aGUgd29ya2luZyBncm91cCB3aG8gaGF2ZSBiZWVuLCBhbmQgZmVsdCwgbWFy Z2luYWxpemVkIGJ5IGJvdGggdGhlIGRlZmluaXRpb24gb2YgY29uc2Vuc3VzIGFuZCB0aGUgaW5h YmlsaXR5IHRvIGFyZ3VlIGFib3V0IHdoYXQNCiBvY2N1cnJlZCBpbiBhIG1lZWluZyBoYWxmd2F5 IGFyb3VuZCB0aGUgd29ybGQgd2hlcmUgdGhleSBlaXRoZXIgd2VyZW7igJl0IGFibGUgdG8gYXR0 ZW5kIG9yIHdlcmUgdW5hYmxlIHRvIGF0dGVuZCBlcXVhbGx5IHdpdGggdGhlIHBhcnRpY2lwYW50 cyBpbiB0aGUgcm9vbSBmYWNlLXRvLWZhY2UuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6NS44cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPk9uZSB3YXkgdG8gYmUgbW9yZSBpbmNsdXNpdmUs IGFuZCBlbnN1cmUgZ3JlYXRlciAoaWYgc29tZXdoYXQgZGlzYWR2YW50YWdlZCkgcGFydGljaXBh dGlvbiB3b3VsZCBiZSB0byBob2xkIHRoZSBpbnRlcmltIG1lZXRpbmcgKGlmIGl0IG11c3QgYmUg aGVsZCkgYXMgYW4gaW50ZXJpbQ0KIHZpcnR1YWwgbWVldGluZyB2ZXJzdXMgZmFjZS10by1mYWNl Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjUuOHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDo1LjhwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+U2luY2UgSeKAmW0gbmV3IEkgZG9u4oCZdCBrbm93IHdo YXQgaXMgY3VzdG9tYXJ5LCBidXQgSSBpbmZlcnJlZCBmcm9tIE1hcnnigJlzIHF1ZXN0aW9uIHRo YXQgYSB2aXJ0dWFsIG1lZXRpbmcgd2FzIGN1c3RvbWFyeSAoYW5kIGNlcnRhaW5seSBjaGVhcGVy KSwgYW5kIHNvIHRoZSBxdWVzdGlvbg0KIHlvdSBmYWlsZWQgdG8gYW5zd2VyIGhhcyBhZGRpdGlv bmFsIG1lcml0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjUuOHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDo1LjhwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+UGllcmNlPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5Hb3JtYW4sDQogUGllcmNlIEEgW0NUT108c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkphbnVhcnkgMDYsIDIwMTYgMTI6MjQg UE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPidNY0dhcnJ5LCBUb20nICZsdDs8YSBocmVmPSJtYWlsdG86VG9tLk1jR2FycnlA bmV1c3Rhci5iaXoiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlRvbS5NY0dhcnJ5QG5ldXN0 YXIuYml6PC9zcGFuPjwvYT4mZ3Q7OyBNb2Rlcm4gTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1v ZGVybkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bW9kZXJuQGlldGYub3Jn PC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBbTW9kZXJuXSBNT0RFUk4gSW50ZXJpbSBN ZWV0aW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAwMENDIj5Zb3UgZGlkbuKAmXQgYW5zd2VyIE1hcnnigJlzIHF1ZXN0aW9uLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDo1LjhwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5Nb2Rlcm4NCiBbPGEgaHJlZj0ibWFpbHRvOm1vZGVybi1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5v cmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5NY0dhcnJ5LCBUb208YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmFudWFyeSAwNiwgMjAxNiAx MjoxMCBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+TW9kZXJuIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzptb2Rlcm5AaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1vZGVybkBpZXRmLm9yZzwvc3Bhbj48 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW01vZGVybl0gTU9ERVJOIEludGVyaW0gTWVldGluZzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlRoZXJlIHdpbGwgYmUgcmVtb3RlIGFjY2VzcywgdmlkZW8gZGVwZW5kaW5nIHVwb24g dmVudWUuICZuYnNwO0kgc2hvdWxkIGhhdmUgbWVudGlvbmVkIHRoaXMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldlJ3JlIGhvcGluZyBieSBoYXZp bmcgcGVvcGxlIGYyZiwgd2l0aCBhIGdvb2QgYW1vdW50IG9mIHRpbWUsIHRvIGdlbmVyYXRlIHNv bWUgcHJvZHVjdGl2ZSBkaXNjdXNzaW9uLiAmbmJzcDtXZSBleHBlY3QgcmVtb3RlIHBhcnRpY2lw YXRpb24gYW5kIHdpbGwgY2VydGFpbmx5IG1ha2Ugc3VyZQ0KIHRoYXQgaXQgY2FuIGJlIGVmZmVj dGl2ZS4gJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlRoYW5rcyBmb3IgcmVzcG9uZGluZyB0byB0aGUgcG9sbC4gJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+TWFyeSBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ5Lmll dGYuYmFybmVzQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFyeS5pZXRm LmJhcm5lc0BnbWFpbC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwgSmFudWFy eSA1LCAyMDE2IDY6NDkgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlRvbSBNY2dhcnJ5ICZsdDs8YSBocmVmPSJtYWlsdG86 dG9tLm1jZ2FycnlAbmV1c3Rhci5iaXoiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRvbS5t Y2dhcnJ5QG5ldXN0YXIuYml6PC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Nb2Rlcm4gTGlzdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1vZGVybkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+bW9kZXJuQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbTW9kZXJu XSBNT0RFUk4gSW50ZXJpbSBNZWV0aW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSdtIGN1cmlvdXMgYXMgdG8gd2h5IGEg ZjJmIG1lZXRpbmcgaXMgYmVpbmcgcHJvcG9zZWQgYXMgb3Bwb3NlZCB0byBhIHZpcnR1YWwgaW50 ZXJpbT8gJm5ic3A7IFRoZSBjaGFsbGVuZ2UgaXMgdGhhdCB3aGVuIHRoZXJlIGFyZSBmb2xrcyBh dCBhIGYyZiBtZWV0aW5nIGFuZCBvdGhlcnMNCiB0cnlpbmcgdG8gcGFydGljaXBhdGUgcmVtb3Rl bHksIHRoZSByZW1vdGUgcGFydGljaXBhbnRzIGFyZSBvZnRlbiBtYXJnaW5hbGl6ZWQuJm5ic3A7 IEl0J3Mgc3VycHJpc2luZ2x5IHJhcmUgdGhhdCBwZW9wbGUgY2FuIGdldCBhIG1lZXRpbmcgcm9v bSBzZXR1cCB0aGF0IG1ha2VzIHJlbW90ZSBwYXJ0aWNpcGF0aW9uIHdvcmsgd2VsbC4gJm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+TWFyeS4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gVHVlLCBKYW4gNSwgMjAxNiBhdCAzOjI5IFBNLCBN Y0dhcnJ5LCBUb20gJmx0OzxhIGhyZWY9Im1haWx0bzpUb20uTWNHYXJyeUBuZXVzdGFyLmJpeiIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlRvbS5NY0dhcnJ5QG5l dXN0YXIuYml6PC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RHVlIHRvIHRo ZSBsZW5ndGggb2YgdGltZSBiZXR3ZWVuIHRoZSBsYXN0IElFVEYgYW5kIHRoZSBuZXh0LCB0aGUg Y2hhaXJzIGFuZCBBRCBiZWxpZXZlIHdlIHNob3VsZCBoYXZlIGFuIGludGVyaW0gbWVldGluZy4m bmJzcDsgV2UncmUgcHJvcG9zaW5nIGRhdGVzIGluIGxhdGUgRmVicnVhcnkNCiB0byBiZSBoZWxk IGluIHRoZSBXYXNoaW5ndG9uLCBEQyBhcmVhLiZuYnNwOyBQbGVhc2UgbGV0IHVzIGtub3cgd2hh dCBkYXRlcyB3b3JrIGJlc3QgZm9yIHlvdS4gJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19kb29kbGUuY29tX3BvbGxfNXQ1cDk4eDVu bm50bW1jZCZhbXA7ZD1Dd01GYVEmYW1wO2M9TU9wdE5sVnRJRVRlREFMQ19sVUxydyZhbXA7cj00 S2xtMzJpQjdIdWZ2ZWVJRGNMZXh0WjFvb05jZnAwMUlZSWFWcXNPUmpJJmFtcDttPTFHbTJZQnlL Y3MwZmRrRk00NmhQdzloRVNBeFlsbzlQVG9yaGd0T3g0MncmYW1wO3M9cFlrWGFxYlB5dXhMelY5 SERsNm4wOFJ3RXpCeVJtU2VobF92NW05dmVQSSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vZG9vZGxlLmNvbS9wb2xsLzV0NXA5OHg1bm5u dG1tY2Q8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5UaGFua3MsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Ub208L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpNb2Rlcm4gbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk1vZGVybkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+TW9kZXJuQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX21vZGVybiZhbXA7ZD1Dd01GYVEmYW1wO2M9TU9wdE5sVnRJRVRlREFM Q19sVUxydyZhbXA7cj00S2xtMzJpQjdIdWZ2ZWVJRGNMZXh0WjFvb05jZnAwMUlZSWFWcXNPUmpJ JmFtcDttPTFHbTJZQnlLY3MwZmRrRk00NmhQdzloRVNBeFlsbzlQVG9yaGd0T3g0MncmYW1wO3M9 d1BQSHhSSXl2V3hzcWtzc3ZhajN0Zko5ZkE3TklFa0NSZ2FmOThsYzlfNCZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50 ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5MZWFybiBtb3JlIG9u IGhvdyB0byBzd2l0Y2ggdG8gU3ByaW50IGFuZCBzYXZlIDUwJSBvbiBtb3N0IFZlcml6b24sIEFU JmFtcDtUIG9yIFQtTW9iaWxlIHJhdGVzLiBTZWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NwcmludC5jb21fNTBvZmYmYW1wO2Q9Q3dNRkFnJmFt cDtjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmYW1wO3I9NEtsbTMyaUI3SHVmdmVlSURjTGV4dFox b29OY2ZwMDFJWUlhVnFzT1JqSSZhbXA7bT04bDQxUmxOWW56aVVyY3Zhb2xaSlcxMzZvbmJuTDdx ZFRlRlhzYVpRVmtrJmFtcDtzPWNRbzZlS2pQQnEtV25uWTA2dHQ4V2pwYjhEQ2t3S29BZXYyY2p2 VTh5ZG8mYW1wO2U9Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zcHJpbnQuY29tLzUwb2Zm PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+Zm9yDQogZGV0YWlscy48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9 InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGhyIHNp emU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5Ij48YnI+DQpUaGlzIGUtbWFp bCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBw cm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug Y29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk1vZGVybiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TW9kZXJuQGlldGYu b3JnIj5Nb2Rlcm5AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tb2Rlcm4iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW9kZXJuPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ TGVhcm4gbW9yZSBvbiBob3cgdG8gc3dpdGNoIHRvIFNwcmludCBhbmQgc2F2ZSA1MCUgb24gbW9z dCBWZXJpem9uLCBBVCZhbXA7VCBvciBULU1vYmlsZSByYXRlcy4gU2VlDQo8YSBocmVmPSJodHRw Oi8vc3ByaW50LmNvbS81MG9mZiI+c3ByaW50LmNvbS81MG9mZjwvYT4gZm9yIGRldGFpbHMuIDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIyIiB3 aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Z3JheSI+PGJyPg0KVGhpcyBlLW1haWwgbWF5IGNv bnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3Qg dGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gTW9kZXJu IG1haWxpbmcgbGlzdA0KPGEgaHJlZj0ibWFpbHRvOk1vZGVybkBpZXRmLm9yZyI+TW9kZXJuQGll dGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21vZGVybiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybjwv YT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IkJsYWNrIiBzaXplPSIyIj48Yj5MZWFybiBtb3JlIG9uIGhvdyB0byBz d2l0Y2ggdG8gU3ByaW50IGFuZCBzYXZlIDUwJSBvbiBtb3N0IFZlcml6b24sIEFUJmFtcDtUIG9y IFQtTW9iaWxlIHJhdGVzLiBTZWUNCjxhIGhyZWY9Imh0dHA6Ly9zcHJpbnQuY29tLzUwb2ZmIj5z cHJpbnQuY29tLzUwb2ZmPC9hPiBmb3IgZGV0YWlscy4gPGJyPg0KPC9iPjwvZm9udD48YnI+DQo8 aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NClRoaXMg ZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRl ZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJz IGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNz YWdlLjxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1b663c1a6e62475d8e123865fde98d9bPLSWE13M01adsprintcom_-- From nobody Mon Jan 11 15:07:28 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 EA2301AC423 for ; Mon, 11 Jan 2016 15:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 P86TFN1soxd2 for ; Mon, 11 Jan 2016 15:07:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8011AC414 for ; Mon, 11 Jan 2016 15:07:18 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0BN7G2G084417 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Jan 2016 17:07:16 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Gorman, Pierce A [CTO]" , "McGarry, Tom" , "modern@ietf.org" References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> From: Adam Roach Message-ID: <569435A3.6060906@nostrum.com> Date: Mon, 11 Jan 2016 17:07:15 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> Content-Type: multipart/alternative; boundary="------------090100080603060906030708" Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 23:07:22 -0000 This is a multi-part message in MIME format. --------------090100080603060906030708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/10/16 17:36, Gorman, Pierce A [CTO] wrote: > *Learn more on how to switch to Sprint and save 50% on most Verizon, > AT&T or T-Mobile rates. See sprint.com/50off > for details. * Really? /a --------------090100080603060906030708 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/10/16 17:36, Gorman, Pierce A [CTO] wrote:
Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.

Really?

/a
--------------090100080603060906030708-- From nobody Mon Jan 11 15:21:31 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 1C1D31AC416 for ; Mon, 11 Jan 2016 15:21:28 -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 YFBfdzFqR18P for ; Mon, 11 Jan 2016 15:21:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F141A912F for ; Mon, 11 Jan 2016 15:21:20 -0800 (PST) Received: from BN1AFFO11FD013.protection.gbl (10.58.52.32) by BN1AFFO11HUB031.protection.gbl (10.58.52.141) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 11 Jan 2016 23:20:59 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) 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.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN1AFFO11FD013.mail.protection.outlook.com (10.58.52.73) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 11 Jan 2016 23:20:59 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u0BJgGVU039952; Mon, 11 Jan 2016 18:20:58 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm1.corp.sprint.com with ESMTP id 20ayjfa33f-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Jan 2016 18:20:58 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 11 Jan 2016 17:20:57 -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; Mon, 11 Jan 2016 17:20:57 -0600 From: "Gorman, Pierce A [CTO]" To: Adam Roach , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Problem statement draft problems Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaugEkKSiAACzib4ABPUe9kAA+y+6AAAwpkoA= Date: Mon, 11 Jan 2016 23:20:57 +0000 Message-ID: <36e966ea7ce140fb86c960fd0b60236a@PLSWE13M08.ad.sprint.com> References: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com> <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> <569435A3.6060906@nostrum.com> In-Reply-To: <569435A3.6060906@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.27] Content-Type: multipart/related; boundary="_004_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD013; 1:jY7oL8NRUe4r+926O6q904VMI1d8JmYc2H96JZaDRXvxXkjvsLe2HxzADwyKKRVKBd6XOz6Ws1KDcyroNKpULwMX5zGcBI7qVxZiFu6x6fTZxzdngvAMSYtWsD93ra+ZZ0JI9XRrec6WuQmA/TcyUk4FHlv9pki9cT9qMz2mnp5hWsVWRf1T2BJcgl2MOGGXVqxnHfSmrydPQnXDruJIn53X31JDI2dsbtdXeF3iYyAJsbcN0kdPAf/J9It0yy+sq4YH63F1yRInd0x5nKzMmJEFzYXUFn3vbnH0SsXemudZjEa9yE+VFKiVUfZ7m2LxY1nDvxn9w/1kI2Xy+/YoFui5OQ8b4RNhQfbICfaaA71G00CQb2jGbE8L2qGrCItArmcRcYQKlsg7fRHk5cKVAg== X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(377454003)(479174004)(24454002)(189002)(199003)(6116002)(66926002)(99936001)(19617315012)(512874002)(19627595001)(24736003)(11100500001)(50986999)(6806005)(790700001)(5008740100001)(33646002)(5250100002)(84326002)(102836003)(86362001)(1220700001)(54356999)(1096002)(15975445007)(2501003)(3846002)(106466001)(575784001)(2906002)(92566002)(300700001)(108616004)(2900100001)(586003)(19300405004)(67866002)(81156007)(5003600100002)(107886002)(16236675004)(2950100001)(5001770100001)(97736004)(18206015028)(189998001)(30436002)(5004730100002)(17760045003)(19580395003)(19580405001)(15395725005)(93886004)(76176999)(87936001)(19625215002)(5001960100002)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB031; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-MS-Office365-Filtering-Correlation-Id: e7806fa4-5221-4867-c319-08d31adddd5f X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB031; 2:qwNzI0Cf8i0/ccB6oarIhbnr94kED0SAFKFcPgUZC10KM6vmCLY2HM26Jlk3oQo4AoowE36GhHyTeaa6OfZFPFOZb9rwLXtKLlnF66D33WyUFQ4m6WoU8AXJS3f/c3hUqAqAYQzW1PyXrxz+Fs+eqXJwL/R1DjE5E1wl+dX58y4Se0rCB5mzHenrjRB1eZgd; 3:a4eA8QwLi16EjYElG/sfojk/7737esLl3Qa0/xwByI8kyeqL2oaJVffo5JXWmz6NHqiAKErl1d8z77CCBnHE+v279QLdeQutLQWfiQqhV3svj+W11+TzKnhXSp3YApwMZvTA3xgvZ+yaqfAxxxLTgermK+jGkEj/PFtugs85rmjt9X7MGptebNedCab+H0yozAad2AjfjWh2dBpwioNVAJkAJGW/ZD1lmm0JIj96r+UllToJyyppUhDty/+FtG0+Kp+c/KHX1+jAU4CPoMA4Qw==; 25:h3Xe3BoT3yFVJYTW3K+DqY139BiGAF9UMcTU9infSNqrXYgZugeEqdQQgIHbrJr/3Sgi+exB24KRk1+wvEfjTWt4hjXLSULwdO+7CPp2HdHYKHbYPjx4tT7RuhdjuTZNTgH1LSwoioqNLGxLeT2LmD5QyAz93rGxyo8kCD+NSW5QuKFrF7um35gr+e+ZX0nL4/d/E2BTKL/cKrvFgSpK0ZliMQs4W/+CGrZif5d4YuiM3kXTt23c9E/Utf8xzuZ7 X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB031; UriScan:(18430343700868); X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB031; 20:ai6GeTqfRC5P+/aRffrmQ0sLDlx96sx2jvPLLi8qUPNkfemIBVxU8dgEs0XzoW3DiwLyTEN5IZZnCcSgaka/LkfyeKLOpmDAt/PAKmgkR0CQgj+Kkppalb+oz61cPOE/eriBtqafpqwZVwNhhKyNx10aEvGvwYone6iNIYRFnnIJ3U+rMMjbr75+fKIgtUO57D8l9sk5IUS05WWY2ARxKVFp5y6Fp9Vhq6I0CEa2ewKGedURkG6m1MPxkrh+nkuF; 4:++bR4QwRzIOzACjngY7d6I3VIJFQroIf6Yt5YBn8dTxjmfJYqbGAWBKRAfLRREGvWCRNTVjwt7lwxjT4FHv57rTOJP5r513Gi1p2eYNIG8v4brWo0cu9nmCKJyVFEN54AAa+wT5+9SAKYI/OcscJC4lkFA4uqp51IQENm4MWugYLIlxEfC8UB9qHC+KOxozOsM+Fn4qEZ8HJw0ejFb5Qa3wW/vYXp9I5Lf/Jzo56p1zv4Yyls/onxYIfrbPAbXZNlYhz5YxGJaoR8I3OzYkyupyzuf/+WD+cTjVhzPf8dsq/QCLhSiZB/iVseoQMk4D4C0xuWTAM/ib6ldfgdqkIMEYYSmU/bqZ+eDWNuanCxzXeXW3A2QAqMw/q5okwqBl7QEHknmd7A5z4EsN+tRM0IZgF5gvHlJ02mfzpSgiZYz8oC2vnXyc3wEKkkP3tx7S1/0XC+VSRvlQ+LGTv+krZXy9glUciiQw+eaoY8bIcuNFA9z3Efojmifv1HJp90wSF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102615245)(601004)(2401047)(5005006)(520078)(13018025)(13015025)(13017025)(8121501046)(3002001)(10201501046); SRVR:BN1AFFO11HUB031; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB031; X-Forefront-PRVS: 0818724663 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB031; 23:4yFQYr3qYjLp4pqXXOIXGoCvBCgAZqsmZFJ9GJ+?= =?us-ascii?Q?+kMuSdZ488Rhqv7Y4qmXAdlQzL5zdzET2NknZ0o4IHK4z/shrT9RU6k0qwNN?= =?us-ascii?Q?OLlqYQexIYpJUAv/9s50F8CiBe2qBlebOKqwakkr6qHXlAGDkc14wsn/9KKa?= =?us-ascii?Q?Wq/LOLs+7ictWHJ5etL79/cxxylnTO4ewTTkqzNlkwYPMWspfeL3H4dbRbTy?= =?us-ascii?Q?ZXEZr5wdzV5HK54stGzWd3b30jOtPAiyro/uBcbAmvwg3WMMYUDtLcsHi5nh?= =?us-ascii?Q?d+NfUxdQ0v5lqhcI8/XZGWkGVwtU+vqLiTDh4Mx2KLsQXrEKCt+tautySqyC?= =?us-ascii?Q?ErERexOXNg5FcbBT+NlhkWUugDo0FZUOIGkqGmFoQJapylfOPjR5rvt6oER1?= =?us-ascii?Q?jGpQaVHsl5C3vaw3D006JS3ycDkQlBprnKZsIqZZjrVUf8H5YmDwPTJdDrOR?= =?us-ascii?Q?OD5D2Em/Ofa6p1DoXtOvxI5CxHikB0p9Cwe3Cf/r5ssEIoccbvoocmcljEao?= =?us-ascii?Q?GOrHc8VWynZA+QyLc0+AeykvO1t5wRXiOZdSmjwzsfbrq1VBoVy/JsL/j7we?= =?us-ascii?Q?28aw2W0Ork4NxYZ1wuvym/BrVxTmNCa9YpT+exCTiFBDWzEoCvsopgoY6T6F?= =?us-ascii?Q?uwatLB673LIx6hptqzX2XX1wGSAv1Wy6kWZXEYaOpfnbhc74xO0WgSb0FfeR?= =?us-ascii?Q?6Hmlj61ikOsyWeBR24L5dIjiC8PS/uQcpQi9qicPH587Qq7cX2RmwbpXbDNu?= =?us-ascii?Q?19B+kLYZJF3iMAhCSNjEDyfFMSiaA+rBTkmICewLLf9Z5WKklzegAfTqR8i+?= =?us-ascii?Q?jfduXdfV3N8YKVKuZcBkApnaPFQqTKZ0jXUbAcHq2AuXVCr7aFU6NoAvbXiI?= =?us-ascii?Q?CvXSw3fEZShkKv9bXJXtMp3TjZeC9RTKrxUe7hxZzxQIZ0HOH/XjyKKi0yZI?= =?us-ascii?Q?CyixPcO30wMjXqDJsnc+PuhJg3jVxQCXovbAE2tP2oZ5NUmRdr1fTq0wT1St?= =?us-ascii?Q?tuV4BDB+fUo9UEMeP7F7pAI/H7ywMnEpXHM8fE/3KPBcldtg8gVbj7MgkReT?= =?us-ascii?Q?bC1y+goyZPxjrCPMFMRLJvCuD8x0SirpMZXeF3L8S11BTBgFfV80w/xu7uCW?= =?us-ascii?Q?pgnvrSgeHwLtL6TSxC8wtcgY/V/qIqoGuQExe5d2gmmcdqkDnZ0Med7Voc5X?= =?us-ascii?Q?3hZNeL9OZgdSITnaX4oQzAuvSCPF/79DKZls7CRBrSXONitRk1DSf5F82tRX?= =?us-ascii?Q?GsPMp3Q+XiOJrepegh6Rwgl8vu852v4exmYeY+UXNg0MCTSjFeQCGzslPD5L?= =?us-ascii?Q?/mnpVAWx7+kQpHbgVUAkRt5wSbQ+XME+Hh3b246ZPnOoqFjuREltDr+OOzCv?= =?us-ascii?Q?PdzaIEz0wAhyhloBC/2TCLpy1NTDgZsAiebC7m1rNe+tD4rc7mcXeDyjKwYy?= =?us-ascii?Q?X4nJchQC2QTJgiNN7J1DMvevacJkOu8utInVs4oJ7rb/6s2dRHNdCrmUKCu7?= =?us-ascii?Q?MezSEAIGoRPL1jY3/yaX+ejkldY26JhYesw2nIFgdtjxJAMXr5FydwyMt2f9?= =?us-ascii?Q?MtWRaeQhxOehT8EnexsM70SfDSX/cTDJkJrsLmmsdhpX6GBGeFkTiJ8Ph7Zx?= =?us-ascii?Q?X?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB031; 5:XCT0ZvALQDvBcVTkQwzAAPyfPwTaa1NDPUyk30JImwR0nNvMzsKtUcm/VJBzJAUzg/F53kYrcZU6/8zTj25pASSkMq0LvifcCVr1xgya9ug6MVowRlSCOtbYrpJzKIoo5JL8uUuvfzmorWhycbMwww==; 24:k4ccYn/ONnNIKkgrruFEHGFGMz4y7kFCUPPRTslmmC3jzzJn/KwK9bro2uJrm23uxrfAieGVQ8yljzo8qSceQ3OmnkPeT7+MoLpR13LK48I= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2016 23:20:59.2727 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB031 Archived-At: Subject: Re: [Modern] Problem statement draft problems X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 23:21:28 -0000 --_004_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_" --_000_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIHdyb3RlIHRoYXQgYW5kIEkgcGxhY2UgaXQgYXQgdGhlIGJvdHRvbSBvZiBldmVyeSBz aW5nbGUgZS1tYWlsIGlzc3VlZCBieSBldmVyeSBzaW5nbGUgU3ByaW50IGVtcGxveWVlIHdobyBz ZW5kcyBlLW1haWwgb3V0c2lkZSBvZiBTcHJpbnQgYmVjYXVzZSBJ4oCZbSBqdXN0IHRoYXQgZ29v ZC4NCg0KT3IsIHdhaXQuICBObywgc29ycnkuICBJIHdhcyB0aGlua2luZyBvZiBzb21ldGhpbmcg ZWxzZS4gIEkgaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGggdGhlIGFkdmVydGlzaW5nIHRoYXQgZ2V0 cyBhcHBlbmRlZCB0byBvdXIgZS1tYWlscy4gIEJ1dCB3aGF0IGEgZ3JlYXQgZGVhbCwgZWghPw0K DQpCZXN0IHJlZ2FyZHMsDQoNCg0KUGllcmNlIEdvcm1hbg0KcGllcmNlLmdvcm1hbkBzcHJpbnQu Y29tDQpbTWFjaW50b3NoIEhEOlVzZXJzOnN0ZXBoYW5pZS5sYWVtb2E6RGVza3RvcDptb3ZlZm9y d2FyZF8xLnBuZ10NCg0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21d DQpTZW50OiBKYW51YXJ5IDExLCAyMDE2IDU6MDcgUE0NClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtD VE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+OyBNY0dhcnJ5LCBUb20gPFRvbS5NY0dhcnJ5 QG5ldXN0YXIuYml6PjsgbW9kZXJuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01vZGVybl0gUHJv YmxlbSBzdGF0ZW1lbnQgZHJhZnQgcHJvYmxlbXMNCg0KT24gMS8xMC8xNiAxNzozNiwgR29ybWFu LCBQaWVyY2UgQSBbQ1RPXSB3cm90ZToNCkxlYXJuIG1vcmUgb24gaG93IHRvIHN3aXRjaCB0byBT cHJpbnQgYW5kIHNhdmUgNTAlIG9uIG1vc3QgVmVyaXpvbiwgQVQmVCBvciBULU1vYmlsZSByYXRl cy4gU2VlIHNwcmludC5jb20vNTBvZmY8aHR0cDovL3NwcmludC5jb20vNTBvZmY+IGZvciBkZXRh aWxzLg0KDQpSZWFsbHk/DQoNCi9hDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpMZWFybiBtb3JlIG9uIGhvdyB0byBzd2l0Y2ggdG8gU3ByaW50IGFuZCBzYXZlIDUwJSBvbiBt b3N0IFZlcml6b24sIEFUJlQgb3IgVC1Nb2JpbGUgcmF0ZXMuIFNlZSBzcHJpbnQuY29tLzUwb2Zm PGh0dHA6Ly9zcHJpbnQuY29tLzUwb2ZmPiBmb3IgZGV0YWlscy4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3By aWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lw aWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= --_000_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMwMDAwQ0M7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0K CXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPlllcywgSSB3cm90ZSB0aGF0IGFuZCBJIHBsYWNl IGl0IGF0IHRoZSBib3R0b20gb2YgZXZlcnkgc2luZ2xlIGUtbWFpbCBpc3N1ZWQgYnkgZXZlcnkg c2luZ2xlIFNwcmludCBlbXBsb3llZSB3aG8gc2VuZHMgZS1tYWlsIG91dHNpZGUgb2YgU3ByaW50 IGJlY2F1c2UgSeKAmW0ganVzdA0KIHRoYXQgZ29vZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMDBDQyI+T3IsIHdhaXQuJm5ic3A7IE5vLCBzb3JyeS4mbmJzcDsgSSB3YXMgdGhp bmtpbmcgb2Ygc29tZXRoaW5nIGVsc2UuJm5ic3A7IEkgaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGgg dGhlIGFkdmVydGlzaW5nIHRoYXQgZ2V0cyBhcHBlbmRlZCB0byBvdXIgZS1tYWlscy4mbmJzcDsg QnV0IHdoYXQgYSBncmVhdCBkZWFsLCBlaCE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAwMENDIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1yaWdodDo1LjhwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6NS44cHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JTt0ZXh0LWF1dG9zcGFjZTpub25lIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+UGllcmNlIEdvcm1h bjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLXJpZ2h0OjUuOHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+cGllcmNlLmdv cm1hbkBzcHJpbnQuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmln aHQ6NS44cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbWJyaWEmcXVvdDssc2VyaWY7Y29sb3I6IzAwMDBDQyI+PGltZyB3aWR0aD0iNDA2IiBoZWln aHQ9IjYyIiBpZD0iUGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMTRD OTQuNkU3MkU3QjAiIGFsdD0iTWFjaW50b3NoIEhEOlVzZXJzOnN0ZXBoYW5pZS5sYWVtb2E6RGVz a3RvcDptb3ZlZm9yd2FyZF8xLnBuZyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAw MENDIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBBZGFtIFJvYWNoIFttYWlsdG86YWRhbUBu b3N0cnVtLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBKYW51YXJ5IDExLCAyMDE2IDU6MDcgUE08 YnI+DQo8Yj5Ubzo8L2I+IEdvcm1hbiwgUGllcmNlIEEgW0NUT10gJmx0O1BpZXJjZS5Hb3JtYW5A c3ByaW50LmNvbSZndDs7IE1jR2FycnksIFRvbSAmbHQ7VG9tLk1jR2FycnlAbmV1c3Rhci5iaXom Z3Q7OyBtb2Rlcm5AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNb2Rlcm5dIFBy b2JsZW0gc3RhdGVtZW50IGRyYWZ0IHByb2JsZW1zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMTAvMTYgMTc6MzYsIEdvcm1hbiwgUGll cmNlIEEgW0NUT10gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TGVhcm4gbW9yZSBvbiBob3cgdG8gc3dpdGNoIHRv IFNwcmludCBhbmQgc2F2ZSA1MCUgb24gbW9zdCBWZXJpem9uLCBBVCZhbXA7VCBvciBULU1vYmls ZSByYXRlcy4gU2VlDQo8YSBocmVmPSJodHRwOi8vc3ByaW50LmNvbS81MG9mZiI+c3ByaW50LmNv bS81MG9mZjwvYT4gZm9yIGRldGFpbHMuIDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpSZWFsbHk/PGJyPg0KPGJyPg0K L2E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwi IGNvbG9yPSJCbGFjayIgc2l6ZT0iMiI+PGI+TGVhcm4gbW9yZSBvbiBob3cgdG8gc3dpdGNoIHRv IFNwcmludCBhbmQgc2F2ZSA1MCUgb24gbW9zdCBWZXJpem9uLCBBVCZhbXA7VCBvciBULU1vYmls ZSByYXRlcy4gU2VlDQo8YSBocmVmPSJodHRwOi8vc3ByaW50LmNvbS81MG9mZiI+c3ByaW50LmNv bS81MG9mZjwvYT4gZm9yIGRldGFpbHMuIDxicj4NCjwvYj48L2ZvbnQ+PGJyPg0KPGhyPg0KPGZv bnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpUaGlzIGUtbWFpbCBt YXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS48YnI+ DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_-- --_004_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3693; creation-date="Mon, 11 Jan 2016 23:20:57 GMT"; modification-date="Mon, 11 Jan 2016 23:20:57 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAA+AZYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp3MklrIJRloj99fT3FTfaYvMjTdzIMoex qRlDqQehrGvYWgi2DOIm3xn0HcVw4mpPDJ1I6x/L/h1+PqbU0ptRe5t0VlPqLx6nEmcxSKuR6E96 0llR3ZFYFl+8AelbUcTTrOSi9U7ESpyjZvqPoooroIOe/t25/uxfkf8AGj+3bn+7F+R/xrb+yW// ADwi/wC+BR9kt/8AnhF/3wK8L6hj/wDn+dnt6P8AIYn9u3P92L8j/jR/btz/AHYvyP8AjW39kt/+ eEX/AHwKPslv/wA8Iv8AvgUfUMf/AM/w9vR/kMT+3bn+7F+R/wAaP7duf7sX5H/Gtv7Jb/8APCL/ AL4FH2S3/wCeEX/fAo+oY/8A5/h7ej/IYn9u3P8Adi/I/wCNH9u3P92L8j/jW39kt/8AnhF/3wKP slv/AM8Iv++BR9Qx/wDz/D29H+QxP7duf7sX5H/Gj+3bn+7F+R/xrb+yW/8Azwi/74FH2S3/AOeE X/fAo+oY/wD5/h7ej/IYn9u3P92L8j/jR/btz/di/I/41t/ZLf8A54Rf98Cj7Jb/APPCL/vgUfUM f/z/AA9vR/kMT+3bn+7F+R/xo/t25/uxfkf8a2/slv8A88Iv++BR9kt/+eEX/fAo+oY//n+Ht6P8 hif27c/3YvyP+NH9u3P92L8j/jW39kt/+eEX/fAo+yW//PCL/vgUfUMf/wA/w9vR/kMT+3bn+7F+ R/xo/t25/uxfkf8AGtv7Jb/88Iv++BR9kt/+eEX/AHwKPqGP/wCf4e3o/wAhif27c/3YvyP+NH9u 3P8Adi/I/wCNbf2S3/54Rf8AfAo+yW//ADwi/wC+BR9Qx/8Az/D29H+QxP7duf7sX5H/ABo/t25/ uxfkf8a2/slv/wA8Iv8AvgUfZLf/AJ4Rf98Cj6hj/wDn+Ht6P8hif27c/wB2L8j/AI0f27c/3Yvy P+Nbf2S3/wCeEX/fAo+yW/8Azwi/74FH1DH/APP8Pb0f5DE/t25/uxfkf8aP7duf7sX5H/Gtv7Jb /wDPCL/vgUfZLf8A54Rf98Cj6hj/APn+Ht6P8hif27c/3YvyP+NH9u3P92L8j/jW39kt/wDnhF/3 wKPslv8A88Iv++BR9Qx//P8AD29H+QxP7duf7sX5H/Gj+3bn+7F+R/xrb+yW/wDzwi/74FH2S3/5 4Rf98Cj6hj/+f4e3o/yGJ/btz/di/I/40f27c/3YvyP+Nbf2S3/54Rf98Cj7Jb/88Iv++BR9Qx// AD/D29H+QxP7duf7sX5H/Gj+3bn+7F+R/wAa2/slv/zwi/74FH2S3/54Rf8AfAo+oY//AJ/h7ej/ ACGJ/btz/di/I/40f27c/wB2L8j/AI1t/ZLf/nhF/wB8Cj7Jb/8APCL/AL4FH1DH/wDP8Pb0f5DE /t25/uxfkf8AGj+3bn+7F+R/xrb+yW//ADwi/wC+BR9kt/8AnhF/3wKPqGP/AOf4e3o/yGJ/btz/ AHYvyP8AjR/btz/di/I/41t/ZLf/AJ4Rf98Cj7Jb/wDPCL/vgUfUMf8A8/w9vR/kMT+3bn+7F+R/ xo/t25/uxfkf8a2/slv/AM8Iv++BR9kt/wDnhF/3wKPqGP8A+f4e3o/yGJ/btz/di/I/40f27c/3 YvyP+Nbf2S3/AOeEX/fAo+yW/wDzwi/74FH1DH/8/wAPb0f5DE/t26/uxfkf8a3omLwox6soJxTP slv/AM8Iv++BUoAAAAwB2rtwWHxFFt1qnNcyq1ISS5I2Fqvewia2cY52nFWKa5ARi3QDmu6cVKLj LZmKdndHONIPtSyNz5YH5gcUlrMYLo3Lknrkf3ie1V2cM5P8Oc1JFG9w21Fz79hXwyqzVVOGru2l 3ff0X4+h6zilHXY3bHUo70EY2SL1U0VFY6aIMueWIxk0V9hhPrHsl7e3MeZU5OZ8mxpUVyuqfETR dL1SawlnR5IXhRisqYDSMVxyf4cZb0p9p480678az+GRHKl3Eu5ZGxsk+UNgc56HP4V1mZ09FczJ 4709PHMfhdY5nvGXLSLjYp2lsHnOcfzroftUH2jyPPi87GfL3jdj6daAJaKYkscjMqOrMhwwByVP vTGu7dIPOa4iEPTzC42/nQBNRWD4p8W23hbT7a7lt57sXM6wRJb4JZiCR1PtT9B8Q3GsyzJcaJqW miJQwa7RVD+wwTQBt0VFDdQXAYwTRShThijhsH3xTTe2oAJuYQGGQfMHPagCeim+YgkEe9d5GQue ceuKje8to4mle4iWNTtLlwAD6ZoAmoqP7RDsR/Nj2OcK24Yb6etNe8to4fNe4iWLO3eXAGfTNAE1 FYukeJI9X1zWNNS3aNtMeNGkLAiTcucgdq2qACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsbVL4zH7LbZfP3yv8AKtC4ge4JVnYR/wB1 eM/U0sFnFAuFUAegFcmIp1K6dOL5U931+X/B+41pyjB8z1ZkWujvJgzHA/uj/GtmG2jgUKqgAdql AxS08Ng6OGX7ta9+oqlWdT4mFFFFdRmeM3PgzW9R8ayzSW9l5cuqEmV9OGzbHHkMfVWJ2+7c0msW jxeJvFWuWKZvNCvbW6RRxui8vEi/Tb/KvZ6hFpbhpmEEQM3Ep2D95xj5vXj1oA8e06yuLfxn4Z1C VANU1WK8vpN3951JjX6BdoqiBoH/AAriS4lkH/CZeeSWLH7Z9p8zgAfexj8Pxr29rW3aaOVoIjLE MRuUGUHse1RnTLE3n2s2dt9q/wCe3lLv/wC+sZoA8t8SaheeCtcurso/neIdKCBYx0vVAX/2aquq 6JJouveH9Guzpa6db6b+5/tQMbZ7gtmQnBA388Z7V7BPa29yYzcQRSmNtyF0DbT6jPQ0l1Z219F5 V5bw3Eec7JUDD8jQB4hqUBTwjZQ2mqW88LeI0Fu9rG/lWxIOVj3/AHlB5GCR712Pjiy1rTPAlyt5 rFxqMb3MX2mVIFiaO3z84wnb1PpXemwtDDFCbWAxRENGnljahHQgdqnZQylWAIIwQe9AHliroMHj vRF8FNb+W9vN/aAs2zH5Oz5S+OM59ec4rP8ACXguw1j4QXVzFBv1O5hlCSliSNjllVR0Ayo6etet 2um2ViHFnZ29uH+/5USru+uBzUkFvDawiK3ijijHREUKB+AoA8Ph8T3jT2vj1t5t7RU0xoyPvEwk s308wirrWNnp1p4X0jUba0kvJbaS+eTU7kx2odzltygfO/YemK9f/s2y+zG2+x2/kE7jF5S7SfXG MZpbrT7O+VFu7WCdUOVEsYbafbPSgDweEJe+D4bMyp9m/wCEqWKMW7kIiMp4jJ5A5yK63WtL0PSv H2j6Xq8MFv4cisZGtYpm/cG4LnduJOCcHvXpQ02yC7RZ2+3zPNx5S/f/AL3Tr7067sbW/jEd5bQ3 CA5CyxhwD9DQB5/8Mf7PHifxaNIYGxE8Pk4JI27W6Z7dce2K9HqKK1ggd3hgijZ8byiAFscDOOtS 0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAcb43m1G0vLa7aTUE0OGJmum0+RVljfIw7Z5KAZ4FR/8JtqCXjP9ht20tdQFgsvmnzXLKCr AYxjnmuh1bw3puuTRSajC83ljaE811RhnOGUHB/Gs/TfBllbareaheRrPPJdPNB8zbYlKhR8ucbs A84oAwB4w1KaDS9WurZIRLbXdxFDFcNsZUjBG8Y55Bx6VFrPjDX5NGukEFrZXAt7a8R4pWYrHI4X b0+9n8ME12Z8L6Q1pbWxslMNtC8ES7m+VHGGHXuKLnwvpF3FLHNZqyy26Wr/ADNzGpyo69jznrQB dsI547RBdlTcN80mxiyhj1Ck849KKfaWsVlaRW0AYRRKFXcxY4HqTyaKAP/Z --_004_36e966ea7ce140fb86c960fd0b60236aPLSWE13M08adsprintcom_-- From nobody Wed Jan 20 11:08: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 823FA1ACD5F for ; Wed, 20 Jan 2016 11:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.035 X-Spam-Level: * X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_28=0.6, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 agp3dTR4BZkx for ; Wed, 20 Jan 2016 11:08:08 -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 AD7741ACD5C for ; Wed, 20 Jan 2016 11:08:08 -0800 (PST) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u0KJ48pL029516 for ; Wed, 20 Jan 2016 14:08:08 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 20fhcwptyp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 20 Jan 2016 14:08:07 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.39]) with mapi id 14.03.0158.001; Wed, 20 Jan 2016 14:08:06 -0500 From: "McGarry, Tom" To: Modern List Thread-Topic: Responses to Sections 1 and 2 Comments Thread-Index: AQHRU7XkdQ4ai0fY8kmOCq+ZcMp/+A== Date: Wed, 20 Jan 2016 19:08:05 +0000 Message-ID: In-Reply-To: <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.90] Content-Type: multipart/alternative; boundary="_000_D2C53F0833A98tommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-20_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601200321 Archived-At: Subject: [Modern] Responses to Sections 1 and 2 Comments X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:08:13 -0000 --_000_D2C53F0833A98tommcgarryneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the feedback Pierce. Here are responses to your comments in Sec= tions 1 and 2. Please see below. From: , Pierce Gorman > Date: Sunday, January 10, 2016 6:36 PM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Problem statement draft problems As promised, below are my remaining edits and editorial comments. The format of my comments is as follows: - Section reference - Quoted content from the Problem Statement - Recommended edits and/or editorial comments I'll preface the work below by saying I have completely read the document w= ord for word and my previous estimation remains that the main issue with th= e problem statement is that it fails to meet the burden of proof that there= is a problem that needs to be solved. A problem statement is something like, "The alligators in the swamp adjoini= ng my back yard keep eating my pets." A solution statement would be something like, "In order to deal with the is= sue(s) outlined in the problem statement, it is recommended that a strong f= ence be constructed (which prevents access to my pets from alligators in th= e swamp adjoining my back yard)." 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. Respectfully, Pierce Gorman _________________________________________________________ 1. Problem Statement "In an Internet environment, establishing a network architecture for routin= g TNs would depend little on geography." I recommend changing the word "would" in the previous sentence to "could". Tom: OK At a minimum the routing of calls to and from TNs is impacted by the geogra= phy and the policies of the nation in which the TN is assigned regardless o= f the layer 2/3 network transport. The fundamental problem with the line o= f reasoning in this sentence is that it misses the fact that geography is a= key consideration in TN assignment, service provisioning, delivery and ass= urance, that must not be dismissed or overlooked but recognized and dealt w= ith. "Adapting TNs to the Internet requires more security, richer datasets and m= ore complex query and response capabilities than previous efforts have prov= ided." Can you provide comparative examples to"previous efforts" illustrating why = more security, richer datasets and more complex query and response capabili= ties are required? If so, it will be helpful to the reader. If not, then = you should strike the sentence. Tom: Earlier versions of the draft provided specific previous examples, bu= t people objected to it as protocol bashing, so the examples no longer appe= ar in the draft. "With the PSTN well on its way to transitioning to an all IP network,and TN= s showing no signs of sunsetting as a resource, it is time to address the i= ssues of routing, management and administration of TNs in an IP environment= ." The subject at the end of the sentence is ironically juxtaposed to the preq= ualifying assumptive phrases at the beginning of the sentence. That is, if the PSTN is already "well on its way to transitioning to an all= IP network", then how can it be that now is the "time to address the issue= s of routing, management and administration of TNs in an IP environment?" It can be argued that the proof that those issues have already been address= ed adequately is the very the fact that the PSTN is already "well on its wa= y to transitioning to an all IP network". I would strike the sentence as being unnecessary to the MODERN problem stat= ement. Tom: OK Section 2.1 "The following actors are defined in this document: Numbering Authority: A regulatory body within a country that manages that = country's TNs. The Numbering Authority decides national numbering policy, = including what TNs can be allocated, and which are reserved." Countries can and do have more than one numbering authority. Either change= the wording or change the actor name to "National Numbering Authority" and= add a subcategory for "Regional or otherwise subtended Numbering Authority= (to the National Numbering Authority)". I would change "The Numbering Authority decides national numbering policy" = to "The Numbering Authority decides numbering policy for the nation, region= , or other domain for which it has authority". Tom: OK "There are two types of Registries an authoritative Registry and a distribu= ted Registry. An authoritative Registry is a single entity with sole responsibility = for specific numbering resources. Distributed Registries are multiple Registries responsible for the same num= bering resources. (There's more on distributed Registries later in this se= ction.) The general term Registry in this document refers to both kinds of Registri= es. When referring to one versus the other this document will use the spec= ific term." I recommend breaking out each registry type as it's own actor. Tom: OK I also am struggling with your use of the term "registry" whereas I think y= ou're referring not so much to registries (i.e., database services) so much= as database models with respect specifically to non-duplicated versus dupl= icated data. The database models you described can have hybrids. One hybrid could be multiple independent distributed (in the sense that the= y are non-collocated and/or in different administrative domains) databases = who collectively represent an authoritative (i.e., non-duplicative) set of = assignment data. An example of this model would be the set of .com top-lev= el domain name databases. Another hybrid could contain top level (e.g., Numbering Plan Area) assignme= nts maintained in a single national-level non-duplicative authoritative dat= abase and subtending assignments maintained in distributed (non-duplicative= or duplicative) databases managed by regional numbering authorities. "User: An individual reachable through a communications service; usually a= customer of a communication service provider who uses TNs to reach and ide= ntify services. Sophisticated users may also act as their own CSPs." The "User" actor definition is ambiguous. To reduce ambiguity consider striking the phrase, "...who uses TNs to reach= and identify services" from the first sentence of the definition (assuming= the phrase refers to the CSP and not the User). The phrase is uncessary a= nd does not add clarity. Tom: OK I recommend striking the 2nd sentence, "Sophisticated users may also act as= their own CSPs." Doing so would not presumably preclude a sophisticated u= ser from being a CSP, but it appears to be a statement of policy or capabil= ity and isn't clear in either case. Tom: This is a statement of role, not policy. "Government Entity: An entity that, due to legal powers deriving from nati= onal policy, has privileged access to information about number administrati= on under certain conditions. Note that a given entity may act in one or more of the roles above. An enti= ty acting as a CSP, Service Enabler, or User can also be said to have a rel= ationship to the Registry of either an assignee or delegate:" The "entity" stuff is confusing. Tom: I agree, the term entity should be removed in the descriptive text. Are you indicating that an "entity" is somehow different from an "Actor"? = Or, are you saying that an entity is a special kind of "Actor"? How about replacing the phrase, "a given entity" with the phrase, "an actor= "? How about removing the phrase, "An entity acting as" in the 2nd sentence of= the 2nd paragraph? "Assignee: An entity that is assigned a TN by the Registry. There is alwa= ys a direct relationship between the Registry and the assignee. Delegate: An entity that is delegated a TN from an assignee or another del= egate. Delegates may use a TN for a communications service or delegate it = in turn." I didn't understand the need for the qualification, "There is always a dire= ct relationship between the Registry and the assignee" in the definition of= the Assignee actor. I would avoid the use of the term, "entity", and replace the entire Assigne= e actor definition with the following: "Assignee: An actor that is assigned a TN by the Registry." Similarly, I would replace the word "entity" with "actor" in the definition= for Delegate. The second sentence in the definition of the Delegate is confusing and ambi= guous. The phrase "Delegates may use a TN for a communications service" is written= such that it could imply that a TN could be used as a form of communicatio= ns service although clearly this wasn't the intent. And the end of the sen= tence referring to additional delegation is too open-ended and should not b= e combined with the first part of the sentence. I recommend breaking the sentence into 2 parts. First change the phrase, "Delegates may use a TN for a communications servi= ce" to be a sentence reading, "Delegates may associate a TN with a communic= ations service." Second change the phrase, "or delegate it in turn" to be a sentence reading= , "Delegates may delegate one or more of their TN assignment(s)to one or m= ore further downstream subdelegates who may also delegate their assignment(= s). There can be up to 1024 levels of sub-delegation." (Just kidding abou= t the 1024 levels, but you get the idea.) Tom: The second sentences in the definitions are to further explain the di= fference between the two definitions. I'll clarify the text. Section 2.2 "Administrative Data: assignment data related to the TN and the relevant a= ctors; it includes TN status, contact data for the assignee or delegate, et= c. and typically does not require real-time performance." What is meant by "TN status"? Tom: assigned, unassigned, etc. I'll add a parenthetical definition. If the definition of "TN status" is clear, unambiguous, and short, use that= instead. If it is not, delete it from the definition of "Administrative D= ata". "Service Data: data necessary to enable service for the TN; it includes ad= dressing data, feature capabilities, etc. and typically does require real-t= ime performance." If examples or the definition of "feature capabilities" is clear, unambiguo= us, and short, use that instead. If it is not, delete it from the definiti= on of "Service Data". Tom: I'll change it to "features" Delete "etc.". Define what is meant by "real-time performance" in the context of it being = a requirement. i.e., what part of the problem statement indicates a need f= or real-time, or non-real-time performance? If we look at existing numbering and registration systems (in North America= ) as an example, what about their real-time, near-real-time, or non-real-ti= me performance is a problem to be solved? "Public: data that anyone can access, for example a list of which numberin= g resources are available for acquisition from the Registry." Define "numbering resources". Tom: Will add a parenthetical definition. Define "available". "Semi-restricted: data that a somewhat broad subset of actors can access, = for example CSPs may be able to access other CSP's service data." Delete the words "somewhat broad". Tom: OK Delete the example. Defining policy should be outside the scope of the pro= blem statement should it not? "Restricted: data that is only available to a small subset of actors, for = example a Government Entity may be able access contact information for a Us= er." Delete the example. Tom: I believe the examples are helpful and not confusing. As you acknowledge there are really only two categories; unrestricted and r= estricted. Degree of restriction is a matter of policy. 2.3 Data Management Architectures "Beyond traditional centralized Registries, this framework also supports en= vironments where the same data is being managed by multiple entities, and s= tored in many locations." I would delete this paragraph for being inappropriate to a problem statemen= t. Save it for the solution to the problem(s). Tom: This is covered in the use cases and defining it here is helpful to t= he flow of the document. "Data store: a service that stores and enables access to administrative an= d/or service data. Typically Registries and CSPs would manage data stores.= " I would delete the last sentence, "Typically Registries and CSPs would mana= ge data stores." Tom: OK "Reference Address: a URL that dereferences to the location of the data st= ore." This is an artifact of a presupposed solution to a problem and does not bel= ong in a problem statement. I would delete this and save it for a solution= statement. Tom: A reference address is a well understood method to access a data stor= e. This is one of multiple solutions described in the use cases. "Distributed Registries: refers to multiple Registries managing the same n= umbering resource. Actors could interact with one or multiple Registries. = The Registries would update each other when change occurs. The challenge = is to ensure there are no clashes, e.g., two Registries assigning the same = TN to two different actors." Define "numbering resource". I would delete, "The Registries would update each other when change occurs.= The challenge is to ensure there are no clashes, e.g., two Registries ass= igning the same TN to two different actors." These statements presuppose a solution architecture and make assumptions ab= out the type of TN being assigned. These statements do not belong in a pro= blem statement. They should be saved for a solution statement. Tom: These are described in the use cases and I believe it is helpful to d= efine it here. --_000_D2C53F0833A98tommcgarryneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <8505F9C6DE51A141BFA21A25E6913DE9@neustar.biz> Content-Transfer-Encoding: quoted-printable
Thanks for the feedback Pierce.  Here are responses to your comments i= n Sections 1 and 2.  Please see below.

From: <Gorman>, Pierce Gorman= <Pierce.Gorman@sprint.com>
Date: Sunday, January 10, 2016 6:36= PM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>, Modern List &l= t;modern@ietf.org>
Subject: RE: [Modern] Problem state= ment draft problems

As promised, below are my remaining edits and edi= torial comments.

 

The format of my comments is as follows:

 

- Section reference

- Quoted content from the Problem Statement<= /o:p>

- Recommended edits and/or editorial comments

 

I'll preface the work below by saying I have comp= letely read the document word for word and my previous estimation remains t= hat the main issue with the problem statement is that it fails to meet the = burden of proof that there is a problem that needs to be solved.

 

A problem statement is something like, "The = alligators in the swamp adjoining my back yard keep eating my pets."

 

A solution statement would be something like, &qu= ot;In order to deal with the issue(s) outlined in the problem statement, it= is recommended that a strong fence be constructed (which prevents access t= o my pets from alligators in the swamp adjoining my back yard)."

 

The MODERN problem statement is in fact a TN mana= gement solution framework.  i.e., a solution looking for a problem.

 

If there is a problem that MODERN addresses, it i= s the inability of end users to directly (through a protocol) manage requis= ition and release of TNs and manage their associated metadata.  This i= s not a protocol problem.  It is a policy problem (if it is a problem at all).  And the only provisioning proto= col I remember seeing referenced in the solution statement is a SIP REGISTE= R.  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 start over.  Do not introduce any text that even= resembles a solution framework.  The problems can then be easily iden= tified and discussed.  And I encourage discussion of policy as part of the problem so that in the end you can hopefully clea= rly differentiate between issues that are political and issues which are te= chnical and therefore appropriate for the MODERN WG.

 

Respectfully,

 

Pierce Gorman

_____________________= ____________________________________

 

1.  Problem Statement

 

"In an Internet environment, establishing a net= work architecture for routing TNs would depend little on geography."

 

I recommend changing the word "would" = in the previous sentence to "could".

Tom:  OK

 

At a minimum the routing of calls to and from TN= s is impacted by the geography and the policies of the nation in which the = TN is assigned regardless of the layer 2/3 network transport.  The fundamental problem with the line of reas= oning in this sentence is that it misses the fact that geography is a key c= onsideration in TN assignment, service provisioning, delivery and assurance= , that must not be dismissed or overlooked but recognized and dealt with.

 

&quo= t;Adapting TNs to the I= nternet requires more security, richer datasets and more complex query and = response capabilities than previous efforts have provided."

 

Can = you provide comparative examples to"previous efforts" illustratin= g why more security, richer datasets and more complex query and response ca= pabilities are required?  If so, it will be helpful to the reader.  If not, then you should strike the sentence.


Tom:  Earlier versions of the draft provided specific = previous examples, but people objected to it as protocol bashing, so the ex= amples no longer appear in the draft. 

 

&quo= t;With the PSTN well on= its way to transitioning to an all IP network,and TNs showing no signs of = sunsetting as a resource, it is time to address the issues of routing, management and administration of TNs in an IP envir= onment."

 

The = subject at the end of the sentence is ironically juxtaposed to the prequali= fying assumptive phrases at the beginning of the sentence.

 

That= is, if the PSTN is already "well on its way to transitioning to an all IP network", then how can it be that now is the "time to addr= ess the issues of routing, management and administration of TNs in an IP en= vironment?"

 

It c= an be argued that the proof that those issues have already been addressed a= dequately is the very the fact that the PSTN is already "well on its way to transitioning to an all IP network&quo= t;.

 

I wo= uld strike the sentence as being unnecessary to the MODERN problem statemen= t.

Tom:  OK

 

Sect= ion 2.1

 

&quo= t;The following actors = are defined in this document:

 

Numbering Authority:  A regulatory body within = a country that manages that country's TNs.  The Numbering Authority de= cides national numbering policy, including what TNs can be allocated, and which are reserved.&quo= t;

 

Coun= tries can and do have more than one numbering authority.  Either chang= e the wording or change the actor name to "National Numbering Authorit= y" and add a subcategory for "Regional or otherwise subtended Numbering Authority (to the National Numbering Authority)".=

 

I wo= uld change "The Nu= mbering Authority decides national numbering policy" to "The Numbering Authority decides numbering policy for the nation, region, or other domain for which it has authority&= quot;.

Tom:  OK

 

&quo= t;There are two types o= f Registries an authoritative Registry and a distributed Registry.

 

An authoritative Registry is a single entity with so= le responsibility      for specific numbering reso= urces.

 

Distributed Registries are multiple Registries respo= nsible for the same numbering resources.  (There's more on distributed= Registries later in this section.)

 

The general term Registry in this document refers to= both kinds of Registries.  When referring to one versus the other thi= s document will use the specific term."<= /o:p>

 

I re= commend breaking out each registry type as it's own actor.

Tom:  OK

 

I al= so am struggling with your use of the term "registry" whereas I t= hink you're referring not so much to registries (i.e., database services) s= o much as database models with respect specifically to non-duplicated versus duplicated data. 

 

The = database models you described can have hybrids.

 

One = hybrid could be multiple independent distributed (in the sense that they ar= e non-collocated and/or in different administrative domains) databases who = collectively represent an authoritative (i.e., non-duplicative) set of assignment data.  An example of this m= odel would be the set of .com top-level domain name databases.

 

Anot= her hybrid could contain top level (e.g., Numbering Plan Area) assignments = maintained in a single national-level non-duplicative authoritative databas= e and subtending assignments maintained in distributed (non-duplicative or duplicative) databases managed by regio= nal numbering authorities.

 

&quo= t;User:  An indivi= dual reachable through a communications service; usually a customer of a co= mmunication service provider who uses TNs to reach and identify services.  Sophisticated users may also act as their own= CSPs."

 

The = "User" actor definition is ambiguous.

 

To r= educe ambiguity consider striking the phrase, "...who uses TNs to reach and identify servic= es" from the first sentence of the definition (assuming the phrase refers to the CSP and not the User)= .  The phrase is uncessary and does not add clarity.

Tom:  OK

 

I re= commend striking the 2nd sentence, "Sophisticated users may also act as their own CSPs."  Doing so would not presumably preclude a sophisticated user from being a CSP, but it appears to be a sta= tement of policy or capability and isn't clear in either case.

Tom:  This is a statement of role, not policy.  <= /font>

 

&quo= t;Government Entity:&nb= sp; An entity that, due to legal powers deriving from national policy, has = privileged access to information about number administration under certain conditions.

 

Note that a given entity may act in one or more of t= he roles above. An entity acting as a CSP, Service Enabler, or User can als= o be said to have a relationship to the Registry of either an assignee or delegate:"=

 

The = "entity" stuff is confusing.

Tom:  I=  agree, the term entity should be removed in the descriptive text.

 

Are = you indicating that an "entity" is somehow different from an &quo= t;Actor"?  Or, are you saying that an entity is a special kind of= "Actor"?

 

How = about replacing the phrase, "a given entity" with the phrase, &= quot;an actor"?

 

How = about removing the phrase, "An entity acting as" in the 2nd sentence of the 2nd paragrap= h?

 

"Assignee:  An entity that is assigned a T= N by the Registry.  There is always a direct relationship between the = Registry and the assignee.

 

Delegate:  An entity that is delegated a TN fro= m an assignee or another delegate.  Delegates may use a TN for a commu= nications service or delegate it in turn."

 

I di= dn't understand the need for the qualification, "There is always a direct relationship betwee= n the Registry and the assignee" in the definition of the Assignee actor.

 

I wo= uld avoid the use of the term, "entity", and replace the entire= Assignee actor definition with the following:

 

&quo= t;Assignee:  An ac= tor that is assigned a TN by the Registry."

 

Simi= larly, I would replace the word "entity" with "actor" i= n the definition for Delegate.

 

The = second sentence in the definition of the Delegate is confusing and ambiguou= s.

 

The = phrase "Delegates = may use a TN for a communications service" is= written such that it could imply that a TN could be used as a form of communications service although clearly this wasn't the = intent.  And the end of the sentence referring to additional delegatio= n is too open-ended and should not be combined with the first part of the s= entence.

 

I re= commend breaking the sentence into 2 parts.

 

Firs= t change the phrase, "Delegates may use a TN for a communications service" to be a sentence reading, "Delegates may associate a TN with a communications service."

 

Seco= nd change the phrase, "D= elegates may delegate one or more of their TN assignment(s)to one or more further d= ownstream subdelegates who may also delegate their assignment(s).  The= re can be up to 1024 levels of sub-delegation.&quo= t;  (Just kidding about the 1024 levels, but you get the idea.)

Tom:  The second sentence= s in the definitions are to further explain the difference between the two = definitions.  I<= span style=3D"color: rgb(255, 0, 0); ">'ll clarify<= /span> the text.  

 

Sect= ion 2.2

 

&quo= t;Administrative Data:&= nbsp; assignment data related to the TN and the relevant actors; it include= s TN status, contact data for the assignee or delegate, etc. and typically does not require real-time performance."

 

What= is meant by "TN s= tatus"?

Tom: assigned, unassigned, etc.  I'll add= a parenthetical definition. 

 

If t= he definition of "= TN status" is clear, unambiguous, and short, = use that instead.  If it is not, delete it from the definition of "Ad= ministrative Data".

 

&quo= t;Service Data:  d= ata necessary to enable service for the TN; it includes addressing data, fe= ature capabilities, etc. and typically does require real-time performance."

 

If e= xamples or the definition of "feature capabilities" is clear, u= nambiguous, and short, use that instead.  If it is not, delete it from the definition of "Service Data".

Tom:  I'll change it to "features&qu= ot;

 

Dele= te "etc.".

 

Defi= ne what is meant by "" in the context of i= t being a requirement.  i.e., what part of the problem statement indicates a need for real-time, or non-real-time performance?

 

If w= e look at existing numbering and registration systems (in North America) as= an example, what about their real-time, near-real-time, or non-real-time p= erformance is a problem to be solved?

 

&quo= t;Public:  data th= at anyone can access, for example a list of which numbering resources are a= vailable for acquisition from the Registry."<= o:p>

 

Defi= ne "numbering reso= urces".

Tom:  Will add a parenthetical definition= .

 

Defi= ne "available".

 

&quo= t;Semi-restricted: = ; data that a somewhat broad subset of actors can access, for example CSPs = may be able to access other CSP's service data.&qu= ot;

 

Dele= te the words "some= what broad".

Tom:  OK

 

Dele= te the example.  Defining policy should be outside the scope of the pr= oblem statement should it not?

 

&quo= t;Restricted:  dat= a that is only available to a small subset of actors, for example a Governm= ent Entity may be able access contact information for a User."

 

Dele= te the example.

Tom:  I believe the examples are hel= pful and not confusing.

 

As y= ou acknowledge there are really only two categories; unrestricted and restr= icted.  Degree of restriction is a matter of policy.=

 

2.3 = Data Management Architectures

 

&quo= t;Beyond traditional ce= ntralized Registries, this framework also supports environments where the s= ame data is being managed by multiple entities, and stored in many locations."

 

I wo= uld delete this paragraph for being inappropriate to a problem statement.&n= bsp; Save it for the solution to the problem(s).

Tom:  This is covered in the use cases an= d defining it here is helpful to the flow of the document. 

 

&quo= t;Data store:  a s= ervice that stores and enables access to administrative and/or service data= .  Typically Registries and CSPs would manage data stores."

 

I wo= uld delete the last sentence, "Typically Registries and CSPs would manage data stores.= "

Tom:  OK

 

&quo= t;Reference Address:&nb= sp; a URL that dereferences to the location of the data store."

 

This= is an artifact of a presupposed solution to a problem and does not belong = in a problem statement.  I would delete this and save it for a solutio= n statement.

Tom:  A reference address is a well under= stood method to access a data store.  This is one of multiple sol= utions described in the use cases.  

 

&quo= t;Distributed Registrie= s:  refers to multiple Registries managing the same numbering resource= .  Actors could interact with one or multiple Registries.  The Registries would update each other when change occurs.  The chall= enge is to ensure there are no clashes, e.g., two Registries assigning the = same TN to two different actors."<= /span>

 

Defi= ne "numbering reso= urce".

 

I wo= uld delete, "The R= egistries would update each other when change occurs.  The challenge i= s to ensure there are no clashes, e.g., two Registries assigning the same TN to two different actors.&qu= ot;

 

Thes= e statements presuppose a solution architecture and make assumptions about = the type of TN being assigned.  These statements do not belong in a pr= oblem statement.  They should be saved for a solution statement.

Tom:  These are described in the use case= s and I believe it is helpful to define it here.  

 


 --_000_D2C53F0833A98tommcgarryneustarbiz_-- From nobody Sat Jan 30 08:58:37 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 ABFBF1B3C4E for ; Sat, 30 Jan 2016 08:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVpzgdNZE_IA for ; Sat, 30 Jan 2016 08:58:30 -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 EEC7C1B3C4B for ; Sat, 30 Jan 2016 08:58:29 -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 u0UGsATQ010002 for ; Sat, 30 Jan 2016 11:58:25 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 20rtcf0dwc-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 30 Jan 2016 11:58:24 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.23]) with mapi id 14.03.0279.002; Sat, 30 Jan 2016 11:58:24 -0500 From: "McGarry, Tom" To: Modern List Thread-Topic: Response to Section 3-8 Coments Thread-Index: AQHRW39tK+DXOuA3K0eNi2Jm3Ttppw== Date: Sat, 30 Jan 2016 16:58:23 +0000 Message-ID: In-Reply-To: <691495e5e2834619937f30fcccc78df6@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.168.132.127] Content-Type: multipart/alternative; boundary="_000_D2D24B9733F12tommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-30_09:, , 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-1601300295 Archived-At: Subject: [Modern] Response to Section 3-8 Coments X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 16:58:35 -0000 --_000_D2D24B9733F12tommcgarryneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank for the feedback, Pierce. Comments below. From: , Pierce Gorman > Date: Sunday, January 10, 2016 6:36 PM To: Tom Mcgarry >, = Modern List > Subject: RE: [Modern] Problem statement draft problems 3. Framework "The framework outlined in this document requires three Internet-based mech= anisms for managing and resolving TNs (TNs) in an IP environment. These me= chanisms will likely reuse existing protocols for sharing structured data; = it is unlikely that new protocol development work will be required, though = new information models specific to the data itself will be a major focus of= framework development. Likely candidates for reuse here include work done= in DRINKS and WEIRDS, as well as the TeRQ [12] framework. These protocol mechanisms are scoped in a way that makes them likely to app= ly to a broad range of future policies for number administration. It is no= t the purpose of this framework to dictate number policy, but instead to pr= ovide tools that will work with policies as they evolve going forward. The= se mechanisms therefore do not assume that number administration is central= ized, nor that number "ownership" is restricted to any privileged service p= roviders, though these tools must and will work in environments with those = properties." The first sentence in the first paragraph has parentheses around the acrony= m TN without spelling out the acronym. Either eliminate the parenthetical = TN or spell out Telephone Number. Here I will also mention that Telephone = Number is an ambiguous and increasingly anachronistic term that might be be= tter served being replaced by the term "E.164 number". TOM: OK. I would delete the sentence, "Likely candidates for reuse here include work= done in DRINKS and WEIRDS, as well as the TeRQ [12] framework." It is an= editorial opinion and not necessarily appropriate to a problem statement. TOM: Part of the discussion so far is how we can borrow from many existing= protocol work already done. This is simply emphasizing that. "Acquisition: a protocol mechanism for acquiring TNs, including an enrollm= ent process." Define "enrollment". Does "enrollment" imply or mean "subscription"? TOM: The term is used as it is commonly defined as a verb. "Retrieval: a protocol mechanism for retrieving data about TNs from either= an authority or a CSP." I would delete the end of the definition beginning with the word "from". I= t presupposes a solution architecture and is not appropriate to a problem s= tatement. TOM: OK "The acquisition mechanism will enable actors to acquire TNs for use with a= communications service. The acquisition mechanism will provide a means to= request numbering resources from a service operated by a Registry, CSP or = similar actor. TNs may be requested either on a number-by-number basis, or= as inventory blocks. Any actor who grants numbering resources will retain= metadata about the assignment, including the responsible or individual to = whom numbers have been assigned." Define "numbering resources". Insert the word "parties" between the words "responsible" and "or" in the = last sentence. TOM: OK Should the paragraph describing acquisition mechanism be included as a subp= aragraph under the initial definition of "Acquisition"? TOM: I prefer to define the concepts at a high level, then go through each= on more detail, rather than go through each in detail. "The management mechanism will let actors provision data associated with TN= s at CSPs. For example, if a User has been assigned a TN, they may select = a CSP to provide a particular service associated with the TN, or a CSP may = assign a TN to a User upon service activation. In either case, a mechanism= is needed to provision data associated with the TN at that CSP." To me, the first sentence is ambiguous with respect to where management act= ion is taking place. Are you indicating management of TN and TN-associated= information withing the corporate database of a CSP? Or, are you indicati= ng the ability to manage the TN and TN-associated information within a MODE= RN database hosted by one or more MODERN-enabled registries? The latter of the two possibilities seems less fraught with legal and opera= tional problems. I would have just assumed the latter except for your add= itional remarks about the "retrieval mechanism". More on that below, but = here I'll just state my opinion you should confine your scope to the public= realm (as inferred in the last sentence of the charter) and will direct mo= st of my remarks as though you agreed. Perhaps change the first sentence to read, "The management mechanism will p= ermit actors to provision data associated with TNs within registries." And change the last sentence to be, "In either case, a mechanism is needed = to provision data associated with the TN within registries." TOM: I'd rather be less proscriptive here and leave the detail you're refe= rring to to the use cases. We can make it more general by deleting the tex= t "at CSPs" in the two places it appears. Should the paragraph describing the management mechanism be moved to be a s= ubparagraph under the initial definition of "Management"? "The retrieval mechanism will enable actors to learn information about TNs,= typically by sending a request to a CSP. For some information, an actor m= ay need to send a request to a Registry rather than a CSP. Different parti= es may be authorized to receive different information about TNs." The Charter implies the output of the working group is a a potentially glob= al process and method which user and CSP actors would use to manage TN assi= gnment and the metadata associated with the TN. I'm stunned that you're also recommending that the framework include a requ= irement for user actors to be able to directly manage TN and TN metadata wi= thin a CSP actor's private corporate database. My opinion is you should confine your scope to the public registry realm an= d avoid creating mechanisms and frameworks which force CSPs to expose their= private corporate databases in any particular way. CSPs often (and increasingly so) make user-defined provisioning options ava= ilable as a matter of competitive advantage, but creating an IETF-designed = requirement to do so as part of a TN and TN metadata management framework i= s not advisable. It makes adoption hurdles more difficult and therefore in= creases the chances that MODERN is more narrowly accepted, if at all. If you want your work used, you should aim for the broadest possible adopti= on and requiring user actor access to CSP actor information is probably goi= ng to harm your chances of achieving your goals. I recommend you confine y= our framework and design to publicly-held and managed implementations. Many IETF protocols and mechanisms have been the source of cyberplagues and= MODERN is an obvious target. If you have a specific kind of information t= hat you think would only be available to a CSP actor and that MUST be direc= tly retrievable or changeable by user actor having direct access to a CSP a= ctor's database, then you should state what that information is and why tha= t steers away from a design using an indirect method through a public regis= try. TOM: Actors in the environment need to access data about TNs. This may he= lp them route, may help them manage their networks, it may help them identi= fy other actors. These are true today. All this is saying is that there i= s a need to retrieve this data from those that have it. 4. Use Cases 4.1 Acquisition "There are three actors from which numbers can be acquired: a Registry, a C= SP and a User (presumably one who is delegating to another party). In these= use cases, a User may acquire TNs either from a CSP or a Registry, or from= an intermediate delegate." The use of the term "delegate" is very loose in this document. The definit= ions and use cases seem to imply delgation and subdelegation between user, = CSP, and service enabler actors can cascade factorily. I appreciate that Section 4.1.1 tries to more precisely outline and proscri= be possible or probable assignee and delegation relationships. This is nec= essary. It would be good if you could also describe what are the expected = reasons for having permitted/designed those relationships. TOM: Most of these relationships exist today. Others have been added to c= apture those possibilities. Section 4.1.1 CSP Aquires TN from Registry "The Registry maintains a profile of the CSP and what qualifications they p= ossess for requesting TNs." Please explain (somewhere) what is meant by "a profile of the CSP". TOM: The term is used as commonly defined as a noun. Please outline why it is important for the registry to maintain a profile t= hat contains the CSP "qualifications they possess for requesting TNs". TOM: This is self explanatory to anyone knowledgable about the environment= . Is there also an expectation that a registry should also maintain profiles = of users and the "qualifications they possess for requesting TNs"? TOM: Yes, but not this use case. The suggestion of using the MODERN numbering management process to also per= form key management for another IETF initiative (STIR) is sensible in the c= ontext of advocates of MODERN promoting other favorite sons, but hopefully = won't be a detailed part of the MODERN number management solution. It is f= ine to suggest it as a plausible thing to do, but there isn't anything like= consensus with regard to whether STIR is a good or favored approach for au= thenticating calling identity and should be outside of the scope of MODERN. I'm going to skip over making any further comments on the various MODERN us= e cases. They would have been useful as part of a definition of terms from= which a problem statement was constructed. In the case of this document t= hey are presented as functional parts of a MODERN solution framework, not a= problem statement. 4.2 Management "While some similar use cases may apply to individual Users, it is anticipa= ted that for the most part these lower-level service information changes wo= uld be communicated via existing protocols (like the baseline [2] SIP REGIS= TER method) rather than through any interfaces defined by MODERN." The above paragraph is duplicated in it's entirety across pages 10 and 11. = Delete the duplicate that ends on page 11. TOM: OK 4.2.2. Management of Service Data "Service data is data necessary to enable communications service to the del= egate or User, for example a SIP URI." This is naive. It assumes a simple single SIP URI would be sufficient "to = enable communications service to the delegate or User". TOM: We will replace "necessary" with "required by an originating or inter= mediate CSP". A consequence of private interconnection networks used for exchanging peeri= ng traffic between CSPs (which is the norm) means that a single SIP URI is = almost certainly out of the question. As I tried to explain in on-line dis= cussions about numbers and geography, call routing of services to a TN ofte= n requires knowing where the call is originating (either physically and/or = logically) and then using the terminating address that makes sense in the c= ontext of the originating network. This oversimplified model of how call routing works is a weakness of the MO= DERN TN information management model. CSPs often have multiple (and regional) physical and logical private and pu= blic network boundaries using a mixture of private (e.g., RFC1918) and publ= ic IP (IPv4 or IPv6) addressing. This impacts managing SIP URIs associated= with a TN and what the visibility should be to those URIs and by whom. It= eliminates any practical possibility that a single URI is sufficient. URI information associated with a TN will be different for different interc= onnection relationships which steers toward a distributed database model ma= intained largely by and for CSPs moreso than end-users and governments. (I= think you tacitly acknowledge this in section "4.2.2.1. CSP to other CSPs= ".) 4.2.2.3. User to Registry "As stated already the protocol should enable Users to acquire TNs directly= from a Registry and in essence act as their own CSP." This is just impractical in the case where there are tens or hundreds, or e= ven thousands of millions of users (which is all of the important cases) be= cause the registry cannot possibly vet with any usable reliability the trus= tworthiness of this many actors let alone prosecute them. Ask anyone whose= worked in the US Internal Revenue Service. They can't possibly know if al= l of the "users" are alive, dead, illegal aliens or where they say they are= , or whether they appropriately paid their taxes. Tax fraud is a multi-bil= lion dollar problem. If we overlay that model on management of TNs, you ca= n practically guarantee that STIR will be of no use whatsoever. The reality is users are going to want (and should be permitted) multiple T= Ns, but the management of their access and use has to be delegated to organ= izations who have a vested interest in being able to recover the TNs, make = efficient use of them, and who can prosecute the users if there is a proble= m. That is, the government needs to give inventory to CSPs who then need t= o manage the users' use of it. 4.2.3.1. Changing the CSP for an Existing Communications Service "The User provides their credential to the new CSP and the CSP initiates th= e change in service." No argument with the method, but will mention at least two large regulatory= environments do not embrace it. You should consider how to integrate othe= r methods such as requesting that the old CSP move the TN assignment to the= new CSP. TOM: Yes, we should capture the concept of that method. "The old credential is revoked and a new one is provided." This seems to imply an integrated STIR or STIR-like function which might ma= ke sense but should be outside of the scope of MODERN. TOM: There is no intention to do STIR work here. It simply mentions a pos= sible solution. I recommend deleting all references to credential management that fall outs= ide of section 4.1. use case examples. "[TBD - more on the case where multiple CSPs provide services for a given T= N, and only one service is "ported" to a new CSP?]" This is actually one of the more important use cases in my mind but not as = a part of a problem that MODERN is required to solve. Based on what I've r= ead of problems in the so-called "problem statement" I still don't believe = MODERN is required. Regardless, the use case is valid and important. I have a sincere frustration that my e-mail address is broken if I move my = e-mail between e-mail service providers. I would much prefer to have e-mai= l address portability. I could easily have this if my e-mail address were = based on my TN. This is an example of where TNs are far superior to domain= names. They are not vulnerable to international character set exploits, e= t cetera. So, I am very sympathetic to a broadened use of TNs and associat= ing metadata (such as e-mail URI) to them for the very purpose of enabling = portability between CSPs if nothing else. It's just that MODERN isn't requ= ired in order to achieve this outcome and benefit. 4.2.3.2. Terminating a Service "In an alternative use case, a User who received their own TN assignment di= rectly from the Registry terminates their service with a CSP. At this time= , the User might terminate their assignment from the Registry, and return t= he TN to the Registry for re-assignment. Alternatively, they could retain t= he TN and elect to assign it to some other service at a later time." I'll encourage others who know more about TN inventory management, but on t= he surface this and delegation look promising for providing an environment = ripe for problems with fraud, abuse, and number exhaust. 4.3.1. Retrieval of Public Data "Under most circumstances, a CSP wants its communications service tobe publ= icly reachable through TNs, so the retrieval interface supports public inte= rfaces that permit clients to query for service data about a TN. Some serv= ice data may however require that the client by authorized to receive it, p= er the use case in Section 4.3.3 below. Public data can simply be posted on websites or made available through a pu= blicly available API. Public data hosted by a CSP may have a reference add= ress at the Registry." One of the robocalling problems plaguing the industry are calls that are ap= parently sequencing through number blocks in an apparent attempt to identif= y which numbers are assigned and which are not. The intentions of the robo= callers wanting this information are suspect and assumed to be bad. Making= the information publicly available on the Internet may actually put the pu= blic at risk of material harm. Ask any mobile user if they would prefer th= at their TN and CSP information be available on a public database and see w= hat they say. Most of this paragraph is of a policy nature and does not belong in a probl= em statement or an RFC. Section 4.2.3.2 has similar weaknesses. i recomme= nd removing any references to policy. TOM: Agree that this is important to get right. Regulators with the indus= try will determine what data fits into which category. This is merely givi= ng examples. 4.3.2. Retrieval of Semi-restricted Administrative Data "A CSP is having service problems completing calls to a specific TN, so it = wants to contact the CSP serving that TN." This is not representative of how trouble management is handled in the US. = Trouble management is between carriers with Inter-Connection Agreements, n= ot between originating and terminating carriers. I believe the sentence and example does not contribute usefully to the sect= ion. I recommend deleting it. TOM: This does not suggest that the service providers do or do not have an= agreement. 4.3.3. Retrieval of Semi-restricted Service Data "There are multiple scenarios to for the query and response." Delete either the word "to", or the word "for" from the sentence. I recomm= end deleting "to". TOM: OK 5. Distributed Registries and Data Stores "For example, when a CSP enables service for a User they can initiative an = update of the service address to multiple other data stores managed by othe= r service providers." The word "initiative" should be changed to "initiate". TOM: OK The phrase "[More TBD]" should be removed or more should be added. TOM: OK 8. Security Considerations "TBD." This is a bigger handwave then the usual caveat that security is important = and be careful because the authors didn't know what else useful to write. I recommend adding the usual useless boiler-plate, or actually try to intro= duce discussion and description about potential fraud and abuse issues from= malintentioned User actors being able to directly request and manage the m= etadata associated with their own TN number assignments or the unrestricted= public data of other TN and associated CSP assignments. ________________________________ Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or= T-Mobile rates. See sprint.com/50off f= or details. ________________________________ 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_D2D24B9733F12tommcgarryneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Thank for the feedback, Pierce.  Comments below.  

From: <Gorman>, Pierce Gorman= <Pierce.Gorman@sprint.com>
Date: Sunday, January 10, 2016 6:36= PM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>, Modern List &l= t;modern@ietf.org>
Subject: RE: [Modern] Problem state= ment draft problems


3. F= ramework

 

&quo= t;The framework outline= d in this document requires three Internet-based mechanisms for managing an= d resolving TNs (TNs) in an IP environment.  These mechanisms will likely reuse existing protocols for sharing structur= ed data; it is unlikely that new protocol development work will be required= , though new information models specific to the data itself will be a major= focus of framework development.  Likely candidates for reuse here include work done in DRINKS and WEIRDS, a= s well as the TeRQ [12] framework.

 

These protocol mechanisms are scoped in a way that m= akes them likely to apply to a broad range of future policies for number ad= ministration.  It is not the purpose of this framework to dictate number policy, but instead to provide tools that= will work with policies as they evolve going forward.  These mechanis= ms therefore do not assume that number administration is centralized, nor t= hat number "ownership" is restricted to any privileged service providers, though these tools must and will work= in environments with those properties."=

 

The = first sentence in the first paragraph has parentheses around the acronym TN= without spelling out the acronym.  Either eliminate the parenthetical= TN or spell out Telephone Number.  Here I will also mention that Telephone Number is an ambiguous and increasingly a= nachronistic term that might be better served being replaced by the term &q= uot;E.164 number".

TOM:  OK.

 

I wo= uld delete the sentence, "Likely candidates for reuse here include work done in DRINKS and WE= IRDS, as well as the TeRQ [12] framework."&nb= sp;  It is an editorial opinion and not necessarily appropriate to a problem st= atement.

TOM:  Part o= f the discussion so far is how we can borrow from many existing protoc= ol work already done.  This is simply emphasizing that.  <= /font>

 

&quo= t;Acquisition:  a = protocol mechanism for acquiring TNs, including an enrollment process."

 

Defi= ne "enrollment".  Does "enrollment" imply or mea= n "subscription"?

TOM:  The term is used as it is comm= only defined as a verb.  

 

&quo= t;Retrieval:  a pr= otocol mechanism for retrieving data about TNs from either an authority or = a CSP."

 

I wo= uld delete the end of the definition beginning with the word "<= span style=3D"font-family: 'Courier New'; ">from&q= uot;.  It presupposes a solution architecture and is not appropriate to a problem statement.

TOM:  OK

 

&quo= t;The acquisition mecha= nism will enable actors to acquire TNs for use with a communications servic= e.  The acquisition mechanism will provide a means to request numbering resources from a service operated by a Registry= , CSP or similar actor.  TNs may be requested either on a number-by-nu= mber basis, or as inventory blocks.  Any actor who grants numbering re= sources will retain metadata about the assignment, including the responsible or individual to whom numbers have been assigned= ."

 

Defi= ne "numbering reso= urces".

 

Inse= rt  the word "parties" between the words "responsible" and "or" in the last sentence.

TOM:  OK

 

Shou= ld the paragraph describing acquisition mechanism be included as a subparag= raph under the initial definition of "Acquisition"?

TOM:  I prefer to define the concepts at = a high level, then go through each on more detail, rather than go through e= ach in detail.  

 

"The management mechanism will let actors provi= sion data associated with TNs at CSPs.  For example, if a User has bee= n assigned a TN, they may select a CSP to provide a particular service associated with the TN, or a CSP may assign a TN to a= User upon service activation.  In either case, a mechanism is needed = to provision data associated with the TN at that CSP."

 

To m= e, the first sentence is ambiguous with respect to where management action = is taking place.  Are you indicating management of TN and TN-associate= d information withing the corporate database of a CSP?  Or, are you indicating the ability to manage the TN and TN= -associated information within a MODERN database hosted by one or more MODE= RN-enabled registries?

 

The = latter of the two possibilities seems less fraught with legal and operation= al problems.   I would have just assumed the latter except for yo= ur additional remarks about the "retrieval mechanism".  = ; More on that below, but here I'll just state my opinion you should confine= your scope to the public realm (as inferred in the last sentence of the ch= arter) and will direct most of my remarks as though you agreed. 

 

Perh= aps change the first sentence to read, "The management mechanism will permit actors to provis= ion data associated with TNs within registries.&qu= ot;

 

And = change the last sentence to be, "In either case, a mechanism is needed to provision data asso= ciated with the TN within registries."=


TOM:  I'd&nb= sp;rather be less proscriptive here and leave the detail you're referring t= o to the use cases.  We can make it more general by deleting the = text "at CSPs" in the two places it appears.  =

 

Shou= ld the paragraph describing the management mechanism be moved to be a subpa= ragraph under the initial definition of "Management"?

 

&quo= t;The retrieval mechani= sm will enable actors to learn information about TNs, typically by sending = a request to a CSP.  For some information, an actor may need to send a request to a Registry rather than a CSP.  Di= fferent parties may be authorized to receive different information about TN= s."

 

The = Charter implies the output of the working group is a a potentially global p= rocess and method which user and CSP actors would use to manage TN assignme= nt and the metadata associated with the TN.

 

I'm = stunned that you're also recommending that the framework include a requirem= ent for user actors to be able to directly manage TN and TN metadata within= a CSP actor's private corporate database.

 

My o= pinion is you should confine your scope to the public registry realm and av= oid creating mechanisms and frameworks which force CSPs to expose their pri= vate corporate databases in any particular way.

 

CSPs= often (and increasingly so) make user-defined provisioning options availab= le as a matter of competitive advantage, but creating an IETF-designed requ= irement to do so as part of a TN and TN metadata management framework is not advisable.  It makes adoption hu= rdles more difficult and therefore increases the chances that MODERN is mor= e narrowly accepted, if at all.

 

If y= ou want your work used, you should aim for the broadest possible adoption a= nd requiring user actor access to CSP actor information is probably going t= o harm your chances of achieving your goals.  I recommend you confine your framework and design to publicly= -held and managed implementations.

 

Many= IETF protocols and mechanisms have been the source of cyberplagues and MOD= ERN is an obvious target.  If you have a specific kind of information = that you think would only be available to a CSP actor and that MUST be directly retrievable or changeable by user acto= r having direct access to a CSP actor's database, then you should state wha= t that information is and why that steers away from a design using an indir= ect method through a public registry.

TOM:  A= ctors in the environment need to access data about TNs. &nbs= p;This may help them route, may help them manage their networks, it may hel= p them identify other actors.  These are true today.  All this is saying is that there is a need to retrieve this data from those that ha= ve it.  

 

 

4. U= se Cases

 

4.1 = Acquisition

 

&quo= t;There are three actor= s from which numbers can be acquired: a Registry, a CSP and a User (presuma= bly one who is delegating to another party). In these use cases, a User may acquire TNs either from a CSP or a Registry= , or from an intermediate delegate."

 

The = use of the term "d= elegate" is very loose in this document. = ; The definitions and use cases seem to imply delgation and subdelegation between user, CSP, and service enabler actors can cascade fa= ctorily.

 

I ap= preciate that Section 4.1.1 tries to more precisely outline and proscribe p= ossible or probable assignee and delegation relationships.  This is ne= cessary.  It would be good if you could also describe what are the expected reasons for having permitted/designed those= relationships.

TOM:  Most of these relationships exist t= oday.  Others have been added to capture those possibilities.  

 

Sect= ion 4.1.1 CSP Aquires TN from Registry

 

&quo= t;The Registry maintain= s a profile of the CSP and what qualifications they possess for requesting = TNs."

 

Plea= se explain (somewhere) what is meant by "a profile of the CSP".

TOM:  The term is used as commonly define= d as a noun.  

 

Plea= se outline why it is important for the registry to maintain a profile that = contains the CSP "= qualifications they possess for requesting TNs&quo= t;.

TOM:  This is self explanatory to anyone = knowledgable about the environment.  

 

Is t= here also an expectation that a registry should also maintain profiles of u= sers and the "qual= ifications they possess for requesting TNs"?<= /span>

TOM:  Yes, but not this use case.  <= /font>

 

The = suggestion of using the MODERN numbering management process to also perform= key management for another IETF initiative (STIR) is sensible in the conte= xt of advocates of MODERN promoting other favorite sons, but hopefully won't be a detailed part of the MODERN number= management solution.  It is fine to suggest it as a plausible thing t= o do, but there isn't anything like consensus with regard to whether STIR i= s a good or favored approach for authenticating calling identity and should be outside of the scope of MODERN.<= /span>

 

I'm = going to skip over making any further comments on the various MODERN use ca= ses.  They would have been useful as part of a definition of terms fro= m which a problem statement was constructed.  In the case of this document they are presented as functional parts of a M= ODERN solution framework, not a problem statement.

 

4.2 = Management

 

&quo= t;While some similar us= e cases may apply to individual Users, it is anticipated that for the most = part these lower-level service information changes would be communicated via existing protocols (like the baseline [2] SIP RE= GISTER method) rather than through any interfaces defined by MODERN.= "

 

The = above paragraph is duplicated in it's entirety across pages 10 and 11. = ; Delete the duplicate that ends on page 11.

TOM:  OK

 

4.2.= 2.  Management of Service Data

 

&quo= t;Service data is data = necessary to enable communications service to the delegate or User, for exa= mple a SIP URI."

 

This= is naive.  It assumes a simple single SIP URI would be sufficient &qu= ot;to enable communicat= ions service to the delegate or User".=


TOM:  We will replace "necessar= y" with "required by an originating or intermediate CSP". &n= bsp;

 

A co= nsequence of private interconnection networks used for exchanging peering t= raffic between CSPs (which is the norm) means that a single SIP URI is almo= st certainly out of the question.  As I tried to explain in on-line discussions about numbers and geography, cal= l routing of services to a TN often requires knowing where the call is orig= inating (either physically and/or logically) and then using the terminating= address that makes sense in the context of the originating network.

 

This= oversimplified model of how call routing works is a weakness of the MODERN= TN information management model.

 

CSPs= often have multiple (and regional) physical and logical private and public= network boundaries using a mixture of private (e.g., RFC1918) and public I= P (IPv4 or IPv6) addressing.  This impacts managing SIP URIs associated with a TN and what the visibility should be t= o those URIs and by whom.  It eliminates any practical possibility tha= t a single URI is sufficient.

 

URI = information associated with a TN will be different for different interconne= ction relationships which steers toward a distributed database model mainta= ined largely by and for CSPs moreso than end-users and governments.  (I think you tacitly acknowledge this in = section "4.2.2.1.&= nbsp; CSP to other CSPs".)<= /p>

 

4.2.= 2.3.  User to Registry

 

&quo= t;As stated already the= protocol should enable Users to acquire TNs directly from a Registry and i= n essence act as their own CSP."

 

This= is just impractical in the case where there are tens or hundreds, or even = thousands of millions of users (which is all of the important cases) becaus= e the registry cannot possibly vet with any usable reliability the trustworthiness of this many actors let alone p= rosecute them.  Ask anyone whose worked in the US Internal Revenue Ser= vice.  They can't possibly know if all of the "users" are al= ive, dead, illegal aliens or where they say they are, or whether they appropriately paid their taxes.  Tax fraud is a multi= -billion dollar problem.  If we overlay that model on management of TN= s, you can practically guarantee that STIR will be of no use whatsoever.

 

The = reality is users are going to want (and should be permitted) multiple TNs, = but the management of their access and use has to be delegated to organizat= ions who have a vested interest in being able to recover the TNs, make efficient use of them, and who can prosecute= the users if there is a problem.  That is, the government needs to gi= ve inventory to CSPs who then need to manage the users' use of it.

 

4.2.= 3.1.  Changing the CSP for an Existing Communications Service

 

&quo= t;The User provides the= ir credential to the new CSP and the CSP initiates the change in service."

 

No a= rgument with the method, but will mention at least two large regulatory env= ironments do not embrace it.  You should consider how to integrate oth= er methods such as requesting that the old CSP move the TN assignment to the new CSP.

TOM:  Yes, we should capture the concept = of that method.  

 

&quo= t;The old credential is= revoked and a new one is provided."

 

This= seems to imply an integrated STIR or STIR-like function which might make s= ense but should be outside of the scope of MODERN.

TOM:  There is no intention to do STIR wo= rk here.  It simply mentions a possible solution.  

 

I re= commend deleting all references to credential management that fall outside = of section 4.1. use case examples.

 

&quo= t;[TBD - more on the ca= se where multiple CSPs provide services for a given TN, and only one servic= e is "ported" to a new CSP?]"<= /o:p>

 

This= is actually one of the more important use cases in my mind but not as a pa= rt of a problem that MODERN is required to solve.  Based on what I've = read of problems in the so-called "problem statement" I still don't believe MODERN is required.  Regardless= , the use case is valid and important.

 

I ha= ve a sincere frustration that my e-mail address is broken if I move my e-ma= il between e-mail service providers.  I would much prefer to have e-ma= il address portability.  I could easily have this if my e-mail address were based on my TN.  This is an example of= where TNs are far superior to domain names.  They are not vulnerable = to international character set exploits, et cetera.  So, I am very sym= pathetic to a broadened use of TNs and associating metadata (such as e-mail URI) to them for the very purpose of enabling por= tability between CSPs if nothing else.  It's just that MODERN isn't re= quired in order to achieve this outcome and benefit.

 

4.2.= 3.2.  Terminating a Service

 

&quo= t;In an alternative use= case, a User who received their own TN assignment directly from the Regist= ry terminates their service with a CSP.  At this time, the User might terminate their assignment from the Registry, and ret= urn the TN to the Registry for re-assignment. Alternatively, they could ret= ain the TN and elect to assign it to some other service at a later time."

 

I'll= encourage others who know more about TN inventory management, but on the s= urface this and delegation look promising for providing an environment ripe= for problems with fraud, abuse, and number exhaust.

 

4.3.= 1.  Retrieval of Public Data

 

&quo= t;Under most circumstan= ces, a CSP wants its communications service tobe publicly reachable through= TNs, so the retrieval interface supports public interfaces that permit clients to query for service data about a TN. = Some service data may however require that the client by authorized to rec= eive it, per the use case in Section 4.3.3 below.

 

Public data can simply be posted on websites or made= available through a publicly available API.  Public data hosted by a = CSP may have a reference address at the Registry.&= quot;

 

One = of the robocalling problems plaguing the industry are calls that are appare= ntly sequencing through number blocks in an apparent attempt to identify wh= ich numbers are assigned and which are not.  The intentions of the robocallers wanting this information are = suspect and assumed to be bad.  Making the information publicly availa= ble on the Internet may actually put the public at risk of material harm.&n= bsp; Ask any mobile user if they would prefer that their TN and CSP information be available on a public database and see wha= t they say.

 

Most= of this paragraph is of a policy nature and does not belong in a problem s= tatement or an RFC.  Section 4.2.3.2 has similar weaknesses.  i r= ecommend removing any references to policy.

TOM:  Agree that this is important to get= right.  Regulators with the industry will determine what da= ta fits into which category.  This is merely giving examples. &nb= sp;

 

4.3.= 2.  Retrieval of Semi-restricted Administrative Data=

 

&quo= t;A CSP is having servi= ce problems completing calls to a specific TN, so it wants to contact the C= SP serving that TN."

 

This= is not representative of how trouble management is handled in the US. = ; Trouble management is between carriers with Inter-Connection Agreements, = not between originating and terminating carriers.

 

I be= lieve the sentence and example does not contribute usefully to the section.=   I recommend deleting it.

TOM:  This does not suggest that the serv= ice providers do or do not have an agreement.  

 

4.3.= 3.  Retrieval of Semi-restricted Service Data

 

&quo= t;There are multiple sc= enarios to for the query and response."<= /o:p>

 

Dele= te either the word "to", or the word "for" from the sen= tence.  I recommend deleting "to".

TOM:  OK

 

5.&n= bsp; Distributed Registries and Data Stores

 

&quo= t;For example, when a C= SP enables service for a User they can initiative an update of the service = address to multiple other data stores managed by other service providers."

 

The = word "initiative" should be changed to "initiate".

TOM:  OK

 

The = phrase "[More TBD]" should be removed or more should be added.

TOM:  OK

 

8.&n= bsp; Security Considerations

 

&quo= t;TBD."

 

This= is a bigger handwave then the usual caveat that security is important and = be careful because the authors didn't know what else useful to write.<= /o:p>

 

I re= commend adding the usual useless boiler-plate, or actually try to introduce= discussion and description about potential fraud and abuse issues from mal= intentioned User actors being able to directly request and manage the metadata associated with their own TN numb= er assignments or the unrestricted public data of other TN  and associ= ated CSP assignments.

 

 


Learn more on how to swi= tch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details.


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_D2D24B9733F12tommcgarryneustarbiz_--