From nobody Wed Jul 1 02:13:40 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7D11A8972 for ; Wed, 1 Jul 2015 02:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiBMV8SUO1Uk for ; Wed, 1 Jul 2015 02:13:36 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E83A1A86F1 for ; Wed, 1 Jul 2015 02:13:35 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t619DT9x019124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 1 Jul 2015 11:13:29 +0200 Received: from RHillNew (adsl-178-39-180-181.adslplus.ch [178.39.180.181]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t619DRGf024531; Wed, 1 Jul 2015 11:13:28 +0200 From: "Richard Hill" To: "'Gorman, Pierce A [CTO]'" , "'Adam Roach'" , "'DOLLY, MARTIN C'" References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <871bd27710eb49b495aa1971e67b44ac@PLSWE13M08.ad.sprint.com> In-Reply-To: <871bd27710eb49b495aa1971e67b44ac@PLSWE13M08.ad.sprint.com> Date: Wed, 1 Jul 2015 11:13:31 +0200 Message-ID: <009a01d0b3de$3412e6f0$9c38b4d0$@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: AQHQstLMEwQ50yu6z0i1W6uAK8HRwp3EngsAgAABPICAAARggIAAAjqAgAARrACAAL3x4IAA384w Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:13:39 -0000 Please see embedded comments below. Thanks and best, Richard > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, > Pierce A [CTO] > Sent: Tuesday, June 30, 2015 22:08 > To: Adam Roach; DOLLY, MARTIN C > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > Adam, > > The IP PBX use case that Cullen Jennings documented is sensible, but > also small scale, and if that was all the MODERN charter proposed to > do, then there would probably be no lack of consensus (as compared to > where we are in reality). > > The reality is if that was all MODERN would attempt, then its leading > proponents would be very dissatisfied. Is this the case? > > Some are frustrated with the existing multi-database and multi- > regulatory organizational structure of number and routing information > management in carrier-based telecommunications and believe they see a > possibility to bypass this situation through a protocol and data model > (of a super-database?) work effort in the IETF. Apparently this is a > political and commerical matter with the emphasis on the former. Indeed, and I think that we all agree that the regulatory and economic aspects of telephone number management are not in the scope of the IETF. SNIP > > So, while the work of MODERN is aimed to solve certain [relatively > minor?] specific allocation implementation issues: > 1. This may not represent the overwhelming interests of current > or future operators; & > 2. Specifically MODERN must consider application to the current > architectures used for allocation, management, & use of E.164 resource, > including LERG, NPAC, Point Code Data, and SMS800 in the US. > 3. IETF should formally liaise with those major national & > international bodies that support the allocation, administration & > usage of numbering data bases including ITU, NANC, LNPA WG, INC, and > the FoN; both before the WG is activated, & to help steer its work. Regarding ITU, in my view they only way to get a sensible response from them is to send them a formal liaison statement. When they get it, they may not reply, but then that would mean that they don't have any concerns with what MODERN is doing. If you don't send a formal liaison and rely on ITU's looking at IETF mailing lists, then you probably won't get a reply until the IETF asks for something that impacts the ITU. And then they might be annoyed because they were not formally brought into the loop earlier. That's what happened with ENUM and I don't think that we should risk a repeat of that situation. > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach > Sent: June 29, 2015 10:27 PM > To: DOLLY, MARTIN C > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, > Distributing, Exposing, & Registering telephone Numbers (modern) > > We discussed this exact use case in Dallas. From Jon's presentation: > > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06- > 29%2022.12.37.png?dl=0 > > It's also described in the charter. In fact, it's really the main > thrust of the work: the charter repeatedly talks about acquiring, > managing, and resolving TNs. This is the "acquring" part. > > So now, as I'm reflecting on it, I'm a little confused about what *you* > think MODERN will be doing. Perhaps whatever you're worried about isn't > actually happening. > > /a > > > On 6/29/15 21:24, DOLLY, MARTIN C wrote: > > How is that applicable? Scope question? > > > > Sent from my iPhone > > > >> On Jun 29, 2015, at 10:16 PM, Adam Roach wrote: > >> > >> In this context, there isn't one. > >> > >> MARTINI was predicated on a continuation of having VISPs do > excruciatingly manual things like emailing -- or in some cases faxing - > - spreadsheets to their customers detailing number ranges. I think I > still have the one I got from our VISP back in the Estacado days when I > was running our PBX. I can dig it up and forward it to you if you > really don't know how number assignment works at that level. Basically, > it's a lot of human reading and human typing. If you're lucky, you > don't have to get a fax machine involved, so you can at least copy and > paste. > >> > >> But emailing or faxing spreadsheets around is a brutally primitive > and error-prone way to get this kind of thing done. I'm a little > surprised it took this long for anyone to make a serious run at some > standardized form of automation. > >> > >> /a > >> > >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > >>> Please explain the number assignment process > >>> > >>> Sent from my iPhone > >>> > >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach wrote: > >>>>> > >>>>> On 6/29/15 20:19, Cullen Jennings wrote: > >>>>> I think private network case is already happening. There are more > and more PBX that integrate with cloud providers such as Tropo or > Twillio to get phone numbers using a simple API. > >>>> And, really, ever since we ruled this out of scope for MARTINI, > it's been a pretty big gap in SIP PBX deployments. > >>>> > >>>> /a > >>>> > >>>> _______________________________________________ > >>>> Modern mailing list > >>>> Modern@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/modern > >>> _______________________________________________ > >>> Modern mailing list > >>> Modern@ietf.org > >>> https://www.ietf.org/mailman/listinfo/modern > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > > ________________________________ > > 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 Wed Jul 1 02:28:00 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EF31B2BED for ; Wed, 1 Jul 2015 02:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMfyxrhyuNxL for ; Wed, 1 Jul 2015 02:27:51 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E6E1B2BDC for ; Wed, 1 Jul 2015 02:27:50 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t619RkSm005951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 1 Jul 2015 11:27:46 +0200 Received: from RHillNew (adsl-178-39-180-181.adslplus.ch [178.39.180.181]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t619Rjpu020011; Wed, 1 Jul 2015 11:27:46 +0200 From: "Richard Hill" To: "'Alissa Cooper'" , References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> In-Reply-To: <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> Date: Wed, 1 Jul 2015 11:27:49 +0200 Message-ID: <00c101d0b3e0$3312a310$9937e930$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCzd/UzgZD+fyqAQ0iQplvAjmEPQgAZkWxg Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:27:58 -0000 Thank you for this and please see embedded replies below. Best, Richard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa = Cooper >Sent: Tuesday, June 30, 2015 23:01 >To: modern@ietf.org >Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & >Registering telephone Numbers (modern) SNIP >The conclusion from the BoF in Dallas was that there was rough = consensus in the room in >support of forming the WG but that the charter and problem scope needed refinement (feel free >to review the minutes:=A0http://www.ietf.org/proceedings/92/minutes/minutes-92-modern).= That >process of refinement took place on this list over several months = following the BoF. The >charter was put out for review on June 12 I presume that the point of that is precisely to solicit comments from people who were not at the BoF and were not involved up to then. > with comments requested to be sent to the IESG by June 22.=20 I apologize for not having responded sooner. >The IESG considered the two ITU-T related comments received (both after = the deadline) I presume that you consider my comment to be "ITU-T related", but = actually it covered broader issues, such as whether the IETF should get into = process reengineering. > and issued no blocking comments on the charter Actually in my message to the IESG I formally objected to the creation = of this group, and gave the reasons for my objection. I fully understand that one objection, or even more than one objection, = is not necessarily sufficient to prevent approval of the creation of the = group. However, I think that it would have been appropriate to explain why the = IESG did not consider my reasons to be sufficient to block approval. >but asked that edits be considered on the basis of comments received. = There were no other >comments received or indications provided to the IESG = about the readiness of this work for >chartering.=20 See above. >I=92m still working on edits (Richard Hill pointed out that I missed = his suggestions) Indeed, I didn't see any objections to my first set of edits, so I'm = looking forward to seeing them incorporated. More importantly, it has now become clear that it is not clear (pun intended) whether the group's charter is intended to be limited to "management of how to get telephone numbers" or whether it might be intended to include the much wider "management of telephone numbers". >From my point of view, the latter is out of the scope of the IETF, so = the charter should be clarified so that it refers only to the former. I made a proposal for that, but there was one objection. After some other E-Mail exchanges, I made a second proposal. I haven't = yet seen any objections to that second proposal. So I'm looking forward to a revised charter than makes it clear that the scope of this group's work is "how to get numbers within the existing regulatory frameworks". > and milestones are in the works as well. Thus this WG is being formed according to the > usual process. As several people have pointed out, issues relating to telephone numbers include regulatory and economic issues that can be very tricky and politically sensitive. So maybe a bit more caution needs to be = exercised here than "the usual process". In particular, I still think that the charter should be sent to ITU-T = Study Group 2 as a formal liaison statement, asking for their comments. [NOTE: = I don't participate in ITU-T Study Group 2] >Alissa From nobody Wed Jul 1 05:45:32 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD281A6FF2 for ; Wed, 1 Jul 2015 05:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VLZIgZe9inB for ; Wed, 1 Jul 2015 05:45:28 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BB71A7003 for ; Wed, 1 Jul 2015 05:45:28 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 0DFEA14DA8E06; Wed, 1 Jul 2015 12:45:24 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t61CjMjd008125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 14:45:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 14:45:13 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , "DOLLY, MARTIN C" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEyfpGjnKN5EOWAsicctSAOp3EKLIAgAABPICAAARggIAA8GIw///+ioCAAWVaEA== Date: Wed, 1 Jul 2015 12:45:12 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69737D0F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737150@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5592C45B.9030105@nostrum.com> In-Reply-To: <5592C45B.9030105@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:45:30 -0000 My remembrance is somewhat different. 3GPP had a solution, based on existing mechanisms, and already enshrined in= their procedures for similar capabilities not based on MARTINI, using reg = event which you claimed was broken.=20 Rather than prolong the argument, the discussion was left out. 3GPP still specifies the reg event mechanism for this functionality, so as = far as 3GPP is concerned, there is no hole in the story. Regards Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 30 June 2015 17:31 > To: DRAGE, Keith (Keith); DOLLY, MARTIN C > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing,=20 > Ordering, Distributing, Exposing, & Registering telephone=20 > Numbers (modern) >=20 > On 6/30/15 09:39, DRAGE, Keith (Keith) wrote: > > You make this sound like MARTINI was originally meant to=20 > solve world hunger, and somehow got scoped down, which is untrue. >=20 > The MARTINI charter was silent on the issue of whether the=20 > AORs being registered were explicit or implicit. Making them=20 > implicit was a simplification, but not a necessary one. We=20 > could have been explicit about the AORs being registered and=20 > still been well within the charter. >=20 > My point is that this simplification left a hole in the=20 > story, and that MODERN's work is well positioned to fill that hole. >=20 > /a > = From nobody Wed Jul 1 05:45:41 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEF01A702E for ; Wed, 1 Jul 2015 05:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owkPSOvb2fEm for ; Wed, 1 Jul 2015 05:45:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117121A6FF2 for ; Wed, 1 Jul 2015 05:45:31 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 663465E2B3D16; Wed, 1 Jul 2015 12:45:27 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t61CjQTT008674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 14:45:29 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 14:45:16 +0200 From: "DRAGE, Keith (Keith)" To: Henning Schulzrinne Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEyfpGjnKN5EOWAsicctSAOp3EKLIAgAABPICAAARggIAAAjqAgAARrACAAMvOcIAANc8AgAFINYA= Date: Wed, 1 Jul 2015 12:45:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com>, <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:45:33 -0000 So my question still remains, given that this is significant data associate= d with the number, rather than just the number itself. How do we distinguish this problem from either device configuration, or net= work management, for which a number of solutions still exist? If the problem is not distinguished, then why are the existing device confi= guration and network management solutions not appropriate? Regards Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Henning Schulzrinne > Sent: 30 June 2015 19:50 > To: DRAGE, Keith (Keith) > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing,=20 > Ordering, Distributing, Exposing, & Registering telephone=20 > Numbers (modern) >=20 > I think of the phone number as a key into a logical (not=20 > necessarily physical) database with a variety of fields (and=20 > a change log), some that are near-universal and others that=20 > are highly-specific to countries, use cases or even=20 > companies. We do the same for domain names, e.g., technical=20 > and administrative contacts or for DHCP, where an IP address=20 > is associated with a set of service records (e.g., for a SIP=20 > proxy, LIS or LoST server in our technical neighborhood). >=20 > Much of that information exists already and is in the AT&T=20 > and Tropos APIs, the LNPA or LERG. Examples include: >=20 > * OCN/carrier code (some kind of assignment identifier is=20 > probably unavoidable) > * number state (available, locked, etc.) > * reachability (URLs) > * cryptographic keying materials >=20 > All but the first and maybe second are likely to be optional.=20 > As usual, there would be suitable extension points, e.g., to=20 > accommodate storing 911 address information that only makes=20 > sense in certain relationships (not for the LNPA, but for a=20 > carrier-customer relationship). All the usual stuff applies=20 > that the veterans in this group do by rote: IANA=20 > considerations, privacy considerations, security considerations, ... >=20 > Henning >=20 > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of DRAGE,=20 > Keith (Keith) [keith.drage@alcatel-lucent.com] > Sent: Tuesday, June 30, 2015 9:50 AM > To: Adam Roach; DOLLY, MARTIN C > Cc: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing,=20 > Ordering, Distributing, Exposing, & Registering telephone=20 > Numbers (modern) >=20 > First of all, Jons presentation has no status (it was one of=20 > a number of presentations made at the meeting as to a single=20 > individuals view of what might be useful); what matters is=20 > the charter. >=20 > However what is clear to me is that we have no consensus=20 > agreement on what this group is meant to be doing or what the=20 > charter actually means. Otherwise this discussion would not=20 > be occurring. >=20 > At the simplest it appears to me that people were stating a=20 > data model where a telephone number is associated with a=20 > specific owner, and nothing more than that. >=20 > However if you dive into various people's proposed use cases,=20 > it appears that more than that is envisaged. So for example=20 > to run any enterprise system, that telephone number would=20 > need to be assocated with various other data either: >=20 > - in the end device itself, that controls how that=20 > telephone number fits with the functions that the end device=20 > provides, any security certificates, or relates to other=20 > identifiers in the device; and/or >=20 > - in some server belonging to the enterprise where the=20 > end users service policy is policed, and added functionality=20 > may also be provided. >=20 > Now the first bullet above is device configuration, and the=20 > second bullet above is network management. >=20 > So I believe some people are talking as if the problem MODERN=20 > is meant to solve also includes device configuration and=20 > network management, as I have described above, and that is=20 > certainly considerably more that a simple allocation problem. >=20 > So which is it? In this new protocol, what data model will=20 > the end point of the protocol end up with? >=20 > Keith >=20 > > -----Original Message----- > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Adam Roach > > Sent: 30 June 2015 04:27 > > To: DOLLY, MARTIN C > > Cc: modern@ietf.org > > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > > Distributing, Exposing, & Registering telephone Numbers (modern) > > > > We discussed this exact use case in Dallas. From Jon's presentation: > > > > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 > > -29%2022.12.37.png?dl=3D0 > > > > It's also described in the charter. In fact, it's really the main=20 > > thrust of the work: the charter repeatedly talks about acquiring,=20 > > managing, and resolving TNs. This is the "acquring" part. > > > > So now, as I'm reflecting on it, I'm a little confused about what=20 > > *you* think MODERN will be doing. Perhaps whatever you're worried=20 > > about isn't actually happening. > > > > /a > > > > > > On 6/29/15 21:24, DOLLY, MARTIN C wrote: > > > How is that applicable? Scope question? > > > > > > Sent from my iPhone > > > > > >> On Jun 29, 2015, at 10:16 PM, Adam Roach=20 > wrote: > > >> > > >> In this context, there isn't one. > > >> > > >> MARTINI was predicated on a continuation of having VISPs > > do excruciatingly manual things like emailing -- or in some cases=20 > > faxing -- spreadsheets to their customers detailing number=20 > ranges. I=20 > > think I still have the one I got from our VISP back in the Estacado=20 > > days when I was running our PBX. I can dig it up and=20 > forward it to you=20 > > if you really don't know how number assignment works at that level.=20 > > Basically, it's a lot of human reading and human typing. If you're=20 > > lucky, you don't have to get a fax machine involved, so you can at=20 > > least copy and paste. > > >> > > >> But emailing or faxing spreadsheets around is a brutally > > primitive and error-prone way to get this kind of thing done. > > I'm a little surprised it took this long for anyone to make=20 > a serious=20 > > run at some standardized form of automation. > > >> > > >> /a > > >> > > >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > > >>> Please explain the number assignment process > > >>> > > >>> Sent from my iPhone > > >>> > > >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach > > wrote: > > >>>>> > > >>>>> On 6/29/15 20:19, Cullen Jennings wrote: > > >>>>> I think private network case is already happening. > > There are more and more PBX that integrate with cloud=20 > providers such=20 > > as Tropo or Twillio to get phone numbers using a simple API. > > >>>> And, really, ever since we ruled this out of scope for > > MARTINI, it's been a pretty big gap in SIP PBX deployments. > > >>>> > > >>>> /a > > >>>> > > >>>> _______________________________________________ > > >>>> Modern mailing list > > >>>> Modern@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/modern > > >>> _______________________________________________ > > >>> Modern mailing list > > >>> Modern@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/modern > > > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > = From nobody Wed Jul 1 06:09:51 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271B91A87BB for ; Wed, 1 Jul 2015 06:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3pdnugrGF_b for ; Wed, 1 Jul 2015 06:09:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B401A8830 for ; Wed, 1 Jul 2015 06:09:47 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t61D9VWf019639 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jul 2015 08:09:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "DRAGE, Keith (Keith)" Date: Wed, 01 Jul 2015 08:09:31 -0500 Message-ID: <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 13:09:50 -0000 On 1 Jul 2015, at 7:45, DRAGE, Keith (Keith) wrote: > So my question still remains, given that this is significant data > associated with the number, rather than just the number itself. > > How do we distinguish this problem from either device configuration, > or network management, for which a number of solutions still exist? > > If the problem is not distinguished, then why are the existing device > configuration and network management solutions not appropriate? (no hats) It's not unreasonable that the working group, after considering requirements, could decide that an existing solution was appropriate. > > Regards > > Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Henning Schulzrinne >> Sent: 30 June 2015 19:50 >> To: DRAGE, Keith (Keith) >> Cc: modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, >> Ordering, Distributing, Exposing, & Registering telephone >> Numbers (modern) >> >> I think of the phone number as a key into a logical (not >> necessarily physical) database with a variety of fields (and >> a change log), some that are near-universal and others that >> are highly-specific to countries, use cases or even >> companies. We do the same for domain names, e.g., technical >> and administrative contacts or for DHCP, where an IP address >> is associated with a set of service records (e.g., for a SIP >> proxy, LIS or LoST server in our technical neighborhood). >> >> Much of that information exists already and is in the AT&T >> and Tropos APIs, the LNPA or LERG. Examples include: >> >> * OCN/carrier code (some kind of assignment identifier is >> probably unavoidable) >> * number state (available, locked, etc.) >> * reachability (URLs) >> * cryptographic keying materials >> >> All but the first and maybe second are likely to be optional. >> As usual, there would be suitable extension points, e.g., to >> accommodate storing 911 address information that only makes >> sense in certain relationships (not for the LNPA, but for a >> carrier-customer relationship). All the usual stuff applies >> that the veterans in this group do by rote: IANA >> considerations, privacy considerations, security considerations, ... >> >> Henning >> >> ________________________________________ >> From: Modern [modern-bounces@ietf.org] on behalf of DRAGE, >> Keith (Keith) [keith.drage@alcatel-lucent.com] >> Sent: Tuesday, June 30, 2015 9:50 AM >> To: Adam Roach; DOLLY, MARTIN C >> Cc: modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, >> Ordering, Distributing, Exposing, & Registering telephone >> Numbers (modern) >> >> First of all, Jons presentation has no status (it was one of >> a number of presentations made at the meeting as to a single >> individuals view of what might be useful); what matters is >> the charter. >> >> However what is clear to me is that we have no consensus >> agreement on what this group is meant to be doing or what the >> charter actually means. Otherwise this discussion would not >> be occurring. >> >> At the simplest it appears to me that people were stating a >> data model where a telephone number is associated with a >> specific owner, and nothing more than that. >> >> However if you dive into various people's proposed use cases, >> it appears that more than that is envisaged. So for example >> to run any enterprise system, that telephone number would >> need to be assocated with various other data either: >> >> - in the end device itself, that controls how that >> telephone number fits with the functions that the end device >> provides, any security certificates, or relates to other >> identifiers in the device; and/or >> >> - in some server belonging to the enterprise where the >> end users service policy is policed, and added functionality >> may also be provided. >> >> Now the first bullet above is device configuration, and the >> second bullet above is network management. >> >> So I believe some people are talking as if the problem MODERN >> is meant to solve also includes device configuration and >> network management, as I have described above, and that is >> certainly considerably more that a simple allocation problem. >> >> So which is it? In this new protocol, what data model will >> the end point of the protocol end up with? >> >> Keith >> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Adam Roach >>> Sent: 30 June 2015 04:27 >>> To: DOLLY, MARTIN C >>> Cc: modern@ietf.org >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >>> Distributing, Exposing, & Registering telephone Numbers (modern) >>> >>> We discussed this exact use case in Dallas. From Jon's presentation: >>> >>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 >>> -29%2022.12.37.png?dl=0 >>> >>> It's also described in the charter. In fact, it's really the main >>> thrust of the work: the charter repeatedly talks about acquiring, >>> managing, and resolving TNs. This is the "acquring" part. >>> >>> So now, as I'm reflecting on it, I'm a little confused about what >>> *you* think MODERN will be doing. Perhaps whatever you're worried >>> about isn't actually happening. >>> >>> /a >>> >>> >>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: >>>> How is that applicable? Scope question? >>>> >>>> Sent from my iPhone >>>> >>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach >> wrote: >>>>> >>>>> In this context, there isn't one. >>>>> >>>>> MARTINI was predicated on a continuation of having VISPs >>> do excruciatingly manual things like emailing -- or in some cases >>> faxing -- spreadsheets to their customers detailing number >> ranges. I >>> think I still have the one I got from our VISP back in the Estacado >>> days when I was running our PBX. I can dig it up and >> forward it to you >>> if you really don't know how number assignment works at that level. >>> Basically, it's a lot of human reading and human typing. If you're >>> lucky, you don't have to get a fax machine involved, so you can at >>> least copy and paste. >>>>> >>>>> But emailing or faxing spreadsheets around is a brutally >>> primitive and error-prone way to get this kind of thing done. >>> I'm a little surprised it took this long for anyone to make >> a serious >>> run at some standardized form of automation. >>>>> >>>>> /a >>>>> >>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>>>>> Please explain the number assignment process >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach >>> wrote: >>>>>>>> >>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>>>>> I think private network case is already happening. >>> There are more and more PBX that integrate with cloud >> providers such >>> as Tropo or Twillio to get phone numbers using a simple API. >>>>>>> And, really, ever since we ruled this out of scope for >>> MARTINI, it's been a pretty big gap in SIP PBX deployments. >>>>>>> >>>>>>> /a >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Modern mailing list >>>>>>> Modern@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/modern >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 06:13:14 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF231A884B for ; Wed, 1 Jul 2015 06:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvvyDZrQDWHi for ; Wed, 1 Jul 2015 06:13:06 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F651A87E2 for ; Wed, 1 Jul 2015 06:13:06 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 267e3955.2aec02c3d940.269727.00-2466.758818.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 01 Jul 2015 13:13:06 +0000 (UTC) X-MXL-Hash: 5593e7620d21975b-53567b535aadea3ae8af63965a9bd3af20d5fa9f Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 557e3955.0.269615.00-2255.758489.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 01 Jul 2015 13:12:54 +0000 (UTC) X-MXL-Hash: 5593e7562dc24161-6eab196e28d04de63a9c2d815cf99b824ac04288 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t61DCpUB010045; Wed, 1 Jul 2015 09:12:52 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t61DCd6u009794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jul 2015 09:12:42 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 1 Jul 2015 13:12:19 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0224.002; Wed, 1 Jul 2015 09:12:19 -0400 From: "DOLLY, MARTIN C" To: Ben Campbell , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABbgSAgAAGyID//71F8A== Date: Wed, 1 Jul 2015 13:12:18 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> In-Reply-To: <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.25.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ZeeqwLpA c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=IzMnIRv6Bj0A:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=gxZvrgisAA] X-AnalysisOut: [AA:8 a=VAMm1qzQAAAA:8 a=Z80JlwQ0AAAA:8 a=28KzlJ9W7uBpbXq90] X-AnalysisOut: [MkA:9 a=CjuIK1q_8ugA:10 a=8Kkkvio1qGN3tiCs:21 a=R7H5nGtPwU] X-AnalysisOut: [-1RpOX:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 13:13:09 -0000 But this is the root of the issue here, the requirements for such a solutio= n is based on policy and regulation, that does not exist , yet.... -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Wednesday, July 01, 2015 9:10 AM To: DRAGE, Keith (Keith) Cc: modern@ietf.org; Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) On 1 Jul 2015, at 7:45, DRAGE, Keith (Keith) wrote: > So my question still remains, given that this is significant data=20 > associated with the number, rather than just the number itself. > > How do we distinguish this problem from either device configuration,=20 > or network management, for which a number of solutions still exist? > > If the problem is not distinguished, then why are the existing device=20 > configuration and network management solutions not appropriate? (no hats) It's not unreasonable that the working group, after considering requirement= s, could decide that an existing solution was appropriate. > > Regards > > Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning=20 >> Schulzrinne >> Sent: 30 June 2015 19:50 >> To: DRAGE, Keith (Keith) >> Cc: modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 >> Distributing, Exposing, & Registering telephone Numbers (modern) >> >> I think of the phone number as a key into a logical (not necessarily=20 >> physical) database with a variety of fields (and a change log), some=20 >> that are near-universal and others that are highly-specific to=20 >> countries, use cases or even companies. We do the same for domain=20 >> names, e.g., technical and administrative contacts or for DHCP, where=20 >> an IP address is associated with a set of service records (e.g., for=20 >> a SIP proxy, LIS or LoST server in our technical neighborhood). >> >> Much of that information exists already and is in the AT&T and Tropos=20 >> APIs, the LNPA or LERG. Examples include: >> >> * OCN/carrier code (some kind of assignment identifier is probably=20 >> unavoidable) >> * number state (available, locked, etc.) >> * reachability (URLs) >> * cryptographic keying materials >> >> All but the first and maybe second are likely to be optional. >> As usual, there would be suitable extension points, e.g., to=20 >> accommodate storing 911 address information that only makes sense in=20 >> certain relationships (not for the LNPA, but for a carrier-customer=20 >> relationship). All the usual stuff applies that the veterans in this=20 >> group do by rote: IANA considerations, privacy considerations,=20 >> security considerations, ... >> >> Henning >> >> ________________________________________ >> From: Modern [modern-bounces@ietf.org] on behalf of DRAGE, Keith=20 >> (Keith) [keith.drage@alcatel-lucent.com] >> Sent: Tuesday, June 30, 2015 9:50 AM >> To: Adam Roach; DOLLY, MARTIN C >> Cc: modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 >> Distributing, Exposing, & Registering telephone Numbers (modern) >> >> First of all, Jons presentation has no status (it was one of a number=20 >> of presentations made at the meeting as to a single individuals view=20 >> of what might be useful); what matters is the charter. >> >> However what is clear to me is that we have no consensus agreement on=20 >> what this group is meant to be doing or what the charter actually=20 >> means. Otherwise this discussion would not be occurring. >> >> At the simplest it appears to me that people were stating a data=20 >> model where a telephone number is associated with a specific owner,=20 >> and nothing more than that. >> >> However if you dive into various people's proposed use cases, it=20 >> appears that more than that is envisaged. So for example to run any=20 >> enterprise system, that telephone number would need to be assocated=20 >> with various other data either: >> >> - in the end device itself, that controls how that >> telephone number fits with the functions that the end device=20 >> provides, any security certificates, or relates to other identifiers=20 >> in the device; and/or >> >> - in some server belonging to the enterprise where the >> end users service policy is policed, and added functionality may also=20 >> be provided. >> >> Now the first bullet above is device configuration, and the second=20 >> bullet above is network management. >> >> So I believe some people are talking as if the problem MODERN is=20 >> meant to solve also includes device configuration and network=20 >> management, as I have described above, and that is certainly=20 >> considerably more that a simple allocation problem. >> >> So which is it? In this new protocol, what data model will the end=20 >> point of the protocol end up with? >> >> Keith >> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Adam Roach >>> Sent: 30 June 2015 04:27 >>> To: DOLLY, MARTIN C >>> Cc: modern@ietf.org >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 >>> Distributing, Exposing, & Registering telephone Numbers (modern) >>> >>> We discussed this exact use case in Dallas. From Jon's presentation: >>> >>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 >>> -29%2022.12.37.png?dl=3D0 >>> >>> It's also described in the charter. In fact, it's really the main=20 >>> thrust of the work: the charter repeatedly talks about acquiring,=20 >>> managing, and resolving TNs. This is the "acquring" part. >>> >>> So now, as I'm reflecting on it, I'm a little confused about what >>> *you* think MODERN will be doing. Perhaps whatever you're worried=20 >>> about isn't actually happening. >>> >>> /a >>> >>> >>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: >>>> How is that applicable? Scope question? >>>> >>>> Sent from my iPhone >>>> >>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach >> wrote: >>>>> >>>>> In this context, there isn't one. >>>>> >>>>> MARTINI was predicated on a continuation of having VISPs >>> do excruciatingly manual things like emailing -- or in some cases=20 >>> faxing -- spreadsheets to their customers detailing number >> ranges. I >>> think I still have the one I got from our VISP back in the Estacado=20 >>> days when I was running our PBX. I can dig it up and >> forward it to you >>> if you really don't know how number assignment works at that level. >>> Basically, it's a lot of human reading and human typing. If you're=20 >>> lucky, you don't have to get a fax machine involved, so you can at=20 >>> least copy and paste. >>>>> >>>>> But emailing or faxing spreadsheets around is a brutally >>> primitive and error-prone way to get this kind of thing done. >>> I'm a little surprised it took this long for anyone to make >> a serious >>> run at some standardized form of automation. >>>>> >>>>> /a >>>>> >>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>>>>> Please explain the number assignment process >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach >>> wrote: >>>>>>>> >>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>>>>> I think private network case is already happening. >>> There are more and more PBX that integrate with cloud >> providers such >>> as Tropo or Twillio to get phone numbers using a simple API. >>>>>>> And, really, ever since we ruled this out of scope for >>> MARTINI, it's been a pretty big gap in SIP PBX deployments. >>>>>>> >>>>>>> /a >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Modern mailing list >>>>>>> Modern@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/modern >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 06:29:15 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C881A8887 for ; Wed, 1 Jul 2015 06:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDirEvDtk9f4 for ; Wed, 1 Jul 2015 06:29:13 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3FE1A884C for ; Wed, 1 Jul 2015 06:29:13 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaA///BkTs= Date: Wed, 1 Jul 2015 13:29:11 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca>, <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com>, <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com>, <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> , <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 13:29:14 -0000 Indeed, it would be interesting to see whether and how Netconf/YANG fits th= e requirements. I'm sure somebody will propose using DNS TXT records...=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com]=0A= Sent: Wednesday, July 01, 2015 8:45 AM=0A= To: Henning Schulzrinne=0A= Cc: modern@ietf.org=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= So my question still remains, given that this is significant data associate= d with the number, rather than just the number itself.=0A= =0A= How do we distinguish this problem from either device configuration, or net= work management, for which a number of solutions still exist?=0A= =0A= If the problem is not distinguished, then why are the existing device confi= guration and network management solutions not appropriate?=0A= =0A= Regards=0A= =0A= Keith=0A= From nobody Wed Jul 1 06:34:10 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F1F1A88DC for ; Wed, 1 Jul 2015 06:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g77RlP8JUWTo for ; Wed, 1 Jul 2015 06:34:06 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 927061A88DB for ; Wed, 1 Jul 2015 06:34:06 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DOLLY, MARTIN C" , Ben Campbell , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGL Date: Wed, 1 Jul 2015 13:34:04 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 13:34:08 -0000 To move the discussion forward, rather than cycling back to invoking the te= rms, I'd be interested in hearing which requirements, precisely and concret= ely, are likely to depend on policy and regulation. =0A= =0A= Everybody has iterated again and again that the "who can get what" part def= initely does, but that's outside the protocol mechanism, just like "who can= see what web page" or "who can place what SIP call" is beyond the concern = of HTTP or SIP, beyond providing an authentication mechanism that allows to= associate a policy with a principal.=0A= =0A= You must have specific issues in mind that go beyond that.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: DOLLY, MARTIN C [md3135@att.com]=0A= Sent: Wednesday, July 01, 2015 9:12 AM=0A= To: Ben Campbell; DRAGE, Keith (Keith)=0A= Cc: modern@ietf.org; Henning Schulzrinne=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= But this is the root of the issue here, the requirements for such a solutio= n is based on policy and regulation, that does not exist , yet....=0A= From nobody Wed Jul 1 07:09:00 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53E91A89C7 for ; Wed, 1 Jul 2015 07:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4PPhQBiQIcv for ; Wed, 1 Jul 2015 07:08:56 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A04C1A89BB for ; Wed, 1 Jul 2015 07:08:55 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A514CBBFBD2ED; Wed, 1 Jul 2015 14:08:50 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t61E8drS032239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 16:08:51 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 16:08:31 +0200 From: "DRAGE, Keith (Keith)" To: Ben Campbell Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEyfpGjnKN5EOWAsicctSAOp3EKLIAgAABPICAAARggIAAAjqAgAARrACAAMvOcIAANc8AgAFINYD//+sjgIAAMVAw Date: Wed, 1 Jul 2015 14:08:30 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69737DD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> In-Reply-To: <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:08:59 -0000 Yes, but the problem is that it appears that the current charter is so wide= ly scoped that any issue that any network management issue involving a tele= phone number falls within the scope of the charter, whereas existing networ= k management (or device configuration groups) should cover network manageme= nt problems. The charter should be revised to be more precise. Regards Keith > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: 01 July 2015 14:10 > To: DRAGE, Keith (Keith) > Cc: Henning Schulzrinne; modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing,=20 > Ordering, Distributing, Exposing, & Registering telephone=20 > Numbers (modern) >=20 > On 1 Jul 2015, at 7:45, DRAGE, Keith (Keith) wrote: >=20 > > So my question still remains, given that this is significant data=20 > > associated with the number, rather than just the number itself. > > > > How do we distinguish this problem from either device=20 > configuration,=20 > > or network management, for which a number of solutions still exist? > > > > If the problem is not distinguished, then why are the=20 > existing device=20 > > configuration and network management solutions not appropriate? >=20 > (no hats) >=20 > It's not unreasonable that the working group, after=20 > considering requirements, could decide that an existing=20 > solution was appropriate. >=20 > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning=20 > >> Schulzrinne > >> Sent: 30 June 2015 19:50 > >> To: DRAGE, Keith (Keith) > >> Cc: modern@ietf.org > >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > >> Distributing, Exposing, & Registering telephone Numbers (modern) > >> > >> I think of the phone number as a key into a logical (not=20 > necessarily=20 > >> physical) database with a variety of fields (and a change=20 > log), some=20 > >> that are near-universal and others that are highly-specific to=20 > >> countries, use cases or even companies. We do the same for domain=20 > >> names, e.g., technical and administrative contacts or for=20 > DHCP, where=20 > >> an IP address is associated with a set of service records=20 > (e.g., for=20 > >> a SIP proxy, LIS or LoST server in our technical neighborhood). > >> > >> Much of that information exists already and is in the AT&T=20 > and Tropos=20 > >> APIs, the LNPA or LERG. Examples include: > >> > >> * OCN/carrier code (some kind of assignment identifier is probably=20 > >> unavoidable) > >> * number state (available, locked, etc.) > >> * reachability (URLs) > >> * cryptographic keying materials > >> > >> All but the first and maybe second are likely to be optional. > >> As usual, there would be suitable extension points, e.g., to=20 > >> accommodate storing 911 address information that only=20 > makes sense in=20 > >> certain relationships (not for the LNPA, but for a=20 > carrier-customer=20 > >> relationship). All the usual stuff applies that the=20 > veterans in this=20 > >> group do by rote: IANA considerations, privacy considerations,=20 > >> security considerations, ... > >> > >> Henning > >> > >> ________________________________________ > >> From: Modern [modern-bounces@ietf.org] on behalf of DRAGE, Keith=20 > >> (Keith) [keith.drage@alcatel-lucent.com] > >> Sent: Tuesday, June 30, 2015 9:50 AM > >> To: Adam Roach; DOLLY, MARTIN C > >> Cc: modern@ietf.org > >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > >> Distributing, Exposing, & Registering telephone Numbers (modern) > >> > >> First of all, Jons presentation has no status (it was one=20 > of a number=20 > >> of presentations made at the meeting as to a single=20 > individuals view=20 > >> of what might be useful); what matters is the charter. > >> > >> However what is clear to me is that we have no consensus=20 > agreement on=20 > >> what this group is meant to be doing or what the charter actually=20 > >> means. Otherwise this discussion would not be occurring. > >> > >> At the simplest it appears to me that people were stating a data=20 > >> model where a telephone number is associated with a=20 > specific owner,=20 > >> and nothing more than that. > >> > >> However if you dive into various people's proposed use cases, it=20 > >> appears that more than that is envisaged. So for example=20 > to run any=20 > >> enterprise system, that telephone number would need to be=20 > assocated=20 > >> with various other data either: > >> > >> - in the end device itself, that controls how that > >> telephone number fits with the functions that the end device=20 > >> provides, any security certificates, or relates to other=20 > identifiers=20 > >> in the device; and/or > >> > >> - in some server belonging to the enterprise where the > >> end users service policy is policed, and added=20 > functionality may also=20 > >> be provided. > >> > >> Now the first bullet above is device configuration, and the second=20 > >> bullet above is network management. > >> > >> So I believe some people are talking as if the problem MODERN is=20 > >> meant to solve also includes device configuration and network=20 > >> management, as I have described above, and that is certainly=20 > >> considerably more that a simple allocation problem. > >> > >> So which is it? In this new protocol, what data model will the end=20 > >> point of the protocol end up with? > >> > >> Keith > >> > >>> -----Original Message----- > >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of > >> Adam Roach > >>> Sent: 30 June 2015 04:27 > >>> To: DOLLY, MARTIN C > >>> Cc: modern@ietf.org > >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > >>> Distributing, Exposing, & Registering telephone Numbers (modern) > >>> > >>> We discussed this exact use case in Dallas. From Jon's=20 > presentation: > >>> > >>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 > >>> -29%2022.12.37.png?dl=3D0 > >>> > >>> It's also described in the charter. In fact, it's really the main=20 > >>> thrust of the work: the charter repeatedly talks about acquiring,=20 > >>> managing, and resolving TNs. This is the "acquring" part. > >>> > >>> So now, as I'm reflecting on it, I'm a little confused about what > >>> *you* think MODERN will be doing. Perhaps whatever you're worried=20 > >>> about isn't actually happening. > >>> > >>> /a > >>> > >>> > >>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: > >>>> How is that applicable? Scope question? > >>>> > >>>> Sent from my iPhone > >>>> > >>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach > >> wrote: > >>>>> > >>>>> In this context, there isn't one. > >>>>> > >>>>> MARTINI was predicated on a continuation of having VISPs > >>> do excruciatingly manual things like emailing -- or in some cases=20 > >>> faxing -- spreadsheets to their customers detailing number > >> ranges. I > >>> think I still have the one I got from our VISP back in=20 > the Estacado=20 > >>> days when I was running our PBX. I can dig it up and > >> forward it to you > >>> if you really don't know how number assignment works at=20 > that level. > >>> Basically, it's a lot of human reading and human typing.=20 > If you're=20 > >>> lucky, you don't have to get a fax machine involved, so=20 > you can at=20 > >>> least copy and paste. > >>>>> > >>>>> But emailing or faxing spreadsheets around is a brutally > >>> primitive and error-prone way to get this kind of thing done. > >>> I'm a little surprised it took this long for anyone to make > >> a serious > >>> run at some standardized form of automation. > >>>>> > >>>>> /a > >>>>> > >>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > >>>>>> Please explain the number assignment process > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach > >>> wrote: > >>>>>>>> > >>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: > >>>>>>>> I think private network case is already happening. > >>> There are more and more PBX that integrate with cloud > >> providers such > >>> as Tropo or Twillio to get phone numbers using a simple API. > >>>>>>> And, really, ever since we ruled this out of scope for > >>> MARTINI, it's been a pretty big gap in SIP PBX deployments. > >>>>>>> > >>>>>>> /a > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Modern mailing list > >>>>>>> Modern@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>> _______________________________________________ > >>>>>> Modern mailing list > >>>>>> Modern@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/modern > >>> > >>> _______________________________________________ > >>> Modern mailing list > >>> Modern@ietf.org > >>> https://www.ietf.org/mailman/listinfo/modern > >>> > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> https://www.ietf.org/mailman/listinfo/modern > >> > >> > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> https://www.ietf.org/mailman/listinfo/modern > >> > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > = From nobody Wed Jul 1 07:15:49 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599601A89C7 for ; Wed, 1 Jul 2015 07:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS-S4pHmVFF6 for ; Wed, 1 Jul 2015 07:15:47 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96171A89B3 for ; Wed, 1 Jul 2015 07:15:46 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 216f3955.2b2febe12940.275845.00-2457.777697.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 01 Jul 2015 14:15:46 +0000 (UTC) X-MXL-Hash: 5593f6125852621d-5e215e20e86a9f9a80bc5c07ce344c539f899db6 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 065f3955.0.273588.00-2259.771210.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 01 Jul 2015 14:12:49 +0000 (UTC) X-MXL-Hash: 5593f561556ccb0e-d48c934e4aba871c789a48fc1533e100af921457 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t61EClM5031363; Wed, 1 Jul 2015 10:12:48 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t61ECelt031264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jul 2015 10:12:43 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 1 Jul 2015 14:12:27 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0224.002; Wed, 1 Jul 2015 10:12:26 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne , Ben Campbell , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABbgSAgAAGyID//71F8IAASZcA///GW4A= Date: Wed, 1 Jul 2015 14:12:26 +0000 Message-ID: References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.25.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=IL61/HTG c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=IzMnIRv6Bj0A:10 a=BLceE] X-AnalysisOut: [mwcHowA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=j9P3lsx995] X-AnalysisOut: [WJzp_WPvkA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:15:48 -0000 May be I have been a System Engineer too long: 1. The service/capability requirements would be defined by policy/regulator= y needs. 2. Then the "tool" requirements would be derived from the policy/regulatory= needs A builder needs to know what he is building in order to ensure that he has = the correct tools in his tool box.... -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 01, 2015 9:34 AM To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) Cc: modern@ietf.org Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) To move the discussion forward, rather than cycling back to invoking the te= rms, I'd be interested in hearing which requirements, precisely and concret= ely, are likely to depend on policy and regulation.=20 Everybody has iterated again and again that the "who can get what" part def= initely does, but that's outside the protocol mechanism, just like "who can= see what web page" or "who can place what SIP call" is beyond the concern = of HTTP or SIP, beyond providing an authentication mechanism that allows to= associate a policy with a principal. You must have specific issues in mind that go beyond that. Henning ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Wednesday, July 01, 2015 9:12 AM To: Ben Campbell; DRAGE, Keith (Keith) Cc: modern@ietf.org; Henning Schulzrinne Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) But this is the root of the issue here, the requirements for such a solutio= n is based on policy and regulation, that does not exist , yet.... From nobody Wed Jul 1 07:27:16 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07D51A8A82 for ; Wed, 1 Jul 2015 07:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpLvnUiWx6S5 for ; Wed, 1 Jul 2015 07:27:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA661A8A81 for ; Wed, 1 Jul 2015 07:26:10 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t61EPtPV026236 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jul 2015 09:26:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "DRAGE, Keith (Keith)" Date: Wed, 01 Jul 2015 09:25:55 -0500 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69737DD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737DD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:27:14 -0000 (no hats) On 1 Jul 2015, at 9:08, DRAGE, Keith (Keith) wrote: > Yes, but the problem is that it appears that the current charter is so > widely scoped that any issue that any network management issue > involving a telephone number falls within the scope of the charter, > whereas existing network management (or device configuration groups) > should cover network management problems. > I think that's a tortured reading of the charter as a whole. > The charter should be revised to be more precise. I disagree. The charter is not a technical specification. It needs to balance precision against allowing enough flexibility for the working group to make decisions. I think it's time to let the wg start making those decisions (and much of the discussion over the last few days may be useful for that purpose.) Ben. > > Regards > > Keith > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 01 July 2015 14:10 >> To: DRAGE, Keith (Keith) >> Cc: Henning Schulzrinne; modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, >> Ordering, Distributing, Exposing, & Registering telephone >> Numbers (modern) >> >> On 1 Jul 2015, at 7:45, DRAGE, Keith (Keith) wrote: >> >>> So my question still remains, given that this is significant data >>> associated with the number, rather than just the number itself. >>> >>> How do we distinguish this problem from either device >> configuration, >>> or network management, for which a number of solutions still exist? >>> >>> If the problem is not distinguished, then why are the >> existing device >>> configuration and network management solutions not appropriate? >> >> (no hats) >> >> It's not unreasonable that the working group, after >> considering requirements, could decide that an existing >> solution was appropriate. >> >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >>>> Schulzrinne >>>> Sent: 30 June 2015 19:50 >>>> To: DRAGE, Keith (Keith) >>>> Cc: modern@ietf.org >>>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >>>> Distributing, Exposing, & Registering telephone Numbers (modern) >>>> >>>> I think of the phone number as a key into a logical (not >> necessarily >>>> physical) database with a variety of fields (and a change >> log), some >>>> that are near-universal and others that are highly-specific to >>>> countries, use cases or even companies. We do the same for domain >>>> names, e.g., technical and administrative contacts or for >> DHCP, where >>>> an IP address is associated with a set of service records >> (e.g., for >>>> a SIP proxy, LIS or LoST server in our technical neighborhood). >>>> >>>> Much of that information exists already and is in the AT&T >> and Tropos >>>> APIs, the LNPA or LERG. Examples include: >>>> >>>> * OCN/carrier code (some kind of assignment identifier is probably >>>> unavoidable) >>>> * number state (available, locked, etc.) >>>> * reachability (URLs) >>>> * cryptographic keying materials >>>> >>>> All but the first and maybe second are likely to be optional. >>>> As usual, there would be suitable extension points, e.g., to >>>> accommodate storing 911 address information that only >> makes sense in >>>> certain relationships (not for the LNPA, but for a >> carrier-customer >>>> relationship). All the usual stuff applies that the >> veterans in this >>>> group do by rote: IANA considerations, privacy considerations, >>>> security considerations, ... >>>> >>>> Henning >>>> >>>> ________________________________________ >>>> From: Modern [modern-bounces@ietf.org] on behalf of DRAGE, Keith >>>> (Keith) [keith.drage@alcatel-lucent.com] >>>> Sent: Tuesday, June 30, 2015 9:50 AM >>>> To: Adam Roach; DOLLY, MARTIN C >>>> Cc: modern@ietf.org >>>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >>>> Distributing, Exposing, & Registering telephone Numbers (modern) >>>> >>>> First of all, Jons presentation has no status (it was one >> of a number >>>> of presentations made at the meeting as to a single >> individuals view >>>> of what might be useful); what matters is the charter. >>>> >>>> However what is clear to me is that we have no consensus >> agreement on >>>> what this group is meant to be doing or what the charter actually >>>> means. Otherwise this discussion would not be occurring. >>>> >>>> At the simplest it appears to me that people were stating a data >>>> model where a telephone number is associated with a >> specific owner, >>>> and nothing more than that. >>>> >>>> However if you dive into various people's proposed use cases, it >>>> appears that more than that is envisaged. So for example >> to run any >>>> enterprise system, that telephone number would need to be >> assocated >>>> with various other data either: >>>> >>>> - in the end device itself, that controls how that >>>> telephone number fits with the functions that the end device >>>> provides, any security certificates, or relates to other >> identifiers >>>> in the device; and/or >>>> >>>> - in some server belonging to the enterprise where the >>>> end users service policy is policed, and added >> functionality may also >>>> be provided. >>>> >>>> Now the first bullet above is device configuration, and the second >>>> bullet above is network management. >>>> >>>> So I believe some people are talking as if the problem MODERN is >>>> meant to solve also includes device configuration and network >>>> management, as I have described above, and that is certainly >>>> considerably more that a simple allocation problem. >>>> >>>> So which is it? In this new protocol, what data model will the end >>>> point of the protocol end up with? >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>> Adam Roach >>>>> Sent: 30 June 2015 04:27 >>>>> To: DOLLY, MARTIN C >>>>> Cc: modern@ietf.org >>>>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >>>>> Distributing, Exposing, & Registering telephone Numbers (modern) >>>>> >>>>> We discussed this exact use case in Dallas. From Jon's >> presentation: >>>>> >>>>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 >>>>> -29%2022.12.37.png?dl=0 >>>>> >>>>> It's also described in the charter. In fact, it's really the main >>>>> thrust of the work: the charter repeatedly talks about acquiring, >>>>> managing, and resolving TNs. This is the "acquring" part. >>>>> >>>>> So now, as I'm reflecting on it, I'm a little confused about what >>>>> *you* think MODERN will be doing. Perhaps whatever you're worried >>>>> about isn't actually happening. >>>>> >>>>> /a >>>>> >>>>> >>>>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: >>>>>> How is that applicable? Scope question? >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach >>>> wrote: >>>>>>> >>>>>>> In this context, there isn't one. >>>>>>> >>>>>>> MARTINI was predicated on a continuation of having VISPs >>>>> do excruciatingly manual things like emailing -- or in some cases >>>>> faxing -- spreadsheets to their customers detailing number >>>> ranges. I >>>>> think I still have the one I got from our VISP back in >> the Estacado >>>>> days when I was running our PBX. I can dig it up and >>>> forward it to you >>>>> if you really don't know how number assignment works at >> that level. >>>>> Basically, it's a lot of human reading and human typing. >> If you're >>>>> lucky, you don't have to get a fax machine involved, so >> you can at >>>>> least copy and paste. >>>>>>> >>>>>>> But emailing or faxing spreadsheets around is a brutally >>>>> primitive and error-prone way to get this kind of thing done. >>>>> I'm a little surprised it took this long for anyone to make >>>> a serious >>>>> run at some standardized form of automation. >>>>>>> >>>>>>> /a >>>>>>> >>>>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >>>>>>>> Please explain the number assignment process >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach >>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >>>>>>>>>> I think private network case is already happening. >>>>> There are more and more PBX that integrate with cloud >>>> providers such >>>>> as Tropo or Twillio to get phone numbers using a simple API. >>>>>>>>> And, really, ever since we ruled this out of scope for >>>>> MARTINI, it's been a pretty big gap in SIP PBX deployments. >>>>>>>>> >>>>>>>>> /a >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Modern mailing list >>>>>>>>> Modern@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>>>> _______________________________________________ >>>>>>>> Modern mailing list >>>>>>>> Modern@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/modern >>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/modern >>>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> From nobody Wed Jul 1 07:38:21 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0545A1A8AC5 for ; Wed, 1 Jul 2015 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9XpEEop7MhJ for ; Wed, 1 Jul 2015 07:38:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8FF1A8A89 for ; Wed, 1 Jul 2015 07:37:37 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B5EB36B1960FF; Wed, 1 Jul 2015 14:37:32 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t61EbTRm023977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 16:37:34 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 16:37:32 +0200 From: "DRAGE, Keith (Keith)" To: Ben Campbell Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEyfpGjnKN5EOWAsicctSAOp3EKLIAgAABPICAAARggIAAAjqAgAARrACAAMvOcIAANc8AgAFINYD//+sjgIAAMVAw///kCICAACQMQA== Date: Wed, 1 Jul 2015 14:37:31 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69737E55@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737DD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:38:20 -0000 It is not me that is doing the tortured reading. It is apparent from potent= ial use cases being identified on the list that others have that flexibilit= y of the reading from the current charter. But the point I am making is that working groups should not be created to c= over the work of other groups. It is clear that there is significant overla= p of this charter with groups doing network management, and that needs to b= e resolved.=20 It is not about restricting the flexibility of the group, it is dealing wit= h overlap (a matter that gets written into the charter of many working grou= ps).=20 Regards Keith > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: 01 July 2015 15:26 > To: DRAGE, Keith (Keith) > Cc: Henning Schulzrinne; modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing,=20 > Ordering, Distributing, Exposing, & Registering telephone=20 > Numbers (modern) >=20 > (no hats) >=20 > On 1 Jul 2015, at 9:08, DRAGE, Keith (Keith) wrote: >=20 > > Yes, but the problem is that it appears that the current=20 > charter is so=20 > > widely scoped that any issue that any network management issue=20 > > involving a telephone number falls within the scope of the charter,=20 > > whereas existing network management (or device=20 > configuration groups)=20 > > should cover network management problems. > > >=20 > I think that's a tortured reading of the charter as a whole. >=20 > > The charter should be revised to be more precise. >=20 > I disagree. The charter is not a technical specification. It=20 > needs to balance precision against allowing enough=20 > flexibility for the working group to make decisions. I think=20 > it's time to let the wg start making those decisions (and=20 > much of the discussion over the last few days may be useful=20 > for that purpose.) >=20 >=20 > Ben. >=20 > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: 01 July 2015 14:10 > >> To: DRAGE, Keith (Keith) > >> Cc: Henning Schulzrinne; modern@ietf.org > >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > >> Distributing, Exposing, & Registering telephone Numbers (modern) > >> > >> On 1 Jul 2015, at 7:45, DRAGE, Keith (Keith) wrote: > >> > >>> So my question still remains, given that this is significant data=20 > >>> associated with the number, rather than just the number itself. > >>> > >>> How do we distinguish this problem from either device > >> configuration, > >>> or network management, for which a number of solutions=20 > still exist? > >>> > >>> If the problem is not distinguished, then why are the > >> existing device > >>> configuration and network management solutions not appropriate? > >> > >> (no hats) > >> > >> It's not unreasonable that the working group, after considering=20 > >> requirements, could decide that an existing solution was=20 > appropriate. > >> > >>> > >>> Regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf=20 > Of Henning=20 > >>>> Schulzrinne > >>>> Sent: 30 June 2015 19:50 > >>>> To: DRAGE, Keith (Keith) > >>>> Cc: modern@ietf.org > >>>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > >>>> Distributing, Exposing, & Registering telephone Numbers (modern) > >>>> > >>>> I think of the phone number as a key into a logical (not > >> necessarily > >>>> physical) database with a variety of fields (and a change > >> log), some > >>>> that are near-universal and others that are highly-specific to=20 > >>>> countries, use cases or even companies. We do the same=20 > for domain=20 > >>>> names, e.g., technical and administrative contacts or for > >> DHCP, where > >>>> an IP address is associated with a set of service records > >> (e.g., for > >>>> a SIP proxy, LIS or LoST server in our technical neighborhood). > >>>> > >>>> Much of that information exists already and is in the AT&T > >> and Tropos > >>>> APIs, the LNPA or LERG. Examples include: > >>>> > >>>> * OCN/carrier code (some kind of assignment identifier=20 > is probably > >>>> unavoidable) > >>>> * number state (available, locked, etc.) > >>>> * reachability (URLs) > >>>> * cryptographic keying materials > >>>> > >>>> All but the first and maybe second are likely to be optional. > >>>> As usual, there would be suitable extension points, e.g., to=20 > >>>> accommodate storing 911 address information that only > >> makes sense in > >>>> certain relationships (not for the LNPA, but for a > >> carrier-customer > >>>> relationship). All the usual stuff applies that the > >> veterans in this > >>>> group do by rote: IANA considerations, privacy considerations,=20 > >>>> security considerations, ... > >>>> > >>>> Henning > >>>> > >>>> ________________________________________ > >>>> From: Modern [modern-bounces@ietf.org] on behalf of DRAGE, Keith > >>>> (Keith) [keith.drage@alcatel-lucent.com] > >>>> Sent: Tuesday, June 30, 2015 9:50 AM > >>>> To: Adam Roach; DOLLY, MARTIN C > >>>> Cc: modern@ietf.org > >>>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > >>>> Distributing, Exposing, & Registering telephone Numbers (modern) > >>>> > >>>> First of all, Jons presentation has no status (it was one > >> of a number > >>>> of presentations made at the meeting as to a single > >> individuals view > >>>> of what might be useful); what matters is the charter. > >>>> > >>>> However what is clear to me is that we have no consensus > >> agreement on > >>>> what this group is meant to be doing or what the charter=20 > actually=20 > >>>> means. Otherwise this discussion would not be occurring. > >>>> > >>>> At the simplest it appears to me that people were stating a data=20 > >>>> model where a telephone number is associated with a > >> specific owner, > >>>> and nothing more than that. > >>>> > >>>> However if you dive into various people's proposed use cases, it=20 > >>>> appears that more than that is envisaged. So for example > >> to run any > >>>> enterprise system, that telephone number would need to be > >> assocated > >>>> with various other data either: > >>>> > >>>> - in the end device itself, that controls how that > >>>> telephone number fits with the functions that the end device=20 > >>>> provides, any security certificates, or relates to other > >> identifiers > >>>> in the device; and/or > >>>> > >>>> - in some server belonging to the enterprise where the > >>>> end users service policy is policed, and added > >> functionality may also > >>>> be provided. > >>>> > >>>> Now the first bullet above is device configuration, and=20 > the second=20 > >>>> bullet above is network management. > >>>> > >>>> So I believe some people are talking as if the problem MODERN is=20 > >>>> meant to solve also includes device configuration and network=20 > >>>> management, as I have described above, and that is certainly=20 > >>>> considerably more that a simple allocation problem. > >>>> > >>>> So which is it? In this new protocol, what data model=20 > will the end=20 > >>>> point of the protocol end up with? > >>>> > >>>> Keith > >>>> > >>>>> -----Original Message----- > >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of > >>>> Adam Roach > >>>>> Sent: 30 June 2015 04:27 > >>>>> To: DOLLY, MARTIN C > >>>>> Cc: modern@ietf.org > >>>>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 > >>>>> Distributing, Exposing, & Registering telephone Numbers (modern) > >>>>> > >>>>> We discussed this exact use case in Dallas. From Jon's > >> presentation: > >>>>> > >>>>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 > >>>>> -29%2022.12.37.png?dl=3D0 > >>>>> > >>>>> It's also described in the charter. In fact, it's=20 > really the main=20 > >>>>> thrust of the work: the charter repeatedly talks about=20 > acquiring,=20 > >>>>> managing, and resolving TNs. This is the "acquring" part. > >>>>> > >>>>> So now, as I'm reflecting on it, I'm a little confused=20 > about what > >>>>> *you* think MODERN will be doing. Perhaps whatever=20 > you're worried=20 > >>>>> about isn't actually happening. > >>>>> > >>>>> /a > >>>>> > >>>>> > >>>>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: > >>>>>> How is that applicable? Scope question? > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach > >>>> wrote: > >>>>>>> > >>>>>>> In this context, there isn't one. > >>>>>>> > >>>>>>> MARTINI was predicated on a continuation of having VISPs > >>>>> do excruciatingly manual things like emailing -- or in=20 > some cases=20 > >>>>> faxing -- spreadsheets to their customers detailing number > >>>> ranges. I > >>>>> think I still have the one I got from our VISP back in > >> the Estacado > >>>>> days when I was running our PBX. I can dig it up and > >>>> forward it to you > >>>>> if you really don't know how number assignment works at > >> that level. > >>>>> Basically, it's a lot of human reading and human typing. > >> If you're > >>>>> lucky, you don't have to get a fax machine involved, so > >> you can at > >>>>> least copy and paste. > >>>>>>> > >>>>>>> But emailing or faxing spreadsheets around is a brutally > >>>>> primitive and error-prone way to get this kind of thing done. > >>>>> I'm a little surprised it took this long for anyone to make > >>>> a serious > >>>>> run at some standardized form of automation. > >>>>>>> > >>>>>>> /a > >>>>>>> > >>>>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: > >>>>>>>> Please explain the number assignment process > >>>>>>>> > >>>>>>>> Sent from my iPhone > >>>>>>>> > >>>>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach > >>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: > >>>>>>>>>> I think private network case is already happening. > >>>>> There are more and more PBX that integrate with cloud > >>>> providers such > >>>>> as Tropo or Twillio to get phone numbers using a simple API. > >>>>>>>>> And, really, ever since we ruled this out of scope for > >>>>> MARTINI, it's been a pretty big gap in SIP PBX deployments. > >>>>>>>>> > >>>>>>>>> /a > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Modern mailing list > >>>>>>>>> Modern@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>>>>> _______________________________________________ > >>>>>>>> Modern mailing list > >>>>>>>> Modern@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>> > >>>>> _______________________________________________ > >>>>> Modern mailing list > >>>>> Modern@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/modern > >>>>> > >>>> _______________________________________________ > >>>> Modern mailing list > >>>> Modern@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/modern > >>>> > >>>> > >>>> _______________________________________________ > >>>> Modern mailing list > >>>> Modern@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/modern > >>>> > >>> _______________________________________________ > >>> Modern mailing list > >>> Modern@ietf.org > >>> https://www.ietf.org/mailman/listinfo/modern > >> > = From nobody Wed Jul 1 07:41:28 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB821A8AB7 for ; Wed, 1 Jul 2015 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfCTKWjyVaRT for ; Wed, 1 Jul 2015 07:41:25 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id DE84E1A1BD1 for ; Wed, 1 Jul 2015 07:41:24 -0700 (PDT) Received: (qmail 6107 invoked by uid 0); 1 Jul 2015 14:41:24 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 1 Jul 2015 14:41:24 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id n8EL1q00j1MNPNq018EP4L; Wed, 01 Jul 2015 14:14:32 -0600 X-Authority-Analysis: v=2.1 cv=UNFOQkvy c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=n2U0tujJ36yO2MQ-XNUA:9 a=oj-4RKB5DX_CKNKP:21 a=tCyNzIPl7cvXAgfE:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=IrkgYYSrDA6FRLgNyPunTgU40czg0bMcZSxLgguzqP4=; b=dp8+qOWMPacHngohlIDAMrFRIvtdC6aeGiwhJlxFmUUHb6AOTfCkw0B99ASCS2d0zdppbHsCzW48dEM/5aHJUq5WQets6/1J/e7r4PHmdPIU8U5IpWvbDz7clZz2vPP+; Received: from [100.36.26.202] (port=49517 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAIsy-0001t4-IB; Wed, 01 Jul 2015 08:21:12 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Wed, 01 Jul 2015 10:21:08 -0400 From: Richard Shockey To: Henning Schulzrinne , "DRAGE, Keith (Keith)" Message-ID: Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:41:27 -0000 Please fix one thing first. MARTINI did one thing and did it well. We opened the WG and closed it down in record time. Discussions of device configuration frankly will go no where. Been there done that. Vendor specific solutions have dominated that area for some time and will continue to do so. See RFC 6011 for another example of IETF epic failure. No ENUM did not fail. e164.apra failed. Contrary to popular opinion. The protocol is widely deployed is countless carrier networks in private carrier specific configurations. http://www.sipforum.org/content/view/311/253/ I don=B9t think number management will go very far at least for years. Not because of regulatory concerns its just that the cost of the OSS/BSS systems in global carrier networks are so expensive and modifying them would cost more that the current US LNP database and no one is going there ever again. I could say some very very uncharitable things about the certain national numbering advisory committees but ... Not to mention there is ample public statements that the incumbent carriers have no intention of spending one penny on anything involving reconfiguring existing TDM networks that continue to dominate the global voice market. There is one thing that would be very useful. A general purpose query response mechanism for STIR public keys. RFC 6116 and SIP Redirect have generally outlived their usefulness for countless reasons. Public key management and retrieval could deploy very quickly in modern SIP and mobile access networks (aka VoLTE) and actually solve a global public policy problem. If the mechanism works then it might possible to fold other use cases and numbering meta data into the structure as the voice networks evolve.. Of course it would be nice to see 4474bis finished up first. < hint Cullen :-) > It might be useful for some folks around here to consider the actual reality of how carrier real time networks work not to mention the issues of CAPEX constraints on what is actually possible to deploy. On 7/1/15, 9:29 AM, "Modern on behalf of Henning Schulzrinne" wrote: >Indeed, it would be interesting to see whether and how Netconf/YANG fits >the requirements. I'm sure somebody will propose using DNS TXT records... > >Henning > >________________________________________ >From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] >Sent: Wednesday, July 01, 2015 8:45 AM >To: Henning Schulzrinne >Cc: modern@ietf.org >Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > >So my question still remains, given that this is significant data >associated with the number, rather than just the number itself. > >How do we distinguish this problem from either device configuration, or >network management, for which a number of solutions still exist? > >If the problem is not distinguished, then why are the existing device >configuration and network management solutions not appropriate? > >Regards > >Keith > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 07:43:58 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB6F1A8AD1 for ; Wed, 1 Jul 2015 07:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 307kLOCdWaIs for ; Wed, 1 Jul 2015 07:43:50 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 96C661A8AB7 for ; Wed, 1 Jul 2015 07:43:50 -0700 (PDT) Received: (qmail 9519 invoked by uid 0); 1 Jul 2015 14:43:48 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 1 Jul 2015 14:43:48 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id n2DP1q00Q1MNPNq012DSeV; Wed, 01 Jul 2015 08:13:27 -0600 X-Authority-Analysis: v=2.1 cv=ALgDonD0 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=Z80JlwQ0AAAA:8 a=VAMm1qzQAAAA:8 a=nN100iy96jVM9hqYMOUA:9 a=ZOafdQoZHWSwulyc:21 a=tBFShBQ02QdFjMv2:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=GfNEVghPTYhg0mYW+sAVS0FUbXNcVWAgtOjUaM+0Rhc=; b=lMPPrjw4mnCogmHCQHVvGiw/zjRJHqCmNhJrV9jZkF17ebOJGAIDGQFuWm1v1LK9ZFjTvyCn76yjE1xpiQRXv9+eO9z5sZw5bOHDEES1+jMHcIbQXJZcAbcxNFbcj73+; Received: from [100.36.26.202] (port=49518 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAIvQ-0003v6-32; Wed, 01 Jul 2015 08:23:44 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Wed, 01 Jul 2015 10:23:39 -0400 From: Richard Shockey To: "DRAGE, Keith (Keith)" , Ben Campbell Message-ID: Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B69737DD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69737DD9@FR712WXCHMBA11.zeu.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:43:57 -0000 Thank you Keith. I completely agree. This charter it totally out of control and the way this WG was formed isn=B9t too great either. On 7/1/15, 10:08 AM, "Modern on behalf of DRAGE, Keith (Keith)" wrote: >Yes, but the problem is that it appears that the current charter is so >widely scoped that any issue that any network management issue involving >a telephone number falls within the scope of the charter, whereas >existing network management (or device configuration groups) should cover >network management problems. > >The charter should be revised to be more precise. > >Regards > >Keith > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 01 July 2015 14:10 >> To: DRAGE, Keith (Keith) >> Cc: Henning Schulzrinne; modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, >> Ordering, Distributing, Exposing, & Registering telephone >> Numbers (modern) >>=20 >> On 1 Jul 2015, at 7:45, DRAGE, Keith (Keith) wrote: >>=20 >> > So my question still remains, given that this is significant data >> > associated with the number, rather than just the number itself. >> > >> > How do we distinguish this problem from either device >> configuration,=20 >> > or network management, for which a number of solutions still exist? >> > >> > If the problem is not distinguished, then why are the >> existing device=20 >> > configuration and network management solutions not appropriate? >>=20 >> (no hats) >>=20 >> It's not unreasonable that the working group, after >> considering requirements, could decide that an existing >> solution was appropriate. >>=20 >> > >> > Regards >> > >> > Keith >> > >> >> -----Original Message----- >> >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >> >> Schulzrinne >> >> Sent: 30 June 2015 19:50 >> >> To: DRAGE, Keith (Keith) >> >> Cc: modern@ietf.org >> >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >> >> Distributing, Exposing, & Registering telephone Numbers (modern) >> >> >> >> I think of the phone number as a key into a logical (not >> necessarily=20 >> >> physical) database with a variety of fields (and a change >> log), some=20 >> >> that are near-universal and others that are highly-specific to >> >> countries, use cases or even companies. We do the same for domain >> >> names, e.g., technical and administrative contacts or for >> DHCP, where=20 >> >> an IP address is associated with a set of service records >> (e.g., for=20 >> >> a SIP proxy, LIS or LoST server in our technical neighborhood). >> >> >> >> Much of that information exists already and is in the AT&T >> and Tropos=20 >> >> APIs, the LNPA or LERG. Examples include: >> >> >> >> * OCN/carrier code (some kind of assignment identifier is probably >> >> unavoidable) >> >> * number state (available, locked, etc.) >> >> * reachability (URLs) >> >> * cryptographic keying materials >> >> >> >> All but the first and maybe second are likely to be optional. >> >> As usual, there would be suitable extension points, e.g., to >> >> accommodate storing 911 address information that only >> makes sense in=20 >> >> certain relationships (not for the LNPA, but for a >> carrier-customer >> >> relationship). All the usual stuff applies that the >> veterans in this >> >> group do by rote: IANA considerations, privacy considerations, >> >> security considerations, ... >> >> >> >> Henning >> >> >> >> ________________________________________ >> >> From: Modern [modern-bounces@ietf.org] on behalf of DRAGE, Keith >> >> (Keith) [keith.drage@alcatel-lucent.com] >> >> Sent: Tuesday, June 30, 2015 9:50 AM >> >> To: Adam Roach; DOLLY, MARTIN C >> >> Cc: modern@ietf.org >> >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >> >> Distributing, Exposing, & Registering telephone Numbers (modern) >> >> >> >> First of all, Jons presentation has no status (it was one >> of a number=20 >> >> of presentations made at the meeting as to a single >> individuals view >> >> of what might be useful); what matters is the charter. >> >> >> >> However what is clear to me is that we have no consensus >> agreement on=20 >> >> what this group is meant to be doing or what the charter actually >> >> means. Otherwise this discussion would not be occurring. >> >> >> >> At the simplest it appears to me that people were stating a data >> >> model where a telephone number is associated with a >> specific owner,=20 >> >> and nothing more than that. >> >> >> >> However if you dive into various people's proposed use cases, it >> >> appears that more than that is envisaged. So for example >> to run any=20 >> >> enterprise system, that telephone number would need to be >> assocated=20 >> >> with various other data either: >> >> >> >> - in the end device itself, that controls how that >> >> telephone number fits with the functions that the end device >> >> provides, any security certificates, or relates to other >> identifiers=20 >> >> in the device; and/or >> >> >> >> - in some server belonging to the enterprise where the >> >> end users service policy is policed, and added >> functionality may also >> >> be provided. >> >> >> >> Now the first bullet above is device configuration, and the second >> >> bullet above is network management. >> >> >> >> So I believe some people are talking as if the problem MODERN is >> >> meant to solve also includes device configuration and network >> >> management, as I have described above, and that is certainly >> >> considerably more that a simple allocation problem. >> >> >> >> So which is it? In this new protocol, what data model will the end >> >> point of the protocol end up with? >> >> >> >> Keith >> >> >> >>> -----Original Message----- >> >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> >> Adam Roach >> >>> Sent: 30 June 2015 04:27 >> >>> To: DOLLY, MARTIN C >> >>> Cc: modern@ietf.org >> >>> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >> >>> Distributing, Exposing, & Registering telephone Numbers (modern) >> >>> >> >>> We discussed this exact use case in Dallas. From Jon's >> presentation: >> >>> >> >>> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06 >> >>> -29%2022.12.37.png?dl=3D0 >> >>> >> >>> It's also described in the charter. In fact, it's really the main >> >>> thrust of the work: the charter repeatedly talks about acquiring, >> >>> managing, and resolving TNs. This is the "acquring" part. >> >>> >> >>> So now, as I'm reflecting on it, I'm a little confused about what >> >>> *you* think MODERN will be doing. Perhaps whatever you're worried >> >>> about isn't actually happening. >> >>> >> >>> /a >> >>> >> >>> >> >>> On 6/29/15 21:24, DOLLY, MARTIN C wrote: >> >>>> How is that applicable? Scope question? >> >>>> >> >>>> Sent from my iPhone >> >>>> >> >>>>> On Jun 29, 2015, at 10:16 PM, Adam Roach >> >> wrote: >> >>>>> >> >>>>> In this context, there isn't one. >> >>>>> >> >>>>> MARTINI was predicated on a continuation of having VISPs >> >>> do excruciatingly manual things like emailing -- or in some cases >> >>> faxing -- spreadsheets to their customers detailing number >> >> ranges. I >> >>> think I still have the one I got from our VISP back in >> the Estacado=20 >> >>> days when I was running our PBX. I can dig it up and >> >> forward it to you >> >>> if you really don't know how number assignment works at >> that level. >> >>> Basically, it's a lot of human reading and human typing. >> If you're=20 >> >>> lucky, you don't have to get a fax machine involved, so >> you can at=20 >> >>> least copy and paste. >> >>>>> >> >>>>> But emailing or faxing spreadsheets around is a brutally >> >>> primitive and error-prone way to get this kind of thing done. >> >>> I'm a little surprised it took this long for anyone to make >> >> a serious >> >>> run at some standardized form of automation. >> >>>>> >> >>>>> /a >> >>>>> >> >>>>>> On 6/29/15 21:00, DOLLY, MARTIN C wrote: >> >>>>>> Please explain the number assignment process >> >>>>>> >> >>>>>> Sent from my iPhone >> >>>>>> >> >>>>>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach >> >>> wrote: >> >>>>>>>> >> >>>>>>>> On 6/29/15 20:19, Cullen Jennings wrote: >> >>>>>>>> I think private network case is already happening. >> >>> There are more and more PBX that integrate with cloud >> >> providers such >> >>> as Tropo or Twillio to get phone numbers using a simple API. >> >>>>>>> And, really, ever since we ruled this out of scope for >> >>> MARTINI, it's been a pretty big gap in SIP PBX deployments. >> >>>>>>> >> >>>>>>> /a >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Modern mailing list >> >>>>>>> Modern@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/modern >> >>>>>> _______________________________________________ >> >>>>>> Modern mailing list >> >>>>>> Modern@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/modern >> >>> >> >>> _______________________________________________ >> >>> Modern mailing list >> >>> Modern@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/modern >> >>> >> >> _______________________________________________ >> >> Modern mailing list >> >> Modern@ietf.org >> >> https://www.ietf.org/mailman/listinfo/modern >> >> >> >> >> >> _______________________________________________ >> >> Modern mailing list >> >> Modern@ietf.org >> >> https://www.ietf.org/mailman/listinfo/modern >> >> >> > _______________________________________________ >> > Modern mailing list >> > Modern@ietf.org >> > https://www.ietf.org/mailman/listinfo/modern >>=20 >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 07:55:02 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5521A8AF3 for ; Wed, 1 Jul 2015 07:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ok4dbK0jPSH for ; Wed, 1 Jul 2015 07:54:49 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id E3F251A8F33 for ; Wed, 1 Jul 2015 07:54:45 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaA///BkTuAAFk6AP//wzCw Date: Wed, 1 Jul 2015 14:54:44 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:54:53 -0000 I don't think anybody is proposing that legacy TDM systems do anything diff= erent from what they are doing today. However, almost all of these systems = will transition to VoIP, in addition to the non-traditional providers that = are emerging (the ones Cullen has mentioned, among others). The transition = to VoLTE is on-going, as is the emphasis on end-to-end work flow automation= (NFV, SDN, and whatever other keynote buzzword you care to list). A number= of people have stated repeatedly that legacy interfaces will likely persis= t until the last TDM switch is turned into scrap metal and tooth fillings. = But in the numbering space, we've always had multiple evolving interfaces (= TCAP ROSE, SOAP and probably a number of proprietary web APIs, in addition = to "protocols" like ftp'ing spreadsheets). >From my limited experience, the notion that policy drives technology is too= narrow. Often, available technology options drive policy options. Thus, ha= ving more technology options enables new policy choices (such as more user-= friendly porting, better number utilization, competition, better use authen= tication [your example] or better NNI). The other way works, but it's usual= ly very incremental tweaking, like the NANC-initiated change order process.= There are exceptions, such as number porting, but they are tied to once-in= -a-generation events like the 1996 Telecom Act in the US. On a macro scale, this should be obvious: the availability of VoIP drove po= licy options; nobody said "we have policy needs, let's invent SIP". Henning -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, July 01, 2015 10:21 AM To: Henning Schulzrinne; DRAGE, Keith (Keith) Cc: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Please fix one thing first. MARTINI did one thing and did it well. We opene= d the WG and closed it down in record time. Discussions of device configuration frankly will go no where. Been there do= ne that. Vendor specific solutions have dominated that area for some time = and will continue to do so. See RFC 6011 for another example of IETF epic f= ailure. No ENUM did not fail. e164.apra failed. Contrary to popular opini= on. The protocol is widely deployed is countless carrier networks in privat= e carrier specific configurations. http://www.sipforum.org/content/view/311/253/ I don=B9t think number management will go very far at least for years. Not= because of regulatory concerns its just that the cost of the OSS/BSS syste= ms in global carrier networks are so expensive and modifying them would cos= t more that the current US LNP database and no one is going there ever agai= n. I could say some very very uncharitable things about the certain nationa= l numbering advisory committees but ... Not to mention there is ample public statements that the incumbent carriers= have no intention of spending one penny on anything involving reconfigurin= g existing TDM networks that continue to dominate the global voice market. There is one thing that would be very useful. A general purpose query resp= onse mechanism for STIR public keys. RFC 6116 and SIP Redirect have general= ly outlived their usefulness for countless reasons. Public key management a= nd retrieval could deploy very quickly in modern SIP and mobile access netw= orks (aka VoLTE) and actually solve a global public policy problem. If the = mechanism works then it might possible to fold other use cases and numberin= g meta data into the structure as the voice networks evolve.. Of course it = would be nice to see 4474bis finished up first. < hint Cullen :-) > It might be useful for some folks around here to consider the actual realit= y of how carrier real time networks work not to mention the issues of CAPEX= constraints on what is actually possible to deploy. On 7/1/15, 9:29 AM, "Modern on behalf of Henning Schulzrinne" wrote: >Indeed, it would be interesting to see whether and how Netconf/YANG=20 >fits the requirements. I'm sure somebody will propose using DNS TXT record= s... > >Henning > >________________________________________ >From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] >Sent: Wednesday, July 01, 2015 8:45 AM >To: Henning Schulzrinne >Cc: modern@ietf.org >Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering,=20 >Distributing, Exposing, & Registering telephone Numbers (modern) > >So my question still remains, given that this is significant data=20 >associated with the number, rather than just the number itself. > >How do we distinguish this problem from either device configuration, or=20 >network management, for which a number of solutions still exist? > >If the problem is not distinguished, then why are the existing device=20 >configuration and network management solutions not appropriate? > >Regards > >Keith > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 08:05:23 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071361A8F35 for ; Wed, 1 Jul 2015 08:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 zC3Zihmn8v-J for ; Wed, 1 Jul 2015 08:05:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906C51A8F37 for ; Wed, 1 Jul 2015 08:03:37 -0700 (PDT) Received: from BN1BFFO11FD052.protection.gbl (10.58.144.33) by BN1BFFO11HUB041.protection.gbl (10.58.144.188) with Microsoft SMTP Server (TLS) id 15.1.201.10; Wed, 1 Jul 2015 15:03:35 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1BFFO11FD052.mail.protection.outlook.com (10.58.145.7) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Wed, 1 Jul 2015 15:03:35 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t61F1tCw023372; Wed, 1 Jul 2015 10:03:34 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm3.corp.sprint.com with ESMTP id 1v9s363h1t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Jul 2015 10:03:34 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 1 Jul 2015 10:03:33 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 1 Jul 2015 10:03:33 -0500 From: "Gorman, Pierce A [CTO]" To: Alissa Cooper , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQs3fqEwQ50yu6z0i1W6uAK8HRwp3Grskw Date: Wed, 1 Jul 2015 15:03:33 +0000 Message-ID: <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> In-Reply-To: <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> 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.29] Content-Type: multipart/related; boundary="_004_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD052; 1:t+GijLjI9Dh5JBE0EASDNyxXt+RsphC3wuSlTEzKBNgZQzxvB8jI9/I3nGNT3uwclsIdddN4VCZPh8dr6idiz6TfHTivBPVmb+lVG9MK3dg3PyJK49kRRcbEFWMP8DrDVG4HR78/Ox5xJV8P0g07HNzpGojQYxug+0OHWHsDY5WNqTfsBwDBGYluNnQj/UXW7BnkuwiPqwVb9B/8SK5ZTDZ09hZT83W6f/e9iypSxLXWPlge7gp7NAB4+v2S0jBR/L3QjAgAJr4wHxG0pYRfiGwp8o7Tc0tWIkiIv+T8OAQs7W8Wy1xF5kpAiM8z//Oa X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(448002)(52044002)(377454003)(189002)(199003)(16236675004)(106116001)(108616004)(17760045003)(33646002)(19627595001)(19617315012)(106466001)(2656002)(86362001)(575784001)(19625215002)(5001960100002)(107886002)(5250100002)(24736003)(189998001)(5001770100001)(2900100001)(2950100001)(92566002)(2501003)(18206015028)(67866002)(99936001)(50986999)(54356999)(76176999)(102836002)(62966003)(15975445007)(77156002)(5003600100002)(84326002)(85326001)(512954002)(66926002)(19300405004)(46102003)(87936001)(19580395003)(6806004)(19580405001)(30436002)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB041; H:plsapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB041; 2:0DY+4GpXH/pvGBtjWOA3rG35bWIvUaOO9Rhqs+m8H85twowCV1TJcgLM3v/2zfew; 3:8iF6GZp8azifjBPGfgC2sugXraL1z/fisiginZG6bDuXf446zRkHnfsMsPZoyZl0xwHJY4RH/ScaWwTPio7wRzrWx1sRVVeAGaEyuZOQlooIZy2HC8600UI74C7ufSpyxk25AGfaM//HHhWiPWmVX2XnXJmQEVTrF9oHz9fBJAnZhSPPt+arOZc+AnQ+lzjPgWBHxkfZVpJpJI6jMtoXtCReCYbNM9olLS3TgTeqyNREPCyIM/CtGz/WQvNAjwkG; 20:Q17lNeaszH5hAsos//DKS6X4dlbVH/B9QAPqwHfos1hMkQ3sfR31SwIggbUBQOSskDsjkf8QsqS4/QfSBUBRfOWKW1y/S2FogR74QCHqVGb/cntrhRJfDJIsejBmZtdclbIoILqHoqqshqRJZ8mCDtXu10TKSYCfGdw3yEVa7kLNIXJlVmuZOscBaMovrBd3CldFXql66ZrUOKcObhxnOBUBP8GtId3RGumYJnx9L615xtUIGq16lcIXj1FJJmIQ; 4:9FVTjSW/RMXQ5qURi6BdOlx+EW4aqgeeQ1vkEs2HqVU4E+n/lIL/2/sjXga5fPsn8ssId8JTFOYnVCKcTl75sPeFyvb1ezS6o1MXhs+oYfDqMOTovKZsD/2nVfr1YIrkZfCwiDsE2YCNYZFhwIWyIcxU+gcYrV6GQhobJGu/8Xn+lFw589sygJikxX+3S/Qkua1s+7BzNirU0AZ7YByvekoHm3eHcD8F215s07tXRz7rRk44+Sby9QeFUphcKYAQKspTk0502G13IJ6XvVQyUGCisx4CyWjktVltnuGv0nE= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB041; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB041; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB041; X-Forefront-PRVS: 0624A2429E X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB041; 23:1utbGKLXSdVdwKDjsorT/UcFBNT4xE1m2A19e3y?= =?us-ascii?Q?RY+V6nqoiVrsdrKUbzhy+ROd7RZB6ooGnooTAX2U+Ty9w23Mn10a+ak1SvYO?= =?us-ascii?Q?fMdJInAoS+Gel1mqaK3QcP1566iyqwCy3CxvcpW9oevnlEoO/HSjZ5DeSl7B?= =?us-ascii?Q?8zJ9ZPCDnkM5OaeJwQRk/rQrVGv9u5rVdL2HfK2P+SAlLnakZpGNDy1Ab/MP?= =?us-ascii?Q?noM0TBZ4cPhdA2AjzaHdylXTFjGS6HD33N40Vx904No4z3IKVnFCevdLYrw2?= =?us-ascii?Q?4OUpRRvyVD3NLAFvOVDkZXIXJTvwAEe4zS1oAQqHTXAVQWfqAvDwh2nnT2/T?= =?us-ascii?Q?WnQ+0pBjQQnTJH/dJQuuj9w1w0x5ocOw4AJ4oJO2QSLk3cLsmzLWaxNwK1PC?= =?us-ascii?Q?j68jpWrBJvBtck2RP90kyI/7NLrqCHqJabA7PYMHadEy4BOWoTq8G5YU06h+?= =?us-ascii?Q?OF5k6+GtRToLO35v/kq5HVACyh0UlG9ENZSzk6enAkGtP53uxN5YWjzhns7s?= =?us-ascii?Q?D7fyePtGU0R2hLnGh8WTlA73X1TOJm6zsbRJGnZY5Nb49Zvz79xEN7a+C5dD?= =?us-ascii?Q?ofjgVus1sAvpk7CXzIDCGgmHCr0xXwc0Th3ntbURUprwI4tkubpe0LDMSNLM?= =?us-ascii?Q?Ktoifw53us62u04d8XJ8q2qhuXYoumpsLILCvSQzOqI0tTBGNcq3q0r4D9oQ?= =?us-ascii?Q?fzKv1j5yxnrx/JHTAYYWmYiU9NsSNxyt7mJTjjvk80bJRigWF+J3asq+JeIZ?= =?us-ascii?Q?70M2pi4g6+92aGyqr3o20deoztIylvo1P60RQvIF/XDHkdZUSMCFp2Gz6H6u?= =?us-ascii?Q?j4PqgVojj4FBSwsCpioRQkx7G9gOfkiP4YuUVXA+W5+YIj6eYwOu8vDAV/V7?= =?us-ascii?Q?5XE1aXbUToQEc7xrFFTsrWmnZ4JrBrespbdNEyqN+VBb7wF+VptZ8UljzFE8?= =?us-ascii?Q?cGwt5ki948VbxLlF39/EA3ZRgASrX9UJfYmqshJY2tdeYVRl2OomyxpDEdKk?= =?us-ascii?Q?4nU3Ch7azhLMljL3LBYEPOD1XDrDBkjEaxLlsT1tG3guDFP1a1xRBXYBLF1a?= =?us-ascii?Q?fJS/dXsddAKKoEZxjdgpScRAab3m3pAEdnkF8Q1JS2OCmcJq+uXouCA8H1fv?= =?us-ascii?Q?cwWHS+tWu3/2xUFQXlhvALK2le7yMbHgu5I6TpQQ46ojDIsrIIxMxi5fu/kh?= =?us-ascii?Q?j/EiG0jm75f/8SbTJuMcttXT+GBBMOGOKIUfTXuR8OdO4Z6DpZ4U5RAhUK6X?= =?us-ascii?Q?B+/gRH8U17MmjzpgJFxVdLJ2SagGQVO3njWw+tE8C8uFcoZvVcYXnkHus/dd?= =?us-ascii?Q?IIri2ICdFXHCPnoGcNPiglURfOuzsRoYjcLicdTJ5TRee?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB041; 5:ye51q7FGVEjEy50Yvwp7rqBeT1ni4hbTjAwEE95HLVLo10+igmM61DffK3DDJaCHYReW/qwlwbV/mvVRyPpcji4HRWL0L+2kD0LQuTykT13MZU14Hg5eRxqgX9pqFG3Gv7r6BORl9ox8TtX8hsWDkQ==; 24:wHpZhN+YuLyCZop7ZZUGNepPrkUbS5sGNuY8Xz3Ar1zoTgn4R/349mo9KN/kmpo6DyJiqD9aY+RiF/XtGkKfnxcx5s3IpjTN9QZUCI3fHJE= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2015 15:03:35.5160 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB041 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:05:22 -0000 --_004_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_ Content-Type: multipart/alternative; boundary="_000_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_" --_000_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alissa, I've admitted before, I'm a novice at IETF procedures. Your repeated use o= f the phrase "rough consensus" as a conclusion of fact caught my attention.= I wondered, is there any IETF accepted definitiion of "rough consensus" t= hat Alissa and others are adhering to that I'm just not aware of? A little research turned up an IETF.org document based on RFC 6722 Section = 4.2 going into some detail on the topic of "Getting Things Done in a Workin= g Group" at URL: https://www.ietf.org/tao.html#getting.things.done I've copied-and-pasted the sentences from the beginning of the section that= I think are particularly relevant to understanding the IETF "consensus" vi= ew on the definition of "rough consensus". "One fact that confuses many novices is that the face-to-face WG meetings a= re much less important in the IETF than they are in most other organization= s. Any decision made at a face-to-face meeting must also gain consensus on = the WG mailing list. There are numerous examples of important decisions mad= e in WG meetings that are later overturned on the mailing list, often becau= se someone who couldn't attend the meeting pointed out a serious flaw in th= e logic used to come to the decision." "The general rule on disputed topics is that the Working Group has to come = to "rough consensus", meaning that a very large majority of those who care = must agree." "Rough consensus has been defined in many ways; a simple version is that it= means that strongly held objections must be debated until most people are = satisfied that these objections are wrong." There is some more verbiage related to the use of a Working Group Last Call= (WGLC), but it isn't clear if this is before or after chartering. If its = supposed to be done before, we skipped it I think. The Tao is not a legalistic document based on rigid parlimentary procedures= and there is what I will call a power of fiat within the IESG and the WG c= hairs, meaning they can basically ignore the definitions given above. I can fully understand the anxiousness of many participants to end debate a= nd just move on. Code prototyping has already happened and available for r= eview (based on request only and an undefined approval process). Regardless, I have to ask, using the definitions of the IETF Tao, on what b= asis can it be claimed that "rough consensus" has been achieved for the MOD= ERN charter? From what I can tell it was the power of fiat. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com [cid:408000_086801428601145001@pvmxe13g01] From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: June 30, 2015 4:01 PM To: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) I'd like to ask that each person participating in this discussion remember = to be respectful of one another's points of view and focus on constructive = dialogue. If you feel that you're wasting cycles on the current threads the= n feel free to change the subject to something more productive; likewise if= you feel someone else is wasting your cycles, don't feel compelled to resp= ond. To review the process that got us to the current point: The conclusion from the BoF in Dallas was that there was rough consensus in= the room in support of forming the WG but that the charter and problem sco= pe needed refinement (feel free to review the minutes: http://www.ietf.org/= proceedings/92/minutes/minutes-92-modern). That process of refinement took = place on this list over several months following the BoF. The charter was p= ut out for review on June 12 with comments requested to be sent to the IESG= by June 22. The IESG considered the two ITU-T related comments received (b= oth after the deadline) and issued no blocking comments on the charter but = asked that edits be considered on the basis of comments received. There wer= e no other comments received or indications provided to the IESG about the = readiness of this work for chartering. I'm still working on edits (Richard = Hill pointed out that I missed his suggestions) and milestones are in the w= orks as well. Thus this WG is being formed according to the usual process. Alissa ________________________________ 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_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alissa,

 

I’ve admitted before, I’m a= novice at IETF procedures.  Your repeated use of the phrase “ro= ugh consensus” as a conclusion of fact caught my attention.  I w= ondered, is there any IETF accepted definitiion of “rough consensus” th= at Alissa and others are adhering to that I’m just not aware of?=

 

A little research turned up an IETF.org= document based on RFC 6722 Section 4.2 going into some detail on the topic= of “Getting Things Done in a Working Group” at URL: https:/= /www.ietf.org/tao.html#getting.things.done

 

I’ve copied-and-pasted the senten= ces from the beginning of the section that I think are particularly relevan= t to understanding the IETF “consensus” view on the definition of “rough consensus”.

 

“One fact that confuses many novices is that the face-to-face WG meetings = are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also= gain consensus on the WG mailing list. There are numerous examples of impo= rtant decisions made in WG meetings that are later overturned on the mailin= g list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used t= o come to the decision.”

 <= /o:p>

“The general rule on disputed topics is that the Working Group has to come= to "rough consensus", meaning that a very large majority of those who care must agree.”

 <= /o:p>

“Rough consensus has been defined in many ways; a simple version is that i= t means that strongly held objections must be debated until most people are satisfied that these objections are wrong.”

 <= /o:p>

There is some more verbiage related to = the use of a Working Group Last Call (WGLC), but it isn’t clear if th= is is before or after chartering.  If its supposed to be done before, we skipped it I think.

 

The Tao is not a legalistic document ba= sed on rigid parlimentary procedures and there is what I will call a power = of fiat within the IESG and the WG chairs, meaning they can basically ignore the definitions given above.

 

I can fully understand the anxiousness = of many participants to end debate and just move on.  Code prototyping= has already happened and available for review (based on request only and an undefined approval process).

 

Regardless, I have to ask, using the de= finitions of the IETF Tao, on what basis can it be claimed that “roug= h consensus” has been achieved for the MODERN charter?  From what I can tell it was the power of fiat.

 

Best regards,

 

 

Pierce = Gorman

Core Networ= k Planning

O: 913-439-= 4368

pierce.gorm= an@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g0=

 

From: Modern [mailto:modern-bounces@= ietf.org] On Behalf Of Alissa Cooper
Sent: June 30, 2015 4:01 PM
To: modern@ietf.org
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Dist= ributing, Exposing, & Registering telephone Numbers (modern)=

 

I’d like to ask that each person participating= in this discussion remember to be respectful of one another’s points= of view and focus on constructive dialogue. If you feel that you’re = wasting cycles on the current threads then feel free to change the subject to something more productive; likewise if you feel s= omeone else is wasting your cycles, don’t feel compelled to respond.<= o:p>

 

To review the process that got us to the current poi= nt:

 

The conclusion from the BoF in Dallas was that there= was rough consensus in the room in support of forming the WG but that the = charter and problem scope needed refinement (feel free to review the minute= s: http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That process of refinement took place on this list over several months fol= lowing the BoF. The charter was put out for review on June 12 with comments= requested to be sent to the IESG by June 22. The IESG considered the two I= TU-T related comments received (both after the deadline) and issued no blocking comments on the charter but ask= ed that edits be considered on the basis of comments received. There were n= o other comments received or indications provided to the IESG about the rea= diness of this work for chartering. I’m still working on edits (Richard Hill pointed out that I missed h= is suggestions) and milestones are in the works as well. Thus this WG is be= ing formed according to the usual process.

 

Alissa



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_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_-- --_004_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5171; creation-date="Wed, 01 Jul 2015 15:03:33 GMT"; modification-date="Wed, 01 Jul 2015 15:03:33 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAU8AAAA8CAYAAADmDDgpAAAT+klEQVR42uydCWyU55nHU2krVRtV mkqrXVW7ap22q12ttqvpVlXVNGldqWk4kmLCEcAcA76wx/PF5KIhJEwIBBIIDEm4CZlwXwnmCkc4 hvtwTIbLHMHGYDAYbBgwYGzAs/8/+l766t05GNsxE/tB+on53pnvnO/7zfM+z/t9fgT/AoIgCELC PBIWBEEQEuYRryAIgpAg4XBYEARBSJB2fwAEQRBEnoIgCCJPQRAEkacgCILIUxAEob3T7g+AIAiC yFMQBEHk+fC4XfGDFOBo78dBEASRZ0JQnCAAvO39WAiCIPJMVKBOEAJBkNLej4cgCCLPRASaCsK2 RJ3t/XgIgiDyTESgBUqgEoEKgiDyTEyghbZAg8ChtfuBq70fH0EQeQqxCkjltkD9WruLbd+qQM92 +R74B/AD8Cj4IXCAfwL/DH4M/hX8BPwM/AL8B/gv8EvgBP8LfgN+B34P/gBSwZ/BX0BH0Bk8C7qC bqAn6AX6gv7ABTJANsgFbuABL4CXwCtgKBgG3gAjwFtgFBgD3gXjwPtgIvgQTAZTwXQwC8wGfjAH zAcLwWKwFHwOCsFKsBp8AdaDL8EmsBlsBdvBTrAb7AVFoBjsB0FwCBwGJeAYOAFOglJwCpwGFeAs qATnQRW4CKpBDbgCQuAaqAU3wE1QB26BetAAboM74C5otAnbNLLd5o79+Xp7/jpw015urb2eq/Z6 L9vbcQlU2dtXaW9vBTht70epvV/H7f0ssff7IAjax6PYPj57wC6w0z5+Aft4bgQbwFqwBqwCK+zv YhlYAhaBBWAu+BR8Aj4GM8A0MNn+rn1gAhhvnwtj7HNjpH2uvGGfO0Ptc+kl+9zyADcYDLLBIOCy z8l0+xztYZ+zafY53Al0AE+BP4E/gifA4+C34NfgV+B/wH+D/wT/Dn4OUsC/2dfVv9jX2Y/s6+5R +zr8PvheuxdjggWksE2akqreJvIUeYo8RZ5C/PynQ3Xp9TaRp8hT5CnyFCILNKC674ZQicuIVL0i T5GnyFPkKfy9qx4CYVuQKZo8CyPkQwPAIfIUeYo8RZ7tHuY3lRg5rRWTQtpnvJpUAyJPkafIU+Qp AAjRZ4sxFfg1UaYY8lS4RJ4iT5GnyLPdow1fKlSRqE1qFHkWijxFniJPkWer8thjP0sBqcCRpLdv PqFJssAoLCkCxnw+4BB5ijxFnm1MnhBVGvCCgEah3ZbSiuJMA2GbUEuv25ayD7iaKFAv8Gt5T28s eRrvlQOnyFPkKfJsA/KERJygHIRjkNqK8iw01l3QgssOaMv1NnP40gJDniFDnj4jWlWEgEPk+eDy XPCxFVw42zrQ0vI8V5xRMeOD/NDMDz1XwTWR57cnzzWLrPnTJuWvbCvyVOIMgXAcHK0ozwJj3c4k lKcTLDDGf4YNXHrUaVCQjPJ847XsTx9//Ilw/349i7Oz0nfw9cg3cxa3tDw/merZ8t6ovP3g69Ld OcuUPMePyTv0/pi8wxPGuo+U7claR3muWmjt43aQRbOtQy0pz33r889zuYrmynP2FM9d0EiUPC8E B4axv/dge3uV56gRg7cP6P/86bYhT1MmwOyiM+JUkV9roqUP0jidZPJUAn1Sdc9VdGmQorWbeJNN nri4vVmZ6VspkezM9O3Pde1yRskTEdqLLSnPjEF9KpWwNi73rFPy1EW2daW1jfK8XNJvbb++Pa92 7tTp9oHN7l3JLE9jWY0kuMkd1ttFnm1AnpRkpO5xspGs8iSaPNMMOQbt94NR5Jmi35UEHA9bnvoF brLEb1F+bohgxPC/Za19c1j2+rFv566E4CZ5h+dsemt4zuapE/OXK3lePOCaOPFd96bR3sE7wa5Z H+Wvrz48YAYvLERfmyHmWrXsoS9nnhz3Tt4BRJ0H9XUOezXz9PxZ1v6tKz1cRtnrQ7PObl/tKSrf m7Xjg3Husg/Hu09hu46dKcos+uh99xlQsfRTq1SX59mvMkqwXVVTffkX5860LhzdnnsKXcea6ZPy LxfOsy6a8qzcP6hq5keeWnAdqYLaa8f71OjyPP/1wOsfT/bUg4bZkz23sW0NSp6MOvVlMdJc9InV iOMU1tsZfX69yX1XyZPL4LIIl4t13FDyXL3QuoFjVwduVu4feLl4g/sKt0/J8+rxPudWzLeqsT9X 5s20qvEjV055ni3OKMU+XyrZlnvSlOfkCe5zu7/wlCh5rltqleBYloNTB7fk7dXlyXQJjz+2dxN6 AyU4/pvZMyjbk7NCl2fNkf5z3x2VW7xhmbVSyRPfzap33srdze//2PbB0yLJc84Ma96IYdlfgg2f zbGmKHm+PjRzzeJPrAmmPF8eMuizT6dZI5NBnqlNyWuy0AK8NinAAQpAQMPH9kgRpUJLGxTa87g0 qXsVMdbtVG1qGTZ+4DT200uM3G5AX0+Tc58g0hhPEiPqVOIMKdlyOpnliQt4utn+9NNP16nXiA5P UZ47VntmdujQ4Zb52Y4dOtbvXZe/eNDA3ufstrggdXAJEj6upieNc5/EBfyVmu7Ro2sdI1J9HqQC LlASu9d6TnTu3OmO/t4zz3S+LzhP/oA6U57PPvtMoz6NSPw2BHqZ8oTIbprbZ0fpjbUn+tRHei8n u6/ZpgTKeRqGvDCwMdL7yA/WUZ4Fluv+vr3gcTXoETKEVMX9IdyX53s+d5uv8QNBgR7ja/yoXdHl CbmVcn7KM3QsfZ9rQK/rnM7N6XcFYqvla0jrsJIntr+aUT/bu3VLu7F/o3vDc891uf63VzLLdHlC aNv4mW925czHj+Ss3r26XeK0y9Wrotfz3S7yNbavSpenle/6mu1903uW4nus5Gv+MFOevXt3P4H1 VOjyxDEZzs8kqzy9TYje0kBQTRuEzHyl8X6aMe2KtF2x1m1Mm6Rqwg7HoxkD5wOg0CgI/VSJ0SBo itOYz/kwc57q4pwyIX8S/8eJf0wVjCCWGl2a6oTX5Vl1wPWuLk6+1qcpTkQZBylS1danT/caSOpC VkZ6lbG8EKKW0mjyjAXl2bNH1/vroETz8/rf4Ot48qQw9TZGfcVf5tfqbbi4G/VpRG13TBG+WDAo jO3nD0DYbF+7xLqLiPRurGWe2JlzXZenmV7Ad3MnMyO9AdFnheq2Q2rXIakGyhORfA33W5cnegnV PC7sto94Pfsi3z8cyN2vuu3Y13vH+tTerICSZ6eOHRuYQlHddkae/EzNkX6LlTz5HeL4UtrT0Cs5 wO93z7r8+arbjmLf55xHyXPbKs9UTiNaXa267e7c/kU8ryhP9UON+cYreTKVhO29lCzddkcEiXjZ noA84xWbymPIM2TKLiF5xh8hEGwFeRYALyjXI0v9DiSzym6I0wTtjz7W2vLEhb84XuSpT6N7N5on PLtcujxxwa7TPwfxbQZbDCnMSyTnGUuejDrZbcd2VBmRW5k+bXdfS9B1r4olz+M7BvPiPM9uu2qj wNCNbNAFi67srbFv593RxZdozlNv47KwzHouW5P2LV2efA/H4sbKBVaI28m2LSusaj3nif05x3ZE +GcQgZbx9edzPBVKnpSlHZnv4WsIvNLMeXIe33vub5Q8+QOm5zwhzc8oVKZaKM+Tu3OWcp5lc6wN lCfFicJj0Mx5Ds7ue0LJEz+yY7Afs/WcJ1NBXI7KefLHGvPsojyRfsl76qm/3MT3PDeZCka+KBGj HzhjyNP8fJomZL8ZYRryNOctUAPiE5BnxFytue5WyHmmgrGGIJ+JIk5nHHEqvMksT0QZ36iC0fK5 1nRdniPfyAnEiwrRdVzRUvLMHdwvpApGqs3u2lWo1wNdvetUwYhSiSZPRnGqYMTcoi4tJbFYJCJP 5jzjLW/MyNwGfb2Iwq6rgtFXG9zV0eZT8uT+Mgod+nLGVcpTddmPbM09QnlGm9eUJ47/MbNgxG47 u++UJ1IDR5jDVgUj+3xZE69ghB+yBThnysx1K3m+/WbOEk5jX18dNzpvFl/jhzIrmeTpMMZVmgRA ShyBUV6xIlpfVHmagk5cnua6na0sTwf4SBPfa6A8ijhdnI7PP3ZtbXnuXOPJhdACaphS17S/nuZr XCQr2HUyI08UNYabkacpT+TTzqiCEQsHiK72gn2MPFtTnuTqsfSj8SJPdoMjyRP5u7u6xCC126pg ZHOHNEeeesEI1BPmWPX1YptCpjwRvV0uWu+u4n6ASnAO4qzA/p7g/qIgc97e/0OQXA1ykDdVtZ3t jNjx3R8EQeSq9+PYFoMidttjyZMFI84/Z7q1g5EmilB7dHliXzaa8kQBsEjJE9/DQn6OxUb+AKMn 844ZeaL4NYTRJs9Bjvxgtz0p7zDS8odxc5dmt/0BotNAFHn62ZaYPOOvuxXlaT4wpBz4miNO4H9Y Oc+83P5rePK+8uKgz5U8UW19T+U8eSJr0dhlJvrNnCcqvIVqOq3LX69ePDjgAxQgVjDvaUaees5z 03LPesrTrLZDPFuaIk9VLEo058lKNsRUo+c90WWvh/zr/z6ddZtDiii7WJEnq+zo0lKeZhTPsZ93 cAzvt32x2GKVvW6INfC+VDGioD6aPDkqQMlT77az2o7RBNWstlOe6O4etyV3Tv2oKHn26N71FuVp dttxjEuRk9wbS55gAfPUKnfNaruSJ9teGjLoqCnPLl2eDSl5QoRHsf7zsbrtYDD2f6M671gwSkZ5 mpGbP0bu0hRQYZTl+B5AngXNlKc/SeSpBsEPjyJO/wOK0wccD0ueiKim4KRfhojn9VdfyliOIUSF uAg9Sp64iObqElASNavtKEhcUG0mkPI1jvNEseKQ+R7lCSFfMavtTZUnhr6U29Nxq+0mRgRci2FC V81KvCHKu5QnpGAWjbhfEavtIGbXHUWqG9HkCSqHvZpVx/3hUCXKE9X3Co97wE22qcgTHEYh5n7+ tqIo45CSJ4ZSnbKLXaevHO274/S+zF3oGZxh24PIE0O9Avws0gLf6OM82buwv6utlw65JmO7ZjDf qReMcG7tZnEIxapxlCe2xc9pU544Bq+xjZFnsj8YxBwDGjQLOjEFlLg8U5spT2+SyDMEpoKQIc4n VRU+DuUgNZlvz+QgeURMPkRdX6BifhD5wcMc54mxlUtMeWKM53h1segg93iWQ5UoTwxnuVehNeWJ i2UdixHNleem5dZJChSjBi4w54eL9RrHeSJFcDaWPDF8pt7I/dWpcZ5IN9RiRMA94ZnFHg5Vojwx VIcRpSlPVtf/nzz5eXb3+Xmz4q+GKsWSJ6rslcgj3tDn5XAlNVRJyZMFI74Hidaag+Q5PlYf6sXX aqhSPHmit7DBTrusNQfJs2DE9/QUDrvtesGIkac+eqN7967nTHnivCtgG3OeSS9PsyvfDHkG2oM8 KT1bfjsiiDP4oNFmst/bjq72aP1EhzAKKU99nCejCf0OI3TZfZDGIrAEEciUSPe2I19XyJwnKriL 9HvbAyutAHOeTX0wCIoiJfrFqwbJQy5KzLxz6lqkB4Ogkl3NnCfGd16KdIcRutcc73iLRLu3HV31 RqLf2w7B3mtDV968w4jLqge3IOi6RO8w4lAl/ggw8mzqHUYq55nIHUb4vkvT+/S4HOsOI373jDyj PRgEIww+ZM4z2h1GiK5XsdvOavt3TZ7OZsgzpH+mDcvTB6bp4zhBp3gVdTUo/rv0YBBEeVErtJQo hDUxmZ6qxAKJvo1m9x1RzWl5qlLTbs/Ej90yVTD6Np+qhO+pGjcHfPmdep5nlPGRKZEFFP/BHm1Y npmGEPPiSDMECr6rj6RDN3Yehyoh4jjJghFBt3gnCiCjk/GRdOiynmHOj7BgRDDI+wqitTJ5JF3T 5Yl85zYWjCDRhd+WPNcv9YzCSIfjHKqUjPJUuUmvLSwncNiv/WZlPFbRxhSn2WVPUnmWgxS1z00Q Z4oWYfqBL14lXR6GLM/zlOd5trGnKsUhBBwJzqPmS0kyefpb4g4jSlDLaY4FgThd9FT5MxwiT5Fn +5JnADgSmcccXJ9k8nS2kDz9IASGxLrVErjkbxiJPEWebVOeacAX5U9vOB+kkq7N7zfni/VUpUhy TfCpSqnx1hGtEGbssw94EywSBcG4GNL0Aof8ATiR5/+1d8cqbYVxGMaHikMQMthCEZR2EaSIAYvN olSXdNIShEDoYOkgLQ5aRBQlCKKIQ4sQKliEQEtQUAxiJbjoFYiX0EsIvYK+wqN8HEhOBqfkHX6L aAzf+X+PJzmR43j6BnAxZ3/tgf8UKsufuPc1fd92x9PxdDwdT+EC0YL8rRPNhzNpx9PxdDwdT8cT vBRvGE3H0/F0PB1PxxOccV43iqbj6Xg6no6n4xng3kS1uGj+u0mm7jiejqfj6XgCMVe8Ww2f46w0 c/WceNbk9hHj+UQ6OXAJ6ZIkB7VbnnKgewhpr7wIYtrPgLxiWIaI6jBRfSNphmuUuI7LBAOYkXdB YKeIbFamJccQ5yOx/RgEd5bofpE5Nsa8fI3Ed5lNtCaFIMIbsilbsh2J8TeCvMtGLcqPIMz78lMO 2NwlNvov+S1lHAaxPpYTQnF6H26cE5MLwlIl5JfEXBQeoo4rXOOKr0Pfr5/DJY9X5fEv+H3nBOyM iJ3y/E7kmOd9JASNqBE2KfEH6oD12Gd99ohckfXble9B7HZkm+BtygbRW5cC4VuVFY7fkixybOc5 1nNE8LPMMhOfIjH8IHlmKcdsZZm1yUgYM8zmhLyVsSCQaRmR10RySAaZ/QHpD2L5UvoIZo88l2fS zf5KEs4E+69TOu7jafG31qjJbTOf0ySeM5Jq97Uza2VtvwANopmSipTEITQzx7PJl+nv230dzMzx NDNzPM3MHE8zM8fTzMzxNDOzOv4DIDV//HSVjucAAAAASUVORK5CYII= --_004_1aacdc5bbb5b4991961136b881bb842bPLSWE13M08adsprintcom_-- From nobody Wed Jul 1 08:49:57 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6FB1A90BC for ; Wed, 1 Jul 2015 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvN5LYxu7MHg for ; Wed, 1 Jul 2015 08:49:53 -0700 (PDT) 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 66B1A1A90C5 for ; Wed, 1 Jul 2015 08:49:53 -0700 (PDT) Received: from BY2FFO11FD011.protection.gbl (10.1.14.33) by BY2FFO11HUB048.protection.gbl (10.1.15.228) with Microsoft SMTP Server (TLS) id 15.1.201.10; Wed, 1 Jul 2015 15:49:48 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 1 Jul 2015 15:49:48 +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 t61FlVAo022385; Wed, 1 Jul 2015 10:49:47 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm1.corp.sprint.com with ESMTP id 1v9sfc3wwf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Jul 2015 10:49:47 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 1 Jul 2015 10:49:46 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 1 Jul 2015 10:49:46 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne , Richard Shockey , "DRAGE, Keith (Keith)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQtAwGFsqnRiPtXUKQIKMG+5M2QJ3HB3QA//+2IxA= Date: Wed, 1 Jul 2015 15:49:45 +0000 Message-ID: <5c33acdf2ec7436c9e8e645571453fa2@PLSWE13M08.ad.sprint.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.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.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD011; 1:yeXPlo/kjpsxmvr9ZDAnpvN5qJFT+30SFveoDyJDsKxD0govYiVE8u483PZQG8ajR2TgLieeZgRHX5YMYw+XCoZ+AqAC0YyO3oSX7UHYO0oEuuCmVkrLS3Zorz0uvTaMFS1EU7f4W0KVHZB5mM4u7UYiyB4kHOpVjyUKtLJb6TxNNLtxjTzI/MdgmiZq09NAwSiKkpHKHltR0QS+JOPO3v0BFOKBVRdcWaBXSVoensXsRGs/uCU+ljBCWD8C1PfJjZNDOeAsczcKlIxY/ofEMsYcHlaE/YFvQDSXzXb6v+PcO/If3T6iNib9sIP/SKW1 X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(448002)(479174004)(51704005)(199003)(24454002)(377454003)(189002)(24736003)(19580405001)(19580395003)(5001960100002)(102836002)(15975445007)(2900100001)(2950100001)(85326001)(6806004)(92566002)(5001770100001)(86362001)(50466002)(87936001)(2656002)(5250100002)(5003600100002)(561944003)(33646002)(54356999)(76176999)(50986999)(46102003)(108616004)(189998001)(23756003)(47776003)(106466001)(62966003)(93886004)(77156002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB048; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB048; 2:B6zwcP2xFYj1dMRN/NdRK+zLWh9VBtOcC4S0BU7BYVLEZQyAyba9E21P+dBQjv91; 3:L95pfKDw7G7kmmzE0FUVbaXRTeuiNgp5SjZL5OUAEQQXKCUJ5m0kQFtWc/AC21ZSt33XvwCGCcuEwfEpxInvYY3Gc6VAByDx+Oh42LdrLJGeZFIzjGYdQtyyN0HnmQzwV5l6hF+FC6ihvXuv8QDO2/fFHE0nhDqKprQbm2QYKvktJpTKyAaj5U17TzXMZKvvj6fI0ITphdOy5szto2gtpCQ8DwEZf87vGNHIpTL6R85QpfmE/Q/TOFoVbV5FyTYI; 20:EyuIubWXUwKwP86fEQvBp+TPEluT3G8iCaFexWcpHMfkRxE8pErtfBN8SMtLJjKBqSDrDP1xQrSRaxpZcI/yJk0rejivXhLXZubz3z5fNWPAhgXSTrJHqG4KHAnTDmnqO65mQR9ynfG6LM0fzraO4yuKpLka1peGW1xf4yEvjHO4uNLwZE1lOB1F8UbipdvGk22ZKC7s8kY3c3XhVj60Y8W1zpXwK6V4zqaboclskP15iOTreEsS7uw5wnxmvd5e; 4:Vg8ZoHlXc8Iv+cTQGmvkJZ44V84huyMmaL4aOvx9am0RuYbVSoVVc7bNLT7GdjB+VFZ0Vij5W9dgQlYeHGRkQTtr4Q5pY+uh8Lmm8Fgd35dxg9BYKZc62UCNm1ADbZwm/6uPha5Vw8fi8FKD66tM4mJz7jlpBYQ9cMPN7LQX747x8kDGjTvZjuGFw2ApPMaddhWfGryAEJYvHHK2oBLWPYDUQSRQGQdrorbh9iuvXmQHB2fe99T2LLIQuexqh+xCMgf8nW13M5EIEty9zASDdwnv1DDeQDWuB1tGUUXuCNM= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB048; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB048; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB048; X-Forefront-PRVS: 0624A2429E X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BY2FFO11HUB048; 23:4ZTzCW0D7S9wk9vVdOx0nd71zD76a2rulsU5W7?= =?iso-8859-1?Q?bi4xwQXg2HyrAV+pkF3CGKuq/o/h6UpD2O3caV1A6wsXNrVBqbq2icfc2e?= =?iso-8859-1?Q?jOANiaCpydkdf7Ll3clLghlPuWNP9Smf3T0/N9aTaBxXhUQ32qJluPt2Rl?= =?iso-8859-1?Q?RCziTwKOasKwd8ueunqDtW10leIHMsoj7v9pS31x0C8KLWOBN7VJIpkyak?= =?iso-8859-1?Q?YOSZN6Fc76654dppT0IlLhcF3yCbz+Q0+sifxNzenp9lLEUxJPSqI1Ldmr?= =?iso-8859-1?Q?kcwLVK+l7drkFd10E3lYl4nryi/FFLh2CHWxft9IeyXnyva25CMRMIsM/+?= =?iso-8859-1?Q?Pv+XKZObhQ97zOXcuRBYahZBu/myma82BDzi8Wtkn6Fu9nD9lVPC5BGGm0?= =?iso-8859-1?Q?4aGtBdpzyNDaFtpKX0EQIlhK7GCwDHI7ou3tlTPveQ99rprF7V7w6qHzke?= =?iso-8859-1?Q?oIgbuu6zw/cuwCPP7htVadymbzJxkpiZQzuxnY0RaeYn9P2WdhzWvNkzPO?= =?iso-8859-1?Q?dNmTm0A6UWquCsW/F+QEjGKnylVd7P6fhwsXCeIZufpnJuOY0B3KFs56pJ?= =?iso-8859-1?Q?ZMpSzMU3rsKP2pcFqzZQ3ujt+IXgpq9suDzyN49iYu044VSB5WevRzrxBB?= =?iso-8859-1?Q?xbNqqJZB0PVbXAoQr1rRploxhW0eRRqX3ehjgbNE68CyhoxIt6Akfy5xbu?= =?iso-8859-1?Q?ic+A1x1upsizLdVXirC14/OyxbBOOOtrn6hrppYPeDcKn3P1sqkoqmrW1k?= =?iso-8859-1?Q?jaC+ynoJiXSTGyv5f4bgnhqFavheMK3Ntm+yt5yf15gYE7Oh1kD8BPiRYO?= =?iso-8859-1?Q?9i45dVpFnQuwSLM6JehU70q30uqg/yjVpYr7U7xVax3iE1pDAToggMNn0Z?= =?iso-8859-1?Q?mZyh42OtXh3tOAyUsIZRKi0MZAM24YWCNnpTK7GeDuknxQwrhYq6eBfKnh?= =?iso-8859-1?Q?WKwhNbMp+1BQKsWbz8pjSMyO+Oaq//e69CyYz4EOIH9JMVpLsZylY7w+k9?= =?iso-8859-1?Q?8IhhuiUngy0M2frh/z5TrdRD4r2MPOvvB4AglH8wEsS8f6hZ2rEtlnVqgp?= =?iso-8859-1?Q?JvBuU/tlmPV7G/dCjvbZIIXXN3NHF+BACVpzYt/JxYfAIAl5jSPSGlUtId?= =?iso-8859-1?Q?M2HIUSmTGYs5gIZHjgCBdkCJc2Jw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB048; 5:TcEPb/5J173VMzQRzBss0K7twPOkF56ll08HQ1jebBfcoYtC6ZyWvvZS9Gx7fDob+lIMe/YVFctLkd8auMivXcr7B7suSu1GgH7BYy8zYXnAm/rCH2eQMZmGIpEbKKF/VoSN0lKa025oAl9Z57CoaQ==; 24:vqSXR31mwpcVSqhaFib6NqTkBSuTROigVo8ivc498t+XoNWPQnRX80oNO0FZAgZBMzJERegTrLQD1C5/FMZLwrOfLflQ7opHPWUC0lUYmX4= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2015 15:49:48.1053 (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: BY2FFO11HUB048 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:49:56 -0000 "On a macro scale, this should be obvious: the availability of VoIP drove p= olicy options; nobody said "we have policy needs, let's invent SIP"." SIP has certainly enjoyed the spotlight in terms of creating opportunities = for policy (and carrier-grade security products). It could be argued, howe= ver, very little policy specifically mentioning VoIP has been codified. Perhaps the most meaningful telephone number and routing information manage= ment changes voluntarily achieved were the addition of four URI fields to N= PAC, and a proposal currently under evaluation to do something similar for = LERG. These two simple changes may be sufficient within themselves to rapi= dly fascilitate an all-IP PSTN (in the US). Numbering and routing information management policy changes with respect to= non-traditional providers of VoIP and multimedia services are in-flight. I've already said folks will agree that there is useful work to be done if = that agreement is limited to how to automatically provision an IP PBX with = a range of telephone numbers. I'm not sure that requires a standard now or= will ever. But, if that is what was proposed, I feel more confident the p= roposal would reach more than "rough consensus". I will heartily agree with Richard's suggestion that a non-DNS and non-SIP = "general purpose query response mechanism" protocol investigation would be = valuable. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: July 01, 2015 9:55 AM To: Richard Shockey; DRAGE, Keith (Keith) Cc: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) I don't think anybody is proposing that legacy TDM systems do anything diff= erent from what they are doing today. However, almost all of these systems = will transition to VoIP, in addition to the non-traditional providers that = are emerging (the ones Cullen has mentioned, among others). The transition = to VoLTE is on-going, as is the emphasis on end-to-end work flow automation= (NFV, SDN, and whatever other keynote buzzword you care to list). A number= of people have stated repeatedly that legacy interfaces will likely persis= t until the last TDM switch is turned into scrap metal and tooth fillings. = But in the numbering space, we've always had multiple evolving interfaces (= TCAP ROSE, SOAP and probably a number of proprietary web APIs, in addition = to "protocols" like ftp'ing spreadsheets). >From my limited experience, the notion that policy drives technology is to= o narrow. Often, available technology options drive policy options. Thus, h= aving more technology options enables new policy choices (such as more user= -friendly porting, better number utilization, competition, better use authe= ntication [your example] or better NNI). The other way works, but it's usua= lly very incremental tweaking, like the NANC-initiated change order process= . There are exceptions, such as number porting, but they are tied to once-i= n-a-generation events like the 1996 Telecom Act in the US. On a macro scale, this should be obvious: the availability of VoIP drove po= licy options; nobody said "we have policy needs, let's invent SIP". Henning -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, July 01, 2015 10:21 AM To: Henning Schulzrinne; DRAGE, Keith (Keith) Cc: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Please fix one thing first. MARTINI did one thing and did it well. We opene= d the WG and closed it down in record time. Discussions of device configuration frankly will go no where. Been there do= ne that. Vendor specific solutions have dominated that area for some time = and will continue to do so. See RFC 6011 for another example of IETF epic f= ailure. No ENUM did not fail. e164.apra failed. Contrary to popular opini= on. The protocol is widely deployed is countless carrier networks in privat= e carrier specific configurations. http://www.sipforum.org/content/view/311/253/ I don=B9t think number management will go very far at least for years. Not= because of regulatory concerns its just that the cost of the OSS/BSS syste= ms in global carrier networks are so expensive and modifying them would cos= t more that the current US LNP database and no one is going there ever agai= n. I could say some very very uncharitable things about the certain nationa= l numbering advisory committees but ... Not to mention there is ample public statements that the incumbent carriers= have no intention of spending one penny on anything involving reconfigurin= g existing TDM networks that continue to dominate the global voice market. There is one thing that would be very useful. A general purpose query resp= onse mechanism for STIR public keys. RFC 6116 and SIP Redirect have general= ly outlived their usefulness for countless reasons. Public key management a= nd retrieval could deploy very quickly in modern SIP and mobile access netw= orks (aka VoLTE) and actually solve a global public policy problem. If the = mechanism works then it might possible to fold other use cases and numberin= g meta data into the structure as the voice networks evolve.. Of course it = would be nice to see 4474bis finished up first. < hint Cullen :-) > It might be useful for some folks around here to consider the actual realit= y of how carrier real time networks work not to mention the issues of CAPEX= constraints on what is actually possible to deploy. On 7/1/15, 9:29 AM, "Modern on behalf of Henning Schulzrinne" wrote: >Indeed, it would be interesting to see whether and how Netconf/YANG >fits the requirements. I'm sure somebody will propose using DNS TXT record= s... > >Henning > >________________________________________ >From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] >Sent: Wednesday, July 01, 2015 8:45 AM >To: Henning Schulzrinne >Cc: modern@ietf.org >Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > >So my question still remains, given that this is significant data >associated with the number, rather than just the number itself. > >How do we distinguish this problem from either device configuration, or >network management, for which a number of solutions still exist? > >If the problem is not distinguished, then why are the existing device >configuration and network management solutions not appropriate? > >Regards > >Keith > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Jul 1 09:18:29 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B314A1A914B for ; Wed, 1 Jul 2015 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRjjl3PTK-4B for ; Wed, 1 Jul 2015 09:18:27 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 B57C41A9147 for ; Wed, 1 Jul 2015 09:18:26 -0700 (PDT) Received: by qgeg89 with SMTP id g89so20922478qge.3 for ; Wed, 01 Jul 2015 09:18:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gVdcO7nWY+5dYs+boMFWpwXGRUGgxt4LajNG1VFbG4I=; b=SLGemQcyUyB8ZdAmeSjy5NT23+qZO6IKBwbXoc4/lMT91+CpalN3wjBE428GKxaf3c VjQtQzBqzPz9F0xo2GCn3vI5TUQ0IpaGsMnPXsgOBhiAzF0Rms3zsX9ydS/dr6GN3N2L jb38f2VZlrWeG8ABFggFKvNALnGdH/6PjWTwmAM2AdHjsZSyb5fHKXjNfpagO6LcRpkb ccbj5uX7NsjyKVSVfNkZf8/9dubEjDEruZXAltzp4uNUXLCGp6NolVi2GXuNN63WtHKe uQYUKIn+YbieThS5usmPO09VWw713mrwgmhzrtgj9L/7d38BdzF2tkUawBNZAkCyrIWp TeNA== X-Gm-Message-State: ALoCoQldEsVUKMvUbL6nRQ+IXTRBfyUAFMSJQPRM9LQV9LdCKc20g4qb2JCcC2rlyOxMfJLedbfX X-Received: by 10.55.15.144 with SMTP id 16mr55541194qkp.98.1435767505922; Wed, 01 Jul 2015 09:18:25 -0700 (PDT) Received: from [172.20.20.20] ([50.153.114.29]) by mx.google.com with ESMTPSA id j143sm1207564qhc.32.2015.07.01.09.18.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jul 2015 09:18:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: Date: Wed, 1 Jul 2015 12:18:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <40997198-9527-49E0-B038-4144F9FDC73D@chriswendt.net> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Ben Campbell , "DRAGE, Keith \(Keith\)" , "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 16:18:28 -0000 +1 Although i know it has always been part of the proposal for Modern, = I=E2=80=99m sensing a shift in conversation or at least more of a = segmentation for enterprise requirements vs. number administrator = requirements. Is there any sense that the charter can and does = represent both of these use cases, and there is any reasonable outcome = that there would be a largely common set of functionality for both? Or is there two explicit requirements, and in my mind very different = solutions, hence my previous question about the analogy to DNS and IP = address allocation. I would agree the enterprise requirements are fairly straight forward. = Entity A has a pool of telephone numbers they can provide some wholesale = or transit relationship for and Entity B would like to provision and use = those numbers. This perhaps could benefit from a standardized = interface, although i might argue that tropo and twilio and AT&T and = others can differentiate their services based on better or worse = interfaces (but that is a different discussion and maybe that=E2=80=99s = a higher level interface than what would be defined here) For the number administrator interface to those entities that are = =E2=80=9Cgoverned=E2=80=9D to be responsible for telephone numbers, = there is a different set of requirements and a fuzzier path forward = based on specific regulatory body rules and what needs to be enabled in = that provisioning interface and registry database, specific to applying = policy as part of the interface. Above and beyond the fact that there = is things like number portability and other things that may or may not = be common to both use case. To Martin=E2=80=99s point, unless there is clear requirements or a path = to clear requirements, it is difficult to engineer a solution or at = least one that would/could be adopted for either or both of the use = cases. Particularly if you are trying to address two at once. Would definitely be interested in any clarification on the intent that i = may have misunderstood or whether it is useful to clarify these and/or = pick an explicit path towards one or the other. > On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: >=20 > May be I have been a System Engineer too long: > 1. The service/capability requirements would be defined by = policy/regulatory needs. > 2. Then the "tool" requirements would be derived from the = policy/regulatory needs >=20 > A builder needs to know what he is building in order to ensure that he = has the correct tools in his tool box.... >=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 > Sent: Wednesday, July 01, 2015 9:34 AM > To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) > Cc: modern@ietf.org > Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > To move the discussion forward, rather than cycling back to invoking = the terms, I'd be interested in hearing which requirements, precisely = and concretely, are likely to depend on policy and regulation.=20 >=20 > Everybody has iterated again and again that the "who can get what" = part definitely does, but that's outside the protocol mechanism, just = like "who can see what web page" or "who can place what SIP call" is = beyond the concern of HTTP or SIP, beyond providing an authentication = mechanism that allows to associate a policy with a principal. >=20 > You must have specific issues in mind that go beyond that. >=20 > Henning >=20 > ________________________________________ > From: DOLLY, MARTIN C [md3135@att.com] > Sent: Wednesday, July 01, 2015 9:12 AM > To: Ben Campbell; DRAGE, Keith (Keith) > Cc: modern@ietf.org; Henning Schulzrinne > Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > But this is the root of the issue here, the requirements for such a = solution is based on policy and regulation, that does not exist , = yet.... >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 09:57:08 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD831A92B8 for ; Wed, 1 Jul 2015 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxyYF4KE1z7k for ; Wed, 1 Jul 2015 09:57:00 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5B81A1EF6 for ; Wed, 1 Jul 2015 09:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1435769820; x=1467305820; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MOh9f1FIT1yIeKBWtrkI/CM+DvE8BAsy5qqdtA7Nf/o=; b=NE/0m0FCAHB2gQdx+NxK7Oyz70F1zm7Oo/fBUZ7ig2OYHkeGksxA/ZWL j8XFOFuaDf/dhI2ya6z8VNs8iaoIN/3EMW47mUVUzlrb9tLJOsHCrgJRL bpXrAorQRvA1qmtQw8uPLiorGddM+J5x39354RFuFYDnSlf4Ah0BfXnXS w=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe03.verizonbusiness.com with ESMTP; 01 Jul 2015 16:56:56 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.15,387,1432598400"; d="scan'208";a="34517073" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 01 Jul 2015 16:56:55 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.151]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 1 Jul 2015 12:56:55 -0400 To: Chris Wendt , "DOLLY, MARTIN C" Date: Wed, 1 Jul 2015 12:56:53 -0400 Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AdC0GZPXJP30hmVGQ+uQ8TJvTIDCjwAATJog Message-ID: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> <40997198-9527-49E0-B038-4144F9FDC73D@chriswendt.net> In-Reply-To: <40997198-9527-49E0-B038-4144F9FDC73D@chriswendt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , "DRAGE, Keith \(Keith\)" , "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 16:57:05 -0000 Q2hyaXMncyBtYWlsIG1hZGUgbWUgd29uZGVyIGFib3V0IHNvbWV0aGluZy4NCg0KVHJhZGl0aW9u YWxseSAiZW5kIHVzZXJzIiAoaW5kaXZpZHVhbHMsIEVudGVycHJpc2VzKSBoYXZlIG9idGFpbmVk IHRlbGVwaG9uZSBudW1iZXJzIGFzIGEgYnlwcm9kdWN0IG9mIHN1YnNjcmliaW5nIHRvIHNvbWUg Zm9ybSBvZiAidGVsZXBob255IiBzZXJ2aWNlLiAgSGVuY2UgaXQgbWFkZSBzZW5zZSB0aGF0IHRo ZSBwcm92aWRlciBvZiB0aGUgc2VydmljZSBiZSB0aGUgc291cmNlIG9mIHRoZSBudW1iZXIuICBN eSByZWFkaW5nIG9mIHRoZSBjdXJyZW50IGNoYXJ0ZXIsIGFuZCBteSBvYnNlcnZhdGlvbiBvZiB0 aGUgcHJlc2VudGF0aW9ucyBtYWRlIGJ5IEpvbiBhbmQgSGVubmluZyBpbiB0aGUgRGFsbGFzIElF VEYsIGxlYWQgbWUgdG8gYmVsaWV2ZSBNT0RFUk4gd2lsbCBhc3N1bWUgYSBkaWZmZXJlbnQgcGFy YWRpZ20uICBUaGUgdG9vbHMgdGhlIHdnIGRldmVsb3BzIG1heSBiZSB1c2FibGUgdG8gc3VwcG9y dCB0aGUgYWJvdmUsIGJ1dCB3b3VsZCBhbHNvIHN1cHBvcnQgYSBjb3VwbGUgb2YgbmV3ICh0byBt ZSBhdCBsZWFzdCkgbm90aW9ucw0KDQphKSBzZXBhcmF0aW9uIG9mIHRlbGVwaG9uZSBudW1iZXIg YXNzaWdubWVudCBmcm9tIHN1YnNjcmlwdGlvbiB0byB0ZWxlY29tbXVuaWNhdGlvbnMgc2Vydmlj ZXMsIGFuZA0KYikgcmVsYXhhdGlvbiBvZiB0aGUgImhpZXJhcmNoeSIgdGhyb3VnaCB3aGljaCBu dW1iZXJzIGFyZSBhbGxvY2F0ZWQgdG9kYXkgKGUuZy4sIE5QQSB0byB0cmFkaXRpb25hbC1TUCB0 byBub24tdHJhZGl0aW9uYWwtU1AgdG8gRW50ZXJwcmlzZSB0byBkZXNrIHBob25lKS4NCg0KSXMg dGhhdCB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/ICANCg0KSSBoYXZlIHRvIHNheSBpdCBjb21lcyBt b3JlIGZyb20gSGVubmluZydzICJtb3RpdmF0aW9uYWwiIHNsaWRlcyB0aGFuIGZyb20gdGhlIGNo YXJ0ZXIgaXRzZWxmLiAgU28gSSdtIG5vdCBzdXJlIHRoZXNlIGFyZSBfdGhlXyBvYmplY3RpdmVz LCBfc29tZV9wb3NzaWJsZV8gb2JqZWN0aXZlcywgb3IgYSBtaXNpbnRlcnByZXRhdGlvbiBvbiBt eSBwYXJ0LiAgQXBvbG9naWVzIGluIGFkdmFuY2UgaWYgdGhlIGxhdHRlciBpcyB0aGUgY2FzZS4N Cg0KdGltDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTW9kZXJuIFtt YWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpcyBXZW5kdA0K U2VudDogV2VkbmVzZGF5LCBKdWx5IDAxLCAyMDE1IDExOjE4IEFNDQpUbzogRE9MTFksIE1BUlRJ TiBDDQpDYzogQmVuIENhbXBiZWxsOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgbW9kZXJuQGlldGYu b3JnOyBIZW5uaW5nIFNjaHVsenJpbm5lDQpTdWJqZWN0OiBSZTogW01vZGVybl0gW25ldy13b3Jr XSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0aW5nLCBFeHBvc2luZywg JiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0KDQorMQ0KDQpBbHRob3Vn aCBpIGtub3cgaXQgaGFzIGFsd2F5cyBiZWVuIHBhcnQgb2YgdGhlIHByb3Bvc2FsIGZvciBNb2Rl cm4sIEnigJltIHNlbnNpbmcgYSBzaGlmdCBpbiBjb252ZXJzYXRpb24gb3IgYXQgbGVhc3QgbW9y ZSBvZiBhIHNlZ21lbnRhdGlvbiBmb3IgZW50ZXJwcmlzZSByZXF1aXJlbWVudHMgdnMuIG51bWJl ciBhZG1pbmlzdHJhdG9yIHJlcXVpcmVtZW50cy4gIElzIHRoZXJlIGFueSBzZW5zZSB0aGF0IHRo ZSBjaGFydGVyIGNhbiBhbmQgZG9lcyByZXByZXNlbnQgYm90aCBvZiB0aGVzZSB1c2UgY2FzZXMs IGFuZCB0aGVyZSBpcyBhbnkgcmVhc29uYWJsZSBvdXRjb21lIHRoYXQgdGhlcmUgd291bGQgYmUg YSBsYXJnZWx5IGNvbW1vbiBzZXQgb2YgZnVuY3Rpb25hbGl0eSBmb3IgYm90aD8NCg0KT3IgaXMg dGhlcmUgdHdvIGV4cGxpY2l0IHJlcXVpcmVtZW50cywgYW5kIGluIG15IG1pbmQgdmVyeSBkaWZm ZXJlbnQgc29sdXRpb25zLCBoZW5jZSBteSBwcmV2aW91cyBxdWVzdGlvbiBhYm91dCB0aGUgYW5h bG9neSB0byBETlMgYW5kIElQIGFkZHJlc3MgYWxsb2NhdGlvbi4NCg0KSSB3b3VsZCBhZ3JlZSB0 aGUgZW50ZXJwcmlzZSByZXF1aXJlbWVudHMgYXJlIGZhaXJseSBzdHJhaWdodCBmb3J3YXJkLiAg RW50aXR5IEEgaGFzIGEgcG9vbCBvZiB0ZWxlcGhvbmUgbnVtYmVycyB0aGV5IGNhbiBwcm92aWRl IHNvbWUgd2hvbGVzYWxlIG9yIHRyYW5zaXQgcmVsYXRpb25zaGlwIGZvciBhbmQgRW50aXR5IEIg d291bGQgbGlrZSB0byBwcm92aXNpb24gYW5kIHVzZSB0aG9zZSBudW1iZXJzLiAgVGhpcyBwZXJo YXBzIGNvdWxkIGJlbmVmaXQgZnJvbSBhIHN0YW5kYXJkaXplZCBpbnRlcmZhY2UsIGFsdGhvdWdo IGkgbWlnaHQgYXJndWUgdGhhdCB0cm9wbyBhbmQgdHdpbGlvIGFuZCBBVCZUIGFuZCBvdGhlcnMg Y2FuIGRpZmZlcmVudGlhdGUgdGhlaXIgc2VydmljZXMgYmFzZWQgb24gYmV0dGVyIG9yIHdvcnNl IGludGVyZmFjZXMgKGJ1dCB0aGF0IGlzIGEgZGlmZmVyZW50IGRpc2N1c3Npb24gYW5kIG1heWJl IHRoYXTigJlzIGEgaGlnaGVyIGxldmVsIGludGVyZmFjZSB0aGFuIHdoYXQgd291bGQgYmUgZGVm aW5lZCBoZXJlKQ0KDQpGb3IgdGhlIG51bWJlciBhZG1pbmlzdHJhdG9yIGludGVyZmFjZSB0byB0 aG9zZSBlbnRpdGllcyB0aGF0IGFyZSDigJxnb3Zlcm5lZOKAnSB0byBiZSByZXNwb25zaWJsZSBm b3IgdGVsZXBob25lIG51bWJlcnMsIHRoZXJlIGlzIGEgZGlmZmVyZW50IHNldCBvZiByZXF1aXJl bWVudHMgYW5kIGEgZnV6emllciBwYXRoIGZvcndhcmQgYmFzZWQgb24gc3BlY2lmaWMgcmVndWxh dG9yeSBib2R5IHJ1bGVzIGFuZCB3aGF0IG5lZWRzIHRvIGJlIGVuYWJsZWQgaW4gdGhhdCBwcm92 aXNpb25pbmcgaW50ZXJmYWNlIGFuZCByZWdpc3RyeSBkYXRhYmFzZSwgc3BlY2lmaWMgdG8gYXBw bHlpbmcgcG9saWN5IGFzIHBhcnQgb2YgdGhlIGludGVyZmFjZS4gIEFib3ZlIGFuZCBiZXlvbmQg dGhlIGZhY3QgdGhhdCB0aGVyZSBpcyB0aGluZ3MgbGlrZSBudW1iZXIgcG9ydGFiaWxpdHkgYW5k IG90aGVyIHRoaW5ncyB0aGF0IG1heSBvciBtYXkgbm90IGJlIGNvbW1vbiB0byBib3RoIHVzZSBj YXNlLg0KDQpUbyBNYXJ0aW7igJlzIHBvaW50LCB1bmxlc3MgdGhlcmUgaXMgY2xlYXIgcmVxdWly ZW1lbnRzIG9yIGEgcGF0aCB0byBjbGVhciByZXF1aXJlbWVudHMsIGl0IGlzIGRpZmZpY3VsdCB0 byBlbmdpbmVlciBhIHNvbHV0aW9uIG9yIGF0IGxlYXN0IG9uZSB0aGF0IHdvdWxkL2NvdWxkIGJl IGFkb3B0ZWQgZm9yIGVpdGhlciBvciBib3RoIG9mIHRoZSB1c2UgY2FzZXMuDQpQYXJ0aWN1bGFy bHkgaWYgeW91IGFyZSB0cnlpbmcgdG8gYWRkcmVzcyB0d28gYXQgb25jZS4NCg0KV291bGQgZGVm aW5pdGVseSBiZSBpbnRlcmVzdGVkIGluIGFueSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBpbnRlbnQg dGhhdCBpIG1heSBoYXZlIG1pc3VuZGVyc3Rvb2Qgb3Igd2hldGhlciBpdCBpcyB1c2VmdWwgdG8g Y2xhcmlmeSB0aGVzZSBhbmQvb3IgcGljayBhbiBleHBsaWNpdCBwYXRoIHRvd2FyZHMgb25lIG9y IHRoZSBvdGhlci4NCg0KDQo+IE9uIEp1bCAxLCAyMDE1LCBhdCAxMDoxMiBBTSwgRE9MTFksIE1B UlRJTiBDIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQo+IA0KPiBNYXkgYmUgSSBoYXZlIGJlZW4g YSBTeXN0ZW0gRW5naW5lZXIgdG9vIGxvbmc6DQo+IDEuIFRoZSBzZXJ2aWNlL2NhcGFiaWxpdHkg cmVxdWlyZW1lbnRzIHdvdWxkIGJlIGRlZmluZWQgYnkgcG9saWN5L3JlZ3VsYXRvcnkgbmVlZHMu DQo+IDIuIFRoZW4gdGhlICJ0b29sIiByZXF1aXJlbWVudHMgd291bGQgYmUgZGVyaXZlZCBmcm9t IHRoZSBwb2xpY3kvcmVndWxhdG9yeSBuZWVkcw0KPiANCj4gQSBidWlsZGVyIG5lZWRzIHRvIGtu b3cgd2hhdCBoZSBpcyBidWlsZGluZyBpbiBvcmRlciB0byBlbnN1cmUgdGhhdCBoZSBoYXMgdGhl IGNvcnJlY3QgdG9vbHMgaW4gaGlzIHRvb2wgYm94Li4uLg0KPiANCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOkhlbm5pbmcu U2NodWx6cmlubmVAZmNjLmdvdl0gDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMSwgMjAxNSA5 OjM0IEFNDQo+IFRvOiBET0xMWSwgTUFSVElOIEM7IEJlbiBDYW1wYmVsbDsgRFJBR0UsIEtlaXRo IChLZWl0aCkNCj4gQ2M6IG1vZGVybkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW01vZGVybl0g W25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0aW5nLCBF eHBvc2luZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0KPiANCj4g VG8gbW92ZSB0aGUgZGlzY3Vzc2lvbiBmb3J3YXJkLCByYXRoZXIgdGhhbiBjeWNsaW5nIGJhY2sg dG8gaW52b2tpbmcgdGhlIHRlcm1zLCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIHdoaWNo IHJlcXVpcmVtZW50cywgcHJlY2lzZWx5IGFuZCBjb25jcmV0ZWx5LCBhcmUgbGlrZWx5IHRvIGRl cGVuZCBvbiBwb2xpY3kgYW5kIHJlZ3VsYXRpb24uIA0KPiANCj4gRXZlcnlib2R5IGhhcyBpdGVy YXRlZCBhZ2FpbiBhbmQgYWdhaW4gdGhhdCB0aGUgIndobyBjYW4gZ2V0IHdoYXQiIHBhcnQgZGVm aW5pdGVseSBkb2VzLCBidXQgdGhhdCdzIG91dHNpZGUgdGhlIHByb3RvY29sIG1lY2hhbmlzbSwg anVzdCBsaWtlICJ3aG8gY2FuIHNlZSB3aGF0IHdlYiBwYWdlIiBvciAid2hvIGNhbiBwbGFjZSB3 aGF0IFNJUCBjYWxsIiBpcyBiZXlvbmQgdGhlIGNvbmNlcm4gb2YgSFRUUCBvciBTSVAsIGJleW9u ZCBwcm92aWRpbmcgYW4gYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIHRoYXQgYWxsb3dzIHRvIGFz c29jaWF0ZSBhIHBvbGljeSB3aXRoIGEgcHJpbmNpcGFsLg0KPiANCj4gWW91IG11c3QgaGF2ZSBz cGVjaWZpYyBpc3N1ZXMgaW4gbWluZCB0aGF0IGdvIGJleW9uZCB0aGF0Lg0KPiANCj4gSGVubmlu Zw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9t OiBET0xMWSwgTUFSVElOIEMgW21kMzEzNUBhdHQuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1 bHkgMDEsIDIwMTUgOToxMiBBTQ0KPiBUbzogQmVuIENhbXBiZWxsOyBEUkFHRSwgS2VpdGggKEtl aXRoKQ0KPiBDYzogbW9kZXJuQGlldGYub3JnOyBIZW5uaW5nIFNjaHVsenJpbm5lDQo+IFN1Ympl Y3Q6IFJFOiBbTW9kZXJuXSBbbmV3LXdvcmtdIFdHIFJldmlldzogTWFuYWdpbmcsIE9yZGVyaW5n LCBEaXN0cmlidXRpbmcsIEV4cG9zaW5nLCAmIFJlZ2lzdGVyaW5nIHRlbGVwaG9uZSBOdW1iZXJz IChtb2Rlcm4pDQo+IA0KPiBCdXQgdGhpcyBpcyB0aGUgcm9vdCBvZiB0aGUgaXNzdWUgaGVyZSwg dGhlIHJlcXVpcmVtZW50cyBmb3Igc3VjaCBhIHNvbHV0aW9uIGlzIGJhc2VkIG9uIHBvbGljeSBh bmQgcmVndWxhdGlvbiwgdGhhdCBkb2VzIG5vdCBleGlzdCAsIHlldC4uLi4NCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1vZGVybiBtYWls aW5nIGxpc3QNCj4gTW9kZXJuQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW9kZXJuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpNb2Rlcm4gbWFpbGluZyBsaXN0DQpNb2Rlcm5AaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9kZXJuDQo= From nobody Wed Jul 1 12:26:54 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643451B2AF7 for ; Wed, 1 Jul 2015 12:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfLBxWumQBhQ for ; Wed, 1 Jul 2015 12:26:50 -0700 (PDT) Received: from smtp93.ord1c.emailsrvr.com (smtp93.ord1c.emailsrvr.com [108.166.43.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA02A1B2AF2 for ; Wed, 1 Jul 2015 12:26:49 -0700 (PDT) Received: from smtp28.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp28.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2B303180391; Wed, 1 Jul 2015 15:26:49 -0400 (EDT) Received: by smtp28.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8D203180075; Wed, 1 Jul 2015 15:26:47 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.0.0.63] (c-71-198-88-125.hsd1.ca.comcast.net [71.198.88.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 01 Jul 2015 19:26:49 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Cullen Jennings In-Reply-To: <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> Date: Wed, 1 Jul 2015 12:26:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> To: "Gorman, Pierce A [CTO]" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "modern@ietf.org" , Alissa Cooper Subject: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 19:26:52 -0000 This topic is complicated and there is not a perfect answer to what = rough consensus is. I suspect that in this case it is formed by a = combination of the views of people that were at the BOF and what has = been expressed on email lists. Keep in mind a lot of people in that room = expressed support for this. Some people have expressed issues on the = email lists - many of theses being basically issues that were raised on = the lists before the BOF or at BOF.=20 Many IETF people I work with view rough consensus as a large percentage = of the informed and relevant people agree - and the people with relevant = objections have had a chance to convince others they are should object = too (so they are informed). The position that debate will continue until = everyone agrees is definitely not a viable definition for a SDO that is = trying to get something done. I realize that makes the process even less deterministic but I suspect = most people at IETF would agree that my answer was at least part of = rough consensus. Part of the reason it is so hard to get a straight = answer on this is the IETF keeps telling itself it does not vote though = when you start describing how most of our important decisions are made, = it starts to sound a bit like a vote.=20 > On Jul 1, 2015, at 8:03 AM, Gorman, Pierce A [CTO] = wrote: >=20 > Alissa, > =20 > I=E2=80=99ve admitted before, I=E2=80=99m a novice at IETF procedures. = Your repeated use of the phrase =E2=80=9Crough consensus=E2=80=9D as a = conclusion of fact caught my attention. I wondered, is there any IETF = accepted definitiion of =E2=80=9Crough consensus=E2=80=9D that Alissa = and others are adhering to that I=E2=80=99m just not aware of? > =20 > A little research turned up an IETF.org document based on RFC 6722 = Section 4.2 going into some detail on the topic of =E2=80=9CGetting = Things Done in a Working Group=E2=80=9D at URL: = https://www.ietf.org/tao.html#getting.things.done > =20 > I=E2=80=99ve copied-and-pasted the sentences from the beginning of the = section that I think are particularly relevant to understanding the IETF = =E2=80=9Cconsensus=E2=80=9D view on the definition of =E2=80=9Crough = consensus=E2=80=9D. > =20 > =E2=80=9COne fact that confuses many novices is that the face-to-face = WG meetings are much less important in the IETF than they are in most = other organizations. Any decision made at a face-to-face meeting must = also gain consensus on the WG mailing list. There are numerous examples = of important decisions made in WG meetings that are later overturned on = the mailing list, often because someone who couldn't attend the meeting = pointed out a serious flaw in the logic used to come to the decision.=E2=80= =9D > =20 > =E2=80=9CThe general rule on disputed topics is that the Working Group = has to come to "rough consensus", meaning that a very large majority of = those who care must agree.=E2=80=9D > =20 > =E2=80=9CRough consensus has been defined in many ways; a simple = version is that it means that strongly held objections must be debated = until most people are satisfied that these objections are wrong.=E2=80=9D > =20 > There is some more verbiage related to the use of a Working Group Last = Call (WGLC), but it isn=E2=80=99t clear if this is before or after = chartering. If its supposed to be done before, we skipped it I think. > =20 > The Tao is not a legalistic document based on rigid parlimentary = procedures and there is what I will call a power of fiat within the IESG = and the WG chairs, meaning they can basically ignore the definitions = given above. > =20 > I can fully understand the anxiousness of many participants to end = debate and just move on. Code prototyping has already happened and = available for review (based on request only and an undefined approval = process). > =20 > Regardless, I have to ask, using the definitions of the IETF Tao, on = what basis can it be claimed that =E2=80=9Crough consensus=E2=80=9D has = been achieved for the MODERN charter? =46rom what I can tell it was the = power of fiat. > =20 > Best regards, > =20 > =20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > =20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa = Cooper > Sent: June 30, 2015 4:01 PM > To: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) > =20 > I=E2=80=99d like to ask that each person participating in this = discussion remember to be respectful of one another=E2=80=99s points of = view and focus on constructive dialogue. If you feel that you=E2=80=99re = wasting cycles on the current threads then feel free to change the = subject to something more productive; likewise if you feel someone else = is wasting your cycles, don=E2=80=99t feel compelled to respond. > =20 > To review the process that got us to the current point: > =20 > The conclusion from the BoF in Dallas was that there was rough = consensus in the room in support of forming the WG but that the charter = and problem scope needed refinement (feel free to review the minutes: = http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That = process of refinement took place on this list over several months = following the BoF. The charter was put out for review on June 12 with = comments requested to be sent to the IESG by June 22. The IESG = considered the two ITU-T related comments received (both after the = deadline) and issued no blocking comments on the charter but asked that = edits be considered on the basis of comments received. There were no = other comments received or indications provided to the IESG about the = readiness of this work for chartering. I=E2=80=99m still working on = edits (Richard Hill pointed out that I missed his suggestions) and = milestones are in the works as well. Thus this WG is being formed = according to the usual process. > =20 > Alissa >=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 From nobody Wed Jul 1 12:52:08 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB831A8774 for ; Wed, 1 Jul 2015 12:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 cB8OREmx2OEw for ; Wed, 1 Jul 2015 12:52:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4A31A87B8 for ; Wed, 1 Jul 2015 12:52:01 -0700 (PDT) Received: from BL2FFO11OLC004.protection.gbl (10.173.160.34) by BL2FFO11HUB055.protection.gbl (10.173.161.155) with Microsoft SMTP Server (TLS) id 15.1.201.10; Wed, 1 Jul 2015 19:52:00 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BL2FFO11OLC004.mail.protection.outlook.com (10.173.161.188) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 1 Jul 2015 19:52:00 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t61Jl0xc001777; Wed, 1 Jul 2015 14:51:59 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm2.corp.sprint.com with ESMTP id 1v9sm25ve9-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Jul 2015 14:51:59 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 1 Jul 2015 15:51:58 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 1 Jul 2015 14:51:58 -0500 From: "Gorman, Pierce A [CTO]" To: Cullen Jennings Thread-Topic: Rough consensus - Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQs3fqEwQ50yu6z0i1W6uAK8HRwp3GrskwgACl1QD//661kA== Date: Wed, 1 Jul 2015 19:51:57 +0000 Message-ID: <4161eac2ce1e4b09a172664472416e20@PLSWE13M08.ad.sprint.com> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> In-Reply-To: <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> 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.26] Content-Type: multipart/alternative; boundary="_000_4161eac2ce1e4b09a172664472416e20PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC004; 1:xxc3vnOCY15LKXgrPhKDUdvcpC9ITJ13HiPcwcmk82ZuZX8IAIysYQTN4ylXahIly3JpLrtBGCohMRuG/v8NVTicIV6FMr1pzudAmyEqdqRwswdlPBt77UG5Vn9hYuxFDbPiBGJ/U5AML6786yALBLjKccxS+YQwYKSod/d61dvQbq1iVuYn6Kw7qaTyPDybmp67NngUtFNeplmcrG0qJF0C3mvS393DEDyVvAukU0nyz/NrUHZbip+Hl05HbbvGOoNYhTTjrzVrYkv6s8FRoaVwsN/cmAUuU1Ae/iBGaTvuwLWUKBKdrW1o955Rzih1 X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(448002)(52044002)(24454002)(189002)(199003)(13464003)(377454003)(51704005)(54356999)(50986999)(110136002)(84326002)(2900100001)(85326001)(19580405001)(24736003)(16236675004)(76176999)(19580395003)(2656002)(512874002)(15975445007)(5001960100002)(2950100001)(87936001)(19625215002)(102836002)(86362001)(189998001)(106466001)(46102003)(5003600100002)(93886004)(5250100002)(108616004)(6806004)(92566002)(62966003)(33646002)(106116001)(19300405004)(77156002)(19617315012)(437434002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB055; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB055; 2:bUEp1s3UBeoPbFtlATv7ojmo9WKzp4NouC1rs5MmpVbpqURcvPaYd3Cp5QDvyp/Q; 3:5hyrXoQjBxHE/c0+1DKKLwjdwmWuIidYZ34rx9G8CZxC91v8hdZD5hyPZ6nMVJHjjYgY/1BIMfXjwb5YXWwchSSmVF+SUC/5yxbWGDPj44kElXua1Ks7Sk+gXZFGv8bdYXNXNnajz4ECG6/1zSOxa/JM3J708UfZaiePUiic+p/h+pChXxRGmRuwTY2gDHimILdHiiEGs5vicEErRu8VgutF3TSDhNln30BXCEBI+O5TN0s6IR5X0UhKBKTYn6sp; 20:nRWQLWauoBKz4aBOh9d5SSgHpV90oyJw1w29/kkWqFQt8I63hs+QbVfeuDtm2kF3YKo9G8187qZp1Uwb+Y8dAck6GWZFIFxietkUBPF8mMDReFMewffjTLyH+R+OMf7NzA6XuSd5VsaoqO3tc1DDvqMaHG/s871bSQyZ++anIhLohMu6dWVa0b5k/R7HTj8nSufshBf1uCVXo8mJJWN5tFK5kkD8QJ4JVIS9G/Otu+2xHX6r/HMxmg8Xfj/dtdTO; 4:PPsxfcCB0pcuKA/1PhOkAKaPc3TIFvvcojQiP+1ssgw/C5h89CqzDKVGFhKAT8HubAaGEwy48GUTkhWJbrjcn4oUmtotdUZ71agG1gW+0BDnGepYGcLi8rTZlr++Eob52cawHeyIBpINPAZikIEuJtGu2cuOplsD0oKDNgabiQun3TLiS7RAjaMC0ZDnL5zUvvMo5MBF6NYKFntwNVdQ53DeV99wAqaE31gCGq5i4k4kukp2w+ZllveeCd5iujj3YmcpJYjMWYQf7d8p+tvJhI5zSu9z4Ajv5Z+YWY9yMec= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB055; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB055; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB055; X-Forefront-PRVS: 0624A2429E X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB055; 23:qPBzPfjJtst0qY2ZHSx2j0SMNbMxI/CGWPmBUl2l?= =?us-ascii?Q?AcMtnyO12AMzeBGPyD9pcVYwmGEcwK5HEiZFp2JWbTw4/zfsFrG4TliE5kpp?= =?us-ascii?Q?lH9c8Q7aXUIhgtHbvUqPC+dN+duviNpAaW38p1yVToOWh65j+EbXWwHBy/Kn?= =?us-ascii?Q?Agm6nUGCn6y5IclomPOzk2a0Dl066Rl3B4U2E2Qt38y5p0NBrycy6TSIrWI+?= =?us-ascii?Q?GGJEj9jEsO9XTs3CRYZg5H0ZahckFO7l9bReQlFu90PxBqRI3PEuI1STG0Mx?= =?us-ascii?Q?tPxCTcXB69VMBsjGsZcj7+LH2bs2yO+MCuM5J6OUSoiLrLRzduQ8jv0pUd8j?= =?us-ascii?Q?jMpu11gu4VCi29F9p3Hk8S77Olpsaq+iCTpzteFCITGnoAXHTS33wYe4p6K8?= =?us-ascii?Q?ipOAX2b6xCBXHNSzZch2otKKadLphjI0aDVVcWvSI37Uqw6t+FFB4/uWqD3L?= =?us-ascii?Q?NuVqs7BEZ7PvEgtbbQLYoU+G7Gj+7n2KwNnSiAQ1Hjg5CRrEi7a/mJc1qx6V?= =?us-ascii?Q?5Gi4/bg0Ym8OmpzX2yEtKZZv3+j6nAhxTnkJjg6sa9395viWAiv+wg5mgQaQ?= =?us-ascii?Q?6pRsU567b66vH6BAETekAAO8n3QuF+pwy44/6qGA8VDwhSpGfYo7cplv2BR0?= =?us-ascii?Q?0tAXEJ6fm3+kKSjiJWcIpEj9pXUZ3IgwZjf0FzU8bEuJzuWg8yyM4DALZQom?= =?us-ascii?Q?3XsRxHEoJN7oK6T5PW9Hm4Z7lhZaon9/S4Cg19LG4x6CWcxmj+CYgz4vkUC6?= =?us-ascii?Q?QYNZvrfAckpNbYTDHMJDsRs6xq6n0YQ9EsBjouGjv8KvR7Q2SuEMrIC4gctd?= =?us-ascii?Q?w9PU8w+iVY8hfH3AmgPhEwSx2AFUhluuVchuVou/IMg5aQaouiD8eO9qXaGa?= =?us-ascii?Q?4Kdwu0tyvJWXuna+5N7ILlfNsThfR38T6+l/wLgANWuS7tCtmo7m1I5nngq+?= =?us-ascii?Q?mhGls5jRPQCsFP+5DN6UgZbnY0bm9GHOEN4EBm5RwpgnNxoMpXtSaHZOaP8b?= =?us-ascii?Q?xN5vP0Ur0nXsMrVnV+HPPGGoLolQVzDV4cRqaCDgjxnfTW4C6xnK2hbeN/l/?= =?us-ascii?Q?hu4+bTyJsl0QpIykcY0164v3+t0LQAGAErHapKff0XYO8poLCLr8P/FDEai1?= =?us-ascii?Q?f92SsFMJ0V/fMQpnme2MLyQqF3HTa4GFiHyZAZynkZIWGXO7toXhXcGfKpQO?= =?us-ascii?Q?jsUqli4bAbX/4Xc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB055; 5:YUdWZgSW2QHxDB9gw73hjSHOcj5ljGJEIEicsdx7GN4Vr0hvM+WgLT/0b6gTCkQ2YUimhdwjLBK4DH3nMEbQ8OukF4JNp2ivxG4Rg6Dnk0/zGP7jomA2c0iFk05Jcv55YOE8c4KgR0G63fY3LwtRbg==; 24:I2J6wr5sL7dd3vLjPDFqXcgK8eLwgYr2esFTOOziaEGjJPy96+cBGoncWe9EVXACe8lBr/DNe+O2MsTj4YP6g/hx90O63PmMe2weBIDuPJc= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2015 19:52:00.4320 (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: BL2FFO11HUB055 Archived-At: Cc: "modern@ietf.org" , Alissa Cooper Subject: Re: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 19:52:06 -0000 --_000_4161eac2ce1e4b09a172664472416e20PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4tbGluZS4NCg0KDQoNClBpZXJjZSBHb3JtYW4NCg0KcGllcmNlLmdvcm1hbkBzcHJpbnQuY29t DQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEN1bGxlbiBKZW5u aW5ncyBbbWFpbHRvOmZsdWZmeUBpaWkuY2FdDQpTZW50OiBKdWx5IDAxLCAyMDE1IDI6MjcgUE0N ClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dDQpDYzogQWxpc3NhIENvb3BlcjsgbW9kZXJuQGll dGYub3JnDQpTdWJqZWN0OiBSb3VnaCBjb25zZW5zdXMgLSBSZTogW01vZGVybl0gW25ldy13b3Jr XSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywgRGlzdHJpYnV0aW5nLCBFeHBvc2luZywg JiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVycyAobW9kZXJuKQ0KDQoNCg0KDQoNClRoaXMg dG9waWMgaXMgY29tcGxpY2F0ZWQgYW5kIHRoZXJlIGlzIG5vdCBhIHBlcmZlY3QgYW5zd2VyIHRv IHdoYXQgcm91Z2ggY29uc2Vuc3VzIGlzLiBJIHN1c3BlY3QgdGhhdCBpbiB0aGlzIGNhc2UgaXQg aXMgZm9ybWVkIGJ5IGEgY29tYmluYXRpb24gb2YgdGhlIHZpZXdzIG9mIHBlb3BsZSB0aGF0IHdl cmUgYXQgdGhlIEJPRiBhbmQgd2hhdCBoYXMgYmVlbiBleHByZXNzZWQgb24gZW1haWwgbGlzdHMu IEtlZXAgaW4gbWluZCBhIGxvdCBvZiBwZW9wbGUgaW4gdGhhdCByb29tIGV4cHJlc3NlZCBzdXBw b3J0IGZvciB0aGlzLg0KDQoNCg0KUEctPiAgSSBoYXZlIG5vIGRvdWJ0IOKAnGEgbG90IG9mIHBl b3BsZSBpbiB0aGF0IHJvb20gZXhwcmVzc2VkIHN1cHBvcnQgZm9yIHRoaXMu4oCdICBIb3dldmVy LCB0aGUgZ3VpZGVsaW5lcyBmb3IgZGVmaW5pbmcgYW5kIGFjaGlldmluZyByb3VnaCBjb25zZW5z dXMgaW4gUkZDIDY3MjIgaW5kaWNhdGVzLCDigJxmYWNlLXRvLWZhY2UgV0cgbWVldGluZ3MgYXJl IG11Y2ggbGVzcyBpbXBvcnRhbnQgaW4gdGhlIElFVEYgdGhhbiB0aGV5IGFyZSBpbiBtb3N0IG90 aGVyIG9yZ2FuaXphdGlvbnMuIEFueSBkZWNpc2lvbiBtYWRlIGF0IGEgZmFjZS10by1mYWNlIG1l ZXRpbmcgbXVzdCBhbHNvIGdhaW4gY29uc2Vuc3VzIG9uIHRoZSBXRyBtYWlsaW5nIGxpc3Qu4oCd DQoNCg0KDQpTb21lIHBlb3BsZSBoYXZlIGV4cHJlc3NlZCBpc3N1ZXMgb24gdGhlIGVtYWlsIGxp c3RzIC0gbWFueSBvZiB0aGVzZXMgYmVpbmcgYmFzaWNhbGx5IGlzc3VlcyB0aGF0IHdlcmUgcmFp c2VkIG9uIHRoZSBsaXN0cyBiZWZvcmUgdGhlIEJPRiBvciBhdCBCT0YuDQoNCg0KDQpNYW55IElF VEYgcGVvcGxlIEkgd29yayB3aXRoIHZpZXcgcm91Z2ggY29uc2Vuc3VzIGFzIGEgbGFyZ2UgcGVy Y2VudGFnZSBvZiB0aGUgaW5mb3JtZWQgYW5kIHJlbGV2YW50IHBlb3BsZSBhZ3JlZSAtIGFuZCB0 aGUgcGVvcGxlIHdpdGggcmVsZXZhbnQgb2JqZWN0aW9ucyBoYXZlIGhhZCBhIGNoYW5jZSB0byBj b252aW5jZSBvdGhlcnMgdGhleSBhcmUgc2hvdWxkIG9iamVjdCB0b28gKHNvIHRoZXkgYXJlIGlu Zm9ybWVkKS4NCg0KDQoNClBHLT4gIFdobyBkZWNpZGVzIHdob20gaXMgaW5mb3JtZWQ/ICBXaG8g ZGVjaWRlcyB0aGUgbWVtYmVyc2hpcCBvZiDigJxyZWxldmFudCBwZW9wbGXigJ0/ICBOb3QgdG8g YmUgKHRvbykgaW1wZXJ0aW5lbnQsIGJ1dCBhbnkgY2hhbmNlIEkgY2FuIGdldCBhIGxpc3Qgb2Yg dGhlIGlycmVsZXZhbnQgcGVvcGxlIGFuZCB0aGVpciBpcnJlbGV2YW50IG9iamVjdGlvbnM/ICBJ IHRoaW5rIEkgY2FuIGd1ZXNzIHdob20gYXJlIHRoZSByZWxldmFudCBwZW9wbGUgYW5kIHRoZWly IHZpZXdzLg0KDQoNCg0KVGhlIHBvc2l0aW9uIHRoYXQgZGViYXRlIHdpbGwgY29udGludWUgdW50 aWwgZXZlcnlvbmUgYWdyZWVzIGlzIGRlZmluaXRlbHkgbm90IGEgdmlhYmxlIGRlZmluaXRpb24g Zm9yIGEgU0RPIHRoYXQgaXMgdHJ5aW5nIHRvIGdldCBzb21ldGhpbmcgZG9uZS4NCg0KDQoNClBH LT4gIEFncmVlLiAgVGhlIGd1aWRlbGluZXMgdGhlIElFVEYgYWRvcHRlZCBhbmQgcHVibGlzaGVk IGluIFJGQyA2NzIyIGluZGljYXRlIGNvbXBsZXRlIGFncmVlbWVudCBpcyBub3QgcmVxdWlyZWQu ICBJbnN0ZWFkIHdoYXQgaXMgcmVxdWlyZWQgaXMgYSDigJxyb3VnaCBjb25zZW5zdXPigJ0gZGVm aW5lZCB2YXJpb3VzbHkgYXMg4oCcYSB2ZXJ5IGxhcmdlIG1ham9yaXR5IG9mIHRob3NlIHdobyBj YXJlIG11c3QgYWdyZWXigJ0sIGFuZCDigJxzdHJvbmdseSBoZWxkIG9iamVjdGlvbnMgbXVzdCBi ZSBkZWJhdGVkIHVudGlsIG1vc3QgcGVvcGxlIGFyZSBzYXRpc2ZpZWQgdGhhdCB0aGVzZSBvYmpl Y3Rpb25zIGFyZSB3cm9uZy7igJ0gIE15IHBvaW50IGlzIHRoYXQgZnJvbSB3aGF0IEkgY2FuIHRl bGwgdGhlc2UgZ3VpZGVsaW5lcyBoYXZlIGJlZW4gZGlzbWlzc2VkIGhlcmUuDQoNCg0KDQpJIHJl YWxpemUgdGhhdCBtYWtlcyB0aGUgcHJvY2VzcyBldmVuIGxlc3MgZGV0ZXJtaW5pc3RpYyBidXQg SSBzdXNwZWN0IG1vc3QgcGVvcGxlIGF0IElFVEYgd291bGQgYWdyZWUgdGhhdCBteSBhbnN3ZXIg d2FzIGF0IGxlYXN0IHBhcnQgb2Ygcm91Z2ggY29uc2Vuc3VzLiAgUGFydCBvZiB0aGUgcmVhc29u IGl0IGlzIHNvIGhhcmQgdG8gZ2V0IGEgc3RyYWlnaHQgYW5zd2VyIG9uIHRoaXMgaXMgdGhlIElF VEYga2VlcHMgdGVsbGluZyBpdHNlbGYgaXQgZG9lcyBub3Qgdm90ZSB0aG91Z2ggd2hlbiB5b3Ug c3RhcnQgZGVzY3JpYmluZyBob3cgbW9zdCBvZiBvdXIgaW1wb3J0YW50IGRlY2lzaW9ucyBhcmUg bWFkZSwgaXQgc3RhcnRzIHRvIHNvdW5kIGEgYml0IGxpa2UgYSB2b3RlLg0KDQoNCg0KDQoNCj4g T24gSnVsIDEsIDIwMTUsIGF0IDg6MDMgQU0sIEdvcm1hbiwgUGllcmNlIEEgW0NUT10gPFBpZXJj ZS5Hb3JtYW5Ac3ByaW50LmNvbTxtYWlsdG86UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPj4gd3Jv dGU6DQoNCj4NCg0KPiBBbGlzc2EsDQoNCj4NCg0KPiBJ4oCZdmUgYWRtaXR0ZWQgYmVmb3JlLCBJ 4oCZbSBhIG5vdmljZSBhdCBJRVRGIHByb2NlZHVyZXMuICBZb3VyIHJlcGVhdGVkIHVzZSBvZiB0 aGUgcGhyYXNlIOKAnHJvdWdoIGNvbnNlbnN1c+KAnSBhcyBhIGNvbmNsdXNpb24gb2YgZmFjdCBj YXVnaHQgbXkgYXR0ZW50aW9uLiAgSSB3b25kZXJlZCwgaXMgdGhlcmUgYW55IElFVEYgYWNjZXB0 ZWQgZGVmaW5pdGlpb24gb2Yg4oCccm91Z2ggY29uc2Vuc3Vz4oCdIHRoYXQgQWxpc3NhIGFuZCBv dGhlcnMgYXJlIGFkaGVyaW5nIHRvIHRoYXQgSeKAmW0ganVzdCBub3QgYXdhcmUgb2Y/DQoNCj4N Cg0KPiBBIGxpdHRsZSByZXNlYXJjaCB0dXJuZWQgdXAgYW4gSUVURi5vcmcgZG9jdW1lbnQgYmFz ZWQgb24gUkZDIDY3MjIgU2VjdGlvbiA0LjIgZ29pbmcgaW50byBzb21lIGRldGFpbCBvbiB0aGUg dG9waWMgb2Yg4oCcR2V0dGluZyBUaGluZ3MgRG9uZSBpbiBhIFdvcmtpbmcgR3JvdXDigJ0gYXQg VVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy90YW8uaHRtbCNnZXR0aW5nLnRoaW5ncy5kb25lDQoN Cj4NCg0KPiBJ4oCZdmUgY29waWVkLWFuZC1wYXN0ZWQgdGhlIHNlbnRlbmNlcyBmcm9tIHRoZSBi ZWdpbm5pbmcgb2YgdGhlIHNlY3Rpb24gdGhhdCBJIHRoaW5rIGFyZSBwYXJ0aWN1bGFybHkgcmVs ZXZhbnQgdG8gdW5kZXJzdGFuZGluZyB0aGUgSUVURiDigJxjb25zZW5zdXPigJ0gdmlldyBvbiB0 aGUgZGVmaW5pdGlvbiBvZiDigJxyb3VnaCBjb25zZW5zdXPigJ0uDQoNCj4NCg0KPiDigJxPbmUg ZmFjdCB0aGF0IGNvbmZ1c2VzIG1hbnkgbm92aWNlcyBpcyB0aGF0IHRoZSBmYWNlLXRvLWZhY2Ug V0cgbWVldGluZ3MgYXJlIG11Y2ggbGVzcyBpbXBvcnRhbnQgaW4gdGhlIElFVEYgdGhhbiB0aGV5 IGFyZSBpbiBtb3N0IG90aGVyIG9yZ2FuaXphdGlvbnMuIEFueSBkZWNpc2lvbiBtYWRlIGF0IGEg ZmFjZS10by1mYWNlIG1lZXRpbmcgbXVzdCBhbHNvIGdhaW4gY29uc2Vuc3VzIG9uIHRoZSBXRyBt YWlsaW5nIGxpc3QuIFRoZXJlIGFyZSBudW1lcm91cyBleGFtcGxlcyBvZiBpbXBvcnRhbnQgZGVj aXNpb25zIG1hZGUgaW4gV0cgbWVldGluZ3MgdGhhdCBhcmUgbGF0ZXIgb3ZlcnR1cm5lZCBvbiB0 aGUgbWFpbGluZyBsaXN0LCBvZnRlbiBiZWNhdXNlIHNvbWVvbmUgd2hvIGNvdWxkbid0IGF0dGVu ZCB0aGUgbWVldGluZyBwb2ludGVkIG91dCBhIHNlcmlvdXMgZmxhdyBpbiB0aGUgbG9naWMgdXNl ZCB0byBjb21lIHRvIHRoZSBkZWNpc2lvbi7igJ0NCg0KPg0KDQo+IOKAnFRoZSBnZW5lcmFsIHJ1 bGUgb24gZGlzcHV0ZWQgdG9waWNzIGlzIHRoYXQgdGhlIFdvcmtpbmcgR3JvdXAgaGFzIHRvIGNv bWUgdG8gInJvdWdoIGNvbnNlbnN1cyIsIG1lYW5pbmcgdGhhdCBhIHZlcnkgbGFyZ2UgbWFqb3Jp dHkgb2YgdGhvc2Ugd2hvIGNhcmUgbXVzdCBhZ3JlZS7igJ0NCg0KPg0KDQo+IOKAnFJvdWdoIGNv bnNlbnN1cyBoYXMgYmVlbiBkZWZpbmVkIGluIG1hbnkgd2F5czsgYSBzaW1wbGUgdmVyc2lvbiBp cyB0aGF0IGl0IG1lYW5zIHRoYXQgc3Ryb25nbHkgaGVsZCBvYmplY3Rpb25zIG11c3QgYmUgZGVi YXRlZCB1bnRpbCBtb3N0IHBlb3BsZSBhcmUgc2F0aXNmaWVkIHRoYXQgdGhlc2Ugb2JqZWN0aW9u cyBhcmUgd3Jvbmcu4oCdDQoNCj4NCg0KPiBUaGVyZSBpcyBzb21lIG1vcmUgdmVyYmlhZ2UgcmVs YXRlZCB0byB0aGUgdXNlIG9mIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgKFdHTEMpLCBidXQg aXQgaXNu4oCZdCBjbGVhciBpZiB0aGlzIGlzIGJlZm9yZSBvciBhZnRlciBjaGFydGVyaW5nLiAg SWYgaXRzIHN1cHBvc2VkIHRvIGJlIGRvbmUgYmVmb3JlLCB3ZSBza2lwcGVkIGl0IEkgdGhpbmsu DQoNCj4NCg0KPiBUaGUgVGFvIGlzIG5vdCBhIGxlZ2FsaXN0aWMgZG9jdW1lbnQgYmFzZWQgb24g cmlnaWQgcGFybGltZW50YXJ5IHByb2NlZHVyZXMgYW5kIHRoZXJlIGlzIHdoYXQgSSB3aWxsIGNh bGwgYSBwb3dlciBvZiBmaWF0IHdpdGhpbiB0aGUgSUVTRyBhbmQgdGhlIFdHIGNoYWlycywgbWVh bmluZyB0aGV5IGNhbiBiYXNpY2FsbHkgaWdub3JlIHRoZSBkZWZpbml0aW9ucyBnaXZlbiBhYm92 ZS4NCg0KPg0KDQo+IEkgY2FuIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGFueGlvdXNuZXNzIG9mIG1h bnkgcGFydGljaXBhbnRzIHRvIGVuZCBkZWJhdGUgYW5kIGp1c3QgbW92ZSBvbi4gIENvZGUgcHJv dG90eXBpbmcgaGFzIGFscmVhZHkgaGFwcGVuZWQgYW5kIGF2YWlsYWJsZSBmb3IgcmV2aWV3IChi YXNlZCBvbiByZXF1ZXN0IG9ubHkgYW5kIGFuIHVuZGVmaW5lZCBhcHByb3ZhbCBwcm9jZXNzKS4N Cg0KPg0KDQo+IFJlZ2FyZGxlc3MsIEkgaGF2ZSB0byBhc2ssIHVzaW5nIHRoZSBkZWZpbml0aW9u cyBvZiB0aGUgSUVURiBUYW8sIG9uIHdoYXQgYmFzaXMgY2FuIGl0IGJlIGNsYWltZWQgdGhhdCDi gJxyb3VnaCBjb25zZW5zdXPigJ0gaGFzIGJlZW4gYWNoaWV2ZWQgZm9yIHRoZSBNT0RFUk4gY2hh cnRlcj8gIEZyb20gd2hhdCBJIGNhbiB0ZWxsIGl0IHdhcyB0aGUgcG93ZXIgb2YgZmlhdC4NCg0K Pg0KDQo+IEJlc3QgcmVnYXJkcywNCg0KPg0KDQo+DQoNCj4gUGllcmNlIEdvcm1hbg0KDQo+IENv cmUgTmV0d29yayBQbGFubmluZw0KDQo+IE86IDkxMy00MzktNDM2OA0KDQo+IHBpZXJjZS5nb3Jt YW5Ac3ByaW50LmNvbTxtYWlsdG86cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tPg0KDQo+IDxpbWFn ZTAwMS5wbmc+DQoNCj4NCg0KPiBGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsaXNzYSBDb29wZXINCg0KPiBTZW50OiBKdW5lIDMwLCAy MDE1IDQ6MDEgUE0NCg0KPiBUbzogbW9kZXJuQGlldGYub3JnPG1haWx0bzptb2Rlcm5AaWV0Zi5v cmc+DQoNCj4gU3ViamVjdDogUmU6IFtNb2Rlcm5dIFtuZXctd29ya10gV0cgUmV2aWV3OiBNYW5h Z2luZywgT3JkZXJpbmcsIERpc3RyaWJ1dGluZywgRXhwb3NpbmcsICYgUmVnaXN0ZXJpbmcgdGVs ZXBob25lIE51bWJlcnMgKG1vZGVybikNCg0KPg0KDQo+IEnigJlkIGxpa2UgdG8gYXNrIHRoYXQg ZWFjaCBwZXJzb24gcGFydGljaXBhdGluZyBpbiB0aGlzIGRpc2N1c3Npb24gcmVtZW1iZXIgdG8g YmUgcmVzcGVjdGZ1bCBvZiBvbmUgYW5vdGhlcuKAmXMgcG9pbnRzIG9mIHZpZXcgYW5kIGZvY3Vz IG9uIGNvbnN0cnVjdGl2ZSBkaWFsb2d1ZS4gSWYgeW91IGZlZWwgdGhhdCB5b3XigJlyZSB3YXN0 aW5nIGN5Y2xlcyBvbiB0aGUgY3VycmVudCB0aHJlYWRzIHRoZW4gZmVlbCBmcmVlIHRvIGNoYW5n ZSB0aGUgc3ViamVjdCB0byBzb21ldGhpbmcgbW9yZSBwcm9kdWN0aXZlOyBsaWtld2lzZSBpZiB5 b3UgZmVlbCBzb21lb25lIGVsc2UgaXMgd2FzdGluZyB5b3VyIGN5Y2xlcywgZG9u4oCZdCBmZWVs IGNvbXBlbGxlZCB0byByZXNwb25kLg0KDQo+DQoNCj4gVG8gcmV2aWV3IHRoZSBwcm9jZXNzIHRo YXQgZ290IHVzIHRvIHRoZSBjdXJyZW50IHBvaW50Og0KDQo+DQoNCj4gVGhlIGNvbmNsdXNpb24g ZnJvbSB0aGUgQm9GIGluIERhbGxhcyB3YXMgdGhhdCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3Vz IGluIHRoZSByb29tIGluIHN1cHBvcnQgb2YgZm9ybWluZyB0aGUgV0cgYnV0IHRoYXQgdGhlIGNo YXJ0ZXIgYW5kIHByb2JsZW0gc2NvcGUgbmVlZGVkIHJlZmluZW1lbnQgKGZlZWwgZnJlZSB0byBy ZXZpZXcgdGhlIG1pbnV0ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvbWlu dXRlcy9taW51dGVzLTkyLW1vZGVybikuIFRoYXQgcHJvY2VzcyBvZiByZWZpbmVtZW50IHRvb2sg cGxhY2Ugb24gdGhpcyBsaXN0IG92ZXIgc2V2ZXJhbCBtb250aHMgZm9sbG93aW5nIHRoZSBCb0Yu IFRoZSBjaGFydGVyIHdhcyBwdXQgb3V0IGZvciByZXZpZXcgb24gSnVuZSAxMiB3aXRoIGNvbW1l bnRzIHJlcXVlc3RlZCB0byBiZSBzZW50IHRvIHRoZSBJRVNHIGJ5IEp1bmUgMjIuIFRoZSBJRVNH IGNvbnNpZGVyZWQgdGhlIHR3byBJVFUtVCByZWxhdGVkIGNvbW1lbnRzIHJlY2VpdmVkIChib3Ro IGFmdGVyIHRoZSBkZWFkbGluZSkgYW5kIGlzc3VlZCBubyBibG9ja2luZyBjb21tZW50cyBvbiB0 aGUgY2hhcnRlciBidXQgYXNrZWQgdGhhdCBlZGl0cyBiZSBjb25zaWRlcmVkIG9uIHRoZSBiYXNp cyBvZiBjb21tZW50cyByZWNlaXZlZC4gVGhlcmUgd2VyZSBubyBvdGhlciBjb21tZW50cyByZWNl aXZlZCBvciBpbmRpY2F0aW9ucyBwcm92aWRlZCB0byB0aGUgSUVTRyBhYm91dCB0aGUgcmVhZGlu ZXNzIG9mIHRoaXMgd29yayBmb3IgY2hhcnRlcmluZy4gSeKAmW0gc3RpbGwgd29ya2luZyBvbiBl ZGl0cyAoUmljaGFyZCBIaWxsIHBvaW50ZWQgb3V0IHRoYXQgSSBtaXNzZWQgaGlzIHN1Z2dlc3Rp b25zKSBhbmQgbWlsZXN0b25lcyBhcmUgaW4gdGhlIHdvcmtzIGFzIHdlbGwuIFRodXMgdGhpcyBX RyBpcyBiZWluZyBmb3JtZWQgYWNjb3JkaW5nIHRvIHRoZSB1c3VhbCBwcm9jZXNzLg0KDQo+DQoN Cj4gQWxpc3NhDQoNCj4NCg0KPg0KDQo+IFRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBw cm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBy ZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gTW9kZXJuIG1haWxpbmcgbGlzdA0K DQo+IE1vZGVybkBpZXRmLm9yZzxtYWlsdG86TW9kZXJuQGlldGYub3JnPg0KDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9kZXJuDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJv cHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVj aXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS4NCg== --_000_4161eac2ce1e4b09a172664472416e20PLSWE13M08adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj5Jbi1saW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGllcmNlIEdvcm1hbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBDdWxsZW4g SmVubmluZ3MgW21haWx0bzpmbHVmZnlAaWlpLmNhXSA8YnI+DQpTZW50OiBKdWx5IDAxLCAyMDE1 IDI6MjcgUE08YnI+DQpUbzogR29ybWFuLCBQaWVyY2UgQSBbQ1RPXTxicj4NCkNjOiBBbGlzc2Eg Q29vcGVyOyBtb2Rlcm5AaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSb3VnaCBjb25zZW5zdXMgLSBS ZTogW01vZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmluZywgRGlz dHJpYnV0aW5nLCBFeHBvc2luZywgJmFtcDsgUmVnaXN0ZXJpbmcgdGVsZXBob25lIE51bWJlcnMg KG1vZGVybik8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhpcyB0b3BpYyBpcyBjb21wbGljYXRlZCBhbmQgdGhlcmUgaXMg bm90IGEgcGVyZmVjdCBhbnN3ZXIgdG8gd2hhdCByb3VnaCBjb25zZW5zdXMgaXMuIEkgc3VzcGVj dCB0aGF0IGluIHRoaXMgY2FzZSBpdCBpcyBmb3JtZWQgYnkgYSBjb21iaW5hdGlvbiBvZiB0aGUg dmlld3Mgb2YgcGVvcGxlIHRoYXQgd2VyZSBhdCB0aGUgQk9GIGFuZCB3aGF0IGhhcyBiZWVuIGV4 cHJlc3NlZCBvbiBlbWFpbCBsaXN0cy4NCiBLZWVwIGluIG1pbmQgYSBsb3Qgb2YgcGVvcGxlIGlu IHRoYXQgcm9vbSBleHByZXNzZWQgc3VwcG9ydCBmb3IgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPlBHLSZndDsmbmJzcDsgSSBo YXZlIG5vIGRvdWJ0IOKAnGEgbG90IG9mIHBlb3BsZSBpbiB0aGF0IHJvb20gZXhwcmVzc2VkIHN1 cHBvcnQgZm9yIHRoaXMu4oCdJm5ic3A7IEhvd2V2ZXIsIHRoZSBndWlkZWxpbmVzIGZvciBkZWZp bmluZyBhbmQgYWNoaWV2aW5nIHJvdWdoIGNvbnNlbnN1cyBpbiBSRkMgNjcyMiBpbmRpY2F0ZXMs IOKAnGZhY2UtdG8tZmFjZSBXRyBtZWV0aW5ncyBhcmUgbXVjaA0KIGxlc3MgaW1wb3J0YW50IGlu IHRoZSBJRVRGIHRoYW4gdGhleSBhcmUgaW4gbW9zdCBvdGhlciBvcmdhbml6YXRpb25zLiBBbnkg ZGVjaXNpb24gbWFkZSBhdCBhIGZhY2UtdG8tZmFjZSBtZWV0aW5nIG11c3QgYWxzbyBnYWluIGNv bnNlbnN1cyBvbiB0aGUgV0cgbWFpbGluZyBsaXN0LuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+U29tZSBwZW9wbGUgaGF2ZSBleHByZXNzZWQgaXNzdWVzIG9uIHRoZSBl bWFpbCBsaXN0cyAtIG1hbnkgb2YgdGhlc2VzIGJlaW5nIGJhc2ljYWxseSBpc3N1ZXMgdGhhdCB3 ZXJlIHJhaXNlZCBvbiB0aGUgbGlzdHMgYmVmb3JlIHRoZSBCT0Ygb3IgYXQgQk9GLg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1hbnkgSUVURiBwZW9wbGUgSSB3b3JrIHdpdGggdmll dyByb3VnaCBjb25zZW5zdXMgYXMgYSBsYXJnZSBwZXJjZW50YWdlIG9mIHRoZSBpbmZvcm1lZCBh bmQgcmVsZXZhbnQgcGVvcGxlIGFncmVlIC0gYW5kIHRoZSBwZW9wbGUgd2l0aCByZWxldmFudCBv YmplY3Rpb25zIGhhdmUgaGFkIGEgY2hhbmNlIHRvIGNvbnZpbmNlIG90aGVycyB0aGV5IGFyZSBz aG91bGQgb2JqZWN0IHRvbyAoc28gdGhleSBhcmUNCiBpbmZvcm1lZCkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj5QRy0mZ3Q7Jm5ic3A7 IFdobyBkZWNpZGVzIHdob20gaXMgaW5mb3JtZWQ/Jm5ic3A7IFdobyBkZWNpZGVzIHRoZSBtZW1i ZXJzaGlwIG9mIOKAnHJlbGV2YW50IHBlb3BsZeKAnT8mbmJzcDsgTm90IHRvIGJlICh0b28pIGlt cGVydGluZW50LCBidXQgYW55IGNoYW5jZSBJIGNhbiBnZXQgYSBsaXN0IG9mIHRoZSBpcnJlbGV2 YW50IHBlb3BsZSBhbmQgdGhlaXIgaXJyZWxldmFudCBvYmplY3Rpb25zPyZuYnNwOw0KIEkgdGhp bmsgSSBjYW4gZ3Vlc3Mgd2hvbSBhcmUgdGhlIHJlbGV2YW50IHBlb3BsZSBhbmQgdGhlaXIgdmll d3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgcG9zaXRpb24gdGhh dCBkZWJhdGUgd2lsbCBjb250aW51ZSB1bnRpbCBldmVyeW9uZSBhZ3JlZXMgaXMgZGVmaW5pdGVs eSBub3QgYSB2aWFibGUgZGVmaW5pdGlvbiBmb3IgYSBTRE8gdGhhdCBpcyB0cnlpbmcgdG8gZ2V0 IHNvbWV0aGluZyBkb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+UEctJmd0 OyZuYnNwOyBBZ3JlZS4mbmJzcDsgVGhlIGd1aWRlbGluZXMgdGhlIElFVEYgYWRvcHRlZCBhbmQg cHVibGlzaGVkIGluIFJGQyA2NzIyIGluZGljYXRlIGNvbXBsZXRlIGFncmVlbWVudCBpcyBub3Qg cmVxdWlyZWQuICZuYnNwO0luc3RlYWQgd2hhdCBpcyByZXF1aXJlZCBpcyBhIOKAnHJvdWdoIGNv bnNlbnN1c+KAnSBkZWZpbmVkIHZhcmlvdXNseSBhcyDigJxhIHZlcnkgbGFyZ2UgbWFqb3JpdHkN CiBvZiB0aG9zZSB3aG8gY2FyZSBtdXN0IGFncmVl4oCdLCBhbmQg4oCcc3Ryb25nbHkgaGVsZCBv YmplY3Rpb25zIG11c3QgYmUgZGViYXRlZCB1bnRpbCBtb3N0IHBlb3BsZSBhcmUgc2F0aXNmaWVk IHRoYXQgdGhlc2Ugb2JqZWN0aW9ucyBhcmUgd3Jvbmcu4oCdJm5ic3A7IE15IHBvaW50IGlzIHRo YXQgZnJvbSB3aGF0IEkgY2FuIHRlbGwgdGhlc2UgZ3VpZGVsaW5lcyBoYXZlIGJlZW4gZGlzbWlz c2VkIGhlcmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIHJlYWxpemUgdGhhdCBtYWtlcyB0aGUgcHJvY2VzcyBl dmVuIGxlc3MgZGV0ZXJtaW5pc3RpYyBidXQgSSBzdXNwZWN0IG1vc3QgcGVvcGxlIGF0IElFVEYg d291bGQgYWdyZWUgdGhhdCBteSBhbnN3ZXIgd2FzIGF0IGxlYXN0IHBhcnQgb2Ygcm91Z2ggY29u c2Vuc3VzLiZuYnNwOyBQYXJ0IG9mIHRoZSByZWFzb24gaXQgaXMgc28gaGFyZCB0byBnZXQgYSBz dHJhaWdodCBhbnN3ZXIgb24gdGhpcyBpcyB0aGUgSUVURg0KIGtlZXBzIHRlbGxpbmcgaXRzZWxm IGl0IGRvZXMgbm90IHZvdGUgdGhvdWdoIHdoZW4geW91IHN0YXJ0IGRlc2NyaWJpbmcgaG93IG1v c3Qgb2Ygb3VyIGltcG9ydGFudCBkZWNpc2lvbnMgYXJlIG1hZGUsIGl0IHN0YXJ0cyB0byBzb3Vu ZCBhIGJpdCBsaWtlIGEgdm90ZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT24gSnVsIDEs IDIwMTUsIGF0IDg6MDMgQU0sIEdvcm1hbiwgUGllcmNlIEEgW0NUT10gJmx0OzxhIGhyZWY9Im1h aWx0bzpQaWVyY2UuR29ybWFuQHNwcmludC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5QaWVyY2UuR29ybWFuQHNwcmludC5jb208L3NwYW4+ PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBbGlzc2Es PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJ4oCZdmUgYWRtaXR0ZWQg YmVmb3JlLCBJ4oCZbSBhIG5vdmljZSBhdCBJRVRGIHByb2NlZHVyZXMuJm5ic3A7IFlvdXIgcmVw ZWF0ZWQgdXNlIG9mIHRoZSBwaHJhc2Ug4oCccm91Z2ggY29uc2Vuc3Vz4oCdIGFzIGEgY29uY2x1 c2lvbiBvZiBmYWN0IGNhdWdodCBteSBhdHRlbnRpb24uJm5ic3A7IEkgd29uZGVyZWQsIGlzIHRo ZXJlIGFueSBJRVRGIGFjY2VwdGVkIGRlZmluaXRpaW9uIG9mIOKAnHJvdWdoIGNvbnNlbnN1c+KA nSB0aGF0IEFsaXNzYQ0KIGFuZCBvdGhlcnMgYXJlIGFkaGVyaW5nIHRvIHRoYXQgSeKAmW0ganVz dCBub3QgYXdhcmUgb2Y/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBB IGxpdHRsZSByZXNlYXJjaCB0dXJuZWQgdXAgYW4gSUVURi5vcmcgZG9jdW1lbnQgYmFzZWQgb24g UkZDIDY3MjIgU2VjdGlvbiA0LjIgZ29pbmcgaW50byBzb21lIGRldGFpbCBvbiB0aGUgdG9waWMg b2Yg4oCcR2V0dGluZyBUaGluZ3MgRG9uZSBpbiBhIFdvcmtpbmcgR3JvdXDigJ0gYXQgVVJMOg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvdGFvLmh0bWwjZ2V0dGluZy50aGluZ3MuZG9u ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL3Rhby5odG1sI2dldHRpbmcudGhpbmdzLmRvbmU8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSeKAmXZlIGNvcGllZC1h bmQtcGFzdGVkIHRoZSBzZW50ZW5jZXMgZnJvbSB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZWN0aW9u IHRoYXQgSSB0aGluayBhcmUgcGFydGljdWxhcmx5IHJlbGV2YW50IHRvIHVuZGVyc3RhbmRpbmcg dGhlIElFVEYg4oCcY29uc2Vuc3Vz4oCdIHZpZXcgb24gdGhlIGRlZmluaXRpb24gb2Yg4oCccm91 Z2ggY29uc2Vuc3Vz4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg 4oCcT25lIGZhY3QgdGhhdCBjb25mdXNlcyBtYW55IG5vdmljZXMgaXMgdGhhdCB0aGUgZmFjZS10 by1mYWNlIFdHIG1lZXRpbmdzIGFyZSBtdWNoIGxlc3MgaW1wb3J0YW50IGluIHRoZSBJRVRGIHRo YW4gdGhleSBhcmUgaW4gbW9zdCBvdGhlciBvcmdhbml6YXRpb25zLiBBbnkgZGVjaXNpb24gbWFk ZSBhdCBhIGZhY2UtdG8tZmFjZSBtZWV0aW5nIG11c3QgYWxzbyBnYWluIGNvbnNlbnN1cyBvbiB0 aGUgV0cNCiBtYWlsaW5nIGxpc3QuIFRoZXJlIGFyZSBudW1lcm91cyBleGFtcGxlcyBvZiBpbXBv cnRhbnQgZGVjaXNpb25zIG1hZGUgaW4gV0cgbWVldGluZ3MgdGhhdCBhcmUgbGF0ZXIgb3ZlcnR1 cm5lZCBvbiB0aGUgbWFpbGluZyBsaXN0LCBvZnRlbiBiZWNhdXNlIHNvbWVvbmUgd2hvIGNvdWxk bid0IGF0dGVuZCB0aGUgbWVldGluZyBwb2ludGVkIG91dCBhIHNlcmlvdXMgZmxhdyBpbiB0aGUg bG9naWMgdXNlZCB0byBjb21lIHRvIHRoZSBkZWNpc2lvbi7igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IOKAnFRoZSBnZW5lcmFsIHJ1bGUgb24gZGlzcHV0ZWQgdG9w aWNzIGlzIHRoYXQgdGhlIFdvcmtpbmcgR3JvdXAgaGFzIHRvIGNvbWUgdG8gJnF1b3Q7cm91Z2gg Y29uc2Vuc3VzJnF1b3Q7LCBtZWFuaW5nIHRoYXQgYSB2ZXJ5IGxhcmdlIG1ham9yaXR5IG9mIHRo b3NlIHdobyBjYXJlIG11c3QgYWdyZWUu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyDigJxSb3VnaCBjb25zZW5zdXMgaGFzIGJlZW4gZGVmaW5lZCBpbiBtYW55IHdh eXM7IGEgc2ltcGxlIHZlcnNpb24gaXMgdGhhdCBpdCBtZWFucyB0aGF0IHN0cm9uZ2x5IGhlbGQg b2JqZWN0aW9ucyBtdXN0IGJlIGRlYmF0ZWQgdW50aWwgbW9zdCBwZW9wbGUgYXJlIHNhdGlzZmll ZCB0aGF0IHRoZXNlIG9iamVjdGlvbnMgYXJlIHdyb25nLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgVGhlcmUgaXMgc29tZSBtb3JlIHZlcmJpYWdlIHJlbGF0ZWQg dG8gdGhlIHVzZSBvZiBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIChXR0xDKSwgYnV0IGl0IGlz buKAmXQgY2xlYXIgaWYgdGhpcyBpcyBiZWZvcmUgb3IgYWZ0ZXIgY2hhcnRlcmluZy4mbmJzcDsg SWYgaXRzIHN1cHBvc2VkIHRvIGJlIGRvbmUgYmVmb3JlLCB3ZSBza2lwcGVkIGl0IEkgdGhpbmsu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgVGFvIGlzIG5vdCBh IGxlZ2FsaXN0aWMgZG9jdW1lbnQgYmFzZWQgb24gcmlnaWQgcGFybGltZW50YXJ5IHByb2NlZHVy ZXMgYW5kIHRoZXJlIGlzIHdoYXQgSSB3aWxsIGNhbGwgYSBwb3dlciBvZiBmaWF0IHdpdGhpbiB0 aGUgSUVTRyBhbmQgdGhlIFdHIGNoYWlycywgbWVhbmluZyB0aGV5IGNhbiBiYXNpY2FsbHkgaWdu b3JlIHRoZSBkZWZpbml0aW9ucyBnaXZlbiBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEkgY2FuIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGFueGlvdXNuZXNzIG9m IG1hbnkgcGFydGljaXBhbnRzIHRvIGVuZCBkZWJhdGUgYW5kIGp1c3QgbW92ZSBvbi4mbmJzcDsg Q29kZSBwcm90b3R5cGluZyBoYXMgYWxyZWFkeSBoYXBwZW5lZCBhbmQgYXZhaWxhYmxlIGZvciBy ZXZpZXcgKGJhc2VkIG9uIHJlcXVlc3Qgb25seSBhbmQgYW4gdW5kZWZpbmVkIGFwcHJvdmFsIHBy b2Nlc3MpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNw OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUmVnYXJkbGVz cywgSSBoYXZlIHRvIGFzaywgdXNpbmcgdGhlIGRlZmluaXRpb25zIG9mIHRoZSBJRVRGIFRhbywg b24gd2hhdCBiYXNpcyBjYW4gaXQgYmUgY2xhaW1lZCB0aGF0IOKAnHJvdWdoIGNvbnNlbnN1c+KA nSBoYXMgYmVlbiBhY2hpZXZlZCBmb3IgdGhlIE1PREVSTiBjaGFydGVyPyZuYnNwOyBGcm9tIHdo YXQgSSBjYW4gdGVsbCBpdCB3YXMgdGhlIHBvd2VyIG9mIGZpYXQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgUGllcmNlIEdvcm1hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBDb3JlIE5ldHdvcmsgUGxhbm5pbmc8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTzogOTEzLTQzOS00MzY4PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpwaWVyY2UuZ29y bWFuQHNwcmludC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5waWVyY2UuZ29ybWFuQHNwcmludC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbHQ7aW1hZ2UwMDEucG5nJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTogTW9kZXJuIFs8YSBo cmVmPSJtYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0 Zi5vcmc8L3NwYW4+PC9hPl0gT24gQmVoYWxmIE9mIEFsaXNzYSBDb29wZXI8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU2VudDogSnVuZSAzMCwgMjAxNSA0OjAx IFBNPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiA8YSBo cmVmPSJtYWlsdG86bW9kZXJuQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bW9kZXJuQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU3ViamVjdDogUmU6IFtNb2Rl cm5dIFtuZXctd29ya10gV0cgUmV2aWV3OiBNYW5hZ2luZywgT3JkZXJpbmcsIERpc3RyaWJ1dGlu ZywgRXhwb3NpbmcsICZhbXA7IFJlZ2lzdGVyaW5nIHRlbGVwaG9uZSBOdW1iZXJzIChtb2Rlcm4p PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJ4oCZZCBsaWtlIHRvIGFz ayB0aGF0IGVhY2ggcGVyc29uIHBhcnRpY2lwYXRpbmcgaW4gdGhpcyBkaXNjdXNzaW9uIHJlbWVt YmVyIHRvIGJlIHJlc3BlY3RmdWwgb2Ygb25lIGFub3RoZXLigJlzIHBvaW50cyBvZiB2aWV3IGFu ZCBmb2N1cyBvbiBjb25zdHJ1Y3RpdmUgZGlhbG9ndWUuIElmIHlvdSBmZWVsIHRoYXQgeW914oCZ cmUgd2FzdGluZyBjeWNsZXMgb24gdGhlIGN1cnJlbnQgdGhyZWFkcyB0aGVuIGZlZWwNCiBmcmVl IHRvIGNoYW5nZSB0aGUgc3ViamVjdCB0byBzb21ldGhpbmcgbW9yZSBwcm9kdWN0aXZlOyBsaWtl d2lzZSBpZiB5b3UgZmVlbCBzb21lb25lIGVsc2UgaXMgd2FzdGluZyB5b3VyIGN5Y2xlcywgZG9u 4oCZdCBmZWVsIGNvbXBlbGxlZCB0byByZXNwb25kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgVG8gcmV2aWV3IHRoZSBwcm9jZXNzIHRoYXQgZ290IHVzIHRvIHRoZSBj dXJyZW50IHBvaW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhl IGNvbmNsdXNpb24gZnJvbSB0aGUgQm9GIGluIERhbGxhcyB3YXMgdGhhdCB0aGVyZSB3YXMgcm91 Z2ggY29uc2Vuc3VzIGluIHRoZSByb29tIGluIHN1cHBvcnQgb2YgZm9ybWluZyB0aGUgV0cgYnV0 IHRoYXQgdGhlIGNoYXJ0ZXIgYW5kIHByb2JsZW0gc2NvcGUgbmVlZGVkIHJlZmluZW1lbnQgKGZl ZWwgZnJlZSB0byByZXZpZXcgdGhlIG1pbnV0ZXM6DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkyL21pbnV0ZXMvbWludXRlcy05Mi1tb2Rlcm4iPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkyL21pbnV0ZXMvbWludXRlcy05Mi1tb2Rlcm48L3NwYW4+PC9hPiku IFRoYXQgcHJvY2VzcyBvZiByZWZpbmVtZW50IHRvb2sgcGxhY2Ugb24gdGhpcyBsaXN0IG92ZXIg c2V2ZXJhbA0KIG1vbnRocyBmb2xsb3dpbmcgdGhlIEJvRi4gVGhlIGNoYXJ0ZXIgd2FzIHB1dCBv dXQgZm9yIHJldmlldyBvbiBKdW5lIDEyIHdpdGggY29tbWVudHMgcmVxdWVzdGVkIHRvIGJlIHNl bnQgdG8gdGhlIElFU0cgYnkgSnVuZSAyMi4gVGhlIElFU0cgY29uc2lkZXJlZCB0aGUgdHdvIElU VS1UIHJlbGF0ZWQgY29tbWVudHMgcmVjZWl2ZWQgKGJvdGggYWZ0ZXIgdGhlIGRlYWRsaW5lKSBh bmQgaXNzdWVkIG5vIGJsb2NraW5nIGNvbW1lbnRzIG9uIHRoZQ0KIGNoYXJ0ZXIgYnV0IGFza2Vk IHRoYXQgZWRpdHMgYmUgY29uc2lkZXJlZCBvbiB0aGUgYmFzaXMgb2YgY29tbWVudHMgcmVjZWl2 ZWQuIFRoZXJlIHdlcmUgbm8gb3RoZXIgY29tbWVudHMgcmVjZWl2ZWQgb3IgaW5kaWNhdGlvbnMg cHJvdmlkZWQgdG8gdGhlIElFU0cgYWJvdXQgdGhlIHJlYWRpbmVzcyBvZiB0aGlzIHdvcmsgZm9y IGNoYXJ0ZXJpbmcuIEnigJltIHN0aWxsIHdvcmtpbmcgb24gZWRpdHMgKFJpY2hhcmQgSGlsbCBw b2ludGVkIG91dCB0aGF0DQogSSBtaXNzZWQgaGlzIHN1Z2dlc3Rpb25zKSBhbmQgbWlsZXN0b25l cyBhcmUgaW4gdGhlIHdvcmtzIGFzIHdlbGwuIFRodXMgdGhpcyBXRyBpcyBiZWluZyBmb3JtZWQg YWNjb3JkaW5nIHRvIHRoZSB1c3VhbCBwcm9jZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgQWxpc3NhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhpcyBlLW1haWwg bWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJv aGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE1vZGVybiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEgaHJlZj0ibWFpbHRvOk1vZGVybkBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pk1vZGVybkBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW9kZXJuIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybjwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNv bG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQg cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg cmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_4161eac2ce1e4b09a172664472416e20PLSWE13M08adsprintcom_-- From nobody Wed Jul 1 13:06:22 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13E01ACD12 for ; Wed, 1 Jul 2015 13:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj8TAv11vUe5 for ; Wed, 1 Jul 2015 13:06:18 -0700 (PDT) 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 98A8D1A8FD7 for ; Wed, 1 Jul 2015 13:06:17 -0700 (PDT) Received: from BY2FFO11OLC009.protection.gbl (10.1.14.34) by BY2FFO11HUB035.protection.gbl (10.1.14.119) with Microsoft SMTP Server (TLS) id 15.1.201.10; Wed, 1 Jul 2015 20:06:15 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; cooperw.in; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm1.corp.sprint.com (144.230.32.80) by BY2FFO11OLC009.mail.protection.outlook.com (10.1.15.0) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 1 Jul 2015 20:06:14 +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 t61K22M8047900; Wed, 1 Jul 2015 16:06:13 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm1.corp.sprint.com with ESMTP id 1v9rabpebt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Jul 2015 16:06:13 -0400 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.1044.25; Wed, 1 Jul 2015 16:06:12 -0400 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.1044.021; Wed, 1 Jul 2015 15:06:12 -0500 From: "Holmes, David W [CTO]" To: Cullen Jennings , "Gorman, Pierce A [CTO]" Thread-Topic: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQtDPvt+fFXxDT7EeO5yugPhGim53HAUbQ Date: Wed, 1 Jul 2015 20:06:11 +0000 Message-ID: <313a3ea588c845e1ad832696e36b13d7@PLSWE13M01.ad.sprint.com> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> In-Reply-To: <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC009; 1:hccPk5hsDSE0fqLmLuhCpqWt7+AxO+P2IXtX2POL4WSEyf5+awCYYCcH+AxVECJmQydxBmoz4zgfN/ShCW+TJnypH6gfzY3ZjUgCrk9wme28u5JdnUdHVqAMe/dB4VgA9GGszoF0Znd8EcCoisRCHhBafKYsVCXwlSk2MyLrR8tUHL0GTYwUE2P0VboFU7bELJFosGve8jQr019OBIr7rhJh3EyZ5SAIzlYgdz8GNeYGc/9+c22J9Q3llhWeOEPsfgY/mC/nhaBXnk2LbZNdo88kZHfV0N3ljIMsIxdOMB2OXjKYlypnPhKeYhDm8Tvo X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(448002)(13464003)(52044002)(51704005)(24454002)(189002)(377454003)(199003)(2950100001)(6806004)(106466001)(33646002)(189998001)(23676002)(93886004)(2900100001)(15975445007)(77156002)(102836002)(62966003)(47776003)(24736003)(5001960100002)(5250100002)(76176999)(5001770100001)(46102003)(106116001)(54356999)(108616004)(19580395003)(19580405001)(85326001)(92566002)(5003600100002)(50986999)(2656002)(86362001)(50466002)(87936001)(437434002)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB035; H:preapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB035; 2:lbWok06FDtFrS+wpGRx+inEMnPWDJhA9OEERHckCWHUYa+/a31aQysuFS+0VhOMe; 3:J51Na1jOUvOdZTbKHJeDVcBT8v+tUELlV+WNCxPQ38ZSJYS0mhIomqw2zUVuHIN8jutLXaGsQtknK61aY3kco4Po6CmhrjzdCGycvrgltecqsz9kDTji7YwxAKEL9yGyrWwA8Ue0xlyeWpBZj4ESOfANkN2bYSUkpz2RF+hqt6uH7wUiloyWLw3Eye3AuXc98BVsVLiat+YCzh45krj5bkP9L5Ga+gdJ2Ifwok/moN0=; 20:vVCPe+FChiz9NVcvRj95kVJaWWUDlko/mjLaBSfIovys54Myof6FASseoZ0wzTNxqL+cknAetNOszE1lzs7x+UZET+1CCcDpxVjorPfJxa6tmsEeCfGMc3/bg6hdSD4BP833lFTXf5S04ykQ+PwpHguMH+5RK2YDgYmjQN2LYDrKZIOMxWzbnC/gFvaa7f7N2erXG2NVX8Ji4L2W7+7gB0zrkmMArXK4HkLD14MhVUS7tIMKMSG5xurlPPo5xgQL; 4:E4nsglsSfXZvotAuC04Z80n1E85XV/NaUvPq7u/nk3y+lyXWzXF7CRi6OeEb0RRyUIUwlr+GwOJQhzgyIyzq0LKLmk/jtcZtb4zcrQR2SAwIkLvj/euRZH/I9X2PizCtirVvDEx1jghP4X3XphWMneYGXWRmkurn0b43f84Yz4NuY/Tmnghq8k5VP0qAdRSHzdfAAa+H2S93SeijlgpVq5sR24CsFQSAmcW6GkSoGld9AIJKS3/Lwsz+VpIyCFtVNjbom+NRuM551K8sB1mMo4sZdMMVLWVPXUrvfEdK4sA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB035; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB035; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB035; X-Forefront-PRVS: 0624A2429E X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJGRk8xMUhVQjAzNTsyMzpTV3ErVU5ZbU1UUFhkK0MrYU9BQkV4SE5K?= =?utf-8?B?KytUZzZ0dmxkNGk0dHlhSUQveGhYS05jUk1way9CZXNqR0pKajE2UTFDMmxs?= =?utf-8?B?RDltZ2tObDVqNGdvL0w0VUNwSE8xM0Z4c0VBa082MXVycWt1TzJCc2NnelVx?= =?utf-8?B?b3FuZ25NSStmQUtkZ045WWJkTDNxMFQzamZQNVQyYUNOMi9JWXBuc0xiRFZu?= =?utf-8?B?S3RRd2tkbnJ2aFRJQVBtcWdQZU9YR1VWMDNxQnNrcjRFaVh4OVFVN0t6R2pj?= =?utf-8?B?amxBd0tKZC9KT0x3T2QwV3ppeWZUSHZGK1JwNHZXQVp6eGMrSG02eFhwSW92?= =?utf-8?B?SllhNVBVc2d1UXk5Mkx2eDlZbmhvQ3p5c29SNk1jYmpVT0szVXR5WTRKQXNT?= =?utf-8?B?WEc4MkorSDNGZUJEMlVMYVpHQW0xczROL2hNS245M08zNGJjLzNYTS9NeXZX?= =?utf-8?B?NzgxbzFxU3JPUW9RV0hIYWM2YXNjZFo2YUgzL1hxdExyakczQnJFSmJWMS9M?= =?utf-8?B?b3hvMUgxOUtKOUV6S3UrajRnRE5WYmpwdVloQUlXTjFaNExCaHhvQVVzdUxD?= =?utf-8?B?aHZ6TXUxUXM1bVF0NHlXRitzTzFYQkEybFVLdjI5YkJGQUtvY0ZLSTJ3Q2lB?= =?utf-8?B?aktxRFJVcWdmbFl5b2NCMDFMRXRGY1g0bnEyN0hWZmVYWVdTS1R2K3Yra0hv?= =?utf-8?B?TEhPTkhzR0V2NnRpaTlEVEVUdCtjNGVxQnBOZXduYkdlU21iaHc5SG0yYi9a?= =?utf-8?B?dFJQZG9DUWJJNU5TTFJ5R2t0WDExbzQ0Z0ZleTgxRnJ3MU5wYi9DWE1QUlM5?= =?utf-8?B?Uk5QWkV1SC9HWDJjeHRIUElXejFhTUd6bnl4TTZoSG5CRHh0SC9jQW0vamtX?= =?utf-8?B?ZUtHMGhtQVMvMEtXb21tRWI1NjYzVnZtQnViNlJ0bkVoMWpBTC8vUVNRV2lN?= =?utf-8?B?bW0vOW92REN6VkMwZU8wdW9QQmNJWkFUaWo3T3ZOOGtKLzRFRTZnT1E4T0ZC?= =?utf-8?B?S21lekpkMlpHUGdzQ01zZW1pVlRHSkZDbmNFWDA4QnQxZktaWUdMSkQrb2lC?= =?utf-8?B?aHBNZFVZVE4zK3lrSFF1aWxDYWJVUVZyOTZ1bUR3bE1RdFIxSXEyWGhyQmdy?= =?utf-8?B?K0pzdzF6OU8rTlhUVG8wditMQ2VjV2F2Q0dqZUlYeUN1NnUycEpBVm5tSnpH?= =?utf-8?B?YnpvaWh5dm1oRkdMN3RNN0p6SVpWREFRdE0wNFhnQ29yVm8rK2htcFo1cDJz?= =?utf-8?B?RzEyc1RkVDE4V3F6ZVJpeENnVWRldUw1VlpyZi9RU3FURVFxbnBZNUtKZ2Rn?= =?utf-8?B?V0VGamtUODdYa1IyTzZsM2pIV2hwNkNyU3hUc245c3dhOEM2aGxKZVVyZWhy?= =?utf-8?B?aUhtbU1yTVNVdnZnSVhqakJvNGNTQ1daM0czYUwrM0wrSk10MFRMM0ZrUCtL?= =?utf-8?B?OUZEbmxPLy9HbWJMNHlvRXh3TFBhUSszbFh5dUFHNU9yUlc1aWVJSVVnbzRY?= =?utf-8?B?clZPL21pbmtMQWlDQkxuTGYzTFFLS2UxWVZMQ2hvdGhLN203dHNMQ3pJdDJE?= =?utf-8?B?S1N2YjFxc09kMjdEK1MyaUdtRHhGVmNnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB035; 5:opT2MQK10F2v0GxnbNhwzh6XTbRzeg3L/EAzkTObkFRZ+uvi0m25h7jUAwQ3MK7nYHjgwPIOfqQCP6NacD2CfpBo/K29yjo2UdhKGBj9HFI+IPxJZSMXy/NDFcoeovCRx5OZOPqdULvOFoiS2iWIrQ==; 24:3OmtDU0/GlM8Sgpkp+G6IdaX0VhMoFKrPbdCVP9LThQKQrUYevcqDBfLmhWyyeihsU3dLaUUdE3cC7bzHPw5szPgPmJc3i23jyHvjTj7eK0= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2015 20:06:14.6558 (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: BY2FFO11HUB035 Archived-At: Cc: Alissa Cooper , "modern@ietf.org" Subject: Re: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 20:06:20 -0000 Q3VsbGVuLA0KDQpJIGJlbGlldmUgdGhlIHNwZWNpZmljIGlzc3VlIGhlcmUgaXMgdGhhdCB0aGUg YXJlYSBvZiBpbnRlcmVzdCBmb3IgTU9ERVJOLCB0ZWxlcGhvbmUgbnVtYmVyIGFkbWluaXN0cmF0 aW9uLCBpcyByZWdhcmRlZCBnZW5lcmFsbHkgaW4gdGhlIGluZHVzdHJ5IGFzIGJlaW5nIGF0IHRo ZSBtYXJnaW5zIG9mIElFVEYgaW5mbHVlbmNlLCBidXQgaXMgdmVyeSBtYWluc3RyZWFtIGluIG90 aGVyIGluZHVzdHJ5IG9yZ2FuaXphdGlvbnMuICBUaGVyZWZvcmUgdGhlIGJhbGFuY2Ugb2YgaW50 ZXJlc3RzIGJldHdlZW4gdGhlIEZ0RiBhdHRlbmRlZXMgdG8gdGhlIEJvRiAmIHRoZSBwYXJ0aWNp cGFudHMgb24gdGhpcyByZWZsZWN0b3IgYXJlIHNvbWV3aGF0IHNrZXdlZDsgc3BlY2lmaWNhbGx5 LCB0aGUgRnRGIHdpbGwgdGVuZCB0byBiZSBhdHRlbmRlZCBieSBJRVRGLWNlbnRyaWMgcGFydGll cywgd2hlcmVhcyB0aGUgcmVmbGVjdG9yIHBvcHVsYXRpb24gYXBwZWFycyB0byBtb3JlIGNsb3Nl bHkgcmVwcmVzZW50IHRoZSBvcmdhbml6YXRpb25zIHRoYXQgaGF2ZSBhIGRlbW9uc3RyYXRlZCBp bnRlcmVzdCBpbiBUTiBhZG1pbmlzdHJhdGlvbi4NCg0KSSB3b3VsZCBhbHNvIG5vdGUgdGhhdCB0 aGUgaGlnaGx5IHBhcmFsbGVsIHNjaGVkdWxpbmcgb2YgdGhlIEZ0RiBtZWV0aW5ncyB3aXRoaW4g dGhlIElFVEYgbWVldGluZyB3ZWVrcyBjYW4gbWFrZSBpdCB2ZXJ5IGRpZmZpY3VsdCBmb3Igb3Jn YW5pemF0aW9ucyB3aXRoIGxpZ2h0IHJlcHJlc2VudGF0aW9uIHRvIGJlIHByZXNlbnQgYXQgYWxs IHRob3NlIHNlc3Npb25zIHRoYXQgdGhleSB3b3VsZCBkZXNpcmUuICBJbiB0aGlzIGNhc2UgdGhl IEJvRiB3YXMgc2NoZWR1bGVkIGFsb25nc2lkZSBvdGhlciBzZXNzaW9ucyB0aGF0IHdlcmUgb2Yg aGlnaCBpbnRlcmVzdCB0byB0ZWxjb3MsIHNvIFNwcmludCwgZm9yIG9uZSwgY291bGQgbm90IGJl IHJlcHJlc2VudGVkIHRoZXJlLg0KDQpTbyBnaXZlbiB0aGVzZSBjb25zaWRlcmF0aW9ucywgYW5k IHRodXMgd2VpZ2h0aW5nIHRoZSBGdEYgJiByZWZsZWN0b3IgZGlzY3Vzc2lvbnMsIGRvIHdlIHJl YWxseSBmZWVsIHRoYXQgd2UgaGF2ZSAiYSBsYXJnZSBudW1iZXIgb2YgaW5mb3JtZWQgJiByZWxl dmFudCBwZW9wbGUiIGFncmVlaW5nIHRvIHByb3ZpZGUgInJvdWdoIGNvbnNlbnN1cyI/ICAoQW4g ZW50aXJlbHkgb3BlbiBxdWVzdGlvbikuDQoNCkJSL0RhdmlkIEhvbG1lcw0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTW9kZXJuIFttYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDdWxsZW4gSmVubmluZ3MNClNlbnQ6IFdlZG5lc2RheSwgSnVs eSAwMSwgMjAxNSAzOjI3IFBNDQpUbzogR29ybWFuLCBQaWVyY2UgQSBbQ1RPXQ0KQ2M6IG1vZGVy bkBpZXRmLm9yZzsgQWxpc3NhIENvb3Blcg0KU3ViamVjdDogW01vZGVybl0gUm91Z2ggY29uc2Vu c3VzIC0gUmU6IFtuZXctd29ya10gV0cgUmV2aWV3OiBNYW5hZ2luZywgT3JkZXJpbmcsIERpc3Ry aWJ1dGluZywgRXhwb3NpbmcsICYgUmVnaXN0ZXJpbmcgdGVsZXBob25lIE51bWJlcnMgKG1vZGVy bikNCg0KDQpUaGlzIHRvcGljIGlzIGNvbXBsaWNhdGVkIGFuZCB0aGVyZSBpcyBub3QgYSBwZXJm ZWN0IGFuc3dlciB0byB3aGF0IHJvdWdoIGNvbnNlbnN1cyBpcy4gSSBzdXNwZWN0IHRoYXQgaW4g dGhpcyBjYXNlIGl0IGlzIGZvcm1lZCBieSBhIGNvbWJpbmF0aW9uIG9mIHRoZSB2aWV3cyBvZiBw ZW9wbGUgdGhhdCB3ZXJlIGF0IHRoZSBCT0YgYW5kIHdoYXQgaGFzIGJlZW4gZXhwcmVzc2VkIG9u IGVtYWlsIGxpc3RzLiBLZWVwIGluIG1pbmQgYSBsb3Qgb2YgcGVvcGxlIGluIHRoYXQgcm9vbSBl eHByZXNzZWQgc3VwcG9ydCBmb3IgdGhpcy4gU29tZSBwZW9wbGUgaGF2ZSBleHByZXNzZWQgaXNz dWVzIG9uIHRoZSBlbWFpbCBsaXN0cyAtIG1hbnkgb2YgdGhlc2VzIGJlaW5nIGJhc2ljYWxseSBp c3N1ZXMgdGhhdCB3ZXJlIHJhaXNlZCBvbiB0aGUgbGlzdHMgYmVmb3JlIHRoZSBCT0Ygb3IgYXQg Qk9GLg0KDQpNYW55IElFVEYgcGVvcGxlIEkgd29yayB3aXRoIHZpZXcgcm91Z2ggY29uc2Vuc3Vz IGFzIGEgbGFyZ2UgcGVyY2VudGFnZSBvZiB0aGUgaW5mb3JtZWQgYW5kIHJlbGV2YW50IHBlb3Bs ZSBhZ3JlZSAtIGFuZCB0aGUgcGVvcGxlIHdpdGggcmVsZXZhbnQgb2JqZWN0aW9ucyBoYXZlIGhh ZCBhIGNoYW5jZSB0byBjb252aW5jZSBvdGhlcnMgdGhleSBhcmUgc2hvdWxkIG9iamVjdCB0b28g KHNvIHRoZXkgYXJlIGluZm9ybWVkKS4gVGhlIHBvc2l0aW9uIHRoYXQgZGViYXRlIHdpbGwgY29u dGludWUgdW50aWwgZXZlcnlvbmUgYWdyZWVzIGlzIGRlZmluaXRlbHkgbm90IGEgdmlhYmxlIGRl ZmluaXRpb24gZm9yIGEgU0RPIHRoYXQgaXMgdHJ5aW5nIHRvIGdldCBzb21ldGhpbmcgZG9uZS4N Cg0KSSByZWFsaXplIHRoYXQgbWFrZXMgdGhlIHByb2Nlc3MgZXZlbiBsZXNzIGRldGVybWluaXN0 aWMgYnV0IEkgc3VzcGVjdCBtb3N0IHBlb3BsZSBhdCBJRVRGIHdvdWxkIGFncmVlIHRoYXQgbXkg YW5zd2VyIHdhcyBhdCBsZWFzdCBwYXJ0IG9mIHJvdWdoIGNvbnNlbnN1cy4gIFBhcnQgb2YgdGhl IHJlYXNvbiBpdCBpcyBzbyBoYXJkIHRvIGdldCBhIHN0cmFpZ2h0IGFuc3dlciBvbiB0aGlzIGlz IHRoZSBJRVRGIGtlZXBzIHRlbGxpbmcgaXRzZWxmIGl0IGRvZXMgbm90IHZvdGUgdGhvdWdoIHdo ZW4geW91IHN0YXJ0IGRlc2NyaWJpbmcgaG93IG1vc3Qgb2Ygb3VyIGltcG9ydGFudCBkZWNpc2lv bnMgYXJlIG1hZGUsIGl0IHN0YXJ0cyB0byBzb3VuZCBhIGJpdCBsaWtlIGEgdm90ZS4NCg0KDQo+ IE9uIEp1bCAxLCAyMDE1LCBhdCA4OjAzIEFNLCBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIDxQaWVy Y2UuR29ybWFuQHNwcmludC5jb20+IHdyb3RlOg0KPg0KPiBBbGlzc2EsDQo+DQo+IEnigJl2ZSBh ZG1pdHRlZCBiZWZvcmUsIEnigJltIGEgbm92aWNlIGF0IElFVEYgcHJvY2VkdXJlcy4gIFlvdXIg cmVwZWF0ZWQgdXNlIG9mIHRoZSBwaHJhc2Ug4oCccm91Z2ggY29uc2Vuc3Vz4oCdIGFzIGEgY29u Y2x1c2lvbiBvZiBmYWN0IGNhdWdodCBteSBhdHRlbnRpb24uICBJIHdvbmRlcmVkLCBpcyB0aGVy ZSBhbnkgSUVURiBhY2NlcHRlZCBkZWZpbml0aWlvbiBvZiDigJxyb3VnaCBjb25zZW5zdXPigJ0g dGhhdCBBbGlzc2EgYW5kIG90aGVycyBhcmUgYWRoZXJpbmcgdG8gdGhhdCBJ4oCZbSBqdXN0IG5v dCBhd2FyZSBvZj8NCj4NCj4gQSBsaXR0bGUgcmVzZWFyY2ggdHVybmVkIHVwIGFuIElFVEYub3Jn IGRvY3VtZW50IGJhc2VkIG9uIFJGQyA2NzIyIFNlY3Rpb24gNC4yIGdvaW5nIGludG8gc29tZSBk ZXRhaWwgb24gdGhlIHRvcGljIG9mIOKAnEdldHRpbmcgVGhpbmdzIERvbmUgaW4gYSBXb3JraW5n IEdyb3Vw4oCdIGF0IFVSTDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvdGFvLmh0bWwjZ2V0dGluZy50 aGluZ3MuZG9uZQ0KPg0KPiBJ4oCZdmUgY29waWVkLWFuZC1wYXN0ZWQgdGhlIHNlbnRlbmNlcyBm cm9tIHRoZSBiZWdpbm5pbmcgb2YgdGhlIHNlY3Rpb24gdGhhdCBJIHRoaW5rIGFyZSBwYXJ0aWN1 bGFybHkgcmVsZXZhbnQgdG8gdW5kZXJzdGFuZGluZyB0aGUgSUVURiDigJxjb25zZW5zdXPigJ0g dmlldyBvbiB0aGUgZGVmaW5pdGlvbiBvZiDigJxyb3VnaCBjb25zZW5zdXPigJ0uDQo+DQo+IOKA nE9uZSBmYWN0IHRoYXQgY29uZnVzZXMgbWFueSBub3ZpY2VzIGlzIHRoYXQgdGhlIGZhY2UtdG8t ZmFjZSBXRyBtZWV0aW5ncyBhcmUgbXVjaCBsZXNzIGltcG9ydGFudCBpbiB0aGUgSUVURiB0aGFu IHRoZXkgYXJlIGluIG1vc3Qgb3RoZXIgb3JnYW5pemF0aW9ucy4gQW55IGRlY2lzaW9uIG1hZGUg YXQgYSBmYWNlLXRvLWZhY2UgbWVldGluZyBtdXN0IGFsc28gZ2FpbiBjb25zZW5zdXMgb24gdGhl IFdHIG1haWxpbmcgbGlzdC4gVGhlcmUgYXJlIG51bWVyb3VzIGV4YW1wbGVzIG9mIGltcG9ydGFu dCBkZWNpc2lvbnMgbWFkZSBpbiBXRyBtZWV0aW5ncyB0aGF0IGFyZSBsYXRlciBvdmVydHVybmVk IG9uIHRoZSBtYWlsaW5nIGxpc3QsIG9mdGVuIGJlY2F1c2Ugc29tZW9uZSB3aG8gY291bGRuJ3Qg YXR0ZW5kIHRoZSBtZWV0aW5nIHBvaW50ZWQgb3V0IGEgc2VyaW91cyBmbGF3IGluIHRoZSBsb2dp YyB1c2VkIHRvIGNvbWUgdG8gdGhlIGRlY2lzaW9uLuKAnQ0KPg0KPiDigJxUaGUgZ2VuZXJhbCBy dWxlIG9uIGRpc3B1dGVkIHRvcGljcyBpcyB0aGF0IHRoZSBXb3JraW5nIEdyb3VwIGhhcyB0byBj b21lIHRvICJyb3VnaCBjb25zZW5zdXMiLCBtZWFuaW5nIHRoYXQgYSB2ZXJ5IGxhcmdlIG1ham9y aXR5IG9mIHRob3NlIHdobyBjYXJlIG11c3QgYWdyZWUu4oCdDQo+DQo+IOKAnFJvdWdoIGNvbnNl bnN1cyBoYXMgYmVlbiBkZWZpbmVkIGluIG1hbnkgd2F5czsgYSBzaW1wbGUgdmVyc2lvbiBpcyB0 aGF0IGl0IG1lYW5zIHRoYXQgc3Ryb25nbHkgaGVsZCBvYmplY3Rpb25zIG11c3QgYmUgZGViYXRl ZCB1bnRpbCBtb3N0IHBlb3BsZSBhcmUgc2F0aXNmaWVkIHRoYXQgdGhlc2Ugb2JqZWN0aW9ucyBh cmUgd3Jvbmcu4oCdDQo+DQo+IFRoZXJlIGlzIHNvbWUgbW9yZSB2ZXJiaWFnZSByZWxhdGVkIHRv IHRoZSB1c2Ugb2YgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCAoV0dMQyksIGJ1dCBpdCBpc27i gJl0IGNsZWFyIGlmIHRoaXMgaXMgYmVmb3JlIG9yIGFmdGVyIGNoYXJ0ZXJpbmcuICBJZiBpdHMg c3VwcG9zZWQgdG8gYmUgZG9uZSBiZWZvcmUsIHdlIHNraXBwZWQgaXQgSSB0aGluay4NCj4NCj4g VGhlIFRhbyBpcyBub3QgYSBsZWdhbGlzdGljIGRvY3VtZW50IGJhc2VkIG9uIHJpZ2lkIHBhcmxp bWVudGFyeSBwcm9jZWR1cmVzIGFuZCB0aGVyZSBpcyB3aGF0IEkgd2lsbCBjYWxsIGEgcG93ZXIg b2YgZmlhdCB3aXRoaW4gdGhlIElFU0cgYW5kIHRoZSBXRyBjaGFpcnMsIG1lYW5pbmcgdGhleSBj YW4gYmFzaWNhbGx5IGlnbm9yZSB0aGUgZGVmaW5pdGlvbnMgZ2l2ZW4gYWJvdmUuDQo+DQo+IEkg Y2FuIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGFueGlvdXNuZXNzIG9mIG1hbnkgcGFydGljaXBhbnRz IHRvIGVuZCBkZWJhdGUgYW5kIGp1c3QgbW92ZSBvbi4gIENvZGUgcHJvdG90eXBpbmcgaGFzIGFs cmVhZHkgaGFwcGVuZWQgYW5kIGF2YWlsYWJsZSBmb3IgcmV2aWV3IChiYXNlZCBvbiByZXF1ZXN0 IG9ubHkgYW5kIGFuIHVuZGVmaW5lZCBhcHByb3ZhbCBwcm9jZXNzKS4NCj4NCj4gUmVnYXJkbGVz cywgSSBoYXZlIHRvIGFzaywgdXNpbmcgdGhlIGRlZmluaXRpb25zIG9mIHRoZSBJRVRGIFRhbywg b24gd2hhdCBiYXNpcyBjYW4gaXQgYmUgY2xhaW1lZCB0aGF0IOKAnHJvdWdoIGNvbnNlbnN1c+KA nSBoYXMgYmVlbiBhY2hpZXZlZCBmb3IgdGhlIE1PREVSTiBjaGFydGVyPyAgRnJvbSB3aGF0IEkg Y2FuIHRlbGwgaXQgd2FzIHRoZSBwb3dlciBvZiBmaWF0Lg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+ DQo+DQo+IFBpZXJjZSBHb3JtYW4NCj4gQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQo+IE86IDkxMy00 MzktNDM2OA0KPiBwaWVyY2UuZ29ybWFuQHNwcmludC5jb20NCj4gPGltYWdlMDAxLnBuZz4NCj4N Cj4gRnJvbTogTW9kZXJuIFttYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbGlzc2EgQ29vcGVyDQo+IFNlbnQ6IEp1bmUgMzAsIDIwMTUgNDowMSBQTQ0KPiBUbzog bW9kZXJuQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBbbmV3LXdvcmtdIFdHIFJl dmlldzogTWFuYWdpbmcsIE9yZGVyaW5nLCBEaXN0cmlidXRpbmcsIEV4cG9zaW5nLCAmIFJlZ2lz dGVyaW5nIHRlbGVwaG9uZSBOdW1iZXJzIChtb2Rlcm4pDQo+DQo+IEnigJlkIGxpa2UgdG8gYXNr IHRoYXQgZWFjaCBwZXJzb24gcGFydGljaXBhdGluZyBpbiB0aGlzIGRpc2N1c3Npb24gcmVtZW1i ZXIgdG8gYmUgcmVzcGVjdGZ1bCBvZiBvbmUgYW5vdGhlcuKAmXMgcG9pbnRzIG9mIHZpZXcgYW5k IGZvY3VzIG9uIGNvbnN0cnVjdGl2ZSBkaWFsb2d1ZS4gSWYgeW91IGZlZWwgdGhhdCB5b3XigJly ZSB3YXN0aW5nIGN5Y2xlcyBvbiB0aGUgY3VycmVudCB0aHJlYWRzIHRoZW4gZmVlbCBmcmVlIHRv IGNoYW5nZSB0aGUgc3ViamVjdCB0byBzb21ldGhpbmcgbW9yZSBwcm9kdWN0aXZlOyBsaWtld2lz ZSBpZiB5b3UgZmVlbCBzb21lb25lIGVsc2UgaXMgd2FzdGluZyB5b3VyIGN5Y2xlcywgZG9u4oCZ dCBmZWVsIGNvbXBlbGxlZCB0byByZXNwb25kLg0KPg0KPiBUbyByZXZpZXcgdGhlIHByb2Nlc3Mg dGhhdCBnb3QgdXMgdG8gdGhlIGN1cnJlbnQgcG9pbnQ6DQo+DQo+IFRoZSBjb25jbHVzaW9uIGZy b20gdGhlIEJvRiBpbiBEYWxsYXMgd2FzIHRoYXQgdGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBp biB0aGUgcm9vbSBpbiBzdXBwb3J0IG9mIGZvcm1pbmcgdGhlIFdHIGJ1dCB0aGF0IHRoZSBjaGFy dGVyIGFuZCBwcm9ibGVtIHNjb3BlIG5lZWRlZCByZWZpbmVtZW50IChmZWVsIGZyZWUgdG8gcmV2 aWV3IHRoZSBtaW51dGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL21pbnV0 ZXMvbWludXRlcy05Mi1tb2Rlcm4pLiBUaGF0IHByb2Nlc3Mgb2YgcmVmaW5lbWVudCB0b29rIHBs YWNlIG9uIHRoaXMgbGlzdCBvdmVyIHNldmVyYWwgbW9udGhzIGZvbGxvd2luZyB0aGUgQm9GLiBU aGUgY2hhcnRlciB3YXMgcHV0IG91dCBmb3IgcmV2aWV3IG9uIEp1bmUgMTIgd2l0aCBjb21tZW50 cyByZXF1ZXN0ZWQgdG8gYmUgc2VudCB0byB0aGUgSUVTRyBieSBKdW5lIDIyLiBUaGUgSUVTRyBj b25zaWRlcmVkIHRoZSB0d28gSVRVLVQgcmVsYXRlZCBjb21tZW50cyByZWNlaXZlZCAoYm90aCBh ZnRlciB0aGUgZGVhZGxpbmUpIGFuZCBpc3N1ZWQgbm8gYmxvY2tpbmcgY29tbWVudHMgb24gdGhl IGNoYXJ0ZXIgYnV0IGFza2VkIHRoYXQgZWRpdHMgYmUgY29uc2lkZXJlZCBvbiB0aGUgYmFzaXMg b2YgY29tbWVudHMgcmVjZWl2ZWQuIFRoZXJlIHdlcmUgbm8gb3RoZXIgY29tbWVudHMgcmVjZWl2 ZWQgb3IgaW5kaWNhdGlvbnMgcHJvdmlkZWQgdG8gdGhlIElFU0cgYWJvdXQgdGhlIHJlYWRpbmVz cyBvZiB0aGlzIHdvcmsgZm9yIGNoYXJ0ZXJpbmcuIEnigJltIHN0aWxsIHdvcmtpbmcgb24gZWRp dHMgKFJpY2hhcmQgSGlsbCBwb2ludGVkIG91dCB0aGF0IEkgbWlzc2VkIGhpcyBzdWdnZXN0aW9u cykgYW5kIG1pbGVzdG9uZXMgYXJlIGluIHRoZSB3b3JrcyBhcyB3ZWxsLiBUaHVzIHRoaXMgV0cg aXMgYmVpbmcgZm9ybWVkIGFjY29yZGluZyB0byB0aGUgdXN1YWwgcHJvY2Vzcy4NCj4NCj4gQWxp c3NhDQo+DQo+DQo+IFRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocyku IEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwg Y29waWVzIG9mIHRoZSBtZXNzYWdlLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBNb2Rlcm4gbWFpbGluZyBsaXN0DQo+IE1vZGVybkBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTW9kZXJuIG1haWxp bmcgbGlzdA0KTW9kZXJuQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21vZGVybg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlz IGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5k ZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVy cyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVz c2FnZS4NCg== From nobody Wed Jul 1 13:41:54 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB211A036E for ; Wed, 1 Jul 2015 13:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 hOJf8VL_9_GT for ; Wed, 1 Jul 2015 13:41:49 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B8B1A00E0 for ; Wed, 1 Jul 2015 13:41:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 491EB20B56 for ; Wed, 1 Jul 2015 16:41:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 01 Jul 2015 16:41:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=15Jib EuGOBNbi1RO97fTonD+WAY=; b=BsBTDcJNNyAxhAwk9OKz9dETqKxMkJe0uOhK2 EvXAkP0QQFU5fry1WFN9is9ogZ+KY+9EG2peab6xVXw7prv+szmTj4+Hji0/CTqv zhmm7Sdo4HPBqVDqd64Ryizie3C+EuBZQMcAPkjBOYPatW3ZEjzhOS9KldcBokuB Pz3Nws= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=15JibEuGOBNbi1RO97fTonD+WAY=; b=TX7bU kdpAa6XPfuFf6SCHpY3OYwbWjuvLcM9MW45VzxBBYn5TYfPfUfdIZuaGHVo4+ipt 6tm2DFTHBImYgNZ2TTxx66eBtku1bCPQRktAbM+lqC2NJj1YTcMwW1niDo9Bvl5B ZE6mAa973LOSj6VhCHPwPaM1BN1DDjzm03tvXE= X-Sasl-enc: +i7vg/bKLkQZ5UGEmodEBAmPjRiAi1/5oYC0jNkZwggw 1435783307 Received: from dhcp-171-68-20-90.cisco.com (unknown [171.68.20.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 5F29268014F; Wed, 1 Jul 2015 16:41:47 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C054492D-4F12-4D56-98E5-EA5A8D213C4D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> Date: Wed, 1 Jul 2015 13:41:45 -0700 Message-Id: <44B5B04E-283D-43D3-B466-ACE5691C3150@cooperw.in> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> To: "Gorman, Pierce A [CTO]" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "modern@ietf.org" Subject: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 20:41:52 -0000 --Apple-Mail=_C054492D-4F12-4D56-98E5-EA5A8D213C4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Pierce, As you=92ve discovered there is no normative definition of =93rough = consensus=94 in the IETF. There are informational descriptions in = various places, some of which go on at length and may be interesting = reading if you=92re looking for different perspectives (e.g., RFC 7282). = But there is no normative definition. I will note that in my message that you quote below, I chose my words = carefully. I said there was rough consensus in the room in Dallas in = support of forming the WG, pending charter and scope edits. This is what = was reported in the minutes, which I linked to. As I=92ve noted before, = I was not there in Dallas since I was on leave (and the audio recording = for that portion is cut off unfortunately), but I trust that the minutes = were reported correctly. Ben was shepherding this work until I came back = from leave in June. As Ben pointed out on this mailing list in April, there is no notion of = WG consensus until there is a WG. The decision to form a WG certainly = must be informed by the level of support demonstrated in the community = for the work. But such decisions generally also take other factors into = account, as reflected in the RFC 2418 questions and the BoF questions = and answers listed in the minutes for this BoF.=20 The decision to form a WG ultimately rests with the IESG, as Adam noted. = The MODERN charter went before the IESG after several months of = iterations and editing resulting from discussions on this list (some of = which I see that you were involved in). As I noted in an earlier mail, = the IESG asked for comments on the charter and did not receive a single = one within the time frame requested. Two came in late and resulting = edits are being worked into the charter.=20 So to summarize, there was a BoF where rough consensus existed in the = room to form the WG pending charter edits and where a sizable group of = volunteers demonstrated interest in authoring and editing the documents, = there were then many months of discussion on this list (which is open to = all) about the viability of the WG and the scope of the charter, there = was a standard charter review period conducted by the IESG that elicited = comments from two commenters, one of whom objected on grounds that had = been previously thoroughly discussed by participants on the list and in = person, and the WG has now been approved for formation by the IESG = pending further charter edits stemming from these comments. I have a = hard time seeing how this equates to WG formation by fiat. It certainly = does not equate to unanimous support for the WG=92s formation, but that = has never been a requirement. Lastly, I=92m not sure what you mean by an =93undefined approval = process=94 for =93code prototyping,=94 but I will note that the IETF has = no role whatsoever in determining who decides to implement what, when, = or how. Cheers, Alissa On Jul 1, 2015, at 8:03 AM, Gorman, Pierce A [CTO] = wrote: > Alissa, > =20 > I=92ve admitted before, I=92m a novice at IETF procedures. Your = repeated use of the phrase =93rough consensus=94 as a conclusion of fact = caught my attention. I wondered, is there any IETF accepted definitiion = of =93rough consensus=94 that Alissa and others are adhering to that I=92m= just not aware of? > =20 > A little research turned up an IETF.org document based on RFC 6722 = Section 4.2 going into some detail on the topic of =93Getting Things = Done in a Working Group=94 at = URL:https://www.ietf.org/tao.html#getting.things.done > =20 > I=92ve copied-and-pasted the sentences from the beginning of the = section that I think are particularly relevant to understanding the IETF = =93consensus=94 view on the definition of =93rough consensus=94. > =20 > =93One fact that confuses many novices is that the face-to-face WG = meetings are much less important in the IETF than they are in most other = organizations. Any decision made at a face-to-face meeting must also = gain consensus on the WG mailing list. There are numerous examples of = important decisions made in WG meetings that are later overturned on the = mailing list, often because someone who couldn't attend the meeting = pointed out a serious flaw in the logic used to come to the decision.=94 > =20 > =93The general rule on disputed topics is that the Working Group has = to come to "rough consensus", meaning that a very large majority of = those who care must agree.=94 > =20 > =93Rough consensus has been defined in many ways; a simple version is = that it means that strongly held objections must be debated until most = people are satisfied that these objections are wrong.=94 > =20 > There is some more verbiage related to the use of a Working Group Last = Call (WGLC), but it isn=92t clear if this is before or after chartering. = If its supposed to be done before, we skipped it I think. > =20 > The Tao is not a legalistic document based on rigid parlimentary = procedures and there is what I will call a power of fiat within the IESG = and the WG chairs, meaning they can basically ignore the definitions = given above. > =20 > I can fully understand the anxiousness of many participants to end = debate and just move on. Code prototyping has already happened and = available for review (based on request only and an undefined approval = process). > =20 > Regardless, I have to ask, using the definitions of the IETF Tao, on = what basis can it be claimed that =93rough consensus=94 has been = achieved for the MODERN charter? =46rom what I can tell it was the = power of fiat. > =20 > Best regards, > =20 > =20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > =20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa = Cooper > Sent: June 30, 2015 4:01 PM > To: modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) > =20 > I=92d like to ask that each person participating in this discussion = remember to be respectful of one another=92s points of view and focus on = constructive dialogue. If you feel that you=92re wasting cycles on the = current threads then feel free to change the subject to something more = productive; likewise if you feel someone else is wasting your cycles, = don=92t feel compelled to respond. > =20 > To review the process that got us to the current point: > =20 > The conclusion from the BoF in Dallas was that there was rough = consensus in the room in support of forming the WG but that the charter = and problem scope needed refinement (feel free to review the minutes: = http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That = process of refinement took place on this list over several months = following the BoF. The charter was put out for review on June 12 with = comments requested to be sent to the IESG by June 22. The IESG = considered the two ITU-T related comments received (both after the = deadline) and issued no blocking comments on the charter but asked that = edits be considered on the basis of comments received. There were no = other comments received or indications provided to the IESG about the = readiness of this work for chartering. I=92m still working on edits = (Richard Hill pointed out that I missed his suggestions) and milestones = are in the works as well. Thus this WG is being formed according to the = usual process. > =20 > Alissa >=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. --Apple-Mail=_C054492D-4F12-4D56-98E5-EA5A8D213C4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Pierce,

As you=92ve = discovered there is no normative definition of =93rough consensus=94 in = the IETF. There are informational descriptions in various places, some = of which go on at length and may be interesting reading if you=92re = looking for different perspectives (e.g., RFC 7282). But there is no = normative definition.

I will note that in my = message that you quote below, I chose my words carefully. I said there = was rough consensus in the room in Dallas in support of forming the WG, = pending charter and scope edits. This is what was reported in the = minutes, which I linked to. As I=92ve noted before, I was not there in = Dallas since I was on leave (and the audio recording for that portion is = cut off unfortunately), but I trust that the minutes were reported = correctly. Ben was shepherding this work until I came back from leave in = June.

As Ben pointed out on this mailing list = in April, there is no notion of WG consensus until there is a WG. The = decision to form a WG certainly must be informed by the level of support = demonstrated in the community for the work. But such decisions generally = also take other factors into account, as reflected in the RFC 2418 = questions and the BoF questions and answers listed in the minutes for = this BoF. 

The decision to form a WG = ultimately rests with the IESG, as Adam noted. The MODERN charter went = before the IESG after several months of iterations and editing resulting = from discussions on this list (some of which I see that you were = involved in). As I noted in an earlier mail, the IESG asked for comments = on the charter and did not receive a single one within the time frame = requested. Two came in late and resulting edits are being worked into = the charter. 

So to summarize, there was a = BoF where rough consensus existed in the room to form the WG pending = charter edits and where a sizable group of volunteers demonstrated = interest in authoring and editing the documents, there were then many = months of discussion on this list (which is open to all) about the = viability of the WG and the scope of the charter, there was a standard = charter review period conducted by the IESG that elicited comments from = two commenters, one of whom objected on grounds that had been previously = thoroughly discussed by participants on the list and in person, and the = WG has now been approved for formation by the IESG pending further = charter edits stemming from these comments. I have a hard time seeing = how this equates to WG formation by fiat.  It certainly does not = equate to unanimous support for the WG=92s formation, but that has never = been a requirement.

Lastly, I=92m not sure what = you mean by an =93undefined approval process=94 for =93code = prototyping,=94 but I will note that the IETF has no role whatsoever in = determining who decides to implement what, when, or = how.

Cheers,
Alissa

On Jul 1, 2015, at 8:03 AM, Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com> = wrote:

Alissa,
 
I=92ve admitted before, I=92m a novice at IETF = procedures.  Your repeated use of the phrase =93rough consensus=94 = as a conclusion of fact caught my attention.  I wondered, is there = any IETF accepted definitiion of =93rough consensus=94 that Alissa and = others are adhering to that I=92m just not aware = of?
 
A little research turned up an IETF.org document based on RFC 6722 = Section 4.2 going into some detail on the topic of =93Getting Things = Done in a Working Group=94 at URL:https://www.ietf.org/tao.html#getting.things.done
 
I=92ve copied-and-pasted the sentences from the beginning of = the section that I think are particularly relevant to understanding the = IETF =93consensus=94 view on the definition of =93rough = consensus=94.
 
=93One fact that confuses many novices is that the = face-to-face WG meetings are much less important in the IETF than they = are in most other organizations. Any decision made at a face-to-face = meeting must also gain consensus on the WG mailing list. There are = numerous examples of important decisions made in WG meetings that are = later overturned on the mailing list, often because someone who couldn't = attend the meeting pointed out a serious flaw in the logic used to come = to the decision.=94
 
=93The general rule on = disputed topics is that the Working Group has to come to "rough = consensus", meaning that a very large majority of those who care must = agree.=94
 
=93Rough consensus has been defined in = many ways; a simple version is that it means that strongly held = objections must be debated until most people are satisfied that these = objections are wrong.=94
 
There is some more verbiage related = to the use of a Working Group Last Call (WGLC), but it isn=92t clear if = this is before or after chartering.  If its supposed to be done = before, we skipped it I think.
 
The Tao is not a legalistic document = based on rigid parlimentary procedures and there is what I will call a = power of fiat within the IESG and the WG chairs, meaning they can = basically ignore the definitions given = above.
 
I can fully understand the anxiousness of many participants to = end debate and just move on.  Code prototyping has already happened = and available for review (based on request only and an undefined = approval process).
 
Regardless, I have to ask, using the definitions of the IETF = Tao, on what basis can it be claimed that =93rough consensus=94 has been = achieved for the MODERN charter?  =46rom what I can tell it was the = power of fiat.
 
Best regards,
 
 
Pierce Gorman
Core Network Planning
O: 913-439-4368
<image001.png>
 
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa = Cooper
Sent: June 30, 2015 4:01 = PM
To: modern@ietf.org
Subject: Re: [Modern] [new-work] WG = Review: Managing, Ordering, Distributing, Exposing, & Registering = telephone Numbers (modern)
 
I=92d = like to ask that each person participating in this discussion remember = to be respectful of one another=92s points of view and focus on = constructive dialogue. If you feel that you=92re wasting cycles on the = current threads then feel free to change the subject to something more = productive; likewise if you feel someone else is wasting your cycles, = don=92t feel compelled to respond.
 
To review the process that got us to the current = point:
 
The = conclusion from the BoF in Dallas was that there was rough consensus in = the room in support of forming the WG but that the charter and problem = scope needed refinement (feel free to review the minutes: http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That process of refinement took place on this list over several = months following the BoF. The charter was put out for review on June 12 = with comments requested to be sent to the IESG by June 22. The IESG = considered the two ITU-T related comments received (both after the = deadline) and issued no blocking comments on the charter but asked that = edits be considered on the basis of comments received. There were no = other comments received or indications provided to the IESG about the = readiness of this work for chartering. I=92m still working on edits = (Richard Hill pointed out that I missed his suggestions) and milestones = are in the works as well. Thus this WG is being formed according to the = usual process.


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.

= --Apple-Mail=_C054492D-4F12-4D56-98E5-EA5A8D213C4D-- From nobody Wed Jul 1 14:07:40 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01D1AC3C2 for ; Wed, 1 Jul 2015 14:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Ej-4C5gsAHvL for ; Wed, 1 Jul 2015 14:07:38 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D35F1A9110 for ; Wed, 1 Jul 2015 14:07:38 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 278D32119E for ; Wed, 1 Jul 2015 17:07:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 01 Jul 2015 17:07:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=saDJw lmRuAwYm3EzpH84bNoKiDQ=; b=A6VsymPRcQTtTsNI8svtzjTtZJjRrLR7ySI5j D8kssZxcRF9Vp186HKXnSG99U5vce3rt3B/tVr8Sy9WVI6r6UdcWE63FTEz4tfSl 8EukcrlBQ9QCR7iwiV/5R3Y21suuVHkssQxFS8Or4a4kFyGW4YyVGRn1X/anWSpR ocq1yA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=saDJwlmRuAwYm3EzpH84bNoKiDQ=; b=RkXU5 Gwxm1tMuosfGryiQ0J4UOJVX5cJvKVgRQH0CZtI5Q3s6M3Kmluy7gIBnDc9ej2Kv 4Y21Y1zmGy/Urj027uBa7r3r24O3Y7G8kq+NqO9IJAIIlnQhZcM3euCrc9LfeTor suk5bRyX2SymBXuPzXKaqT9fR8smWRSbo1yz+Q= X-Sasl-enc: NkRNWkStfbnkSn5umqnJODSX24SuOdQDyiGLSPlm5pCt 1435784856 Received: from dhcp-171-68-20-90.cisco.com (unknown [171.68.20.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 65CD8C00295; Wed, 1 Jul 2015 17:07:36 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6830937-974E-4CAE-B385-F80636E0641E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Wed, 1 Jul 2015 14:07:35 -0700 Message-Id: <585BD041-C1E2-4366-9FB6-DAB6F73F5A0E@cooperw.in> References: To: "McGarry, Tom" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] charter edits X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:07:39 -0000 --Apple-Mail=_F6830937-974E-4CAE-B385-F80636E0641E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Further edits have been incorporated into the first and last paragraphs = based on Richard Hill=92s suggestions and resulting list discussion =97 = . I think we=92re = at the point of diminishing returns at this point (especially = considering Richard=92s overall objection to this work moving forward in = the IETF), so I will hit the approval button unless someone spots an = error introduced in making the changes. Alissa =20 --Apple-Mail=_F6830937-974E-4CAE-B385-F80636E0641E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Further edits have been = incorporated into the first and last paragraphs based on Richard Hill=92s = suggestions and resulting list discussion =97 <http://datat= racker.ietf.org/doc/charter-ietf-modern/>. I think we=92re at the = point of diminishing returns at this point (especially considering = Richard=92s overall objection to this work moving forward in the IETF), = so I will hit the approval button unless someone spots an error = introduced in making the changes.

Alissa =  


= --Apple-Mail=_F6830937-974E-4CAE-B385-F80636E0641E-- From nobody Wed Jul 1 14:09:07 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A281A9107 for ; Wed, 1 Jul 2015 14:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJvAFJhvEV-z for ; Wed, 1 Jul 2015 14:09:03 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 816011ACD8E for ; Wed, 1 Jul 2015 14:08:47 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAACsOA////ClA= Date: Wed, 1 Jul 2015 21:08:45 +0000 References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> <40997198-9527-49E0-B038-4144F9FDC73D@chriswendt.net> <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:09:06 -0000 QXMgeW91IGtub3csIHdlIGFscmVhZHkgaGF2ZSBzb21ld2hhdCB2YXJ5aW5nIGFzc2lnbm1lbnQg cnVsZXMsIGluIHRoZSBVUywgZm9yIGRpZmZlcmVudCBjbGFzc2VzIG9mIG51bWJlcnMsIHN1Y2gg YXMgcEFOSXMsIHRvbGwgZnJlZSBudW1iZXJzLCBTTVMgc2hvcnQgY29kZXMgYW5kICJyZWd1bGFy IiBudW1iZXJzLCBhbW9uZyBvdGhlcnMuIFNvbWUgYXJlIHRpZWQgdG8gc2VydmljZSwgb3RoZXJz IG5vdC4gKEZvciBleGFtcGxlLCBSZXNwT3JncyBmb3IgdG9sbC1mcmVlIG51bWJlcnMgZG9uJ3Qg aGF2ZSB0byBwcm92aWRlIHRyYW5zcG9ydC9zaWduYWxpbmcgc2VydmljZXMuKQ0KDQpXaGV0aGVy IE1PREVSTiBpcyBhcHBsaWNhYmxlIHRvIGFueSBvZiB0aGVzZSBudW1iZXIgc3BhY2VzIGlzIGEg c2VwYXJhdGUgZGlzY3Vzc2lvbjsgbXkgcG9pbnQgaXMgbWFpbmx5IHRoYXQgdGhlcmUgYWxyZWFk eSBpcyBhIHNlcGFyYWJsZSBhdXRob3JpemF0aW9uIHByb2Nlc3MgdGhhdCBkb2Vzbid0IHNlZW0g dG8gaW5mbHVlbmNlIHRoZSBtZWNoYW5pY3MuIEFzIGFuIGV4YW1wbGUsIGEgY29tcGFueSBoYXMg dG8gZ28gdGhyb3VnaCBhIHNldCBvZiBxdWFsaWZpY2F0aW9uIHN0ZXBzIHRvIGJlY29tZSBhIFJl c3BPcmcgYW5kIHRoZW4gZ2V0cyBoYW5kZWQgY3JlZGVudGlhbHMgdG8gaW50ZXJhY3Qgd2l0aCB0 aGUgU01TODAwIGRhdGFiYXNlLg0KDQpCdXQgSSdtIG5vdCBzdXJlIGhvdyB0aGlzIG1hdHRlcnMg dG8gdGhlIHByb2R1Y3Qgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIENsZWFybHksIHRoZXJlIGhhcyB0 byBiZSBhIHBvbGljeSBtZWNoYW5pc20gdGhhdCBzYXlzICJ5b3UgYXJlIGF1dGhvcml6ZWQgdG8g cmVxdWVzdCBhIG51bWJlciIsIHdoZXJlIHRoZSBxdWFsaWZpY2F0aW9ucyBhcmUgbGlrZWx5IHRv IGJlIHZhcnlpbmcgYW5kIGVuZm9yY2VkIGJ5IGNvbnRyYWN0IG9yIHRoZSBuYXRpb25hbCByZWd1 bGF0b3IuICgiQ29udHJhY3QiIGZvciB0aGUgY2FzZSB3aGVyZSBhIGNhcnJpZXIgYXNzaWducyBu dW1iZXJzIHRvIG9uZSBvZiBpdHMgY3VzdG9tZXJzLikgVW5sZXNzIHlvdSBzZWUgc29tZSBuZWVk IHRvIGluY2x1ZGUgdGhlIHF1YWxpZmljYXRpb25zIGFuZCB0aGVpciB2YWxpZGF0aW9uIGluIHRo ZSBwcm90b2NvbCwgSSBkb24ndCBzZWUgaG93IHRoaXMgYWZmZWN0cyB0aGUgcHJvdG9jb2wgbWVj aGFuaWNzLiBJbiB0aGUgVVMsIGZvciBleGFtcGxlLCB5b3UnZCBuZWVkIHRvIGdldCBhbiBPQ04g ZnJvbSBORUNBLCBhbmQgdGhleSByZXF1aXJlIHBhcGVyd29yayBwcm92aW5nIHlvdXIgc3RhdHVz LCBidXQgSSBkb24ndCB0aGluayBhbnlib2R5IGlzIHByb3Bvc2luZyB0aGF0IHdlIGRlc2lnbiBh biBhdXRvbWF0ZWQgYXBwbGljYW50LXRvLU5FQ0EgcHJvdG9jb2wgdGhhdCBpbmNvcnBvcmF0ZXMg YWxsIHRoZSBmaWVsZHMgaW4gaHR0cHM6Ly93d3cubmVjYS5vcmcvV29ya0FyZWEvbGlua2l0LmFz cHg/TGlua0lkZW50aWZpZXI9aWQmSXRlbUlEPTU0MTkmbGliSUQ9NTQzOSkNCg0KSWYgT0ZDT00g b3IgdGhlIEZDQyB3YW50ZWQgdG8gaGFuZCBudW1iZXJzIGRpcmVjdGx5IHRvIGhvdCBkb2cgdmVu ZG9ycyBmb3Igc29tZSByZWFzb24sIEkgc3VzcGVjdCBnaXZpbmcgdGhlbSB0ZWNobmljYWwgYWNj ZXNzIHRvIHRoZSByZXNwZWN0aXZlIGV4aXN0aW5nIG51bWJlcmluZyBkYXRhYmFzZXMgaXMgdGhl IGxlYXN0IG9mIHRoZSBwcm9ibGVtcy4gDQoNCkJ1dCBJJ20gcHJvYmFibHkgbWlzc2luZyBhbiBp bXBvcnRhbnQgZmFjZXQgb2YgdGhlIGNvbmNlcm4uDQoNCkhlbm5pbmcNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IER3aWdodCwgVGltb3RoeSBNIChUaW0pIFttYWlsdG86dGlt b3RoeS5kd2lnaHRAdmVyaXpvbi5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDAxLCAyMDE1 IDEyOjU3IFBNDQpUbzogQ2hyaXMgV2VuZHQ7IERPTExZLCBNQVJUSU4gQw0KQ2M6IEJlbiBDYW1w YmVsbDsgRFJBR0UsIEtlaXRoIChLZWl0aCk7IG1vZGVybkBpZXRmLm9yZzsgSGVubmluZyBTY2h1 bHpyaW5uZQ0KU3ViamVjdDogUkU6IFtNb2Rlcm5dIFtuZXctd29ya10gV0cgUmV2aWV3OiBNYW5h Z2luZywgT3JkZXJpbmcsIERpc3RyaWJ1dGluZywgRXhwb3NpbmcsICYgUmVnaXN0ZXJpbmcgdGVs ZXBob25lIE51bWJlcnMgKG1vZGVybikNCg0KQ2hyaXMncyBtYWlsIG1hZGUgbWUgd29uZGVyIGFi b3V0IHNvbWV0aGluZy4NCg0KVHJhZGl0aW9uYWxseSAiZW5kIHVzZXJzIiAoaW5kaXZpZHVhbHMs IEVudGVycHJpc2VzKSBoYXZlIG9idGFpbmVkIHRlbGVwaG9uZSBudW1iZXJzIGFzIGEgYnlwcm9k dWN0IG9mIHN1YnNjcmliaW5nIHRvIHNvbWUgZm9ybSBvZiAidGVsZXBob255IiBzZXJ2aWNlLiAg SGVuY2UgaXQgbWFkZSBzZW5zZSB0aGF0IHRoZSBwcm92aWRlciBvZiB0aGUgc2VydmljZSBiZSB0 aGUgc291cmNlIG9mIHRoZSBudW1iZXIuICBNeSByZWFkaW5nIG9mIHRoZSBjdXJyZW50IGNoYXJ0 ZXIsIGFuZCBteSBvYnNlcnZhdGlvbiBvZiB0aGUgcHJlc2VudGF0aW9ucyBtYWRlIGJ5IEpvbiBh bmQgSGVubmluZyBpbiB0aGUgRGFsbGFzIElFVEYsIGxlYWQgbWUgdG8gYmVsaWV2ZSBNT0RFUk4g d2lsbCBhc3N1bWUgYSBkaWZmZXJlbnQgcGFyYWRpZ20uICBUaGUgdG9vbHMgdGhlIHdnIGRldmVs b3BzIG1heSBiZSB1c2FibGUgdG8gc3VwcG9ydCB0aGUgYWJvdmUsIGJ1dCB3b3VsZCBhbHNvIHN1 cHBvcnQgYSBjb3VwbGUgb2YgbmV3ICh0byBtZSBhdCBsZWFzdCkgbm90aW9ucw0KDQphKSBzZXBh cmF0aW9uIG9mIHRlbGVwaG9uZSBudW1iZXIgYXNzaWdubWVudCBmcm9tIHN1YnNjcmlwdGlvbiB0 byB0ZWxlY29tbXVuaWNhdGlvbnMgc2VydmljZXMsIGFuZA0KYikgcmVsYXhhdGlvbiBvZiB0aGUg ImhpZXJhcmNoeSIgdGhyb3VnaCB3aGljaCBudW1iZXJzIGFyZSBhbGxvY2F0ZWQgdG9kYXkgKGUu Zy4sIE5QQSB0byB0cmFkaXRpb25hbC1TUCB0byBub24tdHJhZGl0aW9uYWwtU1AgdG8gRW50ZXJw cmlzZSB0byBkZXNrIHBob25lKS4NCg0KSXMgdGhhdCB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/ICAN Cg0KSSBoYXZlIHRvIHNheSBpdCBjb21lcyBtb3JlIGZyb20gSGVubmluZydzICJtb3RpdmF0aW9u YWwiIHNsaWRlcyB0aGFuIGZyb20gdGhlIGNoYXJ0ZXIgaXRzZWxmLiAgU28gSSdtIG5vdCBzdXJl IHRoZXNlIGFyZSBfdGhlXyBvYmplY3RpdmVzLCBfc29tZV9wb3NzaWJsZV8gb2JqZWN0aXZlcywg b3IgYSBtaXNpbnRlcnByZXRhdGlvbiBvbiBteSBwYXJ0LiAgQXBvbG9naWVzIGluIGFkdmFuY2Ug aWYgdGhlIGxhdHRlciBpcyB0aGUgY2FzZS4NCg0KdGltDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTW9kZXJuIFttYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDaHJpcyBXZW5kdA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDAxLCAyMDE1 IDExOjE4IEFNDQpUbzogRE9MTFksIE1BUlRJTiBDDQpDYzogQmVuIENhbXBiZWxsOyBEUkFHRSwg S2VpdGggKEtlaXRoKTsgbW9kZXJuQGlldGYub3JnOyBIZW5uaW5nIFNjaHVsenJpbm5lDQpTdWJq ZWN0OiBSZTogW01vZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5nLCBPcmRlcmlu ZywgRGlzdHJpYnV0aW5nLCBFeHBvc2luZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhvbmUgTnVtYmVy cyAobW9kZXJuKQ0KDQorMQ0KDQpBbHRob3VnaCBpIGtub3cgaXQgaGFzIGFsd2F5cyBiZWVuIHBh cnQgb2YgdGhlIHByb3Bvc2FsIGZvciBNb2Rlcm4sIEnigJltIHNlbnNpbmcgYSBzaGlmdCBpbiBj b252ZXJzYXRpb24gb3IgYXQgbGVhc3QgbW9yZSBvZiBhIHNlZ21lbnRhdGlvbiBmb3IgZW50ZXJw cmlzZSByZXF1aXJlbWVudHMgdnMuIG51bWJlciBhZG1pbmlzdHJhdG9yIHJlcXVpcmVtZW50cy4g IElzIHRoZXJlIGFueSBzZW5zZSB0aGF0IHRoZSBjaGFydGVyIGNhbiBhbmQgZG9lcyByZXByZXNl bnQgYm90aCBvZiB0aGVzZSB1c2UgY2FzZXMsIGFuZCB0aGVyZSBpcyBhbnkgcmVhc29uYWJsZSBv dXRjb21lIHRoYXQgdGhlcmUgd291bGQgYmUgYSBsYXJnZWx5IGNvbW1vbiBzZXQgb2YgZnVuY3Rp b25hbGl0eSBmb3IgYm90aD8NCg0KT3IgaXMgdGhlcmUgdHdvIGV4cGxpY2l0IHJlcXVpcmVtZW50 cywgYW5kIGluIG15IG1pbmQgdmVyeSBkaWZmZXJlbnQgc29sdXRpb25zLCBoZW5jZSBteSBwcmV2 aW91cyBxdWVzdGlvbiBhYm91dCB0aGUgYW5hbG9neSB0byBETlMgYW5kIElQIGFkZHJlc3MgYWxs b2NhdGlvbi4NCg0KSSB3b3VsZCBhZ3JlZSB0aGUgZW50ZXJwcmlzZSByZXF1aXJlbWVudHMgYXJl IGZhaXJseSBzdHJhaWdodCBmb3J3YXJkLiAgRW50aXR5IEEgaGFzIGEgcG9vbCBvZiB0ZWxlcGhv bmUgbnVtYmVycyB0aGV5IGNhbiBwcm92aWRlIHNvbWUgd2hvbGVzYWxlIG9yIHRyYW5zaXQgcmVs YXRpb25zaGlwIGZvciBhbmQgRW50aXR5IEIgd291bGQgbGlrZSB0byBwcm92aXNpb24gYW5kIHVz ZSB0aG9zZSBudW1iZXJzLiAgVGhpcyBwZXJoYXBzIGNvdWxkIGJlbmVmaXQgZnJvbSBhIHN0YW5k YXJkaXplZCBpbnRlcmZhY2UsIGFsdGhvdWdoIGkgbWlnaHQgYXJndWUgdGhhdCB0cm9wbyBhbmQg dHdpbGlvIGFuZCBBVCZUIGFuZCBvdGhlcnMgY2FuIGRpZmZlcmVudGlhdGUgdGhlaXIgc2Vydmlj ZXMgYmFzZWQgb24gYmV0dGVyIG9yIHdvcnNlIGludGVyZmFjZXMgKGJ1dCB0aGF0IGlzIGEgZGlm ZmVyZW50IGRpc2N1c3Npb24gYW5kIG1heWJlIHRoYXTigJlzIGEgaGlnaGVyIGxldmVsIGludGVy ZmFjZSB0aGFuIHdoYXQgd291bGQgYmUgZGVmaW5lZCBoZXJlKQ0KDQpGb3IgdGhlIG51bWJlciBh ZG1pbmlzdHJhdG9yIGludGVyZmFjZSB0byB0aG9zZSBlbnRpdGllcyB0aGF0IGFyZSDigJxnb3Zl cm5lZOKAnSB0byBiZSByZXNwb25zaWJsZSBmb3IgdGVsZXBob25lIG51bWJlcnMsIHRoZXJlIGlz IGEgZGlmZmVyZW50IHNldCBvZiByZXF1aXJlbWVudHMgYW5kIGEgZnV6emllciBwYXRoIGZvcndh cmQgYmFzZWQgb24gc3BlY2lmaWMgcmVndWxhdG9yeSBib2R5IHJ1bGVzIGFuZCB3aGF0IG5lZWRz IHRvIGJlIGVuYWJsZWQgaW4gdGhhdCBwcm92aXNpb25pbmcgaW50ZXJmYWNlIGFuZCByZWdpc3Ry eSBkYXRhYmFzZSwgc3BlY2lmaWMgdG8gYXBwbHlpbmcgcG9saWN5IGFzIHBhcnQgb2YgdGhlIGlu dGVyZmFjZS4gIEFib3ZlIGFuZCBiZXlvbmQgdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyB0aGluZ3Mg bGlrZSBudW1iZXIgcG9ydGFiaWxpdHkgYW5kIG90aGVyIHRoaW5ncyB0aGF0IG1heSBvciBtYXkg bm90IGJlIGNvbW1vbiB0byBib3RoIHVzZSBjYXNlLg0KDQpUbyBNYXJ0aW7igJlzIHBvaW50LCB1 bmxlc3MgdGhlcmUgaXMgY2xlYXIgcmVxdWlyZW1lbnRzIG9yIGEgcGF0aCB0byBjbGVhciByZXF1 aXJlbWVudHMsIGl0IGlzIGRpZmZpY3VsdCB0byBlbmdpbmVlciBhIHNvbHV0aW9uIG9yIGF0IGxl YXN0IG9uZSB0aGF0IHdvdWxkL2NvdWxkIGJlIGFkb3B0ZWQgZm9yIGVpdGhlciBvciBib3RoIG9m IHRoZSB1c2UgY2FzZXMuDQpQYXJ0aWN1bGFybHkgaWYgeW91IGFyZSB0cnlpbmcgdG8gYWRkcmVz cyB0d28gYXQgb25jZS4NCg0KV291bGQgZGVmaW5pdGVseSBiZSBpbnRlcmVzdGVkIGluIGFueSBj bGFyaWZpY2F0aW9uIG9uIHRoZSBpbnRlbnQgdGhhdCBpIG1heSBoYXZlIG1pc3VuZGVyc3Rvb2Qg b3Igd2hldGhlciBpdCBpcyB1c2VmdWwgdG8gY2xhcmlmeSB0aGVzZSBhbmQvb3IgcGljayBhbiBl eHBsaWNpdCBwYXRoIHRvd2FyZHMgb25lIG9yIHRoZSBvdGhlci4NCg0KDQo+IE9uIEp1bCAxLCAy MDE1LCBhdCAxMDoxMiBBTSwgRE9MTFksIE1BUlRJTiBDIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6 DQo+IA0KPiBNYXkgYmUgSSBoYXZlIGJlZW4gYSBTeXN0ZW0gRW5naW5lZXIgdG9vIGxvbmc6DQo+ IDEuIFRoZSBzZXJ2aWNlL2NhcGFiaWxpdHkgcmVxdWlyZW1lbnRzIHdvdWxkIGJlIGRlZmluZWQg YnkgcG9saWN5L3JlZ3VsYXRvcnkgbmVlZHMuDQo+IDIuIFRoZW4gdGhlICJ0b29sIiByZXF1aXJl bWVudHMgd291bGQgYmUgZGVyaXZlZCBmcm9tIHRoZSBwb2xpY3kvcmVndWxhdG9yeSBuZWVkcw0K PiANCj4gQSBidWlsZGVyIG5lZWRzIHRvIGtub3cgd2hhdCBoZSBpcyBidWlsZGluZyBpbiBvcmRl ciB0byBlbnN1cmUgdGhhdCBoZSBoYXMgdGhlIGNvcnJlY3QgdG9vbHMgaW4gaGlzIHRvb2wgYm94 Li4uLg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVubmluZyBT Y2h1bHpyaW5uZSBbbWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdl0gDQo+IFNlbnQ6 IFdlZG5lc2RheSwgSnVseSAwMSwgMjAxNSA5OjM0IEFNDQo+IFRvOiBET0xMWSwgTUFSVElOIEM7 IEJlbiBDYW1wYmVsbDsgRFJBR0UsIEtlaXRoIChLZWl0aCkNCj4gQ2M6IG1vZGVybkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSRTogW01vZGVybl0gW25ldy13b3JrXSBXRyBSZXZpZXc6IE1hbmFnaW5n LCBPcmRlcmluZywgRGlzdHJpYnV0aW5nLCBFeHBvc2luZywgJiBSZWdpc3RlcmluZyB0ZWxlcGhv bmUgTnVtYmVycyAobW9kZXJuKQ0KPiANCj4gVG8gbW92ZSB0aGUgZGlzY3Vzc2lvbiBmb3J3YXJk LCByYXRoZXIgdGhhbiBjeWNsaW5nIGJhY2sgdG8gaW52b2tpbmcgdGhlIHRlcm1zLCBJJ2QgYmUg aW50ZXJlc3RlZCBpbiBoZWFyaW5nIHdoaWNoIHJlcXVpcmVtZW50cywgcHJlY2lzZWx5IGFuZCBj b25jcmV0ZWx5LCBhcmUgbGlrZWx5IHRvIGRlcGVuZCBvbiBwb2xpY3kgYW5kIHJlZ3VsYXRpb24u IA0KPiANCj4gRXZlcnlib2R5IGhhcyBpdGVyYXRlZCBhZ2FpbiBhbmQgYWdhaW4gdGhhdCB0aGUg IndobyBjYW4gZ2V0IHdoYXQiIHBhcnQgZGVmaW5pdGVseSBkb2VzLCBidXQgdGhhdCdzIG91dHNp ZGUgdGhlIHByb3RvY29sIG1lY2hhbmlzbSwganVzdCBsaWtlICJ3aG8gY2FuIHNlZSB3aGF0IHdl YiBwYWdlIiBvciAid2hvIGNhbiBwbGFjZSB3aGF0IFNJUCBjYWxsIiBpcyBiZXlvbmQgdGhlIGNv bmNlcm4gb2YgSFRUUCBvciBTSVAsIGJleW9uZCBwcm92aWRpbmcgYW4gYXV0aGVudGljYXRpb24g bWVjaGFuaXNtIHRoYXQgYWxsb3dzIHRvIGFzc29jaWF0ZSBhIHBvbGljeSB3aXRoIGEgcHJpbmNp cGFsLg0KPiANCj4gWW91IG11c3QgaGF2ZSBzcGVjaWZpYyBpc3N1ZXMgaW4gbWluZCB0aGF0IGdv IGJleW9uZCB0aGF0Lg0KPiANCj4gSGVubmluZw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBET0xMWSwgTUFSVElOIEMgW21kMzEzNUBhdHQu Y29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMDEsIDIwMTUgOToxMiBBTQ0KPiBUbzogQmVu IENhbXBiZWxsOyBEUkFHRSwgS2VpdGggKEtlaXRoKQ0KPiBDYzogbW9kZXJuQGlldGYub3JnOyBI ZW5uaW5nIFNjaHVsenJpbm5lDQo+IFN1YmplY3Q6IFJFOiBbTW9kZXJuXSBbbmV3LXdvcmtdIFdH IFJldmlldzogTWFuYWdpbmcsIE9yZGVyaW5nLCBEaXN0cmlidXRpbmcsIEV4cG9zaW5nLCAmIFJl Z2lzdGVyaW5nIHRlbGVwaG9uZSBOdW1iZXJzIChtb2Rlcm4pDQo+IA0KPiBCdXQgdGhpcyBpcyB0 aGUgcm9vdCBvZiB0aGUgaXNzdWUgaGVyZSwgdGhlIHJlcXVpcmVtZW50cyBmb3Igc3VjaCBhIHNv bHV0aW9uIGlzIGJhc2VkIG9uIHBvbGljeSBhbmQgcmVndWxhdGlvbiwgdGhhdCBkb2VzIG5vdCBl eGlzdCAsIHlldC4uLi4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IE1vZGVybiBtYWlsaW5nIGxpc3QNCj4gTW9kZXJuQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9kZXJuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNb2Rlcm4gbWFpbGluZyBs aXN0DQpNb2Rlcm5AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW9kZXJuDQo= From nobody Wed Jul 1 14:47:08 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1E1A1AE8 for ; Wed, 1 Jul 2015 14:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c6QjZltCsMI for ; Wed, 1 Jul 2015 14:47:05 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 40AF21A1AE3 for ; Wed, 1 Jul 2015 14:47:05 -0700 (PDT) Received: (qmail 28250 invoked by uid 0); 1 Jul 2015 21:47:02 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy5.mail.unifiedlayer.com with SMTP; 1 Jul 2015 21:47:02 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id n9KM1q0171MNPNq019KQCB; Wed, 01 Jul 2015 15:19:27 -0600 X-Authority-Analysis: v=2.1 cv=ItWNLtPg c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=8rKY7V6_AJVqQVWBuL4A:9 a=nvAUy6i5R2TmbZLV:21 a=ZMvtwVr-utMTJOw9:21 a=wPNLvfGTeEIA:10 a=DzjOOp_o1eYA:10 a=Vz3pi8aoyK8A:10 a=Tse0HgvhaukA:10 a=kkUMZHjH4KkA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=5cS81tHKIL4Qk+QXz8Cck4kJ5xXWJX6VhRMNLWh97zM=; b=M7bhTORpU3DSxT2W6L1zGBJ9skLMk+wYZI37CM3Ll+gw1VDMowznoJ+5I3oXoxtR159pznSBhIc7qp+BoiDmcQDUEC7TDlpFhUuqOhFfVQ536fTlMr70yImtpv8pdTst; Received: from [100.36.26.202] (port=58820 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAPWz-0005md-Ac; Wed, 01 Jul 2015 15:26:57 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Wed, 01 Jul 2015 17:26:52 -0400 From: Richard Shockey To: Cullen Jennings , "Gorman, Pierce A [CTO]" Message-ID: Thread-Topic: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> In-Reply-To: <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: Alissa Cooper , "modern@ietf.org" Subject: Re: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:47:07 -0000 On 7/1/15, 3:26 PM, "Modern on behalf of Cullen Jennings" wrote: > >This topic is complicated and there is not a perfect answer to what rough >consensus is. I suspect that in this case it is formed by a combination >of the views of people that were at the BOF and what has been expressed >on email lists. Keep in mind a lot of people in that room expressed >support for this. Some people have expressed issues on the email lists - >many of theses being basically issues that were raised on the lists >before the BOF or at BOF. > >Many IETF people I work with view rough consensus as a large percentage >of the informed and relevant people agree - RS> And just who, pray tell, are those informed and relevant people? Is there a club? Is there a secret handshake? :-) Just the people who can afford to show up for BOF=B9s? IMHO there has been a bit of a rush to judgement (charter) before it was clear that a full spectrum of informed and relevant people had been consulted, especially those that would, by definition, have to implement the, yet to be determined, protocols in question. That said there is some consensus within the industry at large that, over time, there is a problem with numbering administration especially as TDM networks are transitioned but for the time being the problem is uniquely confined to the North American context. As a purely practical matter a charter that is this expansive is a recipe for a epic fail and that is NOT in the best interest of anyone who is informed by the subject matter. A productive discussion of how to limit the scope of a solution within the charter without precluding is use by other metadata elements in the future might produce progress. Pick one ..maybe two use cases. Speaking from personal experience. 6116 and its predecessors was a epic fail until some of us figured out it was just perfect for the retrieval of LNP data that eliminated TCAP dips. I still have the baseball caps BTW! NO TCAP. After that it just took off like a rocket. Number allocation protocols may prove difficult but starting to put in place the infrastructure for E.164 public keys IMHO is not the use/business/policy case is highly compelling. >and the people with relevant objections have had a chance to convince >others they are should object too (so they are informed). The position >that debate will continue until everyone agrees is definitely not a >viable definition for a SDO that is trying to get something done. > >I realize that makes the process even less deterministic but I suspect >most people at IETF would agree that my answer was at least part of rough >consensus. Part of the reason it is so hard to get a straight answer on >this is the IETF keeps telling itself it does not vote though when you >start describing how most of our important decisions are made, it starts >to sound a bit like a vote. > > >> On Jul 1, 2015, at 8:03 AM, Gorman, Pierce A [CTO] >> wrote: >>=20 >> Alissa, >> =20 >> I=B9ve admitted before, I=B9m a novice at IETF procedures. Your repeated >>use of the phrase =B3rough consensus=B2 as a conclusion of fact caught my >>attention. I wondered, is there any IETF accepted definitiion of =B3rough >>consensus=B2 that Alissa and others are adhering to that I=B9m just not >>aware of? >> =20 >> A little research turned up an IETF.org document based on RFC 6722 >>Section 4.2 going into some detail on the topic of =B3Getting Things Done >>in a Working Group=B2 at URL: >>https://www.ietf.org/tao.html#getting.things.done >> =20 >> I=B9ve copied-and-pasted the sentences from the beginning of the section >>that I think are particularly relevant to understanding the IETF >>=B3consensus=B2 view on the definition of =B3rough consensus=B2. >> =20 >> =B3One fact that confuses many novices is that the face-to-face WG >>meetings are much less important in the IETF than they are in most other >>organizations. Any decision made at a face-to-face meeting must also >>gain consensus on the WG mailing list. There are numerous examples of >>important decisions made in WG meetings that are later overturned on the >>mailing list, often because someone who couldn't attend the meeting >>pointed out a serious flaw in the logic used to come to the decision.=B2 >> =20 >> =B3The general rule on disputed topics is that the Working Group has to >>come to "rough consensus", meaning that a very large majority of those >>who care must agree.=B2 >> =20 >> =B3Rough consensus has been defined in many ways; a simple version is >>that it means that strongly held objections must be debated until most >>people are satisfied that these objections are wrong.=B2 >> =20 >> There is some more verbiage related to the use of a Working Group Last >>Call (WGLC), but it isn=B9t clear if this is before or after chartering. >>If its supposed to be done before, we skipped it I think. >> =20 >> The Tao is not a legalistic document based on rigid parlimentary >>procedures and there is what I will call a power of fiat within the IESG >>and the WG chairs, meaning they can basically ignore the definitions >>given above. >> =20 >> I can fully understand the anxiousness of many participants to end >>debate and just move on. Code prototyping has already happened and >>available for review (based on request only and an undefined approval >>process). >> =20 >> Regardless, I have to ask, using the definitions of the IETF Tao, on >>what basis can it be claimed that =B3rough consensus=B2 has been achieved >>for the MODERN charter? From what I can tell it was the power of fiat. >> =20 >> Best regards, >> =20 >> =20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> =20 >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa Cooper >> Sent: June 30, 2015 4:01 PM >> To: modern@ietf.org >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) >> =20 >> I=B9d like to ask that each person participating in this discussion >>remember to be respectful of one another=B9s points of view and focus on >>constructive dialogue. If you feel that you=B9re wasting cycles on the >>current threads then feel free to change the subject to something more >>productive; likewise if you feel someone else is wasting your cycles, >>don=B9t feel compelled to respond. >> =20 >> To review the process that got us to the current point: >> =20 >> The conclusion from the BoF in Dallas was that there was rough >>consensus in the room in support of forming the WG but that the charter >>and problem scope needed refinement (feel free to review the minutes: >>http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That >>process of refinement took place on this list over several months >>following the BoF. The charter was put out for review on June 12 with >>comments requested to be sent to the IESG by June 22. The IESG >>considered the two ITU-T related comments received (both after the >>deadline) and issued no blocking comments on the charter but asked that >>edits be considered on the basis of comments received. There were no >>other comments received or indications provided to the IESG about the >>readiness of this work for chartering. I=B9m still working on edits >>(Richard Hill pointed out that I missed his suggestions) and milestones >>are in the works as well. Thus this WG is being formed according to the >>usual process. >> =20 >> Alissa >>=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 > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 15:08:48 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AC31ACD53 for ; Wed, 1 Jul 2015 15:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KterjtHfeBrL for ; Wed, 1 Jul 2015 15:08:44 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 0D1BA1AD272 for ; Wed, 1 Jul 2015 15:08:44 -0700 (PDT) Received: (qmail 29367 invoked by uid 0); 1 Jul 2015 22:08:43 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 1 Jul 2015 22:08:43 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id n9h21q0081MNPNq019h5Vm; Wed, 01 Jul 2015 15:41:08 -0600 X-Authority-Analysis: v=2.1 cv=ItWNLtPg c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=uw9Sko2_AAAA:8 a=ZsyXEVtvAAAA:8 a=zQP7CpKOAAAA:8 a=SmiCOMSEEGT_AJcn9u4A:9 a=bNBQg-AvALxBuC5o:21 a=R4Ns7uLCptZyC1fN:21 a=wPNLvfGTeEIA:10 a=AhmpJnqEXDwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=GeqQl+8XQ0S7PTtwsBAC3F9O6Kyf1cDgEkItuOzZ4Y4=; b=ks1F4bTfCduIEPLcXHtcYQRmz075LuLyfLLs0qB4ky0m3xIuv6BkJbSFQ3E+xfu3u44V5sDH943Tm/yz28mRtaWVdGCVL/SVYpPR2ClAyCYnkOVM7F4bxiEu402ASuNf; Received: from [100.36.26.202] (port=58836 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAPrw-0002Bl-N8; Wed, 01 Jul 2015 15:48:37 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Wed, 01 Jul 2015 17:48:31 -0400 From: Richard Shockey To: Henning Schulzrinne , "Dwight, Timothy M (Tim)" Message-ID: Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <005a01d0b022$169bcbb0$43d36310$@ch> <42916ac616f94a6f8225e16c9dc83e2e@PLSWE13M08.ad.sprint.com> <5427B076-E291-4547-BE04-2B0D990F3475@standardstrack.com> <949EF20990823C4C85C18D59AA11AD8B69736468@FR712WXCHMBA11.zeu.alcatel-lucent.com> <42930C54-D1CC-4A35-8A2C-A4E5F577457C@iii.ca> <5591F73A.90301@nostrum.com> <77B96357-698D-4A59-8F3A-8092DACE1BAB@att.com> <5591FBEF.2000903@nostrum.com> <0BBC232F-C0EB-4986-9316-3C8739FE4889@att.com> <55920CA0.1070104@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6973705F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B69737D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <91B2910D-9B98-4DDB-9C25-1855AA6FAB51@nostrum.com> <40997198-9527-49E0-B038-4144F9FDC73D@chriswendt.net> <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:08:47 -0000 On 7/1/15, 5:08 PM, "Modern on behalf of Henning Schulzrinne" wrote: >As you know, we already have somewhat varying assignment rules, in the >US, for different classes of numbers, such as pANIs, toll free numbers, >SMS short codes and "regular" numbers, among others. Some are tied to >service, others not. (For example, RespOrgs for toll-free numbers don't >have to provide transport/signaling services.) RS> The word that always comes to mind is fustercluck. That said the US is infinitely better that some nameless jurisdictions re numbering. That would have been a great WG name. Where is Hadriel Kaplan when we need him. > >Whether MODERN is applicable to any of these number spaces is a separate >discussion; my point is mainly that there already is a separable >authorization process that doesn't seem to influence the mechanics. As an >example, a company has to go through a set of qualification steps to >become a RespOrg and then gets handed credentials to interact with the >SMS800 database. > >But I'm not sure how this matters to the product of the working group. >Clearly, there has to be a policy mechanism that says "you are authorized >to request a number", where the qualifications are likely to be varying >and enforced by contract or the national regulator. ("Contract" for the >case where a carrier assigns numbers to one of its customers.) Unless you >see some need to include the qualifications and their validation in the >protocol, I don't see how this affects the protocol mechanics. In the US, >for example, you'd need to get an OCN from NECA, and they require >paperwork proving your status, but I don't think anybody is proposing >that we design an automated applicant-to-NECA protocol that incorporates >all the fields in=20 >https://www.neca.org/WorkArea/linkit.aspx?LinkIdentifier=3Did&ItemID=3D5419&li >bID=3D5439) RS> So Henning pick two use cases. Something that can deploy fast and something that might take time. > >If OFCOM or the FCC wanted to hand numbers directly to hot dog vendors >for some reason, I suspect giving them technical access to the respective >existing numbering databases is the least of the problem. >=20 > >But I'm probably missing an important facet of the concern. RS> Obviously in the case of hot dog vendors you must exclude from the FCC model any hot dog vendor that serves ketchup. That said having actually read the relevant R&O hot dog vendors could certainly offer VoIP services with their mustard and kraut if they can provide the relevant NRUF reporting, USF contributions, 911 services etc. > >Henning > >-----Original Message----- >From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] >Sent: Wednesday, July 01, 2015 12:57 PM >To: Chris Wendt; DOLLY, MARTIN C >Cc: Ben Campbell; DRAGE, Keith (Keith); modern@ietf.org; Henning >Schulzrinne >Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > >Chris's mail made me wonder about something. > >Traditionally "end users" (individuals, Enterprises) have obtained >telephone numbers as a byproduct of subscribing to some form of >"telephony" service. Hence it made sense that the provider of the >service be the source of the number. My reading of the current charter, >and my observation of the presentations made by Jon and Henning in the >Dallas IETF, lead me to believe MODERN will assume a different paradigm. >The tools the wg develops may be usable to support the above, but would >also support a couple of new (to me at least) notions > >a) separation of telephone number assignment from subscription to >telecommunications services, and >b) relaxation of the "hierarchy" through which numbers are allocated >today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise to >desk phone). > >Is that understanding correct? > >I have to say it comes more from Henning's "motivational" slides than >from the charter itself. So I'm not sure these are _the_ objectives, >_some_possible_ objectives, or a misinterpretation on my part. Apologies >in advance if the latter is the case. > >tim > > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Chris Wendt >Sent: Wednesday, July 01, 2015 11:18 AM >To: DOLLY, MARTIN C >Cc: Ben Campbell; DRAGE, Keith (Keith); modern@ietf.org; Henning >Schulzrinne >Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > >+1 > >Although i know it has always been part of the proposal for Modern, I=B9m >sensing a shift in conversation or at least more of a segmentation for >enterprise requirements vs. number administrator requirements. Is there >any sense that the charter can and does represent both of these use >cases, and there is any reasonable outcome that there would be a largely >common set of functionality for both? > >Or is there two explicit requirements, and in my mind very different >solutions, hence my previous question about the analogy to DNS and IP >address allocation. > >I would agree the enterprise requirements are fairly straight forward. >Entity A has a pool of telephone numbers they can provide some wholesale >or transit relationship for and Entity B would like to provision and use >those numbers. This perhaps could benefit from a standardized interface, >although i might argue that tropo and twilio and AT&T and others can >differentiate their services based on better or worse interfaces (but >that is a different discussion and maybe that=B9s a higher level interface >than what would be defined here) > >For the number administrator interface to those entities that are >=B3governed=B2 to be responsible for telephone numbers, there is a different >set of requirements and a fuzzier path forward based on specific >regulatory body rules and what needs to be enabled in that provisioning >interface and registry database, specific to applying policy as part of >the interface. Above and beyond the fact that there is things like >number portability and other things that may or may not be common to both >use case. > >To Martin=B9s point, unless there is clear requirements or a path to clear >requirements, it is difficult to engineer a solution or at least one that >would/could be adopted for either or both of the use cases. >Particularly if you are trying to address two at once. > >Would definitely be interested in any clarification on the intent that i >may have misunderstood or whether it is useful to clarify these and/or >pick an explicit path towards one or the other. > > >> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: >>=20 >> May be I have been a System Engineer too long: >> 1. The service/capability requirements would be defined by >>policy/regulatory needs. >> 2. Then the "tool" requirements would be derived from the >>policy/regulatory needs >>=20 >> A builder needs to know what he is building in order to ensure that he >>has the correct tools in his tool box.... >>=20 >> -----Original Message----- >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >> Sent: Wednesday, July 01, 2015 9:34 AM >> To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) >> Cc: modern@ietf.org >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >> To move the discussion forward, rather than cycling back to invoking >>the terms, I'd be interested in hearing which requirements, precisely >>and concretely, are likely to depend on policy and regulation. >>=20 >> Everybody has iterated again and again that the "who can get what" part >>definitely does, but that's outside the protocol mechanism, just like >>"who can see what web page" or "who can place what SIP call" is beyond >>the concern of HTTP or SIP, beyond providing an authentication mechanism >>that allows to associate a policy with a principal. >>=20 >> You must have specific issues in mind that go beyond that. >>=20 >> Henning >>=20 >> ________________________________________ >> From: DOLLY, MARTIN C [md3135@att.com] >> Sent: Wednesday, July 01, 2015 9:12 AM >> To: Ben Campbell; DRAGE, Keith (Keith) >> Cc: modern@ietf.org; Henning Schulzrinne >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >> But this is the root of the issue here, the requirements for such a >>solution is based on policy and regulation, that does not exist , yet.... >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 15:20:32 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55D1B2ABE for ; Wed, 1 Jul 2015 15:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3FGb0XeoHyd for ; Wed, 1 Jul 2015 15:20:27 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCF51B2AA5 for ; Wed, 1 Jul 2015 15:20:27 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t61MD5Qi013647 for ; Wed, 1 Jul 2015 18:20:27 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vck0g8jbx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 01 Jul 2015 18:20:26 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.54]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Wed, 1 Jul 2015 18:20:27 -0400 From: "McGarry, Tom" To: "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZcstxl3hd1E6WCqHXbRoG2J3DI3GAgAFjg4CAAApVAIAAATyAgAAEYYCAAAI6gIAAEawAgACuGgCAAFODAIABLI+AgAAGyICAAADHAIAABhUAgAAKuACAACMwAIAACsOAgAAXTgA= Date: Wed, 1 Jul 2015 22:20:26 +0000 Message-ID: In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.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.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5DF5EFB7FC38CA4F8FD4CE3516DCA991@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-02_01:2015-06-30,2015-07-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507010347 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:20:30 -0000 Number assignment is done today without a subscription to a communications service. Numbers are allocated to carriers and carriers use that inventory to assign to users as they sign up for subscriptions. There are lots of allocated numbers without subscriptions. I could envision a scenario where a user gets a number from an administrator before they have enabled a communications service on that number. But just like today I would expect the administration process to expect to see service enabled at some time and reclaim it if it not. I could also see processes that either require a subscription before getting the TN or require a short timeframe between acquisition and service enablement. As stated in the charter, solutions need to be flexible enough to accommodate different policies. =20 As to your other question, I see modern enabling different administration models than are common today. Recently in the US the FCC issued an order that said VoIP providers (companies that are not regulatory recognized telecommunications service providers) can be assigned numbers directly by the administrator. The VoIP providers will still rely on TSPs for PSTN interconnection and transport. This is a perfect example of a scenario that modern would address - a protocol mechanism that would facilitate the interactions of the administrator, the TSP and the VoIP provider. On 7/1/15 12:56 PM, "Dwight, Timothy M (Tim)" wrote: >Chris's mail made me wonder about something. > > > >Traditionally "end users" (individuals, Enterprises) have obtained >telephone numbers as a byproduct of subscribing to some form of >"telephony" service. Hence it made sense that the provider of the >service be the source of the number. My reading of the current charter, >and my observation of the presentations made by Jon and Henning in the >Dallas IETF, lead me to believe MODERN will assume a different paradigm. >The tools the wg develops may be usable to support the above, but would >also support a couple of new (to me at least) notions > > > >a) separation of telephone number assignment from subscription to >telecommunications services, and > >b) relaxation of the "hierarchy" through which numbers are allocated >today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise to >desk phone). > > > >Is that understanding correct? > > > >I have to say it comes more from Henning's "motivational" slides than >from the charter itself. So I'm not sure these are _the_ objectives, >_some_possible_ objectives, or a misinterpretation on my part. Apologies >in advance if the latter is the case. > > > >tim > > > > > > > >-----Original Message----- > >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Chris Wendt > >Sent: Wednesday, July 01, 2015 11:18 AM > >To: DOLLY, MARTIN C > >Cc: Ben Campbell; DRAGE, Keith (Keith); modern@ietf.org; Henning >Schulzrinne > >Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > > > >+1 > > > >Although i know it has always been part of the proposal for Modern, I=B9m >sensing a shift in conversation or at least more of a segmentation for >enterprise requirements vs. number administrator requirements. Is there >any sense that the charter can and does represent both of these use >cases, and there is any reasonable outcome that there would be a largely >common set of functionality for both? > > > >Or is there two explicit requirements, and in my mind very different >solutions, hence my previous question about the analogy to DNS and IP >address allocation. > > > >I would agree the enterprise requirements are fairly straight forward. >Entity A has a pool of telephone numbers they can provide some wholesale >or transit relationship for and Entity B would like to provision and use >those numbers. This perhaps could benefit from a standardized interface, >although i might argue that tropo and twilio and AT&T and others can >differentiate their services based on better or worse interfaces (but >that is a different discussion and maybe that=B9s a higher level interface >than what would be defined here) > > > >For the number administrator interface to those entities that are >=B3governed=B2 to be responsible for telephone numbers, there is a differe= nt >set of requirements and a fuzzier path forward based on specific >regulatory body rules and what needs to be enabled in that provisioning >interface and registry database, specific to applying policy as part of >the interface. Above and beyond the fact that there is things like >number portability and other things that may or may not be common to both >use case. > > > >To Martin=B9s point, unless there is clear requirements or a path to clear >requirements, it is difficult to engineer a solution or at least one that >would/could be adopted for either or both of the use cases. > >Particularly if you are trying to address two at once. > > > >Would definitely be interested in any clarification on the intent that i >may have misunderstood or whether it is useful to clarify these and/or >pick an explicit path towards one or the other. > > > > > >> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: > >>=20 > >> May be I have been a System Engineer too long: > >> 1. The service/capability requirements would be defined by >>policy/regulatory needs. > >> 2. Then the "tool" requirements would be derived from the >>policy/regulatory needs > >>=20 > >> A builder needs to know what he is building in order to ensure that he >>has the correct tools in his tool box.... > >>=20 > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > >> Sent: Wednesday, July 01, 2015 9:34 AM > >> To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) > >> Cc: modern@ietf.org > >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) > >>=20 > >> To move the discussion forward, rather than cycling back to invoking >>the terms, I'd be interested in hearing which requirements, precisely >>and concretely, are likely to depend on policy and regulation. > >>=20 > >> Everybody has iterated again and again that the "who can get what" part >>definitely does, but that's outside the protocol mechanism, just like >>"who can see what web page" or "who can place what SIP call" is beyond >>the concern of HTTP or SIP, beyond providing an authentication mechanism >>that allows to associate a policy with a principal. > >>=20 > >> You must have specific issues in mind that go beyond that. > >>=20 > >> Henning > >>=20 > >> ________________________________________ > >> From: DOLLY, MARTIN C [md3135@att.com] > >> Sent: Wednesday, July 01, 2015 9:12 AM > >> To: Ben Campbell; DRAGE, Keith (Keith) > >> Cc: modern@ietf.org; Henning Schulzrinne > >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) > >>=20 > >> But this is the root of the issue here, the requirements for such a >>solution is based on policy and regulation, that does not exist , yet.... > >>=20 > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s= =3DC >>HlbePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D > > > >_______________________________________________ > >Modern mailing list > >Modern@ietf.org > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=3D= CHlb >ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=3D= CHlb >ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D=20 From nobody Wed Jul 1 15:56:06 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB001A6F12 for ; Wed, 1 Jul 2015 15:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4ZyO7CSMaFN for ; Wed, 1 Jul 2015 15:56:00 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B87E1A1B5A for ; Wed, 1 Jul 2015 15:55:59 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t61MsAtC022913 for ; Wed, 1 Jul 2015 18:55:59 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vck6nrhs4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 01 Jul 2015 18:55:59 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.54]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 1 Jul 2015 18:55:58 -0400 From: "McGarry, Tom" To: Modern List Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZcstxl3hd1E6WCqHXbRoG2J3DI3GAgAFjg4CAAApVAIAAATyAgAAEYYCAAAI6gIAAEawAgACuGgCAAFODAIABLI+AgAAGyICAAADHAIAABhUAgAAKuACAACMwAIAAK/8A Date: Wed, 1 Jul 2015 22:55:57 +0000 Message-ID: In-Reply-To: <40997198-9527-49E0-B038-4144F9FDC73D@chriswendt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.168.132.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-02_01:2015-06-30,2015-07-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507010357 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:56:02 -0000 The charter does cover at least both scenarios you mention - "The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment. The working group will also identity protocol mechanisms to support the interactions between the functions defined by the framework." The information related to a TN - subscriber, service, service provider, service address, etc. - is relatively finite. I would expect information exchanged between retail-wholesale to be somewhat different than that between wholesale-administrator, but they're in the same ballpark. Solving both should not be too difficult. And as I stated elsewhere, the solutions are expected to be flexible to account for different policies. So information exchanged under one policy, may not be the same information exchanged under another policy. But the WG should capture the superset. On 7/1/15 12:18 PM, "Chris Wendt" wrote: >+1 > >Although i know it has always been part of the proposal for Modern, I=B9m >sensing a shift in conversation or at least more of a segmentation for >enterprise requirements vs. number administrator requirements. Is there >any sense that the charter can and does represent both of these use >cases, and there is any reasonable outcome that there would be a largely >common set of functionality for both? > >Or is there two explicit requirements, and in my mind very different >solutions, hence my previous question about the analogy to DNS and IP >address allocation. > >I would agree the enterprise requirements are fairly straight forward. >Entity A has a pool of telephone numbers they can provide some wholesale >or transit relationship for and Entity B would like to provision and use >those numbers. This perhaps could benefit from a standardized interface, >although i might argue that tropo and twilio and AT&T and others can >differentiate their services based on better or worse interfaces (but >that is a different discussion and maybe that=B9s a higher level interface >than what would be defined here) > >For the number administrator interface to those entities that are >=B3governed=B2 to be responsible for telephone numbers, there is a differe= nt >set of requirements and a fuzzier path forward based on specific >regulatory body rules and what needs to be enabled in that provisioning >interface and registry database, specific to applying policy as part of >the interface. Above and beyond the fact that there is things like >number portability and other things that may or may not be common to both >use case. > >To Martin=B9s point, unless there is clear requirements or a path to clear >requirements, it is difficult to engineer a solution or at least one that >would/could be adopted for either or both of the use cases. >Particularly if you are trying to address two at once. > >Would definitely be interested in any clarification on the intent that i >may have misunderstood or whether it is useful to clarify these and/or >pick an explicit path towards one or the other. > > >> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: >>=20 >> May be I have been a System Engineer too long: >> 1. The service/capability requirements would be defined by >>policy/regulatory needs. >> 2. Then the "tool" requirements would be derived from the >>policy/regulatory needs >>=20 >> A builder needs to know what he is building in order to ensure that he >>has the correct tools in his tool box.... >>=20 >> -----Original Message----- >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >> Sent: Wednesday, July 01, 2015 9:34 AM >> To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) >> Cc: modern@ietf.org >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >> To move the discussion forward, rather than cycling back to invoking >>the terms, I'd be interested in hearing which requirements, precisely >>and concretely, are likely to depend on policy and regulation. >>=20 >> Everybody has iterated again and again that the "who can get what" part >>definitely does, but that's outside the protocol mechanism, just like >>"who can see what web page" or "who can place what SIP call" is beyond >>the concern of HTTP or SIP, beyond providing an authentication mechanism >>that allows to associate a policy with a principal. >>=20 >> You must have specific issues in mind that go beyond that. >>=20 >> Henning >>=20 >> ________________________________________ >> From: DOLLY, MARTIN C [md3135@att.com] >> Sent: Wednesday, July 01, 2015 9:12 AM >> To: Ben Campbell; DRAGE, Keith (Keith) >> Cc: modern@ietf.org; Henning Schulzrinne >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >> But this is the root of the issue here, the requirements for such a >>solution is based on policy and regulation, that does not exist , yet.... >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3D9uORpP0hGzE9S4A7IIpCY9PNWn06UsCjQ10ngvDS1xE&s= =3Dn >>FOf9-sTlWhwYP4Jid7VSqlTJqv0vHfn3TE9ueNAF7o&e=3D > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3D9uORpP0hGzE9S4A7IIpCY9PNWn06UsCjQ10ngvDS1xE&s=3D= nFOf >9-sTlWhwYP4Jid7VSqlTJqv0vHfn3TE9ueNAF7o&e=3D=20 From nobody Wed Jul 1 16:31:38 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8698E1B2C22 for ; Wed, 1 Jul 2015 16:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS6oWLg_f_uz for ; Wed, 1 Jul 2015 16:31:33 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE1A1AD35A for ; Wed, 1 Jul 2015 16:31:32 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t61NVRAk018519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Jul 2015 01:31:28 +0200 Received: from RHillNew (adsl-178-39-180-181.adslplus.ch [178.39.180.181]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t61NVR1b000621; Thu, 2 Jul 2015 01:31:27 +0200 From: "Richard Hill" To: "'Alissa Cooper'" , "'McGarry, Tom'" References: <585BD041-C1E2-4366-9FB6-DAB6F73F5A0E@cooperw.in> In-Reply-To: <585BD041-C1E2-4366-9FB6-DAB6F73F5A0E@cooperw.in> Date: Thu, 2 Jul 2015 01:31:31 +0200 Message-ID: <003301d0b456$104db6a0$30e923e0$@ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01D0B466.D3D686A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC0Qfkrlo9YdPsYR8avEVLpShqUewAE7S7g Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: modern@ietf.org Subject: Re: [Modern] charter edits X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 23:31:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01D0B466.D3D686A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Alissa, Thank you for this. The new version of the charter accommodates my suggestions, and those of others, so I'm happy with it. My objection was mostly because I feared that the charter would allow the group to stray unwittingly into areas that are politically sensitive because of regulatory frameworks. But I think that this is unlikely under the new charter, so I am hereby withdrawing my objection. I trust that you will communicate the withdrawal of my objection, if appropriate, to the IESG. Thank you very much for your careful and thoughtful considerations of all the comments. Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Wednesday, July 1, 2015 23:08 To: McGarry, Tom Cc: modern@ietf.org Subject: Re: [Modern] charter edits Further edits have been incorporated into the first and last paragraphs based on Richard Hill's suggestions and resulting list discussion - . I think we're at the point of diminishing returns at this point (especially considering Richard's overall objection to this work moving forward in the IETF), so I will hit the approval button unless someone spots an error introduced in making the changes. Alissa ------=_NextPart_000_0034_01D0B466.D3D686A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Alissa,

 

Thank you for this. The new version of the charter accommodates my = suggestions, and those of others, so I’m happy with = it.

 

My objection was mostly because I feared that the charter would allow = the group to stray unwittingly into areas that are politically sensitive = because of regulatory frameworks. But I think that this is unlikely = under the new charter, so I am hereby withdrawing my = objection.


I trust that you will communicate the withdrawal of my objection, = if appropriate, to the IESG.


Thank you very much for your careful and thoughtful = considerations of all the comments.

 

Best,

Richard

 

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa = Cooper
Sent: Wednesday, July 1, 2015 23:08
To: = McGarry, Tom
Cc: modern@ietf.org
Subject: Re: = [Modern] charter edits

 

Further = edits have been incorporated into the first and last paragraphs based on = Richard Hill’s suggestions and resulting list discussion — = <http://data= tracker.ietf.org/doc/charter-ietf-modern/>. I think we’re = at the point of diminishing returns at this point (especially = considering Richard’s overall objection to this work moving = forward in the IETF), so I will hit the approval button unless someone = spots an error introduced in making the changes.

 

Alissa  

 

 

------=_NextPart_000_0034_01D0B466.D3D686A0-- From nobody Wed Jul 1 16:43:42 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9DC1B2C39 for ; Wed, 1 Jul 2015 16:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itGh67pY8rJj for ; Wed, 1 Jul 2015 16:43:38 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AE41B2C33 for ; Wed, 1 Jul 2015 16:43:35 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 42b74955.0.627880.00-2126.1787470.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 01 Jul 2015 23:43:35 +0000 (UTC) X-MXL-Hash: 55947b2704d874b4-fdb3eae052932e4651ab4431b1d83a60c702f401 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t61NhWKm026294; Wed, 1 Jul 2015 19:43:32 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t61NhQ2d026268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jul 2015 19:43:29 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 1 Jul 2015 23:43:10 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0224.002; Wed, 1 Jul 2015 19:43:09 -0400 From: "DOLLY, MARTIN C" To: "McGarry, Tom" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQstLEk/EVKozy60OW6OdQfnITd53DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABbgSAgAAGyID//71F8IAASZcA///GW4CAAGeMAIAACsOAgABaZgD//9QP8g== Date: Wed, 1 Jul 2015 23:43:09 +0000 Message-ID: <94C0E808-42D3-45B6-8DDD-C5093F749725@att.com> References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: NUMBER PORTABILITY, public X-AnalysisOut: [v=2.0 cv=IL61/HTG c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=BLceEmwcHowA:10 a=zOBTXjUuO1YA:10 a=hGBa] X-AnalysisOut: [WAWWAAAA:8 a=ZsyXEVtvAAAA:8 a=48vgC7mUAAAA:8 a=RpNjiQI2AAA] X-AnalysisOut: [A:8 a=LvZDosZVomc4NpFVhjQA:9 a=wPNLvfGTeEIA:10 a=7_HJHg2K5] X-AnalysisOut: [cHq0Qii:21 a=oIuHA7EEfb7n-Oxe:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 23:43:41 -0000 Tom Almost all you stated is policy/regulatory requirements. Did you read the F= CC order? Where are numbers being assigned to individuals? Martin Sent from my iPhone > On Jul 1, 2015, at 6:20 PM, McGarry, Tom wrote: >=20 > Number assignment is done today without a subscription to a communication= s > service. Numbers are allocated to carriers and carriers use that > inventory to assign to users as they sign up for subscriptions. There ar= e > lots of allocated numbers without subscriptions. I could envision a > scenario where a user gets a number from an administrator before they hav= e > enabled a communications service on that number. But just like today I > would expect the administration process to expect to see service enabled > at some time and reclaim it if it not. I could also see processes that > either require a subscription before getting the TN or require a short > timeframe between acquisition and service enablement. As stated in the > charter, solutions need to be flexible enough to accommodate different > policies. =20 >=20 > As to your other question, I see modern enabling different administration > models than are common today. >=20 > Recently in the US the FCC issued an order that said VoIP providers > (companies that are not regulatory recognized telecommunications service > providers) can be assigned numbers directly by the administrator. The > VoIP providers will still rely on TSPs for PSTN interconnection and > transport. This is a perfect example of a scenario that modern would > address - a protocol mechanism that would facilitate the interactions of > the administrator, the TSP and the VoIP provider. >=20 >=20 > On 7/1/15 12:56 PM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Chris's mail made me wonder about something. >>=20 >>=20 >>=20 >> Traditionally "end users" (individuals, Enterprises) have obtained >> telephone numbers as a byproduct of subscribing to some form of >> "telephony" service. Hence it made sense that the provider of the >> service be the source of the number. My reading of the current charter, >> and my observation of the presentations made by Jon and Henning in the >> Dallas IETF, lead me to believe MODERN will assume a different paradigm. >> The tools the wg develops may be usable to support the above, but would >> also support a couple of new (to me at least) notions >>=20 >>=20 >>=20 >> a) separation of telephone number assignment from subscription to >> telecommunications services, and >>=20 >> b) relaxation of the "hierarchy" through which numbers are allocated >> today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise t= o >> desk phone). >>=20 >>=20 >>=20 >> Is that understanding correct? >>=20 >>=20 >>=20 >> I have to say it comes more from Henning's "motivational" slides than >> from the charter itself. So I'm not sure these are _the_ objectives, >> _some_possible_ objectives, or a misinterpretation on my part. Apologie= s >> in advance if the latter is the case. >>=20 >>=20 >>=20 >> tim >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >>=20 >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Chris Wendt >>=20 >> Sent: Wednesday, July 01, 2015 11:18 AM >>=20 >> To: DOLLY, MARTIN C >>=20 >> Cc: Ben Campbell; DRAGE, Keith (Keith); modern@ietf.org; Henning >> Schulzrinne >>=20 >> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >> Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >>=20 >>=20 >> +1 >>=20 >>=20 >>=20 >> Although i know it has always been part of the proposal for Modern, I=B9= m >> sensing a shift in conversation or at least more of a segmentation for >> enterprise requirements vs. number administrator requirements. Is there >> any sense that the charter can and does represent both of these use >> cases, and there is any reasonable outcome that there would be a largely >> common set of functionality for both? >>=20 >>=20 >>=20 >> Or is there two explicit requirements, and in my mind very different >> solutions, hence my previous question about the analogy to DNS and IP >> address allocation. >>=20 >>=20 >>=20 >> I would agree the enterprise requirements are fairly straight forward. >> Entity A has a pool of telephone numbers they can provide some wholesale >> or transit relationship for and Entity B would like to provision and use >> those numbers. This perhaps could benefit from a standardized interface= , >> although i might argue that tropo and twilio and AT&T and others can >> differentiate their services based on better or worse interfaces (but >> that is a different discussion and maybe that=B9s a higher level interfa= ce >> than what would be defined here) >>=20 >>=20 >>=20 >> For the number administrator interface to those entities that are >> =B3governed=B2 to be responsible for telephone numbers, there is a diffe= rent >> set of requirements and a fuzzier path forward based on specific >> regulatory body rules and what needs to be enabled in that provisioning >> interface and registry database, specific to applying policy as part of >> the interface. Above and beyond the fact that there is things like >> number portability and other things that may or may not be common to bot= h >> use case. >>=20 >>=20 >>=20 >> To Martin=B9s point, unless there is clear requirements or a path to cle= ar >> requirements, it is difficult to engineer a solution or at least one tha= t >> would/could be adopted for either or both of the use cases. >>=20 >> Particularly if you are trying to address two at once. >>=20 >>=20 >>=20 >> Would definitely be interested in any clarification on the intent that i >> may have misunderstood or whether it is useful to clarify these and/or >> pick an explicit path towards one or the other. >>=20 >>=20 >>=20 >>=20 >>=20 >>>> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: >>>=20 >>=20 >>> May be I have been a System Engineer too long: >>=20 >>> 1. The service/capability requirements would be defined by >>> policy/regulatory needs. >>=20 >>> 2. Then the "tool" requirements would be derived from the >>> policy/regulatory needs >>=20 >>=20 >>> A builder needs to know what he is building in order to ensure that he >>> has the correct tools in his tool box.... >>=20 >>=20 >>> -----Original Message----- >>=20 >>> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >>=20 >>> Sent: Wednesday, July 01, 2015 9:34 AM >>=20 >>> To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) >>=20 >>> Cc: modern@ietf.org >>=20 >>> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>> Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >>=20 >>> To move the discussion forward, rather than cycling back to invoking >>> the terms, I'd be interested in hearing which requirements, precisely >>> and concretely, are likely to depend on policy and regulation. >>=20 >>=20 >>> Everybody has iterated again and again that the "who can get what" part >>> definitely does, but that's outside the protocol mechanism, just like >>> "who can see what web page" or "who can place what SIP call" is beyond >>> the concern of HTTP or SIP, beyond providing an authentication mechanis= m >>> that allows to associate a policy with a principal. >>=20 >>=20 >>> You must have specific issues in mind that go beyond that. >>=20 >>=20 >>> Henning >>=20 >>=20 >>> ________________________________________ >>=20 >>> From: DOLLY, MARTIN C [md3135@att.com] >>=20 >>> Sent: Wednesday, July 01, 2015 9:12 AM >>=20 >>> To: Ben Campbell; DRAGE, Keith (Keith) >>=20 >>> Cc: modern@ietf.org; Henning Schulzrinne >>=20 >>> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>> Distributing, Exposing, & Registering telephone Numbers (modern) >>=20 >>=20 >>> But this is the root of the issue here, the requirements for such a >>> solution is based on policy and regulation, that does not exist , yet..= .. >>=20 >>=20 >>> _______________________________________________ >>=20 >>> Modern mailing list >>=20 >>> Modern@ietf.org >>=20 >>>=20 >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman >>> _listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Huf= veeIDcLe >>> xtZ1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ= &s=3DC >>> HlbePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> Modern mailing list >>=20 >> Modern@ietf.org >>=20 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_ >> listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLext >> Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s= =3DCHlb >> ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_ >> listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLext >> Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s= =3DCHlb >> ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Wed Jul 1 16:49:26 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2701B2C3B for ; Wed, 1 Jul 2015 16:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kR0QVxVCb1V for ; Wed, 1 Jul 2015 16:49:20 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BED61B2C38 for ; Wed, 1 Jul 2015 16:49:19 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t61NnF5Q022716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Jul 2015 01:49:15 +0200 Received: from RHillNew (adsl-178-39-180-181.adslplus.ch [178.39.180.181]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t61NnEgF009690; Thu, 2 Jul 2015 01:49:14 +0200 From: "Richard Hill" To: "'Gorman, Pierce A [CTO]'" , "'Alissa Cooper'" , References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> In-Reply-To: <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> Date: Thu, 2 Jul 2015 01:49:17 +0200 Message-ID: <009a01d0b458$8c89b0a0$a59d11e0$@ch> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_009B_01D0B469.501280A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQs3fqEwQ50yu6z0i1W6uAK8HRwp3GrskwgACa+eA= Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 23:49:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_009B_01D0B469.501280A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_009C_01D0B469.501280A0" ------=_NextPart_001_009C_01D0B469.501280A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry for responding to this late but, as Alissa has already pointed out, RFC 7282 provides a pretty detailed discussion of consensus in IETF, see: http://www.rfc-editor.org/rfc/rfc7282.txt Best, Richard From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A [CTO] Sent: Wednesday, July 1, 2015 17:04 To: Alissa Cooper; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Alissa, I've admitted before, I'm a novice at IETF procedures. Your repeated use of the phrase "rough consensus" as a conclusion of fact caught my attention. I wondered, is there any IETF accepted definitiion of "rough consensus" that Alissa and others are adhering to that I'm just not aware of? A little research turned up an IETF.org document based on RFC 6722 Section 4.2 going into some detail on the topic of "Getting Things Done in a Working Group" at URL: https://www.ietf.org/tao.html#getting.things.done I've copied-and-pasted the sentences from the beginning of the section that I think are particularly relevant to understanding the IETF "consensus" view on the definition of "rough consensus". "One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision." "The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree." "Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong." There is some more verbiage related to the use of a Working Group Last Call (WGLC), but it isn't clear if this is before or after chartering. If its supposed to be done before, we skipped it I think. The Tao is not a legalistic document based on rigid parlimentary procedures and there is what I will call a power of fiat within the IESG and the WG chairs, meaning they can basically ignore the definitions given above. I can fully understand the anxiousness of many participants to end debate and just move on. Code prototyping has already happened and available for review (based on request only and an undefined approval process). Regardless, I have to ask, using the definitions of the IETF Tao, on what basis can it be claimed that "rough consensus" has been achieved for the MODERN charter? From what I can tell it was the power of fiat. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com cid:408000_086801428601145001@pvmxe13g01 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: June 30, 2015 4:01 PM To: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) I'd like to ask that each person participating in this discussion remember to be respectful of one another's points of view and focus on constructive dialogue. If you feel that you're wasting cycles on the current threads then feel free to change the subject to something more productive; likewise if you feel someone else is wasting your cycles, don't feel compelled to respond. To review the process that got us to the current point: The conclusion from the BoF in Dallas was that there was rough consensus in the room in support of forming the WG but that the charter and problem scope needed refinement (feel free to review the minutes: http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That process of refinement took place on this list over several months following the BoF. The charter was put out for review on June 12 with comments requested to be sent to the IESG by June 22. The IESG considered the two ITU-T related comments received (both after the deadline) and issued no blocking comments on the charter but asked that edits be considered on the basis of comments received. There were no other comments received or indications provided to the IESG about the readiness of this work for chartering. I'm still working on edits (Richard Hill pointed out that I missed his suggestions) and milestones are in the works as well. Thus this WG is being formed according to the usual process. Alissa _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ------=_NextPart_001_009C_01D0B469.501280A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for responding to this late but, as Alissa has already pointed = out, RFC 7282 provides a pretty detailed discussion of consensus in = IETF, see:

 

  http://www.rfc-editor.= org/rfc/rfc7282.txt


Best,

Richard

 

From:= = Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, = Pierce A [CTO]
Sent: Wednesday, July 1, 2015 = 17:04
To: Alissa Cooper; modern@ietf.org
Subject: = Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, = Exposing, & Registering telephone Numbers = (modern)

 

Alissa,

 

I’ve admitted before, I’m a novice at IETF = procedures.  Your repeated use of the phrase “rough = consensus” as a conclusion of fact caught my attention.  I = wondered, is there any IETF accepted definitiion of “rough = consensus” that Alissa and others are adhering to that I’m = just not aware of?

 

A little research turned up an IETF.org document based on RFC 6722 = Section 4.2 going into some detail on the topic of “Getting Things = Done in a Working Group” at URL: https://www.ie= tf.org/tao.html#getting.things.done

 

I’ve copied-and-pasted the sentences from the beginning of the = section that I think are particularly relevant to understanding the IETF = “consensus” view on the definition of “rough = consensus”.

 

“One fact that confuses many novices is that the = face-to-face WG meetings are much less important in the IETF than they = are in most other organizations. Any decision made at a face-to-face = meeting must also gain consensus on the WG mailing list. There are = numerous examples of important decisions made in WG meetings that are = later overturned on the mailing list, often because someone who couldn't = attend the meeting pointed out a serious flaw in the logic used to come = to the decision.”

 

“The general rule on disputed topics is that the Working = Group has to come to "rough consensus", meaning that a very = large majority of those who care must agree.”

 

“Rough consensus has been defined in many ways; a simple = version is that it means that strongly held objections must be debated = until most people are satisfied that these objections are wrong.”

 

There is some more verbiage related to the use of a Working Group Last = Call (WGLC), but it isn’t clear if this is before or after = chartering.  If its supposed to be done before, we skipped it I = think.

 

The Tao is not a legalistic document based on rigid parlimentary = procedures and there is what I will call a power of fiat within the IESG = and the WG chairs, meaning they can basically ignore the definitions = given above.

 

I can fully understand the anxiousness of many participants to end = debate and just move on.  Code prototyping has already happened and = available for review (based on request only and an undefined approval = process).

 

Regardless, I have to ask, using the definitions of the IETF Tao, on = what basis can it be claimed that “rough consensus” has been = achieved for the MODERN charter?  From what I can tell it was the = power of fiat.

 

Best regards,

 

 

Pierce Gorman

= Core Network Planning

= O: 913-439-4368

= pierce.gorman@sprint.com

3D"cid:408000_086801428601145001@pvmxe13g01"

 

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

 

I’d = like to ask that each person participating in this discussion remember = to be respectful of one another’s points of view and focus on = constructive dialogue. If you feel that you’re wasting cycles on = the current threads then feel free to change the subject to something = more productive; likewise if you feel someone else is wasting your = cycles, don’t feel compelled to respond.

 

To review the process that got us to the current = point:

 

The conclusion from the BoF in Dallas was that there = was rough consensus in the room in support of forming the WG but that = the charter and problem scope needed refinement (feel free to review the = minutes: htt= p://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That = process of refinement took place on this list over several months = following the BoF. The charter was put out for review on June 12 with = comments requested to be sent to the IESG by June 22. The IESG = considered the two ITU-T related comments received (both after the = deadline) and issued no blocking comments on the charter but asked that = edits be considered on the basis of comments received. There were no = other comments received or indications provided to the IESG about the = readiness of this work for chartering. I’m still working on edits = (Richard Hill pointed out that I missed his suggestions) and milestones = are in the works as well. Thus this WG is being formed according to the = usual process.

 

Alissa

 

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

------=_NextPart_001_009C_01D0B469.501280A0-- ------=_NextPart_000_009B_01D0B469.501280A0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAU8AAAA8CAYAAADmDDgpAAAT+klEQVR42uydCWyU55nHU2krVRtV mkqrXVW7ap22q12ttqvpVlXVNGldqWk4kmLCEcAcA76wx/PF5KIhJEwIBBIIDEm4CZlwXwnmCkc4 hvtwTIbLHMHGYDAYbBgwYGzAs/8/+l766t05GNsxE/tB+on53pnvnO/7zfM+z/t9fgT/AoIgCELC PBIWBEEQEuYRryAIgpAg4XBYEARBSJB2fwAEQRBEnoIgCCJPQRAEkacgCILIUxAEob3T7g+AIAiC yFMQBEHk+fC4XfGDFOBo78dBEASRZ0JQnCAAvO39WAiCIPJMVKBOEAJBkNLej4cgCCLPRASaCsK2 RJ3t/XgIgiDyTESgBUqgEoEKgiDyTEyghbZAg8ChtfuBq70fH0EQeQqxCkjltkD9WruLbd+qQM92 +R74B/AD8Cj4IXCAfwL/DH4M/hX8BPwM/AL8B/gv8EvgBP8LfgN+B34P/gBSwZ/BX0BH0Bk8C7qC bqAn6AX6gv7ABTJANsgFbuABL4CXwCtgKBgG3gAjwFtgFBgD3gXjwPtgIvgQTAZTwXQwC8wGfjAH zAcLwWKwFHwOCsFKsBp8AdaDL8EmsBlsBdvBTrAb7AVFoBjsB0FwCBwGJeAYOAFOglJwCpwGFeAs qATnQRW4CKpBDbgCQuAaqAU3wE1QB26BetAAboM74C5otAnbNLLd5o79+Xp7/jpw015urb2eq/Z6 L9vbcQlU2dtXaW9vBTht70epvV/H7f0ssff7IAjax6PYPj57wC6w0z5+Aft4bgQbwFqwBqwCK+zv YhlYAhaBBWAu+BR8Aj4GM8A0MNn+rn1gAhhvnwtj7HNjpH2uvGGfO0Ptc+kl+9zyADcYDLLBIOCy z8l0+xztYZ+zafY53Al0AE+BP4E/gifA4+C34NfgV+B/wH+D/wT/Dn4OUsC/2dfVv9jX2Y/s6+5R +zr8PvheuxdjggWksE2akqreJvIUeYo8RZ5C/PynQ3Xp9TaRp8hT5CnyFCILNKC674ZQicuIVL0i T5GnyFPkKfy9qx4CYVuQKZo8CyPkQwPAIfIUeYo8RZ7tHuY3lRg5rRWTQtpnvJpUAyJPkafIU+Qp AAjRZ4sxFfg1UaYY8lS4RJ4iT5GnyLPdow1fKlSRqE1qFHkWijxFniJPkWer8thjP0sBqcCRpLdv PqFJssAoLCkCxnw+4BB5ijxFnm1MnhBVGvCCgEah3ZbSiuJMA2GbUEuv25ayD7iaKFAv8Gt5T28s eRrvlQOnyFPkKfJsA/KERJygHIRjkNqK8iw01l3QgssOaMv1NnP40gJDniFDnj4jWlWEgEPk+eDy XPCxFVw42zrQ0vI8V5xRMeOD/NDMDz1XwTWR57cnzzWLrPnTJuWvbCvyVOIMgXAcHK0ozwJj3c4k lKcTLDDGf4YNXHrUaVCQjPJ847XsTx9//Ilw/349i7Oz0nfw9cg3cxa3tDw/merZ8t6ovP3g69Ld OcuUPMePyTv0/pi8wxPGuo+U7claR3muWmjt43aQRbOtQy0pz33r889zuYrmynP2FM9d0EiUPC8E B4axv/dge3uV56gRg7cP6P/86bYhT1MmwOyiM+JUkV9roqUP0jidZPJUAn1Sdc9VdGmQorWbeJNN nri4vVmZ6VspkezM9O3Pde1yRskTEdqLLSnPjEF9KpWwNi73rFPy1EW2daW1jfK8XNJvbb++Pa92 7tTp9oHN7l3JLE9jWY0kuMkd1ttFnm1AnpRkpO5xspGs8iSaPNMMOQbt94NR5Jmi35UEHA9bnvoF brLEb1F+bohgxPC/Za19c1j2+rFv566E4CZ5h+dsemt4zuapE/OXK3lePOCaOPFd96bR3sE7wa5Z H+Wvrz48YAYvLERfmyHmWrXsoS9nnhz3Tt4BRJ0H9XUOezXz9PxZ1v6tKz1cRtnrQ7PObl/tKSrf m7Xjg3Husg/Hu09hu46dKcos+uh99xlQsfRTq1SX59mvMkqwXVVTffkX5860LhzdnnsKXcea6ZPy LxfOsy6a8qzcP6hq5keeWnAdqYLaa8f71OjyPP/1wOsfT/bUg4bZkz23sW0NSp6MOvVlMdJc9InV iOMU1tsZfX69yX1XyZPL4LIIl4t13FDyXL3QuoFjVwduVu4feLl4g/sKt0/J8+rxPudWzLeqsT9X 5s20qvEjV055ni3OKMU+XyrZlnvSlOfkCe5zu7/wlCh5rltqleBYloNTB7fk7dXlyXQJjz+2dxN6 AyU4/pvZMyjbk7NCl2fNkf5z3x2VW7xhmbVSyRPfzap33srdze//2PbB0yLJc84Ma96IYdlfgg2f zbGmKHm+PjRzzeJPrAmmPF8eMuizT6dZI5NBnqlNyWuy0AK8NinAAQpAQMPH9kgRpUJLGxTa87g0 qXsVMdbtVG1qGTZ+4DT200uM3G5AX0+Tc58g0hhPEiPqVOIMKdlyOpnliQt4utn+9NNP16nXiA5P UZ47VntmdujQ4Zb52Y4dOtbvXZe/eNDA3ufstrggdXAJEj6upieNc5/EBfyVmu7Ro2sdI1J9HqQC LlASu9d6TnTu3OmO/t4zz3S+LzhP/oA6U57PPvtMoz6NSPw2BHqZ8oTIbprbZ0fpjbUn+tRHei8n u6/ZpgTKeRqGvDCwMdL7yA/WUZ4Fluv+vr3gcTXoETKEVMX9IdyX53s+d5uv8QNBgR7ja/yoXdHl CbmVcn7KM3QsfZ9rQK/rnM7N6XcFYqvla0jrsJIntr+aUT/bu3VLu7F/o3vDc891uf63VzLLdHlC aNv4mW925czHj+Ss3r26XeK0y9Wrotfz3S7yNbavSpenle/6mu1903uW4nus5Gv+MFOevXt3P4H1 VOjyxDEZzs8kqzy9TYje0kBQTRuEzHyl8X6aMe2KtF2x1m1Mm6Rqwg7HoxkD5wOg0CgI/VSJ0SBo itOYz/kwc57q4pwyIX8S/8eJf0wVjCCWGl2a6oTX5Vl1wPWuLk6+1qcpTkQZBylS1danT/caSOpC VkZ6lbG8EKKW0mjyjAXl2bNH1/vroETz8/rf4Ot48qQw9TZGfcVf5tfqbbi4G/VpRG13TBG+WDAo jO3nD0DYbF+7xLqLiPRurGWe2JlzXZenmV7Ad3MnMyO9AdFnheq2Q2rXIakGyhORfA33W5cnegnV PC7sto94Pfsi3z8cyN2vuu3Y13vH+tTerICSZ6eOHRuYQlHddkae/EzNkX6LlTz5HeL4UtrT0Cs5 wO93z7r8+arbjmLf55xHyXPbKs9UTiNaXa267e7c/kU8ryhP9UON+cYreTKVhO29lCzddkcEiXjZ noA84xWbymPIM2TKLiF5xh8hEGwFeRYALyjXI0v9DiSzym6I0wTtjz7W2vLEhb84XuSpT6N7N5on PLtcujxxwa7TPwfxbQZbDCnMSyTnGUuejDrZbcd2VBmRW5k+bXdfS9B1r4olz+M7BvPiPM9uu2qj wNCNbNAFi67srbFv593RxZdozlNv47KwzHouW5P2LV2efA/H4sbKBVaI28m2LSusaj3nif05x3ZE +GcQgZbx9edzPBVKnpSlHZnv4WsIvNLMeXIe33vub5Q8+QOm5zwhzc8oVKZaKM+Tu3OWcp5lc6wN lCfFicJj0Mx5Ds7ue0LJEz+yY7Afs/WcJ1NBXI7KefLHGvPsojyRfsl76qm/3MT3PDeZCka+KBGj HzhjyNP8fJomZL8ZYRryNOctUAPiE5BnxFytue5WyHmmgrGGIJ+JIk5nHHEqvMksT0QZ36iC0fK5 1nRdniPfyAnEiwrRdVzRUvLMHdwvpApGqs3u2lWo1wNdvetUwYhSiSZPRnGqYMTcoi4tJbFYJCJP 5jzjLW/MyNwGfb2Iwq6rgtFXG9zV0eZT8uT+Mgod+nLGVcpTddmPbM09QnlGm9eUJ47/MbNgxG47 u++UJ1IDR5jDVgUj+3xZE69ghB+yBThnysx1K3m+/WbOEk5jX18dNzpvFl/jhzIrmeTpMMZVmgRA ShyBUV6xIlpfVHmagk5cnua6na0sTwf4SBPfa6A8ijhdnI7PP3ZtbXnuXOPJhdACaphS17S/nuZr XCQr2HUyI08UNYabkacpT+TTzqiCEQsHiK72gn2MPFtTnuTqsfSj8SJPdoMjyRP5u7u6xCC126pg ZHOHNEeeesEI1BPmWPX1YptCpjwRvV0uWu+u4n6ASnAO4qzA/p7g/qIgc97e/0OQXA1ykDdVtZ3t jNjx3R8EQeSq9+PYFoMidttjyZMFI84/Z7q1g5EmilB7dHliXzaa8kQBsEjJE9/DQn6OxUb+AKMn 844ZeaL4NYTRJs9Bjvxgtz0p7zDS8odxc5dmt/0BotNAFHn62ZaYPOOvuxXlaT4wpBz4miNO4H9Y Oc+83P5rePK+8uKgz5U8UW19T+U8eSJr0dhlJvrNnCcqvIVqOq3LX69ePDjgAxQgVjDvaUaees5z 03LPesrTrLZDPFuaIk9VLEo058lKNsRUo+c90WWvh/zr/z6ddZtDiii7WJEnq+zo0lKeZhTPsZ93 cAzvt32x2GKVvW6INfC+VDGioD6aPDkqQMlT77az2o7RBNWstlOe6O4etyV3Tv2oKHn26N71FuVp dttxjEuRk9wbS55gAfPUKnfNaruSJ9teGjLoqCnPLl2eDSl5QoRHsf7zsbrtYDD2f6M671gwSkZ5 mpGbP0bu0hRQYZTl+B5AngXNlKc/SeSpBsEPjyJO/wOK0wccD0ueiKim4KRfhojn9VdfyliOIUSF uAg9Sp64iObqElASNavtKEhcUG0mkPI1jvNEseKQ+R7lCSFfMavtTZUnhr6U29Nxq+0mRgRci2FC V81KvCHKu5QnpGAWjbhfEavtIGbXHUWqG9HkCSqHvZpVx/3hUCXKE9X3Co97wE22qcgTHEYh5n7+ tqIo45CSJ4ZSnbKLXaevHO274/S+zF3oGZxh24PIE0O9Avws0gLf6OM82buwv6utlw65JmO7ZjDf qReMcG7tZnEIxapxlCe2xc9pU544Bq+xjZFnsj8YxBwDGjQLOjEFlLg8U5spT2+SyDMEpoKQIc4n VRU+DuUgNZlvz+QgeURMPkRdX6BifhD5wcMc54mxlUtMeWKM53h1segg93iWQ5UoTwxnuVehNeWJ i2UdixHNleem5dZJChSjBi4w54eL9RrHeSJFcDaWPDF8pt7I/dWpcZ5IN9RiRMA94ZnFHg5Vojwx VIcRpSlPVtf/nzz5eXb3+Xmz4q+GKsWSJ6rslcgj3tDn5XAlNVRJyZMFI74Hidaag+Q5PlYf6sXX aqhSPHmit7DBTrusNQfJs2DE9/QUDrvtesGIkac+eqN7967nTHnivCtgG3OeSS9PsyvfDHkG2oM8 KT1bfjsiiDP4oNFmst/bjq72aP1EhzAKKU99nCejCf0OI3TZfZDGIrAEEciUSPe2I19XyJwnKriL 9HvbAyutAHOeTX0wCIoiJfrFqwbJQy5KzLxz6lqkB4Ogkl3NnCfGd16KdIcRutcc73iLRLu3HV31 RqLf2w7B3mtDV968w4jLqge3IOi6RO8w4lAl/ggw8mzqHUYq55nIHUb4vkvT+/S4HOsOI373jDyj PRgEIww+ZM4z2h1GiK5XsdvOavt3TZ7OZsgzpH+mDcvTB6bp4zhBp3gVdTUo/rv0YBBEeVErtJQo hDUxmZ6qxAKJvo1m9x1RzWl5qlLTbs/Ej90yVTD6Np+qhO+pGjcHfPmdep5nlPGRKZEFFP/BHm1Y npmGEPPiSDMECr6rj6RDN3Yehyoh4jjJghFBt3gnCiCjk/GRdOiynmHOj7BgRDDI+wqitTJ5JF3T 5Yl85zYWjCDRhd+WPNcv9YzCSIfjHKqUjPJUuUmvLSwncNiv/WZlPFbRxhSn2WVPUnmWgxS1z00Q Z4oWYfqBL14lXR6GLM/zlOd5trGnKsUhBBwJzqPmS0kyefpb4g4jSlDLaY4FgThd9FT5MxwiT5Fn +5JnADgSmcccXJ9k8nS2kDz9IASGxLrVErjkbxiJPEWebVOeacAX5U9vOB+kkq7N7zfni/VUpUhy TfCpSqnx1hGtEGbssw94EywSBcG4GNL0Aof8ATiR5/+1d8cqbYVxGMaHikMQMthCEZR2EaSIAYvN olSXdNIShEDoYOkgLQ5aRBQlCKKIQ4sQKliEQEtQUAxiJbjoFYiX0EsIvYK+wqN8HEhOBqfkHX6L aAzf+X+PJzmR43j6BnAxZ3/tgf8UKsufuPc1fd92x9PxdDwdT+EC0YL8rRPNhzNpx9PxdDwdT8cT vBRvGE3H0/F0PB1PxxOccV43iqbj6Xg6no6n4xng3kS1uGj+u0mm7jiejqfj6XgCMVe8Ww2f46w0 c/WceNbk9hHj+UQ6OXAJ6ZIkB7VbnnKgewhpr7wIYtrPgLxiWIaI6jBRfSNphmuUuI7LBAOYkXdB YKeIbFamJccQ5yOx/RgEd5bofpE5Nsa8fI3Ed5lNtCaFIMIbsilbsh2J8TeCvMtGLcqPIMz78lMO 2NwlNvov+S1lHAaxPpYTQnF6H26cE5MLwlIl5JfEXBQeoo4rXOOKr0Pfr5/DJY9X5fEv+H3nBOyM iJ3y/E7kmOd9JASNqBE2KfEH6oD12Gd99ohckfXble9B7HZkm+BtygbRW5cC4VuVFY7fkixybOc5 1nNE8LPMMhOfIjH8IHlmKcdsZZm1yUgYM8zmhLyVsSCQaRmR10RySAaZ/QHpD2L5UvoIZo88l2fS zf5KEs4E+69TOu7jafG31qjJbTOf0ySeM5Jq97Uza2VtvwANopmSipTEITQzx7PJl+nv230dzMzx NDNzPM3MHE8zM8fTzMzxNDOzOv4DIDV//HSVjucAAAAASUVORK5CYII= ------=_NextPart_000_009B_01D0B469.501280A0-- From nobody Thu Jul 2 07:00:29 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C055B1A8A5E for ; Thu, 2 Jul 2015 07:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWAyzdMi_oIJ for ; Thu, 2 Jul 2015 07:00:13 -0700 (PDT) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) (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 2073D1A8A15 for ; Thu, 2 Jul 2015 07:00:09 -0700 (PDT) Received: by qkhu186 with SMTP id u186so52182022qkh.0 for ; Thu, 02 Jul 2015 07:00:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=VLdh8993tg3VPe+AJc/GcZFPI0kzFn5xO8lkkhSDgU0=; b=TpghwcycCn/HHdEoqdN2vOcFkwZ/6X+qsoB7wNIFuFU0gS0CG/kWKmGZJoV2oNghf5 fcAiufBDlf+1NR5xwD9Gsv2QmcXWk8aIVGGa5Orf88Et6lNhp5Cp+InqDWhepq0+69JI Qdl36sGkvarxGqpqK3KH89aGUoTAzEfhBnAEp7wRtQu3BHF/N3TNiZkZNFd6bPN1s1if m7KCJpIFOw/YjJUpAGVt87kVJ5K759Sy781qRaAMrCMYSBgZAWoOnd8cG+mvUWiiVZEa Tolpr2iz+mRAREPDMUBgDpluusklIWKIcFVIk7m0KidVA+ir6V66sAyP7rk/1WwPelPl HZxA== X-Gm-Message-State: ALoCoQkFpayoJyDbTiVRfcVDqc2R2ysEI5mqCQfU8i+ePGbLn0yApiW7wflOeY4vgkEgBeeW4tXU X-Received: by 10.140.40.39 with SMTP id w36mr41799424qgw.65.1435845608325; Thu, 02 Jul 2015 07:00:08 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9242:4e5:d5a6:e27e:e597? ([2601:41:c101:9242:4e5:d5a6:e27e:e597]) by mx.google.com with ESMTPSA id 47sm2777576qgt.15.2015.07.02.07.00.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 07:00:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: Date: Thu, 2 Jul 2015 10:00:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "McGarry, Tom" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Modern List Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:00:24 -0000 If the push is toward a single extensible protocol/interface, because = there is so many different owner/consumer scenarios and use-cases and = different regulatory environments we will end up spending years defining = 10=92s or 100=92s of =93modern=94 profiles to extend the base spec. Hmm=85 sounds familiar. > On Jul 1, 2015, at 6:55 PM, McGarry, Tom = wrote: >=20 > The charter does cover at least both scenarios you mention - "The = working > group will define an information management framework for the roles = and > functions involved in associating information with one or more TNs in = an > IP environment. The working group will also identity protocol = mechanisms > to support the interactions between the functions defined by the > framework." >=20 > The information related to a TN - subscriber, service, service = provider, > service address, etc. - is relatively finite. I would expect = information > exchanged between retail-wholesale to be somewhat different than that > between wholesale-administrator, but they're in the same ballpark. > Solving both should not be too difficult. >=20 > And as I stated elsewhere, the solutions are expected to be flexible = to > account for different policies. So information exchanged under one > policy, may not be the same information exchanged under another = policy. > But the WG should capture the superset. >=20 >=20 >=20 > On 7/1/15 12:18 PM, "Chris Wendt" wrote: >=20 >> +1 >>=20 >> Although i know it has always been part of the proposal for Modern, = I=B9m >> sensing a shift in conversation or at least more of a segmentation = for >> enterprise requirements vs. number administrator requirements. Is = there >> any sense that the charter can and does represent both of these use >> cases, and there is any reasonable outcome that there would be a = largely >> common set of functionality for both? >>=20 >> Or is there two explicit requirements, and in my mind very different >> solutions, hence my previous question about the analogy to DNS and IP >> address allocation. >>=20 >> I would agree the enterprise requirements are fairly straight = forward. >> Entity A has a pool of telephone numbers they can provide some = wholesale >> or transit relationship for and Entity B would like to provision and = use >> those numbers. This perhaps could benefit from a standardized = interface, >> although i might argue that tropo and twilio and AT&T and others can >> differentiate their services based on better or worse interfaces (but >> that is a different discussion and maybe that=B9s a higher level = interface >> than what would be defined here) >>=20 >> For the number administrator interface to those entities that are >> =B3governed=B2 to be responsible for telephone numbers, there is a = different >> set of requirements and a fuzzier path forward based on specific >> regulatory body rules and what needs to be enabled in that = provisioning >> interface and registry database, specific to applying policy as part = of >> the interface. Above and beyond the fact that there is things like >> number portability and other things that may or may not be common to = both >> use case. >>=20 >> To Martin=B9s point, unless there is clear requirements or a path to = clear >> requirements, it is difficult to engineer a solution or at least one = that >> would/could be adopted for either or both of the use cases. >> Particularly if you are trying to address two at once. >>=20 >> Would definitely be interested in any clarification on the intent = that i >> may have misunderstood or whether it is useful to clarify these = and/or >> pick an explicit path towards one or the other. >>=20 >>=20 >>> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: >>>=20 >>> May be I have been a System Engineer too long: >>> 1. The service/capability requirements would be defined by >>> policy/regulatory needs. >>> 2. Then the "tool" requirements would be derived from the >>> policy/regulatory needs >>>=20 >>> A builder needs to know what he is building in order to ensure that = he >>> has the correct tools in his tool box.... >>>=20 >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >>> Sent: Wednesday, July 01, 2015 9:34 AM >>> To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) >>> Cc: modern@ietf.org >>> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>> Distributing, Exposing, & Registering telephone Numbers (modern) >>>=20 >>> To move the discussion forward, rather than cycling back to invoking >>> the terms, I'd be interested in hearing which requirements, = precisely >>> and concretely, are likely to depend on policy and regulation. >>>=20 >>> Everybody has iterated again and again that the "who can get what" = part >>> definitely does, but that's outside the protocol mechanism, just = like >>> "who can see what web page" or "who can place what SIP call" is = beyond >>> the concern of HTTP or SIP, beyond providing an authentication = mechanism >>> that allows to associate a policy with a principal. >>>=20 >>> You must have specific issues in mind that go beyond that. >>>=20 >>> Henning >>>=20 >>> ________________________________________ >>> From: DOLLY, MARTIN C [md3135@att.com] >>> Sent: Wednesday, July 01, 2015 9:12 AM >>> To: Ben Campbell; DRAGE, Keith (Keith) >>> Cc: modern@ietf.org; Henning Schulzrinne >>> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>> Distributing, Exposing, & Registering telephone Numbers (modern) >>>=20 >>> But this is the root of the issue here, the requirements for such a >>> solution is based on policy and regulation, that does not exist , = yet.... >>>=20 >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>>=20 >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n >>> = _listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee= IDcLe >>> = xtZ1ooNcfp01IYIaVqsORjI&m=3D9uORpP0hGzE9S4A7IIpCY9PNWn06UsCjQ10ngvDS1xE&s=3D= n >>> FOf9-sTlWhwYP4Jid7VSqlTJqv0vHfn3TE9ueNAF7o&e=3D >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >> = listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >> = Z1ooNcfp01IYIaVqsORjI&m=3D9uORpP0hGzE9S4A7IIpCY9PNWn06UsCjQ10ngvDS1xE&s=3D= nFOf >> 9-sTlWhwYP4Jid7VSqlTJqv0vHfn3TE9ueNAF7o&e=3D=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Thu Jul 2 07:12:14 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C101A1BFA for ; Thu, 2 Jul 2015 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 k9YgdOyApZDI for ; Thu, 2 Jul 2015 07:12:10 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F03C1A1BFF for ; Thu, 2 Jul 2015 07:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1435846324; x=1467382324; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=b11On9Rl+wCgEo2EnLlJHP3eTMTpRz9ztZfvbXZqk0U=; b=qFqYeZVqqvZ03TWkDcp1Hm617LJzm8YlF7zcabiosLcHx8qFbVpTmuVa oAcgdu3Uv7k0EyqvIiwnnIZiL5wD2supSK4gJhhKDuBV0TUhYCzPgNGmK I8ytxLX20iBbyg+tvu36aIwAuvPI/k11Oj+IwDUamwTI0elUU7+IwC+Q3 0=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 02 Jul 2015 14:11:52 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.15,393,1432598400"; d="scan'208";a="1030731958" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 02 Jul 2015 14:11:50 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.151]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Thu, 2 Jul 2015 10:11:50 -0400 To: "McGarry, Tom" , "modern@ietf.org" Date: Thu, 2 Jul 2015 10:11:48 -0400 Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZcstxl3hd1E6WCqHXbRoG2J3DI3GAgAFjg4CAAApVAIAAATyAgAAEYYCAAAI6gIAAEawAgACuGgCAAFODAIABLI+AgAAGyICAAADHAIAABhUAgAAKuACAACMwAIAACsOAgAAXTgCAAPxkwA== Message-ID: <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com> References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:12:13 -0000 Tom, My first statement was specifically about how "end users" obtain telephone = numbers. Your response addresses how service providers obtain telephone nu= mbers. The two are orthogonal. The scenario you envision ("a user gets a number from an administrator befo= re they have enabled a communications service on that number") is more what= I was asking about. It's useful to hear concrete ideas, even if they're j= ust examples of the types of capability we intend to enable. To make progr= ess we need to get beyond vague statements about supporting "a wide range o= f policies" and generate actual use cases. I will also note that this scenario raises regulatory / policy concerns. B= ut still I thank you for describing it. In my opinion any non-trivial use = case will raise such concerns. In the end we need requirements in order to= judge proposed solutions, and we need use cases to drive those requirement= s. The fact that a use case has policy implications should not IMHO elimin= ate it from consideration, but it's a factor. Final point... to discuss use cases intelligently we need the "numbering SM= Es" to actively participate. To get that we have to bring this discussion = down out of the clouds... as long as we're talking in generalities ("wide r= ange of policies..."), you won't hear from them. The ones in my company, a= t any rate, are baffled. Tim -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: Wednesday, July 01, 2015 5:20 PM To: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Number assignment is done today without a subscription to a communications = service. Numbers are allocated to carriers and carriers use that inventory= to assign to users as they sign up for subscriptions. There are lots of a= llocated numbers without subscriptions. I could envision a scenario where = a user gets a number from an administrator before they have enabled a commu= nications service on that number. But just like today I would expect the a= dministration process to expect to see service enabled at some time and rec= laim it if it not. I could also see processes that either require a subscr= iption before getting the TN or require a short timeframe between acquisiti= on and service enablement. As stated in the charter, solutions need to be = flexible enough to accommodate different policies. =20 As to your other question, I see modern enabling different administration m= odels than are common today. Recently in the US the FCC issued an order that said VoIP providers (compan= ies that are not regulatory recognized telecommunications service providers) can be assigned numbers directly by the administrator. The VoIP= providers will still rely on TSPs for PSTN interconnection and transport. = This is a perfect example of a scenario that modern would address - a prot= ocol mechanism that would facilitate the interactions of the administrator,= the TSP and the VoIP provider. On 7/1/15 12:56 PM, "Dwight, Timothy M (Tim)" wrote: >Chris's mail made me wonder about something. > > > >Traditionally "end users" (individuals, Enterprises) have obtained=20 >telephone numbers as a byproduct of subscribing to some form of=20 >"telephony" service. Hence it made sense that the provider of the=20 >service be the source of the number. My reading of the current=20 >charter, and my observation of the presentations made by Jon and=20 >Henning in the Dallas IETF, lead me to believe MODERN will assume a differ= ent paradigm. >The tools the wg develops may be usable to support the above, but would=20 >also support a couple of new (to me at least) notions > > > >a) separation of telephone number assignment from subscription to=20 >telecommunications services, and > >b) relaxation of the "hierarchy" through which numbers are allocated=20 >today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise=20 >to desk phone). > > > >Is that understanding correct? > > > >I have to say it comes more from Henning's "motivational" slides than=20 >from the charter itself. So I'm not sure these are _the_ objectives,=20 >_some_possible_ objectives, or a misinterpretation on my part. =20 >Apologies in advance if the latter is the case. > > > >tim > > > > > > > >-----Original Message----- > >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Chris Wendt > >Sent: Wednesday, July 01, 2015 11:18 AM > >To: DOLLY, MARTIN C > >Cc: Ben Campbell; DRAGE, Keith (Keith); modern@ietf.org; Henning=20 >Schulzrinne > >Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,=20 >Distributing, Exposing, & Registering telephone Numbers (modern) > > > >+1 > > > >Although i know it has always been part of the proposal for Modern, I=B9m= =20 >sensing a shift in conversation or at least more of a segmentation for=20 >enterprise requirements vs. number administrator requirements. Is=20 >there any sense that the charter can and does represent both of these=20 >use cases, and there is any reasonable outcome that there would be a=20 >largely common set of functionality for both? > > > >Or is there two explicit requirements, and in my mind very different=20 >solutions, hence my previous question about the analogy to DNS and IP=20 >address allocation. > > > >I would agree the enterprise requirements are fairly straight forward. >Entity A has a pool of telephone numbers they can provide some=20 >wholesale or transit relationship for and Entity B would like to=20 >provision and use those numbers. This perhaps could benefit from a=20 >standardized interface, although i might argue that tropo and twilio=20 >and AT&T and others can differentiate their services based on better or=20 >worse interfaces (but that is a different discussion and maybe that=B9s a= =20 >higher level interface than what would be defined here) > > > >For the number administrator interface to those entities that are=20 >=B3governed=B2 to be responsible for telephone numbers, there is a=20 >different set of requirements and a fuzzier path forward based on=20 >specific regulatory body rules and what needs to be enabled in that=20 >provisioning interface and registry database, specific to applying=20 >policy as part of the interface. Above and beyond the fact that there=20 >is things like number portability and other things that may or may not=20 >be common to both use case. > > > >To Martin=B9s point, unless there is clear requirements or a path to=20 >clear requirements, it is difficult to engineer a solution or at least=20 >one that would/could be adopted for either or both of the use cases. > >Particularly if you are trying to address two at once. > > > >Would definitely be interested in any clarification on the intent that=20 >i may have misunderstood or whether it is useful to clarify these=20 >and/or pick an explicit path towards one or the other. > > > > > >> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: > >>=20 > >> May be I have been a System Engineer too long: > >> 1. The service/capability requirements would be defined by=20 >>policy/regulatory needs. > >> 2. Then the "tool" requirements would be derived from the=20 >>policy/regulatory needs > >>=20 > >> A builder needs to know what he is building in order to ensure that=20 >>he has the correct tools in his tool box.... > >>=20 > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > >> Sent: Wednesday, July 01, 2015 9:34 AM > >> To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) > >> Cc: modern@ietf.org > >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering,=20 >>Distributing, Exposing, & Registering telephone Numbers (modern) > >>=20 > >> To move the discussion forward, rather than cycling back to invoking=20 >>the terms, I'd be interested in hearing which requirements, precisely=20 >>and concretely, are likely to depend on policy and regulation. > >>=20 > >> Everybody has iterated again and again that the "who can get what"=20 >>part definitely does, but that's outside the protocol mechanism, just=20 >>like "who can see what web page" or "who can place what SIP call" is=20 >>beyond the concern of HTTP or SIP, beyond providing an authentication=20 >>mechanism that allows to associate a policy with a principal. > >>=20 > >> You must have specific issues in mind that go beyond that. > >>=20 > >> Henning > >>=20 > >> ________________________________________ > >> From: DOLLY, MARTIN C [md3135@att.com] > >> Sent: Wednesday, July 01, 2015 9:12 AM > >> To: Ben Campbell; DRAGE, Keith (Keith) > >> Cc: modern@ietf.org; Henning Schulzrinne > >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering,=20 >>Distributing, Exposing, & Registering telephone Numbers (modern) > >>=20 > >> But this is the root of the issue here, the requirements for such a=20 >>solution is based on policy and regulation, that does not exist , yet.... > >>=20 > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>man=20 >>_listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eID >>cLe=20 >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ& >>s=3DC HlbePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D > > > >_______________________________________________ > >Modern mailing list > >Modern@ietf.org > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_=20 >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext=20 >Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=3D= C >Hlb ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_=20 >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext=20 >Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=3D= C >Hlb ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern From nobody Thu Jul 2 07:55:12 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CE01A8A0D for ; Thu, 2 Jul 2015 07:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny4GyQNfLHxV for ; Thu, 2 Jul 2015 07:55:07 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id BF7C41A8A08 for ; Thu, 2 Jul 2015 07:55:07 -0700 (PDT) Received: (qmail 9506 invoked by uid 0); 2 Jul 2015 14:55:05 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy5.mail.unifiedlayer.com with SMTP; 2 Jul 2015 14:55:05 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id nYU61q00U1MNPNq01YU9YW; Thu, 02 Jul 2015 14:28:13 -0600 X-Authority-Analysis: v=2.1 cv=UNFOQkvy c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=b-qjkDELlEU7XFp0BJYA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=pwkWNvYH5j4gDC1LeWEA:9 a=a3HcFjYkewAv6_p8:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=xGr15GBsbH3aKssOqHzwk1h3Cw6q2cuH8XYaD0GlxAs=; b=QC4aOxHDASXUt5yTUxBP7KCUeoMZq2XtVh960Gg8/Fl9zS5haCe3gJWLCx/SGzSc7ergFgcmXIYti/1S9CwgKXy6qqhRsa1UqJzZQN524QHvRSWlXe3nLk2h8N0nth9Z; Received: from [100.36.26.202] (port=61198 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAfZq-0007ds-8h; Thu, 02 Jul 2015 08:34:58 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Thu, 02 Jul 2015 10:34:53 -0400 From: Richard Shockey To: Alissa Cooper , "McGarry, Tom" Message-ID: Thread-Topic: [Modern] charter edits References: <585BD041-C1E2-4366-9FB6-DAB6F73F5A0E@cooperw.in> In-Reply-To: <585BD041-C1E2-4366-9FB6-DAB6F73F5A0E@cooperw.in> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518678098_1640965" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] charter edits X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:55:10 -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_3518678098_1640965 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable IMHO that would not be a good idea. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Modern on behalf of Alissa Cooper Date: Wednesday, July 1, 2015 at 5:07 PM To: "McGarry, Tom" Cc: "modern@ietf.org" Subject: Re: [Modern] charter edits Further edits have been incorporated into the first and last paragraphs based on Richard Hill=B9s suggestions and resulting list discussion =8B . I think we=B9re at th= e point of diminishing returns at this point (especially considering Richard=B9= s overall objection to this work moving forward in the IETF), so I will hit the approval button unless someone spots an error introduced in making the changes. Alissa =20 _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3518678098_1640965 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

IMHO= that would not be a good idea.


— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
w= ww.sipforum.org
richard<at>shockey.us
Skype-Linked= in-Facebook rshockey101
PSTN +1 703-593-2683

<= /div>

From: Mo= dern <modern-bounces@ietf.org> on behalf of Alissa Cooper <alis= sa@cooperw.in>
Date: Wednes= day, July 1, 2015 at 5:07 PM
To: "= McGarry, Tom" <Tom.McGarry@neust= ar.biz>
Cc: "modern@ietf.org" <modern@ietf.org>
Subject: = Re: [Modern] charter edits

Further edits have been incorporated into the first and last paragraphs= based on Richard Hill’s suggestions and resulting list discussion = 212; <http= ://datatracker.ietf.org/doc/charter-ietf-modern/>. I think we’r= e at the point of diminishing returns at this point (especially considering = Richard’s overall objection to this work moving forward in the IETF), = so I will hit the approval button unless someone spots an error introduced i= n making the changes.

Alissa  

_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3518678098_1640965-- From nobody Thu Jul 2 08:02:34 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82D41A88D6 for ; Thu, 2 Jul 2015 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dVzOZd71Hd8 for ; Thu, 2 Jul 2015 08:02:31 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9F1A88BF for ; Thu, 2 Jul 2015 08:02:30 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Chris Wendt , "McGarry, Tom" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAAbxWAgAD8moD//8kT+w== Date: Thu, 2 Jul 2015 15:02:29 +0000 References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Modern List Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 15:02:32 -0000 Can you enumerate, roughly, the spectrum you have in mind? In our implement= ation, we (my two grad students and I) looked at a range of options and exi= sting databases (including the LERG) and found this all pretty manageable.= =0A= =0A= Generally, we divided the elements "attached" to each number (or block, alt= hough we decided for simplicity to avoid dealing with blocks since you then= have to worry about block-common and number-specific properties) into a se= t of broad categories:=0A= =0A= * who (the entity being assigned, identified by a carrier code or some othe= r opaque identifier that leads to a record identifying an entity), with two= levels (equivalent to OCN and altSPID).=0A= =0A= * reachability (URL)=0A= =0A= * security (certificates, porting PIN)=0A= =0A= * properties (media, service type, ...)=0A= =0A= Fortunately, we have decades of precedent we can draw on, given the well-es= tablished databases.=0A= =0A= As you said, I think we can make more progress if everybody enumerates spec= ific issues or examples, rather than raising general concerns.=0A= =0A= >From my experience in the SIP space, adding informational content to a prot= ocol is easy (mainly syntax and registration); things that change the proto= col flow are harder.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt [chris-ietf= @chriswendt.net]=0A= Sent: Thursday, July 02, 2015 10:00 AM=0A= To: McGarry, Tom=0A= Cc: Modern List=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= If the push is toward a single extensible protocol/interface, because there= is so many different owner/consumer scenarios and use-cases and different = regulatory environments we will end up spending years defining 10=92s or 10= 0=92s of =93modern=94 profiles to extend the base spec.=0A= =0A= Hmm=85 sounds familiar.=0A= =0A= From nobody Thu Jul 2 08:08:17 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166561A8953 for ; Thu, 2 Jul 2015 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3xnM4_LWl_G for ; Thu, 2 Jul 2015 08:08:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093D31A8968 for ; Thu, 2 Jul 2015 08:08:11 -0700 (PDT) Received: from BL2FFO11OLC003.protection.gbl (10.173.160.34) by BL2FFO11HUB043.protection.gbl (10.173.161.119) with Microsoft SMTP Server (TLS) id 15.1.201.10; Thu, 2 Jul 2015 15:08:10 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm3.corp.sprint.com (144.230.32.82) by BL2FFO11OLC003.mail.protection.outlook.com (10.173.161.187) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Thu, 2 Jul 2015 15:08:10 +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 t62F7Kgj039334; Thu, 2 Jul 2015 11:08:09 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm3.corp.sprint.com with ESMTP id 1v9p33cvgs-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Jul 2015 11:08:09 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 2 Jul 2015 11:08:08 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Thu, 2 Jul 2015 10:08:08 -0500 From: "Gorman, Pierce A [CTO]" To: "Dwight, Timothy M (Tim)" , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZz5JGBH3WP0iIwhHO+Ycc+Z3DI3GAgAFjg4CAAApVAIAAATyAgAAEYYCAAAI6gIAAEawAgACuGgCAAFODAIABLI+AgAAGyICAAADHAIAABhUAgAAKuACAACMwAIAACsOAgAAXTgCAAV2qAP//sEaQ Date: Thu, 2 Jul 2015 15:08:07 +0000 Message-ID: <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.21] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC003; 1:eAjhr/DY8CMpTKbHOCODZPZjBHBQc3NZBp05ppqKQN7t3P9xFUOMmizPPylU3pnNI1459nBAjuyamburbCjgnpc4EMxJo7Fq6ULPwGVgjmVDHn4GDm/K2EBR9lBLjQM3F+Y2FHxHg79Vws5eJZ7/Q7RR5xbnkooO1XpVdIEv5IYXKf624FSHDErT4jmZKz/ACiwAbdSHVLNZBkHgY5QEH6YNpGynGZ/DaIogeLifOErdxruj8DMaULAaWP5uc4SwGzn2PBK/5SgE28y3shm6BrY6smKWLqiJbIl8c8tDpJPX6vTmDc/1WxdY05JgWtKn X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(448002)(24454002)(51704005)(189002)(13464003)(199003)(479174004)(377454003)(5001770100001)(19580405001)(19580395003)(23756003)(106116001)(106466001)(85326001)(108616004)(24736003)(5003600100002)(77156002)(62966003)(5250100002)(561944003)(86362001)(2501003)(87936001)(2656002)(50466002)(76176999)(54356999)(50986999)(189998001)(5001960100002)(107886002)(46102003)(92566002)(33646002)(2900100001)(2950100001)(47776003)(6806004)(102836002)(15975445007)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB043; H:preapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB043; 2:igEO7ikhbRHovDzAlF7u/BG0z5HsH9uBBBWrKr61BvlYr+NNFMcqAcn+cD4cLwzt; 3:hH8eUBxqKJR1yEOfU2b4gQVAOHF8SL/CBsOhoTEuSP8qKO8AWr1Lv0tLYhtGGfK58Z1JOcPTN0qoRd/4Hp0MCVmLjDk14kP0nd95G0i8TSlcLSKtsrjqfH90LW7DxDxO4n4FtWDJGMqsDZ0o6T54oR2A+upTYaqmaSPyHu0aTjz6KSMzwA2CHXaHD/bhVMm0c2lTU8hZjnql22hvQB8bQeLL4+ffRVyrj2yfEMstrOAlvdXrVNseRtbWlHgyKPlD; 20:Vz3UO8cD2cyVZs/vvPDdZx4SqGeIN0SSEhTGy9Psy0Pt0ze/XDACkYS4z4Kyr0tnhYbOIAKtzoo8uUHkus3SrnwJrDKRf1G1HNs2DwyleTGWRfUMyGJlFPX+9lC0ecb7TRaeYdAyeTYPOaymnhR2HFBd+POx2jVUywKfi7YJVtQyB6A+OTTowLXOKO+IgF8+E1/vf/pRTaI2YVMN47lALioU0knqr8whf5wdQDGxhnTMvbOEDxhf2PcrgnonvIc0; 4:V/9Z4+UXQwPEVtAzzJBhgmsgniB0ziBwOnay/s99MFcMSom307sRsqTRP6y8W4aZ/p6xie9YJqydtazLyYl5qK+UuhPsmdQ2WlvIWUdwnfQ1IgeOm9vyAXG+pKkEGXXDi4FouvuaIsMS1hojElLprfehkhfPkLcsGU518ybAqShpcgeVYSgsPjq3bcgxw2QieQLXJkcsSXNoA9qpRjMI+Ibq1MB1D8WAW0/V9/XIkK+7DWYJd6SC6gmXntl08xUqGE4rp9bRJ5ZN8gb62DU8QMgFvWdo2RM0egcjiT7SdYY= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BL2FFO11HUB043; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB043; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB043; X-Forefront-PRVS: 06259BA5A2 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BL2FFO11HUB043; 23:skcDDKOI0UltpTL3EVTbb7DnVfZmfOnhvERQuI?= =?iso-8859-1?Q?Id8w8OoADc36v6qW2H9oIelyi4dwC+Nem4It41yDlax4gAy8Zn1E6RFcVt?= =?iso-8859-1?Q?nuSKge3Us/qFJX8dQlGi0ZXssONlYg/ekGWd1hPB59feCxSWuaVRf5YZfA?= =?iso-8859-1?Q?ncQ/iglu0N2UbwRWOH1M+RsCPr0EJOQsE+DJGmAw/vpy/fQ3fQqH2HgMd+?= =?iso-8859-1?Q?cG8DmTR5e5dPzOSxC7Ntw1HKQ7mU1TfpVIWh4uDutlsxvzA6B9gZ7ukXdD?= =?iso-8859-1?Q?pYaLOP2an6w4E8BbxsziSOkv7fa6+5jR0I7lrt5obmoNHmy1OZZBbiBIea?= =?iso-8859-1?Q?2LAu33pwaRPco2YvzSk3r6b9xpOhP9C1Msl+3w8vyLRWUCUWm3iTyw1IdS?= =?iso-8859-1?Q?Q6dRm7FaN/loOGvROmnZe5m7JG/JDNMpCHMOzmfrPQL8O5ETQYPLPqQkCN?= =?iso-8859-1?Q?drYyIFihoxzNQFwUZEKZwlNmwAd7Pro/X81qG+DxUap6s/hUsSjO0uywgj?= =?iso-8859-1?Q?BgVNy0mPtB1pg7v1Fkc2kR5qZN1I93g6SsajT15RrLmnxOQOpe+sUTdx3K?= =?iso-8859-1?Q?QCzY5kREFv4UvhimB94fQJebyjGjEmSIdEMYOHxwUUFaqEqqabCWaR2rjN?= =?iso-8859-1?Q?w6Le2PsFVi+OawDBJ778BSzYKH8e/RiMXi4VJyvSfm0RkqWevtQ4UJkK4v?= =?iso-8859-1?Q?0bcShSOPsl9RqLW6H5TsYhjksY6jG3HbDc07tvEiOlMyAOxlrNp6qcHArt?= =?iso-8859-1?Q?T6Q3775c/wJ8wbr5nWf4Xw3l0A7VtONXokA89f2tqmPaK7bhK1iwp19e8O?= =?iso-8859-1?Q?cqzN5tbw/cssoX5K7bRSWcQQUi6t24iTAlACUjjGSsZtbGJ3C7Zdy5fGW2?= =?iso-8859-1?Q?EjabrZ+xijyN1xfCL5JJqUq4m/begjd0iL8M/dHQao8CfECv+rBvNofgXH?= =?iso-8859-1?Q?e66eftDdpbKX/zM94f2MZMIJb8QRWIwb0FzD8PAwhJ783b3E85bMZl9tBQ?= =?iso-8859-1?Q?uuVnPBs8rzjD7le23AZImMuIaU2YP8C3nv77MfzuSxAbNGgLVfESjWeX9J?= =?iso-8859-1?Q?+yZQlHeDe+uJQEYnHzn9dEgaIP23DL1MMq+i683sV/tZRNX+FF7KEtUYLp?= =?iso-8859-1?Q?l4cNbXRFSBvZ9zregoUiUEBD6t2US52B0vLGvEABANjIJJBbZy/WwUhIAc?= =?iso-8859-1?Q?LPWZn3TlVbbDgG7EWr0nXt5XTpi3PU7ULA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB043; 5:IuZU8CycW68sxFLF+bSrF62CNRyatdyGJDPLCc/9iYoK5xmXRuI2WHo+SszXmjCrYdLBseKq4bpLW4WVzfi6lKBIwW6w1iOT18Do5mE1UfFhmHsDvp/wdIoUCRc+BdWxxzA8cVBNfIOuGwzy7obIkg==; 24:kSHJRg/OM9OZ/KOj/maFt8tHm0W4y+ihcARH/c1rXB7p5A7L8bMEu37qrjrQ+0Eqt0HRC6zxF+I5O1QwE0WGAz2fhi9aj5c+qIQ9qeX45eg= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2015 15:08:10.2076 (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: BL2FFO11HUB043 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 15:08:16 -0000 Based on the different use case suggestions and comments of "legacy databas= es" being "interfaces" into whatever MODERN creates, it seems the idea is t= o create a super-database data model(s) and protocol(s) to enable "options = that bypass" the problems an NRA encounters employing conventional policy a= pproaches to updating regulated telecommunications infrastructure. Why don't we speak plainly? In the US, there is a perception that LERG and= NPAC, etc., are not the best data model and protocols for managing telepho= ne numbers and routing information for those numbers. (Who doesn't love TP= 4 and CMIS/CMIP?) OK. No heartburn with that view. One of the things that the SIP Forum/AT= IS Joint Task Force has worked on is different models for managing routing = information including a proposal for a monolithic per-TN URI database osten= sibly achieving what LERG and NPAC having URI fields will do. What this illustrated was that whether the databases are centralized or dis= tributed doesn't inhibit policy and that numbering and routing folks embrac= e thinking outside the "legacy" box. Another output of the JTF work was a focus on a "Tiered ENUM" proposal whic= h presents interesting operational challenges and highlighted the value (ag= ain) of developing something better than DNS for telecommunications routing= query and response which is why I enthusiastically embraced Richard Shocke= y's comments on this yesterday. Routing multimedia services could be greatly optimized if there were more a= nd better information available in both the query and the response. E.g., = if terminating number has media attributes which the origination does not s= upport, route through transcoding media anchor, otherwise use optimized TrF= O fast path. If the basic thrust of MODERN is to get to a new and better number administ= ration and routing information data model, can we not plainly say that, and= add a charter item to develop a non-SIP and non-DNS query response protoco= l in support of that model? (It will still encounter all sorts of policy q= uestions, but at least it will be easier to talk about what we're trying to= accomplish.) Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Dwight, Timothy = M (Tim) Sent: July 02, 2015 9:12 AM To: McGarry, Tom; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Tom, My first statement was specifically about how "end users" obtain telephone = numbers. Your response addresses how service providers obtain telephone nu= mbers. The two are orthogonal. The scenario you envision ("a user gets a number from an administrator befo= re they have enabled a communications service on that number") is more what= I was asking about. It's useful to hear concrete ideas, even if they're j= ust examples of the types of capability we intend to enable. To make progr= ess we need to get beyond vague statements about supporting "a wide range o= f policies" and generate actual use cases. I will also note that this scenario raises regulatory / policy concerns. B= ut still I thank you for describing it. In my opinion any non-trivial use = case will raise such concerns. In the end we need requirements in order to= judge proposed solutions, and we need use cases to drive those requirement= s. The fact that a use case has policy implications should not IMHO elimin= ate it from consideration, but it's a factor. Final point... to discuss use cases intelligently we need the "numbering SM= Es" to actively participate. To get that we have to bring this discussion = down out of the clouds... as long as we're talking in generalities ("wide r= ange of policies..."), you won't hear from them. The ones in my company, a= t any rate, are baffled. Tim -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom Sent: Wednesday, July 01, 2015 5:20 PM To: modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Number assignment is done today without a subscription to a communications = service. Numbers are allocated to carriers and carriers use that inventory= to assign to users as they sign up for subscriptions. There are lots of a= llocated numbers without subscriptions. I could envision a scenario where = a user gets a number from an administrator before they have enabled a commu= nications service on that number. But just like today I would expect the a= dministration process to expect to see service enabled at some time and rec= laim it if it not. I could also see processes that either require a subscr= iption before getting the TN or require a short timeframe between acquisiti= on and service enablement. As stated in the charter, solutions need to be = flexible enough to accommodate different policies. As to your other question, I see modern enabling different administration m= odels than are common today. Recently in the US the FCC issued an order that said VoIP providers (compan= ies that are not regulatory recognized telecommunications service providers) can be assigned numbers directly by the administrator. The VoIP= providers will still rely on TSPs for PSTN interconnection and transport. = This is a perfect example of a scenario that modern would address - a prot= ocol mechanism that would facilitate the interactions of the administrator,= the TSP and the VoIP provider. On 7/1/15 12:56 PM, "Dwight, Timothy M (Tim)" wrote: >Chris's mail made me wonder about something. > > > >Traditionally "end users" (individuals, Enterprises) have obtained >telephone numbers as a byproduct of subscribing to some form of >"telephony" service. Hence it made sense that the provider of the >service be the source of the number. My reading of the current >charter, and my observation of the presentations made by Jon and >Henning in the Dallas IETF, lead me to believe MODERN will assume a differ= ent paradigm. >The tools the wg develops may be usable to support the above, but would >also support a couple of new (to me at least) notions > > > >a) separation of telephone number assignment from subscription to >telecommunications services, and > >b) relaxation of the "hierarchy" through which numbers are allocated >today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise >to desk phone). > > > >Is that understanding correct? > > > >I have to say it comes more from Henning's "motivational" slides than >from the charter itself. So I'm not sure these are _the_ objectives, >_some_possible_ objectives, or a misinterpretation on my part. >Apologies in advance if the latter is the case. > > > >tim > > > > > > > >-----Original Message----- > >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Chris Wendt > >Sent: Wednesday, July 01, 2015 11:18 AM > >To: DOLLY, MARTIN C > >Cc: Ben Campbell; DRAGE, Keith (Keith); modern@ietf.org; Henning >Schulzrinne > >Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, >Distributing, Exposing, & Registering telephone Numbers (modern) > > > >+1 > > > >Although i know it has always been part of the proposal for Modern, I=B9m >sensing a shift in conversation or at least more of a segmentation for >enterprise requirements vs. number administrator requirements. Is >there any sense that the charter can and does represent both of these >use cases, and there is any reasonable outcome that there would be a >largely common set of functionality for both? > > > >Or is there two explicit requirements, and in my mind very different >solutions, hence my previous question about the analogy to DNS and IP >address allocation. > > > >I would agree the enterprise requirements are fairly straight forward. >Entity A has a pool of telephone numbers they can provide some >wholesale or transit relationship for and Entity B would like to >provision and use those numbers. This perhaps could benefit from a >standardized interface, although i might argue that tropo and twilio >and AT&T and others can differentiate their services based on better or >worse interfaces (but that is a different discussion and maybe that=B9s a >higher level interface than what would be defined here) > > > >For the number administrator interface to those entities that are >=B3governed=B2 to be responsible for telephone numbers, there is a >different set of requirements and a fuzzier path forward based on >specific regulatory body rules and what needs to be enabled in that >provisioning interface and registry database, specific to applying >policy as part of the interface. Above and beyond the fact that there >is things like number portability and other things that may or may not >be common to both use case. > > > >To Martin=B9s point, unless there is clear requirements or a path to >clear requirements, it is difficult to engineer a solution or at least >one that would/could be adopted for either or both of the use cases. > >Particularly if you are trying to address two at once. > > > >Would definitely be interested in any clarification on the intent that >i may have misunderstood or whether it is useful to clarify these >and/or pick an explicit path towards one or the other. > > > > > >> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C wrote: > >> > >> May be I have been a System Engineer too long: > >> 1. The service/capability requirements would be defined by >>policy/regulatory needs. > >> 2. Then the "tool" requirements would be derived from the >>policy/regulatory needs > >> > >> A builder needs to know what he is building in order to ensure that >>he has the correct tools in his tool box.... > >> > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > >> Sent: Wednesday, July 01, 2015 9:34 AM > >> To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith) > >> Cc: modern@ietf.org > >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) > >> > >> To move the discussion forward, rather than cycling back to invoking >>the terms, I'd be interested in hearing which requirements, precisely >>and concretely, are likely to depend on policy and regulation. > >> > >> Everybody has iterated again and again that the "who can get what" >>part definitely does, but that's outside the protocol mechanism, just >>like "who can see what web page" or "who can place what SIP call" is >>beyond the concern of HTTP or SIP, beyond providing an authentication >>mechanism that allows to associate a policy with a principal. > >> > >> You must have specific issues in mind that go beyond that. > >> > >> Henning > >> > >> ________________________________________ > >> From: DOLLY, MARTIN C [md3135@att.com] > >> Sent: Wednesday, July 01, 2015 9:12 AM > >> To: Ben Campbell; DRAGE, Keith (Keith) > >> Cc: modern@ietf.org; Henning Schulzrinne > >> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, >>Distributing, Exposing, & Registering telephone Numbers (modern) > >> > >> But this is the root of the issue here, the requirements for such a >>solution is based on policy and regulation, that does not exist , yet.... > >> > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>man >>_listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eID >>cLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ& >>s=3DC HlbePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D > > > >_______________________________________________ > >Modern mailing list > >Modern@ietf.org > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext >Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=3D= C >Hlb ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_modern&d=3DAwIGaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcL >ext >Z1ooNcfp01IYIaVqsORjI&m=3DFP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=3D= C >Hlb ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=3D _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Thu Jul 2 08:43:56 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F041ACC81 for ; Thu, 2 Jul 2015 08:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnd9HNxx9B7j for ; Thu, 2 Jul 2015 08:43:54 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id F290A1ACC7F for ; Thu, 2 Jul 2015 08:43:53 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAACsOAgABaZgCAAQnPAIAAD7yA///FsJM= Date: Thu, 2 Jul 2015 15:43:52 +0000 References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com>, <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> In-Reply-To: <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 15:43:55 -0000 Thank you for moving towards more specificity. Reachability and properties = do indeed seem like important facets of this problem (see my other note on = our experimental sandbox). One of the questions is whether a generic (HTTP?= ) query protocol should be specialized to just retrieve the URL or if this = a sufficiently important and different case to warrant a completely differe= nt mechanism.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A [CTO] = [Pierce.Gorman@sprint.com]=0A= Sent: Thursday, July 02, 2015 11:08 AM=0A= To: Dwight, Timothy M (Tim); McGarry, Tom; modern@ietf.org=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Based on the different use case suggestions and comments of "legacy databas= es" being "interfaces" into whatever MODERN creates, it seems the idea is t= o create a super-database data model(s) and protocol(s) to enable "options = that bypass" the problems an NRA encounters employing conventional policy a= pproaches to updating regulated telecommunications infrastructure.=0A= =0A= Why don't we speak plainly? In the US, there is a perception that LERG and= NPAC, etc., are not the best data model and protocols for managing telepho= ne numbers and routing information for those numbers. (Who doesn't love TP= 4 and CMIS/CMIP?)=0A= =0A= OK. No heartburn with that view. One of the things that the SIP Forum/AT= IS Joint Task Force has worked on is different models for managing routing = information including a proposal for a monolithic per-TN URI database osten= sibly achieving what LERG and NPAC having URI fields will do.=0A= =0A= What this illustrated was that whether the databases are centralized or dis= tributed doesn't inhibit policy and that numbering and routing folks embrac= e thinking outside the "legacy" box.=0A= =0A= Another output of the JTF work was a focus on a "Tiered ENUM" proposal whic= h presents interesting operational challenges and highlighted the value (ag= ain) of developing something better than DNS for telecommunications routing= query and response which is why I enthusiastically embraced Richard Shocke= y's comments on this yesterday.=0A= =0A= Routing multimedia services could be greatly optimized if there were more a= nd better information available in both the query and the response. E.g., = if terminating number has media attributes which the origination does not s= upport, route through transcoding media anchor, otherwise use optimized TrF= O fast path.=0A= =0A= If the basic thrust of MODERN is to get to a new and better number administ= ration and routing information data model, can we not plainly say that, and= add a charter item to develop a non-SIP and non-DNS query response protoco= l in support of that model? (It will still encounter all sorts of policy q= uestions, but at least it will be easier to talk about what we're trying to= accomplish.)=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Core Network Planning=0A= O: 913-439-4368=0A= pierce.gorman@sprint.com=0A= =0A= From nobody Thu Jul 2 09:25:35 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0392B1ACEA9 for ; Thu, 2 Jul 2015 09:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxmP3LLxlf39 for ; Thu, 2 Jul 2015 09:25:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E7F1ACE6E for ; Thu, 2 Jul 2015 09:25:31 -0700 (PDT) Received: from BN1BFFO11FD022.protection.gbl (10.58.144.33) by BN1BFFO11HUB055.protection.gbl (10.58.144.202) with Microsoft SMTP Server (TLS) id 15.1.201.10; Thu, 2 Jul 2015 16:25:29 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN1BFFO11FD022.mail.protection.outlook.com (10.58.144.85) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Thu, 2 Jul 2015 16:25:29 +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 t62GM2GO017415; Thu, 2 Jul 2015 12:25:29 -0400 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by preapdm3.corp.sprint.com with ESMTP id 1v9p33dgh1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Jul 2015 12:25:29 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 2 Jul 2015 11:25:28 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Thu, 2 Jul 2015 11:25:28 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZz5JGBH3WP0iIwhHO+Ycc+Z3DI3GAgAFjg4CAAApVAIAAATyAgAAEYYCAAAI6gIAAEawAgACuGgCAAFODAIABLI+AgAAGyICAAADHAIAABhUAgAAKuACAACMwAIAACsOAgAAXTgCAAV2qAP//sEaQgABpcwD//67V8A== Date: Thu, 2 Jul 2015 16:25:27 +0000 Message-ID: <98ee65d16f354ea0b13e264524a5a9de@PLSWE13M08.ad.sprint.com> References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com>, <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD022; 1:QCXJqR75EW2fz9bIZXUMR57jdvdPaPu6gSJhm36zux9vHk4YYfml6BkTCPQnMLkh1cHArhwnnERatPE93w26sivA/waFCByBSKIh9TifnV6C/eIHszc0IJ3LURa5gw1tUUDKmcE5OSQWI/Tb9WtkVVUgfUTQoA1me3xROd/K1AobMWPqsm2f+ArUmb4HA4dLFNhLl6wbmlOWTDlDtgjwk5DZDJJD+c9lXIQVu6JDKo67BqkucRIvg0/2zcOf8qOkyPbRFJaEdbs3zRBmf8x3Wf8RTGGV1vuzrj3bKnAD1CR1+/9SE8Z7nMTizTXKmkQI X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(448002)(189002)(377454003)(13464003)(199003)(5001960100002)(19580395003)(106466001)(19580405001)(189998001)(50986999)(46406003)(54356999)(97756001)(2656002)(46102003)(107886002)(77156002)(6806004)(87936001)(76176999)(47776003)(86362001)(23726002)(62966003)(85326001)(561944003)(2950100001)(2900100001)(5003600100002)(50466002)(33646002)(108616004)(106116001)(24736003)(92566002)(102836002)(2501003)(5001920100001)(5250100002)(5001770100001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB055; H:preapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB055; 2:1txmVV796rtxwLQ7r3MAIyyUOvg5hYKT+nSIiwts83Vkzie+MtgSTYE4Vy8etJ+I; 3:LAXiFnqi+9OhH2Y0lziJV1u/U7UG26NS/DwSzANCF3wDh3nSncsZZmzKB5K58HPTSwfKZgoYHIUewUNz/HXsXdoVVKlNDaOivSNBG+lW29fZF9tZ3LXLB/ADUewpma/3YiApoxy9PaNUFuQA4WX1n+dbngZ8xb2gE/OhWurIawDGK4LX0XO6n8gq1ibf/Fe+B1ASIUOTHxvCtd3EyBmdEjnc6g9Grl+K03wzlEhz01g=; 20:01slpF3XxzwZX6CMYUAfjLoKESO0Wy5VLKTiKSPDaaQX8hrilU021UpTFqHBhZSKBqkXMhzqatBq6w4ZD6hm6w+eTJMDRiJYvWBCcqkcRBT64EHTcM7Hag92YLf6aX1fOMOPhE4LwpYQwvXGOmMB4QS2ZzEf1XoDMn8XVQfSpXs9cdmpC+5YH8mDAuAFy4PNcCUfHpz6BmMhqYiFC21h5YM2AiRdi93eXaApeb2nQqS8Dpcrf1eDRuFVZcEGICGY; 4:jnrKAujQ5Iyb7O7h/rvrfKI9NcsT018uSnYRLky4ukcXMul7YsZ3qcTAKfYDiwGrMsXhqTNpspO3H5vZoQnQQTHZelL+Q2PzaL3ZLBoWOAY39duzM4lLiqimp6V86tVLVVqscGQG9EYpyy72MHDeWXk8HEXtr2gycNR11fpJ1/cEz9wU/VRe+XWsQEXNlEH27Fz1oeYqccvUqr6VeZKW7EXVEuCmnmSmkaCzXcYpH0My1Q04z95xS/7ikySdAwGVcxnAdWCRk4T0yCP/Tz1J8NhJtPShFLcYgbX/HCBE1ao= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB055; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB055; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB055; X-Forefront-PRVS: 06259BA5A2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB055; 23:PaU7frppy5CWRON8KuL466I05QpQBb204khZpKS?= =?us-ascii?Q?vWMTR4KiFS/pQuWcvBL3L2dLDn5t0LMdXS80cS5CcyVvkM+ZVzvXFFFUv5G5?= =?us-ascii?Q?cOxTM0JrIDdNT21YuYvBMlWEp/flxCdOJRj2mMeSs/BpcQn8r3ddML2iqAWJ?= =?us-ascii?Q?pwzFv+SmJQ/ckaaCoAFZ6RKb0PyOpEu0ApCP3D9hg3Hrt376E6U9OYBHeaW0?= =?us-ascii?Q?b2r7b7mcx7+ctsdZfYwASGOOqLh+cSYLvyb9pQ3DgrWCLTvshu/hmJZlFKNY?= =?us-ascii?Q?J794FGLlEdkuKGcvDGIa3YLz1hE/p5DR1Zb2xLuU6s/z/e696KYxCk16kqMd?= =?us-ascii?Q?pP3E4jwi5jOEg3vCmdbPNgG0gg1+a1kRM0382QtIoIYxkv6owvkC0s6c9mM4?= =?us-ascii?Q?4BDRmPiYxyHKBLtNGOBFaL4Mt5Xza+VHaqmcOh4zsilZ6pCHb/72WfUCkJjr?= =?us-ascii?Q?0zHMOjs6oMb7uM5thTT7zZArjJfzD/DIAvxaIhPsrbqKTp5Gu4GQrTZu3V+y?= =?us-ascii?Q?Zq4pOBG8tmyLp1Tu/7LFxcfx6RpvYkakhkrgH5+lHAWtoXbEG86XOF8ZpnKT?= =?us-ascii?Q?ETviSRbcpt6qnkYVq7AVNbmLkNI3YN+ZjpmLsY5KnpUOxIv6BMdEZsIEpKtO?= =?us-ascii?Q?CeViczDEC/aFWn0V22/i78LcZZPdSpeiu+lUyX3w1fBiGv+sNoKA+KWA6p+Y?= =?us-ascii?Q?D6lAhfyPbDZ8aL5r0DoN59jbOlCC36oHPrBil/TiwtmDZxjW1gtH902HXniU?= =?us-ascii?Q?n+yF8CCJSTHi5GPnCEwmbRTBZNb2bDpROk9vfNs6J8ZC4mwV8ln14Fkg2gEH?= =?us-ascii?Q?MrFnk5UpD8LgX/IuFdaK8rWHEnjC/RF+8U4QMfg64qXP8qa1H5rva+I0t2II?= =?us-ascii?Q?T60ehMT67clN2pEqjzMziX/XvMg6jjPW77gR35AYurjEXqlU0Bq0b5uwlnjI?= =?us-ascii?Q?rK2XeuGMcprh79+CThXGwE+dz4YuvbNE6T0hpvjCb+COl/P38uRCkMeJKyR2?= =?us-ascii?Q?ArqlJCdpzu1UY0YgRPELBhX9UY/dZdcbYZ2rC0o1xB+hxCP0DZFkGLyX4k3g?= =?us-ascii?Q?5i+QK5l33/IF4wY0FMuWQAwGZNWbG6SpaVbAmB7bmFKgGu+/bhprhLH/ssPC?= =?us-ascii?Q?leX8Ds2dFQk4lFWFDslU7pX8d7EY7S7Z8?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB055; 5:m+r4krgtNjmeI3MMzoA8uA3I2/4Rr2pwuXfR+Z2oYj5d28/J1d9r+yUlaJFwgck0I7ydytBAku8JDWA/Yrd6S1yFqDgdYTk5Y8DvWdbuwCxPxNHFtNRgegVzeBUxax+AytpU/nU2V8y78Kq8pnH6YQ==; 24:LQKSZzNWWdxA71XId0kbxSt3lqa05oZYcKo0DSn/y/BHA2jNVZ1GjFd06HahLq5gQmlncULNe/guW5T7DiNjE8qt2VdVXY7BuRTwUUNBCdg= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2015 16:25:29.8087 (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: BN1BFFO11HUB055 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 16:25:34 -0000 Agreed wrt HTTP. Media/Service attributes, and services associated with a number (URIs only?= ) seem like the most pertinent categories of interest. And wrt Joe's Hot Dog Stand as a use case, should count on Joe wanting mult= iple numbers to more easily differentiate service configuration for multipl= e personal communications services identities; business, personal, social, = etc., which begs the policy question of NRUF-like enforcement. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 02, 2015 10:44 AM To: Gorman, Pierce A [CTO]; modern@ietf.org Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Thank you for moving towards more specificity. Reachability and properties = do indeed seem like important facets of this problem (see my other note on = our experimental sandbox). One of the questions is whether a generic (HTTP?= ) query protocol should be specialized to just retrieve the URL or if this = a sufficiently important and different case to warrant a completely differe= nt mechanism. Henning ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A [CTO] = [Pierce.Gorman@sprint.com] Sent: Thursday, July 02, 2015 11:08 AM To: Dwight, Timothy M (Tim); McGarry, Tom; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Based on the different use case suggestions and comments of "legacy databas= es" being "interfaces" into whatever MODERN creates, it seems the idea is t= o create a super-database data model(s) and protocol(s) to enable "options = that bypass" the problems an NRA encounters employing conventional policy a= pproaches to updating regulated telecommunications infrastructure. Why don't we speak plainly? In the US, there is a perception that LERG and= NPAC, etc., are not the best data model and protocols for managing telepho= ne numbers and routing information for those numbers. (Who doesn't love TP= 4 and CMIS/CMIP?) OK. No heartburn with that view. One of the things that the SIP Forum/AT= IS Joint Task Force has worked on is different models for managing routing = information including a proposal for a monolithic per-TN URI database osten= sibly achieving what LERG and NPAC having URI fields will do. What this illustrated was that whether the databases are centralized or dis= tributed doesn't inhibit policy and that numbering and routing folks embrac= e thinking outside the "legacy" box. Another output of the JTF work was a focus on a "Tiered ENUM" proposal whic= h presents interesting operational challenges and highlighted the value (ag= ain) of developing something better than DNS for telecommunications routing= query and response which is why I enthusiastically embraced Richard Shocke= y's comments on this yesterday. Routing multimedia services could be greatly optimized if there were more a= nd better information available in both the query and the response. E.g., = if terminating number has media attributes which the origination does not s= upport, route through transcoding media anchor, otherwise use optimized TrF= O fast path. If the basic thrust of MODERN is to get to a new and better number administ= ration and routing information data model, can we not plainly say that, and= add a charter item to develop a non-SIP and non-DNS query response protoco= l in support of that model? (It will still encounter all sorts of policy q= uestions, but at least it will be easier to talk about what we're trying to= accomplish.) Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Thu Jul 2 09:30:23 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3A11ACE98 for ; Thu, 2 Jul 2015 09:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NumHoEGZH91Y for ; Thu, 2 Jul 2015 09:30:19 -0700 (PDT) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (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 9E3951A1AC6 for ; Thu, 2 Jul 2015 09:30:19 -0700 (PDT) Received: by qkei195 with SMTP id i195so55598185qke.3 for ; Thu, 02 Jul 2015 09:30:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cg8jpWNMKUZ7AT6Sr+swL6n/3Zkhlpx/Mh0AcB9W+FM=; b=PVBDctQFcTHigCRkTkZi4fA5McHh1UPB+L4pgJQV4YHkykBZkNigboTALOeJv4ZlsK 1tAirr4l8KN4ook6yhLEWgfBgh/Qnxau8IaIAt/8Cv5VtXyziiZY/f5YBACMeiuGREho tiU5Mx8aCFbW6fYjINPdwUPcCB0b8IkoYeN7EzUpI6NOsiBnHoeq70RDtinn/hNm3+CM h95o6JLy2ArvZ4sygYhjrO7DV3nFIkGj7WlPMkTxzFn8n+Qr7oO/rv/Lpnd6ZM1ZYtcN o/kNu7UuQngFu0NwU6nZFHwWAQOQxvhnAaLVxliNLboifGEJcD7DjDEDbYnxkmQgaJOg Px+w== X-Gm-Message-State: ALoCoQmjW3kIc20y5X7kCFZCSWWbcCGBwRO/F72YAg+k5SUgUl/Qfy6z4pYOIGPmWo4e/JP2Ji3W X-Received: by 10.140.236.147 with SMTP id h141mr45979598qhc.77.1435854618859; Thu, 02 Jul 2015 09:30:18 -0700 (PDT) Received: from [172.31.98.160] (74-95-172-43-Philadelphia.hfc.comcastbusiness.net. [74.95.172.43]) by mx.google.com with ESMTPSA id b31sm2987928qge.5.2015.07.02.09.30.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 09:30:17 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: Date: Thu, 2 Jul 2015 12:30:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henning Schulzrinne X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 16:30:21 -0000 I agree and we are going through a similar exercise in the context of = the ATIS testbed. As you said, the technology is easy. The premise of my concern was assuming that number administration in = various countries, wholesale, transit, centrex, PBXs, security industry, = cars, IoT in general, etc. would all have their own twist on = requirements and =93registry=94 data models. =20 A point I have stated before that typically in the HTTP/REST world, the = usual solution is for the provider to simply provide a customized = proprietary interface. That model often is preferred because it=92s = infinitely extensible and competitors are free to implement cool = features and functionality that attract continued usage and business. = There is no consensus needed, because if you provide a crappy interface, = you are out of business. Innovation happens much more quickly because = it=92s a competitive environment and nobody is beholden to a limited = interface that takes years to evolve. I see very few cases that a = standardized REST interface has made any traction, because typically it = represents the least common denominator of functionality, and changing = the hooks from one API provider to another is typically an exercise = measured in days and worst case weeks, so it=92s not much of an issue. I think, if I am interpreting your point, is that the telephone number = scope is fairly limited, there is only so much you can do with a = telephone number and data that needs to be associated with it. Perhaps, = in the end, the argument is, there is so little value or extensitbility = someone can associate with an interface for allocation of numbers, so = let=92s just provide a standard interface and call it a day. On the telephone administration part, when you get to regulatory = requirements of securing, managing, protecting the telephone number = allocation process. Incorporating a distributed database functionality = to allow for multiple participants in the distribution of telephone = number data and ability to change entries and allocate numbers and port = them from provider to provider. I think we are on a whole new plane of = requirements and functionality, which bears very little resemblance to = the core functionality of allocating a telephone number to a database. And the potential for those rules and procedures to be different for = either different regulatory bodies and certainly would be true of new = private or public numbering administrators, etc. Maybe I=92m wrong, and these things from policy point of view can be = separated, and only the core tools remain, but i think it would be a big = stretch personally. And i think the more efficient path is just to = design the interface with the policies and procedures as first class = requirements in the interface directly. =20 The technology, building the interface and database is easy, applying = policy around the interface is the hard part. And not that Modern isn=92t= up for the challenge, but agreement on how the policy part is = incorporated or even referenced in the charter seems to be getting in = the way. In either case, i don=92t disagree with the fact that i am spouting = general concerns and not providing specific examples, and maybe that = point is moot for now, so i=92ll shut up for a while. > On Jul 2, 2015, at 11:02 AM, Henning Schulzrinne = wrote: >=20 > Can you enumerate, roughly, the spectrum you have in mind? In our = implementation, we (my two grad students and I) looked at a range of = options and existing databases (including the LERG) and found this all = pretty manageable. >=20 > Generally, we divided the elements "attached" to each number (or = block, although we decided for simplicity to avoid dealing with blocks = since you then have to worry about block-common and number-specific = properties) into a set of broad categories: >=20 > * who (the entity being assigned, identified by a carrier code or some = other opaque identifier that leads to a record identifying an entity), = with two levels (equivalent to OCN and altSPID). >=20 > * reachability (URL) >=20 > * security (certificates, porting PIN) >=20 > * properties (media, service type, ...) >=20 > Fortunately, we have decades of precedent we can draw on, given the = well-established databases. >=20 > As you said, I think we can make more progress if everybody enumerates = specific issues or examples, rather than raising general concerns. >=20 > =46rom my experience in the SIP space, adding informational content to = a protocol is easy (mainly syntax and registration); things that change = the protocol flow are harder. >=20 > Henning >=20 > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt = [chris-ietf@chriswendt.net] > Sent: Thursday, July 02, 2015 10:00 AM > To: McGarry, Tom > Cc: Modern List > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > If the push is toward a single extensible protocol/interface, because = there is so many different owner/consumer scenarios and use-cases and = different regulatory environments we will end up spending years defining = 10=92s or 100=92s of =93modern=94 profiles to extend the base spec. >=20 > Hmm=85 sounds familiar. >=20 From nobody Thu Jul 2 10:59:02 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D401A1B72 for ; Thu, 2 Jul 2015 10:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0eMdh09WZkT for ; Thu, 2 Jul 2015 10:59:00 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id B89A91A1B69 for ; Thu, 2 Jul 2015 10:58:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Chris Wendt Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAAbxWAgAD8moD//8kT+4AAYOSA///UoUs= Date: Thu, 2 Jul 2015 17:58:57 +0000 References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 17:59:02 -0000 At least based on my implementation, the distributed model isn't THAT hard = and has use cases, as discussed.=0A= =0A= Standardization works when you have a reasonably large of users on both "si= des"; the dominant API model works if there are relatively few users (with = long-term stable relationships) where writing custom code is not a big deal= . Particularly given recent movements towards protecting "APIs" as copyrigh= table, there's value in open interfaces. We won't know if people will use t= hem, but we'll never find out if we don't try.=0A= =0A= ________________________________________=0A= From: Chris Wendt [chris-ietf@chriswendt.net]=0A= Sent: Thursday, July 02, 2015 12:30 PM=0A= To: Henning Schulzrinne=0A= Cc: McGarry, Tom; Modern List=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= I agree and we are going through a similar exercise in the context of the A= TIS testbed.=0A= =0A= As you said, the technology is easy.=0A= =0A= The premise of my concern was assuming that number administration in variou= s countries, wholesale, transit, centrex, PBXs, security industry, cars, Io= T in general, etc. would all have their own twist on requirements and =93re= gistry=94 data models.=0A= =0A= A point I have stated before that typically in the HTTP/REST world, the usu= al solution is for the provider to simply provide a customized proprietary = interface. That model often is preferred because it=92s infinitely extensi= ble and competitors are free to implement cool features and functionality t= hat attract continued usage and business. There is no consensus needed, be= cause if you provide a crappy interface, you are out of business. Innovati= on happens much more quickly because it=92s a competitive environment and n= obody is beholden to a limited interface that takes years to evolve. I see= very few cases that a standardized REST interface has made any traction, b= ecause typically it represents the least common denominator of functionalit= y, and changing the hooks from one API provider to another is typically an = exercise measured in days and worst case weeks, so it=92s not much of an is= sue.=0A= =0A= I think, if I am interpreting your point, is that the telephone number scop= e is fairly limited, there is only so much you can do with a telephone numb= er and data that needs to be associated with it. Perhaps, in the end, the = argument is, there is so little value or extensitbility someone can associa= te with an interface for allocation of numbers, so let=92s just provide a s= tandard interface and call it a day.=0A= =0A= On the telephone administration part, when you get to regulatory requiremen= ts of securing, managing, protecting the telephone number allocation proces= s. Incorporating a distributed database functionality to allow for multipl= e participants in the distribution of telephone number data and ability to = change entries and allocate numbers and port them from provider to provider= . I think we are on a whole new plane of requirements and functionality, w= hich bears very little resemblance to the core functionality of allocating = a telephone number to a database.=0A= =0A= And the potential for those rules and procedures to be different for either= different regulatory bodies and certainly would be true of new private or = public numbering administrators, etc.=0A= =0A= Maybe I=92m wrong, and these things from policy point of view can be separa= ted, and only the core tools remain, but i think it would be a big stretch = personally. And i think the more efficient path is just to design the inte= rface with the policies and procedures as first class requirements in the i= nterface directly.=0A= =0A= The technology, building the interface and database is easy, applying polic= y around the interface is the hard part. And not that Modern isn=92t up fo= r the challenge, but agreement on how the policy part is incorporated or ev= en referenced in the charter seems to be getting in the way.=0A= =0A= In either case, i don=92t disagree with the fact that i am spouting general= concerns and not providing specific examples, and maybe that point is moot= for now, so i=92ll shut up for a while.=0A= =0A= > On Jul 2, 2015, at 11:02 AM, Henning Schulzrinne wrote:=0A= >=0A= > Can you enumerate, roughly, the spectrum you have in mind? In our impleme= ntation, we (my two grad students and I) looked at a range of options and e= xisting databases (including the LERG) and found this all pretty manageable= .=0A= >=0A= > Generally, we divided the elements "attached" to each number (or block, a= lthough we decided for simplicity to avoid dealing with blocks since you th= en have to worry about block-common and number-specific properties) into a = set of broad categories:=0A= >=0A= > * who (the entity being assigned, identified by a carrier code or some ot= her opaque identifier that leads to a record identifying an entity), with t= wo levels (equivalent to OCN and altSPID).=0A= >=0A= > * reachability (URL)=0A= >=0A= > * security (certificates, porting PIN)=0A= >=0A= > * properties (media, service type, ...)=0A= >=0A= > Fortunately, we have decades of precedent we can draw on, given the well-= established databases.=0A= >=0A= > As you said, I think we can make more progress if everybody enumerates sp= ecific issues or examples, rather than raising general concerns.=0A= >=0A= > From my experience in the SIP space, adding informational content to a pr= otocol is easy (mainly syntax and registration); things that change the pro= tocol flow are harder.=0A= >=0A= > Henning=0A= >=0A= > ________________________________________=0A= > From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt [chris-ie= tf@chriswendt.net]=0A= > Sent: Thursday, July 02, 2015 10:00 AM=0A= > To: McGarry, Tom=0A= > Cc: Modern List=0A= > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distribut= ing, Exposing, & Registering telephone Numbers (modern)=0A= >=0A= > If the push is toward a single extensible protocol/interface, because the= re is so many different owner/consumer scenarios and use-cases and differen= t regulatory environments we will end up spending years defining 10=92s or = 100=92s of =93modern=94 profiles to extend the base spec.=0A= >=0A= > Hmm=85 sounds familiar.=0A= >=0A= =0A= From nobody Thu Jul 2 11:01:56 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2A81A1B87 for ; Thu, 2 Jul 2015 11:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7HgTaf2JNIJ for ; Thu, 2 Jul 2015 11:01:52 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id A7A1E1A1B82 for ; Thu, 2 Jul 2015 11:01:52 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAACsOAgABaZgCAAQnPAIAAD7yA///FsJOAAE/rgP//1x2z Date: Thu, 2 Jul 2015 18:01:50 +0000 References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com>, <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> , <98ee65d16f354ea0b13e264524a5a9de@PLSWE13M08.ad.sprint.com> In-Reply-To: <98ee65d16f354ea0b13e264524a5a9de@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 18:01:54 -0000 There are two known ways to deal with scarcity (and avoid waste): administr= ative (make rules that ensure "use it or lose it") and economical ("pay for= it"). I don't think we need to solve this here, but you wouldn't be surpri= sed that relevant folks are well aware of the trade-offs, given a rich hist= ory across identifiers, radio spectrum and non-network resources.=0A= =0A= ________________________________________=0A= From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com]=0A= Sent: Thursday, July 02, 2015 12:25 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Agreed wrt HTTP.=0A= =0A= Media/Service attributes, and services associated with a number (URIs only?= ) seem like the most pertinent categories of interest.=0A= =0A= And wrt Joe's Hot Dog Stand as a use case, should count on Joe wanting mult= iple numbers to more easily differentiate service configuration for multipl= e personal communications services identities; business, personal, social, = etc., which begs the policy question of NRUF-like enforcement.=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Core Network Planning=0A= O: 913-439-4368=0A= pierce.gorman@sprint.com=0A= =0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: July 02, 2015 10:44 AM=0A= To: Gorman, Pierce A [CTO]; modern@ietf.org=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Thank you for moving towards more specificity. Reachability and properties = do indeed seem like important facets of this problem (see my other note on = our experimental sandbox). One of the questions is whether a generic (HTTP?= ) query protocol should be specialized to just retrieve the URL or if this = a sufficiently important and different case to warrant a completely differe= nt mechanism.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A [CTO] = [Pierce.Gorman@sprint.com]=0A= Sent: Thursday, July 02, 2015 11:08 AM=0A= To: Dwight, Timothy M (Tim); McGarry, Tom; modern@ietf.org=0A= Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Based on the different use case suggestions and comments of "legacy databas= es" being "interfaces" into whatever MODERN creates, it seems the idea is t= o create a super-database data model(s) and protocol(s) to enable "options = that bypass" the problems an NRA encounters employing conventional policy a= pproaches to updating regulated telecommunications infrastructure.=0A= =0A= Why don't we speak plainly? In the US, there is a perception that LERG and= NPAC, etc., are not the best data model and protocols for managing telepho= ne numbers and routing information for those numbers. (Who doesn't love TP= 4 and CMIS/CMIP?)=0A= =0A= OK. No heartburn with that view. One of the things that the SIP Forum/AT= IS Joint Task Force has worked on is different models for managing routing = information including a proposal for a monolithic per-TN URI database osten= sibly achieving what LERG and NPAC having URI fields will do.=0A= =0A= What this illustrated was that whether the databases are centralized or dis= tributed doesn't inhibit policy and that numbering and routing folks embrac= e thinking outside the "legacy" box.=0A= =0A= Another output of the JTF work was a focus on a "Tiered ENUM" proposal whic= h presents interesting operational challenges and highlighted the value (ag= ain) of developing something better than DNS for telecommunications routing= query and response which is why I enthusiastically embraced Richard Shocke= y's comments on this yesterday.=0A= =0A= Routing multimedia services could be greatly optimized if there were more a= nd better information available in both the query and the response. E.g., = if terminating number has media attributes which the origination does not s= upport, route through transcoding media anchor, otherwise use optimized TrF= O fast path.=0A= =0A= If the basic thrust of MODERN is to get to a new and better number administ= ration and routing information data model, can we not plainly say that, and= add a charter item to develop a non-SIP and non-DNS query response protoco= l in support of that model? (It will still encounter all sorts of policy q= uestions, but at least it will be easier to talk about what we're trying to= accomplish.)=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Core Network Planning=0A= O: 913-439-4368=0A= pierce.gorman@sprint.com=0A= =0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= From nobody Thu Jul 2 11:41:52 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C51A88B3 for ; Thu, 2 Jul 2015 11:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-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 MLw19DZDxGh3 for ; Thu, 2 Jul 2015 11:41:48 -0700 (PDT) Received: from smtp109.ord1c.emailsrvr.com (smtp109.ord1c.emailsrvr.com [108.166.43.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C426B1A88B1 for ; Thu, 2 Jul 2015 11:41:48 -0700 (PDT) Received: from smtp22.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp22.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 36B2A1805D4; Thu, 2 Jul 2015 14:41:48 -0400 (EDT) Received: by smtp22.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A16DC1805EA; Thu, 2 Jul 2015 14:41:47 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.0.0.63] (c-71-198-88-125.hsd1.ca.comcast.net [71.198.88.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 02 Jul 2015 18:41:48 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <313a3ea588c845e1ad832696e36b13d7@PLSWE13M01.ad.sprint.com> Date: Thu, 2 Jul 2015 11:41:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88DDD845-D33C-464A-83F1-46BC6B5B1BE7@iii.ca> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> <313a3ea588c845e1ad832696e36b13d7@PLSWE13M01.ad.sprint.com> To: "Holmes, David W [CTO]" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Alissa Cooper , "Gorman, Pierce A \[CTO\]" , "modern@ietf.org" Subject: Re: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 18:41:50 -0000 > On Jul 1, 2015, at 1:06 PM, Holmes, David W [CTO] = wrote: >=20 > Cullen, >=20 > I believe the specific issue here is that the area of interest for = MODERN, telephone number administration, is regarded generally in the = industry as being at the margins of IETF influence, but is very = mainstream in other industry organizations. Therefore the balance of = interests between the FtF attendees to the BoF & the participants on = this reflector are somewhat skewed; specifically, the FtF will tend to = be attended by IETF-centric parties, whereas the reflector population = appears to more closely represent the organizations that have a = demonstrated interest in TN administration. >=20 > I would also note that the highly parallel scheduling of the FtF = meetings within the IETF meeting weeks can make it very difficult for = organizations with light representation to be present at all those = sessions that they would desire. In this case the BoF was scheduled = alongside other sessions that were of high interest to telcos, so = Sprint, for one, could not be represented there. >=20 That makes sense and this situation comes up fairly often at IETF where = some of the stakeholders are not at the meetings for wide range or = reasons. I think that is why it's critical to consider the input from = mailing lists - and I assume that is happening - but input provided at = the meeting is also relevant and needs to be considered.=20 > So given these considerations, and thus weighting the FtF & reflector = discussions, do we really feel that we have "a large number of informed = & relevant people" agreeing to provide "rough consensus"? (An entirely = open question). >=20 > BR/David Holmes Ignoring rough consensus here ... my personal observation would be it = seems there are a bunch of people from relevant communities interested = in spending some time discussing problems and solutions in this general = space. There are proof points that at least some of the simpler version = of the problem can be solved - this does not mean we should use them, = they are just an existence proof that at least some of the problems can = be solved. There seem to be a fair number of people that might use the = solutions if the IETF standardized them. Do we agree on the exact = solution - no. Do we even agree on what parts of the problem we have to = solve in the first part and what can be left to later - no. But I think = that largely we agree that there are some problems in this general space = where some useful solutions could be developed. In my mind we have some = people that want to do some work, figuring out the exact requirements = and solutions if what the WG will do.=20 From nobody Thu Jul 2 14:40:17 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76E91A8783 for ; Thu, 2 Jul 2015 14:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 o9qxWOhE8w5i for ; Thu, 2 Jul 2015 14:40:15 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3715D1A872B for ; Thu, 2 Jul 2015 14:40:15 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A84F520D5D for ; Thu, 2 Jul 2015 17:40:14 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 02 Jul 2015 17:40:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=2HPmG O+aoq4Rc9wW63mbWitnDI0=; b=i2+uwpAgRmXnApHtljjtfc4oawztFTKxTmjUj INVlL+wk4Xz8dEZa9i+t/E1CqALg1rT59Dr+7FXQX9Zvp9iZwDDMzIjmBYJlUoVK Lnd3k9Nd7V3iqlN4vSdwouSUFBgBsFon1fekNkDETIy6z2q8a/HIG2YkKm8P54TN 9tmsug= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=2HPmGO+aoq4Rc9wW63mbWitnDI0=; b=u8VJw j0FA6xeK1S3fdb7ls6rF+KL73ZQri5n04KyrWHJ3sWXNhDrCsj46tPfTuTwgogBM Hx4ScaUyp+LhgDM+nUQiRhizJEdvQpX99i2PdSa+eMx6b+NZJXHqX1M7szNEvbUE vqI8O+vpaY+/HR2Ip8+Vsqbm/WSVvO2NI7bK0U= X-Sasl-enc: g8qAjnW1QNdjRXVsA1YpspK3d9uR5ZpTcpya1YSLmCCG 1435873214 Received: from dhcp-171-68-20-130.cisco.com (dhcp-171-68-20-130.cisco.com [171.68.20.130]) by mail.messagingengine.com (Postfix) with ESMTPA id B66EFC00288; Thu, 2 Jul 2015 17:40:13 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_52A0174B-CCEC-43AF-8454-CF030FEF950A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Thu, 2 Jul 2015 14:40:12 -0700 Message-Id: <05AF65C0-B4ED-428B-A7C4-43992DA08283@cooperw.in> References: <585BD041-C1E2-4366-9FB6-DAB6F73F5A0E@cooperw.in> To: Richard Shockey X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "modern@ietf.org" , "McGarry, Tom" Subject: Re: [Modern] charter edits X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:40:16 -0000 --Apple-Mail=_52A0174B-CCEC-43AF-8454-CF030FEF950A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Richard, consider your objection ack=92ed. On Jul 2, 2015, at 7:34 AM, Richard Shockey wrote: >=20 > IMHO that would not be a good idea. >=20 >=20 > =97=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: Modern on behalf of Alissa Cooper = > Date: Wednesday, July 1, 2015 at 5:07 PM > To: "McGarry, Tom" > Cc: "modern@ietf.org" > Subject: Re: [Modern] charter edits >=20 > Further edits have been incorporated into the first and last = paragraphs based on Richard Hill=92s suggestions and resulting list = discussion =97 . I = think we=92re at the point of diminishing returns at this point = (especially considering Richard=92s overall objection to this work = moving forward in the IETF), so I will hit the approval button unless = someone spots an error introduced in making the changes. >=20 > Alissa =20 >=20 >=20 > _______________________________________________ Modern mailing list = Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_52A0174B-CCEC-43AF-8454-CF030FEF950A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Thanks Richard, consider your objection = ack=92ed.

On Jul 2, 2015, at 7:34 AM, Richard Shockey = <richard@shockey.us> = wrote:


IMHO that = would not be a good = idea.


=97 
Ric= hard Shockey
Shockey Consulting LLC
Chairman of the = Board SIP Forum
richard<= ;at>shockey.us
Skype-Linkedin-Faceboo= k rshockey101
PSTN +1 = 703-593-2683


From: = Modern <modern-bounces@ietf.org> = on behalf of Alissa Cooper <alissa@cooperw.in>
Date: Wednesday, July 1, 2015 at 5:07 = PM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>Cc: "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] charter = edits

Further edits have been incorporated into the first = and last paragraphs based on Richard Hill=92s suggestions and resulting = list discussion =97 <http://datat= racker.ietf.org/doc/charter-ietf-modern/>. I think we=92re at the = point of diminishing returns at this point (especially considering = Richard=92s overall objection to this work moving forward in the IETF), = so I will hit the approval button unless someone spots an error = introduced in making the changes.

Alissa =  


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

= --Apple-Mail=_52A0174B-CCEC-43AF-8454-CF030FEF950A-- From nobody Thu Jul 2 18:37:07 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254161A8763; Thu, 2 Jul 2015 14:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJsxyFXYip9N; Thu, 2 Jul 2015 14:33:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E18051A8774; Thu, 2 Jul 2015 14:33:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702213352.2927.46041.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 14:33:52 -0700 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 18:37:07 -0700 Cc: modern WG Subject: [Modern] WG Action: Formed Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:33:55 -0000 A new IETF working group has been formed in the Applications and Real-Time Area. For additional information please contact the Area Directors or the WG Chairs. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: https://mailarchive.ietf.org/arch/browse/modern/ Charter: The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing the acquisition and resolution of telephone numbers (TNs) in an IP environment. Devices, applications, and network tools increasingly need to request and acquire TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment. The working group will also identify protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs, with a preference for use of existing protocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. Maintaining reliability, real-time application performance, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM as well as work in other relevant standards organizations. The work of this group will focus on TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate communication with another user of a service. The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164, and is cognizant of other related ITU-T Recommendations, including E.164.1 and E.190. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reuse of MODERN mechanisms are out of scope for the MODERN working group. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. Milestones: Mar 2016 - Submit Architecture Overview Draft to IESG (Informational) Jul 2016 - Submit Information Model Draft to IESG (Standards Track) Jan 2017 - Submit TN Resolution Draft to IESG (Standards Track) Apr 2017 - Submit Enrollment Data Access Process Draft to IESG (Standards Track) Jun 2017 - Submit Enrollment Process Draft to IESG (Standards Track) From nobody Fri Jul 3 14:03:03 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05791A87E0 for ; Fri, 3 Jul 2015 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEN6FqyRznTe for ; Fri, 3 Jul 2015 14:02:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7281A87D4 for ; Fri, 3 Jul 2015 14:02:58 -0700 (PDT) Received: from BN1BFFO11FD010.protection.gbl (10.58.144.34) by BN1BFFO11HUB012.protection.gbl (10.58.144.159) with Microsoft SMTP Server (TLS) id 15.1.201.10; Fri, 3 Jul 2015 21:02:57 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN1BFFO11FD010.mail.protection.outlook.com (10.58.144.73) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Fri, 3 Jul 2015 21:02:57 +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 t63L2cUY003494; Fri, 3 Jul 2015 16:02:57 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm1.corp.sprint.com with ESMTP id 1v9sfcne85-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 03 Jul 2015 16:02:57 -0500 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 3 Jul 2015 16:02:56 -0500 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.1044.021; Fri, 3 Jul 2015 16:02:56 -0500 From: "Holmes, David W [CTO]" To: Henning Schulzrinne , "Gorman, Pierce A [CTO]" , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGXEwQ50yu6z0i1W6uAK8HRwp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAACsOAgABaZgCAAQnPAIAAD7yA///FsJOAAE/rgP//1x2zADiyVWA= Date: Fri, 3 Jul 2015 21:02:56 +0000 Message-ID: <4d905a901da143a49da1ef23741eebd6@PLSWE13M01.ad.sprint.com> References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com>, <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> , <98ee65d16f354ea0b13e264524a5a9de@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.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD010; 1:CjvQWnihis5nNfX8uTLGZO/pQvE7z3L2Pw+CpCkTs35tVbY7jgtUj6ZYKK2hiADaCyIfjnubWb2ljaf9LQ+U7bJV5BQtKK/1/KwEUMt/x7JKZCAWC1tJIjrzqIWfqHyEjQbH1DitQzgU/eW1CfE8vNTBeyOjdOLy3If/tJpDRsQqbkP7eadzgPR8l1kmUi+DDOBYeqwJ4QyFDPH3uPENOd8AkZRYWYy1t8NruWZ+Y33bUIowepRIhyt14iLl2A/9sOPyOJbsKCbD2Rrb6wVlwXEfqhZDmHthPK64vBqdkP9xZkbhLT2LvymbbGcODXn8 X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(377454003)(189002)(199003)(13464003)(2656002)(76176999)(50986999)(86362001)(19580405001)(561944003)(19580395003)(46102003)(50466002)(46406003)(54356999)(87936001)(97756001)(106116001)(92566002)(106466001)(5003600100002)(93886004)(24736003)(5001770100001)(5250100002)(5001920100001)(2501003)(5001960100002)(33646002)(47776003)(107886002)(189998001)(6806004)(62966003)(15975445007)(23726002)(2950100001)(2900100001)(108616004)(102836002)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB012; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB012; 2:AwHIhmHnlfVlm5fQquNS5kpQLebo29PerM46kVdqxpW/FmRnmmw235I7Wyt49DBM; 3:GmHbxDKCQ2MwzGPOihmb2m1U65gD4sTFNCP6oJuYKgtUFELVwIGe6mHrda8rNgLyN0Yyf7SjlAw/gPYiQX/T9W3Lu6fwdaMHUYk63KovbgfMIpWPDX7i2bfjUyCyA0+0g8mphC3y1vCtsEDnC8JssYDHFsHNvtvCdHfKToU4XxZxDTsqAhNKG4dnJvcGiY2OGCZIvZy4BbWPHGJiY2qKVCsMnhOklg9TSLOF2TLFfolfeF/cjqWBrgJbcOrwQ0yr; 20:L7agMalvQGxBsq7tXggzCcKs6JQxQe2wyTkHs6kqsR+VUO3j7wyweTrGLnEJAsgF1dOQTUaIrslFixmr31WZKetqTpAMeE32gW1gqNiYvDCv1eE4JFlX8DQ/baSGK3Sn4Rl28qFcnN3qYlW/gyNvL/nOKXuLqdTXGiGVfDRXVynYUab1L0gr6jOfrFOhEsUjl014Cx0hug3qR3/VCQx23wSojWGnuQRVjFRb99aEsmD/UyFQkbfja/u241qh8gol; 4:iauL9R+h19xqbXa6KEY/12jGC/sD+mdMjn72SSanCOZ9OdtZ5OXHmQlsH8EzgYi4ZCxDzEfE2WXsNa8jnnfiBsDVJVkHqoLr7W6l0RkChqZRWzWVeNjyDdy6+MsAIqUpgxc4fHgrkAmLCrIZy/2JLfeJ8UFOC1PeG+N/i7408Eyif8sCD658tfQaWiTFgn2R8WefMisUm6LgeWGCIfdP2qxWMvC4Bavf908ufJDSM+4KCSYV3tvmZk7DKZFLDcpuZXNFIAkR0CT7i/w1efAbpefLdCgd5lt5tsnsXro/sL0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB012; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB012; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB012; X-Forefront-PRVS: 0626C21B10 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB012; 23:QcdK8YLMYtcsNWJVVZsdOeQoj/U8CTXgs/M+VC2?= =?us-ascii?Q?bBAJxBXF/AEPr1V1MF6+d6/BpN63saSnzNnOCrmMf3H7qcB3mYhMa2FunByZ?= =?us-ascii?Q?UYaeVViDgcrPN9fOa3p5do3/U42FrK0ZBpSONTHs2lvgFQzzTBU2qBAuu4SC?= =?us-ascii?Q?JpK7EeVEPZ6o6IZ2QocwbxdDNaCHPws2jqXCS7fHuZGfl25/H9D9gdelTJg+?= =?us-ascii?Q?JjpP/bMa34OIQDCRH6tTFO/jFRCaqqhm+2hWWIujLDfW6GWskkc6et8KaJB2?= =?us-ascii?Q?40w7l0r4Dad7rwLQx2R7DiklXpCIyt6l/K88RGu7EUu6gTwGLILWjC13heyu?= =?us-ascii?Q?YRX8Y3VHt4MMBQ4nDcpZ2InghrF/IMZPRegksYwRMMgjeSd/E/RDq/fTkRHH?= =?us-ascii?Q?qaAW9rV7ZQLQ5JOxdRBTwYsd6HKr2VDHfGk3y3rorH8oBpDq92read3soRid?= =?us-ascii?Q?8Cxl1bpOFP/U7sj0uQUkqlFHfW7XMMKckoNVhiNo9xVe3pNxzYFCIm5ptxYU?= =?us-ascii?Q?IxTMHQepbhX9qy2W2Ad+O22GBNa3IVI9Swqdn6VZqeAKrDCk4zfbfFgLJTrQ?= =?us-ascii?Q?mRQEQTrDSgoqRk72PfJ6c0LdP+XN06zWponqsJ+SZ3vNWey1GGyIY9gZtBAn?= =?us-ascii?Q?1n2frSfhO7OQJdi6Pc+HC2PIg2s+6hmZB3KpiyPJc8BMO1X2TNPWNqWXyOp6?= =?us-ascii?Q?D5dBMR6JIKcTwm02kaiJk1E8qsvRDj5oG6bXVsKlOxZBkjM6chtQmFpsWa5f?= =?us-ascii?Q?VU7i9wCGWTDC1cdP7Nt77LbiL3W7xD1Q5Yv0z9pmvgsDQYTv+mTGLCI9K3lj?= =?us-ascii?Q?TwBSBzHBuSm1X9LH4EsSdWaNeR6T4xPRKsq0dRgl3QKUi8CNOUgzZmNtFZoS?= =?us-ascii?Q?e5sDYCLpbn42xU91SdLeDgp8litQ8B30rVYu29HME0jGFtWeQ+HPevjKGrT9?= =?us-ascii?Q?HeSYvIVOoUq2BY2pLrtmHOYcNS3rdmsX/+cOWNZAOTvEX1a+0mSb48FdGpAb?= =?us-ascii?Q?yboR36jKty2+IsoGGdbxL5YWnyYM4wW/jaM2cm0x1ZxEtRaCMtTfA6pylYco?= =?us-ascii?Q?AfsguCgcKyfY2rYhSfmH3dIMKU0RjBb2l2b1TAkxQKr6Vw7JeAHXwGjrt9T9?= =?us-ascii?Q?84TeNszBJ6yF920VqnJA2K1vEddzutMBa?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB012; 5:hRfrYZnYk3VG4wy8s/7X2OT3IuTpz5mbnjLORpTfehM0QmrmAYoz29Bs/ZHt+PUtyAq2ozcaZMDgGT+D82U8r1KKhxff5PoMNh0fsnUAQTTwStRdZUWBWntfPIZxtlu87PeP5ngI8XhmaQSlQYsZ9g==; 24:YEPWQ0j92n7WX6sYj4VL8SD5DEmGUWgV5FV6HvcG73au49m3q0CRHX5klwe7Wg7nbaL1esxIKb4WFKpLxAaOQB/zUmV/gtUJJyzfoMDnZ4g= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2015 21:02:57.7824 (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: BN1BFFO11HUB012 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 21:03:02 -0000 But the relevant issue to MODERN is that, at very least, any allocation/adm= inistration protocol MUST support mandatory (& preferably verifiable) usage= reporting to minimize wastage of any such scarce resource? David Holmes Standards +1 425 256 7082 david.holmes@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: Thursday, July 02, 2015 11:02 AM To: Gorman, Pierce A [CTO]; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) There are two known ways to deal with scarcity (and avoid waste): administr= ative (make rules that ensure "use it or lose it") and economical ("pay for= it"). I don't think we need to solve this here, but you wouldn't be surpri= sed that relevant folks are well aware of the trade-offs, given a rich hist= ory across identifiers, radio spectrum and non-network resources. ________________________________________ From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] Sent: Thursday, July 02, 2015 12:25 PM To: Henning Schulzrinne; modern@ietf.org Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Agreed wrt HTTP. Media/Service attributes, and services associated with a number (URIs only?= ) seem like the most pertinent categories of interest. And wrt Joe's Hot Dog Stand as a use case, should count on Joe wanting mult= iple numbers to more easily differentiate service configuration for multipl= e personal communications services identities; business, personal, social, = etc., which begs the policy question of NRUF-like enforcement. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 02, 2015 10:44 AM To: Gorman, Pierce A [CTO]; modern@ietf.org Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Thank you for moving towards more specificity. Reachability and properties = do indeed seem like important facets of this problem (see my other note on = our experimental sandbox). One of the questions is whether a generic (HTTP?= ) query protocol should be specialized to just retrieve the URL or if this = a sufficiently important and different case to warrant a completely differe= nt mechanism. Henning ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A [CTO] = [Pierce.Gorman@sprint.com] Sent: Thursday, July 02, 2015 11:08 AM To: Dwight, Timothy M (Tim); McGarry, Tom; modern@ietf.org Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) Based on the different use case suggestions and comments of "legacy databas= es" being "interfaces" into whatever MODERN creates, it seems the idea is t= o create a super-database data model(s) and protocol(s) to enable "options = that bypass" the problems an NRA encounters employing conventional policy a= pproaches to updating regulated telecommunications infrastructure. Why don't we speak plainly? In the US, there is a perception that LERG and= NPAC, etc., are not the best data model and protocols for managing telepho= ne numbers and routing information for those numbers. (Who doesn't love TP= 4 and CMIS/CMIP?) OK. No heartburn with that view. One of the things that the SIP Forum/AT= IS Joint Task Force has worked on is different models for managing routing = information including a proposal for a monolithic per-TN URI database osten= sibly achieving what LERG and NPAC having URI fields will do. What this illustrated was that whether the databases are centralized or dis= tributed doesn't inhibit policy and that numbering and routing folks embrac= e thinking outside the "legacy" box. Another output of the JTF work was a focus on a "Tiered ENUM" proposal whic= h presents interesting operational challenges and highlighted the value (ag= ain) of developing something better than DNS for telecommunications routing= query and response which is why I enthusiastically embraced Richard Shocke= y's comments on this yesterday. Routing multimedia services could be greatly optimized if there were more a= nd better information available in both the query and the response. E.g., = if terminating number has media attributes which the origination does not s= upport, route through transcoding media anchor, otherwise use optimized TrF= O fast path. If the basic thrust of MODERN is to get to a new and better number administ= ration and routing information data model, can we not plainly say that, and= add a charter item to develop a non-SIP and non-DNS query response protoco= l in support of that model? (It will still encounter all sorts of policy q= uestions, but at least it will be easier to talk about what we're trying to= accomplish.) Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Jul 3 19:42:02 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAC51B32FF for ; Fri, 3 Jul 2015 19:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWV7y8bPTSSz for ; Fri, 3 Jul 2015 19:42:01 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2541A1B32FA for ; Fri, 3 Jul 2015 19:42:00 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Holmes, David W [CTO]" , "Gorman, Pierce A [CTO]" , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAACsOAgABaZgCAAQnPAIAAD7yA///FsJOAAE/rgP//1x2zAEEX9AAAAxOL6A== Date: Sat, 4 Jul 2015 02:41:59 +0000 References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com>, <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> , <98ee65d16f354ea0b13e264524a5a9de@PLSWE13M08.ad.sprint.com> , <4d905a901da143a49da1ef23741eebd6@PLSWE13M01.ad.sprint.com> In-Reply-To: <4d905a901da143a49da1ef23741eebd6@PLSWE13M01.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 02:42:02 -0000 I have a modest proposal that leverages our STIR expertise: We enlist roboc= allers to check whether a number is in service or not. They seem to be able= to cover the whole numbering space and may be looking for additional incom= e. Or you could check whether a number is on the Do-Not-Call list.=0A= =0A= More seriously, the toll free number utilization issues in the US show how = difficult this is if you have entities that want to hide their hoarding: it= has been rumored that a large fraction of 800 numbers terminate on the sam= e adult entertainment services, kind of like domain parking.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Holmes, David W [CTO] [David.Holmes@sprint.com]=0A= Sent: Friday, July 03, 2015 5:02 PM=0A= To: Henning Schulzrinne; Gorman, Pierce A [CTO]; modern@ietf.org=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= But the relevant issue to MODERN is that, at very least, any allocation/adm= inistration protocol MUST support mandatory (& preferably verifiable) usage= reporting to minimize wastage of any such scarce resource?=0A= =0A= David Holmes=0A= Standards=0A= +1 425 256 7082=0A= david.holmes@sprint.com=0A= From nobody Sat Jul 4 11:15:09 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02C01A026C for ; Sat, 4 Jul 2015 11:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDb-Jx3D3KGs for ; Sat, 4 Jul 2015 11:15:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B561A014D for ; Sat, 4 Jul 2015 11:15:05 -0700 (PDT) Received: from BN1AFFO11HUB023.protection.gbl (10.58.52.133) by BN1BFFO11HUB017.protection.gbl (10.58.144.164) with Microsoft SMTP Server (TLS) id 15.1.201.10; Sat, 4 Jul 2015 18:14:49 +0000 Received: from BN1AFFO11FD047.protection.gbl (10.58.52.33) by BN1AFFO11HUB023.protection.gbl (10.58.52.133) with Microsoft SMTP Server (TLS) id 15.1.201.10; Sat, 4 Jul 2015 18:14:49 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1AFFO11FD047.mail.protection.outlook.com (10.58.53.62) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Sat, 4 Jul 2015 18:14:48 +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 t64ICrmT007454; Sat, 4 Jul 2015 13:14:48 -0500 Received: from prewe13m02.ad.sprint.com (prewe13m02.corp.sprint.com [144.226.128.21]) by plsapdm2.corp.sprint.com with ESMTP id 1ved90sq2n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 04 Jul 2015 13:14:48 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M02.ad.sprint.com (2002:90e2:8015::90e2:8015) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sat, 4 Jul 2015 14:14:46 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Sat, 4 Jul 2015 13:14:46 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne , "Holmes, David W [CTO]" , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGZz5JGBH3WP0iIwhHO+Ycc+Z3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAACsOAgABaZgCAAQnPAIAAD7yA///FsJOAAE/rgP//1x2zADiyVWAAFlVngAAV7v9A Date: Sat, 4 Jul 2015 18:14:45 +0000 Message-ID: <63866e3507ba4eca82035c7868a2df09@PLSWE13M08.ad.sprint.com> References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com>, <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> , <98ee65d16f354ea0b13e264524a5a9de@PLSWE13M08.ad.sprint.com> , <4d905a901da143a49da1ef23741eebd6@PLSWE13M01.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD047; 1:fXWa3mVVGBnc6LkXvA1IBnUFOBBuh/y4a5uoyN7NRm8b0aCzvE3WR7ApqSTcLIAbVUh/Y3AL4GlApw1A58Yi1d2K3/IDR6K0qgJygCQty5ST+orBgfHmSyVy5Fsd1N/htg7SC5mvIwEFVx0+cN7zO2ezIt1+O6eojmHOynMkCSUJvESI5W1Nwi38Z03F6HMaxtvsip0/rsMfkPuQH2jSJeI69HQWDcfsqj+N+kcjG9xNy0RofdRJs/oUdx/wGKCtMQtJVErx3/jp4hIQ0Na8ezm3DmFG29T22VeQCZ0Ydg79QwNYBfpvaHSzCl2IAEGP X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(448002)(13464003)(377454003)(199003)(189002)(97756001)(23726002)(92566002)(106466001)(50466002)(19580405001)(2501003)(108616004)(19580395003)(85326001)(87936001)(77156002)(2656002)(62966003)(5001770100001)(33646002)(561944003)(2950100001)(86362001)(5003600100002)(107886002)(5001960100002)(46102003)(189998001)(106116001)(47776003)(50986999)(102836002)(76176999)(46406003)(54356999)(2900100001)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB023; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB023; 2:RTPkOPiwL7PGkimnqgActLOEoAgs+rhfu914FukHe2nQqCHdwR83xoA+KHKsDOSu; 3:uF/H3dg7nkDNF5gWGCLZRWi8u7DuGaI2MtuLqEt4onMvWzJlpRQns45CXlMINo2Gna/32WY+paejfgHP8qeW2L0dEV6YTRREDd1r1kDi6f6fnCUDRjIGaoaRK8Emj2noR/R4gfAMOZpLd1WroivmKguRH2foyF2eaaxhK7wwgRQlKoWb9MglJRz2NnsrKvALSIhq8YzQV2nRTEuuW1qEz5iMbt0Km8RY4VzWmRbtv+zD9RBluJOnI4joW1ihzW4c; 20:xBdX2QbCJl7EbtNbgNRx97z+DYMls8UEN3DDyX2hrOoWHKno2FGMIDKwWYGFqaaG445/WtxrImt1/psvvh05zR3mt8Pl3zVM6sucDtqYcY6yXciAdgC6iqVsWgiUz3m1c5FZkAwGYogp0I1521uoxcCv4u9kc1YYnIL4B8Y07vWSGG21vGaHDdP7GxKiIA50fFgcqu3+WNSh2L9/bb6i/gBEDzRU4RY8vjPIzBJfi8uep1Eohgnoc+67374TkCoP; 4:kBk3gURbEOxEv+CroEUsWnkGwnx4FXdLrUU+3nQSRaagf/cxxXomMIoznDXGPmnJ7tCBtgZ5oeU4VWsV3G8GYMwcH6WKdbOgqVnqhXmNopVJnpzENBuXfMOh3NGT/2wMe4oItCneoBEPf/Y/xSHeq9M/880W+mkm1ztqY9bzdt6lKG36e11M6s7xl5CCG32amsRMbychaOR3E/t2OccZ3PpzqhHXOIj3FYm5hcHC3K6lNCwaZ2pyscyI+LE5iKLqvxTZJS3ZApY58P1yoK4fIhbNs86OnoB03J1iBJ6QII8= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB023; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB017; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB023; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB023; X-Forefront-PRVS: 06274D1C43 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB023; 23:yQ/DG74uzEV47ONx+qV1CorJFmjuj2YqRtjaWag?= =?us-ascii?Q?KFaj/L8mDsvoLYuhUTgu4NWzI9J8cUlEMgHFXCZ3OP9mfyY48/oaaDviNEvX?= =?us-ascii?Q?eXD3Q/DZYUcnk3qtneaOU57AMjaNGStJdAnlyEsSEreJESF7BGxyv1SyXnDD?= =?us-ascii?Q?1FZJDynmMXGJro30YQOZDIB0vRu1ZyzJ9leWtCM7TSZUj/R5b+XO8VmGa1Zy?= =?us-ascii?Q?Z4oRg7SpEF2dxc3WUcqUTs3zo3dzNfgK6YmzHw72C2CDfrSxbp/8ZPvT9ggx?= =?us-ascii?Q?QwvJeuUJArS3yMmye0xafrNKH0kFfGu7TP3bsWrvgbIE2Sd6vzpCY816NoQb?= =?us-ascii?Q?ckpVzV0f1TmEGjdy/AsB5VQYcUArqMBrejKS8o3swWGohJc7WrkWBY8Z4oAM?= =?us-ascii?Q?g6tngRMZEeClHidpweHMMeG/KlGNNxeQn//nhUNrjUPv+1TZVpLL0XulGA2j?= =?us-ascii?Q?8FGvwMStdDaMcBwEI4A894gJyCZL7+WI3wC2nGemrKLdKB4fAQ8ZZ3OqUHgj?= =?us-ascii?Q?rY/9DX9HJRZqYBsun2klG8Rlllmdvgywy5w8ggmQjGIOCfeo7Icpti5gLv3J?= =?us-ascii?Q?2gC0mrPhwlytvPXnDPz/sip7PT2MENflP3vKFNysec0ijuO8wvIFfhVuED9j?= =?us-ascii?Q?VePe/0mL1jlEdtsjmL/JgSf5WPSln1G0AFQVIZxoAOAeyzPWDTZi+4pgsxy+?= =?us-ascii?Q?A579dyio4qwYL3vyEocwmQXbW5uuzYsSX3Qs/H3wSVp9/kHwRN/AQ8AV/144?= =?us-ascii?Q?RocEhglj9wgwtC8kD+Vu9rCoROrn8fivlIKv9/eE0oKWYTm+D6SAWoxHhw+O?= =?us-ascii?Q?DqZkwJmU1jgxhjzGFWg7B5JjGYHjG8MF8zCfhpVSa30bZ5HRj604eahfeuUK?= =?us-ascii?Q?luSN7ip6eN6lUtfBe4Gp6M2ZcFxgfBKqjoW8VbvRAzAxq6n/yl0K7psNFc43?= =?us-ascii?Q?Wh1MhxurDWbMSVvUZ3dXTpLq22p/2ORiVwcmEmGebhMsOg4v7LymPCfYIAwu?= =?us-ascii?Q?PA52aUp3JMkbGuWoEdZKPBDvL9Hkuzi8ZR55SVvjYfVli915BofHBo833mpK?= =?us-ascii?Q?1p5q6Z64=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB023; 5:TGRNm3/DAugBIc2gAFTBoJGAZqiUAJWDOlEb1ZMxuN/5IB9/6Itmhl+49YpTbQqhYQ/CTIqqUPQd1ZdRpnoyym7G1GEb+7y7N9IKg1YmIXVC+/ojyjsb8dLzGBdULyBwbKKZpFHxZqLeAASamsJl/w==; 24:xMTnFHt/C9SCgHqaP5/odoQnKHuhgf1GrVbaQiTePUkPFZ02ME+djvbm0oN9P2FUQNmSRG3zQ3Z5KPLWgou+SMEpRL8AQrq4b9KCKWP6Sis= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jul 2015 18:14:48.8174 (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: BN1AFFO11HUB023 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB017; 2:sZhdWyC7Y0rKa9GjyxZKYvL3EdRy5oeM06ENZxB9g4qLCF2dY0az+GWZk4IhewcA; 3:QivQMxZ7jkJcBs3ZkI0AZQyQg7p+VfOqQ5BFJaL45CCJ8HcnDfAo6qTN1IIy7UJYyBbgyGDXS4jUo2aXuMdkOd7pS+L4y1Ok1irPBFu1lWwRm/tHfCLq2xbfd1vSIvZKdORyuf/X37KnfywBPXSuThWcR3F4pdV1gLOorJPgQV2eSWEuRys3nmiwTcECbGSJxiGe5WZZJwkXvVmfM1lVQotRrBae4pj+UHUD3/vYc1ARvWKuO5bL9HDCMlmY9ulF; 23:fTTz8KEXxspCEDUrAgRNZzjVch3qYj4UCperbmCk8Tbe/Nn47xL/cv9xsDO2uuc4IQOM/PiTCEzCJ0HwlOig4zSKg7l1ZF0JKryAXircmEVPLOVw7x+VsAbvnZEQpNgv0gEVZJ0MpX/kqfhzzJ/35wchqE4yOzqbg9IHSgYytFy1lsNI2YiS9WXMWvy5b7QnFtB44m9MS45TdgQFNApsJtOl7vpJvn19elUglo+8pHi5kl72cPbMqMTC9lmJ6ijq X-OriginatorOrg: sprint.com Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 18:15:08 -0000 Ranges of Toll Free numbers being used (and paid for and driving service of= ferings and innovation) is one thing. Pseudo-identities wrapping up TN add= ress space, potentially for "free" and for nefarious purposes is another. Regardless, I assume you're not suggesting there be no RFUS policy requirem= ents whatsoever for individual registrations, but just that it may be techn= ically challenging to police and enforce policy on individual registrations= . Do I assume correctly? Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 03, 2015 9:42 PM To: Holmes, David W [CTO]; Gorman, Pierce A [CTO]; modern@ietf.org Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) I have a modest proposal that leverages our STIR expertise: We enlist roboc= allers to check whether a number is in service or not. They seem to be able= to cover the whole numbering space and may be looking for additional incom= e. Or you could check whether a number is on the Do-Not-Call list. More seriously, the toll free number utilization issues in the US show how = difficult this is if you have entities that want to hide their hoarding: it= has been rumored that a large fraction of 800 numbers terminate on the sam= e adult entertainment services, kind of like domain parking. Henning ________________________________________ From: Holmes, David W [CTO] [David.Holmes@sprint.com] Sent: Friday, July 03, 2015 5:02 PM To: Henning Schulzrinne; Gorman, Pierce A [CTO]; modern@ietf.org Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern) But the relevant issue to MODERN is that, at very least, any allocation/adm= inistration protocol MUST support mandatory (& preferably verifiable) usage= reporting to minimize wastage of any such scarce resource? David Holmes Standards +1 425 256 7082 david.holmes@sprint.com ________________________________ 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 Sat Jul 4 17:11:28 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7808C1A9009 for ; Sat, 4 Jul 2015 17:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yNBHCisT8mB for ; Sat, 4 Jul 2015 17:11:24 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id E13251B2A78 for ; Sat, 4 Jul 2015 17:11:23 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" , "Holmes, David W [CTO]" , "modern@ietf.org" Thread-Topic: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQsNGX1ZDHS0tn4UO/TbmKEXstPp3DI3GAgAFjg4CAAApWAIAAATuAgAAEYYCAAAI6gIAAEawAgACuGgCAAA4M7IABcgaAgAAGyICAAADHAP//wdGLgABO/ACAACMwAIAACsOAgABaZgCAAQnPAIAAD7yA///FsJOAAE/rgP//1x2zAEEX9AAAAxOL6AApV2KAAAPvKfE= Date: Sun, 5 Jul 2015 00:11:22 +0000 References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com>, <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> , <98ee65d16f354ea0b13e264524a5a9de@PLSWE13M08.ad.sprint.com> , <4d905a901da143a49da1ef23741eebd6@PLSWE13M01.ad.sprint.com> , <63866e3507ba4eca82035c7868a2df09@PLSWE13M08.ad.sprint.com> In-Reply-To: <63866e3507ba4eca82035c7868a2df09@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 00:11:26 -0000 This is straying a bit far outside the MODERN scope since the decision who = gets numbers how and under what conditions is largely a policy one. (I susp= ect you could have the existing LNPA system hand out numbers to non-carrier= or iVoIP entities without changing much beyond the NECA process of filing = for OCNs.)=0A= =0A= >From what I can tell, people who have proposed treating numbers more like d= omain names have recognized that this would likely, given the scale, requir= e sufficient economic incentives to encourage frugal use of numbers, in oth= er words, some kind of charge that makes hoarding economically unattractive= .=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com]=0A= Sent: Saturday, July 04, 2015 2:14 PM=0A= To: Henning Schulzrinne; Holmes, David W [CTO]; modern@ietf.org=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= Ranges of Toll Free numbers being used (and paid for and driving service of= ferings and innovation) is one thing. Pseudo-identities wrapping up TN add= ress space, potentially for "free" and for nefarious purposes is another.= =0A= =0A= Regardless, I assume you're not suggesting there be no RFUS policy requirem= ents whatsoever for individual registrations, but just that it may be techn= ically challenging to police and enforce policy on individual registrations= . Do I assume correctly?=0A= =0A= Pierce Gorman=0A= Core Network Planning=0A= O: 913-439-4368=0A= pierce.gorman@sprint.com=0A= =0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: July 03, 2015 9:42 PM=0A= To: Holmes, David W [CTO]; Gorman, Pierce A [CTO]; modern@ietf.org=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= I have a modest proposal that leverages our STIR expertise: We enlist roboc= allers to check whether a number is in service or not. They seem to be able= to cover the whole numbering space and may be looking for additional incom= e. Or you could check whether a number is on the Do-Not-Call list.=0A= =0A= More seriously, the toll free number utilization issues in the US show how = difficult this is if you have entities that want to hide their hoarding: it= has been rumored that a large fraction of 800 numbers terminate on the sam= e adult entertainment services, kind of like domain parking.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Holmes, David W [CTO] [David.Holmes@sprint.com]=0A= Sent: Friday, July 03, 2015 5:02 PM=0A= To: Henning Schulzrinne; Gorman, Pierce A [CTO]; modern@ietf.org=0A= Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributin= g, Exposing, & Registering telephone Numbers (modern)=0A= =0A= But the relevant issue to MODERN is that, at very least, any allocation/adm= inistration protocol MUST support mandatory (& preferably verifiable) usage= reporting to minimize wastage of any such scarce resource?=0A= =0A= David Holmes=0A= Standards=0A= +1 425 256 7082=0A= david.holmes@sprint.com=0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= From nobody Sun Jul 5 00:17:57 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E491B2BFF for ; Sun, 5 Jul 2015 00:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 Q9i6rWrydC8U for ; Sun, 5 Jul 2015 00:17:54 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B9B1B2BFA for ; Sun, 5 Jul 2015 00:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=fW3T+P4VJ9hPTc0LqHRvipvJ7pUf0n/S5Bv+xKSLImk=; b=rh2j72YGHUfsEhJFuPI0UOOQXTR/a1kIhNAX0hk0Upyy1ws27DuEg1WDUBrxXqtLqiVYayBExQ0SVbiRZAIWX13W3+RaMIdliqQc2OnY6xYz90tUqnG9KsEfTptPv6XCNyls7ehCbYqVRdTevr8yCJv9H2sQNYY147MvZzxuq50=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:64093 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZBeBT-0000Ch-Qz for modern@ietf.org; Sun, 05 Jul 2015 00:17:54 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Eric Burger In-Reply-To: <88DDD845-D33C-464A-83F1-46BC6B5B1BE7@iii.ca> Date: Sun, 5 Jul 2015 03:17:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14AD8E93-0BD1-475D-B8B5-F53F490E5F60@standardstrack.com> References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> <313a3ea588c845e1ad832696e36b13d7@PLSWE13M01.ad.sprint.com> <88DDD845-D33C-464A-83F1-46BC6B5B1BE7@iii.ca> To: "modern@ietf.org" X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 07:17:55 -0000 Would it not be easier to call it what it is? A bunch of =E2=80=9Crelevant people=E2=80=9D are interested in doing = this work. =E2=80=9CThis work=E2=80=9D is claimed to not have impacts on = numbering policy, national regulatory bodies, international treaties, = etc. As such, it may be OK to ignore the vehement objections to the IESG = chartering the work group, as those folks are not the target audience. In fact, most of the =E2=80=9Crelevant people=E2=80=9D to the real, = current, in the physical world numbering ecosystem have stated flatly = and unconditionally they do not care for this work. So, they don=E2=80=99t= need to work on it, use the results, write scathing letters to their = national regulators, etc. Can we note that this work group is not targeted to working on a = solution to replace anything that exists today? It is just a mechanism = for handing out short (numeric?) identifiers that have some opaque = policy tokens passed around. That way, the people who really want to = work on this (IMHO, academically interesting) problem can work on it, = and those that do not, don=E2=80=99t? The fact that today there is a = market of five that could use what has been described as being worked on = becomes less of an issue. There were at least five hands that went up in = the room saying they were willing to work on the problem. The 95 people = who said this was brain dead can leave it to its death spiral. Or, if it = turns out to be interesting, I=E2=80=99m sure 60 of the 95 will say =E2=80= =9CI was at the BOF." > On Jul 2, 2015, at 2:41 PM, Cullen Jennings wrote: >=20 > Ignoring rough consensus here ... my personal observation would be it = seems there are a bunch of people from relevant communities interested = in spending some time discussing problems and solutions in this general = space. There are proof points that at least some of the simpler version = of the problem can be solved - this does not mean we should use them, = they are just an existence proof that at least some of the problems can = be solved. There seem to be a fair number of people that might use the = solutions if the IETF standardized them. Do we agree on the exact = solution - no. Do we even agree on what parts of the problem we have to = solve in the first part and what can be left to later - no. But I think = that largely we agree that there are some problems in this general space = where some useful solutions could be developed. In my mind we have some = people that want to do some work, figuring out the exact requirements = and solutions if what the WG will do.=20 From nobody Sun Jul 5 00:19:08 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BFB1B2C02 for ; Sun, 5 Jul 2015 00:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EweyH4XQyx8w for ; Sun, 5 Jul 2015 00:19:05 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36E81B2C00 for ; Sun, 5 Jul 2015 00:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=iRtKe5aJI3Tfd4xVo6ijIXfVfgN0De0kdpNwNqKwEjk=; b=sbUpTsPG0bVynToM3AJeuYL4b5oJDr01FFliLNeDxjm+VknaNSAP05C4OopKXKrl7rAT1CSwr9l+cV+W5myGdLsIxUQnBtMHsXzOtq+KAUpkNOkDkrNO8klLeTvxDEZn+s9jZ7Q0olwTQx1NM8Plwd0VdqW0BlRpLAxXoOLz+7o=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:64176 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZBeCa-0001LQ-7l for modern@ietf.org; Sun, 05 Jul 2015 00:19:04 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_AA5406F9-BA91-4FB5-BAB9-339D3D8699F3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5 From: Eric Burger In-Reply-To: <89D5CE1D-AE42-445F-AE4F-E73BBB4969FD@georgetown.edu> Date: Sun, 5 Jul 2015 03:18:57 -0400 Message-Id: <9CD54417-E770-40BF-B305-8EDA1B379BB1@standardstrack.com> References: <2B0F677F0B95454297753F58D4A07FA3027A80AF59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3027A80B3E8@FHDP1LUMXC7V31.us.one.verizon.com> <66867970ee0b41a6b171cc1d254bf855@PLSWE13M08.ad.sprint.com> <98ee65d16f354ea0b13e264524a5a9de@PLSWE13M08.ad.sprint.com> <89D5CE1D-AE42-445F-AE4F-E73BBB4969FD@georgetown.edu> To: "modern@ietf.org" X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 07:19:07 -0000 --Apple-Mail=_AA5406F9-BA91-4FB5-BAB9-339D3D8699F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What strikes me from this conversation is the IETF created the DNS, so = that ICANN could have a field day. In this context I am thinking of all = of those useful contributors to society such as domainers, squatters, = phishers, blackmail gTLD=E2=80=99s, etc. Who will take the result of MODERN and build squatting empires? > On Jul 2, 2015, at 2:01 PM, Henning Schulzrinne = wrote: >=20 > There are two known ways to deal with scarcity (and avoid waste): = administrative (make rules that ensure "use it or lose it") and = economical ("pay for it"). I don't think we need to solve this here, but = you wouldn't be surprised that relevant folks are well aware of the = trade-offs, given a rich history across identifiers, radio spectrum and = non-network resources. >=20 > ________________________________________ > From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] > Sent: Thursday, July 02, 2015 12:25 PM > To: Henning Schulzrinne; modern@ietf.org > Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > Agreed wrt HTTP. >=20 > Media/Service attributes, and services associated with a number (URIs = only?) seem like the most pertinent categories of interest. >=20 > And wrt Joe's Hot Dog Stand as a use case, should count on Joe wanting = multiple numbers to more easily differentiate service configuration for = multiple personal communications services identities; business, = personal, social, etc., which begs the policy question of NRUF-like = enforcement. >=20 > Best regards, >=20 >=20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com >=20 >=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: July 02, 2015 10:44 AM > To: Gorman, Pierce A [CTO]; modern@ietf.org > Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > Thank you for moving towards more specificity. Reachability and = properties do indeed seem like important facets of this problem (see my = other note on our experimental sandbox). One of the questions is whether = a generic (HTTP?) query protocol should be specialized to just retrieve = the URL or if this a sufficiently important and different case to = warrant a completely different mechanism. >=20 > Henning >=20 > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A = [CTO] [Pierce.Gorman@sprint.com] > Sent: Thursday, July 02, 2015 11:08 AM > To: Dwight, Timothy M (Tim); McGarry, Tom; modern@ietf.org > Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, = Distributing, Exposing, & Registering telephone Numbers (modern) >=20 > Based on the different use case suggestions and comments of "legacy = databases" being "interfaces" into whatever MODERN creates, it seems the = idea is to create a super-database data model(s) and protocol(s) to = enable "options that bypass" the problems an NRA encounters employing = conventional policy approaches to updating regulated telecommunications = infrastructure. >=20 > Why don't we speak plainly? In the US, there is a perception that = LERG and NPAC, etc., are not the best data model and protocols for = managing telephone numbers and routing information for those numbers. = (Who doesn't love TP4 and CMIS/CMIP?) >=20 > OK. No heartburn with that view. One of the things that the SIP = Forum/ATIS Joint Task Force has worked on is different models for = managing routing information including a proposal for a monolithic = per-TN URI database ostensibly achieving what LERG and NPAC having URI = fields will do. >=20 > What this illustrated was that whether the databases are centralized = or distributed doesn't inhibit policy and that numbering and routing = folks embrace thinking outside the "legacy" box. >=20 > Another output of the JTF work was a focus on a "Tiered ENUM" proposal = which presents interesting operational challenges and highlighted the = value (again) of developing something better than DNS for = telecommunications routing query and response which is why I = enthusiastically embraced Richard Shockey's comments on this yesterday. >=20 > Routing multimedia services could be greatly optimized if there were = more and better information available in both the query and the = response. E.g., if terminating number has media attributes which the = origination does not support, route through transcoding media anchor, = otherwise use optimized TrFO fast path. >=20 > If the basic thrust of MODERN is to get to a new and better number = administration and routing information data model, can we not plainly = say that, and add a charter item to develop a non-SIP and non-DNS query = response protocol in support of that model? (It will still encounter = all sorts of policy questions, but at least it will be easier to talk = about what we're trying to accomplish.) >=20 > Best regards, >=20 >=20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com >=20 >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_AA5406F9-BA91-4FB5-BAB9-339D3D8699F3 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 iQIcBAEBCAAGBQJVmNphAAoJEORoZaSQsc1I+TQQAJcSqs2NGfQ58SwhhJD68+iS haJi9kLgWl90loz5jOVRRZljhTEu2T5zzTmAzjSAILNVvRu9TQWmsTvBY7yBGhjK cYTj7WQ3cT0uRUMz8eqSKr663YTr1d2/88MmVkKZnZI0s7p/ExGed7JehtCZ0PtE vt4jpMLfeTIlnpfv+F5iIFPmPekZsM/q+Xq54/sZVOu5nRV1tt2Aq6NGBH6c7vt+ 3FdSKcj3ZAIzefSUvS/AqWrmgOYpgel5PmWRwZrSVjk59eyXHprdQmLWo/ipeEnN sPp57MTqrVXABm9OaoouQdXtQZro7blaLzgel2+BFtOA1Hbptn3WOAahQ2TLebDs a/pBQKoWZ7YljvIWtZK5hOxkPnw/Kl7xWf09I7vp9VtYKP7SGOmrYrNo6T4OwvDI l1o8w5WWKGv+jrqy4m5uPE71/iM42u0iwesv1SbvmltySK6WykkfQmK1/C8o98r2 ++iz1wIcw71FAXI/Nwz1OujHzxJIX9TMZ4bhwlDWkm0+Hmm48KsZGSTx6+C1bYJf r39iAReDntdczdI7UcBeHtGzQxhL8Ot9XhChAIuZmLDYJRArdupSwgPhqVLdZ5v6 CmV6vSK7RrbW9h4FQDTflFcpK+IAhLXoohAnpte83rmyRzwVdsTkXTcKWQaKOy/T OTR2M5qo08Grfig491wo =UP33 -----END PGP SIGNATURE----- --Apple-Mail=_AA5406F9-BA91-4FB5-BAB9-339D3D8699F3-- From nobody Mon Jul 6 11:08:18 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCB1A86FC for ; Mon, 6 Jul 2015 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19XJtISkZQT3 for ; Mon, 6 Jul 2015 11:08:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE1C1A6F11 for ; Mon, 6 Jul 2015 11:08:05 -0700 (PDT) Received: from BN1BFFO11FD020.protection.gbl (10.58.144.32) by BN1BFFO11HUB038.protection.gbl (10.58.144.185) with Microsoft SMTP Server (TLS) id 15.1.201.10; Mon, 6 Jul 2015 18:07:50 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN1BFFO11FD020.mail.protection.outlook.com (10.58.144.83) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Mon, 6 Jul 2015 18:07:50 +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 t66I7LOv021744; Mon, 6 Jul 2015 14:07:50 -0400 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm3.corp.sprint.com with ESMTP id 1ve9r2n9gx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 06 Jul 2015 14:07:50 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 6 Jul 2015 13:07:48 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Mon, 6 Jul 2015 13:07:48 -0500 From: "Gorman, Pierce A [CTO]" To: Eric Burger , "modern@ietf.org" Thread-Topic: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) Thread-Index: AQHQtPbDhqkyszBvW0adt8r9wocthJ3Mz0uAgAHLDhA= Date: Mon, 6 Jul 2015 18:07:48 +0000 Message-ID: References: <9bdeb496cc524575a4ece857fa54e56f@TUCM03.TUECSP.UNICC.ORG> <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <4A21587C-69AF-49C3-B2D8-18F8F2ACAA7C@cooperw.in> <1aacdc5bbb5b4991961136b881bb842b@PLSWE13M08.ad.sprint.com> <4303B28C-B0B3-4781-A44E-D02D3F635F7D@iii.ca> <313a3ea588c845e1ad832696e36b13d7@PLSWE13M01.ad.sprint.com> <88DDD845-D33C-464A-83F1-46BC6B5B1BE7@iii.ca> <14AD8E93-0BD1-475D-B8B5-F53F490E5F60@standardstrack.com> In-Reply-To: <14AD8E93-0BD1-475D-B8B5-F53F490E5F60@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.26] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD020; 1:KgHcJk95HArW72nSz+uehjndocWWYnWGyb2OY70Fj2GJHZNla7CTTk7LGRpL8ruFrRlWpquofbkvxvqrBXvkxneoluxoMQqXrQsI9xKP+0yC1u/UCP6GFXt48gt3+oq6S6KLjEeUwLHmFTh7q0Y3HtIQxUUm125RcA7i/0TkOCXbHeAtT7lnVtOkB1spVmA60EP0Yp5igtT0irdtapa65yRxEVu0CFYR3X9Ho9VqMldGB6e8NJHDb1G+56DqNtPzTDopFcWQ2zSfvbVo0y5gIybv0Oc3dbV9zhhU3+r9aSIPItKs4NaNsPv3bl1FGCt4 X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(448002)(24454002)(13464003)(377454003)(199003)(189002)(51704005)(2656002)(87936001)(102836002)(15975445007)(23676002)(93886004)(33646002)(108616004)(86362001)(106466001)(189998001)(50466002)(107886002)(5001770100001)(5001960100002)(2900100001)(2950100001)(85326001)(92566002)(46102003)(2501003)(19580395003)(19580405001)(106116001)(6806004)(54356999)(5003600100002)(76176999)(50986999)(77156002)(62966003)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB038; H:preapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB038; 2:F0hW0K8ts5yfzKAxwFahWrwkHQrzOkghhquvMaC4ocTcKLvVO1SSUbzlSbIPfHol; 3:ubJMZOo0ioC7kiii5JqcCJSBM/M7Z8NAb9gwzSVgUjPYvl4kk8jd2KvGAZtUFxeSd/auBfpR+x2LluDos7ewYirmR/UfgbZ6j5y9SO7pu/XxQXwuoh0iCvl+oIrkN9P+8m3uAIac5LPMczc2yVbJXvinRoweDKVAWpGTqcvooxrB4uHaaw5Dt6xceFaXeKH1nUn+n76mgUpV3O1olbmkyLIpamjY0pA/XpKGDe471Vo=; 20:Noaj+jJWVw6Rz4fRR+wgHxlRt6INrXjmpfQahuwYxng8dmsciUSnWgOouLf6bXv30C4Kq3IL+7Y0T2ssaJDPSEC+BXStAG3G++cZJyzz1YXtFU1jKQVB3IsTJEi1MJPrA78AA2jlWkug1I/3CY4TefKmshVSi5nsWsiSRaaZ7AvxuLKN+3RnInUhIFtD7dUleIzBzbT1ox6bhXksNXmGm/m0oVgeH2RqsFJHAt0eRK//+i6SMGHTaza9t5tFkbH7; 4:FfXSW5SR9zEX9bLXR/atwjbgRIw78tHnxGAafFdwVslKgQleGrKzexBax23fBO8AzNYL45xVFp62pH/kOhPZFedBIoU9BBk+kzbPrVD7HrijdpQb0yq33nqeiF6l06wbxeoHcMb/pJq29CGCVrqfXhE3DwkSkmK8Jv+7S/2QXYBfU+B7CLq/GbrHT26WwR6OXN9AJAFjgdQ1MsbWG9kBsakTEcfZy2e8NbSffNm4cm7U2g13VdwGngQmWS59/8P0fzQWMRSAq/MIIGMWgt5CVvgo6ps6YmQid3jJnJ74u48= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB038; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB038; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB038; X-Forefront-PRVS: 06290ECA9D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFCRkZPMTFIVUIwMzg7MjM6RmZPZHRJQnNtUEMvU25Zd25idnFJMVFy?= =?utf-8?B?UmQ4VmpyaHV5UHRmSXhmUDg0U3hMeURySHpZbGw3TThxdEV5Rk1KKzVuNjFG?= =?utf-8?B?RWFVT21neXhsaGdSbXBtNXBxcGk0dXJCcE00cVB2QitlandtN1NoNk9oVEFo?= =?utf-8?B?RjBmN0xQOENTRlgzTkYyUDVHUjN3UTI2ci9jNWxTd1J2dTVSdGxERXFHUURH?= =?utf-8?B?S0xOQ2tWSVpWRWEzdFlWbUdIRndhZHJaODhzZElFTHlQc1F3YWtMbm5yRllQ?= =?utf-8?B?OGthQVA2ZEVqblZ0UStWOFgvQllyVEZyRFV2N29xVmgzUHh3RXRpVHNYTzFI?= =?utf-8?B?RXR6c1FtbFlqM2xpb3ZaTCtxeXdHWjdQeEpWZ3ZLWDlyV1I2a3U4dXB2dGRk?= =?utf-8?B?K2xaS2sweFBQWUs3QlVKNDlOS2srOXpic3BaVkx3dWdHb3MvcVZKWHJENVBI?= =?utf-8?B?ZU16OWNTeitlSjVMa04xcWhkRkxIWGIxYmlWSDZTM2dHbWhmY1pOR3hnZnA2?= =?utf-8?B?NjRhQTlBcWF3WS80eXZFcU00UHp0SkhVNURnaXBuWE1sQ2g4T3ZiamZQaGFs?= =?utf-8?B?QTFNQ1lORi9TRmtzMTFmampObjlhdkJmR0lIY28zbThreFdPRVVWTHFvVGVT?= =?utf-8?B?NVNkNXFBRjhPYjQyUDBmdGJMQ0lFWVgxL0V1VTkxeXhzZVRGRG1zeVFsMHZX?= =?utf-8?B?K3A2NFlsVFpQbFVyRDYwK1NZYjZXWk5wd0JKN0J5NzFuR25uOVlvaU5nb3NX?= =?utf-8?B?dUJTM0lVeG90aGZEU2lTV2tLMksrNzAyU2tPOGZsQkIrK0NkeDE0K1pUUkxV?= =?utf-8?B?RU5UOGRvdVBYdHJMR3FMcHFpNlVyZmtIRWR5QWw1a2ljaitJUVhpNXZGYnZx?= =?utf-8?B?b3drSmZ1MUpMdUc5cGR5cUxUWm5WbGJ3OHRDM0QrSDNkYVluWHcwM2hXdG03?= =?utf-8?B?cGdqT1J5R2t5YjczZXZHTDNNaS9QRndXWHB3UFphK2JPUkNIcVlCbk9ubld1?= =?utf-8?B?YUFVTy9ETlU5NXQ4RWZnNlgyYzZBbG56eHlCZHl3LzZCN1k3ZFJDT1RTQWpZ?= =?utf-8?B?WWE4a3c1V2NjK01wZFgwOE1ENFFId3RzSFhiNk9aNFk4K0RweW92dGtFOVhp?= =?utf-8?B?a0VWZFU0ekRIaDUydjBESVU1TklWcTRnMnlpaGw5S01jSEo0SGtBYW5Ib3lR?= =?utf-8?B?LzdoSHhYNmhRaW9adlVqdytrVGVxMGtBM29ZcUROMTFWempJa0FmTUpYK0d5?= =?utf-8?B?Uk1sMHZ6aEN5RTFpelVVdWtPRWcvSUhsOTkrZ0lxUVZKYllrNi9nRnFaYXVS?= =?utf-8?B?RlNqc1Fxd2hMTVE5ZWFEcFVEbW1pWWpoUys0b3k3dlpzRHM2Z0NiRWg2Tnp1?= =?utf-8?B?Y0ZLa3p5czJVTjBibHE5WVgrb293VHNsbHYxTGFZZUpMSkhTMEVQaWJYNTMw?= =?utf-8?Q?yvonbBKV5lHzAVNESllULYZ0iyrJZ?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB038; 5:vdpJYG2Weu/nhOcQGnj4/BASBspzJfFZWmBBP4q7hpwhA8w02k0O+Pr2eJ5iovxVMtiljF1OCRj4BrsD3SWeNoeJ+wUA9gP5aB4VyNWK2XF+zwsWX/avRWawURcht8FS5+AbmCcxFVc2WYW2OVncDw==; 24:+WTaFP1keRmdid15IV5DJ83Qz85FsOYhlVMANcElCrMCWerKYaxlzKtt+/PbK0SOWsuiF92oBpQQkvedDVfNeRBu8UrTNCvuvTKKDRdL/Zs= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2015 18:07:50.3509 (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: BN1BFFO11HUB038 Archived-At: Subject: Re: [Modern] Rough consensus - Re: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:08:17 -0000 WW91IG1ha2UgaXQgc291bmQgbGlrZSB0aGVyZSB3YXNuJ3QgInJvdWdoIGNvbnNlbnN1cyIuDQoN Ck1PREVSTiBtYXkgYmUgc3VjY2Vzc2Z1bCB0aG91Z2guICBETlMgaGFzIHRvIGJlIGNvbnNpZGVy ZWQgYSBzdWNjZXNzIGV2ZW4gd2l0aCBhbGwgb2YgaXRzIG9wZXJhdGlvbmFsIGFuZCBwb2xpdGlj YWwgd2FydHMgKGFzIGxvbmcgYXMgbm9ib2R5IGNhcmVzIGFib3V0IHBvcnRhYmxpdHkgYW55d2F5 KS4NCg0KQW5kLCBwcmVzdW1hYmx5IHRoZSBFTlVNIExMQyBmaWFzY28gcHJvdmlkZWQgYSBwb2ln bmFudCBsZXNzb24gaW4gaG93IG5vdCB0byBjcmVhdGUgYSBwdWJsaWMgZGF0YWJhc2Ugb2YgdGVs ZXBob25lIG51bWJlcnMuDQoNCklNSE8sIGZvciBNT0RFUk4gdG8gYmUgc3VjY2Vzc2Z1bCwgdGhl IHJlc3VsdHMgbmVlZCB0byB3b3JrIGZvciBmdXR1cmUgQU5EIGV4aXN0aW5nIG5lZWRzLiAgVGhv c2UgbmVlZHMgYXJlIG1hbnkgYW5kIGNvbXBsZXggc28gdGltZSBzaG91bGQgYmUgdGFrZW4gdG8g Z2V0IGl0IHJpZ2h0LiAgVGFraW5nIHRoZSB0aW1lIHRvIGdldCBpdCByaWdodCBoYXNuJ3QgYmVl biB0aGUgaGFsbG1hcmsgb2YgdGhpcyBXRywgYnV0IHBhc3QgcGVyZm9ybWFuY2UgaXNuJ3QgYWx3 YXlzIGFuIGluZGljYXRvciBvZiBmdXR1cmUgcmVzdWx0cy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVybi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRXJpYyBCdXJnZXINClNlbnQ6IEp1bHkgMDUsIDIwMTUgMjoxOCBBTQ0KVG86 IG1vZGVybkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNb2Rlcm5dIFJvdWdoIGNvbnNlbnN1cyAt IFJlOiBbbmV3LXdvcmtdIFdHIFJldmlldzogTWFuYWdpbmcsIE9yZGVyaW5nLCBEaXN0cmlidXRp bmcsIEV4cG9zaW5nLCAmIFJlZ2lzdGVyaW5nIHRlbGVwaG9uZSBOdW1iZXJzIChtb2Rlcm4pDQoN CldvdWxkIGl0IG5vdCBiZSBlYXNpZXIgdG8gY2FsbCBpdCB3aGF0IGl0IGlzPw0KDQpBIGJ1bmNo IG9mIOKAnHJlbGV2YW50IHBlb3BsZeKAnSBhcmUgaW50ZXJlc3RlZCBpbiBkb2luZyB0aGlzIHdv cmsuIOKAnFRoaXMgd29ya+KAnSBpcyBjbGFpbWVkIHRvIG5vdCBoYXZlIGltcGFjdHMgb24gbnVt YmVyaW5nIHBvbGljeSwgbmF0aW9uYWwgcmVndWxhdG9yeSBib2RpZXMsIGludGVybmF0aW9uYWwg dHJlYXRpZXMsIGV0Yy4gQXMgc3VjaCwgaXQgbWF5IGJlIE9LIHRvIGlnbm9yZSB0aGUgdmVoZW1l bnQgb2JqZWN0aW9ucyB0byB0aGUgSUVTRyBjaGFydGVyaW5nIHRoZSB3b3JrIGdyb3VwLCBhcyB0 aG9zZSBmb2xrcyBhcmUgbm90IHRoZSB0YXJnZXQgYXVkaWVuY2UuDQoNCkluIGZhY3QsIG1vc3Qg b2YgdGhlIOKAnHJlbGV2YW50IHBlb3BsZeKAnSB0byB0aGUgcmVhbCwgY3VycmVudCwgaW4gdGhl IHBoeXNpY2FsIHdvcmxkIG51bWJlcmluZyBlY29zeXN0ZW0gaGF2ZSBzdGF0ZWQgZmxhdGx5IGFu ZCB1bmNvbmRpdGlvbmFsbHkgdGhleSBkbyBub3QgY2FyZSBmb3IgdGhpcyB3b3JrLiBTbywgdGhl eSBkb27igJl0IG5lZWQgdG8gd29yayBvbiBpdCwgdXNlIHRoZSByZXN1bHRzLCB3cml0ZSBzY2F0 aGluZyBsZXR0ZXJzIHRvIHRoZWlyIG5hdGlvbmFsIHJlZ3VsYXRvcnMsIGV0Yy4NCg0KQ2FuIHdl IG5vdGUgdGhhdCB0aGlzIHdvcmsgZ3JvdXAgaXMgbm90IHRhcmdldGVkIHRvIHdvcmtpbmcgb24g YSBzb2x1dGlvbiB0byByZXBsYWNlIGFueXRoaW5nIHRoYXQgZXhpc3RzIHRvZGF5PyBJdCBpcyBq dXN0IGEgbWVjaGFuaXNtIGZvciBoYW5kaW5nIG91dCBzaG9ydCAobnVtZXJpYz8pIGlkZW50aWZp ZXJzIHRoYXQgaGF2ZSBzb21lIG9wYXF1ZSBwb2xpY3kgdG9rZW5zIHBhc3NlZCBhcm91bmQuIFRo YXQgd2F5LCB0aGUgcGVvcGxlIHdobyByZWFsbHkgd2FudCB0byB3b3JrIG9uIHRoaXMgKElNSE8s IGFjYWRlbWljYWxseSBpbnRlcmVzdGluZykgcHJvYmxlbSBjYW4gd29yayBvbiBpdCwgYW5kIHRo b3NlIHRoYXQgZG8gbm90LCBkb27igJl0PyBUaGUgZmFjdCB0aGF0IHRvZGF5IHRoZXJlIGlzIGEg bWFya2V0IG9mIGZpdmUgdGhhdCBjb3VsZCB1c2Ugd2hhdCBoYXMgYmVlbiBkZXNjcmliZWQgYXMg YmVpbmcgd29ya2VkIG9uIGJlY29tZXMgbGVzcyBvZiBhbiBpc3N1ZS4gVGhlcmUgd2VyZSBhdCBs ZWFzdCBmaXZlIGhhbmRzIHRoYXQgd2VudCB1cCBpbiB0aGUgcm9vbSBzYXlpbmcgdGhleSB3ZXJl IHdpbGxpbmcgdG8gd29yayBvbiB0aGUgcHJvYmxlbS4gVGhlIDk1IHBlb3BsZSB3aG8gc2FpZCB0 aGlzIHdhcyBicmFpbiBkZWFkIGNhbiBsZWF2ZSBpdCB0byBpdHMgZGVhdGggc3BpcmFsLiBPciwg aWYgaXQgdHVybnMgb3V0IHRvIGJlIGludGVyZXN0aW5nLCBJ4oCZbSBzdXJlIDYwIG9mIHRoZSA5 NSB3aWxsIHNheSDigJxJIHdhcyBhdCB0aGUgQk9GLiINCg0KPiBPbiBKdWwgMiwgMjAxNSwgYXQg Mjo0MSBQTSwgQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAaWlpLmNhPiB3cm90ZToNCj4NCj4gSWdu b3Jpbmcgcm91Z2ggY29uc2Vuc3VzIGhlcmUgLi4uIG15IHBlcnNvbmFsIG9ic2VydmF0aW9uIHdv dWxkIGJlIGl0IHNlZW1zIHRoZXJlIGFyZSBhIGJ1bmNoIG9mIHBlb3BsZSBmcm9tIHJlbGV2YW50 IGNvbW11bml0aWVzIGludGVyZXN0ZWQgaW4gc3BlbmRpbmcgc29tZSB0aW1lIGRpc2N1c3Npbmcg cHJvYmxlbXMgYW5kIHNvbHV0aW9ucyBpbiB0aGlzIGdlbmVyYWwgc3BhY2UuIFRoZXJlIGFyZSBw cm9vZiBwb2ludHMgdGhhdCBhdCBsZWFzdCBzb21lIG9mIHRoZSBzaW1wbGVyIHZlcnNpb24gb2Yg dGhlIHByb2JsZW0gY2FuIGJlIHNvbHZlZCAtIHRoaXMgZG9lcyBub3QgbWVhbiB3ZSBzaG91bGQg dXNlIHRoZW0sIHRoZXkgYXJlIGp1c3QgYW4gZXhpc3RlbmNlIHByb29mIHRoYXQgYXQgbGVhc3Qg c29tZSBvZiB0aGUgcHJvYmxlbXMgY2FuIGJlIHNvbHZlZC4gVGhlcmUgc2VlbSB0byBiZSBhIGZh aXIgbnVtYmVyIG9mIHBlb3BsZSB0aGF0IG1pZ2h0IHVzZSB0aGUgc29sdXRpb25zIGlmIHRoZSBJ RVRGIHN0YW5kYXJkaXplZCB0aGVtLiBEbyB3ZSBhZ3JlZSBvbiB0aGUgZXhhY3Qgc29sdXRpb24g LSBuby4gRG8gd2UgZXZlbiBhZ3JlZSBvbiB3aGF0IHBhcnRzIG9mIHRoZSBwcm9ibGVtIHdlIGhh dmUgdG8gc29sdmUgaW4gdGhlIGZpcnN0IHBhcnQgYW5kIHdoYXQgY2FuIGJlIGxlZnQgdG8gbGF0 ZXIgLSBuby4gQnV0IEkgdGhpbmsgdGhhdCBsYXJnZWx5IHdlIGFncmVlIHRoYXQgdGhlcmUgYXJl IHNvbWUgcHJvYmxlbXMgaW4gdGhpcyBnZW5lcmFsIHNwYWNlIHdoZXJlIHNvbWUgdXNlZnVsIHNv bHV0aW9ucyBjb3VsZCBiZSBkZXZlbG9wZWQuIEluIG15IG1pbmQgd2UgaGF2ZSBzb21lIHBlb3Bs ZSB0aGF0IHdhbnQgdG8gZG8gc29tZSB3b3JrLCBmaWd1cmluZyBvdXQgdGhlIGV4YWN0IHJlcXVp cmVtZW50cyBhbmQgc29sdXRpb25zIGlmIHdoYXQgdGhlIFdHIHdpbGwgZG8uDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNb2Rlcm4gbWFpbGluZyBs aXN0DQpNb2Rlcm5AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW9kZXJuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1t YWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlz IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdl Lg0K From nobody Tue Jul 21 06:26:57 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539C81B2D1E for ; Tue, 21 Jul 2015 03:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hLR885ZKZVCJ for ; Tue, 21 Jul 2015 03:13:49 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 3312D1B2D45 for ; Tue, 21 Jul 2015 03:13:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id BDF891E59F2; Tue, 21 Jul 2015 03:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_b6pFW7imlH; Tue, 21 Jul 2015 03:13:09 -0700 (PDT) Received: from dhcp-b22e.meeting.ietf.org (dhcp-b22e.meeting.ietf.org [31.133.178.46]) by c8a.amsl.com (Postfix) with ESMTPA id 0E22A1E59D4; Tue, 21 Jul 2015 03:13:08 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alexa Morris Date: Tue, 21 Jul 2015 03:13:47 -0700 Content-Transfer-Encoding: quoted-printable Sendlaterdate: Tue, 21 Jul 2015 03:13:47 -0700 Message-Id: <99FB8EEC-0F6F-4DF7-829D-AF08AAF401D2@amsl.com> To: modern@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 21 Jul 2015 06:26:52 -0700 Subject: [Modern] Virtual Queue for MODERN WG Session Today at IETF 93 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, 21 Jul 2015 10:13:55 -0000 MODERN WG Participants, If you are planning to participate in MODERN here at IETF 93 this = afternoon =97 either locally in Prague or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a new way to ask questions or make comments. In = addition to using the Jabber room, for the MODERN session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in a few sessions at IETF 92, so you = may have already seen it in action. Some improvements have been made = since the last meeting, but the concept is the same. There will be two = queues for the MODERN session =97 a virtual queue and an actual = (in-room) queue.=20 Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf93.conf.meetecho.com/index.php/Remote_Participation. Join the Meetecho session for MODERN at 15:20 today using this link = http://www.meetecho.com/ietf93/modern Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf93.conf.meetecho.com/index.php/Self_Test Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Wed Jul 22 09:45:21 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1018C1B2BA5 for ; Wed, 22 Jul 2015 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 9aKdO2rVyRBJ for ; Wed, 22 Jul 2015 09:41:24 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id F104C1B2B7D for ; Wed, 22 Jul 2015 09:40:17 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUgG1q01r2NEPrz01UgHS7; Wed, 22 Jul 2015 18:40:17 +0200 Date: Wed, 22 Jul 2015 18:40:18 +0200 (CEST) From: Meetecho Team To: modern@ietf.org Message-ID: <330675554.17.1437583218334.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16_1949966003.1437583218332" Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 09:45:20 -0700 Subject: [Modern] Meetecho recordings of MODERN WG session 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, 22 Jul 2015 16:41:25 -0000 ------=_Part_16_1949966003.1437583218332 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the MODERN WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#MODERN In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_16_1949966003.1437583218332--